Subject: Re: [tcpm] #17 (tcp-edo): Can the EDO extension be allowed in SYN/ACK?

From: Pasi Sarolahti <[email-masked]>
Date: Thu, 16 Oct 2014 22:08:45 +0300

In case you wonder about the mail format, I just thought to test the tools’ issue tracker… But let these be the three email threads I mentioned in previous mail.

- Pasi

On 16 Oct 2014, at 21:53, tcpm issue tracker <[email-masked]> wrote:

> #17: Can the EDO extension be allowed in SYN/ACK?
> 
> “Yes" would be nice, but an option-removing middlebox on return path would
> cause corruption of data
> 
> -- 
> -------------------------+-------------------------------------------------
> Reporter:               |      Owner:  draft-ietf-tcpm-tcp-
>  [email-masked]  |  [email-masked]
>     Type:  task         |     Status:  new
> Priority:  major        |  Milestone:
> Component:  tcp-edo      |    Version:
> Severity:  -            |   Keywords:
> -------------------------+-------------------------------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/tcpm/trac/ticket/17>
> tcpm <http://tools.ietf.org/tcpm/>
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Oct 2014 12:21:20 -0700

>  “Yes" would be nice, but an option-removing middlebox on return path would

I am skeptical of asymmetric paths through middleboxes that ALSO allow
TCP connections to pass.

I.e., asymmetric paths involving NATs would fail.

I would prefer if we considered detecting this condition (Bob suggested
adding some sort of length indicator in the EDO option itself) rather
than prohibiting it.

Joe

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Fri, 17 Oct 2014 06:52:28 +0000

> I.e., asymmetric paths involving NATs would fail.

I fully agree w/ Joe on this point.

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

---

From: "tcpm issue tracker" <[email-masked]>
Date: Thu, 16 Oct 2014 18:53:50 -0000

---

From: John Leslie <[email-masked]>
Date: Fri, 17 Oct 2014 11:44:20 -0400

Pasi Sarolahti <[email-masked]> wrote:
>> ?Yes" would be nice, but an option-removing middlebox on return path would
>> cause corruption of data

   This is one of the things I intended for Data-Offset-zero to solve.

   But first, let's make sure we're talking about the same thing.

   I understand the issue to be that EDO in the initial SYN indicates
that the originating endpoint speaks EDO; that EDO is received by the
"server", which then sends a SYN-ACK with EDO including a length, but
some middlebox strips out the EDO on the SYN-ACK without dropping the
packet; thus the originating endpoint receives junk.

   I would stipulate that the middlebox in question is seriously broken.
But I don't agree that such a mess is too unlikely to consider.

   With Data-Offset-zero, any packet (including a SYN-ACK) which uses
the option-length field would also set Data-Offset to zero. Any endpoint
which receives a Data-Offset of zero without an EDO option specifying
the actual length knows it has received junk, and must discard the
offending packet.

   It's likely, of course, that a middlebox would discard the packet
before it ever reached the endpoint -- but if it reaches the endpoint,
the endpoint immediately knows it's fighting middlebox damage, and
can act accordingly (rather than waiting for a timeout).

   Thus, it's "safe" to use EDO length on the SYN-ACK: the damage
will be detectable.

   Or are we talking some other scenario?

--
John Leslie <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Oct 2014 10:06:54 -0700

> But I don't agree that such a mess is too unlikely to consider.

TCP is not a diagnostic tool.
(yes, I'm going to continue to repeat that).

> the actual length knows it has received junk, and must discard the

So you're proposing a middlebox that DOES remove EDO but does not
rewrite DO==0?

Why would that ever happen? (SYN/ACK presumably should be excepted from
splitting and joining, and even if it weren't what would it be joined with?)

Maybe I should say that "TCP is not a diagnostic tool and middleboxes
are not demonic".

Joe

---

From: John Leslie <[email-masked]>
Date: Fri, 17 Oct 2014 18:48:51 -0400

>> packet; thus the originating endpoint receives junk.

   (I wonder whether Joe disagrees with that statement of the issue...)

> (yes, I'm going to continue to repeat that).

   If Joe would stop saying this, I'd probably keep my mouth shut...

   But in fact, there is so much obfuscation getting in the way of our
traditional diagnostic tools that we will sooner or later be forced
to _use_ TCP as a diagnostic tool.

   :^( :^( :^(

> So you're proposing a middlebox that DOES remove EDO but does not

   I'm going to have to ask Joe to restate that question. I can make no
sense of it as written.

   I believe folks have stipulated the existence of muddleboxes that
remove individual options they "don't like". I am not an academic type;
so I don't regularly scan the literature for papers documenting this,
but a quick Google search reveals:

http://dl.acm.org/citation.cfm?doid=2535828.2535830

   (Can we please stop asking for citations for things which are
blindingly obvious to people in Operations?)

> splitting and joining, and even if it weren't what would it be joined with?)

   Quoting from that paper:

" Often, middleboxes remove a specific TCP option by replacing it
" with the NOP TCP option to avoid having to update the segment length.

   And, on the question of SYN/ACK being excepted from splitting/joining,
note the many attempts to pass user data in the first SYN. (No, I am
not going to bother to google for that!)

> Maybe I should say that "TCP is not a diagnostic tool and middleboxes

   Maybe I should say, "We need diagnostic tools within TCP; and
muddleboxes do not need to be demonic in order to screw things up."

   Or maybe we could find a way to discuss issues without resorting to
exchanges like this? I find them very distasteful.

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Oct 2014 16:53:14 -0700

> to _use_ TCP as a diagnostic tool.

We might, but if we do we'll need to design a true diagnostics option
for that purpose. I don't intend to cloud the design of every new option
with diagnostics in the meantime.

> remove individual options they "don't like". 

If by "stipulated" you mean there's empirical evidence, yes.

> I am not an academic type;

The reason we ask for citations is to understand whether we agree with
your interpretation of the claims. In this case, the primary reference
in [Hesmans13] for this evidence is [Honda11], which is the one I cited
in the updated EDO draft already.

> " with the NOP TCP option to avoid having to update the segment length.

That's a claim made in [Hesmans13] with no corroborating evidence. The
claim follows a citation of [Honda11], which discussions option removal
but never mentions the NOP option or keeping the option length constant.

[Hesmans13] makes no claim to have done a study of this by examining the
actual contents of packets.

That's why citing the paper is important.

> not going to bother to google for that!)

Fair enough; I won't respond to unsubstantiated assertions either, though.

I will note that [Hesmans13] doesn't talk about the SYN or SYN/ACK being
split. [Honda11] notes that all splitting or coalescing involves options
being rewritten from rather than transparently passed, so it wouldn't
matter.

Joe