On Mar 19, 2010, at 8:32 AM, George Barwood wrote:

> 
>>> There are advantages besides messages being lost.
>>> It also prevents spoofing of fragments, and limits amplification attacks.
> 
>> It doesn't limit amplification attacks by much if at all
> 
> It cuts the response from 4K to 1.5K, and I think fragmentation that 
> contributes
> to these attacks being damaging.

All I need to do is find a set of open resolvers which don't have such limits 
to do juuust fine.  

And amplification attacks are overrated anyway:  DOS burns your bots, and most 
of your bots can't send spoofed packets anyway these days.  

So if you are going to burn your bots, do application level: its amazing how 
much damage SSL setups can do to your load if you don't have dedicated crypto 
hardware.

>> and spoofing of fragments is not likely to be happening in large responses, 
>> because large .responses will almost invariably be due to DNSSEC.
> 
> Resolvers may set DO=1 but not validate everything ( or even anything ).
> 
> Taking .SE as an example, by sending an open resolver that doesn't/cannot 
> randomize ports the query [ NS SE ] ,
> if the .SE servers don't conceal the IP ID, only 1 spoof packet is needed, 
> and poisoning is easy and certain, is it not?
> 
> Note: the .SE example does not truncate, it's very unusual for a response to 
> be truncated with a EDNS @ 1450.

Actually, this doesn't apply, since the reason why ns.se is 2700B is all the 
RRSIGs in the additional section, which are after the A and AAAA records.  So 
spoofing this part of the datagrams is pointless anyway, since that only has 
meaning if DNSSEC validation IS performed.


I really don't want to enshrine "Fragments don't work at ALL" into the 
infrastructure, rather I want "fragments are unreliable, so you need to detect 
if its YOUR side thats f-ing up and take action", thus it should be the onus on 
the resolver, not the authorities, to detect when this occurs and do something 
about it.

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to