[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20100926.184654.232737330.davem@davemloft.net>
Date: Sun, 26 Sep 2010 18:46:54 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: herbert@...dor.apana.org.au
Cc: kaber@...sh.net, eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: ESP trailer_len calculation
From: Herbert Xu <herbert@...dor.apana.org.au>
Date: Sat, 25 Sep 2010 14:23:17 +0800
> The number 17 does look very strange, however, after going through
> the logic it does seem correct.
>
> To calculate the minimum safe trailer length we need to consider
> the worst-case scenario, and that is a packet where the payload
> just happens to be one byte less than the cipher block size.
>
> ESP always adds two bytes, then pads to at least the cipher
> block size, follwed by the authentication value. So in the
> worst case we need to add
>
> 2 + (blocksize - 1) + authlen =
> blocksize + 1 + authlen
>
> which is exactly what Patrick's patch does.
Thanks for explaining this Herbert, but I have to admit it's a bit
disappointing :-)
So what we have is that headerlen is actually a function f() which
depends upon the payload length and the size of any IP options, rather
than a fixed value that can be computed based upon the cipher
blocksize, encap mode, and device MTU.
I guess if we really cared about this we could make headerlen a method
rather than a value, but I doubt it's that much of an issue.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists