subject:"Re\: \[DNSOP\] \"Secure Unowned Hierarchical Anycast Root Name Service \- And an Apologia\" \(circleid\)"

Re: [DNSOP] "Secure Unowned Hierarchical Anycast Root Name Service - And an Apologia" (circleid)

2014-11-16 Thread Warren Kumari

On Friday, November 14, 2014, Wolfgang Nagele (AusRegistry) <
wolfgang.nag...@ausregistry.com.au> wrote:

>  Hi,
>
>   AS112 absolutely proves that unowned anycast can work at scale; that's
> not
> my concern.  But if my neighbor announces a route to the AS112 addresses,
> and then misconfigures a server, fills it with lies, or logs all my
> queries, the practical effect on me is pretty small: the worst case
> scenario I can think of offhand is that somebody gleans information about
> my internal network topology that probably wouldn't have been difficult to
> guess anyway.
>
>  One of my biggest concerns about the current proposal is that it seems
> to suggest that AS112 works.
>

Actually, AS112 works just fine
.
.
.
... except when it doesn't.

It is very hard to discover who is answering AS112 queries and go poke them
when things go awry - luckily, the primary effect of a "bad" AS112 node is
often (usually?) just a reduction in the AS112 benefit - it doesn't
actually break you, it just means you don't get the win.

The very fact that anycast works so well means that finding all the AS112
nodes and contacting them, to either delegate new space to them, or remove
existing delegations lead to the omniscient-as112 draft, and
then draft-ietf-dnsop-as112-dname ("AS112 Redirection using DNAME"), which,
IIRC finished IETF LC is waiting for us to incorporate a comment or two.



>  I would like to find some definition of “works” and how we come to that
> conclusion. In my experience there are AS112 nodes out there that are
> misconfigured in many ways (RIPE Atlas be your friend). Returning
> SERVFAILs, wrong data, etc. While wrong data is safeguarded by using DNSSEC
> in this proposal, malfunction is likely to occur still and can be just as
> bad.
>

Well, luckily DNSSEC is ubiquitous at this point...


> In the current system this issue is lessened due to the many different
> operators.
> Within a given enterprise or ISP that would have limited impact and one
> could just point the finger at them and not care (although I don’t agree
> with that either). However route leaks are going to occur as they have in
> the past (no-export stripping happens by accident) and will start to have
> impact on users outside of that admin/routing domain. Assuming that local
> routes are always the routes that are chosen first is a flawed assumption.
> Routing is integral to this proposal and cannot be disregarded if you wanna
> find a workable solution.
>
>  From a TLD operator perspective I think it’s a huge step backwards that
> we will loose our update propagation assurance. Will I have to rely on the
> RRSIG expiry as my worst case scenario for a zone update to be fully
> propagated? With the sort of requirements that are put on TLD operators and
> DNS operators these days that sounds completely unacceptable path to me.
> It’s very different from AS112 where there is are simple zones that are
> configured as master and then remain that way.
>
>  I support the expansion of root server deployments. In my opinion this
> can be fully achieved in the given framework and ICANN as the operator of
> L-root has shown what can be done in a very short period of time. The
> discussion should be about the standards of operation that each root server
> operator is held to these days. There should be no question that some of
> the current root server operators muscle a way more substantial deployment
> than others. If it’s politically too sensitive/hard to establish any level
> of quality with the given root server operators, the addition of other root
> server operators within the current protocol limitations could be used to
> hold them to a certain standard. For the overall system to function well
> this would suffice. This is very similar what was done as part of the new
> gTLD program from ICANN where a whole set of requirements was added that
> didn’t exist before (IPv6, DNSSEC, etc.).
>
>  In closing, this draft proposes a solution to a problem that hasn’t been
> quantified and has no measure of success. Personally I think that’s bad
> practice.
>
>  Regards,
> Wolfgang
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] "Secure Unowned Hierarchical Anycast Root Name Service - And an Apologia" (circleid)

2014-11-14 Thread Mark Andrews


In message <000e7a4f-6391-4842-b2ed-2a28b8d3e...@virtualized.org>, David Conrad 
writes:
>
> Mark,
>
> On Nov 14, 2014, at 11:19 AM, Mark Andrews  wrote:
> >> I believe a better (still not perfect) analogy would be 6to4
> >
> > 6to4 has asymetric routing 99.9% of the time,
>
> 99.9% of all statistics are made up.
>
> > encapsulating IPv4 address mismatch, etc. which are 6to4 specific
> issues.
>
> You apparently missed the "(still not perfect) analogy" bit.
>
> The point was that operationally, anycast can be a PITA to debug and
> unowned anycast increases the magnitude of the PITA.
>
> I'll not comment on the split root zone aspects until I see the revised
> draft.
>
> Regards,
> -drc

6to4 has the listed issues independent of whether you use the anycast
to get to the decapsulation router or not.  Using 6to4 as a reason
for not doing anycast is like comparing apples to cars.  They have
nothing to so with each other.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] "Secure Unowned Hierarchical Anycast Root Name Service - And an Apologia" (circleid)

2014-11-14 Thread Wolfgang Nagele (AusRegistry)

One of my biggest concerns about the current proposal is that it seems to
suggest that AS112 works.
actually, the proposal doesn't mention AS112, but my discussion of the proposal
here has mentioned AS112.
Correct.

I would like to find some definition of “works” and how we come to that
conclusion. In my experience there are AS112 nodes out there that are
misconfigured in many ways (RIPE Atlas be your friend). Returning SERVFAILs,
wrong data, etc. While wrong data is safeguarded by using DNSSEC in this
proposal, malfunction is likely to occur still and can be just as bad.
because AS112 only serves in-addr for non-routable address space (as described
in RFC 1918), its failures are mostly benign -- it's rare to find someone who
cares that the PTR for 10.0.0.73 has some particular value. in that way AS112
is a terrible canary for the scalingroot-XX coal mine, because data failures in
the root zone are extremely noticeable and important. in other words the only
reason we run AS112 at all is to keep the queries out of more important servers
(like the root servers or the in-addr.arpa servers), whereas we have a broader
and more powerful motive to run root servers.

for that same reason, i'm not very worried. failures in AS112 servers go mostly
unnoticed and as a result they might not be fixed quickly or ever. failures in
root name service are extremely visible and will be noticed and fixed pretty
quickly. so, in a way, AS112's weakness is scalingroot-00's strength.
Agree on the technical nature of AS112 and that it goes largely unnoticed.
That’s why I don’t like the notion of drawing conclusions that scalingroot-XX
might work based on AS112 experience. It’s flawed.

In the current system this issue is lessened due to the many different
operators.
i think you mean that the issue is lessened due to the small number of well
known highly visible operators, since in scalingroot-XX, there would be
millions of operators rather than a dozen or so operators.
No, in case that K-root (sorry guys ;)) has a failure it is less likely that
L-root has one as well. In the case of scalingroot-XX propagated failures due
to a single operator are higher.

Within a given enterprise or ISP that would have limited impact and one could
just point the finger at them and not care (although I don’t agree with that
either). However route leaks are going to occur as they have in the past
(no-export stripping happens by accident) and will start to have impact on
users outside of that admin/routing domain.
route leaks also occur for the existing root name server anycast nodes. we're
not inventing new trouble here.
Now at least I know who to contact. See the issues with the root instances in
Beijing and how quickly the could be resolved once noticed.

Assuming that local routes are always the routes that are chosen first is a
flawed assumption. Routing is integral to this proposal and cannot be
disregarded if you wanna find a workable solution.
as i tried to explain in the circleid post last week...

http://www.circleid.com/posts/20141107_secure_unowned_hierarchical_anycast_root_name_service_and_apologia/

...the routing issues are integral to the proposal (as you say) and are in no
way disregarded (as you ask).
Good. Thanks.

From a TLD operator perspective I think it’s a huge step backwards that we will
loose our update propagation assurance. Will I have to rely on the RRSIG expiry
as my worst case scenario for a zone update to be fully propagated? With the
sort of requirements that are put on TLD operators and DNS operators these days
that sounds completely unacceptable path to me. It’s very different from AS112
where there is are simple zones that are configured as master and then remain
that way.
my primary reason for answering this message on-list rather than privately is
to ask you whether your stated concern also applies to
draft-wkumari-dnsop-root-loopback? (it would seem so, in which case, that part
of this thread should continue here, even while the parts related narrowly to
scalingroot-XX should be paused for now.)
Yes it applies the same way to Warren’s draft.

In closing, this draft proposes a solution to a problem that hasn’t been
quantified and has no measure of success. Personally I think that’s bad
practice.
i hope you'll make time to come to hong kong on december 8-9 to inform the
discussion with your perspective.
I would be happy to help with work to quantify the problem. As said, I think
there are more ways to go about this and it seems that the “I want my own root
server” is taking centre stage without there necessarily being a need for that.

mine is: several of us have, and many of us could, construct a simple, cheap,
effective method to ddos all 300+ root name servers, untraceably and
unstoppably. please do the thought experiment. we can repeat it as a group "bar
bof" thought experiment in hong kong if you wish. but in any case i'm going to
make that harder; while no se

38 matches

Mail list logo