Subject: Re: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Jun 2009 02:38:04 -0700

There are also some pretty  nasty effects on multi-homed hosts who may send DNS queries on
multiple interfaces, including the "WiFi hotspot" interface. 

This can result in a user who has a perfectly serviceable alternative connection (e.g. Ethernet, HSDPA, etc.)
being unable to resolve names because their WiFi hotspot has decided to (quickly) return a synthesized (bogus) 
answer to every query. 

The load of support calls this can create is so large that the practice of forbidding multi-homing (via use of
suitably configured connection managers) has become quite common place.   

> Date: Sat, 30 May 2009 09:31:08 +0200
> From: [email-masked]
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
>   Over all, the document appears to be clear.
> 
> 
>   I wonder about the following text in section 4.5, however:
> 
>    NB: any DNS proxy (such as those commonly found in WiFi hotspot
>    "walled gardens") which transparently intercepts all DNS queries, and
>    which returns unsigned responses to signed queries, will also cause
>    TSIG authentication failures.
> 
> 
>   The problem with WiFi hotspot DNS proxies is much, much, worse than
> this simple paragraph would suggest.  There are issues found in in those
> deployments that are not discussed in this document.  I will summarize
> them here:
> 
> 
> Issue: responding to all DNS requests with the IP of the hotspot
> 
> Goal: to guide all client traffic to the hotspot
> 
> Background: Many client machines have VPN software that checks for the
> existence of "internal" corporate DNS names.  If the names resolve, the
> client is assumed to be "within" the corporate network.  If the name
> does not resolve, the client is assumed to be elsewhere, and the VPN
> software behaves differently.  DNS proxies that return an answer for all
> names result in the client erroneously believing it is in the "internal"
> network.  Various things then fail in weird and wonderful ways.
> 
>   Even when VPN software doesn't exist, this practice can cause other
> problems.  A commonly used web browser (I.E. from a major vendor) can
> cache the results of DNS queries at the application layer.  This
> information is cached even across DHCP lease assignments from a new
> subnet, where DNS caches are usually flushed.  The result is that the
> web browser cannot view the first web page that the user tries to visit.
> The captive portal page is always shown instead.
> 
> Suggestion: DNS proxies MUST NOT respond with an answer if the name is
> not resolvable.  DNS proxies MUST NOT synthesize an answer.
> 
> 
> Issue: responding to all DNS requests with a fake IP (commonly 1.1.1.1)
> 
> Goal: to catch *different* kinds of traffic than the previous issue
> (this is no explanation, I've never had one explained to me in a way I
> understand)
> 
> Background: Some proxies return synthetic responses with "fake" IP
> addresses.  While 1.1.1.1 is not currently allocated, it may be in the
> future.  Using it is a bad choice.  In fact, this whole practice is
> completely wtong.
> 
> Suggestion: Same as above.  DNS proxies MUST NOT synthesize an answer.
> 
> 
>   The above suggestions might be a little strong.  There are valid cases
>  where a proxy inside of a corporate network might need to synthesize
> incorrect answers.  These situations are better described as "internal
> corporate policy".  i.e. Notwithstanding the suggestions above, if you
> want to break your own network, there are often valid reasons for doing so.
> 
>   Alan DeKok.
> _______________________________________________
> AAA-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aaa-doctors