Re: [XFRM]: Improve MTU estimation

[Patrick McHardy <kaber@trash.net>]

Herbert Xu wrote:
> On Fri, Aug 04, 2006 at 11:27:11AM +0200, Patrick McHardy wrote:
> 
>>-static u32 esp4_get_max_size(struct xfrm_state *x, int mtu)
>>+static u32 esp4_get_mtu(struct xfrm_state *x, int mtu)
>> {
>> 	struct esp_data *esp = x->data;
>>-	u32 blksize = ALIGN(crypto_tfm_alg_blocksize(esp->conf.tfm), 4);
>>+	u32 align = ALIGN(crypto_tfm_alg_blocksize(esp->conf.tfm), 4);
>> 
>>-	if (x->props.mode) {
>>-		mtu = ALIGN(mtu + 2, blksize);
>>-	} else {
>>-		/* The worst case. */
>>-		mtu = ALIGN(mtu + 2, 4) + blksize - 4;
>>-	}
>>-	if (esp->conf.padlen)
>>-		mtu = ALIGN(mtu, esp->conf.padlen);
>>+	if (esp->conf.padlen > align)
>>+		align = esp->conf.padlen;
>> 
>>-	return mtu + x->props.header_len + esp->auth.icv_trunc_len;
>>+	mtu -= x->props.header_len + esp->auth.icv_trunc_len;
>>+	mtu &= ~(align - 1);
>>+	mtu -= 2;
>>+
>>+	return mtu;
> 
> 
> I haven't actually done the math, but I don't think this can be right
> from a quick look.  The reason is that transport mode is fundamentally
> different from tunnel mode in that the IP options are not encrypted and
> therefore do not contribute to the encryption block padding.
> 
> So as the code doesn't distinguish between transport mode and tunnel
> mode, you might be producing an overestimate for transport mode.


I was wondering why the old code distinguished between transport mode
and tunnel mode, I couldn't spot anything that would be affected. I'll
look into the transport mode case again.