Subject: Re: [mobile-ip] comments on draft-ietf-mobileip-vpn-problem-solution-02

From: Tom Hiller <[email-masked]>
Date: Mon, 04 Aug 2003 20:16:45 -0500

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.

---

From: "Sami Vaarala" <[email-masked]>
Date: Mon, 11 Aug 2003 10:12:53 +0300

Tom,

Some quick comments below.  I'll post a -03b version soon with
some edits that outline how alternative 6 might look in the
specification; have a look and comment.

Best regards,

-Sami

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

Right.  For the particular case of 802.1x/11i we can do better,
but we still need to solve the generic case?

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

The first requirement is to make the solution sane, while the
second is limiting damage when the requirements are not met
(which will eventually happen).

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

Frequent re-registration would be necessary only when in the internal
network, yes.  Of course ordinary Mobile IPv4 re-registration would
still be required even when in the external network (which could be
every hour or whatever is configured).  And if there is a NAT outside,
then tunneled ICMP Echo (see RFC 3519) is required.  (If IPsec is the
lowest layer protocol, one needs IPsec NAT keepalives; there is no way
out of this NAT keepalive problem.)

> [...]
> 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, I agree, supporting a wide range of wireless devices is
desirable.

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

One reasonable setup is where you have one home agent per site.
For large enterprises this could be dozens.  If one wants optimal
routing, there would have to be one home agent per subnet.
The perceived problem is not management as such, but that instead
of one (or a few) security critical devices, there is one in every
site or subnet.

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

Thinking out of the box, IMO the best long term approach would be
to design a standardized hybrid of IPsec and Mobile IPv4, dropping
a number of IPsec features on the way for simplicity.  This is
essentially the combined HA/VPN approach, but maintaining separate
security and mobility layers is not useful since the layers need
to interoperate anyway.  This would simplify implementation, and
would be especially applicable to small devices.

However, one constraint is that we need something that can be
deployed now (or very soon), which is why not changing IPsec
becomes important.  

> > 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
> review the requirement for pinging out the the VPN when there is NAT.

I agree to some extent, especially that we need to be pragmatic.
I'm quite confident that we can work out the re-registration issue
to suit battery powered devices better.

> > Some alternatives to go forward:
> > 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.

Right.  That's only necessary when there is a NAT outside,
and one wants to maintain the tunnel.  I don't think there's
much we can do here, except change NATs :-)  Other pinging
or overhead traffic should not be necessary (apart from
re-registration with a desired interval, such as every hour).

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

We worked out quite a few scenarios with this approach,
and they all end up either changing the security perimeter
or changing standards in a non-trivial way.

If I understand correctly, you propose to combine IPsec/MIPv4 into
the i-HA (I'm assuming there is still a traditional VPN in the DMZ,
as we're otherwise discussing the pinhole solution).  In this case
one would still detect the internal network to avoid overhead and
routing traffic through the DMZ.  The problems here are double IPsec
when MN is outside and changes in standards that are more than
deployment tweaking.

> > 6) Relax the re-registration requirement as follows: - The MN does
not
> > need to re-register periodically, if there is no traffic.
> > [...]
>
> 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.

Yes; on the other hand large buffers are problematic on small
devices.  Buffering of a few packets seems acceptable to
me, though, particularly because a device would probably
have to do that anyway for a proper ARP implementation.

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

Thank you, it's been enlightening.

Best regards,

-Sami