[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: Dead peer detection



On Wed, 3 Apr 2002, Casey Carr wrote:

> 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@xxxxxxxxxxxxxxxx]
> 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.

When we were designing the DPD mechanism published in the draft, we
actually considered this. Given that media traffic can easily be
unidirectional (UDP/RTP traffic needs no ack's), we didn't think this
was appropriate, since you could go your whole life without a packet
in the other direction (internet radio comes to mind, except of course
that most of those run over tcp..).

>     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."
>

The sense I get in the working group is that the key protocol should
indeed have formalized key management functionality (deletes,
informationals, DPD, etc). Using pings has its own set of problems, so
we should formalize this all under the key management protocol
(i.e. son of IKE).

jan
 --
Jan Vilhuber                                            vilhuber@xxxxxxxxx
Cisco Systems, San Jose                                     (408) 527-0847