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

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