Re: Cogent-TATA peering dispute?

2024-05-18 Thread Bill Woodcock



> On May 18, 2024, at 11:55, Saku Ytti  wrote:
> On Sat, 18 May 2024 at 10:38, Bill Woodcock  wrote:
>> So, yes, I think having an open peering policy should be a requirement for 
>> operating a root nameserver.  I don’t think there’s any defensible rationale 
>> that would support root nameservers being a private benefit to be used to 
>> worsen the digital divide or create leverage in commercial disputes.  They 
>> should, indeed, all be accessible to all networks.
> 
> What type of network reach is required? Is single pop enough, that as long as 
> you have single pop, and open policy to peer with anyone who wants to connect 
> to your pop, you qualify?

The topic of the conversation was Cogent, and this question doesn’t apply to 
them.  We have to recognize that there are a limited number of public-benefit 
entities with the mission or budget to operate global-scale Internet public 
infrastructure, and that’s ok; it is what it is.  Different models give us 
diversity and resilience, and that’s good.  The thought I was expressing was 
about a moral principle that costs nothing to adhere to, I’m not interested in 
drawing a “you must be this tall to ride” line.

-Bill



Re: Cogent-TATA peering dispute?

2024-05-18 Thread Bill Woodcock



> On May 18, 2024, at 19:30, Ray Bellis  wrote:
> According to their PeeringDB entry, at all of the 23 IXPs listed they only 
> peer via route servers and not bilaterally.
> As such I don't think it's entirely fair to call them out on this.

I’m not “calling them out,” I’m merely repeating their own assertion of their 
status, as they’ve put it on PeeringDB.  They say they have a selective peering 
policy rather than an open peering policy.  The other have open peering 
policies.  The question was regarding open peering policies, and that’s what I 
was addressing.  It’s not for me to judge whether organizations policies are 
what they claim, I’m only addressing the claim.

> Most of L-root's systems are hosted within transit networks, and not at IXPs. 
>  As such they have no control over additional peerings.

Speaking for PCH, we explicitly do not do that because it aggravates the 
digital divide.  (In addition to being a technically inferior solution, but 
it’s an easy shortcut to “having lots of dots on the map,” if that’s your 
goal.)  Placing a server within a market-dominant network gives that network an 
additional anticompetitive lever to use to compel payments from its 
competitors.  For a for-profit network, that’s a perfectly reasonable trade-off 
to make, and is undoubtedly good for short-term shareholder returns.  For 
something that should be public-benefit network, it’s counterproductive.

Anyway, I thought the conversation was about Cogent, which is about as clearly 
in the for-profit camp as it’s possible to be.

-Bill



Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

2024-05-18 Thread scott via NANOG




On 5/18/24 9:25 PM, Jason Baugher wrote:

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. 

---


While not a Big Guy, Hawaiian Telcom is actively removing all that old 
equipment because of energy/maint/personnel/etc costs.  It's a lot more 
involved and harder to do than most would think. OAEE - Old Ass 
Equipment Everywhere (-: stops migration.


With HT being a private company, I would find it hard to imagine the 
government saying "Do it now!" without some way of helping finance it. 
It costs initial money to get to the saving money part and the previous 
is what's hard to get done; spending that initial money.


This is a netgeek's outside-looking-in perspective.  I am not voice at all.

scott


RE: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

2024-05-18 Thread Jason Baugher
John Levine said:

> It appears that Brandon Martin  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.

STIR/SHAKEN is more complex than it needs to be, sure, but for the time being 
it's effectively broken anyway. If you're in an area where you have to connect 
to an ancient TDM-only LATA tandem, even though you'd like to do STIR/SHAKEN, 
it can't be done over an SS7 call. The call gets to the terminating carrier, 
who decides in their infinite wisdom that since it's not signed, to tell their 
customer it's SPAM-LIKELY. Well, that's helpful. STIR/SHAKEN implementation 
deadlines should have started at the core of the PSTN - transit and tandems - 
and moved out towards the edge. Instead it started at the edge, we all got 
complaint, and we still can't deliver calls because the core of the PSTN is 
lagging.

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
[Adams-Logo]

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.


RE: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

2024-05-18 Thread Jason Baugher
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 

Re: Cogent-TATA peering dispute?

2024-05-18 Thread Ray Bellis




On 18/05/2024 08:38, Bill Woodcock wrote:


L-root, ICANN, selective: https://www.dns.icann.org/imrs/

...

So, of the thirteen root nameservers, ten are potentially available
for interconnection, and of those, only two, Cogent and ICANN, don’t
have open peering policies.


IIUC, most of L-root's systems are hosted within transit networks, and 
not at IXPs.  As such they have no control over additional peerings.


According to their PeeringDB entry, at all of the 23 IXPs listed they 
only peer via route servers and not bilaterally.


As such I don't think it's entirely fair to call them out on this.

Ray


Re: Cogent-TATA peering dispute?

2024-05-18 Thread Saku Ytti
On Sat, 18 May 2024 at 10:38, Bill Woodcock  wrote:

> So, yes, I think having an open peering policy should be a requirement for 
> operating a root nameserver.  I don’t think there’s any defensible rationale 
> that would support root nameservers being a private benefit to be used to 
> worsen the digital divide or create leverage in commercial disputes.  They 
> should, indeed, all be accessible to all networks.

What type of network reach is required? Is single pop enough, that as
long as you have single pop, and open policy to peer with anyone who
wants to connect to your pop, you qualify?

-- 
  ++ytti


Re: Cogent-TATA peering dispute?

2024-05-18 Thread Bill Woodcock



> On May 18, 2024, at 08:56, Saku Ytti  wrote:
> What are we asking in terms of your proposed policy change of allowing
> host a root DNS? You must peer with everyone and anyone, at any terms?

Well, putting aside Cogent per se, and focusing on this much more interesting 
issue, I would suggest that this is already a well-established best practice, 
and reasonable in principle:

A-root, Verisign, open peering policy: https://www.peeringdb.com/net/873

B-root, USC/ISI, doesn’t really peer, but open in principle: 
https://b.root-servers.org/statements/response.html

C-root, Cogent, selective, not obviously published?

D-root, UMD, open peering policy: https://www.pch.net/peering

E-root, NASA, open peering policy: https://www.pch.net/peering

F-root, ISC, open peering policy: https://www.isc.org/froot-peering/

G-root, DISA, doesn’t really peer

H-root, US Army, doesn’t really peer

I-root, NetNod, open peering policy: 
https://www.netnod.se/about-netnod/peering-with-netnod

J-root, Verisign, open peering policy: https://www.peeringdb.com/net/873

K-root, RIPE, open peering policy: 
https://www.ripe.net/analyse/dns/k-root/k-root-peering-policy/

L-root, ICANN, selective: https://www.dns.icann.org/imrs/

M-root, WIDE, open peering policy: https://www.peeringdb.com/asn/7500

So, of the thirteen root nameservers, ten are potentially available for 
interconnection, and of those, only two, Cogent and ICANN, don’t have open 
peering policies.

So, yes, I think having an open peering policy should be a requirement for 
operating a root nameserver.  I don’t think there’s any defensible rationale 
that would support root nameservers being a private benefit to be used to 
worsen the digital divide or create leverage in commercial disputes.  They 
should, indeed, all be accessible to all networks.

-Bill



Re: Cogent-TATA peering dispute?

2024-05-18 Thread Mark Tinka



On 5/18/24 08:56, Saku Ytti wrote:


As long as our toolbox only has a capitalist hammer, peering disputes
are going to be a thing. Cogent has outlived many of its peering
dispute history partners. They are the grandfather of disruptive
transit pricing, which many others have struggled to meet profitably,
and I believe they are a big reason for current transit pricing being
as low as it is in the US and EU.


Or to put it another way, if the community thought Cogent was not 
providing some value to them, they would no longer be in business.


Mark.