idnits 2.17.1 draft-haddad-mipshop-hmipv6-security-06.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 574. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 564. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (August 7, 2006) is 6466 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Ks' is mentioned on line 165, but not defined == Outdated reference: A later version (-01) exists of draft-soliman-mipshop-4140bis-00 -- Possible downref: Normative reference to a draft: ref. 'HMIPv6' ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) == Outdated reference: A later version (-02) exists of draft-ietf-dna-frd-01 == Outdated reference: A later version (-03) exists of draft-haddad-mipshop-optisend-01 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP Working Group W. Haddad 3 Internet-Draft S. Krishnan 4 Expires: February 8, 2007 Ericsson Research 5 H. Soliman 6 Qualcomm-Flarion 7 August 7, 2006 9 Using Cryptographically Generated Addresses (CGA) to secure HMIPv6 10 Protocol (HMIPv6sec) 11 draft-haddad-mipshop-hmipv6-security-06 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on February 8, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This memo describes a method for establishing a security association 45 between the mobile node and the selected mobility anchor point in an 46 hierarchical mobile IPv6 domain. The suggested solution is based on 47 using the cryptographically generated address technology. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions used in this document . . . . . . . . . . . . . . 4 53 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6 55 5. New Messages and Options Format . . . . . . . . . . . . . . . 9 56 5.1. The Pre-Binding Update (PBU) Message Format . . . . . . . 9 57 5.2. Third Party Shared Key (TPSK) Option . . . . . . . . . . . 10 58 5.3. The MAP Session Mobility Secret (MSMS) Option . . . . . . 10 59 5.4. The Session Mobility Secret (SMS) Option . . . . . . . . . 11 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 62 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 67 Intellectual Property and Copyright Statements . . . . . . . . . . 18 69 1. Introduction 71 The Hierarchical Mobile IPv6 Mobility Management [HMIPv6] did not 72 specify nor favor any particular mechanism for establishing a 73 Security Association (SA) between the Mobile Node (MN) and the 74 Mobility Anchor Point (MAP) located within an HMIPv6 domain. 76 This memo describes a method, which allows the MN to establish an SA 77 with the selected MAP. The suggested solution is based on using the 78 Cryptographically Generated Address technology (described in [CGA]). 80 2. Conventions used in this document 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [TERM]. 86 3. Glossary 88 Access Router 90 The Access Router is the Mobile Node's default router. The AR 91 aggregates the outband traffic of mobile nodes. 93 Mobility Anchor Point (MAP) 95 A Mobility Anchor Point is a router located in a network visited 96 by the mobile node, which is used by the MN as a local Home Agent 97 (HA). 99 Regional Care-of Address (RCoA) 101 A Regional Care-of Address is an address obtained by the MN from 102 the visited network. An RCoA is an address on the MAP's subnet 103 and is auto-configured by the MN when receiving the MAP option. 105 On-link Care-of Address (LCoA) 107 The LCoA is the on-link CoA configured on a mobile node's 108 interface based on the prefix advertised by its default router. 110 Local Binding Update (LBU) Message 112 The MN sends a Local Binding Update message to the MAP in order to 113 establish a binding between the RCoA and the LCoA. 115 Pre-Binding Update (PBU) Message 117 The MN's default router sends a Pre-Binding Update message to the 118 MAP upon receiving a Router Solicitation (RtSol) message signed 119 with CGA technology as described in the secure neighbor discovery 120 protocol [SEND]. 122 Cryptographically Generated Address (CGA) 124 A technique described in [CGA] whereby an IPv6 address of a node 125 is cryptographically generated by using a one-way hash function 126 from the node's public key (Kp) and some other parameters. 128 Binding Acknowledgment (BA) Message 130 The MAP sends a binding acknowledgment message to the MN in 131 response to an LBU message. 133 4. Proposed Solution 135 We assume that the MN's LCoA is always computed based on the CGA 136 technology, in order to allow the MN to run SEND protocol. Such 137 assumption has also been made in [FMIPkey], which aims to provide a 138 security mechanism for [FMIPv6] protocol, and in the ongoing work on 139 optimizing the SEND protocol (described in [OptiSEND]). 141 In addition, we assume that the MN can discover the presence of an 142 HMIPv6 domain before sending a RtSol message. One example on how to 143 discover the HMIPv6 domain may consist on using technologies 144 described in [FRD]. However, it is important to mention that the 145 proposed solution works with the same performance without such 146 assumption. 148 A third assumption is the existence of secure links between all 149 routers located within the MAP tree. Such assumption is justified by 150 the fact that HMIPv6 protocol requires that routers within the MAP 151 tree get involved in delivering the RtAdv message sent by the MAP(s) 152 and in assisting the MN in selecting the most appropriate MAP. The 153 lack of secure links between nodes involved in offering the MAP 154 service can make it vulnerable to denial of service (DoS) attacks. 156 The suggested solution introduces a new signaling message, i.e., the 157 Pre-Binding Update (PBU) message, which is sent by the AR to the MAP 158 upon receiving a RtSol message from the MN carrying a valid signature 159 (i.e., the message is signed with the MN's CGA private key). 161 The following figure shows the signaling diagram for establishing a 162 bidirectional SA between the MN and the MAP: 164 1. MN to AR: Router Solicitation [CGA Signature] (RtSol) 165 2a. AR to MN: Router Acknowledgement [Ks] (RtAdv) 166 2b. AR to MAP: Pre-Binding Update [Ks + LCoA] (PBU) 167 3. MN to MAP: Local Binding Update [DH value (X)] (LBU) 168 4. MAP to MN: Binding Acknowledgment [DH value (Y)] (BA) 170 The suggested solution is described in the following steps: 172 o the MN configures a 64-bit interface identifier (IID) from using 173 CGA technology then uses it to send a RtSol message signed with 174 CGA, according to the SEND protocol. Note that at this stage, the 175 MN may not be aware that it has entered an HMIPv6 domain. 177 o Upon receiving a valid unicast RtSol message, the AR replies 178 immediately by sending back a unicast RtAdv message to the MN and 179 in parallel, a PBU message to the MAP. For this purpose, the AR 180 MUST compute a secret (Ks), encrypts it with the MN's CGA public 181 key and sends it in the unicast RtAdv message. The shared secret 182 is inserted in a new option (Third Party Shared Key (TSPK)), which 183 is carried by the unicast RtAdv message. 184 The AR MUST also compute the LCoA and RCoA that the MN is supposed 185 to autoconfigure. For this purpose, the LCoA is computed by 186 appending the 64-bit IID used in the RtSol message to the 64-bit 187 prefix advertised by the AR and the RCoA is computed by appending 188 the 64-bit prefix advertised by the MAP with the 64-bit IID 189 computed in the following way: 191 RCoA (IID) = First (64, SHA1(Ks | LCoA)) 193 Where First(x,y) is a function, which extracts the first x bits 194 from y and LCoA is the MN's on link care-of address. 196 After computing the MN's LCoA and RCoA, the AR inserts the two 197 IPv6 addresses and Ks in the PBU message and sends it to the MAP. 198 As noted earlier, it is assumed that the PBU messages are signed 199 by the ARs and the paths between the ARs and the MAP are secure. 201 o After receiving the PBU message, the MAP creates a binding cache 202 entry (BCE) for the MN, in which it stores the MN's LCoA, RCoA and 203 Ks carried by the PBU message. Once the BCE is created, the MAP 204 waits for a limited amount of time for the owner of the two 205 addresses to send the LBU message. If no valid LBU message is 206 received during the BCE preconfigured lifetime then the MAP SHOULD 207 delete it. 209 o When the MN gets a valid RtAdv message, it discovers that it has 210 entered an HMIPv6 domain. The following is based on the 211 assumption that the MN decides to use the MAP as its local Home 212 Agent, which means that the MN has to configure an RCoA then 213 request the MAP to create a BCE. For this purpose, the MN SHOULD 214 use the same method as the AR (described earlier) to autoconfigure 215 its RCoA and LCoA. After that, the MN initiates a Diffie-Hellman 216 (DH) procedure with the MAP by sending its DH public value (X) in 217 a new option (Session Mobility Secret (SMS)), which is carried by 218 the first LBU message sent to the MAP in order to request the MAP 219 to bind its LCoA to its new RCoA. The MN MUST protect the 220 integrity of the LBU message by including a keyed hash of the 221 message using Ks. The keyed hash is syntactically and 222 semantically similar to the Binding Authorization Data option 223 specified in [MIPv6]. 225 o Upon receiving an LBU message, the MAP searches its BCEs table for 226 an LCoA, which matches the one sent in the LBU message. If the 227 same LCoA is found, then the MAP computes the RCoA IID in the same 228 way as described above, and compares it to the one claimed by the 229 MN in the LBU message then it checks the authenticity of the 230 message. 231 If the LBU message is valid, then the MAP completes the DH 232 exchange by sending its own DH public value (Y) in a new option 233 (MAP Session Mobility Secret (MSMS)), which is carried by the BA 234 message sent to the MN. The MAP MUST protect the integrity of the 235 BA message by including a keyed hash of the message using Ks. The 236 keyed hash is syntactically and semantically similar to the 237 Binding Authorization Data option specified in [MIPv6]. 239 By sending (Y) to the MN, both nodes will be able to compute the 240 session mobility key (Ksm) (i.e., from values (X) and (Y)). 241 Note that if the RCoA address sent in the LBU message is not the 242 same as the one stored in the corresponding BCE then the MAP MUST 243 simply discard the LBU message. 245 o After sending the first BA message, the MAP SHOULD keep Ks and (Y) 246 in the MN's corresponding BCE until a new value of the binding 247 update sequence number is stored. This is needed in case the MN 248 goes out of reach for a short period of time and misses the first 249 BA message (i.e., (Y)), in which case it has to re-send the LBU 250 message. 252 o When the MN gets a BA message carrying a DH value, i.e., an SMS 253 option, it starts by checking its authenticity with Ks. If the 254 message is valid then the MN computes Ksm and establishes a 255 bidirectional SA with the MAP. 257 o By completing the DH procedure, both nodes will be able to compute 258 the session mobility key (Ksm) (i.e., from values (X) and (Y)) and 259 use it to authenticate subsequent LBU/BA messages exchanged 260 between them. 262 Note that the SA lifetime is set to 24 hours, after which the MN has 263 to request the MAP to renew it. 265 5. New Messages and Options Format 267 In the following, we describe the PBU message structure and the 268 format of the four new options. 270 5.1. The Pre-Binding Update (PBU) Message Format 272 When the AR receives a valid RtSol message signed with CGA, it sends 273 a PBU message to the MAP, which carries the MN's LCoA, RCoA and Ks. 275 The format of the PBU message is as follows: 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type | Code | Checksum | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Reserved | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | 285 + + 286 | | 287 + LCoA + 288 | | 289 + + 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | 293 + + 294 | | 295 + RCoA + 296 | | 297 + + 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 . Ks . 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Type 306 308 Code 0 310 Checksum 311 The ICMP checksum. For more details see [ICMPv6]. 313 Reserved 314 This field is unused. It MUST be initialized to zero by the sender 315 and MUST be ignored by the receiver. 317 LCoA 318 This field contains the MN's LCoA. 320 RCoA 321 This field contains the MN's RCoA. 323 Ks 324 The shared secret sent by the AR to the MN and to the MAP. 326 5.2. Third Party Shared Key (TPSK) Option 328 The Third Party Shared Key Option is carried by the unicast RtAdv 329 message sent by the AR to the MN, in response to a RtSol message 330 carrying a valid signature. The TPSK option MUST carry the shared 331 secret Ks. 333 When used, the TPSK option has the following format: 335 0 1 2 3 336 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Option Type | Option Length | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | | 341 . Option Data = Ks . 342 | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Option Type 346 348 Option Length 349 Length of the option. 351 Option Data 352 This field contains the shared secret Ks. 354 5.3. The MAP Session Mobility Secret (MSMS) Option 356 The MSS Option is used by the MAP to carry the DH public value (Y) 357 sent in the BA message, in response to the first LBU message carrying 358 an SMS option sent by the MN to the MAP. 360 Note that the first BA message sent by the MAP to the MN MUST be 361 authenticated with Ks. 363 The MSMS option has the following format: 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Option Type | Option Length | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | | 371 . Option Data = (Y) . 372 | | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Option Type 376 378 Option Length 379 Length of the option. 381 Option Data 382 The Option Data field contains the DH public value (Y) sent by the 383 MAP to the MN in the BA message. 385 5.4. The Session Mobility Secret (SMS) Option 387 The SMS option is carried by the first LBU message sent by the MN to 388 the MAP after receiving an unicast RtAdv message carrying a TPSK 389 option. The SMS option contains the DH public value (X) sent by the 390 MN to the MAP to initiate a DH exchange, which will allow both nodes 391 to compute a shared secret (Ksm). 392 Note that the first LBU message sent by the MN to the MAP MUST be 393 authenticated with Ks. 395 The SMS option has the following format: 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Option Type | Option Length | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | | 403 . Option Data = (X) . 404 | | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Option Type 408 410 Option Length 411 Length of the option. 413 Option Data 414 The Option Data field contains the DH public value (X) sent by the MN 415 to the MAP in the first LBU message. 417 6. IANA Considerations 419 This document introduces 3 new types of options and one new type of 420 message. The values of these types are 8-bit unsigned integers. 421 These values are allocated according to the Standards Actions or IESG 422 approval policies defined in [IANA]. 424 7. Security Considerations 426 This proposal suggests using the CGA technology to secure the 427 exchange between the MN and the AR as described in the SEND protocol, 428 to derive a first shared secret between the two entities and to use 429 it later to authenticate Diffie-Hellman messages exchanged between 430 the MN and the MAP. This is recommended due to the fact that public 431 key signature is a computationally expensive and lengthy procedure. 433 The suggested proposal does not create nor enhance any new and/or 434 existing threats. In particular, launching a man-in-the middle 435 attack against the MN is not possible because the attacker is not 436 aware of the shared secret Ks. 438 The proposal provides integrity protection by including a keyed hash 439 of the message. The proposal provides replay protection by using the 440 sequence number in the binding updates. The proposal does not 441 require the MAP to have prior knowledge of the MN's identity. 443 The suggested proposal DOES NOT guard against compromise of the 444 access router. If the access router is compromised it can act as a 445 man-in-the-middle for the MN-MAP exchange. But a compromised router 446 can do far worse things like null routing all the packets emanating 447 from the mobile node, or modify router advertisements to conceal the 448 presence of a HMIPv6 domain. We consider the AR compromise problem 449 to be orthogonal to the issues addressed in this draft. 451 8. Change Log 453 This document introduces the following changes from previous 454 versions: 456 - Remove the reliance on the crypto-based identifier (CBID) in order 457 to further simplify the protocol. 459 - Remove any new option from the RtSol message and adopt the same 460 format as used in SEND. 462 - Reduce the size of the PBU message by eliminating the need to send 463 the MN's CGA public key. 465 - Change the document title to reflect the new modifications. 467 - Correct few typos. 469 9. References 471 9.1. Normative References 473 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 474 RFC 3972, March 2005. 476 [HMIPv6] Soliman, H., Castelluccia, C., El Malki, K., and L. 477 Bellier, "Hierarchical Mobile IPv6 (HMIPv6)", Internet 478 Draft, draft-soliman-mipshop-4140bis-00.txt, June 2006. 480 [IANA] Narten, T. and H. Alverstrand, "Guidelines for Writing an 481 IANA Considerations Section in RFCs", RFC 2434, BCP 26, 482 October 1998. 484 [ICMPv6] Conta, A. and S. Deering, "Internet Control Message 485 Protocol (ICMPv6) for the Internet Protocol version 6 486 (IPv6) Specification", RFC 2463, July 2005. 488 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 489 in IPv6", RFC 3775, June 2004. 491 [SEND] Arkko, J., Kempf, J., Nikander, P., and B. Zill, "Secure 492 Neighbor Discovery (SEND)", RFC 3971, March 2005. 494 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 495 Requirement Levels", RFC 2119, BCP , March 1997. 497 9.2. Informative References 499 [FMIPkey] Kempf, J. and R. Koodli, "Bootstrapping a Symmetric IPv6 500 Key Handover Key from SEND", Internet 501 Draft, draft-kempf-mipshop-handover-key-00.txt, June 2006. 503 [FMIPv6] Koodli, R., "Fast Handovers for Mobile IPv6", Internet 504 Draft, draft-ietf-mipshop-fmipv6-rev-00.txt, April 2006. 506 [FRD] Choi, J., Chin, D., and W. Haddad, "Fast Router Discovery 507 with L2 Support", Internet 508 Draft, draft-ietf-dna-frd-01.txt, June 2006. 510 [OptiSEND] 511 Haddad, W., Krishnan, S., and J. Choi, "Secure Neighbor 512 Discovery (SEND) Optimization and Adaptation for Mobility: 513 The OptiSEND Protocol", Internet 514 Draft, draft-haddad-mipshop-optisend-01.txt, March 2006. 516 Authors' Addresses 518 Wassim Haddad 519 Ericsson Research 520 Torshamnsgatan 23 521 SE-164 80 Stockholm 522 Sweden 524 Phone: +46 8 4044079 525 Email: Wassim.Haddad@ericsson.com 527 Suresh Krishnan 528 Ericsson Research 529 8400 Decarie Blvd. 530 Town of Mount Royal, QC 531 Canada 533 Phone: +1 514 345 7900 534 Email: Suresh.Krishnan@ericsson.com 536 Hesham Soliman 537 Qualcomm-Flarion 539 Phone: +1 908 997 9775 540 Email: hsoliman@qualcomm.com 542 Intellectual Property Statement 544 The IETF takes no position regarding the validity or scope of any 545 Intellectual Property Rights or other rights that might be claimed to 546 pertain to the implementation or use of the technology described in 547 this document or the extent to which any license under such rights 548 might or might not be available; nor does it represent that it has 549 made any independent effort to identify any such rights. Information 550 on the procedures with respect to rights in RFC documents can be 551 found in BCP 78 and BCP 79. 553 Copies of IPR disclosures made to the IETF Secretariat and any 554 assurances of licenses to be made available, or the result of an 555 attempt made to obtain a general license or permission for the use of 556 such proprietary rights by implementers or users of this 557 specification can be obtained from the IETF on-line IPR repository at 558 http://www.ietf.org/ipr. 560 The IETF invites any interested party to bring to its attention any 561 copyrights, patents or patent applications, or other proprietary 562 rights that may cover technology that may be required to implement 563 this standard. Please address the information to the IETF at 564 ietf-ipr@ietf.org. 566 Disclaimer of Validity 568 This document and the information contained herein are provided on an 569 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 570 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 571 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 572 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 573 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 574 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 576 Copyright Statement 578 Copyright (C) The Internet Society (2006). This document is subject 579 to the rights, licenses and restrictions contained in BCP 78, and 580 except as set forth therein, the authors retain all their rights. 582 Acknowledgment 584 Funding for the RFC Editor function is currently provided by the 585 Internet Society.