4 ms·

Isn't the internet in the same situation, with BGP being assumed to be done between trusted parties?

by est31 6y ago

darkr 6y ago
Yes, but increasingly traffic is strongly encrypted, with users able to exert some level of control over that encryption
pas 6y ago
The first rule of BGP is to filter what you get. Don't just blindly accept whatever the peer advertises. The second rule is obvious, but for the third there's also a lot of knobs for traffic engineering with BGP. And on top of that there's RPKI [ https://blog.cloudflare.com/rpki/ https://blog.cloudflare.com/rpki/ ] I guess all of the big telcos have some homegrown ossified hacky "solution" that also serve as a minimal kind of "firewall" for SS7. (Basically I imagine that there's a lot of hardcoded rules for phone numbers, country codes and operators. Sure, they probably are an opposite of a problem for national intelligence services, after all it's easier to go by unnoticed in the noise, but they at least help with a total BGP-like hijack of a whole country code by an operator.)
- g_p 6y ago
  Big telcos need to do SS7 filtering and (based on the interface they receive the message from) limit what can be done. The trouble is that SS7 lacks proper authentication, so it's like setting Linux iptables rules only based on the interface name - eth0, eth1 etc. There are product-based SS7 protocol firewalls available that try to detect the "patterns" of signalling used to do "bad things", and block and report them. Part of the problem with SS7 is that it's complex, and you can't easily restrict who says what - if you port your number from Operator A to Operator B, your number prefix still sits in A's range, and calls are signalled to Operator A. They can then tell you to try Operator B. B may then need to tell you the user is roaming and how to reach them. But yes, current firewlls leave a lot to be desired! There's a number of good talks from CCC about SS7 - one is https://media.ccc.de/v/31c3_-_6249_-_en_-_saal_1_-_201412271715_-_ss7_locate_track_manipulate_-_tobias_engel https://media.ccc.de/v/31c3_-_6249_-_en_-_saal_1_-_201412271...
  - ng55QPSK 6y ago
    as far as i understand, there are no operators in Europe (maybe UK) anymore that don't run filtering on SS7. btw: SS7 is the legacy system and not part of 4G/5G.
    - g_p 6y ago
      They should all be running filtering, although not all filtering is as effective as each other. As you say, this is the legacy system, but it's still a huge problem for them!
      - ng55QPSK 6y ago
        My colleagues who do intrusion testing (for operators e.g.) tell me: We have not seen SS7 attacks in Europe for long time. The remaining attack surfaces are in the middle-east and north america.
        deleted 6y ago
        [deleted]
        g_p 6y ago
        That's promising! It's now 5 years ago, but Telenor had a fairly big outage caused by malformed SS7 inbound signalling. Not sure if there's been anything since, but it certainly was an issue relatively recently. Hopefully with the (slow) move to 4G and IMS calling, we can turn the page on SS7 attacks soon.
  - amaccuish 6y ago
    > if you port your number from Operator A to Operator B, your number prefix still sits in A's range, and calls are signalled to Operator A. They can then tell you to try Operator B. B may then need to tell you the user is roaming and how to reach them. But yes, current firewlls leave a lot to be desired! Not in all networks as far as I'm aware. UK is an annoying example of not having a central database of ported numbers (with ACQ), where a redirect is setup in the old network. I once ported my number in the UK and had huge issues receiving international calls or 2FA codes, it took me ages to work out and only got it sorted by leaving the number entirely and getting a new one. Otherwise, like here in Germany, it's done with a proper database and the call never passes through the old network.
- sneak 6y ago
  I think RPKI poses a grave danger in terms of censorship. Anyone who controls the centralized database of public keys to prefixes can instantly and automatically take anyone offline, if all other routers refer to them in real-time for building route tables.
  - pas 6y ago
    Hmm, yes, but not really. Yes, because it's a centralized meta-control plane of/for BGP. But no, because after all IP address space is already centrally managed anyway: IANA -> RIRs (-> LIRs), but not really, because each AS decides what to do with RPKI data. So it's much better than parsing RIPE plain text query reults, and it's the correct fix for hijackings. "Real-world censorship resistance" is not in the threat model for the current Internet at the RPKI/BGP/RIR level, but it's very much in scope for high-level protocols like DNS, TLS, HTTP (as privacy concerns). See https://tools.ietf.org/html/rfc4593 https://tools.ietf.org/html/rfc4593 and https://tools.ietf.org/html/rfc7132 https://tools.ietf.org/html/rfc7132 Regular ("in-band") DoS or tampering attacks on RPKI databases and CAs (certificate authorities) are of course taken into consideration - even by nation states. Though these particular RFCs don't offer a particularly systematic and ironclad solution. (The problem is punted to users: "just use (stale data and) caches, decide for yourself what to do if the central DB is unavailable".) Likely there's some other RFCs that offer better answers with - hopefully - more operational detail. Building a truly global efficient/high-bandwidth/low-cost "infinitely" censorship resistant Internet is (very) hard. Currently traffic passes through various networks, those "autonomous systems" have the capability to direct (and filter, eg. null route) traffic. Source routing in theory might help with working-around bad AS-es, but even detecting such AS-es seems hard theoretically. And on top of all that there's the economic aspect. (How would the network/users/operators incentivize each other to work around bad ASes?)
g_p 6y ago
At transit layer to an extent yes, but with every underlying user of the connectivity considering the connection compromised, and therefore using their own measures on the untrusted link. Hence IPsec and site to site/road warrior VPN - the underlying connectivity is regarded as untrusted by any sane user. In telecoms, anyone on the SS7 network can make a request to find a given number, or say the number is available and can be reached by routing via their network.
walrus01 6y ago
Any reputable and clueful transit provider these days is performing automated RPKI validation of the prefixes announced to them. In addition to whatever prefix lists might be manually set up on a bgp session. That's only a small piece of the puzzle in network security generally, but is sure better than how SS7 works right now.
rcarmo 6y ago
Most carriers already use PKI for their BGP traffic. It's not the Wild West anymore (although of course you'll always find some weak link if you backtrack AS announcements far enough)

Isn't the internet in the same situation, with BGP being assumed to be done between trusted parties?

by est31 6y ago

Isn't the internet in the same situation, with BGP being assumed to be done between trusted parties?

Yes, but increasingly traffic is strongly encrypted, with users able to exert some level of control over that encryption

pas 6y ago

The first rule of BGP is to filter what you get. Don't just blindly accept whatever the peer advertises. The second rule is obvious, but for the third there's also a lot of knobs for traffic engineering with BGP. And on top of that there's RPKI [ https://blog.cloudflare.com/rpki/ https://blog.cloudflare.com/rpki/ ] I guess all of the big telcos have some homegrown ossified hacky "solution" that also serve as a minimal kind of "firewall" for SS7. (Basically I imagine that there's a lot of hardcoded rules for phone numbers, country codes and operators. Sure, they probably are an opposite of a problem for national intelligence services, after all it's easier to go by unnoticed in the noise, but they at least help with a total BGP-like hijack of a whole country code by an operator.)

g_p 6y ago
Big telcos need to do SS7 filtering and (based on the interface they receive the message from) limit what can be done. The trouble is that SS7 lacks proper authentication, so it's like setting Linux iptables rules only based on the interface name - eth0, eth1 etc. There are product-based SS7 protocol firewalls available that try to detect the "patterns" of signalling used to do "bad things", and block and report them. Part of the problem with SS7 is that it's complex, and you can't easily restrict who says what - if you port your number from Operator A to Operator B, your number prefix still sits in A's range, and calls are signalled to Operator A. They can then tell you to try Operator B. B may then need to tell you the user is roaming and how to reach them. But yes, current firewlls leave a lot to be desired! There's a number of good talks from CCC about SS7 - one is https://media.ccc.de/v/31c3_-_6249_-_en_-_saal_1_-_201412271715_-_ss7_locate_track_manipulate_-_tobias_engel https://media.ccc.de/v/31c3_-_6249_-_en_-_saal_1_-_201412271...
- ng55QPSK 6y ago
  as far as i understand, there are no operators in Europe (maybe UK) anymore that don't run filtering on SS7. btw: SS7 is the legacy system and not part of 4G/5G.
  - g_p 6y ago
    They should all be running filtering, although not all filtering is as effective as each other. As you say, this is the legacy system, but it's still a huge problem for them!
    - ng55QPSK 6y ago
      My colleagues who do intrusion testing (for operators e.g.) tell me: We have not seen SS7 attacks in Europe for long time. The remaining attack surfaces are in the middle-east and north america.
      - deleted 6y ago
        [deleted]
      - g_p 6y ago
        That's promising! It's now 5 years ago, but Telenor had a fairly big outage caused by malformed SS7 inbound signalling. Not sure if there's been anything since, but it certainly was an issue relatively recently. Hopefully with the (slow) move to 4G and IMS calling, we can turn the page on SS7 attacks soon.
- amaccuish 6y ago
  > if you port your number from Operator A to Operator B, your number prefix still sits in A's range, and calls are signalled to Operator A. They can then tell you to try Operator B. B may then need to tell you the user is roaming and how to reach them. But yes, current firewlls leave a lot to be desired! Not in all networks as far as I'm aware. UK is an annoying example of not having a central database of ported numbers (with ACQ), where a redirect is setup in the old network. I once ported my number in the UK and had huge issues receiving international calls or 2FA codes, it took me ages to work out and only got it sorted by leaving the number entirely and getting a new one. Otherwise, like here in Germany, it's done with a proper database and the call never passes through the old network.
sneak 6y ago
I think RPKI poses a grave danger in terms of censorship. Anyone who controls the centralized database of public keys to prefixes can instantly and automatically take anyone offline, if all other routers refer to them in real-time for building route tables.
- pas 6y ago
  Hmm, yes, but not really. Yes, because it's a centralized meta-control plane of/for BGP. But no, because after all IP address space is already centrally managed anyway: IANA -> RIRs (-> LIRs), but not really, because each AS decides what to do with RPKI data. So it's much better than parsing RIPE plain text query reults, and it's the correct fix for hijackings. "Real-world censorship resistance" is not in the threat model for the current Internet at the RPKI/BGP/RIR level, but it's very much in scope for high-level protocols like DNS, TLS, HTTP (as privacy concerns). See https://tools.ietf.org/html/rfc4593 https://tools.ietf.org/html/rfc4593 and https://tools.ietf.org/html/rfc7132 https://tools.ietf.org/html/rfc7132 Regular ("in-band") DoS or tampering attacks on RPKI databases and CAs (certificate authorities) are of course taken into consideration - even by nation states. Though these particular RFCs don't offer a particularly systematic and ironclad solution. (The problem is punted to users: "just use (stale data and) caches, decide for yourself what to do if the central DB is unavailable".) Likely there's some other RFCs that offer better answers with - hopefully - more operational detail. Building a truly global efficient/high-bandwidth/low-cost "infinitely" censorship resistant Internet is (very) hard. Currently traffic passes through various networks, those "autonomous systems" have the capability to direct (and filter, eg. null route) traffic. Source routing in theory might help with working-around bad AS-es, but even detecting such AS-es seems hard theoretically. And on top of all that there's the economic aspect. (How would the network/users/operators incentivize each other to work around bad ASes?)

g_p 6y ago

At transit layer to an extent yes, but with every underlying user of the connectivity considering the connection compromised, and therefore using their own measures on the untrusted link. Hence IPsec and site to site/road warrior VPN - the underlying connectivity is regarded as untrusted by any sane user. In telecoms, anyone on the SS7 network can make a request to find a given number, or say the number is available and can be reached by routing via their network.

walrus01 6y ago

Any reputable and clueful transit provider these days is performing automated RPKI validation of the prefixes announced to them. In addition to whatever prefix lists might be manually set up on a bgp session. That's only a small piece of the puzzle in network security generally, but is sure better than how SS7 works right now.

rcarmo 6y ago

Most carriers already use PKI for their BGP traffic. It's not the Wild West anymore (although of course you'll always find some weak link if you backtrack AS announcements far enough)