[rssac-caucus] FOR REVIEW: Elements of Potential Root Operators

[Wes Hardaker]

Shane Kerr <shane at time-travellers.org> writes:

> One thing that I would like to see is a request that all of the
> information in this document be public.  For example, descriptions of
> zone distribution architecture.

I'm confused about whether you're asking about the internal
documentation about a particular operator (many (most?) operators of any
networks don't like advertising their exact internal architectures for
security-through-obscurity related reasons, which we shouldn't argue
about here), or are you asking about the root zone distribution system,
which is how IANA/ICANN/Versign/and-the-roots get data changes
propagated through the system.  This last system is fairly well
documented publicly I think, no?  I would need to go search for the
document that describes it, but I'm sure there is one (including how
zone changes are reviewed, etc).

> As someone without access to this for current root server operators I
> have to infer this - I often don't know whether something is broken in
> the root server system or whether they are merely acting in ways that
> I didn't expect because I don't know what's going on "under the hood".

I'd love to hear an example problem where you don't know of whether
something is broken or not based on some external test.

>     3.3.3 Addressing Resources
>
>     The candidate operator MUST have its own AS number(s) and IPv4 and
>     IPv6 address allocations. It is assumed that IP anycast will be
>     used. If IP anycast will not be used, a technology providing
>     similar or better service levels SHOULD be specified. Provider
>     address space or addresses that cannot be used with anycast are
>     undesirable. The expected production IPv4 and IPv6 address blocks
>     MUST be severable from the candidate’s organization to facilitate
>     emergency or planned transfers.
>
> Some RIRs have policies to allocate addresses for "critical use":
>
> https://www.nro.net/rir-comparative-policy-overview/rir-comparative-policy-overview-2016-02#2-4-2
>
> This means that potential root server operators probably do not need to
> have address space in advance of being approved for being a root server
> operator.

I think the paragraph is trying to say "the candidate MUST have address
space before coming an operator" not "before getting approved to be
one".  But it could probably be made more clear?

> My concern is that this will naturally lead to "diversity inflation"
> where each root server operator runs multiple versions of everything
> without any real benefit, and in fact a potential reduction in
> reliability of the overall system.

There is certainly a large amount of debate to be had about how much
diversity is a good thing.  Single points of failure are known to be
bad, and it would be bad if everyone ran the exact same version of bind
(eg) and FreeBSD (eg).  But too much diversity leads to more points of
failure, which I suppose could be bad.  Though if the system could lose
X% of it's deployed infrastructure without visibly affecting the service
itself, then high diversity is likely to be helpful since it's unlikely
that the entire system could go down if the diversity ensured it would
take multiple vulnerabilities to pass the X% threshold. 

-- 
Wes Hardaker
USC/ISI