Internet Engineering Task Force Y. Wu Internet-Draft H. Ji Intended status: Standards Track Q. Chen, Ed. Expires: September 8, 2011 China Telecom T. Tsou, Ed. Huawei Technologies March 7, 2011 IPv4 Header Option For User Identification In CGN Scenario draft-chen-intarea-v4-uid-header-option-00 Abstract In some application scenarios, it is necessary to be able to identify an user when CGN is deployed. This document defines a new IPv4 header option for host identification, which contains NAT mapping information, e.g. the internal source IP address before translation. Each time a NAT device performs translation on an IP packet, NAT mapping information will be added in the IP header. With the NAT mapping information, it will be easy to identify a host. 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 8, 2011. Copyright Notice 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 Wu, et al. Expires September 8, 2011 [Page 1] Internet-Draft IPv4 Header Option For User ID March 2011 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivating Scenarios . . . . . . . . . . . . . . . . . . . . . 4 2.1. Limit The Number Of Sessions From An IP Address . . . . . 4 2.2. Anti-virus Filtering And Limiting Malicious Attack Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Account Security Assistance . . . . . . . . . . . . . . . 4 3. User Identification (UID) IPv4 Header Option . . . . . . . . . 5 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5 3.2. NAT Mapping Sub-option . . . . . . . . . . . . . . . . . . 6 3.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. Procedures At a NAT . . . . . . . . . . . . . . . . . 8 3.3.2. Procedures At an Edge Device Or Firewall . . . . . . . 9 3.3.3. Procedures At Other Routers . . . . . . . . . . . . . 9 4. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 9 5. NAT configuration . . . . . . . . . . . . . . . . . . . . . . 9 6. Impact To Existing Devices . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Informative References . . . . . . . . . . . . . . . . . . 10 10.2. Normative References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Wu, et al. Expires September 8, 2011 [Page 2] Internet-Draft IPv4 Header Option For User ID March 2011 1. Introduction Some existing applications, e.g. web server, FTP server, etc, may need to perform operations based on the user's IP address, e.g., controlling the number of sessions, anti-virus filtering, traffic control against malicious attack, account security assistance, etc. In the initial phase of IPv6 transition, CGNs are deployed to resolve the IPv4 public address depletion problem. Due to dynamic address mapping, some services and applications which require the knowledge of the source address will have problems. It is possible to query NAT log server or CGN to find out a user's source address [ID.draft-zhang-v6ops-cgn-source-trace], but this will impose high performance requirements on the NAT log server or CGN, and usually this kind of service is only available for law enforcement department of the operators themselves. If the address mapping information is carried as an IPv4 header option, it will help those services and applications work, with minimum impact to the network. An alternative solution is proposed by draft-wing-nat-reveal-option [draft-wing-nat-reveal-option]. The solution is based on TCP option; although quite some interesting applications are based on TCP, but there are still some scenarios it cannot cover, e.g., user traffic monitoring and analysis, and some UDP based applications. 1.1. 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]. 1.2. Terminology The following terms are used in this document: BNG: Broadband Network Gateway CPE: Customer Premises Equipment CGN: Carrier Grade NAT UID: User Identification UE: User Equipment Wu, et al. Expires September 8, 2011 [Page 3] Internet-Draft IPv4 Header Option For User ID March 2011 2. Motivating Scenarios +--------------+ +--------------+ +---------+ | | | | | | +------+ +-----+ +---------+ +-----+ +-----+ | Public | | CUST |_____| CPE |__| Accesss |__| BNG |______| CGN |___| IPv4 | | UE | | NAT | | Network | | | | | | Network | +------+ +-----+ +---------+ +-----+ +-----+ | | | Customer LAN | | Provider LAN | +---------+ +--------------+ +--------------+ Figure 1: NAT444 Deployment Dynamic IP address mapping in CGN will cause problems for services and applications which require knowledge of the source IP address. This section describes some typical scenarios where normal operations cannot be carried out without some mitigating measures such as those proposed in this document. 2.1. Limit The Number Of Sessions From An IP Address Some download services need to limit the number of concurrent sessions from a same IP address. But if CGN is deployed, multiple users may be sharing the same IP address, so that such a mechanism will prevent some users from accessing services properly. 2.2. Anti-virus Filtering And Limiting Malicious Attack Traffic Some existing traffic monitoring and analysis devices gather statistics and perform analysis, to enable anti-virus filtering based on the source IP address of packets. Some servers apply security policies based on source IP address to prevent malicious attacks [RFC4732]. For example, servers can refuse malicious users according to their source IP address to prevent drunk mail, malicious registration, etc. Deployment of CGN will impact the correct operation of traffic monitoring and analysis. 2.3. Account Security Assistance Some existing services provide user account security guarantees by combining authentication and the user's IP address. For example, the server can log the user's IP address each time the user logs in, and if the user logs in with an IP address different from the last one or the most often used one, the server can inform the user, and may ask the user for extra authentication information. The deployment of CGN will stop this kind of assistance from working. Wu, et al. Expires September 8, 2011 [Page 4] Internet-Draft IPv4 Header Option For User ID March 2011 3. User Identification (UID) IPv4 Header Option 3.1. Option Format The UID option consists of an option header and one or more instances of the NAT Mapping sub-option. The NAT Mapping sub-option is described in the next section. The UID option is illustrated in Figure 2. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Num | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : NAT Mapping(s) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: UID IPv4 Header Option Format The fields of the option header are defined as follows: Type: The option type, which has the format specified in [RFC0791] and the following specific sub-field values: Copied flag: 1 (copy into fragments) Option class: 2 (debugging and measurement) Option number: TBD. Length: Total length of the option in octets. As specified in [RFC0791], the length value includes the Type and Length octets in its count. Also as specified in [RFC0791], the maximum value of Length is 40 octets minus the length of any other IPv4 header options that are present. Num: The number of appended NAT Mapping sub-option instances. Wu, et al. Expires September 8, 2011 [Page 5] Internet-Draft IPv4 Header Option For User ID March 2011 Reserved: always 0. 3.2. NAT Mapping Sub-option Each instance of the NAT Mapping sub-option records the source of the packet from the point of view of the NAT adding that instance. Depending on the scenario, that source can be identified by an IPv4 address, IPv6 address, or one of several types of tunnel plus host or context identifier, depending on whether DS Lite or Gateway-Initiated DS Lite is used. The format of the NAT Mapping sub-option is shown in Figure 3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IdTyp |TIdTyp | Sequence | TId Length | Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context/Host Identifier (depending on IdTyp) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Identifier (depending on TIdTyp) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: NAT Mapping Sub-option Format The fields of the NAT Mapping sub-option are as follows: IdTyp: Type of context or host identifier. For native transport, this is either IPv4 address or IPv6 address. For DS Lite [ID.DS-Lite], it is always IPv4 address. For Gateway-Initiated DS Lite [ID.GI-DS-Lite], it is the type of the context identifier. This document specifies the following values for IdTyp: 00: reserved; 01: IPv4 address; 02: IPv6 address; 03: GRE key; 04: IPv6 Flow Label. Wu, et al. Expires September 8, 2011 [Page 6] Internet-Draft IPv4 Header Option For User ID March 2011 All other values are reserved. TIdTyp: Type of tunnel identifier. For native IP transport, this is NULL. For DS Lite, it is IPv6 address. For Gateway-Initiated DS Lite, it can be IPv4 or IPv6 address or MPLS VPN ID. Hence this document specifies the following values for TIdTyp: 00: NULL; 01: IPv4 address; 02: IPv6 address; 03: MPLS VPN ID. All other values are reserved. Sequence: Sequence number of the NAT Mapping sub-option instance, indicating the order in which it was added to the option. The sequence number is assigned to the instance when it is created, and never changes after that. As a result, downstream entities can know if instances have been deleted because of lack of space if the first instance present in the option does not have a sequence number equal to 1. TId Length: Length of the tunnel identifier. This is equal to 0 if the TIdTyp is NULL, 4 if the TIdTyp is IPv4 address, 16 if the TIdTyp is IPv6 address, and 7 if the TIdTyp is MPLS VPN ID. Pointer: The sum of the lengths of the Context/Host Identifier field, the Tunnel Identifier field, and the Padding field, effectively pointing to the end of the sub-option instance. Context/Host Identifier: The source address of the incoming packet, for native transport. The source address of the decapsulated packet, for DS Lite. The context identifier value, for Gateway-Initiated DS Lite. The length of this field is 16 for an IPv6 address and 4 for all other types. A context identifier of type Flow Label MUST be Wu, et al. Expires September 8, 2011 [Page 7] Internet-Draft IPv4 Header Option For User ID March 2011 constructed by placing the Flow Label in the least significant bits of the word in network byte order and setting the most significant bits to zeroes. Tunnel Identifier: For native transport, this field is empty. For tunneled transport, it is the IPv4 or IPv6 source address in the outer header or the MPLS VPN ID of the tunnel. Padding: Always 0. Present only when needed to extend the Tunnel Identifier to a four-octet boundary (i.e., when the identifier is an MPLS VPN ID). 3.3. Procedures 3.3.1. Procedures At a NAT If a NAT conforming to this specification receives a packet that it will forward as an IPv4 packet, then: o if the incoming packet (after decapsulation if applicable) was an IPv6 packet, or if it was an IPv4 packet but contained no UID header option, and if sufficient space exists in the IPv4 header to permit it, the NAT MUST add the UID option containing a single instance of the NAT Mapping sub-option. The sequence number of the instance MUST be 1. o if the incoming packet (after decapsulation if applicable) is an IPv4 packet containing the UID header option, the NAT MUST append an instance of the NAT Mapping sub-option to the existing sequence of instances. The sequence number of the new instance MUST be the sequence number of the preceding instance incremented by 1. For the settings of the remaining fields of the instance, see below. If the result is to cause the IPv4 header to exceed its limit of 60 octets [RFC0791], the NAT MUST delete the NAT Mapping sub- option with the lowest sequence number from the UID option. The NAT MUST repeat this action until the IPv4 header length does not exceed 60 octets. If as a result, no more sub-option instances remain in the UID option, the NAT MUST delete the option itself. In either case, the remaining fields are set according to the particular transport mechanism in use. Wu, et al. Expires September 8, 2011 [Page 8] Internet-Draft IPv4 Header Option For User ID March 2011 3.3.2. Procedures At an Edge Device Or Firewall Depending on local policy, edge routers or firewalls conforming to this specification MAY strip off the UID option on the outgoing interfaces if necessary, e.g., because the application server or end user may not be able to recognize the UID option, or because there may be potential interoperability issues in the communication between ISPs due to this option. In this case, the UID option is still useful for user traffic monitoring and analysis in the operator's network. 3.3.3. Procedures At Other Routers Other routers along the packet path should pass the option along unchanged and copy it to fragments when fragmentation occurs, simply in conformity to [RFC0791]. For greater certainty, routers conforming to this specification MUST behave as just described. 4. Maximum Transmission Unit Because IPv4 header options are inserted into packets, which will change the length of an IP packet, a NAT Device MUST modify the MTU value in an ICMP message accordingly when receiving or generating a ICMP Packet Too Big error message. 5. NAT configuration There SHOULD be a configurable parameter on the NAT for the administrator to enable/disable use of the UID option. 6. Impact To Existing Devices The UID option is in the IP header, and complies with the format defined in [RFC0791]. As mentioned in Section 3.3.3, any network devices that fully support [RFC0791] should handle the UID option without any change. User terminal devices do not have to support this option. Resolving the user identification problem via the UID option protects the existing investment and does not require extra cost while being compatible with existing user and network devices. Obviously the consuming applications such as download services, traffic monitoring and analysis, and enhanced identification need to be modified to make use of the information provided by the UID option. Wu, et al. Expires September 8, 2011 [Page 9] Internet-Draft IPv4 Header Option For User ID March 2011 7. Security Considerations TBD. 8. IANA Considerations This document defines a new IPv4 option type, which shall be allocated by IANA. This requires IANA to set up a new registry for IPv4 options. The initial population of this registry consists of the options defined in [RFC0791], plus the new option added by this specification. [Need to determine if any other options have been defined. Registry format to be added later.] 9. Acknowledgements To be completed. 10. References 10.1. Informative References [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- Service Considerations", RFC 4732, December 2006. [draft-wing-nat-reveal-option] Yourtchenko, A. and D. Wing, "Revealing hosts sharing an IP address using TCP option(work in progress)", August 2010. 10.2. Normative References [ID.DS-Lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion (Work in progress)", March 2011. [ID.GI-DS-Lite] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway Initiated Dual-Stack Lite Deployment(work in progress)", Oct 2010. [ID.draft-zhang-v6ops-cgn-source-trace] zhang, D., "Solution Model of Source Address Tracing for Carrier Grade NAT (CGN)(work in progress)", February 2011. Wu, et al. Expires September 8, 2011 [Page 10] Internet-Draft IPv4 Header Option For User ID March 2011 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Youming Wu China Telecom 109, Zhongshan Ave. West, Tianhe District Guangzhou 510630 P.R. China Phone: Email: wuym@gsta.com Hui Ji China Telecom NO19.North Street,CHAOYANGMEN,DONGCHENG District Beijing P.R. China Phone: Email: jihui@chinatelecom.com.cn Qi Chen (editor) China Telecom 109, Zhongshan Ave. West, Tianhe District Guangzhou 510630 P.R. China Phone: Email: chenqi.0819@gmail.com Tina Tsou (editor) Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Phone: Email: tena@huawei.com Wu, et al. Expires September 8, 2011 [Page 11]