<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:20 AM, Mike Hammett
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1753871633.171.1664907605034.JavaMail.mhammett@Thunderfuck2">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<style type="text/css">p { margin: 0; }</style>
<div style="font-family: arial,helvetica,sans-serif; font-size:
10pt; color: #000000">Isn't part of STIR/SHAKEN to make it
easier to determine the ingress provider, or the provider of
last blame?<br>
</div>
</blockquote>
<p>Not exactly. Unlike DKIM which is basically a "blame me" kind of
authentication at the domain level, STIR/SHAKEN tries to solve the
problem of who is allowed to use what E.164 address. You can
probably educe which domain to blame from it... sort of -- I'm not
familiar enough with the specifics to say how though.</p>
<p><br>
</p>
<p>The object has always been to shut down open relays, and this is
much much easier in the telephony space. Like for one, the FCC
exists and regulates it. That is not true of email.<br>
</p>
<p><br>
</p>
<p>Mike<br>
</p>
<blockquote type="cite"
cite="mid:1753871633.171.1664907605034.JavaMail.mhammett@Thunderfuck2">
<div style="font-family: arial,helvetica,sans-serif; font-size:
10pt; color: #000000"><br>
<div><span name="x"></span><br>
<br>
-----<br>
Mike Hammett<br>
Intelligent Computing Solutions<br>
<a class="moz-txt-link-freetext" href="http://www.ics-il.com">http://www.ics-il.com</a><br>
<br>
Midwest-IX<br>
<a class="moz-txt-link-freetext" href="http://www.midwest-ix.com">http://www.midwest-ix.com</a><span name="x"></span><br>
</div>
<br>
<hr id="zwchr">
<div
style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From:
</b>"Michael Thomas" <a class="moz-txt-link-rfc2396E" href="mailto:mike@mtcc.com"><mike@mtcc.com></a><br>
<b>To: </b>"Mike Hammett" <a class="moz-txt-link-rfc2396E" href="mailto:nanog@ics-il.net"><nanog@ics-il.net></a>, "Shane
Ronan" <a class="moz-txt-link-rfc2396E" href="mailto:shane@ronan-online.com"><shane@ronan-online.com></a><br>
<b>Cc: </b><a class="moz-txt-link-abbreviated" href="mailto:nanog@nanog.org">nanog@nanog.org</a><br>
<b>Sent: </b>Tuesday, October 4, 2022 1:18:24 PM<br>
<b>Subject: </b>Re: FCC chairwoman: Fines alone aren't enough
(Robocalls)<br>
<br>
<p><br>
</p>
<div class="moz-cite-prefix">On 10/4/22 6:07 AM, Mike Hammett
wrote:<br>
</div>
<blockquote
cite="mid:2084565525.74.1664888871183.JavaMail.mhammett@Thunderfuck2">
<style>p { margin: 0; }</style>
<div style="font-family: arial,helvetica,sans-serif;
font-size: 10pt; color: #000000">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
cite="mid:2084565525.74.1664888871183.JavaMail.mhammett@Thunderfuck2">
<div style="font-family: arial,helvetica,sans-serif;
font-size: 10pt; color: #000000">
<div><br>
-----<br>
Mike Hammett<br>
Intelligent Computing Solutions<br>
<a class="moz-txt-link-freetext"
href="http://www.ics-il.com" target="_blank"
moz-do-not-send="true">http://www.ics-il.com</a><br>
<br>
Midwest-IX<br>
<a class="moz-txt-link-freetext"
href="http://www.midwest-ix.com" target="_blank"
moz-do-not-send="true">http://www.midwest-ix.com</a><span></span><br>
</div>
<br>
<hr id="zwchr">
<div
style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From:
</b>"Shane Ronan" <a class="moz-txt-link-rfc2396E"
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
class="moz-txt-link-rfc2396E"
href="mailto:mike@mtcc.com" target="_blank"
moz-do-not-send="true"><mike@mtcc.com></a><br>
<b>Cc: </b><a class="moz-txt-link-abbreviated
moz-txt-link-freetext" href="mailto:nanog@nanog.org"
target="_blank" moz-do-not-send="true">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"
class="moz-txt-link-freetext"
moz-do-not-send="true">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"
class="moz-txt-link-freetext"
moz-do-not-send="true">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" class="moz-txt-link-freetext"
moz-do-not-send="true">verobroadband.com@nanog.org</a>
on behalf of <a href="mailto:mike@mtcc.com"
target="_blank" class="moz-txt-link-freetext"
moz-do-not-send="true">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"
class="moz-txt-link-freetext"
moz-do-not-send="true">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>
<br>
</div>
</blockquote>
</body>
</html>