<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 10/4/22 11:58 AM, Tom Beecher wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAL9Qcx5GZbgVdExwO3BJ191JJXUHsL9f4-KyGnBR9UCQk5YBnw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Honestly
the root of a lot of the problems here is the bellheaded
insistence of still using E.164 addresses in the first place.
With SIP they are complete legacy and there is no reason that
my "telephone number" can't be <a href="mailto:mike@mtcc.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">mike@mtcc.com</a>.<br>
</blockquote>
<div><br>
</div>
<div>You can do that all you want. You just don't get to
interact with the PSTN.</div>
</div>
</blockquote>
<p>What is the "PSTN" these days? It's a bunch of interconnected SIP
proxies where there is nothing special about the identifiers used.
With end to end SIP (or middle to middle, etc), the routing is not
being done with e.164 addresses like in the legacy PSTN. It's just
bellheaded thinking that e.164 addresses mean anything these
days.The only time they make any difference is if they need to off
ramp to legacy signaling which is becoming rarer and rarer. <br>
</p>
<p>Mike<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAL9Qcx5GZbgVdExwO3BJ191JJXUHsL9f4-KyGnBR9UCQk5YBnw@mail.gmail.com"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Oct 4, 2022 at 2:53 PM
Michael Thomas <<a href="mailto:mike@mtcc.com"
moz-do-not-send="true" class="moz-txt-link-freetext">mike@mtcc.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<div>On 10/4/22 11:31 AM, Mike Hammett wrote:<br>
</div>
<blockquote type="cite">
<div
style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">What's
regulated or implemented is rarely the best course of
action. Does this cause more good or harm?<br>
</div>
</blockquote>
<p><br>
</p>
<p>Honestly the root of a lot of the problems here is the
bellheaded insistence of still using E.164 addresses in
the first place. With SIP they are complete legacy and
there is no reason that my "telephone number" can't be <a
href="mailto:mike@mtcc.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">mike@mtcc.com</a>.
In fact, that would be a huge win since I could just use
my email address book to make a call. You could tell that
STIR/SHAKEN really went off the rails when it has
heuristics on how to scrape E.164 addresses in the From:
field. At this point we should be mostly ignoring legacy
signaling, IMO. <br>
</p>
<p><br>
</p>
<p>Mike<br>
</p>
<blockquote type="cite">
<div
style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><br>
<div><span name="x"></span><br>
<br>
-----<br>
Mike Hammett<br>
Intelligent Computing Solutions<br>
<a href="http://www.ics-il.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">http://www.ics-il.com</a><br>
<br>
Midwest-IX<br>
<a href="http://www.midwest-ix.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">http://www.midwest-ix.com</a><span
name="x"></span><br>
</div>
<br>
<hr id="m_6608532766720541478zwchr">
<div
style="color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From:
</b>"Shane Ronan" <a
href="mailto:shane@ronan-online.com" target="_blank"
moz-do-not-send="true"><shane@ronan-online.com></a><br>
<b>To: </b>"Michael Thomas" <a
href="mailto:mike@mtcc.com" target="_blank"
moz-do-not-send="true"><mike@mtcc.com></a><br>
<b>Cc: </b>"Mike Hammett" <a
href="mailto:nanog@ics-il.net" target="_blank"
moz-do-not-send="true"><nanog@ics-il.net></a>,
<a href="mailto:nanog@nanog.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">nanog@nanog.org</a><br>
<b>Sent: </b>Tuesday, October 4, 2022 1:21:41 PM<br>
<b>Subject: </b>Re: FCC chairwoman: Fines alone
aren't enough (Robocalls)<br>
<br>
<div dir="ltr">Except the cost to do the data dips to
determine the authorization isn't "free".</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Oct 4,
2022 at 2:18 PM Michael Thomas <<a
href="mailto:mike@mtcc.com" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">mike@mtcc.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<div>On 10/4/22 6:07 AM, Mike Hammett wrote:<br>
</div>
<blockquote>
<div
style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">I
think the point the other Mike was trying to
make was that if everyone policed their
customers, this wouldn't be a problem. Since
some don't, something else needed to be
tried.<br>
<br>
<div><span></span><br>
</div>
</div>
</blockquote>
<p>Exactly. And that doesn't require an
elaborate PKI. Who is allowed to use what
telephone numbers is an administrative issue
for the ingress provider to police. It's the
equivalent to gmail not allowing me to spoof
whatever email address I want. The FCC could
have required that ages ago.<br>
</p>
<p><br>
</p>
<p>Mike<br>
</p>
<blockquote>
<div
style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">
<div><br>
-----<br>
Mike Hammett<br>
Intelligent Computing Solutions<br>
<a href="http://www.ics-il.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://www.ics-il.com</a><br>
<br>
Midwest-IX<br>
<a href="http://www.midwest-ix.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://www.midwest-ix.com</a><span></span><br>
</div>
<br>
<hr
id="m_6608532766720541478m_5695148775473131614zwchr">
<div
style="color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From:
</b>"Shane Ronan" <a
href="mailto:shane@ronan-online.com"
target="_blank" moz-do-not-send="true"><shane@ronan-online.com></a><br>
<b>To: </b>"Michael Thomas" <a
href="mailto:mike@mtcc.com"
target="_blank" moz-do-not-send="true"><mike@mtcc.com></a><br>
<b>Cc: </b><a
href="mailto:nanog@nanog.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">nanog@nanog.org</a><br>
<b>Sent: </b>Monday, October 3, 2022
9:54:07 PM<br>
<b>Subject: </b>Re: FCC chairwoman: Fines
alone aren't enough (Robocalls)<br>
<br>
<div dir="ltr">The issue isn't which
'prefixes' I accept from my customers,
but which 'prefixes' I accept from the
people I peer with, because it's
entirely dynamic and without a doing a
database dip on EVERY call, I have to
assume that my peer or my peers customer
or my peers peer is doing the right
thing.
<div><br>
</div>
<div>I can't simply block traffic from a
peer carrier, it's not allowed, so
there has to be some mechanism to mark
that a prefix should be allowed, which
is what Shaken/Stir does.</div>
<div><br>
</div>
<div>Shane</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On
Mon, Oct 3, 2022 at 7:05 PM Michael
Thomas <<a
href="mailto:mike@mtcc.com"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">mike@mtcc.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">The
problem has always been solvable at
the ingress provider. The <br>
problem was that there was zero to
negative incentive to do that. You <br>
don't need an elaborate PKI to tell
the ingress provider which prefixes <br>
customers are allow to assert. It's
pretty analogous to when submission <br>
authentication was pretty nonexistent
with email... there was no <br>
incentive to not be an open relay
sewer. Unlike email spam, SIP <br>
signaling is pretty easy to determine
whether it's spam. All it needed <br>
was somebody to force regulation which
unlike email there was always <br>
jurisdiction with the FCC.<br>
<br>
Mike<br>
<br>
On 10/3/22 3:13 PM, Jawaid Bazyar
wrote:<br>
> We're talking about blocking
other carriers.<br>
><br>
> On 10/3/22, 3:05 PM, "Michael
Thomas" <<a
href="mailto:mike@mtcc.com"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">mike@mtcc.com</a>>
wrote:<br>
><br>
> On 10/3/22 1:54 PM, Jawaid
Bazyar wrote:<br>
> > Because it's illegal
for common carriers to block traffic
otherwise.<br>
><br>
> Wait, what? It's illegal to
police their own users?<br>
><br>
> Mike<br>
><br>
> ><br>
> > On 10/3/22, 2:53 PM,
"NANOG on behalf of Michael Thomas"
<nanog-bounces+jbazyar=<a
href="mailto:verobroadband.com@nanog.org"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">verobroadband.com@nanog.org</a>
on behalf of <a
href="mailto:mike@mtcc.com"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">mike@mtcc.com</a>>
wrote:<br>
> ><br>
> ><br>
> > On 10/3/22 1:34
PM, Sean Donelan wrote:<br>
> > > 'Fines alone
aren't enough:' FCC threatens to
blacklist voice<br>
> > > providers for
flouting robocall rules<br>
> > ><br>
> > > <a
href="https://www.cyberscoop.com/fcc-robocall-fine-database-removal/"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.cyberscoop.com/fcc-robocall-fine-database-removal/</a><br>
> > ><br>
> > > [...]<br>
> > > “This is a
new era. If a provider doesn’t meet
its obligations under<br>
> > > the law, it
now faces expulsion from America’s
phone networks. Fines<br>
> > > alone aren’t
enough,” FCC chairwoman Jessica
Rosenworcel said in a<br>
> > > statement
accompanying the announcement.
“Providers that don’t follow<br>
> > > our rules and
make it easy to scam consumers will
now face swift<br>
> > >
consequences.”<br>
> > ><br>
> > > It’s the
first such enforcement action by the
agency to reduce the<br>
> > > growing
problem of robocalls since call ID
verification protocols<br>
> > > known as
“STIR/SHAKEN” went fully into effect
this summer.<br>
> > > [...]<br>
> ><br>
> > Why did we need to
wait for STIR/SHAKEN to do this?<br>
> ><br>
> > Mike<br>
> ><br>
><br>
><br>
</blockquote>
</div>
</div>
<br>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
<br>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>