draft-ietf-anima-stable-connectivity-06.txt   draft-ietf-anima-stable-connectivity-07.txt 
ANIMA T. Eckert, Ed. ANIMA T. Eckert, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational M. Behringer Intended status: Informational M. Behringer
Expires: March 21, 2018 September 17, 2017 Expires: April 21, 2018 October 18, 2017
Using Autonomic Control Plane for Stable Connectivity of Network OAM Using Autonomic Control Plane for Stable Connectivity of Network OAM
draft-ietf-anima-stable-connectivity-06 draft-ietf-anima-stable-connectivity-07
Abstract Abstract
OAM (Operations, Administration and Maintenance - as per BCP161, OAM (Operations, Administration and Maintenance - as per BCP161,
[RFC6291]) processes for data networks are often subject to the (RFC6291) processes for data networks are often subject to the
problem of circular dependencies when relying on connectivity problem of circular dependencies when relying on connectivity
provided by the network to be managed for the OAM purposes. provided by the network to be managed for the OAM purposes.
Provisioning while bringing up devices and networks tends to be more Provisioning while bringing up devices and networks tends to be more
difficult to automate than service provisioning later on, changes in difficult to automate than service provisioning later on, changes in
core network functions impacting reachability cannot be automated core network functions impacting reachability cannot be automated
because of ongoing connectivity requirements for the OAM equipment because of ongoing connectivity requirements for the OAM equipment
itself, and widely used OAM protocols are not secure enough to be itself, and widely used OAM protocols are not secure enough to be
carried across the network without security concerns. carried across the network without security concerns.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 March 21, 2018. This Internet-Draft will expire on April 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 43
2.1.6. Autonomic NOC Device/Applications . . . . . . . . . . 12 2.1.6. Autonomic NOC Device/Applications . . . . . . . . . . 12
2.1.7. Encryption of data-plane connections . . . . . . . . 13 2.1.7. Encryption of data-plane connections . . . . . . . . 13
2.1.8. Long Term Direction of the Solution . . . . . . . . . 14 2.1.8. Long Term Direction of the Solution . . . . . . . . . 14
2.2. Stable Connectivity for Distributed Network/OAM . . . . . 15 2.2. Stable Connectivity for Distributed Network/OAM . . . . . 15
3. Architectural Considerations . . . . . . . . . . . . . . . . 15 3. Architectural Considerations . . . . . . . . . . . . . . . . 15
3.1. No IPv4 for ACP . . . . . . . . . . . . . . . . . . . . . 15 3.1. No IPv4 for ACP . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 18 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
1.1. Self dependent OAM Connectivity 1.1. Self dependent OAM Connectivity
OAM (Operations, Administration and Maintenance - as per BCP161, OAM (Operations, Administration and Maintenance - as per BCP161,
[RFC6291]) for data networks is often subject to the problem of [RFC6291]) for data networks is often subject to the problem of
circular dependencies when relying on the connectivity service circular dependencies when relying on the connectivity service
provided by the network to be managed. OAM can easily but provided by the network to be managed. OAM can easily but
skipping to change at page 13, line 45 skipping to change at page 13, line 45
the ACP, the traffic will be mostly encryption protected, especially the ACP, the traffic will be mostly encryption protected, especially
when considering the above described use of AN application devices. when considering the above described use of AN application devices.
If instead the data-plane is used, then this is not the case anymore If instead the data-plane is used, then this is not the case anymore
unless it is done by the application. unless it is done by the application.
The simplest solution for this problem exists when using AN capable The simplest solution for this problem exists when using AN capable
NMS hosts, because in that case the communicating AN capable NMS host NMS hosts, because in that case the communicating AN capable NMS host
and the AN network device have certificates through the AN enrollment and the AN network device have certificates through the AN enrollment
process that they can mutually trust (same AN domain). In result, process that they can mutually trust (same AN domain). In result,
data-plane connectivity that does support this can simply leverage data-plane connectivity that does support this can simply leverage
TLS/DTLS ([RFC5246]/[RFC6347]) with mutual AN-domain certificate TLS/DTLS ([RFC5246])/([RFC6347]) with mutual AN-domain certificate
authentication - and does not incur new key management. authentication - and does not incur new key management.
If this automatic security benefit is seen as most important, but a If this automatic security benefit is seen as most important, but a
"full" ACP stack into the NMS host is unfeasible, then it would still "full" ACP stack into the NMS host is unfeasible, then it would still
be possible to design a stripped down version of AN functionality for be possible to design a stripped down version of AN functionality for
such NOC hosts that only provides enrollment of the NOC host into the such NOC hosts that only provides enrollment of the NOC host into the
AN domain to the extent that the host receives an AN domain AN domain to the extent that the host receives an AN domain
certificate, but without directly participating in the ACP certificate, but without directly participating in the ACP
afterwards. Instead, the host would just leverage TLS/DTLS using its afterwards. Instead, the host would just leverage TLS/DTLS using its
AN certificate via the data-plane with AN network devices as well as AN certificate via the data-plane with AN network devices as well as
skipping to change at page 17, line 5 skipping to change at page 17, line 5
the sites on the Internet, for example the sites on the Internet, for example
https://www.sixxs.net/tools/grh/ula/. Note that this does not https://www.sixxs.net/tools/grh/ula/. Note that this does not
constitute registration and if you want to ensure that your leaked constitute registration and if you want to ensure that your leaked
ACP packets can be recognized to come from you, you may need to list ACP packets can be recognized to come from you, you may need to list
your prefixes in multiple of those sites. your prefixes in multiple of those sites.
Note that there is a provision in [RFC4193] for non-locally assigned Note that there is a provision in [RFC4193] for non-locally assigned
address space (L bit = 0), but there is no existing standardization address space (L bit = 0), but there is no existing standardization
for this, so these ULA prefixes must not be used. for this, so these ULA prefixes must not be used.
According to RFC4193 section 4.4, PTR records for ULA addresses According to [RFC4193] section 4.4, PTR records for ULA addresses
should not be installed into the global DNS (no guaranteed should not be installed into the global DNS (no guaranteed
ownership). Hence also the need to rely on voluntary lists (and in ownership). Hence also the need to rely on voluntary lists (and in
prior paragraph) to make the use of an ULA prefix globally known. prior paragraph) to make the use of an ULA prefix globally known.
Nevertheless, some legacy OAM applications running across the ACP may Nevertheless, some legacy OAM applications running across the ACP may
rely on reverse DNS lookup for authentication of requests (eg: TFTP rely on reverse DNS lookup for authentication of requests (eg: TFTP
for download of network firmware/config/software). Operators may for download of network firmware/config/software). Operators may
therefore need to use a private DNS setup for the ACP ULA addresses. therefore need to use a private DNS setup for the ACP ULA addresses.
This is the same setup that would be necessary for using RFC1918 This is the same setup that would be necessary for using RFC1918
addresses in DNS. See for example [RFC1918] section 5, last addresses in DNS. See for example [RFC1918] section 5, last
skipping to change at page 18, line 7 skipping to change at page 18, line 7
the design and early testing. Many people contributed to the aspects the design and early testing. Many people contributed to the aspects
described in this document, including in alphabetical order: BL described in this document, including in alphabetical order: BL
Balaji, Steinthor Bjarnason, Yves Herthoghs, Sebastian Meissner, Ravi Balaji, Steinthor Bjarnason, Yves Herthoghs, Sebastian Meissner, Ravi
Kumar Vadapalli. The author would also like to thank Michael Kumar Vadapalli. The author would also like to thank Michael
Richardson, James Woodyatt and Brian Carpenter for their review and Richardson, James Woodyatt and Brian Carpenter for their review and
comments. Special thanks to Sheng Jiang and Mohamed Boucadair for comments. Special thanks to Sheng Jiang and Mohamed Boucadair for
their thorough review. their thorough review.
7. Change log [RFC Editor: Please remove] 7. Change log [RFC Editor: Please remove]
07: Fixed ID nits.
06: changed "split-horizon" term to "private-DNS" and reworded the 06: changed "split-horizon" term to "private-DNS" and reworded the
paragraph about it. paragraph about it.
05: Integrated fixes from Brian Carpenters review. See github 05: Integrated fixes from Brian Carpenters review. See github
draft-ietf-anima-stable-connectivity/04-brian-carpenter-review- draft-ietf-anima-stable-connectivity/04-brian-carpenter-review-
reply.txt. Details on semantic/structural changes: reply.txt. Details on semantic/structural changes:
* Folded most comments back into draft-ietf-anima-autonomic- * Folded most comments back into draft-ietf-anima-autonomic-
control-plane-09 because this stable connectivity draft was control-plane-09 because this stable connectivity draft was
suggesting things that are better written out and standardized suggesting things that are better written out and standardized
skipping to change at page 19, line 20 skipping to change at page 19, line 22
better anymore, but still mention it. better anymore, but still mention it.
individual-02: Added explanation why no IPv4 for ACP. individual-02: Added explanation why no IPv4 for ACP.
individual-01: Added security section discussing the role of individual-01: Added security section discussing the role of
address prefix selection and DNS for ACP. Title change to address prefix selection and DNS for ACP. Title change to
emphasize focus on OAM. Expanded abstract. emphasize focus on OAM. Expanded abstract.
individual-00: Initial version. individual-00: Initial version.
8. References 8. Informative References
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-09 (work in progress), August 2017. plane-10 (work in progress), September 2017.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-07 (work in progress), July 2017. keyinfra-08 (work in progress), October 2017.
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A
Reference Model for Autonomic Networking", draft-ietf- Reference Model for Autonomic Networking", draft-ietf-
skipping to change at page 20, line 6 skipping to change at page 20, line 10
[IEEE802.1Q] [IEEE802.1Q]
International Telecommunication Union, "802.1Q-2014 - IEEE International Telecommunication Union, "802.1Q-2014 - IEEE
Standard for Local and metropolitan area networks - Standard for Local and metropolitan area networks -
Bridges and Bridged Networks", 2014. Bridges and Bridged Networks", 2014.
[ITUT] International Telecommunication Union, "Architecture and [ITUT] International Telecommunication Union, "Architecture and
specification of data communication network", specification of data communication network",
ITU-T Recommendation G.7712/Y.1703, Noevember 2001. ITU-T Recommendation G.7712/Y.1703, Noevember 2001.
This is the earliest but superceeded version of the This is the earliest but superceeded version of the
series. See REC-G.7712 Home Page [1] for current series. See "https://www.itu.int/rec/T-REC-G.7712/en" for
versions. current versions.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
skipping to change at page 20, line 46 skipping to change at page 20, line 50
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM" D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011, DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>. <https://www.rfc-editor.org/info/rfc6291>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418,
DOI 10.17487/RFC6418, November 2011,
<https://www.rfc-editor.org/info/rfc6418>.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, DOI 10.17487/RFC6434, December Requirements", RFC 6434, DOI 10.17487/RFC6434, December
2011, <https://www.rfc-editor.org/info/rfc6434>. 2011, <https://www.rfc-editor.org/info/rfc6434>.
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", RFC 6518, Routing Protocols (KARP) Design Guidelines", RFC 6518,
DOI 10.17487/RFC6518, February 2012, DOI 10.17487/RFC6518, February 2012,
<https://www.rfc-editor.org/info/rfc6518>. <https://www.rfc-editor.org/info/rfc6518>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
 End of changes. 13 change blocks. 
17 lines changed or deleted 14 lines changed or added

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