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

> Jan, we are not back to the commit bit.
> This is why you have the ACK from R to I.
> 
Is that a MUST? If not, we ARE back to optional commit-bits. I don't remember
seeing an ACK in the 'draft'.

> I am just saying that an initiator, I, MAY start sending
> ipsec data after the third message, it does not have to.
> 
I would claim that's broken. The draft should state disallow that. At LEAST
it should point out all the potential problems this will cause.

> 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.
> 
The exchange needs to have an even number of messages to data packets don't
get lost, as they almost certainly will with out the ACK. The ACK MUST not be
optional, and traffic MUST NOT be sent by the initiator before the ACK is
received.

I'm no expert, but the above reflects my experience dealing with live
networks and implementing IKE.

jan




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

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



References: