<div dir="ltr"><br><div>For DNS, we have the option to respond with a TC=1 response, so if I detected a datagram with suspicious or mismatching TTLs, TC=1 is a decent workaround. TCP is then much more robust against intermediary spoofing. I can't force the clients to use DF though. </div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 15, 2014 at 2:08 PM, Hannes Frederic Sowa <span dir="ltr"><<a href="mailto:hannes@stressinduktion.org" target="_blank">hannes@stressinduktion.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<div class="im"><br>
On Wed, Jan 15, 2014 at 01:26:20PM -0800, Colm MacCárthaigh wrote:<br>
> Unfortunately I can't share data, but I have looked at a lot of it. In<br>
> general, I've seen TTLs to be very stable. Most ECMP is flow-hashed these<br>
> days and so as long as the path is stable, the TTLs should be identical. If<br>
> there's some kind of transition mid-datagram, the the TTLs may legitimately<br>
> mismatch, but those events seem to be very rare.<br>
<br>
</div>Counterexample: Linux does not use flow-hased steered ECMP. You see the<br>
effect on end-hosts because of the route lookup caching in the socket<br>
(as long as it doesn't get invalidated or unconnected).<br>
<br>
The problem is that as soon as such a knob is provided people could<br>
generate DNS-blackholes (until timeout of resolver and retry with TCP,<br>
maybe this could be sped up with icmp error messages).  Only a couple<br>
of such non-flow-hased-based routed links would suffice to break the<br>
internet for a lot of users. I am pretty sure people will enable this<br>
knob as soon as it is provided and word is spread.<br>
<br>
If we want to accept that we could just force DF-bit on all fragments<br>
and ignore the users behind some specific minimal mtu. Would solve the<br>
problem more elegantly with same consequences. And error handling with DF-bit<br>
is better specified and handled by the kernel, thus more robust and better<br>
debugable (in case UDP path mtu discovery is implemented on the OS). ;)<br>
<div class="im"><br>
> netfilter would be fine, but it'd be nice to not incur any state cost<br>
> beyond what the UDP re-assembly engine is keeping already.<br>
<br>
</div>netfilter reuses the core reassembly logic (at least in IPv4, not yet<br>
for IPv6). As soon as netfilter is active, packets will get reassembled<br>
by netfilter and passed up the network stack without going in "core"<br>
fragmentation cache again. So the TTLs would be kept in the frag queues<br>
and further fragments would indicate to hard match the TTL on further<br>
appends.  So that would be no problem to do. I really doubt it is wise<br>
to do so.<br>
<br>
Greetings,<br>
<br>
  Hannes<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Colm
</div>