Subject: [Idr] RFC 8955 Appendix B

From: Thomas Mangin <[email-masked]>
Date: Mon, 1 Nov 2021 09:31:14 +0000

Hello,

Section 4.2.2.9 of RFC 8955 defines the way to handle the high bits of the
TCP Flag (NS has a value of 0x100 which does not fit in a byte).

   When a single octet (bitmask_op len=00) is specified, it matches
   octet 14 of the TCP header (see also Section 3.1 of [RFC0793]
<https://datatracker.ietf.org/doc/html/rfc0793#section-3.1>), which
   contains the TCP control bits.  When a 2-octet (bitmask_op len=01)
   encoding is used, it matches octets 13 and 14 of the TCP header with
   the data offset (leftmost 4 bits) always treated as 0.

However this change is not listed in Appendix B. "Comparison with RFC
5575": the only changes presented for section 4 are:

   *  Sections 4.2.2.3
<https://datatracker.ietf.org/doc/html/rfc8955#section-4.2.2.3> -
4.2.2.8 <https://datatracker.ietf.org/doc/html/rfc8955#section-4.2.2.8>,
4.2.2.10 <https://datatracker.ietf.org/doc/html/rfc8955#section-4.2.2.10>,
and 4.2.2.11 <https://datatracker.ietf.org/doc/html/rfc8955#section-4.2.2.11>
make use of the
      above numeric operator.  The allowed length of the comparison
      value was not consistently defined in [RFC5575
<https://datatracker.ietf.org/doc/html/rfc5575>].

Adding this information/change to Appendix B. would help when
implementations are updated from 5575 to 8955 to make sure they review the
TCP Flags.

Thank you,

Thomas Mangin

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 1 Nov 2021 14:35:46 +0100

Hi Thomas,

Actually functionality wise there is nothing new defined in RFC8955 in
respect to TCP flags matching.

RFC5575 - Section 4 - Type 9:

         Bitmask values can be encoded as a 1- or 2-byte bitmask.  When
         a single byte is specified, it matches byte 13 of the TCP
         header [RFC0793
<https://datatracker.ietf.org/doc/html/rfc0793>], which contains bits
8 though 15 of the 4th
         32-bit word.  When a 2-byte encoding is used, it matches bytes
         12 and 13 of the TCP header with the data offset field having a
         "don't care" value.

But the original text indeed has a mistake of recommending match on 12th &
13th octet where in reality flags are in 13th & 14th octet and that change
could indeed appear in Appendix B.

Thx,
R.

On Mon, Nov 1, 2021 at 10:31 AM Thomas Mangin <[email-masked]>
wrote:

>    octet 14 of the TCP header (see also Section 3.1 of [RFC0793] <https://datatracker.ietf.org/doc/html/rfc0793#section-3.1>), which
>    *  Sections 4.2.2.3 <https://datatracker.ietf.org/doc/html/rfc8955#section-4.2.2.3> - 4.2.2.8 <https://datatracker.ietf.org/doc/html/rfc8955#section-4.2.2.8>, 4.2.2.10 <https://datatracker.ietf.org/doc/html/rfc8955#section-4.2.2.10>, and 4.2.2.11 <https://datatracker.ietf.org/doc/html/rfc8955#section-4.2.2.11> make use of the
>       value was not consistently defined in [RFC5575 <https://datatracker.ietf.org/doc/html/rfc5575>].
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Thomas Mangin <[email-masked]>
Date: Mon, 1 Nov 2021 21:01:11 +0000

Hello Robert,

Oops, I am not sure how I made this mistake reading the documents but I
will take your finding as consolation that sending this mail was not
totally useless :-)

Thomas

On Mon, 1 Nov 2021 at 13:35, Robert Raszuk <[email-masked]> wrote:

>          header [RFC0793 <https://datatracker.ietf.org/doc/html/rfc0793>], which contains bits 8 though 15 of the 4th
>> Section 4.2.2.9 of RFC 8955 defines the way to handle the high bits of
>> the TCP Flag (NS has a value of 0x100 which does not fit in a byte).
>>