"Is BGP safe yet?" test
Hi Nanog list, Would be interesting to hear your opinion on this: https://isbgpsafeyet.com/ We have cases when residential customers ask support "why is your service isn't safe?" pointing to that article. It's difficult to answer correctly considering that the asking person usually doesn't know what BGP is and what it's used for, save for understanding it's function, design and possible misuses. IMO, on one hand it promotes and is aimed to push RPKI deployment, on the other hand is this a proper way for it? How ethical is to claim other market players unsafe, considering that scope of possible impact of not implementing it has completely different scale for a small stub network and big transit provider? Kind regards, Andrey
On 20/Apr/20 17:08, Andrey Kostin wrote:
Hi Nanog list,
Would be interesting to hear your opinion on this: https://isbgpsafeyet.com/
From a practical standpoint, this doesn't actually tell the whole truth in our case because we do not accept the ARIN TAL. Given that this system is "ARIN-based", it says we aren't safe. Swiftly moving on...
We have cases when residential customers ask support "why is your service isn't safe?" pointing to that article. It's difficult to answer correctly considering that the asking person usually doesn't know what BGP is and what it's used for, save for understanding it's function, design and possible misuses. IMO, on one hand it promotes and is aimed to push RPKI deployment, on the other hand is this a proper way for it? How ethical is to claim other market players unsafe, considering that scope of possible impact of not implementing it has completely different scale for a small stub network and big transit provider?
On count two, my experience with doing the RPKI deployathon in Melbourne during this past APRICOT led to some random news web site talking about how "I would be shedding all invalid routes blah blah", which while not untrue, had locals all the way in South Africa asking if the Internet was going to collapse. So while I think these initiatives are useful, considering that information has been democratized to such an extent that it is now a commodity, we might do well to consider the fallout for folk that do not know (or care) about how the Internet works, but know that their lives depend on it, and what that means for our individual SNR's. Mark.
On 20/Apr/20 17:31, Mark Tinka wrote:
On count two, my experience with doing the RPKI deployathon in Melbourne during this past APRICOT led to some random news web site talking about how "I would be shedding all invalid routes blah blah", which while not untrue, had locals all the way in South Africa asking if the Internet was going to collapse.
https://thenewsheadline.com/telstra-to-roll-out-rpki-routing-security-from-j... Mark.
From a practical standpoint, this doesn't actually tell the whole truth
indeed. route origin validation, while a good thing, does not make bgp safe from attack. this marketing fantasy is being propagated; but is BS. origin validation was designed to reduce the massive number of problems cause by fat figured configuration errors by operators. it will not even get all of those; but it will greatly improve things. but it provides almost zero protection against malicious attack. the attacker merely has to prepend (in the formal, not cisco display) the 'correct' origin AS to their malicious announcement. randy
Randy said,
From a practical standpoint, this doesn't actually tell the whole truth
indeed. route origin validation, while a good thing, does not make bgp safe from attack. this marketing fantasy is being propagated; but is BS.
origin validation was designed to reduce the massive number of problems cause by fat figured configuration errors by operators. it will not even get all of those; but it will greatly improve things.
but it provides almost zero protection against malicious attack. the attacker merely has to prepend (in the formal, not cisco display) the 'correct' origin AS to their malicious announcement.
Randy, I agree of course, that supporting ROV is far from sufficient to ensure BGP security. However, I disagree that this is `zero protection' since the effectiveness of the attack may be much reduced when the attacker has to prepend. Note also that if one combines ASPA, the protection would be even better. The simulation results in our SIGCOMM'2016 give some idea of these benefits (imprecise, of course). I _think_ Randy will agree; but then again, Randy loves to surprise , so ... maybe not. -- Amir Herzberg Comcast professor of Security Innovations, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home Foundations of Cyber-Security (part I: applied crypto, part II: network-security): https://www.researchgate.net/project/Foundations-of-Cyber-Security On Mon, Apr 20, 2020 at 3:10 PM Randy Bush <randy@psg.com> wrote:
From a practical standpoint, this doesn't actually tell the whole truth
indeed. route origin validation, while a good thing, does not make bgp safe from attack. this marketing fantasy is being propagated; but is BS.
origin validation was designed to reduce the massive number of problems cause by fat figured configuration errors by operators. it will not even get all of those; but it will greatly improve things.
but it provides almost zero protection against malicious attack. the attacker merely has to prepend (in the formal, not cisco display) the 'correct' origin AS to their malicious announcement.
randy
On Mon, Apr 20, 2020, at 21:54, Amir Herzberg wrote:
Randy said, > From a practical standpoint, this doesn't actually tell the whole truth
indeed. route origin validation, while a good thing, does not make bgp safe from attack. this marketing fantasy is being propagated; but is BS.
origin validation was designed to reduce the massive number of problems cause by fat figured configuration errors by operators. it will not even get all of those; but it will greatly improve things.
but it provides almost zero protection against malicious attack. the attacker merely has to prepend (in the formal, not cisco display) the 'correct' origin AS to their malicious announcement.
Randy, I agree of course, that supporting ROV is far from sufficient to ensure BGP security. However, I disagree that this is `zero protection' since the effectiveness of the attack may be much reduced when the attacker has to prepend. Note also that if one combines ASPA, the protection would be even better. The simulation results in our SIGCOMM'2016 give some idea of these benefits (imprecise, of course).
Folks, https://gph.is/1iwqrDk ;-) I think you can best capitalise on Origin Validation when OV is combined with other techniques such as AS_PATH filters (based on Peerlock or ASPA) or in some cases direct peering: https://www.slideshare.net/apnic/improving-the-peering-business-case-with-rp... In local scope (IP traffic that will only travel a few milliseconds) I expect to see a substantial increase of robustness as more and more networks deploy OV (and peer directly with networks that matter to them!), however the long paths will remain comparatively more vulnerable. Much like any multi-company logistics system spanning the globe. In the span of just two years we went from "you only need to overcome a single obstacle to insert bad routing information in the system", to a situation where more and more things need to go wrong before rogue announcements are seen universally. This is incredible progress in on a scale most people did not imagine possible. Are we there yet? No, but RPKI OV is a critical prerequisite to further progress.
From the last few days it seems to me we still have work ahead of us: folks need to receive training from their peers so they themselves can make informed decisions about RPKI. We should more openly compare notes about software defects and how to workaround them. We should talk about (privately) how to manoeuvre OV deployment projects along in large corporations, most companies don't have a manual for how to deploy something like RPKI OV :-)
One of the best sources of documentation on RPKI is https://rpki.readthedocs.io/ - the docs are actively maintained to capture all common operational questions that pop-up over time. Kind regards, Job
On Mon, Apr 20, 2020 at 9:09 PM Randy Bush <randy@psg.com> wrote:
but it provides almost zero protection against malicious attack. the attacker merely has to prepend (in the formal, not cisco display) the 'correct' origin AS to their malicious announcement.
Yes but that makes the hijacked AS path length at least 1 longer which makes it less likely that it can win over the true announcement. It is definitely better than nothing. Also AS number filtering might be more prevalent than prefix filtering. If I know which origin ASNs I can accept from a peer and filter on that, then RPKI will prevent them from faking protected prefixes. Regards, Baldur
On Tue, 21 Apr 2020 at 01:02, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
Yes but that makes the hijacked AS path length at least 1 longer which makes it less likely that it can win over the true announcement. It is definitely better than nothing.
Attacker has no incentive to honor existing AS path, attacker can rewrite it as they wish. Anyhow I think some people think about RPKI in a way too binary manner 'because it is not secure, it is not useful'. Yes, AS_PATH authenticity is an open problem, but this doesn't mean RPKI is useless. Most of our BGP outages are not malicious, RPKI helps a lot there and RPKI creates a higher quality database for prefix origin information than what we have had. -- ++ytti
tir. 21. apr. 2020 07.38 skrev Saku Ytti <saku@ytti.fi>:
On Tue, 21 Apr 2020 at 01:02, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
Yes but that makes the hijacked AS path length at least 1 longer which makes it less likely that it can win over the true announcement. It is definitely better than nothing.
Attacker has no incentive to honor existing AS path, attacker can rewrite it as they wish.
My company is in Europe. Lets say an attacker joins the IX in Seattle a long way from here and a place we definitely are not present at. We do however use Hurricane Electric as transit and they are peering freely at Seattle. Everyone there thus sees our prefix with an as path length of two. The attacker can originate the prefixes himself and that way his fake announcements win at Seattle by having the length 1. With RPKI he needs to use our ASN to originate and have his own ASN in between to facilitate peering. Thus the fake path also has the length of two. The real announcement wins by virtue of being the oldest announcement and the attack fails. The situation is even worse for the attacker if he needs an IP transit company to pick up the fake announcement. We have Telia, which filters invalids, and if the attacker tries to get his fake prefix picked up by them, his path will end up being one longer than ours, so he can never succeed. There are of course plenty of situations where the attack still succeeds. I am not claiming this is a magical bullet. Just saying it might do more than some thinks it will. Definitely better than nothing. Regards Baldur
Baldur Norddahl писал 2020-04-21 02:49:
My company is in Europe. Lets say an attacker joins the IX in Seattle a long way from here and a place we definitely are not present at. We do however use Hurricane Electric as transit and they are peering freely at Seattle. Everyone there thus sees our prefix with an as path length of two. The attacker can originate the prefixes himself and that way his fake announcements win at Seattle by having the length 1. With RPKI he needs to use our ASN to originate and have his own ASN in between to facilitate peering. Thus the fake path also has the length of two. The real announcement wins by virtue of being the oldest announcement and the attack fails.
The situation is even worse for the attacker if he needs an IP transit company to pick up the fake announcement. We have Telia, which filters invalids, and if the attacker tries to get his fake prefix picked up by them, his path will end up being one longer than ours, so he can never succeed.
There are of course plenty of situations where the attack still succeeds. I am not claiming this is a magical bullet. Just saying it might do more than some thinks it will. Definitely better than nothing.
I think that for peering sessions regular filters can do their job more directly and effectively. But I see that discussion moved away from initial topic to general dispute about RPKI usefullness. The initial topic though initially was about public web page that claimes your network secure or insecure based on evaluation of only one technology checking one particular specially crafted prefix. Kind regards, Andrey
Anyhow I think some people think about RPKI in a way too binary manner 'because it is not secure, it is not useful'. Yes, AS_PATH authenticity is an open problem, but this doesn't mean RPKI is useless. Most of our BGP outages are not malicious, RPKI helps a lot there and RPKI creates a higher quality database for prefix origin information than what we have had.
essentially agree. my pedantic quibble is that i would like to differentiate between the RPKI, which is a database, and ROV, which uses it. randy
On 21/Apr/20 12:46, Randy Bush wrote:
essentially agree. my pedantic quibble is that i would like to differentiate between the RPKI, which is a database, and ROV, which uses it.
And I think that is a very important distinction to be clear about. Right now, it's not completely arrest-worthy to use RPKI and ROV interchangeably, but I think considering that other use-cases might come from the database itself in the future, being explicit about it and how it can be used is appropriate pedantry. Mark.
essentially agree. my pedantic quibble is that i would like to differentiate between the RPKI, which is a database, and ROV, which uses it.
And I think that is a very important distinction to be clear about. Right now, it's not completely arrest-worthy to use RPKI and ROV interchangeably, but I think considering that other use-cases might come from the database itself in the future, being explicit about it and how it can be used is appropriate pedantry.
i have been pushing this rock uphill for over a decade. to expand, a bit of text from long ago, so hence a bit out of date, but still clear RPKI The RPKI is an X.509 based hierarchy [RFC 6481] which is congruent with the internet IP address allocation administration, the IANA, RIRs, ISPs, ... It is just a database, but is the substrate on which the next two mechanisms are based. It is currently deployed in all five administrative regions. RPKI-based Origin Validation (ROV) RPKI-based Origin Validation [RFC 6811] uses some of the RPKI data to allow a router to verify that the autonomous system originating an IP address prefix is in fact authorized to do so. This is not crypto checked so can be violated. But it should prevent the vast majority of accidental 'hijackings' on the internet today, e.g. the famous Pakistani accidental announcement of YouTube's address space. RPKI-based origin validation is in shipping code from AlcaLu, Cisco, Juniper, and possibly others. BGPsec RPKI-based Path Validation, AKA BGPsec, a future technology still being designed [draft-ietf-sidr-bgpsec-overview], uses the full crypto information of the RPKI to make up for the embarrassing mistake that, like much of the internet BGP was designed with no thought to securing the BGP protocol itself from being gamed/violated. It allows a receiver of a BGP announcement to cryptographically validate that the autonomous systems through which the announcement passed were indeed those which the sender/forwarder at each hop intended. currently, bgosec still has no traction. there are other proposals in the space, e.g. ASPA. but the point is that they USE the rpki, they are not the rpki. randy
( Speaking 100% for myself. ) I think it was tremendously irresponsible, especially in the context of current events, to take a complex technical issue like this and frame it to the general public as a 'safety' issue. It's created articles like this : https://www.wired.com/story/cloudflare-bgp-routing-safe-yet/ , which are terrible because they imply that RPKI is just some simple thing that anyone not doing is just lazy or stupid. Very few people will read to the bottom note about vendors implementing RPKI support, or do any other research on the issue and challenges that some companies face to do it. It's not their job; that's ours. I feel like there has been more momentum in getting more people to implement PKI in the last 18-24 months. ( Maybe others with different visibility have different opinions there. ) There are legitimate technical and business reasons why this isn't just a switch that can be turned on, and everyone in our industry knows that. In my opinion, Mr. Prince is doing a great disservice by taking this approach, and in the longer term RPKI adoption will likely be slower than it would have been otherwise. I genuinely appreciate much of what Cloudflare does for the sake of 'internet good' , but I believe they wildly missed the mark here. On Mon, Apr 20, 2020 at 11:09 AM Andrey Kostin <ankost@podolsk.ru> wrote:
Hi Nanog list,
Would be interesting to hear your opinion on this: https://isbgpsafeyet.com/
We have cases when residential customers ask support "why is your service isn't safe?" pointing to that article. It's difficult to answer correctly considering that the asking person usually doesn't know what BGP is and what it's used for, save for understanding it's function, design and possible misuses. IMO, on one hand it promotes and is aimed to push RPKI deployment, on the other hand is this a proper way for it? How ethical is to claim other market players unsafe, considering that scope of possible impact of not implementing it has completely different scale for a small stub network and big transit provider?
Kind regards, Andrey
Why do you think that RPKI adoption will be slowed due to this action by CloudFlare? — Chris Cummings From: NANOG <nanog-bounces@nanog.org> on behalf of Tom Beecher <beecher@beecher.cc> Date: Monday, April 20, 2020 at 10:35 To: Andrey Kostin <ankost@podolsk.ru> Cc: Nanog <nanog@nanog.org> Subject: Re: "Is BGP safe yet?" test ( Speaking 100% for myself. ) I think it was tremendously irresponsible, especially in the context of current events, to take a complex technical issue like this and frame it to the general public as a 'safety' issue. It's created articles like this : https://www.wired.com/story/cloudflare-bgp-routing-safe-yet/ , which are terrible because they imply that RPKI is just some simple thing that anyone not doing is just lazy or stupid. Very few people will read to the bottom note about vendors implementing RPKI support, or do any other research on the issue and challenges that some companies face to do it. It's not their job; that's ours. I feel like there has been more momentum in getting more people to implement PKI in the last 18-24 months. ( Maybe others with different visibility have different opinions there. ) There are legitimate technical and business reasons why this isn't just a switch that can be turned on, and everyone in our industry knows that. In my opinion, Mr. Prince is doing a great disservice by taking this approach, and in the longer term RPKI adoption will likely be slower than it would have been otherwise. I genuinely appreciate much of what Cloudflare does for the sake of 'internet good' , but I believe they wildly missed the mark here. On Mon, Apr 20, 2020 at 11:09 AM Andrey Kostin <ankost@podolsk.ru<mailto:ankost@podolsk.ru>> wrote: Hi Nanog list, Would be interesting to hear your opinion on this: https://isbgpsafeyet.com/<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fisbgpsafeyet.com%2f&c=E,1,yPfCe3uCN5n20SgR-hbGPgyzXYl7fhPtgS0piraWZK5vfdwL2nMPvg2btKnk02oAsf0IJBBQzRwbwXQEGrrr4gJiesDJCWWswG6KRpMuONuXKHTwRf5I&typo=1> We have cases when residential customers ask support "why is your service isn't safe?" pointing to that article. It's difficult to answer correctly considering that the asking person usually doesn't know what BGP is and what it's used for, save for understanding it's function, design and possible misuses. IMO, on one hand it promotes and is aimed to push RPKI deployment, on the other hand is this a proper way for it? How ethical is to claim other market players unsafe, considering that scope of possible impact of not implementing it has completely different scale for a small stub network and big transit provider? Kind regards, Andrey
Technical people need to make the business case to management for RKPI by laying out what it would cost to implement (equipment, resources, ongoing opex), and what the savings are to the company from protecting themselves against hijacks. By taking this step, I believe RPKI will become viewed by non-technical decision makers as a 'Cloudflare initiative' instead of a 'good of the internet' initiative, especially by some companies who compete with Cloudflare in the CDN space. I believe that will change the calculus and make it a more difficult sell for technical people to get resources approved to make it happen. On Mon, Apr 20, 2020 at 11:38 AM Cummings, Chris <ccummings@coeur.com> wrote:
Why do you think that RPKI adoption will be slowed due to this action by CloudFlare?
—
Chris Cummings
*From: *NANOG <nanog-bounces@nanog.org> on behalf of Tom Beecher <beecher@beecher.cc> *Date: *Monday, April 20, 2020 at 10:35 *To: *Andrey Kostin <ankost@podolsk.ru> *Cc: *Nanog <nanog@nanog.org> *Subject: *Re: "Is BGP safe yet?" test
( Speaking 100% for myself. )
I think it was tremendously irresponsible, especially in the context of current events, to take a complex technical issue like this and frame it to the general public as a 'safety' issue.
It's created articles like this : https://www.wired.com/story/cloudflare-bgp-routing-safe-yet/ , which are terrible because they imply that RPKI is just some simple thing that anyone not doing is just lazy or stupid. Very few people will read to the bottom note about vendors implementing RPKI support, or do any other research on the issue and challenges that some companies face to do it. It's not their job; that's ours.
I feel like there has been more momentum in getting more people to implement PKI in the last 18-24 months. ( Maybe others with different visibility have different opinions there. ) There are legitimate technical and business reasons why this isn't just a switch that can be turned on, and everyone in our industry knows that.
In my opinion, Mr. Prince is doing a great disservice by taking this approach, and in the longer term RPKI adoption will likely be slower than it would have been otherwise. I genuinely appreciate much of what Cloudflare does for the sake of 'internet good' , but I believe they wildly missed the mark here.
On Mon, Apr 20, 2020 at 11:09 AM Andrey Kostin <ankost@podolsk.ru> wrote:
Hi Nanog list,
Would be interesting to hear your opinion on this: https://isbgpsafeyet.com/ <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fisbgpsafeyet.com%2f&c=E,1,yPfCe3uCN5n20SgR-hbGPgyzXYl7fhPtgS0piraWZK5vfdwL2nMPvg2btKnk02oAsf0IJBBQzRwbwXQEGrrr4gJiesDJCWWswG6KRpMuONuXKHTwRf5I&typo=1>
We have cases when residential customers ask support "why is your service isn't safe?" pointing to that article. It's difficult to answer correctly considering that the asking person usually doesn't know what BGP is and what it's used for, save for understanding it's function, design and possible misuses. IMO, on one hand it promotes and is aimed to push RPKI deployment, on the other hand is this a proper way for it? How ethical is to claim other market players unsafe, considering that scope of possible impact of not implementing it has completely different scale for a small stub network and big transit provider?
Kind regards, Andrey
On 20/Apr/20 18:24, Tom Beecher wrote:
Technical people need to make the business case to management for RKPI by laying out what it would cost to implement (equipment, resources, ongoing opex), and what the savings are to the company from protecting themselves against hijacks. By taking this step, I believe RPKI will become viewed by non-technical decision makers as a 'Cloudflare initiative' instead of a 'good of the internet' initiative, especially by some companies who compete with Cloudflare in the CDN space.
I believe that will change the calculus and make it a more difficult sell for technical people to get resources approved to make it happen.
I'm not sure I'd go that far, but I do see your point. Nowadays, if you are running a half-decent router vendor, chances are any upgrades you are doing for normal things (adding capacity, moving from Gig-E to 10Gbps, or from 10Gbps to 100Gbps) will bring RPKI along for the ride by default. We've seen that validators are free, and work very well. Your ongoing RIR membership will get your access to getting your ROA's signed, so you don't need to pay extra for that. So while I can see how an article like this could make life interesting within your business, I don't think much of it will hinge on "the cost of implementing RPKI in terms of $$". My company, for example, only found out we run RPKI because of the April 1, 2019 activation article that we, and Workonline published. And we'd been testing and running RPKI since 2014 - and only because we had a total network refresh to get rid of some clunky Cisco XR 12000 routers (which probably support RPKI if you don't run IOS classic, hehe). Mark.
We've seen that validators are free, and work very well.
Work on a technical level, yes. But there are legal concerns in the ARIN region with that, some of which are spelled out here, by ACTUAL lawyers. https://pc.nanog.org/static/published/meetings/NANOG75/1900/20190219_Yoo_Rpk... Not going to dive any further into that subject here, wrong forum, but it's illustrative of my overall point. Thar Were Dragons still to be slayed on this topic already, and I think CF has just made that harder. On Mon, Apr 20, 2020 at 12:41 PM Mark Tinka <mark.tinka@seacom.mu> wrote:
On 20/Apr/20 18:24, Tom Beecher wrote:
Technical people need to make the business case to management for RKPI by laying out what it would cost to implement (equipment, resources, ongoing opex), and what the savings are to the company from protecting themselves against hijacks. By taking this step, I believe RPKI will become viewed by non-technical decision makers as a 'Cloudflare initiative' instead of a 'good of the internet' initiative, especially by some companies who compete with Cloudflare in the CDN space.
I believe that will change the calculus and make it a more difficult sell for technical people to get resources approved to make it happen.
I'm not sure I'd go that far, but I do see your point.
Nowadays, if you are running a half-decent router vendor, chances are any upgrades you are doing for normal things (adding capacity, moving from Gig-E to 10Gbps, or from 10Gbps to 100Gbps) will bring RPKI along for the ride by default.
We've seen that validators are free, and work very well.
Your ongoing RIR membership will get your access to getting your ROA's signed, so you don't need to pay extra for that.
So while I can see how an article like this could make life interesting within your business, I don't think much of it will hinge on "the cost of implementing RPKI in terms of $$".
My company, for example, only found out we run RPKI because of the April 1, 2019 activation article that we, and Workonline published. And we'd been testing and running RPKI since 2014 - and only because we had a total network refresh to get rid of some clunky Cisco XR 12000 routers (which probably support RPKI if you don't run IOS classic, hehe).
Mark.
On 20/Apr/20 18:50, Tom Beecher wrote:
Work on a technical level, yes. But there are legal concerns in the ARIN region with that, some of which are spelled out here, by ACTUAL lawyers.
https://pc.nanog.org/static/published/meetings/NANOG75/1900/20190219_Yoo_Rpk...
Not going to dive any further into that subject here, wrong forum, but it's illustrative of my overall point. Thar Were Dragons still to be slayed on this topic already, and I think CF has just made that harder.
I (and Ben, and a few others) are all too familiar with the ARIN madness around their TAL. Simple - we just don't accept it, which means our networks will be unsafe against North American resources. Highly doubtful my organization is that interested in how the ARIN region may or may not impact our interest in deploying RPKI on this side of the planet, when the rest of the world are less mad about it :-). This policy was broken in 2014. And it's still broken in 2020. Ah well... we keep moving. Mark.
Mark Tinka писал 2020-04-20 12:57:
On 20/Apr/20 18:50, Tom Beecher wrote:
I (and Ben, and a few others) are all too familiar with the ARIN madness around their TAL.
Simple - we just don't accept it, which means our networks will be unsafe against North American resources. Highly doubtful my organization is that interested in how the ARIN region may or may not impact our interest in deploying RPKI on this side of the planet, when the rest of the world are less mad about it :-).
So this means that there is no single source of truth for PRKI implementation all around the world and there are different shades, right? As a logical conclusion, the information provided on that page may be considered incorrect in terms of proclaiming particular network safe or not safe, but when it's claimed (sometimes blatantly) we now have to prove to our clients that we are not bad guys. Kind regards, Andrey
There is simple use case that will prove this page is giving false positive for their "name&shame" strategy. Any AS owner with default route only (yes it happens a lot) users will get: "YOUR ISP TERRIBLE, HIS BGP NOT SAFE!". But he have nothing to validate! His BGP is implemented safely, its just his upstream is not validating routes. On 2020-04-20 21:21, Andrey Kostin wrote:
Mark Tinka писал 2020-04-20 12:57:
On 20/Apr/20 18:50, Tom Beecher wrote:
I (and Ben, and a few others) are all too familiar with the ARIN madness around their TAL.
Simple - we just don't accept it, which means our networks will be unsafe against North American resources. Highly doubtful my organization is that interested in how the ARIN region may or may not impact our interest in deploying RPKI on this side of the planet, when the rest of the world are less mad about it :-).
So this means that there is no single source of truth for PRKI implementation all around the world and there are different shades, right? As a logical conclusion, the information provided on that page may be considered incorrect in terms of proclaiming particular network safe or not safe, but when it's claimed (sometimes blatantly) we now have to prove to our clients that we are not bad guys.
Kind regards, Andrey
On Mon, Apr 20, 2020 at 3:37 PM Denys Fedoryshchenko < nuclearcat@nuclearcat.com> wrote:
There is simple use case that will prove this page is giving false positive for their "name&shame" strategy. Any AS owner with default route only (yes it happens a lot) users will get: "YOUR ISP TERRIBLE, HIS BGP NOT SAFE!". But he have nothing to validate! His BGP is implemented safely, its just his upstream is not validating routes.
So, that same ISP who is not validating because it has a default route could push its providers to do validation and then be as safe as other validating themselves ? Rubens
On 2020-04-20 22:01, Rubens Kuhl wrote:
On Mon, Apr 20, 2020 at 3:37 PM Denys Fedoryshchenko <nuclearcat@nuclearcat.com> wrote:
There is simple use case that will prove this page is giving false positive for their "name&shame" strategy. Any AS owner with default route only (yes it happens a lot) users will get: "YOUR ISP TERRIBLE, HIS BGP NOT SAFE!". But he have nothing to validate! His BGP is implemented safely, its just his upstream is not validating routes.
So, that same ISP who is not validating because it has a default route could push its providers to do validation and then be as safe as other validating themselves ?
Rubens Typically, those who have "default route only" are too small to be heard, and their "wishes" doesn't go beyond the first line of support. Not to mention that it does not work at all if upstream is a monopoly, especially a state monopoly, who wont move a finger for "optional features".
And most important, the most common answer: All Tier-1 implemented it? No. Major hosting operators, such as AWS, gcloud, etc? - No. So...
Denys Fedoryshchenko писал 2020-04-20 15:27:
And most important, the most common answer: All Tier-1 implemented it? No. Major hosting operators, such as AWS, gcloud, etc? - No. So...
Absolutely, RPKI has different scale of effectiveness and benefits for big telecoms or clouds vs small ISPs or datacenters. On the other hand, the impact of such "BGP safety" test is completely the opposite. For big guys it is the most effective to implement, but being "not BGP safe yet" - "yeah, who cares!" or in best case add to the plan for the next fiscal year. But for small market players it's vise-versa: effect of filtering is minimal but pressure from "not being safe" may be very real. Kind regards, Andrey
On 20/Apr/20 20:21, Andrey Kostin wrote:
So this means that there is no single source of truth for PRKI implementation all around the world and there are different shades, right? As a logical conclusion, the information provided on that page may be considered incorrect in terms of proclaiming particular network safe or not safe, but when it's claimed (sometimes blatantly) we now have to prove to our clients that we are not bad guys.
Years ago, there was talk about giving it to the IANA. Mark.
Thank you Mark, Tom and Chris for your responses that confirmed my "mixed feelings" about this tool. As a side note, I mentioned from https://bgp.he.net/AS13335#_prefixes that AS13335 advertises a bunch or prefixes without RoA and even one invalid prefix, although I don't see it (only invalid one) from other sources. So it looks like an attempt to jump ahead and announce competitive leadership using marketing rather than technology. So for myself with your help I'd qualify it as aggressive push from technical PoV and offensive from marketing PoV. The former definitely has some positive effect which however could or could not be outweighted by the latter. Kind regards, Andrey Tom Beecher писал 2020-04-20 12:24:
Technical people need to make the business case to management for RKPI by laying out what it would cost to implement (equipment, resources, ongoing opex), and what the savings are to the company from protecting themselves against hijacks. By taking this step, I believe RPKI will become viewed by non-technical decision makers as a 'Cloudflare initiative' instead of a 'good of the internet' initiative, especially by some companies who compete with Cloudflare in the CDN space.
I believe that will change the calculus and make it a more difficult sell for technical people to get resources approved to make it happen.
On Mon, Apr 20, 2020 at 11:38 AM Cummings, Chris <ccummings@coeur.com> wrote:
Why do you think that RPKI adoption will be slowed due to this action by CloudFlare?
—
Chris Cummings
FROM: NANOG <nanog-bounces@nanog.org> on behalf of Tom Beecher <beecher@beecher.cc> DATE: Monday, April 20, 2020 at 10:35 TO: Andrey Kostin <ankost@podolsk.ru> CC: Nanog <nanog@nanog.org> SUBJECT: Re: "Is BGP safe yet?" test
( Speaking 100% for myself. )
I think it was tremendously irresponsible, especially in the context of current events, to take a complex technical issue like this and frame it to the general public as a 'safety' issue.
It's created articles like this : https://www.wired.com/story/cloudflare-bgp-routing-safe-yet/ , which are terrible because they imply that RPKI is just some simple thing that anyone not doing is just lazy or stupid. Very few people will read to the bottom note about vendors implementing RPKI support, or do any other research on the issue and challenges that some companies face to do it. It's not their job; that's ours.
I feel like there has been more momentum in getting more people to implement PKI in the last 18-24 months. ( Maybe others with different visibility have different opinions there. ) There are legitimate technical and business reasons why this isn't just a switch that can be turned on, and everyone in our industry knows that.
In my opinion, Mr. Prince is doing a great disservice by taking this approach, and in the longer term RPKI adoption will likely be slower than it would have been otherwise. I genuinely appreciate much of what Cloudflare does for the sake of 'internet good' , but I believe they wildly missed the mark here.
On 20/Apr/20 19:01, Andrey Kostin wrote:
Thank you Mark, Tom and Chris for your responses that confirmed my "mixed feelings" about this tool. As a side note, I mentioned from https://bgp.he.net/AS13335#_prefixes that AS13335 advertises a bunch or prefixes without RoA and even one invalid prefix, although I don't see it (only invalid one) from other sources. So it looks like an attempt to jump ahead and announce competitive leadership using marketing rather than technology. So for myself with your help I'd qualify it as aggressive push from technical PoV and offensive from marketing PoV. The former definitely has some positive effect which however could or could not be outweighted by the latter.
Just to point out, with such things, it's important to remain objective and not lump everything into the same basket because as a society, summary judgements is what we've evolved into since the Internet took over, i.e., the details are too overbearing to weed through :-). Rather, I'm sure many of us can easily deduce that any organization has multiple competing entities within it all striving to do their bit for the company. I know several folk at Cloudflare that I am almost sure (even without asking them) are probably not so amused with the marketing angle of this web site. But, as with the rest of their colleagues, they are another cog in the wheel, keeping their heads down and minding their business. I'm able to separate them and the good work they do to advance the state of RPKI deployment. In parallel I can also tune out all the fluff that emerges from the periphery, which is neither here nor there :-). Mark.
On Mon, Apr 20, 2020 at 12:25 PM Tom Beecher <beecher@beecher.cc> wrote:
Technical people need to make the business case to management for RKPI by laying out what it would cost to implement (equipment, resources, ongoing opex), and what the savings are to the company from protecting themselves against hijacks. By taking this step, I believe RPKI will become viewed by non-technical decision makers as a 'Cloudflare initiative' instead of a 'good of the internet' initiative, especially by some companies who compete with Cloudflare in the CDN space.
you say here: "RPKI" but the cloudflare thing is a little bit more nuanced than that, right? 'RPKI" is really: "Did you sign ROA for your IP Number Resources?" what you do with the RPKI data is the 'more nuanced' part of the webpage. 1) Do you just sign? 2) do you sign and also do Origin Validation(OV) for your peers? 3) do you just do OV and not sign your own IP Number Resources? I think CloudFlare (and other folk doing bgp security work) would like 'everyone' to: 1) sign ROA for their IP number resources 2) enable OV on your peerings 3) prefix filter all of your peerings
I believe that will change the calculus and make it a more difficult sell for technical people to get resources approved to make it happen.
I don't think that's the case... but I'm sure we'll be proven wrong :) -chris
On 20 Apr 2020, at 19:39, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Apr 20, 2020 at 12:25 PM Tom Beecher <beecher@beecher.cc> wrote:
Technical people need to make the business case to management for RKPI by laying out what it would cost to implement (equipment, resources, ongoing opex), and what the savings are to the company from protecting themselves against hijacks. By taking this step, I believe RPKI will become viewed by non-technical decision makers as a 'Cloudflare initiative' instead of a 'good of the internet' initiative, especially by some companies who compete with Cloudflare in the CDN space.
you say here: "RPKI" but the cloudflare thing is a little bit more nuanced than that, right? 'RPKI" is really: "Did you sign ROA for your IP Number Resources?" what you do with the RPKI data is the 'more nuanced' part of the webpage. 1) Do you just sign? 2) do you sign and also do Origin Validation(OV) for your peers? 3) do you just do OV and not sign your own IP Number Resources?
I think CloudFlare (and other folk doing bgp security work) would like 'everyone' to: 1) sign ROA for their IP number resources 2) enable OV on your peerings 3) prefix filter all of your peerings
The page seems very centred around the latter. The shaming is happening around the lack of filtering, not the absence of ROAs. The FAQ talks about “legitimate routes” but there’s not even a few words on how to actually make a route “legitimate". The push for filtering may be a bit premature given the fact that North America has 7% Canada 3% ROA coverage[1]. There’s not much point in setting up filters if there’s no data to filter on. One could argue that with filtering an incentive arises to create ROAs, but this is not how things have evolved elsewhere in the world. -Alex [1] https://nlnetlabs.nl/projects/rpki/rpki-analytics/
On Mon, Apr 20, 2020 at 2:32 PM Alex Band <alex@nlnetlabs.nl> wrote:
On 20 Apr 2020, at 19:39, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Apr 20, 2020 at 12:25 PM Tom Beecher <beecher@beecher.cc> wrote:
Technical people need to make the business case to management for RKPI by laying out what it would cost to implement (equipment, resources, ongoing opex), and what the savings are to the company from protecting themselves against hijacks. By taking this step, I believe RPKI will become viewed by non-technical decision makers as a 'Cloudflare initiative' instead of a 'good of the internet' initiative, especially by some companies who compete with Cloudflare in the CDN space.
you say here: "RPKI" but the cloudflare thing is a little bit more nuanced than that, right? 'RPKI" is really: "Did you sign ROA for your IP Number Resources?" what you do with the RPKI data is the 'more nuanced' part of the webpage. 1) Do you just sign? 2) do you sign and also do Origin Validation(OV) for your peers? 3) do you just do OV and not sign your own IP Number Resources?
I think CloudFlare (and other folk doing bgp security work) would like 'everyone' to: 1) sign ROA for their IP number resources 2) enable OV on your peerings 3) prefix filter all of your peerings
The page seems very centred around the latter. The shaming is happening around the lack of filtering, not the absence of ROAs. The FAQ talks about “legitimate routes” but there’s not even a few words on how to actually make a route “legitimate".
The push for filtering may be a bit premature given the fact that North America has 7% Canada 3% ROA coverage[1]. There’s not much point in setting up filters if there’s no data to filter on. One could argue that with filtering an incentive arises to create ROAs, but this is not how things have evolved elsewhere in the world.
So, if we believe that the players here are working in the best interest of the internet at large: how could CloudFlare's page be more helpful? (with respect to securing the global BGP system) how could ISPs (and other internet operations) be more helpful? (with respect to securing the global BGP system) how could users validate if their ISP options are doing all they can do for their users? (same global bgp system caveat) (is this last bit helpful at all to them or to the various options of ISP for that user?) Having been trying to get more-better-securer internet for a time now... happy to hear options :) -chris
I remember having this discussion more than 20yrs ago, minus the ARIN bit, couldn't get every to agree to it it then either :(. We don't need more rules, we just need to start with basic hygiene. Was a novel idea :) On Mon., Apr. 20, 2020, 2:41 p.m. Christopher Morrow, < morrowc.lists@gmail.com> wrote:
On Mon, Apr 20, 2020 at 12:25 PM Tom Beecher <beecher@beecher.cc> wrote:
Technical people need to make the business case to management for RKPI
by laying out what it would cost to implement (equipment, resources, ongoing opex), and what the savings are to the company from protecting themselves against hijacks. By taking this step, I believe RPKI will become viewed by non-technical decision makers as a 'Cloudflare initiative' instead of a 'good of the internet' initiative, especially by some companies who compete with Cloudflare in the CDN space.
you say here: "RPKI" but the cloudflare thing is a little bit more nuanced than that, right? 'RPKI" is really: "Did you sign ROA for your IP Number Resources?" what you do with the RPKI data is the 'more nuanced' part of the webpage. 1) Do you just sign? 2) do you sign and also do Origin Validation(OV) for your peers? 3) do you just do OV and not sign your own IP Number Resources?
I think CloudFlare (and other folk doing bgp security work) would like 'everyone' to: 1) sign ROA for their IP number resources 2) enable OV on your peerings 3) prefix filter all of your peerings
I believe that will change the calculus and make it a more difficult sell for technical people to get resources approved to make it happen.
I don't think that's the case... but I'm sure we'll be proven wrong :)
-chris
On 2020-04-20 19:24, Tom Beecher wrote:
Technical people need to make the business case to management for RKPI by laying out what it would cost to implement (equipment, resources, ongoing opex), and what the savings are to the company from protecting themselves against hijacks. By taking this step, I believe RPKI will become viewed by non-technical decision makers as a 'Cloudflare initiative' instead of a 'good of the internet' initiative, especially by some companies who compete with Cloudflare in the CDN space.
I believe that will change the calculus and make it a more difficult sell for technical people to get resources approved to make it happen.
If i am not wrong, for most routers implementing RPKI means spinning up VM with RPKI cache that need significant tinkering? I guess it is a blocker for many, unless some "ready made" solutions offered by vendors. Also, if ISP configure his router and it did crashed because he installed some "no warranty whatsoever" software from cloudflare github, what is next? I guess this might be not welcome in support contracts. P.S. Sorry for previous post top-posted. Just by mistake hit "Send" before i finished it
On Mon, Apr 20, 2020 at 8:47 PM Denys Fedoryshchenko < nuclearcat@nuclearcat.com> wrote:
If i am not wrong, for most routers implementing RPKI means spinning up VM with RPKI cache that need significant tinkering? I guess it is a blocker for many, unless some "ready made" solutions offered by vendors. Also, if ISP configure his router and it did crashed because he installed some "no warranty whatsoever" software from cloudflare github, what is next? I guess this might be not welcome in support contracts.
The RPKI software is something you need to run on a server somewhere. Not on the router itself. For our Juniper MX204 routers this was all that I needed to do: First install https://github.com/NLnetLabs/routinator on a server or VM somewhere. The server IP address would be 10.x.y.z in this example. set routing-options validation group rpki-validator session 10.x.y.z port 3323 local-address 10.a.b.c set policy-options community origin-validation-state-invalid members 0x4300: 0.0.0.0:2 set policy-options community origin-validation-state-unknown members 0x4300: 0.0.0.0:1 set policy-options community origin-validation-state-valid members 0x4300: 0.0.0.0:0 set policy-options policy-statement RPKI-CHECK term valid from protocol bgp set policy-options policy-statement RPKI-CHECK term valid from validation-database valid set policy-options policy-statement RPKI-CHECK term valid then validation-state valid set policy-options policy-statement RPKI-CHECK term valid then community add origin-validation-state-valid set policy-options policy-statement RPKI-CHECK term invalid from protocol bgp set policy-options policy-statement RPKI-CHECK term invalid from validation-database invalid set policy-options policy-statement RPKI-CHECK term invalid then validation-state invalid set policy-options policy-statement RPKI-CHECK term invalid then community add origin-validation-state-invalid set policy-options policy-statement RPKI-CHECK term unknown from protocol bgp set policy-options policy-statement RPKI-CHECK term unknown from validation-database unknown set policy-options policy-statement RPKI-CHECK term unknown then validation-state unknown set policy-options policy-statement RPKI-CHECK term unknown then community add origin-validation-state-unknown set policy-options policy-statement REJECT-RPKI-INVALID term RPKI-CHECK from policy RPKI-CHECK set policy-options policy-statement REJECT-RPKI-INVALID term RPKI-INVALID from community origin-validation-state-invalid set policy-options policy-statement REJECT-RPKI-INVALID term RPKI-INVALID then reject set routing-instances internet protocols bgp group nlix import REJECT-RPKI-INVALID set routing-instances internet protocols bgp group cogent import REJECT-RPKI-INVALID And just like that we had RPKI invalid filtering on the NLIX routing server and Cogent IP transit sessions. Since all of that is redundant, I took that opportunity to sanity check that we still had the expected amount of routes installed from these sources sans the invalids. Attribution I did not invent most of the above. It is from the free book Day One Deploying BGP routing security from Juniper. Regards, Baldur
On 20/Apr/20 17:31, Tom Beecher wrote:
( Speaking 100% for myself. )
I think it was tremendously irresponsible, especially in the context of current events, to take a complex technical issue like this and frame it to the general public as a 'safety' issue.
It's created articles like this : https://www.wired.com/story/cloudflare-bgp-routing-safe-yet/ , which are terrible because they imply that RPKI is just some simple thing that anyone not doing is just lazy or stupid. Very few people will read to the bottom note about vendors implementing RPKI support, or do any other research on the issue and challenges that some companies face to do it. It's not their job; that's ours.
I feel like there has been more momentum in getting more people to implement PKI in the last 18-24 months. ( Maybe others with different visibility have different opinions there. ) There are legitimate technical and business reasons why this isn't just a switch that can be turned on, and everyone in our industry knows that.
In my opinion, Mr. Prince is doing a great disservice by taking this approach, and in the longer term RPKI adoption will likely be slower than it would have been otherwise. I genuinely appreciate much of what Cloudflare does for the sake of 'internet good' , but I believe they wildly missed the mark here.
The issue is that due to the democratization of information, every one is now an expert. So if we thought something only appealed to an obvious audience, think again. Mark.
On Mon, Apr 20, 2020 at 5:08 PM Andrey Kostin <ankost@podolsk.ru> wrote:
Hi Nanog list,
Would be interesting to hear your opinion on this: https://isbgpsafeyet.com/
It did push me to implement RPKI filtering. Turned out to be quite easy. Took me all of 1-2 hours to do. Just went straight to dropping invalids and tested on one transit and one IX routing server. When that did look just fine, I could proceed with the remaining sessions. As a bonus at least one of our transits now also implements RPKI filtering. That greatly increases the chance that we will retain a valid route during a prefix hijack attempt. Regards, Baldur
I find it fascinating that in this entire thread about the nature of RPKI the shift in the role of the RIR hasn’t come up. Instead of RIRs coordinating address space use by keeping a public list which is (or should be) checked when a new peering session is added, RPKI shifts RIRs into the hot path of routing updates. Next time the US government decides some bad, bad, very bad country should be cut off from the world with viral sanctions, there’s a new tool available - by simply editing a database, every border router in the world will refuse to talk to $EVIL. By no means am I suggesting we should stop the RPKI train (and AS397444 happily drops invalids and has ROAs for all prefixes), but there’s a very cost here that doesn’t appear to have gotten much love, let alone mitigation effort. In the context of RIPE having to ask for permission to keep receiving payments from several Iranian LIRs, this isn’t completely inconceivable. By way of an example, something like a waiting period for RIRs to add new ROAs replacing removed ROAs (which would imply some kind of signed replacement, but you get the point). At least ARIN already has a several-month quieting period after yanking resources for non-payment, why not use that to give operators time to think about whether they mind talking to Iran? /ducks Matt
On Apr 20, 2020, at 08:10, Andrey Kostin <ankost@podolsk.ru> wrote:
Hi Nanog list,
Would be interesting to hear your opinion on this: https://isbgpsafeyet.com/
We have cases when residential customers ask support "why is your service isn't safe?" pointing to that article. It's difficult to answer correctly considering that the asking person usually doesn't know what BGP is and what it's used for, save for understanding it's function, design and possible misuses. IMO, on one hand it promotes and is aimed to push RPKI deployment, on the other hand is this a proper way for it? How ethical is to claim other market players unsafe, considering that scope of possible impact of not implementing it has completely different scale for a small stub network and big transit provider?
Kind regards, Andrey
On 21 Apr 2020, at 08:51, Matt Corallo via NANOG <nanog@nanog.org> wrote:
I find it fascinating that in this entire thread about the nature of RPKI the shift in the role of the RIR hasn’t come up.
Instead of RIRs coordinating address space use by keeping a public list which is (or should be) checked when a new peering session is added, RPKI shifts RIRs into the hot path of routing updates.
The RIPE NCC has an IRR that is tightly coupled to the resource holder. With many networks requiring a route object to be published in the IRR for them to accept your announcement, the RPKI scenario that you describe has basically existed for the RIPE Database IRR since forever. This tight coupling doesn’t exist for the RADB and ARIN and as a result it is full of incorrect data, which is one of the reasons RPKI exists in the first place. Removing a resource from the certificate to achieve the goal you describe will make the route announcement NotFound, which means it will be accepted. Evil RIR would have to replace an existing ROA with one that explicitly makes a route invalid, i.e. issue an AS0 ROA for specific member prefix. This seems like a pretty convoluted way to try and take a network offline.
Next time the US government decides some bad, bad, very bad country should be cut off from the world with viral sanctions, there’s a new tool available - by simply editing a database, every border router in the world will refuse to talk to $EVIL.
ARIN has taken pretty drastic nonrepudiation measures: https://www.arin.net/resources/manage/rpki/faq/#why-must-i-create-a-key-pair... With Delegated RPKI you can take matters into your own hands: https://rpki.readthedocs.io/en/latest/rpki/implementation-models.html#delega... -Alex
By no means am I suggesting we should stop the RPKI train (and AS397444 happily drops invalids and has ROAs for all prefixes), but there’s a very cost here that doesn’t appear to have gotten much love, let alone mitigation effort. In the context of RIPE having to ask for permission to keep receiving payments from several Iranian LIRs, this isn’t completely inconceivable. By way of an example, something like a waiting period for RIRs to add new ROAs replacing removed ROAs (which would imply some kind of signed replacement, but you get the point). At least ARIN already has a several-month quieting period after yanking resources for non-payment, why not use that to give operators time to think about whether they mind talking to Iran?
/ducks
Matt
On Apr 20, 2020, at 08:10, Andrey Kostin <ankost@podolsk.ru> wrote:
Hi Nanog list,
Would be interesting to hear your opinion on this: https://isbgpsafeyet.com/
We have cases when residential customers ask support "why is your service isn't safe?" pointing to that article. It's difficult to answer correctly considering that the asking person usually doesn't know what BGP is and what it's used for, save for understanding it's function, design and possible misuses. IMO, on one hand it promotes and is aimed to push RPKI deployment, on the other hand is this a proper way for it? How ethical is to claim other market players unsafe, considering that scope of possible impact of not implementing it has completely different scale for a small stub network and big transit provider?
Kind regards, Andrey
Hi,
Removing a resource from the certificate to achieve the goal you describe will make the route announcement NotFound, which means it will be accepted. Evil RIR would have to replace an existing ROA with one that explicitly makes a route invalid, i.e. issue an AS0 ROA for specific member prefix. This seems like a pretty convoluted way to try and take a network offline.
I've seen worse… Sander
On 21.04.2020 10.56, Sander Steffann wrote:
Hi,
Removing a resource from the certificate to achieve the goal you describe will make the route announcement NotFound, which means it will be accepted. Evil RIR would have to replace an existing ROA with one that explicitly makes a route invalid, i.e. issue an AS0 ROA for specific member prefix. This seems like a pretty convoluted way to try and take a network offline. I've seen worse… Sander
As long Good RIR continues to publish a valid ROA for the real ASN that evil AS0 ROA would have no effect? Regards, Baldur
On 21 Apr 2020, at 11:09, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 21.04.2020 10.56, Sander Steffann wrote:
Hi,
Removing a resource from the certificate to achieve the goal you describe will make the route announcement NotFound, which means it will be accepted. Evil RIR would have to replace an existing ROA with one that explicitly makes a route invalid, i.e. issue an AS0 ROA for specific member prefix. This seems like a pretty convoluted way to try and take a network offline. I've seen worse… Sander
As long Good RIR continues to publish a valid ROA for the real ASN that evil AS0 ROA would have no effect?
Correct. Should this really be a concern, then you can run Delegated RPKI. In that case the RIR can’t tamper with your ROA because it’s not on their systems. Evil RIR could only revoke a prefix from your certificate or your entire certificate, but again, your BGP announcements would fall back to NotFound and would be accepted. -Alex
Not sure how this helps? If RIPE (or a government official/court) decides the sanctions against Iranian LIRs prevents them from issuing number resources to said LIRs, they would just remove the delegation. They’d probably then issue an AS0 ROA to replace out given the “AS0 ROA for bogons” policy. In an hour or so these LIRs are now disconnected from the world.
On Apr 21, 2020, at 02:30, Alex Band <alex@nlnetlabs.nl> wrote:
On 21 Apr 2020, at 11:09, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 21.04.2020 10.56, Sander Steffann wrote: Hi,
Removing a resource from the certificate to achieve the goal you describe will make the route announcement NotFound, which means it will be accepted. Evil RIR would have to replace an existing ROA with one that explicitly makes a route invalid, i.e. issue an AS0 ROA for specific member prefix. This seems like a pretty convoluted way to try and take a network offline. I've seen worse… Sander
As long Good RIR continues to publish a valid ROA for the real ASN that evil AS0 ROA would have no effect?
Correct.
Should this really be a concern, then you can run Delegated RPKI. In that case the RIR can’t tamper with your ROA because it’s not on their systems. Evil RIR could only revoke a prefix from your certificate or your entire certificate, but again, your BGP announcements would fall back to NotFound and would be accepted.
-Alex
On Tue, Apr 21, 2020 at 12:17 PM Matt Corallo via NANOG <nanog@nanog.org> wrote:
Not sure how this helps? If RIPE (or a government official/court) decides the sanctions against Iranian LIRs prevents them from issuing number resources to said LIRs, they would just remove the delegation. They’d probably then issue an AS0 ROA to replace out given the “AS0 ROA for bogons” policy. In an hour or so these LIRs are now disconnected from the world.
1) there are other ways the black helicopter people can do their business, this is but one new lever. 2) this is the sort of thing that local TAL / SLURM are meant to help 'fix'. 3) see the long discussions of this in the sidr/sidr-ops wg lists :(
On Apr 21, 2020, at 02:30, Alex Band <alex@nlnetlabs.nl> wrote:
On 21 Apr 2020, at 11:09, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 21.04.2020 10.56, Sander Steffann wrote: Hi,
Removing a resource from the certificate to achieve the goal you describe will make the route announcement NotFound, which means it will be accepted. Evil RIR would have to replace an existing ROA with one that explicitly makes a route invalid, i.e. issue an AS0 ROA for specific member prefix. This seems like a pretty convoluted way to try and take a network offline. I've seen worse… Sander
As long Good RIR continues to publish a valid ROA for the real ASN that evil AS0 ROA would have no effect?
Correct.
Should this really be a concern, then you can run Delegated RPKI. In that case the RIR can’t tamper with your ROA because it’s not on their systems. Evil RIR could only revoke a prefix from your certificate or your entire certificate, but again, your BGP announcements would fall back to NotFound and would be accepted.
-Alex
That’s an interesting idea. I’m not sure that LACNIC would want to issue a ROA for RIPE IP space after RIPE issues an AS0 ROA, though. And you’d at least need some kind of time delay to give other RIRs and operators and chance to discuss the matter before allowing RIPE to issue the AS0 ROA, eg in my example mitigation strategy.
On Apr 21, 2020, at 02:10, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 21.04.2020 10.56, Sander Steffann wrote: Hi,
Removing a resource from the certificate to achieve the goal you describe will make the route announcement NotFound, which means it will be accepted. Evil RIR would have to replace an existing ROA with one that explicitly makes a route invalid, i.e. issue an AS0 ROA for specific member prefix. This seems like a pretty convoluted way to try and take a network offline. I've seen worse… Sander
As long Good RIR continues to publish a valid ROA for the real ASN that evil AS0 ROA would have no effect?
Regards,
Baldur
On Tue, Apr 21, 2020 at 1:10 PM Matt Corallo via NANOG <nanog@nanog.org> wrote:
That’s an interesting idea. I’m not sure that LACNIC would want to issue a ROA for RIPE IP space after RIPE issues an AS0 ROA, though. And you’d at least need some kind of time delay to give other RIRs and operators and chance to discuss the matter before allowing RIPE to issue the AS0 ROA, eg in my example mitigation strategy.
All 5 RIRs can issue ROAs for all the IP address spaces. They don't as a matter of coordinated operations, but that doesn't prevent court orders determining that to be done. Rubens
Sure. This kinda falls under my point that we should be talking about basic mitigation, then. I’m not aware of any previous discussion of creating policy that instructs RIRs to do so. Again, with a basic step like that, plus a validator-enforced time delay between when a RIR can remove a ROA for some IP space and when it can be replaced, RPKI would be drastically de-risked. Once you start going down that road, there would be way more desire on the part of OFAC and other small committees to enforce policy using other levers.
On Apr 21, 2020, at 09:36, Rubens Kuhl <rubensk@gmail.com> wrote:
On Tue, Apr 21, 2020 at 1:10 PM Matt Corallo via NANOG <nanog@nanog.org> wrote: That’s an interesting idea. I’m not sure that LACNIC would want to issue a ROA for RIPE IP space after RIPE issues an AS0 ROA, though. And you’d at least need some kind of time delay to give other RIRs and operators and chance to discuss the matter before allowing RIPE to issue the AS0 ROA, eg in my example mitigation strategy.
All 5 RIRs can issue ROAs for all the IP address spaces. They don't as a matter of coordinated operations, but that doesn't prevent court orders determining that to be done.
Rubens
On 2020-04-21 12:36, Rubens Kuhl wrote:
On Tue, Apr 21, 2020 at 1:10 PM Matt Corallo via NANOG <nanog@nanog.org> wrote:
That’s an interesting idea. I’m not sure that LACNIC would want to issue a ROA for RIPE IP space after RIPE issues an AS0 ROA, though. And you’d at least need some kind of time delay to give other RIRs and operators and chance to discuss the matter before allowing RIPE to issue the AS0 ROA, eg in my example mitigation strategy.
All 5 RIRs can issue ROAs for all the IP address spaces. They don't as a matter of coordinated operations, but that doesn't prevent court orders determining that to be done.
Or a miscreant. [insert-least-favorite-rir] is now part of your attack surface. -danny
On Wed, Apr 22, 2020 at 11:45 AM Danny McPherson <danny@tcb.net> wrote:
On 2020-04-21 12:36, Rubens Kuhl wrote:
On Tue, Apr 21, 2020 at 1:10 PM Matt Corallo via NANOG <nanog@nanog.org> wrote:
That’s an interesting idea. I’m not sure that LACNIC would want to issue a ROA for RIPE IP space after RIPE issues an AS0 ROA, though. And you’d at least need some kind of time delay to give other RIRs and operators and chance to discuss the matter before allowing RIPE to issue the AS0 ROA, eg in my example mitigation strategy.
All 5 RIRs can issue ROAs for all the IP address spaces. They don't as a matter of coordinated operations, but that doesn't prevent court orders determining that to be done.
Or a miscreant. [insert-least-favorite-rir] is now part of your attack surface.
Or a slip of the keyboard / software ooops / mistake -- but, in spite of this, I think that RPKI / ROAs / ROV is a good thing; as with everything, this is an engineering trade off, and to me this feels well worth it... I do think that CloudFlare does some great things for the Internet - they've moved DNSSEC forward immensely, significantly increased the adoption of HTTPS/TLS, the OctoRPKI/GoRTR stuff is nice and easy, their hosted RPKI cache, etc -- but their marketing pushes like this feel overly aggressive. W
-danny
-- 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
There are in fact five anchors. I am not sure ARIN would be able to stop anyone holding RIPE space provided the resource holder uses RIPE RPKI anchor for publishing his ROAs. Regards, Baldur On 21.04.2020 08.51, Matt Corallo via NANOG wrote:
I find it fascinating that in this entire thread about the nature of RPKI the shift in the role of the RIR hasn’t come up.
Instead of RIRs coordinating address space use by keeping a public list which is (or should be) checked when a new peering session is added, RPKI shifts RIRs into the hot path of routing updates. Next time the US government decides some bad, bad, very bad country should be cut off from the world with viral sanctions, there’s a new tool available - by simply editing a database, every border router in the world will refuse to talk to $EVIL.
By no means am I suggesting we should stop the RPKI train (and AS397444 happily drops invalids and has ROAs for all prefixes), but there’s a very cost here that doesn’t appear to have gotten much love, let alone mitigation effort. In the context of RIPE having to ask for permission to keep receiving payments from several Iranian LIRs, this isn’t completely inconceivable.
By way of an example, something like a waiting period for RIRs to add new ROAs replacing removed ROAs (which would imply some kind of signed replacement, but you get the point). At least ARIN already has a several-month quieting period after yanking resources for non-payment, why not use that to give operators time to think about whether they mind talking to Iran?
/ducks
Matt
On Apr 20, 2020, at 08:10, Andrey Kostin <ankost@podolsk.ru> wrote:
Hi Nanog list,
Would be interesting to hear your opinion on this: https://isbgpsafeyet.com/
We have cases when residential customers ask support "why is your service isn't safe?" pointing to that article. It's difficult to answer correctly considering that the asking person usually doesn't know what BGP is and what it's used for, save for understanding it's function, design and possible misuses. IMO, on one hand it promotes and is aimed to push RPKI deployment, on the other hand is this a proper way for it? How ethical is to claim other market players unsafe, considering that scope of possible impact of not implementing it has completely different scale for a small stub network and big transit provider?
Kind regards, Andrey
On 21/Apr/20 08:51, Matt Corallo via NANOG wrote:
Instead of RIRs coordinating address space use by keeping a public list which is (or should be) checked when a new peering session is added, RPKI shifts RIRs into the hot path of routing updates. Next time the US government decides some bad, bad, very bad country should be cut off from the world with viral sanctions, there’s a new tool available - by simply editing a database, every border router in the world will refuse to talk to $EVIL.
This keeps coming up. If a ROA disappears, RPKI state reverts to NotFound. Unless dropping "NotFound" is now BCP, I think we'll be okay. Mark.
Right until RIPE finishes deploying AS0 ROAs for bogons, which I recall is moving forward :p.
On Apr 21, 2020, at 03:01, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 21/Apr/20 08:51, Matt Corallo via NANOG wrote:
Instead of RIRs coordinating address space use by keeping a public list which is (or should be) checked when a new peering session is added, RPKI shifts RIRs into the hot path of routing updates. Next time the US government decides some bad, bad, very bad country should be cut off from the world with viral sanctions, there’s a new tool available - by simply editing a database, every border router in the world will refuse to talk to $EVIL.
This keeps coming up.
If a ROA disappears, RPKI state reverts to NotFound. Unless dropping "NotFound" is now BCP, I think we'll be okay.
Mark.
From: "Andrey Kostin" <ankost@podolsk.ru>
Would be interesting to hear your opinion on this: https://isbgpsafeyet.com/
We have cases when residential customers ask support "why is your service isn't safe?" pointing to that article. It's difficult to answer correctly considering that the asking person usually doesn't know what BGP is and what it's used for, save for understanding it's function, design and possible misuses.
Well, given how little the BCP38 website below has moved that football, you're not likely in much danger... :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Jay R. Ashworth писал 2020-04-22 11:02:
Well, given how little the BCP38 website below has moved that football, you're not likely in much danger... :-)
Cheers, -- jra
BCP38 website doesn't proclaim anybody in person to be unsafe, but if it would be possible to make such test it'd be more useful than that RPKI test. BTW, has anybody yet thought/looked into extending RPKI-RTR protocol for validation of prefixes received from peer-as to make ingress filtering more dynamic and move away prefix filters from the routers? Kind regards, Andrey
On 2020-04-22 12:51, Andrey Kostin wrote:
BCP38 website doesn't proclaim anybody in person to be unsafe, but if it would be possible to make such test it'd be more useful than that RPKI test.
BTW, has anybody yet thought/looked into extending RPKI-RTR protocol for validation of prefixes received from peer-as to make ingress filtering more dynamic and move away prefix filters from the routers?
Do you really want those things in soft-state and not with some giant operational buffer to absorb all the brokenness that's sure to arise? -danny
On Wed, Apr 22, 2020 at 1:32 PM Danny McPherson <danny@tcb.net> wrote:
On 2020-04-22 12:51, Andrey Kostin wrote:
BCP38 website doesn't proclaim anybody in person to be unsafe, but if it would be possible to make such test it'd be more useful than that RPKI test.
BTW, has anybody yet thought/looked into extending RPKI-RTR protocol for validation of prefixes received from peer-as to make ingress filtering more dynamic and move away prefix filters from the routers?
Do you really want those things in soft-state and not with some giant operational buffer to absorb all the brokenness that's sure to arise?
a question about the data types here... So, a neighbor with no downstream ASN could be filtered directly with ROA == prefixlist-content. A neighbor with a downstream ASN has to be ROA (per asn downstream) == prefixlist-content. So you'd now have to do some calculations which are more complicated than just; "is roa for this prefix here and valid" to construct a prefix-list. correct?
On Wed, Apr 22, 2020 at 2:03 PM Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Apr 22, 2020 at 1:32 PM Danny McPherson <danny@tcb.net> wrote:
On 2020-04-22 12:51, Andrey Kostin wrote:
BCP38 website doesn't proclaim anybody in person to be unsafe, but if it would be possible to make such test it'd be more useful than that RPKI test.
BTW, has anybody yet thought/looked into extending RPKI-RTR protocol for validation of prefixes received from peer-as to make ingress filtering more dynamic and move away prefix filters from the routers?
Do you really want those things in soft-state and not with some giant operational buffer to absorb all the brokenness that's sure to arise?
a question about the data types here... So, a neighbor with no downstream ASN could be filtered directly with ROA == prefixlist-content. A neighbor with a downstream ASN has to be ROA (per asn downstream) == prefixlist-content.
So you'd now have to do some calculations which are more complicated than just; "is roa for this prefix here and valid" to construct a prefix-list. correct?
Sorry, and this sidesteps the intent of the peer as well. For instance you may have a peer with 2 'downstream' asn, only 1 of which they wish to provide transit to you (from you?) for... how would you know this intent/policy from the peer's perspective? today you know that (most likely) from IRR data. is your answer ASPA / AS-Cone ?
Christopher Morrow писал 2020-04-22 14:05:
a question about the data types here... So, a neighbor with no downstream ASN could be filtered directly with ROA == prefixlist-content. A neighbor with a downstream ASN has to be ROA (per asn downstream) == prefixlist-content.
So you'd now have to do some calculations which are more complicated than just; "is roa for this prefix here and valid" to construct a prefix-list. correct?
Sorry, and this sidesteps the intent of the peer as well. For instance you may have a peer with 2 'downstream' asn, only 1 of which they wish to provide transit to you (from you?) for... how would you know this intent/policy from the peer's perspective? today you know that (most likely) from IRR data.
is your answer ASPA / AS-Cone ?
ASPA/As-Cone is a concept about whole as-path verification afaik, but I may be mistaken. ROA validation prevents hijacking but doesn't prevent route-leaks. If my transit providers already do ROV, effect of doing it in local network will be limited to direct peers only and expected to be considerably small. For route-leaks prevention we still have to rely on IRR and filters configured directly on routers. Maintaining filters on routers is quite intensive task and they took a lot of space in the configuration. Adopting validation or similar mechanism for it could make it more dynamic and less resources-consuming. Or maybe I'm trying to invent a bicycle? Kind regards, Andrey
❦ 22 avril 2020 12:51 -04, Andrey Kostin:
BTW, has anybody yet thought/looked into extending RPKI-RTR protocol for validation of prefixes received from peer-as to make ingress filtering more dynamic and move away prefix filters from the routers?
It could be used as is if the client implementations were a bit more flexible. With BIRD, you decide which AS to match. So you can match on the neighbor AS instead of the origin AS. Then, you can use something like GoRTR which accepts using JSON files instead of the RPKI as source. BIRD also allows you to have several ROA tables. So, you can check against the "real" RPKI as well as against your custom IRR-based RPKI. -- Choose variable names that won't be confused. - The Elements of Programming Style (Kernighan & Plauger)
Vincent Bernat писал 2020-04-22 15:26:
❦ 22 avril 2020 12:51 -04, Andrey Kostin:
BTW, has anybody yet thought/looked into extending RPKI-RTR protocol for validation of prefixes received from peer-as to make ingress filtering more dynamic and move away prefix filters from the routers?
It could be used as is if the client implementations were a bit more flexible.
With BIRD, you decide which AS to match. So you can match on the neighbor AS instead of the origin AS. Then, you can use something like GoRTR which accepts using JSON files instead of the RPKI as source. BIRD also allows you to have several ROA tables. So, you can check against the "real" RPKI as well as against your custom IRR-based RPKI.
That's what I meant. So I guess IX operators already can use BIRD on route-servers for prefix filtering. I think it could be useful on hw routers as well. Kind regards, Andrey
participants (20)
-
Alex Band -
Amir Herzberg -
Andrey Kostin -
Baldur Norddahl -
Christopher Morrow -
Cummings, Chris -
Danny McPherson -
Denys Fedoryshchenko -
Jay R. Ashworth -
jim deleskie -
Job Snijders -
Mark Tinka -
Matt Corallo -
Randy Bush -
Rubens Kuhl -
Saku Ytti -
Sander Steffann -
Tom Beecher -
Vincent Bernat -
Warren Kumari