Network Working Group X. Deng Internet-Draft France Telecom Intended status: Standards Track C. Zhou Expires: September 30, 2011 Huawei Technologies M. Boucadair France Telecom G. Bajko Nokia T. Tsou Huawei Technologies March 29, 2011 DS-Lite AFTR NAT Bypass: Co-located B4 and NAT Model draft-zhou-softwire-b4-nat-00 Abstract This document describes the behavior of the B4 when co-located with a NAT while the NAT in the AFTR is disabled. The proposed solution is expected to offload the burden on the AFTR, by delegating the NAT to B4. 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 September 30, 2011. Copyright Notice Deng, et al. Expires September 30, 2011 [Page 1] Internet-Draft B4 Behavior in NAT By-pass Solution March 2011 Copyright (c) 2011 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. B4 Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Plain IPv4 Address . . . . . . . . . . . . . . . . . . . . 3 2.3. Restricted IPv4 Address . . . . . . . . . . . . . . . . . . 3 2.3.1. Outgoing Packets Processing . . . . . . . . . . . . . . 4 2.3.2. Incoming Packets Processing . . . . . . . . . . . . . . 4 2.4. Stateless Encapsulation . . . . . . . . . . . . . . . . . . 4 2.5. Fragmentation and Reassembly . . . . . . . . . . . . . . . 4 2.6. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 3.1. Port Randomization . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 5.2. informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Deng, et al. Expires September 30, 2011 [Page 2] Internet-Draft B4 Behavior in NAT By-pass Solution March 2011 1. Introduction As currently defined in [I-D.ietf-softwire-dual-stack-lite], B4 element SHOULD NOT operate a NAT function because the NAT function will be performed by the AFTR in the service provider's network. To reduce the processing requirement of NAT device at the network side, address and port translation can be made at the customer side, e.g., CPE. For convenience, we call this solution as NAT-Bypass. To mitigate the port randomization issue identified in [I-D.ietf-intarea-shared-addressing-issues], a solution is elaborated in Section 3.1. This document provides descriptions on the B4 behavior when supporting NAT-Bypass. 2. B4 Behavior 2.1. Provisioning The provisioning of the B4 element is similar to what is defined in [I-D.ietf-softwire-dual-stack-lite]. 2.2. Plain IPv4 Address A B4 MAY be assigned with a plain IPv4 address. When a plain, IPv4 address is assigned, the NAT operations are enforced as per current legacy CPEs. The NAT in the AFTR is disabled for that user. IPv4 datagrams are encapsulated in IPv6 as specified in [I-D.ietf-softwire-dual-stack-lite]. 2.3. Restricted IPv4 Address In the NAT-Bypass solution, the port set is provisioned to B4 through PCP option defined in [I-D.tsou-pcp-natcoord] or specific DHCP options [I-D.bajko-pripaddrassign]. The PCP Server or IPv4 DHCP server may be co-located with the AFTR. The B4 is responsible for performing NAT and/ALG functions, as well as supporting NAT Traversal mechanisms (e.g., UPnP or NAT-PMP). Deng, et al. Expires September 30, 2011 [Page 3] Internet-Draft B4 Behavior in NAT By-pass Solution March 2011 2.3.1. Outgoing Packets Processing Upon receiving an IPv4 packet, the B4 performs NAT using the public IPv4 address and port set assigned to it. Then B4 encapsulates the resulting IPv4 packet into an IPv6 packet, and delivers it through IPv6 connectivity to AFTR which will then decapsulate the encapsulated packet and forward it through IPv4. The destination IPv6 address used for encapsulation should be the AFTR's address. 2.3.2. Incoming Packets Processing Upon receipt of IPv4-in-IPv6 packet from AFTR, B4 will decapsulate the packet and translate the public IPv4 address to the private IPv4 address. Finally, it delivers the packet to the host using the translated IPv4 address. The source IPv6 address used for encapsulation at AFTR is the AFTR's address, and the destination address is set to the external address of B4. 2.4. Stateless Encapsulation B4 may implement the stateless encapsulation specified in Section 4.4 of [I-D.ymbk-aplusp]. 2.5. Fragmentation and Reassembly No change to Section 5.3 of [I-D.ietf-softwire-dual-stack-lite]. 2.6. DNS The DNS behavior is the same as described in [I-D.ietf-softwire-dual-stack-lite]. 3. Security Considerations 3.1. Port Randomization A successful attack against the TCP or UDP requires the attacker to have knowledge of a valid five-tuple (protocol, source IP address, source port, destination IP address, destination port). As the destination IP, the protocol and the destination port together identifies a specific service on a specific target that the attacker will be spoofing, they are usually known by an attacker. Take BGP TCP RESET attack for example, an attacker assumes the destination port of 179 for BGP. When it comes to Domain Name System (DNS) cache poisoning attack, a hacker assumes the destination port of 53 (the port number IANA has assigned for DNS). There is a chance source IP is also known by an attacker. Therefore, for an attacker, the Deng, et al. Expires September 30, 2011 [Page 4] Internet-Draft B4 Behavior in NAT By-pass Solution March 2011 difficult part of guessing five-tuple is source IP and the TCP/UDP source port which is different per TCP/UDP session. Random source ports could increase the numerical guessing space, thereby increasing the difficulty of an attack. As a result, it is recommended that NAT devices implement random source port selection algorithms in [RFC6056]. However, contiguous port set allocation might be hurdle to port randomization. A simple non-contiguous port set allocation algorithm is therefore proposed to achieve a better port randomization NAT. On every external IPv4 address, according to port set size N, log2(N) bits are randomly choosing by AFTR as subscribers identification bit (s bit) among 1st and 16th bits. Take a sharing ration 1:32 for example, Figure 1 shows an example of 5 random selected bits of s bit. |1st |2nd |3rd |4th |5th |6th |7th | 8th| +----+----+----+----+----+----+----+----+ | 0 | s | 0 | 0 | s | 0 | s | 0 | +----+----+----+----+----+----+----+----+ |9th |10th|11th|12th|13th|14th|15th|16th| +----+----+----+----+----+----+----+----+ | s | 0 | s | 0 | 0 | 0 | 0 | 0 | +----+----+----+----+----+----+----+----+ Figure 1: A s bit selection example (on a sharing ration 1:32 address). Subscriber ID pattern is formed by setting all the s bits to 1 and other trivial bits to 0. Figure 2 illustrates an example of subscriber ID pattern on a sharing ration 1:32 address. Note that the subscriber ID pattern will be different, guaranteed by the random s bit selection, on every restricted IP address no matter whether the sharing ratio varies. |1st |2nd |3rd |4th |5th |6th |7th | 8th| +----+----+----+----+----+----+----+----+ | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | +----+----+----+----+----+----+----+----+ |9th |10th|11th|12th|13th|14th|15th|16th| +----+----+----+----+----+----+----+----+ | 1 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | +----+----+----+----+----+----+----+----+ Figure 2: A subscriber ID pattern example (on a sharing ration 1:32 address). Deng, et al. Expires September 30, 2011 [Page 5] Internet-Draft B4 Behavior in NAT By-pass Solution March 2011 Subscribers ID value is then assigned by setting subscriber ID pattern bits according to a subscriber identification and other trivial bits setting to 1. |1st |2nd |3rd |4th |5th |6th |7th | 8th| +----+----+----+----+----+----+----+----+ | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | +----+----+----+----+----+----+----+----+ |9th |10th|11th|12th|13th|14th|15th|16th| +----+----+----+----+----+----+----+----+ | 1 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | +----+----+----+----+----+----+----+----+ Figure 3: A subscriber ID value example (0# subscriber on this restricted address). Subscriber ID pattern and subscriber ID value together uniquely defines a non-overlapping port set on a restricted IP address. Pseudo-code shown in the Figure 4 describe how to use subscriber ID pattern and subscriber ID value to implement a random ephemeral port selection in a restricted port set. do{ restricted_next_ephemeral = random()|| customer_ID_pattern & customer_ID_value; if(five-tuple is unique) return restricted_next_ephemeral; } Figure 4: Random ephemeral port selection of restricted port set algorithm. 4. IANA Considerations None. 5. References 5.1. Normative References [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work in progress), March 2011. Deng, et al. Expires September 30, 2011 [Page 6] Internet-Draft B4 Behavior in NAT By-pass Solution March 2011 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, January 2011. 5.2. informative References [I-D.bajko-pripaddrassign] Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, "Port Restricted IP Address Assignment", draft-bajko-pripaddrassign-03 (work in progress), September 2010. [I-D.ietf-intarea-shared-addressing-issues] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", draft-ietf-intarea-shared-addressing-issues-05 (work in progress), March 2011. [I-D.tsou-pcp-natcoord] ZOU), T., Zhou, C., Sun, Q., Boucadair, M., and G. Bajko, "Using PCP To Coordinate Between the CGN and Home Gateway Via Port Allocation", draft-tsou-pcp-natcoord-01 (work in progress), March 2011. [I-D.ymbk-aplusp] Bush, R., "The A+P Approach to the IPv4 Address Shortage", draft-ymbk-aplusp-09 (work in progress), February 2011. Authors' Addresses Xiaohong Deng France Telecom Email: xiaohong.deng@orange-ftgroup.com Deng, et al. Expires September 30, 2011 [Page 7] Internet-Draft B4 Behavior in NAT By-pass Solution March 2011 Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Phone: Email: cathyzhou@huawei.com Mohamed Boucadair France Telecom Rennes, 35000 France Email: mohamed.boucadair@orange-ftgroup.com Gabor Bajko Nokia Email: gabor.bajko@nokia.com Tina TSOU Huawei Technologies P.R. China Phone: Email: tena@huawei.com Deng, et al. Expires September 30, 2011 [Page 8]