Re: [tcpinc] Revised version of TCP-ENO

[Stephen Farrell <[e-mail]>]

Hiya,

A couple of points on the session ID stuff:

On 13/08/15 23:11, David Mazieres wrote:
> That said, one could imagine a fringe use case where an application
> wants to prove that two anonymous TCP connections belong to the same two
> processes, in which case the session ID of the first connection might be
> used as a MAC key to authenticate the session ID of the second.  So you
> don't want the session ID to be predictable, even if making it public
> doesn't hurt TCPINC itself.

I tend to agree with the above.

As an FYI, I'm a co-author of an MPLS WG draft that has a
similar concept [1] (which should be no surprise:-) so I'd
like to try make sure those two things end up being similar
to the extent we can. I'll likely just copy what's done here
as much as possible.

I think we might want to also consider that one thing that
might happen is that loads and loads of these values (or
values derived from them) could end up being accumulated and
eventually end up really public. Just for safety's sake I'd
probably prefer that what might end up public is not the same
set of bits used as the session ID during the session though.
For example, using the same bits might enable later correlations
between log files that we'd prefer not be possible - say between
some client-host-firewall log reported via telemetry and an
application server log. So there might be benefits in defining
a way to do that so that application developers don't get
it badly wrong. In [1] we talk about a witness value that
is different from a session ID. Not sure if that's useful
here (or there;-) or not though.

Lastly, we should check that whatever is done here is ok for
MTPCP.

Cheers,
S.




[1]
https://tools.ietf.org/html/draft-ietf-mpls-opportunistic-encrypt-00#section-7.1