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

Hi Tom,

Thanks for the comments; responses below (sorry for long post).

> 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.

Can you clarify this?  If I understand correctly, you're referring
to a case where the VPN is first doing encryption and then decides
to stop that.  If so, that's a different case than what's discussed
in the draft.

The situation the draft describes is where, for various reasons, we
don't want to encrypt when inside.  An ordinary VPN client has no way
of detecting inside vs. outside, so they will typically encrypt all
the time, unless the user turns the VPN off (manually).  So the VPN
doesn't really solve this problem by itself (at least using standard
protocols).

> 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

Correct, when the MN is inside it would have to re-register periodically.
(Note that this is the case with MIPv4 anyway; however, one could use a
longer period without the security issue.)

> battery lifetime point of view because transmitting is expensive ´
> powerwise.  How was the requirement of one minute determined? Why isn't 

Yes, there is a battery impact.  If the MN is sending traffic,
then the net effect should probably be less battery consumption, when
compared to the case where the MN is outside (and requires encryption).
If the MN is inside and not sending traffic, then the battery is being
used for re-registrations every N seconds.

The requirement of one minute is arbitrary as such.  We were trying to
balance the security issue (i.e. how large a hole is acceptable) and the
overhead issue.  The problem is, if there is no required limit, then
given a MN implementing such a protocol cannot be trusted to limit the
leakage to any definite period.

An alternative would be to state the in some cases (which would be
spelled out) the MN may leak plaintext traffic for an indefinite time
(or a time dependent on the registration lifetime, or something else).

> 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?

Yes, I believe there are (that's my personal understanding anyway).
Given the assumptions in the problem statement (namely: compact DMZ,
and that traffic cannot go through the  DMZ when MN is inside), there
is no choice but to drop encryption.  The issue then becomes, how to
do that securely.

The current solution draft attempts to do this by using only current
standards.  The performance could be improved by introduction new
protocols or stronger assumptions (for instance, layer two indications
that are trustworthy from a security point of view).

> 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 

That part of the draft is trying to describe the possible threats,
i.e. what are the events that might cause plaintext to leak.  From a
functional point of view such events are not very important, but from
a security perspective they are (there is no such thing as a "rare"
event when considering security).

> 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 

If such a reconnection were to occur, surely many protocols would fail.
There is no attempt to guarantee that the MN can still communicate in
that scenario.  However, the intent is to address the security implications
of such events.

> 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.

I'm not sure what you mean here.  If a hacker were to "fall into" such
a VPN, that would mean the hacker would be directly connected to the
trusted internal network?  In this case security is pretty much gone,
since there is a potentially hostile entity in the trusted network.
Could you be more specific?

> 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 agree, there's some complexity there.  Can you suggest an alternative
which requires minimal changes to standards?  Or do you suggest that we
should look at solutions which require protocol changes directly?

In other words, do you see a way to improve the draft without changing
the underlying assumptions?  We can surely come up with a better solution
if we relax the assumptions, e.g. the DMZ assumption, or the assumption
that we want to make do with existing standards as much as possible.

> 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.

How would that work in practice?  For instance, if I connect an Ethernet
cable, it's relatively easy to detect that the cable is connected.  But how
do I detect whether it is connected to a trusted or an untrusted network?
Except for media specific solutions this seems to be a difficult approach.

One alternative would be to use the MIP mechanism currently in the draft
to detect entry into a trusted network, and then use L2 triggers to detect
exit.  The problems with this approach are that:

   1) not all MNs have access to L2 triggers;

   2) even if they do, the triggers are not reliable from a security point
      of view (for instance, it is possible to change the Ethernet cable
      without getting a trigger, although this depends on the hardware
      and the driver); therefore there are no security guarantees and
      a plaintext leak may persist in some situations indefinitely
      (or at least up to the next re-registration).

These two considerations lead us to suggest the current solution;
does this rationale sound reasonable?  It seems to me that you consider
point 2) to be minor enough to be dismissed in the draft?

Best regards,

-Sami