RPKI for dummies

Sun Aug 23 12:56:00 UTC 2020

To John and the others that have responded thanks for all the explanations.
It makes things a lot clearer now.

On Thu, Aug 20, 2020 at 10:15 AM John Kristoff <jtk at depaul.edu> wrote:

> On Thu, 20 Aug 2020 13:20:53 +0000
> Dovid Bender <dovid at telecurve.com> wrote:
>
> > How do ISP's that receive my advertisement (either directly from me,
> > meaning my upstreams or my upstreams upstream) verify against the
> > cert that the advertisement is coming from me?
>
> Nothing about your BGP announcements needs to change.  Through ARIN you
> create one or more route origin authorizations (ROAs) with your public
> key.  ARIN can even do all the work of creating the key pair for you if
> you like.  You might try creating test ROAs in their operational test
> and evaluation environment (OTE) environment to see how this process of
> creating a ROA works.
>
> ISPs obtain these ROAs apart and separately from the BGP  system.  ISPs
> that fetch your ROA(s) and other RPKI objects through the RPKI
> ecosystem, perform validation, and communicate AS origin and prefix
> information contained in these ROAs to BGP routers.  At that point
> this information is used to inform the route decision process,
> comparing received routes with processed ROAs as part of a route
> import policy.
>
> > If say we have Medium ISP (AS1000) -> Large ISP (AS200) in the above
> > case AS200 know it's peering with AS1000 so it will take all
> > advertisements. What's stopping AS1000 from adding a router to their
> > network to impersonate me,  make it look like I am peering with them
> > and then they re-advertise the path to Large ISP?
>
> In a nutshell, today, ISPs will only be able to validate the prefix and
> origin AS you publish in the ROA, this is known as route origin
> validation (ROV).  Today someone could advertise your prefix and
> post-pend your AS to appear as the origin.
>
> People are working madly on solutions to protecting other parts of the
> BGP route attributes the origin AS, but nothing is currently, widely
> deployed to provide that protection with the RPKI today.
>
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200823/ff06b57a/attachment.html>