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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAJFZqHzCEJyvxc2NNh3_U8oT9Uh94N6EXLb4UA=twvVcVnEd5w@mail.gmail.com>
Date:	Mon, 17 Dec 2012 14:56:47 +0800
From:	RongQing Li <roy.qing.li@...il.com>
To:	Steffen Klassert <steffen.klassert@...unet.com>
Cc:	netdev@...r.kernel.org
Subject: Re: XFRM: Could we change ESP padding?

2012/12/17 Steffen Klassert <steffen.klassert@...unet.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
--
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