Subject: [arch-d] Treating "private" address ranges specially

From: "Martin Thomson" <[email-masked]>
Date: Wed, 31 Mar 2021 16:24:17 +1100

There is a proposal to add extra controls to the Web to prevent servers on the "public" Internet from connecting to "private" resources without consent:

https://wicg.github.io/private-network-access/

The short story here is that the Web has always included was in which browsers aim to protect themselves from the repercussions of their actions on networks that have insecure local services.  Basically, the browser asks the service for permission before it makes requests.  However, in the interest of compatibility, these protections have always had exceptions where no such permission was requested.  This proposal simply eliminates those exceptions for "private" addresses.

The way that this works is fairly simple.  The IPv4 and IPv6 special-purpose address registries [1][2] have a "globally reachable" flag.  If this flag is false, then a browser will always ask for permission before using a service on one of those addresses.  The browser will look for a new signal from the server (one that is unlikely to appear purely by accident) before it continues to make requests.  There's another similar protection when going from non-globally reachable addresses to loopback addresses.

(Note that this doesn't prevent cross-protocol attacks; it assumes that the server is talking HTTP.  HTTP is not that great at cross-protocol attacks, but there is a separate blocklist for ports that aims to manage that.)

The question then: is this is a reasonable approach for minimizing harm?  Is this sort of approach consistent with the vision for the addressing architecture, or is this an abuse of these flags?  Are there guidelines that we might follow in treating addresses based on their attributes?

My read here is that this is in line with design intent, but I claim no particular expertise with respect to the addressing architecture.  From my perspective, closing consent loopholes is a good thing.

Obviously, there is a school of thought that says if you stand up a networked service, then you need to protect it properly.  This isn't about ensuring that you use HTTPS or that you properly authorize access to resources that should be protected.  This is about browsers taking steps to avoid being complicit in attacks on services that aren't properly protected.

I should also point out that there is no protection conferred if a service is reachable via an address in a globally reachable space.  The proposal doesn't really acknowledge this possibility, but it's implied.

Cheers,
Martin

[1] https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
[2] https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

---

From: Erik Kline <[email-masked]>
Date: Tue, 30 Mar 2021 22:59:12 -0700

On Tue, Mar 30, 2021 at 10:25 PM Martin Thomson <[email-masked]> wrote:

> There is a proposal to add extra controls to the Web to prevent servers on
> the "public" Internet from connecting to "private" resources without
> consent:
>
> The short story here is that the Web has always included was in which
> browsers aim to protect themselves from the repercussions of their actions
> on networks that have insecure local services.  Basically, the browser asks
> the service for permission before it makes requests.  However, in the
> interest of compatibility, these protections have always had exceptions
> where no such permission was requested.  This proposal simply eliminates
> those exceptions for "private" addresses.
>
> The way that this works is fairly simple.  The IPv4 and IPv6
> special-purpose address registries [1][2] have a "globally reachable"
> flag.  If this flag is false, then a browser will always ask for permission
> before using a service on one of those addresses.  The browser will look
> for a new signal from the server (one that is unlikely to appear purely by
> accident) before it continues to make requests.  There's another similar
> protection when going from non-globally reachable addresses to loopback
> addresses.
>
> (Note that this doesn't prevent cross-protocol attacks; it assumes that
> the server is talking HTTP.  HTTP is not that great at cross-protocol
> attacks, but there is a separate blocklist for ports that aims to manage
> that.)
>
> The question then: is this is a reasonable approach for minimizing harm?
> Is this sort of approach consistent with the vision for the addressing
> architecture, or is this an abuse of these flags?  Are there guidelines
> that we might follow in treating addresses based on their attributes?
>
> My read here is that this is in line with design intent, but I claim no
> particular expertise with respect to the addressing architecture.  From my
> perspective, closing consent loopholes is a good thing.
>
> Obviously, there is a school of thought that says if you stand up a
> networked service, then you need to protect it properly.  This isn't about
> ensuring that you use HTTPS or that you properly authorize access to
> resources that should be protected.  This is about browsers taking steps to
> avoid being complicit in attacks on services that aren't properly protected.
>
> I should also point out that there is no protection conferred if a service
> is reachable via an address in a globally reachable space.  The proposal
> doesn't really acknowledge this possibility, but it's implied.
>
> Cheers,
> Martin
>
>
> [1]
> https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
> [2]
> https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
>
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

I'm not clear how much this will really achieve in the presence of typical
IPv6 addressing.  For example, though I haven't read this entirely nor in
detail, the text in 2.2 is somewhat curious.  My reading of that, for one
example scenario, is:

    [1] suppose a URL's host resolves to an IPv6 ULA address
    [2] likely the client has a ULA address as well as a few GUA addresses
    [3] RFC 6724 source address selection selects the ULA source for the
ULA destination
    [4] ergo connection is not deemed private --> any web page can cause a
client to connect to "private" IPv6 destinations

Wouldn't the same be true of a client with only an RFC1918 address, i.e. a
web page can cause connections to RFC1918 destinations?  I'm sure I'm
misunderstanding something here.

---

From: Erik Kline <[email-masked]>
Date: Tue, 30 Mar 2021 23:17:14 -0700

On Tue, Mar 30, 2021 at 10:59 PM Erik Kline <[email-masked]> wrote:

>> There is a proposal to add extra controls to the Web to prevent servers
>> on the "public" Internet from connecting to "private" resources without
>> consent:
>>
>> I should also point out that there is no protection conferred if a
>> service is reachable via an address in a globally reachable space.  The
>> proposal doesn't really acknowledge this possibility, but it's implied.
>>
>> Cheers,
>> Martin
>>
>>
>> [1]

My mistake.  I think the key text I didn't property absord was "the current
url's host".

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 31 Mar 2021 17:20:39 +1100

On Wed, Mar 31, 2021, at 17:17, Erik Kline wrote:
> My mistake.  I think the key text I didn't property absord was "the 
> current url's host".

:) Yes, though if you have name resolution that produces a ULA (which might happen in mDNS), then you would be contacting a "private" address.

---

From: Erik Kline <[email-masked]>
Date: Wed, 31 Mar 2021 00:07:43 -0700

On Tue, Mar 30, 2021 at 11:21 PM Martin Thomson <[email-masked]> wrote:

> :) Yes, though if you have name resolution that produces a ULA (which
> might happen in mDNS), then you would be contacting a "private" address.
>

I will say that this approach would seem to functionally treat all private
spaces as equivalent.  It's fairly easy to think of there being,
essentially, _one_ public sphere, but I think in practice there can be many
different private spaces.  I'm not sure how well that will play out [1],
but maybe it's no worse than today.

[1] I'm imagining a client w/ a private address and VPNs to two different
organizations using two different private spaces.  Now a web page from
ORG1's private address space can cause the client to issue queries to
ORG2's privately addressed resources.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 31 Mar 2021 18:15:48 +1100

> On 31 Mar 2021, at 6:07 pm, Erik Kline <[email-masked]> wrote:
> 
> I will say that this approach would seem to functionally treat all private spaces as equivalent.  It's fairly easy to think of there being, essentially, _one_ public sphere, but I think in practice there can be many different private spaces.  I'm not sure how well that will play out [1], but maybe it's no worse than today.
> 
> [1] I'm imagining a client w/ a private address and VPNs to two different organizations using two different private spaces.  Now a web page from ORG1's private address space can cause the client to issue queries to ORG2's privately addressed resources.

Is that the case? My understanding is that this proposal only reduces privilege when interacting with resources that are considered private, it doesn't add new privileges .  But I could misunderstand.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Erik Kline <[email-masked]>
Date: Wed, 31 Mar 2021 01:31:48 -0700

On Wed, Mar 31, 2021 at 12:15 AM Mark Nottingham <[email-masked]> wrote:

> > I will say that this approach would seem to functionally treat all
> private spaces as equivalent.  It's fairly easy to think of there being,
> > [1] I'm imagining a client w/ a private address and VPNs to two
> different organizations using two different private spaces.  Now a web page
> from ORG1's private address space can cause the client to issue queries to
> Is that the case? My understanding is that this proposal only reduces
> privilege when interacting with resources that are considered private, it
> doesn't add new privileges .  But I could misunderstand.
>

<more speculation>

If we discard the "local" space discussion, then a request is private iff.
the "request’s current url's host maps to a private address, and request’s
client's IP address space is public"... I think (per 2.2)?  If I'm reading
this correctly, then I would think that section 3.1 #2, "[r]equests whose
client's IP address space is private are allowed to fetch resources from
private and public addresses as they do today" would mean a private
resource fetched from a private address in the context of a current URL
privately addressed host does not incur any extra Fetch algorithm
modification (it's not a "private network request").

(But I admit that I'm not versed in Fetch algorithm steps 1 through N so
I'm not readily understanding "modifications to behaviour between steps m<n
and n<=N".  Also, it's past my bedtime. :-)

I merely meant that two different private spaces appear to be treated the
same.  I suspect in practice there's no practical way to distinguish one
private space from another (short of explicit PVD information).  I still
think this proposal is no worse than the status quo in this regard, though.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 31 Mar 2021 10:50:09 +0200

Martin,

This seems well-meaning, but the heuristic might need work, depending on the scope of protection that is really needed.

On my own home network, for which I do nothing special as far as addresses are concerned, I currently see two public IPv6 networks being advertised from my cable co.
I also see public addresses on my VPN tunnels.  Were you to hardcode something around ULAs or 1918 addresses, this stuff wouldn’t really apply to me (or to many home networks).  On the other hand, if you were to apply a policy by matching the subnet mask to one of those networks… that would make a difference.  It may make sense to take as private some list as configuration for enterprises.  You might even be able to deduce this from a proxy.pac file, although that seems a bit fraught with corner cases.

Also, what do the proponents expect/want the behavior to be in the face of devices like printers, ovens, and who-knows-what that have these dinky little web servers, many of which would likely not update for quite some time (if ever)?

I’m presuming one doesn't want to cause an e-Waste problem as happened with popular printers in the face of an update to a popular OS this past year. I doubt people will replace their refrigerators over this, but if they can’t print…

Eliot

> On 31 Mar 2021, at 08:20, Martin Thomson <[email-masked]> wrote:
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 31 Mar 2021 10:07:58 +0100

Following up Erik's message below.

> modification (it's not a "private network request").

The document's description of the address space architecture is:

2.1. IP Address Space

Every IP address belongs to an IP address space, which can be one of three
different values:

   1.

   local: contains the local host only. In other words, addresses whose
   target differs for every device.
   2.

   private: contains addresses that have meaning only within the current
   network. In other words, addresses whose target differs based on network
   position.
   3.

   public: contains all other addresses. In other words, addresses whose
   target is the same for all devices globally on the IP network.

The contents of each IP address space
<https://wicg.github.io/private-network-access/#ip-address-space> are
determined in accordance with the IANA Special-Purpose Address Registries (
[IPV4-REGISTRY]
<https://wicg.github.io/private-network-access/#biblio-ipv4-registry> and
[IPV6-REGISTRY]
<https://wicg.github.io/private-network-access/#biblio-ipv6-registry>). To
determine the IP address space
<https://wicg.github.io/private-network-access/#ip-address-space> of a
given IP address (address), run the following steps:

   1.

   If address is an IPv4 address <https://url.spec.whatwg.org/#concept-ipv4>
   in the "Loopback" address block (127.0.0.1/8 at time of writing), then
   return local
   <https://wicg.github.io/private-network-access/#ip-address-space-local>.
   2.

   If address is an IPv6 address <https://url.spec.whatwg.org/#concept-ipv6>
   in the "Loopback Address" address block (::1/128 at time of writing),
   then return local
   <https://wicg.github.io/private-network-access/#ip-address-space-local>.
   3.

   If address is an IPv6 address in the "IPv4-mapped Address" address block
   (::ffff:0:0/96 at time of writing), return the IP address space
   <https://wicg.github.io/private-network-access/#ip-address-space> of its
   embedded IPv4 address.
   4.

   If address belongs to an address block for which the Globally Reachable
   bit is set to False in the relevant IANA registry, then return private
   <https://wicg.github.io/private-network-access/#ip-address-space-private>
   .
   5.

   Otherwise return public
   <https://wicg.github.io/private-network-access/#ip-address-space-public>.

Note: Link-local IP addresses such as 169.254.0.0/16 are considered private
<https://wicg.github.io/private-network-access/#ip-address-space-private>,
since such addresses can identify the same target for all devices on a
network link. A previous version of this specification considered them to
be local
<https://wicg.github.io/private-network-access/#ip-address-space-local>
instead.
What I think this proposal would actually like to do is to determine
whether a resource referenced by a specific web server would also be
reachable by that server.  If it is:  allow the reference; if it is not,
but it is for the client: ask the user.  First, I'm not a huge fan of "ask
the user" in decisions that rely on an understanding of opaque inner
workings of the net, and this runs that risk.  Having users understand
whether specific disjoint reachability domains are disjoint on purpose or
because of some accident of history does not strike me as a likely win.
Second, I don't understand the intended client behavior here if it accesses
web resources via a proxy, and I didn't find any mention of proxy behavior
in the text.  Text about this in the final document would be useful.

Lastly, "public" and "private" are very poor proxies for the actual
reachability information for a specific host.  A host can have multiple
interfaces, address families, and scopes and the mitigations IPv4/IPv6
interworking make that even more complicated.  In the WebRTC case, the
presence of destinations reachable via TURN which are in distinct
reachability domains is another complication. The current reality is that
the destination address does not encode the reachability domain in any
meaningful way *for the host*.  This is especially true in the
unfortunately large number of organizations who have repurposed unrouted
addresses as "extra" private address space (
https://teamarin.net/2015/11/23/to-squat-or-not-to-squat/ is old, but the
practice is far from dead).

If the final proposal doesn't actually tackle that complexity, we will
likely be left with a system that doesn't protect what it intends to
because it lumps all reachability domains into broad classes.  Add to that
a consent request that most users can't parse and wouldn't have the real
data to answer, and I think this is more burden than benefit.

regards,

Ted Hardie

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Apr 2021 09:27:05 +1300

Hi,

On 31-Mar-21 22:07, Ted Hardie wrote:

<snip>

> Every IP address belongs to an IP address space, which can be one of three different values:
> 
>  1. local: contains the local host only. In other words, addresses whose target differs for every device.
> 
>  2. private: contains addresses that have meaning only within the current network. In other words, addresses whose target differs based on network position.
> 
>  3. public: contains all other addresses. In other words, addresses whose target is the same for all devices globally on the IP network.

The problem is that this classification is worse than heresy; it's nonsense.

1) local. That seems trivially true (assuming that it covers virtual hosts, not just physical ones). Or is it? If a device has multiple interfaces (physical or virtual) which might lie in different administrative domains, each of which has several IP addresses, including but not limited to loopback addresses, are they all equally "local"?

2) private. There is no definition of "private" address in any IETF document. There is no way of looking at the bits in an address and determining that it's private, because there's no definition of private.

3) public. Ditto. Globally reachable != public. "Globally reachable" itself is an over-simplification. See recent very loud discussions in IPv6-land about ULA addresses.

The attempt to use the IANA registry to determine things that are undefined is just nonsense. It's an attempt to over-simplify something that is inherently complex. The ground truth about address scope exists only in the entire Internet's routing tables, and simply *cannot* be deduced from the bits in an address.

BTW, whoever designed the Python ipaddress module got this wrong too.

So IMHO this whole effort is fundamentally misguided and should be scrapped.

   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 1 Apr 2021 00:10:57 +0200

Brian, *:

a) +1

b) Maybe the reasons for what Brian is saying are not as obvious to hose working primarily
   at the app layer, so le me quickly add a bit of explanation: 

   rfc1918/ULA addresses may be as "global Internet" in reachability as "global scope" IP/IPv6
   addresses because of NAT (let's assume BEHAVE compatible applications and NATs to avoid getting
   sucked into a discussion about the "evilness&limitations" of NAT).

   Whereas in IPv4, rfc1988 addresses are often used this way due to address space limitations,
   in IPv6, ULA is likely used similarily just to have fixed addresses in all those cases where
   you do not have PI address space and just don't want to spend the money on renumbering
   when you change SP or multi-source address selection when you have PD addresses with
   redundancy.

   Aka: expect to create a huge amount of blowback of browsers starting to behave differently
   for those cases in companies or in homes where this happens.

   Likewise, just because you may use global-scope addresses (especially in IPv6), you
   as easily may have carved out address semantics for more limited scopes. Likely applicable
   to any larger organization that has PI address space and is not running out of it.
   See "firewalls".

c) There is actually (IMHO) a good discussion that should be had abouut how browser security could
   better support the needs of limited domains (rfc8799), but i fear the mayority of contributors
   to w3c / browser security in ietf still think everything required is just what fits the global
   Internet web-pki and Internet cloud services centric browser security architecture we have today.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Geoff Huston <[email-masked]>
Date: Thu, 1 Apr 2021 10:45:44 +1100

+1 to Brian - I find this whole “browsers know best” approach misguided as well!

Geoff

> On 1 Apr 2021, at 7:27 am, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 01 Apr 2021 10:52:34 +1100

Thanks everyone for the insights.

I'll reply to Ted as he hit the crux of the issue most adroitly...

On Wed, Mar 31, 2021, at 20:07, Ted Hardie wrote:
> reachable by that server.  

That's exactly it.

Brian's point about the inherent folly of making such guesses is well taken.

It's quite clear that it is generically bad to make these sorts of inferences from addresses.  That's good information.

The question I'm now interested in answering is whether using these as part of a heuristic in order to limit the scope of a change like the proposed is tolerable. 

The goal here is to close off a security loophole in how browser make request for a tiny slice of the total set of requests that are made.  The ultimate goal might be to remove the loopholes uniformly.  However, that would break so much stuff that a change like that would never stick.  This is a more narrowly-scoped approach that tries to identify conditions where the requests are a) more dangerous in general, and b) rare enough that any breaks would not be widely felt.

I've pointed out some of the limitations of this approach (and several more have been identified, thanks!), but I haven't seen reasons here why a heuristic like that proposed would be strictly problematic.  Assuming that these shortcoming are acknowledged properly (they are not currently) is there any reason not to use some sort of address-based heuristic for this sort of purpose?

I can see how building on top of this simplistic base for other purposes might be harmful, but is the specific action being taken inherently bad, or is it just not very good?  It not being very good is a totally fair criticism, but that will be balanced against the apparent utility here.  This design protects the badly-secured router provided by my ISP from requests from the big bad Internet.  That is a tangible outcome against which "addressing is more complex than this design allows for" doesn't weigh very heavily.

> First, I'm not a huge fan 
> of "ask the user" in decisions that rely on an understanding of opaque 
> inner workings of the net, and this runs that risk.  

I made the same comment myself.  "Not a huge fan" doesn't really cover it :)  I think that the "ask the user" provisions here are entirely misguided.  Thankfully, my understanding is that this might be implemented without any such controls, which would be good - at least to the extent that you are not happy with "ask the user" as a component in any design.

Eliot raised the converse question about consent, which is to say, is there an override so that users can enable access to stuff that doesn't provide consent on its own, such as old gear.  I agree that this would be desirable and made similar comments; I don't know what provision is being made there though.

> Second, I don't understand the intended client behavior 
> here if it accesses web resources via a proxy, and I didn't find any 
> mention of proxy behavior in the text.  Text about this in the final 
> document would be useful.

Good point; I had not considered that, but I believe that this does not make special provisions for proxies.  This protection would apply if proxy configuration says not to use a proxy, I think.  However, this could not apply if the vulnerable server were contacted via proxy, that is true.

> This is especially true in the 
> unfortunately large number of organizations who have repurposed 
> unrouted addresses as "extra" private address space 
> (https://teamarin.net/2015/11/23/to-squat-or-not-to-squat/ is old, but 
> the practice is far from dead).

Oh yeah, I had forgotten about that.  Another good point to add to those Brian makes.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 1 Apr 2021 02:04:22 +0200

Btw: If you look at the proposal in more detail, the browser actually does not try to
"know best" only by itself, but it uses a protocol for consultation from an entity
that hopefully does know better. That aspect i really like. Except that the solution
around such an approach would need to be revisited from scratch as opposed to be
extened ad-hoc as in this proposal. Especially the part where the browser does try to know the
semantic of an address purely from some IPv4/IPv6 architectural "address scopes".

Disclaimer: superficial, quick assesment..

Cheers
    toerless

On Thu, Apr 01, 2021 at 10:45:44AM +1100, Geoff Huston wrote:
> +1 to Brian - I find this whole ???browsers know best??? approach misguided as well!
> 
> 
> Geoff
> 
> 
> 

-- 
---
[email-masked]

---

From: Joseph Touch <[email-masked]>
Date: Wed, 31 Mar 2021 17:17:09 -0700

> On Mar 31, 2021, at 1:27 PM, Brian E Carpenter <[email-masked]> wrote:
> 

How is this different from RFC6890?

> 1) local. That seems trivially true

Again, RFC6890?

...
> 2) private. There is no definition of "private" address in any IETF document.

RFC1918??

> 3) public. Ditto. Globally reachable != public.

AFAICT, those are equivalent terms; there are lots of “not officially private”, “not officially local” addresses that are not globally reachable either (e.g., most things behind NATs).

So at best, this hierarchy isn’t ill defined or lacking RFC authority; it’s just incomplete.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Apr 2021 14:00:02 +1300

Thanks Toerless.

I should probably have cited the noisy recent discussions more precisely. The threads started at:
https://mailarchive.ietf.org/arch/msg/ipv6/SVEJoron3ICcjaQYjSJSzwsVxRM/
https://mailarchive.ietf.org/arch/msg/ietf/26nb2UjSHEQR9XIvHMQ6ZbeNubE/

(Warning: about 500 messages between them. Summary: simplistic ideas about address scope do not capture reality.)

Also see https://www.cs.auckland.ac.nz/~brian/scope6.pdf which tries to illustrate why certain ideas about address scope are simplistic.

I also forgot to mention another major issue: increasing use of address bits to carry locally defined semantics. Much as traditionalists might dislike this practice, it is increasingly popular and of course greatly complicates the question.

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Apr 2021 14:30:04 +1300

On 01-Apr-21 13:17, Joseph Touch wrote:
> 
> 
>> On Mar 31, 2021, at 1:27 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>

While 6890 is better than what came before, I'm afraid that it still doesn't capture reality (and therefore the IANA registry doesn't either, which is no fault of IANA).

>> 2) private. There is no definition of "private" address in any IETF document. 

Yes, you're right, it does use the word "private". But that is in some old out-dated address space where things are relatively simple. In any case, the definition proposed in the cited document doesn't seem to limit itself to that, but tries to extrapolate the same categories to IPv6 and that simply doesn't work.

> So at best, this hierarchy isn’t ill defined or lacking RFC authority; it’s just incomplete.

I really don't agree. There is a class of address prefixes that are *potentially* globally reachable and therefore potentially public, but there is no way to know by looking at a specific address. So there is no algorithm to reliably return "private" or "public". When I worked for the Network 9 company, you would have needed quite a large table to know which 9.x.y.z addresses were public and which were private. When you installed the corporate VPN, it didn't install a single route to 9/8. It installed a local routing table with a page or two of prefixes. The sort of algorithm proposed here would simply return "public" for any such address. (Try the attached Python script.)

Regards
   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 1 Apr 2021 03:53:42 +0200

I think there are three levels of concern here:

a) The "designated" use/reach of addresses according to architecture
   This is what the proposal assumes can be used to deduce policy from

b) The actually operational use/reach of addressing with the addition of 
   reachability via NAT and the subtraction via routing and firewalling
   which i think Brian referred to and what i tried to explain in my
   prior mail, suggesting this is the minimum level of policy for reachability
   which to consider.

c) Th actual "third-party-access" policy an operator would desire a particular
   browser application to have. I think this will have nothing to do with
   a). At best it will be a subset of b), but in general, i think we won't
   know unless we look at explicit use cases and derive a design from them.

Cheers
    Toerless

On Thu, Apr 01, 2021 at 02:30:04PM +1300, Brian E Carpenter wrote:
> > AFAICT, those are equivalent terms; there are lots of ???not officially private???, ???not officially local??? addresses that are not globally reachable either (e.g., most things behind NATs).
> > 
> > So at best, this hierarchy isn???t ill defined or lacking RFC authority; it???s just incomplete.
> 

> #!/usr/bin/env python3
> # -*- coding: utf-8 -*-
> import ipaddress
> print("This will tell you what Python believes are the properties of any IP address")
> while True:
>     print("Please enter an IP address:")
>     _l = input()
>     if 'q' in _l or 'Q' in _l:
>         break
>     try:
>        _l = ipaddress.IPv6Address(_l)
>     except:
>         try:
>            _l = ipaddress.IPv4Address(_l)
>         except:
>             print("Invalid")
>             continue
>     # Now display address properties
>     print("That's", _l)
>     try:
>         print("Global", _l.is_global)
>     except:
>         print("Global (undefined for IPv4)")
>     print("Private", _l.is_private)
>     print("Unspecified", _l.is_unspecified)
>     print("Reserved", _l.is_reserved)
>     print("Loopback", _l.is_loopback)
>     print("Link Local", _l.is_link_local)
>     print("Multicast", _l.is_multicast)
>     print()
> print("Goodbye")

-- 
---
[email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Wed, 31 Mar 2021 20:33:14 -0700

Martin,

Do you have a description of the type of attacks you are thinking off? I 
understand the general idea of "malicious server somehow gets to use or 
attack internal sites behind the firewall", but a concrete description 
of a couple examples might help. Is it about opening a frame against an 
internal host, or about running javascript and evading the standard 
protections? Is it something like the "request forgery attacks" 
discussed in QUIC?

-- Christian Huitema

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 01 Apr 2021 14:57:23 +1100

On Thu, Apr 1, 2021, at 14:33, Christian Huitema wrote:
> Do you have a description of the type of attacks you are thinking off? 

This is a general problem of which I have only a handful of concrete examples.

The proposal mentions SOHO Pharming, though the link is broken.  In essence, that attack abused default passwords and poorly secured routers to allow DNS configuration on those routers to be hijacked.  This sort of thing is fixed by any of a bunch of things (HTTPS, better passwords, changes to local topology, DoH), but it was still shockingly effective.

The other example I'm aware of is the Zoom problem (last year?  seems longer ago) where they ran a server on loopback that took instruction from random websites.  That was poorly secured and could be exploited.

I'm not clear on whether this particular proposal aims to address this (it might not) but enumeration of servers on local networks could be another target.  (It doesn't appear to attempt to block the timing side channels that are typically used for this, but it could.)

---

From: Christian Huitema <[email-masked]>
Date: Wed, 31 Mar 2021 22:30:33 -0700

On 3/31/2021 8:57 PM, Martin Thomson wrote:

> The other example I'm aware of is the Zoom problem (last year?  seems longer ago) where they ran a server on loopback that took instruction from 
random websites.  That was poorly secured and could be exploited.
> I'm not clear on whether this particular proposal aims to address this (it might not) but enumeration of servers on local networks could be another target.  (It doesn't appear to attempt to block t…

I found a copy of the SOHO Pharming paper at 
http://courses.isi.jhu.edu/netsec/papers/Driveby_Pharming.pdf. The 
attack required a combination of Java Applet or ActiveX, javascript, and 
routers configured with the default password. AFAIK, ActiveX is mostly 
gone. The two suggested mitigations were to (1) uninstall Java and (2) 
change the router password. Of course, not everybody will do that.

If I remember correctly, at the end of the discussion of request forgery 
attacks in the QUIC WG, most implementers concluded that the best we 
could do was "protect loopback", precisely because the definition of 
"private networks" is way to fuzzy to make defense practical. How is 
this different?

-- Christian Huitema