diff mbox series

[v1,2/2] ipv6: always accept routing headers with 0 segments left

Message ID 20240624141602.206398-3-Mathis.Marion@silabs.com (mailing list archive)
State Changes Requested
Delegated to: Netdev Maintainers
Headers show
Series ipv6: always accept routing headers with 0 segments left | expand

Checks

Context Check Description
netdev/series_format warning Target tree name not specified in the subject
netdev/tree_selection success Guessed tree name to be net-next
netdev/ynl success Generated files up to date; no warnings/errors; no diff in generated;
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 842 this patch: 842
netdev/build_tools success No tools touched, skip
netdev/cc_maintainers success CCed 5 of 5 maintainers
netdev/build_clang success Errors and warnings before: 849 this patch: 849
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 849 this patch: 849
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 29 lines checked
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 2 this patch: 2
netdev/source_inline success Was 0 now: 0
netdev/contest success net-next-2024-06-25--09-00 (tests: 662)

Commit Message

Mathis Marion June 24, 2024, 2:15 p.m. UTC
From: Mathis Marion <mathis.marion@silabs.com>

Routing headers of type 3 and 4 would be rejected even if segments left
was 0, in the case that they were disabled through system configuration.

RFC 8200 section 4.4 specifies:

      If Segments Left is zero, the node must ignore the Routing header
      and proceed to process the next header in the packet, whose type
      is identified by the Next Header field in the Routing header.

Signed-off-by: Mathis Marion <mathis.marion@silabs.com>
---
 net/ipv6/exthdrs.c | 17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

Comments

Kuniyuki Iwashima June 25, 2024, 9:38 p.m. UTC | #1
From: Mathis Marion <Mathis.Marion@silabs.com>
Date: Mon, 24 Jun 2024 16:15:33 +0200
> From: Mathis Marion <mathis.marion@silabs.com>
> 
> Routing headers of type 3 and 4 would be rejected even if segments left
> was 0, in the case that they were disabled through system configuration.
> 
> RFC 8200 section 4.4 specifies:
> 
>       If Segments Left is zero, the node must ignore the Routing header
>       and proceed to process the next header in the packet, whose type
>       is identified by the Next Header field in the Routing header.

I think this part is only applied to an unrecognized Routing Type,
so only applied when the network stack does not know the type.

   https://www.rfc-editor.org/rfc/rfc8200.html#section-4.4

   If, while processing a received packet, a node encounters a Routing
   header with an unrecognized Routing Type value, the required behavior
   of the node depends on the value of the Segments Left field, as
   follows:

      If Segments Left is zero, the node must ignore the Routing header
      and proceed to process the next header in the packet, whose type
      is identified by the Next Header field in the Routing header.

That's why RPL with segment length 0 was accepted before 8610c7c6e3bd.

But now the kernel recognizes RPL and it's intentionally disabled
by default with net.ipv6.conf.$DEV.rpl_seg_enabled since introduced.

And SRv6 has been rejected since 1ababeba4a21f for the same reason.


> 
> Signed-off-by: Mathis Marion <mathis.marion@silabs.com>
> ---
>  net/ipv6/exthdrs.c | 17 ++++++-----------
>  1 file changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
> index 083dbbafb166..913160b0fe13 100644
> --- a/net/ipv6/exthdrs.c
> +++ b/net/ipv6/exthdrs.c
> @@ -662,17 +662,6 @@ static int ipv6_rthdr_rcv(struct sk_buff *skb)
>  		return -1;
>  	}
>  
> -	switch (hdr->type) {
> -	case IPV6_SRCRT_TYPE_4:
> -		/* segment routing */
> -		return ipv6_srh_rcv(skb);
> -	case IPV6_SRCRT_TYPE_3:
> -		/* rpl segment routing */
> -		return ipv6_rpl_srh_rcv(skb);
> -	default:
> -		break;
> -	}
> -
>  looped_back:
>  	if (hdr->segments_left == 0) {
>  		switch (hdr->type) {
> @@ -708,6 +697,12 @@ static int ipv6_rthdr_rcv(struct sk_buff *skb)
>  		}
>  		break;
>  #endif
> +	case IPV6_SRCRT_TYPE_3:
> +		/* rpl segment routing */
> +		return ipv6_rpl_srh_rcv(skb);
> +	case IPV6_SRCRT_TYPE_4:
> +		/* segment routing */
> +		return ipv6_srh_rcv(skb);
>  	default:
>  		goto unknown_rh;
>  	}
> -- 
> 2.43.0
Alexander Aring June 26, 2024, 1:45 a.m. UTC | #2
Hi,

On Tue, Jun 25, 2024 at 5:39 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
>
> From: Mathis Marion <Mathis.Marion@silabs.com>
> Date: Mon, 24 Jun 2024 16:15:33 +0200
> > From: Mathis Marion <mathis.marion@silabs.com>
> >
> > Routing headers of type 3 and 4 would be rejected even if segments left
> > was 0, in the case that they were disabled through system configuration.
> >
> > RFC 8200 section 4.4 specifies:
> >
> >       If Segments Left is zero, the node must ignore the Routing header
> >       and proceed to process the next header in the packet, whose type
> >       is identified by the Next Header field in the Routing header.
>
> I think this part is only applied to an unrecognized Routing Type,
> so only applied when the network stack does not know the type.
>
>    https://www.rfc-editor.org/rfc/rfc8200.html#section-4.4
>
>    If, while processing a received packet, a node encounters a Routing
>    header with an unrecognized Routing Type value, the required behavior
>    of the node depends on the value of the Segments Left field, as
>    follows:
>
>       If Segments Left is zero, the node must ignore the Routing header
>       and proceed to process the next header in the packet, whose type
>       is identified by the Next Header field in the Routing header.
>
> That's why RPL with segment length 0 was accepted before 8610c7c6e3bd.
>
> But now the kernel recognizes RPL and it's intentionally disabled
> by default with net.ipv6.conf.$DEV.rpl_seg_enabled since introduced.
>
> And SRv6 has been rejected since 1ababeba4a21f for the same reason.

so there might be a need to have an opt-in knob to actually tell the
kernel ipv6 stack to recognize or not recognize a next header field
for users wanting to bypass certain next header fields to the user
space?

- Alex
Mathis Marion June 26, 2024, 10:10 a.m. UTC | #3
On 26/06/2024 3:45 AM, Alexander Aring wrote:
> Hi,
> 
> On Tue, Jun 25, 2024 at 5:39 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
>>
>> From: Mathis Marion <Mathis.Marion@silabs.com>
>> Date: Mon, 24 Jun 2024 16:15:33 +0200
>>> From: Mathis Marion <mathis.marion@silabs.com>
>>>
>>> Routing headers of type 3 and 4 would be rejected even if segments left
>>> was 0, in the case that they were disabled through system configuration.
>>>
>>> RFC 8200 section 4.4 specifies:
>>>
>>>        If Segments Left is zero, the node must ignore the Routing header
>>>        and proceed to process the next header in the packet, whose type
>>>        is identified by the Next Header field in the Routing header.
>>
>> I think this part is only applied to an unrecognized Routing Type,
>> so only applied when the network stack does not know the type.
>>
>>     https://www.rfc-editor.org/rfc/rfc8200.html#section-4.4
>>
>>     If, while processing a received packet, a node encounters a Routing
>>     header with an unrecognized Routing Type value, the required behavior
>>     of the node depends on the value of the Segments Left field, as
>>     follows:
>>
>>        If Segments Left is zero, the node must ignore the Routing header
>>        and proceed to process the next header in the packet, whose type
>>        is identified by the Next Header field in the Routing header.
>>
>> That's why RPL with segment length 0 was accepted before 8610c7c6e3bd.
>>
>> But now the kernel recognizes RPL and it's intentionally disabled
>> by default with net.ipv6.conf.$DEV.rpl_seg_enabled since introduced.
>>
>> And SRv6 has been rejected since 1ababeba4a21f for the same reason.
> 
> so there might be a need to have an opt-in knob to actually tell the
> kernel ipv6 stack to recognize or not recognize a next header field
> for users wanting to bypass certain next header fields to the user
> space?
> 
> - Alex
> 

My point is that if a particular routing header support is disabled
through system configuration, it should be treated as any unrecognized
header. From my perspective, doing otherwise causes a regression every
time a new routing header is supported.
Alexander Aring June 26, 2024, 1:48 p.m. UTC | #4
Hi,

On Wed, Jun 26, 2024 at 6:10 AM Mathis Marion <mathis.marion@silabs.com> wrote:
>
> On 26/06/2024 3:45 AM, Alexander Aring wrote:
> > Hi,
> >
> > On Tue, Jun 25, 2024 at 5:39 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> >>
> >> From: Mathis Marion <Mathis.Marion@silabs.com>
> >> Date: Mon, 24 Jun 2024 16:15:33 +0200
> >>> From: Mathis Marion <mathis.marion@silabs.com>
> >>>
> >>> Routing headers of type 3 and 4 would be rejected even if segments left
> >>> was 0, in the case that they were disabled through system configuration.
> >>>
> >>> RFC 8200 section 4.4 specifies:
> >>>
> >>>        If Segments Left is zero, the node must ignore the Routing header
> >>>        and proceed to process the next header in the packet, whose type
> >>>        is identified by the Next Header field in the Routing header.
> >>
> >> I think this part is only applied to an unrecognized Routing Type,
> >> so only applied when the network stack does not know the type.
> >>
> >>     https://www.rfc-editor.org/rfc/rfc8200.html#section-4.4
> >>
> >>     If, while processing a received packet, a node encounters a Routing
> >>     header with an unrecognized Routing Type value, the required behavior
> >>     of the node depends on the value of the Segments Left field, as
> >>     follows:
> >>
> >>        If Segments Left is zero, the node must ignore the Routing header
> >>        and proceed to process the next header in the packet, whose type
> >>        is identified by the Next Header field in the Routing header.
> >>
> >> That's why RPL with segment length 0 was accepted before 8610c7c6e3bd.
> >>
> >> But now the kernel recognizes RPL and it's intentionally disabled
> >> by default with net.ipv6.conf.$DEV.rpl_seg_enabled since introduced.
> >>
> >> And SRv6 has been rejected since 1ababeba4a21f for the same reason.
> >
> > so there might be a need to have an opt-in knob to actually tell the
> > kernel ipv6 stack to recognize or not recognize a next header field
> > for users wanting to bypass certain next header fields to the user
> > space?
> >
> > - Alex
> >
>
> My point is that if a particular routing header support is disabled
> through system configuration, it should be treated as any unrecognized
> header. From my perspective, doing otherwise causes a regression every
> time a new routing header is supported.
>

makes sense to me. I am asking myself what the exact reason is to have
the difference between "recognized" and "unrecognized" to judge more
about such change and what we may miss here to consider?

- Alex
Alexander Aring July 16, 2024, 9:27 p.m. UTC | #5
Hi,

On Wed, Jun 26, 2024 at 6:10 AM Mathis Marion <mathis.marion@silabs.com> wrote:
>
> On 26/06/2024 3:45 AM, Alexander Aring wrote:
> > Hi,
> >
> > On Tue, Jun 25, 2024 at 5:39 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> >>
> >> From: Mathis Marion <Mathis.Marion@silabs.com>
> >> Date: Mon, 24 Jun 2024 16:15:33 +0200
> >>> From: Mathis Marion <mathis.marion@silabs.com>
> >>>
> >>> Routing headers of type 3 and 4 would be rejected even if segments left
> >>> was 0, in the case that they were disabled through system configuration.
> >>>
> >>> RFC 8200 section 4.4 specifies:
> >>>
> >>>        If Segments Left is zero, the node must ignore the Routing header
> >>>        and proceed to process the next header in the packet, whose type
> >>>        is identified by the Next Header field in the Routing header.
> >>
> >> I think this part is only applied to an unrecognized Routing Type,
> >> so only applied when the network stack does not know the type.
> >>
> >>     https://www.rfc-editor.org/rfc/rfc8200.html#section-4.4
> >>
> >>     If, while processing a received packet, a node encounters a Routing
> >>     header with an unrecognized Routing Type value, the required behavior
> >>     of the node depends on the value of the Segments Left field, as
> >>     follows:
> >>
> >>        If Segments Left is zero, the node must ignore the Routing header
> >>        and proceed to process the next header in the packet, whose type
> >>        is identified by the Next Header field in the Routing header.
> >>
> >> That's why RPL with segment length 0 was accepted before 8610c7c6e3bd.
> >>
> >> But now the kernel recognizes RPL and it's intentionally disabled
> >> by default with net.ipv6.conf.$DEV.rpl_seg_enabled since introduced.
> >>
> >> And SRv6 has been rejected since 1ababeba4a21f for the same reason.
> >
> > so there might be a need to have an opt-in knob to actually tell the
> > kernel ipv6 stack to recognize or not recognize a next header field
> > for users wanting to bypass certain next header fields to the user
> > space?
> >
> > - Alex
> >
>
> My point is that if a particular routing header support is disabled
> through system configuration, it should be treated as any unrecognized
> header. From my perspective, doing otherwise causes a regression every
> time a new routing header is supported.
>

coming back to this. I think you need to add another switch to do that
and turn it by default in whatever the current default situation is,
otherwise this patch will break the next person's behaviour.

- Alex
diff mbox series

Patch

diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 083dbbafb166..913160b0fe13 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -662,17 +662,6 @@  static int ipv6_rthdr_rcv(struct sk_buff *skb)
 		return -1;
 	}
 
-	switch (hdr->type) {
-	case IPV6_SRCRT_TYPE_4:
-		/* segment routing */
-		return ipv6_srh_rcv(skb);
-	case IPV6_SRCRT_TYPE_3:
-		/* rpl segment routing */
-		return ipv6_rpl_srh_rcv(skb);
-	default:
-		break;
-	}
-
 looped_back:
 	if (hdr->segments_left == 0) {
 		switch (hdr->type) {
@@ -708,6 +697,12 @@  static int ipv6_rthdr_rcv(struct sk_buff *skb)
 		}
 		break;
 #endif
+	case IPV6_SRCRT_TYPE_3:
+		/* rpl segment routing */
+		return ipv6_rpl_srh_rcv(skb);
+	case IPV6_SRCRT_TYPE_4:
+		/* segment routing */
+		return ipv6_srh_rcv(skb);
 	default:
 		goto unknown_rh;
 	}