[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Heartbeats draft (fwd)
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.
> 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.
> 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).
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.
> 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.
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.
Plus, you are ignoring all the other benefits you get from using heartbeats.
Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.
Follow-Ups:
References: