[dns-operations] Bailiwick stats? Idea for mitigation...

[Patrick W. Gilmore]

On Aug 10, 2008, at 2:40 PM, Brian Dickson wrote:
> Paul Vixie wrote:
>>> So, what we were thinking of is doing the following: When a  
>>> cached  entry
>>> is about to be overwritten with something different, do an   
>>> additional
>>> request. The material in that additional request has to be  equal  
>>> to that
>>> 'something different' before the cached entry is  overwritten.
>>>
>>> Roy
>>>
>>
>> far end load balancers (including those made by cisco) won't always  
>> answer
>> equally.  if you repeat a query N times, then in the end you'll  
>> have to either pick the last one or a random one.
>
> Here's an observation... very likely load balancers will hash on  
> some subset tuple of (src IP, dst IP, src port, dst port).

There are other reasons a response might vary, which do not has on  
such things.  (And no, I'm not just talking about CDNs.)  I think it  
would be dangerous to depend on repeated values to verify authenticity.

-- 
TTFN,
patrick


> The birthday attack presumes that *some* tuple will match (the same  
> 4 + TXID) exactly.
> But, it doesn't know *which* one.
>
> If the same query is sent twice, using the *same* port, and  
> different TXID, in short order, it will more than likely be hashed  
> the same way and be sent to the same physical server.
>
> And that *should* get the same answer, modulo changes to the zone  
> that occur in the (very short) interval.
>
> This adds 16 bits of entropy. If the resolver is already patched,  
> you get about 48 bits of entropy - pretty close to the 50 that Paul  
> says we need.
>
> So, in the case of different answers, redo the last one on the same  
> port; the last two answers should be the same.
> Or even blast out a new pair of queries, deliberately closely spaced  
> in time, differing only in TXID.
>
> Since the attacker is only guessing on TXIDs, or on ports, but  
> usually not both, the chances of guessing two in succession are very  
> low.
>
> Brian
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.oarci.net
> http://lists.oarci.net/mailman/listinfo/dns-operations
>