One document matched: draft-zhang-v6ops-cgn-source-trace-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 04:28:11 |