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

Re: Heartbeats draft available



On Mon, 27 Mar 2000, Ari Huttunen wrote:

> The heartbeat draft seems unnecessarily complex. The easiest way
> the functionality could be achieved would be to do the following
> in phase 2 SAs:
> a) Monitor incoming traffic from the peer. If replay protection is
>    enabled, any acceptable packet proves liveness.
> b) If no traffic is incoming (because the peer has nothing to
>    send, or it's down, we don't know yet) we send something very
>    much like an ICMP-EchoRequest, and expect an ICMP-EchoReply.
>    This can also prove liveness without replay protection, provided
>    proper usage of the sequence number field in a echo request/reply
>    field is provided. (The actual messages sent could be real ICMP 
>    messages, or functional equivalents.)
> 
> The reason this doesn't already work in all cases is that some
> SAs won't allow ICMP messages through. This could be fixed my
> updating the IKE minor version number, so that the higher version
> always allows echo requests/replys to be sent over any phase 2 SA,
> provided that the recipient is *exactly* the interface with which
> a connection has been negotiated. (Not another interface in the box.)
> Only if both peers have the minor version number that includes
> the capability to do this, will actual messages be sent. (Unless the
> SA can already handle ICMP messages, in which case no new functionality
> is needed.)
> 

And you say the HAERTBEAT draft is too complex?! I'd say the above paragraph
proves that what you're suggesting is even more complex ("provided ..",
"unless...", etc..).

Personally, I'm against using a phase 2 for keepalvies. If the user of the
tunnel wants to send icmp echo's, that's they're perogative, but I am against
doing this on behalf of the tunnel-user 9for lack of a better way to put it).

Why? Accounting issues for one, as has been raised in the past. You use up
the SA with keepalives. Say you are a reseller of ipsec services, and your
customer contracted for a certain amount of traffic. You are now stealing
from them to send keepalives. Yes, you could then add a keepalives option to
the contract and you could all agree to do this, but then you really have to
start wondering about the complexity not only in configuration but also in
code to handle all the different variants of doing keepalives (send echo on
same SA? different SA? Does it count as customer traffic in accounting? Does
it not?).

Doing the keepalives in phase one between the peers is much cleaner.

jan


> This has some nice properties. First, there is no need to negotiate
> anything in addition to the minor version number. Both peers will simply
> hold their own timers for the peer's liveness. If the timer is about to
> expire, a ping will be sent. If replay protection is enabled, an echo
> request is enough the reset the timer on the peer that receives it.
> This should provide minimum traffic between the peers(?).
> 
> An echo request/reply on a phase 2 SA has also another nice property.
> You could use it to measure the quality of service available on that
> particular connection. Measure the exact time when you send the echo
> request, then wait until you receive the corresponding reply. You can't
> use one-way heartbeats for this, because the clocks won't be in sync.
> And a phase 1 SA can't do it, because it can't take into consideration
> that some phase 2 SAs have more traffic than others. Besides, the
> problem about expired phase 1 SAs goes away.
> 
> I don't see any requirement why a phase 1 SA would need a similar
> mechanism. If you try to use it to set up phase 2 SAs, and it's
> expired, you'll soon enough notice this anyway.
> 
> Ari
> 
> "Scott G. Kelly" wrote:
> > 
> > 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
> > > >
> 
> -- 
> Ari Huttunen                   phone: +358 9 859 900
> Senior Software Engineer       fax  : +358 9 8599 0452
> 
> F-Secure Corporation       http://www.F-Secure.com 
> 
> F-Secure products: Integrated Solutions for Enterprise Security
> 

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



Follow-Ups: References: