Re: [tcpinc] Revised version of TCP-ENO

[David Mazieres <[e-mail]>]

Stephen Farrell <[e-mail]> writes:

> 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.

I think you raise several questions here.

First, should what TCP-ENO calls the session ID be traceable to a
particular connection by a passive eavesdropper?  A contrived scenario
here is that for some reason you run a bulletin board that logs messages
and session IDs.  I put your bulletin board under surveillance,
recording a complete packet transcript.  Now I don't like a particular
message.  From its session ID, can I tell which client connection posted
the message (assuming, say, that all messages are the same length and
that timing information is obscured by batching the messages at the
server).  As I said, this is a bit contrived, but if everyone uses the
same encryption spec, I do think there is value in this kind of privacy,
and it is achieved by requiring the session ID to be computationally
indistinguishable from random.

Second, instead of a single session ID, should we define two values with
this property, a "witness" and a "session ID", where the witness is
available for use by other transport-level RFCs (such as MPTCP) and the
session ID is for use by applications.  Or, generalizing, allow a whole
host of values indexed by an integer.  The advantage of this is that
domain separation ensures that whatever your application does will not
undermine, say MPTCP.  This is a valid argument, but it adds a lot of
complexity, so it might be nice to avoid, also.

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

I assume you mean MPTCP?  If so, I agree, assuming by "ok" you mean a
subsequent update of MPTCP can easily integrate with TCP-ENO (as opposed
to TCP-ENO citing RFC6824 as a normative reference and directly
specifying how the two work together).

David