Internet DRAFT - draft-glass-mobileip-security-issues
draft-glass-mobileip-security-issues
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
<T.B.D.>
4.0 Tunnel Services
<T.B.D.>
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:
<T.B.D.>
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]
