Subject: [tcpm] Analysis of the TCP EDO option

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 20 Jul 2015 13:20:01 +0200

Hello,

Last week after discussion with the TCPM chairs, we wrote a quick draft
that analyses the EDO proposal under discussion.The draft has now been
posted, see below

Olivier

A new version of I-D, draft-bonaventure-tcpm-edo-analysis-00.txt
has been successfully submitted by Olivier Bonaventure and posted to the
IETF repository.

Name: draft-bonaventure-tcpm-edo-analysis
Pages: 20
URL:
https://www.ietf.org/internet-drafts/draft-bonaventure-tcpm-edo-analysis-00.txt
Status:
https://datatracker.ietf.org/doc/draft-bonaventure-tcpm-edo-analysis/
Htmlized: https://tools.ietf.org/html/draft-bonaventure-tcpm-edo-analysis-00

Abstract:
  This document analyses how the proposed TCP EDO option copes with
  various types of middlebox interference.

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Jul 2015 10:02:25 -0700

Oliver,

This issue is already covered in Section 7 of
draft-ietf-tcpm-tcp-edo-03, excepting only:

1. blindly reflecting new options
	This is a hazard of all new options, and should be covered
	by a single test option rather than being built into every
	new option.

2. how to handle detection of middlebox tampering of Segment_Length
	the doc already notes that such events should be noticed

	the simplest solution would be to stop using EDO in the
	other direction, and to change the rule about what to do
	when non-EDO segments are received, e.g., to make them
	cause EDO to be dropped on the connection and the user to be
	signalled

These both could have been handled with an email, as I have done.

Joe

On 7/20/2015 4:20 AM, Olivier Bonaventure wrote:
> Name:draft-bonaventure-tcpm-edo-analysis
> Pages:20
> URL:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 20 Jul 2015 19:37:21 +0200

> Joe,
>         new option

I remember that this was solved in the previous version of the draft. This
is not a severe limitation, but it is worth being mentioned in the document.

>         the doc already notes that such events should be noticed

When reading the draft, I could not find how a receiver had to really react
upon reception of such an invalid segment. It should be better explained in
the draft.

>         cause EDO to be dropped on the connection and the user to be

This solution should be documented precisely in the draft so that
implementors know what is the fallback mechanism. In the current EDO, there
is no feedback from the receiver to the sender and this can create problems
where the two hosts may stop to communicate. This fallback mechanism is key
to preserve the connectivity in case of middlebox interference

> These both could have been handled with an email, as I have done.

If the TCPM working group wants to have a safe mechanism to extend the TCP
header, then this mechanism must be evaluated in details. Our draft is a
contribution in the validation/improvement of EDO. We have also spent quite
some time to implement the proposed EDO in tracebox so that we could start
measurements to verify how EDO passes through existing middleboxes. I think
that such an experiment makes sense before adopting any solution to extend
the TCP header. Such an extension must be safe before it can be deployed.

Olivier

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Jul 2015 10:45:26 -0700

On 7/20/2015 10:37 AM, Olivier Bonaventure wrote:
> I remember that this was solved in the previous version of the draft.
> This is not a severe limitation, but it is worth being mentioned in the
> document.

Agreed.

> When reading the draft, I could not find how a receiver had to really
> react upon reception of such an invalid segment. It should be better
> explained in the draft.

Handling of segments with incorrect Segment_Length is explained in
Section 5.3.

> implementors know what is the fallback mechanism.

It would be a change to the document, but could be a reasonable one.

> In the current EDO,
> there is no feedback from the receiver to the sender and this can create
> problems where the two hosts may stop to communicate. This fallback
> mechanism is key to preserve the connectivity in case of middlebox
> interference

Agreed.

> If the TCPM working group wants to have a safe mechanism to extend the
> TCP header, then this mechanism must be evaluated in details. Our draft
> is a contribution in the validation/improvement of EDO. 

It could (and IMO should) have been done with an email. I'm fairly
responsive to emails posted where they should be.

No, TCPM doesn't track vague messages announcing a long set of documents
to other WGs (MPTCP, in particular, where these issues originated).

If you're discussing a WG doc, it's always more effective to do so on
that WG's mailing list.

> We have also
> spent quite some time to implement the proposed EDO in tracebox so that
> we could start measurements to verify how EDO passes through existing
> middleboxes. I think that such an experiment makes sense before adopting
> any solution to extend the TCP header. Such an extension must be safe
> before it can be deployed.

Certainly, but we also need more than anecdotal evidence. There's always
a middlebox somewhere that does something odd. We cannot possibly design
protocol extensions that pass though every possible contortion of what
every possible middlebox will do.

IMO, when you find something like this, you really ought to try to also
find out where the box is and post those details. Bugs need to be fixed,
not danced around.

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 21 Jul 2015 14:11:37 +0000

Hi Olivier,

the Option Injection case, wouldn’t that be something that could be addressed by setting DO = min(len(tcp.options), max.tcp.option.len); EDO = len(tcp.options).

That is to say, to keep DO and EDO equal if no extended space is needed, and setting DO to it’s maximum if more option space is used?

I assume, that meddleboxes inserting options would refrain from doing so if there is no space left in the DO part, not?

Best regards,
  Richard

From: tcpm [mailto:[email-masked]] On Behalf Of Olivier Bonaventure
Sent: Montag, 20. Juli 2015 19:37
To: Joe Touch
Cc: [email-masked] ([email-masked])
Subject: Re: [tcpm] Analysis of the TCP EDO option

Joe,

I remember that this was solved in the previous version of the draft. This is not a severe limitation, but it is worth being mentioned in the document.

When reading the draft, I could not find how a receiver had to really react upon reception of such an invalid segment. It should be better explained in the draft.

This solution should be documented precisely in the draft so that implementors know what is the fallback mechanism. In the current EDO, there is no feedback from the receiver to the sender and this can create problems where the two hosts may stop to communicate. This fallback mechanism is key to preserve the connectivity in case of middlebox interference

If the TCPM working group wants to have a safe mechanism to extend the TCP header, then this mechanism must be evaluated in details. Our draft is a contribution in the validation/improvement of EDO. We have also spent quite some time to implement the proposed EDO in tracebox so that we could start measurements to verify how EDO passes through existing middleboxes. I think that such an experiment makes sense before adopting any solution to extend the TCP header. Such an extension must be safe before it can be deployed.

Olivier

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Jul 2015 08:24:04 -0700

Why are we trying to solve a hypothetical that's also a violation of Rfc793?

Besides, injection is already detected by the seg_length field.

Joe

> On Jul 21, 2015, at 7:11 AM, Scheffenegger, Richard <[email-masked]> wrote:
> 
> Hi Olivier,
>