tag:blogger.com,1999:blog-3993498847203183398.post9004763149048989186..comments2024-03-28T09:19:27.451+00:00Comments on RevK<sup>®</sup>'s ramblings: BGPRevKhttp://www.blogger.com/profile/12369263214193333422noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-3993498847203183398.post-41356439671240517932020-04-22T07:24:26.597+01:002020-04-22T07:24:26.597+01:00Thanks for your comments - there is, of course, a ...Thanks for your comments - there is, of course, a difference between deliberate "censorship", and simply making things work in the Internet - i.e. blocking duff routes as per best practice. There is also a difference between filtering traffic, and simply not having a route to somewhere. The plan is that we will have RPKI - after the current "crisis". Even if we did not, once our transit routes have it, we will see duff routes correctly removed.RevKhttps://www.blogger.com/profile/12369263214193333422noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-89826211444985260612020-04-21T22:17:28.118+01:002020-04-21T22:17:28.118+01:00I think I need to balance what I have said publicl...I think I need to balance what I have said publicly with what you have written here.<br /><br />There are idiots out there on the Internet who do not publish valid route/route6 objects in the relevant IRR data sources and then when this is pointed out to them by the customer who has that prefix assigned to them; they need to be spoon-fed the relevant text to submit to the RIPE database in order to create the necessary object in order to be able to use the prefix that they assigned to their own customer.<br /><br />I have seen at least one similar error with RPKI; if you change the origin AS for a prefix, you need to publish an additional ROA, update your existing one or simply revoke them all in order to ensure global reachability of that prefix.<br /><br />I think Cloudflare would have put their point across better if they had advertised two 'invalid' prefixes with one prefix testing for those who had implementing strict IRR-based/AS-path filtering and the other prefix for those who had implemented RPKI - there are multiple grades of 'safe' here - and those ISPs who haven't even bothered to implement IRR-based filtering should rightfully be called out for it as that has been The Right Way(tm) to do it for many years prior to RPKI even being on the drawing board.<br /><br />My concern with any provider manually blocking a prefix is made nicely by your own marketing at https://www.aa.net.uk/broadband/real-internet/ headed "Why are we against censorship?":<br /><br />"Censorship of any sort is the thin end of the wedge and must not be taken lightly."<br /><br />The address space is Cloudflare, being advertised by Cloudflare and content is being served by Cloudflare hosts from that space.<br /><br />One thing that Cloudflare could easily do to combat those who manually block their 'invalid' prefix is to periodically cycle what prefix is used for this purpose very much like how spammers frequently switch source addresses/netblocks to ensure they don't trip rate-limits imposed on them by others.<br /><br />Then it becomes a game of whack-a-mole... which can become even more embarrassing for an ISP that promotes an anti-censorship stance if/when Cloudflare start serving legitimate content from one of the manually-blocked prefixes which is no longer 'invalid' as far as RPKI is concerned due to publication of a valid ROA.<br /><br />No ISP can keep up with a game like that until they actually implement RPKI.<br /><br />I guess that the moral of the story is that manually-blocked prefixes (sometimes even bogons) almost always have a habit of coming back and biting you when you least expect it.Terry F.https://www.blogger.com/profile/13969846575454712191noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-75233987479188377572020-04-20T07:39:54.750+01:002020-04-20T07:39:54.750+01:00Yes, thanks, that is the one.Yes, thanks, that is the one.RevKhttps://www.blogger.com/profile/12369263214193333422noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-50502783063293946142020-04-20T07:39:34.605+01:002020-04-20T07:39:34.605+01:00Thanks, yes, updated.Thanks, yes, updated.RevKhttps://www.blogger.com/profile/12369263214193333422noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-27437301255745128722020-04-20T00:20:07.842+01:002020-04-20T00:20:07.842+01:00"Path overload issue [struggling to find the ..."Path overload issue [struggling to find the link to history on this - will update if anyone has details]"<br /><br />Was it this? https://dyn.com/blog/longer-is-not-better/<br />chrislnoreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-43097097809411789162020-04-19T19:48:24.997+01:002020-04-19T19:48:24.997+01:00Regarding path overload incidents:
There have bee...Regarding path overload incidents:<br /><br />There have been a few over the years but the ones that stick in my mind are https://dyn.com/wp-content/uploads/2013/05/nanog54-cowie.pdf and https://dyn.com/blog/the-flap-heard-around-the-world/<br /><br />Primarily caused by folk not reading the MikroTik RouterOS documentation properly:<br /><br />https://wiki.mikrotik.com/wiki/Manual:Routing/Routing_filters<br /><br />The parameter I believe you are thinking of is 'set-bgp-prepend'.Terry F.https://www.blogger.com/profile/13969846575454712191noreply@blogger.com