RE: Dead peer detection

["Casey Carr" <caseyc@cipheroptics.com>]

We are just addressing this from a requirements standpoint.  My hunch is
that we will have to implement something prior to SOI so we would at least
consider the draft DPD as a potential solution.

Casey

-----Original Message-----
From: Ricky Charlet [mailto:rcharlet@SonicWALL.com]
Sent: Wednesday, April 03, 2002 7:06 PM
To: 'Stephane Beaulieu'; Casey Carr; ipsec@lists.tislabs.com
Subject: RE: Dead peer detection


Howdy,

	Hey, I was interested! Very early on I asked the draft authors
about their intentions and they told me to not implement the -00 draft
because they envisioned significant change. So I waited. (and
waited...).  If we implemented the -00 draft, would we interoperate with
you?

	Any VPN vendor will run across the customer driven request for
tunnel-black-hole-detection and possibly for supporting alternative
tunnels to backup gateways. Dead peer detection (of some sort) is a
fundamental requirement for these.

	Yet End-to-End IPsec'ers see any DPD mechanism as dangerous
overhead and unnecessary complexity. Even among folks who want a
standardized DPD mechanism, disagreements over the driving requirements
(should it support site-to-site tunnels, should it support remote access
without interfering with accounting or PPP link keep alive, other
reasonable use cases may be envisioned) lead to opposing suggestions for
its implementation (in IKE, in ESP/AH, in the clear).

	I believe that of the people who are actually deploying home
grown solutions for DPD, this draft-ietf-ipsec-dpd-00.txt (with its
implementation in authenticated IKE exchanges) solves their problem set.
It solves our problem set.

	Also on the horizon it IKEv2 which has a DPD mechanism proposed
within it (thanks Kaufman and IKEv2 team).


--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin

  Ricky Charlet     : rcharlet@sonciwall.com   : usa (408) 962-8711


 > -----Original Message-----
 > From: Stephane Beaulieu [mailto:stephane@cisco.com]
 > Sent: Wednesday, April 03, 2002 1:51 PM
 > To: Casey Carr; ipsec@lists.tislabs.com
 > Subject: RE: Dead peer detection
 >
 >
 > Hi Casey,
 >
 > There are 3 or 4 different ways of doing Dead Peer Detection
 > that I am aware
 > of.  Cisco has an older method reffered to as Keepalives in our older
 > releases of IOS, VPN3000, and PIX.  It is undocumented (to the public)
 > though I believe some of our partners have also implemented it.
 >
 > All of our newer releases support the DPD draft you
 > referenced, and we are
 > going to slowly deprecate keepalives.  We published DPD in
 > the IPsec WG in
 > hopes to get it standardized.  However, there hasn't been
 > much interest
 > which is why the draft has been idle.  I think the WG chairs
 > also decided
 > that DPD was outside the scope of the WG because of the
 > moratorium. I sent
 > an email to Ted a few weeks ago asking whether we could try to go
 > standards-track with it or if we should just go out as
 > Informational.  I'm
 > still waiting for a response.
 >
 > I know that Nortel also has some scheme which addresses the
 > same issues,
 > though they apparently have a patent on it.
 >
 > I'm sure there are other proprietary versions which are
 > probably all very
 > simliar except for the bits on the wire.
 >
 > Hope this helps,
 > Stephane.
 >
 >
 >
 > > -----Original Message-----
 > > From: owner-ipsec@lists.tislabs.com
 > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Casey Carr
 > > Sent: Wednesday, April 03, 2002 3:22 PM
 > > To: ipsec@lists.tislabs.com
 > > Cc: IPSec Policy WG
 > > Subject: FW: Dead peer detection
 > >
 > >
 > > Sorry.  I sent this to the IPSec Policy WG the first time
 > by mistake.
 > >
 > > I think it more appropriate in the general IPSec WG.
 > >
 > > -----Original Message-----
 > > From: Casey Carr [mailto:caseyc@cipheroptics.com]
 > > Sent: Wednesday, April 03, 2002 2:24 PM
 > > To: IPSec Policy WG
 > > Subject: Dead peer detection
 > >
 > >
 > > Is there an RFC or draft on standards track to deal with dead peer
 > > detection?  After spending some time reviewing the IPSec, IKE,
 > > ISAKMP RFCs I
 > > have drawn the conclusion that there is not a "standard"
 > way to implement
 > > dead peer detection.  Have I reached a valid conclusion?
 > Are other IPSec
 > > vendors implementing proprietary solutions?  If so, have there been
 > > interoperability issues?
 > >
 > > I reviewed draft-ietf-ipsec-dpd-00.txt.  It appears to be a year
 > > old without
 > > revisions which leads me to believe that it may not be
 > widely accepted.
 > >
 > > It also  appears from a statement in JFK that the authors regard
 > > this as an
 > > implementation issue:
 > >
 > > "A second major reason for Phase II is dead peer detection.  IPsec
 > >     gateways often need to know if the other end of a
 > security association
 > >     is dead, both to free up resources and to avoid "black holes".
 > >     In JFK, this is done by noting the time of the last
 > packet received.
 > >     A peer that wishes to elicit a packet may send a "ping".  Such
 > >     hosts MAY decline any proposed security associations that do not
 > >     permit such "ping" packets."
 > >
 > >
 > > Thanks,
 > > Casey
 > >
 >
 >