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

From: [email-masked]
Date: Wed, 15 Apr 2015 10:58:05 -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-02.txt
	Pages           : 22
	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-02

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

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:10:24 -0700

Hi, all,

This revision addresses feedback from the last IETF meeting.

It includes a variant that indicates the TCP segment length to detect
when coalescing that might interfere with EDO occurs.

It also includes more detailed motivation.

I'm doing an additional round of wordsmithing, but wanted to post one
ASAP since the previous one expired.

Joe

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

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 15 Apr 2015 23:59:22 -0400

> when coalescing that might interfere with EDO occurs.

This is one thing that I think we particularly want feedback from
the group on.

I think it's a very low-impact way (compared to adding checksums,
using AO, using IPsec, etc) in order to reasonably detect an
accidental pollution of the user data due to resegmentation.

-- 
Wes Eddy
MTI Systems

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 15 Apr 2015 23:45:30 -0700

Hi,

>> When an endpoint receives a segment using the 6-byte EDO
   Extension option, it MUST validate the Segment_Length field with the
   length of the segment as indicated in the TCP pseudoheader. If the
   segment lengths do not match, the segment MUST be discarded and an
   error SHOULD be logged in a rate-limited manner.

I am wondering if discarding a segment is safe enough.

Once resegmentation happens, I think we are not very sure how to recover it.

I guess it would be better to reset a connection.

Thanks,

--

Yoshi

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Apr 2015 14:31:11 -0700

On 4/15/2015 11:45 PM, Yoshifumi Nishida wrote:
> Hi,
> 
> On Wed, Apr 15, 2015 at 8:59 PM, Wesley Eddy <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

It's safe - the connection will fail after several failed
retransmissions anyway. That limit can be controlled with the TCP User
Timeout option.

Jumping to a reset would be quicker but might be premature. The sender
might be able to resend segments without EDO or the situation might be
transient.

Joe

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 26 Apr 2015 23:20:56 -0700

Hi Joe,

> retransmissions anyway. That limit can be controlled with the TCP User

Yes, you're right.
But, I'm guessing discarding segments will be almost the same thing as
resetting a connection except it takes rather long time in most cases.
Also, I think some applications (or mptcp) that have some sort of recovery
mechanisms might want quick reaction.

> might be able to resend segments without EDO or the situation might be

Hmm. falling back to normal TCP might be risky as we might not be sure if
EDO option is removed by a middlebox or not.
I think that's why the current draft says TCP MUST put EDO options in all
segments once it's negotiated.

Thanks,
--
Yoshi

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Apr 2015 08:39:46 -0700

On 4/26/2015 11:20 PM, Yoshifumi Nishida wrote:
> Hi Joe,
> 
> On Mon, Apr 20, 2015 at 2:31 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     > On Wed, Apr 15, 2015 at 8:59 PM, Wesley Eddy <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >

It depends on whether the situation is persistent or not.

> Also, I think some applications (or mptcp) that have some sort of
> recovery mechanisms might want quick reaction. 

They can set the user timeout to be shorter.

> Hmm. falling back to normal TCP might be risky as we might not be sure
> if EDO option is removed by a middlebox or not.

In those cases you'd want stronger protection, e.g., TCP-AO or IPsec.

> I think that's why the current draft says TCP MUST put EDO options in
> all segments once it's negotiated.

Yes. There's also the possibility of using the EDO header without using
the extension area it provides (e.g., EDO values of 15 or below),
though. That presumes that the extended-area options are "optional", though.

Joe