Internet DRAFT - draft-ripke-pcp-tunnel-id-option
draft-ripke-pcp-tunnel-id-option
Internet Engineering Task Force A. Ripke
Internet-Draft T. Dietz
Intended status: Informational J. Quittek
Expires: April 30, 2015 NEC
R. da Silva
Telefonica I+D
October 27, 2014
PCP Third Party ID Option
draft-ripke-pcp-tunnel-id-option-02
Abstract
This document describes a new Port Control Protocol (PCP) option
called THIRD_PARTY_ID. It serves for identifying a Third Party in
addition to the means that PCP's THIRD_PARTY option already provides
for that purpose.
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 April 30, 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
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Ripke, et al. Expires April 30, 2015 [Page 1]
Internet-Draft PCP-ID October 2014
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 . . . . . . . . . . . . . . . . . . . . . 6
4. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Generating a Request . . . . . . . . . . . . . . . . . . 8
5.2. Processing a Request . . . . . . . . . . . . . . . . . . 8
5.3. Processing a Response . . . . . . . . . . . . . . . . . . 8
6. Alternative . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
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 draft focuses on the application of PCP's THIRD_PARTY option
that is used when the PCP client sends requests that concern other
internal hosts than the host of the PCP client. 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 issue addressed by the THIRD_PARTY_ID option is that there are
CGN deployments that do not distinguish internal hosts by their IP
address only, but use further identifiers for unique subscriber
identification. This is, for example, the case if a CGN supports
overlapping private IP address spaces according to [RFC1918] for
internal hosts of different subscribers. Then 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 such cases, the IP address contained in the
THIRD_PARTY option is not sufficient. An additional identifier needs
Ripke, et al. Expires April 30, 2015 [Page 2]
Internet-Draft PCP-ID October 2014
to be carried by the PCP protocol in order to uniquely identify the
internal host. The THIRD_PARTY_ID option serves this purpose.
The THIRD_PARTY_ID option is defined for use in combination with the
THIRD_PARTY option for the PCP opcodes MAP and PEER.
We renamed the option name from TUNNEL_ID to THIRD_PARTY_ID to
reflect the fact that this identifier is an extended THIRD_PARTY
option for general applicability.
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),
2. a carrier web portal for port mapping.
Both scenarios are variants of the same basic scenario shown in
Figure 1. 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 mapping for their
internal hosts is not specified in this basic scenario, but more
elaborated in the specific scenarios below.
Ripke, et al. Expires April 30, 2015 [Page 3]
Internet-Draft PCP-ID October 2014
+------------------+
| Carrier | ==== IP packet tunnel(s)
+--------------+ | +--------------+ | between subscriber
| Subscriber +......+ Port Control | | and CGN
| | | | Interworking | | #### PCP communication
| | | | Function | | .... Subscriber - IWF
| | | +-----#--------+ | interaction
| | | # | (unspecified)
| | | +-----#--------+ |
| +----------+ | | | PCP Server | |
| | Internal | | | | | |
| | Host +-+======+ CGN +--------- Public Internet
| +----------+ | | +--------------+ |
+--------------+ +------------------+
Figure 1: Carrier hosted PCP IWF for port mapping requests
Internal hosts in the subscriber's network use private IP addresses
as specified in [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 very good candidate for this additional identifier at the
CGN is the ID of the tunnel that connects the CGN to the subscriber's
network.
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 April 30, 2015 [Page 4]
Internet-Draft PCP-ID October 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, which can, for example, be provided via (one of the)
tunnel(s) connecting the subscriber's network to the CGN. This
connection can then be used by hosts in the subscriber's network to
request port mappings at the CGN using UPnP as specified in
[RFC6970].
+----------------+
| Carrier | ==== IP packet tunnel(s)
| +------------+ | between subscriber
+--------------+ | | UPnP | | and CGN
| Subscriber +......+ IGD-PCP | | #### PCP communication
| | | | IWF | | .... Subscriber - UPnP
| | | +-----#------+ | IGD-PCP IWF
| | | # | interaction (UPnP)
| | | +-----#------+ |
| +----------+ | | | PCP Server | |
| | Internal | | | | | |
| | Host +-+======+ CGN +--------- Public Internet
| +----------+ | | +------------+ |
+--------------+ +----------------+
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.
Ripke, et al. Expires April 30, 2015 [Page 5]
Internet-Draft PCP-ID October 2014
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.
+----------------+
| Carrier | ==== IP packet tunnel(s)
| +------------+ | between subscriber
+--------------+ | | Web Portal | | and CGN
| Subscriber +......+ | | #### PCP communication
| | | | PCP Client | | .... Subscriber - portal
| | | +-----#------+ | interaction (HTTPS)
| | | # |
| | | +-----#------+ |
| +----------+ | | | PCP Server | |
| | Internal | | | | | |
| | Host +-+======+ CGN +--------- Public Internet
| +----------+ | | +------------+ |
+--------------+ +----------------+
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.
Ripke, et al. Expires April 30, 2015 [Page 6]
Internet-Draft PCP-ID October 2014
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=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| THIRD_PARTY_ID (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: THIRD_PARTY_ID Option
o Option Name: THIRD_PARTY_ID
o Number: TBD
o Purpose: Identifies a request of an external IP address and port.
o Valid for opcodes: MAP, PEER, and all other for which the
THIRD_PARTY option is valid for.
o Length: 16 octets
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 vendor specific identifier that can be used to
identify a subscriber's CGN session and the port ranges to apply
this request to.
o The THIRD_PARTY_ID is not bound to a specific identifier. The
size of 128 bits should be large enough for general applicability.
The identifier field can contain any vendor 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.
Ripke, et al. Expires April 30, 2015 [Page 7]
Internet-Draft PCP-ID October 2014
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 either with a PCP MAP or PEER opcode. It MUST
be used in combination with the THIRD_PARTY option which provides an
IP address and port entered by the subscriber. 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. If the identifier is
shorter than 128 bits then the THIRD_PARTY_ID option field is to be
filled up with leading zeros up to 128 bits.
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.
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 message. To where to
report an error message is implementation dependent.
6. Alternative
An alternative to identify a tunnel affiliation in the given scenario
could be using the DESCRIPTION ([RFC7220]) option to carry a tunnel
ID option. The DESCRIPTION option is to allow a text description to
be attached to a port mapping. But using the DESCRIPTION option for
a tunnel ID might not be appropriate because it specifies using UTF-8
and another requirement is that the description text must not be null
terminated, which cannot always be met.
7. IANA Considerations
The following PCP Option Code is to be allocated in the mandatory-to-
process range:
Ripke, et al. Expires April 30, 2015 [Page 8]
Internet-Draft PCP-ID October 2014
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]
8. 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.
9. References
9.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.
[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.
9.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.
Ripke, et al. Expires April 30, 2015 [Page 9]
Internet-Draft PCP-ID 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.
[RFC7220] Boucadair, M., Penno, R., and D. Wing, "Description Option
for the Port Control Protocol (PCP)", RFC 7220, May 2014.
Authors' Addresses
Andreas Ripke
NEC
Heidelberg
Germany
Email: ripke@neclab.eu
Thomas Dietz
NEC
Heidelberg
Germany
Email: dietz@neclab.eu
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 April 30, 2015 [Page 10]
