Subject: [mobile-ip] I-D ACTION:draft-nikander-mobileip-v6-ro-sec-01.txt

From: [email-masked]
Date: Wed, 02 Jul 2003 16:30:41 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Mobile IP version 6 Route Optimization Security Design
                          Background
	Author(s)	: P. Nikander et al.
	Filename	: draft-nikander-mobileip-v6-ro-sec-01.txt
	Pages		: 40
	Date		: 2003-7-2
	
This document is a succint account of the rationale behind the Mobile
IPv6 (MIPv6) Route Optimization Security Design. The purpose of this
document is to present the thinking and to preserve the reasoning
behind the Mobile IPv6 Security Design in 2001-2002.
The document has two target audiences: (1) MIPv6 implementors (so
that they can better understand the design choices in MIPv6 security
procedures); and (2) people dealing with mobility or multi-homing (so
that they can avoid a number of potential security pitfalls in their
design).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-nikander-mobileip-v6-ro-sec-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-nikander-mobileip-v6-ro-sec-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Tom Hiller <[email-masked]>
Date: Tue, 29 Jul 2003 13:14:16 -0500

Hi,

I had a few comments on draft-ietf-mobileip-vpn-problem-solution-02:

The draft proposes to use MIP to determine whether the mobile is inside the VPN
and can send data in the clear. I think this is misguided. If the VPN
security is such that the MN can exit the protection of the VPN security without
the MN knowing about it and send sensitive data in the clear, then the VPN
and/or its security scheme is broken and MIP should not be expected to fix the
problem.

MIP on battery operated wireless devices will have a problem providing the
correct responsiveness the draft requires. The draft states:

> The default values MUST ensure that the mobile node will stop sending
> plaintext traffic within one minute of the change of i-HA reachability.

Does this imply a MIP registration every minute when the mobile is inside the
VPN?  A high MIP registration rate is counter productive from a battery lifetime
point of view because transmitting is expensive powerwise.  How was the
requirement of one minute determined? Why isn't zero seconds?  Are there really
VPN administrators who would select a VPN security solution that permits data to
be sent in the clear with their users not being aware?

The document states the mobile could fall out of the VPN not only due to layer 2
links switching underneath the unaware client, but also due to unwanted routing
changes that connect the user to the outside. Is MIP being used to detect
routing bugs in virtual private networks?  By the way, since it says: "the
subnet is reconnected to another place in the network topology in its entirety",
then what about the other VPN endpoints on that subnet? Similarly, if a mobile
could fall out of the kind of VPN being addressed in this draft without
realizing it, can a hacker mobile fall into such a VPN and start transmitting
and receiving data?  It seems like these problems are really much larger and
therefore should be resolved in other drafts.

This solution imposes a fair amount of complexity on the MN:  It calls for a
variable number of MIP registrations (i.e., one or two), it needs to handle the
possibility that both are successful, it needs to frequently determine whether
it is internal or external to the VPN, and it needs to be able to reconfigure
its IP stack on the fly.

----

I think this draft should delete all text referring to the use of MIP to
determine whether the MN is inside and can send data in the clear. Instead the
mobile should rely upon link layer indications to determine if it is in the VPN
and have a VPN based policy that determines if it should send data in the clear.

thanks,
Tom