How does Linux do RTTM?

DISCUSSION John Richard Moser 3 participants 7 messages Aug 10, 2006 – Aug 12, 2006

Subsystems (2)

Networking Network drivers

lore

Share & tools

lore

John Richard Moser

author

2006-08-10 05:54 UTC #0 lore raw

-----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-----

David Miller

maintainer

2006-08-10 06:12 UTC #1 lore raw

From: John Richard Moser <[email protected]>
Date: Thu, 10 Aug 2006 01:54:42 -0400

Quoted 3 lines

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.

John Richard Moser

author

2006-08-10 08:59 UTC #2 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 7 lines · David Miller

From: John Richard Moser <[email protected]>
Date: Thu, 10 Aug 2006 01:54:42 -0400
Quoted 3 lines
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 :)

Quoted 6 lines

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?

Quoted 5 lines

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

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-----

David Miller

maintainer

2006-08-10 09:02 UTC #3 lore raw

Please use [email protected] for discussions about the linux networking implementation, not [email protected]

Thanks a lot.

John Richard Moser

author

2006-08-12 13:31 UTC #4 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 3 lines · David Miller

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?

Quoted 2 lines

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

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-----

Evgeniy Polyakov

2006-08-12 13:53 UTC #5 lore raw

Quoted 15 lines · John Richard Moser

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.

Quoted 1 line

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.

Signature · 1 line

	Evgeniy Polyakov

John Richard Moser

author

2006-08-12 14:54 UTC #6 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 16 lines · Evgeniy Polyakov

Quoted 15 lines · John Richard Moser
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.

Quoted 4 lines

Quoted 1 line
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.

Quoted 3 lines

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)

Quoted 4 lines

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

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-----