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

RE: Heartbeats (was RE: keepalives)

Why does it require a new DOI? Why can't we just define a new "heartbeat"
application using, e.g., UDP port X? By definition the phase 2 SA in this
scenario is end-to-end, and so to agree on its parameters within IKE we need
to specify the protocol (and perhaps port number) used in the service. Why
does this have to be any different than restricting end-to-end traffic on
the SA to TCP port 23?

-- Jesse

-----Original Message-----
From: Jan Vilhuber [mailto:vilhuber@cisco.com]
Sent: Tuesday, December 07, 1999 1:14 PM
To: Ricky Charlet
Cc: ipsec@lists.tislabs.com
Subject: Re: Heartbeats (was RE: keepalives)


On Tue, 7 Dec 1999, Ricky Charlet wrote:
> 
> > I'm not sure what heartbeat packet is best, ISAKMP, transport ESP or
> > 'hijacked' tunnelled ESP.  I think this is a new protocol but I don't
think
> > it justifies an SA of its own.  I think using an ISAKMP notification is
best
> > as most people seem to want this associated with the phase 1 SA.
> 
> 
> 
> 	I'd like to see dead peer detection be in a dedicated IPsec SA pair
per
> peer pair. There are several good things about doing dead peer detection
> this way:
> 
This would require a new DOI, no? It's a dedicated phase 2 SA, but it's not
(I claim) an ipsec SA. So a new DOI is needed.

jan



>  * If there are multiple IKE or IPsec SAs to same peer, only need one
> 'keepalive' session.
> 
>  * Allows IKE SAs to go away (or dangle the IPsec SAs) if an
> implementation so wishes.
> 
>  * Does not interfere with packet counts or inactivity time outs of IKE
> or other IPsec SAs.
> 
>  * IPsec may architecturally swap key management protocol without
> worrying about loosing dead peer detection functions.
> 
>  * may be enabled or disabled per peer by policy
> 
> 
> 
> 	Here is one negative that I can think of: If one peer reconfigures
such
> that some but not all current IPsec SAs become defunct, this scheme may
> not detect that or may think all current SAs became defunct. This could
> be engineered around with a dead peer recovery detection algorithm.
> 
> -- 
> ####################################
> #  Ricky Charlet
> #	(510) 795-6903
> #	rcharlet@redcreek.com
> ####################################
> 
> end Howdy;
> 

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