All of lore.kernel.org
 help / color / mirror / Atom feed
* IPv6 Parameter problem with no ICMPv6 response ?
@ 2018-02-05  3:58 David McCullough
  2018-02-05 12:16 ` Pablo Neira Ayuso
  0 siblings, 1 reply; 4+ messages in thread
From: David McCullough @ 2018-02-05  3:58 UTC (permalink / raw)
  To: netfilter-devel


Hi devel,

I am looking for some feedback on IPv6 behaviour with/without netfilter in
the path.  We are in process of some IPv6 certification at a lab.

RFC2460 has a bunch of conditions under which certain ICMPv6 responses
should be sent.  This is even commented in the code.

linux/net/ipv6/reassembly.c:255
                /* Check if the fragment is rounded to 8 bytes.
                 * Required by the RFC.
                 */
                if (end & 0x7) {
                        /* RFC2460 says always send parameter problem in
                         * this case. -DaveM
                         */
                        __IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)),
                                        IPSTATS_MIB_INHDRERRORS);
                        icmpv6_param_prob(skb, ICMPV6_HDR_FIELD,
                                          offsetof(struct ipv6hdr, payload_len));                       
                        return -1;
                }

linux/net/ipv6/netfilter/nf_conntrack_reasm.c:259
                /* Check if the fragment is rounded to 8 bytes.
                 * Required by the RFC.
                 */
                if (end & 0x7) {
                        /* RFC2460 says always send parameter problem in
                         * this case. -DaveM
                         */
                        pr_debug("end of fragment not rounded to 8 bytes.\n");
                        return -1;      
                }

The behaviour of the non-netfilter code is what the certification is expecting.
We are using conntracking though and I can see no way to avoid the above
netfilter code from silently dropping the packet and not responding correctly.

We experiemented with the patch below and it provided the appropriate
responses but we were not sure this is the best approach.  Happy to send in
a proper patch if this looks ok.

Any comments appreciated,

Thanks,
Davidm

--- a/linux/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/linux/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -263,6 +263,8 @@ static int nf_ct_frag6_queue(struct frag_queue *fq, struct sk_buff *skb,
     * this case. -DaveM
     */
    pr_debug("end of fragment not rounded to 8 bytes.\n");
+   icmpv6_send(skb, ICMPV6_PARAMPROB, ICMPV6_HDR_FIELD,
+        offsetof(struct ipv6hdr, saddr));
    return -1;
   }
   if (end > fq->q.len) {


-- 
David McCullough,  david.mccullough@accelerated.com,   Ph: 0410 560 763

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: IPv6 Parameter problem with no ICMPv6 response ?
  2018-02-05  3:58 IPv6 Parameter problem with no ICMPv6 response ? David McCullough
@ 2018-02-05 12:16 ` Pablo Neira Ayuso
  2018-02-05 12:16   ` Pablo Neira Ayuso
  0 siblings, 1 reply; 4+ messages in thread
From: Pablo Neira Ayuso @ 2018-02-05 12:16 UTC (permalink / raw)
  To: David McCullough; +Cc: netfilter-devel

On Mon, Feb 05, 2018 at 01:58:26PM +1000, David McCullough wrote:
> 
> Hi devel,
> 
> I am looking for some feedback on IPv6 behaviour with/without netfilter in
> the path.  We are in process of some IPv6 certification at a lab.
> 
> RFC2460 has a bunch of conditions under which certain ICMPv6 responses
> should be sent.  This is even commented in the code.
> 
> linux/net/ipv6/reassembly.c:255
>                 /* Check if the fragment is rounded to 8 bytes.
>                  * Required by the RFC.
>                  */
>                 if (end & 0x7) {
>                         /* RFC2460 says always send parameter problem in
>                          * this case. -DaveM
>                          */
>                         __IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)),
>                                         IPSTATS_MIB_INHDRERRORS);
>                         icmpv6_param_prob(skb, ICMPV6_HDR_FIELD,
>                                           offsetof(struct ipv6hdr, payload_len));                       
>                         return -1;
>                 }
> 
> linux/net/ipv6/netfilter/nf_conntrack_reasm.c:259
>                 /* Check if the fragment is rounded to 8 bytes.
>                  * Required by the RFC.
>                  */
>                 if (end & 0x7) {
>                         /* RFC2460 says always send parameter problem in
>                          * this case. -DaveM
>                          */
>                         pr_debug("end of fragment not rounded to 8 bytes.\n");
>                         return -1;      
>                 }
> 
> The behaviour of the non-netfilter code is what the certification is expecting.
> We are using conntracking though and I can see no way to avoid the above
> netfilter code from silently dropping the packet and not responding correctly.
> 
> We experiemented with the patch below and it provided the appropriate
> responses but we were not sure this is the best approach.  Happy to send in
> a proper patch if this looks ok.

Probably you're refering to this fix?

commit 83f1999caeb14e15df205e80d210699951733287
Author: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date:   Fri Jan 12 17:36:27 2018 -0700

    netfilter: ipv6: nf_defrag: Pass on packets to stack per RFC2460


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: IPv6 Parameter problem with no ICMPv6 response ?
  2018-02-05 12:16 ` Pablo Neira Ayuso
@ 2018-02-05 12:16   ` Pablo Neira Ayuso
  2018-02-05 23:27     ` David McCullough
  0 siblings, 1 reply; 4+ messages in thread
From: Pablo Neira Ayuso @ 2018-02-05 12:16 UTC (permalink / raw)
  To: David McCullough; +Cc: netfilter-devel

On Mon, Feb 05, 2018 at 01:16:08PM +0100, Pablo Neira Ayuso wrote:
> On Mon, Feb 05, 2018 at 01:58:26PM +1000, David McCullough wrote:
> > 
> > Hi devel,
> > 
> > I am looking for some feedback on IPv6 behaviour with/without netfilter in
> > the path.  We are in process of some IPv6 certification at a lab.
> > 
> > RFC2460 has a bunch of conditions under which certain ICMPv6 responses
> > should be sent.  This is even commented in the code.
> > 
> > linux/net/ipv6/reassembly.c:255
> >                 /* Check if the fragment is rounded to 8 bytes.
> >                  * Required by the RFC.
> >                  */
> >                 if (end & 0x7) {
> >                         /* RFC2460 says always send parameter problem in
> >                          * this case. -DaveM
> >                          */
> >                         __IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)),
> >                                         IPSTATS_MIB_INHDRERRORS);
> >                         icmpv6_param_prob(skb, ICMPV6_HDR_FIELD,
> >                                           offsetof(struct ipv6hdr, payload_len));                       
> >                         return -1;
> >                 }
> > 
> > linux/net/ipv6/netfilter/nf_conntrack_reasm.c:259
> >                 /* Check if the fragment is rounded to 8 bytes.
> >                  * Required by the RFC.
> >                  */
> >                 if (end & 0x7) {
> >                         /* RFC2460 says always send parameter problem in
> >                          * this case. -DaveM
> >                          */
> >                         pr_debug("end of fragment not rounded to 8 bytes.\n");
> >                         return -1;      
> >                 }
> > 
> > The behaviour of the non-netfilter code is what the certification is expecting.
> > We are using conntracking though and I can see no way to avoid the above
> > netfilter code from silently dropping the packet and not responding correctly.
> > 
> > We experiemented with the patch below and it provided the appropriate
> > responses but we were not sure this is the best approach.  Happy to send in
> > a proper patch if this looks ok.
> 
> Probably you're refering to this fix?
> 
> commit 83f1999caeb14e15df205e80d210699951733287
> Author: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
> Date:   Fri Jan 12 17:36:27 2018 -0700
> 
>     netfilter: ipv6: nf_defrag: Pass on packets to stack per RFC2460

You will also need this follow up amendment on top of it:

commit ea23d5e3bf340e413b8e05c13da233c99c64142b
Author: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date:   Wed Jan 31 04:50:01 2018 -0700

    netfilter: ipv6: nf_defrag: Kill frag queue on RFC2460 failure


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: IPv6 Parameter problem with no ICMPv6 response ?
  2018-02-05 12:16   ` Pablo Neira Ayuso
@ 2018-02-05 23:27     ` David McCullough
  0 siblings, 0 replies; 4+ messages in thread
From: David McCullough @ 2018-02-05 23:27 UTC (permalink / raw)
  To: Pablo Neira Ayuso; +Cc: netfilter-devel


Pablo Neira Ayuso wrote the following:
> On Mon, Feb 05, 2018 at 01:16:08PM +0100, Pablo Neira Ayuso wrote:
> > On Mon, Feb 05, 2018 at 01:58:26PM +1000, David McCullough wrote:
> > > 
> > > Hi devel,
> > > 
> > > I am looking for some feedback on IPv6 behaviour with/without netfilter in
> > > the path.  We are in process of some IPv6 certification at a lab.
> > > 
> > > RFC2460 has a bunch of conditions under which certain ICMPv6 responses
> > > should be sent.  This is even commented in the code.
> > > 
> > > linux/net/ipv6/reassembly.c:255
> > >                 /* Check if the fragment is rounded to 8 bytes.
> > >                  * Required by the RFC.
> > >                  */
> > >                 if (end & 0x7) {
> > >                         /* RFC2460 says always send parameter problem in
> > >                          * this case. -DaveM
> > >                          */
> > >                         __IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)),
> > >                                         IPSTATS_MIB_INHDRERRORS);
> > >                         icmpv6_param_prob(skb, ICMPV6_HDR_FIELD,
> > >                                           offsetof(struct ipv6hdr, payload_len));                       
> > >                         return -1;
> > >                 }
> > > 
> > > linux/net/ipv6/netfilter/nf_conntrack_reasm.c:259
> > >                 /* Check if the fragment is rounded to 8 bytes.
> > >                  * Required by the RFC.
> > >                  */
> > >                 if (end & 0x7) {
> > >                         /* RFC2460 says always send parameter problem in
> > >                          * this case. -DaveM
> > >                          */
> > >                         pr_debug("end of fragment not rounded to 8 bytes.\n");
> > >                         return -1;      
> > >                 }
> > > 
> > > The behaviour of the non-netfilter code is what the certification is expecting.
> > > We are using conntracking though and I can see no way to avoid the above
> > > netfilter code from silently dropping the packet and not responding correctly.
> > > 
> > > We experiemented with the patch below and it provided the appropriate
> > > responses but we were not sure this is the best approach.  Happy to send in
> > > a proper patch if this looks ok.
> > 
> > Probably you're refering to this fix?
> > 
> > commit 83f1999caeb14e15df205e80d210699951733287
> > Author: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
> > Date:   Fri Jan 12 17:36:27 2018 -0700
> > 
> >     netfilter: ipv6: nf_defrag: Pass on packets to stack per RFC2460
> 
> You will also need this follow up amendment on top of it:
> 
> commit ea23d5e3bf340e413b8e05c13da233c99c64142b
> Author: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
> Date:   Wed Jan 31 04:50:01 2018 -0700
> 
>     netfilter: ipv6: nf_defrag: Kill frag queue on RFC2460 failure

Awesome,  thanks, wasn't aware of the patch,   will check it out,

Cheers,
Davidm

-- 
David McCullough,  david.mccullough@accelerated.com,   Ph: 0410 560 763

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2018-02-05 23:27 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-05  3:58 IPv6 Parameter problem with no ICMPv6 response ? David McCullough
2018-02-05 12:16 ` Pablo Neira Ayuso
2018-02-05 12:16   ` Pablo Neira Ayuso
2018-02-05 23:27     ` David McCullough

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.