Subject: Re: [tcpm] TCP Four-Way Handshake

From: Bob Briscoe <[email-masked]>
Date: Mon, 3 Nov 2014 23:12:14 +0000

Joe,

A 4WHS RFC could specify precisely how any 
existing TCP option would be negotiated within a 
4WHS (ie it would update a number of TCP option RFCs all at once).

Then, if/when 4WHS was implemented, any necessary 
changes to the negotiation code for each TCP 
option could be included in the same release as the update to the 4WHS.

You both stated that each TCP option spec defines 
its own negotiation logic, and that there is no 
general negotiation rule. But the talking at 
cross-purposes seemed to go on for dozens of 
rounds despite this. It seemed to end without any 
apparent reconciliation - perhaps your keyboards 
burned out? So I thought the above points might still be useful.

In David's latest update 
<draft-borman-tcpm-tcp4way-00> he has added a 
roster of all the existing TCP options and how 
they are negotiated. This could easily be updated 
to say how any that need to be changed MUST be negotiated if a 4WHS were used.

Bob

At 21:02 21/10/2014, Joe Touch wrote:

>On 10/21/2014 1:55 PM, David Borman wrote:
> >
> >> On Oct 21, 2014, at 3:09 PM, Joe Touch <[email-masked]> wrote:
> >> On 10/21/2014 11:50 AM, David Borman wrote:
> >>>
> >>>> On Oct 21, 2014, at 12:47 PM, Joe Touch <[email-masked]> wrote:
> >> ...
> >>>> You're thus proposing NEW requirements on option negotiation, and that
> >>>> ought to be clear in your document as well as considered in comparison
> >>>> to all existing and pending options.
> >>>
> >>> What new requirements?
> >>
> >> That options be negotiated exclusively by appearance in the SYN in each
> >> direction.
> >
> > You're reading things that aren’t there.  There is no one mechanism for
> > enabling use of TCP options.
>
>That is my primary point.
>
> >  Each option defines for itself how it is
> > to be used, including any enablement.  For 
> many existing options, enablement
> > is defined as the option being present in both a packet sent and received
> > with the SYN bit.  Examples include Window 
> Scale, Timestamps, and SACK Permitted.
> >
> > That is nothing new, and is not a requirement for any other TCP option.
>
>4WHS won't work when options are not defined as being enabled by the
>option being present in both SYN segments of a 3WHS.
>
> > ...
> >>>> But it has to include *anything* that the client might want to ACK.
> >>>
> >>> No it doesn’t.  It would only include options that it would still
> >>> like to be enabled, but weren’t included in the inbound SYN.  Why
> >>> on earth would it offer up to enable options it doesn’t want to use?
> >>
> >> It has to send all the options that might be coming in the client's
> >> SYN/ACK. It has to read minds or be exhaustive.
> > ...
> >
> > Absolutely not.
> >
> > In the 4WHS, for options that are only enabled by their presence in the
> > SYN exchange, the servers SYN/ACK can contain additional options to allow
> > the client to agree to enable them by including them in it’s SYN/ACK.
> > That’s it.  End of story.
>
>Again:
>
>#1      Client sends SYN with A, B ->
>
>#2                              <- Server sends SYN/ACK
>                                 with what? it can send A,B
>                                 what else?
>
>#3      Client sends SYN/ACK with X,Y->
>
>#4                              <- server, never having seen X or Y
>                                 MUST have had to send X AND Y in
>                                 its SYN/ACK
>
>If all options are enabled by occurring in a SYN in both directions, we
>have to also note that #2 is the only SYN(ACK) the server sends.
>
>#2 SYN/ACK has to anticipate the options sent in #3 client SYN/ACK.
>
>How exactly does it do that? Doesn't it have to send ANY option that
>MIGHT be arriving in the client SYN/ACK - but it has to do that BEFORE
>the client sends it.
>
>Joe
>
>_______________________________________________
>tcpm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tcpm

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 3 Nov 2014 23:43:50 +0000

Yoshifumi,

I've just sent a critique of tcp4way to David & 
the list. I've pointed out problems with many of 
the things you say you like about it inline below...

At 04:34 22/10/2014, Yoshifumi Nishida wrote:
>Hi David,
>
>(as an individual of course..)
>I personally like this idea from the following reasons.
>
>1: use SYN-ACK to initiate feature negotiation 
>(as discussed in the previous thread)

tcp4way just seems to prevent use of TCP options 
on more segments (and for more rounds).

>2: it can expand SYN options space to 80 octets 
>without overriding DO field. It might be more middlebox friendly.

I agree that if options are going to be placed 
beyond DO, and /if/ the signal that says they are 
there could be stripped or normalised by 
middleboxes, it is important that the signal that 
says they are there is ultra-safe - checked and 
double-checked for middlebox interference.

However, deferring the point at which a 
connection moves to the established state doesn't 
suddenly mean that the segments sent before this didn't need any TCP options.

Also:
* Some IDSs and perhaps some stateful firewalls 
might not like the abnormal extra SYN/ACK.
* The segments have to be abnormal (e.g. 4W flag 
or a TCP option) in order to signal 4WHS support. 
Your [Honda] study found option stripping was far 
from a minor effect, probably due to split 
connections - a split connection would also strip a Reserved flag.

>3: we might be able to re-design syn cookie 
>solution that can address the previous issues.

What previous issues?

>4: even if an option in SYN/ACK has been removed 
>by middleboxes, it can reliably find this situation.

So can any solution that is prepared to add as much latency as the 4WHS.

>5: in mptcp, initiating subflow requires 4 
>packet exchanges. With 4-way handshake 
>mechanism, we might be able to do this with non-mptcp-specific way.Â

There seems little point in doing a 4-way 
exchange in a non-mptcp-specific way if it still 
has the same latency problem. There is certainly 
little point if another solution is available 
that adds no latency and traverses middleboxes.

>6: similar to 5, it might be useful some secure 
>negotiations where we don't want to put 
>something that requires computations in SYN, but 
>want to perform some cryptic algorithms in later packet exchanges.

Any specific TCP security option can always 
require that computation is deferred, without 
making a 4WHS the /only/ way to extend option space for all TCP options.

Nonetheless, I do appreciate you posting your 
views as an individual, so that we can have a discussion about these points.

Cheers

Bob

>(as one of co-chairs..)
>
>When you submit new version, please include 
>-tcpm- in the draft's name so that we can track it easily.
>
>Regards,
>--
>Yoshi

At 04:34 22/10/2014, Yoshifumi Nishida wrote:
>Hi David,
>
>(as an individual of course..)
>I personally like this idea from the following reasons.
>
>1: use SYN-ACK to initiate feature negotiation 
>(as discussed in the previous thread)
>
>2: it can expand SYN options space to 80 octets 
>without overriding DO field. It might be more middlebox friendly.
>
>3: we might be able to re-design syn cookie 
>solution that can address the previous issues.
>
>4: even if an option in SYN/ACK has been removed 
>by middleboxes, it can reliably find this situation.
>
>5: in mptcp, initiating subflow requires 4 
>packet exchanges. With 4-way handshake 
>mechanism, we might be able to do this with non-mptcp-specific way.Â
>
>6: similar to 5, it might be useful some secure 
>negotiations where we don't want to put 
>something that requires computations in SYN, but 
>want to perform some cryptic algorithms in later packet exchanges.
>
>
>(as one of co-chairs..)
>
>When you submit new version, please include 
>-tcpm- in the draft's name so that we can track it easily.
>
>Regards,
>--
>Yoshi
>
>
>
>On Tue, Oct 14, 2014 at 2:44 PM, David Borman 
><<mailto:[email-masked]>[email-masked]> wrote:
>Hi,
>
>Iâ€™ve just posted draft-borman-tcp4way-00.txt, 
>which describes a 4-Way TCP handshake that is 
>intended to allow the TCP EDO option to be used 
>during the initial SYN exchange.Â  This was 
>mentioned during the TCPM WG at the last IETF 
>meeting.Â  Please see the draft for more details.
>
>Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  -David Borman
><mailto:[email-masked]>[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 03 Nov 2014 16:24:03 -0800

On 11/3/2014 3:12 PM, Bob Briscoe wrote:
> Joe,
> 
> A 4WHS RFC could specify precisely how any existing TCP option would be
> negotiated within a 4WHS (ie it would update a number of TCP option RFCs
> all at once).
> 
> Then, if/when 4WHS was implemented, any necessary changes to the
> negotiation code for each TCP option could be included in the same
> release as the update to the 4WHS.

Yes, but it might limit how such options can be negotiated. That's the
sense in which neither I nor Dave wants to have 4WHS include such limits.

Joe

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 4 Nov 2014 01:09:57 -0800

Hi Bob,

On Mon, Nov 3, 2014 at 3:43 PM, Bob Briscoe <[email-masked]> wrote:

>  Yoshifumi,
>
> I've just sent a critique of tcp4way to David & the list. I've pointed out
> problems with many of the things you say you like about it inline below...
>
> 1: use SYN-ACK to initiate feature negotiation (as discussed in the
> previous thread)
>
>
> tcp4way just seems to prevent use of TCP options on more segments (and for
> more rounds).
>

Hmm. Sorry, I'm not very sure if I understand this.

> 2: it can expand SYN options space to 80 octets without overriding DO
> field. It might be more middlebox friendly.
>
>
> I agree that if options are going to be placed beyond DO, and /if/ the
> signal that says they are there could be stripped or normalised by
> middleboxes, it is important that the signal that says they are there is
> ultra-safe - checked and double-checked for middlebox interference.
>
> However, deferring the point at which a connection moves to the
> established state doesn't suddenly mean that the segments sent before this
> didn't need any TCP options.
>
> Also:
> * Some IDSs and perhaps some stateful firewalls might not like the
> abnormal extra SYN/ACK.
> * The segments have to be abnormal (e.g. 4W flag or a TCP option) in order
> to signal 4WHS support. Your [Honda] study found option stripping was far
> from a minor effect, probably due to split connections - a split connection
> would also strip a Reserved flag.
>

Yep. You got a point and we know the discussions for middlebox is always
tricky.
I know this is not a very strong argument, but if we use payload as option
space, we'll need extra mechanisms to avoid being parsed wrongly, which
will increase complexity.

> 3: we might be able to re-design syn cookie solution that can address the
> previous issues.
>
> What previous issues?
>

In SYN cookie, tcp cannot use TCP options other than mss. Also, if the
third ack is lost, the connection might be frozen because the server cannot
retransmit SYN/ACK.

> 4: even if an option in SYN/ACK has been removed by middleboxes, it can
> reliably find this situation.
>
>

Yep. maybe. but, not sure about complexity.

> 5: in mptcp, initiating subflow requires 4 packet exchanges. With 4-way
> handshake mechanism, we might be able to do this with non-mptcp-specific
> way.Â
>
>
> There seems little point in doing a 4-way exchange in a non-mptcp-specific
> way if it still has the same latency problem. There is certainly little
> point if another solution is available that adds no latency and traverses
> middleboxes.
>

Well, it may be a very tiny point, but, the third ACK can be pure ACK.
So, in order to perform 4-way exchange,  mptcp may need to violate a basic
rule in TCP, which is "don't send ack for ack"
I personally don't want to see this kind of adhoc logic if possible.

> 6: similar to 5, it might be useful some secure negotiations where we
> don't want to put something that requires computations in SYN, but want to
> perform some cryptic algorithms in later packet exchanges.
>
>
> Any specific TCP security option can always require that computation is
> deferred, without making a 4WHS the /only/ way to extend option space for
> all TCP options.
>

Yep. again, you maybe right, but not sure about complexity.
A problem in 3WHS is there's no good way to retransmit the third ACK.
We might be able to solve it with additional logic, but at the same time, I
would like to see something simpler.

I think I'm focusing on complexity rather than latency.
I'm not very sure if this is right or not, but I believe complexity is also
an important factor.

However, I cannot and don't want to say 4WHS is less complex than others
for now, it will be required more detailed analysis and comparisons.
I just intuitively thought it looks like that. I might be wrong. I just
would like to say we need more analysis.

Thanks,
--
Yoshi

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 4 Nov 2014 16:52:21 +0000

Yoshifumi,

At 09:09 04/11/2014, Yoshifumi Nishida wrote:
>Hi Bob,
>
>On Mon, Nov 3, 2014 at 3:43 PM, Bob Briscoe 
><<mailto:[email-masked]>[email-masked]> wrote:
>Yoshifumi,
>
>Hmm. Sorry, I'm not very sure if I understand this.Â

See email to Dave Borman yesterday.
<http://www.ietf.org/mail-archive/web/tcpm/current/msg09322.html>
Look for my first point: "Following a false trail?"
When you step back and think about it, tcp4way is 
just confusing us into thinking it is doing 
something useful, but I don't believe it is.

>beyond DO, and /if/ the signal that says they 
>are there could be stripped or normalised by 
>middleboxes, it is important that the signal 
>that says they are there is ultra-safe - checked 
>and double-checked for middlebox interference.
>
>connection moves to the established state 
>doesn't suddenly mean that the segments sent 
>before this didn't need any TCP options.
>
>Also:
>or a TCP option) in order to signal 4WHS 
>support. Your [Honda] study found option 
>stripping was far from a minor effect, probably 
>due to split connections - a split connection would also strip a Reserved flag.
>
>
>Yep. You got a point and we know the discussions 
>for middlebox is always tricky.
>I know this is not a very strong argument, but 
>if we use payload as option space, we'll need 
>extra mechanisms to avoid being parsed wrongly, 
>which will increase complexity.Â

EDO, tcp4way, EOS, Inner Space /all/ use payload 
as option space, because if an option like EDO 
that extends the header is stripped, the data 
receiver thinks the data offset has reverted to 
DO, so the place where the options had been placed becomes payload.

I explained to Joe in the posting pasted below, 
why there is a safety issue when header and 
payload do not necessarily share the same fate.

At 21:36 14/10/2014, Bob Briscoe wrote:
>>[Inner Space] does not involve any additional 
>>TCP options in the TCP option space, ie the 
>>space between the end of the 20B base TCP 
>>header and the max 60B Data Offset. This makes 
>>each [Inner Space] segment /inherently/ robust against option stripping.
>>
>>All the additional options of [Inner Space] are 
>>beyond the Data Offset, including the option 
>>that creates the additional space for the other 
>>options. So they all share the same fate.
>>
>>Whereas, in EDO the option that creates the 
>>space beyond DO is not itself beyond DO. So the 
>>option that creates the space is at risk of 
>>being stripped without stripping the space it 
>>created. The two do not /inherently/ share the same fate.
>>
>>Yes, checks can be added to EDO to check for 
>>option stripping (e.g. deferring use of extra 
>>space until after the SYN/ACK). But this has to 
>>assume that stripping behaviour remains 
>>consistent through the flow. Whereas, with 
>>[Inner Space], each individual segment is 
>>robust against option stripping, all by itself.

This is why Joe has updated EDO to now require an 
EDO option on every segment, even if no extra 
option space is needed. Then if the receiver sees 
the EDO option disappear at a certain point in 
the connection, it knows that the payload could be corrupt.

This is still not as inherently safe as Inner 
Space. For instance segmentation offload might be 
programmed to forward unrecognised options but it 
still resegments the data. So if it blindly 
forwarded EDO with resegmented data, the app would receive corrupt payload.

>Â
>In SYN cookie, tcp cannot use TCP options other 
>than mss. Also, if the third ack is lost, the 
>connection might be frozen because the server cannot retransmit SYN/ACK.

OK. This is why I have published the EchoCookie 
option separately. I originally had it within the 
Inner Space draft, but it should be usable by any of the approaches.

>Â
>>4: even if an option in SYN/ACK has been 
>>removed by middleboxes, it can reliably find this situation.
>

Lots of people can design simple solutions that 
do not work. The task is surely to design the 
simplest solution that does work. We need to 
agree whether latency is part of the design brief.

>>mechanism, we might be able to do this with non-mptcp-specific way.Ã‚
>
>Well, it may be a very tiny point, but, the third ACK can be pure ACK.Â
>So, in order to perform 4-way exchange, Â mptcp 
>may need to violate a basic rule in TCP, which is "don't send ack for ack"

This is not a tiny point. It is important to try 
to avoid ad hoc exceptions. I am having that 
discussion with the tcpcrypt authors, concerning a MAC on a pure ACK.

Because we /are/ changing basic stuff about TCP 
here, we have to be prepared to change even 
'basic' rules. However, if we do, we have to 
replace them with equally universal new rules, not just ad hoc hacks.

>>something that requires computations in SYN, 
>>but want to perform some cryptic algorithms in later packet exchanges.
>
>A problem in 3WHS is there's no good way to retransmit the third ACK.Â
>We might be able to solve it with additional 
>logic, but at the same time, I would like to see something simpler.
>
>I think I'm focusing on complexity rather than latency.Â
>I'm not very sure if this is right or not, but I 
>believe complexity is also an important factor.Â
>
>However, I cannot and don't want to say 4WHS is 
>less complex than others for now, it will be 
>required more detailed analysis and comparisons.
>I just intuitively thought it looks like that. I 
>might be wrong. I just would like to say we need more analysis.

Simplicity is very important, because otherwise bugs will appear.
However, as I said, the task is to design the 
simplest solution that works, not a simple solution that doesn't work.

I am certain that a solution that adds latency 
will not see any deployment - ie. it will not 'work'.

I also want /one/ solution that /completely/ gets 
rid of the complexity of middlebox traversal for 
every other TCP option. It is false simplicity if 
the middlebox problem is not solved when 
providing extra option space. Then every TCP 
option still has all the traversal complexity.

Finally, I would caution against measuring the 
complexity of a scheme by the number of pages of 
the draft. For instance, the protocol spec in 
inner-space-01 is only 12pp, because I have spent 
a lot of effort simplifying the protocol design. 
But the draft is 49pp, much of which is 
justifying all the subtle aspects of what appears to be a simple design.

Most authors don't explain their rationale in a 
draft. They don't realise that other people might 
not infer their intent from the design, then they 
have to write the rationale repeatedly in 
response to questions on mailing lists.

I have posted a presentation about Inner Space that is a quick way to get it:
<http://www.bobbriscoe.net/present.html#1411inner-space>

>Thanks,

This is useful conversation - thank you

Bob

---

From: Joe Touch <[email-masked]>
Date: Tue, 04 Nov 2014 09:46:16 -0800

On 11/4/2014 8:52 AM, Bob Briscoe wrote:
...
> EDO, tcp4way, EOS, Inner Space /all/ use payload as option space,
> because if an option like EDO that extends the header is stripped, the
> data receiver thinks the data offset has reverted to DO, so the place
> where the options had been placed becomes payload.
> 
> I explained to Joe in the posting pasted below, why there is a safety
> issue when header and payload do not necessarily share the same fate.

That's also true for DO, FWIW.

However, the issue of how the option is encoded is orthogonal to these
solutions. Bob's in-band encoding would work in any of them, but also
ends up "encoding TCP inside TCP", which can easily lead to escalation
(as I've pointed out on the list already).

For that reason, I don't support the idea of in-band encoding, but
that's independent of the way in which the space itself is indicated and
coordinated.

...
> This is why Joe has updated EDO to now require an EDO option on every
> segment, even if no extra option space is needed. Then if the receiver
> sees the EDO option disappear at a certain point in the connection, it
> knows that the payload could be corrupt.
> 
> This is still not as inherently safe as Inner Space.

And neither would be as safe as running encrypted TCP inside TCP.

The question is whether we need to deal with this issue, i.e., whether
such middlebox asymmetries can occur in practice.

> ...We need to agree
> whether latency is part of the design brief.

+1

Joe

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 7 Nov 2014 21:50:43 +0000

Joe,

>(as I've pointed out on the list already).

I am encoding TCP /options/ inside TCP Data, which is significantly 
different from encoding TCP inside TCP (which I agree would not be 
appropriate).

>that's independent of the way in which the space itself is indicated and

I believe TCP options should have always been within the TCP Data (as 
a design principle, not just as a hack for middlebox traversal). 
That's where I started from.

See the couple of pages position paper I submitted to the IAB SEMI 
workshop: 
<http://bobbriscoe.net/projects/2020comms/tcp/briscoe-inspace_semi.pdf>

>such middlebox asymmetries can occur in practice.

I definitely want to be able to use encryption of TCP data to also 
encrypt TCP options. Again, this is not TCP in TCP. It's TCP options in TCP.

> > whether latency is part of the design brief.

+2

Vote early, vote often.

Bob

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Nov 2014 13:57:05 -0800

> different from encoding TCP inside TCP (which I agree would not be

There's little difference to me.

> I believe TCP options should have always been within the TCP Data (as a
> design principle, not just as a hack for middlebox traversal). That's
> where I started from.

Just as I start from the converse position.

IMO, TCP has a header. It's either extensible or not. If it is, then
anyone who interprets the header *and* knows it can't understand it
KNOWS it's doing something wrong if it acts on it.

Joe