mext Working Group F. Dupont Internet-Draft ISC Intended status: Informational J-M. Combes Expires: December 5, 2008 Orange Labs R&D M. Laurent-Maknavicius Telecom SudParis June 3, 2008 Dynamic Home Agent Address Discovery (DHAAD) Considered Harmful draft-dupont-mext-dhaadharmful-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 5, 2008. Abstract The Dynamic Home Agent Address Discovery (DHAAD) mechanism is described in the Mobile IPv6 specification. This mechanism is mandatory in any compliant Mobile IPv6 implementation and so in any MIPv6 based protocols too. On the other hand, DHAAD was the only one mechanism to discover a potential Home Agent for a Mobile Node in the past. This is no longer the case today. This document analyzes the security of the different existing home agent discovery mechanisms and promotes the remove of DHAAD from the future Mobile IPv6 standard, in light of this security analysis. Dupont, et al. Expires December 5, 2008 [Page 1] Internet-Draft DHAAD Considered Harmful June 2008 1. Introduction Mobile IPv6 specifications [RFC3775] contains a mechanism where a Home Agent can help a Mobile Node to discover the addresses of the Home Agents named the Dynamic Home Agent Address Discovery (DHAAD). Each Home Agent maintains a separate data structure, the Home Agents List, for each link on which it is serving as a Home Agent and sends modified Router Advertisement messages including a Home Agent Information option to update the Home Agents List of the other Home Agents. This mechanism uses two ICMP message types: o Home Agent Address Discovery Requests which are sent by Mobile Nodes to the Home Agents anycast addresses for their home subnet prefixes. o Home Agent Address Discovery Replies which are sent by Home Agents in response and contain the information from the Home Agents List. A 16-bit identifier aids in matching requests and replies. This document analyzes the security in DHAAD and compares it to the other existing mechanisms [RFC5026] [I-D.ietf-mip6-bootstrapping-integrated-dhc]. This analysis mainly focuses on the Home Agent discovery part in the MIPv6 bootstrapping process. Results apply to other MIPv6 based protocols (e.g., NEMO [RFC3963], HMIPv6 [I-D.ietf-mipshop-4140bis], PMIPv6 [I-D.ietf-netlmm-proxymip6]) because DHAAD is mandatory in any compliant MIPv6 implementation. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The bootstrapping terminology is copied from the Problem Statement for Bootstrapping Mobile IPv6 document [RFC4640]. 2. Mobility Service Provider (MSP) side This section analyzes the security from the MSP point of view. As the Home Agent is a well-known point of failure in IPv6 mobility based protocols, learning easily the exact location of the Home Agents may increase the efficiency of DoS attacks against IPv6 mobility based services. A solution is to allow the MSP to check that the request comes from a legitimate Mobile Node (i.e., one granted to access to the mobility Dupont, et al. Expires December 5, 2008 [Page 2] Internet-Draft DHAAD Considered Harmful June 2008 service). 2.1. DHAAD Currently, there is no standardized solution to secure the DHAAD request. As the destination address in this request is an anycast address (i.e., the Mobile IPv6 Home-Agents anycast address), IKE [RFC2409] [RFC4306] cannot be used. To use IPsec [RFC4301], IPsec Security Associations have to be set up manually what is generally not recommended, from a security point of view. So, today, DHAAD requests cannot be authenticated and anyone can access to the MSP's Home Agents list. 2.2. Split scenario mechanism In this mechanism, the Home Agent discovery is based on a DNS lookup, by Home Agent name or by service name. As the DNS service is a public service, anyone can access to the information stored in the DNS. So, today, the split scenario mechanism doesn't allow the MSP to check the identity of the requester and anyone can access to the MSP's Home Agents list. 2.3. Integrated scenario mechanism In this mechanism, the Home Agent discovery is based on DHCPv6 in using new options [I-D.ietf-mip6-hiopt]. The DHCPv6 server is located in the Access Service Provider (ASP) network. As prior to the Home Agent discovery, the Mobile Node had executed a network access authentication procedure, the ASP is aware whether the Mobile Node is legitimate or not. The DHCP request sent by the Mobile Node may be secured, either in using a network access secure protocol (e.g., 802.1X) or in using authentication for DHCP [RFC3118] in the case the NAS is collocated with the DHCP server, under the condition that the needed shared key is derived from the authentication process (e.g., Usage Specific Root Keys [I-D.ietf-hokey-key-mgm]). So, today, in the integrated scenario mechanism, it is possible for the MSP/ASP to check the identity of the requester. 3. Mobile Node (MN) side This section analyzes the security from the MN point of view. As the knowledge of a Home Agent for the Mobile Node is critical for Dupont, et al. Expires December 5, 2008 [Page 3] Internet-Draft DHAAD Considered Harmful June 2008 the IPv6 mobility protocols, sending erroneous information may cause DoS attacks in blocking IPv6 mobility based services. A solution is to allow the Mobile Node to check the integrity of the information it received and this last one comes from the right entity. 3.1. DHAAD As explained previously in Section 2.1, IPsec is not well adapted to secure the DHAAD mechanism. The consequence is that today DHAAD replies cannot be authenticated by the Mobile Node and nothing prevents a malicious node to intercept and modify the information in the replies. 3.2. Split scenario mechanism As explained in Section 2.2, the mechanism is based on DNS and so DNSSEC [RFC4033] may be used to ensure the Mobile Node received the requested resource records signed by an authoritative DNS server. So, today, it is possible for the Mobile Node to authenticate the content of replies from the DNS server. 3.3. Integrated scenario mechanism As explained in Section 2.3, security may be set up between the ASP and the Mobile Node. The consequence is that is possible for the Mobile Node to check that the integrity of the information he received and this one comes from the right DHCP server. 4. Validity of the information Another important point is the validity of the information delivered to the Mobile Node. 4.1. DHAAD The Home Agents List is updated in using the Router Advertisement (RA) messages sent by the other home agents in a same link. A malicious node, on this link, may sent incorrect RA messages and so it can poison this list with incorrect information. A deployement of Secure Neighbor Discovery (SEND) [RFC3971] may Dupont, et al. Expires December 5, 2008 [Page 4] Internet-Draft DHAAD Considered Harmful June 2008 mitigate this attack: the malicious node must now be a legitimate router to still launch the attack. Unfortunately, this is specially the case when DHAAD is used with NEMO. Any malicious Mobile Router may have the correct certificates to send authenticated RA but SEND doesn't cover the information regarding the Home Agent functionality in the RA messages and so the attack is still valid. The consequence is the information concerning the Home Agents List, when using DHAAD mechanism, is not reliable. 4.2. Split scenario mechanism The list of the Home Agents administrated by a MSP is stored in DNS servers. To be corrupted, a bad guy must have the authorization to modify data in the DNS server. This may be secured in using TSIG or SIG(0) as explained in the Secure Domain Name System (DNS) Dynamic Update document [RFC3007]. So, it is possible to guarantee the validity of the information regarding the Home Agents List. 4.3. Integrated scenario mechanism Most of the time, the list of the Home Agents administrated by a MSP is configured manually in AAA or DHCP servers. So, it is possible to guarantee the validity of the information regarding the Home Agents List. 5. ICMP issue Specification of ICMP to carry DHAAD incurs a certain deployability risk. Many ISPs are blocking ICMP on all links except the first hop, because ICMP is known to be a vehicle for DoS attacks and other sorts of threats. It is theoretically possible to block ICMP types selectively, and therefore it would be possible to allow DHAAD messages through firewalls and still block other DHAAD messages suspected to be an attack. However, because DHAAD is initiated from outside the firewall, the risk of a crude flooding DoS attack is unchanged since the firewall must allow any DHAAD message through. The ISP could deploy some kind of authentication mechanism to validate that a DHAAD message comes from an authorized user before letting it through, but such sophisticated authentication is beyond current practice, and the advantages of deploying such a mechanism specifically for DHAAD are uncertain. It is easier from a network management standpoint to simply uniformly block ICMP except on the last hop. Dupont, et al. Expires December 5, 2008 [Page 5] Internet-Draft DHAAD Considered Harmful June 2008 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations This documents analyzes, from a security point of view, the different existing home agent discovery mechanisms. As DHAAD is insecure today and, on the other hand, the split and the integrated scenario mechanisms allow to set up a minimum of security, the document recommends to remove DHAAD mechanism from the future standard Mobile IPv6, and, if still considered as useful, to define it in a separate document. 8. Acknowledgments The authors of the split scenario mechanism and the integrated scenario mechanism have done the hard work and should get all the credits. Nicolas Montavont proposed to extend the document to NEMO. James Kempf is the author of Section 5. Maryline Maknavicius-Laurent and Jean-Michel Combes are partly funded by MobiSEND, a research project supported by the French 'National Research Agency' (ANR). 9. References 9.1. Normative References [I-D.ietf-hokey-key-mgm] Nakhjiri, M. and Y. Ohba, "Derivation, delivery and management of EAP based keys for handover and re- authentication", draft-ietf-hokey-key-mgm-03 (work in progress), February 2008. [I-D.ietf-mip6-bootstrapping-integrated-dhc] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Dupont, et al. Expires December 5, 2008 [Page 6] Internet-Draft DHAAD Considered Harmful June 2008 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in progress), April 2008. [I-D.ietf-mip6-hiopt] Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP Options for Home Information Discovery in MIPv6", draft-ietf-mip6-hiopt-17 (work in progress), May 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007. 9.2. Informative References [I-D.ietf-mipshop-4140bis] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", draft-ietf-mipshop-4140bis-02 (work in progress), April 2008. [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-18 (work in progress), May 2008. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", Dupont, et al. Expires December 5, 2008 [Page 7] Internet-Draft DHAAD Considered Harmful June 2008 RFC 3963, January 2005. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006. Appendix A. Changes from the previous versions To be removed prior to publication as an RFC. Previous version: draft-dupont-mip6-dhaadharmful-01 Reorganization of the document around the different existing Home Agent discovery mechanisms. Authors' Addresses Francis Dupont ISC Email: Francis.Dupont@fdupont.fr Jean-Michel Combes Orange Labs R&D 38 rue du General Leclerc 92794 Issy-les-Moulineaux Cedex 9 France Email: jeanmichel.combes@gmail.com Dupont, et al. Expires December 5, 2008 [Page 8] Internet-Draft DHAAD Considered Harmful June 2008 Maryline Laurent-Maknavicius Telecom SudParis 9 rue Charles Fourier 91011 Evry France Email: Maryline.Maknavicius@it-sudparis.eu Dupont, et al. Expires December 5, 2008 [Page 9] Internet-Draft DHAAD Considered Harmful June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Dupont, et al. Expires December 5, 2008 [Page 10]