[HN Gopher] Iraq Blocks Telegram, Leaks Blackhole BGP Routes
       ___________________________________________________________________
        
       Iraq Blocks Telegram, Leaks Blackhole BGP Routes
        
       Author : oavioklein
       Score  : 198 points
       Date   : 2023-08-19 17:55 UTC (5 hours ago)
        
 (HTM) web link (www.kentik.com)
 (TXT) w3m dump (www.kentik.com)
        
       | sieabahlpark wrote:
       | [dead]
        
       | 0xDEF wrote:
       | >disruption was minimized by Telegram's use of RPKI
       | 
       | Telegram has spread their hosting across the three big cloud
       | providers; AWS, Azure, and Google Cloud. It is most likely the
       | cloud providers who have enabled RPKI as a default.
        
         | tiernano wrote:
         | Looks like Telegram has its own asn
         | (https://bgp.he.net/AS62041) so they are announcing the space
         | through the cloud providers. So they would announce their space
         | to was, hcp, azure, etc with the rpki.
        
         | Osiris wrote:
         | For those of us unfamiliar with the term, can you explain RPKI
         | and how it helps?
        
           | sschueller wrote:
           | I didn't know either but I found this little snippet:
           | 
           | Resource Public Key Infrastructure (RPKI) is a security
           | framework by which network owners can validate and secure the
           | critical route updates or Border Gateway Protocol (BGP)
           | announcements between public Internet networks. BGP is
           | essentially the central nervous system of the Internet and
           | one of its fundamental building blocks. The main function of
           | BGP is to facilitate efficient routing between Autonomous
           | Systems (AS), by building and maintaining the Internet
           | routing table. The Internet routing table is effectively the
           | navigation system of the Internet and without it, traffic
           | would be unable to flow between its constituent networks.
           | Unfortunately, routing equipment alone cannot distinguish
           | between legitimate and malicious routing announcements, but
           | network operators who implement RPKI validation and filtering
           | can choose to reject announcements from networks not
           | authorized to advertise those resources. In other words, RPKI
           | is essentially a secure identification system for the BGP
           | route information between autonomous systems.
        
           | salawat wrote:
           | https://www.arin.net/resources/manage/rpki/
           | 
           | Basically, RPKI is to BGP as things like DKIM are to email,
           | or DNSSEC is to the DNS system.
           | 
           | Different AS's announce route prefix's to attract packets
           | from other AS's. Orgs like ARIN and such act as trust anchors
           | (CA's, in Web of Trust parlance) for Network operators who
           | use RPKI clients to validate incoming BGP announcements
           | cryptographically against the trust anchor list.
           | 
           | The idea would be that an Iraqi telco _could_ announce they
           | terminate a prefix they don 't, blackholing the traffic
           | originating from within their network to those prefixes, but
           | they wouldn't get the cryptographic vouch by their RIR, so
           | other AS's would ignore altering their routing tables.
           | Insulating the damage to essentially inside the network that
           | was making the fraudulent announcement.
           | 
           | It could even still be worked around by people internal to
           | that network as long as they cross into another AS's routing
           | domain, say by VPN, which would then allow traffic to route
           | as normal.
           | 
           | There is the argument to be made that RPKI is only as useful
           | as the numbering authorities are capable of maintaining a
           | strict position of neutrality. Thus is the way of all of all
           | Trust. It is alas, the best we have.
        
           | chaz6 wrote:
           | Before RPKI, any network on the internet could announce any
           | prefix (e.g. 2001:630::/32) to any neighbour, whether they
           | had the right to or not. With RPKI, the owner of the prefix
           | has to authorize a network to announce the route, so this
           | helps to prevent networks from hijacking prefixes. One caveat
           | is that it depends upon networks checking the RPKI database
           | when receiving prefixes from neighbours, but pretty much all
           | the major networks do this now.
           | 
           | For more information, there is a good article here:
           | https://phoenixnap.com/kb/rpki
        
             | icedchai wrote:
             | More than 50% of prefixes still don't use RPKI. See
             | https://rpki-monitor.antd.nist.gov/
             | 
             | Many will likely never use it. ARIN, for example, does not
             | allow "legacy" networks to use RPKI unless they sign a
             | registration agreement (and start paying for the
             | privilege.)
        
           | almost_usual wrote:
           | Similar to CAs on the web in RPKI a TA (Trust Anchor) will
           | sign a ROA (Route Origin Authorization X.509 certificate) to
           | certify an ASN can originate routes within an address space.
           | 
           | There are five TAs which are RIRs (Regional Internet
           | Registries) AFRINIC, APNIC, ARIN, LACNIC, and RIPE.
           | 
           | So similar to how your web browser can determine a website is
           | valid or not by checking the certificate is signed by a CA. A
           | network can determine a route is valid or not by checking the
           | ROA is signed by a TA.
        
       | PicassoCTs wrote:
       | Once a ISP goes hostile, all that remains is mesh networking, and
       | navigating data- by having encrypted packages, jump from phone to
       | phone, based upon the wifi location the phone has been near in
       | recent history.
       | 
       | Then you need a zero-day, install software that turns almost all
       | phones into nodes and there is nothing any authority can do to
       | prevent communication ever.
        
         | zakki wrote:
         | As long as there is no phone/device in that network outside
         | Iraq that will not work for Internet. If there is, the
         | ISP/Government can fingerprint the traffic and block the IP of
         | any device outside Iraq. Just like how China FW block VPN
         | traffic.
         | 
         | edit: Adding China FW
        
           | PicassoCTs wrote:
           | Well, you don't send it in.. you just bring it in? Like
           | something smuggled physically? Its slow, admitted, but better
           | having that data come in on some truck driver-smuggled-ssd
           | and reach you by hopping from phone to phone, then not at
           | all.
        
         | WJW wrote:
         | How does that work across oceans? There's a severe lack of mesh
         | nodes on the high seas and all high-bandwidth links across the
         | ocean highly centralized in just a couple of companies.
         | 
         | Also, most people would definitely not appreciate their
         | personal devices being hijacked as a mesh network for their
         | neighbors teen watching tiktoks or whatever. Any such zero day
         | exploit would be patched pretty quickly.
        
           | PicassoCTs wrote:
           | Well aiport traveling nodes connect across the oceans
           | regularly. You can even predict that travel and make it a
           | sort of routing announcement.
           | 
           | Example: Guy living in NY on the regular, traveling once a
           | year to cuba and back. So somebody with a message to cuba,
           | passes it along - it rides to the airport, and hops from a
           | employee cellphone to the guy boarding his holiday plane. Add
           | the transmission software being a virus for plausible
           | deniability..
        
             | WJW wrote:
             | Gotta ask again: how much GB of storage on their phone do
             | you think the average air traveler would be willing to
             | donate to people so that their transoceanic fellows would
             | be able to watch tiktoks from their homeland? How about
             | porn? And given that GP seemed to dream of communications
             | uncensorable by governments, how long would it be until a
             | mandatory phone scan would be required before boarding a
             | flight? For that matter, why would a government like Iran
             | or North Korea even let phones into their country without a
             | thorough cleansing of non-sanctioned information
             | beforehand?
             | 
             | I'm all for balancing the power of governments with the
             | power of their citizens but mesh networks have so many
             | practical downsides that they are just Not The Way tbh.
        
         | [deleted]
        
       | technocratius wrote:
       | Sounds interesting! Can someone explain a bit in simple terms
       | what happened here and why it's noteworthy? Thanks :)
        
         | dilyevsky wrote:
         | The way routing works on the internet very simply is a network
         | (like an ISP or connectivity provider) will announce IP prefix
         | and "the origin" - where to send packets matching the prefix.
         | This mechanism is also frequently used by national ISPs to
         | block specific destinations (like Telegram nodes) - they will
         | announce Telegram IP prefixes to be sent to them and then will
         | just toss the packets or try to snoop on sessions. This is
         | known as the "BGP hijack".
         | 
         | These announcement typically only intended for downstream
         | providers (regional Iraqi ISPs in this case) but sometimes
         | "leak" upstream - erroneously announced to the open internet
         | which sometimes cause outages for the whole world. This is what
         | famously happened with YouTube when Pakistan tried to do the
         | same thing in 2008.
         | 
         | In this case the routes "leaked" upstream again like what
         | happened before but seems like outage was mostly prevented by
         | something called RPKI which is basically a technology to attest
         | who _really_ owns which prefix.
        
           | explaininjs wrote:
           | Is this directly at odds with the whole "the internet
           | interprets censorship as damage and routes around it" motif?
        
             | Groxx wrote:
             | Seeing as how the entire internet doesn't still block
             | youtube: no. It routed around it.
             | 
             | The quote has nothing to do with _automatically and
             | invisibly_ routing around censorship, e.g. a techno-system
             | that somehow always works to oppose censorship. It 's just
             | that people will reconnect stuff eventually, bypassing any
             | block somehow. At worst there are always sneakernets.
        
             | WJW wrote:
             | TBH, that is a quote from several decades ago that hasn't
             | kept up with modern censoring technology. When Gilmore
             | originally coined it he was embroiled in a legal dispute
             | with his ISP, I doubt he had BGP hijacks by national
             | governments in mind.
        
             | segfaultbuserr wrote:
             | The original comment was a remark on Usenet newsgroup
             | message filtering. Usenet had a degree of decentralization,
             | a single news server couldn't control the entire network.
             | If the message is filtered at a particular path by a
             | server, at least some other nodes would still receive their
             | own copies via an alternative path, which may then
             | propagate the messages further downstream.
             | 
             | Today's highly-centralized server-client Web architecture
             | does not have this property. Some P2P protocols are closer
             | to the spirit of this quote.
             | 
             | Conclusion: architecture of "the Net" matters a lot (the
             | original quote didn't use the term "Internet").
        
             | dilyevsky wrote:
             | The internet doesn't interpret anything - it's a just a
             | bunch of networks and technologies to pass packets around
             | with some level of redundancy (originally to withstand
             | nuclear strikes on the comms centers).
        
               | explaininjs wrote:
               | It's a metaphor.
        
               | dilyevsky wrote:
               | Ok sure but if router rules say "send these packets over
               | there" that's where they will go (to die). There are no
               | way to "interpret" if the packets are going to the right
               | destination for downstream devices which are totally
               | oblivious to this process if that makes sense
        
               | salawat wrote:
               | What you are homing in on is the problem of trust.
               | 
               | And yes. It is a problem. If your upstream does
               | skulduggerous things, you can't "route around it" from
               | the standpoint of being an endpoint. Your packets will go
               | where your ISP says they go.
               | 
               | Unless...
               | 
               | You take a bit of the routing decision out of their
               | hands, which takes a bit of footwork on your part. For
               | instance, setting up a VPN to a network zone unpolluted
               | by the faulty prefix announcement, which is basically
               | going to be any non downstream of the hostile ISP
               | provider.
               | 
               | Once you're out of that routing zone, normal network
               | visibility is restored. Odds are even a national scale
               | backbone provider is not going to be able to effectively
               | block traffic that's routing out to a proxy, so all the
               | the ISP has really done is made life more difficult for
               | people unaware of how to set up such an arrangement.
               | 
               | Which now that you know about this, it is your duty to
               | spread the knowledge of how to do so far and wide. If
               | someone wants to block it, then that's all the
               | justification needed for frustrating those efforts.
        
               | dilyevsky wrote:
               | VPN traffic is trivially blocked at the ISP level which
               | has been proven by china, russia and others. So no you
               | can't really prevent mass censorship with technology.
        
           | ehsankia wrote:
           | If this node has been known to publish unreliable routes in
           | the past, wouldn't any upstream nodes just put some
           | preventative rules to ignore it / blocklist it? Or is that
           | not feasible?
        
             | dilyevsky wrote:
             | Yes before RPKI especially and still now this technique is
             | commonly used but not even every T1 (backbone) network had
             | done that correctly in the past, hence outages.
        
               | hnarn wrote:
               | By T1 I assume you mean "Tier 1", not to be confused with
               | https://en.wikipedia.org/wiki/T-carrier
        
         | [deleted]
        
         | meltyness wrote:
         | Presumably whichever government is trying to identify users
         | accessing the service, or prevent the spread of information or
         | something.
        
       ___________________________________________________________________
       (page generated 2023-08-19 23:01 UTC)