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]
Message-ID: <20190312050842.b3g4il2zvpwnyox4@gondor.apana.org.au>
Date:   Tue, 12 Mar 2019 13:08:42 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     David Miller <davem@...emloft.net>
Cc:     andrew.boyer@...l.com, aboyer@...ark.org, netdev@...r.kernel.org,
        Farrell.Woods@...l.com, steffen.klassert@...unet.com
Subject: Re: [PATCH] net/ipv6: Skip policy check to improve compliance

On Sun, Mar 10, 2019 at 11:47:47AM -0700, David Miller wrote:
> From: Andrew Boyer <andrew.boyer@...l.com>
> Date: Fri,  8 Mar 2019 14:01:11 -0500
> 
> > From: Farrell Woods <farrell_woods@...l.com>
> > 
> > The patch fixes an IPv6 conformance test failure (v6LC_1_2_03a in the
> > UNH INTACT suite) that occurs specifically when IPsec is in use.  The
> > test iterates through the set of unassigned protocol numbers (currently,
> > 143 through 252) and inserts these into the next header field of a
> > Destination Options header.  The expected test result is that an
> > ICMPv6 Parameter Problem is sent back.  But if there's a policy in
> > place that requires an active SA between the Test Node and the
> > Device Under Test (and none exists), the inbound packet is quietly
> > dropped.
> > 
> > Signed-off-by: Farrell Woods <farrell_woods@...l.com>
> 
> First of all, please CC: the IPSEC maintainers on all IPSEC changes.
> 
> Second of all, is the conformance test setting up these IPSEC rules?

On the face of it I don't see why we shouldn't be dropping the
packets when there is a relevant IPsec policy in place as to do
otherwise makes us vulnerable to DoS attacks.

Please provide a rationale why such packets should *not* be dropped
based on a relevant RFC document.

Thanks,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ