----- Original Message ----- From: "Nicholas Weaver" <[email protected]> To: "George Barwood" <[email protected]> Cc: "Nicholas Weaver" <[email protected]>; <[email protected]> Sent: Friday, March 19, 2010 7:48 PM Subject: Re: [DNSOP] Should root-servers.net be signed
>On Mar 19, 2010, at 12:01 PM, George Barwood wrote: >> >> Anyway, do we yet agree that 1450 is the best default for max-udp-size, and >> that higher values are dangerous?\ >No: I agree it is the proper default for the TLD authorities and roots, but >for everything else, the higher value should be what the resolver requests. >Enshrining "tho shalt never fragment" into the Internet Architecture is >dangerous, and will cause far MORE problems. Having something which >regularly >exercises fragmentation as critical to the infrastructure and we wouldn't have >this problem where 10% of the resolvers are broken WRT >fragmentation. I'm not suggesting that. If the higher level protocol has definite security checks, or security is not important, fragmentation is ok. But for DNSSEC neither of these is true. BTW, I wrongly implied earlier in the thread that the threat was worse if port randomization was not possible. That's not true, the threat is strong even with port randomization, becaause only the first fragment as the source port ( and DNS ID ). Therefore the only thing protecting the fragment is the 16 bit IP ID field. In addition, by flooding the victim with fragments, it's probably possible to stop any valid fragment getting through, so this is a Kaminsky-like attack, the attacker can repeat it as many times as required. If I'm right, it's currently easy for an attacker to spoof an open cache by sending ANY queries for UK. The resolver will not normally have any authoritative records, so will send an ANY query to the server, and the response (which will fragment) can be attacked with success expected after sending ~32K spoof fragments ( note : these fragments will hang around in re-assembly buffers, so attack is quite efficient ). _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
