Network Working Group D. Zhang Internet-Draft Huawei Symantec Intended status: Informational February 16, 2011 Expires: August 20, 2011 Solution Model of Source Address Tracing for Carrier Grade NAT (CGN) draft-zhang-v6ops-cgn-source-trace-00.txt Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 20, 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 Zhang Expires August 20, 2011 [Page 1]
Internet-Draft Source Tracing Model for CGN February 2011 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. Abstract Since NAT function on CGN box will make the IPv4 address re-used by more than one user, the packets sent outside CGN are not able to be identifid where they are from or which user they belong to according to the source address within the packets. However, under some certain circumstances, knowing the original source IP address and the identity of the user who sends the packet out is necessary. This document states the requirement of source address tracing briefly, and discusses the possible solution models for this issue. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirement Statement . . . . . . . . . . . . . . . . . . . . . 3 3.1. Legal Requirement . . . . . . . . . . . . . . . . . . . . . 3 3.2. Application Requirement . . . . . . . . . . . . . . . . . . 4 3.3. Existing Device Constriction . . . . . . . . . . . . . . . 5 4. Solution models for Source Address Tracing . . . . . . . . . . 5 4.1. Non-realtime Tracing Model . . . . . . . . . . . . . . . . 5 4.2. Realtime Tracing Model . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Zhang Expires August 20, 2011 [Page 2]
Internet-Draft Source Tracing Model for CGN February 2011 1. Introduction At this time of the document written, IPv4 addresses for IANA have been depleted. The network is going to experience a long migration stage to IPv6. Some transition solutions have been proposed, such as NAT444, DS-Lite, NAT64 and 6rd. In these solutions, translation is an important technology. The translator which executes the translation function in service provider network means Carrier Grade NAT (CGN) [I-D. draft-ietf-behave-lsn-requirements-00]. Here, the CGN scope in this document includes NAT44 and NAT64. NAT function on CGN box may make the IPv4 address in its address pool re-used by more than one user probably. Thus the packet seen from the outside of CGN cannot be identified based on the source address in the packet, which means it is difficult to know what the original source IP address is before translation and which user sends the packet. As the service providers consider their deployment solution of IPv6 transition, the source address tracing issue has been emphasized explicitly. Under some certain circumstances it is required tracking the source of the packet. Therefore, it is helpful for service provides to give a clear introduction on how to achieve the tracing of source address. This document states the requirement for source address tracing and discusses the possible solution models for this issue. 2. Terminology 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 [RFC2119]. 3. Requirement Statement The requirement of tracing the source address is forced by mainly three reasons. All the requirements below can happen not only in Fixed BroadBand (FBB) network, but also in Mobile BroadBand (MBB) network. And [I-D. draft-ietf-v6ops-v6-in-mobile-networks-03] indicates the same issue as well, espectially for mobile network. 3.1. Legal Requirement CGN box produces log records in which contains the session information used for packet translation. Because of the huge number of NAT log, the log records will be exported to a external log server. In order to monitor Internet, for some carriers, they are demanded conserving the NAT logs for a few months. Once an illegal behavior is present on Internet, legal department will request the carrier find out the subscriber who did it. Depending on the Zhang Expires August 20, 2011 [Page 3]
Internet-Draft Source Tracing Model for CGN February 2011 conserved logs, the carrier is capable of fulfilling the task. This type of requirement can be regards as non-realtime requirement. Generally, the source address tracing may happen later than the NAT binding state has been deleted on NAT box. 3.2. Application Requirement Carriers may provide some applications to the users. The application usually is a kind of application or service operated by the carrier itself. The application or service will provide the users who have subscribed it. For instance, a carrier supplies the subscribers with video, game, email and even broadband sevice management (maybe portal) by a unified web server. As a result, the subscriber identification may be needed. When a user visits the special application, the application server will identify the user by the source address. However, because of the deployed CGN, the IP address got from the source address field in the packet may be shared by more than one user. Thus, the application server must authenticate the subscriber by obtaining the original unique IP address assigned by the carrier, either an IPv4 private address or an IPv6 address. As a matter of fact, this requirement is a real-time trait, which is unlike the former one. The figure depicts the NAT444 case. The service provider allocates non-duplicated IPv4 address to different user's CPE. When the application server receives a packet translated by CGN, it will be confused which user the packet belongs to. Therefore, the authentication of application server could be incorrect. ----- ------------ | AAA | | log server | $ ----- ------------ $ $ \ / $ ---- ------- $ -------- $ |user|=|CPE/NAT|\$ / \ $ -------- ---- ------- \ ------ / IPv4 \ ----- $ | App | | BRAS |=| private |=| CGN |======| Server | ---- ------- / ------ \ address / ----- $ | | |user|=|CPE/NAT|/$ \ / $ -------- ---- ------- $ -------- $ $ $ $ $ Zhang Expires August 20, 2011 [Page 4]
Internet-Draft Source Tracing Model for CGN February 2011 3.3. Existing Device Constriction Service providers also offer value-added services by advanced technologies, such as DPI, P2P cache and so on. Here DPI is token as an example. It seems that most of the DPI products deployed in the network currently cannot support IPv6. It needs time for DPI vendors to develop IPv6 features. As depletion of IPv4 address, if a carrier intends to deploy IPv6-only network and use NAT64 to help users access IPv4 Internet, the placement of CGN should be considered carefully. This is a sort of real-time requirement as well. _____ $ | | IPv6 $ | DPI | IPv4 ---- $ |_____| |user|\ $ / _______ ---- \ ************ $ / / \ \ *********** * * ---- $ / ---- / IPv4 \ * Access *===* Core *=| CR |=====| BR | Internet | / * network * * netowrk * ---- $ ---- \ / / *********** * * / $ \_______/ ---- / ************ / $ |user| / $ ---- ----- $ | CGN | $ ----- $ The picture shows an example of possible network topology. For different service providers, there may be a variation. Since the existing DPI device does not support IPv6, the CGN with NAT64 function should be located lower, leaving the DPI in IPv4 realm. The carrier provides a value-added service, which depends on DIP to deal with billing and accounting. Because not all the users will subscribe the value-added service, and the source IPv4 addresses have been shared, DPI is not able to attach the traffic to the exact user. As a result source address tracing is inevitable in this case. 4. Solution models for Source Address Tracing In order to meet the foregoing requirements, service providers have to take the solution of source address tracing into account. In this section, the possible tracing models are discussed for reference. 4.1. Non-realtime Tracing Model The non-realtime tracing of source address is always suitable for legal requirement. Zhang Expires August 20, 2011 [Page 5]
Internet-Draft Source Tracing Model for CGN February 2011 The aim of tracing is to find out the user information. The lookup action happening on AAA server is indispensable. Hence, the AAA server should be provided with necessary lookup means, such as web, telnet and so on. As AAA server only has the binding between the user information and its IP address assigned originally, the log server is requested working together with AAA server. AAA server will obtain the translation binding according to the public IP address and using time from the log server. The public address and using time may be given by legal department. In this process, a special interface on log server should be implemented for responding the AAA's query message. The process could be demonstrated by the following figure. The operating node would be any PC or terminal by which the carrier launches the source address tracing. operating node AAA server log server | | | | web login or telnet | | |---------------------->| | | | | | user info lookup | | |---------------------->| | | | | | |translation record query| | |----------------------->| | | | | |session record response | | |<-----------------------| | | | | user info response | | |<----------------------| | | | | 4.2. Realtime Tracing Model The realtime tracing satisfies the need of user identity authentication of certain services or subscriber management, e.g. policy and billing. The tracing takes place when the user is online and initializing the service accessing. On account of this, the translation binding state is still preserved on CGN. Therefore, the NAT binding of session will be acquired from CGN, but not log server, in realtime tracing model. (If getting the binding state by log server with the same way as the non-realtime model, it could be unreliable. It is because that some CGN implementations may not send out the log message to log server before the session is expired or the session state is deleted.) So, CGN is demanded a interface for querying the NAT binding of session. Zhang Expires August 20, 2011 [Page 6]
Internet-Draft Source Tracing Model for CGN February 2011 The tracing procedures for the second and third requirements in section 3 can be seen as follows. user CGN Application server AAA server | | | | | data packet | | | |---------------->|---------------->| | | | | | | | | user authentication | | | |---------------------->| | | | | | | NAT state query | | |<----------------------------------------| | | | | | | session NAT state response | | |---------------------------------------->| | | | | | | |authentication response| | | |<----------------------| | | | | | | data packet | | |<----------------|<----------------| | | | | | user CGN DPI AAA server Internet | | | | | |data packet| | | | |---------->|------------->| | | | | | | | | | | user authentication | | | | |---------------------->| | | | | | | | | NAT state query | | | |<-------------------------------------| | | | | | | | | session NAT state response | | | |------------------------------------->| | | | | | | | | |authertication response| | | | |<----------------------| | | | | | | | | | data packet | | | | |---------------------------------->| | | | | | Zhang Expires August 20, 2011 [Page 7]
Internet-Draft Source Tracing Model for CGN February 2011 5. Security Considerations TBD 6. IANA Considerations This document has no IANA actions. 7. Acknowledgement 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 8.2. Informative References [I-D. draft-ietf-behave-lsn-requirements-00] Yamagate, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for IP address sharing schemes", April 2011. [I-D. draft-ietf-v6ops-v6-in-mobile-networks-03] Koodli, R., "Mobile Networks Considerations for IPv6 Deployment", January 2011. Author's Address Dong Zhang Huawei Symantec China EMail: zhangdong_rh@huaweisymantec.com Zhang Expires August 20, 2011 [Page 8]