idnits 2.17.1 draft-xu-tictoc-ipsec-security-for-synchronization-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 14) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 612 has weird spacing: '...rotocol for N...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 16, 2011) is 4577 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TICTOC Y. Xu 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track September 16, 2011 5 Expires: March 19, 2012 7 IPsec security for packet based synchronization 8 draft-xu-tictoc-ipsec-security-for-synchronization-02.txt 10 Abstract 12 Cellular networks often use Internet standard technologies to handle 13 synchronization. This document defines an extension based on WESP. 14 Usually, several traffic flows are carried in one IPsec tunnel, for 15 some applications, such as, 1588 or NTP, the packets need to be 16 identified after IPsec encryption to handle specially. In order to 17 achieve high scalability in implement, a separate IPsec tunnel will 18 not be established for some special traffic. This document analyses 19 the need for security methods for synchronization messages 20 distributed over the Internet. This document also gives a solution 21 on how to mark the synchronization message when IPSec is implemented 22 in end to end frequency synchronization." 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 6, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology used in this document . . . . . . . . . . . . . . 6 72 3. Security requirements for synchronization . . . . . . . . . . 6 73 4. Security mechanism for synchronization . . . . . . . . . . . . 6 74 5. The extension of WESP . . . . . . . . . . . . . . . . . . . . 8 75 5.1. Existing WESP format . . . . . . . . . . . . . . . . . . . 8 76 5.2. Extended WESP format . . . . . . . . . . . . . . . . . . . 9 77 5.3. Authentication field . . . . . . . . . . . . . . . . . . . 11 78 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 7. IPv4/v6 consideration for IPsec based sychronization . . . . . 14 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 When transferring timing in internet, a shared infrastructure is used, 91 and hence the path is no longer physically deterministic. It leaves 92 open the possibility to disrupt, corrupt or even spoof the timing 93 flow, where a timing signal purports to come from a higher quality 94 clock than it actually does. In the extreme, this may be used to 95 attack the integrity of the network, to disrupt the synchronization 96 flow, or cause authentication failures. On the other hand, it may be 97 possible for unauthorized users to request service from a clock 98 server. This may overload a clock server and compromise its ability 99 to deliver timing to authorized users. 101 For the cellular backhaul applications, two kinds of synchronization 102 are needed, one is the recovery of an accurate and stable frequency 103 synchronization signal as a reference for the radio signal (e.g. 104 GSM, UMTS FDD, LTE FDD). In addition to frequency synchronization, 105 phase/time synchronization are also needed in Mobile technologies, 106 This is the case for the TDD technologies such as UMTS TDD,LTE TDD. 108 Frequency synchronization is normally implemented in an end-to-end 109 scenario where none of the intermediate nodes in the network have to 110 recognize and process the synchronization packets. However In phase/ 111 time synchronization, a hop-by-hop scenario will request intermediate 112 nodes to process the synchronization packets If very accurate phase/ 113 time is needed (e.g. sub-microsecond accuracy). 115 Femtocell is the typical cellular backhaul application that requires 116 time synchronization. A Femtocell is defined as a wireless base 117 station for deployment in residential environments and is typically 118 connected to the mobile core network via a public broadband 119 connection (eg., DSL modem, cable modem). Femtocell improves 120 cellular network coverage and saves cost for operators. Just like a 121 typical macrocell (larger base station), a Femtocell (residential base 122 station) requires a certain level of synchronization (frequency or 123 phase/time) on the air interface, predominantly frequency 124 requirements. 126 The [3GPP.33.320] specification defines some of the high-level 127 network architecture aspects of a Home NodeB (3G UMTS) and a Home 128 eNodeB (4G LTE). In addition, the Femto Forum organization also 129 provides a network reference model very similar to 3GPP. Both 130 architectures have commonalities as illustrated in Figure 1. 132 +-------------+ 133 | | 134 | Femtocell |<-----------------------------+ 135 | | | 136 +-------------+ | 137 | 138 | 139 /---------------------\ 140 | | 141 | Public Network | 142 | | 143 \---------------------/ 144 | 145 | 146 +------------+ +-------------+ | 147 |Clock Server|---------->| | | 148 +------------+ | | | 149 | Security GW |->---+ 150 +------------+ | | 151 |Femto GW |---------->| | 152 +------------+ +-------------+ 154 Figure 1. Typical Architecture of a Femtocell Network 156 The network architecture shows that a public network is used to 157 establish connectivity between Femtocell and core network elements 158 (e.g., Security Gateway, Femto Gateway, Clock server, etc.). With 159 respect to synchronization process, Femtocell will therefore see 160 synchronization messages exchanged over the public network (e.g, 161 Internet). This presents a set of unique challenges for mobile 162 operators. 164 One challenge involves the security aspects of such the Femto 165 architecture. In both reference models, the communication between 166 Femtocell and Femto Gateway is secured by a mandatory Security 167 Gateway function. The Security Gateway is mandatory since the Femto 168 Gateway and Clock server communicate to Femtocell via a public 169 backhaul broadband connection (also known as the 3GPP iuh interface 170 or Femto Forum Fa interface). The [3GPP.33.320] specification 171 requires that the Femtocell SHALL support receiving time 172 synchronization messages over the secure backhaul link between 173 Femtocell and the Security Gateway, and Femtocell SHALL use IKEv2 174 protocol to set up at least one IPsec tunnel to protect the traffic 175 with Security Gateway. 177 This document provides analysis on security requirements for packet- 178 based synchronization and proposes IPsec security solution for end to 179 end frequency synchronization. 181 2. Terminology used in this document 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 3. Security requirements for synchronization 189 The ITUT [G.8265] specification provides general consideration on 190 synchronization security. Because packet-based timing streams may be 191 observed at different points in the network, there may be cases where 192 timing packets flow across multiple network domains which may 193 introduce specific security requirements. There may also be aspects 194 of security that may be related to both the network (e.g. 195 authentication and/or authorization) and to the synchronization 196 protocol itself. ITUT [G.8265] specification recommends to use 197 existing, standards-based security techniques to help ensure the 198 integrity of the synchronization. Examples may include encryption 199 and/or authentication techniques, or network techniques for 200 separating traffic, such as VLANs or LSPs. Specifically for the 201 performance issue, it may not be possible to implement some security 202 requirements without actually degrading the overall level of timing 203 or system performance. From above analysis, following 204 synchronizations requirements are listed: 205 1. synchronization client SHOULD be prevented from connecting to 206 rogue clock servers 207 2. clock servers SHOULD be prevented from providing service to 208 unauthorized synchronization client 209 3. Security mechanisms to achieve synchronization SHOULD minimize 210 any degradation in performance and this side effect SHOULD be 211 controlled to meet specific synchronization requirements(e.g., 212 Femtocell synchronization) 214 4. Security mechanism for synchronization 216 There are mainly two kinds of security mechanism used in current 217 synchronization: authentication-based and encryption-based. 219 For the authentication-based security mechanism, a shared secret key 220 between the synchronization client and the clock servers is used to 221 compute an authentication code (known as an "Integrity Check Value", 222 ICV) over the entire message datagram. [IEEE1588] contains an 223 experimental security annex defining an authentication-based 224 approach. This approach also implements a challenge-response 225 mechanism to confirm the creation of any security association (SA) 226 between a clock servers and a synchronization client. A limitation 227 of the process is that no method of sharing the key is proposed in 228 [IEEE1588]. This MUST be handled by other means. 230 For the encryption-based security mechanism, a shared-key approach is 231 also used. Instead of creating an ICV, the shared key is used to 232 encrypt the contents of the packet completely. The encryption might 233 be performed in the synchronization device itself, or it might be 234 performed in a separate device, e.g. a secure gateway. An example 235 might be where the timing packets have to pass through an encrypted 236 tunnel (e.g. an IPSec tunnel). Full encryption might be required for 237 various reasons. The contents of the packet may be considered 238 secret, such as might be the case where accuracy of the time 239 distribution is being sold as a service. Alternatively, it may be 240 because other traffic from a device is considered secret, and hence 241 it is easier to encrypt all traffic. 243 IPsec, as a popular security mechanism, is being considered in some 244 mobile applications, especially in case of unsecure backhaul links 245 (e.g. Femtocells, [3GPP.33.320]) being involved. IPsec can provide 246 data source authentication, confidentiality, integrity that is 247 suitable to end to end synchronization without intermediate nodes. 248 It provides security services by Authentication header (AH) and 249 Encapsulating security payload (ESP). Authentication Header provides 250 integrity protection and data origin authentication. Moreover, ESP 251 can be used to provide confidentiality besides data origin 252 authentication, connectionless integrity. For the time packet 253 protection, the critical issue is the precision of the timestamps. 254 That is the receiver must mark the time as soon as possible when 255 taking over the time packet, and the time will be used for frequency 256 synchronization. And in the implementation, an IPsec tunnel is 257 created to carry all the traffic between the IPsec end points 258 considering the cost of IPsec SA establishment, i.e., this IPsec 259 tunnel will be used to protect both the service traffic packets and 260 time packets. Therefore, for protect against active and passive 261 attack, confidentiality and integrity will be configured when 262 deploying IPsec processing policy. But nodes cannot recognize 1588 263 packets as defined in [IEEE1588]as the port is encrypted by IPsec. 264 It becomes complicated when processing IPsec packets as the nodes 265 will not be able to identify the 1588 packets that need to be time 266 stamped any more. This document describes a method to resolve this 267 problem. For time packets, some identifiers that can be used to 268 recognize all such packet at the physical layer are defined in WESP, 269 and all of these are provided with data integrity protection. For 270 example, if only frequency synchronization is needed, an end-to-end 271 scenario where none of the intermediate nodes in the network have to 272 recognise and process the synchronization packets might be suitable 273 to use IPsec security mechanism. In this case, the synchronization 274 packets will be encrypted if the packed is transported in the IPSec 275 tunnel. 277 IPsec can meet synchronization requirement 1 and 2 in section 3. 278 However IPsec still need some enhancement to meet requirement 3. 279 Normally, device will decrypt IPSec message in IP layer, but in order 280 to improve the synchronization accuracy, some synchronization 281 protocol (e.g. [IEEE1588]) requests to process the synchronization 282 message in hardware, therefore the synchronization device may need to 283 identify synchronization messages in physical layer before the 284 message is decrypted. How to identify the synchronization messages 285 in IPsec becomes the most important issue to keep the synchronization 286 accuracy in IPsec synchronization scenario. 288 5. The extension of WESP 290 As discussed above section, it has advantage to identify whether the 291 tunnel packets received by synchronization client are the special 292 timing packets or not. This section proposes a solution to identify 293 the timing packets When using IPsec to protect the whole time 294 synchronization message. The main thought is to use time packet 295 identifier which is included in the WESP format to identify whether 296 the received data packet is a timing packet or not. 298 5.1. Existing WESP format 300 [RFC5840] describes an encapsulating ESP, i.e., WESP, and affords an 301 extension for ESP. This document applies WESP to provide a mechanism 302 to identify time packet within an IPsec tunnel, the IPSec endpoints 303 could distinguish the time packet and do the corresponding 304 synchronization processing. 306 The WESP format is as follows: 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Next Header | HdrLen | TrailerLen | V VEP | Rsvd | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Padding (optional) | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Existing ESP Encapsulation | 316 ~ ~ 317 | | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Figure 2. Format of an WESP Packet 322 These fields are introduced with the extended WESP format in next 323 section. 325 5.2. Extended WESP format 327 This document describes the extension for the WESP for the additional 328 application. It allows the ESP receiver or intermediate node not 329 only distinguish encrypted and unencrypted traffic, but also identify 330 whether the encrypted packets are the common packets or the time 331 packets. 333 The extension format is depicted as follows: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Next Header | HdrLen | TrailerLen | VVEP|Rsvd | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Authentication | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Padding(optional) | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Existing ESP Encapsulation | 345 ~ ~ 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 3. The extended WESP format 351 The definitions of these fields are as follows: 353 o Next Header is identical with the definition in [RFC5840]. It 354 MUST be the same as the Next Header field in the ESP trailer when 355 using ESP in the Integrity-only mode. When using ESP with 356 encryption, the "Next Header" field looses this name and semantics 357 and becomes an empty field that MUST be initialized to all zeros. 358 The receiver MUST ensure that the Next Header field in the WESP 359 header is an empty field initialized to zero if using ESP with 360 encryption. 361 o HdrLen is identical with the definition in [RFC5840]. It is the 362 offset from the beginning of the WESP header to the beginning of 363 the Rest of Payload Data (i.e., past the IV, if present and any 364 other WESP options defined in the future) within the encapsulated 365 ESP header, in octets. HdrLen MUST be set to zero when using ESP 366 with encryption. 367 o TrailerLen contains the size of the Integrity Check Value (ICV) 368 being used by the negotiated algorithms within the IPsec SA. 369 TrailerLen MUST be set to zero when using ESP with encryption. One 370 issue must be taken into account that if using ESP with 371 encryption, TrailerLen has lost the significance of ICV, as any 372 attacker could juggle the field definition above, Next Header, 373 HdrLen, TrailerLen to zero, and forward the modified packet to the 374 receiver. The receiver will deal with the dummy encrypted packet 375 falsely. 376 o Authentication contains extended data type, extended data length, 377 the optional Algorithm ID field and extended data and ICV when 378 using ESP with encryption. This part will be depicted in next 379 section. 380 o Flags: The bits are defined most-significant-bit (MSB) first, so 381 bit 0 is the most significant bit of the flags octet. The four 382 bits "Rsvd" are used for the future, the least significant bit of 383 the four bit to indicate the some extended information is included 384 when using ESP not only integrity but also with encryption, i.e., 385 if the least significant bit is set to one, the corresponding 386 extended information will be contained in Authentication payload. 388 0 1 2 3 4 5 6 7 389 +-+-+-+-+-+-+-+-+ 390 |V V|E|P| 0001 | 391 +-+-+-+-+-+-+-+-+ 393 Figure 4: Flags Format 395 The definitions of each specific field in flags is as follows: 397 o Version (V): It requires the new version number, and MUST be sent 398 as 0 and checked by the receiver. 400 o Encrypted Payload (E): Setting the Encrypted Payload bit to 1 401 indicates that the WESP (and therefore ESP) payload is protected 402 with encryption. If this bit is set to 0, then the payload is 403 using integrity-only ESP. 404 o Padding header (P), 1 bit: If set (value 1), the 4-octet padding 405 is present. If not set (value 0), the 4-octet padding is absent. 406 The alignment requirement must be guarantee as defined in 407 [RFC5840]. 408 o Rsvd, 4 bits: Reserved for future use. The reserved bits MUST 409 checked whether the least significant bit is set as 0 or 1. If 410 setting with 0, it will be ignored by the receiver. If setting 411 with 1, the receiver will check the correction by ICV, either 412 TrailerLen using ESP without encryption or Authentication when 413 using ESP with encryption. 415 5.3. Authentication field 417 The Authentication field is comprised of extended data type, extended 418 data length, the optional Algorithm ID field and extended data and 419 ICV when using ESP with encryption. The extended data type indicates 420 the packet type. When the type is time packets, it could identify 421 whether the time packet is the event message or not. In addition, 422 ICV parts offer the authentication of data integrity for the whole 423 extended Data is provided. 425 The figure of the proposed flexible ESP format is as following: 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Next Header | HdrLen | TrailerLen | VVEP| Rsvd | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Type | Len | Algorithm ID(optional) | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | | 434 ~ Extended Data(optional) ~ 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | ICV when ESP with encryption. | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Padding(optional) | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Existing ESP Encapsulation | 442 ~ ~ 443 | | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Figure 5. The detailed WESP format 447 In Femtocell scenario, as the link between Security Gateway and clock 448 server is normally security path, the message transmitted between 449 them are in plain text. When Security Gateway receives the message, 450 it identifies the time packet at first, then put appropriate value to 451 Data type field to identify the message type in Payload Data. After 452 that, it could put more packet information into Extended Data 453 Payload, such as UDP port number or timestamps, then Extended Data 454 Length, Algorithm ID, Extended Data integrity Check value (Figure 4), 455 could also be filled consequently. The following figure illustrates 456 on how to use this new flexible ESP format to identify time packet. 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Next Header | HdrLen | TrailerLen | VVEP | Rsvd | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | 0001 | Len | Algorithm ID(optional) | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | | 465 ~ Time packets information(optional) ~ 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Time packets identifier ICV | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Padding(optional) | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Existing ESP Encapsulation | 473 ~ ~ 474 | | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 Figure 6. WESP format for time-packet 479 o type (8-bit) - The value 0x1 here indicates that the extended 480 context is time packet. 481 o Length (16-bit)- The length of whole extended additional 482 authentication data 483 o Time packets information(variable)- the addintional message 484 information, such as UDP port number or timestamps. It is a part 485 of Authentication payload. 486 o Algorithm ID- It indicates which algorithm could be used to 487 generate the extended data ICV. It is a part of Authentication 488 payload.The integrity algorithm negotiated during IKEv2 could be 489 used, also Algorithm ID field in the extended additional 490 authentication data could be marked to indicate the integrity 491 algorithm, such as HMAC-SHA1, HMAC-256, or others. It is a part 492 of Authentication payload. 493 o Time packets identifier integrity Check value (variable) - Time 494 packets identifier integrity Check value, and used to guarantee 495 the integrity of transmission. 497 Time packets information, Algorithm ID are the optional fields. As 498 the integrity protection is only for the Extended Data when ESP with 499 encryption but not for the whole ESP packet, the time delay of 500 calculation can be decreased. In addition, if the integrity 501 protection is not necessary, this part of security validation could 502 be ignored. 504 6. Example 506 In this section, the procedure to identify time packet in Security 507 Gateway scenario is depicted. 509 +-------------+ +------------+ +-------------+ 510 | | | | | | 511 | Femtocell |<-------------------->|Security GW |-----|Clock Server | 512 | | | | | | 513 +-------------+ +------------+ +-------------+ 514 | establish IPSec Tunnel | | 515 |<--------------------------------->| | 516 | | | 517 | Sync Request | | 518 |-----------------------------------|------------------>| 519 | | | 520 | Sync Response | | 521 |<----------------------------------|-------------------| 522 | | | 523 | message with time packets | | 524 |<----------------------------------|-------------------| 525 | | | 526 +--------------+ | | 527 |identify the | | | 528 |timing packet | | | 529 | | | | 530 +--------------+ | | 532 Figure 7. Example Procedure 534 In the Security Gateway scenario, The IPsec with tunnel mode is 535 established between Femtocell and Security Gateway. After Femtocell 536 and Clock server exchange the Sync Request and Sync Response, the 537 clock server will send the time packets to Femtocell to implement 538 frequency synchronization with the protection of IPsec tunnel. When 539 Femtocell receives the message, it can identify whether it is time 540 packet, and can also identify whether the time packet is the event 541 message by the time packet information in the unencrypted field as 542 defined in the new ESP format. If the message is time packet and 543 identifies that it is the event message, Femtocell will do special 544 process for the event message, such as recording the message 545 receiving time. On the server side, When Security Gateway receives 546 the message, it identifies the time packet at first, then put 547 appropriate value to Data type field to identify the message type in 548 Payload Data, after that, it could put more packet information into 549 Authentication Payload, such as UDP port number or timestamps, then 550 Extended Data Length, Algorithm ID, Extended Data integrity Check 551 value, could also be filled consequently. 553 7. IPv4/v6 consideration for IPsec based sychronization 555 IPsec is a security mechanism used both for IPv4 and IPv6, and WESP- 556 based solution has no impact on the IPv4 header and makes the 557 transition/migration from IPv4 to IPv6 seamless. 559 8. Security Considerations 561 This protocol variation inherits all the security properties of 562 regular ESP as described in [RFC4303]. 564 This document describes the modification or extension for the WESP 565 for the additional application. The approach described in this 566 document requires the ESP endpoints to be modified to support the new 567 protocol. It allows the ESP receiver or intermediate node not only 568 to distinguish encrypted and unencrypted traffic deterministically, 569 but also identify whether the encrypted packets are the common 570 packets or the time packets by a simpler implementation for the 571 transport node. 573 Note that whether the time packets identified by the defined mark 574 or tag are transparent or not, there is always a possibility for 575 attackers to employ interception attacks to block transmission. 576 How to prevent interception attack is out of scope of this draft. 578 9. IANA Considerations 580 There have been no IANA considerations so far in this document. 582 10. Acknowledgments 584 The authors appreciate the valuable work and contribution done to 585 this document by Marcus Wong. 587 11. References 589 11.1. Normative References 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, March 1997. 594 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 595 RFC 4303, December 2005. 597 [RFC5840] Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped 598 Encapsulating Security Payload (ESP) for Traffic 599 Visibility", RFC 5840, April 2010. 601 11.2. Informative References 603 [3GPP.33.320] 604 3GPP, "Security of Home Node B (HNB) / Home evolved Node B 605 (HeNB)", 3GPP TS 33.320 10.3.0, June 2011. 607 [G.8265] IEEE, "Architecture and requirements for packet based 608 frequency delivery", V0.2 June 2010. 610 [IEEE1588] 611 IEEE, "Standard for A Precision Clock Synchronization 612 Protocol for Networked Measurement and Control Systems", 613 IEEE Std 1588-2008. 615 Author's Address 617 Yixian Xu 618 Huawei Technologies 619 Huawei Building, Xinxi Road No.3 620 Haidian District, Beijing 100085 621 P. R. China 623 Phone: +86-10-82836300 624 Email: xuyixian@huawei.com