<div dir="ltr">On Wed, Sep 4, 2013 at 8:40 AM,  <span dir="ltr"><<a href="mailto:ondrej.sury@nic.cz" target="_blank">ondrej.sury@nic.cz</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>It'd be interesting to work out what the total entropy is by<br>
using that along with truly random IP IDs.<br>
</blockquote>
<br></div>
It's only 16-bit and it's not much since you can preload the second fragments even before the query is sent.</blockquote><div><br></div><div>I think with variable point fragmentation you can probably squeeze out an additional 8 or 9 bits of entropy if you really push it. Comparable to the 0x20 hack :)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It also seems prudent for clients to validate that the IP TTL of all fragments in a datagram are<br>
the same.<br>
</blockquote>
<br></div>
That's also only visible on IP level, not on application level, and the information is useless because you don't have any information about network topology at the defragmentation point.  Different IP TTLs for fragments are not likely, but still valid.</blockquote>
<div><br></div><div>They are valid -  fragments may take different paths (and multi-fragment UDP datagrams are often subject to inconsistent ECMP flow-hashing due to the absence of the the ports in the second and subsequent fragments) but different TTLs seem to be vanishingly rare on the wire. It looks like even when there is ECMP that there is an equal number of hops. </div>
<div><br></div><div>A smart recipient could fall back to TCP too ; so the "suspiciousness" of the mis-matched TTLs is pretty valuable signal. </div><div><br></div><div>Many of the larger operators now deal directly in packets, rather than sockets, so I wouldn't be surprised if mitigations like the above were viable for them.</div>
</div><div><br></div>-- <br>Colm
</div></div>