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

Re: Heartbeats draft available

This touches on a point I've been trying to make. Depending upon what
you think the requirements are, inactivity timeouts solve a large slice
of this problem, yet this draft never mentions them. Also, as Sankar
points out, the presence of traffic on an SA may be enough to prove that
it is viable, but the draft does not seem to address this point either.

An elucidation of the requirements driving this discussion is necessary,
and not just for my benefit. We cannot be sure we are trying to solve
the same problem unless we explicitly agree upon what the problem is.

Sankar Ramamoorthi wrote:
> 
> Hi,
> 
> I have some questions and comments.
> 
> The heartbeat protocol as described does not take into account of data
> packets. If there is data traffic already flowing between the client
> and gateway, the heartbeat packets from the client-to-gateway seem
> reduntant - is there a way data packets can double as heartbeat packets?
> 
> I also have concerns with the one-way heartbeat message. It forces
> negotiation
> of expected timeout-interval, lost-packet tolerance window and a number of
> other parameters between the communicating parties. This seems to add a
> lot of complexity to the protocol and additional administrative knobs.
> 
> Heartbeat protocol is one way to detect failure of a session - but it seems
> to tie the failure of a transport with failure of a session.
> For example if the router in the transport path is down for 5 minutes
> should the SA's have to be renegotiated?
> 
> Heartbeat protocol also seem to be a very proactive way of detecting
> failures.
> In addition it would be nice to a have an ping like mechanism
> which would allow a communicating party to detect failures when needed
> (For example if a gateway detects an SA has been inactive for a period
> of time, it can issue a ping to detect if the client is still
> active).
> 
> Thanks,
> 
> -- sankar --
> 
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Andrew Krywaniuk
> Sent: Sunday, March 26, 2000 12:45 AM
> To: 'Scott G. Kelly'
> Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com
> Subject: RE: Heartbeats draft available
> 
> Hi Scott,
> 
> For your sake, I'll present a list of requirements on Thursday. But don't be
> surprised if they are very similar to the goals of the draft.
> 
> Negotiation is not a requirement of IPsec heartbeats; it is a requirement of
> good protocol design. If there are options, or if there is any possibility
> of needing options in the future, there should be negotiation.
> 
> BTW, Tero and I discussed heartbeat usage scenarios on the IPSRA list back
> in November. Please see the attached message.
> 
> Andrew
> --------------------------------------
> Beauty with out truth is insubstantial.
> Truth without beauty is unbearable.
> 
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Scott G. Kelly
> > Sent: Thursday, March 23, 2000 12:22 PM
> > To: akrywani@newbridge.com
> > Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com
> > Subject: Re: Heartbeats draft available
> >
> >
> > akrywani@newbridge.com wrote:
> > >
> > <trimmed...>
> >
> > > In fact, I investigated using other negotiation protocols
> > for heartbeat
> > > configuration for the simple reason that I knew that using
> > ISAKMP-Config as
> > > transport would result in a silly, straw-man (or rather
> > straw-protocol)
> > > political argument such as this one.
> >
> > Again, this misses the point: you have to explicitly specify the
> > requirements, because otherwise it is not clear that negotiation is
> > required. Only when we understand *why* negotiation is required can we
> > intelligently discuss protocol requirements.
> >
> > Scott
> >
Follow-Ups: References: