Re: [Add] Relaxed validation and delegated IPv6 prefixes (Was: New Version Notification for draft-schwartz-add-ddr-forwarders-00.txt)

["STARK, BARBARA H" <[e-mail]>]

The GUA address is assigned on LAN-facing interfaces only and is not reachable via the WAN interface. Just because an address is a GUA doesn't mean it has to be reachable from the Internet or via all interfaces. I suppose someone could hairpin through a compromised device on the LAN to get to it. But if they have a compromised device on the LAN, it doesn't matter what format of address is used.
Barbara

From: tirumal reddy <[e-mail]>
Sent: Monday, October 11, 2021 12:02 AM
To: Ben Schwartz <bemasc=[e-mail]>
Cc: STARK, BARBARA H <[e-mail]>; ADD Mailing list <[e-mail]>
Subject: Re: [Add] Relaxed validation and delegated IPv6 prefixes (Was: New Version Notification for draft-schwartz-add-ddr-forwarders-00.txt)

Using a global unicast IPv6 address for a DNS forwarder on the home router would expose it to external attacks (e.g., DDoS, capability to resolve private domains). If the purpose of the forwarder is to only resolve the queries from the devices attached to the home network, I don't get why a DNS forwarder on the home router would want to use a global unicast address and act like a public resolver ?

Cheers,
-Tiru

On Mon, 11 Oct 2021 at 07:37, Ben Schwartz <bemasc=[e-mail]<mailto:[e-mail]>> wrote:
 If the DNS forwarder is identified by a public address (IPv4 or IPv6), then it could get a TLS certificate for that IP address.  A client policy that doesn't require authentication in this case, even though authentication is possible, would be a much bigger departure from baseline DDR.  I would prefer not to describe that behavior in this draft.

<bhs> When you say "[the DNS forwarder] could get a TLS certificate for that IP address", are you saying it would be possible for a gateway to get a PKI CA-signed certificate every time it gets delegated an IPv6 prefix (and subsequent renewal)?

I misspoke.  Let me try again:

In DDR, the Encrypted Resolver must hold a certificate that covers the IP address of the Unencrypted Resolver unless the resolvers have the same IP.  Thus, if the gateway uses a public IP address, and is actually a forwarder, then the upstream resolver must return a certificate that covers the gateway's IP address.

This is not the same as placing a PKI certificate on the gateway.  (I don't know if it's easier or harder.)

...
So if a client is provided a private IPv4 DNS server address and a public (GUA) IPv6 DNS server address (and, BTW, both reply with identical resolver.arpa info), will the relaxed-validation client prefer IPv6 and not upgrade because the IPv6 address is a GUA? Or will the relaxed-validation client try the private IPv4 address (also?) and do the DoH upgrade?

I think it will do the upgrade, via the IPv4 server.

I'm ok not worrying about people with static public IPv4 address assignments (assuming the same argument that a certificate isn't realistic). That's a small population. But is it really not possible to explore allowing "same IPv4 subnet" or "on-link IPv6 prefix"?

Let's consider two clients, one implementing "baseline DDR" and one that relaxes validation as you've described.  They are on a v6-only network whose DNS server has a public IP and is "on-link" according to some criterion.  A DDR query tells the client to use a "far away" designated resolver.

If the local DNS server is actually a forwarder, then it is arguably safe to upgrade without certificate validation.  However, the client doesn't know whether this server is a forwarder.  It might actually be a full resolver.

Suppose there is an active attacker close to the "far away" designated resolver.  The "baseline DDR" client enforces certificate validation, so it detects this attacker and continues to use the local (full) resolver.  As a result, the attacker (who is far away) cannot see or modify most/any of the user's queries.  The "relaxed" client sends all their queries straight to the attacker.

This seems like a much larger departure from the baseline DDR security model than anything contemplated in this draft, so I would prefer not to combine it.  However, this situation is important, and should be mentioned in the draft.  I've added the following paragraph in the pull request [1]:

> IPv6-only networks whose default DNS server has a Global Unicast Address are out of scope, even if this server is actually a simple forwarder.  If the DNS server does not use a private IP address, it is not a "legacy DNS forwarder" under this draft's definition.

[1] https://github.com/bemasc/ddr-forwarders/pull/3<https://urldefense.com/v3/__https:/github.com/bemasc/ddr-forwarders/pull/3__;!!BhdT!wdNh5WKV-u2xtQFlX4hvyjwttEo6LlYpIFsOhKMSSiKdvYcs6wE6UDQCYNa2XA$>
--
Add mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/add<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!BhdT!wdNh5WKV-u2xtQFlX4hvyjwttEo6LlYpIFsOhKMSSiKdvYcs6wE6UDR9Xhh1xA$>