On 3/7/2017 10:12 PM, David Mazieres expires 2017-06-05 PDT wrote:
> Joe Touch writes:
>
>> On 3/7/2017 9:45 PM, dm-list-tcpcr...@scs.stanford.edu wrote:
>>> Wesley Eddy writes:
>>>
> If a host sends a SYN-only SYN+ENO segment bearing data and
On 3/7/2017 9:45 PM, dm-list-tcpcr...@scs.stanford.edu wrote:
> Wesley Eddy writes:
>
>>> 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
Wesley Eddy writes:
>> 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
On 2/22/2017 1:58 PM, David Mazieres wrote:
Wesley Eddy writes:
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
On 2/22/2017 10:58 AM, David Mazieres wrote:
> Wesley Eddy writes:
>
>> 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
Wesley Eddy writes:
> 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
> On Feb 15, 2017, at 8:33 PM, Wesley Eddy 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
On 2/4/17, 11:40 AM, "David Mazieres" wrote:
> Achieving stronger security with TCP-ENO requires verifying session
> IDs. Any application relying on ENO for communications security MUST
> incorporate session IDs into its endpoint authentication. By way
[CCing TCPM for the part that matters to TCPM]
> 4. citing drafts in support of future large SYN options:
> “Is there harm in doing this? E.g., is it bad practice to cite internet
> drafts (non-normatively, of course) in an RFC?”
>
> 4.a. Citing drafts does go against the current BCP, as I
Okay, here is some proposed language. For the definition of the "a"
bit:
a
Legacy applications can benefit from updating their behavior to
take advantage of TCP-level encryption, for instance by improving
endpoint authentication or avoiding double encryption. The
On 2/3/17, 6:27 PM, "David Mazieres" wrote:
>"Holland, Jake" writes:
>> Should my app set the a-bit? I think this version of the ENO draft
>> says yes, because I have altered my behavior in the presence of
>> encrypted TCP (and it wasn’t
"Holland, Jake" writes:
> 2.a. A scenario for illustration:
>
> For instance, maybe next year somebody reads about ENO and decides to
> upgrade protocol X, their proprietary gaming application protocol, so
> that Xv2 will be identical except that the passphrase will now be
>
Hi David,
Thanks for the response.
I’ll try to give a deeper explanation on what I’m thinking on points #2 and #4
(“a-bit” and the draft-citing), and see if it leads to any further clarity or
easier consensus.
Sorry for the length, and please don’t feel a need to respond to each
individual
Hello tcpinc members,
I’m new to the group, and joined at Kyle and David’s invitation to give a
review of this draft before the WGLC expires:
"TCP-ENO: Encryption Negotiation Option"
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/
The doc mostly looks pretty good to me. I couldn’t
14 matches
Mail list logo