-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
How does Linux do RFC 1323 style RTTM measurement? Is there a
pseudo-clock used i.e. number of jiffies since boot? Or just a
real-time timestamp?
Sorry for the dumb questions but Google is being massively bad at "tell
me about an obscure feature of the Linux kernel that nobody cares about"
today :)
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRNrKHws1xW0HCTEFAQL/kA//YKZ+lFWk1XUHTfQUCLClvBEsope7KYDg
8POJjpJVRhOf5ckexPXvmBbxnXJBB4zki2JRiiEbaHtHkMncdk8Ts7r/2Au8YGEj
Jo0ahOssvQKPm3WBeZgXrOXjdRYuF2fW03wrBAuKL3KqXV8U2v4gFcWzV6pysBBp
4gYevF6DS4MXX6Loo9o/HowC4UFZgktELkDE6NX6gMh4aXNwhtsReOlfxY2to2yd
A2R89iJjWvPr3UeG6gpej7GOCg9XuW0nwfMJ5V4T5OqSDVbB0feXBCTEC8JtxPwD
Quc6UTv4Vqx3+lTS71YeTjE2/Oyi77eW46ycnsjPgeQ9mH67ZWA7GYgDxSqvfpbz
9Dn4+elboMKwPXD7FmlC4CjrtsyeB7ebqfUOTRRd4M2IqFZ2y2t50m3TgAAoe3vR
h62RN1o425QSRQlEje7De7ST2jG9UdaNceYt9TT0QZBRsN44TUT+6p1YoFVs6uU0
IhGu+zsFmltE7DuVu9CxWJQ70LP9L/qCWllyPOdGobbDyYISw047sDrxPjF8N5ha
j+I40ozs2JG5Jg3d0w5DDYPsSfeh/LLlLzyGEQzwzXr5PZJaJVeEtb/jroqhjvXc
PAegzN0DUnWVoMX0/Uv6oLoWIYsgwcTLw6ieCeOt5ljTpJxeaJtrcl3RPipLbKrF
HgPtUNRGjqk=
=5z5t
-----END PGP SIGNATURE-----
From: John Richard Moser <[email protected]>
Date: Thu, 10 Aug 2006 01:54:42 -0400
> Sorry for the dumb questions but Google is being massively bad at "tell
> me about an obscure feature of the Linux kernel that nobody cares about"
> today :)
When I type "Linux RTT measurement" to google, the following
very authoritative paper on Linux's TCP congestion control
shows up on the very first page:
http://www.cs.helsinki.fi/research/iwtcp/papers/linuxtcp.pdf
You should try a little bit harder with google next time, and
also ask your question on a more appropriate list such as
[email protected] which is where the networking developers
are subscribed.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Miller wrote:
> From: John Richard Moser <[email protected]>
> Date: Thu, 10 Aug 2006 01:54:42 -0400
>
>> Sorry for the dumb questions but Google is being massively bad at "tell
>> me about an obscure feature of the Linux kernel that nobody cares about"
>> today :)
>
> When I type "Linux RTT measurement" to google, the following
> very authoritative paper on Linux's TCP congestion control
> shows up on the very first page:
>
> http://www.cs.helsinki.fi/research/iwtcp/papers/linuxtcp.pdf
>
This says Linux does use the RTTM "Timestamp" option for TCP; it does
not however tell me HOW it uses it.
So does it stamp the current time in UTC in milliseconds in the field?
Does it stamp in the number of jiffies since boot? Does it use a
pseudo-randomly generated per-connection initial virtual clock value
with a microsecond-per-tick skew-factor to hide information about the
internal state of the system to avoid attacks on the PRNG to guess TCP
ISNs or attack ASLR?
> You should try a little bit harder with google next time, and
> also ask your question on a more appropriate list such as
> [email protected] which is where the networking developers
> are subscribed.
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRNr1WAs1xW0HCTEFAQLugw//T+h1DA5AjQIB0sRVGef63WTZPHbO0Nhy
/6SGTO2lFHPpAv/esNRB7g4622ScOS0pQM3kedgiqGjT1mEhUx3h0PTGWFILbRfx
zzC5aypUv0lRiXhA43KWkIyWSLCubL0Aa1Mthm+Kn+g9jruXto3IIiLQWC3kC5Qm
6S6zFc0EE2VdC8UcWVHE+aAQDIA++VJ+Yb/bLqjNmHi+uaz553S3PT78R5Wq0mtG
aOXfWPd7gE17Ejrj9aAzz2M6M+zvkp7qPoRtezwakClA/OKYTyuBbqyasX7l/P89
R152KZSNOfts4667jegeC/9khXJEmkyjKI8BeYFFb1+VyRE56QSxbQYr1BwD6/Zu
YUkTBnv0qcxEyyYXkK2MBc9BNl2hjsix0AlgnTsYxB+56G9c2bBMRx4LKyXtVTeQ
7LGeFNJvwx5f721W2l+euXeLDStzDHj54TUMEoszT7xDhjsfhJx9mQCQIjG0sbw7
TlPOMfy9x/Sh4P4IQMeqjjHbdOiOBeOSQWJjpg2KhqU98qr+EiKdU1IaJ3R33T9k
INxhmW8nQ1F0k0k2k/tOZ7flD8cy/1ZAqaGyqTyy2c15xT0FwRh9Sq71Cnc81xkg
nfUDZZk5EJBUNaNtF6EKQ2yIGbfiDxXuagHmTKFQCD8Q1EukZZ9MKmin7yyT/lUR
n/ojUoyzSG4=
=prc3
-----END PGP SIGNATURE-----
Please use [email protected] for discussions about the linux
networking implementation, not [email protected]
Thanks a lot.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Miller wrote:
> Please use [email protected] for discussions about the linux
> networking implementation, not [email protected]
>
Kay.
I'm told now that it uses Jiffies for TCP timestamps. I've had thoughts
on this:
- I figured a random timestamp with random microsecond skew would be
nice but this might expose internals of the RNG; amusingly I'm trying
not to expose internals of the RNG by exposing system time.
- Someone recommended starting at zero. This would work, really,
there's no attacks based on guessing the TCP timestamp value. This is
nice since if I want to hax0rz then I might make a connection and see
how many jiffies there are to get a feel for the system's uptime; this
tells me how long since you upgraded your kernel, so I have an arsenal
of vulns I KNOW you haven't fixed ready ;) Starting at 0 doesn't give
that information.
Comments?
> Thanks a lot.
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRN3YOws1xW0HCTEFAQKZAA//R4tRODoaWZCtEnafv7oGTJfYFjzAy06+
WzRAjOZf72cuW2xwzIMqjBzJaoXbWN/j9AgwRGzYNsjeyijVHfwVVtZHIuJUrQwd
pl4elWDDl6uFEeyWVSzBg5GLMJnB/O2Yy5E6T2TYdFaTa78T7SqwcYd5GwGj0L3I
5MxNGYMguVRr4GuYJDNefbnEIicFhrkR09O5/iqliPCWKG5613xDIKt6KWy8KIVh
n9Ui27I0MSmDuB1U1wLQiJJx01y4jAFKELdMnJk7/iyp56aBcvbohKxlqOV1nzWx
UjrPFJW4ytoWGXTxzyccHFvQZIS9oI57YnNyynCj9waaTRSc6rF4RAPLGTU77NaG
Y4leWUfEFOuvA3En0B5csFalMCPgS+hrGZF/klQIxJrKewzoK+/IWNTxixAQdUbQ
PqFE5C9U8Jt81gzVJ5ojA8BRsml48z9aj30/+4kzDJBwXjDIK4ys74orstqM+Q3U
jDgOFBww7EaS0rlw8JcVbEYStKy/gOmq6YQocCnmGGtnwrHD7owPbqo8emRhEFsE
pigFWHuuBT5liT7vAdyC2XyN8JOAFVjfda6ktDolvTAu5HV1btUmL4pxejSW82Je
+6HMedYQT2LJ4f5a29sI+UZGuyveYwITXVmgyqx8fg9Y9vEMzTdGwJzs6MHuWOoR
z7swCkgkZh0=
=J3TR
-----END PGP SIGNATURE-----
On Sat, Aug 12, 2006 at 09:31:42AM -0400, John Richard Moser ([email protected]) wrote:
> I'm told now that it uses Jiffies for TCP timestamps. I've had thoughts
> on this:
>
> - I figured a random timestamp with random microsecond skew would be
> nice but this might expose internals of the RNG; amusingly I'm trying
> not to expose internals of the RNG by exposing system time.
>
> - Someone recommended starting at zero. This would work, really,
> there's no attacks based on guessing the TCP timestamp value. This is
> nice since if I want to hax0rz then I might make a connection and see
> how many jiffies there are to get a feel for the system's uptime; this
> tells me how long since you upgraded your kernel, so I have an arsenal
> of vulns I KNOW you haven't fixed ready ;) Starting at 0 doesn't give
> that information.
>
> Comments?
Starting TCP timestamp from zero or any other arbitrary value for each
new connection will not give you any security benefits. There is no
simple way aleph1 or e-eye will get a remote shell or steal your credit
card number if there is a buffer overflow in kernel and they will know
it's release.
So your proposals just are not needed for majority of people, but if you
strongly feel it will help to find a cure for cancer, implement it and
prove it's usefullness to netdev community.
--
Evgeniy Polyakov
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Evgeniy Polyakov wrote:
> On Sat, Aug 12, 2006 at 09:31:42AM -0400, John Richard Moser ([email protected]) wrote:
>> I'm told now that it uses Jiffies for TCP timestamps. I've had thoughts
>> on this:
>>
>> - I figured a random timestamp with random microsecond skew would be
>> nice but this might expose internals of the RNG; amusingly I'm trying
>> not to expose internals of the RNG by exposing system time.
>>
>> - Someone recommended starting at zero. This would work, really,
>> there's no attacks based on guessing the TCP timestamp value. This is
>> nice since if I want to hax0rz then I might make a connection and see
>> how many jiffies there are to get a feel for the system's uptime; this
>> tells me how long since you upgraded your kernel, so I have an arsenal
>> of vulns I KNOW you haven't fixed ready ;) Starting at 0 doesn't give
>> that information.
>>
>> Comments?
>
> Starting TCP timestamp from zero or any other arbitrary value for each
> new connection will not give you any security benefits. There is no
The TCP timestamp is the vessel; the target is the system uptime.
So, "preventing attackers from discovering the uptime of the remote
system will not give you any security benefits" is your statement.
> simple way aleph1 or e-eye will get a remote shell or steal your credit
> card number if there is a buffer overflow in kernel and they will know
> it's release.
Well, they could throw a netfilter buffer overflow at it; but there's
only ever been one I think. ;) Aside from that, it's a matter of doing
reconaissance BEFORE you get a local non-root or getting a local
non-root and THEN picking out your root elevation exploits, which is
only a few minutes difference.
(then again, storming the Bastille wouldn't have worked if they got to
the front door and sat on their asses for 2 minutes)
> So your proposals just are not needed for majority of people, but if you
> strongly feel it will help to find a cure for cancer, implement it and
> prove it's usefullness to netdev community.
>
It's not so much that as the cost of doing an arbitrary value is storing
the number of jiffies that make zero with each connection; this doesn't
seem significant. On the other hand, it removes one method for getting
a piece of information about the system that nobody said you could have;
some "hardened" configurations disable timestamps altogether for this
(amusingly they don't block ICMP Timestamp Reply outgoing). For the
sake of argument, I can at least say this would improve performance of
the RTTM for the paranoid.
In case you're wondering, myself I find this to be of minimal concern as
long as jiffies/uptime/etc have nothing to do with the PRNGs on the system.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIUAwUBRN3rews1xW0HCTEFAQLppA/4nWBgXTgeDQyqAmERS+Ao/XeS1Ts6S///
Vdh5Hkvn3tAo6mfNfpvKtc4Cw1rz8X9YFew4l9gk8nT8rhiWc9Bp/30nRmqbTra7
BDrgIZr11662mjukCWb+G9aSBuG2frs5xNqtO7eSgOhNX5IroYgsbhtVtZlmvsbM
uQjUyO5VBo8J9XmIGGZ7fi1+WwY8a32I8oVE8OKgMeGTuxFOt7ZjcMiwRu3FoISu
qMO1Cvqp6yieyMxswiJNXZcUUv/yBtV233A5g06a4Y9EbCPSLZ+d6LUvhDYdEUYi
XNNzRmCyQwvbyNyiZBVvx/tZNCSRvqwQLB/FTkECCzJpzcLtPooEwiXY1DLI8zew
6boP3C1uxTQZvZfMBhSDvJZ+j0Fs3xNyxe7rF9iigzOH9Zle2EgjUaP90W1Drgxh
Czx1p67UeQBj7+zLS8TW/cjVpNZPkBWOFd7aJjzmjUf+4u7eRtQlVTfS9iDisvT6
NofjN8BkvmtEz34ooORNLSawW9kTcmNva+/Xjx+qHLjvvOGELm/xwXlGdUKBz7MV
TJydVOie8A10WFmFViSyqMUUv/wWqHabmgQPtJ00O+YntvccT5xcyMCVON8x56q7
IEqT+HsdML3AKSXdg7yf3nUp0Ln8LtFAWkYqIbIE/oxOeNiWnOzYp1+FnQHr/Ady
3VS30lcTgA==
=/G41
-----END PGP SIGNATURE-----