[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Son-of-IKE Performance

On Thu, 6 Dec 2001, Hugo Krawczyk wrote:

> 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 disagree. The purpose of the ACK is to tell you that the resonder is now
ready to accept traffic, i.e. the incoming Sa is set up. All the initiator
can do when sending msg3 is start ACCEPTING traffic on an incoming SA. It
can't make any assumptions about the state at the responder.

> (i.e after 1 RTT).  In most cases, R will have its SA ready when I's IPsec
> traffic starts arriving.

But not in all cases. I would actually claim the reverse. In almost all
cases, data traffic sent by the initiator and key-exchange traffic sent by
the initiator will likely be processed in reverse order due to potential
network packet reordering and processing-paths of data versus control on the
responder (unless you build in a delay between sending msg3 and data traffic,
but that sounds even worse).

Consider voice traffic, which may have a higher quality of service than the
key-exchange traffic. I can almost guarantee that the encrypted voice traffic
will arrive before your msg3 is even seen...

Can the responder (and would it be wise to do so) install it's SA's after
sending msg2?

> On the other hand, when network conditions call
> for it, the initiator may wait for the ACK to arrive before sending IPsec
> traffic.
> 
Great. And we're back to all the debates spawned by the commit-bit in quick
mode.


> 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

If you discount possible data-traffic loss due to the first few data packets
being lost because the responder isn't ready, yes. Otherwise, no.

I claim that any key exchange protocol with an uneven number of messages is
inherently unstable. The extra packet may cost you to wait an extra
round-trip but buys you a lot of stability and lack of packet loss (there's
enough of that. We don't need to add to it).

jan



> (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
> 
> 
> 
> 

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847
Follow-Ups: References: