[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: heartbeats (summary of responses)
> 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.
Hi Tero,
I forgot to mention this before. I don't think randomness is really an issue
here. It is perfectly valid to use a seeded pseudorandom number generator
without consuming any additional randomness for each heartbeat.
As far as I can tell, there is no security implication to using a
pseudorandom message id. I suspect that the reason why we don't simply use
1,2,3... is actually to avoid collisions and not to generate entropy.
I don't think this should be considered as an important argument against
phase 1 heartbeats.
Andrew
_______________________________________________
Beauty without truth is insubstantial.
Truth without beauty is unbearable.
> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@ssh.fi]
> Sent: Thursday, December 09, 1999 12:37 AM
> To: Slava Kavsan
> Cc: Andrew Krywaniuk; ipsec@lists.tislabs.com
> Subject: 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/
>