draft-stewart-tsvwg-sctp-ipv4 enforcement

draft-stewart-tsvwg-sctp-ipv4 enforcement

[Sérgio]

Hello,

I am troubleshooting a deployment with SCTP and eventually found that
the client has configured the equipment using addresses within the
RFC2544 annex C.2.2 test network (198.18.0.0/15).

Although I think the deployment network may be changed to use another
address space in order to "solve" the issue, the restriction
enforcement on the SCTP kernel driver (implemented by function
sctp_v4_addr_valid -- net/sctp/protocol.c -- in expansion of
IS_IPV4_UNUSABLE_ADDRESS -- include/net/sctp/consntans.h) seems odd to
me, because the address is a valid unicast IPv4 address and should be
acceptable as per RFC4960 clause 8.4:

   The receiver of an OOTB packet MUST do the following:

   1)  If the OOTB packet is to or from a non-unicast address, a
       receiver SHOULD silently discard the packet.  Otherwise,

The source code states that this restriction came from
draft-stewart-tsvwg-sctp-ipv4, which is true, and the sysctl
net.sctp.addr_scope_policy is documented in ip-sysctl.txt as a switch
for the desired draft behavior, but changing the sysctl value has no
effect because IS_IPV4_UNUSABLE_ADDRESS macro expansion has no
verification of any sysctl configuration nor the sctp_v4_addr_valid.

The draft-stewart-tsvwg-sctp-ipv4 enforcement seems like a bug or I am
missing something?

Best Regards,
Sérgio Surkamp

Re: draft-stewart-tsvwg-sctp-ipv4 enforcement

[Xin Long]

On Thu, Jun 17, 2021 at 4:40 PM Sérgio <surkamp@gmail.com> wrote:
>
> Hello,
>
> I am troubleshooting a deployment with SCTP and eventually found that
> the client has configured the equipment using addresses within the
> RFC2544 annex C.2.2 test network (198.18.0.0/15).
>
> Although I think the deployment network may be changed to use another
> address space in order to "solve" the issue, the restriction
> enforcement on the SCTP kernel driver (implemented by function
> sctp_v4_addr_valid -- net/sctp/protocol.c -- in expansion of
> IS_IPV4_UNUSABLE_ADDRESS -- include/net/sctp/consntans.h) seems odd to
> me, because the address is a valid unicast IPv4 address and should be
> acceptable as per RFC4960 clause 8.4:
>
>    The receiver of an OOTB packet MUST do the following:
>
>    1)  If the OOTB packet is to or from a non-unicast address, a
>        receiver SHOULD silently discard the packet.  Otherwise,
>
> The source code states that this restriction came from
> draft-stewart-tsvwg-sctp-ipv4, which is true, and the sysctl
> net.sctp.addr_scope_policy is documented in ip-sysctl.txt as a switch
> for the desired draft behavior, but changing the sysctl value has no
> effect because IS_IPV4_UNUSABLE_ADDRESS macro expansion has no
> verification of any sysctl configuration nor the sctp_v4_addr_valid.
>
> The draft-stewart-tsvwg-sctp-ipv4 enforcement seems like a bug or I am
> missing something?
>
There must be a reason for not using 198.18.0.0/24 in SCTP, as in

  https://datatracker.ietf.org/doc/html/draft-stewart-tsvwg-sctp-ipv4-00#section-3.1

   [1]  IANA, I., "Special-Use IPv4 Addresses", draft-iana-special-ipv4-
        03 (work in progress), April 2002.

https://datatracker.ietf.org/doc/html/draft-iana-special-ipv4-03

Re: draft-stewart-tsvwg-sctp-ipv4 enforcement

[Michael Tuexen]

> On 18. Jun 2021, at 18:35, Xin Long <lucien.xin@gmail.com> wrote:
> 
> On Thu, Jun 17, 2021 at 4:40 PM Sérgio <surkamp@gmail.com> wrote:
>> 
>> Hello,
>> 
>> I am troubleshooting a deployment with SCTP and eventually found that
>> the client has configured the equipment using addresses within the
>> RFC2544 annex C.2.2 test network (198.18.0.0/15).
>> 
>> Although I think the deployment network may be changed to use another
>> address space in order to "solve" the issue, the restriction
>> enforcement on the SCTP kernel driver (implemented by function
>> sctp_v4_addr_valid -- net/sctp/protocol.c -- in expansion of
>> IS_IPV4_UNUSABLE_ADDRESS -- include/net/sctp/consntans.h) seems odd to
>> me, because the address is a valid unicast IPv4 address and should be
>> acceptable as per RFC4960 clause 8.4:
>> 
>>   The receiver of an OOTB packet MUST do the following:
>> 
>>   1)  If the OOTB packet is to or from a non-unicast address, a
>>       receiver SHOULD silently discard the packet.  Otherwise,
>> 
>> The source code states that this restriction came from
>> draft-stewart-tsvwg-sctp-ipv4, which is true, and the sysctl
>> net.sctp.addr_scope_policy is documented in ip-sysctl.txt as a switch
>> for the desired draft behavior, but changing the sysctl value has no
>> effect because IS_IPV4_UNUSABLE_ADDRESS macro expansion has no
>> verification of any sysctl configuration nor the sctp_v4_addr_valid.
>> 
>> The draft-stewart-tsvwg-sctp-ipv4 enforcement seems like a bug or I am
>> missing something?
>> 
> There must be a reason for not using 198.18.0.0/24 in SCTP, as in
> 
>  https://datatracker.ietf.org/doc/html/draft-stewart-tsvwg-sctp-ipv4-00#section-3.1
> 
>   [1]  IANA, I., "Special-Use IPv4 Addresses", draft-iana-special-ipv4-
>        03 (work in progress), April 2002.
> 
> https://datatracker.ietf.org/doc/html/draft-iana-special-ipv4-03
I think not allowing it at all is wrong.
https://datatracker.ietf.org/doc/html/rfc6890
states that it is not global. So maybe level 3 would be more appropriate.

Please note, the ID was never published as an RFC, so there might be more
errors...

Best regards
Michael

Re: draft-stewart-tsvwg-sctp-ipv4 enforcement

[Xin Long]

On Fri, Jun 18, 2021 at 4:35 PM Michael Tuexen <tuexen@freebsd.org> wrote:
>
> > On 18. Jun 2021, at 18:35, Xin Long <lucien.xin@gmail.com> wrote:
> >
> > On Thu, Jun 17, 2021 at 4:40 PM Sérgio <surkamp@gmail.com> wrote:
> >>
> >> Hello,
> >>
> >> I am troubleshooting a deployment with SCTP and eventually found that
> >> the client has configured the equipment using addresses within the
> >> RFC2544 annex C.2.2 test network (198.18.0.0/15).
> >>
> >> Although I think the deployment network may be changed to use another
> >> address space in order to "solve" the issue, the restriction
> >> enforcement on the SCTP kernel driver (implemented by function
> >> sctp_v4_addr_valid -- net/sctp/protocol.c -- in expansion of
> >> IS_IPV4_UNUSABLE_ADDRESS -- include/net/sctp/consntans.h) seems odd to
> >> me, because the address is a valid unicast IPv4 address and should be
> >> acceptable as per RFC4960 clause 8.4:
> >>
> >>   The receiver of an OOTB packet MUST do the following:
> >>
> >>   1)  If the OOTB packet is to or from a non-unicast address, a
> >>       receiver SHOULD silently discard the packet.  Otherwise,
> >>
> >> The source code states that this restriction came from
> >> draft-stewart-tsvwg-sctp-ipv4, which is true, and the sysctl
> >> net.sctp.addr_scope_policy is documented in ip-sysctl.txt as a switch
> >> for the desired draft behavior, but changing the sysctl value has no
> >> effect because IS_IPV4_UNUSABLE_ADDRESS macro expansion has no
> >> verification of any sysctl configuration nor the sctp_v4_addr_valid.
> >>
> >> The draft-stewart-tsvwg-sctp-ipv4 enforcement seems like a bug or I am
> >> missing something?
> >>
> > There must be a reason for not using 198.18.0.0/24 in SCTP, as in
> >
> >  https://datatracker.ietf.org/doc/html/draft-stewart-tsvwg-sctp-ipv4-00#section-3.1
> >
> >   [1]  IANA, I., "Special-Use IPv4 Addresses", draft-iana-special-ipv4-
> >        03 (work in progress), April 2002.
> >
> > https://datatracker.ietf.org/doc/html/draft-iana-special-ipv4-03
> I think not allowing it at all is wrong.
> https://datatracker.ietf.org/doc/html/rfc6890
> states that it is not global. So maybe level 3 would be more appropriate.
>
I will fix it, thanks.

> Please note, the ID was never published as an RFC, so there might be more
> errors...
>
> Best regards
> Michael
>