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

Re: heartbeats (summary of responses)



Slava Kavsan writes:
> My vote goes to Phase1-based hearbeats using never-going-away IKE
> SAs (or skeletal ones for resource-restricted implementations - just
> enough to protect Informational messages).

I don't think people want to implement "skeletal IKE SAs". More code,
more special cases, uncommon code path == untested code == lots of
bugs...

BTW, I am not really happy having the IKE SA to transfer more and more
data. Currently the IKE can happily be in user mode and use software
encryption, because the amount of data to be transferred is that
small. If we start sending hearbeats inside the IKE message we also
might end up consuming our randomness quite fast. For each IKE message
we need to create random message id and a random nonce. 

> I would also like to suggest using Ack-ed NOTIFY mechanism and not
> to invent yet another scheme. Heartbeat management messages will
> also be useful.

If we really want to have phase 1 heartbeat, I think one way notify
from both ends using negotiated interval is the right way to do.

Anyways I think phase 2 heartbeats are the ones we want to move
forward, and preferredly we are using just normal ping packets to the
some ip-address of the other end.

I.e during the Phase 2 SA negotiation, the initiator or responder will
send REQUEST_HEARTBEATS notify, which contains ip-number and interval
to use inside the notification data field (as data attribute list).

The other one will then start sending those packets using that SA just
negotiated. The ip address must be from the range that is covered by
the quick mode selectors.

Either end can enable it, and the other end will acknowledge the
willingness of doing it by starting to send heartbeats packets. The
requestor can see if the other end is up and running by watching for
those ping packets, and it will reply to them in normal way. If it
never sees any ping packets it must assume that the other end does not
support heartbeats, and disable the feature.
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/


Follow-Ups: References: