RE: SOI QUESTION: 4.3 Dead peer detection

[Jan Vilhuber <vilhuber@cisco.com>]

On Tue, 25 Jun 2002, Stephane Beaulieu wrote:

>
> >
> >
> > Please discuss and answer this question:
> >
> >
> > 4.3 Dead peer detection
> >
> > 4.3.A) Both JFK and IKEv2 provide dead peer detection via a
> > "keep-alive" mechanism.  The functionality provided is roughly
> > identical.  Does anyone care about how low-level implementation
> > details of IKEv2 and JFK?
>
> SOI MUST be able to handle black-hole detection & resource recovery.  If a
> DPD type mechanism is the best way to handle that, then that's what we need
> to do.
>
> On a side note, I believe both JFK and IKEv2 use more of a "ping" than a
> "keep-alive" mechanism.  The expression "keep-alive" tends to cause a
> knee-jerk reaction as developers tend to equate it to a "make-dead"
> mechanism.
>

In fact JFK (at least in the versions I've read. I haven't been able
to keep up; I'm sure someone will correct me if I'm wrong) specifies
EXACTLY using IP pings, requiring the IPsec SA to cover ICMP packets
(or alternatively you establish a separate IPsec SA just for the
pings, I guess).

So to answer Ted's question: yes, I care about the details of
implementation of IKEv2 and JFK. I don't much care for the hand-waving
ping approach suggested by JFK, whereas IKEv2's approach is closer to
the DPD mechanism suggested by Geoff Huang et.al. (now expired,
looking for a home).

If you believe (as I do) that multiple tunnels are needed between
peers, then an IKE-level 'ping'/DPD/keepalive/whatever covers all
IPsec Sa's created between the peers, which is more efficient.

Another thought in the JFK approach: Assuming people still charge
per-packet or bandwidth used, pings may (or may not; depends on the
customer) need to be excluded from the 'charging/accounting'. This
makes the ipsec code more complex, too.

>
> >
> > 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)
>
> I was under the impression that birth certificates were more of an
> INITIAL-CONTACT replacement than DPD.  In any case, to directly answer the
> question, we need to consider ALL schemes, as long as they address the
> requirements.
>

I was also under the impression that birth-certificates were more akin
to Initial-contact, rather than real-time detection of connectivity
problems. The two aren't necessarily the same.

I seem to recall talking to folks who thought initial-contact together
with DPD would be really nice and robust. Whether we replace
initial-contact with birth-certificates, I don't really care about.

jan


> >
> > Implications from the Scenarios:
> >
> > [none]
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847

http://www.eff.org/cafe