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 _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
