Internet DRAFT - draft-dupont-mip6-dhaadharmful
draft-dupont-mip6-dhaadharmful
Network Working Group F. Dupont, Ed.
Internet-Draft Point6
Expires: April 24, 2006 October 21, 2005
Dynamic Home Agent Address Discovery (DHAAD) Considered Harmful
draft-dupont-mip6-dhaadharmful-01.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 April 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Dynamic Home Agent Address Discovery (DHAAD) mechanism of Mobile IPv6
is nearly impossible to make secure. As the service itself is
useful, this document shows the security problems of the current
mechanism and promotes an alternative solution.
1. Introduction
Mobile IPv6 specifications [RFC3775] contains a mechanism where a
Dupont Expires April 24, 2006 [Page 1]
Internet-Draft DHAAD Considered Harmful October 2005
home agent can help mobile nodes to discover the addresses of the
home agents named the Dynamic Home Agent Address Discovery (DHAAD).
This mechanism uses two ICMP message types:
Home Agent Address Discovery Requests which are sent by mobile
nodes to the Home Agents anycast addresses for their home subnet
prefixes.
Home Agent Address Discovery Replies which are sent by home agents
in response.
A 16-bit identifier aids in matching requests and replies.
The main security issue is in the anycast destination of requests,
and as the mechanism is the first step of bootstrapping, there is no
way to add reasonable security to it.
So a solution is to change for a completely different mechanism
providing the same service. One is developed in the Mobile IPv6
bootstrapping framework [ID-mip6-bootsplit]: it is based on the
"Microsoft-style" for service discovery: DNS SRV Resource Records
[RFC2782].
Security is provided by the DNSSEC [RFC4033] framework. The needed
pre-configured data on the mobile node for this mechanism is the
domain name of the mobile service provider, which marginally better
than the home subnet prefix. For the security, a trust anchor which
dominates the domain is needed.
The mechanism can be extended to the Network Mobility (NEMO
[RFC3963]) with "nemo" as the service name.
2. 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 those DHAAD messages that
are a known threat. 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 Expires April 24, 2006 [Page 2]
Internet-Draft DHAAD Considered Harmful October 2005
3. Security Considerations
Securing the current DHAAD mechanism is a hopeless task. The DNS SRV
RR mechanism is already heavily used for service discovery and the
standard way to make it secure is well known even not yet deployed in
a large scale.
4. Acknowledgments
The authors of [ID-mip6-bootsplit] have done the hard work and should
get all the credits. Many early Mobile IPv6 operators pointed out
that the current DHAAD mechanism does not provide a reasonable level
of security.
Nicolas Montavont proposed to extend the document to NEMO.
James Kempf is the author of the Section 2 "ICMP issue".
5. References
5.1. Normative References
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
5.2. Informative References
[ID-mip6-bootsplit]
Giaretta, G., Ed., Kempf, J., and V. Devarapalli, "Mobile
IPv6 bootstrapping in split scenario",
draft-ietf-mip6-bootstrapping-split-00.txt (work in
progress), June 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
Dupont Expires April 24, 2006 [Page 3]
Internet-Draft DHAAD Considered Harmful October 2005
Appendix A. The new DHAAD mechanism
The text of this annex is from [ID-mip6-bootsplit].
A.1. Component of the solution
HA address discovery. The Mobile Node needs to discover the address
of its Home Agent. The main objective of a bootstrapping solution is
to minimize the data pre-configured on the Mobile Node. For this
reason, the DHAAD defined in [RFC3775] may not be applicable in real
deployments since it is required that the Mobile Node is pre-
configured with the home network prefix and it does not allow an
operator to load balance by having Mobile Nodes dynamically assigned
to Home Agents located in different subnets. This document defines a
solution for Home Agent address discovery that is based on Domain
Name Service (DNS), introducing a new DNS SRV record [RFC2782]. The
unique information that needs to be pre- configured on the Mobile
Node is the domain name of the MSP.
A.2. Home Agent Address Discovery
Once a Mobile Node has obtained network access, it can perform Mobile
IPv6 bootstrapping. For this purpose, the Mobile Node queries the
DNS server to request information on Home Agent service. As
mentioned before in the document, the only information that needs to
be auto- configured on the Mobile Node is the domain name of the
Mobility Service Provider.
The Mobile Node needs to obtain the IP address of the DNS server
before it can send a DNS request. This can be pre-configured on the
Mobile Node or obtained through DHCPv6 from the visited link. In any
case, it is assumed that there is some kind of mechanism by which the
Mobile Node is configured with a DNS server since a DNS server is
needed for many other reasons.
Two options for DNS lookup for a Home Agent address are identified in
this document: DNS lookup by Home Agent Name and DNS lookup by
service name.
While this document specifies a Home Agent Address Discovery solution
based on DNS, when the ASP and the MSP are the same entity DHCP may
be used. See "DCHPv6 option for home agent discovery in MIPv6" for
details.
A.2.1. DNS lookup by Home Agent Name
In this case, the Mobile Node is configured with the Fully Qualified
Domain Name of the Home Agent. As an example, the Mobile Node could
Dupont Expires April 24, 2006 [Page 4]
Internet-Draft DHAAD Considered Harmful October 2005
be configured with the name "ha1.example.com", where "example.com" is
the domain name of the MSP granting the mobility service.
The Mobile Node constructs a DNS request, by setting the QNAME to the
name of the Home Agent. The request has QTYPE set to 'AAAA', so that
the DNS server sends the IPv6 address of the Home Agent. Once the
DNS server replies to this query, the Mobile Node knows its Home
Agent address and can run IKEv2 in order to set up an IPsec SA and
get a Home Address.
Additionally, it could be useful to provide an ability for the Mobile
Node to discover a Home Agent placed in a particular location (e.g.
on the visited link). In order to achieve this, the Mobile Node must
be able to construct a DNS request such that the DNS server will be
able to reply with a Home Agent from the requested location. This
can be accomplished by using a specific naming convention for the
FQDNs of the Home Agents. As an example, an operator might assign
the FQDN "ha.locationA.operator.com" to the Home Agent located in
"location A" and the FQDN "ha.locationB.operator.com" to the Home
Agent located in "location B". If the Mobile Node wants to use a
Home Agent located in "location A", it will set the QNAME to
"ha.locationA.operator.com" in the DNS request.
A.2.2. DNS lookup by service name
[RFC2782] defines the service resource record (SRV RR), that allows
an operator to use several servers for a single domain, to move
services from host to host, and to designate some hosts as primary
servers for a service and others as backups. Clients ask for a
specific service/protocol for a specific domain and get back the
names of any available servers.
[RFC2782] describes also the policies to choose a service agent based
on the preference and weight values. The DNS SRV record may contain
the preference and weight values for multiple Home Agents available
to the Mobile Node in addition to the Home Agent FQDNs. If multiple
Home Agents are available in the DNS SRV record then Mobile Node is
responsible for processing the information as per policy and for
picking one Home Agent. If the Home Agent of choice does not respond
for some reason or the IKEv2 authentication fails, the Mobile Node
SHOULD try other Home Agents on the list.
The service name for Mobile IPv6 Home Agent service as required by
[RFC2782] is "mip6" and the protocol name is "ipv6". Note that a
transport name cannot be used here because Mobile IPv6 does not run
over a transport protocol.
The SRV RR has a DNS type code of 33. As an example, the Mobile
Dupont Expires April 24, 2006 [Page 5]
Internet-Draft DHAAD Considered Harmful October 2005
constructs a request with QNAME set to "mip6.example.com" and QTYPE
to SRV. The reply contains the FQDNs of one or more servers, that
can then be resolved in a separate DNS transaction to the IP
addresses. However, it is RECOMMENDED that the DNS server also
return the IP addresses of the Home Agents in AAAA records as part of
the additional data section in order to avoid requiring an additional
DNS round trip to resolve the FQDNs, if there is room in the SRV
reply.
A.3. HA Address Discovery Security
Use of DNS for address discovery carries certain security risks. DNS
transactions in the Internet are typically done without any
authentication of the DNS server by the client or of the client by
the server. There are two risks involved:
1) A legitimate client obtains a bogus Home Agent address from a
bogus DNS server. This is sometimes called a "pharming" attack,
2) An attacking client obtains a legitimate Home Agent address from a
legitimate server.
The risk in Case 1 is mitigated because the Mobile Node is required
to conduct an IKE transaction with the Home Agent prior to performing
a Binding Update to establish Mobile IPv6 service. According to the
IKEv2 specification, the responder must present the initiator with a
valid certificate containing the responder's public key, and the
responder to initiator IKE_AUTH message must be protected with an
authenticator calculated using the public key in the certificate.
Thus, an attacker would have to set up both a bogus DNS server and a
bogus Home Agent, and provision the Home Agent with a certificate
that a victim Mobile Node could verify. If the Mobile Node can
detect that the certificate is not trustworthy, the attack will be
foiled when the Mobile Node attempts to set up the IKE SA.
The risk in Case 2 is limited for a single Mobile Node to Home Agent
transaction if the attacker does not possess proper credentials to
authenticate with the Home Agent. The IKE SA establishment will fail
when the attacking Mobile Node attempts to authenticate itself with
the Home Agent. Regardless of whether the Home Agent utilizes EAP or
host-side certificates to authenticate the Mobile Node, the
authentication will fail unless the Mobile Node has valid
credentials.
Another risk exists in Case 2 because the attacker may be attempting
to propagate a DoS attack on the Home Agent. In that case, the
attacker obtains the Home Agent address from the DNS, then propagates
the address to a network of attacking hosts that bombard the Home
Dupont Expires April 24, 2006 [Page 6]
Internet-Draft DHAAD Considered Harmful October 2005
Agent with traffic. This attack is not unique to the bootstrapping
solution, however, it is actually a risk that any Mobile IPv6 Home
Agent installation faces. In fact, the risk is faced by any service
in the Internet that distributes a unicast globally routable address
to clients. Since Mobile IPv6 requires that the Mobile Node
communicate through a globally routable unicast address of a Home
Agent, it is possible that the Home Agent address could be propagated
to an attacker by various means (theft of the Mobile Node, malware
installed on the Mobile Node, evil intent of the Mobile Node owner
him/herself, etc.) even if the home address is manually configured on
the Mobile Node. Consequently, every Mobile IPv6 Home Agent
installation will likely be required to mount anti-DoS measures.
Such measures include overprovisioning of links to and from Home
Agents and of Home Agent processing capacity, vigilant monitoring of
traffic on the Home Agent networks to detect when traffic volume
increases abnormally indicating a possible DoS attack, and hot spares
that can quickly be switched on in the event an attack is mounted on
an operating collection of Home Agents. DoS attacks of moderate
intensity should be foiled during the IKEv2 transaction. IKEv2
implementations are expected to generate their cookies without any
saved state, and to time out cookie generation parameters frequently,
with the timeout value increasing if a DoS attack is suspected. This
should prevent state depletion attacks, and should assure continued
service to legitimate clients until the practical limits on the
network bandwith and processing capacity of the Home Agent network
are reached.
Explicit security measures between the DNS server and host, such
DNSSEC or TSIG/TKEY can mitigate the risk of 1) and 2), but these
security measures are not widely deployed on end nodes. These
security measures are not sufficient to protect the Home Agent
address against DoS attack, however, because a node having a
legitimate security association with the DNS server could
nevertheless intentionally or inadvertently cause the Home Agent
address to become the target of DoS.
Security considerations for discovering HA using DHCP are covered in
draft-jang-dhc-haopt-01.
Dupont Expires April 24, 2006 [Page 7]
Internet-Draft DHAAD Considered Harmful October 2005
Author's Address
Francis Dupont (editor)
Point6
c/o GET/ENST Bretagne
2 rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
Fax: +33 2 99 12 70 30
Email: Francis.Dupont@enst-bretagne.fr
Dupont Expires April 24, 2006 [Page 8]
Internet-Draft DHAAD Considered Harmful October 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Dupont Expires April 24, 2006 [Page 9]
