comments on draft-ietf-mobileip-vpn-problem-solution-02

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