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

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

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

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.

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

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

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

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.

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

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

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

  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?

Best regards,

-Sami