rpki vs. secure dns?

Mon Apr 30 13:41:51 UTC 2012

> free dinner at nanog/van for anyone who can explain how the dnssec
> approach meets the defcon attack.  hint: it is a path attack, not an
> origin attack, and the dns pidgeon has no hooks to path attack
> prevention.  at ripe, joe gersh asked me for an example of a path attack
> and i told him of the defcon demo.  seems he also did not bother to do
> his homework.  but it makes good pr.
....
> you are right, you have not done your homework.  rpki-based origin
> validation asks no changes to bgp.

Free dinner to anyone who can explain how the RPKI piece of the SIDR
work resolves path attacks. You're comparing apples to oranges here.
Neither a DNS based solution nor the RPKI will resolve path attacks, so
neither apply to the type of attack you're talking about.

There are solutions for this sort of attack. Everything from completely
loose, community based solutions to totally control freak horrible
solutions, like BGP-SEC (and which doesn't really solve the problem anyway).

> yes.  rpki can also have that issue as the certs can have urls that use
> domain names.  i believe they could use ip address urls instead.  but
> the gathering operation differs greatly between the rpki and the dnssec
> based proposal.  with the latter, you can't even tell you have the full
> set.

The problem at hand is relying on routing to build the routing system.
How does using an IP address rather than a DNS based hostname change the
need for routing to work before routing can work?

Reality check: I don't know that this is all that important, in the end.
So long as you can use an IGP locally with a default route to reach a
copy of the database, whether it be based on DNS, an RPKI, or anything
else, then you can bootstrap your EGP routing. If everything goes down
at the same time, then you would just start rebuilding from the places
where the root servers live, no matter what system's root servers we're
talking about.

So I think this is a bit of a red herring at the EGP level.

> i do not like it either.  but it is a trade you make for security.  and,
> at ripe ljubljana, i think alex started to discuss some schemes to
> ameliorate it.  more later on this.

The problem is worse than your initial estimate. A day's worth of
downtime can cost you your business in total, not just some lost revenue.

No matter whether or not you agree with the article's premise, at least
some provider folks are starting to ask some hard questions --which is a
good thing! Let's not shut the conversation down by making broad
proclamations about how the problem has been solved, "move along,
nothing to see here," etc. There is something to see here, so slow down
and take a look. Rubbernecking, in this case, is encouraged.

Russ

-- 
<>< Scripture Alone, Grace Alone, Faith Alone
http://thinkinginchrist.com/