[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Heartbeats draft (fwd)
On Wed, 29 Mar 2000, Andrew Krywaniuk wrote:
> Hi Chinna,
>
> > 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 this is really a problem for you then I suggest you invest in some good
> database software.
Please also suggest databases from which vendor are the best for IPSec,
for the benefit of the list. I don't think anyone has explored that yet.
>
>
> > 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.
>
> You don't have to use the SPI list if you don't want to; if you think
> acknowledge delete notifications are sufficient then by all means use them
> (the draft recommends it).
>
> Of course, acknowledged deletes don't work if the peer can't send them. For
> example, the peer may periodically dangle the phase 2 SAs, in which case
> there won't be a phase 1 available on which to send the delete. Alternately,
> the link may have gone down temporarily, in which case the SADs may be out
> of synch.
>
If you have dangling Phase2 SAs you cant do Heartbeats either!
>
> > 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.
>
> As has been pointed out before, the cost of heartbeats is O(n). This is a
> theoretical minimum, and I maintain that any alternate scheme you might
> propose will also be O(n).
The cost for each peer is huge, and O(n) of some huge cost is not cheap.
> Yes, if you have N times as many peers then you also have to send N times as
> many heartbeats. But you are ignoring the fact that you will also have N
> times as many SAs, which means N times as much traffic, which means that you
> need an N times bigger box with N times as much CPU power. And this N times
> bigger box is properly equipped to process N times as many heartbeat
> packets.
>
> And BTW, as technology advances, users will demand more traffic per (phase
> 1) SA. This will result in heartbeat traffic being an increasingly small
> percentage of total traffic.
>
Please don't mix management traffic with real customer traffic. I think in
most implementations we deal with management traffic and real traffic
differently. Even if Heartbeats traffic may look small (one message per
peer, per 20 seconds), we need to make the distinction that it is
management traffic, and no real traffic. In client systems you many not
have such distiction, but in bigger and bigger boxes, we are very very
sensitive to these things.
>
> > 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.
>
> Which means that you will be extra vulnerable to DoS attacks right after we
> restart, which is fine as long as it wasn't a DoS attack which caused you to
> crash in the first place.
>
If a DOS attack caused you to crash, then I don't see how you are not
going to crash again (even if didn't have to deal with the new DOS risk).
> Also, I find it abhorent that an attacker would be able to force me to
> initiate an SA with some arbitrary peer just by sending me an invalid spi
> notify.
Firslty, the proposal is to act on an invalid SPI error condition, and not
responding to an Invalid SPI notification.
We need scalability, and Heartbeats are not going to scale.
>
> Plus, you are ignoring all the other benefits you get from using heartbeats.
What benefits? I cant use them in dialer environments anyway.
-chinna
>
> Andrew
> --------------------------------------
> Beauty with out truth is insubstantial.
> Truth without beauty is unbearable.
>
>
>
chinna narasimha reddy pellacuru
s/w engineer
References: