[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Son-of-IKE Performance
Hugo Krawczyk <hugo@ee.technion.ac.il> writes:
> 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.
It's a clever idea but I suspect too clever :)
The problem is that if the first encrypted packet arrives before the
responder establishes the SA then the packet will be dropped. This
creates pathological conditions. For instance, if the first encrypted
packet is a TCP SYN then the retransmit won't happen for 500ms, which
is usually greater than 1RTT.
Obviously, it's worth taking this chance if it almost never happens in
practice, but I think the opposite is true--the first encrypted packet
will arrive before the SA is established quite frequently.
Jan brings up the point that the key exchange messages and the data
messages may be reordered (perhaps due to QoS reasons) but there are
implementation reasons to believe that this will be a problem as well.
Recall that the SA isn't installed by the responder as soon as message
3 arrives. At the very least certificates and signature have to be
verified. Additionally, since the key exchange is typically implemented
in some daemon, the data has to be passed up into user space and then
the daemon needs to call down to the kernel to set up the SA.
This all takes time (possibly 10s of ms for the signature
verification alone). Interpacket arrival times on fast networks are
often very short and there's a significant probability that even if
the data packet arrives after message 3 it will already have been
rejected before the new SA is installed.
In short, what you propose might be safe under certain circumstances
but I suspect that the average case behavior will be worse than just
waiting the extra RTT.
-Ekr
Follow-Ups:
References: