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

Sami,

Thanks for your responses. My comments are in-line below.

thanks,
Tom

On 7/31/2003 4:48 AM, Sami Vaarala wrote:
> 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).
> 

The draft suggests that either the mobile may attach to a radio link outside the
VPN or that routing errors may put the mobile outside the VPN, implying the
mobile is transmitting potentially sensitive information in the clear outside
the VPN.  I am wondering if frequently pinging the HA-i with an RRQ is the way
to combat this problem.  It seems link level security is the correct way to go.
 As well as to fix the VPN so that the users aren't route outside of the VPN, if
that is a 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
> 
> 
> 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.)

We don't usually have that short type of MIP lifetime.  In fact I don't know of
any networks that use such a short lifetime.  We never use that short lifetime
in wireless due to the battery issue.  I believe the rates suggested in the
draft are unacceptable for battery powered wireless devices.

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

You write "less battery consumption" --- did you mean less battery lifetime
inside the VPN than compared to when outside the VPN due to the frequent
registrations?  The encryption of data in the mobile will have far less negative
impact on the battery lifetime than turning on the transmitter once a minute.
Running IPSec will cost something --- largely due to the fact that there are
more bytes to transmit over-the-air. I suspect for typical users that the loss
of battery lifetime due to once a minute transmission is much more serious than
due to a slightly extended transmission time because of IPSec overhead when they
have data to send.  In the former case the battery runs down even though they're
not using their device for anything.

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

Clearly not acceptable.

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

Perhaps we can solicit opinions on this matter from security people?

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

Right, that sounds like the correct solution.  I am concerned that MIP is being
asked to do something it isn't really equipped to do, at least in wireless devices.

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


If these threats can happen as outlined, I am wondering if the security of the
VPN isn't already pretty much gone.

If the threats are really rare then one needs to look at the cost to protect
that situation in the face of the loss of battery time. However, I assume the
event of the mobile finding another link because its confused which ones it
should use may not be that rare, and that is perhaps a problem to worry about.

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

The pinhole in the firewall seems like a more straightforward solution: The
mobile establishes a security association to the HA-i and then runs collocated
MIP inside that security association.  The mobile does the same whether it is
inside or outside the VPN.  There is only one HA involved: the HA-i.  The HA-i
has a public address.

If there is a mandate in the external network to use an FA and an HA-x, then
obviously the mobile would have to use it.  In that case the mobile should run
IPSec and collocated CoA over the HA-x through the pinhole to the HA-i.   The
solution should not incorporate the need for an HA-x as a general assumption for
VPN access when the mobile is outside to the VPN.

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

See previous comment.

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

I think the issue is that if you want the mobile to move around inside and
outside the VPN without user intervention then you either need the mobile to be
able to determine that the link is within the VPN and is secure, or you need to
run IPsec all the time.

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

With L2 triggers not working reliably as you state, it may be too soon for a
draft to work the way this one works because the mobile either needs to ping the
HA at such a rate that is detrimental to battery lifetime, or it needs to allow
for clear text data to be sent outside the VPN.  Instead, the pinhole in the
firewall solution with only one HA (an HA-i with a public address) may be more
correct for now, and the data needs to be encrypted all the time, or at least on
links where there is a question.