Hiya, On 14/08/15 18:49, David Mazieres wrote: > Stephen Farrell <[email protected]> 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.
Right. For the MPLS stuff, so far, we have two things, one a key id (really a session id of sorts when you combine with the other identifiers that exist in MPLS) and the 2nd a witness value. Providing more outputs didn't seem useful. Note I'm not claiming that split is great or should be copied, I'm just describing what we've got in the current MPLS draft. The RFC5705 approach could work here too I guess. Might be a little odd to supply the application inputs like that to a getsockopt call in an optval (are there others like that? I forget) but I guess it could work. > >> 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). Correct. Cheers, S. > > David > _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
