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? On Thu, May 16, 2024 at 3:53 PM Brandon Zhi <Brandon@huize.asia> wrote:

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.

*Brandon Zhi* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter

This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.

On Thu 16 May 2024 at 20:27, Sean Donelan <sean@donelan.com> wrote:

...

Should FCC focus on SS7 vulnerabilities or BGP vulnerabilities?

https://www.404media.co/email/79f7367c-bd3c-4bff-ac9f-85c738d08bec/ https://www.fcc.gov/ecfs/document/10427582404839/1

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."

On Wed, 15 May 2024, Job Snijders via NANOG wrote:

...

Dear all, FYI: https://docs.fcc.gov/public/attachments/DOC-402579A1.pdf

So the FCC is efficient enough to understand BGP vulnerabilities but not efficient enough to understand what a spam call is? On Thu, May 16, 2024 at 4:20 PM Job Snijders <job@fastly.com> wrote:

On Thu, May 16, 2024 at 04:05:21PM -0400, Josh Luthman wrote:

...

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.

https://www.fcc.gov/news-events/events/2023/07/bgp-security-workshop

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

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

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. On Fri, May 17, 2024 at 11:11 AM Mike Hammett <nanog@ics-il.net> wrote:

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.

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

Midwest-IX http://www.midwest-ix.com

------------------------------ *From: *"Job Snijders via NANOG" <nanog@nanog.org> *To: *"Josh Luthman" <josh@imaginenetworksllc.com> *Cc: *"NANOG [nanog@nanog.org]" <nanog@nanog.org> *Sent: *Thursday, May 16, 2024 3:20:54 PM *Subject: *Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

On Thu, May 16, 2024 at 04:05:21PM -0400, Josh Luthman wrote:

...

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.

https://www.fcc.gov/news-events/events/2023/07/bgp-security-workshop

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

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

Fri, May 17, 2024 at 12:01:14PM -0400, Sean Donelan:

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.

Because the FCC has done such a fantastic job regulating TV and radio or managing their infrastructure investment tax dollars? Perhaps they should stick to comically-sized coffee cups. FCC needs an overhaul, just to advance to the current century for the things they already regulate. For example; besides the power button, TVs now have a channel selector that allows the viewer to choose what they want to watch, so programming does not need to be regulated. Let us stop them from "helping" with the Internet.

On Thu, May 16, 2024 at 07:17:37PM -0400, Brandon Martin wrote:

I suspect that's why we've had some success with getting BGP security not just addressed in guidance but actually practically improved.

Ben Cartwright-Cox's axiom (paraphrased): "The real reason the Internet works is that we want it to work." https://ripe88.ripe.net/wp-content/uploads/A-Network-Of-Networks-RIPE88-RACI... Kind regards, Job

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

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.

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. On Fri, May 17, 2024 at 5:21 PM Ca By <cb.list6@gmail.com> wrote:

On Fri, May 17, 2024 at 2:02 PM Sean Donelan <sean@donelan.com> wrote:

...

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.

...

https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-pa... 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. On Fri, May 17, 2024 at 7:24 PM Ca By <cb.list6@gmail.com> wrote:

On Fri, May 17, 2024 at 4:20 PM Tom Beecher <beecher@beecher.cc> wrote:

...

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.

...

On Fri, May 17, 2024 at 5:21 PM Ca By <cb.list6@gmail.com> wrote:

...

On Fri, May 17, 2024 at 2:02 PM Sean Donelan <sean@donelan.com> wrote:

...

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.

...

On Thursday, May 16, 2024 6:18 PM, Brandon Martin wrote:

On 5/16/24 16:05, Josh Luthman wrote:

...

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/> [Adams-Logo]<http://adams.net/> ________________________________ The information contained in this email message is PRIVILEGED AND CONFIDENTIAL, and is intended for the use of the addressee and no one else. If you are not the intended recipient, please do not read, distribute, reproduce or use this email message (or the attachments) and notify the sender of the mistaken transmission. Thank you.

On 5/16/24 21:53, Brandon Zhi wrote:

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.

When roaming, the home mobile network has two options to deliver data services to their customer: * Breakout to the Internet using the local roaming partner, or * Tunnel to the home network via the local roaming partner, and breakout to the Internet there. Both models are viable particularly if the roaming partner and home network are basing their roaming architecture on IPX rather than GRX. Local breakout improves performance because it is low-latency, while remote breakout is often preferred because it does not complicate billing and other traffic controls imposed by the home network. My anecdotal experience has been that you will have local breakout sometimes, and remote breakout most of the time. This will also vary from provider to provider. I also find that home networks tend to prefer remote breakout, while users, unsurprisingly, will have a better experience with local breakout. I've never been able to find conclusive data on which mobile operators implement local vs. remote breakout. It doesn't appear that the GSMA mandate any one model over another against their membership, so mobile operators are likely making individual choices on what they do. Either way, with an IPX-based roaming architecture, it is really just a glorified l3vpn cloud built on a standard IP/MPLS network. If you have time, the below is an interesting read: https://www.gsma.com/newsroom/wp-content/uploads//IR.34-v17.0.pdf Mark.