Re: [tcpm] draft-ietf-tcpm-tcp-edo

[John Leslie <[e-mail]>]

Joe Touch <[e-mail]> wrote:
> On 10/4/2014 1:24 PM, John Leslie wrote:
>> Bob Briscoe <[e-mail]> wrote:
>>> <snipP 
>>>
>>> There are three suggested additions to EDO:
>>> a) defer extra options until after the SYN/ACK
>>> b) require EDO on all segments
>> 
>> Please don't!
> 
> I'm not sure about your concern; we're talking about putting EDO in all
> segments of a connection *on which* EDO has been negotiated. Nobody is
> expecting EDO to be turned on for all connections.

   It's hard to know at every connection start whether at some later
point extra options will prove useful.

>>> c) include the payload size in the EDO option
>> 
>>    what about:
>> 
>>  d) set the Data Offset field to zero when using EDO?
>> 
>> (I may have missed something, but it seems to me that would prevent
>> the horror Bob mentioned.)
> 
> That just means that middleboxes won't see *any* of the options,
> including whether a segment is using TCP-AO (and thus modifying the
> segment would trash it).

   Middleboxes which don't understand EDO, indeed, won't see the extra
options. But this really doesn't matter, because they'll either pass
it correctly or drop it -- the same choices as if they _did_ understand
EDO.

   (I could have sworn it was Joe who said broken middleboxes need to
be replaced. ;)

> It doesn't address the scenario Bob described. Extended options could
> still be merged with user data if the segments are merged or rewritten
> in without consideration for EDO.

   The Data-Offset-Zero case can't lead to merging, because clueless
middleboxes won't be able to find _any_ options to merge.

====

   It might help for me to detail what I think Data-Offset-Zero means.

   The original SYN includes a two-byte option announcing that the
sender speaks EDO -- that is, it will understand if it receives an
EDO packet and it knows how to send one.

   The SYN-ACK MAY include a four-byte option announcing the option
space is larger than 40 bytes. Or it may include in the regular
option space a two-byte option simply announcing that it speaks EDO
but doesn't want to use it yet.

   If either of these doesn't happen, the connection is not EDO-capable.
But recall that the original SYN-sender knows how to speak EDO; thus
the SYN-ACK, upon sending an EDO option, MAY assume the connection to
be EDO-capable. (This assumption may prove false if there is a middlebox
which doesn't understand EDO. The ambiguity will be short-lived in that
case because the SYN-ACK with the EDO option won't arrive.)

   If the connection _is_ EDO-capable, both endpoints will know that
a Data Offset of zero indicates the presence of a four-byte EDO option
stating the actual length of the option space. Thus they can start
parsing the option space before learning its actual length.

   Middleboxes which don't understand EDO will of necessity drop the
packet instead of misinterpreting some of the actual options as
application data. The packet drop will indicate the probable presence
of such a middlebox. (I need not go into detail here about how to
deal with that, but questions will be welcomed.)

   Middleboxes which aren't trying to violate layering will simply
pass the IP packet without any damage (or drop it, if it violates
some rule they're trying to enforce).

   If a meddlebox drops the SYN or SYN-ACK EDO option, the endpoints
won't even try to speak EDO. If paths change and a different middlebox
drops a packet, we simply detect the problem when it arises.

====

>> I'm not sure we need to limit our thinking to detection-only -- but
>> that seems sufficient for our first RFC (if it's Experimental status).
> 
> It would help if you could give an example of any other option that
> corrects middlebox corruption; otherwise, we should set our expectations
> for this option accordingly.

   One _can_ only "correct" middlebox corruption by detecting it and
routing around it. Data-Offset-Zero will certainly detect it; and the
endpoints can route around it by avoiding EDO.

>>> We need experiments (including those already written up) to determine 
>>> how prevalent various middlebox behaviours are.
>> 
>> I agree experiments are needed. I prefer getting an Experimental
>> document out fairly quickly to trying to do all needed Experiments
>> before publishing.
> 
> By that logic, all work on all new TCP options should halt dead in its
> tracks.

   I can't think of a way to parse what I wrote so as to lead to that
conclusion. (I have to guess you missed the "to" before "trying to do".)

   Let me restate it:

   I prefer getting an Experimental document out fairly quickly for EDO.
This threatens to drag on interminably if we try to do all the needed
experiments before publishing an Experimental-track document. Also,
if we describe the experiments in such a document, it will be easier
for folks to help us with them.

> What we do need is to understand the prevalence of the byzantine
> failures we've been discussing (and no, let's not call them just
> "behaviors"; there needs to be a limit to what we allow on-path. at some
> point, that "behavior" is an attack or a bug and should be fixed rather
> than "observed").

   I sympathize!

   But eliminating bad behavior in-the-wild just doesn't happen. We
_can_ raise the awareness of it; and that will help _reduce_ it.
Just bad-mouthing it general won't even reach the folk who can help
us reduce the bad behavior. :^(

--
John Leslie <[e-mail]>