Subject: [tcpm] Some text on updating what "RFC 793 says that the Reserved fields"

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 22 Jul 2015 13:37:54 +0200

If the group thinks that TCP reserved fields need to be handled in the 
normal IETF protocol way, there is a standards-track RFC that would 
kindof support this:

RFC3360: Inappropriate TCP Resets Considered Harmful (BCP: 60) from 
2002, see "2.1. The TCP Reserved Field":

    RFC 793 says that the Reserved field in the TCP header is reserved
    for future use, and must be zero.  A rephrasing more consistent with
    the rest of the document would have been to say that the Reserved
    field should be zero when sent and ignored when received, unless
    specified otherwise by future standards actions.  However, the
    phrasing in RFC 793 does not permit sending resets in response to TCP
    packets with a non-zero Reserved field, as is explained in the
    section above.

Gorry

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 Jul 2015 13:47:23 -0700

Hi, Gorry,

> 2002, see "2.1. The TCP Reserved Field":
...
>    ...However, the

This RFC basically gives a good reason NOT to handle this in a "normal
IETF protocol way" - you've basically doomed the connection to failing
to generate RSTs for legacy code, which means it's not safe.

There is an exception, which would be:

	MUST NOT use those bits until support for them has been
	confirmed via the TWHS

However, once negotiated, the point of "ignore if not supported" becomes
irrelevant.

AFAICT, there's thus no useful way to update RFC793 on how these bits
are interpreted if not supported.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 Jul 2015 13:57:47 -0700

Hi, all,

Going back to RFC3360 in more detail, let me correct my previous note
and clarify:

- I misinterpreted RFC3360 to say that "it wasn't possible to send RSTs
on connections with Reserved bits set"
	it says that TCP should not send a RST *only because* those
	bits are set

- IMO, it's OK to define these fields as
	sender MUST zero if not supported
	receiver MUST ignore if not supported

	HOWEVER that also implies that these bits would only be useful
	for optional capabilities with silent failure.

I.e., considering the possibilities when it comes to unused fields:

	QUIET)
		sender MUST zero if not supported
		receiver MUST ignore if not supported

	LOUD)
		sender MUST zero if not supported
		receiver MUST tell the sender if not zero
`		and not supported

		that error can be "SOFT" or "HARD"
			SOFT - ignore the segment, but tell the sender
			HARD - kill the connection (which should inform
				the sender too)

RFC3360 allows for QUIET errors but not LOUD ones. QUIET errors support
soft, unidirectional signals only.

If use of these bits is negotiated in advance (e.g., as with ECN), then
none of this matters. Those bits can be defined as QUIET, LOUD/HARD or
LOUD/SOFT at negotiation time.

I.e., I don't mind updating RFC793 if needed, but I think it's a bit
more complex than just "set to zero/ignore if not supported".

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sat, 25 Jul 2015 12:50:11 +0000

Hi Joe,

I think it warrants clarification with 2119 wording in an update in any case - including during SYN.

Even for the ECN bits (ECE, CWR; NS) we observed behaviors of QUIET (majority) and LOUD/HARD (minority) in the wild, for SYNs, when ECN is not supported; And to be more exact, that affects both sets [ECE,CWR] and [NS] independently from each other...

More clarity for an implementer is needed.

Best regards,
   Richard

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Freitag, 24. Juli 2015 22:58
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [tcpm] Some text on updating what "RFC 793 says that the
> Reserved fields"
> 
> Hi, all,
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm