< draft-ietf-anima-autonomic-control-plane.txt   draft-ietf-anima-autonomic-control-plane.txt >
skipping to change at page 5, line 7 skipping to change at page 5, line 7
9.4. Partial or Incremental adoption . . . . . . . . . . . . . 113 9.4. Partial or Incremental adoption . . . . . . . . . . . . . 113
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 . . . . . . . . . . . . . . . 117
10.2.1. From the outside . . . . . . . . . . . . . . . . . . 117 10.2.1. From the outside . . . . . . . . . . . . . . . . . . 117
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 . . . . . . . . . . . . . . . . . 119
11. Security Considerations . . . . . . . . . . . . . . . . . . . 120 11. Security Considerations . . . . . . . . . . . . . . . . . . . 120
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 123 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 124 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 126
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 124 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 126
15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 125 15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 127
15.1. Summary of changes since entering IESG review . . . . . 125 15.1. Summary of changes since entering IESG review . . . . . 127
15.1.1. Reviews (while in IESG review status) / status . . . 125 15.1.1. Reviews (while in IESG review status) / status . . . 127
15.1.2. BRSKI / ACP registrar related enhancements . . . . . 126 15.1.2. BRSKI / ACP registrar related enhancements . . . . . 128
15.1.3. Normative enhancements since start of IESG review . 126 15.1.3. Normative enhancements since start of IESG review . 128
15.1.4. Explanatory enhancements since start of IESG 15.1.4. Explanatory enhancements since start of IESG
review . . . . . . . . . . . . . . . . . . . . . . . 127 review . . . . . . . . . . . . . . . . . . . . . . . 129
15.2. draft-ietf-anima-autonomic-control-plane-29 . . . . . . 128 15.2. draft-ietf-anima-autonomic-control-plane-29 . . . . . . 130
15.3. draft-ietf-anima-autonomic-control-plane-28 . . . . . . 128 15.3. draft-ietf-anima-autonomic-control-plane-28 . . . . . . 130
15.4. draft-ietf-anima-autonomic-control-plane-27 . . . . . . 129 15.4. draft-ietf-anima-autonomic-control-plane-27 . . . . . . 132
15.5. draft-ietf-anima-autonomic-control-plane-26 . . . . . . 130 15.5. draft-ietf-anima-autonomic-control-plane-26 . . . . . . 132
15.6. draft-ietf-anima-autonomic-control-plane-25 . . . . . . 131 15.6. draft-ietf-anima-autonomic-control-plane-25 . . . . . . 133
15.7. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 134 15.7. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 136
15.8. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 134 15.8. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 136
15.9. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 136 15.9. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 138
16. Normative References . . . . . . . . . . . . . . . . . . . . 138 16. Normative References . . . . . . . . . . . . . . . . . . . . 140
17. Informative References . . . . . . . . . . . . . . . . . . . 141 17. Informative References . . . . . . . . . . . . . . . . . . . 143
Appendix A. Background and Futures (Informative) . . . . . . . . 149 Appendix A. Background and Futures (Informative) . . . . . . . . 151
A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 149 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 151
A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 150 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 152
A.3. ACP Neighbor discovery protocol selection . . . . . . . . 151 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 153
A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 151 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 153
A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 152 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 154
A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 152 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 154
A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 152 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 154
A.5. ACP Information Distribution and multicast . . . . . . . 154 A.5. ACP Information Distribution and multicast . . . . . . . 156
A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 155 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 157
A.7. CAs, domains and routing subdomains . . . . . . . . . . . 157 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 159
A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 158 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 160
A.9. Adopting ACP concepts for other environments . . . . . . 159 A.9. Adopting ACP concepts for other environments . . . . . . 161
A.10. Further (future) options . . . . . . . . . . . . . . . . 161 A.10. Further (future) options . . . . . . . . . . . . . . . . 163
A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 161 A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 163
A.10.2. More options for avoiding IPv6 Data-Plane A.10.2. More options for avoiding IPv6 Data-Plane
dependencies . . . . . . . . . . . . . . . . . . . . 161 dependencies . . . . . . . . . . . . . . . . . . . . 163
A.10.3. ACP APIs and operational models (YANG) . . . . . . . 162 A.10.3. ACP APIs and operational models (YANG) . . . . . . . 164
A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 162 A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 164
A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 163 A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 165
A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 163 A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 165
A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 163 A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 165
A.10.8. Avoiding and dealing with compromised ACP nodes . . 164 A.10.8. Avoiding and dealing with compromised ACP nodes . . 166
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 167
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 36, line 5 skipping to change at page 35, line 46
three consecutive messages can be dropped before considering an three consecutive messages can be dropped before considering an
announcement expired. In the example above, the ttl is 210000 msec, announcement expired. In the example above, the ttl is 210000 msec,
3.5 times 60 seconds. When a service announcer using these 3.5 times 60 seconds. When a service announcer using these
parameters unexpectedly dies immediately after sending the M_FLOOD, parameters unexpectedly dies immediately after sending the M_FLOOD,
receivers would consider it expired 210 seconds later. When a receivers would consider it expired 210 seconds later. When a
receiver tries to connect to this dead service before this timeout, receiver tries to connect to this dead service before this timeout,
it will experience a failing connection and use that as an indication it will experience a failing connection and use that as an indication
that the service instance is dead and select another instance of the that the service instance is dead and select another instance of the
same service instead (from another GRASP announcement). same service instead (from another GRASP announcement).
The "SRV.est" objective(s) SHOULD only be announced when the ACP node
knows that it can successfully communicate with a CA to perform the
EST renewal/rekeying operations for the ACP domain. See also
Section 11.
6.1.5.2. Renewal 6.1.5.2. Renewal
When performing renewal, the node SHOULD attempt to connect to the When performing renewal, the node SHOULD attempt to connect to the
remembered EST server. If that fails, it SHOULD attempt to connect remembered EST server. If that fails, it SHOULD attempt to connect
to an EST server learned via GRASP. The server with which to an EST server learned via GRASP. The server with which
certificate renewal succeeds SHOULD be remembered for the next certificate renewal succeeds SHOULD be remembered for the next
renewal. renewal.
Remembering the last renewal server and preferring it provides Remembering the last renewal server and preferring it provides
stickiness which can help diagnostics. It also provides some stickiness which can help diagnostics. It also provides some
skipping to change at page 120, line 17 skipping to change at page 120, line 17
Since an ACP is self-protecting, a node not supporting the ACP, or Since an ACP is self-protecting, a node not supporting the ACP, or
without a valid domain certificate cannot connect to it. This means without a valid domain certificate cannot connect to it. This means
that by default a traditional controller or network management system that by default a traditional controller or network management system
cannot connect to an ACP. See Section 8.1.1 for more details on how cannot connect to an ACP. See Section 8.1.1 for more details on how
to connect an NMS host into the ACP. to connect an NMS host into the ACP.
11. Security Considerations 11. Security Considerations
A set of ACP nodes with ACP certificates for the same ACP domain and A set of ACP nodes with ACP certificates for the same ACP domain and
with ACP functionaliy enabled is automatically "self-building": The with ACP functionality enabled is automatically "self-building": The
ACP is automatically established between neighboring ACP nodes. It ACP is automatically established between neighboring ACP nodes. It
is also "self-protecting": The ACP secure channels are authenticated is also "self-protecting": The ACP secure channels are authenticated
and encrypted. No configuration is required for this. and encrypted. No configuration is required for this.
The self-protecting property does not include workarounds for non- The self-protecting property does not include workarounds for non-
autonomic components as explained in Section 8. See Section 10.2 for autonomic components as explained in Section 8. See Section 10.2 for
details of how the ACP protects itself against attacks from the details of how the ACP protects itself against attacks from the
outside and to a more limited degree from the inside as well. outside and to a more limited degree from the inside as well.
However, the security of the ACP depends on a number of other However, the security of the ACP depends on a number of other
factors: factors:
* 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.
* Every ACP registrar is criticial infrastructure that needs to be * ACP nodes receive their certificates from ACP registrars. These
hardened against attacks, similar to a CA. A malicious registrar ACP registrars are security critical dependencies of the ACP:
can enroll enemy plegdes to an ACP network or break ACP routing by Procedures and protocols for ACP registrars are outside the scope
duplicate ACP address assignment to pledges via their ACP of this specification as explained in Section 6.10.7.1, only
requirements against the resulting ACP certificates are specified.
* Every ACP registrar (for enrolment of ACP certificates) and ACP
EST server (for renewal of ACP certificates) is a security
critical entity and its protocols are security critical protocols.
Both need to be hardened against attacks, similar to a CA and its
protocols. A malicious registrar can enroll malicious nodes to an
ACP network (if the CA delegates this policy to the registrar) or
break ACP routing for example by assigning duplicate ACP address
assignment to ACP nodes via their ACP certificates.
* ACP nodes that are ANI nodes rely on BRSKI as the protocol for ACP
registrars. For ANI type ACP nodes, the security considerations
of BRSKI apply. It enables automated, secure enrolment of ACP
certificates. certificates.
* Security can be compromised by implementation errors (bugs), as in
all products. * BRSKI and potentially other ACP registrar protocol options require
that nodes have an (X.509v3 based) IDevID. IDevIDs are an option
for ACP registrars to securely identify candidate ACP nodes that
should be enrolled into an ACP domain.
* For IDevIDs to securely identify the node to which it IDevID is
assigned, the node it needs to (1) utilize hardware support such
as a Trusted Platform Module (TPM) to protect against extraction/
cloning of the private key of the IDevID and (2) a hardware/
software infrastructure to prohibit execution of non authenticated
software to protect against malicious use of the IDevID.
* Like the IDevID, the ACP certificate should equally be protected
from extraction or other abuse by the same ACP node
infrastructure. This infrastructure for IDevID and ACP
certificate is beneficial independent of the ACP registrar
protocol used (BRSKI or other).
* Renewal of ACP certificates requires support for EST, therefore
the security considerations of [RFC7030] related to certificate
renewal/rekeying and TP renewal apply to the ACP. EST security
considerations when using other than mutual certificate
authentication do not apply nor do considerations for initial
enrolment via EST apply, except for ANI type ACP nodes because
BRSKI leverages EST.
* 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
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.
* Malicious on-path ACP nodes may filter valid EST server
announcements across the ACP, but such malicious ACP nodes could
equally filter any ACP traffic such as the EST traffic itself.
Either attack requires the ability to execute malicious software
on an impaired ACP node though.
* In the abscence of malicious software injection, an attacker that
can misconfigure an ACP node which is supporting EST server
functionality could attempt to configure a malicious CA. This
would not result in the ability to successfully renew ACP
certificates, but it could result in Denial-of-Service (DoS)
attacks by becoming an EST server and making ACP nodes attempting
their ACP certificate renewal via this impaired ACP node. This
problem can be avoided when the EST server implementation can
verify that the CA configured is indeed providing renewal for
certificates of the nodes ACP. The ability to do so depends on
the EST-Server to CA protocol, which is outside the scope of this
document.
In summary, attacks against the PKI/certificate dependencies of the
ACP can be minimized by a variety of hardware/software commponents
including options such as TPM for IDevID/ACP-certificate,
prohibitions against execution of non-trusted software and design
aspects of the EST Server functionality for the ACP to eliminate
configuration level impairment.
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
skipping to change at page 128, line 28 skipping to change at page 130, 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 Roman Dayliw:
6.1.5.1 - Added requirement to only announce SRV.est when a working
CA connection.
15 - Amended security considerations with text about registrar
dependencies, security of IDevID/ACP-certificate, EST-Server and
GRASP for EST server discovery.
Other:
Conversion to XML v3. Solved empty () taxonomy xref problems. Conversion to XML v3. Solved empty () taxonomy xref problems.
Various formatting fixes for v3. Various formatting fixes for v3.
Added contributors section. Added contributors section.
15.3. draft-ietf-anima-autonomic-control-plane-28 15.3. draft-ietf-anima-autonomic-control-plane-28
IESG review Roman Danyliw: IESG review Roman Danyliw:
6. Requested additional text elaborating misconfiguration plus 6. Requested additional text elaborating misconfiguration plus
 End of changes. 8 change blocks. 
49 lines changed or deleted 133 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/