[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Son-of-IKE Performance
Eric, good summary!
One comment about latency and RTT.
What you count as latency is the total number of round trips in
the protocol. However, note that if you define latency
as the time it elapses from the moment the initiator sends its
first message until it has an active SA then the numbers in the
table change. In particular, SIGMA gets a SINGLE RTT (or two in DoS mode).
Now, in relation to SIGMA having an odd number of messages: I am now
convinced that an even number is good to preserve an healthy
request-response approach. This is easy to obtain in SIGMA: just add a
fourth message with an (authenticated) ACK from R to I. So now we have
four messages, but the initiator is free to start using its SA
(for protecting IPsec traffic) already after sending the third message
(i.e after 1 RTT). In most cases, R will have its SA ready when I's IPsec
traffic starts arriving. On the other hand, when network conditions call
for it, the initiator may wait for the ACK to arrive before sending IPsec
traffic.
In this case, we have 4 messages in the protocol, we provide a full
req/resp design, and yet the initiator has a latency of only 1 RTT
until it creates the SA (also R has 1 RTT latency since the time it
sends its first message until it creates its SA)
If this notion of latency is significant (isn't it?) then SIGMA
has a real latency advantage over the other proposals (including
my last "merge" proposal). In all these protocols this latency
is 2 RTTs for the initiator and 1.5 for responder.
Makes sense?
Hugo
Follow-Ups:
References: