netdev - Re: [RFC PATCH] xfrm: avoid to send/receive the exceeding hard lifetime data

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:	Fri, 14 Dec 2012 14:58:03 +0800
From:	RongQing Li <roy.qing.li@...il.com>
To:	Steffen Klassert <steffen.klassert@...unet.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC PATCH] xfrm: avoid to send/receive the exceeding hard
 lifetime data

2012/12/13 Steffen Klassert <steffen.klassert@...unet.com>:
> On Thu, Dec 13, 2012 at 04:25:52PM +0800, roy.qing.li@...il.com wrote:
>> From: Li RongQing <roy.qing.li@...il.com>
>>
>> If setkey sets both bh and bs as 1024, and the total send and receive package
>> size is 1024, then if next package size is too large, this package should be
>> discard.
>>
>> Example, first package size is 1000, send success, then the second package
>> is 500, 1000+500 is larger than 1024, so the second package should be discard.
>>
>> Signed-off-by: Li RongQing <roy.qing.li@...il.com>
>> ---
>>  net/xfrm/xfrm_input.c  |    6 +++---
>>  net/xfrm/xfrm_output.c |    6 +++---
>>  2 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
>> index ab2bb42..d0de8f3 100644
>> --- a/net/xfrm/xfrm_input.c
>> +++ b/net/xfrm/xfrm_input.c
>> @@ -178,6 +178,9 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
>>                       goto drop_unlock;
>>               }
>>
>> +             x->curlft.bytes += skb->len;
>> +             x->curlft.packets++;
>> +
>
> This is a bit critical on input. We should only increment these values
> if the integrity check on this packet was successfull. Otherwise someone
> could spam us with invalid packets and trigger a state expiry.
>
> If a synchronous crypto algorithm is used, we send at most one packet too
> much. The maximal byte count was not yet reached and RFC 2401 says not
> much on how to handle the packet that reaches the maximal byte count,
> so this is probaply ok.
>

Yes, RFC does not say how to handle this packet.

But when I do a IPsec compliance test with IxANVL, the test case 5.3/5.11,
which reports a error because it expects this packet should be dropped, but not.


I do not know if it is bug, or if it is valuable to fix it?

-Li

> But if an asynchronous crypto algorithm is used, we can send a lot
> of packets too much. So we should probaply add a second expiry check
> after resume from asynchronous crypto. We do this already with the replay
> check.
>
--
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