Re: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-07-09 Thread goemon--- via NANOG 

On Fri, 9 Jul 2021, K. Scott Helms wrote:

Nothing will change immediately.  Having said that, I do expect that we will 
see much more effective enforcement.  The investigations will come from the ITG 
(Industry Traceback Group) with
enforcement coming from FCC or FTC depending on the actual offense.  The 
problem has been that it's been far too easy for robocalling companies to hop 
from one telecom provider to another.  Now
there are requirements around "know your customer" that telecom operators have 
to follow and the ITG will have a much better chance of figuring out who the bad actor is 
than they have in the past.
Longer term I worry that this will lead to more attacks on PBXs, eSBCs, and 
VOIP handsets to be able to call either from that endpoint itself or be able to 
use the SIP credentials.  The market for
robocalls will certainly not disappear.


until there is enforcement there will be no changes.

enforcement means more than just sternly worded letters.

robocalls won't stop until the perps go to prison.

-Dan

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-07-09 Thread Michael Thomas 



On 7/9/21 3:44 PM, Keith Medcalf wrote:

On Friday, 9 July, 2021 16:32, K. Scott Helms wrote:
Robocalls really aren't a product of the legacy PSTN.  Today almost none
of them originate from anywhere but VOIP.  Now, you can certainly say
that if SS7 had robust authentication mechanisms that we could then trust
caller ID (more) but there's no sign of us abandoning the PSTN anytime
soon.  Having said that, there's any number of protocols we rely on today
that have the exact same gap.  BGP is arguably even worse than SS7.

The root of the problem is that the "Caller ID" is not a "Caller ID".  If there were a requirement 
for "truth in advertizing" it would properly be called the "Caller Advertizement" because it is 
primarily intended as an advertizement by the caller, and not an ID of the caller.

The assumption back around 2004 was that P-Asserted-ID would be an old 
boys network to the end and get told to buzz off when I complained that 
it wouldn't. This was trivially foreseeable  back then and it played it 
the most ridiculously foreseeable way.


Mike

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-07-09 Thread Michael Thomas 


On 7/9/21 3:32 PM, K. Scott Helms wrote:




On Fri, Jul 9, 2021 at 4:47 PM Michael Thomas > wrote:



On 7/9/21 1:36 PM, K. Scott Helms wrote:
> Nothing will change immediately.  Having said that, I do expect
that
> we will see much more effective enforcement. The investigations
will
> come from the ITG (Industry Traceback Group) with enforcement
> coming from FCC or FTC depending on the actual offense.  The
problem
> has been that it's been far too easy for robocalling companies
to hop
> from one telecom provider to another.  Now there are requirements
> around "know your customer" that telecom operators have to
follow and
> the ITG will have a much better chance of figuring out who the bad
> actor is than they have in the past.

The thing is that that shouldn't have been held up by rolling out
STIR.
With email, there was nothing akin to the FCC so it was really the
only
name-and-shame stick we had. This could have been done years ago.


It wouldn't work the same and I say that as someone who ran email for 
ISPs for decades and just got done with a STIR/SHAKEN implementation.  
There's far more money in robocalls than there ever has been in spam.  
The other thing is that the technologies are fundamentally different.  
Don't get me wrong, there are parallels, but comparing email to the 
various flavors of telephony (POTS, SIP, MGCP, H.323, etc) isn't all 
that useful because they're so different. When I get an email as a 
provider I can always figure out the path it took to get to me.  The 
same is not at all true for a call, though I can trace it to a degree 
via the CDRs from carriers I work with.  Much of the call path will be 
opaque and often in the case of robocallers it's intentionally so.  
Number porting is another (big) difference.  We could always choose to 
forward email for a customer who left our service, but imagine if 
email literally let that person take their address with them 
regardless of who was providing the hosting for the email.


Once it hits a SIP gateway it's pretty much the same. The thing that I 
think that made the made the biggest -- and this coming from one of the 
inventors of DKIM -- was shutting down open relays. With email there was 
no back pressure on ESP's to close them so DKIM was at least a way to 
name and shame, or at least that was one of the goals at least in my 
mind. It's hard to say whether there was actually cause and effect, but 
the reality now is that open relays are pretty much gone -- at least 
with ESP's.


I was one of the early Cassandras telling people that 
P-Asserted-Identity was going to lead to exactly what has happened for 
which I got told I was wrong, and then threw up my hands and went and 
worked on email. This could have been dealt with 15 years ago and it 
could have trivially piggybacked off of the DKIM work -- heck I even 
hacked a SIP stack to prove the point. And it should have learned the 
lessons with email which it apparently has not because the 9th of July 
don't seem any different than the 30th of June.


Also: since there are PSTN gateways which fundamentally can't be secured 
spammers will take advantage of the holes as they become economically 
viable. The entire scheme of attesting for e.164 addresses was a 
complete waste of time. The problem is with the SIP gateway that onramps 
the bogus calls not whether somebody should be able to assert a given 
address real time. Those onramps could have taken those measures a 
decade ago but didn't just like the open email sewers before requiring 
submission auth. I think that Peterson has some other wacky shit to make 
PSTN gateway traversal better, turning a Rube Goldberg contraption into 
something even worse. The entire thing is madness with its complexity 
but I would expect nothing less from the SIP WG.




> Longer term I worry that this will lead to more attacks on PBXs,
> eSBCs, and VOIP handsets to be able to call either from that
endpoint
> itself or be able to use the SIP credentials. The market for
robocalls
> will certainly not disappear.
>
A meta question that really needs to be asked these days is why we
even
need telco telephony anymore. A lot of problems go away if you are
not
in thrall to 100 year old technology and its accreted kruft.


Robocalls really aren't a product of the legacy PSTN. Today almost 
none of them originate from anywhere but VOIP. Now, you can certainly 
say that if SS7 had robust authentication mechanisms that we could 
then trust caller ID (more) but there's no sign of us abandoning the 
PSTN anytime soon.  Having said that, there's any number of protocols 
we rely on today that have the exact same gap.  BGP is arguably even 
worse than SS7.


I'm not speaking about PSTN qua PSTN/SS7, etc. I'm speaking about being 
shackled to an architecture that isn't relevant today. The 
bellheadedness of

RE: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-07-09 Thread Keith Medcalf 


>On Friday, 9 July, 2021 16:32, K. Scott Helms wrote:

>Robocalls really aren't a product of the legacy PSTN.  Today almost none
>of them originate from anywhere but VOIP.  Now, you can certainly say
>that if SS7 had robust authentication mechanisms that we could then trust
>caller ID (more) but there's no sign of us abandoning the PSTN anytime
>soon.  Having said that, there's any number of protocols we rely on today
>that have the exact same gap.  BGP is arguably even worse than SS7.

The root of the problem is that the "Caller ID" is not a "Caller ID".  If there 
were a requirement for "truth in advertizing" it would properly be called the 
"Caller Advertizement" because it is primarily intended as an advertizement by 
the caller, and not an ID of the caller.

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-07-09 Thread K. Scott Helms 
On Fri, Jul 9, 2021 at 4:47 PM Michael Thomas  wrote:

>
> On 7/9/21 1:36 PM, K. Scott Helms wrote:
> > Nothing will change immediately.  Having said that, I do expect that
> > we will see much more effective enforcement. The investigations will
> > come from the ITG (Industry Traceback Group) with enforcement
> > coming from FCC or FTC depending on the actual offense.  The problem
> > has been that it's been far too easy for robocalling companies to hop
> > from one telecom provider to another.  Now there are requirements
> > around "know your customer" that telecom operators have to follow and
> > the ITG will have a much better chance of figuring out who the bad
> > actor is than they have in the past.
>
> The thing is that that shouldn't have been held up by rolling out STIR.
> With email, there was nothing akin to the FCC so it was really the only
> name-and-shame stick we had. This could have been done years ago.
>

It wouldn't work the same and I say that as someone who ran email for ISPs
for decades and just got done with a STIR/SHAKEN implementation.  There's
far more money in robocalls than there ever has been in spam.  The other
thing is that the technologies are fundamentally different.  Don't get me
wrong, there are parallels, but comparing email to the various flavors of
telephony (POTS, SIP, MGCP, H.323, etc) isn't all that useful because
they're so different.  When I get an email as a provider I can always
figure out the path it took to get to me.  The same is not at all true for
a call, though I can trace it to a degree via the CDRs from carriers I work
with.  Much of the call path will be opaque and often in the case of
robocallers it's intentionally so.  Number porting is another (big)
difference.  We could always choose to forward email for a customer who
left our service, but imagine if email literally let that person take their
address with them regardless of who was providing the hosting for the email.



> > Longer term I worry that this will lead to more attacks on PBXs,
> > eSBCs, and VOIP handsets to be able to call either from that endpoint
> > itself or be able to use the SIP credentials. The market for robocalls
> > will certainly not disappear.
> >
> A meta question that really needs to be asked these days is why we even
> need telco telephony anymore. A lot of problems go away if you are not
> in thrall to 100 year old technology and its accreted kruft.
>

Robocalls really aren't a product of the legacy PSTN.  Today almost none of
them originate from anywhere but VOIP.  Now, you can certainly say that if
SS7 had robust authentication mechanisms that we could then trust caller ID
(more) but there's no sign of us abandoning the PSTN anytime soon.  Having
said that, there's any number of protocols we rely on today that have the
exact same gap.  BGP is arguably even worse than SS7.

tl;dr You can no more get rid of telephone companies than you can get rid
of ISPs.



>
> Mike
>
>

Re: Do you care about "gray" failures? Can we (network academics) help? A 10-min survey

2021-07-09 Thread Yang Yu 
On Thu, Jul 8, 2021 at 4:03 PM William Herrin  wrote:
>
> On Thu, Jul 8, 2021 at 5:31 AM Saku Ytti  wrote:
> > Network experiences gray failures all the time, and I almost never
> > care, unless a customer does.
>
> I would suggest that your customer does care, but as there is no
> simple test to demonstrate gray failures, your customer rarely makes
> it past first tier support to bring the issue to your attention and
> gives up trying. Indeed, name the networks with the worst reputations
> around here and many of them have those reputations because of a
> routine, uncorrected state of gray failure.

Networks originating/receiving the traffic tend to have more
incentives to resolve these issues, which might be not so rare

If you have connection/application level health metrics (e.g. TLS
handshake failures, TCP retransmits), identifying a problem exists is
not too difficult. Having health metrics associated with network paths
can greatly simplify repro. Then it's mostly troubleshooting datapath
issues on your favorite platform.

It takes quite some effort to figure out/collect relevant metrics and
present them in a usable way. Something like connections from PoP A to
destination ASN/prefix (via interface X) had TLS handshake failure
rate increased from 0.02% to 1% is a good starting point for
troubleshooting (may or may not be a network issue, the
origin/receiver probably wants to fix it regardless).

Things can get more complicated when traffic crosses network
boundaries with things you don't have visibility into (IX fabric,
remote peering, another networks' optical systems, complicated setups
like stateful firewall / MC-LAG)

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-07-09 Thread Michael Thomas 



On 7/9/21 1:36 PM, K. Scott Helms wrote:
Nothing will change immediately.  Having said that, I do expect that 
we will see much more effective enforcement. The investigations will 
come from the ITG (Industry Traceback Group) with enforcement 
coming from FCC or FTC depending on the actual offense.  The problem 
has been that it's been far too easy for robocalling companies to hop 
from one telecom provider to another.  Now there are requirements 
around "know your customer" that telecom operators have to follow and 
the ITG will have a much better chance of figuring out who the bad 
actor is than they have in the past.


The thing is that that shouldn't have been held up by rolling out STIR. 
With email, there was nothing akin to the FCC so it was really the only 
name-and-shame stick we had. This could have been done years ago.





Longer term I worry that this will lead to more attacks on PBXs, 
eSBCs, and VOIP handsets to be able to call either from that endpoint 
itself or be able to use the SIP credentials. The market for robocalls 
will certainly not disappear.


A meta question that really needs to be asked these days is why we even 
need telco telephony anymore. A lot of problems go away if you are not 
in thrall to 100 year old technology and its accreted kruft.


Mike

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-07-09 Thread K. Scott Helms 
Nothing will change immediately.  Having said that, I do expect that we
will see much more effective enforcement.  The investigations will come
from the ITG (Industry Traceback Group) with enforcement coming from FCC or
FTC depending on the actual offense.  The problem has been that it's been
far too easy for robocalling companies to hop from one telecom provider to
another.  Now there are requirements around "know your customer" that
telecom operators have to follow and the ITG will have a much better chance
of figuring out who the bad actor is than they have in the past.

Longer term I worry that this will lead to more attacks on PBXs, eSBCs, and
VOIP handsets to be able to call either from that endpoint itself or be
able to use the SIP credentials.  The market for robocalls will certainly
not disappear.

Scott Helms



On Fri, Jul 9, 2021 at 1:07 PM Michael Thomas  wrote:

> Nothing has changed for me either. Color me surprised. The real proof will
> be to see if the originating domain can be determined, and whether the
> receiving domain does anything about it.
>
> Mike
> On 7/9/21 9:42 AM, Brandon Svec via NANOG wrote:
>
> I’m getting the same or more, but did anyone really expect they would stop
> July 1? It will take time for complaints to be tracked down and operators
> to take actions, right?
>
> Brandon
>
> On Fri, Jul 9, 2021 at 6:49 AM Josh Luthman 
> wrote:
>
>> Subjectively speaking, I'm still getting the same amount of spam phone
>> calls.
>>
>> I'm certainly getting a lot more spam SMS to my cell.  Almost all of them
>> in my entire life starting July 1...
>>
>>
>> Josh Luthman
>> 24/7 Help Desk: 937-552-2340
>> Direct: 937-552-2343
>> 1100 Wayne St
>> 
>> Suite 1337
>> 
>> Troy, OH 45373
>> 
>>
>>
>> On Fri, Jul 9, 2021 at 9:40 AM Jeff Shultz 
>> wrote:
>>
>>> All I know is that I am getting a lot fewer bogus calls on my cell phone
>>> than I was this time last month.
>>>
>>> On Fri, Jul 9, 2021, 06:17 Ryan Finnesey via NANOG 
>>> wrote:
>>>
 This should help with Robo calls a lot.

 -Original Message-
 From: NANOG  On
 Behalf Of Sean Donelan
 Sent: Wednesday, June 30, 2021 2:31 PM
 To: nanog@nanog.org
 Subject: SITR/SHAKEN implementation in effect today (June 30 2021)


 STIR/SHAKEN Broadly Implemented Starting Today
 https://www.fcc.gov/document/stirshaken-broadly-implemented-starting-today

 WASHINGTON, June 30, 2021—FCC Acting Chairwoman Jessica Rosenworcel
 today announced that the largest voice service providers are now using
 STIR/SHAKEN caller ID authentication standards in their IP networks, in
 accordance with the deadline set by the FCC. This widespread implementation
 helps protect consumers against malicious spoofed robocalls and helps law
 enforcement track bad actors. The STIR/SHAKEN standards serve as a common
 digital language used by phone networks, allowing valid information to pass
 from provider to provider which, among other things, informs blocking tools
 of possible suspicious calls.
>>>
>>> --
> Brandon Svec
> 15106862204 ☎️ or 
>
>

Weekly Routing Table Report

2021-07-09 Thread Routing Analysis Role Account 
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 10 Jul, 2021

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  856890
Prefixes after maximum aggregation (per Origin AS):  323763
Deaggregation factor:  2.65
Unique aggregates announced (without unneeded subnets):  411662
Total ASes present in the Internet Routing Table: 71580
Prefixes per ASN: 11.97
Origin-only ASes present in the Internet Routing Table:   61528
Origin ASes announcing only one prefix:   25390
Transit ASes present in the Internet Routing Table:   10052
Transit-only ASes present in the Internet Routing Table:327
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  54
Max AS path prepend of ASN ( 48366)  51
Prefixes from unregistered ASNs in the Routing Table:  1121
Number of instances of unregistered ASNs:  1127
Number of 32-bit ASNs allocated by the RIRs:  36586
Number of 32-bit ASNs visible in the Routing Table:   30391
Prefixes from 32-bit ASNs in the Routing Table:  141715
Number of bogon 32-bit ASNs visible in the Routing Table:25
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:527
Number of addresses announced to Internet:   3040396928
Equivalent to 181 /8s, 56 /16s and 198 /24s
Percentage of available address space announced:   82.1
Percentage of allocated address space announced:   82.1
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  285265

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   230189
Total APNIC prefixes after maximum aggregation:   65859
APNIC Deaggregation factor:3.50
Prefixes being announced from the APNIC address blocks:  225794
Unique aggregates announced from the APNIC address blocks:90587
APNIC Region origin ASes present in the Internet Routing Table:   11729
APNIC Prefixes per ASN:   19.25
APNIC Region origin ASes announcing only one prefix:   3325
APNIC Region transit ASes present in the Internet Routing Table:   1669
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 32
Number of APNIC region 32-bit ASNs visible in the Routing Table:   6895
Number of APNIC addresses announced to Internet:  774110464
Equivalent to 46 /8s, 35 /16s and 253 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-147769
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:250240
Total ARIN prefixes after maximum aggregation:   114147
ARIN Deaggregation factor: 2.19
Prefixes being announced from the ARIN address blocks:   250004
Unique aggregates announced from the ARIN address blocks:119032
ARIN Region origin ASes present in the Internet Routing Table:18840
ARIN Prefixes per ASN:13.27
ARIN

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-07-09 Thread goemon--- via NANOG 

On Fri, 9 Jul 2021, Michael Thomas wrote:

Nothing has changed for me either. Color me surprised. The real proof will be 
to see if the originating domain can be determined, and whether the receiving 
domain does anything about it.


Why would they do anything? The traffic is revenue.

What is the FCC going to do other than write mean letters?

-Dan

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-07-09 Thread Michael Thomas 
Nothing has changed for me either. Color me surprised. The real proof 
will be to see if the originating domain can be determined, and whether 
the receiving domain does anything about it.


Mike

On 7/9/21 9:42 AM, Brandon Svec via NANOG wrote:
I’m getting the same or more, but did anyone really expect they would 
stop July 1? It will take time for complaints to be tracked down and 
operators to take actions, right?


Brandon

On Fri, Jul 9, 2021 at 6:49 AM Josh Luthman 
mailto:j...@imaginenetworksllc.com>> wrote:


Subjectively speaking, I'm still getting the same amount of spam
phone calls.

I'm certainly getting a lot more spam SMS to my cell.  Almost all
of them in my entire life starting July 1...


Josh Luthman
24/7 Help Desk: 937-552-2340
Direct: 937-552-2343
1100 Wayne St


Suite 1337


Troy, OH 45373




On Fri, Jul 9, 2021 at 9:40 AM Jeff Shultz mailto:jeffshu...@sctcweb.com>> wrote:

All I know is that I am getting a lot fewer bogus calls on my
cell phone than I was this time last month.

On Fri, Jul 9, 2021, 06:17 Ryan Finnesey via NANOG
mailto:nanog@nanog.org>> wrote:

This should help with Robo calls a lot.

-Original Message-
From: NANOG
mailto:conovence@nanog.org>> On Behalf Of Sean Donelan
Sent: Wednesday, June 30, 2021 2:31 PM
To: nanog@nanog.org 
Subject: SITR/SHAKEN implementation in effect today (June
30 2021)


STIR/SHAKEN Broadly Implemented Starting Today

https://www.fcc.gov/document/stirshaken-broadly-implemented-starting-today



WASHINGTON, June 30, 2021—FCC Acting Chairwoman Jessica
Rosenworcel today announced that the largest voice service
providers are now using STIR/SHAKEN caller ID
authentication standards in their IP networks, in
accordance with the deadline set by the FCC. This
widespread implementation helps protect consumers against
malicious spoofed robocalls and helps law enforcement
track bad actors. The STIR/SHAKEN standards serve as a
common digital language used by phone networks, allowing
valid information to pass from provider to provider which,
among other things, informs blocking tools of possible
suspicious calls.

--
Brandon Svec
15106862204 ☎️ or 

Care to get more involved in ARIN? (was: Fwd: [arin-announce] Call for Nominations Extended for Board and Advisory Council)

2021-07-09 Thread John Curran 
NANOGers -

From time to time discussions break out on the nanog mailing list about various 
ARIN policies and practices, and I frequently note that ARIN’s governing and 
policy development bodies are actually made up of members of this very same 
operator community.

If you have views on how ARIN should operate – or are interested in help 
facilitate the Internet number policy that we use for administration of the 
ARIN registry – please consider running for the ARIN Board of Trustees or the 
ARIN Advisory Council.We have extended the deadline so there is still time 
to be nominated and details may be found in the attached message regarding 
requirements and expectations.

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers


Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [arin-announce] Call for Nominations Extended for Board and Advisory 
Council
Date: 8 July 2021 at 12:59:50 PM EDT
To: "arin-annou...@arin.net" 
mailto:arin-annou...@arin.net>>

By request of the 2021 Nomination Committee, ARIN has extended the Call for 
Nominations for the Board of Trustees and Advisory Council. Nominations will 
now be accepted through 5:00 PM EDT on Friday, 16 July 2021 to fill two seats 
on the ARIN Board of Trustees and seven seats on the Advisory Council.
Contribute to the ARIN community by verifying the eligibility requirements for 
nominators and nominees and submitting a nomination for a qualified individual 
today! To submit a nomination, use one of the links below:

  *   Board of Trustees Nominations:
https://www.surveymonkey.com/r/2021BoardNom 

  *   Advisory Council Nominations:
https://www.surveymonkey.com/r/2021ACNom 


Nominator Requirements
ARIN Trustees and representatives from General Members in Good Standing may 
make up to three nominations for each open position on the Board of Trustees 
and Advisory Council. Eligible individuals may nominate anyone, including 
themselves. Nominees are not required to have an affiliation with an ARIN 
Member.
If you are not an ARIN Trustee or a representative from a Member in Good 
Standing, the members of the NomCom may assist in submitting a nomination on 
your behalf – either as a nomination of yourself or someone you know whom you 
believe is qualified. Simply send an email to 
nominati...@arin.net with the name and contact 
information (phone and email) of the person you wish to nominate – but as time 
is limited, don’t wait!
Nominee Requirements
To view requirements, expected qualifications, and/or responsibilities for 
these elected positions, please visit:

  *   Board of Trustees: https://www.arin.net/about/welcome/board/requirements/
  *   Advisory Council: https://www.arin.net/about/welcome/ac/requirements/

All nominees must confirm that they qualify and are willing to serve if elected 
and that they do not violate the Nomination and Appointment Conflict of 
Interest List found at:
https://www.arin.net/participate/oversight/elections/conflicts/
All nominees must officially accept their nomination and submit their completed 
nominee questionnaire before 5:00 PM ET on Friday, 16 July, when the extension 
of the Call for Nominations closes. ARIN strongly discourages last minute 
nominations since there may not be adequate time for a nominee to be notified, 
accept their nomination, and/or complete and submit their questionnaire.
For more information about ARIN Elections, the 2021 Election Calendar, or 
details of the ARIN Election processes, please visit:
https://www.arin.net/elections/
Regards,
Jason Byrne
Senior Customer Success Analyst
American Registry for Internet Numbers (ARIN)
___
ARIN-Announce
You are receiving this message because you are subscribed to
the ARIN Announce Mailing List 
(arin-annou...@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-announce
Please contact i...@arin.net if you experience any issues.

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-07-09 Thread Brandon Svec via NANOG 
I’m getting the same or more, but did anyone really expect they would stop
July 1? It will take time for complaints to be tracked down and operators
to take actions, right?

Brandon

On Fri, Jul 9, 2021 at 6:49 AM Josh Luthman 
wrote:

> Subjectively speaking, I'm still getting the same amount of spam phone
> calls.
>
> I'm certainly getting a lot more spam SMS to my cell.  Almost all of them
> in my entire life starting July 1...
>
>
> Josh Luthman
> 24/7 Help Desk: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> 
> Suite 1337
> 
> Troy, OH 45373
> 
>
>
> On Fri, Jul 9, 2021 at 9:40 AM Jeff Shultz  wrote:
>
>> All I know is that I am getting a lot fewer bogus calls on my cell phone
>> than I was this time last month.
>>
>> On Fri, Jul 9, 2021, 06:17 Ryan Finnesey via NANOG 
>> wrote:
>>
>>> This should help with Robo calls a lot.
>>>
>>> -Original Message-
>>> From: NANOG  On
>>> Behalf Of Sean Donelan
>>> Sent: Wednesday, June 30, 2021 2:31 PM
>>> To: nanog@nanog.org
>>> Subject: SITR/SHAKEN implementation in effect today (June 30 2021)
>>>
>>>
>>> STIR/SHAKEN Broadly Implemented Starting Today
>>> https://www.fcc.gov/document/stirshaken-broadly-implemented-starting-today
>>>
>>> WASHINGTON, June 30, 2021—FCC Acting Chairwoman Jessica Rosenworcel
>>> today announced that the largest voice service providers are now using
>>> STIR/SHAKEN caller ID authentication standards in their IP networks, in
>>> accordance with the deadline set by the FCC. This widespread implementation
>>> helps protect consumers against malicious spoofed robocalls and helps law
>>> enforcement track bad actors. The STIR/SHAKEN standards serve as a common
>>> digital language used by phone networks, allowing valid information to pass
>>> from provider to provider which, among other things, informs blocking tools
>>> of possible suspicious calls.
>>
>> --
Brandon Svec
15106862204 ☎️ or 

RE: VoP regulatory consultant

2021-07-09 Thread Ryan Finnesey via NANOG 
Thanks Tim.  I have been a member of that listserv for years.  It is very US 
focused.  That’s why I thought I would ask the larger NANOG community.  

Ryan


-Original Message-
From: Tim Nelson  
Sent: Friday, July 9, 2021 9:28 AM
To: Ryan Finnesey 
Cc: nanog@nanog.org
Subject: Re: VoP regulatory consultant

Check the VoiceOps mailing list:  http://voiceops.org/

--Tim

On Fri, Jul 9, 2021 at 8:06 AM Ryan Finnesey via NANOG  wrote:
>
> Would anyone have any recommendations on regulatory consultants for VoIP 
> within North America but markets outside the US?
>
> Get Outlook for iOS

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-07-09 Thread Josh Luthman 
Subjectively speaking, I'm still getting the same amount of spam phone
calls.

I'm certainly getting a lot more spam SMS to my cell.  Almost all of them
in my entire life starting July 1...

Josh Luthman
24/7 Help Desk: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Fri, Jul 9, 2021 at 9:40 AM Jeff Shultz  wrote:

> All I know is that I am getting a lot fewer bogus calls on my cell phone
> than I was this time last month.
>
> On Fri, Jul 9, 2021, 06:17 Ryan Finnesey via NANOG 
> wrote:
>
>> This should help with Robo calls a lot.
>>
>> -Original Message-
>> From: NANOG  On
>> Behalf Of Sean Donelan
>> Sent: Wednesday, June 30, 2021 2:31 PM
>> To: nanog@nanog.org
>> Subject: SITR/SHAKEN implementation in effect today (June 30 2021)
>>
>>
>> STIR/SHAKEN Broadly Implemented Starting Today
>> https://www.fcc.gov/document/stirshaken-broadly-implemented-starting-today
>>
>> WASHINGTON, June 30, 2021—FCC Acting Chairwoman Jessica Rosenworcel today
>> announced that the largest voice service providers are now using
>> STIR/SHAKEN caller ID authentication standards in their IP networks, in
>> accordance with the deadline set by the FCC. This widespread implementation
>> helps protect consumers against malicious spoofed robocalls and helps law
>> enforcement track bad actors. The STIR/SHAKEN standards serve as a common
>> digital language used by phone networks, allowing valid information to pass
>> from provider to provider which, among other things, informs blocking tools
>> of possible suspicious calls.
>>
>
> Like us on Social Media for News, Promotions, and other information!!
>
> [image:
> https://www.instagram.com/sctc_sctc/]
> 
> 
> 
>
>
>
>
>
>
>
>  This message contains confidential information and is intended only
> for the individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. E-mail transmission cannot be
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
> The sender therefore does not accept liability for any errors or omissions
> in the contents of this message, which arise as a result of e-mail
> transmission. 
>

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-07-09 Thread Jeff Shultz 
All I know is that I am getting a lot fewer bogus calls on my cell phone
than I was this time last month.

On Fri, Jul 9, 2021, 06:17 Ryan Finnesey via NANOG  wrote:

> This should help with Robo calls a lot.
>
> -Original Message-
> From: NANOG  On
> Behalf Of Sean Donelan
> Sent: Wednesday, June 30, 2021 2:31 PM
> To: nanog@nanog.org
> Subject: SITR/SHAKEN implementation in effect today (June 30 2021)
>
>
> STIR/SHAKEN Broadly Implemented Starting Today
> https://www.fcc.gov/document/stirshaken-broadly-implemented-starting-today
>
> WASHINGTON, June 30, 2021—FCC Acting Chairwoman Jessica Rosenworcel today
> announced that the largest voice service providers are now using
> STIR/SHAKEN caller ID authentication standards in their IP networks, in
> accordance with the deadline set by the FCC. This widespread implementation
> helps protect consumers against malicious spoofed robocalls and helps law
> enforcement track bad actors. The STIR/SHAKEN standards serve as a common
> digital language used by phone networks, allowing valid information to pass
> from provider to provider which, among other things, informs blocking tools
> of possible suspicious calls.
>

-- 
Like us on Social Media for News, Promotions, and other information!!

   
      
      
      














_ This message 
contains confidential information and is intended only for the individual 
named. If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately by 
e-mail if you have received this e-mail by mistake and delete this e-mail 
from your system. E-mail transmission cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses. The sender therefore does 
not accept liability for any errors or omissions in the contents of this 
message, which arise as a result of e-mail transmission. _

RE: Email and Web Hosting

2021-07-09 Thread Shawn L via NANOG 

There's also Rackspace.  They have e-mail and web hosting, etc.


-Original Message-
From: "Ryan Finnesey via NANOG" 
Sent: Thursday, July 8, 2021 10:56pm
To: "Steve Saner" , "nanog@nanog.org" 
Subject: RE: Email and Web Hosting




If the client base wants to stick with basic IMAP/POP3 email Tucows/OpenSRS has 
a good platform.  Also a few years ago my company migrated business email 
accounts and domains from an ISP and moved them to Office 365 and did a revenue 
share with the ISP.  They where happy still got a bit of revenue  but did not 
have to support it.
 
Ryan
 
 

From: NANOG  On Behalf Of 
Steve Saner
Sent: Tuesday, July 6, 2021 10:42 AM
To: nanog@nanog.org
Subject: Email and Web Hosting
 
I hope this isn't too far off topic for this list.

 
We acquired a small ISP a couple years ago that has its roots in the "local 
ISPs" of the 90s. This ISP is still hosting email and web services for 
customers both on company domains as well as customer domains. There is some 
decent revenue coming from these services, but cost of maintenance is becoming 
a challenge. We are looking at migrating to another platform or completely 
discontinuing those services.

 
I'm wondering if others here have gone through that process and have any advice 
as to how to go about it. 

 
--
Steve Saner | Senior Network Engineer
ideatek INTERNET FREEDOM FOR ALL
Cell: 620-860-9433 | 111 Old Mill Lane, Buhler, KS 67522 | [ ideatek.com ]( 
http://www.ideatek.com/ )
This email transmission and any documents, files or previous email messages 
attached to it may contain confidential information. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering the message to the intended recipient, you are hereby notified that 
any dissemination, distribution or copying of this communication is strictly 
prohibited. If you are not or believe you may not be the intended recipient, 
please advise the sender immediately by return email or by calling 
620.543.5026. Then, please take all steps necessary to permanently delete the 
email and all attachments from your computer system. No trees were affected by 
this transmission – though a few billion photons were mildly inconvenienced.

Networks not reachable from VZ as if there's no route

2021-07-09 Thread S Umple 
Hi,


Networks are not reachable from VZ FIOS as if there's no route.

Upon further checking, issue appears to be widespread. I've checked two
major SPs VZ/Sprint and neither has these networks, while ATT/HE.NET/
route-views all have them.



root# for i in 8.8.8.8 121.51.175.17 121.51.22.64 182.254.52.163
182.254.60.11; do mtr -ur $i; done
HOST: Loss% Snt Last Avg Best Wrst StDev
1.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
2.|-- 100.41.26.128 0.0% 10 10.9 11.7 8.7 14.3 1.7
3.|-- 140.222.10.38 0.0% 10 16.2 15.8 14.0 18.4 1.3
4.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6.|-- 140.222.227.25 0.0% 10 16.9 16.4 14.8 22.4 2.4
7.|-- 72.14.208.130 0.0% 10 15.6 15.4 12.6 16.8 1.4
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
HOST: Loss% Snt Last Avg Best Wrst StDev
1.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4.|-- 100.41.26.128 90.0% 10 9.2 9.2 9.2 9.2 0.0
HOST: Loss% Snt Last Avg Best Wrst StDev
1.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
2.|-- 100.41.26.126 90.0% 10 11.4 11.4 11.4 11.4 0.0
HOST: Loss% Snt Last Avg Best Wrst StDev
1.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4.|-- 100.41.26.126 90.0% 10 12.0 12.0 12.0 12.0 0.0
HOST: Loss% Snt Last Avg Best Wrst StDev
1.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6.|-- 100.41.26.128 80.0% 10 14.7 12.0 9.3 14.7 3.8

RE: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-07-09 Thread Ryan Finnesey via NANOG 
This should help with Robo calls a lot.

-Original Message-
From: NANOG  On Behalf Of 
Sean Donelan
Sent: Wednesday, June 30, 2021 2:31 PM
To: nanog@nanog.org
Subject: SITR/SHAKEN implementation in effect today (June 30 2021)


STIR/SHAKEN Broadly Implemented Starting Today 
https://www.fcc.gov/document/stirshaken-broadly-implemented-starting-today

WASHINGTON, June 30, 2021—FCC Acting Chairwoman Jessica Rosenworcel today 
announced that the largest voice service providers are now using STIR/SHAKEN 
caller ID authentication standards in their IP networks, in accordance with the 
deadline set by the FCC. This widespread implementation helps protect consumers 
against malicious spoofed robocalls and helps law enforcement track bad actors. 
The STIR/SHAKEN standards serve as a common digital language used by phone 
networks, allowing valid information to pass from provider to provider which, 
among other things, informs blocking tools of possible suspicious calls.

RE: Email and Web Hosting

2021-07-09 Thread Ryan Finnesey via NANOG 
If the client base wants to stick with basic IMAP/POP3 email Tucows/OpenSRS has 
a good platform.  Also a few years ago my company migrated business email 
accounts and domains from an ISP and moved them to Office 365 and did a revenue 
share with the ISP.  They where happy still got a bit of revenue  but did not 
have to support it.

Ryan


From: NANOG  On Behalf Of 
Steve Saner
Sent: Tuesday, July 6, 2021 10:42 AM
To: nanog@nanog.org
Subject: Email and Web Hosting

I hope this isn't too far off topic for this list.

We acquired a small ISP a couple years ago that has its roots in the "local 
ISPs" of the 90s. This ISP is still hosting email and web services for 
customers both on company domains as well as customer domains. There is some 
decent revenue coming from these services, but cost of maintenance is becoming 
a challenge. We are looking at migrating to another platform or completely 
discontinuing those services.

I'm wondering if others here have gone through that process and have any advice 
as to how to go about it.

--

Steve Saner | Senior Network Engineer

ideatek INTERNET FREEDOM FOR ALL

Cell: 620-860-9433 | 111 Old Mill Lane, Buhler, KS 67522 | 
ideatek.com

This email transmission and any documents, files or previous email messages 
attached to it may contain confidential information. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering the message to the intended recipient, you are hereby notified that 
any dissemination, distribution or copying of this communication is strictly 
prohibited. If you are not or believe you may not be the intended recipient, 
please advise the sender immediately by return email or by calling 
620.543.5026. Then, please take all steps necessary to permanently delete the 
email and all attachments from your computer system. No trees were affected by 
this transmission – though a few billion photons were mildly inconvenienced.

RE: Email and Web Hosting

2021-07-09 Thread Ryan Finnesey via NANOG 
Tucows/OpenSRS works well for “ISP email”

From: NANOG  On Behalf Of 
K. Scott Helms
Sent: Tuesday, July 6, 2021 11:14 AM
To: Steve Saner 
Cc: NANOG list 
Subject: Re: Email and Web Hosting

Two decent options, one on prem and the other fully hosted.

Tucows/OpenSRS has a fully hosted email offering that was built for ISPs to 
resell.  (They also have domain registration and some other ISP focused 
services.)

https://opensrs.com/services/hosted-email/

MagicMail is an email (including webmail) suite that you run on prem.  It is 
comparatively inexpensive but also fully supported.  It's built largely on 
qmail, but they replaced some of the components to deal with spam and virus 
filtering more efficiently.

https://www.magicmail.com/

I have direct experience with both and have used them both for ISPs 
specifically.

Scott Helms


On Tue, Jul 6, 2021 at 10:44 AM Steve Saner 
mailto:ssa...@ideatek.com>> wrote:
I hope this isn't too far off topic for this list.

We acquired a small ISP a couple years ago that has its roots in the "local 
ISPs" of the 90s. This ISP is still hosting email and web services for 
customers both on company domains as well as customer domains. There is some 
decent revenue coming from these services, but cost of maintenance is becoming 
a challenge. We are looking at migrating to another platform or completely 
discontinuing those services.

I'm wondering if others here have gone through that process and have any advice 
as to how to go about it.

--

Steve Saner | Senior Network Engineer

ideatek INTERNET FREEDOM FOR ALL

Cell: 620-860-9433 | 111 Old Mill Lane, Buhler, KS 67522 | 
ideatek.com

This email transmission and any documents, files or previous email messages 
attached to it may contain confidential information. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering the message to the intended recipient, you are hereby notified that 
any dissemination, distribution or copying of this communication is strictly 
prohibited. If you are not or believe you may not be the intended recipient, 
please advise the sender immediately by return email or by calling 
620.543.5026. Then, please take all steps necessary to permanently delete the 
email and all attachments from your computer system. No trees were affected by 
this transmission – though a few billion photons were mildly inconvenienced.

VoP regulatory consultant

2021-07-09 Thread Ryan Finnesey via NANOG 
Would anyone have any recommendations on regulatory consultants for VoIP within 
North America but markets outside the US?

Get Outlook for iOS

Spoofer Report for NANOG for Jun 2021

2021-07-09 Thread CAIDA Spoofer Project 
In response to feedback from operational security communities,
CAIDA's source address validation measurement project
(https://spoofer.caida.org) is automatically generating monthly
reports of ASes originating prefixes in BGP for systems from which
we received packets with a spoofed source address.
We are publishing these reports to network and security operations
lists in order to ensure this information reaches operational
contacts in these ASes.

This report summarises tests conducted within usa, can.

Inferred improvements during Jun 2021:
ASNName   Fixed-By
19624  SERVERROOM 2021-06-06
32035  CCDT   2021-06-09

Further information for the inferred remediation is available at:
https://spoofer.caida.org/remedy.php

Source Address Validation issues inferred during Jun 2021:
ASNName   First-Spoofed Last-Spoofed
209CENTURYLINK-US-LEGACY-QWEST   2016-08-16   2021-06-30
20412  CLARITY-TELECOM   2016-09-30   2021-06-30
6181   FUSE-NET  2016-10-10   2021-06-30
11427  TWC-11427-TEXAS   2016-10-21   2021-06-04
22898  ATLINK2016-12-16   2021-06-29
63296  AWBROADBAND   2017-09-01   2021-06-17
546PARSONS-PGS-1 2017-11-20   2021-06-02
393564 SPOKANE   2018-06-05   2021-06-15
33452  RW2018-09-19   2021-06-16
20448  VPNTRANET-LLC 2018-09-20   2021-06-25
5078   ONENET-AS-1   2020-04-06   2021-06-17
61317  ASDETUK   2020-08-31   2021-06-08
208188 PUGET-SOUND-NETWORKS  2020-12-04   2021-06-29
13876  FIBER-64  2021-05-20   2021-06-26
1299   TELIANET  2021-06-02   2021-06-02
212000   2021-06-21   2021-06-29
22191  WILKES-COMM   2021-06-25   2021-06-29

Further information for these tests where we received spoofed
packets is available at:
https://spoofer.caida.org/recent_tests.php?country_include=usa,can_block=1

Please send any feedback or suggestions to spoofer-i...@caida.org

Re: Do you care about "gray" failures? Can we (network academics) help? A 10-min survey

2021-07-09 Thread Warren Kumari 
On Thu, Jul 8, 2021 at 5:04 PM William Herrin  wrote:
>
> On Thu, Jul 8, 2021 at 5:31 AM Saku Ytti  wrote:
> > Network experiences gray failures all the time, and I almost never
> > care, unless a customer does.
>
> Greetings,
>
> I would suggest that your customer does care, but as there is no
> simple test to demonstrate gray failures, your customer rarely makes
> it past first tier support to bring the issue to your attention and
> gives up trying. Indeed, name the networks with the worst reputations
> around here and many of them have those reputations because of a
> routine, uncorrected state of gray failure.
>
> To answer Laurent 's question:
>
> Yes, gray failures are a regular problem. Yes, most of us care. And
> for the most part we don't have particularly good ways to detect and
> isolate the problems, let alone fix them.

Depending on the actual failure mode, and the architecture of the
device itself, one technique is to run test traffic through the
box/path/whatever while twiddling the source and destination ports,
and sometimes the source IP as well.
This sometimes helps find the issue if there is a bad interface in a
LAG, or in a device which sprays packets/cells across an internal
fabric, etc. If you are really lucky you can convince the vendor to
share how they spray/hash (or, at least demonstrate deterministic
failure and hopefully they can hash and tell which of the N fabric
cards is broken)

Hopefully you noticed the number of weasel words in there...

W



>  When it's not a clean
> failure we really are driven by: customer says blank is broken, often
> followed by grueling manual effort just to duplicate the problem
> within our view.
>
> Can network researchers do anything about it? Maybe. Because of the
> end to end principle, only the endpoints understand the state of the
> connection and they don't know the difference capacity and error. They
> mostly process that information locally sharing only limited
> information with the other endpoint. Which means there's not much
> passing over the wire for the middle to examine and learn that there's
> a problem... and when there is it often takes correlating multiple
> packets to understand that a problem exists which, in the stateless
> middle with asymmetric routing, is not usable. The middle can only
> look at its immediate link stats which, when there's a bug, are
> misleading.
>
> What would you change to dig us out of this hole?
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/



-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

Re: Do you care about "gray" failures? Can we (network academics) help? A 10-min survey

2021-07-09 Thread Chriztoffer Hansen 
On Thu, 8 Jul 2021 at 22:10, Baldur Norddahl  wrote:
> We had a line card that would drop any IPv6 packet with bit #65 in the 
> destination address set to 1. Turns out that only a few hosts have this bit 
> set to 1 in the address, so nobody noticed until some Debian mirrors started 
> to become unreachable. Also, web browsers are very good at switching to IPv4 
> in case of IPv6 timeouts, so nobody would notice web hosts with the problem. 
> And then we had to live with the problem for a while because the device was 
> out of warranty and marked to be replaced, but you do not just replace a 
> router in a hurry unless you absolutely need to.

Grey failures, ugh. Heard of a colleague at prior employment who did
troubleshooting of an issue with an extended line. Where packets to
select IPv4 dest addresses would be dropped by the extended line card.
Took time plus inserting middle-boxes from Vendor Y (packet capture
for evidence) to confirm and convince the vendor of their code had
problems. 