[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Heartbeats draft available
Hi Sankar,
> The other redundancy concern I have is about the symmetric nature
> of the described heartbeat protocol. Should two communicating parties
> have to independently negotiate heartbeat protocol if they want to
> ensure the other one is alive?
The fact that the heartbeats are negotiated separately in each direction
makes the negotiation very simple.
The original design of the protocol had an "optimized" negotiation mode
whereby the peers could negotiate heartbeats in both directions using a
single config transaction.
However, we removed this option because it added complexity to the protocol
(needing to have a backoff method to resolve simultaneous initiation), but
without significant benefit (no reduction in latency, slight reduction in
traffic).
> Also is the effect really small as you describe?
> Consider a gateway hosting lots of clients. Eack IKE SA to
> the client is
> separate. If all clients were to send 'notify active'
> periodically, would'nt
> it add up to considerable overhead on the gateway to process
> the keep-alive
> packets, verify the hash... The scaling problem worsens if the gateway
> negotiates for a smaller 'notify active' time interval.
The scaling is O(n), which is as optimal as you can expect. Are you
suggesting multicasting to improve scaling? (multicast and security don't go
together very well)
Note that this correlates with the expected CPU power required to support
large numbers of SAs, which is O(n) or greater.
BTW, the purpose of negotiating the heartbeat interval is to ensure that
neither peer is overloaded by the extra traffic (which is unlikely, BTW --
this is discussed in the draft).
> The complexity is in determining the acceptable heartbeat interval
> beforehand. How can the gateway determine the suitable acceptable
> interval to be negotiated? A time of 2 hours may look appropriate
> in the begining (to allow the gateway to be not overly sensitive to
> link, router failures..), but as the load on the system increases
> it may want to clean up stale SAs at a faster rate.
I wouldn't really qualify that as complexity. I suggest that you always use
the same heartbeat interval (2 hours is way too long -- the draft suggests
20 seconds).
BTW, the primary purpose of the protocol is not to reduce memory usage from
stray state (although, that is an intended side-effect), but rather to
ensure that a loss in connectivity is detected in a secure and timely
manner.
> Why does it require double the bandwidth? With a stateful
> Request/Reply
> protocol the sender of the request/reply message could send it only
> when needed - that should actually save processing time and bandwidth.
A stateful request/reply protocol WITH A SEQUENCE NUMBER AND HEARTBEAT
INTERVAL requires double the bandwidth. Without that shared state, you are
succeptable to DoS. With the state you have a fixed overhead per peer.
> This fixed overhead is per remote peer. Is it scalable?
It is O(n) or less. In other words, yes.
> I did not get it. Why are we mixing up these pings with user traffic?
> If done correctly the client would see the ping from the gateway -
> reprime its inactivity timer and not a send a ping to the gateway.
>
> Also the inactivity timeout has no bearing on SA lifetime - right?
If you send the ping on a phase 2 SA that is not clearly identified as a
"management only" SA then it is easy to mix up the heartbeat with user
traffic.
BTW, I don't think you understand what I mean by inactivity timer. The
inactivity timer is meant to delete a phase 2 SA if it has gone for a long
time without receiving any NON-MANAGEMENT traffic.
If you send management traffic on a user SA then you are defeating this
potentially useful mechanism on the peer.
Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.
References: