Re: how many angels can dance on the head of a pin?

[Alex Bligh <[e-mail]>]

--On 10 August 2008 19:07:25 +1000 Duane at e164 dot org <[e-mail]> 
wrote:

>>  1. Lookups would more often take place from behind a NAT. This can
>>  reduce entropy and make any given attack easier. Thus remember unlike
>>     many attack profiles, sticking a shared cache behind a NAT only
>>     serves to make things worse.
>
> I fail to see how this would apply, the reason for randomising the ports
> was for publicly accessible caches, such that ISPs run, which can be
> queried by the attacker and also for the attacker to send fake replies
> at the same time.
>
> If the attacker can't send requests and replies they would need to be in
> the path to alter things.

Some NATs (e.g.) have the behaviour of using a constant source port by
DNS, or a source port incrementing by 1 for each query (which is just
as bad). So, if the caching resolver is behind that NAT (or more
accurately NAPT) then simply spoof the NAT's external IP address and
guess the source port it used (using that as your destination port).
The NAT then helpfully rewrites this to the randomised source port
inside the NAT. Roy Arends has been doing a survey of NAT behaviour.
I'm not sure whether he's demonstrated poisoning through broken NAT
with a randomised source port cache in the lab, but I don't think it
should be hard; a NAPT which rewrites the source port to a constant
value effectively removes all the entropy given by the recent bind
patches. I mentioned this on namedroppers a while ago but I
was being somewhat cryptic as the nature of the attack itself wasn't
public then.

Alex

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>