Subject: [Maprg] Fwd: [tcpinc] TCP-ENO draft issues

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 4 May 2016 10:14:16 +0200

Hi maprg,

there is an on-going thread about tcp option stripping on the tcpinc mailing list (see below). Two problem cases have been identified:

1) Strip of non-SYN option while SYN-options pass correctly

2) Reflection of SYN options in the SYN/ACK (by load-balancers/proxies)

Does anybody have further data here?

Mirja

> Anfang der weitergeleiteten Nachricht:
> 
> Von: David Mazieres <[email-masked]>
> Betreff: Aw: [tcpinc] TCP-ENO draft issues
> Datum: 2. Mai 2016 um 01:41:25 MESZ
> An: Christoph Paasch <[email-masked]>, [email-masked]
> Kopie: [email-masked]
> Antwort an: David Mazieres expires 2016-07-30 PDT <[email-masked]>
> 
> Christoph Paasch <[email-masked]> writes:
> 
>> Hello,
>> 
>> I have read through the TCP-ENO draft and have a few comments:
>> 
>> 
>> First, am wondering whether there might be an issue when the third ACK
>> gets lost.
>> 
>> Specifically, the draft says that a host MUST disable ENO if the
>> following condition is met:
>> 
>>   4.  The first ACK segment received by a host does not contain an ENO
>>       option.
>> 
>> So, if this ACK gets lost, and the client goes on with sending
>> (encrypted) data, the server won't be able to know whether ENO has
>> been successfully negotiated or not and how to interpret the data.
>> 
>> To overcome this, one possible way would be to include the ENO-option
>> in every data-segment that a host is sending after the 3-way handshake
>> until successful use of ENO has been confirmed by the receiver.
> 
> Indeed, this is a good point.  The idea is really that you MUST include
> the ENO option whenever you ACK a SYN segment.  The problem is that the
> ACK might be cumulative.  So we would like flows to look like this:
> 
>   A -> B:  SYN ENO
>   B -> A:  SYN-ACK ENO
>   A -> B:  ACK ENO (lost)
>   A -> B:  ACK ENO* data
> 
> The draft is not at all clear about the need for the ENO marked by *.
> Your suggestion is one way to fix this.
> 
>> But even then, there might be a middlebox that removes the ENO-option
>> from non-SYN segments (assuming that we want to support such kind of
>> middleboxes). The sender will thus send encrypted data with the
>> ENO-option. The receiver receives this encrypted data without the
>> ENO-option (due to the middlebox stripping the option) and thus will
>> assume that the data is unencrypted. (for the background, this kind of
>> behavior is the reason why MPTCP makes sure to only send in-order data
>> in the first few segments, until middlebox-support has been confirmed
>> as it allows to fallback to regular TCP)
> 
> This is one reason we would love to collaborate with someone who has
> very concrete middlebox experience (hint hint), at the very least on a
> TCP-ENO Middlebox Probing document, if not on ENO itself.  We have not
> observed stripping from SYN but not non-SYN segments, and agree it would
> be annoying.
> 
> Currently we would deal with this in the same as DPI--probe the
> middlebox at DHCP lease time and disable ENO if the middlebox is not
> compatible.  However, if such middleboxes are common enough, then we
> might need to support them.  Such middleboxes are kind of pernicious,
> since a lot of options are first negotiated in SYN segments then used
> later.  Hence, if they exist but are not too common, I would be okay
> with disabling encryption, so long as connections don't fail entirely or
> get garbled.
> 
>> This kind of means that we would need to do a 4-way handshake where
>> data can only be sent after it has been confirmed on non-SYN segments
>> that ENO is enabled. Maybe there is a better solution to it?
> 
> There are other solutions, though it's not clear if they are better.
> The 4-way handshake could be compressed by sending a SYN-ACK and plain
> ACK back-to-back (so at least it doesn't incur an extra 1/2 round trip
> in the common case).  Or we could do it probabilistically, including 4-8
> bytes of randomness in the ENO options that then get hashed along with
> some magic number and included in the TCP payload data.  That's kind of
> yucky.
> 
>> Second, there are loadbalancers out there (used by baidu.com
>> <http://baidu.com/> in particular) that echo unknown TCP options. As
>> far as I can tell, TCP-ENO won't be able to handle this situation
>> gracefully, as an active opener will interpret the ECHO'd option as
>> valid. The P-bit seems to allow to resolve this situation as the
>> client would receive a TCP-ENO option with the P-bit set on a SYN/ACK
>> segment. But, the P-bit is currently not part of the option thus I
>> think it would be good to include it.
> 
> That's another very useful point we didn't know about.  The p-bit is
> currently implicit, but we could get rid of it and rely entirely on the
> explicit b bit.  That would have the added advantage of simplifying role
> negotiation at the cost of sometimes consuming an extra byte of option
> space in the SYN-ACK segments.
> 
> Thanks for the useful feedback.
> 
> David
> 
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 4 May 2016 18:04:19 +0200

Mirja,
> 1) Strip of non-SYN option while SYN-options pass correctly

tracebox (http://www.tracebox.org) could be used to program such tests, 
but I don't think that someone has done this analysis

Micchio's paper ( http://conferences.sigcomm.org/imc/2011/docs/p181.pdf 
) notes :

All the paths which passed unknown options in the SYN also passed both 
known and unknown options in data segments. In the tables, the “Removed” 
rows in- dicate that packets on that path arrive with the option removed 
from the packet. For the unknown options in the SYN packet, this was the 
only anomaly we found; no
path modified the option or failed to deliver the packet due to its 
presence. In addition, all the paths which passed the unknown option in 
the SYN also passed un- known options in data segments. This bodes well 
for deployability of new TCP options - testing in the SYN and SYN/ACK is 
sufficient to determine that new op- tions are safe to use throughout 
the connection.
Our test did not distinguish between middleboxes that stripped options 
from SYNs and those that stripped options from SYN/ACKs. With hindsight, 
this was an unfortunate limitation of our methodology that uses a 
stateless responder. However it is clear that any extension using TCP 
options to negotiate functional- ity should be robust to stripped 
unknown options in SYN/ACK packets, even if they are passed in SYNs. If 
it is crucial that the server knows whether or not the client received 
the option in the SYN/ACK, the proto- col must take this into account. 
For example, TcpCrypt requires that the first non-SYN packet from the 
client contains the INIT1 option - if this is missing, TcpCrypt moves to 
the disabled state and falls back to regular TCP behavior.

> Does anybody have further data here?

For point 2, there is some data concerning MPTCP, but this applies to 
ENO as well.

https://academic-network-security.research.nicta.com.au/mptcp/deployment/

Olivier Mehani and his colleagues probe the Alexa top 1M on a regular 
basis to verify the deployment of MPTCP servers. On the plot, you can 
see two parts :

- before September 2015 where they report the number of servers that 
replied to their SYN+MPCAPABLE with a SYN+ACK+MPCAPABLE

- after September 2015 where they checked whether the returned MPCAPABLE 
option was a mirror of the one sent in the SYN segment. The vast 
majority of the servers that return the MPCAPABLE option are middleboxes 
that simply mirror this option. The geolocation of these servers points 
to China...

I guess that Olivier could provide more information about their tests

Olivier

---

From: Olivier Mehani <[email-masked]>
Date: Thu, 5 May 2016 21:24:04 +1000

Hi Mirja, Olivier,

On Wed, May 04, 2016 at 06:04:19PM +0200, Olivier Bonaventure wrote:
> For point 2, there is some data concerning MPTCP, but this applies to ENO as
> well.

Yes.

Essentially, we get Alexa dumps, resolve them with team Cymru's APIs,
scan them with a patch version of zmap them to see if they support
MPTCP. This step essentially creates a TCP packet from scratch, and our
patch add the MP_CAPABLE option, and check for its presence on return
packets.

For all those IPs for which we received an MP_CAPABLE option back, we
then wget the default HTTP page from a different machine. This machine
runs an MPTCP-enabled kernel (unlike the scanning one above, as zmap
does the packet building), so the wget session allows to have a full
transaction, which allows us to capture other MPTCP options from the
remote hosts.

Since Olivier pointed out the problem of mirroring middle boxes, we
started inspecting the value of the sender's key, which should be
different when coming from the remote host. In the case of mirroring
middle-boxes, this is obviusly not the case.

The second bit is a pretty ad-hoc, so I don't think it will work as well
as tracebox, but for Internet-wide (IPv4) scans, zmap is a pretty good
bet to do some coarse filtering. Adding new options there is relatively
straightforward [1]; we implemented a separate synscan probe module to
be able to merge upstream changes more easily, but you could otherwise
do it straight into the upstream synscan.

[0] https://ext.npc.nicta.com.au/projects/mptcpscan/repository/zmap
[1] https://ext.npc.nicta.com.au/projects/mptcpscan/repository/zmap/revisions/mptcpscan/entry/src/probe_modules/module_mptcp_synscan.c

-- 
Olivier Mehani <[email-masked]>
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.