Subject: [tcpm] 793bis item - reserved bit behavior

From: Joe Touch <[email-masked]>
Date: Thu, 03 Jul 2014 13:24:45 -0700

Hi, all,

As per the discussion of EDO, I'd like to suggest that 793bis should be 
more clear in the description of Reserved bits as follows:

MUST be set as zero on outgoing segments. This is superseded only when 
the bit is otherwise defined in the future through an update to this 
document.

MUST be ignored on receipt on incoming segments, except as already 
integrated in checksums and security mechanisms (e.g., TCP-AO). This is 
superseded only when the bit is otherwise defined in the future through 
an update to this document.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 Jul 2014 13:31:33 -0700

> an update to this document.

Also:

MUST NOT be modified except at the packet source, because it is already 
included in the TCP checksum and TCP-AO.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 03 Jul 2014 16:47:47 -0400

> an update to this document.

I fully agree.

I don't recall if any of the BEHAVE documents, or others, capture it,
but there may also need to be a sentence begging middleboxes not to
filter on these bits or pervert them in-transit.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 Jul 2014 14:08:38 -0700

> filter on these bits or pervert them in-transit.

Yup - I sent that in a followup.

Joe

---

From: Dan Wing <[email-masked]>
Date: Thu, 3 Jul 2014 15:45:08 -0700

> filter on these bits or pervert them in-transit.

BEHAVE was scoped to not discuss firewall-ish behavior like filtering.

As for firewalls interfering with those bits, that is the sort of protocol conformance performed by many firewalls to prevent protocol attacks (TCP christmas tree, overlapping segments, out of window RST, etc.).  We would not be successful in changing firewall behavior with an RFC saying they are mis-guided to interfere with packets with Reserved bits set, especially that we don't have any documented reason those bits would be set.  It might be useful to encourage nerd knobs for the Reserved bits, and allow market forces will cause the vendors to allow those Reserved bits by default.  I suggest something like "So that the Reserved bits can be used in the future, and to allow deployment of TCP-AO, a network security function (e.g., host firewall or network firewall) SHOULD NOT interfere (that is, block or modify such packets) with TCP packets that have any of the Reserved bits set.  If a network security function does interfere with those TCP packets, the security device SHOULD provide a configuration to avoid interfering with those TCP packets."

-d

> 
> -- 
> Wes Eddy
> MTI Systems
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Jul 2014 17:30:17 -0700

On 7/3/2014 3:45 PM, Dan Wing wrote:
> As for firewalls interfering with those bits, that is the sort of
> protocol conformance performed by many firewalls to prevent protocol
> attacks (TCP christmas tree, overlapping segments, out of window RST,
> etc.).

They have confused "something they didn't expect" with "an attack". I've 
seen that faulty logic before.

> We would not be successful in changing firewall behavior with an
> RFC saying they are mis-guided to interfere with packets with Reserved
> bits set, especially that we don't have any documented reason those bits
> would be set.

IMO, anything that modifies a TCP header is acting as a host, and ought 
to be following RFC1122.

When that's not the case, it's less a "middlebox" and more a "meddlebox" 
(i.e., it meddles where it ought not). We shouldn't need documented 
reasons not to meddle.

> It might be useful to encourage nerd knobs for the
> Reserved bits, and allow market forces will cause the vendors to allow
> those Reserved bits by default.

Uh, no. That just makes things worse.

 > I suggest something like "So that the
> Reserved bits can be used in the future, and to allow deployment of
> TCP-AO, a network security function (e.g., host firewall or network
> firewall) SHOULD NOT interfere (that is, block or modify such packets)
> with TCP packets that have any of the Reserved bits set.

TCP-AO is very clear. If you change anything in the header, it will fail 
because *that's the kind of attack it's designed to detect*.

The exceptions fpr TCP-AO are:
	a) TCP options, which can be ignored on a per-connection basis
	if desired

	b) A given IP address and TCP port, to allow NAT traversal

Exceptions for other TCP options may vary, e.g., if we have (another) 
alternate TCP checksum.

> If a network
> security function does interfere with those TCP packets, the security
> device SHOULD provide a configuration to avoid interfering with those
> TCP packets."

This is more than a security issue. Middleboxes SHOULD provide a way to 
change its understanding of protocols they attempt to validate or modify 
to avoid their configuration from limiting that of a valid endpoint.

Joe

---

From: Dan Wing <[email-masked]>
Date: Mon, 7 Jul 2014 17:59:02 -0700

On Jul 7, 2014, at 5:30 PM, Joe Touch <[email-masked]> wrote:

> They have confused "something they didn't expect" with "an attack". I've seen that faulty logic before.

I don't disagree.  My statement above is a result of an hour discussion with marketing about MPTCP and why our products do what they do.

> IMO, anything that modifies a TCP header is acting as a host, and ought to be following RFC1122.

Yes, I recall the similar argument about modifying IP header that resulted in RFC6864 (specifically around IPID).

> When that's not the case, it's less a "middlebox" and more a "meddlebox" (i.e., it meddles where it ought not). We shouldn't need documented reasons not to meddle.
> 

Yes, I understand and agree with the desire to change the default behavior of a firewall box that is doing protocol validation.  I am pointing out that products have a different philosophy, and even if Cisco or another couple of vendors changed default behavior this month it would still be years away from becoming common default behavior on networks -- if at all -- as (for example) some network operators think host-generated TCP ISN are the path to ruin, and want network devices to (re?) randomize ISNs, even though it was a decade ago that host-generated ISNs were predictable, and even though steganographic communications can be achieved using a million other techniques.

> TCP-AO is very clear. If you change anything in the header, it will fail because *that's the kind of attack it's designed to detect*.
> 
> Exceptions for other TCP options may vary, e.g., if we have (another) alternate TCP checksum.
> 
>> If a network
> This is more than a security issue. Middleboxes SHOULD provide a way to change its understanding of protocols they attempt to validate or modify to avoid their configuration from limiting that of a valid endpoint.

That's the nerd knob I described above.

-d