Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

Should FCC focus on SS7 vulnerabilities or BGP vulnerabilities?

Additional comments from Kevin Briggs: "I have seen what appears to be reliable information related to numerous other exploits based on SS7 and Diameter that go beyond location tracking. Some of these involve issues like (1) the monitoring of voice and text messages, (2) the delivery
of spyware to targeted devices, and (3) the influencing of U.S. voters by overseas countries using text messages."

Are APNs like a vpn for mobile devices to access the public internet? Based on the experience that I used Mobile roaming outside my country. The provider would connect back to the original country via local providers.

The FCC has spent the last several years hounding us voice providers over spam calls. They’ve implemented laws. They have required us to do paperwork. Have they been successful in that task?

Now do you think they’re going to properly understand what an SS7 or vulnerability is?

The FCC organised several sessions (private and public) where they
invited knowledgeable people from this community to help edifice them on
what BGP is and what risks exist.

Watch https://www.youtube.com/watch?v=VQhoNX2Q0aM to see our very own
Tony Tauber looking sharp in a nice suit! :slight_smile:

FCC staff attended NANOG & IETF meetings to further explore and discuss
the problem space in the hallway track. If anything, I think the FCC
made a proper effort to connect with various stakeholders and learn from
them.

Kind regards,

Job

So the FCC is efficient enough to understand BGP vulnerabilities but not efficient enough to understand what a spam call is?

The FCC absolutely is going to have experts in house who know what SS7 is and who are likely aware of the basics of how it works and what vulnerabilities that might "obviously" lead to. Whether they have anyone in house who knows it in technical detail and would be able to audit it from a protocol and implementation level to come up with novel vulnerabilities or even really understand in detail how published vulnerabilities work is perhaps another matter, but they don't necessarily need that to come up with effective advisory guidelines or even mandatory regulations if they invite proper comment from the industry and review them.

Regulating the phone system is not exactly a new thing for the FCC, after all.

I think the issue with their lack of effectiveness on spam calls is due to the comparatively small number of players in the PSTN (speaking of both classic TDM and modern IP voice-carrying and signaling networks) world allowing lots of regulatory capture. That's going to keep the FCC from issuing mandatory rules much beyond what much of the industry is on the road to implementing already to keep their customers placated.

The Internet is at least a little different in that it is set up more as a system where every player has some degree of parity in operation regardless of their size or footprint, and the self-governance rulemaking is much more out in the open. I suspect that's why we've had some success with getting BGP security not just addressed in guidance but actually practically improved.

That self-governance and openness also improves the FCC's ability to gather information and I suspect also improves the quality and relevance of official public comments that they receive.

I do think the FCC should at least consider looking at SS7 security...and perhaps they should attempt to just get rid of it. It's really only relevant for legacy TDM networks at this point, from what I can tell, with essentially all modern IP voice-carrying networks instead using SIP. Maybe it's time for it to just die along with the TDM PSTN which a lot of states are essentially killing off by removing mandatory service offering, anyway.

Ben Cartwright-Cox's axiom (paraphrased): "The real reason the Internet
works is that we want it to work."

Kind regards,

Job

I think it should be pointed out that the STIR/SHAKEN crowd doesn't really get it either. The problem is mainly a problem of the border between bad guys and the onramps onto the PSTN. SIP has made that dirt cheap and something anybody can do it for nothing at all down in their basements. It's essentially the same thing as email back in the days of open relays and no submission auth. STIR/SHAKEN obfuscated that problem by trying to solve the problem of who is allowed to assert what E.164 address when it's much easier to solve in the "where did this come from and who should I blame?" realm. I don't hear anybody moaning about deploying DKIM except maybe spammer sites that don't want accountability and their onramp sites that turn a blind eye making money off them. They care these days because for legit senders, baddies cost them money due to deliverability. It would have been trivial to attach a DKIM like signature to SIP messages and be done with it instead of trying to boil the legacy addressing ocean. I should know, I did that for shits and giggles about 20 years ago.

Mike

It appears that Brandon Martin <lists.nanog@monmotha.net> said:

I think the issue with their lack of effectiveness on spam calls is due
to the comparatively small number of players in the PSTN (speaking of
both classic TDM and modern IP voice-carrying and signaling networks)
world allowing lots of regulatory capture.

It's the opposite. SS7 was designed for a world with a handful of
large trustworthy telcos. But now that we have VoIP, it's a world of a
zillion sleasy little VoIP carriers stuffing junk into the network.
The real telcos have no desire to deliver spam calls. Everything is
bill and keep so they get no revenue and a lot of complaints.

Mike is right that STIR/SHAKEN is more complex than it needs to be but
even after it was widely deployed, the telcos had to argue with the
FCC to change the rules so they were allowed to drop spam calls which
only changed recently. That's why you see PROBABLE SPAM rather than
just not getting the call.

R's,
John

I was screaming at the top of my lungs that P-Asserted-Identity was going to bite them in the ass 20 years ago. And then they eventually came up with something that solved the wrong problem in the most bellheaded way possible 15 years later. Bellheads should not be trusted with internet security. The FCC is most likely not blameless here either but the telcos/bellheads most certainly aren't either. Anybody who thinks this is an either/or problem is wrong.

Mike

When roaming, the home mobile network has two options to deliver data services to their customer:

Sigh, industry hasn't solved spoofing and routing insecurity in two decades. If it was easy, everyone would have fixed it by now.

Industry has been saying 'don't regulate us' for decades.

Just because they were presented with the information doesn’t mean they understand.
Just because they understand doesn’t mean they execute based on that information.

Just because they were presented with the information doesn’t mean they understand.

It’s our job as operators to get involved and help them understand as best as can be done, so that the proposals are as well informed as possible.

Just because they understand doesn’t mean they execute based on that information.

No set of rules will ever be perfectly executed or implemented. Doesn’t matter if it’s a government regulation or internal company rule. You try to start from a good place, learn what works and what doesn’t, and adjust accordingly.

The FCC's job isn't to solve technical problems.

Instead it is attempting to get CEOs, business managers and venture capital firms to include these public policy requirements as part of their business decision making. Impact business budgets and decision making to fix public problems.

FCC is setting goals (and punishments). It is up to industry how it wants to solve the technical problems to achieve the FCC's business requirements.

Sigh, industry hasn’t solved spoofing and routing insecurity in two
decades. If it was easy, everyone would have fixed it by now.

Industry has been saying ‘don’t regulate us’ for decades.

I hope the regulations are more outcome focused.

RPKI is not a good solution for all networks, especially those that are non-transit in nature and take reasonable mitigation actions like IRR prefix lists.

RPKI is not a good solution for all networks, especially those that are non-transit in nature and take reasonable mitigation actions like IRR prefix lists.

Some of the largest , most impactful route leaks have come from non-transit networks reliant on IRR managed prefix lists.

RPKI is not a good solution for all networks, especially those that are non-transit in nature and take reasonable mitigation actions like IRR prefix lists.

Some of the largest , most impactful route leaks have come from non-transit networks reliant on IRR managed prefix lists.

Can you be more specific?

Was it malicious?

Who in the usa was impacted ?

Keep mind rpki only solves misorigination.

https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today

Keep mind rpki only solves misorigination.

I’m very well aware that RPKI only solves misorigination. But misorigination is a significant problem, so that’s a good problem to be solved.

Not engaging with RPKI because it doesn’t perfectly solve every BGP-adjacent issue is a poor argument.

The FCC has spent the last several years hounding us voice providers
over spam calls. They've implemented laws. They have required us to
do paperwork. Have they been successful in that task?

Now do you think they're going to properly understand what an SS7 or
vulnerability is?

The FCC absolutely is going to have experts in house who know what SS7 is and who are likely aware of the basics of how it works and what vulnerabilities that might "obviously" lead to. Whether they have anyone in house who knows it in technical detail and would be able to audit it from a protocol and implementation level to come up with novel vulnerabilities or even really understand in detail how published vulnerabilities work is perhaps another matter, but they don't necessarily need that to come up with effective advisory guidelines or even mandatory regulations if they invite proper comment from the industry and review them.

I'm not so sure about the FCC or any government agency having technical experts in-house. Possibly they exist, but the chances of their voices being heard are low. Not only that, but I feel that any time an expert isn't actually working actively in their field, they quickly stop being an expert.

Regulating the phone system is not exactly a new thing for the FCC, after all.

No, it isn't. And yet, the same old problems seem to persist, primarily caused by the same companies, doing the same things they've always done. When the fines are far lower than the profits, nothing will really change. See rural call termination as an example.

I think the issue with their lack of effectiveness on spam calls is due to the comparatively small number of players in the PSTN (speaking of both classic TDM and modern IP voice-carrying and signaling networks) world allowing lots of regulatory capture. That's going to keep the FCC from issuing mandatory rules much beyond what much of the industry is on the road to implementing already to keep their customers placated.

Rules are issued and the big companies use armies of lawyers to either influence the writing of the regulations or avoid them completely. In the rare case that a fine is levied, it's negotiated down by the same armies of lawyers to the point where it has no impact on the behavior.

The Internet is at least a little different in that it is set up more as a system where every player has some degree of parity in operation regardless of their size or footprint, and the self-governance rulemaking is much more out in the open. I suspect that's why we've had some success with getting BGP security not just addressed in guidance but actually practically improved.

So, the Internet has done a better job of self-regulating than the PSTN being regulated by the FCC? It seems then that the better plan would be to not increase regulation, but decrease it.

That self-governance and openness also improves the FCC's ability to gather information and I suspect also improves the quality and relevance of official public comments that they receive.

The FCC is unfortunately ultimately a political organization. The amount and type of regulation waxes and wanes depending on which party holds the majority of chairs. It would be amazing if that wasn't the case, but it's clear that unless something changes drastically in how the org is structured, that's the reality we have to deal with. Remove politics and money from the process, and we'd see different results.

I do think the FCC should at least consider looking at SS7 security...and perhaps they should attempt to just get rid of it. It's really only relevant for legacy TDM networks at this point, from what I can tell, with essentially all modern IP voice-carrying networks instead using SIP. Maybe it's time for it to just die along with the TDM PSTN which a lot of states are essentially killing off by removing mandatory service offering, anyway.

As much as most of us would like to be 100% SIP, it's the big guys holding us back with legacy TDM networks and lata tandems. There are plenty of telcos that are completely IP-based voice within their networks, and still have to use SS7 connectivity to connect outside. When - RBOC of your choice here - won't connect via SIP, they're stuck with keeping SS7 going. It's getting better, because there are more options all the time to move away from that RBOC connectivity, but we'd have done it years ago if we'd had any cooperation from the RBOCs and tandems. Any order from the FCC to put an end date on SS7 would need to start with forcing the RBOC's and tandems to upgrade their networks to actually support SIP. Good luck with that when your lata tandem is so old and broke they're running Rockwell 3x50's.

Jason Baugher, Network Operations Manager
405 Emminga Road | PO Box 217 | Golden, IL 62339-0217
P (217) 696-4411 | F (217) 696-4811 | www.adams.net<http://www.adams.net/&gt;
[Adams-Logo]<http://adams.net/&gt;