Internet Engineering Task Force S. Glass INTERNET-DRAFT Sun Microsystems Individual Submission 23 February, 2001 Security Issues in Mobile IP draft-glass-mobileip-security-issues-00.txt Status of this memo This document is an individual submission to the Mobile IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract Mobile IP is designed to provide IP services to roaming nodes, allowing them access to services, and enabling other nodes to reach them, as if they were on their home domain. By definition this functionality must be deployed on multiple subnets, and in many cases across domains, and while Mobile IP services MUST be present on a subnet in order for a mobile node to have this reachability, deploying Mobile IP can introduce some security issues which may need to be addressed, but which certainly should be understood by any network administrator overseeing Mobile IP subnets. While there are many security details which must be negotiated in wen a Mobile IP session is to take place involving an inter-domain relationships, this document does not address them. In these cases the reader is directed to a series of documents produce by the AAA working group Glass Expires 14 January 2001 [Page 1] Internet Draft Security Issues in Mobile IP 31 January 2001 2.0 Agent Advertisements Agent Advertisements as defined by [1] [3] append a mobility extension to the router advertisement packets of [4]. These will contain a code of 16 if the agent sending the advertisements does not support generic routing. The mobility extension contains a sequence number used by mobile nodes to detect if a foreign agent has reset its state, and has therefore (likely) lost the mobile node's mobility binding and is no longer providing mobile ip services to the mobile node. This mechanism is protected from "falsing" in the case of sequence number roll-over as the foreign agent is required to set the sequence number to 256 upon detecting its advertisement sequence number space has been exhaused. This "beaconing" mechanism MAY be used by a "man-in-the-middle" to fool the mobile node into thinking its current binding has been lost. A "man-in-the-middle" that forges an agent advertisement, setting the IP source address to suggest the beacon came from the agent with which the mobile node is currently recieving foreign agent services, and setting the sequence nubmer to 0 may fool any mobile node registered with that foreign agent that its state has been reset, and that likely its binding has been lost. The scope of this attack is somewhat limited since agent advertisements MUST be sent with a TTL of 1, meaning that smarter mobile node implementations check this before reacting, and hence such an attack must either come from the local link, or must have the TTL set correctly so that upon reaching the link on which the mobile node is currently residing the TTL has been reduced to 1. Moreover, agent advertisements are sent using either a broadcast/multicast mechanism, or unicast. Agent advertisements destined for the entire link are sent to either the all subnet broadcast address of 255.255.255.255, or the all host multicast address 224.0.0.1 (the directed subnet broadcast address is not used as mobile node's are not expected to know apriori which subnets they'll be visiting, and therefore don't know what constitutes such an address, especially since the deployment of CIDR [8]). Attacks to these addresses from nodes off the mobile nodes current link do not pose a problem as packets originating from such links with these destination addresses will never be routed to the mobile node's current link. Agent advertisements are sent to a mobile node's unicast address only in response to an agent-solicitation sent by the mobile node, and these do pose a threat from attackers off the mobile node's current link. Such an attack could be rendered nearly useless, however, if a mobile node implementation ignored unicast agent advertisements except when awaiting a response to an agent solicitation. The threat of attack may also be minimized if routers servicing the mobile node's current link perform ingress filtering. Glass Expires 14 January 2001 [Page 2] Internet Draft Security Issues in Mobile IP 31 January 2001 Forged agent advertisements from nodes on the same link as the mobile node, however, and sent to either the mobile node's unicast address, or sent to either the all subnet broadcast address, or the all hosts multicast address, are the most likely to fool a mobile node into thinking its binding has been lost. A good mobile node implementation may check to make sure the originating hardware address matches the hardware address it has seen in previous agent advertisements, as well as that in the registration reply which confirmed mobile ip services were being provided to the mobile node, however this is of limited use since hardware addresses can be faked as well. It is hoped that some security mechanism will be designed so that a mobile node registering with a foreign agent can authenticate future agent advertisements as originating from the same agent with which it is receiving foreign agent services. 3.0 Registration Process 4.0 Tunnel Services 5.0 Security Considerations This entire document addresses the security considerations for deploying mobile ip on, and by definition across, IP subnets. It addresses security issues that may pertain to mobile nodes roaming onto foreign subnets, to those foreign subnets that service such mobile nodes, to home subnets that wish to provide service to such roaming mobile nodes, as well as subnets in general now that Mobile IP has been standardized, implemented, and deployed. Acknowledgements The editor would like to thank the following persons for their contributions to this document: Glass Expires 14 January 2001 [Page 3] Internet Draft Security Issues in Mobile IP 31 January 2001 References [1] IPv4 Mobility Support RFC 2002, October 1996 C. Perkins, Editor. [2] Reverse Tunneling for Mobile IP, revisited RFC 3024, January 2001 (obsoletes RFC 2344) G. Montenegro, Editor. [3] Mobility Support in IPv6 work in progress, revision 13, November 2000 D. Johnson, and C. Perkins. [4] ICMP Router Discovery Messages RFC 1256, September 1991 S. Deering, Editor. [5] Mobile IP Network Access Identifier Extension for IPv4, RFC 2794, March 2000 P. Calhoun, C. Perkins. [6] Mobile IP Agents as DHCP Proxies work in progress, revision 01, February 2001 S. Glass [7] Registration Revocation in Mobile IP work in progress, revision 01, February 2001 S. Glass [8] Classless Inter-Domain Routing (CIDR) RFCs 1518, 1519 September 1993 Y. Rekhter, T. Li, and V. Fuller, T. Li, J. Yu, K. Varadhan Where to Direct Comments Questions and comments about this draft should be directed at the Mobile IP working group: mobile-ip@standards.nortelnetworks.com Questions and comments about this draft may also be directed to the author: Steven M. Glass Internet Engineering Sun Microsystems 1 Network Drive Burlington, MA. 01801 Phone: 1.781.442.0006 Fax: 1.781.442.1706 E-mail: Steven.Glass@Sun.COM Glass Expires 14 January 2001 [Page 4] Internet Draft Security Issues in Mobile IP 31 January 2001 The working group may also be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola 6000 Connection Drive 1501 West Shure Drive M/S M8-540 Irving, Texas 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 Fax : +1 972-894-5349 eMail: Basavaraj.Patil@nokia.com eMail: QA3445@email.mot.com Full Copyright Statement "Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Glass Expires 14 January 2001 [Page 5]