Independent Submission S. Vinapamula Request for Comments: 7767 Juniper Networks Category: Informational S. Sivakumar ISSN: 2070-1721 Cisco Systems M. Boucadair Orange T. Reddy Cisco February 2016 Application-Initiated Check-Pointing via the Port Control Protocol (PCP)
AbstractThis document specifies a mechanism for a host to indicate via the Port Control Protocol (PCP) which connections should be protected against network failures. These connections will then be subject to high-availability mechanisms enabled on the network side. This approach assumes that applications and/or users have more visibility about sensitive connections than any heuristic that can be enabled on the network side to guess which connections should be check-pointed. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7767.
Copyright Notice Copyright (c) 2016 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 (http://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. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Note . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Issues with the Existing Implementations . . . . . . . . . . 4 3. CHECKPOINT_REQUIRED PCP Option . . . . . . . . . . . . . . . 4 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Sample Use Cases . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Additional Considerations . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Section 2.
Heuristics based on the protocol, mapping lifetime, etc., are used in the network to elect which connections need to be check-pointed (e.g., by means of high-availability (HA) techniques). This document advocates for an application-initiated approach that would allow applications and/or users to signal to the network which of their connections are critical. Within this document, "check-pointing" refers to a process of state replication and synchronization between active and backup PCP- controlled devices. When the active PCP-controlled device fails, the backup PCP-controlled device will take over all the existing established sessions that were check-pointed. This process is transparent to internal hosts. This document specifies how PCP [RFC6887] can be extended to indicate which connection should be check-pointed for high availability (Section 3). A set of use cases are provided for illustrative purposes in Section 4. This document does not make any assumptions about the PCP-controlled device that will process the PCP-formatted signaling information from PCP clients. These devices are likely to be flow aware. The approach in this document is aligned with the networking trends advocating for open network APIs to interact with applications/ services (e.g., [RFC7149]). For instance, the decision-making process about policy on the network side will be enriched with information provided by applications using PCP. Section 3) is defined in the "Specification Required" range (see Section 6). In order to be assigned a code point in that range, a permanent publication is required as per Section 4.1 of [RFC5226]. Publication of an RFC is an ideal means of achieving this requirement and also to ease interoperability. Note, this work was presented to the Port Control Protocol (PCP) WG, but there was no consensus to define this option in the "Standards Action" range despite positive feedback that was received from the working group. Technical comments that were received during PCP meetings and those received on the mailing list were addressed. RFC2119].
The entry to be backed up is indicated by the content of a MAP or PEER message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Option Code=192| Reserved | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Name: CHECKPOINT_REQUIRED Number: 192 Purpose: Indicate if an entry needs to be check-pointed. Valid for Opcodes: MAP, PEER Length: 0. May appear in: Request and response. Maximum occurrences: 1. Figure 1: CHECKPOINT_REQUIRED PCP Option The description of the fields is as follows: o Option Code: 192 (see Section 6). o Reserved: This field is initialized as specified in Section 7.3 of [RFC6887]. o Option Length: 0. This means no data is included in the option. An application or user can take advantage of this PCP option to explicitly indicate which of the connections need to be check-pointed and should not be disrupted. The processing of this option by the PCP server will then yield the check-pointing of the corresponding states by the relevant devices or functions dynamically controlled by the PCP server. Communication between application/user and PCP client is implementation specific. Figure 1) may be included in a PCP MAP or PEER request to indicate a connection is to be protected against network failures. There is a risk that every PCP client may wish to check-point every connection; this can potentially load the system. Administration SHOULD restrict the number of connections that can be elected to be
backed up and the rate of check-pointing per network attachment point (e.g., Customer Premises Equipment (CPE), host). To that aim, the PCP server should unambiguously identify the network attachment point a PCP client belongs to. For example, the PCP server may rely on the PCP identity [RFC7652], the assigned prefix to a CPE or host, the subscriber-mask [PREFIX-BINDING], or other identification means. The PCP client includes a CHECKPOINT_REQUIRED option in a MAP or PEER request to signal that the corresponding mapping is to be protected. If the PCP client does not receive a CHECKPOINT_REQUIRED option in response to a PCP request that enclosed the CHECKPOINT_REQUIRED option, this means that either the PCP server does not support the option, or the PCP server is configured to ignore the option, or the PCP server cannot satisfy the request expressed in this option (e.g., because of a lack of resources). If the CHECKPOINT_REQUIRED option is not included in the PCP client request, the PCP server MUST NOT include the CHECKPOINT_REQUIRED option in the associated response. When the PCP server receives a CHECKPOINT_REQUIRED option, the PCP server checks if it can honor this request depending on whether resources are available for check-pointing. If there are no resources available for check-pointing, but there are resources available to honor the MAP or PEER request, a response is sent back to the PCP client without including the CHECKPOINT_REQUIRED option (i.e., the request is processed as any MAP or PEER request that does not convey a CHECKPOINT_REQUIRED option). If check-pointing resources are still available and the quota for this PCP client has not been reached, the PCP server tags the corresponding entry as eligible to the HA mechanism and sends back the CHECKPOINT_REQUIRED option in the positive answer to the PCP client. To update the check-pointing behavior of a mapping maintained by the PCP server, the PCP client generates a PCP MAP or PEER renewal request that includes a CHECKPOINT_REQUIRED option to indicate this mapping has to be check-pointed or that doesn't include a CHECKPOINT_REQUIRED option to indicate this mapping does not need be check-pointed anymore. Upon receipt of the PCP request, the PCP server proceeds with the same operations to validate a MAP or PEER request to update an existing mapping. If validation checks are passed, the PCP server updates the check-point flag associated with that mapping accordingly (i.e., it is set if a CHECKPOINT_REQUIRED option was included in the update request or it is cleared if no CHECKPOINT_REQUIRED option was included), and the PCP server returns the response to the PCP client accordingly.
What information to check-point and how to check-point are outside the scope of this document and are left for implementations. Also, the mechanism for users or applications to indicate check-pointing in a PCP request may be automatic, semiautomatic, or require human intervention. This behavior is also left for application implementations. For managed CPEs, a service provider may influence what connections are to be check-pointed. For honored requests, it is RECOMMENDED to check-point state on backup before a response is sent to the PCP client.
* None of the flows associated with a bronze subscription are check-pointed. When a user invokes the streaming service, he/she may fall into one of those buckets, and according to the configured policy, his/ her associated streaming flows are automatically check-pointed. Login credentials can be used as a trigger to determine the subscription level (and therefore the associated check-pointing behavior). Example 3: Consider a VoIP application that is able to request that its flows be check-pointed. No matter what is configured by the user, some calls such as emergency calls should be check-pointed. The application has to identify such calls. Example 4: In the context of an enterprise network, applications are customized by the administrator. Instructions about whether a CHECKPOINT_REQUIRED option is to be included are determined by the administrator. Only the subset of applications identified by the administrator will make use of this option in conformance with the enterprise network's management policies. Any misbehavior can be considered as abuse. In order to prevent every application from including a CHECKPOINT_REQUIRED option in its PCP requests, the following items are assumed: o Applications may be delivered with some default settings for check-pointing, and these settings should be programmable by end user. o Exposing and enforcing these settings is application specific. o The end user may customize these settings based on the requirements. RFC6887]. The CHECKPOINT_REQUIRED option can be used by an attacker to identify critical flows; this is sensitive from a privacy standpoint. Also, an attacker can cause critical flows to not be check-pointed by stripping the CHECKPOINT_REQUIRED option or by consuming the quota by adding the option to other flows.
These two issues can be mitigated if the network on which the PCP messages are to be sent is fully trusted. Means to defend against attackers who can intercept packets between the PCP server and the PCP client should be enabled. In some deployments, access control lists (ACLs) can be installed on the PCP client, PCP server, and the network between them, so those ACLs allow only communications between trusted PCP elements. If the networking environment between the PCP client and the PCP server is not secure, PCP authentication [RFC7652] MUST be enabled. A network device can always override the end-user signaling, i.e., what is signaled by the PCP client, if the instructions conflict with the network policies. http://www.iana.org/assignments/pcp-parameters): 192 CHECKPOINT_REQUIRED (see Section 3.1) [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>. [RFC7652] Cullen, M., Hartman, S., Zhang, D., and T. Reddy, "Port Control Protocol (PCP) Authentication Mechanism", RFC 7652, DOI 10.17487/RFC7652, September 2015, <http://www.rfc-editor.org/info/rfc7652>. [PREFIX-BINDING] Vinapamula, S. and M. Boucadair, "Recommendations for Prefix Binding in the Softwire DS-Lite Context", Work in Progress, draft-vinapamula-softwire-dslite-prefix- binding-12, October 2015.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <http://www.rfc-editor.org/info/rfc7149>.