idnits 2.17.1 draft-ietf-mip6-ikev2-ipsec-08.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1119. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1130. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1137. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1143. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 draft header indicates that this document updates RFC3776, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC3776, updated by this document, for RFC5378 checks: 2002-09-20) -- 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 (December 16, 2006) is 6303 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 901 -- Looks like a reference, but probably isn't: 'N' on line 841 -- Looks like a reference, but probably isn't: 'KEi' on line 841 -- Looks like a reference, but probably isn't: 'KEr' on line 844 ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (ref. '4') (Obsoleted by RFC 5996) == Outdated reference: A later version (-12) exists of draft-ietf-pki4ipsec-ikecert-profile-11 -- Obsolete informational reference (is this intentional?): RFC 822 (ref. '9') (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '11') (Obsoleted by RFC 4301) == Outdated reference: A later version (-04) exists of draft-sugimoto-mip6-pfkey-migrate-03 == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-03 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group V. Devarapalli 3 Internet-Draft Azaire Networks 4 Updates: 3776 (if approved) F. Dupont 5 Intended status: Standards Track CELAR 6 Expires: June 19, 2007 December 16, 2006 8 Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture 9 draft-ietf-mip6-ikev2-ipsec-08.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 19, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes Mobile IPv6 operation with the revised IPsec 43 architecture and IKEv2. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 3 50 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 4 52 4.2. Policy Requirements . . . . . . . . . . . . . . . . . . . 5 53 4.3. IPsec Protocol Processing Requirements . . . . . . . . . . 7 54 4.4. Dynamic Keying Requirements . . . . . . . . . . . . . . . 9 55 5. Selector Granularity Considerations . . . . . . . . . . . . . 9 56 6. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 11 57 6.1. Binding Updates and Acknowledgements . . . . . . . . . . . 11 58 6.2. Return Routabililty Messages . . . . . . . . . . . . . . . 12 59 6.3. Mobile Prefix Discovery Messages . . . . . . . . . . . . . 13 60 6.4. Payload Packets . . . . . . . . . . . . . . . . . . . . . 14 61 7. Dynamic Configuration . . . . . . . . . . . . . . . . . . . . 14 62 7.1. Peer Authorization Database Entries . . . . . . . . . . . 15 63 7.2. Security Policy Database Entries . . . . . . . . . . . . . 15 64 7.2.1. Binding Updates and Acknowledgements . . . . . . . . . 15 65 7.2.2. Return Routability Messages . . . . . . . . . . . . . 16 66 7.2.3. Mobile Prefix Discovery Messages . . . . . . . . . . . 17 67 7.2.4. Payload Packets . . . . . . . . . . . . . . . . . . . 18 68 7.3. Security Association negotiation using IKEv2 . . . . . . . 18 69 7.4. Movements and Dynamic Keying . . . . . . . . . . . . . . . 20 70 8. The use of EAP authentication . . . . . . . . . . . . . . . . 21 71 9. Dynamic Home Address Configuration . . . . . . . . . . . . . . 22 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 74 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 76 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 77 13.2. Informative References . . . . . . . . . . . . . . . . . . 24 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 79 Intellectual Property and Copyright Statements . . . . . . . . . . 26 81 1. Introduction 83 RFC 3776 describes how IPsec, as described in RFC 2401 [11], is used 84 with Mobile IPv6 [2] to protect the signaling messages. It also 85 illustrates examples of Security Policy Database and Security 86 Association Database entries that can be used to protect Mobile IPv6 87 signaling messages. 89 The IPsec architecture has been revised in RFC 4301 [5]. Among the 90 many changes, the list of selectors has been expanded to include the 91 Mobility Header message type. This has an impact on how security 92 policies and security associations are configured for protecting 93 mobility header messages. It becomes easier to differentiate between 94 the various Mobility Header messages based on the type value instead 95 of checking if a particular mobility header message is being sent on 96 a tunnel interface between the mobile node and the home agent, as it 97 was in RFC 3776. The revised IPsec architecture specification also 98 includes ICMP message type and code as selectors. This makes it 99 possible to protect Mobile Prefix Discovery messages without applying 100 the same security associations to all ICMPv6 messages. 102 This document discusses new requirements for the home agent and the 103 mobile node to use the revised IPsec architecture and IKEv2. 104 Section 4 lists the requirements. Section 6 and Section 7 describe 105 the required Security Policy Database (SPD) and Security Association 106 Database (SAD) entries. 108 The Internet Key Exchange (IKE) protocol has also been substantially 109 revised and simplified [4]. Section 7.3 of this document describes 110 how IKEv2 can be used to setup security associations for Mobile IPv6. 112 The use of EAP within IKEv2 is allowed to authenticate the mobile 113 node to the home agent. This is described in Section 8. A method 114 for dynamically configuring a home address from the home agent using 115 the Configuration Payload in IKEv2 is described in Section 9. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [1]. 123 3. Packet Formats 125 The mobile node and the home agent MUST support the packet formats as 126 defined in Section 3 of RFC 3776. 128 In case the mobile node reverse tunnels all traffic including Mobile 129 IPv6 signaling messages exchanged between the mobile node and the 130 home agent, then the Home Address Option is not required to be 131 present in the messages sent to the home agent. The packet format 132 for the binding update when sent in the tunnel mode looks as follows. 134 IPv6 hdr (source = care-of address, 135 destination = home agent) 136 ESP header in tunnel mode 137 IPv6 hdr (source = home address, 138 destination = home agent) 139 Mobility Header 140 Binding Update 141 Alternate Care-of Address option (care-of address) 143 The binding acknowledgement sent to the mobile node when it is away 144 from the home link looks as follows. 146 IPv6 hdr (source = home agent, 147 destination = care-of address) 148 ESP header in tunnel mode 149 IPv6 hdr (source = home agent, 150 destination = home address) 151 Mobility Header 152 Binding Acknowledgement 154 The packet formats for tunneled mobile prefix discovery messages is 155 very similar with the home address as the source address in the inner 156 IP header. 158 The support for the above tunneled packet format is optional on the 159 mobile node and the home agent. 161 4. Requirements 163 This section describes mandatory rules and requirements for all 164 Mobile IPv6 mobile nodes and home agents so that IPsec, with IKEv2 as 165 the key management protocol, can be used to protect traffic between 166 the mobile node and the home agent. Many of the requirements are 167 repeated from RFC 3776 to make this document self-contained and 168 complete. 170 4.1. General Requirements 172 o RFC 3775 states that manual configuration of IPsec security 173 associations MUST be supported and automated key management MAY be 174 supported. This document does not make any recommendations 175 regarding the support of manual IPsec configuration and dynamic 176 IPsec configuration. This document just describes the use of 177 manually created IPsec security associations and the use of IKEv2 178 as the automated IPsec key management protocol for protecting 179 Mobile IPv6 signaling messages. 181 o ESP encapsulation for Binding Updates and Binding Acknowledgements 182 MUST be supported and used. 184 o ESP encapsulation in tunnel mode for the Home Test Init and Home 185 Test messages tunneled between the mobile node and the home agent 186 MUST be supported and SHOULD be used. 188 o ESP encapsulation of the ICMPv6 messages related to mobile prefix 189 discovery MUST be supported and SHOULD be used. 191 o ESP encapsulation of the payload packets tunneled between the 192 mobile node and the home agent MAY be supported and used. 194 o If multicast group membership control protocols or stateful 195 address autoconfiguration protocols are supported, payload data 196 protection MUST be supported for those protocols. 198 o The home agent and the mobile node MAY support authentication 199 using EAP in IKEv2 as described in Section 8. 201 o The home agent and the mobile node MAY support remote 202 configuration of home address as described in Section 9. When the 203 home agent receives a configuration payload with a CFG_REQUEST for 204 INTERNAL_IP6_ADDRESS, it must reply with a valid home address for 205 the mobile node. The home agent can pick a home address from a 206 local database or from a DHCPv6 server on the home link. 208 4.2. Policy Requirements 210 The following requirements are related to the configuration of 211 security policy database on the home agent and the mobile node. 213 o RFC 3776 required configuration of the security policies per 214 interface in order to be able to differentiate between mobility 215 header messages sent to the home agent and tunneled through the 216 home agent to the correspondent node. Since the Mobility Header 217 message type is a selector, it is now easy to differentiate 218 between HoTi and HoT messages from other mobility header messages. 219 Therefore per-interface configuration of security policies is not 220 required for protecting mobility header messages. Note that 221 without per-interface security policies. payload packet protection 222 is limited to packets originating/terminating at the home address. 224 Traffic using link local address within the Mobile IP tunnel 225 cannot be provided IPsec protection without per-interface security 226 policies. 228 o The home agent MUST be able to prevent a mobile node from using 229 its security association to send a Binding Update on behalf of 230 another mobile node. With manual IPsec configuration, the home 231 agent MUST be able to verify that a security association was 232 created for a particular home address. With dynamic keying, the 233 home agent MUST be able to verify that the identity presented in 234 the IKE_AUTH exchange is allowed to create security associations 235 for a particular home address. 237 o The home agent uses the Peer Authorization Database (PAD) [5] to 238 store per-mobile node state. More specifically the per-mobile 239 state stores information that is used to authenticate the mobile 240 node and the authorization information that ties the mobile node's 241 identity to the home address of the mobile node. This will allow 242 the home agent to prevent a mobile node from creating IPsec 243 security associations for another mobile node's home address. In 244 case of dynamic home address assignment, the home agent creates a 245 temporary PAD entry linking the authenticated peer identity and 246 the newly allocated home address. 248 o As required in the base specification [2], when a packet destined 249 to the receiving node is matched against IPsec security policy or 250 selectors of a security association, an address appearing in a 251 Home Address destination option is considered as the source 252 address of the packet. 254 Note that the home address option appears before IPsec headers. 255 Section 11.3.2 of the base specification describes one possible 256 implementation approach for this: The IPsec policy operations can 257 be performed at the time when the packet has not yet been modified 258 per Mobile IPv6 rules, or has been brought back to its normal form 259 after Mobile IPv6 processing. That is, the processing of the Home 260 Address option is seen as a fixed transformation of the packets 261 that does not affect IPsec processing. 263 o Similarly, a home address within a Type 2 Routing header destined 264 to the receiving node is considered as the destination address of 265 the packet, when a packet is matched against IPsec security policy 266 or selectors of a security association. 268 Similar implementation considerations apply to the Routing header 269 processing as was described above for the Home Address destination 270 option. 272 o When the mobile node returns home and de-registers with the Home 273 Agent, the tunnel between the home agent and the mobile node's 274 care-of address is torn down. The security policy entries, which 275 were used for protecting tunneled traffic between the mobile node 276 and the home agent SHOULD be made inactive (for instance, by 277 removing them and installing them back later through an API). The 278 corresponding security associations could be kept as they are or 279 deleted depending on how they were created. If the security 280 associations were created dynamically using IKE, they are 281 automatically deleted when they expire. If the security 282 associations were created through manual configuration, they MUST 283 be retained and used later when the mobile node moves away from 284 home again. The security associations protecting Binding Updates 285 and Acknowledgements, and prefix discovery SHOULD NOT be deleted 286 as they do not depend on care-of addresses and can be used again. 288 o The mobile node MUST use the Home Address destination option in 289 Binding Updates and Mobile Prefix Solicitations when transport 290 mode IPsec protection is used, so that the home address is visible 291 when the IPsec policy checks are made. 293 o The home agent MUST use the Type 2 Routing header in Binding 294 Acknowledgements and Mobile Prefix Advertisements sent to the 295 mobile node when transport mode IPsec protection is used, again 296 due to the need to have the home address visible when the policy 297 checks are made. 299 4.3. IPsec Protocol Processing Requirements 301 The following lists requirements for IPsec processing at the Home 302 Agent and the mobile node. 304 o The home agent and mobile node SHOULD support Mobility Header 305 message type as an IPsec selector. 307 o The home agent and mobile node SHOULD support ICMPv6 message type 308 as an IPsec selector. 310 o The home agent MUST be able to distinguish between HoTi messages 311 sent to itself, when it is acting as a Correspondent Node, from 312 those sent to Correspondent Nodes when it is acting as a home 313 agent, based on the destination address of the packet. 315 o When securing Binding Updates, Binding Acknowledgements, and 316 Mobile Prefix Discovery messages, both the mobile node and the 317 home agent MUST support the use of Encapsulating Security Payload 318 (ESP) [6] header in transport mode and MUST use a non-null payload 319 authentication algorithm to provide data origin authentication, 320 connectionless integrity and optional anti-replay protection. The 321 use of sequence number in the ESP header to provide anti-replay 322 protection is optional because the sequence numbers in the Binding 323 Updates provide anti-replay protection. However, the anti-replay 324 protection fails if the home agent looses the binding cache state, 325 for example, due to a reboot. Since the IPsec security 326 association state can be also be assumed to be lost, ESP cannot 327 provide anti-replay protection in this case. Complete anti-replay 328 protection can only be provided by the use of a dynamic keying 329 mechanism, like IKEv2. 331 Support for protecting these messages using ESP in tunnel mode is 332 optional. 334 o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the 335 protection of packets belonging to the return routability 336 procedure. A non-null encryption transform and a non-null 337 authentication algorithm MUST be applied. 339 o When ESP is used to protect Binding Updates, there is no 340 protection for the care-of address that appears in the IPv6 header 341 outside the area protected by ESP. It is important for the home 342 agent to verify that the care-of address has not been tampered 343 with. As a result, the attacker would have redirected the mobile 344 node's traffic to another address. In order to prevent this, 345 Mobile IPv6 implementations MUST use the Alternate Care-of Address 346 mobility option in Binding Updates sent by mobile nodes while away 347 from home. The exception to this is when the mobile node returns 348 home and sends a Binding Update to the home agent in order to de- 349 register. 351 When IPsec is used to protect return routability signaling or 352 payload packets, the mobile node MUST set the source address it 353 uses for the outgoing tunnel packets to the current primary care- 354 of address. 356 o When IPsec is used to protect return routability signaling or 357 payload packets, IPsec security associations are needed to provide 358 this protection. When the care-of address for the mobile node 359 changes as a result of an accepted Binding Update, special 360 treatment is needed for the next packets sent using these security 361 associations. The home agent MUST set the new care-of address as 362 the destination address of these packets, as if the outer header 363 destination address in the security association had changed. 364 Similarly, the home agent starts to expect the new source address 365 in the tunnel packets received from the mobile node. 367 Such address changes can be implemented, for instance, through an 368 API from the Mobile IPv6 implementation to the IPsec 369 implementation. One such API is described in [12]. It should be 370 noted that the use of such an API and the address changes MUST 371 only be done based on the Binding Updates received by the home 372 agent and protected by the use of IPsec. Address modifications 373 based on other sources, such as Binding Updates to the 374 correspondent nodes protected by return routability, or open 375 access to an API from any application may result in security 376 vulnerabilities. 378 4.4. Dynamic Keying Requirements 380 The following requirements are related to the use of a dynamic key 381 management protocol by the mobile node and the home agent. 382 Section 7.3 describes the use of IKEv2 as the dynamic key management 383 protocol. 385 o The mobile node MUST use its care-of address as source address in 386 protocol exchanges, when using dynamic keying. 388 o The mobile node and the home agent MUST create security 389 associations based on the home address, so that the security 390 associations survive change in care-of address. When using IKEv2 391 as the key exchange protocol, the home address should be carried 392 as the initiator IP address in the TSi payload during the 393 CREATE_CHILD_SA exchange [4]. 395 o If the mobile node has used IKEv2 to establish security 396 associations with its home agent, it should follow the procedures 397 discussed in Section 11.7.1 and 11.7.3 of the base specification 398 [2] to determine whether the IKE endpoints can be moved or if the 399 SAs, including the IKEv2 SA, have to be re-established. 401 o If the home agent has used IKEv2 to establish security 402 associations with the mobile node, it should follow the procedures 403 discussed in Section 10.3.1 and 10.3.2 of the base specification 404 [2] to determine whether the IKE endpoints can be moved or if the 405 SAs, including the IKEv2 SA, have to be re-established. 407 5. Selector Granularity Considerations 409 IPsec implementations are compatible with this document even if they 410 do not support fine grain selectors such as the Mobility Header 411 message type and ICMPv6 message type. Note that such IPsec 412 implementations are not compliant to RFC 4301 [5]. For various 413 reasons, some implementations may choose to support only coarse grain 414 selectors (i.e., addresses and in some cases the protocol field) for 415 forwarded traffic. As finer grain selectors give better control, 416 i.e., the protection is only applied when required, the examples in 417 the document always use the finest granularity. 419 The following describes different ways of setting up IPsec policies 420 for protecting Mobile IPv6 messages: 422 o The IPsec implementations on the mobile node and the home agent 423 support fine grain selectors, including the Mobility Header 424 message type. This is the case assumed in the IPsec SPD and SAD 425 examples in this document. 427 o The IPsec implementations only support selectors at a protocol 428 level. In such implementations, the IPsec implementation can only 429 identify mobility header traffic and cannot identify the 430 individual mobility header messages. In this case, the protection 431 of Return Routability Messages uses a setup similar to the regular 432 payload packets to the correspondent node with the protocol 433 selector set to Mobility Header messages. All tunneled Mobility 434 Header messages will be protected. 436 o The third case is where the protocol selector is not available in 437 the IPsec implementation. In this case all traffic sent by the 438 mobile node reverse tunneled through the home agent is protected 439 using ESP in tunnel mode. This case is also applicable when the 440 mobile node, due to privacy considerations, tunnels all traffic to 441 the home agent. This includes Mobile IPv6 signaling messages 442 exchanged between the mobile node and the home agent and all 443 traffic exchanged between the mobile node and the correspondent 444 node. This case uses IPsec tunnel mode SA with the protocol 445 selector set to 'any'. 447 The third case where all tunneled traffic is protected introduces 448 some additional considerations: 450 o If there is just one IPsec SA providing protection for all 451 traffic, then the SA MUST fulfill the requirements for protecting 452 the Return Routability messages which require confidentiality 453 protection. If the third case is being used for privacy 454 considerations, then there can also be separate tunnel mode SPD 455 entries for protecting the Return Routability messages with a 456 higher priority in the SPD so that the SPD entry with the higher 457 priority gets applied first. 459 o The receipt of a Binding Update from the new care-of address 460 updates the tunnel endpoint of the IPsec SA as described in 461 Section 4.3. Since the Binding Update that updates the tunnel 462 endpoint is received through the same tunnel interface that needs 463 to be updated, special care should be taken on the home agent to 464 ensure that the Binding Update is not dropped. This can be 465 achieved by either performing the source address check on the 466 outer IPv6 header after the binding update is processed or have 467 exception handling to check the inner packet for a Binding Update 468 when the source address match on the outer source address fails. 469 Typical IPsec processing does not check the outer source address 470 when the originator of the packet has already been authenticated. 472 6. Manual Configuration 474 This section describes the SPD and SAD entries that can be used to 475 protect Mobile IPv6 signaling messages. The SPD and SAD entries are 476 only example configurations. A particular mobile node implementation 477 and a home agent implementation could configure different SPD and SAD 478 entries as long as they provide the required security of the Mobile 479 IPv6 signaling messages. 481 For the examples described in this document, a mobile node with home 482 address, "home_address_1", primary care-of address, 483 "care_of_address_1", a home agent with address, "home_agent_1" and a 484 user of the mobile node with identity "user_1" are assumed. If the 485 home address of the mobile node changes, the SPD and SAD entries need 486 to be re-created or updated for the new home address. 488 The Peer Authorization Database is not used when manual IPsec 489 configuration is used for setting up security associations for 490 protecting Mobile IPv6 signaling messages. 492 6.1. Binding Updates and Acknowledgements 494 The following are the SPD and SAD entries on the mobile node and the 495 home agent to protect Binding Updates and Acknowledgements. 497 mobile node SPD-S: 498 - IF local_address = home_address_1 & 499 remote_address = home_agent_1 & proto = MH & 500 local_mh_type = BU & remote_mh_type = BAck 501 Then use SA SA1 (OUT) and SA2 (IN) 503 mobile node SAD: 504 - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): 505 local_address = home_address_1 & 506 remote_address = home_agent_1 & 507 proto = MH & mh_type = BU 508 - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): 509 local_address = home_agent_1 & 510 remote_address = home_address_1 & 511 proto = MH & mh_type = BAck 513 home agent SPD-S: 514 - IF local_address = home_agent_1 & 515 remote_address = home_address_1 & proto = MH & 516 local_mh_type = BAck & remote_mh_type = BU 517 Then use SA SA2 (OUT) and SA1 (IN) 519 home agent SAD: 520 - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): 521 local_address = home_agent_1 & 522 remote_address = home_address_1 & 523 proto = MH & mh_type = BAck 524 - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): 525 local_address = home_address_1 & 526 remote_address = home_agent_1 & 527 proto = MH & mh_type = BU 529 6.2. Return Routabililty Messages 531 The following are the SPD and SAD entries on the mobile node and the 532 home agent to protect Return Routability messages. 534 mobile node SPD-S: 535 - IF local_address = home_address_1 & remote_address = any & 536 proto = MH & local_mh_type = HoTi & remote_mh_type = HoT 537 Then use SA SA3 (OUT) and SA4 (IN) 539 mobile node SAD: 540 - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): 541 local_address = home_address_1 & remote_address = any & 542 proto = MH & mh_type = HoTi 543 - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL): 544 local_address = any & remote_address = home_address_1 & 545 proto = MH & mh_type = HoT 547 home agent SPD-S: 548 - IF remote_address = home_address_1 & local_address = any & 549 proto = MH & local_mh_type = HoT & remote_mh_type = HoTi 550 Then use SA SA4 (OUT) and SA3 (IN) 552 home agent SAD: 553 - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL): 554 local_address = any & remote_address = home_address_1 & 555 proto = MH & mh_type = HoT 556 - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): 557 local_address = home_address_1 & remote_address = any & 558 proto = MH & mh_type = HoTi 560 6.3. Mobile Prefix Discovery Messages 562 The following are the SPD and SAD entries used to protect Mobile 563 Prefix Discovery messages. 565 mobile node SPD-S: 566 - IF local_address = home_address_1 & 567 remote_address = home_agent_1 & proto = ICMPv6 & 568 local_icmp6_type = MPS & remote_icmp6_type = MPA 569 Then use SA SA5 (OUT) and SA6 (IN) 571 mobile node SAD: 572 - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): 573 local_address = home_address_1 & 574 remote_address = home_agent_1 & 575 proto = ICMPv6 & icmp6_type = MPS 576 - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): 577 local_address = home_agent_1 & 578 remote_address = home_address_1 & 579 proto = ICMPv6 & icmp6_type = MPA 581 home agent SPD-S: 582 - IF local_address = home_agent_1 & 583 remote_address = home_address_1 & proto = ICMPv6 & 584 local_icmp6_type = MPA & remote_icmp6_type = MPS 585 Then use SA SA6 (OUT) and SA5 (IN) 587 home agent SAD: 588 - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): 589 local_address = home_agent_1 & 590 remote_address = home_address_1 & 591 proto = ICMPv6 & icmp6_type = MPA 592 - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): 593 local_address = home_address_1 & 594 remote_address = home_agent_1 & 595 proto = ICMPv6 & icmp6_type = MPS 597 6.4. Payload Packets 599 Regular payload traffic between the mobile node and the correspondent 600 node tunneled through the home agent can be protected by IPsec, if 601 required. The mobile node and the home agent use ESP in tunnel mode 602 to protect the tunneled traffic. The SPD and SAD entries shown in 603 Section 5.2.4 of [3] are applicable here. 605 7. Dynamic Configuration 607 This section describes the use of IKEv2 to setup the required 608 security associations. 610 7.1. Peer Authorization Database Entries 612 The following describes PAD entries on the mobile node and the home 613 agent. The PAD entries are only example configurations. Note that 614 the PAD is a logical concept and a particular mobile node and a home 615 agent implementation can implement the PAD in an implementation 616 specific manner. The PAD state may also be distributed across 617 various databases in a specific implementation. 619 mobile node PAD: 620 - IF remote_identity = home_agent_identity_1 621 Then authenticate (shared secret/certificate/) 622 and authorize CHILD_SA for remote address home_agent_1 624 home agent PAD: 625 - IF remote_identity = user_1 626 Then authenticate (shared secret/certificate/EAP) 627 and authorize CHILD_SAs for remote address home_address_1 629 The list of authentication mechanisms in the above examples is not 630 exhaustive. There could be other credentials used for authentication 631 stored in the PAD. 633 In case of dynamic home address assignment, the home agent creates a 634 temporary PAD entry linking the authenticated peer identity and the 635 newly allocated home address. 637 7.2. Security Policy Database Entries 639 The following sections describe the security policy entries on the 640 mobile node and the home agent. The SPD entries are only example 641 configurations. A particular mobile node implementation and a Home 642 Agent implementation could configure different SPD entries as long as 643 they provide the required security of the Mobile IPv6 signaling 644 messages. 646 In the examples shown below, the identity of the user of the mobile 647 node is assumed to be user_1, the home address of the mobile node is 648 assumed to be home_address_1, the primary care-of address of the 649 mobile node is assumed to be care_of_address_1 and the IPv6 address 650 of the Home Agent is assumed to be home_agent_1. 652 7.2.1. Binding Updates and Acknowledgements 654 The following are the SPD entries on the mobile node and the home 655 agent for protecting Binding Updates and Acknowledgements. 657 mobile node SPD-S: 658 - IF local_address = home_address_1 & 659 remote_address = home_agent_1 & 660 proto = MH & local_mh_type = BU & remote_mh_type = BAck 661 Then use SA ESP transport mode 662 Initiate using IDi = user_1 to address home_agent_1 664 home agent SPD-S: 665 - IF local_address = home_agent_1 & 666 remote_address = home_address_1 & 667 proto = MH & local_mh_type = BAck & remote_mh_type = BU 668 Then use SA ESP transport mode 670 In the examples shown above, the home address of the mobile node 671 might not be available all the time. For instance, the mobile node 672 might have not configured a home address yet. When the mobile node 673 acquires a new home address, it must either add the address to the 674 corresponding SPD entries or create the SPD entries for the home 675 address. 677 The home agent should have named SPD entries per mobile node, based 678 on the identity of the mobile node. The identity of the mobile node 679 is stored in the "Name" selector in the SPD [5]. The home address 680 presented by the mobile node during the IKE negotiation is stored as 681 the remote IP address in the resultant IPsec security associations. 682 If the mobile node dynamically configures a home agent and the home 683 address, the home agent may not know which mobile nodes it is 684 supposed to be serving. Therefore the home agent cannot have SPD 685 entries configured per mobile node. Instead the home agent should 686 have have generic SPD entries to prevent mobility header traffic that 687 requires IPsec protection from bypassing the IPsec filters. Once a 688 mobile node authenticates to the home agent and configures a home 689 address, appropriate SPD entries are created for the mobile node. 691 The Mobility Header message type is negotiated by placing it in the 692 most significant eight bits of the 16 bit local "port" selector 693 during IKEv2 exchange. For more details, refer to [5]. The TSi and 694 TSr payloads in the above examples will contain many other selectors 695 apart from home_address_1. For the sake of brevity, we show only 696 those values that are relevant for Mobile IPv6. 698 7.2.2. Return Routability Messages 700 The following are the SPD entries on the mobile node and the home 701 agent for protecting the Return Routability messages. 703 mobile node SPD-S: 704 - IF local_address = home_address_1 & remote_address = any & 705 proto = MH & local_mh_type = HoTi & remote_mh_type = HoT 706 Then use SA ESP tunnel mode 707 Initiate using IDi = user_1 to address home_agent_1 709 home agent SPD-S: 710 - IF local_address = any & remote_address = home_address_1 & 711 proto = MH & local_mh_type = HoT & remote_mh_type = HoTi 712 Then use SA ESP tunnel mode 714 When the mobile node's care-of address changes the SPD entries on 715 both the mobile node and the home agent must be updated. The home 716 agent knows about the change in care-of address of the mobile node 717 when it receives a Binding Update from the mobile node. 719 7.2.3. Mobile Prefix Discovery Messages 721 The following are the SPD entries on the mobile node and the home 722 agent for protecting Mobile Prefix Discovery messages. 724 mobile node SPD-S: 725 - IF local_address = home_address_1 & 726 remote_address = home_agent_1 & 727 proto = ICMPv6 & local_icmp6_type = MPS & 728 remote_icmp6_type = MPA 729 Then use SA ESP transport mode 730 Initiate using IDi = user_1 to address home_agent_1 732 home agent SPD-S: 733 - IF local_address = home_agent_1 & 734 remote_address = home_address_1 & 735 proto = ICMPv6 & local_icmp6_type = MPA & 736 remote_icmp6_type = MPS 737 Then use SA ESP transport mode 739 In the examples shown above, the home address of the mobile node 740 might not be available all the time. When the mobile node acquires a 741 new home address, it must add the address to the corresponding SPD 742 entries. 744 The TSi and TSr payloads in the above examples will contain many 745 other selectors apart from home_address_1. For brevity, they are not 746 show here. 748 7.2.4. Payload Packets 750 The following are the SPD entries on the mobile node and the home 751 agent if payload traffic exchanged between the mobile node and its 752 Correspondent Node needs to be protected. The SPD entries are 753 similar to the entries for protecting Return Routability messages and 754 have lower priority than the above SPD entries. 756 mobile node SPD-S: 757 - IF interface = IPv6 tunnel to home_agent_1 & 758 source = home_address_1 & destination = any & proto = X 759 Then use SA ESP tunnel mode 760 Initiate using IDi = user_1 to address home_agent_1 762 home agent SPD-S: 763 - IF interface = IPv6 tunnel to home_address_1 & 764 source = any & destination = home_address_1 & proto = X 765 Then use SA ESP tunnel mode 767 7.3. Security Association negotiation using IKEv2 769 Mobile IPv6 signaling messages are typically initiated by the mobile 770 node. The mobile node sends a Binding Update to the home agent 771 whenever it moves and acquires a new care-of address. 773 The mobile node initiates an IKEv2 protocol exchange if the required 774 security associations are not present. A possible mechanism used for 775 mutual authentication is a shared secret between the mobile node and 776 the home agent. The home agent uses the identity of the mobile node 777 to identify the corresponding shared secret. When a public key based 778 mechanism is available, it should be the preferred mechanism for 779 mutual authentication. 781 If a shared secret is being used, the mobile node uses the shared 782 secret to generate the AUTH payload in the IKE_AUTH exchange. If the 783 mobile node is using a public key based mechanism, then it uses its 784 private key to generate the AUTH payload in the IKE_AUTH exchange. 786 Mobile Node Home Agent 787 ----------- ---------- 788 HDR, SAi1, KEi, Ni --> 790 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 792 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 793 AUTH, SAi2, TSi, TSr} 794 --> 796 <-- HDR, SK {IDr, [CERT,] AUTH, 797 SAr2, TSi, TSr} 799 The mobile node always includes its identity in the IDi payload in 800 the IKE_AUTH exchange. The mobile node could use the following 801 different types of identities to identity itself to the home agent. 803 o Home Address - The mobile node could use its statically configured 804 home address as its identity. In this case the ID Type field is 805 set to ID_IPV6_ADDR. 806 o FQDN - The mobile node can use a Fully Qualified Domain Name as 807 the identifier and set the ID Type field to ID_FQDN. 808 o RFC 822 identifier - If the mobile node uses a RFC 822 identifier 809 [9], it sets the ID Type field to ID_RFC822_ADDR. 811 The above list of identities is not exhaustive. 813 In the IKE_AUTH exchange, the mobile node includes the home address 814 and the appropriate selectors in the TSi (Traffic Selector-initiator) 815 payload to negotiate IPsec security associations for protecting the 816 Binding Update and Binding Acknowledgement messages. The mobile node 817 MAY use a range of selectors that includes the mobility message types 818 for Binding Update and Binding Acknowledgement to use the same pair 819 of IPsec security association for both messages. 821 After the IKE_AUTH exchange completes, the mobile node initiates 822 CREATE_CHILD_SA exchanges to negotiate additional security 823 associations for protecting Return Routability signaling, Mobile 824 Prefix Discovery messages and optionally payload traffic. The 825 CREATE_CHILD_SA exchanges are protected by IKEv2 security association 826 created during the IKE_SA_INIT exchange. If a correspondent node, 827 that is also a mobile node, initiates the return routability 828 exchange, then the home agent initiates the CREATE_CHILD_SA exchange 829 to negotiate security associations for protecting Return Routabilty 830 messages. 832 It is important that the security associations are created based on 833 the home address of the mobile node, so that the security 834 associations survive care-of address change. The mobile node MUST 835 use its home address as the initiator IP address in the TSi payload 836 in the CREATE_CHILD_SA exchange in order to create the IPsec security 837 associations for the home address. 839 Mobile Node Home Agent 840 ----------- ---------- 841 HDR, SK {[N], SA, Ni, [KEi], 842 [TSi, TSr]} --> 844 <-- HDR, SK {SA, Nr, [KEr], 845 [TSi, TSr]} 847 When PKI based authentication is used between the mobile node and the 848 Home Agent, the identity presented by the mobile node in the IDi 849 payload MUST correspond to the identity in the certificate obtained 850 by the Home Agent. The home agent uses the identity presented in the 851 IDi payload to lookup the policy and the certificate that corresponds 852 to the mobile node. If the mobile node presents its home address in 853 the IDi payload, then the home agent MUST verify that the home 854 address matches the address in an iPAddress field in the 855 SubjectAltName extension [8]. 857 When the mobile node uses its home address in the IDi field, 858 implementations are not required to match the source address in the 859 outermost IP header with the IP address in the IDi field. According 860 to RFC 4306 [4], the IP header fields in the IKEv2 messages are 861 ignored and used only in the IP headers for IKEv2 messages sent as 862 replies. 864 7.4. Movements and Dynamic Keying 866 If the mobile node moves and its care-of address changes, the IKEv2 867 SA might not be valid. RFC 3775 defines a mechanism based on the 868 successful exchange of Binding Update and Binding Acknowledgement 869 messages. The mobile node establishes the IKE SA with the home agent 870 using its primary care-of address. The IKE SA endpoints are updated 871 on the home agent when it receives the Binding Update from the mobile 872 node's new care-of address and on the mobile node when it sends the 873 Binding Update to the home agent or when it receives the Binding 874 acknowledgement sent by the home agent. This capability to change 875 IKE endpoints is indicated through setting the Key Management 876 Capability (K) flag [2] in the Binding Update and Binding 877 Acknowledgement messages. If the mobile node or the home agent does 878 not support this capability, and has no other means to update the 879 addresses, then an IKEv2 exchange MUST be initiated to re-establish a 880 new IKE SA. 882 8. The use of EAP authentication 884 In addition to using public key signatures and shared secrets, EAP 885 [10] can be used with IKEv2 for authenticating the mobile node to the 886 home agent. 888 The mobile node indicates that it wants to use EAP by including the 889 IDi payload but leaving out the AUTH payload in the first message 890 during the IKE_AUTH exchange. The home agent then includes an EAP 891 payload if it is willing to use an extensible authentication method. 892 Security associations are not created until the subsequent IKE_AUTH 893 exchange after successful EAP authentication. The use of EAP adds at 894 least two round trips to the IKE negotiation. The number of round 895 trips depends on the EAP method used. 897 Mobile Node Home Agent 898 ------------ ---------- 899 HDR, SAi1, KEi, Ni --> 901 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 903 HDR, SK {IDi, [CERTREQ,] [IDr,] 904 SAi2, TSi, TSr}--> 906 <-- HDR, SK {IDr, [CERT,] AUTH, 907 EAP } 908 . 909 . 910 . 912 HDR, SK {EAP} --> 914 <-- HDR, SK {EAP (success)} 916 HDR, SK {AUTH} --> 918 <-- HDR, SK {AUTH, SAr2, TSi, 919 TSr} 921 When EAP is used, the identity presented by the mobile node in the 922 IDi field may not be the actual identity of the mobile node. It 923 could be set to an identity that is used only for AAA routing 924 purposes and selecting the right EAP method. It is possible that the 925 actual identity is carried inside EAP, invisible to the home agent. 926 While IKEv2 does not allow an EAP Identity Request/Response message 927 exchange, EAP methods may exchange identities within themselves. In 928 this case the home agent MUST acquire the mobile node's identity from 929 the corresponding AAA server. How the home agent acquires the mobile 930 node's identity is out of scope for this document. 932 Some EAP methods, when used with IKEv2, generate a shared key on the 933 mobile node and the Home Agent once the EAP authentication succeeds. 934 This shared key is used to generate the AUTH payloads in the 935 subsequent IKEv2 messages. The shared key, if used to generate the 936 AUTH payloads, MUST NOT be used for any other purpose. For more 937 details, refer to [4]. 939 The use of EAP between the mobile node and the home agent might 940 require the home agent to contact an authorization server like the 941 AAA Home server, on the home link, to authenticate the mobile node. 942 Please refer to [7] for more details. 944 9. Dynamic Home Address Configuration 946 The mobile node can dynamically configure a home address by including 947 a Configuration Payload in the IKE_AUTH exchange, with a request for 948 an address from the home link. The mobile node should include a 949 zero-length INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST 950 Payload. The mobile node MAY include multiple instances of the 951 INTERNAL_IP6_ADDRESS to request multiple home address to the assigned 952 by the home agent. 954 When the home agent receives a configuration payload with a 955 CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home 956 address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in 957 the CFG_REPLY contains the prefix length of the home prefix in 958 addition to a 128 bit home address. The home agent could use a local 959 database or contact a DHCPv6 server on the home link to allocate a 960 home address. The duration for which the home address is allocated 961 to the mobile node is the same as duration for which an IKEv2 962 security association exists between the mobile node and the home 963 agent. If the IKEv2 security association is rekeyed, the home 964 address lifetime is also extended. 966 Mobile Node Home Agent 967 ----------- ---------- 968 HDR, SK {IDi, [CERT,] [CERTREQ,] 969 [IDr,] AUTH, CP(CFG_REQUEST), 970 SAi2, TSi, TSr} 971 --> 973 <-- HDR, SK {IDr, [CERT,] AUTH, 974 CP(CFG_REPLY), SAr2, 975 TSi, TSr} 977 The mobile node could suggest a home address that it wants to use in 978 the CFG_REQUEST. For example, this could be a home address that it 979 was allocated before or could be an address the mobile node auto- 980 configured from the IPv6 prefix on the home link. The Home Agent 981 could let the mobile node use the same home address by setting the 982 INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same 983 home address. If the home agent wants the mobile node to use a 984 different home address, it sends a new home address in the 985 INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload. The Mobile 986 Node MUST stop using its old home address and start using the newly 987 allocated home address. 989 In case the home agent is unable to allocate a home address for the 990 mobile node during the IKE_AUTH exchange, it MUST send a Notify 991 Payload with an INTERNAL_ADDRESS_FAILURE message. When the mobile 992 node receives a Notify Payload with an INTERNAL_ADDRESS_FAILURE 993 message, it SHOULD terminate the IKE_AUTH exchange. The mobile node 994 then should initiate a new IKE_SA_INIT and IKE_AUTH exchange and try 995 to auto-configure a home address as described in [13]. The mobile 996 node MAY also switch to another home agent. The new home agent 997 address can be obtained by consulting a home agent list received 998 during a previous home agent discovery phase or, if such list is 999 empty or not available, by attempting a new home agent discovery. 1001 If the mobile node wants to configure a DNS server from the home link 1002 it can request for the DNS server information by including an 1003 INTERNAL_IP6_DNS attribute in the CFG_REQUEST payload. 1005 10. Security Considerations 1007 This document describes how IPsec can be used to secure Mobile IPv6 1008 signaling messages. Please refer to RFC 3775 for security 1009 considerations related to the use of IPsec with Mobile IPv6. 1011 A misbehaving mobile node could create IPsec security associations 1012 for a home address that belongs to another mobile node. Therefore, 1013 the home agent should check if a particular mobile node is authorized 1014 to use a home address before creating IPsec security associations for 1015 the home address. If the home address is assigned as described in 1016 Section 9, the home agent MUST associate the home address with the 1017 identity used in IKE negotiation. The home agent MAY store the 1018 assigned home address in the SPD entries created for the mobile node. 1020 The use of EAP for authenticating the mobile node to the home agent 1021 is described in Section 8. Security considerations related to the 1022 use of EAP with IKEv2 are described in [4]. 1024 11. IANA Considerations 1026 This document requires no action from IANA. 1028 12. Acknowledgements 1030 The authors would like to thank Mika Joutsenvirta, Pasi Eronen, Jari 1031 Arkko, Gerardo Giaretta, Shinta Sugimoto, Tero Kivinen, Steve 1032 Bellovin, Kilian Weniger and Vijay Gurbani for reviewing the 1033 document. 1035 Many of the requirements listed in Section 4 are copied from RFC 1036 3776. Therefore, the authors of RFC 3776 are acknowledged. 1038 13. References 1040 13.1. Normative References 1042 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1043 Levels", BCP 14, RFC 2119, March 1997. 1045 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1046 IPv6", RFC 3775, June 2004. 1048 [3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1049 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1050 Agents", RFC 3776, June 2004. 1052 [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 1053 December 2005. 1055 [5] Kent, S. and K. Seo, "Security Architecture for the Internet 1056 Protocol", RFC 4301, December 2005. 1058 [6] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 1059 December 2005. 1061 13.2. Informative References 1063 [7] Giaretta, G., "AAA Goals for Mobile IPv6", 1064 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 1065 September 2006. 1067 [8] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ 1068 ISAKMP, IKEv2, and PKIX", 1069 draft-ietf-pki4ipsec-ikecert-profile-11 (work in progress), 1070 September 2006. 1072 [9] Crocker, D., "Standard for the format of ARPA Internet text 1073 messages", STD 11, RFC 822, August 1982. 1075 [10] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1076 Levkowetz, "Extensible Authentication Protocol (EAP)", 1077 RFC 3748, June 2004. 1079 [11] Kent, S. and R. Atkinson, "Security Architecture for the 1080 Internet Protocol", RFC 2401, November 1998. 1082 [12] Sugimoto, S., "PF_KEY Extension as an Interface between Mobile 1083 IPv6 and IPsec/IKE", draft-sugimoto-mip6-pfkey-migrate-03 (work 1084 in progress), September 2006. 1086 [13] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 1087 draft-ietf-mip6-bootstrapping-split-03 (work in progress), 1088 October 2006. 1090 Authors' Addresses 1092 Vijay Devarapalli 1093 Azaire Networks 1094 4800 Great America Pkwy 1095 Santa Clara, CA 95054 1096 USA 1098 Email: vijay.devarapalli@azairenet.com 1100 Francis Dupont 1101 CELAR 1103 Email: Francis.Dupont@fdupont.fr 1105 Full Copyright Statement 1107 Copyright (C) The Internet Society (2006). 1109 This document is subject to the rights, licenses and restrictions 1110 contained in BCP 78, and except as set forth therein, the authors 1111 retain all their rights. 1113 This document and the information contained herein are provided on an 1114 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1115 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1116 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1117 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1118 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1119 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1121 Intellectual Property 1123 The IETF takes no position regarding the validity or scope of any 1124 Intellectual Property Rights or other rights that might be claimed to 1125 pertain to the implementation or use of the technology described in 1126 this document or the extent to which any license under such rights 1127 might or might not be available; nor does it represent that it has 1128 made any independent effort to identify any such rights. Information 1129 on the procedures with respect to rights in RFC documents can be 1130 found in BCP 78 and BCP 79. 1132 Copies of IPR disclosures made to the IETF Secretariat and any 1133 assurances of licenses to be made available, or the result of an 1134 attempt made to obtain a general license or permission for the use of 1135 such proprietary rights by implementers or users of this 1136 specification can be obtained from the IETF on-line IPR repository at 1137 http://www.ietf.org/ipr. 1139 The IETF invites any interested party to bring to its attention any 1140 copyrights, patents or patent applications, or other proprietary 1141 rights that may cover technology that may be required to implement 1142 this standard. Please address the information to the IETF at 1143 ietf-ipr@ietf.org. 1145 Acknowledgment 1147 Funding for the RFC Editor function is provided by the IETF 1148 Administrative Support Activity (IASA).