Re: TCP timestamp starting value

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

JS> A lot of protocols use the currennt time for various reasons. Knowing
JS> the exact value might be a useful property for some attack vector.
JS> That's why an unmasked time leak without good reason is not a good idea.
I'm not sure whether I get this correctly. Do you mean that "leaking" wall 
time would allow an attacker to attack some protocol on some system where that 
system's RTC is deliberately running wrong and knowing the exact value (within 
~500ms) would open an attack vector? Could you give an example of that.

JS> It is completely unnecessary in this context either.
It is the only solution I can think of that doesn't allow an attacker to 
deduce whether the system rebooted.

JS> ntpdate is often run on boot. That will often produce a trivally measurable
JS> time difference. That means even using the "UTC" clock has visible skews
JS> in it.
Unless you run ntp, no?
And sorry, that's (as far as I understand) not an answer to my question, which 
was:
EF> what exactly is the concern (or are the concerns) of people objecting to 
EF> using the uptime for [TCP timestamps]?

JS> While I can understand the desire the somewhat correlate the timestamps
JS> of different connections on a short term time frame, any network stack 
JS> that depends on them to remain stable over a long time is IMO plainly 
JS> broken.
Yes. So what? Do you seriously expect IBM to fix the AIX network stack 
because some perfectly standard conformant niche OS doesn't meet their 
false expectations?

JS> There is no standard justification for the expectation here.
I started this sub-thread with stating that NetBSD's behaviour is in perfect
aggreement woth the standard. So what?

JS> It's not about a niche OS, I even question the validity of that argument.
I live and work in the Real World. There were complaints by our employees that 
certain web sites were awfully slow to load on our IT (but not on others).
We tracked this down to an IBM load balancer on the other end dropping SYNs 
if presented with repeating (or decreasing -- it's hard to tell the difference) 
timestamp values. So I have three options:
1. Tell our employees we are standard conformant, it's IBMs fault and I'm 
   awfully sorry they virtually can't access the web sites in question.
2. Get IBM to fix their network stack (or whatever).
3. Work around the problem on our side.