Subject: Re: [tcpm] #18 (tcp-edo): MUST the EDO option be included in all subsequent segments after being negotiated?

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

On 10/16/2014 12:01 PM, tcpm issue tracker wrote:
> #18: MUST the EDO option be included in all subsequent segments after being
> negotiated?
> 
>  If this is required, lack of EDO option would cause the segment to be
>  dropped

I think the same answer to #1 applies here. The only way this would be
of concern is if such an "asymmetric middlebox that also passes TCP"
appeared on-path mid-connection. Again, such a middlebox is hypothetical
AFAICT, but given the impact, I can see adding the length validation
inside EDO to detect this condition.

Joe

---

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

-- 
-------------------------+-------------------------------------------------
 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/18>
tcpm <http://tools.ietf.org/tcpm/>

---

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

Joe Touch <[email-masked]> wrote:
> I think the same answer to #1 applies here.

   Likewise, I think my answer to #1 applies...

> The only way this would be of concern is if such an "asymmetric
> middlebox that also passes TCP" appeared on-path mid-connection...

   I'm not sure it has to be "asymmetric" if it appears mid-connection.

   And I really think it unwise to assume that no middlebox "appears"
mid-connection. TCP is used for some very-long connections, during
which routing may change and/or software updates may be applied.

--
John Leslie <[email-masked]>

---

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

> which routing may change and/or software updates may be applied.

The typical such middlebox - a NAT - would break the connection if
shifted without state being transferred.

It'd be useful to describe why you think a stateless middlebox would be
doing this sort of stuff, otherwise we're chasing phantoms...

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 17 Oct 2014 21:29:46 +0000

I don't recall whether this has already been suggested in the earlier threads:

Given that the best answer to the question #18 seems to depend on the question whether certain (possibly hypothetical) middleboxes indeed exist or not, one solution could be to mandate both modes in the EDO spec, right? For instance, the connection originator would then (by some signal to be determined) select which mode to use.

Sure, that approach has downsides as well, but if we lack good data to make an informed choice right now, we could let the market decide...

Michael

---

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

On 10/17/2014 2:29 PM, Scharf, Michael (Michael) wrote:
> Given that the best answer to the question #18 seems to depend on the
> question whether certain (possibly hypothetical) middleboxes indeed
> exist or not, one solution could be to mandate both modes in the EDO
> spec, right? For instance, the connection originator would then (by
> some signal to be determined) select which mode to use.
> 
> Sure, that approach has downsides as well, but if we lack good data
> to make an informed choice right now, we could let the market
> decide...

Sure; my preference would be to allow the two modes to be independent as
separate options, e.g.:

	- EDO

	- a lightweight "TCP Integrity Option" that indicated the
	user data length for a given segment as transmitted

That way, EDO could be coupled with TIO as needed, and TIO could be
omitted where redundant (e.g., when using TCP-AO at least).

Joe

---

From: John Leslie <[email-masked]>
Date: Fri, 17 Oct 2014 19:01:09 -0400

> shifted without state being transferred.

   NATs aren't the only middleboxes out there.

   Nor is it safe to assume there will only be one middlebox on a path.

   Programming only for "typical" cases produces support nightmares.

> doing this sort of stuff, otherwise we're chasing phantoms...

   NAT is not the only "stateful" thing middleboxes do; and it's
common advice to middlebox-writers to pass doubtful traffic when they
reboot, hoping to recover state by context.

   I haven't put much thought into what a "stateless" middlebox might
be doing -- my experience is with middleboxes which keep "state", but
not NAT-like state which breaks as soon as you have to forward an
"incoming" packet.

   I really must advise against defining "unlikely" middlebox behavior
as out-of-scope for EDO.

   (Need I remind folks that NSA is known to be maintaining middleboxes?)

---

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

>    Programming only for "typical" cases produces support nightmares.

Agreed. But I wonder how many boxes rewrite segments that are stateless.

If that's either extremely rare or (more likely, IMO), a fantasy, we're
doing a lot of work to address a use case that doesn't exist.

> reboot, hoping to recover state by context.

That's a good way to corrupt the very state you're trying to recover.
Good to know that's "common advice".

> not NAT-like state which breaks as soon as you have to forward an

We need to know what they do, not what they might *ever* do. We can't
chase ghosts (despite the upcoming holiday).

>    I really must advise against defining "unlikely" middlebox behavior

TCP is not a diagnostic tool.

If a user is that concerned about these issues, IMO they ought to be
using IPsec or TCP-AO. We should not design every feature into every
option.

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 20 Oct 2014 08:18:50 +0000

> omitted where redundant (e.g., when using TCP-AO at least).

Indeed, a separate option could be a useful approach, in particular if that option could also be re-used for other TCP extensions. Obviously, the protocol design would have to be sorted out.

Michael (chair hat off)