[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/