Subject: Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

From: Wesley Eddy <[email-masked]>
Date: Wed, 15 Feb 2017 23:33:55 -0500

I haven't been following the WG discussions closely, so apologize in 
advance if this has been beat to death ... In reviewing the present 
draft, section 4.7 seems awkward to me.

I think the WG should consider taking a position that data-on-SYN for 
TEPs should only be permitted to be sent if you have some prior 
indication that ENO is understood by the other end (e.g. via a cache 
entry from a previous connection, or other means).

While the draft correctly says that discarding data on SYNs may already 
be a common practice, it seems to me that there could be two issues, 
including:

1) edge cases where you're communicating with non-ENO hosts, that do not 
discard data on SYNs (for whatever reason), and may pollute the data 
stream delivered to the application, breaking the goals of TCPINC to 
work without impacting the application's TCP mapping

2) cases where other TCP extensions (perhaps yet to-be-defined) do 
something in conflict with that data

I think it goes along with being 'conservative in what you send' to only 
include TEP data on the SYN if ENO is highly likely to be supported by 
the other side.

On 1/23/2017 6:15 PM, Kyle Rose wrote:
> This is a working group last call for the "TCP-ENO: Encryption 
> Negotiation Option" draft available at 
> https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/. Please 
> review the document and send your comments to the list by 
> 2017-February-15.
>
> -Kyle and David
>
>
>
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Feb 2017 22:37:27 -0800

> On Feb 15, 2017, at 8:33 PM, Wesley Eddy <[email-masked]> wrote:
> 
> I haven't been following the WG discussions closely, so apologize in advance if this has been beat to death ... In reviewing the present draft, section 4.7 seems awkward to me.
> 
> I think the WG should consider taking a position that data-on-SYN for TEPs should only be permitted to be sent if you have some prior indication that ENO is understood by the other end (e.g. via a cache entry from a previous connection, or other means).
> 
FWIW, I don't much care what TCPINC decides, but the decision has consequences...
> While the draft correctly says that discarding data on SYNs may already be a common practice, it seems to me that there could be two issues, including:
> 
> 1) edge cases where you're communicating with non-ENO hosts, that do not discard data on SYNs (for whatever reason), and may pollute the data stream delivered to the application, breaking the goals of TCPINC to work without impacting the application's TCP mapping
> 
> 2) cases where other TCP extensions (perhaps yet to-be-defined) do something in conflict with that data
> 
> I think it goes along with being 'conservative in what you send' to only include TEP data on the SYN if ENO is highly likely to be supported by the other side.
> 
I'd prefer to be explicit:

- if non-data info is included in the TCP SYN payload, then this mechanism MUST abort SYN-ACKs that do not confirm TCPINC participation (i.e., fallback by aborting the current connection), which defeats transparent downgrade to legacy listeners.

That rule applies to all TCP extensions, and is discussed in draft-touch-tcpm-tcp-syn-ext-opt. 

The potential for other TCP options to have conflicting interpretations for that data would need to be dealt with in each such option in the context of options defined up to that point, but that seems like an unnecessary swamp to enter.

Joe

>> This is a working group last call for the "TCP-ENO: Encryption Negotiation Option" draft available at https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/. Please review the document and send your comments to the list by 2017-February-15.
>> 
>> -Kyle and David
>> 
>> 
>>

---

From: David Mazieres <[email-masked]>
Date: Wed, 22 Feb 2017 10:58:51 -0800

> something in conflict with that data

Can you make concrete suggestions for wording changes?  In particular,
we intended to address the points you raised with the following language
of section 4.7:

1)

        If a host sends a SYN-only SYN+ENO segment bearing data and
        subsequently receives a SYN-ACK segment without an ENO option,
        that host MUST reset the connection even if the SYN-ACK segment
        does not acknowledge the SYN data...

        To avoid unexpected connection resets, ENO implementations MUST
        disable the use of data in SYN-only segments by default.

2)

        More specifically, a host that implements ENO MUST discard the
        data in a received SYN+ENO segment if any of the following
        applies:
        ...
        * The SYN segment contains a non-empty TFO option or any other
          TCP option implying a conflicting definition of SYN data.

If those aren't clear, the question is how to make them so.

Thanks,
David

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Feb 2017 11:16:18 -0800

>         disable the use of data in SYN-only segments by default.

It might be useful to explain the rationale briefly.

It might also be useful to explain what happens next. AFAICT, the reset
should just terminate the connection. I.e., a TCP ENO implementation
MUST NOT internally retry a failed ENO connection with a non-ENO
connection (it would break the semantics of of the TCP API to do so with
different source port numbers because the user might have pinned them,
and you can't wait for a retry because that would cause the API to stall
longer than TCP SYN timeouts expect).

>           TCP option implying a conflicting definition of SYN data.

MUST discard the data
MUST NOT cache the data, even if not ACKd

And, IMO, SHOULD refuse the connection (the other end is clearly asking
something that could be dangerous and if they don't know better, you
might be better off not trusting that connection to continue)

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Sun, 26 Feb 2017 21:39:02 -0500

>          does not acknowledge the SYN data...

Saying "reset the connection" is interesting to me, because technically 
there is not yet any connection (there are TCBs at each side, but 
neither has entered ESTABLISHED state).  The reset that's sent should 
probably *not* acknowledge any data that may have been on the SYN-ACK, 
which seems important to state.  That way, if some application's 
transaction erroneously started due to data on the SYN, any response 
piggybacking the SYN-ACK would not be acknowledged, and the RST should 
cause the application transaction to fail.

>          disable the use of data in SYN-only segments by default.

In my opinion, it might be better to disable the use of data in SYN-only 
segments unless the peer's ENO capability is already known through some 
means (e.g. TCB cache from prior connections).