Re: [dns-operations] summary of recent vulnerabilities in DNS security.
Hi! On Wed, Jan 15, 2014 at 01:26:20PM -0800, Colm MacCárthaigh wrote: Unfortunately I can't share data, but I have looked at a lot of it. In general, I've seen TTLs to be very stable. Most ECMP is flow-hashed these days and so as long as the path is stable, the TTLs should be identical. If there's some kind of transition mid-datagram, the the TTLs may legitimately mismatch, but those events seem to be very rare. Counterexample: Linux does not use flow-hased steered ECMP. You see the effect on end-hosts because of the route lookup caching in the socket (as long as it doesn't get invalidated or unconnected). The problem is that as soon as such a knob is provided people could generate DNS-blackholes (until timeout of resolver and retry with TCP, maybe this could be sped up with icmp error messages). Only a couple of such non-flow-hased-based routed links would suffice to break the internet for a lot of users. I am pretty sure people will enable this knob as soon as it is provided and word is spread. If we want to accept that we could just force DF-bit on all fragments and ignore the users behind some specific minimal mtu. Would solve the problem more elegantly with same consequences. And error handling with DF-bit is better specified and handled by the kernel, thus more robust and better debugable (in case UDP path mtu discovery is implemented on the OS). ;) netfilter would be fine, but it'd be nice to not incur any state cost beyond what the UDP re-assembly engine is keeping already. netfilter reuses the core reassembly logic (at least in IPv4, not yet for IPv6). As soon as netfilter is active, packets will get reassembled by netfilter and passed up the network stack without going in core fragmentation cache again. So the TTLs would be kept in the frag queues and further fragments would indicate to hard match the TTL on further appends. So that would be no problem to do. I really doubt it is wise to do so. Greetings, Hannes ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
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. On Wed, Jan 15, 2014 at 2:08 PM, Hannes Frederic Sowa han...@stressinduktion.org wrote: Hi! On Wed, Jan 15, 2014 at 01:26:20PM -0800, Colm MacCárthaigh wrote: Unfortunately I can't share data, but I have looked at a lot of it. In general, I've seen TTLs to be very stable. Most ECMP is flow-hashed these days and so as long as the path is stable, the TTLs should be identical. If there's some kind of transition mid-datagram, the the TTLs may legitimately mismatch, but those events seem to be very rare. Counterexample: Linux does not use flow-hased steered ECMP. You see the effect on end-hosts because of the route lookup caching in the socket (as long as it doesn't get invalidated or unconnected). The problem is that as soon as such a knob is provided people could generate DNS-blackholes (until timeout of resolver and retry with TCP, maybe this could be sped up with icmp error messages). Only a couple of such non-flow-hased-based routed links would suffice to break the internet for a lot of users. I am pretty sure people will enable this knob as soon as it is provided and word is spread. If we want to accept that we could just force DF-bit on all fragments and ignore the users behind some specific minimal mtu. Would solve the problem more elegantly with same consequences. And error handling with DF-bit is better specified and handled by the kernel, thus more robust and better debugable (in case UDP path mtu discovery is implemented on the OS). ;) netfilter would be fine, but it'd be nice to not incur any state cost beyond what the UDP re-assembly engine is keeping already. netfilter reuses the core reassembly logic (at least in IPv4, not yet for IPv6). As soon as netfilter is active, packets will get reassembled by netfilter and passed up the network stack without going in core fragmentation cache again. So the TTLs would be kept in the frag queues and further fragments would indicate to hard match the TTL on further appends. So that would be no problem to do. I really doubt it is wise to do so. Greetings, Hannes -- Colm ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
On Wed, Jan 15, 2014 at 03:33:02PM -0800, Colm MacCárthaigh wrote: 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. That would need to be implemented as cmsg access ancillary data and cannot be done as a netfilter module (unless the DNS packet generation is also implemented as netfilter target). Because this touches core code, this really needs strong arguments to get accepted. Maybe this can be done as part of the socket fragmentation notification work. I'll have a look but want to think about how easy this can get circumvented first. Maybe you already thought about that? Thanks, Hannes ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
