< draft-ietf-anima-autonomic-control-plane.txt   draft-ietf-anima-autonomic-control-plane.txt >
ANIMA WG T. Eckert, Ed. ANIMA WG T. Eckert, Ed.
Internet-Draft Futurewei USA Internet-Draft Futurewei USA
Intended status: Standards Track M. Behringer, Ed. Intended status: Standards Track M. Behringer, Ed.
Expires: 25 February 2021 Expires: 7 March 2021
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
24 August 2020 3 September 2020
An Autonomic Control Plane (ACP) An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-29 draft-ietf-anima-autonomic-control-plane-29
Abstract Abstract
Autonomic functions need a control plane to communicate, which Autonomic functions need a control plane to communicate, which
depends on some addressing and routing. This Autonomic Control Plane depends on some addressing and routing. This Autonomic Control Plane
should ideally be self-managing, and as independent as possible of should ideally be self-managing, and as independent as possible of
configuration. This document defines such a plane and calls it the configuration. This document defines such a plane and calls it the
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 25 February 2021. This Internet-Draft will expire on 7 March 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 40 skipping to change at page 2, line 40
6.1.2.1. AcpNodeName ASN.1 Module . . . . . . . . . . . . 28 6.1.2.1. AcpNodeName ASN.1 Module . . . . . . . . . . . . 28
6.1.3. ACP domain membership check . . . . . . . . . . . . . 29 6.1.3. ACP domain membership check . . . . . . . . . . . . . 29
6.1.3.1. Realtime clock and Time Validation . . . . . . . 31 6.1.3.1. Realtime clock and Time Validation . . . . . . . 31
6.1.4. Trust Anchors (TA) . . . . . . . . . . . . . . . . . 32 6.1.4. Trust Anchors (TA) . . . . . . . . . . . . . . . . . 32
6.1.5. Certificate and Trust Anchor Maintenance . . . . . . 33 6.1.5. Certificate and Trust Anchor Maintenance . . . . . . 33
6.1.5.1. GRASP objective for EST server . . . . . . . . . 34 6.1.5.1. GRASP objective for EST server . . . . . . . . . 34
6.1.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 36 6.1.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 36
6.1.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 36 6.1.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 36
6.1.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 37 6.1.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 37
6.1.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 37 6.1.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 37
6.1.5.6. Failing Certificates . . . . . . . . . . . . . . 38 6.1.5.6. Failing Certificates . . . . . . . . . . . . . . 39
6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 39 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 39
6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 40 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 40
6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 43 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 44
6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 44 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 44
6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 47 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 47
6.7. Security Association (Secure Channel) protocols . . . . . 47 6.7. Security Association (Secure Channel) protocols . . . . . 47
6.7.1. General considerations . . . . . . . . . . . . . . . 48 6.7.1. General considerations . . . . . . . . . . . . . . . 48
6.7.2. Common requirements . . . . . . . . . . . . . . . . . 49 6.7.2. Common requirements . . . . . . . . . . . . . . . . . 49
6.7.3. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 50 6.7.3. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 50
6.7.3.1. Native IPsec . . . . . . . . . . . . . . . . . . 50 6.7.3.1. Native IPsec . . . . . . . . . . . . . . . . . . 50
6.7.3.1.1. RFC8221 (IPsec/ESP) . . . . . . . . . . . . . 51 6.7.3.1.1. RFC8221 (IPsec/ESP) . . . . . . . . . . . . . 51
6.7.3.1.2. RFC8247 (IKEv2) . . . . . . . . . . . . . . . 52 6.7.3.1.2. RFC8247 (IKEv2) . . . . . . . . . . . . . . . 52
skipping to change at page 3, line 33 skipping to change at page 3, line 33
6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 69 6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 69
6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 70 6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 70
6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 70 6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 70
6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 72 6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 72
6.10.7.5. Further Details . . . . . . . . . . . . . . . . 72 6.10.7.5. Further Details . . . . . . . . . . . . . . . . 72
6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 72 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 72
6.11.1. ACP RPL Profile . . . . . . . . . . . . . . . . . . 73 6.11.1. ACP RPL Profile . . . . . . . . . . . . . . . . . . 73
6.11.1.1. Overview . . . . . . . . . . . . . . . . . . . . 73 6.11.1.1. Overview . . . . . . . . . . . . . . . . . . . . 73
6.11.1.1.1. Single Instance . . . . . . . . . . . . . . 73 6.11.1.1.1. Single Instance . . . . . . . . . . . . . . 73
6.11.1.1.2. Reconvergence . . . . . . . . . . . . . . . 74 6.11.1.1.2. Reconvergence . . . . . . . . . . . . . . . 74
6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 74 6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 75
6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 74 6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 75
6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 75 6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 75
6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 75 6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 75
6.11.1.6. Objective Function . . . . . . . . . . . . . . . 75 6.11.1.6. Objective Function . . . . . . . . . . . . . . . 75
6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 75 6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 75
6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 76 6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 76
6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 76 6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 76
6.11.1.10. P2P communications . . . . . . . . . . . . . . . 76 6.11.1.10. P2P communications . . . . . . . . . . . . . . . 76
6.11.1.11. IPv6 address configuration . . . . . . . . . . . 76 6.11.1.11. IPv6 address configuration . . . . . . . . . . . 76
6.11.1.12. Administrative parameters . . . . . . . . . . . 76 6.11.1.12. Administrative parameters . . . . . . . . . . . 77
6.11.1.13. RPL Packet Information . . . . . . . . . . . . . 76 6.11.1.13. RPL Packet Information . . . . . . . . . . . . . 77
6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 77 6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 77
6.12. General ACP Considerations . . . . . . . . . . . . . . . 77 6.12. General ACP Considerations . . . . . . . . . . . . . . . 78
6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 77 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 78
6.12.2. Addressing of Secure Channels . . . . . . . . . . . 78 6.12.2. Addressing of Secure Channels . . . . . . . . . . . 78
6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 78 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 79
6.12.4. Multiple links between nodes . . . . . . . . . . . . 79 6.12.4. Multiple links between nodes . . . . . . . . . . . . 79
6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 79 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 79
6.12.5.1. ACP loopback interfaces . . . . . . . . . . . . 79 6.12.5.1. ACP loopback interfaces . . . . . . . . . . . . 79
6.12.5.2. ACP virtual interfaces . . . . . . . . . . . . . 81 6.12.5.2. ACP virtual interfaces . . . . . . . . . . . . . 82
6.12.5.2.1. ACP point-to-point virtual interfaces . . . 81 6.12.5.2.1. ACP point-to-point virtual interfaces . . . 82
6.12.5.2.2. ACP multi-access virtual interfaces . . . . 82 6.12.5.2.2. ACP multi-access virtual interfaces . . . . 82
7. ACP support on L2 switches/ports (Normative) . . . . . . . . 84 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 84
7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 84 7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 84
7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 85 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 86
8. Support for Non-ACP Components (Normative) . . . . . . . . . 87 8. Support for Non-ACP Components (Normative) . . . . . . . . . 87
8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 87 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 87
8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 87 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 88
8.1.2. Software Components . . . . . . . . . . . . . . . . . 90 8.1.2. Software Components . . . . . . . . . . . . . . . . . 90
8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 91 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 91
8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 91 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 92
8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 93 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 93
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) . . . . . . . . . . . . . . . . . . . . . . . 94 neighbors) . . . . . . . . . . . . . . . . . . . . . . . 94
8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 94 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 94
8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 95 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 95
8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 95 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 96
9. ACP Operations (Informative) . . . . . . . . . . . . . . . . 96 9. ACP Operations (Informative) . . . . . . . . . . . . . . . . 96
9.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . . 96 9.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . . 97
9.1.1. Secure Channel Peer diagnostics . . . . . . . . . . . 100 9.1.1. Secure Channel Peer diagnostics . . . . . . . . . . . 100
9.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 101 9.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 101
9.2.1. Registrar interactions . . . . . . . . . . . . . . . 101 9.2.1. Registrar interactions . . . . . . . . . . . . . . . 101
9.2.2. Registrar Parameter . . . . . . . . . . . . . . . . . 102 9.2.2. Registrar Parameter . . . . . . . . . . . . . . . . . 102
9.2.3. Certificate renewal and limitations . . . . . . . . . 103 9.2.3. Certificate renewal and limitations . . . . . . . . . 103
9.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 104 9.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 104
9.2.5. Centralized Policy Control . . . . . . . . . . . . . 104 9.2.5. Centralized Policy Control . . . . . . . . . . . . . 104
9.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 105 9.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 105
9.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . . 105 9.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . . 105
9.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 106 9.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 106
9.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 107 9.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 107
9.3.2.2. Fast state propagation and Diagnostics . . . . . 107 9.3.2.2. Fast state propagation and Diagnostics . . . . . 108
9.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 108 9.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 108
9.3.2.4. Power Consumption Issues . . . . . . . . . . . . 109 9.3.2.4. Power Consumption Issues . . . . . . . . . . . . 109
9.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 109 9.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 109
9.3.4. Which interfaces to auto-enable? . . . . . . . . . . 109 9.3.4. Which interfaces to auto-enable? . . . . . . . . . . 109
9.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . . 111 9.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . . 111
9.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 111 9.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 111
9.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 112 9.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 112
9.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 113 9.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 113
9.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 113 9.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 113
9.4. Partial or Incremental adoption . . . . . . . . . . . . . 113 9.4. Partial or Incremental adoption . . . . . . . . . . . . . 114
9.5. Configuration and the ACP (summary) . . . . . . . . . . . 115 9.5. Configuration and the ACP (summary) . . . . . . . . . . . 115
10. Summary: Benefits (Informative) . . . . . . . . . . . . . . . 116 10. Summary: Benefits (Informative) . . . . . . . . . . . . . . . 116
10.1. Self-Healing Properties . . . . . . . . . . . . . . . . 116 10.1. Self-Healing Properties . . . . . . . . . . . . . . . . 116
10.2. Self-Protection Properties . . . . . . . . . . . . . . . 117 10.2. Self-Protection Properties . . . . . . . . . . . . . . . 118
10.2.1. From the outside . . . . . . . . . . . . . . . . . . 117 10.2.1. From the outside . . . . . . . . . . . . . . . . . . 118
10.2.2. From the inside . . . . . . . . . . . . . . . . . . 119 10.2.2. From the inside . . . . . . . . . . . . . . . . . . 119
10.3. The Administrator View . . . . . . . . . . . . . . . . . 119 10.3. The Administrator View . . . . . . . . . . . . . . . . . 120
11. Security Considerations . . . . . . . . . . . . . . . . . . . 120 11. Security Considerations . . . . . . . . . . . . . . . . . . . 121
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 126
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 126 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 127
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 126 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 127
15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 127 15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 128
15.1. Summary of changes since entering IESG review . . . . . 127 15.1. Summary of changes since entering IESG review . . . . . 128
15.1.1. Reviews (while in IESG review status) / status . . . 127 15.1.1. Reviews (while in IESG review status) / status . . . 128
15.1.2. BRSKI / ACP registrar related enhancements . . . . . 128 15.1.2. BRSKI / ACP registrar related enhancements . . . . . 129
15.1.3. Normative enhancements since start of IESG review . 128 15.1.3. Normative enhancements since start of IESG review . 129
15.1.4. Explanatory enhancements since start of IESG 15.1.4. Explanatory enhancements since start of IESG
review . . . . . . . . . . . . . . . . . . . . . . . 129 review . . . . . . . . . . . . . . . . . . . . . . . 130
15.2. draft-ietf-anima-autonomic-control-plane-29 . . . . . . 130 15.2. draft-ietf-anima-autonomic-control-plane-29 . . . . . . 131
15.3. draft-ietf-anima-autonomic-control-plane-28 . . . . . . 130 15.3. draft-ietf-anima-autonomic-control-plane-28 . . . . . . 132
15.4. draft-ietf-anima-autonomic-control-plane-27 . . . . . . 132 15.4. draft-ietf-anima-autonomic-control-plane-27 . . . . . . 134
15.5. draft-ietf-anima-autonomic-control-plane-26 . . . . . . 132 15.5. draft-ietf-anima-autonomic-control-plane-26 . . . . . . 134
15.6. draft-ietf-anima-autonomic-control-plane-25 . . . . . . 133 15.6. draft-ietf-anima-autonomic-control-plane-25 . . . . . . 135
15.7. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 136 15.7. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 138
15.8. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 136 15.8. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 139
15.9. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 138 15.9. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 140
16. Normative References . . . . . . . . . . . . . . . . . . . . 140 16. Normative References . . . . . . . . . . . . . . . . . . . . 142
17. Informative References . . . . . . . . . . . . . . . . . . . 143 17. Informative References . . . . . . . . . . . . . . . . . . . 145
Appendix A. Background and Futures (Informative) . . . . . . . . 151 Appendix A. Background and Futures (Informative) . . . . . . . . 153
A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 151 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 154
A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 152 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 154
A.3. ACP Neighbor discovery protocol selection . . . . . . . . 153 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 155
A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 153 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 156
A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 154 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 156
A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 154 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 156
A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 154 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 157
A.5. ACP Information Distribution and multicast . . . . . . . 156 A.5. ACP Information Distribution and multicast . . . . . . . 158
A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 157 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 159
A.7. CAs, domains and routing subdomains . . . . . . . . . . . 159 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 161
A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 160 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 162
A.9. Adopting ACP concepts for other environments . . . . . . 161 A.9. Adopting ACP concepts for other environments . . . . . . 163
A.10. Further (future) options . . . . . . . . . . . . . . . . 163 A.10. Further (future) options . . . . . . . . . . . . . . . . 165
A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 163 A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 165
A.10.2. More options for avoiding IPv6 Data-Plane A.10.2. More options for avoiding IPv6 Data-Plane
dependencies . . . . . . . . . . . . . . . . . . . . 163 dependencies . . . . . . . . . . . . . . . . . . . . 165
A.10.3. ACP APIs and operational models (YANG) . . . . . . . 164 A.10.3. ACP APIs and operational models (YANG) . . . . . . . 166
A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 164 A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 166
A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 165 A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 167
A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 165 A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 167
A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 165 A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 167
A.10.8. Avoiding and dealing with compromised ACP nodes . . 166 A.10.8. Avoiding and dealing with compromised ACP nodes . . 168
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 167 A.10.9. Detecting ACP secure channel downgrade attacks . . . 169
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 170
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 6, line 50 skipping to change at page 6, line 50
In increasingly automated networks either centralized management In increasingly automated networks either centralized management
systems or distributed autonomic service agents in the network systems or distributed autonomic service agents in the network
require a control plane which is independent of the configuration of require a control plane which is independent of the configuration of
the network they manage, to avoid impacting their own operations the network they manage, to avoid impacting their own operations
through the configuration actions they take. through the configuration actions they take.
This document describes a modular design for a self-forming, self- This document describes a modular design for a self-forming, self-
managing and self-protecting ACP, which is a virtual out-of-band managing and self-protecting ACP, which is a virtual out-of-band
network designed to be as independent as possible of configuration, network designed to be as independent as possible of configuration,
addressing and routing and similar self-dependency problems in addressing and routing to avoid the self-dependency problems of
current IP networks, but which is still operating in-band on the same current IP networks while still operating in-band on the same
physical network that it is controlling and managing. The ACP design physical network that it is controlling and managing. The ACP design
is therefore intended to combine as good as possible the resilience is therefore intended to combine as good as possible the resilience
of out-of-band management networks with the low-cost of traditional of out-of-band management networks with the low-cost of traditional
IP in-band network management. The details how this is achieved are IP in-band network management. The details how this is achieved are
described in Section 6. described in Section 6.
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 that just a forwarding plane for "Data" IPv6 packets, aka: packets other
are not forwarded by the ACP itself such as control or management than the control and management plane packets that are forwarded by
plane packets. 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 ACPs 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 and management traffic and common control/management protocol session and
presentation functions. presentation functions.
skipping to change at page 9, line 40 skipping to change at page 9, line 40
and confidentiality mechanism used by the ACP is defined to be and confidentiality mechanism used by the ACP is defined to be
negotiable, therefore it can be extended to environments with negotiable, therefore it can be extended to environments with
different protocol preferences. The minimum implementation different protocol preferences. The minimum implementation
requirements in this document attempt to achieve maximum requirements in this document attempt to achieve maximum
interoperability by requiring support for multiple options depending interoperability by requiring support for multiple options depending
on the type of device: IPsec, see [RFC4301], and datagram Transport on the type of device: IPsec, see [RFC4301], and datagram Transport
Layer Security (DTLS) version 1.2, see [RFC6347]). Layer Security (DTLS) version 1.2, see [RFC6347]).
The implementation footprint of the ACP consists of Public Key The implementation footprint of the ACP consists of Public Key
Infrastructure (PKI) code for the ACP certificate, the GRASP Infrastructure (PKI) code for the ACP certificate, the GRASP
protocol, UDP, TCP and TLS 1.2 ([RFC5246], for security and protocol, UDP, TCP and TLS ([RFC5246] [RFC8446], for security and
reliability of GRASP), the ACP secure channel protocol used (such as reliability of GRASP), the ACP secure channel protocol used (such as
IPsec or DTLS), and an instance of IPv6 packet forwarding and routing IPsec or DTLS), and an instance of IPv6 packet forwarding and routing
via the Routing Protocol for Low-power and Lossy Networks (RPL), see via the Routing Protocol for Low-power and Lossy Networks (RPL), see
[RFC6550], that is separate from routing and forwarding for the Data- [RFC6550], that is separate from routing and forwarding for the Data-
Plane (user traffic). Plane (user traffic).
The ACP uses only IPv6 to avoid complexity of dual-stack ACP The ACP uses only IPv6 to avoid complexity of dual-stack ACP
operations (IPv6/IPv4). Nevertheless, it can without any changes be operations (IPv6/IPv4). Nevertheless, it can without any changes be
integrated into even otherwise IPv4-only network devices. The Data- integrated into even otherwise IPv4-only network devices. The Data-
Plane itself would not need to change, it could continue to be IPv4 Plane itself would not need to change, it could continue to be IPv4
skipping to change at page 20, line 34 skipping to change at page 20, line 34
result in one adjacency per interface. If the ACP node has result in one adjacency per interface. If the ACP node has
multiple interfaces connecting to the same subnet across which it multiple interfaces connecting to the same subnet across which it
is also operating as an L2 switch in the Data-Plane, it employs is also operating as an L2 switch in the Data-Plane, it employs
methods for ACP with L2 switching, see Section 7. methods for ACP with L2 switching, see Section 7.
4. For each entry in the candidate adjacency list, the node 4. For each entry in the candidate adjacency list, the node
negotiates a secure tunnel using the candidate channel types. negotiates a secure tunnel using the candidate channel types.
See Section 6.5. See Section 6.5.
5. The node authenticates the peer node during secure channel setup 5. The node authenticates the peer node during secure channel setup
and authorizes it to become part of the ACP according to and authorizes it to become part of the ACP according to
Section 6.1.3. Section 6.1.3.
6. Each successfully established secure channel is mapped into an 6. Unsuccessful authentication of a candidate peer results in
throttled connection retries for as long as the candidate peer is
discoverable. See Section 6.6.
7. Each successfully established secure channel is mapped into an
ACP virtual interface, which is placed into the ACP VRF. See ACP virtual interface, which is placed into the ACP VRF. See
Section 6.12.5.2. Section 6.12.5.2.
7. Each node runs a lightweight routing protocol, see Section 6.11, 8. Each node runs a lightweight routing protocol, see Section 6.11,
to announce reachability of the ACP loopback address (or prefix) to announce reachability of the ACP loopback address (or prefix)
across the ACP. across the ACP.
8. This completes the creation of the ACP with hop-by-hop secure 9. This completes the creation of the ACP with hop-by-hop secure
tunnels, auto-addressing and auto-routing. The node is now an tunnels, auto-addressing and auto-routing. The node is now an
ACP node with a running ACP. ACP node with a running ACP.
Note: Note:
* None of the above operations (except the following explicit * None of the above operations (except the following explicit
configured ones) are reflected in the configuration of the node. configured ones) are reflected in the configuration of the node.
* Non-ACP NMS ("Network Management Systems") or SDN controllers have * Non-ACP NMS ("Network Management Systems") or SDN controllers have
to be explicitly configured for connection into the ACP. to be explicitly configured for connection into the ACP.
* Additional candidate peer adjacencies for ACP connections across * Additional candidate peer adjacencies for ACP connections across
non-ACP Layer-3 clouds requires explicit configuration. See non-ACP Layer-3 clouds requires explicit configuration. See
Section 8.2. Section 8.2.
The following figure illustrates the ACP. The following figure illustrates the ACP.
ACP node 1 ACP node 2 ACP node 1 ACP node 2
................... ................... ................... ...................
secure . . secure . . secure secure . . secure . . secure
channel: +-----------+ : channel : +-----------+ : channel channel: +-----------+ : channel : +-----------+ : channel
skipping to change at page 23, line 43 skipping to change at page 23, line 43
in this section) with RSA public keys and certificates with Elliptic in this section) with RSA public keys and certificates with Elliptic
Curve (ECC) public keys. Curve (ECC) public keys.
ACP nodes MUST NOT support certificates with RSA public keys of less ACP nodes MUST NOT support certificates with RSA public keys of less
than 2048 bit modulus or curves with group order of less than 256 than 2048 bit modulus or curves with group order of less than 256
bit. They MUST support certificates with RSA public keys with 2048 bit. They MUST support certificates with RSA public keys with 2048
bit modulus and MAY support longer RSA keys. They MUST support bit modulus and MAY support longer RSA keys. They MUST support
certificates with ECC public keys using NIST P-256 curves and SHOULD certificates with ECC public keys using NIST P-256 curves and SHOULD
support P-384 and P-521 curves. support P-384 and P-521 curves.
ACP nodes MUST support SHA-256 and SHOULD support SHA-384, SHA-512 ACP nodes MUST NOT support certificates with RSA public keys whose
signatures for certificates with RSA key and the same RSA signatures modulus is less than 2048 bits, or certificates whose ECC public keys
plus ECDSA signatures for certificates with ECC key. are in groups whose order is less than 256 bits. RSA signing
certificates with 2048-bit public keys MUST be supported, and such
certificates with longer public keys MAY be supported. ECDSA
certificates using the NIST P-256 curve MUST be supported, and such
certificates using the P-384 and P-521 curves SHOULD be supported.
ACP nodes MUST support RSA certificates that are signed by RSA
signatures over the SHA-256 digest of the contents, and SHOULD
additionally support SHA-384 and SHA-512 digests in such signatures.
The same requirements for certificate signatures apply to ECDSA
certificates, and additionally, ACP nodes MUST support ECDSA
signatures on ECDSA certificates.
The ACP certificate SHOULD use an RSA key and an RSA signature when The ACP certificate SHOULD use an RSA key and an RSA signature when
the ACP certificate is intended to be used not only for ACP the ACP certificate is intended to be used not only for ACP
authentication but also for other purposes. The ACP certificate MAY authentication but also for other purposes. The ACP certificate MAY
use an ECC key and an ECDSA signature if the ACP certificate is only use an ECC key and an ECDSA signature if the ACP certificate is only
used for ACP and ANI authentication and authorization. used for ACP and ANI authentication and authorization.
Any secure channel protocols used for the ACP as specified in this Any secure channel protocols used for the ACP as specified in this
document or extensions of this document MUST therefore support document or extensions of this document MUST therefore support
authentication (e.g.:signing) starting with these type of authentication (e.g.:signing) starting with these type of
skipping to change at page 24, line 22 skipping to change at page 24, line 35
equivalent security at (logarithmically) shorter key lengths (see equivalent security at (logarithmically) shorter key lengths (see
[RFC4492]). This can be beneficial especially in the presence of [RFC4492]). This can be beneficial especially in the presence of
constrained bandwidth or constrained nodes in an ACP/ANI network. constrained bandwidth or constrained nodes in an ACP/ANI network.
Some ACP functions such as GRASP peer-2-peer across the ACP require Some ACP functions such as GRASP peer-2-peer across the ACP require
end-to-end/any-to-any authentication/authorization, therefore ECC can end-to-end/any-to-any authentication/authorization, therefore ECC can
only reliably be used in the ACP when it MUST be supported on all ACP only reliably be used in the ACP when it MUST be supported on all ACP
nodes. RSA signatures are mandatory to be supported also for ECC nodes. RSA signatures are mandatory to be supported also for ECC
certificates because CAs themselves may not support ECC yet. certificates because CAs themselves may not support ECC yet.
The ACP certificate SHOULD be used for any authentication between The ACP certificate SHOULD be used for any authentication between
nodes with ACP domain certificates (ACP nodes and NOC nodes) where nodes with ACP domain certificates (ACP nodes and NOC nodes) where a
the required authorization condition is ACP domain membership, such required authorization condition is ACP domain membership, such as
as ACP node to NOC/OAM end-to-end security and ASA to ASA end-to-end ACP node to NOC/OAM end-to-end security and ASA to ASA end-to-end
security. Section 6.1.3 defines this "ACP domain membership check". security. Section 6.1.3 defines this "ACP domain membership check".
The uses of this check that are standardized in this document are for The uses of this check that are standardized in this document are for
the establishment of hop-by-hop ACP secure channels (Section 6.6) and the establishment of hop-by-hop ACP secure channels (Section 6.6) and
for ACP GRASP (Section 6.8.2) end-to-end via TLS 1.2 ([RFC5246]). for ACP GRASP (Section 6.8.2) end-to-end via TLS 1.2 ([RFC5246]).
The ACP domain membership check requires a minimum amount of elements The ACP domain membership check requires a minimum amount of elements
in a certificate as described in Section 6.1.3. The identity of a in a certificate as described in Section 6.1.3. The identity of a
node in the ACP is carried via the acp-node-name as defined in node in the ACP is carried via the acp-node-name as defined in
Section 6.1.2. Section 6.1.2.
In support of ECDH key establishment, ACP certificates with ECC keys In support of ECDH key establishment, ACP certificates with ECC keys
MUST indicate to be Elliptic Curve Diffie-Hellman capable (ECDH) if MUST indicate to be Elliptic Curve Diffie-Hellman capable (ECDH): If
X.509 v3 keyUsage and extendedKeyUsage are included in the the X.509v3 keyUsage extension is present, the keyAgreement bit MUST
certificate. be set.
Any other field of the ACP certificate is to be populated as required Any other fields of the ACP certificate are to be populated as
by [RFC5280] or desired by the operator of the ACP domain ACP required by [RFC5280]: As long as they are compliant with [RFC5280],
registrars/CA and required by other purposes that the ACP certificate any other field of an ACP certificate can be set as desired by the
is intended to be used for. operator of the ACP domain through appropriate ACP registrar/ACP CA
procedures. For example, other fields may be required for other
purposes that the ACP certificate is intended to be used for (such as
elements of a SubjectName).
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 "serialNumber" (see into the ACP certificate, such as the [X.520], section 6.2.9
[I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1). This can be "serialNumber" attribute in the subjects field distinguished name
done for example if it would be acceptable for the devices encoding. Note that this is not the certificate serial number. See
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
"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
ACP or autonomic networks using the ACP to just the ACP domain ACP or autonomic networks using the ACP to just the ACP domain
membership check as defined in this document. It can be extended or membership check as defined in this document. It can be extended or
modified with future requirements. Such future authorizations can modified with additional requirements. Such future authorizations
use and require additional elements in certificates or policies or can use and require additional elements in certificates or policies
even additional certificates. For an example, see Appendix A.10.5. or even additional certificates. See the additional check agagainst
the id-kp-cmcRA [RFC6402] extended key usage attribute
(Section 6.1.5) and for possible future extensions, see
Appendix A.10.5.
6.1.2. ACP Certificate AcpNodeName 6.1.2. ACP Certificate AcpNodeName
acp-node-name = local-part "@" acp-domain-name acp-node-name = local-part "@" acp-domain-name
local-part = [ acp-address ] [ "+" rsub extensions ] local-part = [ acp-address ] [ "+" rsub extensions ]
HEXLC = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" acp-address = 32HEXDIG | "0" ; HEXDIG as of RFC5234 section B.1
; DIGIT as of RFC5234 section B.1
acp-address = 32HEXLC | "0"
rsub = [ <subdomain> ] ; <subdomain> as of RFC1034, section 3.5 rsub = [ <subdomain> ] ; <subdomain> as of RFC1034, section 3.5
acp-domain-name = ; <domain> ; as of RFC 1034, section 3.5 acp-domain-name = ; <domain> ; as of RFC 1034, section 3.5
extensions = *( "+" extension ) extensions = *( "+" extension )
extension = ; future standard definition. extension = 1*etext ; future standard definition.
; Must fit RFC5322 simple dot-atom format. etext = ALPHA / DIGIT / ; Printable US-ASCII
"!" / "#" / "$" / "%" / "&" / "'" /
"*" / "-" / "/" / "=" / "?" / "^" /
"_" / "`" / "{" / "|" / "}" / "~"
routing-subdomain = [ rsub "." ] acp-domain-name routing-subdomain = [ rsub "." ] acp-domain-name
Example: Example:
given an ACP address of fd89:b714:f3db:0:200:0:6400:0000 given an ACP address of fd89:b714:f3db:0:200:0:6400:0000
and an ACP domain-name of acp.example.com and an ACP domain-name of acp.example.com
and an rsub extenstion of area51.research and an rsub extenstion of area51.research
then this results in: then this results in:
acp-node-name = fd89b714F3db00000200000064000000 acp-node-name = fd89b714f3db00000200000064000000
+area51.research@acp.example.com +area51.research@acp.example.com
acp-domain-name = acp.example.com acp-domain-name = acp.example.com
routing-subdomain = area51.research.acp.example.com routing-subdomain = area51.research.acp.example.com
Figure 2: ACP Node Name ABNF Figure 2: ACP Node Name ABNF
acp-node-name in above Figure 2 is the ABNF ([RFC5234]) definition of acp-node-name in above Figure 2 is the ABNF ([RFC5234]) definition of
the ACP Node Name. An ACP certificate MUST carry this information. the ACP Node Name. An ACP certificate MUST carry this information.
It MUST be encoded as a subjectAltName / otherName / AcpNodeName as It MUST be encoded as a subjectAltName / otherName / AcpNodeName as
described in Section 6.1.2.1. described in Section 6.1.2.1.
Nodes complying with this specification MUST be able to receive their Nodes complying with this specification MUST be able to receive their
ACP address through the domain certificate, in which case their own ACP address through the domain certificate, in which case their own
ACP certificate MUST have a 32HEXLC "acp-address" field. Nodes ACP certificate MUST have a 32HEXDIG acp-address field. Acp-address
complying with this specification MUST also be able to authenticate is case insensitive because ABNF HEXDIG is. It is recommended to
nodes as ACP domain members or ACP secure channel peers when they encode acp-address with lower case letters. Nodes complying with
have a 0-value acp-address field and as ACP domain members (but not this specification MUST also be able to authenticate nodes as ACP
as ACP secure channel peers) when they have an empty acp-address domain members or ACP secure channel peers when they have a 0-value
field. See Section 6.1.3. acp-address field and as ACP domain members (but not as ACP secure
channel peers) when the acp-address field is omitted from their
AcpNodeName. See Section 6.1.3.
acp-domain-name is used to indicate the ACP Domain across which ACP acp-domain-name is used to indicate the ACP Domain across which ACP
nodes authenticate and authorize each other, for example to build ACP nodes authenticate and authorize each other, for example to build ACP
secure channels to each other, see Section 6.1.3. acp-domain-name secure channels to each other, see Section 6.1.3. acp-domain-name
SHOULD be the FQDN of an Internet domain owned by the network SHOULD be the FQDN of an Internet domain owned by the network
administration of the ACP and ideally reserved to only be used for administration of the ACP and ideally reserved to only be used for
the ACP. In this specification it serves to be a name for the ACP the ACP. In this specification it serves to be a name for the ACP
that ideally is globally unique. When acp-domain-name is a globally that ideally is globally unique. When acp-domain-name is a globally
unique name, collision of ACP addresses across different ACP domains unique name, collision of ACP addresses across different ACP domains
can only happen due to ULA hash collisions (see Section 6.10.2). can only happen due to ULA hash collisions (see Section 6.10.2).
skipping to change at page 27, line 7 skipping to change at page 27, line 41
The following points explain and justify the encoding choices The following points explain and justify the encoding choices
described: described:
1. Formatting notes: 1. Formatting notes:
1.1 "rsub" needs to be in the "local-part": If the format just 1.1 "rsub" needs to be in the "local-part": If the format just
had routing-subdomain as the domain part of the acp-node- had routing-subdomain as the domain part of the acp-node-
name, rsub and acp-domain-name could not be separated from name, rsub and acp-domain-name could not be separated from
each other to determine in the ACP domain membership check each other to determine in the ACP domain membership check
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 "acp-address" is empty, and "rsub" is empty too, the 1.2 If both "acp-address" and "rsub" are omitted from
"local-part" will have the format ":++extension(s)". The AcpNodeName, the "local-part" will have the format
two plus characters are necessary so the node can "++extension(s)". The two plus characters are necessary so
unambiguously parse that both "acp-address" and "rsub" are the node can unambiguously parse that both "acp-address" and
empty. "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 nodes 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 27, line 30 skipping to change at page 28, line 17
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
this format (standard string encoding) for operator this format (standard string encoding) for operator
consumption. consumption.
2.4 Addresses of the form <local><@domain> have become the 2.4 Addresses of the form <local>@<domain> have become the
preferred format for identifiers of entities in many preferred format for identifiers of entities in many
systems, including the majority of user identification in systems, including the majority of user identification in
web or mobile applications such as multi-domain single-sign- web or mobile applications such as multi-domain single-sign-
on systems. on systems.
3. Compatibilities: 3. Compatibilities:
3.1 It should be possible to use the ACP certificate as an 3.1 It should be possible to use the ACP certificate as an
LDevID certificate on the system for other uses beside the LDevID certificate on the system for other uses beside the
ACP. Therefore, the information element required for the ACP. Therefore, the information element required for the
ACP should be encoded so that it minimizes the possibility ACP should be encoded so that it minimizes the possibility
of creating incompatibilities with such other uses. The of creating incompatibilities with such other uses. The
subjectName is for example often used as an entity attributes of the subject field for example are often used
identifier in non-ACP uses of a the ACP certificate. in non-ACP applications and should therefore not be occupied
by new ACP values.
3.2 The element should not require additional ASN.1 en/decoding, 3.2 The element should not require additional ASN.1 en/decoding,
because libraries to access certificate information because libraries to access certificate information
especially for embedded devices may not support extended especially for embedded devices may not support extended
ASN.1 decoding beyond predefined, mandatory fields. ASN.1 decoding beyond predefined, mandatory fields.
subjectAltName / otherName is already used with a single subjectAltName / otherName is already used with a single
string parameter for several otherNames (see [RFC3920], string parameter for several otherNames (see [RFC3920],
[RFC7585], [RFC4985], [RFC8398]). [RFC7585], [RFC4985], [RFC8398]).
3.3 The element required for the ACP should minimize the risk of 3.3 The element required for the ACP should minimize the risk of
being misinterpreted by other uses of the LDevID being misinterpreted by other uses of the LDevID
certificate. It also must not be misinterpreted to actually certificate. It also must not be misinterpreted to actually
be an email address, hence the use of the otherName / be an email address, hence the use of the otherName /
rfc822Name option in the certificate would be inappropriate. rfc822Name option in the certificate would be inappropriate.
See section 4.2.1.6 of [RFC5280] for details on the subjectAltName See section 4.2.1.6 of [RFC5280] for details on the subjectAltName
field. field.
6.1.2.1. AcpNodeName ASN.1 Module 6.1.2.1. AcpNodeName ASN.1 Module
skipping to change at page 30, line 10 skipping to change at page 30, line 10
1: The peer has proved ownership of the private key associated with 1: The peer has proved ownership of the private key associated with
the certificate's public key. This check is performed by the the certificate's public key. This check is performed by the
security association protocol used, for example [RFC7296], section security association protocol used, for example [RFC7296], section
2.15. 2.15.
2: The peer's certificate passes certificate path validation as 2: The peer's certificate passes certificate path validation as
defined in [RFC5280], section 6 against one of the TA associated defined in [RFC5280], section 6 against one of the TA associated
with the ACP node's ACP certificate (see Section 6.1.4 below). with the ACP node's ACP certificate (see Section 6.1.4 below).
This includes verification of the validity (lifetime) of the This includes verification of the validity (lifetime) of the
certificates in the path. certificates in the path.
3: If the node certificate indicates a Certificate Revocation List 3: If the peer's certificate indicates a Certificate Revocation List
(CRL) Distribution Point (CRLDP) ([RFC5280], section 4.2.1.13) or (CRL) Distribution Point (CRLDP) ([RFC5280], section 4.2.1.13) or
Online Certificate Status Protocol (OCSP) responder ([RFC5280], Online Certificate Status Protocol (OCSP) responder ([RFC5280],
section 4.2.2.1), then the peer's certificate MUST be valid section 4.2.2.1), then the peer's certificate MUST be valid
according to those mechanisms when they are available: An OCSP according to those mechanisms when they are available: An OCSP
check for the peer's certificate across the ACP must succeed or check for the peer's certificate across the ACP must succeed or
the peer certificate must not be listed in the CRL retrieved from the peer certificate must not be listed in the CRL retrieved from
the CRLDP. These mechanisms are not available when the node has the CRLDP. These mechanisms are not available when the ACP node
no ACP or non-ACP connectivity to retrieve a current CRL or access has no ACP or non-ACP connectivity to retrieve a current CRL or
an OCSP responder and the security association protocol itself has access an OCSP responder and the security association protocol
also no way to communicate CRL or OCSP check. itself has also no way to communicate CRL or OCSP check.
Retries to learn revocation via OCSP/CRL SHOULD be made using the Retries to learn revocation via OCSP/CRL SHOULD be made using the
same backoff as described in Section 6.6. If and when the ACP same backoff as described in Section 6.6. If and when the ACP
node then learns that an ACP peer's certificate is invalid for node then learns that an ACP peer's certificate is invalid for
which rule 3 had to be skipped during ACP secure channel which rule 3 had to be skipped during ACP secure channel
establishment, then the ACP secure channel to that peer MUST be establishment, then the ACP secure channel to that peer MUST be
closed even if this peer is the only connectivity to access CRL/ closed even if this peer is the only connectivity to access CRL/
OCSP. This applies (of course) to all ACP secure channels to this OCSP. This applies (of course) to all ACP secure channels to this
peer if there are multiple. The ACP secure channel connection peer if there are multiple. The ACP secure channel connection
MUST be retried periodically to support the case that the neighbor MUST be retried periodically to support the case that the neighbor
acquires a new, valid certificate. acquires a new, valid certificate.
4: The peer's certificate has a syntactically valid acp-node-name 4: The peer's certificate has a syntactically valid acp-node-name
field and the acp-domain-name in that peer's acp-node-name is the field and the acp-domain-name in that peer's acp-node-name is the
same as in this ACP node's certificate (lowercase normalized). same as in this ACP node's certificate (lowercase normalized).
When checking a candidate peer's certificate for the purpose of When checking a candidate peer's certificate for the purpose of
establishing an ACP secure channel, one additional check is establishing an ACP secure channel, one additional check is
performed: performed:
5: The candidate peer certificate's acp-node-name has a non-empty 5: The acp-address field of the candidate peer certificate's
acp-address field (either 32HEXLC or 0, according to Figure 2). AcpNodeName is not omitted but either 32HEXDIG or 0, according to
Figure 2.
Technically, ACP secure channels can only be built with nodes that Technically, ACP secure channels can only be built with nodes that
have an acp-address. Rule 5 ensures that this is taken into account have an acp-address. Rule 5 ensures that this is taken into account
during ACP domain membership check. during ACP domain membership check.
Nodes with an empty acp-address field can only use their ACP domain Nodes with an omitted acp-address field can only use their ACP domain
certificate for non-ACP-secure channel authentication purposes. This certificate for non-ACP-secure channel authentication purposes. This
includes for example NMS type nodes permitted to communicate into the includes for example NMS type nodes permitted to communicate into the
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
skipping to change at page 31, line 22 skipping to change at page 31, line 22
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. Steps 5 and 6 are the equivalent steps. certificate common name. Step 5 is an equivalent step for the
AcpNodeName.
* Step 4 constitutes standard CRL/OCSP checks refined for the case * Step 4 constitutes standard CRL/OCSP checks refined for the case
of missing connectivity and limited functionality security of missing connectivity and limited functionality security
association protocols. association protocols.
* Step 5 checks for the presence of an ACP identity for the peer. * Steps 1...4 authorize to build any secure connection between
* Steps 1...5 authorize to build any secure connection between
members of the same ACP domain except for ACP secure channels. members of the same ACP domain except for ACP secure channels.
* Step 6 is the additional verification of the presence of an ACP * Step 5 is the additional verification of the presence of an ACP
address. address as necessary for ACP secure channels.
* Steps 1...6 authorize to build an ACP secure channel. * Steps 1...5 therefore authorize to build an ACP secure channel.
For brevity, the remainder of this document refers to this process For brevity, the remainder of this document refers to this process
only as authentication instead of as authentication and only as authentication instead of as authentication and
authorization. authorization.
6.1.3.1. Realtime clock and Time Validation 6.1.3.1. Realtime clock and Time Validation
An ACP node with a realtime clock in which it has confidence, MUST An ACP node with a realtime clock in which it has confidence, MUST
check the time stamps when performing ACP domain membership check check the time stamps when performing ACP domain membership check
such as as the certificate validity period in step 1. and the such as as the certificate validity period in step 1. and the
skipping to change at page 32, line 34 skipping to change at page 32, line 34
using the ACP will likeley have the need to know the current time. using the ACP will likeley have the need to know the current time.
For example event logging. For example event logging.
6.1.4. Trust Anchors (TA) 6.1.4. Trust Anchors (TA)
ACP nodes need TA information according to [RFC5280], section 6.1.1 ACP nodes need TA information according to [RFC5280], section 6.1.1
(d), typically in the form of one or more certificate of the TA to (d), typically in the form of one or more certificate of the TA to
perform certificate path validation as required by Section 6.1.3, perform certificate path validation as required by Section 6.1.3,
rule 2. TA information MUST be provisioned to an ACP node (together rule 2. TA information MUST be provisioned to an ACP node (together
with its ACP domain certificate) by an ACP Registrar during initial with its ACP domain certificate) by an ACP Registrar during initial
enrolment of a candidate ACP node. ACP nodes MUST also support enrollment of a candidate ACP node. ACP nodes MUST also support
renewal of TA information via Enrollment over Secure Transport (EST, renewal of TA information via Enrollment over Secure Transport (EST,
see [RFC7030]), as described below in Section 6.1.5. see [RFC7030]), as described below in Section 6.1.5.
The required information about a TA can consist of not only a single, The required information about a TA can consist of not only a single,
but multiple certificates as required for dealing with CA certificate but multiple certificates as required for dealing with CA certificate
renewals as explained in Section 4.4 of CMP ([RFC4210]). renewals as explained in Section 4.4 of CMP ([RFC4210]).
A certificate path is a chain of certificates starting at the ACP A certificate path is a chain of certificates starting at the ACP
certificate (leaf/end-entity) followed by zero or more intermediate certificate (leaf/end-entity) followed by zero or more intermediate
CA certificates and ending with the TA information, which are CA certificates and ending with the TA information, which are
skipping to change at page 34, line 12 skipping to change at page 34, line 12
[I-D.ietf-anima-bootstrapping-keyinfra]) is used, the IPv6 locator of [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the IPv6 locator of
the BRSKI registrar from the BRSKI TLS connection SHOULD be the BRSKI registrar from the BRSKI TLS connection SHOULD be
remembered and used for the next renewal via EST if that registrar remembered and used for the next renewal via EST if that registrar
also announces itself as an EST server via GRASP (see next section) also announces itself as an EST server via GRASP (see next section)
on its ACP address. on its ACP address.
The EST server MUST present a certificate that is passing ACP domain The EST server MUST present a certificate that is passing ACP domain
membership check in its TLS connection setup (Section 6.1.3, rules membership check in its TLS connection setup (Section 6.1.3, rules
1..4, not rule 5 as this is not for an ACP secure channel setup). 1..4, not rule 5 as this is not for an ACP secure channel setup).
The EST server certificate MUST also contain the id-kp-cmcRA The EST server certificate MUST also contain the id-kp-cmcRA
[RFC6402] extended key usage extension and the EST client MUST check [RFC6402] extended key usage attribute and the EST client MUST check
its presence. its presence.
The additional check against the id-kp-cmcRA extended key usage The additional check against the id-kp-cmcRA extended key usage
extension field ensures that clients do not fall prey to an illicit extension field ensures that clients do not fall prey to an illicit
EST server. While such illicit EST servers should not be able to EST server. While such illicit EST servers should not be able to
support certificate signing requests (as they are not able to elicit support certificate signing requests (as they are not able to elicit
a signing response from a valid CA), such an illicit EST server would a signing response from a valid CA), such an illicit EST server would
be able to provide faked CA certificates to EST clients that need to be able to provide faked CA certificates to EST clients that need to
renew their CA certificates when they expire. renew their CA certificates when they expire.
skipping to change at page 34, line 38 skipping to change at page 34, line 38
extended usage extension for themselves. extended usage extension for themselves.
6.1.5.1. GRASP objective for EST server 6.1.5.1. GRASP objective for EST server
ACP nodes that are EST servers MUST announce their service via GRASP ACP nodes that are EST servers MUST announce their service via GRASP
in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp], in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp],
section 2.8.11 for the definition of this message type: section 2.8.11 for the definition of this message type:
Example: Example:
[M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, [M_FLOOD, 12340815, h'fd89b714f3db00002000000640000001', 210000,
[["SRV.est", 4, 255 ], [["SRV.est", 4, 255 ],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fd89b714f3db0000200000064000001', IPPROTO_TCP, 443]] h'fd89b714f3db00002000000640000001', IPPROTO_TCP, 443]]
] ]
Figure 4: GRASP SRV.est example Figure 4: GRASP SRV.est example
The formal definition of the objective in Concise data definition The formal definition of the objective in Concise data definition
language (CDDL) (see [RFC8610]) is as follows: language (CDDL) (see [RFC8610]) is as follows:
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
; see example above and explanation ; see example above and explanation
skipping to change at page 36, line 44 skipping to change at page 36, line 44
It is common to use domain names for CRLDP(s), but there is no It is common to use domain names for CRLDP(s), but there is no
requirement for the ACP to support DNS. Any DNS lookup in the Data- requirement for the ACP to support DNS. Any DNS lookup in the Data-
Plane is not only a possible security issue, but it would also not Plane is not only a possible security issue, but it would also not
indicate whether the resolved address is meant to be reachable across indicate whether the resolved address is meant to be reachable across
the ACP. Therefore, the use of an IPv6 address versus the use of a the ACP. Therefore, the use of an IPv6 address versus the use of a
DNS name doubles as an indicator whether or not to reach the CRLDP DNS name doubles as an indicator whether or not to reach the CRLDP
via the ACP. via the ACP.
A CRLDP can be reachable across the ACP either by running it on a A CRLDP can be reachable across the ACP either by running it on a
node with ACP or by connecting its node via an ACP connect interface node with ACP or by connecting its node via an ACP connect interface
(see Section 8.1). The CRLDP SHOULD use an ACP certificate for its (see Section 8.1).
HTTPs connections. The connecting ACP node SHOULD verify that the
CRLDP certificate used during the HTTPs connection has the same ACP When using a private PKI for ACP certificates, the CRL may be need-
address as indicated in the CRLDP URL of the node's ACP certificate to-know, for example to prohibit insight into the operational
if the CRLDP URL uses an IPv6 address. practices of the domain by tracking the growth of the CRL. In this
case, HTTPS may be chosen to provide confidentiality, especially when
making the CRL available via the Data-Plane. Authentication and
authorization SHOULD use ACP certificates and ACP domain membership
check. The CRLDP MAY omit the CRL verification during authentication
of the peer to permit retrieval of the CRL by an ACP node with
revoked ACP certificate. This can allow for that (ex) ACP node to
quickly discover its ACP certificate revocation. This may violate
the desired need-to-know requirement though. ACP nodes MAY support
CRLDP operations via HTTPS.
6.1.5.4. Lifetimes 6.1.5.4. Lifetimes
Certificate lifetime may be set to shorter lifetimes than customary Certificate lifetime may be set to shorter lifetimes than customary
(1 year) because certificate renewal is fully automated via ACP and (1 year) because certificate renewal is fully automated via ACP and
EST. The primary limiting factor for shorter certificate lifetimes EST. The primary limiting factor for shorter certificate lifetimes
is load on the EST server(s) and CA. It is therefore recommended is load on the EST server(s) and CA. It is therefore recommended
that ACP certificates are managed via a CA chain where the assigning that ACP certificates are managed via a CA chain where the assigning
CA has enough performance to manage short lived certificates. See CA has enough performance to manage short lived certificates. See
also Section 9.2.4 for discussion about an example setup achieving also Section 9.2.4 for discussion about an example setup achieving
skipping to change at page 38, line 17 skipping to change at page 38, line 23
its IDevID certificate as defined in BRSKI during the TLS connection its IDevID certificate as defined in BRSKI during the TLS connection
setup. setup.
Both when the BRSKI connection is attempted with the old ACP Both when the BRSKI connection is attempted with the old ACP
certificate or the IDevID certificate, the re-enrolling candidate ACP certificate or the IDevID certificate, the re-enrolling candidate ACP
node SHOULD authenticate the BRSKI registrar during TLS connection node SHOULD authenticate the BRSKI registrar during TLS connection
setup based on its existing TA certificate chain information setup based on its existing TA certificate chain information
associated with its old ACP certificate. The re-enrolling candidate associated with its old ACP certificate. The re-enrolling candidate
ACP node SHOULD only fall back to requesting a voucher from the BRSKI ACP node SHOULD only fall back to requesting a voucher from the BRSKI
registrar when this authentication fails during TLS connection setup. registrar when this authentication fails during TLS connection setup.
To prohibit attacks that attempt to force the ACP node to forget its
prior (expired) certificate and TA, the ACP node should alternate
between attempting to re-enroll using its old keying material and
attempting to re-enroll with its IDevID and requesting a voucher.
When other mechanisms than BRSKI are used for ACP certificate When other mechanisms than BRSKI are used for ACP certificate
enrollment, the principles of the re-enrolling candidate ACP node are enrollment, the principles of the re-enrolling candidate ACP node are
the same. The re-enrolling candidate ACP node attempts to the same. The re-enrolling candidate ACP node attempts to
authenticate any ACP Registrar peers during re-enrollment protocol/ authenticate any ACP Registrar peers during re-enrollment protocol/
mechanisms via its existing certificate chain/TA information and mechanisms via its existing certificate chain/TA information and
provides its existing ACP certificate and other identification (such provides its existing ACP certificate and other identification (such
as the IDevID certificate) as necessary to the registrar. as the IDevID certificate) as necessary to the registrar.
Maintaining existing TA information is especially important when Maintaining existing TA information is especially important when
enrollment mechanisms are used that unlike BRSKI do not leverage a enrollment mechanisms are used that unlike BRSKI do not leverage a
voucher mechanism to authenticate the ACP registrar and where mechanism (such as the voucher in BRSKI) to authenticate the ACP
therefore the injection of certificate failures could otherwise make registrar and where therefore the injection of certificate failures
the ACP node easily attackable remotely. could otherwise make the ACP node easily attackable remotely by
returning the ACP node to a "duckling" state in which it accepts to
be enrolled by any network it connects to. The (expired) ACP
certificate and ACP TA SHOULD therefore be maintained and used for
re-enrollment until new keying material is enrolled.
When using BRSKI or other protocol/mechanisms supporting vouchers, When using BRSKI or other protocol/mechanisms supporting vouchers,
maintaining existing TA information allows for re-enrollment of maintaining existing TA information allows for re-enrollment of
expired ACP certificates to be more lightweight, especially in expired ACP certificates to be more lightweight, especially in
environments where repeated acquisition of vouchers during the environments where repeated acquisition of vouchers during the
lifetime of ACP nodes may be operationally expensive or otherwise lifetime of ACP nodes may be operationally expensive or otherwise
undesirable. undesirable.
6.1.5.6. Failing Certificates 6.1.5.6. Failing Certificates
skipping to change at page 40, line 34 skipping to change at page 40, line 44
interfaces MUST be limited so that at first only IPv6 StateLess interfaces MUST be limited so that at first only IPv6 StateLess
Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work
and then only the following ACP secure channel setup packets - but and then only the following ACP secure channel setup packets - but
not any other unnecessary traffic (e.g., no other link-local IPv6 not any other unnecessary traffic (e.g., no other link-local IPv6
transport stack responders for example). transport stack responders for example).
Note that the use of the IPv6 link-local multicast address Note that the use of the IPv6 link-local multicast address
(ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener (ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener
Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to
receive packets for that address. Otherwise DULL GRASP could fail to receive packets for that address. Otherwise DULL GRASP could fail to
operate correctly in the presence of MLD snooping, non-ACP enabled L2 operate correctly in the presence of MLD snooping ([RFC4541])
switches ([RFC4541]) - because those would stop forwarding DULL GRASP switches that are not ACP supporting/enabled - because those switches
packets. Switches not supporting MLD snooping simply need to operate would stop forwarding DULL GRASP packets. Switches not supporting
as pure L2 bridges for IPv6 multicast packets for DULL GRASP to work. MLD snooping simply need to operate as pure L2 bridges for IPv6
multicast packets for DULL GRASP to work.
ACP discovery SHOULD NOT be enabled by default on non-native ACP discovery SHOULD NOT be enabled by default on non-native
interfaces. In particular, ACP discovery MUST NOT run inside the ACP interfaces. In particular, ACP discovery MUST NOT run inside the ACP
across ACP virtual interfaces. See Section 9.3 for further, non- across ACP virtual interfaces. See Section 9.3 for further, non-
normative suggestions on how to enable/disable ACP at node and normative suggestions on how to enable/disable ACP at node and
interface level. See Section 8.2.2 for more details about tunnels interface level. See Section 8.2.2 for more details about tunnels
(typical non-native interfaces). See Section 7 for how ACP should be (typical non-native interfaces). See Section 7 for how ACP should be
extended on devices operating (also) as L2 bridges. extended on devices operating (also) as L2 bridges.
Note: If an ACP node also implements BRSKI to enroll its ACP Note: If an ACP node also implements BRSKI to enroll its ACP
skipping to change at page 43, line 10 skipping to change at page 43, line 15
The secure channel methods defined in this document use the The secure channel methods defined in this document use the
objective-values of "IKEv2" and "DTLS". There is no distinction objective-values of "IKEv2" and "DTLS". There is no distinction
between IKEv2 native and GRE-IKEv2 because this is purely negotiated between IKEv2 native and GRE-IKEv2 because this is purely negotiated
via IKEv2. via IKEv2.
A node that supports more than one secure channel protocol method A node that supports more than one secure channel protocol method
needs to flood multiple versions of the "AN_ACP" objective so that needs to flood multiple versions of the "AN_ACP" objective so that
each method can be accompanied by its own locator-option. This can each method can be accompanied by its own locator-option. This can
use a single GRASP M_FLOOD message as shown in Figure 6. use a single GRASP M_FLOOD message as shown in Figure 6.
The use of DULL GRASP primarily serves to discover the link-local
IPv6 address of candidate ACP peers on subnets. The signaling of the
supported secure channel option is primarily for diagnostic purposes,
but it is also necessary for discovery when the protocol has no well-
known transport address, such as in the case of DTLS.
Attackers on a subnet may be able to inject malicious DULL GRASP
messages that are indistinguishable from non-malicious DULL GRASP
messages to create Denial-of-Service (DoS) attacks that force ACP
nodes to attempt many unsuccessful ACP secure channel connections.
When an ACP node sees multiple AN_ACP objectives for the same secure
channel protocol on different transport addresses, it SHOULD prefer
connecting via the well-known transport address if the secure channel
method has one (such as UDP port 500 for IKEv2).
Note that a node serving both as an ACP node and BRSKI Join Proxy may Note that a node serving both as an ACP node and BRSKI Join Proxy may
choose to distribute the "AN_ACP" objective and the respective BRSKI choose to distribute the "AN_ACP" objective and the respective BRSKI
in the same M_FLOOD message, since GRASP allows multiple objectives in the same M_FLOOD message, since GRASP allows multiple objectives
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.2), which then drives the further Adjacency Table (see Section 6.2), which then drives the further
skipping to change at page 44, line 50 skipping to change at page 45, line 18
* An ACP node may choose to attempt to initiate the different * An ACP node may choose to attempt to initiate the different
feasible ACP secure channel protocols it supports according to its feasible ACP secure channel protocols it supports according to its
local policies sequentially or in parallel, but it MUST support local policies sequentially or in parallel, but it MUST support
acting as a responder to all of them in parallel. acting as a responder to all of them in parallel.
* Once the first secure channel protocol succeeds, the two peers * Once the first secure channel protocol succeeds, the two peers
know each other's certificates because they are used by all secure know each other's certificates because they are used by all secure
channel protocols for mutual authentication. The node with the channel protocols for mutual authentication. The node with the
lower Node-ID in the ACP address of its ACP certificate becomes lower Node-ID in the ACP address of its ACP certificate becomes
Bob, the one with the higher Node-ID in the certificate Alice. A Bob, the one with the higher Node-ID in the certificate Alice. A
peer with an empty ACP address field in its ACP certificate peer with an omitted ACP address field in its ACP certificate
becomes Bob (this specification does not define such peers, only becomes Bob (this specification does not define such peers, only
the interoperability with them). the interoperability with them).
* Bob becomes passive, he does not attempt to further initiate ACP * Bob becomes passive, he does not attempt to further initiate ACP
secure channel protocols with Alice and does not consider it to be secure channel protocols with Alice and does not consider it to be
an error when Alice closes secure channels. Alice becomes the an error when Alice closes secure channels. Alice becomes the
active party, continues to attempt setting up secure channel active party, continues to attempt setting up secure channel
protocols with Bob until she arrives at the best one from her view protocols with Bob until she arrives at the best one from her view
that also works with Bob. that also works with Bob.
For example, originally Bob could have been the initiator of one ACP For example, originally Bob could have been the initiator of one ACP
secure channel protocol that Bob prefers and the security association secure channel protocol that Bob prefers and the security association
succeeded. The roles of Bob and Alice are then assigned and the succeeded. The roles of Bob and Alice are then assigned and the
skipping to change at page 47, line 47 skipping to change at page 47, line 47
ACP. Section 6.3 above described how IPv6 subnet adjacent peers are ACP. Section 6.3 above described how IPv6 subnet adjacent peers are
discovered automatically. Section 8.2 describes how non IPv6 subnet discovered automatically. Section 8.2 describes how non IPv6 subnet
adjacent peers can be configured. adjacent peers can be configured.
Section 6.12.5.2 describes how secure channels are mapped to virtual Section 6.12.5.2 describes how secure channels are mapped to virtual
IPv6 subnet interfaces in the ACP. The simple case is to map every IPv6 subnet interfaces in the ACP. The simple case is to map every
ACP secure channel into a separate ACP point-to-point virtual ACP secure channel into a separate ACP point-to-point virtual
interface Section 6.12.5.2.1. When a single subnet has multiple ACP interface Section 6.12.5.2.1. When a single subnet has multiple ACP
peers this results in multiple ACP point-to-point virtual interfaces peers this results in multiple ACP point-to-point virtual interfaces
across that underlying multi-party IPv6 subnet. This can be across that underlying multi-party IPv6 subnet. This can be
optimized with ACP multi-access virtual interfaces Section 6.12.5.2.2 optimized with ACP multi-access virtual interfaces
but the benefits of that optimization may not justify the complexity (Section 6.12.5.2.2) but the benefits of that optimization may not
of that option. justify the complexity of that option.
6.7.1. General considerations 6.7.1. General considerations
Due to Channel Selection (Section 6.5), ACP can support an evolving Due to Channel Selection (Section 6.5), ACP can support an evolving
set of security association protocols and does not require support set of security association protocols and does not require support
for a single network wide MTI. ACP nodes only need to implement for a single network wide MTI. ACP nodes only need to implement
those protocols required to interoperate with their candidate peers, those protocols required to interoperate with their candidate peers,
not with potentially any node in the ACP domain. See Section 6.7.5 not with potentially any node in the ACP domain. See Section 6.7.5
for an example of this. for an example of this.
skipping to change at page 51, line 20 skipping to change at page 51, line 20
AH MUST NOT be used (because it does not provide confidentiality). AH MUST NOT be used (because it does not provide confidentiality).
For the required ESP encryption algorithms in section 5 of [RFC8221] For the required ESP encryption algorithms in section 5 of [RFC8221]
the following guidance applies: the following guidance applies:
* ENCR_NULL AH MUST NOT be used (because it does not provide * ENCR_NULL AH MUST NOT be used (because it does not provide
confidentiality). confidentiality).
* ENCR_AES_GCM_16 is the only MTI ESP encryption algorithm for ACP * ENCR_AES_GCM_16 is the only MTI ESP encryption algorithm for ACP
via IPsec/ESP (it is already listed as MUST in [RFC8221]). via IPsec/ESP (it is already listed as MUST in [RFC8221]).
* ENCR_AES_CBC and ENCR_AES_CCM_8 MAY be supported. If either * ENCR_AES_CBC with AUTH_HMAC_SHA2_256_128 (as the ESP
provides higher performance than ENCR_AES_GCM_16 it SHOULD be authentication algorithm) and ENCR_AES_CCM_8 MAY be supported. If
supported. either provides higher performance than ENCR_AES_GCM_16 it SHOULD
be supported.
* ENCR_CHACHA20_POLY1305 SHOULD be supported at equal or higher * ENCR_CHACHA20_POLY1305 SHOULD be supported at equal or higher
performance than ENCR_AES_GCM_16. If that performance is not performance than ENCR_AES_GCM_16. If that performance is not
feasible, it MAY be supported. feasible, it MAY be supported.
IKEv2 indicates an order for the offered algorithms. The algorithms IKEv2 indicates an order for the offered algorithms. The algorithms
SHOULD be ordered by performance. The first algorithm supported by SHOULD be ordered by performance. The first algorithm supported by
both sides is generally choosen. both sides is generally choosen.
Explanations: Explanations:
* There is no requirement to interoperate with legacy equipment in * There is no requirement to interoperate with legacy equipment in
ACP secure channels, so a single MTI encryption algorithm for ACP secure channels, so a single MTI encryption algorithm for
IPsec in ACP secure channels is sufficient for interoperability IPsec in ACP secure channels is sufficient for interoperability
and allows for the most lightweight implementations. and allows for the most lightweight implementations.
* ENCR_AES_GCM_16 is an authenticated encryption with associated * ENCR_AES_GCM_16 is an authenticated encryption with associated
data (AEAD) cipher mode, so no additional ESP authentication data (AEAD) cipher mode, so no additional ESP authentication
algorithm is needed, simplifying the MTI requirements of IPsec for algorithm is needed, simplifying the MTI requirements of IPsec for
the ACP. the ACP.
* There is no MTI requirement against support of ENCR_AES_CBC * There is no MTI requirement for the support of ENCR_AES_CBC
because ENCR_AES_GCM_16 is assumed to be feasible with less cost/ because ENCR_AES_GCM_16 is assumed to be feasible with less cost/
higher performance in modern devices hardware accelerated higher performance in modern devices hardware accelerated
implementations compared to ENCR-AES_CBC. implementations compared to ENCR-AES_CBC.
* ENCR_CHACHA20_POLY1305 is mandatory in [RFC8221] because of its * ENCR_CHACHA20_POLY1305 is mandatory in [RFC8221] because of its
target use as a fallback algorithm in case weaknesses in AES are target use as a fallback algorithm in case weaknesses in AES are
uncoverered. Unfortunately, there is currently no way to uncoverered. Unfortunately, there is currently no way to
automatically propagate across an ACP a policy to disallow use of automatically propagate across an ACP a policy to disallow use of
AES based algorithms, so this target benefit of AES based algorithms, so this target benefit of
ENCR_CHACHA20_POLY1305 can not fully be adopted yet for the ACP. ENCR_CHACHA20_POLY1305 can not fully be adopted yet for the ACP.
Therefore this algorithm is only recommended. Changing from AES Therefore this algorithm is only recommended. Changing from AES
skipping to change at page 53, line 15 skipping to change at page 53, line 15
Note that with IKEv2, failing authentication will only result in the Note that with IKEv2, failing authentication will only result in the
responder receiving the certificate chain from the initiator, but not responder receiving the certificate chain from the initiator, but not
vice versa. Because ACP secure channel setup is symmetric (see vice versa. Because ACP secure channel setup is symmetric (see
Section 6.6), every non-malicious ACP neighbor will attempt to Section 6.6), every non-malicious ACP neighbor will attempt to
connect as an initiator though, allowing to obtain the diagnostic connect as an initiator though, allowing to obtain the diagnostic
information about the neighbors certificate. information about the neighbors certificate.
In IKEv2, ACP nodes are identified by their ACP address. The In IKEv2, ACP nodes are identified by their ACP address. The
ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST
convey the ACP address. If the peer's ACP certificate includes a convey the ACP address. If the peer's ACP certificate includes a
32HEXLC ACP address in the acp-node-name (not "0" or empty), the 32HEXDIG ACP address in the acp-node-name (not "0" or omitted), the
address in the IKEv2 identification payload MUST match it. See address in the IKEv2 identification payload MUST match it. See
Section 6.1.3 for more information about "0" or empty ACP address Section 6.1.3 for more information about "0" or omitted ACP address
fields in the acp-node-name. fields in the acp-node-name.
IKEv2 authentication MUST use authentication method 14 ("Digital IKEv2 authentication MUST use authentication method 14 ("Digital
Signature") for ACP certificates; this authentication method can be Signature") for ACP certificates; this authentication method can be
used with both RSA and ECDSA certificates, indicated by an ASN.1 used with both RSA and ECDSA certificates, indicated by an ASN.1
object AlgorithmIdentifier. object AlgorithmIdentifier.
The Digital Signature hash SHA2-512 MUST be supported (in addition to The Digital Signature hash SHA2-512 MUST be supported (in addition to
SHA2-256). SHA2-256).
skipping to change at page 54, line 20 skipping to change at page 54, line 20
We define the use of ACP via DTLS in the assumption that it is likely We define the use of ACP via DTLS in the assumption that it is likely
the first transport encryption supported in some classes of the first transport encryption supported in some classes of
constrained devices because DTLS is already used in those devices but constrained devices because DTLS is already used in those devices but
IPsec is not, and code-space may be limited. IPsec is not, and code-space may be limited.
An ACP node announces its ability to support DTLS v1.2 compliant with An ACP node announces its ability to support DTLS v1.2 compliant with
the requirements defined in this document as an ACP secure channel the requirements defined in this document as an ACP secure channel
protocol in GRASP through the "DTLS" objective-value in the "AN_ACP" protocol in GRASP through the "DTLS" objective-value in the "AN_ACP"
objective. objective.
To run ACP via UDP and DTLS v1.2 [RFC6347], a locally assigned UDP To run ACP via UDP and DTLS [RFC6347], a locally assigned UDP port is
port is used that is announced as a parameter in the GRASP AN_ACP used that is announced as a parameter in the GRASP AN_ACP objective
objective to candidate neighbors. This port can also be any newer to candidate neighbors. This port can also be any newer version of
version of DTLS as long as that version can negotiate a DTLS v1.2 DTLS as long as that version can negotiate a DTLS v1.2 connection in
connection in the presence of an DTLS v1.2 only peer. the presence of an DTLS v1.2 only peer.
All ACP nodes supporting DTLS as a secure channel protocol MUST All ACP nodes supporting DTLS as a secure channel protocol MUST
adhere to the DTLS implementation recommendations and security adhere to the DTLS implementation recommendations and security
considerations of BCP 195 [RFC7525] except with respect to the DTLS considerations of BCP 195 [RFC7525] except with respect to the DTLS
version. ACP nodes supporting DTLS MUST support DTLS 1.2. They MUST version. ACP nodes supporting DTLS MUST support DTLS 1.2. They MUST
NOT support older versions of DTLS. Implementation MUST comply with NOT support older versions of DTLS. Implementation MUST comply with
BCP 195, [RFC7525]. BCP 195, [RFC7525].
Unlike for IPsec, no attempts are made to simplify the requirements Unlike for IPsec, no attempts are made to simplify the requirements
of the BCP 195 recommendations because the expectation is that DTLS of the BCP 195 recommendations because the expectation is that DTLS
would be using software-only implementations where the ability to would be using software-only implementations where the ability to
reuse of widely adopted implementations is more important than reuse of widely adopted implementations is more important than
minizing the complexity of a hardware accelerated implementation minizing the complexity of a hardware accelerated implementation
which is known to be important for IPsec. which is known to be important for IPsec.
DTLS v1.3 ([I-D.ietf-tls-dtls13]) is "backward compatible" with DTLS DTLS v1.3 ([I-D.ietf-tls-dtls13]) is "backward compatible" with DTLS
v1.2 (see section 1. of DTLS v1.3): A DTLS implementation supporting v1.2 (see section 1. of DTLS v1.3): A DTLS implementation supporting
both DTLS v1.2 and DTLS v1.3 does comply with the above requirements both DTLS v1.2 and DTLS v1.3 does comply with the above requirements
of negoting to DTLS v1.2 in the presence of a DTLS v1.2 only peer, of negotiating to DTLS v1.2 in the presence of a DTLS v1.2 only peer,
but using DTLS v1.3 when booth peers support it. but using DTLS v1.3 when booth peers support it.
Version v1.2 is the MTI version of DTLS in this specification because Version v1.2 is the MTI version of DTLS in this specification because
* There is more experience with DTLS v1.2 across the spectrum of * There is more experience with DTLS v1.2 across the spectrum of
target ACP nodes. target ACP nodes.
* Firmware of lower end, embedded ACP nodes may not support a newer * Firmware of lower end, embedded ACP nodes may not support a newer
version for a long time. version for a long time.
* There are significant changes of DTLS v1.3, such as a different * There are significant changes of DTLS v1.3, such as a different
skipping to change at page 57, line 50 skipping to change at page 57, line 50
virtual interface (as defined Section 6.12.5) but are sent by the ACP virtual interface (as defined Section 6.12.5) but are sent by the ACP
into an ACP GRASP virtual interface that is constructed from the TCP into an ACP GRASP virtual interface that is constructed from the TCP
connection(s) to the IPv6 link-local neighbor address(es) on the connection(s) to the IPv6 link-local neighbor address(es) on the
underlying ACP virtual interface. If the ACP GRASP virtual interface underlying ACP virtual interface. If the ACP GRASP virtual interface
has two or more neighbors, the GRASP link-local multicast messages has two or more neighbors, the GRASP link-local multicast messages
are replicated to all neighbor TCP connections. are replicated to all neighbor TCP connections.
TLS for GRASP MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS for GRASP MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options
with less than 256 bit symmetric key strength or hash strength of with less than 256 bit symmetric key strength or hash strength of
less han SHA384. TLS for GRASP MUST also include the "Supported less than SHA384. When TLS 1.3 is supported, TLS_AES_256_GCM_SHA384
Elliptic Curves" extension, it MUST support support the NIST P-256 MUST be offered and TLS_CHACHA20_POLY1305_SHA256 MAY be offered. TLS
(secp256r1) and P-384 (secp384r1(24)) curves [RFC4492]. In addition, for GRASP MUST also include the "Supported Elliptic Curves"
GRASP TLS clients SHOULD send an ec_point_formats extension with a extension, it MUST support support the NIST P-256 (secp256r1) and
single element, "uncompressed". For further interoperability P-384 (secp384r1(24)) curves [RFC4492]. In addition, GRASP TLS
clients SHOULD send an ec_point_formats extension with a single
element, "uncompressed". For further interoperability
recommendations, GRASP TLS implementations SHOULD follow [RFC7525]. recommendations, GRASP TLS implementations SHOULD follow [RFC7525].
TCP and TLS connections for GRASP in the ACP use the IANA assigned TCP and TLS connections for GRASP in the ACP use the IANA assigned
TCP port for GRASP (7107). Effectively the transport stack is TCP port for GRASP (7107). Effectively the transport stack is
expected to be TLS for connections from/to the ACP address (e.g., expected to be TLS for connections from/to the ACP address (e.g.,
global scope address(es)) and TCP for connections from/to link-local global scope address(es)) and TCP for connections from/to link-local
addresses on the ACP virtual interfaces. The latter ones are only addresses on the ACP virtual interfaces. The latter ones are only
used for flooding of GRASP messages. used for flooding of GRASP messages.
..............................ACP.............................. ..............................ACP..............................
skipping to change at page 60, line 26 skipping to change at page 60, line 26
elimination by GRASP. elimination by GRASP.
TLS is mandated for GRASP non-link-local unicast because the ACP TLS is mandated for GRASP non-link-local unicast because the ACP
secure channel mandatory authentication and encryption protects only secure channel mandatory authentication and encryption protects only
against attacks from the outside but not against attacks from the against attacks from the outside but not against attacks from the
inside: Compromised ACP members that have (not yet) been detected and inside: Compromised ACP members that have (not yet) been detected and
removed (e.g., via domain certificate revocation / expiry). removed (e.g., via domain certificate revocation / expiry).
If GRASP peer connections were to use just TCP, compromised ACP If GRASP peer connections were to use just TCP, compromised ACP
members could simply eavesdrop passively on GRASP peer connections members could simply eavesdrop passively on GRASP peer connections
for whom they are on-path ("Man In The Middle" - MITM) or intercept for whom they are on-path ("man in the middle" - MITM) or intercept
and modify them. With TLS, it is not possible to completely and modify them. With TLS, it is not possible to completely
eliminate problems with compromised ACP members, but attacks are a eliminate problems with compromised ACP members, but attacks are a
lot more complex: lot more complex:
Eavesdropping/spoofing by a compromised ACP node is still possible Eavesdropping/spoofing by a compromised ACP node is still possible
because in the model of the ACP and GRASP, the provider and consumer because in the model of the ACP and GRASP, the provider and consumer
of an objective have initially no unique information (such as an of an objective have initially no unique information (such as an
identity) about the other side which would allow them to distinguish identity) about the other side which would allow them to distinguish
a benevolent from a compromised peer. The compromised ACP node would a benevolent from a compromised peer. The compromised ACP node would
simply announce the objective as well, potentially filter the simply announce the objective as well, potentially filter the
skipping to change at page 67, line 17 skipping to change at page 67, line 17
scheme and therefore allowing for the Vlong scheme (described below) scheme and therefore allowing for the Vlong scheme (described below)
to have one more bit available. to have one more bit available.
Manual addressing sub-scheme addresses SHOULD NOT be used in ACP Manual addressing sub-scheme addresses SHOULD NOT be used in ACP
certificates. Any node capable to build ACP secure channels and certificates. Any node capable to build ACP secure channels and
permitted by Registrar policy to participate in building ACP secure permitted by Registrar policy to participate in building ACP secure
channels SHOULD receive an ACP address (prefix) from one of the other channels SHOULD receive an ACP address (prefix) from one of the other
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 include setting up an ACP secure channel. Their ACP certificate MUST omit
an empty acp-address 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.
6.10.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP-VLong-16 6.10.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
skipping to change at page 69, line 33 skipping to change at page 69, line 33
certificates for ACP nodes from a Certification Authority through any certificates for ACP nodes from a Certification Authority through any
appropriate mechanism (out of scope in this document, but required to appropriate mechanism (out of scope in this document, but required to
be BRSKI for ANI registrars). Only nodes that are trusted to be be BRSKI for ANI registrars). Only nodes that are trusted to be
compliant with the requirements against registrar described in this compliant with the requirements against registrar described in this
section can be given the necessary credentials to perform this RA section can be given the necessary credentials to perform this RA
function, such as credentials for the BRSKI connection to the CA for function, such as credentials for the BRSKI connection to the CA for
ANI registrars. ANI registrars.
6.10.7.1. Use of BRSKI or other Mechanism/Protocols 6.10.7.1. Use of BRSKI or other Mechanism/Protocols
Any protocols or mechanisms may be used as ACP registrars, as long as Any protocols or mechanisms may be used by ACP registrars, as long as
the resulting ACP certificate and TA certificate(s) allow to perform the resulting ACP certificate and TA certificate(s) allow to perform
the ACP domain membership described in Section 6.1.3 with other ACP the ACP domain membership described in Section 6.1.3 with other ACP
domain members, and meet the ACP addressing requirements for its acp- domain members, and meet the ACP addressing requirements for its acp-
node-name as described further below in this section. node-name as described further below in this section.
An ACP registrar could be a person deciding whether to enroll a An ACP registrar could be a person deciding whether to enroll a
candidate ACP node and then orchestrating the enrollment of the ACP candidate ACP node and then orchestrating the enrollment of the ACP
certificate and associated TA, using command line or web based certificate and associated TA, using command line or web based
commands on the candidate ACP node and TA to generate and sign the commands on the candidate ACP node and TA to generate and sign the
ACP certificate and configure certificate and TA onto the node. ACP certificate and configure certificate and TA onto the node.
skipping to change at page 71, line 18 skipping to change at page 71, line 18
in the prefix are for other uses by the ACP node as described in the in the prefix are for other uses by the ACP node as described in the
zone and Vlong addressing sub scheme sections. The ACP address zone and Vlong addressing sub scheme sections. The ACP address
prefix itself is then signaled by the ACP node into the ACP routing prefix itself is then signaled by the ACP node into the ACP routing
protocol (see Section 6.11) to establish IPv6 reachability across the protocol (see Section 6.11) to establish IPv6 reachability across the
ACP. ACP.
The choice of addressing sub-scheme and prefix-length in the Vlong The choice of addressing sub-scheme and prefix-length in the Vlong
address sub-scheme is subject to ACP registrar policy. It could be address sub-scheme is subject to ACP registrar policy. It could be
an ACP domain wide policy, or a per ACP node or per ACP node type an ACP domain wide policy, or a per ACP node or per ACP node type
policy. For example, in BRSKI, the ACP registrar is aware of the policy. For example, in BRSKI, the ACP registrar is aware of the
IDevID certificate of the candidate ACP node, which contains a IDevID certificate of the candidate ACP node, which typically
"serialNnumber" that is typically indicating the node's vendor and contains a "serialNumber" attribute in the subjects field
device type and can be used to drive a policy selecting an distinguished name encoding that is often indicating the node's
vendor and device type and can be used to drive a policy selecting an
appropriate addressing sub-scheme for the (class of) node(s). appropriate addressing sub-scheme for the (class of) node(s).
ACP registrars SHOULD default to allocate ACP zone sub-address scheme ACP registrars SHOULD default to allocate ACP zone sub-address scheme
addresses with Zone-ID 0. addresses with Zone-ID 0.
ACP registrars that are aware of the IDevID certificate of a ACP registrars that are aware of the IDevID certificate of a
candidate ACP device SHOULD be able to choose the zone vs. Vlong sub- candidate ACP device SHOULD be able to choose the zone vs. Vlong sub-
address scheme for ACP nodes based on the "serialNumber" of the address scheme for ACP nodes based on the [X.520] "serialNumber"
attribute in the subjects field distinguished name encoding of the
IDevID certificate, for example by the PID (Product Identifier) part IDevID certificate, for example by the PID (Product Identifier) part
which identifies the product type, or the complete "serialNumber". which identifies the product type, or the complete "serialNumber".
The PID for example could identify nodes that allow for specialized The PID for example could identify nodes that allow for specialized
ASA requiring multiple addresses or non-autonomic VMs for services ASA requiring multiple addresses or non-autonomic VMs for services
and those nodes could receive Vlong sub-address scheme ACP addresses. and those nodes could receive Vlong sub-address scheme ACP addresses.
In a simple allocation scheme, an ACP registrar remembers In a simple allocation scheme, an ACP registrar remembers
persistently across reboots its currently used Registrar-ID and for persistently across reboots its currently used Registrar-ID and for
each addressing scheme (Zone with Zone-ID 0, Vlong with /112, Vlong each addressing scheme (Zone with Zone-ID 0, Vlong with /112, Vlong
with /120), the next Node-Number available for allocation and with /120), the next Node-Number available for allocation and
skipping to change at page 75, line 48 skipping to change at page 76, line 13
catastrophic events (e.g., administrative action). catastrophic events (e.g., administrative action).
Local Repair: As soon as link breakage is detected, send No-Path DAO Local Repair: As soon as link breakage is detected, send No-Path DAO
for all the targets that were reachable only via this link. As soon for all the targets that were reachable only via this link. As soon
as link repair is detected, validate if this link provides you a as link repair is detected, validate if this link provides you a
better parent. If so, compute your new rank, and send new DIO that better parent. If so, compute your new rank, and send new DIO that
advertises your new rank. Then send a DAO with a new path sequence advertises your new rank. Then send a DAO with a new path sequence
about yourself. about yourself.
When using ACP multi-access virtual interfaces, local repair can be When using ACP multi-access virtual interfaces, local repair can be
directly by peer breakage, see Section 6.12.5.2.2. triggered directly by peer breakage, see Section 6.12.5.2.2.
stretch_rank: none provided ("not stretched"). stretch_rank: none provided ("not stretched").
Data Path Validation: Not used. Data Path Validation: Not used.
Trickle: Not used. Trickle: Not used.
6.11.1.8. Multicast 6.11.1.8. Multicast
Not used yet but possible because of the selected mode of operations. Not used yet but possible because of the selected mode of operations.
skipping to change at page 77, line 22 skipping to change at page 77, line 36
6.11.1.14. Unknown Destinations 6.11.1.14. Unknown Destinations
Because RPL minimizes the size of the routing and forwarding table, Because RPL minimizes the size of the routing and forwarding table,
prefixes reachable through the same interface as the RPL root are not prefixes reachable through the same interface as the RPL root are not
known on every ACP node. Therefore traffic to unknown destination known on every ACP node. Therefore traffic to unknown destination
addresses can only be discovered at the RPL root. The RPL root addresses can only be discovered at the RPL root. The RPL root
SHOULD have attach safe mechanisms to operationally discover and log SHOULD have attach safe mechanisms to operationally discover and log
such packets. such packets.
As this requirement raises additional Data-Plane, it does not apply As this requirement places additional constraints on the Data-Plane
to nodes where the administrative parameter to become root functionality of the RPL root, it does not apply to "normal" nodes
(Section 6.11.1.12) can always only be 0b001, e.g.: the node does not that are not configured to have special functionality (i.e., the
support explicit configuration to be root, or to be ACP registrar or adminstrative parameter from Section 6.11.1.12 has value 0b001). If
to have ACP-connect functionality. If an ACP network is degraded to the ACP network is degraded to the point where there are no nodes
the point where there are no nodes that could be configured roots, that could be configured as root, registrar, or ACP-connect nodes, it
ACP registrars or ACP-connect nodes, traffic to unknown destinations is possible that the RPL root ( and thus the ACP as a whole) would be
could not be diagnosed, but in the absence of any intelligent nodes unable to detect traffic to unknown destinations. However, in the
supporting other than 0b001 administrative preference, there is absence of nodes with administrative preference other than 0b001,
likely also no diagnostic function possible. there is also unlikely to be a way to get diagnostic information out
of the ACP, so detection of traffic to unknown destinations would not
be actionable anyway.
6.12. General ACP Considerations 6.12. General ACP Considerations
Since channels are by default established between adjacent neighbors, Since channels are by default established between adjacent neighbors,
the resulting overlay network does hop-by-hop encryption. Each node the resulting overlay network does hop-by-hop encryption. Each node
decrypts incoming traffic from the ACP, and encrypts outgoing traffic decrypts incoming traffic from the ACP, and encrypts outgoing traffic
to its neighbors in the ACP. Routing is discussed in Section 6.11. to its neighbors in the ACP. Routing is discussed in Section 6.11.
6.12.1. Performance 6.12.1. Performance
skipping to change at page 81, line 18 skipping to change at page 81, line 33
[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
unnecessary if those subnets only connect routers, such as ACP unnecessary if those subnets only connect routers, such as ACP
secure channels because they can communicate to remote nodes via secure channels, because they can communicate to remote nodes via
their global scope loopback addresses. Using global scope their global scope loopback addresses. Using global scope
addresses for those extern subnets is therefore wasteful for the addresses for those extern subnets is therefore wasteful for the
address space and also unnecessarily increasing the size of address space and also unnecessarily increasing the size of
routing and forwarding tables, which especially for the ACP is routing and forwarding tables, which especially for the ACP is
highly undesirable because it should attempt to minimize the per- highly undesirable because it should attempt to minimize the per-
node overhead of the ACP VRF. node overhead of the ACP VRF.
9. For all these reasons, the ACP addressing schemes do not consider 9. For all these reasons, the ACP addressing schemes do not consider
ACP addresses for subnets connecting ACP nodes. ACP addresses for subnets connecting ACP nodes.
Note that [RFC8402] introduces the term Node-SID to refer to IGP Note that [RFC8402] introduces the term Node-SID to refer to IGP
skipping to change at page 81, line 42 skipping to change at page 82, line 14
6.12.5.2. ACP virtual interfaces 6.12.5.2. ACP virtual interfaces
Any ACP secure channel to another ACP node is mapped to ACP virtual Any ACP secure channel to another ACP node is mapped to ACP virtual
interfaces in one of the following ways. This is independent of the interfaces in one of the following ways. This is independent of the
chosen secure channel protocol (IPsec, DTLS or other future protocol chosen secure channel protocol (IPsec, DTLS or other future protocol
- standards or non-standards). - standards or non-standards).
Note that all the considerations described here are assuming point- Note that all the considerations described here are assuming point-
to-point secure channel associations. Mapping multi-party secure to-point secure channel associations. Mapping multi-party secure
channel associations such as [RFC6407] is out of scope (but would be channel associations such as [RFC6407] is out of scope.
easy to add).
6.12.5.2.1. ACP point-to-point virtual interfaces 6.12.5.2.1. ACP point-to-point virtual interfaces
In this option, each ACP secure channel is mapped into a separate In this option, each ACP secure channel is mapped into a separate
point-to-point ACP virtual interface. If a physical subnet has more point-to-point ACP virtual interface. If a physical subnet has more
than two ACP capable nodes (in the same domain), this implementation than two ACP capable nodes (in the same domain), this implementation
approach will lead to a full mesh of ACP virtual interfaces between approach will lead to a full mesh of ACP virtual interfaces between
them. them.
When the secure channel protocol determines a peer to be dead, this When the secure channel protocol determines a peer to be dead, this
skipping to change at page 87, line 46 skipping to change at page 88, line 27
explicit configuration. To support connections to adjacent non-ACP explicit configuration. To support connections to adjacent non-ACP
nodes, an ACP node SHOULD support "ACP connect" (sometimes also nodes, an ACP node SHOULD support "ACP connect" (sometimes also
called "autonomic connect"): called "autonomic connect"):
"ACP connect" is an interface level configured workaround for "ACP connect" is an interface level configured workaround for
connection of trusted non-ACP nodes to the ACP. The ACP node on connection of trusted non-ACP nodes to the ACP. The ACP node on
which ACP connect is configured is called an "ACP edge node". With which ACP connect is configured is called an "ACP edge node". With
ACP connect, the ACP is accessible from those non-ACP nodes (such as ACP connect, the ACP is accessible from those non-ACP nodes (such as
NOC systems) on such an interface without those non-ACP nodes having NOC systems) on such an interface without those non-ACP nodes having
to support any ACP discovery or ACP channel setup. This is also to support any ACP discovery or ACP channel setup. This is also
called "native" access to the ACP because to those NOC systems the called "native" access to the ACP (native == without ACP secure
interface looks like a normal network interface (without any channel) because to those NOC systems the interface looks like a
encryption/novel-signaling). normal network interface (without any encryption/novel-signaling).
Data-Plane "native" (no ACP) Data-Plane "native" (no ACP)
. .
+--------+ +----------------+ . +-------------+ +--------+ +----------------+ . +-------------+
| ACP | |ACP Edge Node | . | | | ACP | |ACP Edge Node | . | |
| Node | | | v | | | Node | | | v | |
| |-------|...[ACP VRF]....+----------------| |+ | |-------|...[ACP VRF]....+----------------| |+
| | ^ |. | | NOC Device || | | ^ |. | | NOC Device ||
| | . | .[Data-Plane]..+----------------| "NMS hosts" || | | . | .[Data-Plane]..+----------------| "NMS hosts" ||
| | . | [ ] | . ^ | || | | . | [ ] | . ^ | ||
skipping to change at page 89, line 41 skipping to change at page 90, line 19
through administrative measures. through administrative measures.
To limit the security impact of ACP connect, nodes supporting it To limit the security impact of ACP connect, nodes supporting it
SHOULD implement a security mechanism to allow configuration/use of SHOULD implement a security mechanism to allow configuration/use of
ACP connect interfaces only on nodes explicitly targeted to be ACP connect interfaces only on nodes explicitly targeted to be
deployed with it (those in physically secure locations such as a deployed with it (those in physically secure locations such as a
NOC). For example, the registrar could disable the ability to enable NOC). For example, the registrar could disable the ability to enable
ACP connect on devices during enrollment and that property could only ACP connect on devices during enrollment and that property could only
be changed through re-enrollment. See also Appendix A.10.5. be changed through re-enrollment. See also Appendix A.10.5.
ACP Edge nodes SHOULD have a configurable option to filter packets ACP Edge nodes SHOULD have a configurable option to prohibit packets
with RPI headers (xsee Section 6.11.1.13 across an ACP connect with RPI headers (see Section 6.11.1.13 across an ACP connect
interface. These headers are outside the scope of the RPL profile in interface. These headers are outside the scope of the RPL profile in
this specification but may be used in future extensions of this this specification but may be used in future extensions of this
specification. specification.
8.1.2. Software Components 8.1.2. Software Components
The previous section assumed that ACP Edge node and NOC devices are The previous section assumed that ACP Edge node and NOC devices are
separate physical devices and the ACP connect interface is a physical separate physical devices and the ACP connect interface is a physical
network connection. This section discusses the implication when network connection. This section discusses the implication when
these components are instead software components running on a single these components are instead software components running on a single
skipping to change at page 95, line 47 skipping to change at page 96, line 5
Tunneled Remote ACP Neighbor requires two encapsulations: the Tunneled Remote ACP Neighbor requires two encapsulations: the
configured tunnel and the secure channel inside of that tunnel. This configured tunnel and the secure channel inside of that tunnel. This
makes it in general less desirable than Configured Remote ACP makes it in general less desirable than Configured Remote ACP
Neighbor. Benefits of tunnels are that it may be easier to implement Neighbor. Benefits of tunnels are that it may be easier to implement
because there is no change to the ACP functionality - just running it because there is no change to the ACP functionality - just running it
over a virtual (tunnel) interface instead of only native interfaces. over a virtual (tunnel) interface instead of only native interfaces.
The tunnel itself may also provide PMTUD while the secure channel The tunnel itself may also provide PMTUD while the secure channel
method may not. Or the tunnel mechanism is permitted/possible method may not. Or the tunnel mechanism is permitted/possible
through some firewall while the secure channel method may not. through some firewall while the secure channel method may not.
Tunneling using an insecure tunnel encapsulation increases on average
the risk of a MITM downgrade attack somewhere along the underlay path
that blocks all but the most easily attacked ACP secure channel
option. ACP nodes supporting tunneled remote ACP Neighbors SHOULD
support configuration on such tunnel interfaces to restrict or
explicitly select the available ACP secure channel protocols (if the
ACP node supports more than one ACP secure channel protocol in the
first place).
8.2.3. Summary 8.2.3. Summary
Configured/Tunneled Remote ACP neighbors are less "indestructible" Configured/Tunneled Remote ACP neighbors are less "indestructible"
than L2 adjacent ACP neighbors based on link local addressing, since than L2 adjacent ACP neighbors based on link local addressing, since
they depend on more correct Data-Plane operations, such as routing they depend on more correct Data-Plane operations, such as routing
and global addressing. and global addressing.
Nevertheless, these options may be crucial to incrementally deploy Nevertheless, these options may be crucial to incrementally deploy
the ACP, especially if it is meant to connect islands across the the ACP, especially if it is meant to connect islands across the
Internet. Implementations SHOULD support at least Tunneled Remote Internet. Implementations SHOULD support at least Tunneled Remote
skipping to change at page 101, line 7 skipping to change at page 101, line 18
While the ACP itself is not impact by this, the Data-Plane to be While the ACP itself is not impact by this, the Data-Plane to be
built later may be impacted. Therefore it is important to be able to built later may be impacted. Therefore it is important to be able to
diagnose such undesirable connectivity from the ACP so that any diagnose such undesirable connectivity from the ACP so that any
autonomic or non-autonomic mechanisms to configure the Data-Plane can autonomic or non-autonomic mechanisms to configure the Data-Plane can
accordingly treat such interfaces. The information in the TA of the accordingly treat such interfaces. The information in the TA of the
peer can then ease troubleshooting of such issues. peer can then ease troubleshooting of such issues.
Another example case is the intended or accidental re-activation of Another example case is the intended or accidental re-activation of
equipment whose TA certificate has long expired, such as redundant equipment whose TA certificate has long expired, such as redundant
gear taken from storage after years. Potentially without following gear taken from storage after years.
the correct process set up for such cases.
A third example case is when in a mergers&aquisition case ACP nodes A third example case is when in a mergers&aquisition case ACP nodes
have not been correctly provisioned with the mutual TA of previously have not been correctly provisioned with the mutual TA of previously
disjoint ACP. This is assuming that the ACP domain names where disjoint ACP. This is assuming that the ACP domain names where
already aligned so that the ACP domain membership check is only already aligned so that the ACP domain membership check is only
failing on the TA. failing on the TA.
A fourth example case is when multiple registrars where set up for A fourth example case is when multiple registrars where set up for
the same ACP but without correctly setting up the same TA. For the same ACP but without correctly setting up the same TA. For
example when registrars support to also be CA themselves but are example when registrars support to also be CA themselves but are
skipping to change at page 103, line 4 skipping to change at page 103, line 10
9.2.2. Registrar Parameter 9.2.2. Registrar Parameter
The interactions of an ACP registrar outlined Section 6.10.7 and The interactions of an ACP registrar outlined Section 6.10.7 and
Section 9.2.1 above depend on the following parameters: Section 9.2.1 above depend on the following parameters:
* A URL to the TA and credentials so that the ACP registrar can let * A URL to the TA and credentials so that the ACP registrar can let
the TA sign candidate ACP node certificates. the TA sign candidate ACP node certificates.
* The ACP domain-name. * The ACP domain-name.
* The Registrar-ID to use. This could default to a MAC address of * The Registrar-ID to use. This could default to a MAC address of
the ACP registrar. the ACP registrar.
* For recovery, the next-useable Node-IDs for zone (Zone-ID=0) sub- * For recovery, the next-useable Node-IDs for zone (Zone-ID=0) sub-
addressing scheme, for Vlong /112 and for Vlong /120 sub- addressing scheme, for Vlong /112 and for Vlong /120 sub-
addressing scheme. These IDs would only need to be provisioned addressing scheme. These IDs would only need to be provisioned
after recovering from a crash. Some other mechanism would be after recovering from a crash. Some other mechanism would be
required to remember these IDs in a backup location or to recover required to remember these IDs in a backup location or to recover
them from the set of currently known ACP nodes. them from the set of currently known ACP nodes.
* Policies if candidate ACP nodes should receive a domain * Policies if candidate ACP nodes should receive a domain
certificate or not, for example based on the devices IDevID certificate or not, for example based on the devices IDevID
certificate as in BRSKI. The ACP registrar may have a whitelist certificate as in BRSKI. The ACP registrar may have a whitelist
or blacklist of devices "serialNumbers" from their IDevID or blacklist of devices [X.520] "serialNumbers" attribute in the
subjects field distinguished name encoding from their IDevID
certificate. certificate.
* Policies what type of address prefix to assign to a candidate ACP * Policies what type of address prefix to assign to a candidate ACP
devices, based on likely the same information. devices, based on likely the same information.
* For BRSKI or other mechanisms using vouchers: Parameters to * For BRSKI or other mechanisms using vouchers: Parameters to
determine how to retrieve vouchers for specific type of secure determine how to retrieve vouchers for specific type of secure
bootstrap candidate ACP nodes (such as MASA URLs), unless this bootstrap candidate ACP nodes (such as MASA URLs), unless this
information is automatically learned such as from the IDevID information is automatically learned such as from the IDevID
certificate of candidate ACP nodes (as defined in BRSKI). certificate of candidate ACP nodes (as defined in BRSKI).
9.2.3. Certificate renewal and limitations 9.2.3. Certificate renewal and limitations
skipping to change at page 104, line 46 skipping to change at page 104, line 52
lived and subject to CRL. lived and subject to CRL.
9.2.5. Centralized Policy Control 9.2.5. Centralized Policy Control
When using multiple, uncoordinated ACP registrars, several advanced When using multiple, uncoordinated ACP registrars, several advanced
operations are potentially more complex than with a single, resilient operations are potentially more complex than with a single, resilient
policy control backend, for example including but not limited to: policy control backend, for example including but not limited to:
* Which candidate ACP node is permitted or not permitted into an ACP * Which candidate ACP node is permitted or not permitted into an ACP
domain. This may not be a decision to be taken upfront, so that a domain. This may not be a decision to be taken upfront, so that a
per-"serialNumber" policy can be loaded into every ACP registrar. policy per "serialNumber" attribute in the subjects field
Instead, it may better be decided in real-time including distinguished name encoding can be loaded into every ACP
potentially a human decision in a NOC. registrar. Instead, it may better be decided in real-time
including potentially a human decision in a NOC.
* Tracking of all enrolled ACP nodes and their certificate * Tracking of all enrolled ACP nodes and their certificate
information. For example in support of revoking individual ACP information. For example in support of revoking individual ACP
nodes certificates. nodes certificates.
* More flexible policies what type of address prefix or even what * More flexible policies what type of address prefix or even what
specific address prefix to assign to a candidate ACP node. specific address prefix to assign to a candidate ACP node.
These and other operations could be introduced more easily by These and other operations could be introduced more easily by
introducing a centralized Policy Management System (PMS) and introducing a centralized Policy Management System (PMS) and
modifying ACP registrar behavior so that it queries the PMS for any modifying ACP registrar behavior so that it queries the PMS for any
policy decision occurring during the candidate ACP node enrollment policy decision occurring during the candidate ACP node enrollment
process and/or the ACP node certificate renewal process. For process and/or the ACP node certificate renewal process. For
example, which ACP address prefix to assign. Likewise the ACP example, which ACP address prefix to assign. Likewise the ACP
registrar would report any relevant state change information to the registrar would report any relevant state change information to the
skipping to change at page 112, line 11 skipping to change at page 112, line 11
operator likely never even heard of it could be quite irritating to operator likely never even heard of it could be quite irritating to
the operator. Especially when "down" behavior is changed to "admin the operator. Especially when "down" behavior is changed to "admin
down". down".
Automatically setting "ANI enable" on brownfield nodes where the Automatically setting "ANI enable" on brownfield nodes where the
operator is unaware of BRSKI and MASA operations could also be an operator is unaware of BRSKI and MASA operations could also be an
unlikely but then critical security issue. If an attacker could unlikely but then critical security issue. If an attacker could
impersonate the operator and register as the operator at the MASA or impersonate the operator and register as the operator at the MASA or
otherwise get hold of vouchers and can get enough physical access to otherwise get hold of vouchers and can get enough physical access to
the network so pledges would register to an attacking registrar, then the network so pledges would register to an attacking registrar, then
the attacker could gain access to the network through the ACP that the attacker could gain access to the ACP, and through the ACP gain
the attacker then has access to. access to the Data-Plane.
In networks where the operator explicitly wants to enable the ANI In networks where the operator explicitly wants to enable the ANI
this could not happen, because the operator would create a BRSKI this could not happen, because the operator would create a BRSKI
registrar that would discover attack attempts, and the operator would registrar that would discover attack attempts, and the operator would
be setting up his registrar with the MASA. Nodes requiring be setting up his registrar with the MASA. Nodes requiring
"ownership vouchers" would not be subject to that attack. See "ownership vouchers" would not be subject to that attack. See
[I-D.ietf-anima-bootstrapping-keyinfra] for more details. Note that [I-D.ietf-anima-bootstrapping-keyinfra] for more details. Note that
a global "ACP enable" alone is not subject to these type of attacks, a global "ACP enable" alone is not subject to these type of attacks,
because it always depends on some other mechanism first to provision because it always depends on some other mechanism first to provision
domain certificates into the device. domain certificates into the device.
9.3.5.2. Greenfield nodes 9.3.5.2. Greenfield nodes
A "greenfield" node is one that did not have any prior configuration. An ACP "greenfield" node is one that does not have any prior
configuration and that can be bootstrapped into the ACP across the
network. To support greenfield nodes, ACP as described in this
document needs to be combined with a bootstrap protocol/mechanism
that will enroll the node with the ACP keying material - ACP
certificate and TA. For ANI nodes, this protocol/mechanism is BRSKI.
For greenfield nodes, only "ANI enable" is relevant. If another When such a node is powered on and determines it is in greenfield
mechanism than BRSKI is used to (zero-touch) bootstrap a node, then condition, it enables the bootstrap protocol(s)/mechanism(s), and
it is up to that mechanism to provision domain certificates and to once the ACP keying material is enrolled, greenfield state ends and
set global "ACP enable" as desired. the ACP is started. When BRSKI is used, the node's state reflects
this by setting "ANI enable" upon determination of greenfield state
at power on.
Nodes supporting full ANI functionality set "ANI enable" ACP greenfield nodes that in the absence of ACP would have their
automatically when they decide that they are greenfield, e.g., that interfaces in "down" state SHOULD set all native interfaces into
they are powering on from factory condition. They will then put all "admin down" state and only permit Data-Plane traffic required for
native interfaces into "admin down" state and start to perform BRSKI the bootstrap protocol/mechanisms.
pledge functionality - and once a domain certificate is enrolled they
automatically enable ACP.
Attempts for BRSKI pledge operations in greenfield state should ACP nodes supporting greenfield operations MAY want to provide
terminate automatically when another method of configuring the node backward compatibility with other forms of configuration/
is used. Methods that indicate some form of physical possession of provisioning, especially when only a subset of the nodes are expected
the device such as configuration via the serial console port could to be deployed with ACP. Such an ACP node SHOULD observe attempts to
lead to immediate termination of BRSKI, while other parallel auto provision/configure the node via interfaces/methods that
configuration methods subject to remote attacks might lead to BRSKI traditionally indicate physical possession of the node, such as a
termination only after they were successful. Details of this may serial or USB console port or a USB memory stick with a bootstrap
vary widely over different type of nodes. When BRSKI pledge configuration. When such an operation is observed before enrollment
operation terminates, this will automatically unset "ANI enable" and of the ACP keying material has completed, the node SHOULD put itself
should terminate any temporarily needed state on the device to into the greenfield state the node would have been in, if ACP/ANI was
perform BRSKI - DULL GRASP, BRSKI pledge and any IPv6 configuration disabled at boot.
on interfaces.
When a greenfield node enables multiple enrollment/botstrap
protocols/mechanisms in parallel, care must be taken not to terminate
any protocol/mechanism before another one has progressed to a point
where greenfield state is defined to end.
Nodes that claim to support ANI greenfield operations SHOULD NOT
enable in parallel to BRSKI any enrollment/bootstrap protocol/
mechanism that allows Trust On First Use (TOFU, [RFC7435]) over
interfaces other than those traditionally indicating physical
possession of the node. Protocols/mechanisms with published default
username/password authentication are considered to suffer from TOFU.
Securing the bootstrap protocol/mechanism by requiring a voucher
([RFC8366]) can be used to avoid TOFU.
In summary, the goal of ACP greenfield support is to allow remote
automated enrollment of ACP keying materials, and therefore automated
bootstrap into the ACP and to prohibit TOFU during bootstrap with the
likely exception (for backward compatibility) of bootstrapping via
interfaces traditionally indicating physical possession of the node.
9.3.6. Undoing ANI/ACP enable 9.3.6. Undoing ANI/ACP enable
Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the
reliable operations of the ACP if it can be executed by mistake or reliable operations of the ACP if it can be executed by mistake or
unauthorized. This behavior could be influenced through some unauthorized. This behavior could be influenced through some
additional (future) property in the certificate (e.g., in the acp- additional (future) property in the certificate (e.g., in the acp-
node-name extension field): In an ANI deployment intended for node-name extension field): In an ANI deployment intended for
convenience, disabling it could be allowed without further convenience, disabling it could be allowed without further
constraints. In an ANI deployment considered to be critical more constraints. In an ANI deployment considered to be critical more
skipping to change at page 114, line 32 skipping to change at page 115, line 14
While such a setup is possible with any ACP addressing sub-scheme, While such a setup is possible with any ACP addressing sub-scheme,
the ACP-Zone Addressing sub-scheme makes it easy to configure and the ACP-Zone Addressing sub-scheme makes it easy to configure and
scalable for any VPN routing protocols because every ACP zone would scalable for any VPN routing protocols because every ACP zone would
only need to indicate one or more /64 ACP Zone Addressing prefix only need to indicate one or more /64 ACP Zone Addressing prefix
routes into the ACP-Core VPN as opposed to routes for every routes into the ACP-Core VPN as opposed to routes for every
individual ACP node as required in the other ACP addressing schemes. individual ACP node as required in the other ACP addressing schemes.
Note that the non-autonomous ACP-Core VPN would require additional Note that the non-autonomous ACP-Core VPN would require additional
extensions to propagate GRASP messages when GRASP discovery is extensions to propagate GRASP messages when GRASP discovery is
desired across the zones. For example, one could set up on each Zone desired across the zones.
edge router remote ACP tunnel to an appplication level implemented
GRASP hub running in the networks NOC that is generating GRASP
announcements for NOC services into the ACP Zones or propagating them
between ACP Zones.
Such partial deployment may prove to be sufficient or could evolve to For example, one could set up on each Zone edge router a remote ACP
become more autonomous through future standardized or non- tunnel to a GRASP hub. The GRASP hub could be implemented at the
application level and could run in the NOC of the network. It would
serve to propagage GRASP announcements between ACP Zones and/or
generate GRASP announcements for NOC services.
Such a partial deployment may prove to be sufficient or could evolve
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. nodes ACP certificates are fromm a single ACP.
9.5. Configuration and the ACP (summary) 9.5. Configuration and the ACP (summary)
skipping to change at page 117, line 21 skipping to change at page 118, line 7
partitions will also not cause problems with ACP addresses assigned partitions will also not cause problems with ACP addresses assigned
during partitioning. during partitioning.
After a network partition, a re-merge will just establish the After a network partition, a re-merge will just establish the
previous status, certificates can be renewed, the CRL is available, previous status, certificates can be renewed, the CRL is available,
and new nodes can be enrolled everywhere. Since all nodes use the and new nodes can be enrolled everywhere. Since all nodes use the
same TA, a re-merge will be smooth. same TA, a re-merge will be smooth.
Merging two networks with different TA requires the ACP nodes to Merging two networks with different TA requires the ACP nodes to
trust the union of TA. As long as the routing-subdomain hashes are trust the union of TA. As long as the routing-subdomain hashes are
different, the addressing will not overlap, which only happens in the different, the addressing will not overlap. Accidentally, overlaps
unlikely event of a 40-bit hash collision in SHA256 (see will only happen in the unlikely event of a 40-bit hash collision in
Section 6.10). Note that the complete mechanisms to merge networks SHA256 (see Section 6.10). Note that the complete mechanisms to
is out of scope of this specification. merge networks is out of scope of this specification.
It is also highly desirable for implementation of the ACP to be able It is also highly desirable for implementation of the ACP to be able
to run it over interfaces that are administratively down. If this is to run it over interfaces that are administratively down. If this is
not feasible, then it might instead be possible to request explicit not feasible, then it might instead be possible to request explicit
operator override upon administrative actions that would operator override upon administrative actions that would
administratively bring down an interface across which the ACP is administratively bring down an interface across which the ACP is
running. Especially if bringing down the ACP is known to disconnect running. Especially if bringing down the ACP is known to disconnect
the operator from the node. For example any such down administrative the operator from the node. For example any such down administrative
action could perform a dependency check to see if the transport action could perform a dependency check to see if the transport
connection across which this action is performed is affected by the connection across which this action is performed is affected by the
skipping to change at page 118, line 14 skipping to change at page 119, line 11
can also not decrypt ACP traffic except if they can crack the can also not decrypt ACP traffic except if they can crack the
encryption. They can attempt behavioral traffic analysis on the encryption. They can attempt behavioral traffic analysis on the
encrypted ACP traffic. encrypted ACP traffic.
The degree to which compromised ACP nodes can impact the ACP depends The degree to which compromised ACP nodes can impact the ACP depends
on the implementation of the ACP nodes and their impairment. When an on the implementation of the ACP nodes and their impairment. When an
attacker has only gained administrative privileges to configure ACP attacker has only gained administrative privileges to configure ACP
nodes remotely, the attacker can disrupt the ACP only through one of nodes remotely, the attacker can disrupt the ACP only through one of
the few configuration options to disable it, see Section 9.3, or by the few configuration options to disable it, see Section 9.3, or by
configuring of non-autonomic ACP options if those are supported on configuring of non-autonomic ACP options if those are supported on
the impaired ACP nodes, see Section 8. Injecting or ectracting the impaired ACP nodes, see Section 8. Injecting or extracting
traffic into/from an impaired ACP node is only possible when an traffic into/from an impaired ACP node is only possible when an
impaired ACP node supports ACP connect (see Section 8.1) and the impaired ACP node supports ACP connect (see Section 8.1) and the
attacker can control traffic into/from one of the ACP nodes attacker can control traffic into/from one of the ACP nodes
interfaces, such as by having physical access to the ACP node. interfaces, such as by having physical access to the ACP node.
The ACP also serves as protection (through authentication and The ACP also serves as protection (through authentication and
encryption) for protocols relevant to OAM that may not have secured encryption) for protocols relevant to OAM that may not have secured
protocol stack options or where implementation or deployment of those protocol stack options or where implementation or deployment of those
options fail on some vendor/product/customer limitations. This options fail on some vendor/product/customer limitations. This
includes protocols such as SNMP ([RFC3411]), NTP ([RFC5905]), PTP includes protocols such as SNMP ([RFC3411]), NTP ([RFC5905]), PTP
skipping to change at page 120, line 39 skipping to change at page 121, line 36
* The usage of domain certificates depends on a valid supporting PKI * The usage of domain certificates depends on a valid supporting PKI
infrastructure. If the chain of trust of this PKI infrastructure infrastructure. If the chain of trust of this PKI infrastructure
is compromised, the security of the ACP is also compromised. This is compromised, the security of the ACP is also compromised. This
is typically under the control of the network administrator. is typically under the control of the network administrator.
* ACP nodes receive their certificates from ACP registrars. These * ACP nodes receive their certificates from ACP registrars. These
ACP registrars are security critical dependencies of the ACP: ACP registrars are security critical dependencies of the ACP:
Procedures and protocols for ACP registrars are outside the scope Procedures and protocols for ACP registrars are outside the scope
of this specification as explained in Section 6.10.7.1, only of this specification as explained in Section 6.10.7.1, only
requirements against the resulting ACP certificates are specified. requirements against the resulting ACP certificates are specified.
* Every ACP registrar (for enrolment of ACP certificates) and ACP * Every ACP registrar (for enrollment of ACP certificates) and ACP
EST server (for renewal of ACP certificates) is a security EST server (for renewal of ACP certificates) is a security
critical entity and its protocols are security critical protocols. critical entity and its protocols are security critical protocols.
Both need to be hardened against attacks, similar to a CA and its Both need to be hardened against attacks, similar to a CA and its
protocols. A malicious registrar can enroll malicious nodes to an protocols. A malicious registrar can enroll malicious nodes to an
ACP network (if the CA delegates this policy to the registrar) or ACP network (if the CA delegates this policy to the registrar) or
break ACP routing for example by assigning duplicate ACP address break ACP routing for example by assigning duplicate ACP address
assignment to ACP nodes via their ACP certificates. assignment to ACP nodes via their ACP certificates.
* ACP nodes that are ANI nodes rely on BRSKI as the protocol for ACP * ACP nodes that are ANI nodes rely on BRSKI as the protocol for ACP
registrars. For ANI type ACP nodes, the security considerations registrars. For ANI type ACP nodes, the security considerations
of BRSKI apply. It enables automated, secure enrolment of ACP of BRSKI apply. It enables automated, secure enrollment of ACP
certificates. certificates.
* BRSKI and potentially other ACP registrar protocol options require * BRSKI and potentially other ACP registrar protocol options require
that nodes have an (X.509v3 based) IDevID. IDevIDs are an option that nodes have an (X.509v3 based) IDevID. IDevIDs are an option
for ACP registrars to securely identify candidate ACP nodes that for ACP registrars to securely identify candidate ACP nodes that
should be enrolled into an ACP domain. should be enrolled into an ACP domain.
* For IDevIDs to securely identify the node to which it IDevID is * For IDevIDs to securely identify the node to which it IDevID is
assigned, the node it needs to (1) utilize hardware support such assigned, the node it needs to (1) utilize hardware support such
as a Trusted Platform Module (TPM) to protect against extraction/ as a Trusted Platform Module (TPM) to protect against extraction/
cloning of the private key of the IDevID and (2) a hardware/ cloning of the private key of the IDevID and (2) a hardware/
software infrastructure to prohibit execution of non authenticated software infrastructure to prohibit execution of non authenticated
software to protect against malicious use of the IDevID. software to protect against malicious use of the IDevID.
* Like the IDevID, the ACP certificate should equally be protected * Like the IDevID, the ACP certificate should equally be protected
from extraction or other abuse by the same ACP node from extraction or other abuse by the same ACP node
infrastructure. This infrastructure for IDevID and ACP infrastructure. This infrastructure for IDevID and ACP
certificate is beneficial independent of the ACP registrar certificate is beneficial independent of the ACP registrar
skipping to change at page 121, line 25 skipping to change at page 122, line 21
* Like the IDevID, the ACP certificate should equally be protected * Like the IDevID, the ACP certificate should equally be protected
from extraction or other abuse by the same ACP node from extraction or other abuse by the same ACP node
infrastructure. This infrastructure for IDevID and ACP infrastructure. This infrastructure for IDevID and ACP
certificate is beneficial independent of the ACP registrar certificate is beneficial independent of the ACP registrar
protocol used (BRSKI or other). protocol used (BRSKI or other).
* Renewal of ACP certificates requires support for EST, therefore * Renewal of ACP certificates requires support for EST, therefore
the security considerations of [RFC7030] related to certificate the security considerations of [RFC7030] related to certificate
renewal/rekeying and TP renewal apply to the ACP. EST security renewal/rekeying and TP renewal apply to the ACP. EST security
considerations when using other than mutual certificate considerations when using other than mutual certificate
authentication do not apply nor do considerations for initial authentication do not apply nor do considerations for initial
enrolment via EST apply, except for ANI type ACP nodes because enrollment via EST apply, except for ANI type ACP nodes because
BRSKI leverages EST. BRSKI leverages EST.
* A malicious ACP node could declare itself to be an EST server via * A malicious ACP node could declare itself to be an EST server via
GRASP across the ACP if malicious software could be executed on GRASP across the ACP if malicious software could be executed on
it. CA should therefore authenticate only known trustworthy EST it. CA should therefore authenticate only known trustworthy EST
servers, such as nodes with hardware protections against malicious servers, such as nodes with hardware protections against malicious
software. When Registrars use their ACP certificate to
authenticate towards a CA, the id-kp-cmcRA [RFC6402] extended key
usage attribute allows the CA to determine that the ACP node was
permitted during enrollment to act as an ACP registrar. Without
the ability to talk to the CA, a malicious EST server can still
attract ACP nodes attempting to renew their keying material, but
they will fail to perform successful renewal of a valid ACP
certificate. The ACP node attempting to use the malicious EST
server can then continue to use a different EST server, and log a
failure against a malicious EST server.
* A malicious ACP node could declare itself to be an EST server via
GRASP across the ACP if malicious software could be executed on
it. CA should therefore authenticate only known trustworthy EST
servers, such as nodes with hardware protections against malicious
software. Without the ability to talk to the CA, a malicious EST software. Without the ability to talk to the CA, a malicious EST
server can still attract ACP nodes attempting to renew their server can still attract ACP nodes attempting to renew their
keying material, but they will fail to perform successful renewal keying material, but they will fail to perform successful renewal
of a valid ACP certificate. The ACP node attempting to use the of a valid ACP certificate. The ACP node attempting to use the
malicious EST server can then continue to use a different EST malicious EST server can then continue to use a different EST
server, and log a failure against a malicious EST server. server, and log a failure against a malicious EST server.
* Malicious on-path ACP nodes may filter valid EST server * Malicious on-path ACP nodes may filter valid EST server
announcements across the ACP, but such malicious ACP nodes could announcements across the ACP, but such malicious ACP nodes could
equally filter any ACP traffic such as the EST traffic itself. equally filter any ACP traffic such as the EST traffic itself.
Either attack requires the ability to execute malicious software Either attack requires the ability to execute malicious software
on an impaired ACP node though. on an impaired ACP node though.
* 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 Denial-of-Service (DoS) certificates, but it could result in DoS attacks by becoming an
attacks by becoming an EST server and making ACP nodes attempting EST server and making ACP nodes attempting their ACP certificate
their ACP certificate renewal via this impaired ACP node. This renewal via this impaired ACP node. This problem can be avoided
problem can be avoided when the EST server implementation can when the EST server implementation can verify that the CA
verify that the CA configured is indeed providing renewal for configured is indeed providing renewal for certificates of the
certificates of the nodes ACP. The ability to do so depends on nodes ACP. The ability to do so depends on the EST-Server to CA
the EST-Server to CA protocol, which is outside the scope of this protocol, which is outside the scope of this document.
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
mutually supported ACP secure channel protocols via the approach
described in Section 6.5, ACP secure channel setup is subject to
downgrade attacks by MITM attackers. This can be discovered by
additional mechanisms described in Appendix A.10.9.
The security model of the ACP as defined in this document is tailored
for use with private PKI. The TA of a private PKI provide the
security against maliciously created ACP certificates to give access
to an ACP. Such attacks can create fake ACP certificates with
correct looking AcpNodeNames, but those certificates would not pass
the certificate path validation of the ACP domain membership check
(see Section 6.1.3, point 2).
If public CA are to be used, ACP registrars would need to prove
ownership of the domain-name of AcpNodeNames to the public CA.
However, maintaining the ULA based address allocation when using a
public CA might be considered to be a violation of the private
allocation expectation of ULA prefixes. To avoid this issue, further
changes to registrar address allocation procedures might be needed,
for example using global IPv6 address prefixes owned by the public CA
instead of ULA.
There is no prevention of source-address spoofing inside the ACP. There is no prevention of source-address spoofing inside the ACP.
This implies that if an attacker gains access to the ACP, it can This implies that if an attacker gains access to the ACP, it can
spoof all addresses inside the ACP and fake messages from any other spoof all addresses inside the ACP and fake messages from any other
node. New protocol/services run across the ACP should therefore use node. New protocol/services run across the ACP should therefore use
end-to-end authentication inside the ACP. This is already done by end-to-end authentication inside the ACP. This is already done by
GRASP as specified in this document. GRASP as specified in this document.
The ACP is designed to enable automation of current network The ACP is designed to enable automation of current network
management and future autonomic peer-to-peer/distributed network management and future autonomic peer-to-peer/distributed network
automation. Any ACP member can send ACP IPv6 packet to other ACP automation. Any ACP member can send ACP IPv6 packet to other ACP
members and announce via ACP GRASP services to all ACP members members and announce via ACP GRASP services to all ACP members
without depenency against centralized components. without dependency against centralized components.
The ACP relies on peer-to-peer authentication and authorization using The ACP relies on peer-to-peer authentication and authorization using
ACP certificates. This security model is necessary to enable the ACP certificates. This security model is necessary to enable the
autonomic ad-hoc any-to-any connectivity between ACP nodes. It autonomic ad-hoc any-to-any connectivity between ACP nodes. It
provides infrastructure protection through hop by hop authentication provides infrastructure protection through hop by hop authentication
and encryption - without relying on third parties. For any services and encryption - without relying on third parties. For any services
where this complete autonomic peer-to-peer group security model is where this complete autonomic peer-to-peer group security model is
appropriate, the ACP certificate can also be used unchanged. For appropriate, the ACP certificate can also be used unchanged. For
example for any type of Data-Plane routing protocol security. example for any type of Data-Plane routing protocol security.
skipping to change at page 124, line 32 skipping to change at page 125, line 44
In combination with BRSKI, ACP enables a resilient, fully zero-touch In combination with BRSKI, ACP enables a resilient, fully zero-touch
network solution for short-lived certificates that can be renewed or network solution for short-lived certificates that can be renewed or
re-enrolled even after unintentional expiry (e.g., because of re-enrolled even after unintentional expiry (e.g., because of
interrupted connectivity). See Appendix A.2. interrupted connectivity). See Appendix A.2.
Because ACP secure channels can be long lived, but certificates used Because ACP secure channels can be long lived, but certificates used
may be short lived, secure channels, for example built via IPsec need may be short lived, secure channels, for example built via IPsec need
to be terminated when peer certificates expire. See Section 6.7.5. to be terminated when peer certificates expire. See Section 6.7.5.
The ACP is designed to minimize attacks from the outside by
minimizing its dependency against any non-ACP (Data-Plane)
operations/configuration on a node. See also Section 6.12.2.
Section 7.2 describes how to implement a routed ACP topology Section 7.2 describes how to implement a routed ACP topology
operating on what effectively is a large bridge-domain when using L3/ operating on what effectively is a large bridge-domain when using L3/
L2 routers that operate at L2 in the Data-Plane. In this case, the L2 routers that operate at L2 in the Data-Plane. In this case, the
ACP is subject to much higher likelyhood of attacks by other nodes ACP is subject to much higher likelyhood of attacks by other nodes
"stealing" L2 addresses than in the actual routed case. Especially "stealing" L2 addresses than in the actual routed case. Especially
when the bridged network includes non-trusted devices such as hosts. when the bridged network includes non-trusted devices such as hosts.
This is a generic issue in L2 LANs. L2/L3 devices often already have This is a generic issue in L2 LANs. L2/L3 devices often already have
some form of "port security" to prohibit this. They rely on NDP or some form of "port security" to prohibit this. They rely on NDP or
DHCP learning of which port/MAC-address and IPv6 address belong DHCP learning of which port/MAC-address and IPv6 address belong
together and block MAC/IPv6 source addresses from wrong ports. This together and block MAC/IPv6 source addresses from wrong ports. This
skipping to change at page 128, line 25 skipping to change at page 129, line 25
example via NetConf) would understand the requirements for ACP example via NetConf) would understand the requirements for ACP
registrars and its certificate handling. registrars and its certificate handling.
This lead to additional text about ACP registrars in the ACP This lead to additional text about ACP registrars in the ACP
document: document:
1. Defined relationship ACP / ANI (ANI = ACP + BRSKI). 1. Defined relationship ACP / ANI (ANI = ACP + BRSKI).
6.1.4 (new) Overview of TA required for ACP. 6.1.4 (new) Overview of TA required for ACP.
6.1.5.5 Added explanations/requirements for Re-enrolment. 6.1.5.5 Added explanations/requirements for Re-enrollment.
6.10.7 Normative requirements for ACP registrars (BRSKI or not). 6.10.7 Normative requirements for ACP registrars (BRSKI or not).
10.2 Operational expectations against ACP registrars (BRSKI or not). 10.2 Operational expectations against ACP registrars (BRSKI or not).
15.1.3. Normative enhancements since start of IESG review 15.1.3. Normative enhancements since start of IESG review
In addition to above ACP registrar / BRSKI related enhancements there In addition to above ACP registrar / BRSKI related enhancements there
is a range of minor normative (also explanatory) enhancements since is a range of minor normative (also explanatory) enhancements since
the start of IESG review: the start of IESG review:
skipping to change at page 130, line 21 skipping to change at page 131, 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 from Ben Kaduk:
Many good editorial improvements - thanks!.
5. added explanation of what to do upon failed secure channel
establishment.
6.1.1. refined/extended cert public cey crypto algo and better
distinguished algo for the keys of the cert and the key of the
signer.
6.1.1. and following: explicitly defining "serialNumber" to be the
X.520 subject name serialNumber, not the certificate serial Number.
6.1.1. emhasize additional authorization step for EST servers (id-kp-
cmcRA).
6.1.2 changed AcpNodeName ABNF to again use 32HEXDIG instead of self-
defined variation, because authors overlooked that ABNF is case
agnostic (which is fine). Added recommendation to encode as lower
case. Added full ABNF encoding for extensions (any characters as in
"atoms" except the new "+" separator).
6.1.5.3. New text to explain reason for use of HTTPS (instead of
HTTP) for CRLDP and when and how to use HTTPS then.
6.1.5.5. added text explaning why/how and when to maintain TA data
upon failing cert renewal (one version with BRSKI, one version with
other, ess secure bootstrap protocols).
6.3. new text and requirement about the signaling of transport ports
in DULL GRASP - benefits (no well-known ports required), and problems
(additional DoS attack vector, albeit not worse than pre-existing
ones, depending on setup of L2 subnets.).
6.7.3.1.1. Specified AUTH_HMAC_SHA2_256_128 (as the ESP
authentication algorithm).
6.8.2. Added recommendations for TLS_AES_256_GCM_SHA384,
TLS_CHACHA20_POLY1305_SHA256 when supporting TLS 1.3.
8.2.2. Added explanation about downgrade attack across configured
ACP tunnels and what to do against it.
9.3.5.2. Rewrote most of section as it originally was too centric on
BRSKI. Should now well describe expectations against automated
bootstrap. Introduces new requirement not to call node as in support
of ANI if is ALSO has TOFU bootstrap.
11. Expanded text about malicious EST servers. Added paragraph
about ACP secure channel downgrade attacks. Added paragraphs about
private PKI as a core to allow security against fake certificates,
added paragraph about considerationsproblems when using public PI.
A.10.9 New appendix suggesting how to discover ACP secure channel
negotiation downgrade attacks.
Discuss from Roman Dayliw: Discuss from Roman Dayliw:
6.1.5.1 - Added requirement to only announce SRV.est when a working 6.1.5.1 - Added requirement to only announce SRV.est when a working
CA connection. CA connection.
15 - Amended security considerations with text about registrar 15 - Amended security considerations with text about registrar
dependencies, security of IDevID/ACP-certificate, EST-Server and dependencies, security of IDevID/ACP-certificate, EST-Server and
GRASP for EST server discovery. GRASP for EST server discovery.
Other: Other:
skipping to change at page 140, line 17 skipping to change at page 142, line 24
information. information.
- removed last two paragraphs about relationship to rfc8247, as his - removed last two paragraphs about relationship to rfc8247, as his
is now written in first paragraph of the section. is now written in first paragraph of the section.
End of Ben Kaduk review related fixes. End of Ben Kaduk review related fixes.
Other: Other:
Forgot to update example of ACP domain information to use capitalized Forgot to update example of ACP domain information to use capitalized
hex-digits as required by HEXLC used. hex-digits as required by HEXDIG used.
Added reference to RFC8316 (AN use-cases) to beginning of section 3 Added reference to RFC8316 (AN use-cases) to beginning of section 3
(ACP use cases). (ACP use cases).
Small Enhanced IPsec parameters description / requirements fixes Small Enhanced IPsec parameters description / requirements fixes
(from Michael Richardson). (from Michael Richardson).
16. Normative References 16. Normative References
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
skipping to change at page 141, line 5 skipping to change at page 143, line 9
[IKEV2IANA] [IKEV2IANA]
IANA, "Internet Key Exchange Version 2 (IKEv2) IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters", <https://www.iana.org/assignments/ikev2- Parameters", <https://www.iana.org/assignments/ikev2-
parameters/ikev2-parameters.xhtml>. parameters/ikev2-parameters.xhtml>.
[RFC1034] Mockapetris, P.V., "Domain names - concepts and [RFC1034] Mockapetris, P.V., "Domain names - concepts and
facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034,
November 1987, <https://www.rfc-editor.org/info/rfc1034>. November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004, DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>. <https://www.rfc-editor.org/info/rfc3810>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>. November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
skipping to change at page 141, line 26 skipping to change at page 143, line 35
<https://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492,
DOI 10.17487/RFC4492, May 2006,
<https://www.rfc-editor.org/info/rfc4492>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
skipping to change at page 145, line 34 skipping to change at page 148, line 5
[RFC1654] Rekhter, Y., Ed. and T. Li, Ed., "A Border Gateway [RFC1654] Rekhter, Y., Ed. and T. Li, Ed., "A Border Gateway
Protocol 4 (BGP-4)", RFC 1654, DOI 10.17487/RFC1654, July Protocol 4 (BGP-4)", RFC 1654, DOI 10.17487/RFC1654, July
1994, <https://www.rfc-editor.org/info/rfc1654>. 1994, <https://www.rfc-editor.org/info/rfc1654>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>. February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
<https://www.rfc-editor.org/info/rfc2315>. <https://www.rfc-editor.org/info/rfc2315>.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998,
<https://www.rfc-editor.org/info/rfc2409>. <https://www.rfc-editor.org/info/rfc2409>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
skipping to change at page 147, line 5 skipping to change at page 149, line 19
<https://www.rfc-editor.org/info/rfc4210>. <https://www.rfc-editor.org/info/rfc4210>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<https://www.rfc-editor.org/info/rfc4429>. <https://www.rfc-editor.org/info/rfc4429>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492,
DOI 10.17487/RFC4492, May 2006,
<https://www.rfc-editor.org/info/rfc4492>.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, [RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping (IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<https://www.rfc-editor.org/info/rfc4541>. <https://www.rfc-editor.org/info/rfc4541>.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
skipping to change at page 149, line 40 skipping to change at page 151, line 50
Addressing inside an IPv6 Network", RFC 7404, Addressing inside an IPv6 Network", RFC 7404,
DOI 10.17487/RFC7404, November 2014, DOI 10.17487/RFC7404, November 2014,
<https://www.rfc-editor.org/info/rfc7404>. <https://www.rfc-editor.org/info/rfc7404>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>. 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575, Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015, DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>. <https://www.rfc-editor.org/info/rfc7575>.
[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap
Analysis for Autonomic Networking", RFC 7576, Analysis for Autonomic Networking", RFC 7576,
DOI 10.17487/RFC7576, June 2015, DOI 10.17487/RFC7576, June 2015,
<https://www.rfc-editor.org/info/rfc7576>. <https://www.rfc-editor.org/info/rfc7576>.
skipping to change at page 151, line 26 skipping to change at page 153, line 37
Touch Provisioning (SZTP)", RFC 8572, Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019, DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>. <https://www.rfc-editor.org/info/rfc8572>.
[X.509] International Telecommunication Union, "Information [X.509] International Telecommunication Union, "Information
technology - Open Systems Interconnection - The Directory: technology - Open Systems Interconnection - The Directory:
Public-key and attribute certificate frameworks", ITU-T Public-key and attribute certificate frameworks", ITU-T
Recommendation X.509, ISO/IEC 9594-8, October 2016, Recommendation X.509, ISO/IEC 9594-8, October 2016,
<https://www.itu.int/rec/T-REC-X.509>. <https://www.itu.int/rec/T-REC-X.509>.
[X.520] International Telecommunication Union, "Information
technology - Open Systems Interconnection - The Directory:
Selected attribute types", ITU-T Recommendation
X.520, ISO/IEC 9594-6, October 2016,
<https://www.itu.int/rec/T-REC-X.520>.
Appendix A. Background and Futures (Informative) Appendix A. Background and Futures (Informative)
The following sections discuss additional background information The following sections discuss additional background information
about aspects of the normative parts of this document or associated about aspects of the normative parts of this document or associated
mechanisms such as BRSKI (such as why specific choices were made by mechanisms such as BRSKI (such as why specific choices were made by
the ACP) and they provide discussion about possible future variations the ACP) and they provide discussion about possible future variations
of the ACP. of the ACP.
A.1. ACP Address Space Schemes A.1. ACP Address Space Schemes
skipping to change at page 159, line 42 skipping to change at page 161, line 46
connect later together into a contiguous ACP network. connect later together into a contiguous ACP network.
One instance of such a use case is an ACP for regions interconnected One instance of such a use case is an ACP for regions interconnected
via a non-ACP enabled core, for example due to the absence of product via a non-ACP enabled core, for example due to the absence of product
support for ACP on the core nodes. ACP connect configurations as support for ACP on the core nodes. ACP connect configurations as
defined in this document can be used to extend and interconnect those defined in this document can be used to extend and interconnect those
ACP islands to the NOC and merge them into a single ACP when later ACP islands to the NOC and merge them into a single ACP when later
that product support gap is closed. that product support gap is closed.
Note that RPL scales very well. It is not necessary to use multiple Note that RPL scales very well. It is not necessary to use multiple
routing subdomains to scale ACP domains in a way it would be possible routing subdomains to scale ACP domains in a way that would be
if other routing protocols where used. They exist only as options required if other routing protocols where used. They exist only as
for the above mentioned reasons. options for the above mentioned reasons.
If different ACP domains are to be created that should not allow to If different ACP domains are to be created that should not allow to
connect to each other by default, these ACP domains simply need to connect to each other by default, these ACP domains simply need to
have different domain elements in the acp-node-name. These domain have different domain elements in the acp-node-name. These domain
elements can be arbitrary, including subdomains of one another: elements can be arbitrary, including subdomains of one another:
Domains "example.com" and "research.example.com" are separate domains Domains "example.com" and "research.example.com" are separate domains
if both are domain elements in the acp-node-name of certificates. if both are domain elements in the acp-node-name of certificates.
It is not necessary to have a separate CA for different ACP domains: It is not necessary to have a separate CA for different ACP domains:
an operator can use a single CA to sign certificates for multiple ACP an operator can use a single CA to sign certificates for multiple ACP
skipping to change at page 161, line 41 skipping to change at page 163, line 41
prefix. This prefix could simply be a configuration of the ACP prefix. This prefix could simply be a configuration of the ACP
registrars (for example when using BRSKI) to enroll the domain registrars (for example when using BRSKI) to enroll the domain
certificates - instead of the ACP registrar deriving the /48 ULA certificates - instead of the ACP registrar deriving the /48 ULA
prefix from the AN domain name. prefix from the AN domain name.
Some solutions may already have an auto-addressing scheme, for Some solutions may already have an auto-addressing scheme, for
example derived from existing unique device identifiers (e.g., MAC example derived from existing unique device identifiers (e.g., MAC
addresses). In those cases it may not be desirable to assign addresses). In those cases it may not be desirable to assign
addresses to devices via the ACP address information field in the way addresses to devices via the ACP address information field in the way
described in this document. The certificate may simply serve to described in this document. The certificate may simply serve to
identify the ACP domain, and the address field could be empty/unused. identify the ACP domain, and the address field could be omitted. The
The only fix required in the remaining way the ACP operate is to only fix required in the remaining way the ACP operate is to define
define another element in the domain certificate for the two peers to another element in the domain certificate for the two peers to decide
decide who is Alice and who is Bob during secure channel building. who is Alice and who is Bob during secure channel building. Note
Note though that future work may leverage the acp address to though that future work may leverage the acp address to authenticate
authenticate "ownership" of the address by the device. If the "ownership" of the address by the device. If the address used by a
address used by a device is derived from some pre-existing permanent device is derived from some pre-existing permanent local ID (such as
local ID (such as MAC address), then it would be useful to store that MAC address), then it would be useful to store that address in the
address in the certificate using the format of the access address certificate using the format of the access address information field
information field or in a similar way. or in a similar way.
The ACP is defined as a separate VRF because it intends to support The ACP is defined as a separate VRF because it intends to support
well managed networks with a wide variety of configurations. well managed networks with a wide variety of configurations.
Therefore, reliable, configuration-indestructible connectivity cannot Therefore, reliable, configuration-indestructible connectivity cannot
be achieved from the Data-Plane itself. In solutions where all be achieved from the Data-Plane itself. In solutions where all
transit connectivity impacting functions are fully automated transit connectivity impacting functions are fully automated
(including security), indestructible and resilient, it would be (including security), indestructible and resilient, it would be
possible to eliminate the need for the ACP to be a separate VRF. possible to eliminate the need for the ACP to be a separate VRF.
Consider the most simple example system in which there is no separate Consider the most simple example system in which there is no separate
Data-Plane, but the ACP is the Data-Plane. Add BRSKI, and it becomes Data-Plane, but the ACP is the Data-Plane. Add BRSKI, and it becomes
skipping to change at page 167, line 28 skipping to change at page 169, line 28
node kicked off the network - until the situation can be further node kicked off the network - until the situation can be further
rectified, likely requiring direct physical access to the node. rectified, likely requiring direct physical access to the node.
Without extensions, compromised ACP nodes can only be removed from Without extensions, compromised ACP nodes can only be removed from
the ACP at the speed of CRL/OCSP information refresh or expiry (and the ACP at the speed of CRL/OCSP information refresh or expiry (and
non-removal) of short lived certificates. Future extensions to the non-removal) of short lived certificates. Future extensions to the
ACP could for example use GRASP flooding distribution of triggered ACP could for example use GRASP flooding distribution of triggered
updates of CRL/OCSP or explicit removal indication of the compromised updates of CRL/OCSP or explicit removal indication of the compromised
nodes domain certificate. nodes domain certificate.
A.10.9. Detecting ACP secure channel downgrade attacks
MITM attackers can force downgrade attacks for ACP secure channel
selection by filtering/modifying DULL GRASP messages and/or actual
secure channel data packets. For example if at some point in time
DTLS traffic could be easier decrypted than traffic of IKEv2, the
MITM could filter all IKEv2 packets to force ACP nodes to use DTLS
(assuming the ACP nodes in question supported both DTLS and IKEv2).
For cases where such MITM attacks are not capable to inject malicious
traffic (but only to decrypt the traffic), a downgrade attack could
be discovered after a secure channel connection is established, for
example by use of the following type of mechanism:
After the secure channel connection is established, the two ACP peers
negotiate via an appropriate (To Be Defined) GRASP negotiation which
ACP secure channel protocol should have been selected between them
(in the absence of a MITM attacker). This negotiation would have to
signal the DULL GRASP announced ACP secure channel options by each
peer followed by an announcement of the preferred secure channel
protocol by the ACP peer that is Alice in the secure channel setup,
e.g.: the ACP peer that is deciding which secure channel protocol to
pick. If that choosen secure channel protocol is different from the
one that actually was choosen, then this mismatch is an indication
that there is a MITM attacker or other similar issue (firewall
prohibiting the use of specific protocols) that caused a non-
preferred secure channel protocol to be chosen. This discovery could
then result in mitigation options such as logging and ensueing
investigations.
Authors' Addresses Authors' Addresses
Toerless Eckert (editor) Toerless Eckert (editor)
Futurewei Technologies Inc. USA Futurewei Technologies Inc. USA
2330 Central Expy 2330 Central Expy
Santa Clara, 95050 Santa Clara, 95050
United States of America United States of America
Email: tte+ietf@cs.fau.de Email: tte+ietf@cs.fau.de
 End of changes. 118 change blocks. 
284 lines changed or deleted 513 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/