Network Working Group C. Donley
Internet-Draft C. Grundemann
Intended status: Experimental V. Sarawat
Expires: March 29, 2012 K. Sundaresan
CableLabs
September 26, 2011
Deterministic Address Mapping to Reduce Logging in Carrier Grade NATs
draft-donley-behave-deterministic-cgn-00
Abstract
Many Carrier Grade NAT solutions require per-connection logging.
Unfortunately, such logging is not scalable to many residential
broadband services. This document suggests a way to manage Carrier
Grade NAT translations in such a way as to significantly reduce the
amount of logging required while providing traceability for abuse
response. This method also provides a way of including geo-location
significance in such assignments.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 March 29, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Donley, et al. Expires March 29, 2012 [Page 1]
Internet-Draft deterministic-cgn September 2011
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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Deterministic NAT . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Geo-location Considerations . . . . . . . . . . . . . . . . 5
2.2. Deterministic NAT Example . . . . . . . . . . . . . . . . . 5
3. Additional Logging Considerations . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Donley, et al. Expires March 29, 2012 [Page 2]
Internet-Draft deterministic-cgn September 2011
1. Introduction
The world is rapidly running out of unallocated IPv4 addresses. To
meet the growing demand for Internet service from new subscribers,
devices, and service types, ISPs will be forced to share a single
public IPv4 address among multiple subscribers using a technology
such as Carrier Grade Network Address Translation (CGN) [RFC6264].
However, address sharing poses additional challenges to ISPs in
responding to law enforcement requests or attack/abuse reports. In
order to respond to such requests to identify a specific user
associated with an IP address, an ISP will need to map a subscriber's
internal source IP address and source port with the global public IP
address and source port provided by the CGN for every connection
initiated by the user.
CGN connection logging satisfies the need to identify attackers and
respond to abuse/law enforcement requests, but it imposes significant
operational challenges to ISPs. In lab testing, we have observed CGN
log messages to be approximately 150 bytes long for NAT444
[I-D.shirasaki-nat444], and 175 bytes for DS-Lite [RFC6333]
(individual log messages vary somewhat in size). Although we are not
aware of definitive studies of connection rates per subscriber,
reports from several ISPs in the US sets the average number of
connections per household per day at approximately 33,000 connections
per day. If each connection is individually logged, this translates
to a data volume of approximately 5 MB per subscriber per day, or
about 150 MB per subscriber per month; however, specific data volumes
may vary across different ISPs based on myriad factors. Based on
available data, a 1-million subscriber service provider will generate
approximately 150 terabytes of log data per month, or 1.8 petabytes
per year.
As an alternative to per-connection logging, CGNs could
deterministically map internal addresses to external addresses in
such a way as to be able to algorithmically calculate the mapping
without relying on per connection logging. This document describes a
method for such CGN address mapping, combined with block port
reservations, that significantly reduces the burden on ISPs while
offering the ability to map a subscriber's inside IP address with an
outside address and port observed on the Internet.
2. Deterministic NAT
While a subscriber uses thousands of connections per day, most
subscribers use far fewer at any given time. When the compression
ratio is low (i.e., the ratio of the number of subscribers to the
number of public IPv4 addresses allocated to a CGN is closer to 10:1
Donley, et al. Expires March 29, 2012 [Page 3]
Internet-Draft deterministic-cgn September 2011
than 1000:1), each subscriber could expect to have access to
thousands of TCP/UDP ports at any given time. Thus, as an
alternative to logging each connection, CGNs could deterministically
map customer private addresses on the inside of the CGN to public
addresses on the outside of the CGN. This algorithm will allow an
operator to identify a subscriber internal IP address when provided
the public side IP and port number without having to examine the CGN
translation logs. This prevents an operator from having to transport
and store massive amounts of session data from the CGN and then
process it to identify a subscriber.
Deterministic NAT requires configuration of the following variables:
o Inside IPv4/IPv6 address range (I);
o Outside IPv4 address range (O);
o Compression ratio (e.g. inside IP addresses I/outside IP addresses
O) (C);
o Dynamic address pool factor (D), to be added to the compression
ratio in order to create an overflow address pool;
o Maximum ports per user (M); and
o Reserved TCP/UDP port list
Note: The inside address range (I) will be an IPv4 range in NAT444
operation ([I-D.shirasaki-nat444]) and an IPv6 range in DS-Lite
operation ([RFC6333]).
The CGN then reserves ports as follows:
1. The CGN removes reserved ports from the port candidate list (e.g.
1-1023 for TCP and UDP). At a minimum, the CGN SHOULD remove
system ports [I-D.ietf-tsvwg-iana-ports] from the port candidate
list reserved for deterministic assignment.
2. The CGN calculates the total compression ratio (C+D), and
allocates 1/(C+D) of the available ports to each internal IP
address. Any remaining ports are allocated to the dynamic pool.
Port allocation could be made sequentially (e.g. the first block
goes to address 1, the second block to address 2, etc.),
staggered (e.g. address 1 receives ports n*(C+D), address 2
receives ports 1+n*(C+D), etc.), or through some other
deterministic algorithm left to CGN implementation. Subscribers
could be restricted to ports from a single IPv4 address, or could
be allocated ports across all addresses in a pool, for example.
Donley, et al. Expires March 29, 2012 [Page 4]
Internet-Draft deterministic-cgn September 2011
3. When a subscriber initiates a connection, the CGN creates a
translation mapping between the subscriber's inside local IP
address/port and the CGN outside global IP address/port. The CGN
MUST use one of the ports allocated in step 2 for the translation
as long as such ports are available. The CGN MUST use the
preallocated port range from step 2 for port control protocol
(PCP) [I-D.ietf-pcp-base] reservations as long as such ports are
available. While the CGN maintains its mapping table, it need
not generate a log entry for translation mappings created in this
step.
4. The CGN will have a pool of ports left for dynamic assignment.
If a subscriber uses more than the range of ports allocated in
step 2 (but fewer than the configured maximum ports M), the CGN
uses a port from the dynamic assignment range for such a
connection or for PCP reservations. The CGN MUST log dynamically
assigned ports to facilitate subscriber-to-address mapping. The
CGN SHOULD manage dynamic ports as described in
[I-D.tsou-behave-natx4-log-reduction].
5. Configuration of reserved ports (e.g. system ports) is left to
operator configuration.
Thus, the CGN will maintain translation mapping information for all
connections within its internal translation tables; however, it only
needs to externally log translations for dynamically-assigned ports.
2.1. Geo-location Considerations
As described in [RFC6269], CGN implementation can reduce the level of
confidence and level of granularity of geo-location information.
However, the level of confidence in geo-location data can be
increased, even in a centralized CGN deployment, by sub-dividing
inside and outside ranges. If I and O are subdivided such that I-1
corresponds to a particular headend or central office (CO), and I-2
corresponds with another headend/CO, etc., then geo-location data
tied to address ranges O-1 and O-2, etc. can be accurate down to the
headend/CO level, approximately the same level of granularity
available in residential broadband services without CGNs. This
information can help content providers enforce regional content
licensing restrictions, target advertising to local markets, and
assist with emergency services provisioning.
2.2. Deterministic NAT Example
To illustrate the use of deterministic NAT, let's consider a simple
example. The operator configures an inside address range (I) of
192.168.0.0/28 and outside address (O) of 203.0.113.1. The dynamic
Donley, et al. Expires March 29, 2012 [Page 5]
Internet-Draft deterministic-cgn September 2011
buffer factor is set to '2'. Thus, the total compression ratio is
1:(14+2) = 1:16. Only the system ports (e.g. ports < 1024) are
reserved. This configuration causes the CGN to preallocate ((65536-
1024)/16 =) 4032 TCP and 4032 UDP ports per inside IPv4 address. For
the purposes of this example, let's assume that they are allocated
sequentially, where 192.168.0.1 maps to 203.0.113.1 ports 1024-5055,
192.168.0.2 maps to 203.0.113.1 ports 5056-9087, etc. The dynamic
port range thus contains ports 57472-65535. Finally, the maximum
ports/subscriber is set to 5040.
When subscriber 1 using 192.168.0.1 initiates a low volume of
connections (e.g. < 4032 concurrent connections), the CGN maps the
outgoing source address/port to the preallocated range. These
translation mappings are not logged.
Subscriber 2 concurrently uses more than the allocated 4032 ports
(e.g. for peer-to-peer, mapping, video streaming, or other
connection-intensive traffic types), the CGN allocates up to an
additional 1008 ports using bulk port reservations. In this example,
subscriber 2 uses outside ports 5056-9087, and then 100-port blocks
between 58000-58999. Connections using ports 5056-9087 are not
logged, while 10 log entries are created for ports 58000-58099,
58100-58199, 58200-58299, ..., 58900-58999.
If a law enforcement agency reports abuse from 203.0.113.1, port
2001, the operator can reverse the mapping algorithm to determine
that subscriber 1 generated the traffic without consulting logs. If
a second abuse report comes in for 203.0.113.1, port 58204, the
operator will determine that port 58204 is within the dynamic pool
range, consult the log file, and determine that subscriber 2
generated the traffic (assuming that the law enforcement timestamp
matches the operator timestamp).
In this example, there are no log entries for the majority of
subscribers, who only use pre-allocated ports. Only minimal logging
would be needed for those few subscribers who exceed their pre-
allocated ports and obtain extra bulk port assignments from the
dynamic pool. Logging data for those users will include inside
address, outside address, outside port range, and timestamp.
3. Additional Logging Considerations
In order to be able to identify a subscriber based on observed
external IPv4 address, port, and timestamp, an operator needs to know
how the CGN was configured with regards to internal and external IP
addresses, dynamic address pool factor, maximum ports per user, and
reserved port range at any given time. Therefore, the CGN MUST
Donley, et al. Expires March 29, 2012 [Page 6]
Internet-Draft deterministic-cgn September 2011
generate a log message any time such variables are changed. Also,
the CGN SHOULD generate such a log message once per day to facilitate
quick identification of the relevant configuration in the event of an
abuse notification.
Such a log message MUST, at minimum, include the timestamp, inside
prefix I, inside mask, outside prefix O, outside mask, D, M, and
reserved port range; for example:
[Wed Oct 11 14:32:52 2000]:192.168.0.0:28:203.0.113.0:32:2:5040:1-
1023,5004,5060.
4. IANA Considerations
This document makes no request of IANA.
5. Security Considerations
The security considerations applicable to NAT operation for various
protocols as documented in, for example, RFC 4787 [RFC4787] and RFC
5382 [RFC5382] also apply to this document.
6. Acknowledgements
TBD
7. References
7.1. Normative References
[I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-13 (work in progress), July 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
Donley, et al. Expires March 29, 2012 [Page 7]
Internet-Draft deterministic-cgn September 2011
RFC 5382, October 2008.
[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental
Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264,
June 2011.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011.
7.2. Informative References
[I-D.ietf-tsvwg-iana-ports]
Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry",
draft-ietf-tsvwg-iana-ports-10 (work in progress),
February 2011.
[I-D.shirasaki-nat444]
Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", draft-shirasaki-nat444-04 (work
in progress), July 2011.
[I-D.tsou-behave-natx4-log-reduction]
ZOU), T., Li, W., and T. Taylor, "Port Management To
Reduce Logging In Large-Scale NATs",
draft-tsou-behave-natx4-log-reduction-02 (work in
progress), September 2010.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
Authors' Addresses
Chris Donley
CableLabs
858 Coal Creek Cir
Louisville, CO 80027
US
Email: c.donley@cablelabs.com
Donley, et al. Expires March 29, 2012 [Page 8]
Internet-Draft deterministic-cgn September 2011
Chris Grundemann
CableLabs
858 Coal Creek Cir
Louisville, CO 80027
US
Email: c.grundemann@cablelabs.com
Vikas Sarawat
CableLabs
858 Coal Creek Cir
Louisville, CO 80027
US
Email: v.sarawat@cablelabs.com
Karthik Sundaresan
CableLabs
858 Coal Creek Cir
Louisville, CO 80027
US
Email: k.sundaresan@cablelabs.com
Donley, et al. Expires March 29, 2012 [Page 9]