[152417] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: rpki vs. secure dns?

daemon@ATHENA.MIT.EDU (Stephane Bortzmeyer)
Sat Apr 28 09:23:57 2012

Date: Sat, 28 Apr 2012 15:18:55 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Saku Ytti <saku@ytti.fi>
In-Reply-To: <17627_1335611056_4F9BCEB0_17627_2219_1_20120428101710.GA26852@pob.ytti.fi>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

On Sat, Apr 28, 2012 at 01:17:10PM +0300,
 Saku Ytti <saku@ytti.fi> wrote 
 a message of 27 lines which said:

> I think ROVER is better solution, doesn't need any changes to BGP
> just little software magic when accepting routes.

I like Rover but RPKI+ROA does not change BGP either (it will be a
different story with BGPsec).

> People might scared to rely on DNS on accepting routes, but is this
> really an issue?

RPKI+ROA depends on DNS too, since rsync://rpki.ripe.net/repository
will work only if DNS works. Not a problem in practice, since route
origins do not change every minute and the validating ROA cache can
work even if it can no longer update its data. Same thing with Rover:
temporary glitches in the DNS are not a practical problem (the router
keeps the old info).

> routes which fail authorization are logged but accepted if there
> wasn't pre-existing covering route. Only drop routes if they fail
> authorization _AND_ there is pre-existing covering route.

It is a bit more complicated: more-specific attacks, and so on. But,
yes, you're right. As Alex Band says, Rover, RPKI and the IRR make
(authenticated) statements about route origins. You then do what you
want (what your boss wants? what the FBI wants?) with these statements
(route-map, etc).




home help back first fref pref prev next nref lref last post