Subject: [tcpm] Is ECN a valid TCP header flag?

From: t petch <[email-masked]>
Date: Fri, 24 Sep 2021 11:05:53 +0100

This question came to me seeing the IESG discussion of an OPSAWG I-D 
which modelled, in part, TCP, in YANG, but did not model it the way TCPM 
does.

There is a lot of this about, as in I2NSF, which has the most detailed 
model I see of TCP although not in a way that is likely to be used by 
those operating TCP.

Thus draft-ietf-i2nsf-nsf-facing-interface-dm provides identities such as
     identity tcp-flags {
which is then used as

   base tcp-flags;
     identity cwr {
     identity ecn {
     identity urg {
     identity ack {
     identity psh {
     identity rst {
     identity syn {
     identity fin {
with descriptions and references.  My knowledge of this is limited but I 
suspect that the reference for 'ecn' should be RFC3168 and not RFC793 
but then should it be 'ece' and not 'ecn'?  I suspect that a TCP expert 
might see rather more idiosyncrasies.  Is RFC793 still the right 
reference or should it be 793bis? Both are used.

Details of TCP also appear in
draft-ietf-i2nsf-capability-data-model
draft-ietf-i2nsf-consumer-facing-interface-dm
draft-ietf-i2nsf-nsf-monitoring-data-model
as do details of IP and a wide range of application and transport 
protocols; I suspect that those with an attention to detail and an 
interest in transport could have a field day here.

Tom Petch

---

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 24 Sep 2021 10:25:24 +0000

Thanks for the heads-up!

As already noted by Tom, there are multiple documents in the I2NSF working group. 

As TSV-ART reviewer, I have pushed already back against similar issues in draft-ietf-i2nsf-capability-data-model: https://mailarchive.ietf.org/arch/msg/i2nsf/94nz77vNHDpP8DkbXb2hzuuBjRk/

It would probably help if more contributors to TCPM have a look at these documents in I2NSF.

Michael

> -----Original Message-----
> From: tcpm <[email-masked]> On Behalf Of t petch
> Sent: Friday, September 24, 2021 12:06 PM
> To: tcpm <[email-masked]>
> Subject: [tcpm] Is ECN a valid TCP header flag?
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: tom petch <[email-masked]>
Date: Fri, 24 Sep 2021 10:32:05 +0000

From: Scharf, Michael <[email-masked]>
Sent: 24 September 2021 11:25

Thanks for the heads-up!

<tp>
Yes!

No knowledge of YANG needed. Search for 793 in the I-D and read the 'description'  clause and the 'reference' clause.  I find the documents from the data tracker Active WG where I2NSF comes under Security.  I know, you would like URLs but with my e-mail system that would take me the rest of the day:-(

Tom Petch

Michael

---

From: tom petch <[email-masked]>
Date: Fri, 24 Sep 2021 10:51:48 +0000

From: Scharf, Michael <[email-masked]>
Sent: 24 September 2021 11:25
To: tom petch; tcpm
Subject: RE: [tcpm] Is ECN a valid TCP header flag?

Thanks for the heads-up!

<tp>
Ah yes I had not seen that review.  I agree with most but not all of the review.  I found that I had to read five I-D, one now an RFC, to see how they hang together.  Thus I see capability as higher level and not needing the detail, whereas nsf-facing and consumer-facing are lower level and need the detail of which aspects of e.g. TCP header need to be specified in the I-D.

The five I-D were reviewed by five different YANG doctors which I find unfortunate; there is so much overlap that I think that you have to read all five.  Changing one may be an improvement but may make it out of line without changing the others (and one is an RFC).  I see 'capability-data-model', now -18,  as the starting point and have worked to bring the others in line with that if only in terminology.

Tom Petch

p.s. my ESP thinks that these e-mail are junk - grrrrr.

Michael

---

From: Jonathan Morton <[email-masked]>
Date: Fri, 24 Sep 2021 18:02:53 +0300

> On 24 Sep, 2021, at 1:05 pm, t petch <[email-masked]> wrote:
> 
>  base tcp-flags;
>    identity cwr {
>    identity ecn {
>    identity urg {
>    identity ack {
>    identity psh {
>    identity rst {
>    identity syn {
>    identity fin {
> with descriptions and references.  My knowledge of this is limited but I suspect that the reference for 'ecn' should be RFC3168 and not RFC793 but then should it be 'ece' and not 'ecn'?  I suspect that a TCP expert might see rather more idiosyncrasies.

I agree, it should definitely be ECE and not ECN.  The abbreviation is for "Echo Congestion Experienced", where "Congestion Experienced" refers to a codepoint of the ECN field in the IP header.  RFC-3168 describes the ECE and CWR (Congestion Window Reduced) flags and how they must be used.

The remaining established TCP flags are named here with their usual and familiar abbreviations.  I don't see any cause for concern there.

There are several additional TCP flags, in an adjacent byte, which are reserved for future use - effectively "should be zero" at origin and "should be ignored" upon receipt.  One of them was, for example, historically defined as NS (Nonce Sum), and other uses may arise in future.  Are these flags accounted for in the model?

 - Jonathan Morton

---

From: tom petch <[email-masked]>
Date: Fri, 24 Sep 2021 15:42:26 +0000

From: Jonathan Morton <[email-masked]>
Sent: 24 September 2021 16:02

<tp>

Thank you for the information; yes, I think that the I-D should reference RFC3168.  The model does not cater for additional flags but then it is not really that sort of model.  It is about security, about monitoring and action, so that it models the sort of things that a firewall might be configured to be interested in, such as SYN, port ranges, POP3 and so on; but as I said, there is much overlap with all sorts of IETF WG and I think that users would find it simpler if the terminology were to be the same   (and a transport AD might not feel the need to tear his hair out - one change the authors made at my request was to remove ICMP from the list of layer-4 protocols).

Tom Petch

 - Jonathan Morton