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

Re: Son-of-IKE Performance

Jan, we are not back to the commit bit.
This is why you have the ACK from R to I.

I am just saying that an initiator, I, MAY start sending
ipsec data after the third message, it does not have to.

In any case, I was offering this as a possible feature
to be used at the discretion of the initiator.
But this is not my area of expertise, so I am really
asking for feedback from the experts.

Thanks,

Hugo

On Wed, 5 Dec 2001, Jan Vilhuber wrote:

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