One document matched: draft-dupont-mext-dhaadharmful-00.txt

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]