Re: [dns-privacy] [EXTERNAL] Re: Review request: draft-btw-dprive-rfc8484-clarification

[Neil Cook <[e-mail]>]

> On 9 Sep 2020, at 15:35, Ben Schwartz <bemasc=[e-mail]> wrote:
> 
> Caching at the CPE reduces upstream resolver load by quite a lot more than you might imagine not actually a big problem but it’s nice to avoid adding compute if there is a cheaper solution trivially available.
> It sounds like the key goal here is caching at the CPE; the other goals could be served by client-specific logic at the central resolver.  Do ISP-provided CPEs normally operate a DNS cache?  My understanding was that they are usually mostly-stateless forwarders.
> 

Yes lots of ISP-provided CPEs do caching. There is a draft in the ADD WG that describes this for at least 3 large ISPs in Europe.

There are other reasons for wanting to do DoH in the CPE, such as performing DNS filtering on the CPE.

BTW I’d interested in how “client-specific logic at the central resolver” solves the connection count issue?
> * How does the server know which CPE to redirect the client to?
> 
>  
> 
> I’m are assuming here that this is an ISP running both elements so knowing how to map the incoming IP to the name its currently using / was told to use is relatively trivial.
> 
> 
> Trivial, perhaps, but not necessarily secure.  An adversary in the network could alter the IP headers to change the apparent client location, causing the client to be redirected to an attacker-controlled CPE, thus defeating the integrity assurances of DoH.

Possible, but I’m not sure this is a practical attack. The attacker would need to be able to also change all the IP headers in the return packets to their original values (that’s hard enough to do for legit purposes). Also, the attacker has to have compromised an ISP-managed CPE, and that CPE still needs to be running on an ISP-managed network connection.

Neil