[HN Gopher] Is BGP Safe Yet?
___________________________________________________________________
Is BGP Safe Yet?
Author : eastdakota
Score : 350 points
Date : 2020-04-17 15:02 UTC (7 hours ago)
(HTM) web link (isbgpsafeyet.com)
(TXT) w3m dump (isbgpsafeyet.com)
| surround wrote:
| http://isThisYourPaperOnSingleServingSites.com/
| rsync wrote:
| Hrm...
|
| I have been a huge fan of Hurricane Electric (he.net) for over
| ten years and have done a lot of evangelizing ... rsync.net uses
| he.net pops all over the world (except for Zurich, where we use
| init7...).
|
| They have been very progressive, clueful and efficient in all of
| our dealings with them.
|
| So I am surprised to see them marked unsafe. I have emailed my
| point of contact there and asked for some explanation - perhaps I
| can update this comment in a bit ...
| kitteh wrote:
| Hurricane Electric doesn't implement RPKI Origin Validation as
| most people understand it. They try to do some route filtering
| that is RPKI like, but it's not the same.
| bsder wrote:
| A startup company that several of my friends worked at many
| years ago had boxes that continuously monitored routing around
| that would and would flag and delay BGP updates that caused a
| significant topological change. They could be added manually
| immediately, or would be implemented with a delay after they
| had enough data that the route was legitimate.
|
| My ISP had one of these boxes and was quite proud of it. It
| worked really well against BGP idiocy. It might not have worked
| against a concerted attack, but it did stop several of the
| "Ooops. All the routes are belong to us." problems that seem to
| be the "normal" BGP "attacks".
|
| I am surprised that these big players don't already have
| something that does something similar.
| rodiger wrote:
| Wow the diagrams are really well done here. Really well-made and
| presented.
| gouggoug wrote:
| They are visually appealing and are technically implemented
| nicely. I think, however, that they are not very insightful to
| the matter. It is easy to visualize the result of a BGP hijack:
| packets are routed to the wrong/malicious destination; so is
| visualizing the result of RPKI: packets aren't routed to the
| wrong destination.
|
| What, to me, would have provided a little more value would have
| been to diagram _how_ BGP hijack happens (visualize a router
| announcing the wrong route), and _how_ RPKI solves the issue.
| Of course, those 2 things are probably much harder to diagram.
|
| edit: re-phrased a sentence.
| adamschwartz wrote:
| (Designer of the site) This is such a great point, and
| something I'd definitely like to tackle in a future
| iteration. Thanks for the push in that direction!
| imagine99 wrote:
| Yes, they look really great and responsive, too. I'd actually
| like to know how they were done... Are they just basically
| coded by hand or is there a visual tool you can use to design
| interactive graphical stuff like this in what I guess is
| HTML5/CSS/maybe JavaScript, similar to (dare I mention the
| word) Flash in the olden days? (Sorry, haven't done any web
| development in decades, obviously :-)).
| neurostimulant wrote:
| It's basically animating SVG with CSS, which is very neat.
| Not using js at all except to toggle some class names when
| you click the button.
| adamschwartz wrote:
| It's really just using CSS to animate regular HTML
| elements. SVG is used for the icons (the laptop, server,
| cloud), but the grid lines, connection lines, and packet
| animation are all just plain `<div/>`s :P
|
| But you're totally correct about the JS only toggling
| between path="happy" and path="sad"
| adamschwartz wrote:
| Yup, they were coded by hand!
|
| Here was the initial commit which added the first diagram
| (originally there was only one):
|
| https://git.io/JfJ4K
| job wrote:
| a really cool way to explain RPKI, thanks for sharing!
| jamieweb wrote:
| For those who don't have their own Autonomous System, but want to
| play with RPKI validation, you can join DN42 [1] and validate
| routes there.
|
| Netravnen kindly provides a route export compatible with GoRTR
| and Routinator [2], which has been working nicely for me.
|
| [1] https://dn42.us
|
| [2] https://github.com/netravnen/dn42-roa-export
| toomuchtodo wrote:
| Love this effort. [EDIT: Removed poorly thought out idea]
| ocdtrekkie wrote:
| I would discourage this approach. Internet spam-generating
| campaigns aren't really an effective way of creating change,
| and the poor employee required to read the emails at that
| contact address is probably not responsible for the decisions
| holding up implementation.
|
| Which is to say: Please don't advocate for behaviors that
| harass line employees at corps you don't like.
| eastdakota wrote:
| Agree. Mentioning them on Twitter is one thing. Harassing
| NOCs already stressed during this time of unprecedented
| Internet usage is another.
| toomuchtodo wrote:
| Point taken. Please excuse the over exuberance during
| uncertain times.
| [deleted]
| [deleted]
| [deleted]
| bifrost wrote:
| This has already been done by William Leibzon, its a bad idea
| and for the most part everyone despises him now.
| thoraway1010 wrote:
| This is actually a very very powerful idea.
|
| The trick is to get something VPs / "Decision Makers" can use to
| make decisions that's easy for them to digest especially if they
| are not technically sophisticated. This meets that criteria.
|
| They should add microsoft azure to this list.
|
| This could absolutely become an RFP requirement / preference
| point for a lot of compliance focused / not only tech focused
| buyers (govt / large agencies and companies)
|
| A huge thumbs up!
| notaplumber wrote:
| OpenBSD just released a portable version of their privsep rpki-
| client(8)* this week!
|
| https://www.rpki-client.org/
|
| rpki-client 6.6p1 was released Apr 13, 2020: https://www.rpki-
| client.org/txt/rpki-client-6.6p1.txt
|
| * https://man.openbsd.org/rpki-client
|
| Looks like there may be problems with the mirror sites, a
| generated tarball is on the official portable github, but it may
| be worth waiting for an official announcement as github can re-
| roll these (it's not an uploaded release asset):
| https://github.com/rpki-client/rpki-client-portable/releases
| job wrote:
| please check back in a few days, we are almost there.
|
| you can also work with https://github.com/rpki-client/rpki-
| client-portable currently runs on a bunch of systems! coming to
| packages in the popular formats close to you soon!
| notaplumber wrote:
| Thanks for the update!
| Liblor wrote:
| A professor at my University mentioned that when he was a
| student, the professors at that time claimed that the security of
| BGP is a solved problem and nobody is going to talk about it in
| ~2 years. This was +20 years ago. He has spent a lot of his
| research on an alternative for BGP called SCION[1], as the
| adaption of BGPSec is not very straight forward and rather an
| ugly fix. I think it is pretty interesting that the problems of
| BGP are not discussed more widely and often.
|
| [1] https://www.scion-architecture.net/
| bifrost wrote:
| There has been tooling for generating proper route filtering
| for quite some time now, the problem is virtually nobody uses
| it.
| tptacek wrote:
| It would be interesting to read more about the _problems_ with
| RPKI. The set of organizations that need to implement RPKI to
| make it effective is pretty small, and yet it 's been a long slog
| to get it even to this point. It's not like network engineers at
| Google, Comcast, and Verizon are unfamiliar with it. What's going
| wrong?
| q3k wrote:
| Certainly ARIN being weird [1] and not allowing to distribute
| their TAL (~CA cert, but for RPKI ROAs), or resulting RPKI data
| freely doesn't help.
|
| [1] - https://www.arin.net/resources/manage/rpki/rpa.pdf
| dsl wrote:
| IRRs already solves this problem. RPKI just adds crypto because
| hand waving reasons.
|
| Providers won't implement RPKI for the same reason they haven't
| implemented IRR filtering or BCP38 for the last 10 years. It
| adds operational overhead, adds another thing that might go
| wrong, and there is no financial incentive.
| kitteh wrote:
| IRR has data issues. RIRs put some control around this (tying
| prefix to org), but plenty of trash in the other IRRs (people
| claiming they own /12s they don't, etc). Also the chain of
| people using as-sets to mark who their customers are is
| busted. People are being way too broad by putting peers in
| their set for networks that aren't their transit customers -
| and prefixes get permitted.
|
| The BCP38 war is lost. Credit to those who try to do better
| but it's the hosting shops who are the biggest offenders.
| Most broadband and cloud providers do this proper. I chase
| down tcp syn reflection attacks and they always come from the
| same types of hosters.
| pathseeker wrote:
| RPKI doesn't sign hops in the path for a BGP update. That means
| to hijack a prefix, all you need to do is to take a legitimate
| route and re-advertise it with your AS as the second hop in the
| path.
|
| This isn't as damaging as being able to advertise a smaller
| prefix because it won't send _all_ traffic to you. It will just
| send from routers where your path is shorter than the original.
|
| To actually prevent hijacking via path shortening attacks like
| this, you need a full BGPSEC implementation
| https://en.wikipedia.org/wiki/BGPsec which is a much higher
| barrier than RPKI because the crypto operations jump 1 or 2
| orders of magnitude (signing every re-advertised route rather
| than just originated routes).
|
| So RPKI gets the cert infra in place, but it doesn't really
| fully solve the problem.
| londons_explore wrote:
| A modern CPU can do how many thousands of signatures per
| second?
|
| How many internet routes change per second?
|
| How many dollars per second would pay for enough CPU's to
| sign every changed route? I'd bet less than one... I'd guess
| 1000x less than one...
| bifrost wrote:
| Routers don't typically use PC cpus.
| job wrote:
| For the BGP portion of the work they absolutely do.
| bifrost wrote:
| I'm not sure which platform you're talking about, mine
| uses PPC, which hasn't been in a desktop in quite some
| time.
|
| kern.version: JUNOS 18.XXX.X #0: XXXX-XX-XX 03:28:10 UTC
| builder@svl-junos-p001:/volume/build/junos/18.X/release/1
| 8.XXX.X/obj/powerpc/junos/bsd/kernels/JUNIPER-PPC/kernel
|
| There certainly are some routers that use x86 based CPUs,
| but they're embedded versions which you'd be unlikely to
| use on a PC.
| londons_explore wrote:
| Nothing stops you hooking up a regular PC to do route
| validation and run the BGP protocol and stuff, and load
| validated routes into any router you choose.
| bifrost wrote:
| There are lots of things stopping that...
|
| The first namely being that nobody is going to do that
| unless they have too much time on their hands and don't
| actually run a real network. "Just loading routes" into a
| router is not really that straightforward.
| job wrote:
| You can easily do origin validation on that type of CPU.
| It's a very efficient lookup.
| bifrost wrote:
| I guess we'll see what happens TBH. I didn't realize it'd
| been available in JunOS since 12.2 which covers a variety
| of devices (even some old stuff I've seen on customer
| sites), I've yet to come across a site with it deployed.
| Maybe I should do some consulting for folks.
| skissane wrote:
| > mine uses PPC, which hasn't been in a desktop in quite
| some time
|
| Raptor sells desktops with IBM POWER9 CPUs -
| https://www.raptorcs.com/content/base/products.html -
| they are expensive, and the same amount of money would
| buy you a much more powerful x86 system, but they exist.
| bifrost wrote:
| Took me a minute to realize you were Job Snijders too
| lol.
|
| We both know there are still garbagey nets out there
| using ARM32, MIPS and who knows what else out there for
| control plane processing. Only the big guys are gonna
| upgrade to support this.
| korethr wrote:
| But, with RPKI getting the cert infra in place, would that
| not then make it relatively easier to take that 2nd step,
| than when not even RPKI was in place?
| corndoge wrote:
| The same thing that's going wrong with IPv6 adoption.
|
| Edit: It's true. RPKI works, it's just harder to use than not
| using it, and network engineers have been doing bgp without
| rpki since forever. Managing PKI is outside the scope of a
| Cisco flat file and so it's not getting done. Route maps are
| easier to write than managing PKI. In the same vein IPv4
| networks work and have been done since forever and as long as
| it's easier to shim over your v4 core and do carrier NAT and
| memorize dotted quads v6 will not get done with haste.
| job wrote:
| I've made an actual study of implementing RPKI's outcome in
| the route-map language, and its not pretty:
| https://github.com/job/rpki-ov-route-map
|
| I recommend using RTR and native origin validation, not to
| depend on the route-map language to accomplish the task ;-)
| eastdakota wrote:
| The excuse used to be there wasn't adequate tooling. That's
| changed over the last 18 months. See, for example, the open
| source GoRTR tool our team released:
|
| https://github.com/cloudflare/gortr
|
| And the fact that major ISPs with complex networks like AT&T,
| NTT, and Telia have implemented it proves it's possible.
| SEAthr0waway wrote:
| There's a few challenges with the adoption/deployment of RPKI.
|
| Remember, there are two parts here: -Signing your IP address
| space (generating ROAs to reference your Origin ASN and Max
| Prefix Length). -Implementing Origin Validation in your network
| (getting an RPKI validator, grabbing ROAs, talking RTR to
| routers).
|
| There's also another aspect here worth calling out. Which is
| that RPKI at the moment doesn't address path validation.
| Basically, stopping routing leaks or addressing as-path
| spoofing. AS Path Authorization is still in the early days at
| the IETF, but the idea is people can piggyback off the existing
| RPKI infrastructure to implement it without making any major
| changes. Some folks will say because there is no ASPA - that
| Origin Validation isn't worth the effort, but I disagree with
| that - any bit helps to stop hijacks.
|
| Going back to ROA generation, there are two ways to sign
| announcements. You can go to your RIR and use their APIs or
| website to do it. Some of the RIRs have okay APIs, some are not
| so great (which is a pain if you are into automation). You can
| run in delegated RPKI mode and do your own CA, but that is a
| fair amount of work and only a few people on the planet do it
| (but props to those people who have open sourced the s/w and
| making this easier). The other two challenges with ROA
| generation are that if you screw it up, it's real painful to
| unwind. Revoking the ROA can take hours to take effect, or
| publishing a new/corrected ROA can take hours. If you screw up
| and specify the wrong ASNs (or lets say you migrate ASNs over),
| or screw up the max prefix length, you can invalidate your
| address space on the Internet and blackhole yourself. The other
| issue is with ARIN - specifically the fact that people running
| RPKI validators have to deliberately accept the ARIN Trust
| Anchor for legal reasons (ARIN indemnification). There is
| evidence that some people are installing the validators and not
| adding ARINs trust anchor, resulting in not accepting any ROAs
| that went through ARIN - which is a big chunk of the Internet.
|
| As for Origin Validation, there have been some great open
| source efforts in the last few years to make this easier to
| adopt (and big thanks to those whove lowered the bar here).
| That said, it still means building/deploying this in a robust
| way, enabling RTR on all your routers and writing policy to
| reject invalids. It's just a bunch of work and for some
| networks, it takes time to roll that out globally. Then there
| is the question of which routes do you apply validation on?
| What if your have customers who screwed up ROAs? Now you have
| to coordinate and get them to clean up their game before you
| turn on the switch or poke holes (nasty). Finally, you have to
| agree that you are going to essentially drop invalid prefixes
| for destinations on the Internet. That means if someone on the
| other side of the world screws up a ROA, you're not routing to
| them. You've got to be prepared to tell a customer why they
| can't reach their destination on your network, but another
| network without origin validation can (like a competitor).
|
| that said, there is no reason to not sign your address space
| today and start rolling origin validation. there are a number
| of network operators in the right spots (irc, mailing lists)
| who are there to help you and give you guidance if you need it.
|
| ps - hi tom. i still have your enteract card from years ago and
| recall meeting you a few times at the third coast cafe.
| tptacek wrote:
| Whoah. Don't leave me hanging like that! My email's in my
| profile.
| eastdakota wrote:
| More details on the problem of BGP hijacking and how the
| IsBGPSafeYet.com test was implemented:
| https://blog.cloudflare.com/is-bgp-safe-yet-rpki-routing-sec...
| eastdakota wrote:
| Also Wired story: https://www.wired.com/story/cloudflare-bgp-
| routing-safe-yet/
| lordleft wrote:
| I have no comment re: the actual campaign but I find the site
| wonderfully clean.
| devmunchies wrote:
| going on a tangent here... I looked at the stylesheet
| (https://isbgpsafeyet.com/index.css?v=24) and saw things like
| `border-top-color: currentColor;` and other variables used in
| plain CSS that I didn't even know you could do.
| adamschwartz wrote:
| (Designer here) YES! `currentColor` is amazingly useful and
| supported everywhere https://caniuse.com/#feat=currentcolor
| rodiger wrote:
| Looks like all the animations were keyframed manually, pretty
| sweet!
| daxfohl wrote:
| Does this solution apply to private networks? I learned first
| hand how dangerous it can be when I brought down our datacenter
| with an accidental BGP announcement.
| kitteh wrote:
| You can do this. I know a few large well know networks which
| have suffered from internal BGP hijacks within their data
| centers from different business units stepping on each other.
| You can either try to implement via strict route policies or
| try to do RPKI.
| amelius wrote:
| It seems to me that trust is not a global thing. If A trusts B
| then that does not mean that C would also trust B. Does the
| protocol capture that principle?
| tialaramex wrote:
| A PKI provides us with a globally trusted answer about identity
| only. If there is no global consensus about identity then you
| don't actually have a network.
|
| If you don't agree that this is news.ycombinator.com and
| believe instead it's 4chan or Reddit, then the Web PKI can't
| help you, and "improving" the Web PKI to some people decide
| this is Apple and others that it's PornHub is pointless. If you
| want other names, go build your own network.
|
| In RPKI the identities aren't DNS names like in the Web PKI
| they're number resources - IP addresses and Autonomous System
| numbers. Again though, if you can't agree with everybody else
| about global identity you can't participate in the network.
|
| If you believe maybe 1.1.1.1 is the IP address of your PC and
| everybody else thinks it's a distributed DNS service run by
| Cloudflare, there's no purpose to trying to allow us to "agree
| to disagree". We're right, and you're wrong, go away.
|
| Having global agreement about identity doesn't magically mean
| we all agree on who to trust, just because I agree with you
| that Reddit is Reddit, doesn't mean I agree about how much
| faith to put in a post you saw there.
| AnotherGoodName wrote:
| No it doesn't.
|
| I remember the first time i setup a rack of servers in a cage
| in a datacenter for a company i founded. We bought a block of
| IPs in bulk and then we bought an interconnect from a provider
| within the datacenter. To get those IPs pointing to our server
| we had our severs announce ownership over BGP. It's that easy.
|
| Usually BGP messages are filtered out by routers. Otherwise
| home users would announce ownership of the Google addresses and
| have all those messages come to them for example. But if you
| have access to an interconnect in a datacenter you can state
| you own whatever IP addresses you want. There's really nothing
| at all stopping it right now.
| icedchai wrote:
| Many upstream transit providers have route filters in place.
| They won't accept any route, like they did in the 90's. Some
| still do, of course.
|
| Also, normally you have your _router_ announce routes over
| BGP, not your _servers_.
| DyslexicAtheist wrote:
| the most promising replacement is the SCION[1] project. See
| section "Authentication and PKI"[2]. It's already used by
| SwissCom and another CH based ISP. It can do path selection, geo-
| fencing, and traffic shaping. Really cool DDoS mitigation[3] as
| well. It has been previously discussed on HN[4].
|
| [1] https://www.scion-architecture.net/
|
| [2] https://www.scion-architecture.net/pages/publications/
|
| [3] https://news.ycombinator.com/item?id=21546214
|
| [4]
| https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
| bifrost wrote:
| I'm not sure thats truly "promising" in any sense :)
| Bluecobra wrote:
| I would argue that for BGP to be safe, all ~68,000 autonomous
| systems will need to embrace RPKI, not just a handful of
| ISPs/telcos/CDNs. Akamai is announcing ~2,300 prefixes, shouldn't
| they use RPKI?
| eastdakota wrote:
| Yes, though it's a bit like if every airline implemented an
| accurate COVID-19 health check. You'd still have local
| problems, but the infection would keep from spreading
| worldwide. In the case of BGP, if the major transit providers
| properly filter routes, hijacks do much less damage to the
| broad network.
| dsl wrote:
| How are you verifying compliance? It looks like to pass the
| test all I need to do is implement filtering on my
| interconnects with Cloudflare (or just drop 103.21.244.0/24
| entirely).
|
| To your example, airlines could screen passengers flying out
| of Eastdakota Regional Airport but nowhere else.
| eastdakota wrote:
| We can always change up the bad IP range announced.
|
| But, more generally, I think the network engineers at ISPs
| want to implement RPKI. It's the managers who haven't
| prioritized. Hopefully this helps escalate it as a
| priority.
| bifrost wrote:
| Very few people want to implement RPKI, those that are
| doing it either are really hot for it or are being forced
| to do it.
| larkster wrote:
| Semi-tangential, but an interesting alternative to RPKI that uses
| blockchain: https://ieeexplore.ieee.org/abstract/document/8751229
| strbean wrote:
| I remember doing an IP range scan with nmap from an EC2 instance
| in the early days, and finding a bunch of exposed BGP routers. I
| wonder how vulnerable they were.
| bifrost wrote:
| TLDR; Not very unless they were general purpose operating
| systems vs network operating systems.
___________________________________________________________________
(page generated 2020-04-17 23:00 UTC)