idnits 2.17.1 draft-xu-ike-sa-sync-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 646. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 411: '... ONLY OPTIONAL. if the operator want...' RFC 2119 keyword, line 516: '...ed with IPsec Client, the stub MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 7, 2008) is 5679 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) == Missing Reference: 'CERTREQ' is mentioned on line 99, but not defined == Missing Reference: 'SYN' is mentioned on line 203, but not defined == Unused Reference: 'Sheffer07' is defined on line 551, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-vidya-ipsec-failover-ps-00 ** Downref: Normative reference to an Informational draft: draft-vidya-ipsec-failover-ps (ref. 'Narayanan06') ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Xu 3 Internet-Draft Tsinghua Univ. 4 Intended status: Standards Track P. Yang 5 Expires: April 10, 2009 Y. Ma 6 Hitachi (China) R&D Corporation 7 H. Deng 8 China Mobile 9 K. Xu 10 Tsinghua University 11 October 7, 2008 13 IKEv2 SA Synchronization for session resumption 14 draft-xu-ike-sa-sync-01 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 10, 2009. 41 Abstract 43 It will take a long time and mass computation to do session 44 resumption among IKE/IPsec gateways possibly maintaining huge numbers 45 of IKEv2/IPsec SAs, when the serving gateway fails or over-loaded. 46 The major reason is that the prcocedure of IKEv2 SA re-establishment 47 will incur a time-consuming computation especially in the Diffie- 48 Hellman exchange. In this draft, a new IKE security associations 49 synchronization solution is proposed to do fast IKE SA session 50 resumption by directly transferring the indexed IKE SA (named stub) 51 from old gateway to new gateway, wherein the most expensive Diffie- 52 Hellman calculation can be avoided. Without some time-consuming 53 IKEv2 exchanges, the huge amount of IKE/IPsec SA session resumption 54 procedures can be finished in a short time. 56 Table of Contents 58 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Application scenarios of IKEv2 Session Resumption . . . . . . 4 60 2.1. Scenario of IKEv2 Gateway fail . . . . . . . . . . . . . . 4 61 2.2. Scenario of load-balance . . . . . . . . . . . . . . . . . 5 62 3. Details on Proposed solution . . . . . . . . . . . . . . . . . 6 63 3.1. Overview of the Proposed solution . . . . . . . . . . . . 6 64 3.2. data structure of stub . . . . . . . . . . . . . . . . . . 7 65 3.3. Consideration on building IKE SA in session resumption . . 7 66 3.4. Consideration on Stub handling . . . . . . . . . . . . . . 7 67 3.5. Consideration on location of Stub . . . . . . . . . . . . 9 68 3.6. When should Gateways download/update Stub . . . . . . . . 10 69 3.7. Related new messages . . . . . . . . . . . . . . . . . . . 11 70 4. Modification on the base IKEv2 protocol . . . . . . . . . . . 12 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 7. Normative References . . . . . . . . . . . . . . . . . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 75 Intellectual Property and Copyright Statements . . . . . . . . . . 18 77 1. Background 79 IKEv2 protocol which has been defined by [RFC4306] provides us a 80 method to negotiate ipsec's key automatically between ipsec clients 81 and gateway. Before negotiating ipsec's key, they should negotiate 82 IKE's SA first. Usually, ipsec client sends IKE_INIT message to 83 gateway with SAi1, KEi, Ni, then gateway chooses some proposal of 84 SAi1 which come to the algorithm for encryption and decryption, also 85 proposal for Diffie-Hellman, and then calculates the Diffie-Hellman, 86 sends IKE_INIT respond message back to ipsec client. At this time, 87 the most important keyring can be generated. After other IKE_AUTH 88 exchange, The identity has verified. IKE SA has completely been 89 established. The timing overhead of IKEv2 protocol, including some 90 computation and signaling round-trips, is rather big especially when 91 the Extensible Authentication Protocol (EAP) is used for third-party 92 authentication. The picture below is the typical procedure for IKEv2 93 SA establishment. 95 Initiator Responder 96 ----------- ----------- 97 HDR, SAi1, KEi, Ni --> 99 < -- HDR, SAr1, KEr, Nr, [CERTREQ] 101 HDR, SK {IDi, [CERT,] 102 [CERTREQ,] [IDr,],AUTH, 103 SAi2, TSi, TSr} --> 104 < -- HDR, SK {IDr, [CERT,] AUTH, 105 SAr2, TSi, TSr} 107 Figure 1: IKE_INIT and IKE_AUTH exchanges 109 The establishment of an IKE SA in the first two exchanges of IKEv2 110 procedure in [RFC4306] (especially Diffie-Hellman computation), is 111 rather time-consuming. Normally, the IKEv2/IPsec gateway embodyment 112 (like IPsec VPN gateway, Mobile IPv6 Home Agent, etc) keeps a large 113 number of IKE/IPsec sessions. So in some scenarios (see Section 2), 114 it will take a very time to re-establish all the IKE SA for session 115 resumption of IKEv2/IPsec clients. 117 2. Application scenarios of IKEv2 Session Resumption 119 2.1. Scenario of IKEv2 Gateway fail 121 IPsec old new/old 122 client Gateway gateway 123 | | | 124 | IKE/IPsec SAs | | 125 |< ========================== >| | 126 | | | 127 | | | 128 | O Fail of old GW | 129 | | | 130 O detect the fail | | 131 | of old GW | | 132 | | | 133 | new IKE init procedure | 134 |< =================================================== >| 135 | | | 136 | set up other child IPsec SAs | 137 |< =================================================== >| 138 | | | 140 Figure 2: scenarios of IKEv2 Gateway fail 142 In this scenario, IPsec clients has established IKE/IPsec connections 143 with old gateway with tunnel mode or transporation mode. Because of 144 some reason, the old gateway may fail. In this case, IPsec client 145 can know old gateway has failed(how to know gateway fail is out of 146 our scope in this draft), and re-establish the IKEv2/IPsec sessions 147 with the old gateway or another new gateway. While a large number of 148 IPsec clients try to make the IKEv2/IPsec connections at the same 149 moment, it will take a rather long time due to the reason mentioned 150 in Section 1. And, the target gateway may have problem to response 151 some clients in this case as well. The problem statement and goals 152 for a failover solution are described in [Narayanan06]. 154 2.2. Scenario of load-balance 156 IPsec old new 157 client Gateway gateway 158 | | | 159 | IKE/IPsec SAs | | 160 |< ========================== >| | 161 | | | 162 | | | 163 | O overload of old GW | 164 | | | 165 O detect the overload | | 166 | of old GW | | 167 | | | 168 | new IKE init procedure | 169 |< =================================================== >| 170 | | | 171 | set up other child IPsec SAs | 172 |< =================================================== >| 173 | | | 175 Figure 3: load-balance scenarios 177 In this scenario, after establishing IKE connections between IPsec 178 clients and old gateway, the old gateway may be over-loading. then, 179 some of the IPsec clients should stop the connection with old gateway 180 and establish the connection with new gateway(how to know new gateway 181 is also out of our scope). Again, while many IKE/IPsec sessions are 182 transferred from old gateway to new gateway, it is a challenge to new 183 gateway to re-establish bunch of IKE SAs at the same time. 185 3. Details on Proposed solution 187 3.1. Overview of the Proposed solution 189 In this section, a new data structure is named as "stub", which has 190 the most important information of IKE SA. And gateway can use this 191 data structure to accelerate the rebuilding of IKE SA. IKE_INIT 192 message is extended with a new payload called IKE_SA_SYN. Since the 193 gateway's IP address and SPI can uniquely index the stub of IKE SA, 194 these two information are mandatory in the IKE_SA_SYN payload in 195 order to retrieve the stub of IKE SA by the target gateway. The 196 detailed data structure of Stub is introduced in Section 3.2. 198 The IKE SA session resumption procedure in this draft is depicted 199 below: 201 Initiator Responder 202 ----------- -------------- 203 HDRGBP[not]SAr1, KEi, Ni, [SYN] ---> 204 < -- HDR, Nr 206 Figure 4: IKE SA synchronization exchange 208 o While the IPsec client notices that it has to be transfer from old 209 gateway to target gateway and want to pursue the fast session 210 resumption, it sends IKE_INIT message with the SYN payload. The stub 211 indexing information like old gateway IP address and old gateway's 212 SPI shall be enclosed in the IKE SYN payload. 214 o Upon receiving the IKE_INIT message with the IKE_SA_SYN payload, 215 the target gateway uses the information inside to retrieve the the 216 stub of previous IKE SA in the stub bank. if the retrieved stub is 217 qualified for IKE SA re-building, the target gateway will choose the 218 new SPI, derive the new set of keyring and re-establish the IKE 219 session for the related client. Lastly, it sends IKE_INIT response 220 with new SPI in the IKEv2 header and Nr. The new IKE_SA has been re- 221 established successfully. 223 If the taget gateway does not support IKE_SA_SYN or not find the 224 proper stub, it can establish IKE SA by normal IKE_INIT and IKE_AUTH 225 exchanges as specified in [RFC4306], or just drop the packet based on 226 the local policy configured by network operator. 228 The stub can be stored in an independent stub bank, co-located with 229 target gateway or even co-located with the corresponding IPsec 230 client. This is discussed in Section 3.5. However, the case of stub 231 co-located with IPsec client is only optional in this draft. 233 3.2. data structure of stub 235 the stub data structure should conclude all these informations. 237 o IDi, IDr. 238 o SPIi, SPIr. 239 o SAr (the accepted proposal). 240 o SK_d_old. 241 o shared secret. 242 o old gateway's ip address. 243 o lifetime 245 In the data structure of stub, the old gateway's ip address and SPI 246 are used as the index for retrieval of stub. 248 SAr have the encrypt and decrypt algorithm, and shared secrect is the 249 DH exchange's result, we can calculate the IKE SA's keyring as rekey 250 process. It will be very quick. 252 3.3. Consideration on building IKE SA in session resumption 254 After the stub index has been presented by IKE client in the gateway, 255 it will retrieve the stub from the stub bank. The way to get the 256 stub from the stub bank can be found in Section 3.4. 258 As shown in Section 3.2, IDi, SA value can be obtained directly from 259 the retrieved stub. The target gateway shall choose the new SPIr 260 (called SPIr_new in this draft) for the key derivation of session 261 resumption. The nounce values, Ni and Nr, are from the current IKE 262 SYNC exchange. 264 So, the new value of SKEYSEED is calculated as below (SK_d_old value 265 is from the stub): 267 SKEYSEED = prf (SK_d_old, Ni | Nr) 269 And the keyring set are derived by the way of generic IKEv2 271 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+ 272 (SKEYSEED, Ni | Nr | SPIi | SPIr_new ) 274 The prf (pseudo-random function) of the cryptographic algorithms is 275 specified in the SA value of stub. 277 3.4. Consideration on Stub handling 279 1) generation 280 After IKE SA has been established(after first two exchanges), the 281 IKE/IPsec gateway extracts the stub from IKE SA. 283 2) propagation 285 After extracted from IKE SA, stubs should be updated to 286 infrastructure such as stub bank. The stub bank can be independent 287 entity in the network or co-located with the gateways (see 288 Section 3.5). 290 3) Retrieve 292 The gateway can use the the old gateway's ip address and spi can 293 index the unique stub. 295 4) Expire 297 The stub may be invalid when the lifetime expires. The value of 298 lifetime is recommended to be same as the one in the IKE SA. The 299 gateway may set different lifetime in stub. 301 5) Delete 303 When the IKEv2/IPsec session is deleted, the gateway shall delete the 304 related stubs in the stub bank. 306 The following signaling shall be supported by IKE/IPsec gateways to 307 communicate with Stub bank. 309 o Initiate Stub: 311 Gateway initiates the stub in the stub bank once new stub has been 312 established. The index shall at least include the gateway's IP 313 address and SPI. 315 o Update Stub: 317 Gateway updates its stub to infrastructure once the related IKE SA 318 has been changed 320 o GET Stub: 322 Gateway uses this message to receives stub by the information in 323 IKE_SA SYN payload from IKE client. 325 o Download Stub: 327 The stub bank can use this message to push the stubs to gateway. 329 o Delete Stub: 331 The Gateway can delete the stubs while the related IKE SAs are no 332 longer available. 334 3.5. Consideration on location of Stub 336 1. Centralized infrastructure 338 IPsec old Target stub 339 client GW GW bank 340 | | | | 341 | IKE/IPsec | | | 342 |< ================= >| | Update Stub | 343 | | ------------------------>| 344 | o Fail | | 345 | | | | 346 | HDR,SAr1,KEi,Ni,SYN | | 347 |----------------------------->| GET Stub | 348 | | |---------------->| 349 | | | Download Stub | 350 | | |< ---------------| 351 | HDR,Nr | | | 352 |< --------------------------- | | 353 | | | | 355 Figure 5: centralized structure 357 This proposal has a centralized Stub Bank server, gateway doesn't 358 need local stub database. 360 a) After IKE connection has been established, old gateway set up the 361 stub to stub bank. 363 b) Once the fast session resumption is started, IPsec client sends 364 IKE_INIT with SYN payload. 366 c) When the target gateway receives IKE_INIT with SYN payload, it 367 asks Stub Bank for stub via GET Stub signaling. 369 d) stub bank push proper stub to target gateway. 371 e) Target gateway gets the stub and rebuild IKE SA, then send HDR, Nr 372 to Notify IPsec client that the new IKE SA has been set up by IKE 373 SYNC session resumption. 375 2. Distributed infrastructure 376 IPsec Target Old GW 377 client gateway Stub 378 | | | 379 | HDR,SAr1,KEi,Ni,SYN| Update Stub | 380 | ------------------->| < ------------------| 381 | < ------------------| | 382 | HDR,Nr | | 384 Figure 6: distributed structure 386 This structure doesn't have centralized Stub Bank, and all gateway 387 must have local stub database. if there is stub in local database, it 388 will find the stub in local database, otherwise, it will GET the stub 389 from other gateways. 391 a) After IKE connection has been established, old gateway initiates 392 the stub to the potential target gateway. 394 b) Once session resumption is initiated, IPsec client send IKE_INIT 395 with SYN payload. 397 c) Target gateway finds the proper stub and rebuild IKE SA, then send 398 HDR, Nr to IPsec client. 400 Gateway has to store stubs in distributed structure, but it seems 401 more simple than centralized structure. Also, these two proposals 402 can mix together, other gateway also can be Stub Bank. 404 3. Full distributed in IKEv2/IPsec Client 406 There is also the possibility that the Gateway or Stub bank push the 407 stub to the corresponding client. During the session resumption 408 process, the target gateway can have another option to retrieve the 409 stub from the corresponding client by the way specified in 410 Section 3.4. But, this way of stub co-located with IPsec client is 411 ONLY OPTIONAL. if the operator wants to use this case, the stub MUST 412 be protected perfectly by strong encryption and integrity protection. 413 So, in this draft, it is only optional to co-locate the stub in the 414 client. 416 3.6. When should Gateways download/update Stub 418 Because of the stub is not sensitive with time, the gateways assemble 419 the stub messages to reduce the message number in initiate event. 421 The single gateway can get many stubs at a time in download event. 423 The gateway may also update the stubs in bundles whenever it was 424 thought to be necessary 426 3.7. Related new messages 428 1)IKE_SA_SYN Payload format 430 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Next Payload |C| RESERVED | Payload Length | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | GateWay's SPI | 436 | | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | GateWay's IP Address | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 C bit is the direction of this message. 443 2) Stub related signaling 445 Header Format 447 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Next Payload| type | Payload Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 type number 453 Init 0x01 454 update 0x02 455 get 0x03 456 download 0x04 457 delete 0x05 458 reserved 0x00 460 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Next Payload| RESERVED | Payload Length | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | | 466 | PAYLOAD CONTENT | 467 ~ ~ 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 4. Modification on the base IKEv2 protocol 472 As the core principle of this draft, the base IKEv2 protocol should 473 be changed as little as possible. In the proposal, three aspects 474 require slight modification on IKEv2 protocol in [RFC4306] 476 1) new IKE payload in the IKE_INIT message: IKE_SA_SYN 478 2) Modification on the state machine 480 IPsec client can send generic IKE_INIT message with SYN payload, if 481 it decides to use the session resumption. Upon receiving IKE_INIT 482 response only with the Nr and SPIr_new, it will calculate the new IKE 483 SA as IKE SA rekey. And set state to IKE SA has been established. if 484 the session resumption can not be accepted by the target gateway, the 485 client will receive the usual IKE_INIT response as in [RFC4306] and 486 continue the usual IKE_AUTH procedure afterwards 488 The target gateway, once receives IKE_SA_SYN payload, will firstly 489 find the proper stub. if the stub can be found successfully, it will 490 follow the session resumption proecedure as specified in this draft: 491 re-establish IKE SA, send IKE_INIT respond with Nr only to ipsec 492 client, and set state to IKE SA has been established. if the session 493 resumption can not be accepted by target gateway, it just follows the 494 usual IKEv2 initiation procedure as in [RFC4306] 496 3) The gateway should support the Stub related functions as specified 497 in Section 3.4 499 5. Security Considerations 501 the security framework of IKEv2 protocol will not be compromised in 502 this solution. 504 1) The stub index (Old gateway's IP address and SPI) in IKE_SA_SYN is 505 a light-weighted information, which can be transported without 506 encryption. And it relies on IKE_INIT message to handle the replay 507 protection and DoS attack. 509 2) The Gateway can use SAr1, KEi to verify the identity, such as ID 510 property. 512 3) Even if the index is right and IPsec client cannot rebuild IKE_SA 513 because of some reason, the newly re-built IKE SA in gateway will be 514 deleted after somewhile. 516 4) In the case of stub co-located with IPsec Client, the stub MUST be 517 perfected protected to prevent the malicious attackers from cracking 518 the stub, if they can obtain the stub on the network. Actually, even 519 if the stub is strongly encrypted, there still has the risk. With 520 the development of harware in accord with the Moore's Law, the 521 capability of computing equipment will be increased step by step. 522 Sometime, somehow, the brutal force decryption of the stub encryption 523 method may be possible. And, there is also posibility that the 524 currently safe encryption algorithm may be proved to be 525 mathematically solvable. So, all in all, it is only optional to 526 tranport the stub on the untrusted network, even if it can be 527 protected strongly. 529 6. Conclusion 531 In this draft, a new solution is proposed to do IKE SA 532 synchrinization for quick session resumption of IKE SA. With the 533 extension of IKE_SA_SYNC payload in IKE_INIT message, it can remove 534 the most time-consuming IKEv2 exchanges to re-build the IKE SA, which 535 makes it much faster to transfer millions of IKE sessions from old 536 gateway to target gateway. And the proposal in this draft will just 537 slightly modify the base IKEv2 protocol with a new logical IKE SA 538 Stub bank in the network. 540 7. Normative References 542 [Narayanan06] 543 Narayanan, V., "IPsec Gateway Failover and Redundancy 544 Problem Statement and Goals", 545 draft-vidya-ipsec-failover-ps-00.txt (work in progress), 546 December 2006. 548 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 549 RFC 4306, December 2005. 551 [Sheffer07] 552 Xie, Y., "Stateless Session Resumption for the IKE 553 Protocol", draft-sheffer-ike-session-resumption-00.txt 554 (work in progress), January 2007. 556 Authors' Addresses 558 Yan Xu 559 Tsinghua Univ. 560 Department of Computer Science 561 Tsinghua University 562 Haidian District 563 Beijing, 100088 564 P.R. China 566 Email: xydkl@163.com 568 Peng Yang 569 Hitachi (China) R&D Corporation 570 301, North Wing, Tower C Raycom Infotech Park 571 2 kexueyuan Nanlu 572 Haidian District 573 Beijing, 100080 574 P.R. China 576 Phone: +861082862918(ext.)328 577 Email: peng.yang.chn@gmail.com 579 Yuanchen Ma 580 Hitachi (China) R&D Corporation 581 301, North Wing, Tower C Raycom Infotech Park 582 2 kexueyuan Nanlu 583 Haidian District 584 Beijing, 100080 585 P.R. China 587 Phone: +861082862918(ext.)327 588 Email: ycma@hitachi.cn 590 Hui Deng 591 China Mobile 592 53A,Xibianmennei Ave., 593 Xuanwu District, 594 Beijing 100053 595 China 597 Email: denghui@chinamobile.com 598 Ke Xu 599 Tsinghua University 600 Department of Computer Science 601 Tsinghua University 602 Haidian District 603 Beijing, 100088 604 P.R. China 606 Email: xuke@mail.tsinghua.edu.cn 608 Full Copyright Statement 610 Copyright (C) The IETF Trust (2008). 612 This document is subject to the rights, licenses and restrictions 613 contained in BCP 78, and except as set forth therein, the authors 614 retain all their rights. 616 This document and the information contained herein are provided on an 617 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 618 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 619 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 620 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 621 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 622 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 624 Intellectual Property 626 The IETF takes no position regarding the validity or scope of any 627 Intellectual Property Rights or other rights that might be claimed to 628 pertain to the implementation or use of the technology described in 629 this document or the extent to which any license under such rights 630 might or might not be available; nor does it represent that it has 631 made any independent effort to identify any such rights. Information 632 on the procedures with respect to rights in RFC documents can be 633 found in BCP 78 and BCP 79. 635 Copies of IPR disclosures made to the IETF Secretariat and any 636 assurances of licenses to be made available, or the result of an 637 attempt made to obtain a general license or permission for the use of 638 such proprietary rights by implementers or users of this 639 specification can be obtained from the IETF on-line IPR repository at 640 http://www.ietf.org/ipr. 642 The IETF invites any interested party to bring to its attention any 643 copyrights, patents or patent applications, or other proprietary 644 rights that may cover technology that may be required to implement 645 this standard. Please address the information to the IETF at 646 ietf-ipr@ietf.org.