[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Heartbeats draft (fwd)
If we have acknowledged notifies (all types of notifies, particularly delete
notifies, as proposed in the new IKE revision), then I don't see why the SADs
are going to get out of sync, except in just one case where one of the peer goes
down.
When one of the peer goes down, and comes back up, as I said before, the peer
that went down can ("intellegently") initiate fresh SAs with the Initial
Contact, and both the peers are going to sync their SADs again.
So, I feel that to solve the problems that this draft is trying to solve, we do
not need Heartbeats at all.
We have implemented "keepalives" in our implementation, and our experience is
that "keepalives" can be very expensive.
-chinna
Andrew Krywaniuk wrote:
> Hi Chinna,
>
> > 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.
>
> I assume that you are advocating sending an acknowledged notify every time
> you receive an invalid SPI message? The problem with this is that it is too
> promiscuous in allowing an attacker to elicit a response from a spoofed
> message.
>
> Let me suggest that you instead keep track of the invalid SPIs you receive
> during a heartbeat interval then send SPI lists for each one in the your
> next heartbeat message. (But up to a certain maximum, since you don't want
> to allow the attacker to suck up all your memory.)
>
> > 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).
>
> But that's what the basic heartbeat protocol is for. The SPI list is an
> optional payload that performs an additional function (SAD synchronization).
> If you just want to know when the peer as a whole is dead, then don't
> request to receive the SPI list.
>
> > 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.
>
> Yes. This is one of the issues I was planning to bring up at the meeting.
> The difference between validating heartbeats and validating certificates is
> that for heartbeats, the time has to be synchronized within a few seconds
> (whereas the requirements for validating certificates are not necessarily so
> rigid).
>
> Also, certificates are administered by an SA, so it is clear that the time
> on the certificate is based on the CA's time. Heartbeats do not require
> PKIs, and they are not bound to a particular CA time; therefore, there is
> room for confusion.
>
> One thing I considered is that the receiver could ask the sender to send him
> the current time (encoded as a second count... presumably in the C standard
> library format). Then the sender would store the offset between the two
> times.
>
> Comments, anyone? Would this be better than using sequence numbers?
>
> Andrew
> --------------------------------------
> Beauty with out truth is insubstantial.
> Truth without beauty is unbearable.
>
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of CHINNA
> > N.R. PELLACURU
> > Sent: Monday, March 27, 2000 4:51 PM
> > To: ipsec mailling list
> > Subject: 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:
References: