Re: RPKI for dummies

[Randy Bush]

> Some might suggest that a lot of time was spent debating how to do it
> with little actual progress or experimentation done.

this is the internet.  some have suggested pretty much anything.

for the historians in the audience, the first s-bgp, what we would now
call testathon i guess, was held at u oregon, on the side of the eugene
nanog in either 1999 or 2000.  a few large isps, bbn folk, ...  this was
where ops met crypto theorists and started s-bgp's evolution into the
separate threads of rpki, rov, and bgpsec.  

randy

Re: RPKI for dummies

[Rayhaan Jaufeerally (NANOG)]

[sorry if you're getting this twice, I accidentally sent from the wrong
address and it was rejected from the list]
Hi Dovid,

BGPSEC (as specified in RFC8205 ) is
the next level of routing security which provides the kind of in-band
guarantees that you describe. In my view, RPKI with its ROAs is a stepping
stone to get to an end state where BGPSEC can be deployed and routes
validated end-to-end in the BGP control plane itself. Specifically, RPKI
gets the roots of trust out there, and in use, and these can then be used
in the future to bootstrap the BGPSEC ecosystem (RFC 8209
 proposes a certificate profile for
BGPSEC based on the RPKI)

>From what I have seen, there are some roadblocks to widespread adoption of
BGPSEC, notably:

   - I'm not aware of any ready to use out of the box implementations of
   RFC8205 on off the shelf routers from major vendors,
  - There is a patch to BIRD
(site
  appears down ATM, but referenced from:
  https://bird.network.cz/pipermail/bird-users/2015-August/009877.html)
  and a variant of Quagga
  

which
  supports BGPSEC, though.
   - There will be increased memory and CPU requirements for routers
   performing these validations in the control plane

I think the offloading approach we've seen with RPKI validators running on
another host would be an interesting one to consider as it could relieve
the need for routers themselves to be upgraded with more performant
hardware to perform the required signature verifications etc.

I found this presentation

to
be very informative about BGPSEC's guarantees and failure modes, it's a few
years old but still provides a nice overview.

Hope that helps,
Rayhaan

Disclaimer: any and all views expressed here are those of myself in a
personal capacity, and not necessarily those of my employer.


On Sun, Aug 23, 2020 at 2:43 PM Dovid Bender  wrote:

> Ok. So here is another n00b question. Why don't we have something where
> when we advertise IP space we also pass along a cert that can
> independently be verified by going back to the RIR to see if that cert was
> signed by them. This would also stop someone spoofing my ASN.
>
>
> On Thu, Aug 20, 2020 at 10:53 AM Tom Beecher  wrote:
>
>> ROA = Route Origin Authorization . Origin is the key word.
>>
>> When you create an signed ROA and do all the publishing bits, RPKI
>> validator software will retrieve that , validate the signature, and pass
>> that up to routers, saying "This prefix range that originates from this ASN
>> is valid." Then, any BGP advertisement that contains a prefix in that
>> range, with an origin ASN that matches, is treated as valid. The
>> intermediary as-path isn't a factor.
>>
>> If another ASN ORIGINATES an announcement for your space, then RPKI
>> routers will treat that announcement as INVALID, because that isn't
>> authorized.
>>
>> If another ASN spoofs your ASN , pretending that they are your upstream,
>> RPKI won't solve that. But that is a different problem set.
>>
>> On Thu, Aug 20, 2020 at 10:02 AM Dovid Bender 
>> wrote:
>>
>>> Fabien,
>>>
>>> Thanks. So to sum it up there is nothing stopping a bad actor from
>>> impersonating me as if I am BGP'ing with them. It's to stop any other AS
>>> other then mine from advertising my IP space. Is that correct? How is
>>> verification done? They connect to the RIR and verify that there is  a cert
>>> signed by the RIR for my range?
>>>
>>>
>>>
>>> On Thu, Aug 20, 2020 at 9:51 AM Fabien VINCENT (NaNOG) via NANOG <
>>> nanog@nanog.org> wrote:
>>>
 Hi,

 In fact, RPKI does nothing about AS Path checks if it's your question.
 RPKI is based on ROA where signatures are published to guarantee you're the
 owner of a specific prefix with optionnal different maxLength from your
 ASN.

 So if the question is about if RPKI is sufficient to secure the whole
 BGP path, well, it's not. RPKI guarantee / permit only to verify the
 ressource announcements (IPvX block) is really owned by your ASN. But even
 if it's not sufficient, we need to deploy it to start securing resources',
 not the whole path.

 Don't know if it replies to your question, but you can read also the
 pretty good documentation on RPKI here :
 https://rpki.readthedocs.io/en/latest/rpki/introduction.html or the
 corresponding RFC ;)

 Le 20-08-2020 15:20, Dovid Bender a écrit :

 Hi,

 I am sorry for the n00b question. Can someone help point me in the
 right direction to understand how RPKI works? I understand that from my
 side that I create a key, submit the public portion to ARIN and then send a
 signed 

Re: RPKI for dummies

[Robert Raszuk]

Sure thing :)

Btw my point was to avoid the potential impression that origin validation
brings any real security to bgp.

Cheers,
R.


On Mon, Aug 24, 2020 at 3:12 PM John Kristoff  wrote:

> On Mon, 24 Aug 2020 13:01:15 +
> Robert Raszuk  wrote:
>
> > I would not say that either S-BGP nor so-BGP were precursors to BGP
> > origin validation ( I am assuming this is what you are referring to
> > as "system we have today").
>
> I would consider origin validation as just one application of the
> system we have today.  Does that sound better?
>
> John
>

Re: RPKI for dummies

[John Kristoff]

On Mon, 24 Aug 2020 13:01:15 +
Robert Raszuk  wrote:

> I would not say that either S-BGP nor so-BGP were precursors to BGP
> origin validation ( I am assuming this is what you are referring to
> as "system we have today").

I would consider origin validation as just one application of the
system we have today.  Does that sound better?

John

Re: RPKI for dummies

[Robert Raszuk]

John,

> Two precursors to the system we have today.

I would not say that either S-BGP nor so-BGP were precursors to BGP origin
validation ( I am assuming this is what you are referring to as "system we
have today").

If I recall, securing BGP and validating src ASN were independent projects
both aiming at completely different goals. Former was to assure no one
could hijack your prefixes along the path and latter to detect someone fat
fingering your prefix or ASN.

Thx,
R.



On Mon, Aug 24, 2020 at 2:43 PM John Kristoff  wrote:

> On Sun, 23 Aug 2020 12:40:19 +
> Dovid Bender  wrote:
>
> > Ok. So here is another n00b question. Why don't we have something
> > where when we advertise IP space we also pass along a cert [...]
>
> Take a look at:
>
>   Stephen Kent, Charles Lynn, and Karen Seo. 2000. Secure border gateway
>   protocol (S-BGP). IEEE Journal on Selected areas in Communications 18, 4
> (2000),
>   582–592.
>
> and
>
>   Russ White. 2003. Securing BGP: soBGP. Internet Protocol Journal 6, 3
>   (Sept. 2003), 15–22.
>
> Two precursors to the system we have today.  Both proposed some form of
> including PKI-related matter in BGP messages.  Neither system gained
> much actual traction outside of the design phase as far as I know.
> Some might suggest that a lot of time was spent debating how to do it
> with little actual progress or experimentation done.  The current
> approach has echoes of those ideas with the obvious difference as you
> imply, it is independent from BGP.  This poses some challenges to
> providing a complete solution, but was probably necessary for deployment
> and might prove useful if something other than wants to BGP uses it.
>
> John
>

Re: RPKI for dummies

[John Kristoff]

On Sun, 23 Aug 2020 12:40:19 +
Dovid Bender  wrote:

> Ok. So here is another n00b question. Why don't we have something
> where when we advertise IP space we also pass along a cert [...]

Take a look at:

  Stephen Kent, Charles Lynn, and Karen Seo. 2000. Secure border gateway
  protocol (S-BGP). IEEE Journal on Selected areas in Communications 18, 4 
(2000),
  582–592.

and

  Russ White. 2003. Securing BGP: soBGP. Internet Protocol Journal 6, 3
  (Sept. 2003), 15–22.

Two precursors to the system we have today.  Both proposed some form of
including PKI-related matter in BGP messages.  Neither system gained
much actual traction outside of the design phase as far as I know.
Some might suggest that a lot of time was spent debating how to do it
with little actual progress or experimentation done.  The current
approach has echoes of those ideas with the obvious difference as you
imply, it is independent from BGP.  This poses some challenges to
providing a complete solution, but was probably necessary for deployment
and might prove useful if something other than wants to BGP uses it.

John

Re: RPKI for dummies

[Randy Bush]

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

ripe/ncc and isoc/manrs have some gl!tzich webinarz etc on all this

randy

Re: RPKI for dummies

[Dovid Bender]

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  wrote:

> On Thu, 20 Aug 2020 13:20:53 +
> Dovid Bender  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
>

Re: RPKI for dummies

[Dovid Bender]

Ok. So here is another n00b question. Why don't we have something where
when we advertise IP space we also pass along a cert that can
independently be verified by going back to the RIR to see if that cert was
signed by them. This would also stop someone spoofing my ASN.


On Thu, Aug 20, 2020 at 10:53 AM Tom Beecher  wrote:

> ROA = Route Origin Authorization . Origin is the key word.
>
> When you create an signed ROA and do all the publishing bits, RPKI
> validator software will retrieve that , validate the signature, and pass
> that up to routers, saying "This prefix range that originates from this ASN
> is valid." Then, any BGP advertisement that contains a prefix in that
> range, with an origin ASN that matches, is treated as valid. The
> intermediary as-path isn't a factor.
>
> If another ASN ORIGINATES an announcement for your space, then RPKI
> routers will treat that announcement as INVALID, because that isn't
> authorized.
>
> If another ASN spoofs your ASN , pretending that they are your upstream,
> RPKI won't solve that. But that is a different problem set.
>
> On Thu, Aug 20, 2020 at 10:02 AM Dovid Bender  wrote:
>
>> Fabien,
>>
>> Thanks. So to sum it up there is nothing stopping a bad actor from
>> impersonating me as if I am BGP'ing with them. It's to stop any other AS
>> other then mine from advertising my IP space. Is that correct? How is
>> verification done? They connect to the RIR and verify that there is  a cert
>> signed by the RIR for my range?
>>
>>
>>
>> On Thu, Aug 20, 2020 at 9:51 AM Fabien VINCENT (NaNOG) via NANOG <
>> nanog@nanog.org> wrote:
>>
>>> Hi,
>>>
>>> In fact, RPKI does nothing about AS Path checks if it's your question.
>>> RPKI is based on ROA where signatures are published to guarantee you're the
>>> owner of a specific prefix with optionnal different maxLength from your
>>> ASN.
>>>
>>> So if the question is about if RPKI is sufficient to secure the whole
>>> BGP path, well, it's not. RPKI guarantee / permit only to verify the
>>> ressource announcements (IPvX block) is really owned by your ASN. But even
>>> if it's not sufficient, we need to deploy it to start securing resources',
>>> not the whole path.
>>>
>>> Don't know if it replies to your question, but you can read also the
>>> pretty good documentation on RPKI here :
>>> https://rpki.readthedocs.io/en/latest/rpki/introduction.html or the
>>> corresponding RFC ;)
>>>
>>> Le 20-08-2020 15:20, Dovid Bender a écrit :
>>>
>>> Hi,
>>>
>>> I am sorry for the n00b question. Can someone help point me in the right
>>> direction to understand how RPKI works? I understand that from my side that
>>> I create a key, submit the public portion to ARIN and then send a signed
>>> request to ARIN asking them to publish it. 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? 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?
>>>
>>> Again sorry for the n00b question, I am trying to make sense of how it
>>> works.
>>>
>>> TIA.
>>>
>>> Dovid
>>>
>>>
>>> --
>>> *Fabien VINCENT*
>>> *@beufanet*
>>>
>>

Re: RPKI for dummies

[Tom Beecher]

ROA = Route Origin Authorization . Origin is the key word.

When you create an signed ROA and do all the publishing bits, RPKI
validator software will retrieve that , validate the signature, and pass
that up to routers, saying "This prefix range that originates from this ASN
is valid." Then, any BGP advertisement that contains a prefix in that
range, with an origin ASN that matches, is treated as valid. The
intermediary as-path isn't a factor.

If another ASN ORIGINATES an announcement for your space, then RPKI routers
will treat that announcement as INVALID, because that isn't authorized.

If another ASN spoofs your ASN , pretending that they are your upstream,
RPKI won't solve that. But that is a different problem set.

On Thu, Aug 20, 2020 at 10:02 AM Dovid Bender  wrote:

> Fabien,
>
> Thanks. So to sum it up there is nothing stopping a bad actor from
> impersonating me as if I am BGP'ing with them. It's to stop any other AS
> other then mine from advertising my IP space. Is that correct? How is
> verification done? They connect to the RIR and verify that there is  a cert
> signed by the RIR for my range?
>
>
>
> On Thu, Aug 20, 2020 at 9:51 AM Fabien VINCENT (NaNOG) via NANOG <
> nanog@nanog.org> wrote:
>
>> Hi,
>>
>> In fact, RPKI does nothing about AS Path checks if it's your question.
>> RPKI is based on ROA where signatures are published to guarantee you're the
>> owner of a specific prefix with optionnal different maxLength from your
>> ASN.
>>
>> So if the question is about if RPKI is sufficient to secure the whole BGP
>> path, well, it's not. RPKI guarantee / permit only to verify the ressource
>> announcements (IPvX block) is really owned by your ASN. But even if it's
>> not sufficient, we need to deploy it to start securing resources', not the
>> whole path.
>>
>> Don't know if it replies to your question, but you can read also the
>> pretty good documentation on RPKI here :
>> https://rpki.readthedocs.io/en/latest/rpki/introduction.html or the
>> corresponding RFC ;)
>>
>> Le 20-08-2020 15:20, Dovid Bender a écrit :
>>
>> Hi,
>>
>> I am sorry for the n00b question. Can someone help point me in the right
>> direction to understand how RPKI works? I understand that from my side that
>> I create a key, submit the public portion to ARIN and then send a signed
>> request to ARIN asking them to publish it. 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? 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?
>>
>> Again sorry for the n00b question, I am trying to make sense of how it
>> works.
>>
>> TIA.
>>
>> Dovid
>>
>>
>> --
>> *Fabien VINCENT*
>> *@beufanet*
>>
>

Re: RPKI for dummies

[John Kristoff]

On Thu, 20 Aug 2020 13:20:53 +
Dovid Bender  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

Re: RPKI for dummies

[Fabien VINCENT (NaNOG) via NANOG]

If the other AS announce the same resource, AS Path Length should be 
perhaps longer will prefix length is the same.


RPKI is just here to secure resource announcement verification (ROV). 
Nothing more in my own opinion. You could read this RFC for RPKI OPs : 
https://tools.ietf.org/html/rfc7115.html


Verification is done using tools like Routinator or GoRTR, that fetch 
Trusted Anchors Lists provided by RIR, compute them and provide RTR 
protocol support for your routers to verify against ROA the BGP table 
(what we called ROV).


Everything is in the excellent RPKI documentation, so you should 
absolutely read it or look any presentation done on RIRs' meeting, 
probably available on YouTube ;)


Le 20-08-2020 16:00, Dovid Bender a écrit :


Fabien,

Thanks. So to sum it up there is nothing stopping a bad actor from 
impersonating me as if I am BGP'ing with them. It's to stop any other 
AS other then mine from advertising my IP space. Is that correct? How 
is verification done? They connect to the RIR and verify that there is  
a cert signed by the RIR for my range?


On Thu, Aug 20, 2020 at 9:51 AM Fabien VINCENT (NaNOG) via NANOG 
 wrote:


Hi,

In fact, RPKI does nothing about AS Path checks if it's your question. 
RPKI is based on ROA where signatures are published to guarantee you're 
the owner of a specific prefix with optionnal different maxLength from 
your ASN.


So if the question is about if RPKI is sufficient to secure the whole 
BGP path, well, it's not. RPKI guarantee / permit only to verify the 
ressource announcements (IPvX block) is really owned by your ASN. But 
even if it's not sufficient, we need to deploy it to start securing 
resources', not the whole path.


Don't know if it replies to your question, but you can read also the 
pretty good documentation on RPKI here : 
https://rpki.readthedocs.io/en/latest/rpki/introduction.html or the 
corresponding RFC ;)


Le 20-08-2020 15:20, Dovid Bender a écrit :

Hi,

I am sorry for the n00b question. Can someone help point me in the 
right direction to understand how RPKI works? I understand that from my 
side that I create a key, submit the public portion to ARIN and then 
send a signed request to ARIN asking them to publish it. 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? 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?


Again sorry for the n00b question, I am trying to make sense of how it 
works.


TIA.

Dovid

--
Fabien VINCENT
_@beufanet_


--
Fabien VINCENT
_@beufanet_

Re: RPKI for dummies

[Eric Dugas via NANOG]

Here's some more literature: 
https://blog.cloudflare.com/rpki-and-the-rtr-protocol/

Eric
On Aug 20 2020, at 10:00 am, Dovid Bender  wrote:
> Fabien,
>
> Thanks. So to sum it up there is nothing stopping a bad actor from 
> impersonating me as if I am BGP'ing with them. It's to stop any other AS 
> other then mine from advertising my IP space. Is that correct? How is 
> verification done? They connect to the RIR and verify that there is a cert 
> signed by the RIR for my range?
>
>
>
> On Thu, Aug 20, 2020 at 9:51 AM Fabien VINCENT (NaNOG) via NANOG 
> mailto:nanog@nanog.org)> wrote:
> > Hi,
> >
> > In fact, RPKI does nothing about AS Path checks if it's your question. RPKI 
> > is based on ROA where signatures are published to guarantee you're the 
> > owner of a specific prefix with optionnal different maxLength from your ASN.
> > So if the question is about if RPKI is sufficient to secure the whole BGP 
> > path, well, it's not. RPKI guarantee / permit only to verify the ressource 
> > announcements (IPvX block) is really owned by your ASN. But even if it's 
> > not sufficient, we need to deploy it to start securing resources', not the 
> > whole path.
> > Don't know if it replies to your question, but you can read also the pretty 
> > good documentation on RPKI here : 
> > https://rpki.readthedocs.io/en/latest/rpki/introduction.html or the 
> > corresponding RFC ;)
> > Le 20-08-2020 15:20, Dovid Bender a écrit :
> > > Hi,
> > >
> > > I am sorry for the n00b question. Can someone help point me in the right 
> > > direction to understand how RPKI works? I understand that from my side 
> > > that I create a key, submit the public portion to ARIN and then send a 
> > > signed request to ARIN asking them to publish it. 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? 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?
> > >
> > > Again sorry for the n00b question, I am trying to make sense of how it 
> > > works.
> > >
> > > TIA.
> > >
> > > Dovid
> > >
> > >
> > >
> >
> > --
> > Fabien VINCENT
> > @beufanet
> >
> >
>
>

Re: RPKI for dummies

[Dovid Bender]

Fabien,

Thanks. So to sum it up there is nothing stopping a bad actor from
impersonating me as if I am BGP'ing with them. It's to stop any other AS
other then mine from advertising my IP space. Is that correct? How is
verification done? They connect to the RIR and verify that there is  a cert
signed by the RIR for my range?



On Thu, Aug 20, 2020 at 9:51 AM Fabien VINCENT (NaNOG) via NANOG <
nanog@nanog.org> wrote:

> Hi,
>
> In fact, RPKI does nothing about AS Path checks if it's your question.
> RPKI is based on ROA where signatures are published to guarantee you're the
> owner of a specific prefix with optionnal different maxLength from your
> ASN.
>
> So if the question is about if RPKI is sufficient to secure the whole BGP
> path, well, it's not. RPKI guarantee / permit only to verify the ressource
> announcements (IPvX block) is really owned by your ASN. But even if it's
> not sufficient, we need to deploy it to start securing resources', not the
> whole path.
>
> Don't know if it replies to your question, but you can read also the
> pretty good documentation on RPKI here :
> https://rpki.readthedocs.io/en/latest/rpki/introduction.html or the
> corresponding RFC ;)
>
> Le 20-08-2020 15:20, Dovid Bender a écrit :
>
> Hi,
>
> I am sorry for the n00b question. Can someone help point me in the right
> direction to understand how RPKI works? I understand that from my side that
> I create a key, submit the public portion to ARIN and then send a signed
> request to ARIN asking them to publish it. 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? 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?
>
> Again sorry for the n00b question, I am trying to make sense of how it
> works.
>
> TIA.
>
> Dovid
>
>
> --
> *Fabien VINCENT*
> *@beufanet*
>

Re: RPKI for dummies

[Fabien VINCENT (NaNOG) via NANOG]

Hi,

In fact, RPKI does nothing about AS Path checks if it's your question. 
RPKI is based on ROA where signatures are published to guarantee you're 
the owner of a specific prefix with optionnal different maxLength from 
your ASN.


So if the question is about if RPKI is sufficient to secure the whole 
BGP path, well, it's not. RPKI guarantee / permit only to verify the 
ressource announcements (IPvX block) is really owned by your ASN. But 
even if it's not sufficient, we need to deploy it to start securing 
resources', not the whole path.


Don't know if it replies to your question, but you can read also the 
pretty good documentation on RPKI here : 
https://rpki.readthedocs.io/en/latest/rpki/introduction.html or the 
corresponding RFC ;)


Le 20-08-2020 15:20, Dovid Bender a écrit :


Hi,

I am sorry for the n00b question. Can someone help point me in the 
right direction to understand how RPKI works? I understand that from my 
side that I create a key, submit the public portion to ARIN and then 
send a signed request to ARIN asking them to publish it. 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? 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?


Again sorry for the n00b question, I am trying to make sense of how it 
works.


TIA.

Dovid


--
Fabien VINCENT
_@beufanet_

RPKI for dummies

[Dovid Bender]

Hi,

I am sorry for the n00b question. Can someone help point me in the right
direction to understand how RPKI works? I understand that from my side that
I create a key, submit the public portion to ARIN and then send a signed
request to ARIN asking them to publish it. 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? 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?

Again sorry for the n00b question, I am trying to make sense of how it
works.

TIA.

Dovid