Hi, On 2017-11-29, at 1:26, Brian Trammell (IETF) <[email protected]> wrote: > There are three possible states for an ECN negotiation: not attempted, > failed, and succeeded. Each of these can add a fractional bit of information > about the client and server TCP implementations. If a server negotiates ECN, > you can be reasonably certain that it supports ECN, and can leverage the > observations that sysadmins love defaults and servers are mostly Linux these > days to figure out whether it's running a kernel before or after server side > defaults were turned on. > > Long-term observation of the ECN negotiation attempts of a client can be used > to determine if the client is using probabilistic negotiation by default; > i.e. is an Apple device of a certain vintage. > > These are fractional bits of fingerprinting information, though, if that. I'm > almost certain (but won't take the time to do the research now) that any of > these observations would be useless. Anyone in a position to make them could > also get much more information about the behavior of the TCP stacks at each > end, such that the ECN bits add negligible information. cf. p0f, if that's > still a thing.
this is certainly all true for TCP and ECN, where whether ECN is available and/or tried by default is tied to a certain kernel versions. But for QUIC (= ECN with UDP), whether ECN is used or not is completely up to the app (= the QUIC stack), so you can't draw conclusions about whether a certain kernel or OS flavor is underneath (other than they less than about ten years old, i.e., have support for the IP_TOS/IP_RECVTOS socket options.) So the fractional information leakage seems to be less than with TCP. Lars
signature.asc
Description: Message signed with OpenPGP
