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]