Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-03.txt

From: [email-masked]
Date: Wed, 15 Apr 2015 11:23:43 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.

        Title           : TCP Extended Data Offset Option
        Authors         : Joe Touch
                          Wesley M. Eddy
	Filename        : draft-ietf-tcpm-tcp-edo-03.txt
	Pages           : 23
	Date            : 2015-04-15

Abstract:
   TCP segments include a Data Offset field to indicate space for TCP
   options but the size of the field can limit the space available for
   complex options such as SACK and Multipath TCP and can limit the
   combination of such options supported in a single connection. This
   document updates RFC 793 with an optional TCP extension to that
   space to support the use of multiple large options. It also explains
   why the initial SYN of a connection cannot be extending a single
   segment.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Apr 2015 11:31:48 -0700

A bit more word-smithing and deeper explanation of the Segment Length field.

For discussions, please compare 03 to 01.

Joe

On 4/15/2015 11:23 AM, [email-masked] wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 15 Apr 2015 17:29:51 -0700

Joe

you cited michio's paper that
"In the split case,   the key concern is if the split happens within
the option extension
   space or if EDO is silently copied to both segments without copying
   the corresponding extended option space contents. However, the most
   comprehensive study of these cases indicates that "although
   middleboxes do split and coalesce segments, none did so while
   passing unknown options" [Ho11]."

a) their "unknown options", according to the paper (sec 4.6), was
really one (MP_DATA) option.
b) MP_DATA, is not like EDO that touches payload space afaict

Don't want to be pedantic, but there are middleboxes out there use GRO stuff
How do we safely use EDO w/o worrying TCP is still reliable?

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 16 Apr 2015 00:05:07 -0400

> How do we safely use EDO w/o worrying TCP is still reliable?

My guess has been that this would be treated very similarly to ECN
blackholes.  Once the issue in the path is detected, that fact is
cached, and subsequent connections to the same destination don't
attempt to use the feature.

I think the change to add segment length to the option actually goes
a long way in making this detectable too, and of course, there are
other ways as well (such as John Leslie's checksum draft).

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Apr 2015 21:56:53 -0700

>> b) MP_DATA, is not like EDO that touches payload space afaict

Although they are different, they both are unknown options. Middleboxes
should not modify segments with options they don't understand - even
before there were middleboxes, there were options that prohibited
segment modification (alternate checksum, e.g.).

That said, they clearly already do what they shouldn't, which is why we
extended EDO to provide a detection mechanism.

>> Don't want to be pedantic, but there are middleboxes out there use GRO stuff

Our experience with GRO is a different issue. GRO explicitly claims to
NOT merge or split segments with options that are not understood, but
our experience with GRO in Linux was that this self-proclaimed
requirement was not satisfied.

Our code was not bulletproofed; it's entirely possible that there is a
bug in how we implemented EDO that caused an undesired interaction with
GRO. However, it's also entirely possible that GRO has a bug in it that
needs to be fixed.

We need to separate the GRO issue from middlebox manipulation until we
understand why GRO is behaving in was that currently appear inconsistent
*with its own claims*.

>> How do we safely use EDO w/o worrying TCP is still reliable?

a) use the Segment_Length variant, as is already recommended in this
version (that's why we put it there)

b) use EDO with a mechanism that truly protects TCP against middlebox
misbehavior (e.g., IPsec, TCP-AO)

...
> other ways as well (such as John Leslie's checksum draft).

The length field will catch any changes that modify the length of a
segment in transit. It will not catch other content rewriting. A
checksum might catch rewriting too, but costs more to implement.

Ultimately, we have to acknowledge that TCP describes communications
between the endpoints - and that any intermediary should not modify what
it doesn't *completely* understand (or, more specifically, that when it
does modify things, it acts as an endpoint in place of the receiver).

Joe