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]