Re: Mailing list SPF Failure

[Hank Nussbacher]

On 17/05/2024 5:45, Karl Auer wrote:

On Thu, 2024-05-16 at 19:27 -0700, Michael Thomas wrote:

On 5/16/24 7:22 PM, Scott Q. wrote:

Mike, you do realize Google/Gmail rejects e-mails with
invalid/missing SPF right ?

I was receiving the mail while NANOG had no SPF record, so no? Any
receiver would be really stupid take a single signal as
disqualifying.

For small-scale senders, it's either or both. For large-scale senders
(5000+ per day) it's both.

At least according to this:

https://support.google.com/a/answer/81126


I think some may have missed these announcements:

https://labs.ripe.net/author/fergalc/enhancing-email-delivery-at-the-ripe-ncc/

https://blog.google/products/gmail/gmail-security-authentication-spam-protection/


Regards,

Hank

Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

[Mark Tinka]

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.

Re: Mailing list SPF Failure

[Tom Beecher]

Same, this address for me is also gmail.

This is what Gmail shows me from earlier today, when the SPF record was not
present :

Message ID <
bff409fd0177c9caf1461e2439691...@polarismail--com.w.emailarray.com>
Created at: Thu, May 16, 2024 at 11:59 AM (Delivered after 77 seconds)
From: "Scott Q."  Using Group-Office
To: Michael Thomas , nanog@nanog.org
Subject: Re: Mailing list SPF Failure
SPF: NONE with IP 50.31.151.76 Learn more


Message ID <74b33cf0-b7c4-46ac-8154-1cfca082e...@mtcc.com>
Created at: Thu, May 16, 2024 at 2:13 PM (Delivered after 85 seconds)
From: Michael Thomas 
To: "Scott Q." , nanog@nanog.org
Subject: Re: Mailing list SPF Failure
SPF: NONE with IP 50.31.151.76 Learn more
DKIM: 'PASS' with domain mtcc.com Learn more


Message ID <20240516190341.beb6f8b53...@ary.qy>
Created at: Thu, May 16, 2024 at 3:03 PM (Delivered after 79 seconds)
From: John Levine 
To: nanog@nanog.org
Subject: Re: Mailing list SPF Failure
SPF: NONE with IP 2001:1838:2001:8:0:0:0:20 Learn more
DKIM: 'FAIL' with domain iecc.com Learn more
DMARC: 'FAIL' Learn more

All 3 of these messages were delivered to my inbox as normal. The messages
from Scott and John provided warnings when hovering over the icon that the
user was not authenticated.


After the SPF record was fixed :

Message ID 
Created at: Thu, May 16, 2024 at 10:36 PM (Delivered after 68 seconds)
From: "John R. Levine" 
To: "Scott Q." 
Subject: Re: Mailing list SPF Failure
SPF: PASS with IP 50.31.151.76 Learn more
DKIM: 'PASS' with domain iecc.com Learn more
DMARC: 'PASS' Learn more

Message ID <
e47a1819deae8e7c8f592ab653c42...@polarismail--com.w.emailarray.com>
Created at: Thu, May 16, 2024 at 10:23 PM (Delivered after 180 seconds)
From: "Scott Q."  Using Group-Office
To: "John R. Levine" , William Herrin 
Subject: Re: Mailing list SPF Failure
SPF: PASS with IP 50.31.151.76 Learn more

The warnings were not present on these messages .

Google's support page if you click on those warnings it here :

https://support.google.com/mail/answer/180707

Where it states the following :

Check if a message is authenticated
>
> Important: Messages that aren't authenticated aren't necessarily spam.
> Sometimes authentication doesn't work for real organizations who send mail
> to big groups, like messages sent to mailing lists.
>

On Thu, May 16, 2024 at 10:46 PM Michael Thomas  wrote:

>
> On 5/16/24 7:36 PM, John R. Levine wrote:
> > I think a lot of us have nanog whitelisted or otherwise special cased.
>
> I don't and gmail is my backend. That's trivial falsification that lack
> of an SPF records alone will cause gmail rejects.
>
> Mike
>
> >
> > Also, it's been pumping out list mail for decades and I expect has a
> > close to zero complaint rate so even without the SPF ths IPs it sends
> > from have a good reputation.
> >
> > On Thu, 16 May 2024, Scott Q. wrote:
> >
> >> I'm surprised nobody noticed for close to 10 days. I was away
> >> from work and upon coming back I saw the little discussion there was ,
> >> in my Spam folder.
> >>
> >> On Thursday, 16/05/2024 at 18:56 John R. Levine wrote:
> >>
> >> On Thu, 16 May 2024, William Herrin wrote:
> >>> The message content (including the message headers) is theoretically
> >>> not used for SPF validation. In practice, some SPF validators don't
> >>> have direct access to the SMTP session so they rely on the SMTP
> >>> session placing the envelope sender in the Return-path header.
> >>
> >> But that wasn't the problem here, the SPF record was just
> >> gone.  Oops.
> >>
> >> I see that the SPF record is back and seems have the correct addresses
> >> so we can now return to our previously scheduled flamage.
>

Re: Mailing list SPF Failure

[Karl Auer]

On Thu, 2024-05-16 at 19:27 -0700, Michael Thomas wrote:
> On 5/16/24 7:22 PM, Scott Q. wrote:
> > Mike, you do realize Google/Gmail rejects e-mails with
> > invalid/missing SPF right ?
> 
> I was receiving the mail while NANOG had no SPF record, so no? Any 
> receiver would be really stupid take a single signal as
> disqualifying.

For small-scale senders, it's either or both. For large-scale senders
(5000+ per day) it's both.

At least according to this:

https://support.google.com/a/answer/81126

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au, he/him)
http://www.biplane.com.au/kauer

Re: Mailing list SPF Failure

[Michael Thomas]

On 5/16/24 7:36 PM, John R. Levine wrote:

I think a lot of us have nanog whitelisted or otherwise special cased.


I don't and gmail is my backend. That's trivial falsification that lack 
of an SPF records alone will cause gmail rejects.


Mike



Also, it's been pumping out list mail for decades and I expect has a 
close to zero complaint rate so even without the SPF ths IPs it sends 
from have a good reputation.


On Thu, 16 May 2024, Scott Q. wrote:


I'm surprised nobody noticed for close to 10 days. I was away
from work and upon coming back I saw the little discussion there was ,
in my Spam folder.

On Thursday, 16/05/2024 at 18:56 John R. Levine wrote:

On Thu, 16 May 2024, William Herrin wrote:

The message content (including the message headers) is theoretically
not used for SPF validation. In practice, some SPF validators don't
have direct access to the SMTP session so they rely on the SMTP
session placing the envelope sender in the Return-path header.


But that wasn't the problem here, the SPF record was just
gone.  Oops.

I see that the SPF record is back and seems have the correct addresses
so we can now return to our previously scheduled flamage.

Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

[Michael Thomas]

On 5/16/24 6:55 PM, John Levine wrote:

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.


I was screaming at the top of my lungs that P-Asserted-Identity was 
going to bite them in the ass 20 years ago. And then they eventually 
came up with something that solved the wrong problem in the most 
bellheaded way possible 15 years later. Bellheads should not be trusted 
with internet security. The FCC is most likely not blameless here either 
but the telcos/bellheads most certainly aren't either. Anybody who 
thinks this is an either/or problem is wrong.


Mike

Re: Mailing list SPF Failure

[Tom Beecher]

>
> I'm surprised nobody noticed for close to 10 days.


Probably because it wasn't 10 days.

On Thu, May 16, 2024 at 10:26 PM Scott Q.  wrote:

> I'm surprised nobody noticed for close to 10 days. I was away from work
> and upon coming back I saw the little discussion there was , in my Spam
> folder.
>
> On Thursday, 16/05/2024 at 18:56 John R. Levine wrote:
>
> On Thu, 16 May 2024, William Herrin wrote:
> > The message content (including the message headers) is theoretically
> > not used for SPF validation. In practice, some SPF validators don't
> > have direct access to the SMTP session so they rely on the SMTP
> > session placing the envelope sender in the Return-path header.
>
> But that wasn't the problem here, the SPF record was just gone.  Oops.
>
> I see that the SPF record is back and seems have the correct addresses so
> we can now return to our previously scheduled flamage.
>
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
>
>

Re: Mailing list SPF Failure

[John R. Levine]

I think a lot of us have nanog whitelisted or otherwise special cased.

Also, it's been pumping out list mail for decades and I expect has a close 
to zero complaint rate so even without the SPF ths IPs it sends from have 
a good reputation.


On Thu, 16 May 2024, Scott Q. wrote:


I'm surprised nobody noticed for close to 10 days. I was away
from work and upon coming back I saw the little discussion there was ,
in my Spam folder.

On Thursday, 16/05/2024 at 18:56 John R. Levine wrote:

On Thu, 16 May 2024, William Herrin wrote:

The message content (including the message headers) is theoretically
not used for SPF validation. In practice, some SPF validators don't
have direct access to the SMTP session so they rely on the SMTP
session placing the envelope sender in the Return-path header.


But that wasn't the problem here, the SPF record was just
gone.  Oops.

I see that the SPF record is back and seems have the correct addresses
so we can now return to our previously scheduled flamage.

Re: Mailing list SPF Failure

[Michael Thomas]

On 5/16/24 7:22 PM, Scott Q. wrote:
Mike, you do realize Google/Gmail rejects e-mails with invalid/missing 
SPF right ?


I was receiving the mail while NANOG had no SPF record, so no? Any 
receiver would be really stupid take a single signal as disqualifying.


Mike




If you want to tell them they're broken...there's a few guys on the 
list here.


On Thursday, 16/05/2024 at 19:17 Michael Thomas wrote:

On 5/16/24 3:54 PM, William Herrin wrote:
> On Thu, May 16, 2024 at 12:03 PM John Levine mailto:jo...@iecc.com>> wrote:
>> It appears that Michael Thomas mailto:m...@mtcc.com>> said:
>>> Since probably 99% of the mail from NANOG is through this list, it
>>> hardly matters since SPF will always fail.
>> Sorry, but no. A mailing list puts its own envelope return
address on
>> the message so with a reasonable SPF record, SPF will normally
>> succeed.
> Exactly. SPF acts on the -envelope- sender. That means the one
> presented in the SMTP From:<> command. For mail from nanog, that's:
> nanog-bounces+addr...@nanog.org
, regardless of what the
sender's
> header From address is.
>
> The message content (including the message headers) is theoretically
> not used for SPF validation. In practice, some SPF validators don't
> have direct access to the SMTP session so they rely on the SMTP
> session placing the envelope sender in the Return-path header.

Yes, and why is that needed? The mailing list resigning has the same
effect and then you only need one mechanism instead of two and
with DKIM
you get the benefit that it's signing the 822 address which can be
used
for user level stuff in way that SPF is a little sus. So it makes SPF
pretty irrelevant. IMO, SPF was always a stopgap since there was no
guarantee that DKIM would be deployed. 20 years on, I guess I
don't feel
like I need to keep my trap shut about that.

If a receiving site is rejecting something solely based on the
lack of a
SPF record but has a valid DKIM signature, the site is broken IMO.

Mike

Re: Mailing list SPF Failure

[Scott Q.]

I'm surprised nobody noticed for close to 10 days. I was away
from work and upon coming back I saw the little discussion there was ,
in my Spam folder.

On Thursday, 16/05/2024 at 18:56 John R. Levine wrote:



On Thu, 16 May 2024, William Herrin wrote:
> The message content (including the message headers) is theoretically
> not used for SPF validation. In practice, some SPF validators don't
> have direct access to the SMTP session so they rely on the SMTP
> session placing the envelope sender in the Return-path header.

But that wasn't the problem here, the SPF record was just
gone.  Oops.

I see that the SPF record is back and seems have the correct addresses
so 
we can now return to our previously scheduled flamage.

Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for
Dummies",
Please consider the environment before reading this e-mail.
https://jl.ly

Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

[John Levine]

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.

R's,
John

Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

[Michael Thomas]

On 5/16/24 4:17 PM, Brandon Martin wrote:


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.


I think it should be pointed out that the STIR/SHAKEN crowd doesn't 
really get it either. The problem is mainly a problem of the border 
between bad guys and the onramps onto the PSTN. SIP has made that dirt 
cheap and something anybody can do it for nothing at all down in their 
basements. It's essentially the same thing as email back in the days of 
open relays and no submission auth. STIR/SHAKEN obfuscated that problem 
by trying to solve the problem of who is allowed to assert what E.164 
address when it's much easier to solve in the "where did this come from 
and who should I blame?" realm. I don't hear anybody moaning about 
deploying DKIM except maybe spammer sites that don't want accountability 
and their onramp sites that turn a blind eye making money off them. They 
care these days because for legit senders, baddies cost them money due 
to deliverability. It would have been trivial to attach a DKIM like 
signature to SIP messages and be done with it instead of trying to boil 
the legacy addressing ocean. I should know, I did that for shits and 
giggles about 20 years ago.


Mike

Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

[Job Snijders via NANOG]

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-Ben-Cartwright-Cox.pdf

Kind regards,

Job

Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

[Brandon Martin]

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.


Regulating the phone system is not exactly a new thing for the FCC, 
after all.


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.


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.


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.


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.

--
Brandon Martin

Re: Mailing list SPF Failure

[Michael Thomas]

On 5/16/24 3:54 PM, William Herrin wrote:

On Thu, May 16, 2024 at 12:03 PM John Levine  wrote:

It appears that Michael Thomas  said:

Since probably 99% of the mail from NANOG is through this list, it
hardly matters since SPF will always fail.

Sorry, but no. A mailing list puts its own envelope return address on
the message so with a reasonable SPF record, SPF will normally
succeed.

Exactly. SPF acts on the -envelope- sender. That means the one
presented in the SMTP From:<> command. For mail from nanog, that's:
nanog-bounces+addr...@nanog.org, regardless of what the sender's
header From address is.

The message content (including the message headers) is theoretically
not used for SPF validation. In practice, some SPF validators don't
have direct access to the SMTP session so they rely on the SMTP
session placing the envelope sender in the Return-path header.


Yes, and why is that needed? The mailing list resigning has the same 
effect and then you only need one mechanism instead of two and with DKIM 
you get the benefit that it's signing the 822 address which can be used 
for user level stuff in way that SPF is a little sus. So it makes SPF 
pretty irrelevant. IMO, SPF was always a stopgap since there was no 
guarantee that DKIM would be deployed. 20 years on, I guess I don't feel 
like I need to keep my trap shut about that.


If a receiving site is rejecting something solely based on the lack of a 
SPF record but has a valid DKIM signature, the site is broken IMO.


Mike

Re: Mailing list SPF Failure

[John R. Levine]

On Thu, 16 May 2024, William Herrin wrote:

The message content (including the message headers) is theoretically
not used for SPF validation. In practice, some SPF validators don't
have direct access to the SMTP session so they rely on the SMTP
session placing the envelope sender in the Return-path header.


But that wasn't the problem here, the SPF record was just gone.  Oops.

I see that the SPF record is back and seems have the correct addresses so 
we can now return to our previously scheduled flamage.


Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: Mailing list SPF Failure

[William Herrin]

On Thu, May 16, 2024 at 12:03 PM John Levine  wrote:
> It appears that Michael Thomas  said:
> >Since probably 99% of the mail from NANOG is through this list, it
> >hardly matters since SPF will always fail.
>
> Sorry, but no. A mailing list puts its own envelope return address on
> the message so with a reasonable SPF record, SPF will normally
> succeed.

Exactly. SPF acts on the -envelope- sender. That means the one
presented in the SMTP From:<> command. For mail from nanog, that's:
nanog-bounces+addr...@nanog.org, regardless of what the sender's
header From address is.

The message content (including the message headers) is theoretically
not used for SPF validation. In practice, some SPF validators don't
have direct access to the SMTP session so they rely on the SMTP
session placing the envelope sender in the Return-path header.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: FCC proposes Internet Routing Security Reporting Requirements

[Job Snijders via NANOG]

Dear all,

A fact sheet has now been published, with much more detail and
considerations: https://docs.fcc.gov/public/attachments/DOC-402609A1.pdf

This is a VERY interesting read!

Kind regards,

Job

Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

[Josh Luthman]

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

Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

[Job Snijders via NANOG]

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

Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

[Josh Luthman]

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

Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

[Brandon Zhi]

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

Re: Mailing list SPF Failure

[John Levine]

It appears that Michael Thomas  said:
>On 5/16/24 8:11 AM, Peter Potvin via NANOG wrote:
>> Appears there’s no SPF record at all now for nanog.org 
>> , which is not ideal…
>
>Since probably 99% of the mail from NANOG is through this list, it 
>hardly matters since SPF will always fail.

Sorry, but no. A mailing list puts its own envelope return address on
the message so with a reasonable SPF record, SPF will normally
succeed. (If the mail is subsequently forwarded SPF will fail, but
that's not unique to mailing lists.)

DKIM and DMARC do not get along with mailing lists, but SPF is OK, at
least as OK as SPF ever is.

tl;dr nanog needs to put back its SPF record. It'll make some systems
such as Gmail considerably more likely to accept the mail.

R's,
John

Re: Meet NANOG's New Executive Director! N91 Agenda is LIVE! + More

[Job Snijders via NANOG]

On Thu, May 16, 2024 at 02:23:52PM -0400, Nanog News wrote:
> *Jonathan Black has been appointed NANOG Executive Director*
> 
> In his new role, Jonathan will be responsible for the organization's
> operational management and will collaborate with the NANOG Board to
> refine, articulate, and implement NANOG's mission and strategic plan.

Jonathan, I wish you a warm welcome!

Kind regards,

Job

Meet NANOG's New Executive Director! N91 Agenda is LIVE! + More

[Nanog News]

*Meet NANOG's New Executive Director!*
*VIDEO - Interview with Jonathan Black *

*Jonathan Black has been appointed NANOG Executive Director*

In his new role, Jonathan will be responsible for the organization's
operational management and will collaborate with the NANOG Board to refine,
articulate, and implement NANOG's mission and strategic plan.

Find out more about Jonathan's background + vision in a video interview
with NANOG's content producer Elizabeth Drolet.

*VIEW NOW *


*NANOG 91 Agenda is LIVE! *
*Sync Your Calendars Now! *

*All NANOG 91 programming is now available on the NANOG website. *

 Download saved talks to your calendar.
All saved talks will also show on your appointment calendar.

*VIEW NOW  *

*New NANOG 91 Conference Kit Available*
*Share on your Social, Newsletter, Website, + More! *

Help us spread the word about NANOG 91!

All N91 materials, including messaging, logos, and graphics, needed to
promote our next meeting are accessible on our website. Download and share
with your community today!


*VIEW NOW  *

[NANOG-announce] Meet NANOG's New Executive Director! N91 Agenda is LIVE! + More

[Nanog News]

*Meet NANOG's New Executive Director!*
*VIDEO - Interview with Jonathan Black *

*Jonathan Black has been appointed NANOG Executive Director*

In his new role, Jonathan will be responsible for the organization's
operational management and will collaborate with the NANOG Board to refine,
articulate, and implement NANOG's mission and strategic plan.

Find out more about Jonathan's background + vision in a video interview
with NANOG's content producer Elizabeth Drolet.

*VIEW NOW *


*NANOG 91 Agenda is LIVE! *
*Sync Your Calendars Now! *

*All NANOG 91 programming is now available on the NANOG website. *

 Download saved talks to your calendar.
All saved talks will also show on your appointment calendar.

*VIEW NOW  *

*New NANOG 91 Conference Kit Available*
*Share on your Social, Newsletter, Website, + More! *

Help us spread the word about NANOG 91!

All N91 materials, including messaging, logos, and graphics, needed to
promote our next meeting are accessible on our website. Download and share
with your community today!


*VIEW NOW  *
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

[Sean Donelan]

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

Re: Mailing list SPF Failure

[Michael Thomas]

On 5/16/24 8:59 AM, Scott Q. wrote:
Uhm, not really. An SPF failure is really bad even though DKIM works. 
It might depend what they do with DMARC but even so, there's no reason 
they can't just add that IP to their SPF record.


SPF has from day one been known to be broken with mailing lists. It's 
not "really bad", it's just what it is. There are other modes that SPF 
fails too like forwarding. Frankly I've tried to keep clear of "SPF is 
pointless", but it is actually pointless. It doesn't bring anything to 
the table that DKIM can't do better.


Mike

Re: Mailing list SPF Failure

[Scott Q.]

Uhm, not really. An SPF failure is really bad even though DKIM
works. It might depend what they do with DMARC but even so, there's no
reason they can't just add that IP to their SPF record.

>From what I see, it's been broken at least since May 6-7.


On Thursday, 16/05/2024 at 11:37 Michael Thomas wrote:









On 5/16/24 8:11 AM, Peter Potvin via NANOG wrote:
 

 
Appears there’s no SPF record at all now for nanog.org [1], which is
not ideal…
 

 

Since probably 99% of the mail from NANOG is through this list, it
hardly matters since SPF will always fail. What is more important is
that they resign with DKIM so that receivers can use that identity.
SPF is for the most part belt and suspenders.




Mike









 




Kind regards, 
Peter Potvin 

 



On Thu, May 16, 2024 at 02:59 Bjørn Mork  wrote:
 

"Scott Q."  writes:

> Anyone else getting SPF failures on all messages sent to the list
> ?
>
> I see them all originating from 50.31.151.76 but nanog.org [1]'s
SPF
> record doesn't list that as allowed.

I see the same.  nanog.org [1] mail is originated from
2001:1838:2001:8:0:0:0:20 or 50.31.151.76, and the SPF record is
currently

 "v=spf1 a include:_spf.google.com [2] ~all"

Neither of those are Google addresses so it's a soft fail.


Bjørn


   





Links:
--
[1] http://nanog.org
[2] http://spf.google.com

Re: Mailing list SPF Failure

[Michael Thomas]

On 5/16/24 8:11 AM, Peter Potvin via NANOG wrote:
Appears there’s no SPF record at all now for nanog.org 
, which is not ideal…


Since probably 99% of the mail from NANOG is through this list, it 
hardly matters since SPF will always fail. What is more important is 
that they resign with DKIM so that receivers can use that identity. SPF 
is for the most part belt and suspenders.


Mike




Kind regards,
Peter Potvin


On Thu, May 16, 2024 at 02:59 Bjørn Mork  wrote:

"Scott Q."  writes:

> Anyone else getting SPF failures on all messages sent to the list
> ?
>
> I see them all originating from 50.31.151.76 but nanog.org
's SPF
> record doesn't list that as allowed.

I see the same. nanog.org  mail is originated from
2001:1838:2001:8:0:0:0:20 or 50.31.151.76, and the SPF record is
currently

 "v=spf1 a include:_spf.google.com  ~all"

Neither of those are Google addresses so it's a soft fail.


Bjørn

Re: Mailing list SPF Failure

[Peter Potvin via NANOG]

Appears there’s no SPF record at all now for nanog.org, which is not ideal…

Kind regards,
Peter Potvin


On Thu, May 16, 2024 at 02:59 Bjørn Mork  wrote:

> "Scott Q."  writes:
>
> > Anyone else getting SPF failures on all messages sent to the list
> > ?
> >
> > I see them all originating from 50.31.151.76 but nanog.org's SPF
> > record doesn't list that as allowed.
>
> I see the same.  nanog.org mail is originated from
> 2001:1838:2001:8:0:0:0:20 or 50.31.151.76, and the SPF record is
> currently
>
>  "v=spf1 a include:_spf.google.com ~all"
>
> Neither of those are Google addresses so it's a soft fail.
>
>
> Bjørn
>

Re: Q: is RFC3531 still applicable?

[Mel Beckman]

Bill,

I would just make it /64s all the way down. Subnetting a /64 is like taking 
half-breaths from a snorkel: why bother when the supply is effectively infinite?

 -mel

> On May 16, 2024, at 3:35 AM, William Herrin  wrote:
> 
> On Wed, May 15, 2024 at 10:09 PM Mel Beckman  wrote:
>> The RFC seems to be concerned with aggregation efficiency, and while that 
>> may be a concern someday, so far computer and memory capacity has far 
>> outstripped prefix growth in the default-free zone.
>> 
>> If you can explain why a /64 would ever not be enough for a single subnet, 
>> I’m willing to listen.
> 
> The subnet contains a router that gateways to another /64. For
> example, there's a home automation controller and the controller
> implements its own lan of components on a different media type.
> 
> Instead of assigning a pair of /64's, you assign a /63 and then route
> a /64 from the /63 to the home automation controller.
> 
> Except you don't do that either. IPv6 is plentiful and reverse-DNS
> delegates cleanly on 4-bit boundaries so you think in terms of 4-bit
> boundaries instead: assign a /60, use a /64 on the immediate LAN and
> route a /64 to the home automation controller and retain the balance
> for the next device that wants to implement an internal subnet.
> 
> Regards,
> Bill Herrin
> 
> 
> 
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: Q: is RFC3531 still applicable?

[William Herrin]

On Wed, May 15, 2024 at 10:09 PM Mel Beckman  wrote:
> The RFC seems to be concerned with aggregation efficiency, and while that may 
> be a concern someday, so far computer and memory capacity has far outstripped 
> prefix growth in the default-free zone.
>
> If you can explain why a /64 would ever not be enough for a single subnet, 
> I’m willing to listen.

The subnet contains a router that gateways to another /64. For
example, there's a home automation controller and the controller
implements its own lan of components on a different media type.

Instead of assigning a pair of /64's, you assign a /63 and then route
a /64 from the /63 to the home automation controller.

Except you don't do that either. IPv6 is plentiful and reverse-DNS
delegates cleanly on 4-bit boundaries so you think in terms of 4-bit
boundaries instead: assign a /60, use a /64 on the immediate LAN and
route a /64 to the home automation controller and retain the balance
for the next device that wants to implement an internal subnet.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Mailing list SPF Failure

[Bjørn Mork]

"Scott Q."  writes:

> Anyone else getting SPF failures on all messages sent to the list
> ?
>
> I see them all originating from 50.31.151.76 but nanog.org's SPF
> record doesn't list that as allowed.

I see the same.  nanog.org mail is originated from
2001:1838:2001:8:0:0:0:20 or 50.31.151.76, and the SPF record is
currently

 "v=spf1 a include:_spf.google.com ~all"

Neither of those are Google addresses so it's a soft fail.


Bjørn