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

Sami,

Thanks for your responses.  Comments below.

thanks,
Tom

On 8/5/2003 3:56 AM, Sami Vaarala wrote:
> Tom,
>
> Responses below,
>
>
>> 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.
>
>
> Can you give a concrete example what you mean by "link level security"?
>
> For instance, do you mean that we detect entry into the internal network
> using RRQ/RRP but don't monitor the i-HA and detect exit using link layer
> triggers?  (And rule out other causes for problems, such as administrator
> mistakes in configuring switches?)
>

As an example, link level security could be set up via key distribution such as
with EAP, that is, when all the details are finalized.

Your draft has a rule that says the VPN firewall needs to block outside traffic
to the HA-i, so security needs to be configured correctly no matter what.

>
>>> 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.
>
>
> In laptop use, for instance, higher frequency of re-registration is desirable
> because problems (such as routing issues, HA reboot etc) can be detected
> early enough (otherwise you have a black hole). Furthermore, with NATs one
> has to re-register roughly once a minute or less anyway (when outside).  But
> that's laptops.

I thought from reading the draft that the pinging only was necessary when
running inside the VPN; do I understand correctly this happens all the time?
Then I can say for cdma2000 this is bad news. I discuss the battery impact below.

I concur that when a laptop is running on batteries there is so much else
going on that one MIP registration per minute probably won't impact the battery
lifetime.

>
> Do you have a reference (or a back-of-the-envelope calculation) of how big an
> issue the re-registration once a minute is? That would make the discussion
> more concrete.

I can offer this qualitative insight: when a wireless hand held mobile has to
transmit or receive, it has to be woken up from a sleep state.  At a minimum
this means turning on the WLAN transmitter and receiver. (I assume this is the
kind of radio link you have in mind inside the WLAN).  Depending on other
things, other parts of the mobile may be sleeping and therefore have to be
woken, as well.   Were it not for that, the mobile would remain asleep.

Having said that, you have a note above on NAT and pinging when outside the VPN.
For cdma2000, the transmitter doesn't turn off instantly.  It may linger for 20
seconds, or even longer. I can find exact numbers.  We do this partially to see
if we can catch a return response (e.g., from a web server) without
transitionning  active-dormant-active, which requires signaling, that is, even
more transmissions.  With the 1/min approach the mobile would be active half of
the time, and the batteries would die quickly.  Pinging at any rate like 1/minh
outside the VPN is not acceptable for cdma2000.

In my initial comment I was thinking about hand held devices with batteries.
Some enterprises could be like that -- delivery services could have mobiles that
are sometimes inside and sometimes outside their buildings, for example. Or
employees with hand held wireless devices that change radio usage when the user
walks in the building. I assumed we'd like a solution that works a wide range of
wireless devices.

>
>
>>> 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 requi 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. [...]
>
>
> No, I mean less battery consumption -- assuming that the MN is doing
> something, i.e. sending at least one IPsec-protected packet per minute.
> Agreed, if the MN is not doing anything, then clearly once a minute is more
> battery consumption than no traffic at all.
>
>
>>> [...] 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.
>
>
> That's what we thought too :-)
>
>
>>> 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.
>
>
> More on this below (see alternative 6 at the end).
>
>
>> If these threats can happen as outlined, I am wondering if the security of
>> the VPN isn't already pretty much gone.
>
>
> That depends on what happens to the network.  We wanted to point out that
> such things do happen, and we need to say either that (1) they're out of
> scope, or (2) this is what you can do to minimize damage.  I'm personally
> happy with alternative (1), as such events are really rare and as you said,
> security is questionably at that point anyway.
>
> However, this does not, IMO, solve the problem with unreliable L2 triggers.
> Which, I believe, is the root of the issue.
>
>
>> 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 it
>> confused which ones it should use may not be that rare, and that is perhaps
>> a problem to worry about.
>
>
> Right.
>
>
>>> I agree, there's some complexity there.  Can you suggest analternative
>>> 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.
>
>
> This is equivalent to what we (Netseal) and several other MIP/IPsec vendors
> deploy today.  Either the combined security/mobility device is in the DMZ
> (which has routing impact) or the device is inside (and we have a pinhole).
> The latter has been clearly unacceptable to some customers, which is why
> there is interest in avoiding both problems. (The concern is that you will
> have a large security perimeter because you need pinholes for every i-HA
> there is; this may be a large number in a large enterprise.)

Can you provide some examples of what is a large number of
home agents with associated numbers of users?

>
> What you suggest also requires changes in the IPsec layer, namely to allow
> IPsec SA endpoint update, which is not part of the specifications.  Which
> means that the solution is either proprietary (these proprietary products are
> already out there) or needs more IPsec specification work.
>

Some specification work will be necessary; the question is what is the best long
term approach.  I have been concerned your solution rules out hand held mobile
devices; reading forward I need to think about your alternatives and gather more
information.

>
>
>>>> 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.
>
>
> You referred to the use of link layer indications to determine whether the MN
> is inside the internal network.  How would that work in practice?
>
>
>> 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.
>
> This is a good solution (already deployed :) but it is not a solution to the
> problem statement document, which assumes that the security perimeter should
> not be distributed (see e.g. sections 2.5, 4, 5.1), as is the case with the
> "pinhole" approach.  It seems that we disagree on the requirements document?
>

I think we have to be pragmatic to some extent.  If the requirements produce a
solution that requires devices that are more or less assumed to be plugged into
a power source then we have to review the requirements and examine the various
tradeoffs with other solutions.  And we have to reivew the requirement for
pinging out the the VPN when there is NAT.

> Some alternatives to go forward:
>
> 1) We change the requirements document some way (firewall requirements,
> battery requirements, ...).
>
> 2) We emphasize that the solution is for current enterprise users (typically
> laptops), and that it is not necessarily applicable to small battery-powered
> devices (i.e. keep current solution).

At a minimum, we would need to address pinging outside the VPN as this has
spectral implication apart from battery ones.

>
> 3) We rely on RRQ/RRP to detect entry, and use L2 triggers to detect exit; if
> in doubt, the administrator could say that IPsec shall always be used
> (although this defeats the point to some extent, because traffic goes through
> DMZ).

Question:  I was thinking the home agents could also support IPSec, i.e.,
combined mobility/security entities.  Therefore, when mobiles are inside the VPN
traffic, wouldn't the traffic stay inside the VPN?

>
> 4) We rely on RRQ/RRP to detect entry, and use L2 triggers to detect exit
> using L2 triggers for those media that have reliable L2 triggers (which may
> be a can of worms). The rest of the media rely on re-registration.
>
> 5) We rely on RRQ/RRP to detect entry, but make exit detection and its
> parameters SHOULD.  This has an impact on overall security and what can be
> expected from an implementation.
>
> 6) Relax the re-registration requirement as follows: - The MN does not need
> to re-register periodically, if there is no traffic.
>
> - However, when traffic is about to be sent or received, the traffic is
> queued up (or dropped), and a re-registration invoked (assuming more than N
> seconds have passed since last re-reg.)
>
> - If the re-registration goes through, the traffic is delivered;  if not, it
> is dropped and the MN registers through the x-HA.
>
> If we want to have better support for idle devices (esp. battery powered
> ones), I'd go with alternative 6. Although it adds complexity (queue
> management and such), such complexity will only be required when the steady
> re-registration is an issue.  There is still some battery overhead involved,
> but that only happens when the MN is sending/receiving MIP tunneled traffic
> (i.e. is active).
>
> Does this sound like an acceptable solution to the battery problem?

We need more input from mobile vendors on the complexity issue of this
alternative.  One initial thought: it's probably necessary to buffer data
because discarding data would appear like buggy network service to users.

Thanks for your many comments and ideas.  I respond today in order to avoid
looking like I dropped off this exchange.  I need a bit more time to think, and
to read your thoughts on my comments above.


thanks,
Tom