Subject: Re: [tcpm] RFC793bis draft 14 Reserved Bits

From: Mike Kosek <[email-masked]>
Date: Tue, 3 Dec 2019 17:18:09 +0000

Hi,

I would second the proposal to be more explicit. If we would add a MUST of unaltered traversal in this specific case, I am wondering if this should be addressed in other fields as well. Obviously there are limitations for certain option types, or src/dst port, but Flags and Window Size seem like perfect fits. Flags would also be the subsequent step of Rodney's and Joe's proposal, as bits would not be covered any longer if they are assigned.

Best,
Mike

On 28. Nov 2019, at 04:52, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:

On Nov 27, 2019, at 6:44 PM, Rodney W. Grimes <[email-masked]<mailto:[email-masked]>> wrote:

Hi tcpm,

Sorry for bumping this, maybe it got overlooked during 106.

Catching up on draft-ietf-tcpm-rfc793bis-14, I was wondering why the rsrvd bits are not explicitly stated as a formal MUST requirement:

"Must be zero in generated segments and must be ignored in received segments, if corresponding future features are unimplemented by the sending or receiving host."

To my understanding, the current phrasing is up to interpretation, i.e., someone might opt to not implement it as stated due to the missing formal MUST - Please prove me wrong if I am missing something.

I would even like to see it go further and add "they MUST be ignored by the network, and traverse the network unchanged.”

Perhaps further explicitly:

they MUST be ignored by the network and MUST traverse the network unchanged

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 4 Dec 2019 09:59:33 -0500

On 11/27/2019 10:52 PM, Joe Touch wrote:
>
>> On Nov 27, 2019, at 6:44 PM, Rodney W. Grimes <[email-masked]> wrote:
>>
>>> Hi tcpm,
>>>

This clarification seems good to me, and it looks like everyone who's 
chimed in so far agrees, so I can put it into the upcoming revision.

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 4 Dec 2019 10:12:15 -0500

On 12/3/2019 12:18 PM, Mike Kosek wrote:
>
> I would second the proposal to be more explicit. If we would add a 
> MUST of unaltered traversal in this specific case, I am wondering if 
> this should be addressed in other fields as well. Obviously there are 
> limitations for certain option types, or src/dst port, but Flags and 
> Window Size seem like perfect fits. Flags would also be the subsequent 
> step of Rodney's and Joe's proposal, as bits would not be covered any 
> longer if they are assigned.

In the case of reserved bits, I believe the reason we're trying to be so 
clear is that we want any new feature that might use them to work.  At 
least, in the past when this came up, that was why the current 793bis 
text on the reserved bits differs a little from the original 793 text 
(which is just "Reserved for future use. Must be zero.").

I think it would be a mistake and fruitless to try to say for the other 
individual fields which ones MUST be unaltered by the network.  
Generally, this is the expectation for the entire segment, even though 
that expectation doesn't typically hold anymore (due to NAT, etc).  I 
wouldn't say much more than that, because it's inviting misunderstanding 
that it's okay to twiddle with any bits and violate laying whenever the 
doc doesn't explicitly indicate not to.

---

From: Mike Kosek <[email-masked]>
Date: Mon, 9 Dec 2019 07:43:56 +0000

I think it would be a mistake and fruitless to try to say for the other individual fields which ones MUST be unaltered by the network.  Generally, this is the expectation for the entire segment, even though that expectation doesn't typically hold anymore (due to NAT, etc).  I wouldn't say much more than that, because it's inviting misunderstanding that it's okay to twiddle with any bits and violate laying whenever the doc doesn't explicitly indicate not to.

Fair enough.

In the case of reserved bits, I believe the reason we're trying to be so clear is that we want any new feature that might use them to work.  At least, in the past when this came up, that was why the current 793bis text on the reserved bits differs a little from the original 793 text (which is just "Reserved for future use.  Must be zero.").

I agree. However, future features assigning Rsrvd could extend the Control Bits with SHOULD requirements. As ECN shows with SHLD-8 "A TCP SHOULD implement ECN as described in RFC 3168", the usage is recommended, but not required. If someone opts to not include RFC 3168, it is not stated how this TCP must handle the unused bits. I think that an explicit statement of how to handle these cases will be beneficial, i.e., as a MUST within Control Bits of Section 3.1:
"A TCP that does not implement a Control Bits optional feature MUST handle it as a Rsrvd Bit."

Best,
Mike

On 4. Dec 2019, at 16:12, Wesley Eddy <[email-masked]<mailto:[email-masked]>> wrote:

In the case of reserved bits, I believe the reason we're trying to be so clear is that we want any new feature that might use them to work.  At least, in the past when this came up, that was why the current 793bis text on the reserved bits differs a little from the original 793 text (which is just "Reserved for future use.  Must be zero.").

I think it would be a mistake and fruitless to try to say for the other individual fields which ones MUST be unaltered by the network.  Generally, this is the expectation for the entire segment, even though that expectation doesn't typically hold anymore (due to NAT, etc).  I wouldn't say much more than that, because it's inviting misunderstanding that it's okay to twiddle with any bits and violate laying whenever the doc doesn't explicitly indicate not to.

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

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 11 Dec 2019 18:12:30 +0000

Wes,

> chimed in so far agrees, so I can put it into the upcoming revision.

I think it's important to make this a requirement for middleboxes as 
well as just 'the network'. Where I would define middlebox as a function 
acting on L4 (TCP) fields without being a full implementation of TCP.

I know some middlebox developers will ignore it. But their customers 
(operators) cannot require middleboxes to comply with IETF spec's if we 
don't write what middleboxes should do in our specs.

You might find some of the text in the AccECN spec on middlebox 
requirements useful (and pls send comments if it could be improved):
https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-09#section-3.3

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Joe Touch <[email-masked]>
Date: Thu, 12 Dec 2019 07:08:58 -0800

> On Dec 11, 2019, at 10:12 AM, Bob Briscoe <[email-masked]> wrote:
> 
> Wes,
> 
>> This clarification seems good to me, and it looks like everyone who's chimed in so far agrees, so I can put it into the upcoming revision. 
> 
> I think it's important to make this a requirement for middleboxes as well as just 'the network'. Where I would define middlebox as a function acting on L4 (TCP) fields without being a full implementation of TCP.

RFC1812. ;-)

> I know some middlebox developers will ignore it. But their customers (operators) cannot require middleboxes to comply with IETF spec's if we don't write what middleboxes should do in our specs.

That hasn’t helped in the past. Laws for the lawless aren’t productive.

Joe