Re: SOI QUESTION: 4.3 Dead peer detection

[Henry Spencer <henry@spsystems.net>]

On Tue, 25 Jun 2002, Theodore Ts'o wrote:
> 4.3.A) Both JFK and IKEv2 provide dead peer detection via a
> "keep-alive" mechanism.

No, only IKEv2 provides this.  JFK claims that this functionality can be
provided using an ordinary ping, which is incorrect.  (It suggests that an
implementation could allow only SAs which permitted suitable pings -- a
restriction so severe that it would cripple interoperability.  This is not
a solution, it's an attempt to avoid providing a solution.)

Also, speaking of this as a "keep-alive" is misleading (and likely to
produce unnecessary adverse reactions).  Dead-peer detection need not be
used as a keep-alive.  It is conceivable, indeed preferable, to probe the
status of the peer only when there is specific evidence that something may
be wrong, e.g. receipt of an unauthenticated error report suggesting that
the peer's host has been rebooted. 

It might be better to refer to this feature as "dead-SA detection". 
That's the real issue. 

> The functionality provided is roughly
> identical.  Does anyone care about how low-level implementation
> details of IKEv2 and JFK?

Do I care how it's done?  Not so long as it works, which JFK's current
approach doesn't. 

Do I care whether it is precisely specified?  *Yes*; it's important.  JFK
falls down again here.  draft-ietf-ipsec-ikev2-02.txt section 6 nails down
just how dead-SA detection is done, which is most welcome.  The JFK draft
needs equivalent detail; even if "let them send pings" was a workable way
to probe the peer, probing is only one part of the solution, and the rest
needs to be specified. 

> 4.3.B) Should the working group consider other schemes which provide
> the same functionality as dead peer detection?  (i.e., birth
> certificates, see section 3.5 in draft-ietf-ipsec-soi-features-01.txt)

The crucial requirement is a way of reliably propagating authenticated
information about the demise of SAs.  Whether this is done in one step
(authenticated error report or reboot report) or two (unauthenticated
report followed by authenticated probe/response) is unimportant. 

It does seem to me, though, that the added protocol complexity of an
authenticated probe/response facility is so slight that it is probably the
most expedient solution. 

                                                          Henry Spencer
                                                       henry@spsystems.net