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]