Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
draft-ietf-tsvwg-addip-sctp-22
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5061.
|
|
---|---|---|---|
Authors | Qiaobing Xie , Randall R. Stewart , Shin Maruyama , Michael Tüxen , Masahiro Kozuka | ||
Last updated | 2015-10-14 (Latest revision 2007-06-19) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | Proposed Standard | ||
Formats | |||
Reviews | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | (None) | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 5061 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | Lars Eggert | ||
Send notices to | (None) |
draft-ietf-tsvwg-addip-sctp-22
ANIMA WG T. Eckert, Ed. Internet-Draft Huawei Intended status: Standards Track M. Behringer, Ed. Expires: December 10, 2018 S. Bjarnason Arbor Networks June 8, 2018 An Autonomic Control Plane (ACP) draft-ietf-anima-autonomic-control-plane-16 Abstract Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations Administration and Management (OAM) communications over a network that is secure and reliable even when the network is not configured, or misconfigured. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ' + 1), simply skip to the next ASCONF, and include in the outbound response packet any previously cached ASCONF-ACK response that was sent and saved that matches the sequence number of the ASCONF. Note: it is possible that no cached ASCONF-ACK Chunk exists. This will occur when an older ASCONF arrives out of order. In such a case the receiver should skip the ASCONF Chunk and not include ASCONF-ACK Chunk for that chunk. E3) Then, process each ASCONF one by one as above while the Sequence Number of the ASCONF is less than the ('Peer-Sequence-Number' + 1). E4) When the sequence number matches the next one expected, process the ASCONF as described below and after processing the ASCONF Chunk, append an ASCONF-ACK Chunk to the response packet and cache a copy of it (in the event it later needs to be retransmitted). V1) Process the TLVs contained within the Chunk performing the appropriate actions as indicated by each TLV type. The TLVs MUST be processed in order within the Chunk. For example, if the sender puts 3 TLVs in one chunk, the first TLV (the one closest to the Chunk Header) in the Chunk MUST be processed first. The next TLV in the chunk (the middle one) MUST be processed second and finally the last TLV in the Chunk MUST be processed last. Stewart, et al. Expires December 21, 2007 [Page 24] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 V2) In processing the chunk, the receiver should build a response message with the appropriate error TLVs, as specified in the Parameter type bits for any ASCONF Parameter it does not understand. To indicate an unrecognized parameter, cause type 8 as defined in the ERROR in 3.3.10.8 of [I-D.ietf-tsvwg-2960bis] should be used. The endpoint may also use the response to carry rejections for other reasons such as resource shortages etc, using the Error Cause TLV and an appropriate error condition. Note: a positive response is implied if no error is indicated by the sender. V3) All responses MUST copy the ASCONF-Request Correlation ID field received in the ASCONF parameter, from the TLV being responded to, into the ASCONF-Request Correlation ID field in the response parameter. V4) After processing the entire Chunk, the receiver of the ASCONF MUST queue the response ASCONF-ACK Chunk for transmission after the rest of the SCTP packet has been processed. This allows the ASCONF-ACK Chunk to be bundled with other ASCONF-ACK Chunks as well as any additional responses e.g. a SACK Chunk. V5) Update the 'Peer-Sequence-Number' to the value found in the sequence number field. E5) Otherwise, the ASCONF Chunk is discarded since it must be either a stale packet or from an attacker. A receiver of such a packet MAY log the event for security purposes. E6) When all ASCONF Chunks are processed for this SCTP packet, send back the accumulated single response packet with all of the ASCONF-ACK Chunks. The destination address of the SCTP packet containing the ASCONF-ACK Chunks MUST be the source address of the SCTP packet that held the ASCONF Chunks. E7) While processing the ASCONF Chunks in the SCTP packet, if the response packet will exceed the PMTU of the return path, the receiver MUST stop adding additional ASCONF-ACKs into the response packet but MUST continue to process all of the ASCONF Chunks, saving ASCONF-ACK Chunk responses in its cached copy. The sender of the ASCONF Chunk will later retransmit the ASCONF Chunks that were not responded to, at which time the cached copies of the responses that would NOT fit in the PMTU can be sent to the peer. Stewart, et al. Expires December 21, 2007 [Page 25] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 Note: These rules have been presented with the assumption that the implementation is caching old ASCONF-ACKs in case of loss of SCTP packets in the ACK path. It is allowable for an implementation to maintain this state in another form it deems appropriate, as long as that form results in the same ASCONF-ACK sequences being returned to the peer as outlined above. 5.3. General rules for address manipulation When building TLV parameters for the ASCONF Chunk that will add or delete IP addresses the following rules MUST be applied: F0) If an endpoint receives an ASCONF-ACK that is greater than or equal to the next sequence number to be used but no ASCONF Chunk is outstanding the endpoint MUST ABORT the association. Note: that a sequence number is greater than if it is no more than 2^^31-1 larger than the current sequence number (using serial arithmetic). F1) When adding an IP address to an association, the IP address is NOT considered fully added to the association until the ASCONF-ACK arrives. This means that until such time as the ASCONF containing the add is acknowledged the sender MUST NOT use the new IP address as a source for ANY SCTP packet except on carrying an ASCONF Chunk. The receiver of the add IP address request may use the address as a destination immediately. The receiver MUST use the path verification procedure for the added address before using that address. The receiver MUST NOT send packets to the new address except for the corresponding ASCONF-ACK Chunk or HEARTBEAT Chunks for path verification before the new path is verified. If the ASCONF-ACK is sent to the new address it MAY be bundled with the HEARTBEAT chunk for path verification. F2) After the ASCONF-ACK of an IP address add arrives, the endpoint MAY begin using the added IP address as a source address for any type of SCTP chunk. F3a) If an endpoint receives an Error Cause TLV indicating that the IP address Add or IP address Deletion parameters was not understood, the endpoint MUST consider the operation failed and MUST NOT attempt to send any subsequent Add or Delete requests to the peer. F3b) If an endpoint receives an Error Cause TLV indicating that the IP address Set Primary IP Address parameter was not understood, the endpoint MUST consider the operation failed and MUST NOT attempt to send any subsequent Set Primary IP Address requests to the peer. Stewart, et al. Expires December 21, 2007 [Page 26] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 F4) When deleting an IP address from an association, the IP address MUST be considered a valid destination address for the reception of SCTP packets until the ASCONF-ACK arrives and MUST NOT be used as a source address for any subsequent packets. This means that any datagrams that arrive before the ASCONF-ACK destined to the IP address being deleted MUST be considered part of the current association. One special consideration is that ABORT Chunks arriving destined to the IP address being deleted MUST be ignored (see Section 5.3.1 for further details). F5) An endpoint MUST NOT delete its last remaining IP address from an association. In other words if an endpoint is NOT multi-homed it MUST NOT use the delete IP address without an add IP address preceding the delete parameter in the ASCONF Chunk. Or if an endpoint sends multiple requests to delete IP addresses it MUST NOT delete all of the IP addresses that the peer has listed for the requester. F6) An endpoint MUST NOT set an IP header source address for an SCTP packet holding the ASCONF Chunk to be the same as an address being deleted by the ASCONF Chunk. F7) If a request is received to delete the last remaining IP address of a peer endpoint, the receiver MUST send an Error Cause TLV with the error cause set to the new error code 'Request to Delete Last Remaining IP Address'. The requested delete MUST NOT be performed or acted upon, other than to send the ASCONF-ACK. F8) If a request is received to delete an IP address which is also the source address of the IP packet which contained the ASCONF chunk, the receiver MUST reject this request. To reject the request the receiver MUST send an Error Cause TLV set to the new error code 'Request to Delete Source IP Address' (unless Rule F5 has also been violated, in which case the error code 'Request to Delete Last Remaining IP Address' is sent). F9) If an endpoint receives an ADD IP address request and does not have the local resources to add this new address to the association, it MUST return an Error Cause TLV set to the new error code 'Operation Refused Due to Resource Shortage'. F10) If an endpoint receives an 'Out of Resource' error in response to its request to ADD an IP address to an association, it must either ABORT the association or not consider the address part of the association. In other words if the endpoint does not ABORT the association, it must consider the add attempt failed and NOT use this address since its peer will treat SCTP packets destined to the address as Out Of The Blue packets. Stewart, et al. Expires December 21, 2007 [Page 27] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 F11) When an endpoint receiving an ASCONF to add an IP address sends an 'Out of Resource' in its response, it MUST also fail any subsequent add or delete requests bundled in the ASCONF. The receiver MUST NOT reject an ADD and then accept a subsequent DELETE of an IP address in the same ASCONF Chunk. In other words, once a receiver begins failing any ADD or DELETE request, it must fail all subsequent ADD or DELETE requests contained in that single ASCONF. F12) When an endpoint receives a request to delete an IP address that is the current primary address, it is an implementation decision as to how that endpoint chooses the new primary address. F13) When an endpoint receives a valid request to DELETE an IP address the endpoint MUST consider the address no longer as part of the association. It MUST NOT send SCTP packets for the association to that address and it MUST treat subsequent packets received from that address as Out Of The Blue. During the time interval between sending out the ASCONF and receiving the ASCONF-ACK it MAY be possible to receive DATA Chunks out of order. The following examples illustrate these problems: F14) All addresses added by the reception of an ASCONF chunk MUST be put into the unconfirmed state and MUST have path verification performed on them before the address can be used as described in [I-D.ietf-tsvwg-2960bis] section 5.4. Endpoint-A Endpoint-Z ---------- ---------- ASCONF[Add-IP:X]------------------------------> /--ASCONF-ACK / /--------/---New DATA: / / Destination <-------------------/ / IP:X / <--------------------------/ In the above example we see a new IP address (X) being added to the Endpoint-A. However due to packet re-ordering in the network a new DATA chunk is sent and arrives at Endpoint-A before the ASCONF-ACK confirming the add of the address to the association. Stewart, et al. Expires December 21, 2007 [Page 28] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 A similar problem exists with the deletion of an IP address as follows: Endpoint-A Endpoint-Z ---------- ---------- /------------New DATA: / Destination / IP:X ASCONF [DEL-IP:X]---------/----------------> <-----------------/------------------ASCONF-ACK / / <-------------/ In this example we see a DATA chunk destined to the IP:X (which is about to be deleted) arriving after the deletion is complete. For the ADD case an endpoint SHOULD consider the newly adding IP address valid for the association to receive data from during the interval when awaiting the ASCONF-ACK. The endpoint MUST NOT source data from this new address until the ASCONF-ACK arrives but it may receive out of order data as illustrated and MUST NOT treat this data as an OOTB datagram (please see [I-D.ietf-tsvwg-2960bis] section 8.4). It MAY drop the data silently or it MAY consider it part of the association but it MUST NOT respond with an ABORT. For the DELETE case, an endpoint MAY respond to the late arriving DATA packet as an OOTB datagram or it MAY hold the deleting IP address for a small period of time as still valid. If it treats the DATA packet as an OOTB the peer will silently discard the ABORT (since by the time the ABORT is sent the peer will have removed the IP address from this association). If the endpoint elects to hold the IP address valid for a period of time, it MUST NOT hold it valid longer than 2 RTO intervals for the destination being removed. 5.3.1. A special case for OOTB ABORT Chunks Another case worth mentioning is illustrated below: Stewart, et al. Expires December 21, 2007 [Page 29] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 Endpoint-A Endpoint-Z ---------- ---------- New DATA:------------\ Source IP:X \ \ ASCONF-REQ[DEL-IP:X]----\------------------> \ /---------ASCONF-ACK \ / \----/-----------> OOTB (Ignored <---------------------/-------------ABORT by rule F4) / <---------------------/ For this case, during the deletion of an IP address, an Abort MUST be ignored if the destination address of the Abort message is that of a destination being deleted. 5.3.2. A special case for changing an address. In some instances the sender may only have one IP address in an association that is being renumbered. When this occurs, the sender may not be able to send to the peer the appropriate ADD/DELETE pair and use the old address as a source in the IP header. For this reason the sender MUST fill in the Address Parameter field with an address that is part of the association (in this case the one being deleted). This will allow the receiver to locate the association without using the source address found in the IP header. The receiver of such a chunk MUST always first use the source address found in the IP header in looking up the association. The receiver should attempt to use the address found in the Address Parameter field only if the lookup fails using the source address from the IP header. The receiver MUST reply to the source address of the packet in this case which is the new address that was added by the ASCONF (since the old address is no longer a part of the association after processing). 5.4. Setting of the primary address A sender of this option MAY elect to send this combined with a deletion or addition of an address. A sender MUST only send a set primary request to an address that is already considered part of the association. In other words if a sender combines a set primary with an add of a new IP address the set primary will be discarded unless the add request is to be processed BEFORE the set primary (i.e., it precedes the set primary). Stewart, et al. Expires December 21, 2007 [Page 30] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 A request to set primary MAY also appear in an INIT or INIT-ACK chunk. This can give advice to the peer endpoint as to which of its addresses the sender of the INIT or INIT-ACK would prefer to be used as the primary address. The request to set an address as the primary path is an option the receiver SHOULD perform. It is considered advice to the receiver of the best destination address to use in sending SCTP packets (in the requester's view). If a request arrives that asks the receiver to set an address as primary that does not exist, the receiver SHOULD NOT honor the request, leaving its existing primary address unchanged. 5.5. Bundling of multiple ASCONFs In the normal case a single ASCONF is sent in a packet and a single reply ASCONF-ACK is received. However, in the event of the loss of an SCTP packet containing either an ASCONF or ASCONF-ACK it is allowable for a sender to bundle additional ASCONFs in the retransmission. In bundling multiple ASCONFs the following rules MUST be followed: 1. Previously transmitted ASCONF Chunks MUST be left unchanged. 2. Each SCTP packet containing ASCONF Chunks MUST be bundled starting with the smallest ASCONF Sequence Number first in the packet (closest to the Chunk header) and preceding in sequential order from lowest to highest ASCONF Sequence Number. 3. All ASCONFs within the packet MUST be adjacent to each other i.e., no other chunk type must separate the ASCONFs. 4. Each new ASCONF lookup address MUST be populated as if the previous ASCONFs had been processed and accepted. 6. Security Considerations The addition and or deletion of an IP address to an existing association does provide an additional mechanism by which existing associations can be hijacked. Therefore this document requires the use of the authentication mechanism defined in [I-D.ietf-tsvwg-sctp-auth] to limit the ability of an attacker to hijack an association. Hijacking an association by using the addition and deletion of an IP address is only possible for an attacker who is able to intercept the initial two packets of the association setup when the SCTP-AUTH extension is used without pre-shared keys. If such a threat is considered a possibility, then the [I-D.ietf-tsvwg-sctp-auth] extension MUST be used with a preconfigured shared end-point pair key to mitigate this threat. For a more detailed analysis see Stewart, et al. Expires December 21, 2007 [Page 31] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 [I-D.ietf-tsvwg-sctp-auth]. When the address parameter in ASCONF chunks with Add, IP Delete IP, or Set Primary IP parameters is a wildcard, the source address of the packet is used. This address is not protected by SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth] and an attacker can therefore intercept such a packet and modify the source address. Even if the source address is not one presently an alternate for the association, the identification of the association may rely on the other information in the packet (perhaps the verification tag, for example). An on- path attacker can therefore modify the source address to its liking. If the ASCONF includes an Add IP with a wildcard address, the attacker can add an address of its liking, which provides little immediate damage but can set up later attacks. If the ASCONF includes a Delete IP with a wildcard address, the attacker can cause all addresses but one of its choosing to be deleted from an association. The address supplied by the attacker must already belong to the association, which makes this more difficult for the attacker. However, the sole remaining address might be one that the attacker controls, for example, or can monitor, etc. The least result is the sender and the deceived receiver would have different ideas of what that sole remaining address would be. This will eventually cause the association to fail, but in the meantime, the deceived receiver could be transmitting packets to an address the sender did not intend. If the ASCONF includes a Set Primary IP with a wildcard address, then the attacker can cause an address to be used as a primary address. This is limited to an address that already belongs to the association, so the damage is limited. At least, the result would be that the recipient is using a primary address that the sender did not intend. However, if both a wildcard Add IP and a wildcard Set Primary IP are used, then the attacker can modify the source address to both add an address to its liking to the association and make it the primary address. Such a combination would present the attacker with opportunity for more damage. Note that all these attacks are from an on-path attacker. Endpoints that believe they face a threat from on-path attackers SHOULD NOT use wildcard addresses in ASCONF Add IP, Delete IP or Set Primary IP parameters. If an SCTP endpoint that supports this extension receives an INIT that indicates that the peer supports the ASCONF extension but does NOT support the [I-D.ietf-tsvwg-sctp-auth] extension, the receiver of such an INIT MUST send an ABORT in response to such an INIT. Note: Stewart, et al. Expires December 21, 2007 [Page 32] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 that an implementation is allowed to silently discard such an INIT as an option as well but under NO circumstance is an implementation allowed to proceed with the association setup by sending an INIT-ACK in response. An implementation that receives an INIT-ACK that indicates that the peer does not support the [I-D.ietf-tsvwg-sctp-auth] extension MUST NOT send the COOKIE-ECHO to establish the association. Instead the implementation MUST discard the INIT-ACK and report to the upper layer user that an association cannot be established destroying the TCB. Other types of attacks, e.g. bombing, are discussed in detail in [I-D.ietf-tsvwg-sctpthreat]. The bombing attack, in particular, is countered by the use of a random nonce and is required by [I-D.ietf-tsvwg-2960bis]. An on-path attacker can modify the INIT and INIT-ACK Supported Extensions parameter (and authentication related parameters) to produce a denial of service. If the on-path attacker removes the [I-D.ietf-tsvwg-sctp-auth] related parameters from an INIT that indicates it supports the ASCONF extension, the association will not be established. If the on-path attacker adds a Supported Extensions parameter mentioning the ASCONF type to an INIT or INIT-ACK that does not carry any AUTH related parameters, the association will not be established. If the on-path attacker removes the Supported Extensions parameter (or removes the ASCONF type from that parameter) from the INIT or the INIT-ACK, then the association will not be able to use the ADD-IP feature. If the on-path attacker adds the Supported Extensions parameter listing the ASCONF type to an INIT-ACK that did not carry one (but did carry AUTH related parameters), then the INIT sender may use ASCONF where the INIT-ACK sender does not support it. This would be discovered later if the INIT sender transmitted an ASCONF, but the INIT sender could have made configuration choices at that point. As the INIT and INIT-ACK are not protected by the AUTH feature, there is no way to counter such attacks. Note however that an on-path attacker capable of modifying the INIT and INIT-ACK would almost certainly also be able to prevent the INIT and INIT-ACK from being delivered or modify the verification tags or checksum to cause the packet to be discarded, so the Supported Extensions adds little additional vulnerability (with respect to preventing association formation) to the SCTP protocol. The ability to prevent the use of this new feature is an additional vulnerability to SCTP but only for this new feature. The Adaptation Layer Indication is subject to corruption, insertion or deletion from the INIT and INIT-ACK chunks by an on-path attacker. This parameter SHOULD be opaque to the SCTP protocol (see section Stewart, et al. Expires December 21, 2007 [Page 33] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 4.2.6), and so changes to the parameter will likely not affect the SCTP protocol. However, any adaptation layer that is defined SHOULD consider its own vulnerabilities in the security considerations section of the RFC that defines its adaptation code point. The Set Primary IP Address parameter is subject to corruption, insertion or deletion by an on-path attacker when included in the INIT and INIT-ACK chunks. The attacker could use this to influence the receiver to choose an address to its own purposes (one over which it has control, one that would be less desirable for the sender, etc.). An on-path attacker would also have the ability to include or remove addresses for the association from the INIT or INIT-ACK, so it is not limited in the address it can specify in the Set Primary IP Address. Endpoints that wish to avoid this possible threat MAY defer sending the initial Set Primary request and wait until the association is fully established before sending a fully protected ASCONF with the Set Primary as its single parameter. 7. IANA considerations This document defines the following new SCTP parameters, chunks and errors (http://www.iana.org/assignments/sctp-parameters): o Two new chunk types, o Six parameter types, and o Five new SCTP error causes. One of the two new chunk types must come from the range of chunk types where the upper two bits are one, we recommend 0xC1 but any other available code point with the upper bits set is also acceptable. The second chunk type must come from the range where only the upper bit is set to one. We recommend 0x80 but any other available code point with the upper bit set is also acceptable. The chunk types with there suggested values are shown below. Chunk Type Chunk Name -------------------------------------------------------------- 0xC1 Address Configuration Change Chunk (ASCONF) 0x80 Address Configuration Acknowledgment (ASCONF-ACK) All of the parameter types, with the exception of the supported parameters extension, must come from the range of types where the upper two bits are set, we recommend 0xC001 - 0xC006, as shown below. The supported parameters type extension must come from the range where only the upper bit is set, we recommend 0x8008. Note: that for Stewart, et al. Expires December 21, 2007 [Page 34] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 any of these values a different unique parameter type may be assigned by IANA as long as the upper bits correspond to the ones specified in this document. The suggested parameter types are listed below: Parameter Type Parameter Name ------------------------------------------------- 0x8008 Supported Extensions 0xC001 Add IP Address 0xC002 Delete IP Address 0xC003 Error Cause Indication 0xC004 Set Primary Address 0xC005 Success Indication 0xC006 Adaptation Layer Indication The five new error causes can be any value, in this document we have used 0x0100-0x0104 in an attempt to separate these from the common ranges of error codes. Any other unassigned values are also acceptable. The suggested error causes are listed below:. Cause Code Value Cause Code --------- ---------------- 0x0100 Request to Delete Last Remaining IP Address. 0x0101 Operation Refused Due to Resource Shortage. 0x0102 Request to Delete Source IP Address. 0x0103 Association Aborted due to illegal ASCONF-ACK 0x0104 Request refused - no authorization. This document also defines an Adaptation code point. The adaptation code point is a 32 bit integer that is assigned by IANA through an IETF Consensus action as defined in [RFC2434]. For this new registry no initial values are being added by this document, however draft-ietf-rddp-sctp will add the first entry. 8. Acknowledgments The authors would like to express a special note of thanks to Michael Ramahlo and Phillip Conrad for their extreme efforts in the early formation of this draft. The authors wish to thank Jon Berger, Mark Butler, Lars Eggert, Janardhan Iyengar, Greg Kendall, Seok Koh, Salvatore Loreto, Peter Lei, John Loughney, Sandy Murphy, Ivan Arias Rodriguez, Renee Revis, Stewart, et al. Expires December 21, 2007 [Page 35] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 Marshall Rose, Ronnie Sellars, Chip Sharp, and Irene Ruengeler for their invaluable comments. The authors would also like to give special mention to Maria-Carmen Belinchon and Ian Rytina for there early contributions to this document and their thoughtful comments. And a special thanks to James Polk, abstract writer to the few but lucky. 9. References 9.1. Normative References [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels&"work in progress." This Internet-Draft will expire on December 10, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Eckert, et al. Expires December 10, 2018 [Page 1] Internet-Draft An Autonomic Control Plane (ACP) June 2018 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 7 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . 9 3. Use Cases for an Autonomic Control Plane . . . . . . . . . . 14 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 14 3.2. Secure Bootstrap over a not configured Network . . . . . 14 3.3. Data-Plane Independent Permanent Reachability . . . . . . 15 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 18 6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 19 6.1.1. Certificate Domain Information Field . . . . . . . . 20 6.1.2. ACP domain membership check . . . . . . . . . . . . . 22 6.1.3. Certificate Maintenance . . . . . . . . . . . . . . . 23 6.1.3.1. GRASP objective for EST server . . . . . . . . . 23 6.1.3.2. Renewal . . . . . . . . . . . . . . . . . . . . . 25 6.1.3.3. Certificate Revocation Lists (CRLs) . . . . . . . 25 6.1.3.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 26 6.1.3.5. Re-enrollment . . . . . . . . . . . . . . . . . . 26 6.1.3.6. Failing Certificates . . . . . . . . . . . . . . 27 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 28 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 29 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 32 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 32 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 34 6.7. Security Association protocols . . . . . . . . . . . . . 34 6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 34 6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 34 6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 35 6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 36 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 36 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 36 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 37 6.8.2. ACP as the Security and Transport substrate for GRASP 37 6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 39 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 40 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 41 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 41 Eckert, et al. Expires December 10, 2018 [Page 2] Internet-Draft An Autonomic Control Plane (ACP) June 2018 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 42 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 43 6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 45 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 46 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 47 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 48 6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 48 6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 48 6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 49 6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 50 6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 51 6.10.7.5. Further Details . . . . . . . . . . . . . . . . 51 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 51 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 52 6.11.1.1. Summary . . . . . . . . . . . . . . . . . . . . 52 6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 53 6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 53 6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 53 6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 54 6.11.1.6. Objective Function . . . . . . . . . . . . . . . 54 6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 54 6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 54 6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 54 6.11.1.10. P2P communications . . . . . . . . . . . . . . . 54 6.11.1.11. IPv6 address configuration . . . . . . . . . . . 54 6.11.1.12. Administrative parameters . . . . . . . . . . . 55 6.11.1.13. RPL Data-Plane artifacts . . . . . . . . . . . . 55 6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 55 6.12. General ACP Considerations . . . . . . . . . . . . . . . 55 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 56 6.12.2. Addressing of Secure Channels in the Data-Plane . . 56 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 56 6.12.4. Multiple links between nodes . . . . . . . . . . . . 57 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 57 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 60 7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 61 8. Support for Non-ACP Components (Normative) . . . . . . . . . 63 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 63 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 63 8.1.2. Software Components . . . . . . . . . . . . . . . . . 65 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 66 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 67 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 68 8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 69 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 69 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 71 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 71 Eckert, et al. Expires December 10, 2018 [Page 3] Internet-Draft An Autonomic Control Plane (ACP) June 2018 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 71 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 71 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 73 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 73 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 74 9.3. The Administrator View . . . . . . . . . . . . . . . . . 74 10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 75 10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 75 10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 80 10.2.1. Registrar interactions . . . . . . . . . . . . . . . 80 10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 82 10.2.3. Certificate renewal and limitations . . . . . . . . 82 10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 83 10.2.5. Centralized Policy Control . . . . . . . . . . . . . 84 10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 84 10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 85 10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 85 10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 86 10.3.2.2. Fast state propagation and Diagnostics . . . . . 86 10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 87 10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 88 10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 88 10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 88 10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 90 10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 90 10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 91 10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 91 10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 92 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 94 14.1. Initial version . . . . . . . . . . . . . . . . . . . . 94 14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 95 14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 95 14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 95 14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 95 14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 96 14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 96 14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 96 14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 97 14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 97 14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 97 14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 98 14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 98 14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 100 14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 102 14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 104 Eckert, et al. Expires December 10, 2018 [Page 4] Internet-Draft An Autonomic Control Plane (ACP) June 2018 14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 105 14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 106 14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 107 14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 109 14.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 113 14.22. draft-ietf-anima-autonomic-control-plane-16 . . . . . . 113 14.23. wish-list . . . . . . . . . . . . . . . . . . . . . . . 114 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 114 15.1. Normative References . . . . . . . . . . . . . . . . . . 115 15.2. Informative References . . . . . . . . . . . . . . . . . 117 Appendix A. Background and Futures (Informative) . . . . . . . . 121 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 122 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 122 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 123 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 124 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 124 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 124 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 125 A.5. ACP Information Distribution and multicast . . . . . . . 126 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 127 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 129 A.8. Adopting ACP concepts for other environments . . . . . . 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 132 1. Introduction Autonomic Networking is a concept of self-management: Autonomic functions self-configure, and negotiate parameters and settings across the network. [RFC7575] defines the fundamental ideas and design goals of Autonomic Networking. A gap analysis of Autonomic Networking is given in [RFC7576]. The reference architecture for Autonomic Networking in the IETF is specified in the document [I-D.ietf-anima-reference-model] Autonomic functions need an autonomically built communications infrastructure. This infrastructure needs to be secure, resilient and re-usable by all autonomic functions. Section 5 of [RFC7575] introduces that infrastructure and calls it the Autonomic Control Plane (ACP). More descriptively it would be the "Autonomic communications infrastructure for Management and Control". For naming consistency with that prior document, this document continues to use the name ACP though. Today, the management and control plane of networks typically uses a routing and forwarding table which is dependent on correct configuration and routing. Misconfigurations or routing problems can therefore disrupt management and control channels. Traditionally, an out-of-band network has been used to avoid or allow recovery from Eckert, et al. Expires December 10, 2018 [Page 5]quot;, BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [I-D.ietf-tsvwg-2960bis] Stewart, R., "Stream Control Transmission Protocol", draft-ietf-tsvwg-2960bis-05 (work in progress), June 2007. [I-D.ietf-tsvwg-sctp-auth] Tuexen, M., "Authenticated Chunks for Stream Control Transmission Protocol (SCTP)", draft-ietf-tsvwg-sctp-auth-08 (work in progress), February 2007. 9.2. Informative References [I-D.ietf-tsvwg-sctpthreat] Stewart, R., "Security Attacks Found Against SCTP and Current Countermeasures", draft-ietf-tsvwg-sctpthreat-05 (work in progress), June 2007. Stewart, et al. Expires December 21, 2007 [Page 36] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 Appendix A. Abstract Address Handling A.1. General remarks This appendix is non-normative. It is present to give the reader a concise mathematical definition of an SCTP endpoint. The following text provides a working definition of the endpoint notion to discuss address reconfiguration. It is not intended to restrict implementations in any way, its goal is to provide a set of definitions only. Using these definitions should make a discussion about address issues easier. A.2. Generalized endpoints A generalized endpoint is a pair of a set of IP addresses and a port number at any given point of time. The precise definition is as follows: A generalized endpoint gE at time t is given by gE(t) = ({IP1, ..., IPn}, Port) where {IP1, ..., IPn} is a non empty set of IP addresses. Please note that the dynamic addition and deletion of IP-addresses described in this document allows the set of IP-addresses of a generalized endpoint to be changed at some point of time. The port number can never be changed. The set of IP addresses of a generalized endpoint gE at a time t is defined as Addr(gE)(t) = {IP1, ..., IPn} if gE(t) = ({IP1, ..., IPn}, Port) holds at time t. The port number of a generalized endpoint gE is defined as Port(gE) = Port if gE(t) = ({IP1, ..., IPn}, Port) holds at time t. There is one fundamental rule which restricts all generalized endpoints: For two different generalized endpoints gE' and gE'' with the same port number Port(gE') = Port(gE'') the address sets Addr(gE')(t) and Addr(gE'')(t) must be disjoint at every point of time. Stewart, et al. Expires December 21, 2007 [Page 37] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 A.3. Associations Associations consists of two generalized endpoints and the two address sets known by the peer at any time. The precise definition is as follows: An association A between to different generalized endpoints gE' and gE'' is given by A = (gE', S', gE'', S'') where S'(t) and S''(t) are set of addresses at any time t such that S'(t) is a non-empty subset of Addr(gE')(t) and S''(t) is a non-empty subset of Addr(gE'')(t). If A = (gE', S', gE'', S'') is an association between the generalized endpoints gE' and gE'' the following notion is used: Addr(A, gE') = S' and Addr(A, gE'') = S''. If the dependency on time is important the notion Addr(A, gE')(t) = S'(t) will be used. If A is an association between gE' and gE'' then Addr(A, gE') is the subset of IP addresses of gE' which is known by gE'' and used by gE'. Association establishment between gE' and gE'' can be seen as: 1. gE' and gE'' do exist before the association. 2. If an INIT has to be send from gE' to gE'' address scoping rules and other limitations are applied to calculate the subset S' from Addr(gE'). The addresses of S' are included in the INIT chunk. 3. If an INIT-ACK has to be send from gE'' to gE' address scoping rules and other limitations are applied to calculate the subset S'' from Addr(gE''). The addresses of S'' are included in the INIT-ACK chunk. 4. After the handshake the association A = (gE', S', gE'', S'') has been established. 5. Right after the association establishment Addr(A, gE') and Addr(A, gE'') are the addresses which have been seen on the wire during the handshake. A.4. Relationship with RFC 4960 [I-D.ietf-tsvwg-2960bis] defines the notion of an endpoint. This subsection will show that these endpoints are also (special) generalized endpoints. Stewart, et al. Expires December 21, 2007 [Page 38] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 [I-D.ietf-tsvwg-2960bis] has no notion of address scoping or other address handling limitations and provides no mechanism to change the addresses of an endpoint. This means that an endpoint is simply a generalized endpoint which does not depend on the time. Neither the Port nor the address list changes. During association setup no address scoping rules or other limitations will be applied. This means that for an association A between two endpoints gE' and gE'' the following is true: Addr(A, gE') = Addr(gE') and Addr(A, gE'') = Addr(gE'& Internet-Draft An Autonomic Control Plane (ACP) June 2018 such problems, or personnel are sent on site to access devices through out-of-band management ports (also called craft ports, serial console, management ethernet port). However, both options are expensive. In increasingly automated networks either centralized management systems or distributed autonomic service agents in the network require a control plane which is independent of the configuration of the network they manage, to avoid impacting their own operations through the configuration actions they take. This document describes a modular design for a self-forming, self- managing and self-protecting Autonomic Control Plane (ACP), which is a virtual in-band network designed to be as independent as possible of configuration, addressing and routing problems. The details how this achieved are defined in Section 6. The ACP is designed to remains operational even in the presence of configuration errors, addressing or routing issues, or where policy could inadvertently affect connectivity of both data packets or control packets. This document uses the term "Data-Plane" to refer to anything in the network nodes that is not the ACP, and therefore considered to be dependent on (mis-)configuration. This Data-Plane includes both the traditional forwarding-plane, as well as any pre-existing control- plane, such as routing protocols that establish routing tables for the forwarding plane. The Autonomic Control Plane serves several purposes at the same time: 1. Autonomic functions communicate over the ACP. The ACP therefore supports directly Autonomic Networking functions, as described in [I-D.ietf-anima-reference-model]. For example, Generic Autonomic Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely inside the ACP and depends on the ACP as its "security and transport substrate". 2. A controller or network management system can use it to securely bootstrap network devices in remote locations, even if the network in between is not yet configured; no Data-Plane dependent bootstrap configuration is required. An example of such a secure bootstrap process is described in [I-D.ietf-anima-bootstrapping-keyinfra] 3. An operator can use it to log into remote devices, even if the network is misconfigured or not configured. This document describes these purposes as use cases for the ACP in Section 3, it defines the requirements in Section 4. Section 5 gives Eckert, et al. Expires December 10, 2018 [Page 6] Internet-Draft An Autonomic Control Plane (ACP) June 2018 an overview how the ACP is constructed, and in Section 6 the process is defined in detail. Section 7 defines how to support ACP on L2 switches. Section 8 explains how non-ACP nodes and networks can be integrated. The following sections are non-normative: Section 9 reviews benefits of the ACP (after all the details have been defined), Section 10 provides operational recommendations, Appendix A provides additional explanations and describes additional details or future work possibilities that where considered not to be appropriate for standardization in this document but were considered important to document. The ACP provides secure IPv6 connectivity, therefore it can not only be used as the secure connectivity for self-management as required for the ACP in [RFC7575], but it can also be used as the secure connectivity for traditional (centralized) management. The ACP can be implemented and operated without any other components of autonomic networks, except for the GRASP protocol which it leverages. The document "Using Autonomic Control Plane for Stable Connectivity of Network OAM" [RFC8368] describes how the ACP alone can be used to provide secure and stable connectivity for autonomic and non- autonomic Operations Administration and Management (OAM) applications. That document also explains how existing management solutions can leverage the ACP in parallel with traditional management models, when to use the ACP and how to integrate with potentially IPv4 only OAM backends. Combining ACP with Bootstrapping Remote Secure Key Infrastructures (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the "Autonomic Network Infrastructure" as defined in [I-D.ietf-anima-reference-model], which provides autonomic connectivity (from ACP) with fully secure zero-touch (automated) bootstrap from BRSKI. The ANI itself does not constitute an Autonomic Network, but it allows the building of more or less autonomic networks on top of it - using either centralized, Software Defined Networking (SDN) (see [RFC7426]), style automation or distributed automation via Autonomic Service Agents (ASA) / Autonomic Functions (AF) - or a mixture of both. See [I-D.ietf-anima-reference-model] for more information. 1.1. Applicability and Scope Please see the following Terminology section (Section 2) for explanations of terms used in this section. Eckert, et al. Expires December 10, 2018 [Page 7] Internet-Draft An Autonomic Control Plane (ACP) June 2018 The design of the ACP as defined in this document is considered to be applicable to all types of "professionally managed" networks: Service Provider, Local Area Network (LAN), Metro(politan networks), Wide Area Network (WAN), Enterprise Information Technology (IT) and Operational Technology (OT) networks. The ACP can operate equally on layer 3 equipment and on layer 2 equipment such a bridges (see Section 7). The encryption mechanism used by the ACP is defined to be negotiable, therefore it can be extended to environments with different encryption protocol preferences. The minimum implementation requirements in this document attempt to achieve maximum interoperability by requiring support for few options: IPsec, DTLS - depending on type of device. The implementation footprint of the ACP consists of Public Key Infrastructure (PKI) code for the ACP certificate, the GRASP protocol, UDP, TCP and TLS (for security and reliability of GRASP), the ACP secure channel protocol used (such as IPsec or DTLS), and an instance of IPv6 packet forwarding and routing via the RPL routing protocol ([RFC6550]) that is separate from routing and forwarding for the Data-Plane (user traffic). The ACP uses only IPv6 to avoid complexity of dual-stack ACP operations (IPv6/IPv4). Nevertheless, it can without any changes be integrated into even otherwise IPv4-only network devices. The Data- Plane itself would not need to change, it could continue to be IPv4 only. For such IPv4 only devices, the IPv6 protocol itself would be additional implementation footprint only used for the ACP. The protocol choices of the ACP are primarily based on wide use and support in networks and devices, well understood security properties and required scalability. The ACP design is an attempt to produce the lowest risk combination of existing technologies and protocols to build a widely applicable operational network management solution: RPL was chosen because it requires a smaller routing table footprint in large networks compared to other routing protocols with an autonomically configured single area. The deployment experience of large scale Internet of Things (IoT) networks serves as the basis for wide deployment experience with RPL. The profile chosen for RPL in the ACP does not not leverage any RPL specific forwarding plane features (IPv6 extension headers), making its implementation a pure control plane software requirement. GRASP is the only completely novel protocol used in the ACP, and this choice was necessary because there is no existing suitable protocol to provide the necessary functions to the ACP, so GRASP was developed to fill that gap. Eckert, et al. Expires December 10, 2018 [Page 8] Internet-Draft An Autonomic Control Plane (ACP) June 2018 The ACP design can be applicable to (cpu, memory) constrained devices and (bitrate, reliability) constrained networks, but this document does not attempt to define the most constrained type of devices or networks to which the ACP is applicable. RPL and DTLS are two protocol choices already making ACP more applicable to constrained environments. See Appendix A.8 for discussions about how variations of the ACP could be defined in the future to better meet different expectations from those on which the current design is based. 2. Acronyms and Terminology In the rest of the document we will refer to systems using the ACP as "nodes". Typically such a node is a physical (network equipment) device, but it can equally be some virtualized system. Therefore, we do not refer to them as devices unless the context specifically calls for a physical system. This document introduces or uses the following terms (sorted alphabetically). Terms introduced are explained on first use, so this list is for reference only. ACP: "Autonomic Control Plane". The Autonomic Function as defined in this document. It provides secure zero-touch (automated) transitive (network wide) IPv6 connectivity for all nodes in the same ACP domain as well as a GRASP instance running across this ACP IPv6 connectivity. The ACP is primarily meant to be used as a component of the ANI to enable Autonomic Networks but it can equally be used in simple ANI networks (with no other Autonomic Functions) or completely by itself. ACP address: An IPv6 address assigned to the ACP node. It is stored in the domain information field of the ->"ACP domain certificate" (). ACP address range/set: The ACP address may imply a range or set of addresses that the node can assign for different purposes. This address range/set is derived by the node from the format of the ACP address called the "addressing sub-scheme". ACP connect interface: An interface on an ACP node providing access to the ACP for non ACP capable nodes without using an ACP secure channel. See Section 8.1.1. ACP domain: The ACP domain is the set of nodes with ->"ACP domain certificates" that allow them to authenticate each other as members of the ACP domain. See also Section 6.1.2. Eckert, et al. Expires December 10, 2018 [Page 9] Internet-Draft An Autonomic Control Plane (ACP) June 2018 ACP (ANI/AN) Domain Certificate: A provisioned [RFC5280] certificate (LDevID) carrying the domain information field which is used by the ACP to learn its address in the ACP and to derive and cryptographically assert its membership in the ACP domain. domain information (field): An rfc822Name information element (e.g., field) in the domain certificate in which the ACP relevant information is encoded: the domain name and the ACP address. ACP Loopback interface: The Loopback interface in the ACP VRF that has the ACP address assigned to it. ACP network: The ACP network constitutes all the nodes that have access to the ACP. It is the set of active and transitively connected nodes of an ACP domain plus all nodes that get access to the ACP of that domain via ACP edge nodes. ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the ACP. In the normal/simple case, the ACP has one ULA prefix, see Section 6.10. The ACP routing table may include multiple ULA prefixes if the "rsub" option is used to create addresses from more than one ULA prefix. See Section 6.1.1. The ACP may also include non-ULA prefixes if those are configured on ACP connect interfaces. See Section 8.1.1. ACP secure channel: A security association established hop-by-hop between adjacent ACP nodes to carry traffic of the ACP VRF separated from Data-Plane traffic in-band over the same links as the Data-Plane. ACP secure channel protocol: The protocol used to build an ACP secure channel, e.g., Internet Key Exchange Protocol version 2 (IKEv2) with IPsec or Datagram Transport Layer Security (DTLS). ACP virtual interface: An interface in the ACP VRF mapped to one or more ACP secure channels. See Section 6.12.5. AN "Autonomic Network": A network according to [I-D.ietf-anima-reference-model]. Its main components are ANI, Autonomic Functions and Intent. (AN) Domain Name: An FQDN (Fully Qualified Domain Name) in the domain information field of the Domain Certificate. See Section 6.1.1. ANI (nodes/network): "Autonomic Network Infrastructure". The ANI is the infrastructure to enable Autonomic Networks. It includes ACP, BRSKI and GRASP. Every Autonomic Network includes the ANI, but Eckert, et al. Expires December 10, 2018 [Page 10] Internet-Draft An Autonomic Control Plane (ACP) June 2018 not every ANI network needs to include autonomic functions beyond the ANI (nor intent). An ANI network without further autonomic functions can for example support secure zero-touch (automated) bootstrap and stable connectivity for SDN networks - see [RFC8368]. ANIMA: "Autonomic Networking Integrated Model and Approach". ACP, BRSKI and GRASP are products of the IETF ANIMA working group. ASA: "Autonomic Service Agent". Autonomic software modules running on an ANI device. The components making up the ANI (BRSKI, ACP, GRASP) are also described as ASAs. Autonomic Function: A function/service in an Autonomic Network (AN) composed of one or more ASA across one or more ANI nodes. BRSKI: "Bootstrapping Remote Secure Key Infrastructures" ([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending EST to enable secure zero-touch bootstrap in conjunction with ACP. ANI nodes use ACP, BRSKI and GRASP. Data-Plane: The counterpoint to the ACP VRF in an ACP node: all routing and forwarding in the node other than the ACP VRF. In a simple ACP or ANI node, the Data-Plane is typically provisioned non-autonomic, for example manually (including across the ACP) or via SDN controllers. In a fully Autonomic Network node, the Data- Plane is managed autonomically via Autonomic Functions and Intent. Note that other (non-ANIMA) RFC use the Data-Plane to refer to what is better called the forwarding plane. This is not the way the term is used in this document! device: A physical system, or physical node. Enrollment: The process where a node presents identification (for example through keying material such as the private key of an IDevID) to a network and acquires a network specific identity and trust anchor such as an LDevID. EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard protocol for enrollment of a node with an LDevID. BRSKI is based on EST. GRASP: "Generic Autonomic Signaling Protocol". An extensible signaling protocol required by the ACP for ACP neighbor discovery. The ACP also provides the "security and transport substrate" for the "ACP instance of GRASP". This instance of GRASP runs across the ACP secure channels to support BRSKI and other future Autonomic Functions. See [I-D.ietf-anima-grasp]. Eckert, et al. Expires December 10, 2018 [Page 11] Internet-Draft An Autonomic Control Plane (ACP) June 2018 IDevID: An "Initial Device IDentity" X.509 certificate installed by the vendor on new equipment. Contains information that establishes the identity of the node in the context of its vendor/ manufacturer such as device model/type and serial number. See [AR8021]. IDevID can not be used for the ACP because they are not provisioned by the owner of the network, so they can not directly indicate an ACP domain they belong to. in-band (management): The type of management used predominantly in IP based networks, not leveraging an ->"out-of-band network" (). In in-band management, access to the managed equipment depends on the configuration of this equipment itself: interface, addressing, forwarding, routing, policy, security, management. This dependency makes in-band management fragile because the configuration actions performed may break in-band management connectivity. Breakage can not only be unintentional, it can simply be an unavoidable side effect of being unable to create configuration schemes where in-band management connectivity configuration is unaffected by Data-Plane configuration. See also ->"(virtual) out-of-band network" (). Intent: Policy language of an autonomic network according to [I-D.ietf-anima-reference-model]. Loopback interface: The conventional name for an internal IP interface to which addresses may be assigned, but which transmits no external traffic. LDevID: A "Local Device IDentity" is an X.509 certificate installed during "enrollment". The Domain Certificate used by the ACP is an LDevID. See [AR8021]. MIC: "Manufacturer Installed Certificate". Another word not used in this document to describe an IDevID. native interface: Interfaces existing on a node without configuration of the already running node. On physical nodes these are usually physical interfaces. On virtual nodes their equivalent. node: A system, e.g., supporting the ACP according to this document. Can be virtual or physical. Physical nodes are called devices. Node-ID: The identifier of an ACP node inside that ACP. It is the last 64 (see Section 6.10.3) or 78 bit (see xref target="Vlong"/>) of the ACP address. Eckert, et al. Expires December 10, 2018 [Page 12] Internet-Draft An Autonomic Control Plane (ACP) June 2018 (virtual) out-of-band network: An out-of-band network is a secondary network used to manage a primary network. The equipment of the primary network is connected to the out-of-band network via dedicated management ports on the primary network equipment. Serial (console) management ports where historically most common, higher end network equipment now also has ethernet ports dedicated only for management. An out-of-band network provides management access to the primary network independent of the configuration state of the primary network. One of the goals of the ACP is to provide this benefit of out-of-band networks virtually on the primary network equipment. The ACP VRF acts as a virtual out of band network device providing configuration independent management access. The ACP secure channels are the virtual links of the ACP virtual out-of-band network, meant to be operating independent of the configuration of the primary network. See also ->"in-band (management)" (). RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The routing protocol used in the ACP. See [RFC6550]. MASA (service): "Manufacturer Authorized Signing Authority". A vendor/manufacturer or delegated cloud service on the Internet used as part of the BRSKI protocol. (ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software and/or person) that is orchestrating the enrollment of ACP nodes with the ACP domain certificate. ANI nodes use BRSKI, so ANI registrars are also called BRSKI registrars. For non-ANI ACP nodes, the registrar mechanisms are undefined by this document. See Section 6.10.7. Renewal and other maintenance (such as revocation) of ACP domain certificates may be performed by other entities than registrars. EST must be supported for ACP domain certificate renewal (see Section 6.1.3). BRSKI is an extension of EST, so ANI/BRSKI registrars can easily support ACP domain certificate renewal in addition to initial enrollment. sUDI: "secured Unique Device Identifier". Another term not used in this document to refer to an IDevID. UDI: "Unique Device Identifier". In the context of this document unsecured identity information of a node typically consisting of at least device model/type and serial number, often in a vendor specific format. See sUDI and LDevID. ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 address in the block fc00::/7, defined in [RFC4193]. It is the approximate IPv6 counterpart of the IPv4 private address Eckert, et al. Expires December 10, 2018 [Page 13] Internet-Draft An Autonomic Control Plane (ACP) June 2018 ([RFC1918]). The ULA Global ID prefix are the first 48 bit of a ULA address. In this document it is abbreviated as "ULA prefix". (ACP) VRF: The ACP is modeled in this document as a "Virtual Routing and Forwarding" instance (VRF). This means that it is based on a "virtual router" consisting of a separate IPv6 forwarding table to which the ACP virtual interfaces are attached and an associated IPv6 routing table separate from the Data-Plane. Unlike the VRFs on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF does not have any special "core facing" functionality or routing/ mapping protocols shared across multiple VRFs. In vendor products a VRF such as the ACP-VRF may also be referred to as a so called VRF-lite. (ACP) Zone: An ACP zone is a connected region of the ACP where nodes derive from their non-aggregatable ACP address (identifier address) an aggregatable ACP zone address (locator address). See the definition of the ACP Zone Addressing Sub-Scheme (Section 6.10.3). The complete definition of zones is subject to future work because this document does not describe the routing protocols details for aggregation of ACP zone addresses, but only their addressing scheme. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC8174] when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "should" or "Should"), they have their usual English meanings, and are not to be interpreted as [RFC8174] key words. 3. Use Cases for an Autonomic Control Plane 3.1. An Infrastructure for Autonomic Functions Autonomic Functions need a stable infrastructure to run on, and all autonomic functions should use the same infrastructure to minimize the complexity of the network. This way, there is only need for a single discovery mechanism, a single security mechanism, and other processes that distributed functions require. 3.2. Secure Bootstrap over a not configured Network Today, bootstrapping a new node typically requires all nodes between a controlling node such as an SDN controller ("Software Defined Networking", see [RFC7426]) and the new node to be completely and correctly addressed, configured and secured. Bootstrapping and configuration of a network happens in rings around the controller - Eckert, et al. Expires December 10, 2018 [Page 14] Internet-Draft An Autonomic Control Plane (ACP) June 2018 configuring each ring of devices before the next one can be bootstrapped. Without console access (for example through an out-of- band network) it is not possible today to make devices securely reachable before having configured the entire network leading up to them. With the ACP, secure bootstrap of new devices and whole new networks can happen without requiring any configuration of unconfigured devices along the path: As long as all devices along the path support ACP and a zero-touch bootstrap mechanism like BRSKI, the ACP across a whole network of unconfigured devices can be brought up without operator/provisioning intervention. The ACP also provides additional security for any bootstrap mechanism, because it encrypts the traffic along the path hop-by-hop. 3.3. Data-Plane Independent Permanent Reachability Today, most critical control plane protocols and network management protocols are using the Data-Plane of the network. This leads to often undesirable dependencies between control and management plane on one side and the Data-Plane on the other: Only if the forwarding and control plane of the Data-Plane are configured correctly, will the Data-Plane and the managment plane work as expected. Data-Plane connectivity can be affected by errors and faults, for example misconfigurations that make AAA (Authentication, Authorization and Accounting) servers unreachable or can lock an administrator out of a device; routing or addressing issues can make a device unreachable; shutting down interfaces over which a current management session is running can lock an admin irreversibly out of the device. Traditionally only out-of-band access can help recover from such issues (such as serial console or ethernet management port). Data-Plane dependencies also affect applications in a Network Operations Center (NOC) such as SDN controller applications: Certain network changes are today hard to implement, because the change itself may affect reachability of the devices. Examples are address or mask changes, routing changes, or security policies. Today such changes require precise hop-by-hop planning. Note that specific control plane functions for the Data-Plane often want to depend on forwarding of their packets via the Data-Plane: Aliveness and routing protocol signaling packets across the Data- Plane to verify reachability across the Data-Plane, using IPv4 signaling packets for IPv4 routing vs. IPv6 signaling packets for IPv6 routing. Eckert, et al. Expires December 10, 2018 [Page 15] Internet-Draft An Autonomic Control Plane (ACP) June 2018 The ACP provides reachability that is independent of the Data-Plane (except for the dependency discussed in Section 6.12.2 which can be removed through future work), which allows the control plane and management plane to operate more robustly: o For management plane protocols, the ACP provides the functionality of a Virtual out of Band (VooB) channel, by providing connectivity to all nodes regardless of their Data-Plane configuration, routing and forwarding tables. o For control plane protocols, the ACP allows their operation even when the Data-Plane is temporarily faulty, or during transitional events, such as routing changes, which may affect the control plane at least temporarily. This is specifically important for autonomic service agents, which could affect Data-Plane connectivity. The document "Using Autonomic Control Plane for Stable Connectivity of Network OAM" [RFC8368] explains this use case for the ACP in significantly more detail and explains how the ACP can be used in practical network operations. 4. Requirements The Autonomic Control Plane has the following requirements: ACP1: The ACP SHOULD provide robust connectivity: As far as possible, it should be independent of configured addressing, configuration and routing. Requirements 2 and 3 build on this requirement, but also have value on their own. ACP2: The ACP MUST have a separate address space from the Data- Plane. Reason: traceability, debug-ability, separation from Data-Plane, security (can block easily at edge). ACP3: The ACP MUST use autonomically managed address space. Reason: easy bootstrap and setup ("autonomic"); robustness (admin can't mess things up so easily). This document suggests using ULA addressing for this purpose ("Unique Local Address", see [RFC4193]). ACP4: The ACP MUST be generic. Usable by all the functions and protocols of the ANI. Clients of the ACP MUST NOT be tied to a particular application or transport protocol. ACP5: The ACP MUST provide security: Messages coming through the ACP MUST be authenticated to be from a trusted node, and SHOULD (very strong SHOULD) be encrypted. Eckert, et al. Expires December 10, 2018 [Page 16] Internet-Draft An Autonomic Control Plane (ACP) June 2018 Explanation for ACP4: In a fully autonomic network (AN), newly written ASA could potentially all communicate exclusively via GRASP with each other, and if that was assumed to be the only requirement against the ACP, it would not need to provide IPv6 layer connectivity between nodes, but only GRASP connectivity. Nevertheless, because ACP also intends to support non-AN networks, it it is crucial to support IPv6 layer connectivity across the ACP to support any transport and application layer protocols. Th eACP operates hop-by-hop, because this interaction can be built on IPv6 link local addressing, which is autonomic, and has no dependency on configuration (requirement 1). It may be necessary to have ACP connectivity across non-ACP nodes, for example to link ACP nodes over the general Internet. This is possible, but introduces a dependency against stable/resilient routing over the non-ACP hops (see Section 8.2). 5. Overview The Autonomic Control Plane is constructed in the following way (for details, see Section 6): 1. An ACP node creates a Virtual Routing and Forwarding (VRF) instance, or a similar virtual context. 2. It determines, following a policy, a candidate peer list. This is the list of nodes to which it should establish an Autonomic Control Plane. Default policy is: To all link-layer adjacent nodes supporting ACP. 3. For each node in the candidate peer list, it authenticates that node and negotiates a mutually acceptable channel type. 4. For each node in the candidate peer list, it then establishes a secure tunnel of the negotiated type. The resulting tunnels are then placed into the previously set up VRF. This creates an overlay network with hop-by-hop tunnels. 5. Inside the ACP VRF, each node assigns its ULA IPv6 address to a Loopback interface assigned to the ACP VRF. 6. Each node runs a lightweight routing protocol, to announce reachability of the virtual addresses inside the ACP (see Section 6.12.5). Note: Eckert, et al. Expires December 10, 2018 [Page 17] Internet-Draft An Autonomic Control Plane (ACP) June 2018 o Non-autonomic NMS ("Network Management Systems") or SDN controllers have to be explicitly configured for connection into the ACP. o Connecting over non-ACP Layer-3 clouds requires explicit configuration. See Section 8.2. This may be automated in the future through auto discovery mechanisms across L3. o None of the above operations (except explicit configured ones) are reflected in the configuration of the node. The following figure illustrates the ACP. ACP node 1 ACP node 2 ................... ................... secure . . secure . . secure channel: +-----------+ : channel : +-----------+ : channel ..--------| ACP VRF |---------------------| ACP VRF |---------.. : / \ / \ <--routing--> / \ / \ : : \ / \ / \ / \ / : ..--------| Loopback |---------------------| Loopback |---------.. : | interface | : : | interface | : : +-----------+ : : +-----------+ : : : : : : Data-Plane :...............: Data-Plane : : : link : : :.................: :.................: Figure 1: ACP VRF and secure channels The resulting overlay network is normally based exclusively on hop- by-hop tunnels. This is because addressing used on links is IPv6 link local addressing, which does not require any prior set-up. This way the ACP can be built even if there is no configuration on the node, or if the Data-Plane has issues such as addressing or routing problems. 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) This section describes the components and steps to set up an Autonomic Control Plane (ACP), and highlights the key properties which make it "indestructible" against many inadvertent changes to the Data-Plane, for example caused by misconfigurations. An ACP node can be a router, switch, controller, NMS host, or any other IP capable node. Initially, it must have its ACP domain certificate, as well as an (empty) ACP Adjacency Table (described in Eckert, et al. Expires December 10, 2018 [Page 18] Internet-Draft An Autonomic Control Plane (ACP) June 2018 Section 6.2). It then can start to discover ACP neighbors and build the ACP. This is described step by step in the following sections: 6.1. ACP Domain, Certificate and Network The ACP relies on group security. An ACP domain is a group of nodes that trust each other to participate in ACP operations. To establish trust, each ACP member requires keying material: An ACP node MUST have a certificate (LDevID) and a Trust Anchor (TA) consisting of a certificate (chain) used to sign the LDevID of all ACP domain members. The LDevID is used to cryptographically authenticate the membership of its owner node in the ACP domain to other ACP domain members, the TA is used to authenticate the ACP domain membership of other nodes (see Section 6.1.2). The LDevID is called the ACP domain certificate, the TA is the Certificate Authority (CA) of the ACP domain. The ACP does not mandate specific mechanisms by which this keying material is provisioned into the ACP node, it only requires the Domain information field as specified in Section 6.1.1 in its domain certificate as well as those of candidate ACP peers. See Appendix A.2 for more information about enrollment or provisioning options. This document uses the term ACP in many places where the Autonomic Networking reference documents [RFC7575] and [I-D.ietf-anima-reference-model] use the word autonomic. This is done because those reference documents consider (only) fully autonomic networks and nodes, but support of ACP does not require support for other components of autonomic networks. Therefore the word autonomic might be misleading to operators interested in only the ACP: [RFC7575] defines the term "Autonomic Domain" as a collection of autonomic nodes. ACP nodes do not need to be fully autonomic, but when they are, then the ACP domain is an autonomic domain. Likewise, [I-D.ietf-anima-reference-model] defines the term "Domain Certificate" as the certificate used in an autonomic domain. The ACP domain certificate is that domain certificate when ACP nodes are (fully) autonomic nodes. Finally, this document uses the term ACP network to refer to the network created by active ACP nodes in an ACP domain. The ACP network itself can extend beyond ACP nodes through the mechanisms described in Section 8.1). The ACP domain certificate can and should be used for any authentication between ACP nodes where the required security is domain membership. Section 6.1.2 defines this "ACP domain membership Eckert, et al. Expires December 10, 2018 [Page 19] Internet-Draft An Autonomic Control Plane (ACP) June 2018 check". The uses of this check that are standardized in this document are for the establishment of ACP secure channels (Section 6.6) and for ACP GRASP (Section 6.8.2). Other uses are subject to future work, but it is recommended that it is the default security check for any end-to-end connections between ASA. It is equally useable by other functions such as legacy OAM functions. 6.1.1. Certificate Domain Information Field Information about the domain MUST be encoded in the domain certificate in a subjectAltName / rfc822Name field according to the following ABNF definition ([RFC5234]): [RFC Editor: Please substitute SELF in all occurences of rfcSELF in this document with the RFC number assigned to this document and remove this comment line] domain-information = local-part "@" acp-domain-name local-part = key [ "." local-info ] key = "rfcSELF" local-info = [ acp-address ] [ "+" rsub extensions ] acp-address = 32hex-dig hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" rsub = [ <subdomain> ] ; <subdomain> as of RFC1034, section 3.5 routing-subdomain = [ rsub " ." ] acp-domain-name acp-domain-name = ; <domain> ; as of RFC 1034, section 3.5 extensions = *( "+" extension ) extension = ; future definition. ; Must fit RFC5322 simple dot-atom format. Example: domain-information = rfcSELF+fd89b714f3db00000200000064000000 +area51.research@acp.example.com acp-domain-name = acp.example.com routing-subdomain = area51.research.acp.example.com Figure 2: ACP Domain Information Field ABNF "acp-address" MUST be the ACP address of the node. It is optional to support variations of the ACP mechanisms, for example other means for nodes to assign ACP addresses to themselves. Such methods are subject to future work though. Note: "acp-address" cannot use standard IPv6 address formats because it must match the simple dot-atom format of [RFC5322]. ":" are not allowed in that format. Eckert, et al. Expires December 10, 2018 [Page 20] Internet-Draft An Autonomic Control Plane (ACP) June 2018 "acp-domain-name" is used to indicate the ACP Domain across which all ACP nodes trust each other and are willing to build ACP channel to each other. See Section 6.1.2. Acp-domain-name SHOULD be the FQDN of a DNS domain owned by the operator assigning the certificate. This is a simple method to ensure that the domain is globally unique and collision of ACP addresses would therefore only happen due to ULA hash collisions. If the operator does not own any FQDN, it should choose a string (in FQDN format) that intends to be equally unique. "routing-subdomain" is the autonomic subdomain that is used to calculate the hash for the ULA Global ID of the ACP address of the node. "rsub" is optional; its syntax is defined in this document, but its semantics are for further study. Understanding the benefits of using rsub may depend on the results of future work on enhancing routing for the ACP. When "rsub" is not used, "routing-subdomain" is the same as "acp-domain-name". "rsub" needs to be in the "local- part": If the format just had routing-subdomain as the domain part of the domain-information, rsub and acp-domain-name could not be separated from each other. It also makes acp-domain-name a valid e-mail target across all routing-subdomains. The optional "extensions" field is used for future extensions to this specification. It MUST be ignored if present and not understood. In this specification, the "acp-address" field is REQUIRED, but future variations (see Appendix A.8) may use local information to derive the ACP address. In this case, "acp-address" could be empty. Such a variation would be indicated by an appropriate "extension". If "acp-address" is empty, and "rsub" is empty too, the "local-part" will have the format "rfcSELF + + extension(s)". The two plus characters are necessary so the node can unambiguously parse that both "acp-address" and "rsub" are empty. Note that the maximum size of "domain-information" is 254 characters and the maximum size of node-info is 64 characters according to [RFC5280] that is referring to [RFC2821] (superseded by [RFC5321]). The subjectAltName / rfc822Name encoding of the ACP domain name and ACP address is used for the following reasons: o It should be possible to share the LDevID with other uses beside the ACP. Therefore, the information element required for the ACP should be encoded so that it minimizes the possibility of creating incompatibilities with such other uses. o The information for the ACP should not cause incompatibilities with any pre-existing ASN.1 software. This eliminates the Eckert, et al. Expires December 10, 2018 [Page 21] Internet-Draft An Autonomic Control Plane (ACP) June 2018 introduction of a novel information element because that could require extensions to such pre-existing ASN.1 parsers. o subjectAltName / rfc822Name is a pre-existing element that must be supported by all existing ASN.1 parsers for LDevID. o The element required for the ACP should not be misinterpreted by any other uses of the LDevID. If the element used for the ACP is interpreted by other uses, the impact should be benign. o Using an IP address format encoding could result in non-benign misinterpretation of the domain information field; other uses unaware of the ACP could try to do something with the ACP address that would fail to work correctly. For example, the address could be interpreted to be an address of the node which does not belong to the ACP VRF. o At minimum, both the AN domain name and the non-domain name derived part of the ACP address need to be encoded in one or more appropriate fields of the certificate, so there are not many alternatives with pre-existing fields where the only possible conflicts would likely be beneficial. o rfc822Name encoding is quite flexible. We choose to encode the full ACP address AND the domain name with sub part into a single rfc822Name information element it, so that it is easier to examine/use the "domain information field". o The format of the rfc822Name is chosen so that an operator can set up a mailbox called rfcSELF@<domain> that would receive emails sent towards the rfc822Name of any node inside a domain. This is possible because in many modern mail systems, components behind a "+" character are considered part of a single mailbox. In other words, it is not necessary to set up a separate mailbox for every ACP node, but only one for the whole domain. o In result, if any unexpected use of the ACP addressing information in a certificate happens, it is benign and detectable: it would be mail to that mailbox. See section 4.2.1.6 of [RFC5280] for details on the subjectAltName field. 6.1.2. ACP domain membership check The following points constitute the ACP domain membership check of a possible peer certificate, independent of the protocol used: Eckert, et al. Expires December 10, 2018 [Page 22] Internet-Draft An Autonomic Control Plane (ACP) June 2018 o The peer certificate is valid (lifetime). o The peer has proved ownership of the private key associated with the certifictes public key. o The peer's certificate is signed by one of the trust anchors associated with the ACP domain certificate. o If the node certificates indicates a Certificate Revocation List (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or Online Certificate Status Protocol (OCSP) responder ([RFC5280], section 4.2.2.1), then the peer's certificate must be valid according to those criteria: An OCSP check for the peers certificate across the ACP must succeed or the peer certificate must not be listed in the CRL retrieved from the CDP. o The peers certificate has a syntactically valid domain information field (subjectAltName / rfc822Name) and the acp-domain-name in that peers domain information field is the same as in this ACP node certificate. Note that future Intent rules may modify this. See Appendix A.7. 6.1.3. Certificate Maintenance ACP nodes MUST support certificate renewal via EST ("Enrollment over Secure Transport", see [RFC7030]) and MAY support other mechanisms. An ACP network MUST have at least one ACP node supporting EST server functionality across the ACP so that EST renewal is useable. ACP nodes SHOULD be able to remember the EST server from which they last renewed their ACP domain certificate and SHOULD provide the ability for this remembered EST server to also be set by the ACP Registrar (see Section 6.10.7) that initially enrolled the ACP device with its ACP domain certificate. When BRSKI (see [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the ACP address of the BRSKI registrar from the BRSKI TLS connection SHOULD be remembered and used for the next renewal via EST if that registrar also announces itself as an EST server via GRASP (see next section) on its ACP address. 6.1.3.1. GRASP objective for EST server 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], section 2.8.11 for the definition of this message type: Eckert, et al. Expires December 10, 2018 [Page 23] Internet-Draft An Autonomic Control Plane (ACP) June 2018 Example: [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, ["SRV.est", 4, 255 ], [O_IPv6_LOCATOR, h'fd89b714f3db0000200000064000001', TCP, 80] ] Figure 3: GRASP SRV.est example The formal definition of the objective in Concise data definition language (CDDL) (see [I-D.ietf-cbor-cddl]) is as follows: flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] objective = ["SRV.est", objective-flags, loop-count, objective-value] objective-flags = sync-only ; as in GRASP spec sync-only = 4 ; M_FLOOD only requires synchronization loop-count = 255 ; recommended objective-value = ; Not used (yet) Figure 4: GRASP SRV.est definition The objective value "SRV.est" indicates that the objective is an [RFC7030] compliant EST server because "est" is an [RFC6335] registered service name for [RFC7030]. Future backward compatible extensions/alternatives to [RFC7030] may be indicated through objective-value. Future non-backward compatible certificate renewal options must use a different objective-name. The M_FLOOD message MUST be sent periodically. The default SHOULD be 60 seconds, the value SHOULD be operator configurable but SHOULD be not smaller than 60 seconds. The frequency of sending MUST be such that the aggregate amount of periodic M_FLOODs from all flooding sources causes only negligible traffic across the ACP. The ttl parameter SHOULD be 3.5 times the period so that up to three consecutive messages can be dropped before considering an announcement expired. In the example above, the ttl is 210000 msec, 3.5 times 60 seconds. When a service announcer using these parameters unexpectedly dies immediately after sending the M_FLOOD, receivers would consider it expired 210 seconds later. When a receiver tries to connect to this dead service before this timeout, it will experience a failing connection and use that as an indication Eckert, et al. Expires December 10, 2018 [Page 24] Internet-Draft An Autonomic Control Plane (ACP) June 2018 #x27;). A.5. Rules for address manipulation The rules for address manipulation can now be stated in a simple way: 1. An address can be added to a generalized endpoint gE only if this address is not an address of a different generalized endpoint with the same port number. 2. An address can be added to an association A with generalized endpoint gE if it has been added to the generalized endpoint gE first. This means that the address must be an element of Addr(gE) first and then it can become an element of Addr(A, gE). But this is not necessary. If the association does not allow the reconfiguration of the addresses only Addr(gE) can be modified. 3. An address can be deleted from an association A with generalized endpoint gE as long as Addr(A, gE) stays non-empty. 4. An address can be deleted from an generalized endpoint gE only if it has been removed from all associations having gE as a generalized endpoint. These rules simply make sure that the rules for the endpoints and associations given above are always fulfilled. Authors' Addresses Randall R. Stewart Cisco Systems, Inc. 4875 Forest Drive Suite 200 Columbia, SC 29206 US Phone: Email: rrs@cisco.com Stewart, et al. Expires December 21, 2007 [Page 39] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, #2309 Arlington Heights, IL 60004 USA Phone: +1-847-632-3028 Email: qxie1@email.mot.com Michael Tuexen Univ. of Applied Sciences Muenster Stegerwaldstr. 39 48565 Steinfurt Germany Email: tuexen@fh-muenster.de Shin Maruyama Kyoto University Yoshida-Honmachi Sakyo-ku Kyoto, Kyoto 606-8501 JAPAN Phone: +81-75-753-7468 Email: mail@marushin.gr.jp Masahiro Kozuka Kyoto University Yoshida-Honmachi Sakyo-ku Kyoto, Kyoto 606-8501 JAPAN Phone: +81-75-753-7468 Email: ma-kun@kozuka.jp Stewart, et al. Expires December 21, 2007 [Page 40] Internet-Draft SCTP Dynamic Address Reconfiguration June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Stewart, et al. Expires December 21, 2007 [Page 41]