idnits 2.17.1 draft-dondeti-ipsec-failover-sol-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1049. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1060. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1067. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1073. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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 (February 25, 2007) is 6264 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) -- Looks like a reference, but probably isn't: 'CERTREQ' on line 433 -- Looks like a reference, but probably isn't: 'KEi' on line 607 -- Looks like a reference, but probably isn't: 'TSi' on line 610 -- Looks like a reference, but probably isn't: 'TSr' on line 610 -- Looks like a reference, but probably isn't: 'KEr' on line 610 == 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. '1') ** Obsolete normative reference: RFC 4306 (ref. '4') (Obsoleted by RFC 5996) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Dondeti 3 Internet-Draft V. Narayanan 4 Intended status: Standards Track QUALCOMM, Inc. 5 Expires: August 29, 2007 February 25, 2007 7 IPsec Gateway Failover and Redundancy Protocol 8 draft-dondeti-ipsec-failover-sol-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 29, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 IPsec gateways and servers maintaining SAs with large number of 42 clients can quickly recover from failover using the protocols and 43 procedures specified in this document. These techniques also 44 facilitate IPsec clients to move from one gateway to another and 45 resume operation without having to rerun IKEv2. The idea is to 46 maintain IKEv2 and IPsec SA state at either the client or one or more 47 backup servers to reduce the communication and computation overhead 48 associated with reestablishing the SAs from scratch. Client to 49 server SA state storage retrieval mechanisms and client-initiated or 50 server-initiated failover recovery protocols are specified. This 51 document, however, does not define an inter-gateway transport 52 mechanism to transfer the state across entities at the backend. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Recovering from a Remote Access Gateway Failover . . . . . 5 60 3.2. Recovering from an Application Server Failover . . . . . . 7 61 4. IKEv2 Session Resumption Protocol Details . . . . . . . . . . 8 62 4.1. Capability Negotiation and State Transfer . . . . . . . . 8 63 4.1.1. Extensions to the IKE_INIT_SA message . . . . . . . . 9 64 4.1.2. Extensions to the IKE_AUTH Exchange . . . . . . . . . 9 65 4.1.3. Capability Negotiation and State Transfer via an 66 Informational Exchange . . . . . . . . . . . . . . . . 11 67 4.1.4. IKEv2 Ticket . . . . . . . . . . . . . . . . . . . . . 12 68 4.2. IKEv2 Session Resumption . . . . . . . . . . . . . . . . . 13 69 4.2.1. IKE_SESSION_RESUME Exchange . . . . . . . . . . . . . 14 70 4.2.2. Replay Protection of Session Resumption Exchange . . . 15 71 4.2.3. Processing IKE_SESSION_RESUME messages . . . . . . . . 16 72 5. Message Types and Formats . . . . . . . . . . . . . . . . . . 18 73 5.1. IKEv2 Header with Gateway Switch Count . . . . . . . . . . 18 74 5.2. SESSION_RESUMPTION_SUPPORTED Notify Message Type . . . . . 19 75 5.3. Other Payload Specifications . . . . . . . . . . . . . . . 19 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 77 6.1. Properties of the Secure Domain . . . . . . . . . . . . . 20 78 6.2. Properties of Capability Negotiation . . . . . . . . . . . 20 79 6.3. Properties of SA Ticket Creation, Distribution and Use . . 21 80 6.4. Properties of the Session Resumption Protocol . . . . . . 22 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 83 9. Normative References . . . . . . . . . . . . . . . . . . . . . 23 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 85 Intellectual Property and Copyright Statements . . . . . . . . . . 25 87 1. Introduction 89 Recovering from failure of IPsec gateways or servers maintaining SAs 90 with large numbers of clients may take several minutes, if they need 91 to re-establish the IPsec SAs by re-running the key management 92 protocol, IKEv2. A similar problem arises in the event of a network 93 outage resulting in the failure of several gateways and servers. The 94 computational and communication latency in running IKEv2 or IKEv2 95 with EAP for client authentication is significant, leading to a need 96 for a faster and yet secure failover solution. The problem statement 97 and goals for a failover solution are described in [1]. 99 When an IPsec gateway fails or otherwise unreachable for a client, 100 the situation may be temporary or long lasting. The client should be 101 able to recover in either scenario. In other words, the client may 102 go back to the original gateway or alternatively, it may go to 103 another gateway to re-establish the session. The new gateway needs 104 access to the IKEv2 SA that the client and the old gateway 105 established with each other. The new gateway may acquire the SA from 106 the old gateway or another infrastructure entity where the old 107 gateway has stored the SA. The only other possibility for SA storage 108 and retrieval is for the old gateway to store the SA at the client 109 itself in the form of a "ticket." The client then presents the 110 ticket to the new or the old gateway. To facilitate such SA storage 111 and retrieval, the gateways must share security associations between 112 themselves or with an infrastructure entity. 114 For convenience we call gateways that share a security association 115 with each other either directly or through another entity, as 116 belonging to a secure domain. When the SA state is stored at the 117 client, the infrastructure is "stateless" until the client restores 118 the SA with one of the gateways within the secure domain; thus, we 119 refer to SA resumption with SA storage at the client as stateless 120 session resumption. When the infrastructure maintains SA state, we 121 refer to the process as stateful session resumption. 123 We identify three components to an efficient failover solution: 125 In the first part, the client and the gateway negotiate failover 126 support. More specifically, the client indicates supports for 127 failover and any related capabilities. The gateway verifies its 128 policy and may accept or reject support for failover for the 129 client; if it accepts the request, it indicates its own 130 capabilities in supporting the failover. The gateway may include 131 a list of backup gateways in its response; when the gateway does 132 not return a list of alternative gateways, the clients are 133 expected to discover the backup gateways or servers through a 134 mechanism external to IPsec key management. Capability 135 negotiation can be piggybacked on the IKE_AUTH exchange. The 136 client indicates whether it supports failover in the IKE_AUTH 137 request message via a notify payload; the gateway indicates 138 whether it supports failover for that client and may send a list 139 of other gateways in the secure domain, all via notify payloads in 140 the IKE_AUTH response message. 142 In the second part, the gateway creates a ticket and stores it in 143 the infrastructure or supplies it to the client, if the client had 144 indicated support for it and the gateway's policy allows storing 145 state in the client for that particular client. The gateway may 146 send the ticket via a notify payload included in the IKE_AUTH 147 response message. 149 The third part is session re-establishment itself: When a client 150 discovers that it cannot reach a gateway or application server 151 with which it has an IPsec SA, it attempts to reach another 152 gateway within the same secure domain as the initial gateway. In 153 other cases, the client may have gone dormant and could be 154 resuming the session with the original gateway. For session re- 155 establishment, we specify a new IKE exchange, IKE_SESSION_RESUME, 156 which is quite similar to CREATE_CHILD_SA in many ways, but with 157 some crucial differences also. In simple terms, processing 158 IKE_SESSION_RESUME request is a cross between processing 159 IKE_SA_INIT and CREATE_CHILD_SA. For the scope of this work, it 160 is assumed that the gateways in the secure domain do not share the 161 same IP address and may not share the same view of the network, 162 i.e., they may be connected to different DHCP servers. Thus, the 163 client may need to acquire a new IP address upon reestablishing an 164 IKE session with a new gateway. It is assumed that in this case, 165 the original IKEv2 exchange used the Configuration Payload to 166 acquire configuration information. 168 Note that it is plausible to run the capability negotiation and 169 ticket request/response via a information exchange after the SA has 170 been established. Another possibility is to piggyback the 171 negotiation and ticket request/response on a CREATE_CHILD_SA 172 exchange. 174 2. Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC 2119 [2]. 180 This document uses terminology defined in [3], [4], and [5]. In 181 addition, this document uses the following terms: 183 Secure domain: A secure domain comprises a set of gateways that are 184 able to resume an IKEv2 session that may have been established any 185 other gateway within the domain. All the gateways in the secure 186 domain are expected to share a security association -- either with 187 each other or through a trusted third party -- so they can verify 188 the validity of the ticket and can extract the IKEv2 policy and 189 session key material from the ticket. 191 IKEv2 ticket: An IKEv2 ticket is a data structure that contains all 192 the necessary information that allows any gateway within the same 193 secure domain as the gateway that created the ticket to verify the 194 validity of the ticket and extract IKEv2 policy and session keys 195 to re-establish an IKEv2 session. 197 Stateless failover: When the IKEv2 session state is stored at the 198 client, the infrastructure is "stateless" until the client 199 restores the SA with one of the gateways within the secure domain; 200 thus, we refer to SA resumption with SA storage at the client as 201 stateless session resumption. 203 Stateful failover: When the infrastructure maintains IKEv2 session 204 state, we refer to the process of IKEv2 SA re-establishment as 205 stateful session resumption. 207 3. Usage Scenarios 209 This specification envisions two usage scenarios for efficient IKEv2 210 and IPsec SA session re-establishment: The first is similar to the 211 use case specified in Section 1.1.3 of the IKEv2 specification [4], 212 where IPsec tunnel mode is to establish a secure channel between a 213 remote access client and a gateway; the traffic flow may be between 214 the client and entities beyond the gateway. The second use case is 215 somewhat different from any of the use cases defined in the IKEv2 216 specification: at the IP layer, two endpoints use transport (or 217 tunnel) mode to communicate between themselves. The two endpoints 218 have a client-server relationship with respect to a protocol that 219 runs using the protections afforded by the IPsec SA. 221 3.1. Recovering from a Remote Access Gateway Failover 222 (a) 224 +-+-+-+-+-+ +-+-+-+-+-+ 225 ! ! IKEv2/IKEv2-EAP ! ! Protected 226 ! Remote !<------------------------>! Remote ! Subnet 227 ! Access ! ! Access !<--- and/or 228 ! Client !<------------------------>! Gateway ! Internet 229 ! ! IPsec tunnel ! ! 230 +-+-+-+-+-+ +-+-+-+-+-+ 232 (b) 234 +-+-+-+-+-+ +-+-+-+-+-+ 235 ! ! IKE_SESSION_RESUME ! ! 236 ! Remote !<------------------------>! New/Old ! 237 ! Access ! ! Gateway ! 238 ! Client !<------------------------>! ! 239 ! ! IPsec tunnel ! ! 240 +-+-+-+-+-+ +-+-+-+-+-+ 242 Figure 1: Remote Access Gateway Failure 244 In this scenario, an endhost (an entity with a host implementation of 245 IPsec [3] ) establishes a tunnel mode IPsec SA with a gateway in a 246 remote network using IKEv2. The endhost in this scenario is 247 sometimes referred to as a remote access client. When the remote 248 gateway fails, all the clients associated with the gateway either 249 need to re-establish IKEv2 sessions with another gateway within the 250 same secure domain of the original gateway, or with the original 251 gateway if the server is back online soon. 253 The clients may choose to establish IPsec SAs using a full IKEv2 254 exchange or the IKE_SESSION_RESUME exchange (shown in Figure 1). 256 In this scenario, the client needs to get an IP address from the 257 remote network so that traffic can be encapsulated by the remote 258 access gateway before reaching the client. In the initial exchange, 259 the gateway may acquire IP addresses from the address pool of a local 260 DHCP server. The new gateway that a client gets associated may not 261 receive addresses from the same address pool. Thus, the session 262 resumption protocol needs to be able to support for new IP address 263 assignment. 265 3.2. Recovering from an Application Server Failover 267 (a) 269 +-+-+-+-+-+ +-+-+-+-+-+ 270 ! App. ! IKEv2/IKEv2-EAP ! App. ! 271 ! Client !<------------------------>! Server ! 272 ! & ! ! & ! 273 ! IPsec !<------------------------>! IPsec ! 274 ! host ! IPsec transport/ ! host ! 275 +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ 277 (b) 279 +-+-+-+-+-+ +-+-+-+-+-+ 280 ! App. ! IKE_SESSION_RESUME ! New ! 281 ! Client !<------------------------>! Server ! 282 ! & ! ! & ! 283 ! IPsec !<------------------------>! IPsec ! 284 ! host ! IPsec transport/ ! host ! 285 +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ 287 Figure 2: Application Server Failover 289 The second usage scenario is as follows: two entities with IPsec host 290 implementations establish an IPsec transport or tunnel mode SA 291 between themselves; this is similar to the model described in Section 292 1.1.2. of [4]. At the application level, one of the entities is 293 always the client and the other is a server. From that view point, 294 the IKEv2 exchange is always initiated by the client. This allows 295 the Initiator (the client) to authenticate itself using EAP, as long 296 as the Responder (or the application server) allows it. 298 If the application server fails, the client may find other servers 299 within the same secure domain for service continuity. It may use a 300 full IKEv2 exchange or the IKE_SESSION_RESUME exchange to re- 301 establish the IPsec SAs for secure communication required by the 302 application layer signaling. 304 The client-server relationship at the application layer ensures that 305 one of the entities in this usage scenario is unambiguously always 306 the Initiator and the other the Responder. This role determination 307 also allows the Initiator to request an address in the Responder's 308 network using the Configuration Payload mechanism of the IKEv2 309 protocol. If the client has thus received an address during the 310 initial IKEv2 exchange, when it associates with a new server upon 311 failure of the original server, it needs to request an address, 312 specifying its assigned address. The server may allow the client to 313 use the original address or if it is not permitted to use that 314 address, assigns a new address. 316 4. IKEv2 Session Resumption Protocol Details 318 The IKEv2 session resumption protocol specified in this document has 319 three components: capability negotiation, state transfer, and session 320 resumption. Capability negotiation and state transfer are extensions 321 to the IKEv2 base exchange. IKE_SESSION_RESUME exchange is new; it 322 is modelled after the CREATE_CHILD_SA, but looks slightly different 323 in transit and has different processing semantics. It does share a 324 majority of the structure, format and processing semantics of the 325 CREATE_CHILD_SA exchange, but also has some fundamental differences. 327 4.1. Capability Negotiation and State Transfer 329 IKEv2 session resumption capabilities -- whether the client and 330 server support session resumption, whether the client needs the 331 gateway list and whether the client can store state-- are negotiated 332 via notify payloads. The Initiator uses a notify payload to indicate 333 what it supports and what it needs: for session resumption, the 334 client MUST send a notify payload of type 335 SESSION_RESUMPTION_SUPPORTED. The notification data filed of this 336 type of notify payload defines two flags: the Initiator may indicate 337 support for client side state storage (in other words, request an 338 IKEv2 ticket) setting the flag CLIENT_SIDE_STORAGE_SUPPORTED and may 339 request the list of backup gateways from the Responder, by setting 340 the flag CLIENT_REQUEST_GW_LIST. 342 The Responder processes the notify payload and if it supports session 343 resumption for the client in question, then it returns a notify 344 payload of type SESSION_RESUMPTION_SUPPORTED. In addition, if the 345 Initiator request a list of gateways, the Responder SHOULD send a 346 notify payload of type ALT_GW_LIST, with a list of gateway addresses 347 belonging to the same secure domain. Finally, if the Responder 348 supports client side state storage, it sends a ticket via a notify 349 payload of type IKEv2_TICKET. 351 Capability negotiation can be piggybacked on the IKE_SA_INIT, the 352 IKE_AUTH or an Informational exchange after the base exchange is 353 complete. Session state transfer cannot occur until mutual 354 authentication and IKE SA establishment is complete. Thus, session 355 state transfer can be piggybacked on the IKE_AUTH exchange or an 356 Informational exchange after the base exchange is complete. 358 4.1.1. Extensions to the IKE_INIT_SA message 360 The initiator indicates support for session resumption by including 361 the Notify payload of type SESSION_RESUMPTION_SUPPORTED in the 362 IKE_INIT_SA request message. If the responder does not support such 363 a capability, it MUST ignore the session resumption notify payload. 364 A responder that supports failover and is willing to offer that 365 support to the client MUST return a notify payload of type 366 SESSION_RESUMPTION_SUPPORTED in the IKE_INIT_SA response message. If 367 the Initiator sets the flag CLIENT_REQUEST_GW_LIST, the responder 368 typically returns a list of gateways in a separate notify payload, of 369 type ALT_GW_LIST. 371 Implementations support session transfer MAY support extensions to 372 the IKE_INIT_SA messages. If the responder does not respond to 373 capability negotiation during the IKE_INIT_SA exchange, the initiator 374 may choose to try again during the IKE_AUTH exchange. 376 The capability negotiation is authenticated as part of the mutual 377 authentication processes during the IKE_AUTH exchange. 379 If the Initiator sets the flag CLIENT_SIDE_STORAGE_SUPPORTED, the 380 Responder may send the state via a notify payload of type 381 IKEv2_TICKET as part of the subsequent IKE_AUTH exchange. See 382 Section 4.1.2 for additional details. 384 Initiator Responder 385 ----------- ----------- 386 HDR, SAi1, KEi, Ni, 387 N(SESSION_RESUMPTION_SUPPORTED) --> 389 <-- HDR, SAr1, KEr, Nr, [CERTREQ], 390 N(SESSION_RESUMPTION_SUPPORTED) 392 Figure 3: Piggybacking over IKE_INIT_SA messages 394 4.1.2. Extensions to the IKE_AUTH Exchange 396 Capability negotiation and the state transfer can together be 397 piggybacked on the IKE_AUTH exchange, in the 4-message version or the 398 version where EAP is used for client authentication. The ticket can 399 in fact be sent in the clear -- more on that later -- but it is 400 simpler to include it within the SK payload of the IKE_AUTH message 401 and that allows us to make minimal modifications to the IKE_AUTH 402 message processing semantics. 404 If the Initiator supports ticket storage, it is RECOMMENDED that the 405 IKE_AUTH exchange be used for capability negotiation and state 406 transfer. 408 The capability negotiation and state transfer semantics are as 409 specified in Section Section 4.1.1. The exchange is protected by the 410 MAC in the IKE_AUTH exchange. Note that when the capability exchange 411 is piggybacked on the IKE_SA_INIT exchange the protection afforded to 412 the negotiation is the same as that afforded to the IKE SA parameter 413 negotiation and when it is piggybacked on the IKE_AUTH exchange, the 414 protections afforded are the same as that to the Child SA parameter 415 negotiation. 417 Initiator Responder 418 ----------- ----------- 419 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 420 AUTH, SAi2, TSi, TSr, 421 [N(SESSION_RESUMPTION_SUPPORTED)]} --> 423 <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi 424 TSr, [N(SESSION_RESUMPTION_SUPPORTED), 425 N(IKEv2_TICKET)]} 427 Figure 4: Piggybacking over the IKE_AUTH Exchange 429 Initiator Responder 430 ----------- ----------- 431 HDR, SAi1, KEi, Ni --> 433 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 435 HDR, SK {IDi, [CERTREQ,] [IDr,] 436 SAi2, TSi, TSr 437 [N(SESSION_RESUMPTION_SUPPORTED)]} --> 439 <-- HDR, SK {IDr, [CERT,] AUTH, 440 EAP } 442 HDR, SK {EAP} --> 444 <-- HDR, SK {EAP (success)} 446 HDR, SK {AUTH} --> 448 <-- HDR, SK {AUTH, SAr2, TSi, TSr 449 [N(SESSION_RESUMPTION_SUPPORTED), 450 N(IKEv2_TICKET)]} 452 Figure 5: Piggyback over IKE_AUTH with EAP for Client Authentication 454 If the Initiator sets the flag CLIENT_SIDE_STORAGE_SUPPORTED, the 455 Responder MAY send the state via a notify payload of type 456 IKEv2_TICKET in the IKE_AUTH response message. In case of IKEv2-EAP 457 exchange the request for session resumption support is indicated in 458 the first message of the IKE_AUTH sequence of messages from the 459 initiator and the response is included in the last message from the 460 responder. 462 The client is expected the store the ticket and present it to the 463 gateway with which it is resuming the session. The 464 IKE_SESSION_RESUME exchange is used for that purpose. 466 The Ticket is included as part of a Notify message and can be opaque 467 or conformant to the format specified in this document. 469 4.1.3. Capability Negotiation and State Transfer via an Informational 470 Exchange 472 An initiator may choose to wait until the IKEv2 and IPsec SA 473 establishment is complete before negotiating the IKEv2 session 474 transfer support. The initiator then uses an informational exchange 475 to indicate support for session resumption and the responder can 476 agree to support the capability and may send the ticket in response, 477 as applicable. The negotiation is protected as the Notify payloads 478 are within the SK payload of IKEv2. 480 Initiator Responder 481 ----------- ----------- 482 HDR, SK { 483 N(SESSION_RESUMPTION_SUPPORTED), 484 [N(SPI)]} --> 485 <-- HDR, SK {N(SESSION_RESUMPTION_SUPPORTED), 486 [N(IKEv2_TICKET)]} 488 Figure 6: Informational Exchange for Session Resumption Negotiation 490 4.1.4. IKEv2 Ticket 492 To enable clients to present the IKEv2 ticket received from one 493 gateway to another, the contents of the ticket need to specified. 494 The ticket structure may be used by a gateway to send state to the 495 client or to another gateway or SA store. In the event of backend 496 storage of state, the SA store may be present in a highly available 497 centralized entity or distributed across the backup gateways. This 498 document does not provide a protocol to upload or download state to/ 499 from the SA store. However, such an exchange MUST be encrypted, 500 authenticated and replay protected. 502 In the simplest IKEv2 session, there is an IKE SA and a single IPsec 503 SA. The IKEv2 ticket may have been sent by the gateway during the 504 base exchange or via an Informational exchange. If either the IPsec 505 SA or the IKE SA is rekeyed, the gateway sends the new ticket to the 506 client. The ticket is then associated with the IPsec SA in that when 507 an SA is deleted, the corresponding ticket is also expected to be 508 deleted, even if the ticket has not expired. 510 The ticket contains all the necessary information for a gateway to 511 restore the IKE SA; more specifically, it contains the negotiated IKE 512 SA parameters and the corresponding attributes where applicable. 513 There is also a lifetime to the ticket, which takes the form of a 514 timestamp after which the ticket is no longer valid. The ticket 515 itself is protected -- encrypted and integrity protected -- with a 516 security association created specifically for generating and 517 validating tickets within a given secure domain. The ticket 518 generation SA (TGS) is identified with the TGS-SPI and that is 519 included in the clear with the ticket. The TGS-SPI allows the new 520 gateway to identify the SA to use in validating the ticket. The TGS- 521 SPI is a blob that only the entities within a secure domain need to 522 understand; for instance, if the gateways within a secure domain form 523 a multicast group and use a group IPsec SA, the SPI may contain the 524 destination address (group's multicast address) and a 32-bit random 525 value. The ticket may also contain the identity of the gateway/ 526 domain issuing it. 528 When multiple IPsec SAs are created, the gateway MAY send a new 529 ticket in each CREATE_CHILD_SA response message. It is not clear 530 whether the fields within the ticket, other than the lifetime of the 531 ticket will be different. 533 The ticket may contain IPsec specific information such as the tunnel 534 inner address (TIA) assigned by the gateway. In that case, each 535 ticket is different. Whether there is a need to include the TIA in 536 the ticket is for discussion. 538 4.2. IKEv2 Session Resumption 540 When a client discovers that the gateway it is associated with is 541 unreachable, according to the IKEv2 specification the client needs to 542 verify the liveness of the gateway through IKEv2. If the client 543 determines that the gateway is unreachable, it is to delete the IKE 544 SA and all associated CHILD SAs. This specification modifies that 545 behavior. 547 If session resumption capability has been negotiated for the IKE SA, 548 the client MAY reestablish the session with a backup gateway instead 549 of deleting it. The client needs to first find an alternative 550 gateway: we refer to this step as gateway discovery. There are a few 551 possible ways of gateway discovery: 553 Preconfiguration: The client may have been pre-configured with a 554 list of backup gateways. In other words, the client learns of the 555 backup gateways just as it does the address of the original 556 gateway. 558 Discovery through IKEv2: First, the client may have requested and 559 received a list of gateways during the capability negotiation 560 phase. In this case, the list of gateways is provided by the 561 original gateway and the discovery has the protection of an IKEv2 562 exchange. 564 Discovery through application: The client may discover that a 565 gateway has failed and a new gateway must be used for connectivity 566 through application layer messages. An example of this is the 567 Mobile IPv6 Home Agent (HA) discovery, where the client may 568 discover the HA via MIP6 bootstrapping mechanisms. The IKEv2 569 specification has details on expected behavior on receiving 570 unauthenticated information about gateway unreachability. Those 571 rules still apply in this case, in that the client should verify 572 the non-reachability before initiating a switch to the new 573 gateway. 575 4.2.1. IKE_SESSION_RESUME Exchange 577 Subsequent to discovering gateway failure and alternative gateways to 578 contact, a client may choose to run a full IKEv2 exchange to 579 establish a new IKEv2 session or to resume the use of the previously 580 established SA at the new gateway. There are two cases to consider: 581 in the first, the client has received an IKEv2_ticket from the 582 original gateway and presents that to the new gateway. In the second 583 case, the client has no ticket to present and therefore simply 584 attempts to reestablish the session with the new gateway. 586 Note that it is impractical for all the gateways to be in synchrony 587 with each other on all the replay protection state at each entity. 588 Thus we need a special IKE SA created for session reestablishment and 589 use that in the IKEv2 ticket or we need to tweak the IKEv2 replay 590 protection mechanism as the client moves between gateways. Next, the 591 new gateway may not be able to support the same tunnel inner address 592 as the original gateway. Finally, for stateless failover, the new 593 gateway will need to supply the next IKEv2_ticket to the client. 594 Thus, the session resumption exchange comprises an IPsec SA 595 establishment, optional IKEv2 SA rekeying, optional IP address 596 assignment, and optional ticket delivery from the gateway to the 597 client. For the purposes of this specification, we assume that the 598 client always initiates SA reestablishment. We consider the case of 599 gateway initiating SA recovery out of scope of the specification. 601 We specify a new IKEv2 exchange type called IKE_SESSION_RESUME of 602 type IANA-TBA. 604 Initiator Responder 605 ----------- ----------- 606 HDR, [N(IKEv2_Ticket)], [N,] SK { SA, Ni, 607 [KEi], [TSi, TSr], [CP(CFG_Request)], 608 [N(UPDATE_SA_ADDRESSES)]} --> 610 <-- HDR, SK {SA, Nr, [KEr], [TSi, TSr], 611 [CP(CFG_REPLY)], [N(IKEv2_Ticket)]} 613 Figure 7: IKE_SESSION_RESUME Exchange 615 The HDR contains the Initiator's SPI as a random number of 8 octets 616 chosen by the Initiator. The Responder's SPI is set to zero. The 617 new gateway will pick the SPI and include it in the return message. 618 The exchange type is set to 'IKE_SESSION_RESUME'. We use a message 619 ID of structure Gateway_Switch_Count (GSC) || message_ID, where 620 Gateway_Switch_Count indicates the number of gateways the client has 621 switched with the given IKE SA and message_ID is zero (or a suitable 622 default value). 624 In case of stateless failover, the client MUST include the 625 IKEv2_Ticket payload. For stateful failover, the client MUST include 626 a Notify payload with the original IKEv2 SPI pair so that the new 627 gateway can look up the SA and verify the validity of the 628 IKE_SESSION_RESUME message. Only one of these payloads MUST be 629 present. Note that the IKEv2_Ticket payload and the Notify payload 630 containing the SPI values are included after the header, but, outside 631 the encrypted data. This allows for integrity protection of these 632 payloads and not encryption. The Responder must be able to read 633 these payloads before it can decrypt the SK payload in the 634 IKE_SESSION_RESUME message. 636 If the client is contacting the same gateway to resume the IKE 637 session, it may not require a new IP address or any configuration 638 parameters. For the purpose of this document, gateways that have the 639 same view of the backend and are capable of supporting the same IP 640 address for the clients are viewed as being a single gateway. If the 641 client does not know whether the new gateway can assign the same 642 tunnel inner IP address and then it MUST include the CFG_Request 643 Configuration Payload, indicating the need for an IP address. It MAY 644 include the original tunnel inner address in the request. For tunnel 645 mode IPsec, this is the tunnel inner address of the client. If the 646 local address of the client (tunnel outer address in tunnel mode) has 647 also changed in the meantime, the client MUST include the 648 UPDATE_SA_ADDRESSES notify payload defined in [5] in the session 649 reestablishment Request message. 651 4.2.2. Replay Protection of Session Resumption Exchange 653 IKEv2, as defined in [4] provides replay protection between the 654 initiator and the responder using sequence numbers. Each entity 655 maintains its own sequence number space and the sequence number is 656 incremented after transmission of a request message. When one of the 657 entities involved in the IKEv2 exchange may change within the same 658 IKE session, replay protection will require per packet update of 659 state to continue to use the same model of sequence numbers specified 660 in [4]. Per packet state updates are impractical and also do not 661 always work. It is plausible for the SA endpoints to fall out of 662 sync or fail before an update is done, effectively opening up the 663 possibility of replays. 665 In order to provide replay protection even when one of the entities 666 is changing mid-session, this document proposes a structure to the 667 message ID field of the IKEv2 header. The message ID field is 668 composed as GSC||s_message_ID, where the GSC is a 4-bit value and the 669 s_message_ID is a 28-bit value; the s_message_ID has the same 670 semantics as the IKEv2 message ID except for the smaller size. The 671 s_message_ID starts at zero (or a suitable constant) every time the 672 client switches to a new gateway. 674 The initiator and the responder initialize the GSC to zero at the 675 time of establishment of the IKE SA. In case of stateless failover, 676 the responder includes the GSC in the IKEv2_Ticket. The initiator 677 increments the GSC and uses GSC||s_message_ID as the IKEv2 message_ID 678 in theIKE_SESSION_RESUME exchange. The responder uses the same 679 message ID in the response. When a failover or switch to another 680 gateway occurs, this count is incremented. Note that the GSC is 681 incremented even if the client has visited the "new" gateway in the 682 past under the protection of the same IKE SA. Continuing with the 683 case of stateless failover, the responder includes the new GSC in the 684 new ticket and includes the new ticket along with the 685 IKE_SESSION_RESUME response message. If the initiator never receives 686 the response, it may use the same GSC in a future IKE_SESSION_RESUME 687 exchange with the same or a different gateway. 689 In case of stateful failover, the responder maintains the GSC value 690 independent of the initiator and thus the initiator must increment 691 the GSC for use with every fresh IKE_SESSION_RESUME request message. 692 Note that the responder increments its local value of the GSC as soon 693 as it responds with an IKE_SESSION_RESUME response message and 694 updates the SA state of the client with the new GSC value. A new 695 gateway MUST only accept an IKE_SESSION_RESUME request message, if 696 the GSC value in the message ID is greater than the GSC value present 697 as part of the state. 699 The presence of the GSC provides replay protection across gateways 700 without per packet state updates. The IKE_SA MUST be re-keyed before 701 the GSC overflows. The IKE_SA MUST also be re-keyed before the 28- 702 bit sequence number overflows, as required by [4]. This re-keying, 703 however, may be done off the critical path, instead of at the time of 704 failover. 706 4.2.3. Processing IKE_SESSION_RESUME messages 708 IKE_SESSION_RESUME messages are treated much like IKE_SA_INIT 709 messages in that the first step in processing them is not looking up 710 the SA. In case of IKE_SA_INIT, the responder processes the entire 711 message and sends a response either by challenging the initiator to 712 prove liveness or by sending the IKE_SA_INIT response message. In 713 case of IKE_SESSION_RESUME message case, the first step is to process 714 the message partially, provisionally revive the old SA to verify the 715 session resumption request and process the rest of the message; the 716 result of the processing, assuming everything is in order, is to 717 install an IKE SA and one or more IPsec SAs at both ends. 719 The responder follows the steps below in processing an 720 IKE_SESSION_RESUME request message: 722 o When an IKEv2 entity receives a message of exchange type 723 'IKE_SESSION_RESUME' it first verifies the consistency of the 724 message. The Initiator's SPI must be non-NULL; the Responder's 725 SPI can be ignored. The GSC must be greater than 1. The message 726 must have either an N payload or the IKEv2_Ticket payload followed 727 by an SK payload. 729 o The next step is to recover the SA to be reestablished. If the 730 received message contains an IKEv2_Ticket payload, the receiver 731 validates the ticket. It uses the TGS-SPI of the ticket to lookup 732 the SA that protects the ticket. It then verifies the integrity 733 of the ticket. It then verifies that the ticket is fresh and not 734 invalidated by policy. The next step is to verify whether the 735 received session resumption request itself is fresh: the received 736 GSC must be greater than the GSC within the ticket. 738 o If the received message contains a Notify payload, the SPIs within 739 the payload are used to lookup the SA that protects the received 740 session resumption request message. The responder retrieves the 741 SA from the SA store. It then verifies that the received GSC is 742 greater than the local GSC. 744 o After replay verification, the next step is to verify the 745 integrity of the session resumption request message itself. If 746 the integrity checksum is valid, the purported sender of the 747 message in fact has access to the IKE SA corresponding to the SPI 748 in the N payload or the IKE SA contained in the IKEv2_Ticket. 750 o The responder then proceeds to process the rest of the 751 IKE_SESSION_RESUME just as it would process a CREATE_CHILD_SA 752 request message. It first decrypts the SK payload. The first 753 encrypted payload is not an N payload (if it is, the responder 754 returns an error message to the initiator) and so the message is 755 treated as a request to create a new IPsec SA. 757 o 759 In response to a session resumption request message, the responder 760 sends a message that is quite similar to a CREATE_CHILD_SA response 761 message. There are some subtle differences between the 762 CREATE_CHILD_SA response and an IKE_SESSION_RESUME response message. 764 The IKE_SESSION_RESUME response message is composed as follows: the 765 responder picks an SPI and includes it in the Responder's SPI field 766 of the IKEv2 header. The message ID is the same as the message ID in 767 the request message. In case of stateless failover the responder 768 creates a new IKEv2_ticket and includes the current GSC in the 769 ticket. The new ticket is included within the SK as one of the 770 encrypted payloads. Encryption of the new ticket prevents an 771 attacker from attempting to present the ticket to another gateway 772 before the client has had a chance to use it. 774 5. Message Types and Formats 776 5.1. IKEv2 Header with Gateway Switch Count 778 1 2 3 779 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 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 ! IKE_SA Initiator's SPI ! 782 ! ! 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 ! IKE_SA Responder's SPI ! 785 ! ! 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 !GSC| S-Message ID (28 bits) ! 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 ! Length ! 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 Figure 8: IKEv2 Header with GSC 796 GSC - This 4-bit field indicates the Gateway Switch Count. It is 797 initialized to zero when the IKE_SA is created and incremented by one 798 every time a CREATE_CHILD_SA failover request message is sent by an 799 IKE peer. 801 S-Message ID - This is a 28-bit field that has the same semantics as 802 the message ID field of the IKEv2 header. 804 5.2. SESSION_RESUMPTION_SUPPORTED Notify Message Type 806 The SESSION_RESUMPTION_SUPPORTED Notify message type may be present 807 in a Notify payload and indicates the support for failover at an IKE 808 peer. The Notify Message Type value is IANA-TBD. The Notification 809 Data contains an 8 bit flags field, the format of which is defined 810 below. 812 0 1 2 3 4 5 6 7 813 +-+-+-+-+-+-+-+-+ 814 |S|L| Reserved | 815 +-+-+-+-+-+-+-+-+ 817 Figure 9: SESSION_RESUMPTION_SUPPORTED Notification Data 819 The S (CLIENT_SIDE_STORAGE_SUPPORTED) flag is set by the IKE peer to 820 indicate support for stateless failover operation. The gateway MUST 821 NOT set this flag if it does not also include a STATE_TICKET Notify 822 payload in the response message. [***NOTE: Are we allowing not 823 supporting the GSC? If so, we need to include the GW ID in the 824 exchange and also defined how it is used in the IDr payload] 826 The L(CLIENT_REQUEST_GW_LIST) flag is set by the IKE peer to indicate 827 a message that requests or contains the list of gateways. 829 5.3. Other Payload Specifications 831 TBD. 833 6. Security Considerations 835 IKEv2 establishes an IKE SA and an IPsec SA in a 4 (or 6 message) 836 base exchange. The number of messages can be larger than that if EAP 837 is used for client authentication. The goal of this document is to 838 specify a fast session resumption protocol. The session resumption 839 protocol enables an IPsec client to quickly resume the use of the IKE 840 SA and establish a new IPsec SA with the original gateway (after it 841 fails and recovers) or another gateway within a secure domain. 843 If the new gateway is in perfect synchrony with the old gateway, the 844 only thing that changes is the IP address of one of the parties to 845 the IKE exchange. A protocol similar to MOBIKE may be used to signal 846 the change in the IP address of one of the end points of the session. 847 Perfect synchronization is impractical and thus there is a need to 848 design an IKEv2 session resumption protocol. 850 It is plausible that the new gateway obtains the SA state from within 851 the secure domain, either from the old gateway or from another entity 852 to which the old gateway has sent the SA state. It is also plausible 853 for the old gateway to send the state to the client itself so it can 854 present the state to the new gateway. 856 There are several components to the solution: we need to define a 857 secure domain, identify the security properties required for session 858 resumption capability negotiation, identify the security properties 859 required for SA storage or ticket creation, distribution and use, and 860 finally identify the requirements of a session resumption protocol. 861 Replay protection for the IKE SA as it is used across gateways is a 862 crucial component of the ticket use and session resumption protocol. 864 6.1. Properties of the Secure Domain 866 A secure domain consists of a pool of gateways that are able to 867 resume SAs created by any gateway belonging to the same domain. It 868 is not necessary for any two gateways to share the same IP address or 869 have the same view of the network. 871 All the gateways in the secure domain must share a security 872 association for state storage and retrieval purposes. Such a 873 security association must provide confidentiality, integrity and 874 replay protection for the state stored or retrieved. The gateways 875 may share a group SA or each gateway in the secure domain may share 876 an individual SA with a central entity. In the case of stateful 877 session resumption, the central entity may act as the SA store. In 878 the case of stateless session resumption, such a central SA manager 879 will imply that the tickets are protected with an SA known only to 880 the central entity and each gateway needs to contact the central 881 entity to encrypt or decrypt the contents of the tickets. 883 6.2. Properties of Capability Negotiation 885 The failover solution described here relies on a capability exchange 886 occurring as part of the initial IKEv2 exchange. The capability for 887 failover support may be indicated by the initiator as part of the 888 IKE_INIT or IKE_AUTH exchange and the failover support and any 889 corresponding information (such as list of gateways or state) is 890 included by the gateway as part of the IKE_AUTH exchange. The 891 capability negotiation is authenticated as part of the mutual 892 authentication processes during the IKE_AUTH exchange or is integrity 893 protected by the MAC in the SK payload. 895 Further, if the responder includes a ticket containing the session 896 state, that ticket is encrypted and integrity protected in a self- 897 contained manner. This is so that upon session resumption, the 898 gateway can verify the validity of the ticket. The SA used to 899 encrypt and integrity protect the ticket depends on the type of SAs 900 used in the secure domain, as described in Section 6.1. 902 6.3. Properties of SA Ticket Creation, Distribution and Use 904 For the purpose of stateless session resumption, the gateway may 905 distribute a ticket containing the SA state to the client. Any 906 gateway in the secure domain may then allow the client to resume the 907 IKE session upon successful processing of the ticket and installation 908 of the SA. There are some security properties to consider in such 909 ticket creation and distribution. 911 The ticket must contain information that will allow the gateway 912 resuming the session to determine the validity of the ticket based on 913 the lifetime policies of the secure domain. The ticket itself may 914 also contain information necessary to determine its lifetime that is 915 allowed by the issuing gateway. This will prevent a ticket from 916 being indefinitely used. 918 All the contents of the ticket, except the SPI that indicates the SA 919 to be used, must be encrypted and a MAC must be generated on the 920 encrypted data. This prevents an eavesdropper from obtaining the 921 contents of the ticket. 923 In addition to the confidentiality of the ticket contents itself, 924 ticket revocation is an issue that cannot be easily addressed without 925 some gateway side state. If a ticket needs to be revoked and the 926 client needs to be denied access, the gateways in the secure domain 927 must contain some state or must be able to obtain the necessary 928 information from a trusted source elsewhere. This will allow the 929 infrastructure to reject resumption of a session after a client has 930 been revoked access. 932 Every time the SA state is updated or the client attaches to a new 933 gateway, it receives a new ticket which is supposed to be used for 934 subsequent session resumption. However, there is no way the gateways 935 in the secure domain can ensure that the client always presents the 936 latest ticket, unless some state on the ticket itself is maintained 937 in the secure domain. While such state will be significantly less 938 than storing the entire SA, that still somewhat negates the goal of 939 remaining stateless. 941 Hence, if the infrastructure is completely stateless on the tickets, 942 it is feasible for the client to re-use old tickets. For the client 943 itself, there is typically no incentive in using an older ticket, as 944 opposed to a newer one and hence, it is less of a problem. However, 945 the possibility of ticket re-use leads to possible message replays. 946 An attacker would be able to capture an IKE_SESSION_RESUME request 947 message and replay it at a later time. Since the ticket contains an 948 older value of the Gateway Switch Count (GSC), the message will be 949 accepted by the gateway, as long as the lifetime of the ticket is 950 still valid. While this would result in the IKE SA being installed 951 on the gateway, it will result in a new IPsec SA being created, which 952 will not be available to the attacker. Hence, replay of IPsec 953 packets is not feasible in this case. Hence, the worst impact of 954 message replays with old tickets is the installation of the IKE_SA at 955 the gateway and creation of a new IPsec SA. It should be noted that 956 if that gateway happens to be still serving the client to which the 957 ticket actually belongs, it will most likely lead to re-installation 958 of the same IKE SA or rejection of the replayed IKE_SESSION_RESUME 959 since a different IKE SA for the same client is already present. 960 Hence, ticket re-use is not a serious problem, although it could 961 result in consumption of unnecessary resources at the gateway. 963 If an attacker replayed a message with a ticket and successfully 964 created state at the gateway and the client attempted to re-connect 965 to that gateway, its request may be rejected by the gateway. Hence, 966 depending on the timing of the replay, it is feasible to cause a DoS 967 attack on the legitimate client. 969 6.4. Properties of the Session Resumption Protocol 971 This document defines an IKE_SESSION_RESUME exchange to allow 972 resumption of an already established IKE SA. The security properties 973 of this exchange are largely similar to that of the 974 IKE_CREATE_CHILD_SA exchange. The only difference is that before the 975 creation of the IPsec SA, the recipient processing session resume 976 request message first needs to provisionally install the IKE SA 977 corresponding to the request. This IKE SA may be retrieved from the 978 SA store or from the ticket presented by the client. The gateway 979 must first install this SA and verify the validity of the 980 IKE_SESSION_RESUME Request message. If the session resume request 981 message is valid, the installed SA is kept; otherwise it is deleted 982 and any related state updates are rolled back. When the validity 983 check succeeds, the processing of the rest of the message and 984 creation of the IPsec SA is analogous to processing an 985 IKE_CREATE_CHILD_SA message. 987 7. IANA Considerations 989 This document specifies a new IKEv2 exchange type and several notify 990 payload types. Detailed instructions to IANA will be provided when 991 the protocol specification becomes more stable. 993 8. Acknowledgments 995 Thanks to Paul Hoffman for his valuable input to discussions on the 996 design of this protocol. 998 9. Normative References 1000 [1] Narayanan, V., "IPsec Gateway Failover and Redundancy - Problem 1001 Statement and Goals", draft-vidya-ipsec-failover-ps-00 (work in 1002 progress), December 2006. 1004 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1005 Levels", BCP 14, RFC 2119, March 1997. 1007 [3] Kent, S. and K. Seo, "Security Architecture for the Internet 1008 Protocol", RFC 4301, December 2005. 1010 [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 1011 December 2005. 1013 [5] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", 1014 RFC 4555, June 2006. 1016 Authors' Addresses 1018 Lakshminath Dondeti 1019 QUALCOMM, Inc. 1020 5775 Morehouse Dr 1021 San Diego, CA 1022 USA 1024 Phone: +1 858-845-1267 1025 Email: ldondeti@qualcomm.com 1026 Vidya Narayanan 1027 QUALCOMM, Inc. 1028 5775 Morehouse Dr 1029 San Diego, CA 1030 USA 1032 Phone: +1 858-845-2483 1033 Email: vidyan@qualcomm.com 1035 Full Copyright Statement 1037 Copyright (C) The IETF Trust (2007). 1039 This document is subject to the rights, licenses and restrictions 1040 contained in BCP 78, and except as set forth therein, the authors 1041 retain all their rights. 1043 This document and the information contained herein are provided on an 1044 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1045 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1046 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1047 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1048 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1049 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1051 Intellectual Property 1053 The IETF takes no position regarding the validity or scope of any 1054 Intellectual Property Rights or other rights that might be claimed to 1055 pertain to the implementation or use of the technology described in 1056 this document or the extent to which any license under such rights 1057 might or might not be available; nor does it represent that it has 1058 made any independent effort to identify any such rights. Information 1059 on the procedures with respect to rights in RFC documents can be 1060 found in BCP 78 and BCP 79. 1062 Copies of IPR disclosures made to the IETF Secretariat and any 1063 assurances of licenses to be made available, or the result of an 1064 attempt made to obtain a general license or permission for the use of 1065 such proprietary rights by implementers or users of this 1066 specification can be obtained from the IETF on-line IPR repository at 1067 http://www.ietf.org/ipr. 1069 The IETF invites any interested party to bring to its attention any 1070 copyrights, patents or patent applications, or other proprietary 1071 rights that may cover technology that may be required to implement 1072 this standard. Please address the information to the IETF at 1073 ietf-ipr@ietf.org. 1075 Acknowledgment 1077 Funding for the RFC Editor function is provided by the IETF 1078 Administrative Support Activity (IASA).