draft-ietf-anima-autonomic-control-plane-21.txt   draft-ietf-anima-autonomic-control-plane-22.txt 
ANIMA WG T. Eckert, Ed. ANIMA WG T. Eckert, Ed.
Internet-Draft Futurewei USA Internet-Draft Futurewei USA
Intended status: Standards Track M. Behringer, Ed. Intended status: Standards Track M. Behringer, Ed.
Expires: May 5, 2020 Expires: August 6, 2020
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
November 2, 2019 February 3, 2020
An Autonomic Control Plane (ACP) An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-21 draft-ietf-anima-autonomic-control-plane-22
Abstract Abstract
Autonomic functions need a control plane to communicate, which Autonomic functions need a control plane to communicate, which
depends on some addressing and routing. This Autonomic Management depends on some addressing and routing. This Autonomic Management
and Control Plane should ideally be self-managing, and as independent and Control Plane should ideally be self-managing, and as independent
as possible of configuration. This document defines such a plane and as possible of configuration. This document defines such a plane and
calls it the "Autonomic Control Plane", with the primary use as a calls it the "Autonomic Control Plane", with the primary use as a
control plane for autonomic functions. It also serves as a "virtual control plane for autonomic functions. It also serves as a "virtual
out-of-band channel" for Operations Administration and Management out-of-band channel" for Operations Administration and Management
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 5, 2020. This Internet-Draft will expire on August 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction (Informative) . . . . . . . . . . . . . . . . . 6 1. Introduction (Informative) . . . . . . . . . . . . . . . . . 5
1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 8 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 8
2. Acronyms and Terminology (Informative) . . . . . . . . . . . 10 2. Acronyms and Terminology (Informative) . . . . . . . . . . . 9
3. Use Cases for an Autonomic Control Plane (Informative) . . . 16 3. Use Cases for an Autonomic Control Plane (Informative) . . . 15
3.1. An Infrastructure for Autonomic Functions . . . . . . . . 16 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 15
3.2. Secure Bootstrap over a not configured Network . . . . . 16 3.2. Secure Bootstrap over a not configured Network . . . . . 15
3.3. Data-Plane Independent Permanent Reachability . . . . . . 16 3.3. Data-Plane Independent Permanent Reachability . . . . . . 16
4. Requirements (Informative) . . . . . . . . . . . . . . . . . 18 4. Requirements (Informative) . . . . . . . . . . . . . . . . . 17
5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 19 5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 18
6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 20 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 20
6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 20 6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 20
6.1.1. ACP Certificates . . . . . . . . . . . . . . . . . . 21 6.1.1. ACP Certificates . . . . . . . . . . . . . . . . . . 21
6.1.2. ACP Certificate ACP Domain Information Field . . . . 23 6.1.2. ACP Certificate ACP Domain Information Field . . . . 23
6.1.3. ACP domain membership check . . . . . . . . . . . . . 26 6.1.3. ACP domain membership check . . . . . . . . . . . . . 27
6.1.4. Trust Points and Trust Anchors . . . . . . . . . . . 28 6.1.4. Trust Points and Trust Anchors . . . . . . . . . . . 29
6.1.5. Certificate and Trust Point Maintenance . . . . . . . 29 6.1.5. Certificate and Trust Point Maintenance . . . . . . . 30
6.1.5.1. GRASP objective for EST server . . . . . . . . . 30 6.1.5.1. GRASP objective for EST server . . . . . . . . . 31
6.1.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 31 6.1.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 32
6.1.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 32 6.1.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 32
6.1.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 32 6.1.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 33
6.1.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 33 6.1.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 33
6.1.5.6. Failing Certificates . . . . . . . . . . . . . . 34 6.1.5.6. Failing Certificates . . . . . . . . . . . . . . 35
6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 35 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 35
6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 35 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 36
6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 39 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 39
6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 39 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 39
6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 42 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 43
6.7. Security Association (Secure Channel) protocols . . . . . 42 6.7. Security Association (Secure Channel) protocols . . . . . 43
6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 43 6.7.1. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 44
6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 43 6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 44
6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 44 6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 47
6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 45 6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 48
6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 45 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 48
6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 46 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 49
6.8.1. GRASP as a core service of the ACP . . . . . . . . . 46 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 49
6.8.2. ACP as the Security and Transport substrate for GRASP 46 6.8.2. ACP as the Security and Transport substrate for GRASP 50
6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 49 6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 52
6.9. Context Separation . . . . . . . . . . . . . . . . . . . 50 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 53
6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 51 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 54
6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 51 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 54
6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 53 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 56
6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 54 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 57
6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 56 6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 59
6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 57 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 60
6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 58 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 61
6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 59 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 62
6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 59 6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 62
6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 60 6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 63
6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 60 6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 63
6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 61 6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 64
6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 62 6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 65
6.10.7.5. Further Details . . . . . . . . . . . . . . . . 62 6.10.7.5. Further Details . . . . . . . . . . . . . . . . 65
6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 62 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 65
6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 63 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 66
6.11.1.1. Overview . . . . . . . . . . . . . . . . . . . . 63 6.11.1.1. Overview . . . . . . . . . . . . . . . . . . . . 66
6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 65 6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 68
6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 65 6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 68
6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 65 6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 68
6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 65 6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 68
6.11.1.6. Objective Function . . . . . . . . . . . . . . . 65 6.11.1.6. Objective Function . . . . . . . . . . . . . . . 68
6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 65 6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 68
6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 66 6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 69
6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 66 6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 69
6.11.1.10. P2P communications . . . . . . . . . . . . . . . 66 6.11.1.10. P2P communications . . . . . . . . . . . . . . . 69
6.11.1.11. IPv6 address configuration . . . . . . . . . . . 66 6.11.1.11. IPv6 address configuration . . . . . . . . . . . 69
6.11.1.12. Administrative parameters . . . . . . . . . . . 66 6.11.1.12. Administrative parameters . . . . . . . . . . . 69
6.11.1.13. RPL Data-Plane artifacts . . . . . . . . . . . . 67 6.11.1.13. RPL Data-Plane artifacts . . . . . . . . . . . . 70
6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 67 6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 70
6.12. General ACP Considerations . . . . . . . . . . . . . . . 67 6.12. General ACP Considerations . . . . . . . . . . . . . . . 70
6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 67 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 70
6.12.2. Addressing of Secure Channels . . . . . . . . . . . 68 6.12.2. Addressing of Secure Channels . . . . . . . . . . . 71
6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 68 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 71
6.12.4. Multiple links between nodes . . . . . . . . . . . . 69 6.12.4. Multiple links between nodes . . . . . . . . . . . . 72
6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 69 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 72
7. ACP support on L2 switches/ports (Normative) . . . . . . . . 72 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 75
7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 72 7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 75
7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 73 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 76
8. Support for Non-ACP Components (Normative) . . . . . . . . . 75 8. Support for Non-ACP Components (Normative) . . . . . . . . . 78
8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 75 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 78
8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 75 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 78
8.1.2. Software Components . . . . . . . . . . . . . . . . . 77 8.1.2. Software Components . . . . . . . . . . . . . . . . . 80
8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 78 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 81
8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 79 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 82
8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 80 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 83
8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 81 8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 84
8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 81 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 84
8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 83 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 86
8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 83 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 86
9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 83 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 86
9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 83 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 86
9.2. Self-Protection Properties . . . . . . . . . . . . . . . 85 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 88
9.2.1. From the outside . . . . . . . . . . . . . . . . . . 85 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 88
9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 86 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 89
9.3. The Administrator View . . . . . . . . . . . . . . . . . 86 9.3. The Administrator View . . . . . . . . . . . . . . . . . 89
10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 87 10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 90
10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 88 10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 91
10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 92 10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 95
10.2.1. Registrar interactions . . . . . . . . . . . . . . . 92 10.2.1. Registrar interactions . . . . . . . . . . . . . . . 95
10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 93 10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 96
10.2.3. Certificate renewal and limitations . . . . . . . . 94 10.2.3. Certificate renewal and limitations . . . . . . . . 97
10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 95 10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 98
10.2.5. Centralized Policy Control . . . . . . . . . . . . . 95 10.2.5. Centralized Policy Control . . . . . . . . . . . . . 98
10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 96 10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 99
10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 96 10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 99
10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 97 10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 100
10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 98 10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 101
10.3.2.2. Fast state propagation and Diagnostics . . . . . 98 10.3.2.2. Fast state propagation and Diagnostics . . . . . 101
10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 99 10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 102
10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 99 10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 102
10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 100 10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 103
10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 100 10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 103
10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 101 10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 104
10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 102 10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 105
10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 102 10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 105
10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 103 10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 106
10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 103 10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 106
10.4. Configuration and the ACP (summary) . . . . . . . . . . 104 10.4. Configuration and the ACP (summary) . . . . . . . . . . 107
11. Security Considerations . . . . . . . . . . . . . . . . . . . 105 11. Security Considerations . . . . . . . . . . . . . . . . . . . 108
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 108 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 108 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 111
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 109 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 112
14.1. Initial version . . . . . . . . . . . . . . . . . . . . 109 14.1. Summary of changes since entering IESG review . . . . . 112
14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 109 14.1.1. Reviews (while in IESG review status) / status . . . 112
14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 109 14.1.2. BRSKI / ACP registrar related enhancements . . . . . 113
14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 109 14.1.3. Normative enhancements since start of IESG review . 113
14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 110 14.1.4. Explanatory enhancements since start of IESG review 114
14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 110 14.2. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 115
14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 110 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 117
14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 111 15.1. Normative References . . . . . . . . . . . . . . . . . . 117
14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 111 15.2. Informative References . . . . . . . . . . . . . . . . . 120
14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 112 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 127
14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 112 Appendix A. Background and Futures (Informative) . . . . . . . . 127
14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 112 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 127
14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 113 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 128
14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 114 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 129
14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 116 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 129
14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 118 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 129
14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 120 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 130
14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 120 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 130
14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 122 A.5. ACP Information Distribution and multicast . . . . . . . 131
14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 124 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 132
14.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 128 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 134
14.22. draft-ietf-anima-autonomic-control-plane-16 . . . . . . 128 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 135
14.23. draft-ietf-anima-autonomic-control-plane-17 . . . . . . 129 A.9. Adopting ACP concepts for other environments . . . . . . 136
14.24. draft-ietf-anima-autonomic-control-plane-18 . . . . . . 131 A.10. Further (future) options . . . . . . . . . . . . . . . . 138
14.25. draft-ietf-anima-autonomic-control-plane-19 . . . . . . 131 A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 138
14.26. Open Issues in -19 . . . . . . . . . . . . . . . . . . . 133 A.10.2. More options for avoiding IPv6 Data-Plane dependency 138
14.27. draft-ietf-anima-autonomic-control-plane-20 . . . . . . 133 A.10.3. ACP APIs and operational models (YANG) . . . . . . . 139
14.28. draft-ietf-anima-autonomic-control-plane-21 . . . . . . 137 A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 139
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 137 A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 140
15.1. Normative References . . . . . . . . . . . . . . . . . . 137 A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 141
15.2. Informative References . . . . . . . . . . . . . . . . . 140 A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 141
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 147 A.10.8. Avoiding and dealing with compromised ACP nodes . . 142
Appendix A. Background and Futures (Informative) . . . . . . . . 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 143
A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 147
A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 148
A.3. ACP Neighbor discovery protocol selection . . . . . . . . 149
A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 149
A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 150
A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 150
A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 150
A.5. ACP Information Distribution and multicast . . . . . . . 152
A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 153
A.7. CAs, domains and routing subdomains . . . . . . . . . . . 155
A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 156
A.9. Adopting ACP concepts for other environments . . . . . . 157
A.10. Further (future) options . . . . . . . . . . . . . . . . 159
A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 159
A.10.2. More options for avoiding IPv6 Data-Plane dependency 159
A.10.3. ACP APIs and operational models (YANG) . . . . . . . 160
A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 160
A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 161
A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 161
A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 161
A.10.8. Avoiding and dealing with compromised ACP nodes . . 162
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 163
1. Introduction (Informative) 1. Introduction (Informative)
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 specified in the document Autonomic Networking in the IETF is specified in the document
[I-D.ietf-anima-reference-model]. [I-D.ietf-anima-reference-model].
skipping to change at page 16, line 7 skipping to change at page 15, line 26
addresses within the same /48-bit ULA prefix. addresses within the same /48-bit ULA prefix.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119],[RFC8174] when, and only when, they appear in all 14 [RFC2119],[RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Use Cases for an Autonomic Control Plane (Informative) 3. Use Cases for an Autonomic Control Plane (Informative)
This section summarizes the use cases that are intended to be
supported by an ACP. To understand how these are derived from and
relate to the larger set of use cases for autonomic networks, please
refer to [RFC8316].
3.1. An Infrastructure for Autonomic Functions 3.1. An Infrastructure for Autonomic Functions
Autonomic Functions need a stable infrastructure to run on, and all Autonomic Functions need a stable infrastructure to run on, and all
autonomic functions should use the same infrastructure to minimize autonomic functions should use the same infrastructure to minimize
the complexity of the network. In this way, there is only need for a the complexity of the network. In this way, there is only need for a
single discovery mechanism, a single security mechanism, and single single discovery mechanism, a single security mechanism, and single
instances of other processes that distributed functions require. instances of other processes that distributed functions require.
3.2. Secure Bootstrap over a not configured Network 3.2. Secure Bootstrap over a not configured Network
skipping to change at page 20, line 45 skipping to change at page 20, line 21
An ACP node can be a router, switch, controller, NMS host, or any An ACP node can be a router, switch, controller, NMS host, or any
other IP capable node. Initially, it must have its ACP domain other IP capable node. Initially, it must have its ACP domain
certificate, as well as an (empty) ACP Adjacency Table (described in certificate, as well as an (empty) ACP Adjacency Table (described in
Section 6.2). It then can start to discover ACP neighbors and build Section 6.2). It then can start to discover ACP neighbors and build
the ACP. This is described step by step in the following sections: the ACP. This is described step by step in the following sections:
6.1. ACP Domain, Certificate and Network 6.1. ACP Domain, Certificate and Network
The ACP relies on group security. An ACP domain is a group of nodes The ACP relies on group security. An ACP domain is a group of nodes
that trust each other to participate in ACP operations. To establish that trust each other to participate in ACP operations such as
creating ACP secure channels in an autonomous peer-to-peer fashion
between ACP domain members via protocols such as IPsec. To establish
trust, each ACP member requires keying material: An ACP node MUST trust, each ACP member requires keying material: An ACP node MUST
have a certificate (LDevID) and a Trust Anchor (TA) consisting of a have a certificate (LDevID) and a Trust Anchor (TA) consisting of a
certificate (chain) used to sign the LDevID of all ACP domain certificate (chain) used to sign the LDevID of all ACP domain
members. The LDevID is used to cryptographically authenticate the members. The LDevID is used to cryptographically authenticate the
membership of its owner node in the ACP domain to other ACP domain membership of its owner node in the ACP domain to other ACP domain
members. The TA is used to authenticate the ACP domain membership of members. The TA is used to authenticate the ACP domain membership of
other nodes (see Section 6.1.3). other nodes (see Section 6.1.3).
Manual keying via shared secrets is not usable for an ACP domain
because it would require a single shared secret across all current
and future ACP domain members to meet the expectation of autonomous,
peer-to-peer establishment of ACP secure channels between any ACP
domain members. Such a single shared secret would be an inacceptable
security weakness. Asymmetric keying material (public keys) without
certificates does not provide the mechanisms to authenticate ACP
domain membership in an autonomous, peer-to-peer fashion for current
and future ACP domain members.
The LDevID is called the ACP domain certificate, the TA is the The LDevID is called the ACP domain certificate, the TA is the
Certificate Authority (CA) of the ACP domain. Certificate Authority (CA) of the ACP domain.
The ACP does not mandate specific mechanisms by which this keying The ACP does not mandate specific mechanisms by which this keying
material is provisioned into the ACP node. It only requires the material is provisioned into the ACP node. It only requires the
certificate to comply with Section 6.1.1, specifically the Domain certificate to comply with Section 6.1.1, specifically the Domain
information field as specified in Section 6.1.2 in its domain information field as specified in Section 6.1.2 in its domain
certificate as well as those of candidate ACP peers. See certificate as well as those of candidate ACP peers. See
Appendix A.2 for more information about enrollment or provisioning Appendix A.2 for more information about enrollment or provisioning
options. options.
skipping to change at page 21, line 42 skipping to change at page 21, line 31
(fully) autonomic nodes. Finally, this document uses the term ACP (fully) autonomic nodes. Finally, this document uses the term ACP
network to refer to the network created by active ACP nodes in an ACP network to refer to the network created by active ACP nodes in an ACP
domain. The ACP network itself can extend beyond ACP nodes through domain. The ACP network itself can extend beyond ACP nodes through
the mechanisms described in Section 8.1. the mechanisms described in Section 8.1.
6.1.1. ACP Certificates 6.1.1. ACP Certificates
ACP domain certificates MUST be [RFC5280] compliant X.509 ACP domain certificates MUST be [RFC5280] compliant X.509
certificates. certificates.
ACP nodes MUST support RSA and Elliptic Curve Diffie-Hellman (ECDH) ACP nodes MUST support RSA and Elliptic Curve (ECC) public keys in
public keys in ACP certificates. ACP nodes MUST support RSA and ACP certificates. ACP certificates wth ECC keys MUST indicate to be
Elliptic Curve Diffie-Hellman (ECDH) signatures for ACP certificates. Elliptic Curve Diffie-Hellman capable (ECDH) if X.509 v3 keyUsage and
extendedKeyUsage are included in the certificate.
ACP nodes MUST support Certificates RSA keys with no less than 2048
bit key length and ECC keys with NIST P-256, P-384 and P-521 key
length (and curve) or better. ACP nodes MUST support SHA-256, SHA-
384, SHA-512 or better signatures for ACP certificates with RSA key
and the same RSA signatures plus ECDSA signatures for ACP
certificates with ECC key.
The ACP certificate SHOULD use an RSA key and an RSA signature when The ACP certificate SHOULD use an RSA key and an RSA signature when
the ACP certificate is intended to be used not only for ACP the ACP certificate is intended to be used not only for ACP
authentication but also for other purposes. The ACP certificate MAY authentication but also for other purposes. The ACP certificate MAY
use an ECDH key and an ECDH signature if the ACP certificate is only use an ECC key and an ECDSA signature if the ACP certificate is only
used for ACP and ANI authentication and authorization. ACP nodes used for ACP and ANI authentication and authorization.
MUST support 2048-bit RSA using SHA-256, SHA-384 or SHA-512 or
Elliptic Curve using NIST P-256, P-384, or P-521 as key lengths in
ACP certificates/signatures.
Any secure channel protocols used for the ACP as specified in this Any secure channel protocols used for the ACP as specified in this
document or extensions of this document MUST therefore support document or extensions of this document MUST therefore support
authentication (e.g.:signing) starting with these type of authentication (e.g.:signing) starting with these type of
certificates. See [RFC4492] for more information. certificates. See [RFC4492] for more information.
The reason for these choices are as follows: As of 2019, RSA is more The reason for these choices are as follows: As of 2020, RSA is still
widely used than ECDH, therefore the MUST for RSA. ECDH offers more widely used than ECC, therefore the MUST for RSA. ECC offers
equivalent security at shorter key lengths (see [RFC4492]). This can equivalent security at (logarithmically) shorter key lengths (see
be beneficial especially in the presence of constrained bandwidth or [RFC4492]). This can be beneficial especially in the presence of
constrained nodes in an ACP/ANI network. Some ACP functions such as constrained bandwidth or constrained nodes in an ACP/ANI network.
GRASP peer-2-peer across the ACP require end-to-end/any-to-any Some ACP functions such as GRASP peer-2-peer across the ACP require
authenticatio/authorization, therefore ECDH can only reliably be used end-to-end/any-to-any authentication/authorization, therefore ECC can
in the ACP when it MUST be supported on all ACP nodes. only reliably be used in the ACP when it MUST be supported on all ACP
nodes. RSA signatures are mandatory to be supported also for ECC
certificates because CAs themselves may not support ECC yet.
For further certificate details, ACP certificates may follow the For further certificate details, ACP certificates may follow the
recommendations from [CABFORUM]. recommendations from [CABFORUM].
The ACP domain certificate SHOULD be used for any authentication The ACP domain certificate SHOULD be used for any authentication
between nodes with ACP domain certificates (ACP nodes and NOC nodes) between nodes with ACP domain certificates (ACP nodes and NOC nodes)
where the required authorization condition is ACP domain membership, where the required authorization condition is ACP domain membership,
such as ACP node to NOC/OAM end-to-end security and ASA to ASA end- such as ACP node to NOC/OAM end-to-end security and ASA to ASA end-
to-end security. Section 6.1.3 defines this "ACP domain membership to-end security. Section 6.1.3 defines this "ACP domain membership
check". The uses of this check that are standardized in this check". The uses of this check that are standardized in this
skipping to change at page 23, line 23 skipping to change at page 23, line 19
Information about the domain MUST be encoded in the domain Information about the domain MUST be encoded in the domain
certificate in a subjectAltName / rfc822Name field according to the certificate in a subjectAltName / rfc822Name field according to the
following ABNF ([RFC5234]) definition: following ABNF ([RFC5234]) definition:
[RFC Editor: Please substitute SELF in all occurrences of rfcSELF in [RFC Editor: Please substitute SELF in all occurrences of rfcSELF in
this document with the RFC number assigned to this document and this document with the RFC number assigned to this document and
remove this comment line] remove this comment line]
domain-information = local-part "@" acp-domain-name domain-information = local-part "@" acp-domain-name
local-part = key [ "." local-info ] local-part = key [ "+" local-info ]
key = "rfcSELF" key = "rfcSELF"
local-info = [ acp-address ] [ "+" rsub extensions ] local-info = [ acp-address ] [ "+" rsub extensions ]
acp-address = 32HEXDIG | 0 ; HEXDIG as of RFC5234 section B.1 acp-address = 32HEXDIG | 0 ; HEXDIG as of RFC5234 section B.1
rsub = [ <subdomain> ] ; <subdomain> as of RFC1034, section 3.5 rsub = [ <subdomain> ] ; <subdomain> as of RFC1034, section 3.5
acp-domain-name = ; <domain> ; as of RFC 1034, section 3.5 acp-domain-name = ; <domain> ; as of RFC 1034, section 3.5
extensions = *( "+" extension ) extensions = *( "+" extension )
extension = ; future standard definition. extension = ; future standard definition.
; Must fit RFC5322 simple dot-atom format. ; Must fit RFC5322 simple dot-atom format.
routing-subdomain = [ rsub " ." ] acp-domain-name routing-subdomain = [ rsub " ." ] acp-domain-name
Example: Example:
given an ACP address of fd89:b714:f3db:0:200:0:6400:0000 given an ACP address of fd89:b714:f3db:0:200:0:6400:0000
and an ACP domain-name of acp.example.com and an ACP domain-name of acp.example.com
and an rsub extenstion of area51.research and an rsub extenstion of area51.research
then this results in: then this results in:
domain-information = rfcSELF+fd89b714f3db00000200000064000000 domain-information = rfcSELF+FD89B714F3DB00000200000064000000
+area51.research@acp.example.com +area51.research@acp.example.com
acp-domain-name = acp.example.com acp-domain-name = acp.example.com
routing-subdomain = area51.research.acp.example.com routing-subdomain = area51.research.acp.example.com
Figure 2: ACP Domain Information Field ABNF Figure 2: ACP Domain Information Field ABNF
domain-information is the encoded information that is put into the domain-information is the encoded information that is put into the
ACP domain certificates subjectAltName / rfc822Name field. routing- ACP domain certificates subjectAltName / rfc822Name field. routing-
subdomain is a string that can be constructed from the domain- subdomain is a string that can be constructed from the domain-
information, and it is used in the hash-creation of the ULA (see information, and it is used in the hash-creation of the ULA (see
below). The requirements and sementics of the parts of this below). The requirements and sementics of the parts of this
information are explained in the following paragraphs: information are explained in the following paragraphs:
Nodes complying with this specification MUST be able to receive their Nodes complying with this specification MUST be able to receive their
ACP address through the domain certificate, in which case their own ACP address through the domain certificate, in which case their own
ACP domain certificate MUST have the 32HEXDIG "acp-address" field. ACP domain certificate MUST have the 32HEXDIG "acp-address" field.
Nodes complying with this specification MUST also be able to Nodes complying with this specification MUST also be able to
authenticate nodes as ACP domain members / ACP secure channel peers authenticate nodes as ACP domain members or ACP secure channel peers
when they have an empty or 0-value acp-address field. See when they have a 0-value acp-address field and as ACP domain members
Section 6.1.3. (but not as ACP secure channel peers) when they have an empty acp-
address field. See Section 6.1.3.
"acp-domain-name" is used to indicate the ACP Domain across which all "acp-domain-name" is used to indicate the ACP Domain across which all
ACP nodes trust each other and are willing to build ACP channels to ACP nodes trust each other and are willing to build ACP channels to
each other. See Section 6.1.3. Acp-domain-name SHOULD be the FQDN each other. See Section 6.1.3. Acp-domain-name SHOULD be the FQDN
of a DNS domain owned by the operator assigning the certificate. of a DNS domain owned by the operator assigning the certificate.
This is a simple method to ensure that the domain is globally unique This is a simple method to ensure that the domain is globally unique
and collision of ACP addresses would therefore only happen due to ULA and collision of ACP addresses would therefore only happen due to ULA
hash collisions (see Section 6.10.2). If the operator does not own hash collisions (see Section 6.10.2). If the operator does not own
any FQDN, it should choose a string (in FQDN format) that it intends any FQDN, it should choose a string (in FQDN format) that it intends
to be equally unique. to be equally unique.
skipping to change at page 25, line 21 skipping to change at page 25, line 21
characters are necessary so the node can unambiguously parse that characters are necessary so the node can unambiguously parse that
both "acp-address" and "rsub" are empty. both "acp-address" and "rsub" are empty.
o The maximum size of "domain-information" is 254 characters and the o The maximum size of "domain-information" is 254 characters and the
maximum size of local-part is 64 characters according to [RFC5280] maximum size of local-part is 64 characters according to [RFC5280]
that is referring to [RFC2821] (superseded by [RFC5321]). that is referring to [RFC2821] (superseded by [RFC5321]).
The subjectAltName / rfc822Name encoding of the ACP domain name and The subjectAltName / rfc822Name encoding of the ACP domain name and
ACP address is used for the following reasons: ACP address is used for the following reasons:
o It should be possible to use the ACP domain certificate as an Rfc822name encoding for the ACP domain information was choosen for
LDevID on the system for other uses beside the ACP. Therefore, the following reasons.
the information element required for the ACP should be encoded so
that it minimizes the possibility of creating incompatibilities
with such other uses.
o The information for the ACP should not cause incompatibilities o The ACP domain information field is the identifier of a node's
with any pre-existing ASN.1 software. This eliminates the ACP. It includes the the necessary components to identify a nodes
introduction of a novel information element because that could ACP both from within the ACP as well as from the outside of the
require extensions to such pre-existing ASN.1 parsers. ACP.
o subjectAltName / rfc822Name is a pre-existing element that must be o For manual and/or automated diagnostics and backend management of
supported by all existing ASN.1 parsers for LDevID. devices and ACPs, it is necessary to have an easily human readible
and software parsed standard, single string representation of the
ACP domain information. For example, inventory or other backend
systems can always identify an entity by one unique string field
but not by a combination of multiple fields, which would be
necessary if there was no single string representation.
o The element required for the ACP should not be misinterpreted by o If the encoding of the ACP domain information into the ACP domains
any other uses of the LDevID. If the element used for the ACP is certificate was not that of such a string, it would be necessary
interpreted by other uses, the impact should be benign. to define a second standard encoding to provide this format
(standard string encoding).
o The element should not require additional ASN.1 en/decoding, o Rfc822 addresses have become standard identifiers of entities in
because it is unclear if all, especially embedded devices many systems, including the majority of user identification in web
certificate libraries would support extensible ASN.1 or mobile applications, where in many cases, e-mail is not even
functionality. part of the service for which an rfc822 address is used as an
entities identifier. In single-sign-on systems for example,
<local-part>@<domain> is instead used to indicate a <domain> with
which authentication and authorization of <local-part> is
performend without any other use of RFC822 than its address format
(e.g.: no rfc822 formatted message exchanges).
o Using an IP address format encoding could result in non-benign o Encoding the ACP nodes identity/name in the format of an
misinterpretation of the domain information field; other uses rfc822address is therefore following common practices for how
unaware of the ACP could try to do something with the ACP address rfc822 addresses are used in other contexts. It also very well
that would fail to work correctly. For example, the address could matches the format of rfc822 address structure <local-
be interpreted to be an address of the node which does not belong part>@<domain> because the ACP domain information does logically
to the ACP VRF. also consist of a <domain> identifying the ACP, and a <local-part>
identifying a nodes ACP.
o At minimum, both the AN domain name and the non-domain name o subjectAltName / rfc822Name is the standard, mandatory to
derived part of the ACP address need to be encoded in one or more implement certificate attribute to encode the certificate subjects
appropriate fields of the certificate, so there are not many rfc822 address and can be the only subjects name.
alternatives with pre-existing fields where the only possible
conflicts would likely be beneficial.
o rfc822Name encoding is very flexible. It allows to encode all the Compatibilities:
different fields of information required for the ACP.
o The format of the rfc822Name is chosen so that an operator can set o It should be possible to use the ACP domain certificate as an
up a mailbox called rfcSELF@<domain> that would receive emails LDevID on the system for other uses beside the ACP. Therefore,
sent towards the rfc822Name of any node inside a domain. This is the information element required for the ACP should be encoded so
possible because in many modern mail systems, components behind a that it minimizes the possibility of creating incompatibilities
"+" character are considered part of a single mailbox. In other with such other uses. The subjectName for example is for example
words, it is not necessary to set up a separate mailbox for every often used as an entity identifier in non-ACP uses.
ACP node, but only one for the whole domain.
o In result, if any unexpected use of the ACP addressing information o The element should not require additional ASN.1 en/decoding,
in a certificate happens, it is benign and detectable: it would be because libraries to access certificate information especially for
mail to that mailbox. embedded devices may not support extended ASN.1 decoding beyond
predefined, manadatory fields. subjectAltName / rfc822Name is such
a mandatory predefined field. subjectAlName / otherName for
example is not.
o Encoding of the ACP domain information as a human readable string
in a manadatory certificate field also has the benefit that it can
be diagnosed/decoded in any pre-existing certificate diagnostic
software.
o The element required for the ACP should not be misinterpreted by
any other uses of the LDevID. If the element used for the ACP is
interpreted by other components than the ACP, the impact should be
benign. By using fully rfc822address compliant encoding, the
benign side effect of non-ACP software using the ACP rfc822address
would be emails sent to the mailbox identified by the
rfc822address. If it is desired to receive such emails, suitable
email software may also support assigning all rfc822addresses for
an ACP domain to a single mailbox rfcSELF@<domain>. This is
possible when "+" (which follows rfcSELF) is supported by the Mail
User Agent as a separator between mail subscriber and sub-mailbox.
See section 4.2.1.6 of [RFC5280] for details on the subjectAltName See section 4.2.1.6 of [RFC5280] for details on the subjectAltName
field. field.
6.1.3. ACP domain membership check 6.1.3. ACP domain membership check
The following points constitute the ACP domain membership check of a The following points constitute the ACP domain membership check of a
candidate peer via its certificate: candidate peer via its certificate:
1: The peer certificate is valid (lifetime). 1: The peer certificate is valid (lifetime).
skipping to change at page 37, line 49 skipping to change at page 38, line 22
messages are dropped in transit. messages are dropped in transit.
The session-id is a random number used for loop prevention The session-id is a random number used for loop prevention
(distinguishing a message from a prior instance of the same message). (distinguishing a message from a prior instance of the same message).
In DULL this field is irrelevant but must still be set according to In DULL this field is irrelevant but must still be set according to
the GRASP specification. the GRASP specification.
The originator MUST be the IPv6 link local address of the originating The originator MUST be the IPv6 link local address of the originating
ACP node on the sending interface. ACP node on the sending interface.
The 'objective-value' parameter is a string indicating the secure The 'objective-value' parameter is a string indicating the protocol
channel protocol available at the specified or implied locator. available at the specified or implied locator. It must be a protocol
supported by the node to negotiate a secure channel. IKEv2 as shown
above is the protocol used to negotiate an IPsec secure channel.
The locator-option is optional and only required when the secure The locator-option is optional and only required when the secure
channel protocol is not offered at a well-defined port number, or if channel protocol is not offered at a well-defined port number, or if
there is no well-defined port number. there is no well-defined port number.
"IKEv2" is the abbreviation for "Internet Key Exchange protocol "IKEv2" is the abbreviation for "Internet Key Exchange protocol
version 2". It is the main protocol used by the Internet IP security version 2". It is the main protocol used by the Internet IP security
architecture (IPsec). We therefore use the term "IKEv2" and not architecture (IPsec). We therefore use the term "IKEv2" and not
"IPsec" in the GRASP definitions and example above. "IKEv2" has a "IPsec" in the GRASP definitions and example above. "IKEv2" has a
well-defined port number 500, but in the above example, the candidate well-defined port number 500, but in the above example, the candidate
skipping to change at page 42, line 44 skipping to change at page 43, line 44
The authentication of peers in any security association protocol MUST The authentication of peers in any security association protocol MUST
use the ACP domain certificate according to Section 6.1.3. Because use the ACP domain certificate according to Section 6.1.3. Because
auto-discovery of candidate ACP neighbors via GRASP (see Section 6.3) auto-discovery of candidate ACP neighbors via GRASP (see Section 6.3)
as specified in this document does not communicate the neighbors ACP as specified in this document does not communicate the neighbors ACP
domain certificate, and ACP nodes may not (yet) have any other domain certificate, and ACP nodes may not (yet) have any other
network connectivity to retrieve certificates, any security network connectivity to retrieve certificates, any security
association protocol MUST use a mechanism to communicate the association protocol MUST use a mechanism to communicate the
certificate directly instead of relying on a referential mechanism certificate directly instead of relying on a referential mechanism
such as communicating only a hash and/or URL for the certificate. such as communicating only a hash and/or URL for the certificate.
Any security association protocol MUST use PFS (such as profiles Any security association protocol MUST provide Forward Secrecy
providing PFS). (whether inherently or as part of a profile of the security
association protocol).
The degree of security required on every hop of an ACP network needs The degree of security required on every hop of an ACP network needs
to be consistent across the network so that there is no designated to be consistent across the network so that there is no designated
"weakest link" because it is that "weakest link" that would otherwise "weakest link" because it is that "weakest link" that would otherwise
become the designated point of attack. When the secure channel become the designated point of attack. When the secure channel
protection on one link is compromised, it can be used to send/receive protection on one link is compromised, it can be used to send/receive
packets across the whole ACP network. This principle does not imply packets across the whole ACP network. This principle does not imply
that the requirements against ACP security association protocols have that the requirements against ACP security association protocols have
to be the same across all subnets in an ACP network: to be the same across all subnets in an ACP network:
skipping to change at page 43, line 31 skipping to change at page 44, line 32
configuration and that configuration too could become an attack configuration and that configuration too could become an attack
vector. This document therefore only specifies with ACP connect vector. This document therefore only specifies with ACP connect
(Figure 15) one explicitly configured mechanism without any secure (Figure 15) one explicitly configured mechanism without any secure
channel association protocol - for the case where both the link channel association protocol - for the case where both the link
and the nodes attached to it have strong physical security. and the nodes attached to it have strong physical security.
The following sub-sections define the security association protocols The following sub-sections define the security association protocols
that are considered to be important and feasible to specify in this that are considered to be important and feasible to specify in this
document. document.
6.7.1. ACP via IKEv2 6.7.1. ACP via IPsec
An ACP node announces its ability to support IKEv2 as the ACP secure An ACP node announces its ability to support IPsec, negotiated via
channel protocol in GRASP as "IKEv2". IKEv2, as the ACP secure channel protocol using the "IKEv2"
objective-value in the "AN_ACP" GRASP objective.
The ACP usage of IPsec and IKEv2 mandates a narrow profile of the
current standards-track usage guidance for IPsec [RFC8221] and IKEv2
[RFC8247]. This profile provides for stringent security properties
and can exclude deprecated/legacy algorithms because there is no need
for interoperability with legacy equipment for ACP secure channels.
Any such backward compatibility would lead only to increased attack
surface and implementation complexity, for no benefit.
6.7.1.1. Native IPsec 6.7.1.1. Native IPsec
To run ACP via IPsec natively, no further IANA assignments/ To run ACP via IPsec natively, no further IANA assignments/
definitions are required. definitions are required.
An ACP node that is supporting native IPsec MUST use IPsec security An ACP node that is supporting native IPsec MUST use IPsec in tunnel
setup via IKEv2 for tunnel mode and IPsec/IKE signaling accordingly mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next
for IPv6 payload (e.g.: ESP next header of 41). It MUST use local Header of 41). It MUST use local and peer link-local IPv6 addresses
and peer link-local IPv6 addresses for encapsulation. for encapsulation. Manual keying MUST NOT be used, see Section 6.1.
Authentication MUST use the ACP domain certificates. Certificate
Encoding MUST support "PKCS #7 wrapped X.509 certificate" (0) (see
[IKEV2IANA] for this and other IANA IKEv2 parameter names used in
this text). If certificate chains are used, all intermediate
certificates up to, but not including the locally provisioned trust
anchor certificate must be signaled.
IPsec tunnel mode is required because the ACP will route/forward IPsec tunnel mode is required because the ACP will route/forward
packets received from any other ACP node across the ACP secure packets received from any other ACP node across the ACP secure
channels, and not only its own generated ACP packets. With IPsec channels, and not only its own generated ACP packets. With IPsec
transport mode, it would only be possible to send packets originated transport mode, it would only be possible to send packets originated
by the ACP node itself. by the ACP node itself.
IPsec MUST support ESP with ENCR_AES_GCM_16 ([RFC4106]) due to its 6.7.1.1.1. RFC8221 (IPsec/ESP)
higher performance over ENCR_AES_CBC. ACP MUST NOT use any NULL
encryption option due to the confidentiality of ACP payload that may
not be encrypted by itself (when carrying legacy management protocol
traffics as well as hop-by-hop GRASP).
These IPsec requirements are based on [RFC8221] but limited to the ACP IPsec implementations MUST comply with [RFC8221] (and its
minimum necessary options because ACP is not a general purpose use updates), with the following modifications to simplify hardware
case today with a wide range of interoperability requirements against accelerated ACP IPsec implementation requirements by eliminating
legacy devices originally developed against older profile requirements for legacy or cryptographically weak options.
recommendations. Once there are updates to [RFC8221], these should
accordingly be reflected in updates to these ACP requirements (for
example if ENCR_AES_GCM_16 was to be superceeded in the future).
Additional requirements from [RFC8221] MAY be used for ACP channels ACP MUST NOT use any NULL encryption option due to the
as long as they do not result in a reduction of security over the confidentiality of ACP payload that may not be encrypted by itself
above MTI requirements. For example, ESP compression MAY be used. when carrying legacy management protocol traffics as well as hop-by-
hop GRASP, which is designed to rely on the ACP for confidentiality
of hop-by-hop distributed information. Therefore, IPsec MUST support
ESP and MUST NOT use AH. For ESP, ENCR_NULL MUST NOT be used for ACP
secure channels.
IKEv2 MUST follow [RFC8247] as necessary to support the above listed Only ENCR_AES_GCM_16 is REQUIRED as an encryption algorithm for ACP
IPsec requirements. secure channels with ESP.
If an ACP node can perform ENCR_AES_CBC, ENCR_AES_CCM_8 at higher
performance than ENCR_AES_GCM_16 or ENCR_CHACHA20_POLY1305 at equal
or higher performance than ENCR_AES_GCM_16 then that ACP node SHOULD
support such an encryption algorithm and prefer it in the IKEv2
negotiation if its performance is higher than that of
ENCR_AES_GCM_16. Otherwise there are no normative requirements
against either of these options. These requirements are overriding
the MUST/SHOULD/SHOULD requirements of [RFC8221] for these three
algorithms for the following reasons:
o There is no unconditional requirement against ENCR_AES_CBC because
* ENCR_AES_GCM_16 is assumed to be feasible with less cost/higher
higher performance in modern devices hardware accelerated
implementations compared to ENCR-AES_CBC.
* AES-GCM is an authenticated encryption with associated data
(AEAD) cipher mode, so no ESP authentication algorithm
requirement is needed (unless further encryption algorithms are
supported), further simplifying ACP IPsec implementations.
* there is no requirement to interoperate with legacy equipment
in ACP secure channels, so a single MTI encryption algorithm
for IPsec in ACP secure channels is sufficient for
interoperability.
o There is no unconditional requirement against ENCR_AES_CCM_8
because it is currently not likely that it would be preferrable in
ACP secure channels for more constrained IoT devices over options
such as DTLS. In [RFC8221] this algorithm is more desirable,
because of solutions relying only on IPsec without such non-IPsec
alternatives.
o There is no unconditional requirement against
ENCR_CHACHA20_POLY1305 because there is currently no mechanism in
the ACP to migrate all secure channels in an ACP domain to a
different preferred encryption algorithm in the case of future
discovered crypto weaknesses of AES. Once such mechanisms are
defined, ENCR_CHACHA20_POLY1305 would be a good encryption
algorithm, but due to the transitive traffic through ACP secure
channels only when this does not result in an unexpected drop in
performance.
When using AES for encryption, keys less than 256 bits MUST NOT be
used, and 256-bit keys MUST be supported.
Once there are updates to [RFC8221], these should accordingly be
reflected in updates to these ACP requirements, for example if
ENCR_AES_GCM_16 was to be superceeded in the future.
6.7.1.1.2. RFC847 (IKEv2)
IKEv2 for ACP secure channels MUST support the requirements of
[RFC8247] (as necessary to support the above described modified
[RFC8221] requirements for IPsec via ESP). Because IKEv2 for ACP
secure channels is sufficient to be implemented in control plane
software as opposed to ESP (which may need to be implemented in
accelerated forwarding plane for sufficient performance), there are
no restrictions on the requirements of [RFC8247] for ACP secure
channels. Instead, the following paragraphs describe additional or
stricter requirements necessary for the authentication of ACP secure
channels in IKEv2 via ACP domain certificates.
IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP) MUST
be supported (in addition to 2048-bit MODP). ECC provides a similar
security level to finite-field (MODP) key exchange with a shorter key
length, so is generally preferred absent other considerations.
IKEv2 authentication MUST use the ACP domain certificates. The
Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be
supported (see [IKEV2IANA] for this and other IANA IKEv2 parameter
names used in this text). If certificate chains are used, all
intermediate certificates up to, but not including the locally
provisioned trust anchor certificate must be signaled.
A certificate payload with the ACP certificate MUST be included
during IKEv2 authentication to support the ACP domain membership
check as described in Section 6.1.3, because it is using additional
elements of the ACP certificates. ACP peers are expected to have the
same set of Trust Anchors (TA), so a certificate path MUST only be
included in the signaled payload when the path contains intermediate
certificates not in the TA set, such as sub-CAs (see Section 6.10.7).
In IKEv2, ACP nodes are identified by their ACP address. The
ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST
convey the ACP address. If the peer's ACP domain certificate
includes an ACP address in the ACP domain information field (not "0"
or empty), the address in the IKEv2 identification payload must match
it. See Section 6.1.3 for more information about "0" or empty ACP
address fields in the ACP domain information field.
IKEv2 authentication MUST use authentication method 14 ("Digital
Signature") for ACP certificates; this authentication method can be
used with both RSA and ECDSA certificates, as indicated by a PKIX-
style OID.
The Digital Signature hash SHA2-512 MUST be supported (in addition to
SHA2-256).
6.7.1.2. IPsec with GRE encapsulation 6.7.1.2. IPsec with GRE encapsulation
In network devices it is often more common to implement high In network devices it is often more common to implement high
performance virtual interfaces on top of GRE encapsulation than on performance virtual interfaces on top of GRE encapsulation than on
top of a "native" IPsec association (without any other encapsulation top of a "native" IPsec association (without any other encapsulation
than those defined by IPsec). On those devices it may be beneficial than those defined by IPsec). On those devices it may be beneficial
to run the ACP secure channel on top of GRE protected by the IPsec to run the ACP secure channel on top of GRE protected by the IPsec
association. association.
skipping to change at page 45, line 11 skipping to change at page 48, line 17
If IKEv2 initiator and responder support IPsec over GRE, it has to be If IKEv2 initiator and responder support IPsec over GRE, it has to be
preferred over native IPsec. The ACP IPv6 traffic has to be carried preferred over native IPsec. The ACP IPv6 traffic has to be carried
across GRE according to [RFC7676]. across GRE according to [RFC7676].
6.7.2. ACP via DTLS 6.7.2. ACP via DTLS
We define the use of ACP via DTLS in the assumption that it is likely We define the use of ACP via DTLS in the assumption that it is likely
the first transport encryption supported in some classes of the first transport encryption supported in some classes of
constrained devices. constrained devices.
An ACP node announces its ability to support DTLS (as described here)
as an ACP secure channel protocol in GRASP through the "DTLS"
objective-value in the "AN_ACP" objective.
To run ACP via UDP and DTLS v1.2 [RFC6347] a locally assigned UDP To run ACP via UDP and DTLS v1.2 [RFC6347] a locally assigned UDP
port is used that is announced as a parameter in the GRASP AN_ACP port is used that is announced as a parameter in the GRASP AN_ACP
objective to candidate neighbors. objective to candidate neighbors.
All ACP nodes supporting DTLS as a secure channel protocol MUST All ACP nodes supporting DTLS as a secure channel protocol MUST
adhere to the DTLS implementation recommendations and security adhere to the DTLS implementation recommendations and security
considerations of BCP 195 [RFC7525] except with respect to the DTLS considerations of BCP 195 [RFC7525] except with respect to the DTLS
version. ACP nodes supporting DTLS MUST implement only DTLS 1.2 or version. ACP nodes supporting DTLS MUST implement only DTLS 1.2 or
later. For example, implementing DTLS-1.3 ([I-D.ietf-tls-dtls13]) is later. For example, implementing DTLS-1.3 ([I-D.ietf-tls-dtls13]) is
also an option. also an option.
skipping to change at page 109, line 13 skipping to change at page 112, line 13
this project and the idea of the Autonomic Control Plane, amongst this project and the idea of the Autonomic Control Plane, amongst
which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji
BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael
Richardson, Ravi Kumar Vadapalli. Richardson, Ravi Kumar Vadapalli.
Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and
Sheng Jiang for their thorough reviews and to Pascal Thubert and Sheng Jiang for their thorough reviews and to Pascal Thubert and
Michael Richardson to provide the details for the recommendations of Michael Richardson to provide the details for the recommendations of
the use of RPL in the ACP. the use of RPL in the ACP.
Thanks to Valery Smyslov for review of the IPsec and IKEv2
configuration parameters.
Further input, review or suggestions were received from: Rene Struik, Further input, review or suggestions were received from: Rene Struik,
Brian Carpenter, Benoit Claise, William Atwood and Yongkang Zhang. Brian Carpenter, Benoit Claise, William Atwood and Yongkang Zhang.
14. Change log [RFC Editor: Please remove] 14. Change log [RFC Editor: Please remove]
14.1. Initial version 14.1. Summary of changes since entering IESG review
First version of this document: draft-behringer-autonomic-control-
plane
14.2. draft-behringer-anima-autonomic-control-plane-00
Initial version of the anima document; only minor edits.
14.3. draft-behringer-anima-autonomic-control-plane-01
o Clarified that the ACP should be based on, and support only IPv6.
o Clarified in intro that ACP is for both, between devices, as well
as for access from a central entity, such as an NMS.
o Added a section on how to connect an NMS system.
o Clarified the hop-by-hop crypto nature of the ACP.
o Added several references to GDNP as a candidate protocol.
o Added a discussion on network split and merge. Although, this
should probably go into the certificate management story longer
term.
14.4. draft-behringer-anima-autonomic-control-plane-02
Addresses (numerous) comments from Brian Carpenter. See mailing list
for details. The most important changes are:
o Introduced a new section "overview", to ease the understanding of
the approach.
o Merged the previous "problem statement" and "use case" sections
into a mostly re-written "use cases" section, since they were
overlapping.
o Clarified the relationship with draft-ietf-anima-stable-
connectivity
14.5. draft-behringer-anima-autonomic-control-plane-03
o Took out requirement for IPv6 --> that's in the reference doc.
o Added requirement section.
o Changed focus: more focus on autonomic functions, not only virtual
out-of-band. This goes a bit throughout the document, starting
with a changed abstract and intro.
14.6. draft-ietf-anima-autonomic-control-plane-00
No changes; re-submitted as WG document.
14.7. draft-ietf-anima-autonomic-control-plane-01
o Added some paragraphs in addressing section on "why IPv6 only", to
reflect the discussion on the list.
o Moved the Data-Plane ACP out of the main document, into an
appendix. The focus is now the virtually separated ACP, since it
has significant advantages, and isn't much harder to do.
o Changed the self-creation algorithm: Part of the initial steps go
into the reference document. This document now assumes an
adjacency table, and domain certificate. How those get onto the
device is outside scope for this document.
o Created a new section 6 "workarounds for non-autonomic nodes", and
put the previous controller section (5.9) into this new section.
Now, section 5 is "autonomic only", and section 6 explains what to
do with non-autonomic stuff. Much cleaner now.
o Added an appendix explaining the choice of RPL as a routing
protocol.
o Formalized the creation process a bit more. Now, we create a
"candidate peer list" from the adjacency table, and form the ACP
with those candidates. Also it explains now better that policy
(Intent) can influence the peer selection. (section 4 and 5)
o Introduce a section for the capability negotiation protocol
(section 7). This needs to be worked out in more detail. This
will likely be based on GRASP.
o Introduce a new parameter: ACP tunnel type. And defines it in the
IANA considerations section. Suggest GRE protected with IPSec
transport mode as the default tunnel type.
o Updated links, lots of small edits.
14.8. draft-ietf-anima-autonomic-control-plane-02
o Added explicitly text for the ACP channel negotiation.
o Merged draft-behringer-anima-autonomic-addressing-02 into this
document, as suggested by WG chairs.
14.9. draft-ietf-anima-autonomic-control-plane-03
o Changed Neighbor discovery protocol from GRASP to mDNS. Bootstrap
protocol team decided to go with mDNS to discover bootstrap proxy,
and ACP should be consistent with this. Reasons to go with mDNS
in bootstrap were a) Bootstrap should be reuseable also outside of
full anima solutions and introduce as few as possible new
elements. mDNS was considered well-known and very-likely even pre-
existing in low-end devices (IoT). b) Using GRASP both for the
insecure neighbor discovery and secure ACP operatations raises the
risk of introducing security issues through implementation issues/
non-isolation between those two instances of GRASP.
o Shortened the section on GRASP instances, because with mDNS being
used for discovery, there is no insecure GRASP session any longer,
simplifying the GRASP considerations.
o Added certificate requirements for ANIMA in section 5.1.1,
specifically how the ANIMA information is encoded in
subjectAltName.
o Deleted the appendix on "ACP without separation", as originally
planned, and the paragraph in the main text referring to it.
o Deleted one sub-addressing scheme, focusing on a single scheme
now.
o Included information on how ANIMA information must be encoded in
the domain certificate in section "preconditions".
o Editorial changes, updated draft references, etc.
14.10. draft-ietf-anima-autonomic-control-plane-04
Changed discovery of ACP neighbor back from mDNS to GRASP after
revisiting the L2 problem. Described problem in discovery section
itself to justify. Added text to explain how ACP discovery relates
to BRSKY (bootstrap) discovery and pointed to Michael Richardsons
draft detailing it. Removed appendix section that contained the
original explanations why GRASP would be useful (current text is
meant to be better).
14.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 6.10.1 (addressing): State that addresses in the ACP are
permanent, and do not support temporary addresses as defined in
RFC4941.
o Modified Section 6.3 to point to the GRASP objective defined in
draft-carpenter-anima-ani-objectives. (and added that reference)
o Section 6.10.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 8.1.1 the ACP Connect port, and defined that
term "ACP Connect".
o Section 8.2: Added some thoughts (from mcr) on how traversing a L3
cloud could be automated.
o Added a CRL check in Section 6.7.
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.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 detailed it.
o Added text to suggest admin down interfaces should still run ACP.
14.13. draft-ietf-anima-autonomic-control-plane-07
o Changed author association.
o Improved ACP connect setion (after confusion about term came up in
the stable connectivity draft review). Added picture, defined
complete terminology.
o Moved ACP channel negotiation from normative section to appendix
because it can in the timeline of this document not be fully
specified to be implementable. Aka: work for future document.
That work would also need to include analysing IKEv2 and describin
the difference of a proposed GRASP/TLS solution to it.
o Removed IANA request to allocate registry for GRASP/TLS. This
would come with future draft (see above).
o Gave the name "ACP domain information field" to the field in the
certificate carrying the ACP address and domain name.
o Changed the rules for mutual authentication of certificates to
rely on the domain in the ACP information field of the certificate
instead of the OU in the certificate. Also renewed the text
pointing out that the ACP information field in the certificate is
meant to be in a form that it does not disturb other uses of the
certificate. As long as the ACP expected to rely on a common OU
across all certificates in a domain, this was not really true:
Other uses of the certificates might require different OUs for
different areas/type of devices. With the rules in this draft
version, the ACP authentication does not rely on any other fields
in the certificate.
o Added an extension field to the ACP information field so that in
the future additional fields like a subdomain could be inserted.
An example using such a subdomain field was added to the pre-
existing text suggesting sub-domains. This approach is necessary
so that there can be a single (main) domain in the ACP information
field, because that is used for mutual authentication of the
certificate. Also clarified that only the register(s) SHOULD/MUST
use that the ACP address was generated from the domain name - so
that we can easier extend change this in extensions.
o Took the text for the GRASP discovery of ACP neighbors from Brians
grasp-ani-objectives draft. Alas, that draft was behind the
latest GRASP draft, so i had to overhaul. The mayor change is to
describe in the ACP draft the whole format of the M_FLOOD message
(and not only the actual objective). This should make it a lot
easier to read (without having to go back and forth to the GRASP
RFC/draft). It was also necessary because the locator in the
M_FLOOD messages has an important role and its not coded inside
the objective. The specification of how to format the M_FLOOD
message shuold now be complete, the text may be some duplicate
with the DULL specificateion in GRASP, but no contradiction.
o One of the main outcomes of reworking the GRASP section was the
notion that GRASP announces both the candidate peer's IPv6 link
local address but also the support ACP security protocol including
the port it is running on. In the past we shied away from using
this information because it is not secured, but i think the
additional attack vectors possible by using this information are
negligible: If an attacker on an L2 subnet can fake another
devices GRASP message then it can already provide a similar amount
of attack by purely faking the link-local address.
o Removed the section on discovery and BRSKI. This can be revived
in the BRSKI document, but it seems mood given how we did remove
mDNS from the latest BRSKI document (aka: this section discussed
discrepancies between GRASP and mDNS discovery which should not
exist anymore with latest BRSKI.
o Tried to resolve the EDNOTE about CRL vs. OCSP by pointing out we
do not specify which one is to be used but that the ACP should be
used to reach the URL included in the certificate to get to the
CRL storage or OCSP server.
o Changed ACP via IPsec to ACP via IKEv2 and restructured the
sections to make IPsec native and IPsec via GRE subsections.
o No need for any assigned DTLS port if ACP is run across DTLS
because it is signaled via GRASP.
14.14. draft-ietf-anima-autonomic-control-plane-08
Modified mentioning of BRSKI to make it consistent with current
(07/2017) target for BRSKI: MASA and IDevID are mandatory. Devices
with only insecure UDI would need a security reduced variant of
BRSKI. Also added mentioning of Netconf Zero-Touch. Made BRSKI non-
normative for ACP because wrt. ACP it is just one option how the
domain certificate can be provisioned. Instead, BRSKI is mandatory
when a device implements ANI which is ACP+BRSKI.
Enhanced text for ACP across tunnels to describe two options: one
across configured tunnels (GRE, IPinIP etc) a more efficient one via
directed DULL.
Moved decription of BRSKI to appendix to emphasize that BRSKI is not
a (normative) dependency of GRASP, enhanced text to indicate other
options how Domain Certificates can be provisioned.
Added terminology section.
Separated references into normative and non-normative.
Enhanced section about ACP via "tunnels". Defined an option to run
ACP secure channel without an outer tunnel, discussed PMTU, benefits
of tunneling, potential of using this with BRSKI, made ACP via GREP a
SHOULD requirement.
Moved appendix sections up before IANA section because there where
concerns about appendices to be too far on the bottom to be read.
Added (Informative) / (Normative) to section titles to clarify which
sections are informative and which are normative
Moved explanation of ACP with L2 from precondition to separate
section before workarounds, made it instructive enough to explain how
to implement ACP on L2 ports for L3/L2 switches and made this part of
normative requirement (L2/L3 switches SHOULD support this).
Rewrote section "GRASP in the ACP" to define GRASP in ACP as
mandatory (and why), and define the ACP as security and transport
substrate to GRASP in ACP. And how it works.
Enhanced "self-protection" properties section: protect legacy
management protocols. Security in ACP is for protection from outside
and those legacy protocols. Otherwise need end-to-end encryption
also inside ACP, e.g., with domain certificate.
Enhanced initial domain certificate section to include requirements
for maintenance (renewal/revocation) of certificates. Added
explanation to BRSKI informative section how to handle very short
lived certificates (renewal via BRSKI with expired cert).
Modified the encoding of the ACP address to better fit RFC822 simple
local-parts (":" as required by RFC5952 are not permitted in simple
dot-atoms according to RFC5322. Removed reference to RFC5952 as its
now not needed anymore.
Introduced a sub-domain field in the ACP information in the
certificate to allow defining such subdomains with depending on
future Intent definitions. It also makes it clear what the "main
domain" is. Scheme is called "routing subdomain" to have a unique
name.
Added V8 (now called Vlong) addressing sub-scheme according to
suggestion from mcr in his mail from 30 Nov 2016
(https://mailarchive.ietf.org/arch/msg/anima/
nZpEphrTqDCBdzsKMpaIn2gsIzI). Also modified the explanation of the
single V bit in the first sub-scheme now renamed to Zone sub-scheme
to distinguish it.
14.15. draft-ietf-anima-autonomic-control-plane-09
Added reference to RFC4191 and explained how it should be used on ACP
edge routers to allow auto configuration of routing by NMS hosts.
This came after review of stable connectivity draft where ACP connect
is being referred to.
V8 addressing Sub-Scheme was modified to allow not only /8 device-
local address space but also /16. This was in response to the
possible need to have maybe as much as 2^12 local addresses for
future encaps in BRSKI like IPinIP. It also would allow fully
autonomic address assignment for ACP connect interfaces from this
local address space (on an ACP edge device), subject to approval of
the implied update to rfc4291/rfc4193 (IID length). Changed name to
Vlong addressing sub-scheme.
Added text in response to Brian Carpenters review of draft-ietf-
anima-stable-connectivity-04.
o The stable connectivity draft was vaguely describing ACP connect
behavior that is better standardized in this ACP draft.
o Added new ACP "Manual" addressing sub-scheme with /64 subnets for
use with ACP connect interfaces. Being covered by the ACP ULA
prefix, these subnets do not require additional routing entries
for NMS hosts. They also are fully 64-bit IID length compliant
and therefore not subject to 4191bis considerations. And they
avoid that operators manually assign prefixes from the ACP ULA
prefixes that might later be assigned autonomically.
o ACP connect auto-configuration: Defined that ACP edge devices, NMS
hosts should use RFC4191 to automatically learn ACP prefixes.
This is especially necessary when the ACP uses multiple ULA
prefixes (via e.g., the rsub domain certificate option), or if ACP
connect sub-interfaces use manually configured prefixes NOT
covered by the ACP ULA prefixes.
o Explained how rfc6724 is (only) sufficient when the NMS host has a
separate ACP connect and Data-Plane interface. But not when there
is a single interface.
o Added a separate subsection to talk about "software" instead of
"NMS hosts" connecting to the ACP via the "ACP connect" method.
The reason is to point out that the "ACP connect" method is not
only a workaround (for NMS hosts), but an actual desirable long
term architectural component to modularly build software (e.g.,
ASA or OAM for VNF) into ACP devices.
o Added a section to define how to run ACP connect across the same
interface as the Data-Plane. This turns out to be quite
challenging because we only want to rely on existing standards for
the network stack in the NMS host/software and only define what
features the ACP edge device needs.
o Added section about use of GRASP over ACP connect.
o Added text to indicate packet processing/filtering for security:
filter incorrect packets arriving on ACP connect interfaces,
diagnose on RPL root packets to incorrect destination address (not
in ACP connect section, but because of it).
o Reaffirm security goal of ACP: Do not permit non-ACP routers into
ACP routing domain.
Made this ACP document be an update to RFC4291 and RFC4193. At the
core, some of the ACP addressing sub-schemes do effectively not use
64-bit IIDs as required by RFC4191 and debated in rfc4191bis. During
6man in Prague, it was suggested that all documents that do not do
this should be classified as such updates. Add a rather long section
that summarizes the relevant parts of ACP addressing and usage and.
Aka: This section is meant to be the primary review section for
readers interested in these changes (e.g., 6man WG.).
Added changes from Michael Richardsons review https://github.com/
anima-wg/autonomic-control-plane/pull/3/commits, textual and:
o ACP discovery inside ACP is bad *doh*!.
o Better CA trust and revocation sentences.
o More details about RPL behavior in ACP.
o black hole route to avoid loops in RPL.
Added requirement to terminate ACP channels upon cert expiry/
revocation.
Added fixes from 08-mcr-review-reply.txt (on github):
o AN Domain Names are FQDNs.
o Fixed bit length of schemes, numerical writing of bits (00b/01b).
o Lets use US american english.
14.16. draft-ietf-anima-autonomic-control-plane-10
Used the term routing subdomain more consistently where previously
only subdomain was used. Clarified use of routing subdomain in
creation of ULA "global ID" addressing prefix.
6.7.1.* Changed native IPsec encapsulation to tunnel mode
(necessary), explained why. Added notion that ESP is used, added
explanations why tunnel/transport mode in native vs. GRE cases.
6.10.3/6.10.5 Added term "ACP address range/set" to be able to better
explain how the address in the ACP certificate is actually the base
address (lowest address) of a range/set that is available to the
device.
6.10.4 Added note that manual address sub-scheme addresses must not
be used within domain certificates (only for explicit configuration).
6.12.5 Refined explanation of how ACP virtual interfaces work (p2p
and multipoint). Did seek for pre-existing RFCs that explain how to
build a multi-access interface on top of a full mesh of p2p
connections (6man WG, anima WG mailing lists), but could not find any
prior work that had a succinct explanation. So wrote up an
explanation here. Added hopefully all necessary and sufficient
details how to map ACP unicast packets to ACP secure channel, how to
deal with ND packet details. Added verbiage for ACP not to assign
the virtual interface link-local address from the underlying
interface. Added note that GRAP link-local messages are treated
specially but logically the same. Added paragraph about NBMA
interfaces.
remaining changes from Brian Carpenters review. See Github file
draft-ietf-anima-autonomic-control-plane/08-carpenter-review-reply.tx
for more details:
Added multiple new RFC references for terms/technologies used.
Fixed verbage in several places.
2. (terminology) Added 802.1AR as reference.
2. Fixed up definition of ULA.
6.1.1 Changed definition of ACP information in cert into ABNF format.
Added warning about maximum size of ACP address field due to domain-
name limitations.
6.2 Mentioned API requirement between ACP and clients leveraging
adjacency table.
6.3 Fixed TTL in GRASP example: msec, not hop-count!.
6.8.2 MAYOR: expanded security/transport substrate text:
Introduced term ACP GRASP virtual interface to explain how GRASP
link-local multicast messages are encapsulated and replicated to
neighbors. Explain how ACP knows when to use TLS vs. TCP (TCP only
for link-local address (sockets). Introduced "ladder" picture to
visualize stack.
6.8.2.1 Expanded discussion/explanation of security model. TLS for
GRASP unicast connections across ACP is double encryption (plus
underlying ACP secure channel), but highly necessary to avoid very
simple man-in-the-middle attacks by compromised ACP members on-path.
Ultimately, this is done to ensure that any apps using GRASP can get
full end-to-end secrecy for information sent across GRASP. But for
publically known ASA services, even this will not provide 100%
security (this is discussed). Also why double encryption is the
better/easier solution than trying to optimize this.
6.10.1 Added discussion about pseudo-random addressing, scanning-
attacks (not an issue for ACP).
6.12.2 New performance requirements section added.
6.10.1 Added notion to first experiment with existing addressing
schemes before defining new ones - we should be flexible enough.
6.3/7.2 clarified the interactions between MLD and DULL GRASP and
specified what needs to be done (e.g., in 2 switches doing ACP per L2
port).
12. Added explanations and cross-references to various security
aspects of ACP discussed elsewhere in the document.
13. Added IANA requirements.
Added RFC2119 boilerplate.
14.17. draft-ietf-anima-autonomic-control-plane-11
Same text as -10 Unfortunately when uploading -10 .xml/.txt to
datatracker, a wrong version of .txt got uploaded, only the .xml was
correct. This impacts the -10 html version on datatracker and the
PDF versions as well. Because rfcdiff also compares the .txt
version, this -11 version was created so that one can compare changes
from -09 and changes to the next version (-12).
14.18. draft-ietf-anima-autonomic-control-plane-12
Sheng Jiangs extensive review. Thanks! See Github file draft-ietf-
anima-autonomic-control-plane/09-sheng-review-reply.txt for more
details. Many of the larger changes listed below where inspired by
the review.
Removed the claim that the document is updating RFC4291,RFC4193 and
the section detailing it. Done on suggestion of Michael Richardson -
just try to describe use of addressing in a way that would not
suggest a need claim update to architecture.
Terminology cleanup:
o Replaced "device" with "node" in text. Kept "device" only when
referring to "physical node". Added definitions for those words.
Includes changes of derived terms, especially in addressing:
"Node-ID" and "Node-Number" in the addressing details.
o Replaced term "autonomic FOOBAR" with "acp FOOBAR" as wherever
appropriate: "autonomic" would imply that the node would need to
support more than the ACP, but that is not correct in most of the
cases. Wanted to make sure that implementers know they only need
to support/implement ACP - unless stated otherwise. Includes
"AN->ACP node", "AN->ACP adjacency table" and so on.
1 Added explanation in the introduction about relationship between
ACP, BRSKI, ANI and Autonomic Networks.
6.1.1 Improved terminology and features of the certificate
information field. Now called domain information field instead of
ACP information field. The acp-address field in the domain
information field is now optional, enabling easier introduction of
various future options.
6.1.2 Moved ACP domain membership check from section 6.6 to (ACP
secure channels setup) here because it is not only used for ACP
secure channel setup.
6.1.3 Fix text about certificate renewal after discussion with Max
Pritikin/Michael Richardson/Brian Carpenter:
o Version 10 erroneously assumed that the certificate itself could
store a URL for renewal, but that is only possible for CRL URLs.
Text now only refers to "remembered EST server" without implying
that this is stored in the certificate.
o Objective for RFC7030/EST domain certificate renewal was changed
to "SRV.est" See also IANA section for explanation.
o Removed detail of distance based service selection. This can be
better done in future work because it would require a lot more
detail for a good DNS-SD compatible approach.
o Removed detail about trying to create more security by using ACP
address from certificate of peer. After rethinking, this does not
seem to buy additional security.
6.10 Added reference to 6.12.5 in initial use of "loopback interface"
in section 6.10 in result of email discussion michaelR/michaelB.
10.2 Introduced informational section (diagnostics) because of
operational experience - ACP/ANI undeployable without at least
diagnostics like this.
10.3 Introduced informational section (enabling/disabling) ACP.
Important to discuss this for security reasons (e.g., why to never
auto-enable ANI on brownfield devices), for implementers and to
answer ongoing questions during WG meetings about how to deal with
shutdown interface.
10.8 Added informational section discussing possible future
variations of the ACP for potential adopters that cannot directly use
the complete solution described in this document unmodified.
14.19. draft-ietf-anima-autonomic-control-plane-13
Swap author list (with permission).
6.1.1. Eliminate blank lines in definition by making it a picture
(reformatting only).
6.10.3.1 New paragraph: Explained how nodes using Zone-ID != 0 need
to use Zone-ID != 0 in GRASP so that we can avoid routing/forwarding
of Zone-ID = 0 prefixes.
Rest of feedback from review of -12, see
https://raw.githubusercontent.com/anima-wg/autonomic-control-
plane/master/draft-ietf-anima-autonomic-control-plane/12-feedback-
reply.txt
Review from Brian Carpenter:
various: Autonomous -> autonomic(ally) in all remaining occurrences.
various: changed "manual (configured)" to "explicitly (configured)"
to not exclude the option of (SDN controller) automatic configuration
(no humans involved).
1. Fixed reference to section 9.
2. Added definition of loopback interface == internal interface.
After discus on WG mailing lists, including 6man.
6.1.2 Defined CDP/OCSP and pointed to RFC5280 for them.
6.1.3 Removed "EST-TLS", no objective value needed or beneficial,
added explanation paragraph why.
6.2 Added to adjacency table the interface that a neighbor is
discovered on.
6.3 Simplified CDDL syntax: Only one method per AN_ACP objective
(because of locators). Example with two objectives in GRASP message.
6.8.1 Added note about link-local GRASP multicast message to avoid
confusion.
8.1.4 Added RFC8028 as recommended on hosts to better support VRF-
select with ACP.
8.2.1 Rewrote and Simplified CDDL for configured remote peer and
explanations. Removed pattern option for remote peer. Not important
enough to be mandated.
Review thread started by William Atwood:
2. Refined definition of VRF (vs. MPLS/VPN, LISP, VRF-LITE).
2. Refined definition of ACP (ACP includes ACP GRASP instance).
2. Added explanation for "zones" to terminology section and into
Zone Addressing Sub Scheme section, relating it to RFC4007 zones
(from Brian Carpenter).
4. Fixed text for ACP4 requirement (Clients of the ACP must not be
tied to specific protocol.).
5. Fixed step 4. with proposed text.
6.1.1 Included suggested explanation for rsub semantics.
6.1.3 must->MUST for at least one EST server in ACP network to
autonomically renew certs.
6.7.2 normative: AND MUST NOT (permit weaker crypto options.
6.7.1.1 also included text denying weaker IPsec profile options.
6.8.2 Fixed description how to build ACP GRASP virtual interfaces.
Added text that ACP continues to exist in absence of ACP neighbors.
various: Make sure all "zone" words are used consistently.
6.10.2/various: fixed 40-bit RFC4193 ULA prefix in all examples to
89b714f3db (thanks MichaelR).
6.10.1 Removed comment about assigned ULA addressing. Decision not
to use it now ancient history of WG decision making process, not
worth nothing anymore in the RFC.
Review from Yongkang Zhang:
6.10.5 Fixed length of Node-Numbers in ACP Vlong Addressing Sub-
Scheme.
14.20. draft-ietf-anima-autonomic-control-plane-14
Disclaimer: All new text introduced by this revision provides only
additional explanations/ details based on received reviews and
analysis by the authors. No changes to behavior already specified in
prior revisions.
Joel Halpern, review part 3:
Define/explain "ACP registrar" in reply to Joel Halpern review part
3, resolving primarily 2 documentation issues::
1. Unclear how much ACP depends on BRSKI. ACP document was
referring unqualified to registrars and Registrar-ID in the
addressing section without explaining what a registrar is,
leading to the assumption it must be a BRSKI Registrar.
2. Unclear how the ACP addresses in ACP domain certificates are
assigned because the BRSKI document does not defines this, but
refers to this ACP document.
Wrt. 1: ACP does NOT depend on BRSKI registrars, instead ANY
appropriate automated or manual mechanism can be used to enroll ACP
nodes with ACP domain certificates. This revision calls defines such
mechanisms the "ACP registrar" and defines requirements. this is
non-normative, because it does not define specific mechanisms that
need to be support. In ANI devices, ACP Registrars are BRSKI
Registrars. In non-ANI ACP networks, the registrar may simply be a
person using CLI/web-interfaces to provision domain certificates and
set the ACP address correctly in the ACP domain certificate.
Wrt. 2.: The BRSKI document does rightfully not define how the ACP
address assignment and creation of the ACP domain information field
has to work because this is independent of BRSKI and needs to follow
the same rules whatever protocol/mechanisms are used to implement an
ACP Registrar. Another set of protocols that could be used instead
of BRSKI is Netconf/Netconf-Call-Home, but such an alternative ACP
Registrar solution would need to be specified in its own document.
Additional text/sections had to be added to detail important
conditions so that automatic certificate maintenance for ACP nodes
(with BRSKI or other mechanisms) can be done in a way that as good as
possible maintains ACP address information of ACP nodes across the
nodes lifetime because that ACP address is intended as an identifier
of the ACP node.
Summary of sections added:
o 6.1.3.5/6.1.3.6 (normative): re-enrollment of ACP nodes after
certificate expiry/failure in a way that allows to maintain as
much as possible ACP address information.
o 6.10.7 (normative): defines "ACP Registrar" including requirements
and how it can perform ACP address assignment.
o 10.3 (informative): details / examples about registrars to help
implementers and operators understand easier how they operate, and
provide suggestion of models that a likely very useful (sub-CA
and/or centralized policy management).
o 10.4 (informative): Explains the need for the multiple address
sub-spaces defined in response to discuss with Joel.
Other changes:
Updated references (RFC8366, RFC8368).
Introduced sub-section headings for 6.1.3 (certificate maintenance)
because section became too long with newly added sub-sections. Also
some small text fixups/remove of duplicate text.
Gen-ART review, Elwyn Davies:
[RFC Editor: how can i raise the issue of problematic cross
references of terms in the terminology section - rendering is
problematic. ].
4. added explanation for ACP4 (finally).
6.1.1 Simplified text in bullet list explaining rfc822 encoding.
6.1.3 refined second paragraph defining remembering of previous EST
server and explaining how to do this with BRSKI.
9.1 Added paragraph outlining the benefit of the sub-CA Registrar
option for supporting partitioned networks.
Roughly 100 more nits/minor fixes throughout the document. See:
https://raw.githubusercontent.com/anima-wg/autonomic-control-
plane/master/draft-ietf-anima-autonomic-control-plane/13-elwynd-
reply.txt
Joel Halpern, review part 2:
6.1.1: added note about "+ +" format in address field when acp-
address and rsub are empty.
6.5.10 - clarified text about V bit in Vlong addressing scheme.
6.10.3/6.10.4 - moved the Z bit field up front (directly after base
scheme) and indicated more explicitly Z is part of selecting of the
sub-addressing scheme.
Refined text about reaching CRL Distribution Point, explain why
address as indicator to use ACP.
Note from Brian Carpenter: RFC Editor note for section reference into
GRASP.
IOT directorate review from Pascal Thubert:
Various Nits/typos.
TBD: Punted wish for mentioning RFC reference titles to RFC editor
for now.
1. Added section 1.1 - applicability, discussing protocol choices
re. applicability to constrained devices (or not). Added notion of
TCP/TLS via CoAP/DTLS to section 10.4 in support of this.
2. Added in-band / out-of-band into terminology.
5. Referenced section 8.2 for remote ACP channel configuration.
6.3 made M_FLOOD periods RECOMMENDED (less guesswork)
6.7.x Clarified conditional nature of MUST for the profile details of
IPsec parameters (aka: only 6.7.3 defines actual MUST for nodes,
prior notions only define the requirements for IPsec profiles IF
IPsec is supported.
6.8.1 Moved discussion about IP multicast, IGP, RPL for GRASP into a
new subsection in the informative part (section 10) to tighten up
text in normative part.
6.10.1 added another reference to stable-connectivity for interop
with IPv4 management.
6.10.1 removed mentioning of ULA-Random, term was used in email
discus of ULA with L=1, but term actually not defined in rfc4193, so
mentioning it is just confusing/redundant. Also added note about the
random hash being defined in this document, not using SHA1 from
rfc4193.
6.11.1.1 added suggested text about mechanisms to further reduce
opportunities for loop during reconvergence (active signaling options
from RFC6550).
6.11.1.3 made mode 2 MUST and mode 2 MAY (RPL MOP - mode of
operations). Removes ambiguity.
6.12.5 Added recommendation for RFC4429 (optimistic DAD).
Nits from Benjamin Kaduk: dTLS -> DTLS:
Review from Joel Halpern:
1. swapped order of "purposes" for ACP to match order in section 3.
1. Added notion about manageability of ACP gong beyond RFC7575
(before discussion of stable connectivity).
2. Changed definition of Intent to be same as reference model
(policy language instead of API).
6.1.1 changed BNF specification so that a local-part without acp-
address (for future extensions) would not be rfcSELF.+rsub but
simpler rfcSELF+rsub. Added explanation why rsub is in local-part.
Tried to eliminate unnecessary references to VRF to minimize
assumption how system is designed.
6.1.3 Explained how to make CDP reachable via ACP.
6.7.2 Made it clearer that constrained devices MUST support DTLS if
they cannot support IPsec.
6.8.2.1 clarified first paragraph (TCP retransmissions lightweight).
6.11.1 fixed up RPL profile text - to remove "VRF". Text was also
buggy. mentioned control plane, but it's a forwarding/silicon issue
to have these header.
6.12.5 Clarified how link-local ACP channel address can be derived,
and how not.
8.2.1 Fixed up text to distinguish between configuration and model
describing parameters of the configuration (spec only provides
parameter model).
Various Nits.
14.21. draft-ietf-anima-autonomic-control-plane-15
Only reshuffling and formatting changes, but wanted to allow
reviewers later to easily compare -13 with -14, and these changes in
-15 mess that up too much.
increased TOC depth to 4.
Separated and reordered section 10 into an operational and a
background and futures section. The background and futures could
also become appendices if the layout of appendices in RFC format
wasn't so horrible that you really only want to avoid using them (all
the way after a lot of text like references that stop most readers
from proceeding any further).
14.22. draft-ietf-anima-autonomic-control-plane-16
Mirja Kuehlewind:
Tightened requirements for ACP related GRASP objective timers.
Better text to introduce/explains baseline and constrained ACP
profiles.
IANA guideline: MUST only accept extensible last allocation for
address sub-scheme.
Moved section 11 into appendix.
Warren Kumari:
Removed "global routing table", replaced with "Data-Plane routing
(and forwarding) tables.
added text to indicate how routing protocols do like to have data-
plane dependencies.
Changed power consumption section re. admin-down state. Power needed
to bring up such interfaces make t inappropriate to probe. Need to
think more about best suggests -> beyond scope.
Replaced "console" with out-of-band... (console/management ethernet).
Various nits.
Joel Halpern:
Fixed up domain information field ABNF to eliminate confusion that
rsub is not an FQDN but only a prefix to routing-subdomain.
Corrected certcheck to separate out cert verification into lifetime
validity and proof of ownership of private key.
Fixed pagination for "ACP as security and transport substrate for
GRASP" picture.
14.23. draft-ietf-anima-autonomic-control-plane-17
Review Alissa Cooper:
Main discuss point fixed by untangling two specific node type cases:
NOC nodes have ACP domain cert without acp-address field. Are ACP
domain members, but cannot build ACP secure channels (just end-to-end
or nay other authentications.
ACP nodes may have other methods to assign ACP address than getting
it through the cert. This is indicated through new value 0 for acp-
address in certificate.
Accordingly modified texts in ABNF/explanation and Cert-Check
section.
Other:
Better separation of normative text and considerations for "future"
work:
- Marked missing chapters as Informative. Reworded requirements
section to indicate its informative nature, changed requirements to
_MUST_/_SHOULD_ to indicate these are not RFC2119 requirements but
that this requirements section is really just in place of a separate
solutions requirements document (that ANIMA was not allowed to
produce).
- removed ca. 20 instances of "futures" in normative part of
document.
- moved important instances of "futures" into new section A.10 (last
section of appendix). These serve as reminder of work discussed
during WG but not able to finish specifying it.
Eliminated perception that "rsub" (routing subdomain) is only
beneficial with future work. Example in A.7.
Added RFC-editor note re formatting of references to terms defined in
terminology section.
Using now correct RFC 8174 boilerplate.
Clarified semantic and use of manual ACP sub-scheme. Not used in
certificates, only assigned via traditional methods. Use for ACP-
connect subnets or the like.
Corrected text about Data-Plane dependencies of ACP. Appropriate
implementations can be fully data-plane independent (without more
spec work) if not sharing link-local address with Data-Plane. 6.12.2
text updated to discuss those (MAC address), A.10.2 discusses options
that would require new standards work.
Moved all text about Intent into A.8 to clearly mark it as futures.
Changed suggestion of future insecure ACP option to future "end-to-
end-security-only" option.
Various textual fixes.
Gen-ART review by Elwyn Davies:
Some fixes also mentioned by Alissa.
Added reference for OT.
Fixed notion that secure channel is not only a security association.
>20 good textual fixes. Thanks!
Other:
Added picture requested by Pascal Thubert about Dual-NOC (A.10.4).
Moved RFC-editor request for better first RFC reference closer to the
top of the document.
Fixed typo /126 -> 127 for prefix length with zone address scheme.
Overlooked early SecDir review from frank.xialiang@huawei.com:
most issues fixed through other review in -16. Added reference to
self-protection section 9.2 into security considerations section.
14.24. draft-ietf-anima-autonomic-control-plane-18
Too many word/grammar mistakes in -17.
14.25. draft-ietf-anima-autonomic-control-plane-19
Review Eric Rescola:
6.1.2 - clarified that we do certificate path validation against
potentially multiple trust anchors.
6.1.3 - Added more comprehensive explanation of Trust Points via new
section 6.1.3.
6.5 - added figure with sequential steps of ACP channel establishment
and Alice and Bob finding their role in the setup.
6.7.x - detailled crypto profiles: AES-256-GCM, ECDHE.
6.7.2 - Referring to RFC7525 as the required crypto profile for DTLS
(taking text from RFC8310 as previously discussed with Eric).
6.7.3 - Added explanation that ACP needs no single MTI secure channel
protocol with example.
6.10.2 - Added requirement that rsub must be choosen so that they
don't create SHA256 collisions. Added explanation how the same could
be done for different ACP networks with same trust anchors but that
this outside the scope of this specification.
6.7.10 - Explains security expectations against ACP registrars: Must
be trusted and then given credentials to act as PKI RA to help
pledges to enroll with an ACP certificate.
9.1 - Added explanations about merging ACP domains requiring both
domains to trust union of Trust Anchors and need to avod ULA hash
collisions.
11 - Added that ACP registrars are critical infrastructure requiring
hardening like CA, mentioning attack impact examples.
11 - Mentioning that ACP requires initial setup of CA and registrar.
11 - long rewrite/extension of group security model and its
implication shared with review from Ben (below).
Many nits fixed.
Review Benjamin Kaduk:
Fixed various nits.
Changed style of MUST/SHOULD in Requirements section to all lower
case to avoid any RFC2119 confusion.
1. clarified support for constrained devices/DTLS: Opportunistic.
1. Clarified ACPs use of two variants of GRASP DULL for neighbor
discovery and ACP grasp for service discovery/clients.
3.2 - amended text explaining what additional security ACP provides
for bootstrap protocols.
6.1.1 - Added note about ASN.1 encoding in the justification for use
of rfc822address.
6.1.2 - Added details how to handle ACP connection when node via
which OCSP/CRL-server is reached fails certificate verification.
12. Rewrote explanation why objective names requested for ACP use This text replaces the prior changelog with a summary to provide
SRV.name. guidance for further IESG review.
10.4 - added summary section about ACP and configuration. Please see revision -21 for the individual changelogs of prior
versions .
Review Eric Rescorla: 14.1.1. Reviews (while in IESG review status) / status
6.1.2 - changed peer certificate verification to be certificate path This document entered IESG review with version -13. It has since
verification, added lowercase normalizaion comparison to domain name seen the following reviews:
check.
6.1.2 - explained how domain membership check is authentication and IESG: Original owner/Yes: Terry Manderson (INT).
authorization.
6.1.4.1 - Fixed "objective value" to "objective name". IESG: No Objection: Deborah Brungard (RTG), Alissa Cooper (GEN),
Warren Kumari (OPS), Mirja Kuehlewind (TSV), Alexey Melnikov (ART),
Adam Roach (ART).
6.1.4.3 - check IPv6 address of CDP against CDP ACP certificate IPv6 IESG: No Objection, not counted anymore as they have left IESG: Ben
address only if URL uses IPv6 address. Campbell (ART), Spencer Dawkins (TSV).
6.10.1 - added more justification why there is no need for privacy IESG: Open DISCUSS hopefully resolved by this version: Eric Rescorla
protection of ACP addresses. (SEC, left IESG), Benjamin Kaduk (SEC).
6.11.1.1 - thorough fixup of sentences/structure of this RPL overview Other: Michael Richardson (WG), Brian Carpenter (WG), Pascal Thubert
section to make it more logical and easier to digest. Also added a (WG), Frank Xialiang (WG), Elwyn Davies (GEN), Joel Halpern (RTGdir),
paragraph about the second key benefit of this profile (scalability). Yongkang Zhang (WG), William Atwood (WG).
6.11.1.9 - Added explanation about not using RPL security from 14.1.2. BRSKI / ACP registrar related enhancements
Benjamin.
8.1.1 - Fixed up text for address assignment of ACP connect Only after ACP entered IESG review did it become clear that the in-
interfaces. Only recommending manual addressing scheme. progress BRSKI document would not provide all the explanations needed
for ACP registrars as expected earlier by ACP authors. Instead,
BRSKI will only specify a subset of required ACP behavior related to
certificate handling and registrar. There, it became clear that the
ACP draft should specify generic ACP registrar behavior independent
of BRSKI so ACP could be implemented with or without BRSKI and any
manual/proprietary or future standardized BRSKI alternatives (for
example via NetConf) would understand the requirements for ACP
registrars and its certificate handling.
9.1 - changed self-healing benefit text to describe immediate channel This lead to additional text about ACP registrars in the ACP
reset for short-lived certificates and describing how the same with document:
CRL/OCSP is optional.
11. - added note about immediate termination of secure channels after 1. Defined relationship ACP / ANI (ANI = ACP + BRSKI).
certificate expiry as this is uncommon today.
11. - rewrote section of security model, attacks and mitigation of 6.1.4 (new) Overview of trust points and trust anchors required for
compromised ACP members. ACP.
A.24 - clarified the process in which expired certificates are used 6.1.5.5 Added explanations/requirements for Re-enrolment.
for certificate renewal to avvoid higher overhead of -re-enrolment.
A.4 - removed mentioning of RPL trickle because not used by ACP RPL 6.10.7 Normative requirements for ACP registrars (BRSKI or not).
profile.
A.10.8 - added section discussing how to minimize risk of compromised 10.2 Operational expectations against ACP registrars (BRSKI or not).
nodes, recovering them or kicking them out.
14.26. Open Issues in -19 14.1.3. Normative enhancements since start of IESG review
Need to find good reference for TLS profile for ACP GRASP TLS In addition to above ACP registrar / BRSKI related enhancements there
connections. is a range of minor normative (also explanatory) enhancements since
the start of IESG review:
TBD: Add DTLS choice to GRASP secure channel. 6.1.1 Hex digits in ACP domain information field now upper-case (no
specific reason except that both options are equally good, but
capitalized ones are used in rfc5234).
14.27. draft-ietf-anima-autonomic-control-plane-20 6.1.5.3 Added explanations about CRLs.
(1)In reply to review of -16 by Ben Kaduk: 6.1.5.6 Added explanations of behavior under failing certificates.
Diff: 6.1.2 Allow ACP adddress '0' in ACP domain information field:
presence of address indicates permission to build ACP secure channel
to node, 0 indicates that the address of the node is assigned by
(future) other means than certificate. Non-autonomic nodes have no
address at all (that was in -13), and can only connect via ACP
connect interfaces to ACP.
http://tools.ietf.org/tools/rfcdiff/ 6.1.3 Distinction of real ACP nodes (with address) and those with
rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/ domain certificate without address added as a new rule to ACP domain
autonomic-control-plane/master/draft-ietf-anima-autonomic-control- membership check.
plane/draft-ietf-anima-autonomic-control-plane-
19.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-
control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-
ietf-anima-autonomic-control-plane.19.1.txt
6.1.1 - Changed ABNF to use HEXDIG (to simpllify ABNF) and changed 6.6 Added throttling of secure-channel setup attempts.
example to resulting uppercase hex characters. There was no specific
reason to pick lower vs. upper-case left, and predefined HEXDIG is
uppercase.
- Added explanation why internationalized domain-names are not 6.11.1.14 Removed requirement to handle unknown destination ACP
supported/required. traffic in low-end nodes that would never be RPL roots.
6.1.4.1 - better hint/formal text to explain grasp objective encoding 6.12.5 Added recommendation to use IPv6 DAD.
parameters.
6.7.1.1 - rewrote IPsec/IKEv2 requirements after discovering the 6.1.1, 6.7.1.1, 6.7.2, 6.7.3, 6.8.2 Various refined additional
appropriate references RFC8221/8247 and ben asking to use IANA certificate, secure channel protocol (IPsec/IKEv2 and DTLS) and ACP
registry code-point words correctly. Fully relying on RFC GRASP TLS protocol parameter requirements to ensure interoperating
recommendatin parameters, just stripping down required options to implementations (from SEC-AD review).
minimum for IPsec to simplify any HW dependencies. Not stripped down
IKEv2 (SW) requirements though - unclear if that would be useful.
6.7.1.2 - stripped down IPsec/GRE requirements by referring to the 14.1.4. Explanatory enhancements since start of IESG review
new text in 6.7.1.1 (reducing duplication that existed up to -19.
Referring to RFC7525 also as BCP as requested by Benj. Q: Do BCPs Beyond the functional enhancements from the previous two sections,
keep numbers even if RFCs for them change ?? Otherwise i am not sure the mayority of changes since -13 are additional explanations from
what difference it makes to mention the BCP (maybe just to emphasize review feedback, textual nits and restructuring - with no functional
on the operartional character..). requirement additions/changes.
6.8.2 - Also referring now to RFC7525 for TLS requirements. Authors 1.1 Added "applicability and scope" section with summarized
had overlooked that it was not only covering DTLS, but also TLS. explanations.
6.11.1.14 - added paragraph about "simple" nodes not having to become 2.Added in-band vs. out-of-band management definitions.
RPL roots (and therefore have less forwarding plane requirements.
Logic is that when there are only "simple" nodes, the requested
forwarding plane feature (diagnostcs) wouldn't be useful immediately
anyhow because no operator could connect to the network (all access
to ACP assumed to be via more intelligent nodes.
10.3.7 - Refined/amended explanation of ACP-connect configuration 6.1.2 (was 6.1.1) expanded explanations of reasoning for elements of
case and how it can also be simple. the ACP domain information field.
various - fixed places where LDevID was used instead of IDevID. Some 6.1.3 refined explanations of ACP domain membership check and
other smaller textual fixes justifications for it.
(2)In reply to review of -16 by Eric Rescorla (by Ben Kaduk): 6.5 Elaborated step-by-step secure channel setup.
Diff: 6.10 Additional explanations for addressing modes, additional table
of addressing formats (thanks MichaelR).
http://tools.ietf.org/tools/rfcdiff/ 6.10.5 introduced 'F' bit position as a better visual representation
rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/ in the Vlong address space.
autonomic-control-plane/master/draft-ietf-anima-autonomic-control-
plane/draft-ietf-anima-autonomic-control-
plane.19.1.txt&url2=https://raw.githubusercontent.com/anima-wg/
autonomic-control-plane/master/draft-ietf-anima-autonomic-control-
plane/draft-ietf-anima-autonomic-control-plane.19.2.txt
6.1.1. - new subsection to cover generic ACP certificate 6.11.1.1 extensive overhaul to improve readability of use of RPL
requirements. Must be rfc5280 complaint. Asks for what is (from IESG feedback of non-routing/RPL experts).
understood to be hopefully best current practices: Certificate with
ECDH public key, preferrably signed by ECDH key, describes how ACP
domain information field is effectively non cryptographic identity/
name of entity owning certificate.
6.1.3 (was 6.1.2) - ACP domain membership text refinement: 6.12.2 Added caution about unconfiguring data-plane IPv6 addresses
and impact to ACP (limitation of current ACP design, and pointint to
more details in 10.2).
emphasises how this includes action of a security association 10.4 New explanations / summary of configurations for ACP (aka: all
protocol (example IKEv2 proof of ownership of cert), reines relevant config is undesirable and only required for integrating with non-
parts of rfc5280, refines that CRL/OCSP are skipped only in absence autonomic components, primarily ACP-connect and Registrars).
of doing them via secure association protocol)..
created new summary at the end restating the purpose of the different 11. Textually enhanced / better structured security considerations
steps. section after IESG security review.
6.1.5 (was 6.1.4) - added requirement for EST server certificate to A. (new) Moved all explanations and discussions about futures from
have extended key use id-kp-cmcRA so clients can trust them when section 10 into this new appendix. This text should not be removed
requesting refreshed CA certificates. Also explains how to set up because it captures a lot of repeated asked questions in WG and
EST server for multiple ACP domains. during reviews and from users, and also captures ideas for some
likely important followup work. But none of this is relevant to
implementing (section 6) and operating (section 10) the ACP.
6.3 - DULL GRASP, explains why certs are not signalled in DULL grasp. 14.2. draft-ietf-anima-autonomic-control-plane-22
6.7 - explains generic requirements against security association Ben Kaduk review of -21:
protocols: be able to authenticate with ACP certificates, have
appropriate security level (weakest link). Be able to directly
signal ACP certificates due to absence of other option to learn peer
cert. Discusses cases (L2 security, physical security) where
security association protocol security can be relaxed/removed).
8.1.5 - GRASP via ACP connect: removed suggestion for policy RFC822 encoding of ACP domain information:
filtering of GRASP messages. Better restatement of security model of
ACP connect to argue that GRASP is to be run equally run across it as
across the rest of ACP.
few smaller textual improvements. 6.1.2 rewrote text for explaining / justifying use of rfc822name as
identifier for node CP in certificate (was discussed in thread, but
badly written in prior versions).
In reply to 2nd review email (new ballot position) by Ben Kaduk: 6.1.2 Changed EBNF syntax to use "+" after rfcSELF because that is
the known primary name to extensions separator in many email systems
("." was wrong in prior versions).
Diff: 6.1.2 Rewrote/improved explanations for use of rfc822name field to
explain better why it is PKIX compliant and the right thing to do.
http://tools.ietf.org/tools/rfcdiff/ Crypto parameters for IPsec:
rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/
autonomic-control-plane/master/draft-ietf-anima-autonomic-control-
plane/draft-ietf-anima-autonomic-control-
plane.19.2.txt&url2=https://raw.githubusercontent.com/anima-wg/
autonomic-control-plane/master/draft-ietf-anima-autonomic-control-
plane/draft-ietf-anima-autonomic-control-plane.19.3.txt
large number of textual nits (thanks a lot!). 6.1 - Added explanation of why manual keying for ACP is not feasible
for ACP. Surprisingly, that text did not exist. Referred to by
IPsec text (6.7.1), but here is the right place to describe the
reasoning.
6.1.1 - Attempted to further complete whats required in certificate: 6.1.2 - Small textual refinement referring to requirements to
take from rfc5280 and if feasible by operator policy copy attributes authenticate peers (for the special cases of empty or '0' ACP address
from IDevID for easier diagnostics. Added note that authorization in ACP domain information field.
mechanisms for ACP can extend over time leveraging other fields of
certificate.
6.1.2 - Added paragraph stating ABNF domain-information field is what 6.3 - To better justify Bens proposed change of secure channel
becomes the rfc822address and other ABNF terminal nodes are used just protocol being IPsec vs. GRASP objective being IKEv2, better
in the text (and hash creation). explained how protocol indicated in GRASP objective-value is name of
protocol used to negotiate secure channel, use example of IKEv2 to
negotiate IPsec.
6.1.5.1 - added note about unknown GRASP objective values MUST be 6.7.1 - refinemenet similar to 6.3.
ignored.
6.1.5.3 - CDP distribution uses HTTP, not HTTP (to avoid circular - moved new paragraph from Bens pull request up from 6.7.1.1 to 6.7.1
authentication reuirements and because payload is self signed/ as it equally applies to GRE encapped IPsec (looks nicer one level
authenticated). up).
6.5 (Channel selection) - Alice/Bob uses ACP address as tiebreakers, - created subsections 6.7.1.1 (IPsec/ESP) / 6.7.1.2 (IKEv2) to
empty ACP address just means "lowest tie-breaker" (become Bob). clearer distinguish between these two requirements blocks.
10.3.5.1 - Better justification why ANI MUST be explicitly configured - Refined the text in these two sections to hopefully be a good
on brownfield nodes - customer not bothering about registering answer to Valery's concern of not randomnly mocking with existing
company with MASA etc. requirements docs (rfc8247 / rfc8221).
A.6 - added RFC editor note to remove this section before publication 6.7.1.1.1 - IPsec/ESP requirements section:
(as i think we agreed on earlier in WG).
A.7 - added note about possible security wise undesirability to make - MUST support rfc8221 mandatory EXCEPT for the superceeding
IDevID information of nodes available even easier through unprotected requirements in this section. Previously, this was not quite clear
protocols. from the text.
In reply to Michael Richardson: - Hopefully persuasive explanations about the requirements levels for
ENCR_AES_GCM_16, ENCR_AES_CBC, ENCR_AES_CCM_8 and
ENCR_CHACHA20_POLY1305: Restructured text for why not ENCR_AES_CBC
(was in prior version, just not well structured), added new
expanations for ENCR_AES_CCM_8 and ENCR_CHACHA20_POLY130.
Diff: - In simple terms, requirements for ENCR_AES_CBC, ENCR_AES_CCM_8,
ENCR_CHACHACHA are SHOULD when they are implementable with rqual or
faster performancce than ENCR_AES_GCM_16.
http://tools.ietf.org/tools/rfcdiff/ - Removed text about "additional rfc8221" reqiurements MAY be used.
rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/ Now the logic is that all other requirements apply. Hopefully we
autonomic-control-plane/master/draft-ietf-anima-autonomic-control- have written enough so that we prohibited downgrades.
plane/draft-ietf-anima-autonomic-control-
plane.19.3.txt&url2=https://raw.githubusercontent.com/anima-wg/
autonomic-control-plane/master/draft-ietf-anima-autonomic-control-
plane/draft-ietf-anima-autonomic-control-plane.19.4.txt
Missing changes lost in github from March 2019, no functional all 6.7.1.1.2 - RFC8247 requirements:
textual/representation improvements:
Terminology text improvements, sUDI, routing-subdomain. - Added mandate to support rfc8247, added explanation that there is
no "stripping down" requirement, just additional stronger
requirements to mandate correct use of ACP certificartes during
authentication.
6.10.2 - new table showing the different address formats as a - refined text on identifying ACP by IPv6 address to be clearer:
summary. Identifying in the context of IKEv2 and cases for '0' in ACP domain
information.
6.10.5 - Vlong address format, cleaned up representation by - removed last two paragraphs about relationship to rfc8247, as his
introducing F-bit to distinguish 23/15 Vlong address prefixes. is now written in first paragraph of the section.
Adjusted explanatory text accordingly.
6.1.5.1 - Changed TCP port for SRV.est from 80 to 443 (EST is using End of Ben Kaduk review related fixes.
TLS).
Other: Other:
Change author association: Toerless Eckert, Huawei -> Futurewei USA. Forgot to update example of ACP domain information to use capitalized
hex-digits as required by HEXDIGIT used.
14.28. draft-ietf-anima-autonomic-control-plane-21
In reply to review of -19 by Ben Kaduk (also for Eric Rescorla) that
where not fixed in -20:
6.1.1 Added missing detail about ACP domain certificate requirements
and explanations.
Also added pointer to CABFORUM cert recommendations as suggested by
MichaelR (changing pointer, external non-IETF document, so can not be
a real MUST/SHOULD).
6.7 Added requirement for PFS in secure channel protocols. Added reference to RFC8316 (AN use-cases) to beginning of section 3
(ACP use cases).
6.8.2 Added TLS security profile based on 'intersection' of Bens Small Enhanced IPsec parameters description / requirements fixes
recommended profiles and RFC7525. (from Michael Richardson).
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
skipping to change at page 141, line 26 skipping to change at page 120, line 46
Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T.
Fossati, "Support for Short-Term, Automatically-Renewed Fossati, "Support for Short-Term, Automatically-Renewed
(STAR) Certificates in Automated Certificate Management (STAR) Certificates in Automated Certificate Management
Environment (ACME)", draft-ietf-acme-star-11 (work in Environment (ACME)", draft-ietf-acme-star-11 (work in
progress), October 2019. progress), October 2019.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-29 (work in progress), October 2019. keyinfra-34 (work in progress), January 2020.
[I-D.ietf-anima-prefix-management] [I-D.ietf-anima-prefix-management]
Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic
IPv6 Edge Prefix Management in Large-scale Networks", IPv6 Edge Prefix Management in Large-scale Networks",
draft-ietf-anima-prefix-management-07 (work in progress), draft-ietf-anima-prefix-management-07 (work in progress),
December 2017. December 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.,
and J. Nobre, "A Reference Model for Autonomic and J. Nobre, "A Reference Model for Autonomic
skipping to change at page 142, line 6 skipping to change at page 121, line 22
Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero
Touch Provisioning (SZTP)", draft-ietf-netconf- Touch Provisioning (SZTP)", draft-ietf-netconf-
zerotouch-29 (work in progress), January 2019. zerotouch-29 (work in progress), January 2019.
[I-D.ietf-roll-applicability-template] [I-D.ietf-roll-applicability-template]
Richardson, M., "ROLL Applicability Statement Template", Richardson, M., "ROLL Applicability Statement Template",
draft-ietf-roll-applicability-template-09 (work in draft-ietf-roll-applicability-template-09 (work in
progress), May 2016. progress), May 2016.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "Using RPL Robles, I., Richardson, M., and P. Thubert, "Using RPI
Option Type, Routing Header for Source Routes and IPv6-in- Option Type, Routing Header for Source Routes and IPv6-in-
IPv6 encapsulation in the RPL Data Plane", draft-ietf- IPv6 encapsulation in the RPL Data Plane", draft-ietf-
roll-useofrplinfo-31 (work in progress), August 2019. roll-useofrplinfo-34 (work in progress), January 2020.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-33 (work in progress), October 1.3", draft-ietf-tls-dtls13-34 (work in progress),
2019. November 2019.
[IEEE-1588-2008] [IEEE-1588-2008]
IEEE, "IEEE Standard for a Precision Clock Synchronization IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems", Protocol for Networked Measurement and Control Systems",
December 2008, <http://standards.ieee.org/findstds/ December 2008, <http://standards.ieee.org/findstds/
standard/1588-2008.html>. standard/1588-2008.html>.
[IEEE-802.1X] [IEEE-802.1X]
Group, W. -. H. L. L. P. W., "IEEE Standard for Local and Group, W. -. H. L. L. P. W., "IEEE Standard for Local and
Metropolitan Area Networks: Port-Based Network Access Metropolitan Area Networks: Port-Based Network Access
skipping to change at page 147, line 15 skipping to change at page 126, line 35
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028, Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016, DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/info/rfc8028>. <https://www.rfc-editor.org/info/rfc8028>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8316] Nobre, J., Granville, L., Clemm, A., and A. Gonzalez
Prieto, "Autonomic Networking Use Case for Distributed
Detection of Service Level Agreement (SLA) Violations",
RFC 8316, DOI 10.17487/RFC8316, February 2018,
<https://www.rfc-editor.org/info/rfc8316>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
[RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic
Control Plane for Stable Connectivity of Network Control Plane for Stable Connectivity of Network
Operations, Administration, and Maintenance (OAM)", Operations, Administration, and Maintenance (OAM)",
RFC 8368, DOI 10.17487/RFC8368, May 2018, RFC 8368, DOI 10.17487/RFC8368, May 2018,
<https://www.rfc-editor.org/info/rfc8368>. <https://www.rfc-editor.org/info/rfc8368>.
 End of changes. 119 change blocks. 
1556 lines changed or deleted 578 lines changed or added

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