< draft-ietf-anima-autonomic-control-plane.txt   draft-ietf-anima-autonomic-control-plane.txt >
skipping to change at page 2, line 21 skipping to change at page 2, line 21
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction (Informative) . . . . . . . . . . . . . . . . . 6 1. Introduction (Informative) . . . . . . . . . . . . . . . . . 6
1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 9 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 9
2. Acronyms and Terminology (Informative) . . . . . . . . . . . 10 2. Acronyms and Terminology (Informative) . . . . . . . . . . . 10
3. Use Cases for an Autonomic Control Plane (Informative) . . . 16 3. Use Cases for an Autonomic Control Plane (Informative) . . . 16
3.1. An Infrastructure for Autonomic Functions . . . . . . . . 16 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 16
3.2. Secure Bootstrap over a not configured Network . . . . . 16 3.2. Secure Bootstrap over a not configured Network . . . . . 17
3.3. Data-Plane Independent Permanent Reachability . . . . . . 17 3.3. Data-Plane Independent Permanent Reachability . . . . . . 17
4. Requirements (Informative) . . . . . . . . . . . . . . . . . 18 4. Requirements (Informative) . . . . . . . . . . . . . . . . . 19
5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 19 5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 20
6. Self-Creation of an Autonomic Control Plane (ACP) 6. Self-Creation of an Autonomic Control Plane (ACP)
(Normative) . . . . . . . . . . . . . . . . . . . . . . . 21 (Normative) . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Requirements for use of Transport Layer Security (TLS) . 21 6.1. Requirements for use of Transport Layer Security (TLS) . 22
6.2. ACP Domain, Certificate and Network . . . . . . . . . . . 22 6.2. ACP Domain, Certificate and Network . . . . . . . . . . . 23
6.2.1. ACP Certificates . . . . . . . . . . . . . . . . . . 23 6.2.1. ACP Certificates . . . . . . . . . . . . . . . . . . 24
6.2.2. ACP Certificate AcpNodeName . . . . . . . . . . . . . 25 6.2.2. ACP Certificate AcpNodeName . . . . . . . . . . . . . 26
6.2.2.1. AcpNodeName ASN.1 Module . . . . . . . . . . . . 28 6.2.2.1. AcpNodeName ASN.1 Module . . . . . . . . . . . . 29
6.2.3. ACP domain membership check . . . . . . . . . . . . . 29 6.2.3. ACP domain membership check . . . . . . . . . . . . . 30
6.2.3.1. Realtime clock and Time Validation . . . . . . . 31 6.2.3.1. Realtime clock and Time Validation . . . . . . . 32
6.2.4. Trust Anchors (TA) . . . . . . . . . . . . . . . . . 32 6.2.4. Trust Anchors (TA) . . . . . . . . . . . . . . . . . 33
6.2.5. Certificate and Trust Anchor Maintenance . . . . . . 33 6.2.5. Certificate and Trust Anchor Maintenance . . . . . . 34
6.2.5.1. GRASP objective for EST server . . . . . . . . . 34 6.2.5.1. GRASP objective for EST server . . . . . . . . . 35
6.2.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 36 6.2.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 37
6.2.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 36 6.2.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 37
6.2.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 37 6.2.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 38
6.2.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 37 6.2.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 38
6.2.5.6. Failing Certificates . . . . . . . . . . . . . . 39 6.2.5.6. Failing Certificates . . . . . . . . . . . . . . 40
6.3. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 39 6.3. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 40
6.4. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 40 6.4. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 41
6.5. Candidate ACP Neighbor Selection . . . . . . . . . . . . 43 6.5. Candidate ACP Neighbor Selection . . . . . . . . . . . . 45
6.6. Channel Selection . . . . . . . . . . . . . . . . . . . . 44 6.6. Channel Selection . . . . . . . . . . . . . . . . . . . . 45
6.7. Candidate ACP Neighbor verification . . . . . . . . . . . 48 6.7. Candidate ACP Neighbor verification . . . . . . . . . . . 49
6.8. Security Association (Secure Channel) protocols . . . . . 48 6.8. Security Association (Secure Channel) protocols . . . . . 49
6.8.1. General considerations . . . . . . . . . . . . . . . 49 6.8.1. General considerations . . . . . . . . . . . . . . . 50
6.8.2. Common requirements . . . . . . . . . . . . . . . . . 50 6.8.2. Common requirements . . . . . . . . . . . . . . . . . 51
6.8.3. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 51 6.8.3. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 52
6.8.3.1. Native IPsec . . . . . . . . . . . . . . . . . . 51 6.8.3.1. Native IPsec . . . . . . . . . . . . . . . . . . 52
6.8.3.1.1. RFC8221 (IPsec/ESP) . . . . . . . . . . . . . 52 6.8.3.1.1. RFC8221 (IPsec/ESP) . . . . . . . . . . . . . 53
6.8.3.1.2. RFC8247 (IKEv2) . . . . . . . . . . . . . . . 53 6.8.3.1.2. RFC8247 (IKEv2) . . . . . . . . . . . . . . . 54
6.8.3.2. IPsec with GRE encapsulation . . . . . . . . . . 54 6.8.3.2. IPsec with GRE encapsulation . . . . . . . . . . 55
6.8.4. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 55 6.8.4. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 56
6.8.5. ACP Secure Channel Profiles . . . . . . . . . . . . . 57 6.8.5. ACP Secure Channel Profiles . . . . . . . . . . . . . 58
6.9. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 57 6.9. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 58
6.9.1. GRASP as a core service of the ACP . . . . . . . . . 57 6.9.1. GRASP as a core service of the ACP . . . . . . . . . 58
6.9.2. ACP as the Security and Transport substrate for 6.9.2. ACP as the Security and Transport substrate for
GRASP . . . . . . . . . . . . . . . . . . . . . . . . 58 GRASP . . . . . . . . . . . . . . . . . . . . . . . . 59
6.9.2.1. Discussion . . . . . . . . . . . . . . . . . . . 61 6.9.2.1. Discussion . . . . . . . . . . . . . . . . . . . 62
6.10. Context Separation . . . . . . . . . . . . . . . . . . . 62 6.10. Context Separation . . . . . . . . . . . . . . . . . . . 63
6.11. Addressing inside the ACP . . . . . . . . . . . . . . . . 62 6.11. Addressing inside the ACP . . . . . . . . . . . . . . . . 63
6.11.1. Fundamental Concepts of Autonomic Addressing . . . . 62 6.11.1. Fundamental Concepts of Autonomic Addressing . . . . 63
6.11.2. The ACP Addressing Base Scheme . . . . . . . . . . . 64 6.11.2. The ACP Addressing Base Scheme . . . . . . . . . . . 65
6.11.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) . . . . . 65 6.11.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) . . . . . 67
6.11.4. ACP Manual Addressing Sub-Scheme (ACP-Manual) . . . 67 6.11.4. ACP Manual Addressing Sub-Scheme (ACP-Manual) . . . 68
6.11.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ 6.11.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/
ACP-VLong-16 . . . . . . . . . . . . . . . . . . . . 68 ACP-VLong-16 . . . . . . . . . . . . . . . . . . . . 69
6.11.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 69 6.11.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 70
6.11.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 70 6.11.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 71
6.11.7.1. Use of BRSKI or other Mechanism/Protocols . . . 70 6.11.7.1. Use of BRSKI or other Mechanism/Protocols . . . 71
6.11.7.2. Unique Address/Prefix allocation . . . . . . . . 71 6.11.7.2. Unique Address/Prefix allocation . . . . . . . . 72
6.11.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 71 6.11.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 72
6.11.7.4. Address/Prefix Persistence . . . . . . . . . . . 73 6.11.7.4. Address/Prefix Persistence . . . . . . . . . . . 74
6.11.7.5. Further Details . . . . . . . . . . . . . . . . 73 6.11.7.5. Further Details . . . . . . . . . . . . . . . . 74
6.12. Routing in the ACP . . . . . . . . . . . . . . . . . . . 73 6.12. Routing in the ACP . . . . . . . . . . . . . . . . . . . 74
6.12.1. ACP RPL Profile . . . . . . . . . . . . . . . . . . 74 6.12.1. ACP RPL Profile . . . . . . . . . . . . . . . . . . 75
6.12.1.1. Overview . . . . . . . . . . . . . . . . . . . . 74 6.12.1.1. Overview . . . . . . . . . . . . . . . . . . . . 75
6.12.1.1.1. Single Instance . . . . . . . . . . . . . . 74 6.12.1.1.1. Single Instance . . . . . . . . . . . . . . 75
6.12.1.1.2. Reconvergence . . . . . . . . . . . . . . . 75 6.12.1.1.2. Reconvergence . . . . . . . . . . . . . . . 76
6.12.1.2. RPL Instances . . . . . . . . . . . . . . . . . 76 6.12.1.2. RPL Instances . . . . . . . . . . . . . . . . . 77
6.12.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 76 6.12.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 77
6.12.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 76 6.12.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 77
6.12.1.5. Path Metric . . . . . . . . . . . . . . . . . . 76 6.12.1.5. Path Metric . . . . . . . . . . . . . . . . . . 77
6.12.1.6. Objective Function . . . . . . . . . . . . . . . 76 6.12.1.6. Objective Function . . . . . . . . . . . . . . . 77
6.12.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 76 6.12.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 77
6.12.1.8. Multicast . . . . . . . . . . . . . . . . . . . 77 6.12.1.8. Multicast . . . . . . . . . . . . . . . . . . . 78
6.12.1.9. Security . . . . . . . . . . . . . . . . . . . . 77 6.12.1.9. Security . . . . . . . . . . . . . . . . . . . . 78
6.12.1.10. P2P communications . . . . . . . . . . . . . . . 77 6.12.1.10. P2P communications . . . . . . . . . . . . . . . 78
6.12.1.11. IPv6 address configuration . . . . . . . . . . . 77 6.12.1.11. IPv6 address configuration . . . . . . . . . . . 78
6.12.1.12. Administrative parameters . . . . . . . . . . . 78 6.12.1.12. Administrative parameters . . . . . . . . . . . 79
6.12.1.13. RPL Packet Information . . . . . . . . . . . . . 78 6.12.1.13. RPL Packet Information . . . . . . . . . . . . . 79
6.12.1.14. Unknown Destinations . . . . . . . . . . . . . . 78 6.12.1.14. Unknown Destinations . . . . . . . . . . . . . . 79
6.13. General ACP Considerations . . . . . . . . . . . . . . . 79 6.13. General ACP Considerations . . . . . . . . . . . . . . . 80
6.13.1. Performance . . . . . . . . . . . . . . . . . . . . 79 6.13.1. Performance . . . . . . . . . . . . . . . . . . . . 80
6.13.2. Addressing of Secure Channels . . . . . . . . . . . 79 6.13.2. Addressing of Secure Channels . . . . . . . . . . . 80
6.13.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 80 6.13.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 81
6.13.4. Multiple links between nodes . . . . . . . . . . . . 80 6.13.4. Multiple links between nodes . . . . . . . . . . . . 81
6.13.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 80 6.13.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 82
6.13.5.1. ACP loopback interfaces . . . . . . . . . . . . 80 6.13.5.1. ACP loopback interfaces . . . . . . . . . . . . 82
6.13.5.2. ACP virtual interfaces . . . . . . . . . . . . . 83 6.13.5.2. ACP virtual interfaces . . . . . . . . . . . . . 84
6.13.5.2.1. ACP point-to-point virtual interfaces . . . 83 6.13.5.2.1. ACP point-to-point virtual interfaces . . . 84
6.13.5.2.2. ACP multi-access virtual interfaces . . . . 83 6.13.5.2.2. ACP multi-access virtual interfaces . . . . 84
7. ACP support on L2 switches/ports (Normative) . . . . . . . . 86 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 87
7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 86 7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 87
7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 87 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 88
8. Support for Non-ACP Components (Normative) . . . . . . . . . 88 8. Support for Non-ACP Components (Normative) . . . . . . . . . 89
8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 88 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 89
8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 89 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 90
8.1.2. Software Components . . . . . . . . . . . . . . . . . 91 8.1.2. Software Components . . . . . . . . . . . . . . . . . 92
8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 92 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 93
8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 93 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 94
8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 95 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 96
8.2. Connecting ACP islands over Non-ACP L3 networks (Remote ACP 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote ACP
neighbors) . . . . . . . . . . . . . . . . . . . . . . . 95 neighbors) . . . . . . . . . . . . . . . . . . . . . . . 97
8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 96 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 97
8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 97 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 98
8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 97 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 98
9. ACP Operations (Informative) . . . . . . . . . . . . . . . . 98 9. ACP Operations (Informative) . . . . . . . . . . . . . . . . 99
9.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . . 98 9.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . . 99
9.1.1. Secure Channel Peer diagnostics . . . . . . . . . . . 102 9.1.1. Secure Channel Peer diagnostics . . . . . . . . . . . 103
9.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 103 9.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 104
9.2.1. Registrar interactions . . . . . . . . . . . . . . . 103 9.2.1. Registrar interactions . . . . . . . . . . . . . . . 104
9.2.2. Registrar Parameter . . . . . . . . . . . . . . . . . 104 9.2.2. Registrar Parameter . . . . . . . . . . . . . . . . . 105
9.2.3. Certificate renewal and limitations . . . . . . . . . 105 9.2.3. Certificate renewal and limitations . . . . . . . . . 106
9.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 106 9.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 107
9.2.5. Centralized Policy Control . . . . . . . . . . . . . 106 9.2.5. Centralized Policy Control . . . . . . . . . . . . . 107
9.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 107 9.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 108
9.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . . 107 9.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . . 108
9.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 108 9.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 109
9.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 109 9.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 110
9.3.2.2. Fast state propagation and Diagnostics . . . . . 109 9.3.2.2. Fast state propagation and Diagnostics . . . . . 110
9.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 110 9.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 111
9.3.2.4. Power Consumption Issues . . . . . . . . . . . . 111 9.3.2.4. Power Consumption Issues . . . . . . . . . . . . 112
9.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 111 9.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 112
9.3.4. Which interfaces to auto-enable? . . . . . . . . . . 111 9.3.4. Which interfaces to auto-enable? . . . . . . . . . . 112
9.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . . 113 9.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . . 114
9.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 113 9.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 114
9.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 114 9.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 115
9.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 115 9.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 116
9.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 115 9.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 116
9.4. Partial or Incremental adoption . . . . . . . . . . . . . 116 9.4. Partial or Incremental adoption . . . . . . . . . . . . . 117
9.5. Configuration and the ACP (summary) . . . . . . . . . . . 117 9.5. Configuration and the ACP (summary) . . . . . . . . . . . 118
10. Summary: Benefits (Informative) . . . . . . . . . . . . . . . 118 10. Summary: Benefits (Informative) . . . . . . . . . . . . . . . 119
10.1. Self-Healing Properties . . . . . . . . . . . . . . . . 118 10.1. Self-Healing Properties . . . . . . . . . . . . . . . . 119
10.2. Self-Protection Properties . . . . . . . . . . . . . . . 120 10.2. Self-Protection Properties . . . . . . . . . . . . . . . 121
10.2.1. From the outside . . . . . . . . . . . . . . . . . . 120 10.2.1. From the outside . . . . . . . . . . . . . . . . . . 121
10.2.2. From the inside . . . . . . . . . . . . . . . . . . 121 10.2.2. From the inside . . . . . . . . . . . . . . . . . . 122
10.3. The Administrator View . . . . . . . . . . . . . . . . . 122 10.3. The Administrator View . . . . . . . . . . . . . . . . . 123
11. Security Considerations . . . . . . . . . . . . . . . . . . . 123 11. Security Considerations . . . . . . . . . . . . . . . . . . . 124
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 128 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 129
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 129 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 130
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 129 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 130
15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 130 15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 131
15.1. Summary of changes since entering IESG review . . . . . 130 15.1. Summary of changes since entering IESG review . . . . . 131
15.1.1. Reviews (while in IESG review status) / status . . . 130 15.1.1. Reviews (while in IESG review status) / status . . . 131
15.1.2. BRSKI / ACP registrar related enhancements . . . . . 131 15.1.2. BRSKI / ACP registrar related enhancements . . . . . 132
15.1.3. Normative enhancements since start of IESG review . 131 15.1.3. Normative enhancements since start of IESG review . 132
15.1.4. Explanatory enhancements since start of IESG 15.1.4. Explanatory enhancements since start of IESG
review . . . . . . . . . . . . . . . . . . . . . . . 132 review . . . . . . . . . . . . . . . . . . . . . . . 133
15.2. draft-ietf-anima-autonomic-control-plane-29 . . . . . . 133 15.2. draft-ietf-anima-autonomic-control-plane-29 . . . . . . 134
15.3. draft-ietf-anima-autonomic-control-plane-28 . . . . . . 135 15.3. draft-ietf-anima-autonomic-control-plane-28 . . . . . . 137
15.4. draft-ietf-anima-autonomic-control-plane-27 . . . . . . 136 15.4. draft-ietf-anima-autonomic-control-plane-27 . . . . . . 138
15.5. draft-ietf-anima-autonomic-control-plane-26 . . . . . . 137 15.5. draft-ietf-anima-autonomic-control-plane-26 . . . . . . 138
15.6. draft-ietf-anima-autonomic-control-plane-25 . . . . . . 137 15.6. draft-ietf-anima-autonomic-control-plane-25 . . . . . . 139
15.7. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 141 15.7. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 143
15.8. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 141 15.8. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 143
15.9. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 143 15.9. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 144
16. Normative References . . . . . . . . . . . . . . . . . . . . 145 16. Normative References . . . . . . . . . . . . . . . . . . . . 146
17. Informative References . . . . . . . . . . . . . . . . . . . 148 17. Informative References . . . . . . . . . . . . . . . . . . . 150
Appendix A. Background and Futures (Informative) . . . . . . . . 156 Appendix A. Background and Futures (Informative) . . . . . . . . 158
A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 157 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 158
A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 157 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 158
A.3. ACP Neighbor discovery protocol selection . . . . . . . . 158 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 160
A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 159 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 160
A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 159 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 160
A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 159 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 160
A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 160 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 161
A.5. ACP Information Distribution and multicast . . . . . . . 161 A.5. ACP Information Distribution and multicast . . . . . . . 162
A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 162 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 163
A.7. CAs, domains and routing subdomains . . . . . . . . . . . 164 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 165
A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 165 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 166
A.9. Adopting ACP concepts for other environments . . . . . . 166 A.9. Adopting ACP concepts for other environments . . . . . . 167
A.10. Further (future) options . . . . . . . . . . . . . . . . 168 A.10. Further (future) options . . . . . . . . . . . . . . . . 169
A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 168 A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 169
A.10.2. More options for avoiding IPv6 Data-Plane A.10.2. More options for avoiding IPv6 Data-Plane
dependencies . . . . . . . . . . . . . . . . . . . . 168 dependencies . . . . . . . . . . . . . . . . . . . . 170
A.10.3. ACP APIs and operational models (YANG) . . . . . . . 169 A.10.3. ACP APIs and operational models (YANG) . . . . . . . 170
A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 169 A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 170
A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 170 A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 171
A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 170 A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 172
A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 170 A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 172
A.10.8. Avoiding and dealing with compromised ACP nodes . . 171 A.10.8. Avoiding and dealing with compromised ACP nodes . . 173
A.10.9. Detecting ACP secure channel downgrade attacks . . . 172 A.10.9. Detecting ACP secure channel downgrade attacks . . . 174
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 173 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 174
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 7, line 18 skipping to change at page 7, line 18
In a fully autonomic network node without legacy control or In a fully autonomic network node without legacy control or
management functions/protocols, the Data-Plane would be for example management functions/protocols, the Data-Plane would be for example
just a forwarding plane for "Data" IPv6 packets, aka: packets other just a forwarding plane for "Data" IPv6 packets, aka: packets other
than the control and management plane packets that are forwarded by than the control and management plane packets that are forwarded by
the ACP itself. In such networks/nodes, there would be no non- the ACP itself. In such networks/nodes, there would be no non-
autonomous control or non-autonomous management plane. autonomous control or non-autonomous management plane.
Routing protocols for example would be built inside the ACP as so- Routing protocols for example would be built inside the ACP as so-
called autonomous functions via autonomous service agents, leveraging called autonomous functions via autonomous service agents, leveraging
the ACPs functions instead of implementing them seperately for each the ACP's functions instead of implementing them seperately for each
protocol: discovery, automatically established authenticated and protocol: discovery, automatically established authenticated and
encrypted local and distant peer connectivity for control and encrypted local and distant peer connectivity for control and
management traffic, and common control/management protocol session management traffic, and common control/management protocol session
and presentation functions. and presentation functions.
When ACP functionality is added to nodes that have non-autonomous When ACP functionality is added to nodes that have non-autonomous
management plane and/or control plane functions (henceforth called management plane and/or control plane functions (henceforth called
non-autonomous nodes), the ACP instead is best abstracted as a non-autonomous nodes), the ACP instead is best abstracted as a
special Virtual Routing and Forwarding (VRF) instance (or virtual special Virtual Routing and Forwarding (VRF) instance (or virtual
router) and the complete pre-existing non-autonomous management and/ router) and the complete pre-existing non-autonomous management and/
skipping to change at page 8, line 18 skipping to change at page 8, line 18
dependent bootstrap configuration is required. An example of dependent bootstrap configuration is required. An example of
such a secure bootstrap process is described in such a secure bootstrap process is described in
[I-D.ietf-anima-bootstrapping-keyinfra]. [I-D.ietf-anima-bootstrapping-keyinfra].
3. An operator can use it to access remote devices using protocols 3. An operator can use it to access remote devices using protocols
such as Secure SHell (SSH) or Network Configuration Protocol such as Secure SHell (SSH) or Network Configuration Protocol
(NETCONF) running across the ACP, even if the network is (NETCONF) running across the ACP, even if the network is
misconfigured or not configured. misconfigured or not configured.
This document describes these purposes as use cases for the ACP in This document describes these purposes as use cases for the ACP in
Section 3, it defines the requirements in Section 4. Section 5 gives Section 3, it defines the requirements in Section 4. Section 5 gives
an overview how the ACP is constructed. an overview of how the ACP is constructed.
The normative part of this document starts with Section 6, where the The normative part of this document starts with Section 6, where the
ACP is specified. Section 7 explains how to support ACP on L2 ACP is specified. Section 7 explains how to support ACP on L2
switches (normative). Section 8 explains how non-ACP nodes and switches (normative). Section 8 explains how non-ACP nodes and
networks can be integrated (normative). networks can be integrated (normative).
The remaining sections are non-normative: Section 10 reviews benefits The remaining sections are non-normative: Section 10 reviews benefits
of the ACP (after all the details have been defined), Section 9 of the ACP (after all the details have been defined), Section 9
provides operational recommendations, Appendix A provides additional provides operational recommendations, Appendix A provides additional
explanations and describes additional details or future standard or explanations and describes additional details or future standard or
propriety extensions that were considered not to be appropriate for proprietary extensions that were considered not to be appropriate for
standardization in this document but were considered important to standardization in this document but were considered important to
document. There are no dependencies against Appendix A to build a document. There are no dependencies against Appendix A to build a
complete working and interoperable ACP according to this document. complete working and interoperable ACP according to this document.
The ACP provides secure IPv6 connectivity, therefore it can be used The ACP provides secure IPv6 connectivity, therefore it can be used
not only as the secure connectivity for self-management as required not only as the secure connectivity for self-management as required
for the ACP in [RFC7575], but it can also be used as the secure for the ACP in [RFC7575], but it can also be used as the secure
connectivity for traditional (centralized) management. The ACP can connectivity for traditional (centralized) management. The ACP can
be implemented and operated without any other components of autonomic be implemented and operated without any other components of autonomic
networks, except for the GRASP protocol. ACP relies on per-link DULL networks, except for the GRASP protocol. ACP relies on per-link DULL
skipping to change at page 10, line 49 skipping to change at page 10, line 49
different expectations from those on which the current design is different expectations from those on which the current design is
based including supporting constrained devices better. based including supporting constrained devices better.
2. Acronyms and Terminology (Informative) 2. Acronyms and Terminology (Informative)
[RFC Editor: Please add ACP, BRSKI, GRASP, MASA to https://www.rfc- [RFC Editor: Please add ACP, BRSKI, GRASP, MASA to https://www.rfc-
editor.org/materials/abbrev.expansion.txt.] editor.org/materials/abbrev.expansion.txt.]
[RFC Editor: What is the recommended way to reference a hanging text, [RFC Editor: What is the recommended way to reference a hanging text,
e.g.: to a definition in the list of definitions ? Up to -28, this e.g.: to a definition in the list of definitions ? Up to -28, this
document was using XMLv2 and the the only option I could find for document was using XMLv2 and the only option I could find for RFC/XML
RFC/XML to point to a hanging text was format="title" , which leads to point to a hanging text was format="title" , which leads to
to references such as '->"ACP certificate" ()', aka: redundant empty references such as '->"ACP certificate" ()', aka: redundant empty
parenthsis. Many reviewer where concerned about this. I created a parenthsis. Many reviewer where concerned about this. I created a
ticket to ask for an xml2rfc enhancement to avoid this in the future: ticket to ask for an xml2rfc enhancement to avoid this in the future:
https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347. When i https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347. When i
changed to XMLv3 in version -29, i could get rid of the unnecessary changed to XMLv3 in version -29, i could get rid of the unnecessary
() by using format="none", but that format is declared to be () by using format="none", but that format is declared to be
deprecated in XMLv3. So i am not aware of any working AND "non- deprecated in XMLv3. So i am not aware of any working AND "non-
deprecated" option.] deprecated" option.]
[RFC Editor: Question: Is it possible to change the first occurrences [RFC Editor: Question: Is it possible to change the first occurrences
of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC
skipping to change at page 14, line 33 skipping to change at page 14, line 33
LDevID certificate. See [AR8021]. LDevID certificate. See [AR8021].
Management: Used in this document as another word for ->"OAM". Management: Used in this document as another word for ->"OAM".
MASA (service): "Manufacturer Authorized Signing Authority". A MASA (service): "Manufacturer Authorized Signing Authority". A
vendor/manufacturer or delegated cloud service on the Internet vendor/manufacturer or delegated cloud service on the Internet
used as part of the BRSKI protocol. used as part of the BRSKI protocol.
MIC: "Manufacturer Installed Certificate". This is another word to MIC: "Manufacturer Installed Certificate". This is another word to
describe an IDevID in referenced materials. This term is not used describe an IDevID in referenced materials. This term is not used
in this document. in this document.
native interface: Interfaces existing on a node without native interface: Interfaces existing on a node without
configuration of the already running node. On physical nodes configuration of the already running node. On physical nodes
these are usually physical interfaces. On virtual nodes their these are usually physical interfaces; on virtual nodes their
equivalent. equivalent.
NOC: Network Operations Center. NOC: Network Operations Center.
node: A system supporting the ACP according to this document. Can node: A system supporting the ACP according to this document. Can
be virtual or physical. Physical nodes are called devices. be virtual or physical. Physical nodes are called devices.
Node-ID: The identifier of an ACP node inside that ACP. It is the Node-ID: The identifier of an ACP node inside that ACP. It is the
last 64 (see Section 6.11.3) or 78-bits (see Section 6.11.5) of last 64 (see Section 6.11.3) or 78-bits (see Section 6.11.5) of
the ACP address. the ACP address.
OAM: Operations, Administration and Management. Includes Network OAM: Operations, Administration and Management. Includes Network
Monitoring. Monitoring.
Operational Technology (OT): https://en.wikipedia.org/wiki/ Operational Technology (OT): https://en.wikipedia.org/wiki/
skipping to change at page 16, line 4 skipping to change at page 16, line 4
TA: "Trust Anchor". A Trust Anchor is an entity that is trusted for TA: "Trust Anchor". A Trust Anchor is an entity that is trusted for
the purpose of certificate validation. Trust Anchor Information the purpose of certificate validation. Trust Anchor Information
such as self-signed certificate(s) of the Trust Anchor is such as self-signed certificate(s) of the Trust Anchor is
configured into the ACP node as part of Enrollment. See configured into the ACP node as part of Enrollment. See
[RFC5280], Section 6.1.1. [RFC5280], Section 6.1.1.
UDI: "Unique Device Identifier". In the context of this document UDI: "Unique Device Identifier". In the context of this document
unsecured identity information of a node typically consisting of unsecured identity information of a node typically consisting of
at least device model/type and serial number, often in a vendor at least device model/type and serial number, often in a vendor
specific format. See sUDI and LDevID. specific format. See sUDI and LDevID.
ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6
address in the block fc00::/7, defined in [RFC4193]. It is the address in the block fc00::/7, defined in [RFC4193]. It is often
approximate IPv6 counterpart of the IPv4 private address thought of as the approximate IPv6 counterpart of the IPv4 private
([RFC1918]). The ULA Global ID prefix are the first 48-bits of a address ([RFC1918]). There are important differences though that
ULA address. In this document it is abbreviated as "ULA prefix". are beneficial for and exploited by the ACP, such as the ULA
Global ID prefix, which are the first 48-bits of a ULA address.
In this document it is abbreviated as "ULA prefix".
(ACP) VRF: The ACP is modeled in this document as a "Virtual Routing (ACP) VRF: The ACP is modeled in this document as a "Virtual Routing
and Forwarding" instance (VRF). This means that it is based on a and Forwarding" instance (VRF). This means that it is based on a
"virtual router" consisting of a separate IPv6 forwarding table to "virtual router" consisting of a separate IPv6 forwarding table to
which the ACP virtual interfaces are attached and an associated which the ACP virtual interfaces are attached and an associated
IPv6 routing table separate from the Data-Plane. Unlike the VRFs IPv6 routing table separate from the Data-Plane. Unlike the VRFs
on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF
does not have any special "core facing" functionality or routing/ does not have any special "core facing" functionality or routing/
mapping protocols shared across multiple VRFs. In vendor products mapping protocols shared across multiple VRFs. In vendor products
a VRF such as the ACP-VRF may also be referred to as a so called a VRF such as the ACP-VRF may also be referred to as a so called
VRF-lite. VRF-lite.
skipping to change at page 25, line 27 skipping to change at page 25, line 52
For further certificate details, ACP certificates may follow the For further certificate details, ACP certificates may follow the
recommendations from [CABFORUM]. recommendations from [CABFORUM].
For diagnostic and other operational purposes, it is beneficial to For diagnostic and other operational purposes, it is beneficial to
copy the device identifying fields of the node's IDevID certificate copy the device identifying fields of the node's IDevID certificate
into the ACP certificate, such as the [X.520], section 6.2.9 into the ACP certificate, such as the [X.520], section 6.2.9
"serialNumber" attribute in the subjects field distinguished name "serialNumber" attribute in the subjects field distinguished name
encoding. Note that this is not the certificate serial number. See encoding. Note that this is not the certificate serial number. See
also [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1. This can also [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1. This can
be done for example if it would be acceptable for the devices be done for example if it would be acceptable for the device's
"serialNumber" to be signalled via the Link Layer Discovery Protocol "serialNumber" to be signalled via the Link Layer Discovery Protocol
(LLDP, [LLDP]) because like LLDP signalled information, the ACP (LLDP, [LLDP]) because like LLDP signalled information, the ACP
certificate information can be retrieved by neighboring nodes without certificate information can be retrieved by neighboring nodes without
further authentication and be used either for beneficial diagnostics further authentication and be used either for beneficial diagnostics
or for malicious attacks. Retrieval of the ACP certificate is or for malicious attacks. Retrieval of the ACP certificate is
possible via a (failing) attempt to set up an ACP secure channel, and possible via a (failing) attempt to set up an ACP secure channel, and
the "serialNumber" contains usually device type information that may the "serialNumber" contains usually device type information that may
help to faster determine working exploits/attacks against the device. help to faster determine working exploits/attacks against the device.
Note that there is no intention to constrain authorization within the Note that there is no intention to constrain authorization within the
skipping to change at page 27, line 49 skipping to change at page 28, line 23
which part is the acp-domain-name and which is solely for which part is the acp-domain-name and which is solely for
creating a different ULA prefix. creating a different ULA prefix.
1.2 If both "acp-address" and "rsub" are omitted from 1.2 If both "acp-address" and "rsub" are omitted from
AcpNodeName, the "local-part" will have the format AcpNodeName, the "local-part" will have the format
"++extension(s)". The two plus characters are necessary so "++extension(s)". The two plus characters are necessary so
the node can unambiguously parse that both "acp-address" and the node can unambiguously parse that both "acp-address" and
"rsub" are omitted. "rsub" are omitted.
2. The encoding of the ACP domain name and ACP address as described 2. The encoding of the ACP domain name and ACP address as described
in this section is used for the following reasons: in this section is used for the following reasons:
2.1 The acp-node-name is the identifier of a node's ACP. It 2.1 The acp-node-name is the identifier of a node's ACP. It
includes the necessary components to identify a nodes ACP includes the necessary components to identify a node's ACP
both from within the ACP as well as from the outside of the both from within the ACP as well as from the outside of the
ACP. ACP.
2.2 For manual and/or automated diagnostics and backend 2.2 For manual and/or automated diagnostics and backend
management of devices and ACPs, it is necessary to have an management of devices and ACPs, it is necessary to have an
easily human readable and software parsed standard, single easily human readable and software parsed standard, single
string representation of the information in the acp-node- string representation of the information in the acp-node-
name. For example, inventory or other backend systems can name. For example, inventory or other backend systems can
always identify an entity by one unique string field but not always identify an entity by one unique string field but not
by a combination of multiple fields, which would be by a combination of multiple fields, which would be
necessary if there was no single string representation. necessary if there was no single string representation.
2.3 If the encoding was not that of such a string, it would be 2.3 If the encoding was not that of such a string, it would be
necessary to define a second standard encoding to provide necessary to define a second standard encoding to provide
skipping to change at page 31, line 13 skipping to change at page 32, line 13
ACP via ACP connect (Section 8.1) ACP via ACP connect (Section 8.1)
The special value 0 in an ACP certificates acp-address field is used The special value 0 in an ACP certificates acp-address field is used
for nodes that can and should determine their ACP address through for nodes that can and should determine their ACP address through
other mechanisms than learning it through the acp-address field in other mechanisms than learning it through the acp-address field in
their ACP certificate. These ACP nodes are permitted to establish their ACP certificate. These ACP nodes are permitted to establish
ACP secure channels. Mechanisms for those nodes to determine their ACP secure channels. Mechanisms for those nodes to determine their
ACP address are outside the scope of this specification, but this ACP address are outside the scope of this specification, but this
option is defined here so that any ACP nodes can build ACP secure option is defined here so that any ACP nodes can build ACP secure
channels to them according to Rule 5. channels to them according to Rule 5.
The optional rsub field of the AcpNodeName is not relevant to the ACP
domain membership check because it only serves to structure routing
and addressing within an ACP but not to segment mutual
authentication/authorization (hence the name "routing subdomain").
In summary: In summary:
* Steps 1...4 constitute standard certificate validity verification * Steps 1...4 constitute standard certificate validity verification
and private key authentication as defined by [RFC5280] and and private key authentication as defined by [RFC5280] and
security association protocols (such as Internet Key Exchange security association protocols (such as Internet Key Exchange
Protocol version 2 IKEv2 [RFC7296] when leveraging certificates. Protocol version 2 IKEv2 [RFC7296] when leveraging certificates.
* Steps 1...4 do not include verification of any pre-existing form * Steps 1...4 do not include verification of any pre-existing form
of non-public-key-only based identity elements of a certificate of non-public-key-only based identity elements of a certificate
such as a web servers domain name prefix often encoded in such as a web servers domain name prefix often encoded in
certificate common name. Step 5 is an equivalent step for the certificate common name. Step 5 is an equivalent step for the
skipping to change at page 41, line 48 skipping to change at page 43, line 14
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["AN_ACP", objective-flags, loop-count, objective = ["AN_ACP", objective-flags, loop-count,
objective-value] objective-value]
objective-flags = sync-only ; as in the GRASP specification objective-flags = sync-only ; as in the GRASP specification
sync-only = 4 ; M_FLOOD only requires synchronization sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 1 ; limit to link-local operation loop-count = 1 ; limit to link-local operation
objective-value = method objective-value = method / [ method, extensions ]
method = "IKEv2" / "DTLS" ; or future standard methods extensions = 1*any
method = method-name / [ method-name, method-params]
method-name = "IKEv2" / "DTLS" | any
method-params = 1*any
Figure 7: GRASP AN_ACP definition Figure 7: GRASP AN_ACP definition
The objective-flags field is set to indicate synchronization. The objective-flags field is set to indicate synchronization.
The loop-count is fixed at 1 since this is a link-local operation. The loop-count is fixed at 1 since this is a link-local operation.
In the above example the RECOMMENDED period of sending of the In the above example the RECOMMENDED period of sending of the
objective is 60 seconds. The indicated ttl of 210000 msec means that objective is 60 seconds. The indicated ttl of 210000 msec means that
the objective would be cached by ACP nodes even when two out of three the objective would be cached by ACP nodes even when two out of three
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 has to be set according to the In DULL this field is irrelevant but has to be set according to the
GRASP specification. 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 protocol The method-name in the 'objective-value' parameter is a string
available at the specified or implied locator. It is a protocol indicating the protocol available at the specified or implied
supported by the node to negotiate a secure channel. IKEv2 as shown locator. It is a protocol supported by the node to negotiate a
above is the protocol used to negotiate an IPsec secure channel. secure channel. IKEv2 as shown above is the protocol used to
negotiate an IPsec secure channel.
Method-params allows to carry method specific parameters. This
specification does not define any method-params for "IKEv2" or
"DTLS". Method-params for these two methods that are not understood
by an ACP node MUST be ignored by it.
extensions allows to define method independent parameters. This
specification does not define any extensions. Extensions not
understood by an ACP node MUST be ignored by it.
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 actual protocol used to negotiate an Internet Protocol IKEv2 is the actual protocol used to negotiate an Internet Protocol
security architecture (IPsec) connection. GRASP therefore indicates security architecture (IPsec) connection. GRASP therefore indicates
"IKEv2" and not "IPsec". If "IPsec" was used, this too could mean "IKEv2" and not "IPsec". If "IPsec" was used, this too could mean
use of the obsolete older version IKE (v1) ([RFC2409]). IKEv2 has an use of the obsolete older version IKE (v1) ([RFC2409]). IKEv2 has an
IANA assigned port number 500, but in the above example, the IANA assigned port number 500, but in the above example, the
skipping to change at page 43, line 38 skipping to change at page 45, line 18
in one message. This may be impractical though if ACP and BRSKI in one message. This may be impractical though if ACP and BRSKI
operations are implemented via separate software modules / ASAs. operations are implemented via separate software modules / ASAs.
The result of the discovery is the IPv6 link-local address of the The result of the discovery is the IPv6 link-local address of the
neighbor as well as its supported secure channel protocols (and non- neighbor as well as its supported secure channel protocols (and non-
standard port they are running on). It is stored in the ACP standard port they are running on). It is stored in the ACP
Adjacency Table (see Section 6.3), which then drives the further Adjacency Table (see Section 6.3), which then drives the further
building of the ACP to that neighbor. building of the ACP to that neighbor.
Note that the DULL GRASP objective described intentionally does not Note that the DULL GRASP objective described intentionally does not
include ACP nodes ACP certificate even though this would be useful include the ACP node's ACP certificate even though this would be
for diagnostics and to simplify the security exchange in ACP secure useful for diagnostics and to simplify the security exchange in ACP
channel security association protocols (see Section 6.8). The reason secure channel security association protocols (see Section 6.8). The
is that DULL GRASP messages are periodically multicasted across IPv6 reason is that DULL GRASP messages are periodically multicasted
subnets and full certificates could easily lead to fragmented IPv6 across IPv6 subnets and full certificates could easily lead to
DULL GRASP multicast packets due to the size of a certificate. This fragmented IPv6 DULL GRASP multicast packets due to the size of a
would be highly undesirable. certificate. This would be highly undesirable.
6.5. Candidate ACP Neighbor Selection 6.5. Candidate ACP Neighbor Selection
An ACP node determines to which other ACP nodes in the adjacency An ACP node determines to which other ACP nodes in the adjacency
table it should attempt to build an ACP connection. This is based on table it should attempt to build an ACP connection. This is based on
the information in the ACP Adjacency table. the information in the ACP Adjacency table.
The ACP is established exclusively between nodes in the same domain. The ACP is established exclusively between nodes in the same domain.
This includes all routing subdomains. Appendix A.7 explains how ACP This includes all routing subdomains. Appendix A.7 explains how ACP
connections across multiple routing subdomains are special. connections across multiple routing subdomains are special.
skipping to change at page 46, line 7 skipping to change at page 47, line 30
The Decider SHOULD NOT send actual payload packets across a secure The Decider SHOULD NOT send actual payload packets across a secure
channel until it has decided to use it. The Follower MAY delay channel until it has decided to use it. The Follower MAY delay
linking the ACP secure channel into the ACP virtual interface until linking the ACP secure channel into the ACP virtual interface until
it sees the first payload packet from the Decider up to a maximum of it sees the first payload packet from the Decider up to a maximum of
5 seconds to avoid unnecessarily linking a secure channel that will 5 seconds to avoid unnecessarily linking a secure channel that will
be terminated as undesired by the Decider shortly afterwards. be terminated as undesired by the Decider shortly afterwards.
The following sequence of steps show this example in more detail. The following sequence of steps show this example in more detail.
Each step is tagged with [<step#>{:<connection>}]. The connection is Each step is tagged with [<step#>{:<connection>}]. The connection is
included to easier distinguish which of the two competing connections included to more easily distinguish which of the two competing
the step belong to, one initiated by Node 1, one initiated by Node 2. connections the step belong to, one initiated by Node 1, one
initiated by Node 2.
[1] Node 1 sends GRASP AN_ACP message to announce itself [1] Node 1 sends GRASP AN_ACP message to announce itself
[2] Node 2 sends GRASP AN_ACP message to announce itself [2] Node 2 sends GRASP AN_ACP message to announce itself
[3] Node 2 receives [1] from Node 1 [3] Node 2 receives [1] from Node 1
[4:C1] Because of [3], Node 2 starts as initiator on its [4:C1] Because of [3], Node 2 starts as initiator on its
preferred secure channel protocol towards Node 1. preferred secure channel protocol towards Node 1.
Connection C1. Connection C1.
skipping to change at page 48, line 32 skipping to change at page 49, line 32
6.7. Candidate ACP Neighbor verification 6.7. Candidate ACP Neighbor verification
Independent of the security association protocol chosen, candidate Independent of the security association protocol chosen, candidate
ACP neighbors need to be authenticated based on their domain ACP neighbors need to be authenticated based on their domain
certificate. This implies that any secure channel protocol MUST certificate. This implies that any secure channel protocol MUST
support certificate based authentication that can support the ACP support certificate based authentication that can support the ACP
domain membership check as defined in Section 6.2.3. If it fails, domain membership check as defined in Section 6.2.3. If it fails,
the connection attempt is aborted and an error logged. Attempts to the connection attempt is aborted and an error logged. Attempts to
reconnect MUST be throttled. The RECOMMENDED default is exponential reconnect MUST be throttled. The RECOMMENDED default is exponential
base 2 backoff with a minimum delay of 10 seconds and a maximum delay base 2 backoff with an initial retransmission time (IRT) of 10
of 640 seconds. seconds and a maximum retransmission time (MRT) of 640 seconds.
Failure to authenticate an ACP neighbor when acting in the role of a Failure to authenticate an ACP neighbor when acting in the role of a
responder of the security authentication protocol MUST NOT impact the responder of the security authentication protocol MUST NOT impact the
attempts of the ACP node to attempt establishing a connection as an attempts of the ACP node to attempt establishing a connection as an
initiator. Only failed connection attempts as an initiator must initiator. Only failed connection attempts as an initiator must
cause throttling. This rule is meant to increase resilience of cause throttling. This rule is meant to increase resilience of
secure channel creation. Section 6.6 shows how simultaneous mutual secure channel creation. Section 6.6 shows how simultaneous mutual
secure channel setup collisions are resolved. secure channel setup collisions are resolved.
6.8. Security Association (Secure Channel) protocols 6.8. Security Association (Secure Channel) protocols
skipping to change at page 55, line 10 skipping to change at page 56, line 10
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.
The requirements for ESP/IPsec/IKEv2 with GRE are the same as for The requirements for ESP/IPsec/IKEv2 with GRE are the same as for
native IPsec (see Section 6.8.3.1) except that IPsec transport mode native IPsec (see Section 6.8.3.1) except that IPsec transport mode
and next protocol GRE (47) are to be negotiated. Tunnel mode is not and next protocol GRE (47) are to be negotiated. Tunnel mode is not
required because of GRE. Traffic Selectors are: required because of GRE. Traffic Selectors are:
TSi = (47, 0-65535, Initiator-IPv6-LL-addr ... Initiator-ACP-LL-addr) TSi = (47, 0-65535, Initiator-IPv6-LL-addr ... Initiator-IPv6-LL-
addr)
TSr = (47, 0-65535, Responder-IPv6-LL-addr ... Responder-IPv6-LL- TSr = (47, 0-65535, Responder-IPv6-LL-addr ... Responder-IPv6-LL-
addr) addr)
If IKEv2 initiator and responder support IPsec over GRE, it will be If IKEv2 initiator and responder support IPsec over GRE, it will be
preferred over native IPsec because of the way how IKEv2 negotiates preferred over native IPsec because of the way how IKEv2 negotiates
transport mode as used by this IPsec over GRE profile) versus tunnel transport mode as used by this IPsec over GRE profile) versus tunnel
mode as used by native IPsec (see [RFC7296], section 1.3.1). The ACP mode as used by native IPsec (see [RFC7296], section 1.3.1). The ACP
IPv6 traffic has to be carried across GRE according to [RFC7676]. IPv6 traffic has to be carried across GRE according to [RFC7676].
skipping to change at page 65, line 29 skipping to change at page 66, line 29
The sub-scheme may imply a range or set of addresses assigned to the The sub-scheme may imply a range or set of addresses assigned to the
node, this is called the ACP address range/set and explained in each node, this is called the ACP address range/set and explained in each
sub-scheme. sub-scheme.
Please refer to Section 6.11.7 and Appendix A.1 for further Please refer to Section 6.11.7 and Appendix A.1 for further
explanations why the following Sub-Addressing schemes are used and explanations why the following Sub-Addressing schemes are used and
why multiple are necessary. why multiple are necessary.
The following summarizes the addressing Sub-Schemes: The following summarizes the addressing Sub-Schemes:
+------+-----+-----------------+-------+------------+ +------+-----------------+-----------+-------------------+
| Type | Z | name | F-bit | V-bit size | | Type | Name |F-bit| Z | V-bits | Prefix |
+------+-----+-----------------+-------+------------+ +------+-----------------+-----+-----+----------+--------+
| 0x00 | 0 | ACP-Zone | N/A | 1 bit | | 0x00 | ACP-Zone | N/A | 0 | 1 bit | /127 |
+------+-----+-----------------+-------+------------+ +------+-----------------+-----+-----+----------+--------+
| 0x00 | 1 | ACP-Manual | N/A | 1 bit | | 0x00 | ACP-Manual | N/A | 1 | N/A | /64 |
+------+-----+-----------------+-------+------------+ +------+-----------------+-----+-----+----------+--------+
| 0x01 | N/A | ACP-VLong-8 | 0 | 8 bits | | 0x01 | ACP-VLong-8 | 0 | N/A | 8 bits | /120 |
+------+-----+-----------------+-------+------------+ +------+-----------------+-----+-----+----------+--------+
| 0x01 | N/A | ACP-VLong-16 | 1 | 16 bits | | 0x01 | ACP-VLong-16 | 1 | N/A | 16 bits | /112 |
+------+-----+-----------------+-------+------------+ +------+-----------------+-----+-----+----------+--------+
| 0x10 | Reserved / For future definition/allocation |
+------+-----------------+-----+-----+----------+--------+
| 0x11 | Reserved / For future definition/allocation |
+------+-----------------+-----+-----+----------+--------+
Figure 11: Addressing schemes Figure 11: Addressing Sub-Schemes
F-Bit and Z are two encoding fields explained below for the Sub-
Schemes that introduce/use them. V-bits is the number of bits of
addresses allocated to the ACP node. Prefix is the prefix the ACP
node is announcing into the RPL routing protocol.
6.11.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) 6.11.3. ACP Zone Addressing Sub-Scheme (ACP-Zone)
This sub-scheme is used when the Type field of the base scheme is This sub-scheme is used when the Type field of the base scheme is
0x00 and the Z bit is 0x0. 0x00 and the Z bit is 0x0.
64 64 64 64
+-----------------+---+---------++-----------------------------+---+ +-----------------+---+---------++-----------------------------+---+
| (base scheme) | Z | Zone-ID || Node-ID | | (base scheme) | Z | Zone-ID || Node-ID |
| | | || Registrar-ID | Node-Number| V | | | | || Registrar-ID | Node-Number| V |
skipping to change at page 68, line 24 skipping to change at page 69, line 29
ACP addressing sub-schemes. Nodes not capable (or permitted) to ACP addressing sub-schemes. Nodes not capable (or permitted) to
participate in ACP secure channels can connect to the ACP via ACP participate in ACP secure channels can connect to the ACP via ACP
connect interfaces of ACP edge nodes (see Section 8.1), without connect interfaces of ACP edge nodes (see Section 8.1), without
setting up an ACP secure channel. Their ACP certificate MUST omit setting up an ACP secure channel. Their ACP certificate MUST omit
the acp-address field to indicate that their ACP certificate is only the acp-address field to indicate that their ACP certificate is only
usable for non- ACP secure channel authentication, such as end-to-end usable for non- ACP secure channel authentication, such as end-to-end
transport connections across the ACP or Data-Plane. transport connections across the ACP or Data-Plane.
Address management of ACP connect subnets is done using traditional Address management of ACP connect subnets is done using traditional
assignment methods and existing IPv6 protocols. See Section 8.1.3 assignment methods and existing IPv6 protocols. See Section 8.1.3
for details. for details. Therefore the notion of V-bit many addresses assigned
to the ACP nodes does not apply to this Sub-Scheme.
6.11.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP-VLong-16 6.11.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP-VLong-16
This sub-scheme is used when the Type field of the base scheme is This sub-scheme is used when the Type field of the base scheme is
0x01. 0x01.
50 78 50 78
+---------------------++-----------------------------+----------+ +---------------------++-----------------------------+----------+
| (base scheme) || Node-ID | | (base scheme) || Node-ID |
| || Registrar-ID |F| Node-Number| V | | || Registrar-ID |F| Node-Number| V |
skipping to change at page 77, line 40 skipping to change at page 78, line 40
and integrity protection, their usage at the RPL layer would be and integrity protection, their usage at the RPL layer would be
redundant, and so RPL security is not used. redundant, and so RPL security is not used.
6.12.1.10. P2P communications 6.12.1.10. P2P communications
Not used. Not used.
6.12.1.11. IPv6 address configuration 6.12.1.11. IPv6 address configuration
Every ACP node (RPL node) announces an IPv6 prefix covering the Every ACP node (RPL node) announces an IPv6 prefix covering the
address(es) used in the ACP node. The prefix length depends on the addresses assigned to the ACP node via the AcpNodeName. The prefix
chosen addressing sub-scheme of the ACP address provisioned into the length depends on the addressing sub-scheme of the acp-address, /127
certificate of the ACP node, e.g., /127 for Zone Addressing Sub- for Zone Addressing Sub-Scheme and /112 or /120 for Vlong addressing
Scheme or /112 or /120 for Vlong addressing sub-scheme. See sub-scheme. See Section 6.11 for more details.
Section 6.11 for more details.
Every ACP node MUST install a black hole (aka null) route for Every ACP node MUST install a black hole (aka null) route if there
whatever ACP address space that it advertises (i.e.: the /96 or are unused parts of the ACP address space assigned to the ACP node
/127). This is avoid routing loops for addresses that an ACP node via its AcpNodeName. This is superceeded by longer prefixes assigned
has not (yet) used. to interfaces for the address space actually used by the node. For
example, when the node has an ACP-VLong-8 address space, it installs
a /120 black hole route. If it then for example only uses the ACP
address (first address from the space), it would assign that address
via a /128 address prefix to the ACP loopback interface (see
Section 6.13.5.1). None of those longer prefixes are announced into
RPL.
For ACP-Manual address prefixes configured on an ACP node, for
example for ACP connect subnets (see Section 8.1.1), the node
announces the /64 subnet prefix.
6.12.1.12. Administrative parameters 6.12.1.12. Administrative parameters
Administrative Preference ([RFC6550], 3.2.6 - to become root): Administrative Preference ([RFC6550], 3.2.6 - to become root):
Indicated in DODAGPreference field of DIO message. Indicated in DODAGPreference field of DIO message.
* Explicit configured "root": 0b100 * Explicit configured "root": 0b100
* ACP registrar (Default): 0b011 * ACP registrar (Default): 0b011
* ACP-connect (non-registrar): 0b010 * ACP-connect (non-registrar): 0b010
* Default: 0b001. * Default: 0b001.
skipping to change at page 80, line 17 skipping to change at page 81, line 29
The MTU for ACP secure channels MUST be derived locally from the The MTU for ACP secure channels MUST be derived locally from the
underlying link MTU minus the secure channel encapsulation overhead. underlying link MTU minus the secure channel encapsulation overhead.
ACP secure Channel protocols do not need to perform MTU discovery ACP secure Channel protocols do not need to perform MTU discovery
because they are built across L2 adjacencies - the MTU on both sides because they are built across L2 adjacencies - the MTU on both sides
connecting to the L2 connection are assumed to be consistent. connecting to the L2 connection are assumed to be consistent.
Extensions to ACP where the ACP is for example tunneled need to Extensions to ACP where the ACP is for example tunneled need to
consider how to guarantee MTU consistency. This is an issue of consider how to guarantee MTU consistency. This is an issue of
tunnels, not an issue of running the ACP across a tunnel. Transport tunnels, not an issue of running the ACP across a tunnel. Transport
stacks running across ACP can perform normal PMTUD (Path MTU stacks running across ACP can perform normal PMTUD (Path MTU
Discovery). Because the ACP is meant to be prioritize reliability Discovery). Because the ACP is meant to prioritize reliability over
over performance, they MAY opt to only expect IPv6 minimum MTU (1280) performance, they MAY opt to only expect IPv6 minimum MTU (1280) to
to avoid running into PMTUD implementation bugs or underlying link avoid running into PMTUD implementation bugs or underlying link MTU
MTU mismatch problems. mismatch problems.
6.13.4. Multiple links between nodes 6.13.4. Multiple links between nodes
If two nodes are connected via several links, the ACP SHOULD be If two nodes are connected via several links, the ACP SHOULD be
established across every link, but it is possible to establish the established across every link, but it is possible to establish the
ACP only on a sub-set of links. Having an ACP channel on every link ACP only on a sub-set of links. Having an ACP channel on every link
has a number of advantages, for example it allows for a faster has a number of advantages, for example it allows for a faster
failover in case of link failure, and it reflects the physical failover in case of link failure, and it reflects the physical
topology more closely. Using a subset of links (for example, a topology more closely. Using a subset of links (for example, a
single link), reduces resource consumption on the node, because state single link), reduces resource consumption on the node, because state
skipping to change at page 80, line 51 skipping to change at page 82, line 17
The ACP VRF has conceptually two type of interfaces: The "ACP The ACP VRF has conceptually two type of interfaces: The "ACP
Loopback interface(s)" to which the ACP ULA address(es) are assigned Loopback interface(s)" to which the ACP ULA address(es) are assigned
and the "ACP virtual interfaces" that are mapped to the ACP secure and the "ACP virtual interfaces" that are mapped to the ACP secure
channels. channels.
6.13.5.1. ACP loopback interfaces 6.13.5.1. ACP loopback interfaces
For autonomous operations of the ACP, as described in Section 6 and For autonomous operations of the ACP, as described in Section 6 and
Section 7, the ACP node uses the first address from the N bit ACP Section 7, the ACP node uses the first address from the N bit ACP
prefix (N = 128 - number of Vbits of the ACP address) assigned to the prefix (N = 128 - number of Vbits of the ACP address) assigned to the
node. This address is assigned with an adddress prefix of N or node. This address is assigned with an address prefix of N or larger
larger to a loopback interface. to a loopback interface.
Other addresses from the prefix can be used by the ACP of the node as Other addresses from the prefix can be used by the ACP of the node as
desired. The autonomous operations of the ACP does not require desired. The autonomous operations of the ACP does not require
additional global scope IPv6 addresses, they are instead intended for additional global scope IPv6 addresses, they are instead intended for
ASA or non-autonomous functions. Non fully autonomic components of ASA or non-autonomous functions. Non fully autonomic components of
the ACP such as ACP connect interfaces (see Figure 16 may also the ACP such as ACP connect interfaces (see Figure 16) may also
introduce additional global scope IPv6 addresses on other type of introduce additional global scope IPv6 addresses on other types of
interfaces into the ACP. interfaces into the ACP.
[RFC Editor: please remove this paragraph: Note to reviewers: Please [RFC Editor: please remove this paragraph: Note to reviewers: Please
do not complain again about an obsolete RFC number in the following do not complain again about an obsolete RFC number in the following
paragraph. The text should make it clear that the reference was paragraph. The text should make it clear that the reference was
choosen to indicate a particular point in time, but not to recommend/ choosen to indicate a particular point in time, but not to recommend/
use a particularily obsolete protocol spec.] use a particularily obsolete protocol spec.]
The use of loopback interfaces for global scope addresses is common The use of loopback interfaces for global scope addresses is common
operational configuration practice on routers, for example in IBGP operational configuration practice on routers, for example in IBGP
skipping to change at page 82, line 21 skipping to change at page 83, line 34
interface and making the addresses unusable, it could result in interface and making the addresses unusable, it could result in
unreachability of the address because the shortest path to the unreachability of the address because the shortest path to the
node might go through one of the other nodes on the same subnet node might go through one of the other nodes on the same subnet
which could equally consider the subnet to be operational even which could equally consider the subnet to be operational even
though it is not. though it is not.
5. Many OAM service implementations on routers can not deal with 5. Many OAM service implementations on routers can not deal with
more than one peer address, often because they do already expect more than one peer address, often because they do already expect
that a single loopback address can be used, especially to provide that a single loopback address can be used, especially to provide
a stable address under failure of external interfaces or links. a stable address under failure of external interfaces or links.
6. Even when an application supports multiple addresses to a peer, 6. Even when an application supports multiple addresses to a peer,
it can only use one adddress for a connection at a time with the it can only use one address for a connection at a time with the
most widely deployed transport protocols TCP and UDP. While most widely deployed transport protocols TCP and UDP. While
[RFC6824] solves this problem, it is not widely adopted for [RFC6824] solves this problem, it is not widely adopted for
router OAM services implementations. router OAM services implementations.
7. To completely autonomously assign global scope addresses to 7. To completely autonomously assign global scope addresses to
subnets connecting to other nodes, it would be necessary for subnets connecting to other nodes, it would be necessary for
every node to have an amount of prefix address space in the order every node to have an amount of prefix address space in the order
of the maximum number of subnets that the node could connect to of the maximum number of subnets that the node could connect to
and then the node would have to negotiate with adjacent nodes and then the node would have to negotiate with adjacent nodes
across those subnet whose address space to use for each subnet. across those subnet whose address space to use for each subnet.
8. Using global scope addresses for subnets between nodes is 8. Using global scope addresses for subnets between nodes is
skipping to change at page 92, line 35 skipping to change at page 93, line 35
software packages. software packages.
8.1.3. Auto Configuration 8.1.3. Auto Configuration
ACP edge nodes, NMS hosts and software components that as described ACP edge nodes, NMS hosts and software components that as described
in the previous section are meant to be composed via virtual in the previous section are meant to be composed via virtual
interfaces SHOULD support on the ACP connect subnet StateLess Address interfaces SHOULD support on the ACP connect subnet StateLess Address
Autoconfiguration (SLAAC - [RFC4862]) and route auto configuration Autoconfiguration (SLAAC - [RFC4862]) and route auto configuration
according to [RFC4191]. according to [RFC4191].
The ACP edge node acts as the router on the ACP connect subnet, The ACP edge node acts as the router towards the ACP on the ACP
providing the (auto-)configured prefix for the ACP connect subnet to connect subnet, providing the (auto-)configured prefix for the ACP
NMS hosts and/or software components. The ACP edge node uses route connect subnet and (auto-)configured routes into the ACP to NMS hosts
prefix option of RFC4191 to announce the default route (::/) with a and/or software components.
lifetime of 0 and aggregated prefixes for routes in the ACP routing
table with normal lifetimes. This will ensure that the ACP edge node The ACP edge node uses the Route Information Option (RIO) of RFC4191
does not become a default router, but that the NMS hosts and software to announce aggregated prefixes for address prefixes used in the ACP
components will route the prefixes used in the ACP to the ACP edge (with normal RIO lifetimes. In addition, the ACP edge node also uses
a RIO to announce the default route (::/0) with a lifetime of 0.
These RIOs allow to connect Type C hosts to the ACP via an ACP
connect subnet on one interface and another network (Data Plane / NMS
network) on the same or another interface of the Type C host, relying
on other routers than the ACP edge node. The RIOs ensure that these
hosts will only route the prefixes used in the ACP to the ACP edge
node. node.
Type A/B host ignore the RIOs and will consider the ACP node to be
their default router for all destination. This is sufficient when
type A/B hosts only need to connect to the ACP but not other
networks. Attaching Type A/B hosts to both the ACP and other
networks, requires either explicit ACP prefix route configuration on
the Type A/B hosts or the combined ACP/Data-Plane interface on the
ACP edge node, see Section 8.1.4.
Aggregated prefix means that the ACP edge node needs to only announce Aggregated prefix means that the ACP edge node needs to only announce
the /48 ULA prefixes used in the ACP but none of the actual /64 the /48 ULA prefixes used in the ACP but none of the actual /64
(Manual Addressing Sub-Scheme), /127 (ACP Zone Addressing Sub- (Manual Addressing Sub-Scheme), /127 (ACP Zone Addressing Sub-
Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual
ACP nodes. If ACP interfaces are configured with non ULA prefixes, ACP nodes. If ACP interfaces are configured with non ULA prefixes,
then those prefixes cannot be aggregated without further configured then those prefixes cannot be aggregated without further configured
policy on the ACP edge node. This explains the above recommendation policy on the ACP edge node. This explains the above recommendation
to use ACP ULA prefix covered prefixes for ACP connect interfaces: to use ACP ULA prefix covered prefixes for ACP connect interfaces:
They allow for a shorter list of prefixes to be signaled via RFC4191 They allow for a shorter list of prefixes to be signaled via RFC4191
to NMS hosts and software components. to NMS hosts and software components.
skipping to change at page 93, line 43 skipping to change at page 95, line 8
| | . | [ ] | +--------------+| | | . | [ ] | +--------------+|
+--------+ . +--------------------+ +--------------+ +--------+ . +--------------------+ +--------------+
. .
Data-Plane "native" and + ACP auto-negotiated/encrypted Data-Plane "native" and + ACP auto-negotiated/encrypted
Figure 17: VRF select Figure 17: VRF select
Using two physical and/or virtual subnets (and therefore interfaces) Using two physical and/or virtual subnets (and therefore interfaces)
into NMS Hosts (as per Section 8.1.1) or Software (as per into NMS Hosts (as per Section 8.1.1) or Software (as per
Section 8.1.2) may be seen as additional complexity, for example with Section 8.1.2) may be seen as additional complexity, for example with
legacy NMS Hosts that support only one IP interface. legacy NMS Hosts that support only one IP interface, or it may be
insufficient to support [RFC4191] Type A or B host (see
Section 8.1.3).
To provide a single subnet into both ACP and Data-Plane, the ACP Edge To provide a single subnet into both ACP and Data-Plane, the ACP Edge
node needs to de-multiplex packets from NMS hosts into ACP VRF and node needs to de-multiplex packets from NMS hosts into ACP VRF and
Data-Plane. This is sometimes called "VRF select". If the ACP VRF Data-Plane. This is sometimes called "VRF select". If the ACP VRF
has no overlapping IPv6 addresses with the Data-Plane (it should have has no overlapping IPv6 addresses with the Data-Plane (it should have
no overlapping addresses), then this function can use the IPv6 no overlapping addresses), then this function can use the IPv6
Destination address. The problem is Source Address Selection on the Destination address. The problem is Source Address Selection on the
NMS Host(s) according to RFC6724. NMS Host(s) according to RFC6724.
Consider the simple case: The ACP uses only one ULA prefix, the ACP Consider the simple case: The ACP uses only one ULA prefix, the ACP
skipping to change at page 117, line 31 skipping to change at page 118, line 31
Such a partial deployment may prove to be sufficient or could evolve Such a partial deployment may prove to be sufficient or could evolve
to become more autonomous through future standardized or non- to become more autonomous through future standardized or non-
standardized enhancements, for example by allowing GRASP messages to standardized enhancements, for example by allowing GRASP messages to
be propagated across the layer 3 VPN, leveraging for example L3VPN be propagated across the layer 3 VPN, leveraging for example L3VPN
Multicast support. Multicast support.
Finally, these partial deployments can be merged into a single Finally, these partial deployments can be merged into a single
contiguous complete autonomous ACP (given appropriate ACP support contiguous complete autonomous ACP (given appropriate ACP support
across the core) without changes in the crypto material, because the across the core) without changes in the crypto material, because the
nodes ACP certificates are fromm a single ACP. node's ACP certificates are fromm a single ACP.
9.5. Configuration and the ACP (summary) 9.5. Configuration and the ACP (summary)
There is no desirable configuration for the ACP. Instead, all There is no desirable configuration for the ACP. Instead, all
parameters that need to be configured in support of the ACP are parameters that need to be configured in support of the ACP are
limitations of the solution, but they are only needed in cases where limitations of the solution, but they are only needed in cases where
not all components are made autonomic. Whereever this is necessary, not all components are made autonomic. Whereever this is necessary,
it relies on pre-existing mechanisms for configuration such as CLI or it relies on pre-existing mechanisms for configuration such as CLI or
YANG ([RFC7950]) data models. YANG ([RFC7950]) data models.
skipping to change at page 125, line 14 skipping to change at page 126, line 14
* In the abscence of malicious software injection, an attacker that * In the abscence of malicious software injection, an attacker that
can misconfigure an ACP node which is supporting EST server can misconfigure an ACP node which is supporting EST server
functionality could attempt to configure a malicious CA. This functionality could attempt to configure a malicious CA. This
would not result in the ability to successfully renew ACP would not result in the ability to successfully renew ACP
certificates, but it could result in DoS attacks by becoming an certificates, but it could result in DoS attacks by becoming an
EST server and making ACP nodes attempting their ACP certificate EST server and making ACP nodes attempting their ACP certificate
renewal via this impaired ACP node. This problem can be avoided renewal via this impaired ACP node. This problem can be avoided
when the EST server implementation can verify that the CA when the EST server implementation can verify that the CA
configured is indeed providing renewal for certificates of the configured is indeed providing renewal for certificates of the
nodes ACP. The ability to do so depends on the EST-Server to CA node's ACP. The ability to do so depends on the EST-Server to CA
protocol, which is outside the scope of this document. protocol, which is outside the scope of this document.
In summary, attacks against the PKI/certificate dependencies of the In summary, attacks against the PKI/certificate dependencies of the
ACP can be minimized by a variety of hardware/software commponents ACP can be minimized by a variety of hardware/software commponents
including options such as TPM for IDevID/ACP-certificate, including options such as TPM for IDevID/ACP-certificate,
prohibitions against execution of non-trusted software and design prohibitions against execution of non-trusted software and design
aspects of the EST Server functionality for the ACP to eliminate aspects of the EST Server functionality for the ACP to eliminate
configuration level impairment. configuration level impairment.
Because ACP peers select one out of potentially more than one Because ACP peers select one out of potentially more than one
skipping to change at page 129, line 22 skipping to change at page 130, line 22
Systems, which started in early 2010. Many people contributed to Systems, which started in early 2010. Many people contributed to
this project and the idea of the Autonomic Control Plane, amongst this project and the idea of the Autonomic Control Plane, amongst
which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji
BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, 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. Sheng Jiang for their thorough reviews.
Many thanks Ben Kaduk, Roman Danyliv and Eric Rescorla for their Many thanks Ben Kaduk, Roman Danyliv and Eric Rescorla for their
thorough SEC AD reviews and to Valery Smyslov, Tero Kivinen, Paul thorough SEC AD reviews, Russ Housley and Erik Kline for their
Wouters and Yoav Nir for review of IPsec and IKEv2 parameters and reviews and to Valery Smyslov, Tero Kivinen, Paul Wouters and Yoav
helping to understand those and other security protocol details Nir for review of IPsec and IKEv2 parameters and helping to
better. understand those and other security protocol details better.
Further input, review or suggestions were received from: Rene Struik, Further input, review or suggestions were received from: Rene Struik,
Benoit Claise, William Atwood and Yongkang Zhang. Benoit Claise, William Atwood and Yongkang Zhang.
14. Contributors 14. Contributors
For all things GRASP including validation code, ongoing document text For all things GRASP including validation code, ongoing document text
support and technical input. support and technical input.
Brian Carpenter Brian Carpenter
skipping to change at page 131, line 45 skipping to change at page 132, line 45
the start of IESG review: the start of IESG review:
6.1.1 Hex digits in ACP domain information field now upper-case (no 6.1.1 Hex digits in ACP domain information field now upper-case (no
specific reason except that both options are equally good, but specific reason except that both options are equally good, but
capitalized ones are used in rfc5234). capitalized ones are used in rfc5234).
6.1.5.3 Added explanations about CRLs. 6.1.5.3 Added explanations about CRLs.
6.1.5.6 Added explanations of behavior under failing certificates. 6.1.5.6 Added explanations of behavior under failing certificates.
6.1.2 Allow ACP adddress '0' in ACP domain information field: 6.1.2 Allow ACP address '0' in ACP domain information field: presence
presence of address indicates permission to build ACP secure channel of address indicates permission to build ACP secure channel to node,
to node, 0 indicates that the address of the node is assigned by 0 indicates that the address of the node is assigned by (future)
(future) other means than certificate. Non-autonomic nodes have no other means than certificate. Non-autonomic nodes have no address at
address at all (that was in -13), and can only connect via ACP all (that was in -13), and can only connect via ACP connect
connect interfaces to ACP. interfaces to ACP.
6.1.3 Distinction of real ACP nodes (with address) and those with 6.1.3 Distinction of real ACP nodes (with address) and those with
domain certificate without address added as a new rule to ACP domain domain certificate without address added as a new rule to ACP domain
membership check. membership check.
6.6 Added throttling of secure-channel setup attempts. 6.6 Added throttling of secure-channel setup attempts.
6.11.1.14 Removed requirement to handle unknown destination ACP 6.11.1.14 Removed requirement to handle unknown destination ACP
traffic in low-end nodes that would never be RPL roots. traffic in low-end nodes that would never be RPL roots.
skipping to change at page 133, line 21 skipping to change at page 134, line 21
A. (new) Moved all explanations and discussions about futures from A. (new) Moved all explanations and discussions about futures from
section 10 into this new appendix. This text should not be removed section 10 into this new appendix. This text should not be removed
because it captures a lot of repeated asked questions in WG and because it captures a lot of repeated asked questions in WG and
during reviews and from users, and also captures ideas for some during reviews and from users, and also captures ideas for some
likely important followup work. But none of this is relevant to likely important followup work. But none of this is relevant to
implementing (section 6) and operating (section 10) the ACP. implementing (section 6) and operating (section 10) the ACP.
15.2. draft-ietf-anima-autonomic-control-plane-29 15.2. draft-ietf-anima-autonomic-control-plane-29
Discuss/Comments from Erik Kline:
Editorial suggestions and nits. Thanks!.
6.1.3 Added text about how/why rsub is irrelevant for domain
membership check.
6.3 Added extension points to AN_ACP DULL GRASP objective because for
example ACP domain certificate could be a nice optional additional
parameter and prior syntax would have forced us to encode into
separate objective unnecessarily.
6.7 Using RFC8415 terminology for exponential backoff parameters.
6.11.2 Amended ACP Sub-Addressing table with future code points,
explanations and prefix announced into RPL.
6.12.1.11. Reworked text to better explain how black hole route
works and added expanation for prefix for manual address scheme.
8.1.3. Reworked explanation of RIOs for ACP connect interfaces for
Type C vs. Type A/B hosts.
8.1.4. Added explanation how this "VRF select" option is required
for auto-attachment of Type A/B hosts to ACP and other networks.
Discuss/Comments from Barry Leiba: Discuss/Comments from Barry Leiba:
Various editorial nits - thanks. Various editorial nits - thanks.
6.1 New section pulling in TLS requirements, no need anymore to 6.1 New section pulling in TLS requirements, no need anymore to
duplicat for ACP GRASP, EST, BRSKI (ACP/ANI nodes) and (if desired) duplicat for ACP GRASP, EST, BRSKI (ACP/ANI nodes) and (if desired)
OCSP/CRLDP. Added rule to start use secure channel only after OCSP/CRLDP. Added rule to start use secure channel only after
negotiation has finished. Added rules not to optimize negotiation negotiation has finished. Added rules not to optimize negotiation
across multiple L2 interfaces to the same peer. across multiple L2 interfaces to the same peer.
skipping to change at page 157, line 15 skipping to change at page 158, line 23
A.1. ACP Address Space Schemes A.1. ACP Address Space Schemes
This document defines the Zone, Vlong and Manual sub address schemes This document defines the Zone, Vlong and Manual sub address schemes
primarily to support address prefix assignment via distributed, primarily to support address prefix assignment via distributed,
potentially uncoordinated ACP registrars as defined in potentially uncoordinated ACP registrars as defined in
Section 6.11.7. This costs 48/46-bit identifier so that these ACP Section 6.11.7. This costs 48/46-bit identifier so that these ACP
registrar can assign non-conflicting address prefixes. This design registrar can assign non-conflicting address prefixes. This design
does not leave enough bits to simultaneously support a large number does not leave enough bits to simultaneously support a large number
of nodes (Node-ID) plus a large prefix of local addresses for every of nodes (Node-ID) plus a large prefix of local addresses for every
node plus a large enough set of bits to identify a routing Zone. In node plus a large enough set of bits to identify a routing Zone. In
result, Zone, Vlong 8/16 attempt to support all features, but in via result, Zone, Vlong 8/16 attempt to support all features, but via
separate prefixes. separate prefixes.
In networks that always expect to rely on a centralized PMS as In networks that always expect to rely on a centralized PMS as
described above (Section 9.2.5), the 48/46-bits for the Registrar-ID described above (Section 9.2.5), the 48/46-bits for the Registrar-ID
could be saved. Such variations of the ACP addressing mechanisms could be saved. Such variations of the ACP addressing mechanisms
could be introduced through future work in different ways. If a new could be introduced through future work in different ways. If a new
otherName was introduced, incompatible ACP variations could be otherName was introduced, incompatible ACP variations could be
created where every design aspect of the ACP could be changed. created where every design aspect of the ACP could be changed.
Including all addressing choices. If instead a new addressing sub- Including all addressing choices. If instead a new addressing sub-
type would be defined, it could be a backward compatible extension of type would be defined, it could be a backward compatible extension of
 End of changes. 42 change blocks. 
253 lines changed or deleted 336 lines changed or added

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