Re: [btns] Q: How to deal with connection latch breaks?

[Nicolas Williams <[e-mail]>]

On Wed, Aug 12, 2009 at 01:06:32PM -0700, Laganier, Julien wrote:
> Not sure I caught all the details of the discussion, but just to make
> sure I understand correctly: If a peer restarts, DPD will eventually
> detect it, and then the peers can proceed with re-establishing IKE and
> CHILD SAs. In the BTNS case where the BTNS IKE SA gets re-established
> after DPD, each of the BTNS peers can verify that they're talking to
> the same peer right? Thus I think the latches shouldn't be broken
> automatically when DPD concludes a peer is dead. They should only be
> broken in case it's not possible to re-establish a BTNS IKE SA after
> DPD, or a BTNS IKE SA can be established but to a different peer.

If a peer has restarted then, yes, we could immediately transition the
affected latches to BROKEN (without a way to get back to ESTABLISHED).
That's presuming that peer restart -> all connections to it are reset.
But there's no need to do this since the lack of valid SAs will quickly
be discovered, new SAs will be negotiated, and then TCP RSTs / SCTP
ABORTs will follow (there's no equiv for UDP though, so breaking UDP
latches in the case of peer restart makes sense).  We need to be careful
to distinguish restart of IKE daemon processes from peer reboots.

DPD also looks for peers that are simply not there anymore.  That's a
heuristic mechanism (liveness check -> <crickets for more than N seconds>
-> dead peer).  I'm not sure that it would be appropriate to let IKE
heuristically decide that a peer is dead when the ULP and app can do
that themselves.  In fact, I'd say that would not be appropriate.

OK, so I've convinced myself: we need not say anything about DPD, though
we could add that when peer restarts (reboots) are detected then all
affected latches SHOULD transition to BROKEN.

Nico
--