Re: [Add] Soliciting input on "DDR and Forwarders"

[tirumal reddy <[e-mail]>]

Hi Ben,

Please see inline

On Wed, 9 Mar 2022 at 04:06, Ben Schwartz <[e-mail]> wrote:

> Thanks for the comments, Tiru.  I've posted a PR to address some of them
> here: https://github.com/bemasc/ddr-forwarders/pull/4
>
> On Tue, Mar 8, 2022 at 2:44 AM tirumal reddy <[e-mail]> wrote:
>
>> Hi Ben,
>>
>> Agree with the legacy DNS forwarder problem and the proposed solution:
>>
>> Comments below:
>>
>> 1. Any network device will have vulnerabilities (including cloud
>> workloads) and needs to be updated periodically to fixed versions. The home
>> routers that cannot be upgraded are most likely already compromised because
>> of existing vulnerabilities. It will be helpful to articulate this threat
>> and assume the attacker will always be on-path residing on the legacy
>> unpatchable home router.
>>
>
> This is a good point, but nothing here assumes that the router is
> "unpatchable".  The problem is that implementing DDR on a pre-existing
> gateway device is far from trivial.  It requires running an encrypted DNS
> (IMHO likely DoH) server, which may be difficult or impossible on legacy
> hardware.
>

Home networks will have both legacy routers and routers with network
security services. For instance, several security companies offer home
network network security on home routers (e.g.,
https://www.mcafee.com/consumer/en-au/store/SHP.html,
https://www.trendmicro.com/en_us/forHome/products/homenetworksecurity.html
etc.).
In my previous company, Secure Home Platform (SHP) is shipped on millions
of home routers with hardened OpenWRT. We are able provision a DoH/DoT
forwarder and each router was provisioned with a unique domain name (e.g.,
cpe1.example.com) and was assigned a PKIX certificate using ACME (see
https://datatracker.ietf.org/doc/html/draft-boucadair-add-deployment-considerations-00#section-4.1
for more details).

The legacy routers fall into three categories (1) cannot upgrade to support
encrypted DNS forwarder but patchable (2) cannot upgrade to support encrypted
DNS forwarder, not patchable and configuration cannot be modified (3) cannot
upgrade to support encrypted DNS forwarder but configuration is updated to
use the ISP DNS resolver (both encrypted and unencrypted).

My understanding is the proposed mechanism in your draft can be used for
both (1) and (2) deployments.


>
> 2. I like using the reputation of the resolver without burdening an
>> average user. A public database or consensus algorithm among OS and
>> browsers would increase the number of trusted resolvers. It would also
>> reduce the burden of an ISP to reach each and every OS and browser vendor
>> (to be added to the TRR).
>>
>
> I have no objection to that, but I don't think it's something that can
> happen inside the IETF.
>

It could be an experimental draft just like certificate transparency.


>
> 3.
>> https://datatracker.ietf.org/doc/html/draft-schwartz-add-ddr-forwarders-01#section-7.4,
>> it may not work with headless IoT devices.
>>
>
> I don't see a problem.  IoT devices still need to be administered by
> somebody through some controls, even if those controls are over the network.
>

IoT devices can be on-boarded both automatically and with user assistance
(see
https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-secure-bootstrapping).
However, I agree the latter mode is popular today.


>
> 4. A timeline (e.g., 5 or 10 years) to sunset the proposed mechanism would
>> be helpful.
>>
>
> I added a note related to this in the PR.  I don't think a fixed timeline
> is appropriate, but it's a good reminder that we don't expect this to be
> relevant forever.
>

Works for me.


>
> 5. If the discovered resolver is not trusted, a warning to the user will
>> be helpful (e.g., to upgrade the router).
>>
>
> Added.
>

Thanks.


>
> 6. I don't get the relevance of sections 4.1, 4.2 and 4.3 to this
>> specification.
>>
>
> This is an Informational document, providing an overview of the topic,
> including problems and various mitigations.  Section 4 discusses some less
> problematic aspects of this situation.
>

The draft is relaxing the mandatory validation discussed in DDR and is an
update to DDR. I am not sure about the Informational status of the draft !


>
> 7.
>> https://datatracker.ietf.org/doc/html/draft-schwartz-add-ddr-forwarders-01#section-7.1
>>
>> a) what kind of split-horizon namespaces are you referring to in home
>> networks ?
>>
>
> This document is not limited to home networks.  Even if this problem is
> only present in home networks, devices don't know whether a given network
> is a "home network", so we need to consider the impact on enterprise
> networks as well.
>

I thought the problem was specific to home networks.


>
> I do think there are some home networks with split DNS, but probably not
> too many.
>

I doubt if any home network would have split DNS with legacy forwarders.


>
>
>> b) I don't think this type of network will support homenet (see
>> https://datatracker.ietf.org/doc/html/rfc8375) ?
>>
>
> I'm not sure I understand.  NXDOMAIN fallback would seem to enable support
> for .home.arpa and
> https://datatracker.ietf.org/doc/html/rfc8375#section-6.3 discusses
> possible client behavior changes as well.
>

Yes, but my comment was if these legacy forwarders would even understand
DNS queries with ".home.arpa" and not forward it.

-Tiru