[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Heartbeats draft available
> -----Original Message-----
> From: Sankar Ramamoorthi [mailto:SRamamoorthi@netscreen.com]
> Sent: 27 March 2000 04:59
> To: akrywani@newbridge.com; 'Scott G. Kelly'
> Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com
> Subject: RE: Heartbeats draft available
> 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?
This depends on the requirements.
In general there will be a phase 1 SA and some number of dependent phase 2
SAs.
I think in a lot of cases that these SAs will go up/down (fail) as a group.
This isn't going to be the only case though as some implementations drop
phase 1s or drop individual phase 2 SAs if resource limited. In the latter
case, forcing a SGW to renegotiate while resource limited isn't the kindest
thing to do.
If the 'atomic' failure assumption can be held then you only need traffic on
any authenticated SA to satisfy yourself that remaining SAs are still up.
This might mean that heartbeats only need to be sent in the absence of
regular traffic. The main problem with this is that you need to associate
the traffic back to the group of SAs and this might not be accounted for
currently. Heartbeats are end-to-end and could be transmitted in transport
mode. The phase 1 SA is essentially 'transport'. The alternative is to set
up an extra ESP (tunnel or transport) SA between the peers. This is
undesirable as it consumes a deal of resource for relatively little benefit.
I don't think hijacking 'customer' SAs is an alternative. This would
require addresses to be reserved from both ends of the SA for the keep-alive
protocol. This is not possible in the general case and would cause
management problems beyond the SGW.
If you have a definite need to know about the status of individual SAs then
you could run keep-alives down every open SA but I've already objected to
this. The draft proposes that the peer periodically sends you his complete
list of open SAs. I think this is much more reasonable, though it means
that keep-alives must be sent regularly, regardless how much other traffic
is sent. If the open-SA list is split across multiple keep-alives then the
individual keep-alive messages can be kept as small as desired.
> 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.
The keep-alive protocol is for the benefit of the requestor (so it can
release dead resource or renegotiate). All that needs to be negotiated is
the frequency at which keep-alives are to be transmitted. The remaining
parameters are local to requestor.
> 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?
These sorts of decisions are down to the equipment in question. It's not
something that need be negotiated. Failure of the transport is a problem -
as are intermittent transports like ISDN. The heart-beat protocol is
designed to be a secure (authenticate) means for positively identifying the
liveness of SAs. It can't hope to determine positively that an SA is dead.
The decision on whether to maintain, drop or renegotiate an SA depends on
the requirements of the user. Some users might need a high-availability
service and would wish SAs to be renegotiated if the SA were quiet for a few
seconds.
Intermittent services like ISDN present special problems. The last thing a
user will want is for the heartbeat protocol to keep the ISDN link up
perpetually! I don't know whether people will want to address these issues.
My thoughts are that the protocol should be capable of being able to be
suspended or 'slept' to suspend or back off the keep-alives during periods
when the line would be otherwise idle.
> Heartbeat protocol also seem to be a very proactive way of detecting
> failures.
Yes, though not necessarily SA failures in particular and, if the
keep-alives are easily identified, open to abuse by an attacker. It
provides proof of liveness.
> 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).
There is ping already. I'm not sure of the benefit of adding more than
this. An operator could attempt to ping between the various interfaces of
the SGW and client. Where this is done manually there aren't the same
concerns about hijacking etc.
Chris
> Thanks,
>
> -- sankar --
Follow-Ups: