Subject: [tcpm] 793bis: what to say about source routing

From: Wesley Eddy <[email-masked]>
Date: Mon, 29 Nov 2021 22:12:04 -0500

One of the IESG comments that needs to be addressed on 793bis regards 
source routing.  There is the comment:

    [S3.9.2.1]

    * I feel like there should be some additional caveat about security
       implications of support for source routing.  RFC 6274, for example, says
       packets with LSRR (6274s3.13.2.3) and SSRR (6274s3.13.2.4) options should
       be dropped, citing various security concerns.

       I'm not sure there needs to be a lot of text; perhaps just an observation
       that some end systems may not support the source route semantics described
       here for security (or policy) reasons?

After looking at what 6274 says (which is Informational) and 793bis, 
here are my main thoughts:

    (1) The text in question was written for IPv4, prior to IPv6 with
    its own methods (deprecated RH0, and now other things like segment
    routing).

    (2) I'm not aware of anything changing with regard to 1122's
    description of IPv4 source routing support in IP stacks.

    (3) Looking at defaults on popular Linux systems, it looks like
    "net.ipv4.conf.default.accept_source_route = 1" is not uncommon ...
    so source routing support probably still exists.  I didn't look at
    what the TCP code does though, with regard to incoming source routed
    packets to see if it matches what 793bis says.

So, my suggestion is that we rename that section of 793bis (section 
3.9.2.1) to be specific to *IPv4* source routing, and then append at the 
end of the section a sentence like:

    RFC 6274 describes security concerns with IP source routing, and
    source routing may be disabled or unsupported on some systems.

Does this sound good?  Note that it basically leaves any flavors of IPv6 
source routing unmentioned (which seems right, since there isn't 
anything on standards track to use).  I would be very happy if someone 
more knowledgeable about the state of source routing support and usage 
could check this and share their thoughts.

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 29 Nov 2021 20:53:07 -0800

Hi, Wes,

The text in RFC793bis is correct and sufficient regarding TCP. TCP has no business making recommendations about what options IP uses.

Let’s please not continue to propagate the misconception that features that are not expected are either errors or attacks. And let’s please stop citing this deeply flawed work that is not BCP. Whether IP source routing is disabled or not on a system should be of no consequence to TCP. It is either used or not; when used, TCP *MUST* support its use

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Nov 29, 2021, at 7:12 PM, Wesley Eddy <[email-masked]> wrote:
> 
> One of the IESG comments that needs to be addressed on 793bis regards source routing.  There is the comment:
> 
> [S3.9.2.1]
> 
> After looking at what 6274 says (which is Informational) and 793bis, here are my main thoughts:
> 
> (1) The text in question was written for IPv4, prior to IPv6 with its own methods (deprecated RH0, and now other things like segment routing).
> 
> (2) I'm not aware of anything changing with regard to 1122's description of IPv4 source routing support in IP stacks.
> 
> (3) Looking at defaults on popular Linux systems, it looks like "net.ipv4.conf.default.accept_source_route = 1" is not uncommon ... so source routing support probably still exists.  I didn't look at what the TCP code does though, with regard to incoming source routed packets to see if it matches what 793bis says.
> 
> So, my suggestion is that we rename that section of 793bis (section 3.9.2.1) to be specific to *IPv4* source routing, and then append at the end of the section a sentence like:
> 
> RFC 6274 describes security concerns with IP source routing, and source routing may be disabled or unsupported on some systems.
> 
> Does this sound good?  Note that it basically leaves any flavors of IPv6 source routing unmentioned (which seems right, since there isn't anything on standards track to use).  I would be very happy if someone more knowledgeable about the state of source routing support and usage could check this and share their thoughts.
> 
> 
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 30 Nov 2021 09:17:14 +0000

Pleasse see below.

On 30/11/2021 04:53, [email-masked] wrote:
> Hi, Wes,
>
> The text in RFC793bis is correct and sufficient regarding TCP. TCP has 
> no business making recommendations about what options IP uses.
>
> Let’s please not continue to propagate the misconception that features 
> that are not expected are either errors or attacks. And let’s please 
> stop citing this deeply flawed work that is not BCP. Whether IP source 
> routing is disabled or not on a system should be of no consequence to 
> TCP. It is either used or not; when used, TCP *MUST* support its use
>
> Joe
>
> —
> www.strayalpha.com <http://www.strayalpha.com>
>
I have looked again at the text in 3.9.2.1. I would suggest a more 
radical change to that text.

First, it is entitled "Source Routing", to me this was once have been 
about the IPv4 source routing option, but I suggest this is actually an 
"example" where the host provides input that selects the path from the 
host, and we really should say this much more explicitly and not hide 
this as an example of an IPv4 option.

* So: To me MUST-51 is wrong in a transport spec. It should have been a 
part of an interface to a source route spec - there is no interop issue 
here, and it isn't a requirement for TCP! similarly I'd argue that 
MUST-52 is wrong in a transport spec, it's dictating host policy on how 
to use the interface.

* MUST-53 is important in that it provides a return path. The important 
advice/requirements apply to other cases also that can select 
interfaces/paths: the correct source and destination address (and any 
other selectors used to choose a path - segment routing, and others) 
needs to be appled and a return address needs to be notified that can be 
consistently used to reach the remote host (which I expect is what 
MUST-53 is about).

- The datagram language was odd, probably better as an "IP packet".

... SHLD-24 appears to be about the path changing... although this isn't 
really a TCP thing, it is important thing to get correct. It seems to be 
a lower layer thing: If the path changes, the packets from TCP change 
their forwarding to be consistent ...

To me the security concerns are not relevant here - this is a transport 
spec., and the mechanisms below need to be designed correctly, and while 
an exmaple or two are good, it seems rather silly to state or enumerate 
the different sub-transport protocols or their individual concerns.

Gorry

>>     its own methods (deprecated RH0, and now other things like
>>     segment routing).
>>
>>     "net.ipv4.conf.default.accept_source_route = 1" is not uncommon
>>     ... so source routing support probably still exists.  I didn't
>>     look at what the TCP code does though, with regard to incoming
>>     source routed packets to see if it matches what 793bis says.
>>
>> 3.9.2.1) to be specific to *IPv4* source routing, and then append at 
>> the end of the section a sentence like:
>>
>> Does this sound good?  Note that it basically leaves any flavors of 
>> IPv6 source routing unmentioned (which seems right, since there isn't 
>> anything on standards track to use).  I would be very happy if 
>> someone more knowledgeable about the state of source routing support 
>> and usage could check this and share their thoughts.
>>
>>
>>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 30 Nov 2021 10:58:31 +0000

I agree with Joe. I don’t find the guidance in RFC 6274 particular relevant for someone who is implementing TCP.

Especially I don’t think it would make sense to limit the existing section to IPv4 only. If you really want to add the propose sentence below, that sentence could be limited to IPv4 (“RFC 6274 describes security concerns with IPv4 source routing… “).

Mirja

From: tcpm <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Tuesday, 30. November 2021 at 05:53
To: Wes Eddy <[email-masked]>
Cc: tcpm IETF list <[email-masked]>
Subject: Re: [tcpm] 793bis: what to say about source routing

Hi, Wes,

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com<https://protect2.fireeye.com/v1/url?k=b5d6ea65-ea4dd326-b5d6aafe-861fcb972bfc-8afd7ad9b245f6b9&q=1&e=671185cd-2b01-458b-ba0a-52af0b0bb739&u=http%3A%2F%2Fwww.strayalpha.com%2F>

On Nov 29, 2021, at 7:12 PM, Wesley Eddy <[email-masked]<mailto:[email-masked]>> wrote:

[S3.9.2.1]

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 30 Nov 2021 20:44:11 -0800

Hi, Gorry, 

To me, your final point is the most significant. 

Notably, putting the proposed note in TCP would suggest either that IP source routing is deprecated (it isn’t) or that TCP support for it should be considered optional (it should not) - regardless of whether is deprecated in the future or not.

Joe
 
—

> On Nov 30, 2021, at 1:17 AM, Gorry Fairhurst <[email-masked]> wrote:
> 
> To me the security concerns are not relevant here - this is a transport spec., and the mechanisms below need to be designed correctly, and while an exmaple or two are good, it seems rather silly to state or enumerate the different sub-transport protocols or their individual concerns.
> 
>