Internet Engineering Task Force Q. Sun
Internet-Draft China Telecom
Intended status: Standards Track M. Boucadair
Expires: September 14, 2012 X. Deng
France Telecom
C. Zhou
Huawei Technologies
T. Tsou
Huawei Technologies (USA)
March 13, 2012
Using PCP To Coordinate Between the CGN and Home Gateway Via Port
Allocation
draft-tsou-pcp-natcoord-05
Abstract
This document defines an extension to the base PCP. New OpCode and
Options are defined to enhance PCP with the ability to reserve port
sets for internal hosts.
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 September 14, 2012.
Copyright Notice
Copyright (c) 2012 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
Sun, et al. Expires September 14, 2012 [Page 1]
Internet-Draft NAT Coordination Using Port Allocation March 2012
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. Application Scenario . . . . . . . . . . . . . . . . . . . . . 3
2. MAP_PORT_SET Opcode . . . . . . . . . . . . . . . . . . . . . 3
2.1. MAP_PORT_SET Operation Packet Formats . . . . . . . . . . 4
2.2. Port-Set Options Formats . . . . . . . . . . . . . . . . . 5
2.2.1. Port_Range_Option . . . . . . . . . . . . . . . . . . 6
2.2.2. Cryptographically_Random_Port_Range_Option . . . . . . 6
2.3. Generating a MAP_PORT_SET Request . . . . . . . . . . . . 8
2.4. Renewing a MAP_PORT_SET Mapping . . . . . . . . . . . . . 8
2.5. Processing a MAP_PORT_SET Request . . . . . . . . . . . . 8
2.6. Processing a MAP_PORT_SET Response . . . . . . . . . . . . 9
2.7. Mapping Lifetime and Deletion . . . . . . . . . . . . . . 9
2.8. PREFER_FAILURE Option for MAP_PORT_SET Opcode . . . . . . 9
3. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Contributor List . . . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Sun, et al. Expires September 14, 2012 [Page 2]
Internet-Draft NAT Coordination Using Port Allocation March 2012
1. Application Scenario
PCP can be used to control an upstream device to achieve the
following goals:
1. A plain (i.e., a non-shared) IP address can be assigned to a
given subscriber because the subscriber subscribed to a service
which uses a protocol that don't embed a transport number or
because the NAT is the only deployed platform to manage IP
addresses.
2. An application (e.g., sensor) does not need to listen to a whole
range of ports available on a given IP address. Only a limited
set of ports are used to bind its running services. For such
devices, the external port(s) and IP address can be delegated to
that application and therefore avoid enforcing NAT in the network
side for its associated flows. The NAT in the PCP- controlled
device should be bypassed.
3. A device able to restrict its source ports can be delegated an
external port restricted IP address. The PCP- controlled device
should be instructed to by-pass the NAT when handling flows
destined/issued to that device.
This document extends PCP with the ability to reserve port set
instead of individual mapping. This is motivated by the need to
offload to a port-restricted device, reduce the logging and enhance
the performance of the CGN.
A new PCP OpCode and two new PCP Options are defined in this
document.
2. MAP_PORT_SET Opcode
This section defines a new Opcode which requests port set from a PCP-
controlled device to a PCP client. By analogy, a port set binding
can be seen as an aggregate of MAP mappings. When assigning a port
set to a PCP Client, the PCP-controlled device maintains a binding
between the source IP address of the PCP request, the assigned
external IP address and port set. It can greatly reduce individual
MAP requests for a PCP client when requesting a bulk of ports at one
time. This mechanism can be applied for instance to lightweight
4over6 [l4over6] in port-set allocation process.
MAP_PORT_SET: Create an explicit dynamic mapping between an Internet
Address and an External Address + Port set
Sun, et al. Expires September 14, 2012 [Page 3]
Internet-Draft NAT Coordination Using Port Allocation March 2012
The format of a port-set can either be contiguous or non-contiguous
including a cryptographical assigned port set. The contiguous port-
set is simple but since the port space for a subscriber shrinks
significantly, the randomness for the port numbers is decreased
significantly. This may allow an attacker to guess the port number
used. Non-contiguous port-set, e.g., cryptographical algorithm
[RFC6431], can be provided to improve the randomness of port number.
It may be used as a mitigation tool against blind attacks.
Therefore, in MAP_PORT_SET Opcode, it is mandatory to support two
port-set options: PORT_MASK Option and
Cryptographically_Random_Port_set Option. Besides, PREFERE_FAILURE
Option would also apply for MAP_PORT_SET Opcode.
PCP-controlled device SHOULD provide a configuration option to allow
administrators to configure the size of the port set to be assigned
and whether cryptographical option is supported or not.
2.1. MAP_PORT_SET Operation Packet Formats
The MAP_PORT_SET Opcode has a similar packet layout for both requests
and response. The following figure shows the format of the Opcode in
a request for the MAP_PORT_SET Opcode.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Suggested External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
Figure 1: MAP_PORT_SET Opcode format of Request
These fields are described below:
o Protocol: the default value is zero (to indicate all transport
protocols).
o Reserved bits: 24 bits MUST be set to 0.
o Suggested External IP Address: Suggested external IPv4 or IPv6
address. Same as Section 10.1 of [PCP-base].
Sun, et al. Expires September 14, 2012 [Page 4]
Internet-Draft NAT Coordination Using Port Allocation March 2012
The following figure shows the format of Opcode-specific information
in a response packet for the MAP_PORT_SET Opcode:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Assigned External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
Figure 2: MAP_PORT_SET Opcode format of Response
These fields are described below:
o Protocol: MUST be copied from the request.
o Reserved bits: 24 bits MUST be set to 0.
o Assigned External IP Address (128 bits): This filed conveys the
assigned external IPv4 (encoded using IPv4-mapped IPv6 address) or
IPv6 address for the mapping. On an error response, the Assigned
External IP Address is coped from the request.
o Requested lifetime (in common header): Requested lifetime for the
whole port-set mapping, in seconds. The value 0 also indicates
"delete" here.
Discussion note: Assess further whether THIRD_PARTY Option is needed
for PORTRANGE OpCode.
2.2. Port-Set Options Formats
The Port_Set options are used to specify one set of ports pertaining
to a given IP address. As defined in [RFC6431],there are three kinds
of port range: contiguous, non-contiguous and random. A
cryptographically random Port Range Option may be used as a
mitigation tool against blind attacks. We will describe the two port
set PCP options in this section.
Sun, et al. Expires September 14, 2012 [Page 5]
Internet-Draft NAT Coordination Using Port Allocation March 2012
2.2.1. Port_Range_Option
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA | Reserved | Option Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Range Value | Port Range Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Port_Range_Option
o Port Range Value (PRV): The PRV indicates the value of the
significant bits of the Port Mask. By default, no PRV is
assigned.
o Port Range Mask (PRM): The Port Range Mask indicates the position
of the bits that are used to build the Port Range Value. By
default, no PRM value is assigned. The 1 values in the Port Range
Mask indicate by their position the significant bits of the Port
Range Value.
This option:
o name: Port range option
o number: TBA
o purpose: A PCP Client inserts this option in a PCP request to
specify one set of ports (contiguous or not contiguous) pertaining
to a given IP address.
o is valid for OpCodes:MAP_PORT_SET.
o length:4 octets
o may appear in:request and response
o maximum occurrences:1
2.2.2. Cryptographically_Random_Port_Range_Option
The cryptographically random Port Range PCP Option is formated as
below.
Sun, et al. Expires September 14, 2012 [Page 6]
Internet-Draft NAT Coordination Using Port Allocation March 2012
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=24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| function | starting point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number of delegated ports | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ... |
| Key K |
| ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 0X00 |
+-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Cryptographically_Random_Port_Range_Option
o function/starting point/number of delegated ports/k: In request
packet, it is the suggested function/starting point/number of
delegated ports/k which might be helpful for refreshing a mapping
after the PCP server loses state. For a success response packet,
it is the assigned function/starting point/number of delegated
ports/k, while for an error response packet, it is copied from the
request.
This option:
o name: Cryptographically Random Port Range Option
o number: TBA
o purpose: A PCP Client inserts this option in a PCP request to
specify one set of random ports pertaining to a given IP address.
The random ports can be achieved by defining a function that takes
as input a key 'K' and an integer 'x' within the 1024-65535 port
range and produces an output 'y' also within the 1024-65535 port
range.
o is valid for OpCodes:MAP_PORT_SET.
o length: 24 octets.
o may appear in:request and response
o maximum occurrences:1
Sun, et al. Expires September 14, 2012 [Page 7]
Internet-Draft NAT Coordination Using Port Allocation March 2012
2.3. Generating a MAP_PORT_SET Request
The request MAP_PORT_SET MUST contains one of the port-set options,
either PORT_RANGE option or Cryptographically_Random_Port_Set option.
The request MAY contain values in the Suggested IP Address field and
corresponding parameters in PORT_RANGE option. However, this port
set indicated in the request of the PCP Client is only a hint; it is
up to the PCP Server to assign a free port set.
2.4. Renewing a MAP_PORT_SET Mapping
The similar actions defined in PCP-BASE specification [section 10.2.1
of [ID.ietf-pcp-base]] can be applied to MAP_PORT_SET Opcode to
extend the lifetime of a port-set mapping. The MAP_PORT_SET request
SHOULD include the currently assigned IP address and port-set in the
suggested IP address and port-set options. The PCP-client should
renew the port-set mapping before its expiry time.
[Discussion note: Do we need to cover the case in which a client MAY
send a request to the LSN for another delegated set of ports? I
think we should recommand that the same external IP address.
Otherwise, the client has to determine which address should be used
in actual data communication process among multiple external
addresses.]
2.5. Processing a MAP_PORT_SET Request
The procedures regarding to lifetime is similar to the single port
processes in MAP Opcode [section 10.3 of [ID.ietf-pcp-base]], except
that the whole port-set should be treated consistently in
MAP_PORT_SET Opcode.
The error codes in MAP_PORT_SET Response mainly have the following
possibilities:
o If the PCP server or PCP-controlled device does not support
MAP_PORT_SET Opcode, the error UNSUPP_OPCODE MUST be returned.
o if the PCP server or PCP-controlled device does not support the
port-set option indicated in MAP_PORT_SET request, the error
UNSUPP_OPTION MUST be returned.
o If an option does not make sense, (e.g., the PREFER_FAILURE Option
is included in a request with lifetime=0, or MAP_PORT_SET Opcode
does not include port-set options, etc.,), the request is invalid
and generates a MALFORMED_OPTION error. This procedure is the
same with section 10.3 of [ID.ietf-pcp-base].
Sun, et al. Expires September 14, 2012 [Page 8]
Internet-Draft NAT Coordination Using Port Allocation March 2012
o If the MAP request contains the PREFER_FAILURE Option, but the
Suggested External Address and Port-set do not match the External
Address and Port of the existing mapping, the PCP server MUST
return CANNOT_PROVIDE_EXTERNAL.
If all of the preceding operations were successful (did not generate
an error response), then the requested port-set mapping is created or
refreshed as described in the request and a SUCCESS response is
built. The assigned external IPv4 (encoded using IPv4-mapped IPv6
address) or IPv6 address for the mapping should be returned.
2.6. Processing a MAP_PORT_SET Response
On receiving a MAP_PORT_SET Response, the same procedure as the one
for individual mapping [section 10.4 of [ID.ietf-pcp-base]] should be
followed by the PCP Client to validate the response (except the
considerations related to the internal port).
2.7. Mapping Lifetime and Deletion
The procedure for port-set mapping lifetime and deletion is also the
same with individual mapping [section 10.5 of [ID.ietf-pcp-base]].
2.8. PREFER_FAILURE Option for MAP_PORT_SET Opcode
This option [section 10.2 of [ID.ietf-pcp-base]] can be applied to
MAP_PORT_SET Opcode indicating that if the PCP server cannot map the
suggested External Address and port-set, the PCP server should not
create a mapping.
3. Security Considerations
None.
4. IANA Considerations
The authors request the following new OpCode: MAP_PORT_SET and the
following two Options: PORT_RANGE Cryptographically_Random_Port_Set
5. Contributor List
Gabor Bajko
Nokia
Sun, et al. Expires September 14, 2012 [Page 9]
Internet-Draft NAT Coordination Using Port Allocation March 2012
Email: gabor.bajko@nokia.com
6. References
6.1. Normative References
[ID.ietf-pcp-base]
Wing, D., "Port Control Protocol (PCP)", February 2012.
[RFC6431] IETF, "Huawei Port Range Configuration Options for PPP IP
Control Protocol (IPCP)", November 2011,
<http://datatracker.ietf.org/doc/rfc6431/>.
6.2. informative References
[ID.behave-natx4-log-reduction]
Tsou, T., Li, W., and T. Taylor, "Port Management To
Reduce Logging In Large-Scale NATs", September 2010.
[ID.cui-softwire-b4-translated-ds-lite]
Cui, Y., Sun, Q., Boucadair, M., Tsou, T., and Y. Lee,
"Lightweight 4over6: An Extension to DS-Lite
Architecture", Feb 2012.
Authors' Addresses
Qiong Sun
China Telecom
P.R.China
Phone: 86 10 58552936
Email: sunqiong@ctbri.com.cn
Mohamed Boucadair
France Telecom
Rennes, 35000
France
Email: mohamed.boucadair@orange-ftgroup.com
Sun, et al. Expires September 14, 2012 [Page 10]
Internet-Draft NAT Coordination Using Port Allocation March 2012
Xiaohong Deng
France Telecom
Email: xiaohong.deng@orange-ftgroup.com
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: cathy.zhou@huawei.com
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: Tina.Tsou.Zouting@huawei.com
Sun, et al. Expires September 14, 2012 [Page 11]