XFRM: Could we change ESP padding?

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.


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!


RFC4303:
If Padding bytes are needed but the encryption algorithm does not
specify the padding contents, then the following default processing
MUST be used.  The Padding bytes are initialized with a series of
(unsigned, 1-byte) integer values.  The first padding byte appended
to the plaintext is numbered 1, with subsequent padding bytes making
up a monotonically increasing sequence: 1, 2, 3, ....  When this
padding scheme is employed, the receiver SHOULD inspect the Padding
field.  (This scheme was selected because of its relative simplicity,
ease of implementation in hardware, and because it offers limited
protection against certain forms of "cut and paste" attacks in the
absence of other integrity measures, if the receiver checks the
padding values upon decryption.)


Thanks

-RongQing

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 ;-) 

2012/12/17 Steffen Klassert [off-list ref]:

On Mon, Dec 17, 2012 at 11:28:05AM +0800, RongQing Li wrote:

quoted

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.

quoted

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

On Mon, Dec 17, 2012 at 02:56:47PM +0800, RongQing Li wrote:

2012/12/17 Steffen Klassert [off-list ref]:

quoted

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.

The comment at the place where the padding field inspection should be done
is rather old. I always respected this when I came accross this code, but
I would not mind to have it implemented. Not sure if somebody still
remembers exactly why it was not implemented.