[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on ESP and AH IPSEC drafts.
>Isn't it true that the most common (as opposed to most general) case
>is that these fields can be removed from the mbuf chain by simply
>decreasing the byte count in the last mbuf? Like Van Jacobson's
>fast-path TCP code, you look for the common case first and do it
>quickly. Then, 95% of the time, you don't have to search the chain
>twice, or release any trailing whole mbuf's.
>
Finding the payload type and padding length is very simple and I wouldn't
mind leaving them at the end. It has been rare, in my experience, that the
payload type and padding length have been split between MBUFs. The problem
is the padding itself. It could be spread out over up to three MBUFs if
your driver fills out MBUFs completely, which drivers don't. You won't
know this until you're at the end of the chain. The best case is when the
padding is small and the chain is filled out such that the padding is
included with the signature and trailing data in the last MBUF along with 1
or more bytes of the payload. In reality, this happens very infrequently.
In any other case you must manipulate MBUFs that are before you in the
chain. Someone else mentioned that if you're driver gives you the packet
in a cluster, you're all set. This is true in most cases where MTU is
smaller than your cluster size, but if your clusters are less than 1/2 your
MTU, you'll have the same problem. For instance, an MTU size of 4352 for
FDDI and an implemenation with clusters of 2048 bytes.
>By the way, intuitively it seems that this kind of bookkeeping
>overhead contributes insignificantly to poor performance;
True, that these gyrations add little compared to the encryption itself.
But every little bit helps and the bookkeeping and operations aren't
necessary if the padding is up front.
As far as the IV being optional and the Replay field being optional in AH
is that we have a variable option in the middle of a fixed header. If we
are going to allow for IV's optionally in the header, then I think this
should be in a fixed header for another transform. As far as AH goes, if
we are going to keep an optional replay field, we should move the replay
field to the end of the AH header, after the signature.
Why is the AH replay field 64 bits anyway?
-Rob