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

Re: heartbeats (summary of responses)

Tero Kivinen wrote:

> 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.
>

Tero, consider the case when 2 gateways have many (hundreds or
thousands) tunnels between them. Running phase 2 heartbeats for each
IPSec SA pair between gateways will not scale. You may suggest that
multiple IPSec tunnels between 2 IPSec gateways is not a terribly useful
configuration but it can be done. One the other hand phase 1 heartbeats
do not have the same problem.

>
> 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/

--
+--------------------------------+
|        Leonard Schwartz        |
|       Lucent Technologies      |
|         50 Nagog Park          |
|        Acton, MA 01720         |
|     TEL (978)-263-0060 x150    |
+--------------------------------+
Follow-Ups: References: