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

Versions: 00

Network Working Group                                              Y. Ma
Internet-Draft                                Hitachi (China) Research &
Intended status: Standards Track                 Development Corporation
Expires: August 21, 2008                                         H. Deng
                                                            China Mobile
                                                                   Y. Wu
                                                                 ZTE USA
                                                       February 18, 2008


       IPsec secured GRE tunnel demultiplexing problem statement
            draft-ma-softwire-ipsec-gre-demultiplexing-ps-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).










Ma, et al.               Expires August 21, 2008                [Page 1]


Internet-Draft        GRE demultiplexing for IPsec         February 2008


Abstract

   This document describes the IPsec secured GRE based VPN
   demultiplexing problem statement.  When two or more IPsec SAs are
   used to protect GRE encapsulated VPN network between the same pair of
   edge router, the current GRE based VPN does not support the edge
   router to demultiplex data for different IPsec SA.  GRE key provides
   one solution to demultiplex the VPNs secured by IPsec.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem statement  . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  softwire case  . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  layer 3 VPN case . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Remote access compulsory VPN case  . . . . . . . . . . . .  5
   3.  GRE key usage for IPsec secured VPN demultiplexing . . . . . .  7
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Consideration . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13



























Ma, et al.               Expires August 21, 2008                [Page 2]


Internet-Draft        GRE demultiplexing for IPsec         February 2008


1.  Introduction

   GRE is used to set up tunnel in many ways including the softwire mesh
   framework[softwire-mesh] and VPN network[RFC4023][RFC4110].  Also
   there are needs to protect GRE tunnel using IPsec for data plane of
   softwire mesh framework[softwire-sec-req] and l3vpn[l3vpn-ipsec].

   In [l3vpn-ipsec] it is noted that a number of different MPLS VPNs
   might need to have traffic carried from a particular ingress PE to a
   particular egress PE through an IP/IPsec based transport network.  It
   is thus natural to ask whether there should be one SA between the
   pair of PEs, or n SAs between the pair of PEs, where n is the number
   of VPNs.  Existing IPsec implementation does not allow multiple SAs
   to be used for multiple VPNs, because the VPN multiplexing is done by
   MPLS inner label and both MPLS-in-IP and MPLS-in-GRE encapsulation do
   not provide a mechanism to demultiplex VPN traffic based on IPsec
   selector.

   However there exists scenarios where multiple IPsec SAs are needed to
   protect the GRE tunnel between the same pair of PEs.  This documents
   descirbes several scenarios where multiple IPsec SAs are needed to
   protect GRE tunnels between the same pair.  And currently there is no
   mechanism for IPsec to demultiplexing GRE encapsulated packets.  And
   solution for IPsec SA to demultiplexing GRE encapsulated packets is
   proposed.


























Ma, et al.               Expires August 21, 2008                [Page 3]


Internet-Draft        GRE demultiplexing for IPsec         February 2008


2.  Problem statement

2.1.  softwire case

   Due to the address space limitation NAT is widely deployed for
   carrier's network.  As shown in Fig. 1, several subnets are connected
   to the GW through the AR.  The GRE tunnel is set up to encapsulate
   packets between AR and GW.  If for example, subnet 1 and subnet 2 has
   the same private IP address subnet, the GW can not differentiate data
   from the two subnets by the IP address.  In this case GRE key can be
   used to identify the tunnel from different subnets.

   If the carrier's network is connected to other networks by IPv6 only
   network, GRE will be used for data encapsulation.  The GRE key used
   between AR and GW should be kept for the GW to demultiplex the
   packets.

   IPsec will be used to encrypt the GRE encapsulated packets.  For
   different GRE tunnel, only one IPv6 IPsec SA will be used.  This will
   cause potential security threats.  Since if the IPsec is attacked,
   all the GRE tunnels will be affected.

   Also one advantage of GRE is that multicast can be supported by GRE.
   When multicast is taken into consideration, it is more desirable to
   provide different security level for different streams.  Currently
   there is no mechanism to separate multicast and unicast traffic
   encapsulated in different GRE tunnels for IPsec SAs between the same
   pair of GWs.  By providing multiplexing capability for IPsec SA to
   differentiate packets in different GRE tunnels between the same pair
   of GWs, such flexibility can be achieved.


     10.0.0.x/24
      +------+
      | AR 1 |-----GRE key=1-------+
      +------+                     |
     10.0.0.x/24                   |       IPv6 IPsec SA
      +------+                   +------+_________________+------+
      | AR 2 |-----GRE key=2-----| GW/  |=== GRE key=1 ===|      |
      +------+                   | AFBR |                 | AFBR |
         .                       |      |=== GRE key=2 ===|      |
         .                       |      |-----------------|      |
         .                       +------+                 +------+
         .                         |
     10.1.0.x/24                   |
      +------+                     |
      | AR n |------GRE------------+
      +------+



Ma, et al.               Expires August 21, 2008                [Page 4]


Internet-Draft        GRE demultiplexing for IPsec         February 2008


2.2.  layer 3 VPN case

   As shown in Fig. 2, in [l3vpn-ipsec] scenario where there might need
   to be two (or more) SAs between the same pair of PEs is depicted.
   One IPsec SA can be used for data encryption and another one can be
   used for authentication but not encryption.  This scenario actually
   describes a SA bundle case where ESP is applied first followed by AH
   protection on the same packet.  It is different than applying
   different SAs to different packets based on IPsec selector criteria.

   VPN security requirements are described in [RFC4111].  Clearly,
   different VPN contexts have different security requirements, hence
   may require different security protections.  Using one security
   association for all VPNs creates a greater risk if that security
   association is compromised.  There is a clear need to apply different
   IPsec SAs to different VPN contexts.  However, current IPsec
   implementation does not provide a mechanism that would allow
   demultiplexing VPN traffics into different SAs based on VPN contexts.
   Specifically, IPsec traffic selector is limited in VPN case.  It is
   solely based on protocol type field, which is GRE for GRE based VPN
   and MPLS for MPLS based VPN.


    +--------+                                                 +-------+
    | VPN 1  |-------------+                                   | VPN 1 |
    +--------+             |                                   +-------+
    +--------+          +----+ IPsec tunnel      +----+          |
    | VPN 2  |----------| PE |-------------------| PE |----------+
    +--------+          |    |=====GRE tunnel====|    |----------+
       .                |    |-------------------|    |          |
       .                |    |                   +----+        +-------+
       .                |    |                                 | VPN 2 |
       .                |    | IPsec tunnel      +----+        +-------+
       .                |    |-------------------| PE |
    +--------+          |    |=====GRE tunnel====|    |        +-------+
    | VPN n  |----------|    |-------------------|    |--------| VPN n |
    +--------+          +----+                   +----+        +-------+


2.3.  Remote access compulsory VPN case

   In remote access scenario, as shown in Fig. 3, different users access
   their home VPN gateways through an access network.  The AR in access
   network establishes a compulsory tunnel to the user!_s home VPN
   gateway.  The compulsory tunnel is traditionally L2TP [RFC2661],
   secured by IPsec [RFC3193].  However, all L2TP traffic, including
   user data and control signaling are protected by the same IPsec SA.




Ma, et al.               Expires August 21, 2008                [Page 5]


Internet-Draft        GRE demultiplexing for IPsec         February 2008


   If GRE tunnel can be used as compulsory tunnel mechanism, and
   different user traffics are multiplexed by GRE key.  There could be a
   way to provide different security protection based on GRE key field.
   A GRE compulsory tunnel would also reduce the overhead of PPP/L2TP,
   both payload and signaling perspective, and provides a direct point-
   to-point tunnel for address configuration, such as DHCPv4 [RFC2131]
   and RS/RA [RFC4861].  A GRE compulsory tunnel could also serve as a
   generic tunnel for both layer2 and layer 3 traffic, as well as IP
   multicast.


       +--------+
       | VPN  1 |
       | User 1 |-------------+
       +--------+             |
       +--------+          +----+ IPsec tunnel      +-------+
       | VPN  1 |          |    |                   |       |
       | User 2 |----------| AR |-------------------| VPN 1 |
       +--------+          |    |=====GRE tunnels===|  GW   |
          .                |    |-------------------|       |
          .                |    |                   +-------+
          .                |    |
          .                |    | IPsec tunnel      +-------+
          .                |    |-------------------| VPN n |
       +--------+          |    |=====GRE tunnels===|  GW   |
       | VPN n  |          |    |-------------------|       |
       | User m |----------|    |                   +-------+
       +--------+          +----+























Ma, et al.               Expires August 21, 2008                [Page 6]


Internet-Draft        GRE demultiplexing for IPsec         February 2008


3.  GRE key usage for IPsec secured VPN demultiplexing

   If the packets of the VPNs need to be demulplexed by the IPsec, one
   way is to use GRE key to provide the demulplexing capability.  The
   GRE tunnels are identified by GRE key.  GRE key is then used by IPsec
   SA as the traffic selector.  Although in [RFC4023] the usage of GRE
   key is not encouraged, it does not exclude the use of GRE key.

   However current IKE/IPsec implementation does not support GRE key as
   the traffic selector.  Extensions for IKE/IPsec is needed to support
   GRE key.








































Ma, et al.               Expires August 21, 2008                [Page 7]


Internet-Draft        GRE demultiplexing for IPsec         February 2008


4.  Security Considerations

   When multiple VPNs share an SA, the compromise of a key has a greater
   impact, and an attack on the security of one VPN may become an attack
   on the security of all the VPNs sharing the SA.  So the idea of using
   multiple IPsec SAs improves the security for IPsec secured VPN.













































Ma, et al.               Expires August 21, 2008                [Page 8]


Internet-Draft        GRE demultiplexing for IPsec         February 2008


5.  IANA Consideration

   This document defines no encodings, hence there are no IANA
   considerations.















































Ma, et al.               Expires August 21, 2008                [Page 9]


Internet-Draft        GRE demultiplexing for IPsec         February 2008


6.  Conclusion

   This document describes a demulplexing problem statement where
   multiple IPsec SAs are used to protect data of different VPNs between
   the same CE/PE or PE/PE pair.  GRE key is proposed to be used to
   demultiplex the data of different IPsec secured VPNs.













































Ma, et al.               Expires August 21, 2008               [Page 10]


Internet-Draft        GRE demultiplexing for IPsec         February 2008


7.  Normative References

   [l3vpn-ipsec]
              Rosen, E., "Architecture for the Use of PE-PE IPsec
              Tunnels in BGP/MPLS IP VPNs",
              draft-ietf-l3vpn-ipsec-2547-05 (work in progress),
              August 2005.

   [softwire-mesh]
              Wu, J., Cui, Y., Li, X., Metz, C., Rosen, E., Barber, S.,
              Mohapatra, P., and J. Scudder, "Softwire Mesh Framework",
              draft-ietf-softwire-mesh-framework-03 (work in progress),
              January 2008.

   [softwire-sec-req]
              Yamamoto, S., Williams, C., Parent, F., and H. Yokota,
              "Softwire Security Analysis and Requirements",
              draft-ietf-softwire-security-requirements-05 (work in
              progress), December 2007.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2661]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
              G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
              RFC 2661, August 1999.

   [RFC3193]  Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
              "Securing L2TP using IPsec", RFC 3193, November 2001.

   [RFC4023]  Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
              MPLS in IP or Generic Routing Encapsulation (GRE)",
              RFC 4023, March 2005.

   [RFC4111]  Fang, L., "Security Framework for Provider-Provisioned
              Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.











Ma, et al.               Expires August 21, 2008               [Page 11]


Internet-Draft        GRE demultiplexing for IPsec         February 2008


Authors' Addresses

   Yuanchen Ma
   Hitachi (China) Research & Development Corporation
   2, Kexueyuan Nanlu
   Haidian District,
   Beijing  100053
   China

   Email: ycma610103@gmail.com


   Hui Deng
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   Email: denghui@chinamobile.com


   Yingzhe Wu
   ZTE USA
   10105 Pacific Heights Blvd, Suite 250
   San Diego, CA  92121
   USA

   Email: yingzhe.wu@zteusa.com






















Ma, et al.               Expires August 21, 2008               [Page 12]


Internet-Draft        GRE demultiplexing for IPsec         February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Ma, et al.               Expires August 21, 2008               [Page 13]


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