Re: XFRM: Could we change ESP padding?

[RongQing Li <roy.qing.li@gmail.com>]

2012/12/17 Steffen Klassert <steffen.klassert@secunet.com>:
> On Mon, Dec 17, 2012 at 11:28:05AM +0800, RongQing Li wrote:
>> Hi:
>>
>> setkey has the below parameter, but this parameter seems not be
>> implemented in kernel and userspace,
>>
>>      -f pad_option  defines the content of the ESP padding.
>> pad_option is one of following:
>>         zero-pad    All the paddings are zero.
>>         random-pad  A series of randomized values are used.
>>         seq-pad     A series of sequential increasing numbers
>>  started from 1 are used.
>>
>
> We can not implement this. As you already mentioned, RFC 4303
> makes strong statements on how the padding bytes are initialized.
> An IPsec implementation that checks the padding bytes would drop our
> packets if we don't use the padding method described in RFC 4303.
>
>>
>> and kernel seems not inspect the ESP padding content too, the result
>> is the packets are not dropped even if they are with a wrong pad
>> content(not a monotonically increasing sequence).
>>
>>
>> Could anyone tell me why, bad description in RFC, performance, lack time,
>> or other reason? Thanks very much!
>>
>
> RFC 4303 says that the receiver should inspect the padding field,
> so we are free to do it or not. You can find a comment that explains
> why we don't do it in the esp_input_done2() function ;-)
>
Thanks.

But I see BSD has implemented it, and cisco device has similar implmentation.

http://fxr.watson.org/fxr/source/netipsec/xform_esp.c

-RongQing