Internet Engineering Task Force A. Ripke Internet-Draft R. Winter Intended status: Standards Track T. Dietz Expires: June 11, 2015 J. Quittek NEC R. da Silva Telefonica I+D December 8, 2014 PCP Third Party ID Option draft-ietf-pcp-third-party-id-option-00 Abstract This document describes a new Port Control Protocol (PCP) option called THIRD_PARTY_ID. It is used together with the THIRD_PARTY option specified in [RFC6887] to identify a Third Party in situations where the IP address in the THIRD_PARTY option alone is insufficient to create mappings in a PCP-controlled device. 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 http://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 "work in progress." This Internet-Draft will expire on June 11, 2015. Copyright Notice Copyright (c) 2014 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 Ripke, et al. Expires June 11, 2015 [Page 1] Internet-Draft Third Party ID December 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Target Scenarios . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Carrier-hosted UPnP IGD-PCP IWF . . . . . . . . . . . . . 5 3.2. Carrier Web Portal . . . . . . . . . . . . . . . . . . . 6 3.3. Other Use Cases . . . . . . . . . . . . . . . . . . . . . 7 4. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Generating a Request . . . . . . . . . . . . . . . . . . 8 5.2. Processing a Request . . . . . . . . . . . . . . . . . . 9 5.3. Processing a Response . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The IETF has specified the Port Control Protocol (PCP) ([RFC6887]) to control how packets are translated and forwarded by a PCP-controlled device such as a network address translator (NAT) or firewall. This document focuses on the application of PCP's THIRD_PARTY option that is used when the PCP client sends requests that concern internal hosts other than the host of the PCP client itself. This is, for example, the case if port mapping requests for a carrier-grade NAT (CGN) are not sent from PCP clients at the subscribers, but from a PCP Interworking Function which requests port mappings. The primary issue addressed by the THIRD_PARTY_ID option is that there are CGN deployments that do not distinguish internal hosts by their IP address alone, but use further identifiers (IDs) for unique subscriber identification. This is, for example, the case if a CGN supports overlapping private IP address spaces ([RFC1918]) for internal hosts of different subscribers. In such cases, different internal hosts are identified and mapped at the CGN by their IP address and an additional ID, for example, the ID of a tunnel between the CGN and the subscriber. In these and similar scenarios, the IP address contained in the THIRD_PARTY option is not sufficient. An Ripke, et al. Expires June 11, 2015 [Page 2] Internet-Draft Third Party ID December 2014 additional identifier needs to be present in the PCP message in order to uniquely identify the internal host. The THIRD_PARTY_ID option is used to carry this ID. This applies to some of the PCP deployment scenarios that are listed in Section 2.1 of RFC 6887 [RFC6887], in particular to a Layer-2 aware NAT which is described in more detail in Section 3. The THIRD_PARTY_ID option is defined for use in combination with the THIRD_PARTY option for the PCP opcodes MAP and PEER. 2. Terminology The terminology defined in the specification of PCP [RFC6887] applies. 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 RFC 2119 [RFC2119]. 3. Target Scenarios This section describes two scenarios that illustrate the use of the THIRD_PARTY_ID option: 1. a UPnP IGD-PCP IWF (Universal Plug and Play Internet Gateway Device - Port Control Protocol Interworking Function [RFC6970]), 2. a carrier web portal for port mapping. Both scenarios are refinements of the same basic scenario shown in Figure 1 which is considered as a PCP deployment scenario employing Layer-2 aware NATs as listed in Section 2.1 of [RFC6887]. It has a carrier operating a CGN and a Port Control Protocol Interworking Function (PCP IWF) for subscribers to request port mappings at the CGN. The PCP IWF communicates with the CGN using PCP. For this purpose the PCP IWF contains a PCP client and the CGN is co-located with a PCP server. The way subscribers interact with the PCP IWF for requesting port mappings for their internal hosts is not specified in this basic scenario, but it is elaborated on more in the specific scenarios in Section 3.1 and Section 3.2. The CGN operates as a Layer-2 aware NAT. Unlike a standard NAT, it includes a subscriber identifier in addition to the source IP address in entries of the NAT mapping table. Ripke, et al. Expires June 11, 2015 [Page 3] Internet-Draft Third Party ID December 2014 +--------------+ +------------------+ | Subscriber | | Carrier | ==== L2 tunnel(s) | | | +--------------+ | between subscriber | +......+ PCP | | and CGN | +----------+ | | | Interworking | | #### PCP communication | | Internal | | | | Function | | .... Subscriber - IWF | | Host | | | +-----#--------+ | interaction | +----+-----+ | | # | (elaborated | | | | +-----#--------+ | in specific | +----+-----+ | | | PCP Server | | scenarios below) | | CPE | | | | | | | | +-+======+ CGN L2NAT +--------- Public Internet | +----------+ | | +--------------+ | +--------------+ +------------------+ Figure 1: Carrier hosted PCP IWF for port mapping requests Internal hosts in the subscriber's network use private IP addresses ([RFC1918]). Since there is no NAT between the internal host and the CGN, there is an overlap of addresses used by internal hosts at different subscribers. That is why the CGN needs more than just the internal host's IP address to distinguish internal hosts at different subscribers. A commonly deployed method for solving this issue is using an additional identifier for this purpose. A natural candidate for this additional identifier at the CGN is the ID of the tunnel that connects the CGN to the subscriber's network. The subscriber's CPE operates as a Layer-2 bridge. Requests for port mappings from the PCP IWF to the CGN need to uniquely identify the internal host for which a port mapping is to be established or modified. Already existing for this purpose is the THIRD_PARTY option that can be used to specify the internal host's IP address. The THIRD_PARTY_ID option is introduced for carrying the additional (tunnel) information needed to identify the internal host in this scenario. The additional identifier for internal hosts needs to be included in MAP requests from the PCP IWF in order to uniquely identify the internal host that should have its address mapped. This is the purpose that the new THIRD_PARTY_ID serves in this scenario. It carries the additional identifier, that is the tunnel ID, that serves for identifying an internal host in combination with the internal host's (private) IP address. The IP address of the internal host is included in the PCP IWF's mapping requests by using the THIRD_PARTY option. The information carried by the THIRD_PARTY_ID is not just needed to identify an internal host in a PCP request. The CGN needs this Ripke, et al. Expires June 11, 2015 [Page 4] Internet-Draft Third Party ID December 2014 information in its internal mapping tables for translating packet addresses and for forwarding packets to subscriber-specific tunnels. How the carrier PCP IWF is managing port mappings, such as, for example, automatically extending the lifetime of a mapping, is beyond the scope of this document. 3.1. Carrier-hosted UPnP IGD-PCP IWF This scenario further elaborates the basic one above by choosing UPnP as communication protocol between subscriber and the carrier's PCP IWF. Then obviously, the PCP IWF is realized as an UPnP IGD-PCP IWF as specified in [RFC6970]. As shown in Figure 2 it is assumed here that the UPnP IGD-PCP IWF is not embedded in the subscriber premises router, but offered as a service to the subscriber. Further, it is assumed that the UPnP IGD- PCP IWF is not providing NAT functionality. This requires that the subscriber has a UPnP connection to the UPnP IGD-PCP IWF, that can then be used by hosts in the subscriber's network to request port mappings at the CGN using UPnP as specified in [RFC6970]. In this scenario the connection is provided via (one of the) tunnel(s) connecting the subscriber's network to the BRAS and an extension of this tunnel from the BRAS to the UPnP IGD-PCP IWF. Note that there are other alternatives that can be used for providing the connection to the UPnP IGD-PCP IWF. The tunnel extension used in this scenario can, for example, be realized by a forwarding function for UPnP messages at the BRAS that forwards such messages through per-subscriber tunnels to the UPnP IGD-PCP IWF. Depending on an actual implementation, the UPnP IGD-PCP IWF can then either use the ID of the tunnel in which the UPnP message arrived directly as THIRD_PARTY_ID for PCP requests to the CGN or it uses the ID of the tunnel to retrieve the THIRD_PARTY_ID from the AAA server. To support the latter option, the BRAS needs to register the subscriber's tunnel IDs at the AAA Server at the time it contacts the AAA server for authentication and/or authorization of the subscriber. The tunnel IDs to be registered per subscriber at the AAA server may include the tunnel between CPE and BRAS, between BRAS and UPnP IGD- PCP IWF, and between BRAS and CGN. The UPnP IGD-PCP IWF queries the AAA Server for the ID of the tunnel between BRAS and CGN, because this is the identifier to be used as the THIRD_PARTY_ID in the subsequent port mapping request. Ripke, et al. Expires June 11, 2015 [Page 5] Internet-Draft Third Party ID December 2014 +--------------+ +------------------------------------+ | Subscriber | | Carrier | | | | +----------------------------+ | | | | | AAA Server | | | | | +-----+---------------+------+ | | | | | | | | +----------+ | | +-----+---+ +-----+------+ | | | Internal | | | | +=====+ | | | | Host | | | | ...........| UPnP IGD | | | +----+-----+ | | | . +=====+ PCP IWF | | | | . | | | . | +-----#------+ | | +----+--.--| | | | . | # | | | | . +========+ . | +-----#------+ | | | | .................. +=====+ PCP Server | | | | +------------------------------| | | | | CPE +========+ BRAS +=====+ CGN L2NAT +------- Public | +----------+ | | +---------+ +------------+ | Internet +--------------+ +------------------------------------+ ==== L2 tunnel borders between subscriber, BRAS, IWF, and CGN .... UPnP communication #### PCP communication Figure 2: UPnP IGD-PCP IWF A potential extension to [RFC6970] regarding an additional state variable for the THIRD_PARTY_ID and regarding an additional error code for a mismatched THIRD_PARTY_ID and its processing might be a logical next step. However, this is not in the scope of this document. 3.2. Carrier Web Portal This scenario shown in Figure 3 is different from the previous one concerning the protocol used between the subscriber and the IWF. Here, HTTP(S) is the protocol that the subscriber uses for port mapping requests. The subscriber may make requests manually using a web browser or automatically - as in the previous scenario - with hosts in the subscriber's network issuing port mapping requests on demand. The Web Portal queries the AAA Server for the subscriber's tunnel ID of tunnel(BRAS, CGN) which was reported by the BRAS. The returned tunnel ID of tunnel(BRAS, CGN) is used as the THIRD_PARTY_ID in the subsequent port mapping request. Ripke, et al. Expires June 11, 2015 [Page 6] Internet-Draft Third Party ID December 2014 +--------------+ +------------------------------------+ | Subscriber | | Carrier | | | | +------------+ | | | | +------------+ | Web Portal | | | +----------+ | | | AAA Server +--+ +--+ | | | Internal | | | +-----+------+ | PCP Client | | | | | Host | | | | +-----#------+ | | | +----+-----+ | | | # | | | | | | +-----+---+ +-----#------+ | | | +----+-----+ | | | | | PCP Server | | | | | CPE | | | | BRAS | | | | | | | +-+======+ +=====+ CGN L2NAT +--+---- Public | +----------+ | | +---------+ +------------+ | Internet +--------------+ +------------------------------------+ ==== L2 tunnel(s) between subscriber, BRAS, and CGN #### PCP communication Figure 3: Carrier Web Portal The PCP IWF is realized as a combination of a web server and a PCP Client. This scenario is also described as HTTP-triggered PCP client model in section 5.2 of [I-D.boucadair-pcp-deployment-cases]. 3.3. Other Use Cases Despite the fact that above scenarios solely use tunnel IDs the THIRD_PARTY_ID can include any Layer-2 identifier like a MAC address or other subscriber identifiers as mentioned in section 6 of [I-D.boucadair-pcp-sfc-classifier-control]. 4. Format The THIRD_PARTY_ID option is formatted as shown in Figure 4. 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 | Reserved | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | THIRD_PARTY_ID | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: THIRD_PARTY_ID Option o Option Name: THIRD_PARTY_ID Ripke, et al. Expires June 11, 2015 [Page 7] Internet-Draft Third Party ID December 2014 o Number: TBD o Purpose: Identifies a third party for which a request for an external IP address and port is made. o Valid for opcodes: MAP, PEER, and all other for which the THIRD_PARTY option is valid for. o Length: Variable. o May appear in: request. Must appear in response if it appeared in the associated request. o Maximum occurrences: 1 The fields are as follows: o THIRD_PARTY_ID: A deployment specific identifier that can be used to identify a subscriber's CGN session. The THIRD_PARTY_ID is not bound to any specific identifier. The Option Length is variable and specifies the length of the THIRD_PARTY_ID field in octets as described in Section 7.3 of [RFC6887]. The identifier field can contain any deployment specific value. The option number is in the mandatory-to-process range (0-127), meaning that a request with a THIRD_PARTY_ID option is executed by the PCP server if and only if the THIRD_PARTY_ID option is supported by the PCP server. 5. Behavior The following sections describe the operations of a PCP client and a PCP server when generating the request and processing the request and response. 5.1. Generating a Request In addition to generating a PCP request that is described in [RFC6887] the following has to be applied. The THIRD_PARTY_ID option can be used together with either a PCP MAP or PEER opcode. It MUST be used in combination with the THIRD_PARTY option which provides an IP address. The THIRD_PARTY_ID option holds an identifier to allow the CGN to uniquely identify the internal host (specified in the THIRD_PARTY option) for which the port mapping is to be established or modified. The padding rules described in Section 7.3 of [RFC6887] apply. Ripke, et al. Expires June 11, 2015 [Page 8] Internet-Draft Third Party ID December 2014 5.2. Processing a Request The THIRD_PARTY_ID option is in the mandatory-to-process range and if the PCP server does not support this option it MUST return an UNSUPP_OPTION response. If the provided THIRD_PARTY_ID is unknown/ unavailable the PCP server MUST return a THIRD_PARTY_ID_UNKNOWN response. If the THIRD_PARTY_ID option is sent without a THIRD_PARTY option the PCP server MUST return a MALFORMED_REQUEST response. 5.3. Processing a Response If the PCP client receives a THIRD_PARTY_ID_UNKNOWN response back for its previous request it SHOULD report an error. To where to report an error is implementation dependent. 6. IANA Considerations The following PCP Option Code is to be allocated in the mandatory-to- process range: THIRD_PARTY_ID [NOTE for IANA: Please allocate a PCP Option Code at http://www.iana.org/assignments/pcp-parameters/pcp- parameters.xml#option-rules] The following PCP Result Code is to be allocated: THIRD_PARTY_ID_UNKNOWN [NOTE for IANA: Please allocate a PCP Result Code at http://www.iana.org/assignments/pcp-parameters/pcp- parameters.xml#result-codes] 7. Security Considerations As this option is related to the use of the THIRD_PARTY option the corresponding security considerations apply. Especially, the network on which the PCP messages are sent must be fully trusted. 8. References 8.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. Ripke, et al. Expires June 11, 2015 [Page 9] Internet-Draft Third Party ID December 2014 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. 8.2. Informative References [I-D.boucadair-pcp-deployment-cases] Boucadair, M., "Port Control Protocol (PCP) Deployment Models", draft-boucadair-pcp-deployment-cases-03 (work in progress), July 2014. [I-D.boucadair-pcp-sfc-classifier-control] Boucadair, M., "PCP as a Traffic Classifier Control Protocol", draft-boucadair-pcp-sfc-classifier-control-01 (work in progress), October 2014. [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, July 2013. Authors' Addresses Andreas Ripke NEC Heidelberg Germany Email: ripke@neclab.eu Rolf Winter NEC Heidelberg Germany Email: winter@neclab.eu Thomas Dietz NEC Heidelberg Germany Email: dietz@neclab.eu Ripke, et al. Expires June 11, 2015 [Page 10] Internet-Draft Third Party ID December 2014 Juergen Quittek NEC Heidelberg Germany Email: quittek@neclab.eu Rafael Lopez da Silva Telefonica I+D Madrid Spain Email: ralds@tid.es Ripke, et al. Expires June 11, 2015 [Page 11]