Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02

[Bob Briscoe <[e-mail]>]

Joe,

At 16:15 30/09/2014, Joe Touch wrote:


>On 9/30/2014 7:45 AM, Bob Briscoe wrote:
> > Joe & John,
> >
> > At 19:11 29/09/2014, Joe Touch wrote:
> >
> >
> >> On 9/29/2014 9:58 AM, John Leslie wrote:
> >> > Joe Touch <[e-mail]> wrote:
> >> >> On 9/26/2014 12:53 PM, John Leslie wrote:
> >> >>> Bob Briscoe <[e-mail]> wrote:
> >> >>>> " If an upgraded TCP client includes the TCP Fast Open option
> >> >>>> " [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the
> >> extra
> >> >>>> " TCP options after the end of the payload.
> >> >>>
> >> >>> Indeed, that is a good way to ensure that the SYN receiver is aware
> >> >>> of the sender's intent to place something _after_ the data
> >> intended to
> >> >>> be passed to the application.
> >> >>
> >> >> I'd like to understand the logic behind this claim.
> >> >
> >> >    Good!
> >> >
> >> >> Regardless of where signalling information is placed:
> >> >>
> >> >> - legacy servers will (irrevocably) accept it as
> >> >> application data; the only way to undo it is to
> >> >> terminate the connection*
> >
> > As you know, syn-op-sis is designed so the client detects a legacy
> > SYN/ACK and terminates that connection.
>
>By the time the client receives the SYN/ACK, the legacy server would
>have already forwarded FTO data to the user.
>
> > The reason for requiring a syn-op-sis client to only ever locate TFO
> > beyond the Data Offset in a SYN with extra options is precisely so that
> > it will never use TFO to ask a legacy server to pass the payload to the
> > app at the same time as it is placing (other) options in the payload.
>
>Ahh - I see.
>
> > And the wording in the draft generalises this to any future option that
> > might cause a server to pass payload to the app during the 3WHS, not
> > just TFO.
>
>The problem is that you can't necessarily make assertions about options
>that already exist, and this might complicate TCP option processing --
>you need to enforce it on both client and server, and legacy receivers
>can't know that this is a problem.

I can make this assertion, because it only applies to the behaviour 
of a client that has been upgraded for SYNOPSIS. This text requires 
such an update to also alter any pre-existing TFO code.


> >> >> - upgraded servers will know where to find it
> >> >>
> >> >> Except to make parsing more complex, what is the perceived benefit of
> >> >> using trailer-based signalling?
> >
> > The fact that you (Joe) are asking the same question that I've already
> > answered (on the list and in the draft) implies you don't accept the
> > answer. But unless I can understand what you don't accept about the
> > answer, I can only answer it the same way as I already have. However, I
> > will try to spell it out more fully...
> >
> > a) Ultimately, locating options as a trailer is not intrinsic to
> > syn-op-sis. At this pre-implementation stage, a quick edit to the draft
> > could locate them straight after the Data Offset.
> >
> > b) However, as the initial proposition, I have located the options as a
> > trailer, because middleboxes exist that look at the dest port, and they
> > assume that the app-layer protocol is that associated with the port (eg.
> > http if the port is 80). [Acting on this assumption violates layering,
> > but I'll come to that.]
> >
> > Then they parse the first X bytes of the payload, where the choice of X
> > depends on the expect protocol and how much they can do at line rate.
>...
>
>I am skeptical that middleboxes parse SYN payloads, but even if they did
>this might still not work. It depends on the size of the segment and the
>size of the extension option space.

If a box does parse a SYN payload, it is much more likely to work if 
it works from the start, because usually the parsing stops once it 
has found what it wants.

If the parsing comes to the clean end of the app-layer commands, a 
really paranoid box (e.g. an intrusion detection system) might be 
programmed to be suspicious of odd inexplicable bytes afterwards. But 
I figure that's much less likely than tripping up on unrecognisable 
bytes before it's even got started.


> > * Locating extra options beyond the Data Offset (whether before or after
> > the payload) provides a distinction between middlebox and destination
> > options for the future.
>
>That's necessary because the DO field is limited anyway.
>
> > * Locating extra options after the payload is to avoid certain classes
> > of existing muddleboxes, but with no intention to outwit meddleboxes
> > (spelled out below).
>...
> >> >    Indeed, to a middlebox, harder-to-find translates to "expensive",
> >> > possibly prohibitively expensive. To an actual endpoint, the expense
> >> > is bearable -- if you need to act on both anyway, it's a toss-up...
> >
> > That's why I'm happy to evolve to a position where the current TCP
> > options are intended for middleboxes, and it's at least acceptable if
> > extra 'destination' options are 'harder-to-find'.
>
>All TCP options are "destination" options.

I forgot to add an <irony> tag to the destination adjective.


>However, the nature of dual-SYN requires that certain options always
>come after the extension (as above) - but that also means it might
>interfere with this partitioning by option type.
>
>E.g., I would not be surprised at all to see TFO be of particular
>interest to middleboxes - esp. to support load balancing while
>supporting TFO.

The critical point here is that there are two viewpoints on which 
options are for middleboxes:
- the sender's viewpoint
- the middlebox's viewpoint.

Enabling the sender to separating options into two sets allows it to 
express its viewpoint. A middlebox does not have to /express/ its 
viewpoint. It just /acts/ in whatever way it chooses.

Nonetheless, once the separation is in place, it might be possible 
for the sender to encyrypt the extra options. Then the power to act 
unilaterally swings the other way.


> >> I'm not sure I understand this. User data can't be placed in (or removed
> >> from) the segment until after all the options are handled anyway.
> >
> > I'm not sure why the sender has any constraint on the order in which it
> > serialises a segment. Surely it can construct the segment in memory in
> > any order, then serialise it?
>
>It can, but I don't understand the need to support more esoteric
>middleboxes (including those I still consider meddlers) but not the
>typical case where headers are built then data is added (or headers are
>built in one place, data in the other, and the two combined).
>
>Putting trailing options into that mix complicates lots of
>implementations - and can be difficult to support in offload engines,
>depending on how they handle buffers.
>
> > John and Joe, I'm actually unclear what the context is for this part of
> > the conversation. As a general point, it's not healthy to have email
> > conversations where all the participants start with the words, "I
> > haven't properly read the draft but...", then proceed to say there are
> > probably problems, and then try to solve those probable problems.
>
>I didn't start my email with that statement.

Sorry, I noticed John did and I thought I recalled that you had in 
the email before that, but, checking back, you actually said "I did 
not follow the latest discussions very closely"

>...
>
> > It would be more useful for participants to trust that the author(s) of
> > a draft wrote it because they have a solution, and they have taken some
> > care to write it up carefully. Then it would be useful to hear critique
> > (or praise) if there are problems with the draft (or not).
>
>I disagree; it's useful to post directed questions and have direct
>answers. Not everyone wants to try to infer intent from pages of text.

Certainly. But only after having read the draft under discussion.


>...
> >> >    Dual-SYN solutions would be expected to place fast-open in both
> >> SYNs,
> >> > probably with the same cookie. In the legacy case, nothing can prevent
> >> > the payload being passed to the application long before the sender
> >> > becomes aware of the state of the other SYN.
> >>
> >> Right - the legacy case of FO + any dual-SYN approach has this problem.
> >
> > Wrong. It is easy to solve for dual-SYN as explained in the draft (and
> > above). As long as TFO is after the Data Offset, a legacy server won't
> > pass the payload to the app during the 3WHS.
>
>Agreed. As long as TFO is after the DO.

Great. We're making progress.

Cheers



Bob


>Joe

________________________________________________________________
Bob Briscoe,                                                  BT