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

Versions: 00 01 02

TICTOC                                                             Y. Xu
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                       September 16, 2011
Expires: March 19, 2012


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

Abstract

   Cellular networks often use Internet standard technologies to handle
   synchronization.  This document defines an extension based on WESP.
   Usually, several traffic flows are carried in one IPsec tunnel, for
   some applications, such as, 1588 or NTP, the packets need to be
   identified after IPsec encryption to handle specially.  In order to
   achieve high scalability in implement, a separate IPsec tunnel will
   not be established for some special traffic.  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 January 6, 2012.

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



Xu                       Expires  March 19, 2012                 [Page 1]


Internet-Draft      IPsec security for synchronization          July 2011


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   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.

































Xu                       Expires  March 19, 2012                 [Page 2]


Internet-Draft      IPsec security for synchronization          July 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology used in this document  . . . . . . . . . . . . . .  6
   3.  Security requirements for synchronization  . . . . . . . . . .  6
   4.  Security mechanism for synchronization . . . . . . . . . . . .  6
   5.  The extension of WESP  . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Existing WESP format . . . . . . . . . . . . . . . . . . .  8
     5.2.  Extended WESP format . . . . . . . . . . . . . . . . . . .  9
     5.3.  Authentication field . . . . . . . . . . . . . . . . . . . 11
   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  IPv4/v6 consideration for IPsec based sychronization . . . . . 14
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     11.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
































Xu                       Expires  March 19, 2012                 [Page 3]


Internet-Draft      IPsec security for synchronization          July 2011


1.  Introduction

   When transferring 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
   are 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), a Femtocell (residential base
   station) requires 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  March 19, 2012                 [Page 4]


Internet-Draft      IPsec security for synchronization          July 2011


          +-------------+
          |             |
          |  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  March 19, 2012                 [Page 5]


Internet-Draft      IPsec security for synchronization          July 2011


   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 March 19, 2012                [Page 6]


Internet-Draft      IPsec security for synchronization          July 2011


   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.
   It provides security services by Authentication header (AH) and
   Encapsulating security payload (ESP).  Authentication Header provides
   integrity protection and data origin authentication.  Moreover, ESP
   can be used to provide confidentiality besides data origin
   authentication, connectionless integrity.  For the time packet
   protection, the critical issue is the precision of the timestamps.
   That is the receiver must mark the time as soon as possible when
   taking over the time packet, and the time will be used for frequency
   synchronization.  And in the implementation, an IPsec tunnel is
   created to carry all the traffic between the IPsec end points
   considering the cost of IPsec SA establishment, i.e., this IPsec
   tunnel will be used to protect both the service traffic packets and
   time packets.  Therefore, for protect against active and passive
   attack, confidentiality and integrity will be configured when
   deploying IPsec processing policy.  But nodes cannot recognize 1588
   packets as defined in [IEEE1588]as the port is encrypted by IPsec.
   It becomes complicated when processing IPsec packets as the nodes
   will not be able to identify the 1588 packets that need to be time
   stamped any more.  This document describes a method to resolve this
   problem.  For time packets, some identifiers that can be used to
   recognize all such packet at the physical layer are defined in WESP,
   and all of these are provided with data integrity protection.  For



Xu                       Expires  March 19, 2012                 [Page 7]


Internet-Draft      IPsec security for synchronization          July 2011


   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 mechanism. In this case, the synchronization
   packets will be encrypted if the packed is transported in the IPSec
   tunnel.

   IPsec can meet synchronization requirement 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.  The extension of WESP

   As discussed above section, it has advantage to identify whether the
   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 the WESP format to identify whether
   the received data packet is a timing packet or not.

5.1.  Existing WESP format

   [RFC5840] describes an encapsulating ESP, i.e., WESP, and affords an
   extension for ESP.  This document applies WESP to provide a mechanism
   to identify time packet within an IPsec tunnel, the IPSec endpoints
   could distinguish the time packet and do the corresponding
   synchronization processing.

   The WESP format is as follows:













Xu                       Expires  March 19, 2012                [Page 8]


Internet-Draft      IPsec security for synchronization          July 2011


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Header |    HdrLen     |  TrailerLen   | V VEP | Rsvd  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Padding (optional)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Existing ESP Encapsulation              |
   ~                                                             ~
   |                                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 2.  Format of an WESP Packet

   These fields are introduced with the extended WESP format in next
   section.

5.2.   Extended WESP format

   This document describes the extension for the WESP for the additional
   application.  It allows the ESP receiver or intermediate node not
   only distinguish encrypted and unencrypted traffic, but also identify
   whether the encrypted packets are the common packets or the time
   packets.

   The extension format is depicted as follows:


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Header |    HdrLen     |  TrailerLen   |   VVEP|Rsvd   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Authentication                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Padding(optional)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Existing ESP Encapsulation              |
   ~                                                             ~
   |                                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Figure 3.  The extended WESP format

   The definitions of these fields are as follows:



Xu                       Expires  March 19, 2012                [Page 9]


Internet-Draft      IPsec security for synchronization          July 2011


   o  Next Header is identical with the definition in [RFC5840].  It
      MUST be the same as the Next Header field in the ESP trailer when
      using ESP in the Integrity-only mode.  When using ESP with
      encryption, the "Next Header" field looses this name and semantics
      and becomes an empty field that MUST be initialized to all zeros.
      The receiver MUST ensure that the Next Header field in the WESP
      header is an empty field initialized to zero if using ESP with
      encryption.
   o  HdrLen is identical with the definition in [RFC5840].  It is the
      offset from the beginning of the WESP header to the beginning of
      the Rest of Payload Data (i.e., past the IV, if present and any
      other WESP options defined in the future) within the encapsulated
      ESP header, in octets.  HdrLen MUST be set to zero when using ESP
      with encryption.
   o  TrailerLen contains the size of the Integrity Check Value (ICV)
      being used by the negotiated algorithms within the IPsec SA.
      TrailerLen MUST be set to zero when using ESP with encryption. One
      issue must be taken into account that if using ESP with
      encryption, TrailerLen has lost the significance of ICV, as any
      attacker could juggle the field definition above, Next Header,
      HdrLen, TrailerLen to zero, and forward the modified packet to the
      receiver.  The receiver will deal with the dummy encrypted packet
      falsely.
   o  Authentication contains extended data type, extended data length,
      the optional Algorithm ID field and extended data and ICV when
      using ESP with encryption.  This part will be depicted in next
      section.
   o  Flags: The bits are defined most-significant-bit (MSB) first, so
      bit 0 is the most significant bit of the flags octet.  The four
      bits "Rsvd" are used for the future, the least significant bit of
      the four bit to indicate the some extended information is included
      when using ESP not only integrity but also with encryption, i.e.,
      if the least significant bit is set to one, the corresponding
      extended information will be contained in Authentication payload.

          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |V V|E|P| 0001  |
         +-+-+-+-+-+-+-+-+


   Figure 4: Flags Format

   The definitions of each specific field in flags is as follows:

   o  Version (V): It requires the new version number, and MUST be sent
      as 0 and checked by the receiver.




Xu                       Expires  March 19, 2012               [Page 10]


Internet-Draft      IPsec security for synchronization          July 2011


   o  Encrypted Payload (E): Setting the Encrypted Payload bit to 1
      indicates that the WESP (and therefore ESP) payload is protected
      with encryption.  If this bit is set to 0, then the payload is
      using integrity-only ESP.
   o  Padding header (P), 1 bit: If set (value 1), the 4-octet padding
      is present.  If not set (value 0), the 4-octet padding is absent.
      The alignment requirement must be guarantee as defined in
      [RFC5840].
   o  Rsvd, 4 bits: Reserved for future use.  The reserved bits MUST
      checked whether the least significant bit is set as 0 or 1.  If
      setting with 0, it will be ignored by the receiver.  If setting
      with 1, the receiver will check the correction by ICV, either
      TrailerLen using ESP without encryption or Authentication when
      using ESP with encryption.

5.3.  Authentication field

   The Authentication field is comprised of extended data type, extended
   data length, the optional Algorithm ID field and extended data and
   ICV when using ESP with encryption.  The extended data type indicates
   the packet type.  When the type is time packets, it could identify
   whether the time packet is the event message or not.  In addition,
   ICV parts offer 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 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 Header |      HdrLen   |   TrailerLen  |   VVEP|  Rsvd |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type     |      Len      |    Algorithm ID(optional)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                             |
   ~               Extended Data(optional)                       ~
   |                                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              ICV when ESP with encryption.                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Padding(optional)                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Existing ESP Encapsulation                      |
   ~                                                             ~
   |                                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Xu                       Expires March 19, 2012                [Page 11]


Internet-Draft      IPsec security for synchronization          July 2011


   Figure 5.  The detailed WESP format

   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 Extended Data
   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.  The following figure illustrates
   on how to use this new flexible ESP format to identify time packet.


   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 Header |      HdrLen   |  TrailerLen   |  VVEP | Rsvd  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   0001      |      Len      |     Algorithm ID(optional)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                             |
   ~                 Time packets information(optional)          ~
   |                                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Time packets identifier ICV                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Padding(optional)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Existing ESP Encapsulation                  |
   ~                                                             ~
   |                                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Figure 6.  WESP format for time-packet

   o  type (8-bit) - The value 0x1 here indicates that the extended
      context is time packet.
   o  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 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



Xu                       Expires  March 19, 2012               [Page 12]


Internet-Draft      IPsec security for synchronization          July 2011


      authentication data could be marked to indicate the integrity
      algorithm, such as HMAC-SHA1, HMAC-256, or others.  It is a part
      of Authentication payload.
   o  Time packets identifier integrity Check value (variable) - Time
      packets identifier integrity Check value, and used to guarantee
      the integrity of transmission.

   Time packets information, Algorithm ID are the optional fields.  As
   the integrity protection is only for the Extended Data when ESP with
   encryption 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 7. Example Procedure

   In the Security Gateway scenario, The IPsec with tunnel mode is



Xu                       Expires  March 19, 2012               [Page 13]


Internet-Draft      IPsec security for synchronization          July 2011


   established between Femtocell and Security Gateway.  After Femtocell
   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 unencrypted 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 WESP-
   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 describes the modification or extension for the WESP
   for the additional application.  The approach described in this
   document requires the ESP endpoints to be modified to support the new
   protocol.  It allows the ESP receiver or intermediate node not only
   to distinguish encrypted and unencrypted traffic deterministically,
   but also identify whether the encrypted packets are the common
   packets or the time packets by a simpler implementation for the
   transport node.

   Note that whether the time packets identified by the defined mark
   or tag are transparent or not, there is always a possibility for
   attackers to employ interception attacks to block transmission.
   How to prevent interception attack is out of scope of this draft.


9.  IANA Considerations

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







Xu                       Expires  March 19, 2012               [Page 14]


Internet-Draft      IPsec security for synchronization          July 2011


10.  Acknowledgments

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


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.

   [RFC5840]  Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped
              Encapsulating Security Payload (ESP) for Traffic
              Visibility", RFC 5840, April 2010.

11.2.  Informative References

   [3GPP.33.320]
              3GPP, "Security of Home Node B (HNB) / Home evolved Node B
              (HeNB)", 3GPP TS 33.320 10.3.0, June 2011.

   [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  March 19, 2012               [Page 15]


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