[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Heartbeats draft (fwd)
Chris Trobridge wrote:
> > -----Original Message-----
> > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com]
> > Sent: 27 March 2000 22:51
> > 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
>
> This is only the list of SPIs from on peer to the other - I don't see any
> great need for this to grow dramatically. Even if it is large, the protocol
> allows for a portion of the list to be transmitted each time. In this way
> the processing effort can be maintained at a constant level at the expense
> of a longer verification period.
The number of quick mode SAs between two site to site security gateways can grow
dramatically, and because the SPIs are completely randomly allocated, we have to
essentially walk through all SPIs that we have with a particular peer, and then
send the SPIs that are in a particular range. I don't see any real saving in
processing here, although there is saving on the receiving side. And I don't see
how we can cleanly comeup with ranges of SPIs that will actually divide the SPIs
that we have with a peer as we intend to (or atleast reasonably equally),
because SPIs are supposed to be completely random. If we use acknowledged delete
notifications, the we pretty much don't have to worry about any SAD sync issues,
for most of the time. The only place we need to deal with them would be when a
peer goes down.
> The point about the heartbeat protocol is that it is relatively resistent to
> DOS attacks. This is particularly true if the heartbeat traffic is
> indistinguishable from regular traffic. In this case it can't be
> selectively deleted and limits the possibility of holding back traffic. In
> any case if an attacker can delete and insert datagrams at will then there
> are plenty of attacks he can make.
>
> Where the heartbeat protocol is stronger is that it can't be provoked into
> generating traffic or renegotiating SAs by spoofed traffic. If one peer has
> gone down then the 'cheap' basis for authentication has gone. This means
> that spoofed traffic can force either one end to generate an expensive
> signature or the other end to renegotiate SAs, depending on whether
> authentication is used or not.
>
Firstly heartbeats are not going to be 'cheap', atleast from our experience they
are not cheap even without the equivalent of SPI lists. If you had a lot of
peers, and if you use the recommended heartbeat interval of 20 seconds, then the
box is sending/processing a considerable amount of heartbeat traffic.
Coming to DOS vulnerability, I am not advocating that we should try and
negotiate SAs for invalid SPI errors all the time. We can "intellegently"
initiate SAs only when we detect that we recently restarted, and limit the
number of times we initiate to a particular peer. I don't think that this is a
major DOS risk, and can be easily bounded, if we are smart about it. We can use
techniques used similar to what we use to prevent against DOS attacks, when we
are responding.
Somehow, the argument that we will send out a heartbeat to every peer, once
every 20 seconds (a lot of processing and traffic), to save ourselves against
DOS attacks, is not very logical to me.
-chinna
>
> Chris
Follow-Ups:
References: