Herbert Xu wrote: > I've reread your patches and your handling of ESP padding is spot on. > It's anyone's guess whether the current code gets it right or not :) > > However, I believe that the transport mode handling does run into > problems with IP options. Basically, your calculation returns a > length that is a precise multiple of block size minus 2. > > Now imagine that we have 4 bytes of IP options, given a block size > of 8 taking away 4 bytes from inside the encrypted area simply causes > them to be padded out so the encrypted length does not change. However, > we have to put those 4 bytes outside the encrypted area. The problem is > that we may not have those 4 bytes given the MTU. > > For a standard 1500 MTU and the block size of 8 it just happens that > we do have 4 bytes (because 1500 % 8 == 4). However, this breaks down > if you start with say 1480 (standard MTU for 1500 with IPIP on the > outside). > > You run into problems even with 1500 if your block size happens to be > 16 (AES).
Now I get it, thanks :) I missed that the IP header isn't part of the length when it is aligned. So the worst-case increases by block-size - 4 (- 8 for IPv6). How does this look? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
