[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Heartbeats draft (fwd)
some thoughts on Heartbeats:
SPI lists: I feel that this approach to maintain synchonization between
the SADs of two peers is not going to scale well. It's going to be very
expensive to send the SPI list, and also check the SAD against the SPI
list, as the number of SAs increase. I feel that implementing acknowledged
Notifys is a much more simple and clean solution to the SA synchronization
problem.
Problem being solved: The major problem that is being solved here is
knowing exactly when the peer went down. If we don't have heartbeats, when
a peer goes down, we will continue to send encrypted traffic to the peer,
and even if the peer comes back up, it is silently going to drop all the
encrypted traffic (no SA). First of all, what is the probability that this
situation happens? Can we say reasonably corner case. Second of all even
when this happens we can change the peers behaviour to 'intellegently'
start negotiating the SA with us, with the Initial Contact. I say
'intellegently' in the sense to avoid DOS attacks (but, I guess this is
not a major DOS attack risk).
IMHO, heartbeats would be more useful if we had a list of multiple peers
which support the same trafic flow (redundancy/failover), but I guess this
is getting into too much of implementation detail. It can be left to the
implementations to provide this kind of redundancy. I guess there is no
real customer requirement that IPSec implementations of different vendors
should provide redundancy/failover across vendor implementations.
Regarding the below discussion: One justification for not using a time
stamp with the SPI list given is that the time may not be synchronized
between the different peers. I feel that expecting IPSec peers to be able
to maintain accurate time is a basic requirement for validating
Certificates, and using PKI.
chinna narasimha reddy pellacuru
s/w engineer
---------- Forwarded message ----------
Date: Sun, 26 Mar 2000 03:25:11 -0500
From: Andrew Krywaniuk <akrywani@newbridge.com>
To: 'CHINNA N.R. PELLACURU' <pcn@cisco.com>
Cc: 'Tero Kivinen' <kivinen@ssh.fi>
Subject: RE: Heartbeats draft
Good point. When comparing the SPI list with the SAD, an implementation
should ignore SAs that were negotiated "recently" and SA negotiations that
are still in progress.
The delay attack by an intermediate router is less important because we do
not claim to be able to prevent delay attacks. However, I guess that using
TO_I for the above definition of "recently" would be a good practice
nonetheless.
Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.
> -----Original Message-----
> From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com]
> Sent: Saturday, March 25, 2000 4:01 PM
> To: akrywani@newbridge.com
> Cc: 'Tero Kivinen'
> Subject: Heartbeats draft
>
>
> I feel that the SPI list specification and processing has
> some problems.
>
> For example:
>
> Peer1 Peer2
> HeartBeat Sender (QM Responder) HeartBeat Receiver (QM Initiator)
> Hearbeat with SPI list-----> <----- Final QM message
>
> Suppose Peer1 and Peer2 are negotiating a QM and Peer2 is
> sending Peer1
> the fianl QM message, and Peer1 is the HeartBeat Sender.
> Peer1 will not
> have SPIs corresponding the QM that is being negotiated in
> his SAD yet,
> and so these SPIs won't be in the SPI list. But Peer2 may have just
> finished processing the 2nd QM message, sends out the final
> QM message,
> and then installs the SAs in to it's SAD. Now when the
> HeartBeat reaches
> the Peer2, it won't have the SPIs for the QM that was just
> negotiated, and
> these SHOULD be deleted.
>
> I guess it is important to also communicate some sense of at
> what time the
> snapshot of the SAD is being sent. Or the receiver of the SA
> list must be
> more intelligent about deleting QM SAs that were setup just
> recently (he
> can probably have some upper bound on the SAs age that he
> will delete in
> this situation. This is useful against other kinds of simple
> attacks like
> someone just holding onto a legitimate HeartBeat for some time and
> replaying it. The recommended timeout is 65 seconds, and if
> the attacker
> holds on to the packet for 60 seconds and replays it, then all the QMs
> that were negotiated during that time SHOULD be deleted. The Heartbeat
> packet may also arrive out of order(rarely), and may cause similar
> problems with QM Sas that are being negotiated.
>
>
> chinna narasimha reddy pellacuru
> s/w engineer
>
>
>
Follow-Ups: