Re: address inertia

The conversation is getting a bit muddled.
Let me try to clarify a few things.

The central topic of discussion concerns Restarting
the Responder-end of a Road Warrior connection (RRRW).
We all agree that this is a problem.  A difficult and
important problem.  We agree that there are multiple
possible solutions.

We need to discuss the pros and cons of various
proposed RRRW solutions.  Factors to take into
account include:
  -- security
  -- performance (how quickly can it restore things?)
  -- statefulness (does it require the hub to keep
     state information that persists across a restart)
  -- cost in terms of computation
  -- cost in terms of network traffic
  -- deployability (if I have a hub that already has
     N connections, can I install the RRRW solution
     without taking down the hub?)
  -- interoperability (if I install it on a FreeS/WAN
     hub, does it interoperate with every possible
     flavor of client, or does it assume F/S clients,
     and/or does it require installing non-standard
     "helper" applications on all clients?)
  -- existence (is a ready-to-use implementation available?)



The mk_conf solution requires a stateful responder. This
shouldn't be a burden in typical cases. (There are some
IPsec systems that boot from CDROM, using essentially no
persistent storage. But these are rather atypical.) In all other
ways, mk_conf is close to optimal. It exists and can be
installed without disturbing existing connections. In the
typical case, it generates no unnecessary network traffic.
The exception is if the road warrior moves or shuts down
while the hub is restarting, in which case the hub will waste a
certain amount of effort trying to contact the wayward peer.
But this problem should be rare if the hub isn't down for very
long. And it can be alleviated by limiting the number of
keyingtries in outgoing connections to road warriors, e.g. by
using the mk_conf -k2 option.


MCR has proposed another approach to the RRRW problem,
involving birth certificates.  I can imagine a number
of variations on this idea.  The version originally
proposed was:

> If the base station gets ESP traffic that it does not recognize, then
> it sends out a rate limited ICMP "I've was born at time X" (RSA
> signed). This puts the burden on the client to re-initialize when
> they actually have traffic again.
> 
> The downside is that this requires changes on base station and road 
> warrior.

And it breaks NAT-traversal.  Perhaps using UDP 500
would be better than ICMP.

And it causes non-promptness:  The connection is not
restored until after at least one packet has been
dropped.

And AFAIK this is only a proposal;  no ready-to-use
implementation is presently available AFAIK.

Another way of using birth certificates might be to
run a web server on the base station, from which
interested parties could download a birth certificate.
Road warriors could poll this server (excess traffic,
alas) or check it only if/when they notice a problem
(hard to notice in general, alas).  Call this a "pull"
model in contrast to the original "push" model.

> Address inertia will work if implemented on the base station only, 
> and will work with FreeSWAN road warriors.

I'm not sure what that's saying.  As I see it
  -- the mk_conf script runs on the base station.
     It requires FreeSWAN.
  -- the mk_conf solution requires no changes whatsoever
     to the road warriors.
  -- it should interoperate just fine with road warriors
     no matter what flavor of IPsec the latter are running.


> The road warriors will need a way to tell pluto "bring up an ISAKMP
> SA and then delete it" so that the base station will know to remove
> the inertia.

Huh?  Who needs to do that?  Why?  How?

Often one should impose limits on the amount of
inertia, but that can be done using keyingtries.
See the --k2 option to mk_conf

http://www.monmouth.com/~jsd/vpn/ipsec+routing/mk_conf.htm


> Right now, if your credentials to access a base station get screwed
> up, but you have SSH access in,

But what if I don't?  mk_conf works even if I don't have
ssh access.

> you can simply wait for the keys to expire and the base station,
> if set to "rekey=no" will not attempt to re-establish things.

What problem are we solving here?  Limitation of
address inertia?  Isn't the solution in mk_conf
(limiting the keyingtries) sufficient?