netdev - Re: XFRM: Could we change ESP padding?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Dec 2012 07:43:02 +0100
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	RongQing Li <roy.qing.li@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: XFRM: Could we change ESP padding?

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

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