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

[Ted Hardie <[e-mail]>]

I've snipped almost everything to give a narrow response to your follow-up
question.

On Thu, Apr 1, 2021 at 12:53 AM Martin Thomson <[e-mail]> wrote:


> 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.
>

My personal take is that this does not do what it says on the tin, and that
deploying a security mitigation that doesn't do what it says it does is
inherently bad.

As Toerless pointed out, the simple designations tell you whether something
is *potentially* globally routable or *potentially* private.  In
organizations that got lots of globally routable space, parts of it were
carved into limited reachability domains.  Those are just as private for
those organizations as those marked in the IANA registry.  They are not
protected by this, but in the presence of this method, the organizations
might assume those private addresses were (and the number of organizations
with sufficient address space to do this in IPv6-land is not small).  There
are lots of other organizations that have deployed methods to make IP
address space that is nominally private actually have a greater scope.
They would lose the ability to reference resources that should be
reachable.  That breaks the character of the web.

Mapping the reachability overlap of two hosts on the network is,
unfortunately, a complex problem in the current Internet.  I don't think
that this registry-based approach is a sound basis for tackling the
problem.

Just my two cents,

Ted Hardie