Re: [Add] [EXTERNAL] Private IPs, DDR, and PR#11

[Ben Schwartz <[e-mail]>]

I agree that this topic is worthy of agenda time.  I would be happy to
contribute some slides, perhaps in collaboration with someone who's argued
the opposite side.

On Wed, Jul 7, 2021 at 5:03 PM Deen, Glenn (NBCUniversal) <
[e-mail]> wrote:

> This is an important discussion and I’m a little worried that it’s not
> getting enough eyes on it at the moment  – which is why there isn’t a lot
> of traffic discussing it – very possibly due to it being a popular vacation
> time in the US and elsewhere for summer and people busily on other
> drafts/things.   So making a big decision on list traffic alone at the
> moment might be a bit rushed.
>
>
>
> I do recall that previously the WG had discussed the scenario and it was
> important to an number of people and we’ve already had a lot of discussion
> that went into building up the requirements Doc around this.
>
>
>
> Suggestion:   Before anything gets even seriously considered for removal,
> we should discuss the proposition during the ADD session for IETF111, and
> in any post IETF111 list traffic that discussion may trivver.   Is
> someone(s) willing to put together a couple of slides documenting the
> scenario at IETF111?
>
>
>
>
>
> -glenn as ADD co-chair
>
>
>
> On 7/7/21, 9:46 AM, "Add on behalf of Tommy Jensen" <[e-mail]
> on behalf of Jensen.Thomas=[e-mail]> wrote:
>
>
>
> > Are there an appreciable number of networks with these properties? If
> so, can we write down where that happens and put it in Security
> Considerations? If not, we should consider removing this mode.
>
>
>
> Just my 0.02: I would support removing this whether in PR#11 or DDR as it
> stands. The reason we added this “same IP is allowed without verification”
> mechanism was in response to WG feedback that expecting ecosystem members
> to accomplish this on our own was unreasonable (the authors originally said
> “we leave that to DoT knocking which is already suggested in RFC7858”).
>
>
>
> I see Michael already commented on this; it would be useful to hear more
> WG commentary on this point. I was under the impression that there is some
> subset of network operators who found that useful. If not, we should
> revisit.
>
>
>
> Thanks,
>
> Tommy
>
>
>
> *From:* Add <[e-mail]> *On Behalf Of *Eric Rescorla
> *Sent:* Thursday, July 1, 2021 3:18 PM
> *To:* ADD Mailing list <[e-mail]>
> *Subject:* [EXTERNAL] [Add] Private IPs, DDR, and PR#11
>
>
>
> I've been spending some time thinking about PR#11 and trying
> to figure out the threat model where it brings value. This
> message is an attempt to get to a better understanding. As
> should be clear, I'm a little confused, so if people want
> to tell me why I'm wrong, that would be helpful.
>
>
> First, let's start with what I take to be the network topology:
>
>
>                    ISP Resolver
>                     192.0.2.1
>                         |
>                         | <- ISP Network
>                         |
>                     192.0.2.100
>                    CPE/DNS Proxy
>                      10.0.0.1
>                         |
>                         | <- Home network
>                         |
>                      10.0.0.100
>                     Users device
>
>
> We have the ISP's resolver with a public address of 192.0.2.1.  The
> user has some sort of CPE with an external address of 192.0.2.100 and
> an internal address of 10.0.0.1. The user's device has an IP of
> 10.0.0.100. When the user's device does DHCP, it gets the address
> 10.0.0.1 for its resolver, presumably because the CPE intends to proxy
> or cache DNS, otherwise it could just serve the ISP's resolver address
> (192.0.2.1) in DHCP.
>
> The general assumption for the DDR threat model so far is that:
>
> 1. The user's device gets the address of its resolver securely
> (presumably because DHCP is secure in some way). If that's not true,
> then I think we can agree that DDR does not provide much additional
> security benefit because the attacker can just substitute their own
> resolver [0].
>
> 2. Either the home network or the ISP network is insecure, otherwise
> you don't need DoX.
>
> OPPORTUNISTIC MODE
> So, first, its not entirely clear to me what the Opportunistic mode of
> S 4.2 provides. In this scenario, presumably the client will be doing
> TLS to the CPE (because otherwise the IP address would be the
> resolver's public address), which means that we are concerned with the
> attacker controlling the home network. So, in this scenario, we are
> only getting value if you have a network in which:
>
> 1. The attacker can *see* traffic not destined for their IP address
>    (otherwise there's not much point in encrypting).
> 2. The attacker cannot forge traffic from another IP address
>    (otherwise they can just impersonate the CPE because there
>    is no certificate).
>
> Are there an appreciable number of networks with these properties? If
> so, can we write down where that happens and put it in Security
> Considerations? If not, we should consider removing this mode.
>
>
>
> PR #11
> The idea with PR#11 seems to be to bootstrap up from a local IP
> address issued via DHCP to some other address. PR#11 doesn't do that
> great a job of describing the setting, but I'm assuming the scenario
> is that we want to start from a situation in which we have a CPE-based
> proxy and move to a situation in which the user's device talks directly
> to the ISP resolver. Otherwise, presumably, we could just make do
> with the mode in S 4.2. Is this right or am I missing something?
> And the reason we're not just vending the ISP's resolver directly
> via DHCP is that the CPE isn't upgradeable or potentially under
> the user's control and not the network's?
>
> So, first, what threat model are we concerned with:
>
> 1. If it's control of the home network, then why can't the attacker
>    block the _SVCB record between the user and the CPE stopping
>    them from upgrading?
>
> 2. If it's control of the link to the ISP, then why can't the
>    attacker just block the resolution of the _SCVB record between
>    the CPE and the ISP's resolver? Maybe the CPE is using DoX,
>    but we're trying to protect against *future* compromise
>    of the user's network?
>
> Can we get this documented before we start designing mechanisms?
> That would also help understand the effectiveness of the 5 minute
> timeout.
>
>
> Finally, assuming I've understood things correctly, reaching through
> the CPE in this way seems like it has the potential to bypass any
> CPE-specific filtering that the user has has installed. Suppose I have
> some CPE that uses the ISP DNS but filters out certain names; if the
> ISP posts a _SVCB record that directs me to their resolver, doesn't
> that cause that filtering not to work?
>
> -Ekr
>
> [0] Modulo cdisco-style steering where the address is matched up
> against a trusted list.
>
>
>
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>