[PATCH net] ipv6: revert degradation in IPv6 Ready Logo test results

[PATCH net] ipv6: revert degradation in IPv6 Ready Logo test results

[Mike Manning]

This reverts commit 0ed4229b08c1 ("ipv6: defrag: drop non-last frags
smaller than min mtu"). While one should not get fragments smaller than
the IPv6 minimum MTU, not handling crafted packets in the TAHI IPv6
conformance test suite (v6eval) for IPv6 Ready Logo results in 18
failures representing over 5% of the score.

Cc: Florian Westphal <fw@strlen.de>
Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
---
The failures which are reverted by this fix are:

Section 1: RFC 2460 - IPv6 Specification
Test v6LC.1.2.4: Extension Header Processing Order
33-34
Test v6LC.1.3.1: Fragment Reassembly
67-72
Test v6LC.1.3.2: Reassembly Time Exceeded
73-76
Test v6LC.1.3.3: Fragment Header M-Bit Set, Payload Length Invalid
78

Section 5: RFC 4443 - ICMPv6
Test v6LC.5.1.6: Erroneous Header Field (Parameter Problem Generation)
20 Erroneous Header Field (Parameter Problem Generation)
Test v6LC.5.1.10: Error Condition With Multicast Destination
31 Part B: Echo Request Reassembly Timeout
Test v6LC.5.1.11: Error Condition With Non-Unique Source - Unspecified
35 Part C: Echo Request Reassembly Timeout (Routers and Hosts)
Test v6LC.5.1.12: Error Condition With Non-Unique Source - Multicast
40 Part C: Echo Request Reassembly Timeout (Routers and Hosts)
Test v6LC.5.1.13: Error Condition With Non-Unique Source Anycast (Routers Only)
45 Part C: Echo Request Reassembly Timeout

 net/ipv6/netfilter/nf_conntrack_reasm.c | 4 ----
 net/ipv6/reassembly.c                   | 4 ----
 2 files changed, 8 deletions(-)

diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 8f68a518d9db..8c69c4fc78d8 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -559,10 +559,6 @@ int nf_ct_frag6_gather(struct net *net, struct sk_buff *skb, u32 user)
 	hdr = ipv6_hdr(skb);
 	fhdr = (struct frag_hdr *)skb_transport_header(skb);
 
-	if (skb->len - skb_network_offset(skb) < IPV6_MIN_MTU &&
-	    fhdr->frag_off & htons(IP6_MF))
-		return -EINVAL;
-
 	skb_orphan(skb);
 	fq = fq_find(net, fhdr->identification, user, hdr,
 		     skb->dev ? skb->dev->ifindex : 0);
diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index 5c5b4f79296e..b4e558ab39fa 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -456,10 +456,6 @@ static int ipv6_frag_rcv(struct sk_buff *skb)
 		return 1;
 	}
 
-	if (skb->len - skb_network_offset(skb) < IPV6_MIN_MTU &&
-	    fhdr->frag_off & htons(IP6_MF))
-		goto fail_hdr;
-
 	iif = skb->dev ? skb->dev->ifindex : 0;
 	fq = fq_find(net, fhdr->identification, hdr, iif);
 	if (fq) {
-- 
2.11.0

Re: [PATCH net] ipv6: revert degradation in IPv6 Ready Logo test results

[David Miller]

From: Mike Manning <mmanning@vyatta.att-mail.com>
Date: Tue,  2 Oct 2018 12:40:30 +0100

> This reverts commit 0ed4229b08c1 ("ipv6: defrag: drop non-last frags
> smaller than min mtu"). While one should not get fragments smaller than
> the IPv6 minimum MTU, not handling crafted packets in the TAHI IPv6
> conformance test suite (v6eval) for IPv6 Ready Logo results in 18
> failures representing over 5% of the score.
> 
> Cc: Florian Westphal <fw@strlen.de>
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>

Sorry, I'm not just going to blindly apply a patch because some
TAHI tests fail.

It's possible the TAHI tests are wrong, or that the specification
elements it is testing don't make any sense these days.

Allowing all kinds of random junk in the middle of the fragment queue
leads to lots of unnecessary cpu overhead and potential bugs, and it
triggerable remotely.

Re: [PATCH net] ipv6: revert degradation in IPv6 Ready Logo test results

[Mike Manning]

On 02/10/2018 19:26, David Miller wrote:
> From: Mike Manning <mmanning@vyatta.att-mail.com>
> Date: Tue,  2 Oct 2018 12:40:30 +0100
>
>> This reverts commit 0ed4229b08c1 ("ipv6: defrag: drop non-last frags
>> smaller than min mtu"). While one should not get fragments smaller than
>> the IPv6 minimum MTU, not handling crafted packets in the TAHI IPv6
>> conformance test suite (v6eval) for IPv6 Ready Logo results in 18
>> failures representing over 5% of the score.
>>
>> Cc: Florian Westphal <fw@strlen.de>
>> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
> Sorry, I'm not just going to blindly apply a patch because some
> TAHI tests fail.
>
> It's possible the TAHI tests are wrong, or that the specification
> elements it is testing don't make any sense these days.
>
> Allowing all kinds of random junk in the middle of the fragment queue
> leads to lots of unnecessary cpu overhead and potential bugs, and it
> triggerable remotely.

Understood, thank you.

It would be great if there is someone on this mailer who has influence
with ipv6ready.org so as to get the TAHI tests for IPv6 conformance
updated, as an upgrade to a kernel with the commit mentioned will result
in a 5% degradation in results for the existing tests.

Re: [PATCH net] ipv6: revert degradation in IPv6 Ready Logo test results

[吉藤英明]

Hi,

2018年10月3日(水) 16:57 Mike Manning <mmanning@vyatta.att-mail.com>:
>
> On 02/10/2018 19:26, David Miller wrote:
> > From: Mike Manning <mmanning@vyatta.att-mail.com>
> > Date: Tue,  2 Oct 2018 12:40:30 +0100
> >
> >> This reverts commit 0ed4229b08c1 ("ipv6: defrag: drop non-last frags
> >> smaller than min mtu"). While one should not get fragments smaller than
> >> the IPv6 minimum MTU, not handling crafted packets in the TAHI IPv6
> >> conformance test suite (v6eval) for IPv6 Ready Logo results in 18
> >> failures representing over 5% of the score.
> >>
> >> Cc: Florian Westphal <fw@strlen.de>
> >> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
> > Sorry, I'm not just going to blindly apply a patch because some
> > TAHI tests fail.
> >
> > It's possible the TAHI tests are wrong, or that the specification
> > elements it is testing don't make any sense these days.
> >
> > Allowing all kinds of random junk in the middle of the fragment queue
> > leads to lots of unnecessary cpu overhead and potential bugs, and it
> > triggerable remotely.
>
> Understood, thank you.
>
> It would be great if there is someone on this mailer who has influence
> with ipv6ready.org so as to get the TAHI tests for IPv6 conformance
> updated, as an upgrade to a kernel with the commit mentioned will result
> in a 5% degradation in results for the existing tests.
>

You can ignore some tests especially if you have some related,
updated RFC(s).

--yoshfuji