Network Working Group                                              Y. Xu
Internet-Draft                                            Tsinghua Univ.
Intended status: Standards Track                                 P. Yang
Expires: April 10, 2009                                            Y. Ma
                                         Hitachi (China) R&D Corporation
                                                                 H. Deng
                                                            China Mobile
                                                                   K. Xu
                                                     Tsinghua University
                                                         October 7, 2008


            IKEv2 SA Synchronization for session resumption
                        draft-xu-ike-sa-sync-01

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 April 10, 2009.












Xu, et al.               Expires April 10, 2009                 [Page 1]


Internet-Draft                IKEv2 SA SYNC                 October 2008


Abstract

   It will take a long time and mass computation to do session
   resumption among IKE/IPsec gateways possibly maintaining huge numbers
   of IKEv2/IPsec SAs, when the serving gateway fails or over-loaded.
   The major reason is that the prcocedure of IKEv2 SA re-establishment
   will incur a time-consuming computation especially in the Diffie-
   Hellman exchange.  In this draft, a new IKE security associations
   synchronization solution is proposed to do fast IKE SA session
   resumption by directly transferring the indexed IKE SA (named stub)
   from old gateway to new gateway, wherein the most expensive Diffie-
   Hellman calculation can be avoided.  Without some time-consuming
   IKEv2 exchanges, the huge amount of IKE/IPsec SA session resumption
   procedures can be finished in a short time.


Table of Contents

   1.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Application scenarios of IKEv2 Session Resumption  . . . . . .  4
     2.1.  Scenario of IKEv2 Gateway fail . . . . . . . . . . . . . .  4
     2.2.  Scenario of load-balance . . . . . . . . . . . . . . . . .  5
   3.  Details on Proposed solution . . . . . . . . . . . . . . . . .  6
     3.1.  Overview of the Proposed solution  . . . . . . . . . . . .  6
     3.2.  data structure of stub . . . . . . . . . . . . . . . . . .  7
     3.3.  Consideration on building IKE SA in session resumption . .  7
     3.4.  Consideration on Stub handling . . . . . . . . . . . . . .  7
     3.5.  Consideration on location of Stub  . . . . . . . . . . . .  9
     3.6.  When should Gateways download/update Stub  . . . . . . . . 10
     3.7.  Related new messages . . . . . . . . . . . . . . . . . . . 11
   4.  Modification on the base IKEv2 protocol  . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 18















Xu, et al.               Expires April 10, 2009                 [Page 2]


Internet-Draft                IKEv2 SA SYNC                 October 2008


1.  Background

   IKEv2 protocol which has been defined by [RFC4306] provides us a
   method to negotiate ipsec's key automatically between ipsec clients
   and gateway.  Before negotiating ipsec's key, they should negotiate
   IKE's SA first.  Usually, ipsec client sends IKE_INIT message to
   gateway with SAi1, KEi, Ni, then gateway chooses some proposal of
   SAi1 which come to the algorithm for encryption and decryption, also
   proposal for Diffie-Hellman, and then calculates the Diffie-Hellman,
   sends IKE_INIT respond message back to ipsec client.  At this time,
   the most important keyring can be generated.  After other IKE_AUTH
   exchange, The identity has verified.  IKE SA has completely been
   established.  The timing overhead of IKEv2 protocol, including some
   computation and signaling round-trips, is rather big especially when
   the Extensible Authentication Protocol (EAP) is used for third-party
   authentication.  The picture below is the typical procedure for IKEv2
   SA establishment.

       Initiator                          Responder
       -----------                        -----------
    HDR, SAi1, KEi, Ni      -->

                               < -- HDR, SAr1, KEr, Nr, [CERTREQ]

    HDR, SK {IDi, [CERT,]
    [CERTREQ,] [IDr,],AUTH,
    SAi2, TSi, TSr}         -->
                               < -- HDR, SK {IDr, [CERT,] AUTH,
                                    SAr2, TSi, TSr}


   Figure 1: IKE_INIT and IKE_AUTH exchanges

   The establishment of an IKE SA in the first two exchanges of IKEv2
   procedure in [RFC4306] (especially Diffie-Hellman computation), is
   rather time-consuming.  Normally, the IKEv2/IPsec gateway embodyment
   (like IPsec VPN gateway, Mobile IPv6 Home Agent, etc) keeps a large
   number of IKE/IPsec sessions.  So in some scenarios (see Section 2),
   it will take a very time to re-establish all the IKE SA for session
   resumption of IKEv2/IPsec clients.











Xu, et al.               Expires April 10, 2009                 [Page 3]


Internet-Draft                IKEv2 SA SYNC                 October 2008


2.  Application scenarios of IKEv2 Session Resumption

2.1.  Scenario of IKEv2 Gateway fail


      IPsec                          old                    new/old
      client                         Gateway                gateway
       |                              |                        |
       |     IKE/IPsec SAs            |                        |
       |< ========================== >|                        |
       |                              |                        |
       |                              |                        |
       |                              O Fail of old GW         |
       |                              |                        |
       O detect the fail              |                        |
       | of old GW                    |                        |
       |                              |                        |
       |           new IKE init procedure                      |
       |< =================================================== >|
       |                              |                        |
       |           set up other child IPsec SAs                |
       |< =================================================== >|
       |                              |                        |


   Figure 2: scenarios of IKEv2 Gateway fail

   In this scenario, IPsec clients has established IKE/IPsec connections
   with old gateway with tunnel mode or transporation mode.  Because of
   some reason, the old gateway may fail.  In this case, IPsec client
   can know old gateway has failed(how to know gateway fail is out of
   our scope in this draft), and re-establish the IKEv2/IPsec sessions
   with the old gateway or another new gateway.  While a large number of
   IPsec clients try to make the IKEv2/IPsec connections at the same
   moment, it will take a rather long time due to the reason mentioned
   in Section 1.  And, the target gateway may have problem to response
   some clients in this case as well.  The problem statement and goals
   for a failover solution are described in [Narayanan06].













Xu, et al.               Expires April 10, 2009                 [Page 4]


Internet-Draft                IKEv2 SA SYNC                 October 2008


2.2.  Scenario of load-balance


      IPsec                          old                    new
      client                         Gateway                gateway
       |                              |                        |
       |     IKE/IPsec SAs            |                        |
       |< ========================== >|                        |
       |                              |                        |
       |                              |                        |
       |                              O overload of old GW     |
       |                              |                        |
       O detect the overload          |                        |
       | of old GW                    |                        |
       |                              |                        |
       |           new IKE init procedure                      |
       |< =================================================== >|
       |                              |                        |
       |           set up other child IPsec SAs                |
       |< =================================================== >|
       |                              |                        |


   Figure 3: load-balance scenarios

   In this scenario, after establishing IKE connections between IPsec
   clients and old gateway, the old gateway may be over-loading. then,
   some of the IPsec clients should stop the connection with old gateway
   and establish the connection with new gateway(how to know new gateway
   is also out of our scope).  Again, while many IKE/IPsec sessions are
   transferred from old gateway to new gateway, it is a challenge to new
   gateway to re-establish bunch of IKE SAs at the same time.



















Xu, et al.               Expires April 10, 2009                 [Page 5]


Internet-Draft                IKEv2 SA SYNC                 October 2008


3.  Details on Proposed solution

3.1.  Overview of the Proposed solution

   In this section, a new data structure is named as "stub", which has
   the most important information of IKE SA.  And gateway can use this
   data structure to accelerate the rebuilding of IKE SA.  IKE_INIT
   message is extended with a new payload called IKE_SA_SYN.  Since the
   gateway's IP address and SPI can uniquely index the stub of IKE SA,
   these two information are mandatory in the IKE_SA_SYN payload in
   order to retrieve the stub of IKE SA by the target gateway.  The
   detailed data structure of Stub is introduced in Section 3.2.

   The IKE SA session resumption procedure in this draft is depicted
   below:

   Initiator                                    Responder
   -----------                                  --------------
   HDRGBP[not]SAr1, KEi, Ni, [SYN]   --->
                                      < --      HDR, Nr

   Figure 4: IKE SA synchronization exchange

   o While the IPsec client notices that it has to be transfer from old
   gateway to target gateway and want to pursue the fast session
   resumption, it sends IKE_INIT message with the SYN payload.  The stub
   indexing information like old gateway IP address and old gateway's
   SPI shall be enclosed in the IKE SYN payload.

   o Upon receiving the IKE_INIT message with the IKE_SA_SYN payload,
   the target gateway uses the information inside to retrieve the the
   stub of previous IKE SA in the stub bank. if the retrieved stub is
   qualified for IKE SA re-building, the target gateway will choose the
   new SPI, derive the new set of keyring and re-establish the IKE
   session for the related client.  Lastly, it sends IKE_INIT response
   with new SPI in the IKEv2 header and Nr.  The new IKE_SA has been re-
   established successfully.

   If the taget gateway does not support IKE_SA_SYN or not find the
   proper stub, it can establish IKE SA by normal IKE_INIT and IKE_AUTH
   exchanges as specified in [RFC4306], or just drop the packet based on
   the local policy configured by network operator.

   The stub can be stored in an independent stub bank, co-located with
   target gateway or even co-located with the corresponding IPsec
   client.  This is discussed in Section 3.5.  However, the case of stub
   co-located with IPsec client is only optional in this draft.




Xu, et al.               Expires April 10, 2009                 [Page 6]


Internet-Draft                IKEv2 SA SYNC                 October 2008


3.2.  data structure of stub

   the stub data structure should conclude all these informations.

      o  IDi, IDr.
      o  SPIi, SPIr.
      o  SAr (the accepted proposal).
      o  SK_d_old.
      o  shared secret.
      o  old gateway's ip address.
      o  lifetime

   In the data structure of stub, the old gateway's ip address and SPI
   are used as the index for retrieval of stub.

   SAr have the encrypt and decrypt algorithm, and shared secrect is the
   DH exchange's result, we can calculate the IKE SA's keyring as rekey
   process.  It will be very quick.

3.3.  Consideration on building IKE SA in session resumption

   After the stub index has been presented by IKE client in the gateway,
   it will retrieve the stub from the stub bank.  The way to get the
   stub from the stub bank can be found in Section 3.4.

   As shown in Section 3.2, IDi, SA value can be obtained directly from
   the retrieved stub.  The target gateway shall choose the new SPIr
   (called SPIr_new in this draft) for the key derivation of session
   resumption.  The nounce values, Ni and Nr, are from the current IKE
   SYNC exchange.

   So, the new value of SKEYSEED is calculated as below (SK_d_old value
   is from the stub):

   SKEYSEED = prf (SK_d_old, Ni | Nr)

   And the keyring set are derived by the way of generic IKEv2

   {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+
                           (SKEYSEED, Ni | Nr | SPIi | SPIr_new )

   The prf (pseudo-random function) of the cryptographic algorithms is
   specified in the SA value of stub.

3.4.  Consideration on Stub handling

   1) generation




Xu, et al.               Expires April 10, 2009                 [Page 7]


Internet-Draft                IKEv2 SA SYNC                 October 2008


   After IKE SA has been established(after first two exchanges), the
   IKE/IPsec gateway extracts the stub from IKE SA.

   2) propagation

   After extracted from IKE SA, stubs should be updated to
   infrastructure such as stub bank.  The stub bank can be independent
   entity in the network or co-located with the gateways (see
   Section 3.5).

   3) Retrieve

   The gateway can use the the old gateway's ip address and spi can
   index the unique stub.

   4) Expire

   The stub may be invalid when the lifetime expires.  The value of
   lifetime is recommended to be same as the one in the IKE SA.  The
   gateway may set different lifetime in stub.

   5) Delete

   When the IKEv2/IPsec session is deleted, the gateway shall delete the
   related stubs in the stub bank.

   The following signaling shall be supported by IKE/IPsec gateways to
   communicate with Stub bank.

   o Initiate Stub:

   Gateway initiates the stub in the stub bank once new stub has been
   established.  The index shall at least include the gateway's IP
   address and SPI.

   o Update Stub:

   Gateway updates its stub to infrastructure once the related IKE SA
   has been changed

   o GET Stub:

   Gateway uses this message to receives stub by the information in
   IKE_SA SYN payload from IKE client.

   o Download Stub:

   The stub bank can use this message to push the stubs to gateway.



Xu, et al.               Expires April 10, 2009                 [Page 8]


Internet-Draft                IKEv2 SA SYNC                 October 2008


   o Delete Stub:

   The Gateway can delete the stubs while the related IKE SAs are no
   longer available.

3.5.  Consideration on location of Stub

   1.  Centralized infrastructure

    IPsec                  old        Target          stub
    client                 GW         GW              bank
       |                     |        |                 |
       |      IKE/IPsec      |        |                 |
       |< ================= >|        |    Update Stub  |
       |                     | ------------------------>|
       |                     o  Fail  |                 |
       |                     |        |                 |
       |         HDR,SAr1,KEi,Ni,SYN  |                 |
       |----------------------------->|  GET Stub       |
       |                     |        |---------------->|
       |                     |        |  Download Stub  |
       |                     |        |< ---------------|
       |      HDR,Nr         |        |                 |
       |< --------------------------- |                 |
       |                     |        |                 |

   Figure 5: centralized structure

   This proposal has a centralized Stub Bank server, gateway doesn't
   need local stub database.

   a) After IKE connection has been established, old gateway set up the
   stub to stub bank.

   b) Once the fast session resumption is started, IPsec client sends
   IKE_INIT with SYN payload.

   c) When the target gateway receives IKE_INIT with SYN payload, it
   asks Stub Bank for stub via GET Stub signaling.

   d) stub bank push proper stub to target gateway.

   e) Target gateway gets the stub and rebuild IKE SA, then send HDR, Nr
   to Notify IPsec client that the new IKE SA has been set up by IKE
   SYNC session resumption.

   2.  Distributed infrastructure




Xu, et al.               Expires April 10, 2009                 [Page 9]


Internet-Draft                IKEv2 SA SYNC                 October 2008


    IPsec                  Target                Old GW
    client                 gateway                Stub
       |                     |                     |
       |  HDR,SAr1,KEi,Ni,SYN|     Update Stub     |
       | ------------------->| < ------------------|
       | < ------------------|                     |
       |      HDR,Nr         |                     |

   Figure 6: distributed structure

   This structure doesn't have centralized Stub Bank, and all gateway
   must have local stub database. if there is stub in local database, it
   will find the stub in local database, otherwise, it will GET the stub
   from other gateways.

   a) After IKE connection has been established, old gateway initiates
   the stub to the potential target gateway.

   b) Once session resumption is initiated, IPsec client send IKE_INIT
   with SYN payload.

   c) Target gateway finds the proper stub and rebuild IKE SA, then send
   HDR, Nr to IPsec client.

   Gateway has to store stubs in distributed structure, but it seems
   more simple than centralized structure.  Also, these two proposals
   can mix together, other gateway also can be Stub Bank.

   3.  Full distributed in IKEv2/IPsec Client

   There is also the possibility that the Gateway or Stub bank push the
   stub to the corresponding client.  During the session resumption
   process, the target gateway can have another option to retrieve the
   stub from the corresponding client by the way specified in
   Section 3.4.  But, this way of stub co-located with IPsec client is
   ONLY OPTIONAL. if the operator wants to use this case, the stub MUST
   be protected perfectly by strong encryption and integrity protection.
   So, in this draft, it is only optional to co-locate the stub in the
   client.

3.6.  When should Gateways download/update Stub

   Because of the stub is not sensitive with time, the gateways assemble
   the stub messages to reduce the message number in initiate event.

   The single gateway can get many stubs at a time in download event.

   The gateway may also update the stubs in bundles whenever it was



Xu, et al.               Expires April 10, 2009                [Page 10]


Internet-Draft                IKEv2 SA SYNC                 October 2008


   thought to be necessary

3.7.  Related new messages

   1)IKE_SA_SYN Payload format

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         GateWay's SPI                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         GateWay's IP Address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   C bit is the direction of this message.

   2) Stub related signaling

   Header Format

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next   Payload|       type   |         Payload Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   type               number
                   Init           0x01
                   update         0x02
                   get            0x03
                   download       0x04
                   delete         0x05
                   reserved       0x00


                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next   Payload|   RESERVED   |         Payload Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         PAYLOAD CONTENT                       |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Xu, et al.               Expires April 10, 2009                [Page 11]


Internet-Draft                IKEv2 SA SYNC                 October 2008


4.  Modification on the base IKEv2 protocol

   As the core principle of this draft, the base IKEv2 protocol should
   be changed as little as possible.  In the proposal, three aspects
   require slight modification on IKEv2 protocol in [RFC4306]

   1) new IKE payload in the IKE_INIT message: IKE_SA_SYN

   2) Modification on the state machine

   IPsec client can send generic IKE_INIT message with SYN payload, if
   it decides to use the session resumption.  Upon receiving IKE_INIT
   response only with the Nr and SPIr_new, it will calculate the new IKE
   SA as IKE SA rekey.  And set state to IKE SA has been established. if
   the session resumption can not be accepted by the target gateway, the
   client will receive the usual IKE_INIT response as in [RFC4306] and
   continue the usual IKE_AUTH procedure afterwards

   The target gateway, once receives IKE_SA_SYN payload, will firstly
   find the proper stub. if the stub can be found successfully, it will
   follow the session resumption proecedure as specified in this draft:
   re-establish IKE SA, send IKE_INIT respond with Nr only to ipsec
   client, and set state to IKE SA has been established. if the session
   resumption can not be accepted by target gateway, it just follows the
   usual IKEv2 initiation procedure as in [RFC4306]

   3) The gateway should support the Stub related functions as specified
   in Section 3.4























Xu, et al.               Expires April 10, 2009                [Page 12]


Internet-Draft                IKEv2 SA SYNC                 October 2008


5.  Security Considerations

   the security framework of IKEv2 protocol will not be compromised in
   this solution.

   1) The stub index (Old gateway's IP address and SPI) in IKE_SA_SYN is
   a light-weighted information, which can be transported without
   encryption.  And it relies on IKE_INIT message to handle the replay
   protection and DoS attack.

   2) The Gateway can use SAr1, KEi to verify the identity, such as ID
   property.

   3) Even if the index is right and IPsec client cannot rebuild IKE_SA
   because of some reason, the newly re-built IKE SA in gateway will be
   deleted after somewhile.

   4) In the case of stub co-located with IPsec Client, the stub MUST be
   perfected protected to prevent the malicious attackers from cracking
   the stub, if they can obtain the stub on the network.  Actually, even
   if the stub is strongly encrypted, there still has the risk.  With
   the development of harware in accord with the Moore's Law, the
   capability of computing equipment will be increased step by step.
   Sometime, somehow, the brutal force decryption of the stub encryption
   method may be possible.  And, there is also posibility that the
   currently safe encryption algorithm may be proved to be
   mathematically solvable.  So, all in all, it is only optional to
   tranport the stub on the untrusted network, even if it can be
   protected strongly.






















Xu, et al.               Expires April 10, 2009                [Page 13]


Internet-Draft                IKEv2 SA SYNC                 October 2008


6.  Conclusion

   In this draft, a new solution is proposed to do IKE SA
   synchrinization for quick session resumption of IKE SA.  With the
   extension of IKE_SA_SYNC payload in IKE_INIT message, it can remove
   the most time-consuming IKEv2 exchanges to re-build the IKE SA, which
   makes it much faster to transfer millions of IKE sessions from old
   gateway to target gateway.  And the proposal in this draft will just
   slightly modify the base IKEv2 protocol with a new logical IKE SA
   Stub bank in the network.









































Xu, et al.               Expires April 10, 2009                [Page 14]


Internet-Draft                IKEv2 SA SYNC                 October 2008


7.  Normative References

   [Narayanan06]
              Narayanan, V., "IPsec Gateway Failover and Redundancy
              Problem Statement and Goals",
              draft-vidya-ipsec-failover-ps-00.txt (work in progress),
              December  2006.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [Sheffer07]
              Xie, Y., "Stateless Session Resumption for the IKE
              Protocol", draft-sheffer-ike-session-resumption-00.txt
              (work in progress), January 2007.




































Xu, et al.               Expires April 10, 2009                [Page 15]


Internet-Draft                IKEv2 SA SYNC                 October 2008


Authors' Addresses

   Yan Xu
   Tsinghua Univ.
   Department of Computer Science
   Tsinghua University
   Haidian District
   Beijing, 100088
   P.R. China

   Email: xydkl@163.com


   Peng Yang
   Hitachi (China) R&D Corporation
   301, North Wing, Tower C Raycom Infotech Park
   2 kexueyuan Nanlu
   Haidian District
   Beijing, 100080
   P.R. China

   Phone: +861082862918(ext.)328
   Email: peng.yang.chn@gmail.com


   Yuanchen Ma
   Hitachi (China) R&D Corporation
   301, North Wing, Tower C Raycom Infotech Park
   2 kexueyuan Nanlu
   Haidian District
   Beijing, 100080
   P.R. China

   Phone: +861082862918(ext.)327
   Email: ycma@hitachi.cn


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

   Email: denghui@chinamobile.com



Xu, et al.               Expires April 10, 2009                [Page 16]


Internet-Draft                IKEv2 SA SYNC                 October 2008


   Ke Xu
   Tsinghua University
   Department of Computer Science
   Tsinghua University
   Haidian District
   Beijing, 100088
   P.R. China

   Email: xuke@mail.tsinghua.edu.cn










































Xu, et al.               Expires April 10, 2009                [Page 17]


Internet-Draft                IKEv2 SA SYNC                 October 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.











Xu, et al.               Expires April 10, 2009                [Page 18]