[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