idnits 2.17.1 draft-dupont-mext-dhaadharmful-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 401. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 414. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (June 3, 2008) is 5804 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-hokey-key-mgm-03 == Outdated reference: A later version (-18) exists of draft-ietf-mip6-hiopt-17 ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-05) exists of draft-ietf-mipshop-4140bis-02 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 mext Working Group F. Dupont 3 Internet-Draft ISC 4 Intended status: Informational J-M. Combes 5 Expires: December 5, 2008 Orange Labs R&D 6 M. Laurent-Maknavicius 7 Telecom SudParis 8 June 3, 2008 10 Dynamic Home Agent Address Discovery (DHAAD) Considered Harmful 11 draft-dupont-mext-dhaadharmful-00.txt 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 December 5, 2008. 38 Abstract 40 The Dynamic Home Agent Address Discovery (DHAAD) mechanism is 41 described in the Mobile IPv6 specification. This mechanism is 42 mandatory in any compliant Mobile IPv6 implementation and so in any 43 MIPv6 based protocols too. On the other hand, DHAAD was the only one 44 mechanism to discover a potential Home Agent for a Mobile Node in the 45 past. This is no longer the case today. This document analyzes the 46 security of the different existing home agent discovery mechanisms 47 and promotes the remove of DHAAD from the future Mobile IPv6 48 standard, in light of this security analysis. 50 1. Introduction 52 Mobile IPv6 specifications [RFC3775] contains a mechanism where a 53 Home Agent can help a Mobile Node to discover the addresses of the 54 Home Agents named the Dynamic Home Agent Address Discovery (DHAAD). 56 Each Home Agent maintains a separate data structure, the Home Agents 57 List, for each link on which it is serving as a Home Agent and sends 58 modified Router Advertisement messages including a Home Agent 59 Information option to update the Home Agents List of the other Home 60 Agents. 62 This mechanism uses two ICMP message types: 63 o Home Agent Address Discovery Requests which are sent by Mobile 64 Nodes to the Home Agents anycast addresses for their home subnet 65 prefixes. 66 o Home Agent Address Discovery Replies which are sent by Home Agents 67 in response and contain the information from the Home Agents List. 68 A 16-bit identifier aids in matching requests and replies. 70 This document analyzes the security in DHAAD and compares it to the 71 other existing mechanisms [RFC5026] 72 [I-D.ietf-mip6-bootstrapping-integrated-dhc]. This analysis mainly 73 focuses on the Home Agent discovery part in the MIPv6 bootstrapping 74 process. Results apply to other MIPv6 based protocols (e.g., NEMO 75 [RFC3963], HMIPv6 [I-D.ietf-mipshop-4140bis], PMIPv6 76 [I-D.ietf-netlmm-proxymip6]) because DHAAD is mandatory in any 77 compliant MIPv6 implementation. 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 The bootstrapping terminology is copied from the Problem Statement 84 for Bootstrapping Mobile IPv6 document [RFC4640]. 86 2. Mobility Service Provider (MSP) side 88 This section analyzes the security from the MSP point of view. 90 As the Home Agent is a well-known point of failure in IPv6 mobility 91 based protocols, learning easily the exact location of the Home 92 Agents may increase the efficiency of DoS attacks against IPv6 93 mobility based services. 95 A solution is to allow the MSP to check that the request comes from a 96 legitimate Mobile Node (i.e., one granted to access to the mobility 97 service). 99 2.1. DHAAD 101 Currently, there is no standardized solution to secure the DHAAD 102 request. As the destination address in this request is an anycast 103 address (i.e., the Mobile IPv6 Home-Agents anycast address), IKE 104 [RFC2409] [RFC4306] cannot be used. To use IPsec [RFC4301], IPsec 105 Security Associations have to be set up manually what is generally 106 not recommended, from a security point of view. 108 So, today, DHAAD requests cannot be authenticated and anyone can 109 access to the MSP's Home Agents list. 111 2.2. Split scenario mechanism 113 In this mechanism, the Home Agent discovery is based on a DNS lookup, 114 by Home Agent name or by service name. As the DNS service is a 115 public service, anyone can access to the information stored in the 116 DNS. 118 So, today, the split scenario mechanism doesn't allow the MSP to 119 check the identity of the requester and anyone can access to the 120 MSP's Home Agents list. 122 2.3. Integrated scenario mechanism 124 In this mechanism, the Home Agent discovery is based on DHCPv6 in 125 using new options [I-D.ietf-mip6-hiopt]. The DHCPv6 server is 126 located in the Access Service Provider (ASP) network. As prior to 127 the Home Agent discovery, the Mobile Node had executed a network 128 access authentication procedure, the ASP is aware whether the Mobile 129 Node is legitimate or not. The DHCP request sent by the Mobile Node 130 may be secured, either in using a network access secure protocol 131 (e.g., 802.1X) or in using authentication for DHCP [RFC3118] in the 132 case the NAS is collocated with the DHCP server, under the condition 133 that the needed shared key is derived from the authentication process 134 (e.g., Usage Specific Root Keys [I-D.ietf-hokey-key-mgm]). 136 So, today, in the integrated scenario mechanism, it is possible for 137 the MSP/ASP to check the identity of the requester. 139 3. Mobile Node (MN) side 141 This section analyzes the security from the MN point of view. 143 As the knowledge of a Home Agent for the Mobile Node is critical for 144 the IPv6 mobility protocols, sending erroneous information may cause 145 DoS attacks in blocking IPv6 mobility based services. 147 A solution is to allow the Mobile Node to check the integrity of the 148 information it received and this last one comes from the right 149 entity. 151 3.1. DHAAD 153 As explained previously in Section 2.1, IPsec is not well adapted to 154 secure the DHAAD mechanism. 156 The consequence is that today DHAAD replies cannot be authenticated 157 by the Mobile Node and nothing prevents a malicious node to intercept 158 and modify the information in the replies. 160 3.2. Split scenario mechanism 162 As explained in Section 2.2, the mechanism is based on DNS and so 163 DNSSEC [RFC4033] may be used to ensure the Mobile Node received the 164 requested resource records signed by an authoritative DNS server. 166 So, today, it is possible for the Mobile Node to authenticate the 167 content of replies from the DNS server. 169 3.3. Integrated scenario mechanism 171 As explained in Section 2.3, security may be set up between the ASP 172 and the Mobile Node. 174 The consequence is that is possible for the Mobile Node to check that 175 the integrity of the information he received and this one comes from 176 the right DHCP server. 178 4. Validity of the information 180 Another important point is the validity of the information delivered 181 to the Mobile Node. 183 4.1. DHAAD 185 The Home Agents List is updated in using the Router Advertisement 186 (RA) messages sent by the other home agents in a same link. A 187 malicious node, on this link, may sent incorrect RA messages and so 188 it can poison this list with incorrect information. 190 A deployement of Secure Neighbor Discovery (SEND) [RFC3971] may 191 mitigate this attack: the malicious node must now be a legitimate 192 router to still launch the attack. Unfortunately, this is specially 193 the case when DHAAD is used with NEMO. Any malicious Mobile Router 194 may have the correct certificates to send authenticated RA but SEND 195 doesn't cover the information regarding the Home Agent functionality 196 in the RA messages and so the attack is still valid. 198 The consequence is the information concerning the Home Agents List, 199 when using DHAAD mechanism, is not reliable. 201 4.2. Split scenario mechanism 203 The list of the Home Agents administrated by a MSP is stored in DNS 204 servers. To be corrupted, a bad guy must have the authorization to 205 modify data in the DNS server. This may be secured in using TSIG or 206 SIG(0) as explained in the Secure Domain Name System (DNS) Dynamic 207 Update document [RFC3007]. 209 So, it is possible to guarantee the validity of the information 210 regarding the Home Agents List. 212 4.3. Integrated scenario mechanism 214 Most of the time, the list of the Home Agents administrated by a MSP 215 is configured manually in AAA or DHCP servers. 217 So, it is possible to guarantee the validity of the information 218 regarding the Home Agents List. 220 5. ICMP issue 222 Specification of ICMP to carry DHAAD incurs a certain deployability 223 risk. Many ISPs are blocking ICMP on all links except the first hop, 224 because ICMP is known to be a vehicle for DoS attacks and other sorts 225 of threats. It is theoretically possible to block ICMP types 226 selectively, and therefore it would be possible to allow DHAAD 227 messages through firewalls and still block other DHAAD messages 228 suspected to be an attack. However, because DHAAD is initiated from 229 outside the firewall, the risk of a crude flooding DoS attack is 230 unchanged since the firewall must allow any DHAAD message through. 231 The ISP could deploy some kind of authentication mechanism to 232 validate that a DHAAD message comes from an authorized user before 233 letting it through, but such sophisticated authentication is beyond 234 current practice, and the advantages of deploying such a mechanism 235 specifically for DHAAD are uncertain. It is easier from a network 236 management standpoint to simply uniformly block ICMP except on the 237 last hop. 239 6. IANA Considerations 241 This document makes no request of IANA. 243 Note to RFC Editor: this section may be removed on publication as an 244 RFC. 246 7. Security Considerations 248 This documents analyzes, from a security point of view, the different 249 existing home agent discovery mechanisms. 251 As DHAAD is insecure today and, on the other hand, the split and the 252 integrated scenario mechanisms allow to set up a minimum of security, 253 the document recommends to remove DHAAD mechanism from the future 254 standard Mobile IPv6, and, if still considered as useful, to define 255 it in a separate document. 257 8. Acknowledgments 259 The authors of the split scenario mechanism and the integrated 260 scenario mechanism have done the hard work and should get all the 261 credits. 263 Nicolas Montavont proposed to extend the document to NEMO. 265 James Kempf is the author of Section 5. 267 Maryline Maknavicius-Laurent and Jean-Michel Combes are partly funded 268 by MobiSEND, a research project supported by the French 'National 269 Research Agency' (ANR). 271 9. References 273 9.1. Normative References 275 [I-D.ietf-hokey-key-mgm] 276 Nakhjiri, M. and Y. Ohba, "Derivation, delivery and 277 management of EAP based keys for handover and re- 278 authentication", draft-ietf-hokey-key-mgm-03 (work in 279 progress), February 2008. 281 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 282 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 283 Integrated Scenario", 284 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 285 progress), April 2008. 287 [I-D.ietf-mip6-hiopt] 288 Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP 289 Options for Home Information Discovery in MIPv6", 290 draft-ietf-mip6-hiopt-17 (work in progress), May 2008. 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", RFC 2119, BCP 14, March 1997. 295 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 296 (IKE)", RFC 2409, November 1998. 298 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 299 in IPv6", RFC 3775, June 2004. 301 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 302 Internet Protocol", RFC 4301, December 2005. 304 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 305 Protocol", RFC 4306, December 2005. 307 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 308 Bootstrapping in Split Scenario", RFC 5026, October 2007. 310 9.2. Informative References 312 [I-D.ietf-mipshop-4140bis] 313 Soliman, H., Castelluccia, C., El Malki, K., and L. 314 Bellier, "Hierarchical Mobile IPv6 Mobility Management 315 (HMIPv6)", draft-ietf-mipshop-4140bis-02 (work in 316 progress), April 2008. 318 [I-D.ietf-netlmm-proxymip6] 319 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 320 and B. Patil, "Proxy Mobile IPv6", 321 draft-ietf-netlmm-proxymip6-18 (work in progress), 322 May 2008. 324 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 325 Update", RFC 3007, November 2000. 327 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 328 Messages", RFC 3118, June 2001. 330 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 331 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 332 RFC 3963, January 2005. 334 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 335 Neighbor Discovery (SEND)", RFC 3971, March 2005. 337 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 338 Rose, "DNS Security Introduction and Requirements", 339 RFC 4033, March 2005. 341 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 342 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, 343 September 2006. 345 Appendix A. Changes from the previous versions 347 To be removed prior to publication as an RFC. 349 Previous version: draft-dupont-mip6-dhaadharmful-01 351 Reorganization of the document around the different existing Home 352 Agent discovery mechanisms. 354 Authors' Addresses 356 Francis Dupont 357 ISC 359 Email: Francis.Dupont@fdupont.fr 361 Jean-Michel Combes 362 Orange Labs R&D 363 38 rue du General Leclerc 364 92794 Issy-les-Moulineaux Cedex 9 365 France 367 Email: jeanmichel.combes@gmail.com 368 Maryline Laurent-Maknavicius 369 Telecom SudParis 370 9 rue Charles Fourier 371 91011 Evry 372 France 374 Email: Maryline.Maknavicius@it-sudparis.eu 376 Full Copyright Statement 378 Copyright (C) The IETF Trust (2008). 380 This document is subject to the rights, licenses and restrictions 381 contained in BCP 78, and except as set forth therein, the authors 382 retain all their rights. 384 This document and the information contained herein are provided on an 385 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 386 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 387 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 388 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 389 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 390 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 392 Intellectual Property 394 The IETF takes no position regarding the validity or scope of any 395 Intellectual Property Rights or other rights that might be claimed to 396 pertain to the implementation or use of the technology described in 397 this document or the extent to which any license under such rights 398 might or might not be available; nor does it represent that it has 399 made any independent effort to identify any such rights. Information 400 on the procedures with respect to rights in RFC documents can be 401 found in BCP 78 and BCP 79. 403 Copies of IPR disclosures made to the IETF Secretariat and any 404 assurances of licenses to be made available, or the result of an 405 attempt made to obtain a general license or permission for the use of 406 such proprietary rights by implementers or users of this 407 specification can be obtained from the IETF on-line IPR repository at 408 http://www.ietf.org/ipr. 410 The IETF invites any interested party to bring to its attention any 411 copyrights, patents or patent applications, or other proprietary 412 rights that may cover technology that may be required to implement 413 this standard. Please address the information to the IETF at 414 ietf-ipr@ietf.org.