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

Versions: 00 01 02

TICTOC                                                             Y. Xu
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                        October 16, 2010
Expires: April 19, 2011


            IPsec security for packet based synchronization
       draft-xu-tictoc-ipsec-security-for-synchronization-00.txt

Abstract

   Cellular networks often use Internet standard technologies to handle
   synchronization.  This document analyses the need for security
   methods for synchronization messages distributed over the Internet.
   This document also gives a solution on how to mark the
   synchronization message when IPSec is implemented in end to end
   frequency synchronization."

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 April 19, 2011.

Copyright Notice

   Copyright (c) 2010 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
   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



Xu                       Expires April 19, 2011                 [Page 1]


Internet-Draft      IPsec security for synchronzation       October 2010


   described in the Simplified BSD License.

   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology used in this document  . . . . . . . . . . . . . .  5
   3.  Security requirements for synchronization  . . . . . . . . . .  5
   4.  Security mechanism for synchronization . . . . . . . . . . . .  5
   5.  ESP format enhancement . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Existing ESP format  . . . . . . . . . . . . . . . . . . .  7
     5.2.  Flexible ESP format  . . . . . . . . . . . . . . . . . . .  8
   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  IPv4/v6 consideration for IPsec based sychronization . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     11.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13


















Xu                       Expires April 19, 2011                 [Page 2]


Internet-Draft      IPsec security for synchronzation       October 2010


1.  Introduction

   When transfering timing in internet, a shared infrastructure is used,
   and hence the path is no longer physically deterministic.  It leaves
   open the possibility to disrupt, corrupt or even spoof the timing
   flow, where a timing signal purports to come from a higher quality
   clock than it actually does.  In the extreme, this may be used to
   attack the integrity of the network, to disrupt the synchronization
   flow, or cause authentication failures.  On the other hand, it may be
   possible for unauthorized users to request service from a clock
   server.  This may overload a clock server and compromise its ability
   to deliver timing to authorized users.

   For the cellular backhaul applications, two kinds of synchronization
   is needed, one is the recovery of an accurate and stable frequency
   synchronization signal as a reference for the radio signal (e.g.
   GSM, UMTS FDD, LTE FDD).  In addition to frequency synchronization,
   phase/time synchronization are also needed in Mobile technologies,
   This is the case for the TDD technologies such as UMTS TDD,LTE TDD.

   Frequency synchronization is normally implemented in an end-to-end
   scenario where none of the intermediate nodes in the network have to
   recognize and process the synchronization packets.  However In phase/
   time synchronization, a hop-by-hop scenario will request intermediate
   nodes to process the synchronization packets If very accurate phase/
   time is needed (e.g. sub-microsecond accuracy).

   Femtocell is the typical cellular backhaul application that requires
   time synchronization.  A Femtocell is defined as a wireless base
   station for deployment in residential environments and is typically
   connected to the mobile core network via a public broadband
   connection (eg., DSL modem, cable modem).  Femtocell improves
   cellular network coverage and saves cost for operators.  Just like a
   typical macrocell (larger base station), Femtocells (residential base
   stations) require a certain level of synchronization (frequency or
   phase/time) on the air interface, predominantly frequency
   requirements.

   The [3GPP.33.320] specification defines some of the high-level
   network architecture aspects of a Home NodeB (3G UMTS) and a Home
   eNodeB (4G LTE).  In addition, the Femto Forum organization also
   provides a network reference model very similar to 3GPP.  Both
   architectures have commonalities as illustrated in Figure 1.








Xu                       Expires April 19, 2011                 [Page 3]


Internet-Draft      IPsec security for synchronzation       October 2010


          +-------------+
          |             |
          |  Femtocell  |<-----------------------------+
          |             |                              |
          +-------------+                              |
                                                       |
                                                       |
                                           /---------------------\
                                           |                     |
                                           |   Public Network    |
                                           |                     |
                                           \---------------------/
                                                       |
                                                       |
          +------------+           +-------------+     |
          |Clock Server|---------->|             |     |
          +------------+           |             |     |
                                   | Security GW |->---+
          +------------+           |             |
          |Femto GW    |---------->|             |
          +------------+           +-------------+




   Figure 1.  Typical Architecture of a Femtocell Network

   The network architecture shows that a public network is used to
   establish connectivity between Femtocell and core network elements
   (e.g., Security Gateway, Femto Gateway, Clock server, etc.).  With
   respect to synchronization process, Femtocell will therefore see
   synchronization messages exchanged over the public network (e.g,
   Internet).  This presents a set of unique challenges for mobile
   operators.

   One challenge involves the security aspects of such the Femto
   architecture.  In both reference models, the communication between
   Femtocell and Femto Gateway is secured by a mandatory Security
   Gateway function.  The Security Gateway is mandatory since the Femto
   Gateway and Clock server communicate to Femtocell via a public
   backhaul broadband connection (also known as the 3GPP iuh interface
   or Femto Forum Fa interface).  The [3GPP.33.320] specification
   requires that the Femtocell SHALL support receiving time
   synchronization messages over the secure backhaul link between
   Femtocell and the Security Gateway, and Femtocell SHALL use IKEv2
   protocol to set up at least one IPsec tunnel to protect the traffic
   with Security Gateway.




Xu                       Expires April 19, 2011                 [Page 4]


Internet-Draft      IPsec security for synchronzation       October 2010


   This document provides analysis on security requirements for packet-
   based synchronization and proposes IPsec security solution for end to
   end frequency synchronization.


2.  Terminology used in this document

   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.  Security requirements for synchronization

   The ITUT [G.8265] specification provides general consideration on
   synchronization security.  Because packet-based timing streams may be
   observed at different points in the network, there may be cases where
   timing packets flow across multiple network domains which may
   introduce specific security requirements.  There may also be aspects
   of security that may be related to both the network (e.g.
   authentication and/or authorization) and to the synchronization
   protocol itself.  ITUT [G.8265] specification recommends to use
   existing, standards-based security techniques to help ensure the
   integrity of the synchronization.  Examples may include encryption
   and/or authentication techniques, or network techniques for
   separating traffic, such as VLANs or LSPs.  Specifically for the
   performance issue, it may not be possible to implement some security
   requirements without actually degrading the overall level of timing
   or system performance.  From above analysis, following
   synchronizations requirements are listed:
   1.  synchronization client SHOULD be prevented from connecting to
       rogue clock servers
   2.  clock servers SHOULD be prevented from providing service to
       unauthorized synchronization client
   3.  Security mechanisms to achieve synchronization SHOULD minimize
       any degradation in performance and this side effect SHOULD be
       controlled to meet specific synchronization requirements(e.g.,
       Femtocell synchronization)


4.  Security mechanism for synchronization

   There are mainly two kinds of security mechanism used in current
   synchronization: authentication-based and encryption-based.

   For the authentication-based security mechanism, a shared secret key
   between the synchronization client and the clock servers is used to
   compute an authentication code (known as an "Integrity Check Value",



Xu                       Expires April 19, 2011                 [Page 5]


Internet-Draft      IPsec security for synchronzation       October 2010


   ICV) over the entire message datagram.  [IEEE1588] contains an
   experimental security annex defining an authentication-based
   approach.  This approach also implements a challenge-response
   mechanism to confirm the creation of any security association (SA)
   between a clock servers and a synchronization client.  A limitation
   of the process is that no method of sharing the key is proposed in
   [IEEE1588].  This MUST be handled by other means.

   For the encryption-based security mechanism, a shared-key approach is
   also used.  Instead of creating an ICV, the shared key is used to
   encrypt the contents of the packet completely.  The encryption might
   be performed in the synchronization device itself, or it might be
   performed in a separate device, e.g. a secure gateway.  An example
   might be where the timing packets have to pass through an encrypted
   tunnel (e.g. an IPSec tunnel).  Full encryption might be required for
   various reasons.  The contents of the packet may be considered
   secret, such as might be the case where accuracy of the time
   distribution is being sold as a service.  Alternatively, it may be
   because other traffic from a device is considered secret, and hence
   it is easier to encrypt all traffic.

   IPsec,as a popular security mechanism, is being considered in some
   mobile applications, especially in case of unsecure backhaul links
   (e.g.  Femtocells, [3GPP.33.320]) being involved.  IPsec can provide
   data source authentication, confidentiality, integrity that is
   suitable to end to end synchronization without intermediate nodes .
   For example, if only frequency synchronization is needed, an end-to-
   end scenario where none of the intermediate nodes in the network have
   to recognise and process the synchronization packets might be
   suitable to use IPsec security mechansim.  In this case, the
   synchronization packets will be encrypted if the packed is
   transported in the IPSec tunnel.

   IPsec can meet synchronization rquirement 1 and 2 in section 3,
   however IPsec still need some enhancement to meet requirement 3 .
   Normally, device will decrypt IPSec message in IP layer, but in order
   to improve the synchronization accuracy, some synchronization
   protocol (e.g.  [IEEE1588]) requests to process the synchronization
   message in hardware, therefore the synchronization device may need to
   identify synchronization messages in physical layer before the
   message is decrypted.  How to identify the synchronization messages
   in IPsec becomes the most important issue to keep the synchronization
   accuracy in IPsec synchronization scenario.


5.  ESP format enhancement

   As discussed above section, it has advantage to identify whether the



Xu                       Expires April 19, 2011                 [Page 6]


Internet-Draft      IPsec security for synchronzation       October 2010


   tunnel packets received by synchronization client are the special
   timing packets or not.  This section proposes a solution to identify
   the timing packets When using IPsec to protect the whole time
   synchronization message.  The main thought is to use time packet
   identifier which is included in a new defined flexible ESP format to
   identify whether the received data packet is a timing packet or not.

5.1.   Existing ESP format

   ESP provides confidentiality, data integrity, access control, and
   data source authentication to IP datagrams as specified in [RFC4303].
   The ESP contains several parts (Figure 2): Security Parameters
   Index(SPI) and Sequence Number(SQN),ESP Payload,ESP trailer and the
   ICV.  SPI and SQN are used to identity a SA and replay protection
   respectively.  ESP trailer is comprised of Padding, Pad length, Next
   Header.  The integrity scope is from SPI to Next Header.  The
   encryption protection is provided for the Payload Data and ESP
   trailer.  For SPI and SQN, only the authentication of data integrity
   is provided.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
|               Security Parameters Index (SPI)                 | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|                      Sequence Number                          | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
|                    Payload Data* (variable)                   | |   ^
~                                                               ~ |   |
|                                                               | |Conf.
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|               |     Padding (0-255 bytes)                     | |ered*
+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   |
|                               |  Pad Length   | Next Header   | v   v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|         Integrity Check Value-ICV   (variable)                |
~                                                               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Figure 2.  Top-Level Format of an ESP Packet

   Except for the fields discussed above, there are no other reserved
   bits in ESP.  However, In the protection of time packets over IPsec
   scenario, the time packet is encrypted in Payload Data, the receiver
   could not identify whether it is the time packet or not.



Xu                       Expires April 19, 2011                 [Page 7]


Internet-Draft      IPsec security for synchronzation       October 2010


5.2.   Flexible ESP format

   This documents proposes to define a new flexible ESP format.  The new
   extended ESP format not only contains the fields described in
   [RFC4303], but also has additional authentication information.  The
   additional authentication information is comprised of ESP special
   usage flags(one octet zeros),extended data type, extended data
   length, and Authentication Payload (Figure 3).  In the extended ESP
   additional authentication information, it includes a data type to
   identify the time packets, and could also identify whether the time
   packet is the event message or not by addintional time-packet
   information in Authentication Payload.  In addition, the
   authentication of data integrity for the whole extended Data is
   provided.  The figure of the proposed flexible ESP format is as
   following:

         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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               Security Parameters Index (SPI)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Sequence Number (32-bit)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 0 0 0 0 0 |     Type     |         Length                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                                                               ~
       |                 Authentication Payload (variable)             |
       ~                                                               ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Payload Data* (variable)                   |
       ~                                                               ~
       |                                                               |
       +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               |     Padding (0-255 bytes)                     |
       +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               | Pad Length    | Next Header   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Integrity Check Value-ICV   (variable)                |
       ~                                                               ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 3.  New defined ESP format with 32-bit Sequence Number

   o  Security Parameters Index(32-bit)-Defined in [RFC4303].





Xu                       Expires April 19, 2011                 [Page 8]


Internet-Draft      IPsec security for synchronzation       October 2010


   o  Sequence Number (32-bit or the extended 64-bit)-Defined in
      [RFC4303].
   o  One octet zero bits - The inspection bits, used to distinguish
      from the existing ESP.
   o  ED-Type(Extended Data Type (8-bit))- The message type flag in
      extended additional authentication information which indicates the
      message type in encryped Payload Data.
   o  ED-Length(Extended Data Length (16-bit))- The length of extended
      additional authentication data contains the whole extended
      additional authentication information.
   o  Authentication Payload- It contains additional message
      information, and also contains the information of integrity for
      extended data, such as, integrity algorithm, and the extended data
      integrity check value. it is an optional part to provide more
      information of encrypted messages in Payload Data and also provide
      authentication of data integrity for extended data, which includes
      One octet zero bits, Extended Data Type, Extended Data Length and
      Authentication Payload data.
   o  Other fields- Defined in [RFC4303].

   In Femtocell scenario, as the link between Security Gateway and clock
   server is normally security path, the message transmitted between
   them are in plain text.  When Security Gateway receives the message,
   it identifies the time packet at first, then put appropriate value to
   Data type field to identify the message type in Payload Data, after
   that, it could put more packet information into Authentication
   Payload, such as UDP port number or timestamps, then Extended Data
   Length, Algorithm ID, Extended Data integrity Check value (Figure 4),
   could also be filled consequently. following figure illustrates on
   how to use this new flexible ESP format to identify time packet.





















Xu                       Expires April 19, 2011                 [Page 9]


Internet-Draft      IPsec security for synchronzation       October 2010


         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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               Security Parameters Index (SPI)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Sequence Number (32-bit)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1|        Length                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Time packets information                   ~
       |                                                               |
       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               | Algorithm or Algorithm ID     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Time packets identifier ICV                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Payload Data* (variable)                   |
       ~                                                               ~
       |                                                               |
       +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               |     Padding (0-255 bytes)                     |
       +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |  Pad Length   | Next Header   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Integrity Check Value-ICV   (variable)                |
       ~                                                               ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Figure 4.  New defined ESP format with 32-bit Sequence Number for
   time-packet

   o  Extended Data Type (8-bit) - The value 0x1 here indicates that the
      extended context is time packet.
   o  Extended Data Length (16-bit)- The length of whole extended
      additional authentication data
   o  Time packets information(variable)- the addintional message
      information, such as UDP port number or timestamps.  It is a part
      of Authentication payload.
   o  Algorithm or Algorithm ID- It indicates which algorithm could be
      used to generate the extended data ICV.  It is a part of
      Authentication payload.The integrity algorithm negotiated during
      IKEv2 could be used, also Algorithm ID field in the extended
      additional authentication data could be marked to indicate the
      integrity algorithm, such as HMAC- SHA1, HMAC-256, or others.  It



Xu                       Expires April 19, 2011                [Page 10]


Internet-Draft      IPsec security for synchronzation       October 2010


      is a part of Authentication payload.
   o  Extended Data integrity Check value (variable) - Time packets
      identifier integrity Check value.It is a part of Authentication
      payload.

   Time packets information, Algorithm or Algorithm ID and Extended Data
   integrity Check value form the Authentication Payload, it is an
   optinal field and used to guarantee the integrity of transmission.
   As the integrity protection is only for the Extended Data but not for
   the whole ESP packet, the time delay of calculation can be decreased.
   In addition, if the integrity protection is not necessary, this part
   of security validation could be ignored.


6.  Example

   In this section, the procedure to identify time packet in Security
   Gateway scenario is depicted.


 +-------------+                      +------------+     +-------------+
 |             |                      |            |     |             |
 |  Femtocell  |<-------------------->|Security GW |-----|Clock Server |
 |             |                      |            |     |             |
 +-------------+                      +------------+     +-------------+
        |      establish IPSec Tunnel       |                   |
        |<--------------------------------->|                   |
        |                                   |                   |
        |                    Sync Request   |                   |
        |-----------------------------------|------------------>|
        |                                   |                   |
        |                    Sync Response  |                   |
        |<----------------------------------|-------------------|
        |                                   |                   |
        |       message with time packets   |                   |
        |<----------------------------------|-------------------|
        |                                   |                   |
 +--------------+                           |                   |
 |identify the  |                           |                   |
 |timing packet |                           |                   |
 |              |                           |                   |
 +--------------+                           |                   |


   Figure 5. example procedure

   In the Security Gateway scenario, The IPsec with tunnel mode is
   established between Femtocell and Security Gateway.  After Femtocell



Xu                       Expires April 19, 2011                [Page 11]


Internet-Draft      IPsec security for synchronzation       October 2010


   and Clock server exchange the Sync Request and Sync Response, the
   clock server will send the time packets to Femtocell to implement
   frequency synchronization with the protection of IPsec tunnel.  When
   Femtocell receives the message, it can identify whether it is time
   packet, and can also identify whether the time packet is the event
   message by the time packet information in the unencryped field as
   defined in the new ESP format.  If the message is time packet and
   identifies that it is the event message, Femtocell will do special
   process for the event message, such as recording the message
   receiving time.  On the server side, When Security Gateway receives
   the message, it identifies the time packet at first, then put
   appropriate value to Data type field to identify the message type in
   Payload Data, after that, it could put more packet information into
   Authentication Payload, such as UDP port number or timestamps, then
   Extended Data Length, Algorithm ID, Extended Data integrity Check
   value, could also be filled consequently.


7.  IPv4/v6 consideration for IPsec based sychronization

   IPsec is a security mechanism used both for IPv4 and IPv6, and ESP-
   based solution has no impact on the IPv4 header and makes the
   transition/migration from IPv4 to IPv6 seamless.


8.  Security Considerations

   This protocol variation inherits all the security properties of
   regular ESP as described in [RFC4303].

   This document defines a new flexible ESP format, which contains
   Extended Data Type Extended Data Length and additional authentication
   paylaod.  The authentication of data integrity for the extended data
   is provided, and the data type is carried in the unencryption part.
   Therefore the receiver could identify whether the receiving messages
   are time packets or not.


9.  IANA Considerations

   There have been no IANA considerations so far in this document.


10.  Acknowledgments

   The authors appreciate the valuable work and contribution done to
   this document by Marcus Wong.




Xu                       Expires April 19, 2011                [Page 12]


Internet-Draft      IPsec security for synchronzation       October 2010


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

11.2.  Informative References

   [3GPP.33.320]
              3GPP, "Security of Home Node B (HNB) / Home evolved Node B
              (HeNB)", 3GPP TS 33.320 10.0.0, October 2010.

   [G.8265]   IEEE, "Architecture and requirements for packet based
              frequency delivery", V0.2 June 2010.

   [IEEE1588]
              IEEE, "Standard for A Precision Clock Synchronization
              Protocol for Networked Measurement and Control Systems",
              IEEE Std 1588-2008.


Author's Address

   Yixian Xu
   Huawei Technologies
   Huawei Building, Xinxi Road No.3
   Haidian District, Beijing  100085
   P. R. China

   Phone: +86-10-82836300
   Email: xuyixian@huawei.com
















Xu                       Expires April 19, 2011                [Page 13]


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