[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?
Well, as one of the authors, I can honestly say I don't recall that
conversation.
Yes, if you implemented -00, you would interoperate (well... hopefully at
least ;). IOS, PIX, VPN3000, and our Client have all implemented the -00
draft seperately, and have had successful interop. Perhaps we can test at
the next bakeoff?
>
> 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
> > >
> >
> >