Subject: [tcpm] a comment on draft-touch-tcpm-tcp-edo-03.txt

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 10 Jul 2014 22:26:42 -0700

(as individual)
Hi,
I basically support this draft, but I am wondering how to react to
EDO-unfriendly middleboxes.
When we find EDO-unfriendly middleboxes by using TCP-AO or EDO-checksum,
how we should react? Shall we terminate the connection? Or, is there any
way to fallback safely? Or just re-transmit the segments? I think this
point should be clarified in the draft.

Thanks,
--
Yoshi

---

From: Joe Touch <[email-masked]>
Date: Fri, 11 Jul 2014 11:08:44 -0700

> EDO-unfriendly middleboxes.

Define "unfriendly".

If a middlebox strips the option, it will be disabled for the 
connection. If a middlebox drops the segment based on the option, the 
connection won't proceed. If a box reflects the option in a SYN segment 
without knowing what it is, i.e., for a "transparent proxy", the 
connection will proceed with corrupt data (NB: that's just a hijacked 
connection).

Both of those happen for any new (or old) option.

> how we should react?

There's no way to find EDO-unfriendly middleboxes per se except with an 
additional checksum. TCP-AO, or even IPsec won't find boxes that permit 
those protocols but not EDO.

 > Shall we terminate the connection? Or, is there any

I don't.

We cannot write new specifications with the assumption that old 
specifications aren't being minimally followed. We'd never get anywhere.

I think the issue of what happens if these boxes are encountered should 
be addressed, and blame placed where it lies - with the "meddlebox".

Joe

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 11 Jul 2014 16:09:14 -0700

Hi Joe,

On Fri, Jul 11, 2014 at 11:08 AM, Joe Touch <[email-masked]> wrote:

> If a middlebox strips the option, it will be disabled for the connection.
> If a middlebox drops the segment based on the option, the connection won't
> proceed. If a box reflects the option in a SYN segment without knowing what
> it is, i.e., for a "transparent proxy", the connection will proceed with
> corrupt data (NB: that's just a hijacked connection).
>

Sorry, I was not clear enough.
What I'm thinking is the following types

1: middleboxes that drop options
2: middleboxes that re-segment (coalesce or split) packets

I'm basically fine for 1:, but I'm having a bit concern on 2: as 2: can
work with other options (I know this is also tricky for mptcp options, but
mptcp uses some tricks to handle this.)

> I think the issue of what happens if these boxes are encountered should be
> addressed, and blame placed where it lies - with the "meddlebox".

This makes sense to me if you claim dealing with middleboxes like 2: is
out-of-scope of the draft.
But, I thought the reason why you mentioned TCP-AO or checksums in EDO in
the draft is to find such middleboxes.

My point is if you mentioned integrity checking mechanisms in the draft,
why you don't mention the behavior when you find errors.

Thanks,
--
Yoshi

---

From: Joe Touch <[email-masked]>
Date: Fri, 11 Jul 2014 16:32:09 -0700

On 7/11/2014 4:09 PM, Yoshifumi Nishida wrote:
> Hi Joe,
>
> On Fri, Jul 11, 2014 at 11:08 AM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     connection. If a middlebox drops the segment based on the option,
>     the connection won't proceed. If a box reflects the option in a SYN
>     segment without knowing what it is, i.e., for a "transparent proxy",
>     the connection will proceed with corrupt data (NB: that's just a
>     hijacked connection).
>

Yes; that's always a concern.

> work with other options (I know this is also tricky for mptcp options,
> but mptcp uses some tricks to handle this.)

If you use option space, there is no trick needed - that's why I was 
against mptcp using in-band space.

EDO will break when exposed to these non-compliant devices. The only way 
to detect it would be to use an additional checksum (as noted in the 
text) - at least until the middlebox decides it wants to update that 
checksum but ignore EDO.

>     There's no way to find EDO-unfriendly middleboxes per se except with
>     an additional checksum. TCP-AO, or even IPsec won't find boxes that
>     permit those protocols but not EDO.
>
>     I think the issue of what happens if these boxes are encountered
>     should be addressed, and blame placed where it lies - with the
>     "meddlebox".
>
>

Agreed.

> But, I thought the reason why you mentioned TCP-AO or checksums in EDO
> in the draft is to find such middleboxes.

Not so much to find them as to ensure that it EDO would fail safely in 
the presence of those boxes.

> why you don't mention the behavior when you find errors.

Because you don't know the reason for the error. You're not finding 
anything definite; all you know is that the packet has been reformatted 
in a way that corrupts its ability to support EDO.

At that point, you should terminate the connection with an error. 
There's nothing you can do to recover except retransmit the segments 
without EDO, but I don't think we should be adding a signal to make that 
happen.

Joe

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 14 Jul 2014 07:20:19 -0700

Hi Joe,

On Fri, Jul 11, 2014 at 4:32 PM, Joe Touch <[email-masked]> wrote

> Not so much to find them as to ensure that it EDO would fail safely in the
> presence of those boxes.
>
> anything definite; all you know is that the packet has been reformatted in
> a way that corrupts its ability to support EDO.
>

I agree.

> At that point, you should terminate the connection with an error. There's
> nothing you can do to recover except retransmit the segments without EDO,
> but I don't think we should be adding a signal to make that happen.

I support terminating connections with an error. My personal preference is
to mention it explicitly as I don't want to see someone work on some
"smart" logics with different interpretations. Especially, if it aims for
standard track.

Thanks,
--
Yoshi