Re: Microsoft missing public DNS TXT entry for DKIM records (msn.com)

[Michael Thomas]

On 4/4/24 12:43 AM, Jay Acuna wrote:

On Thu, Apr 4, 2024 at 1:23 AM Adam Brenner via NANOG  wrote:
..

It seems to me that if msn.com is going to include DKIM headers in their
outgoing email, they should also publish their DKIM public key. If they
are not going to publish their DKIM public key, then they should not
include DKIM headers in their outgoing email.

Microsoft can still sign the message, Even if the signature cannot be verified
because they have not yet published the Public Key, for whatever reason.
That is a partial/incomplete implementation of DKIM then.


There is one potential reason a site might want to do this which is to 
essentially invalidate signatures from a non-repudiation standpoint. 
Simply unpublishing the key while not 100% foolproof is essentially 
saying "we don't take responsibility for mail signed with this key 
anymore" -- sort of like the expirey tag in the header but with 
attitude. The entire kerfuffle about Her Emails (ie Hillary's email 
server) was in part about the fact that the mail on it could still be 
verified and thus not denied. After, there were calls for providers to 
publish their private keys on a regular basis but that went nowhere that 
I've heard of. That's probably not what's going on here -- maybe they 
just botched a key rollover -- but it still amusing to me that we got 
non-repudiation along for the ride [*].


Mike

[*] while DKIM only speaks at the domain level and not an individual 
account, if providers always require submission auth before signing that 
seems pretty airtight to me

Re: IPv6 uptake

[Michael Thomas]

On 2/18/24 1:10 PM, Nick Hilliard wrote:

Michael Thomas wrote on 18/02/2024 20:56:
That's really great to hear. Of course there is still the problem 
with CPE that doesn't speak v6, but that's not their fault and gives 
some reason to use their CPE.


Already solved: cable modem ipv6 support is usually also excellent, 
both in terms of subscriber services handoff and management. The 
requirements for ipv6 support are very clearly defined in the 
cablelabs docsis 3.0 specification.


So it has its own wireless? I seem to recall that there were some 
economic reasons to use their CPE as little as possible to avoid rent. 
Has that changed? Or can I run down and just buy a Cablelabs certified 
router/modem these days?


Mike

Re: IPv6 uptake

[Michael Thomas]

On 2/18/24 12:50 PM, Nick Hilliard wrote:

Michael Thomas wrote on 18/02/2024 20:28:
I do know that Cablelabs pretty early on -- around the time I 
mentioned above -- has been pushing for v6. Maybe Jason Livingood can 
clue us in. Getting cable operators onboard too would certainly be a 
good thing,


availability of provider-side ipv6 support is generally excellent on 
docsis networks. This includes end-user device support, management, 
client and server side provisioning, the works. This is one of the 
real ipv6 success stories in the service provider arena.


That's really great to hear. Of course there is still the problem with 
CPE that doesn't speak v6, but that's not their fault and gives some 
reason to use their CPE.


Mike

Re: IPv6 uptake (was: The Reg does 240/4)

[Michael Thomas]

On 2/18/24 8:47 AM, Greg Skinner via NANOG wrote:

On Feb 17, 2024, at 11:27 AM, William Herrin  wrote:

On Sat, Feb 17, 2024 at 10:34?AM Michael Thomas  wrote:


Funny, I don't recall Bellovin and Cheswick's Firewall book discussing
NAT.

And mine too, since I hadn't heard of "Firewalls and Internet
Security: Repelling the Wily Hacker" and have not read it.

For what it's worth, both editions of Bellovin and Cheswick's Firewalls book 
are online. [1]  Also, there are discussions about NAT and how it influenced 
IPng (eventually IPv6) on the big-internet list. [2]


FWIW, while at Cisco I started to get wind of some NAT-like proposal 
being floated by 3COM at Packetcable back in the late 90's, early 2000's 
(sorry, I have no memory of the specifics now). That was pretty 
horrifying to me and others as the implication was that we'd have to 
implement it in our routers, which I'm sure 3COM viewed as a feature, 
not a bug. We pushed back that implementing IPv6 was a far better option 
if it came down to that. That sent me and Steve Deering off on an 
adventure to figure out how we might actually make good on that 
alternative in the various service provider BU's. Unsurprisingly the 
BU's were not very receptive not just because of the problems with v6 vs 
hardware forwarding, but mostly because providers weren't asking for it. 
They weren't asking for CGNAT like things either though so it was mostly 
the status quo. IOS on the other hand was taking IPv6 much more 
seriously so that providers could at least deploy it in the small for 
testing, pilots, etc even if it was a patchwork in the various platforms.


The problem with v6 uptake has always been on the provider side. BU's 
wouldn't have wanted to respin silicon but if providers were asking for 
it and it gave them a competitive advantage, they'd have done it in a 
heartbeat. It's heartening to hear that a lot of big providers and orgs 
are using IPv6 internally to simplify management along with LTE's use of 
v6. I don't know what's happening in MSO land these days, but it would 
be good to hear if they too are pushing a LTE-like solution. I do know 
that Cablelabs pretty early on -- around the time I mentioned above -- 
has been pushing for v6. Maybe Jason Livingood can clue us in. Getting 
cable operators onboard too would certainly be a good thing, though LTE 
doesn't have to deal with things like brain dead v4-only wireless 
routers on their network.


Mike

Re: IPv6 uptake (was: The Reg does 240/4)

[Michael Thomas]

On 2/17/24 11:27 AM, William Herrin wrote:

On Sat, Feb 17, 2024 at 10:34 AM Michael Thomas  wrote:

I didn't hear about NAT until the
late 90's, iirc. I've definitely not heard of Gauntlet.

Then there are gaps in your knowledge.


Funny, I don't recall Bellovin and Cheswick's Firewall book discussing
NAT.

And mine too, since I hadn't heard of "Firewalls and Internet
Security: Repelling the Wily Hacker" and have not read it.

I see that the book was published in 1994. In 1994 Gauntlet was
calling their process "transparent application layer gateways," not
NAT.

What was called NAT in 1994 was stateless 1:1 NAT, where one IP mapped
to exactly one IP in both directions. Stateless 1:1 NAT had no impact
on security. But that's not the technology we're talking about in
2024. Stateless 1:1 NAT is so obsolete that support was dropped from
the Linux kernel a long time ago. That actually caused a problem for
me in 2017. I had a use where I wanted 1:1 NAT and wanted to turn off
connection tracking so that I could do asymmetric routing through the
stateless translators. No go.

So it does not surprise me that a 1994 book on network security would
not have discussed NAT. They'd have referred to the comparable
contemporary technology, which was "transparent application layer
gateways." Those behaved like what we now call NAT but did the job a
different way: instead of modifying packets, they terminated the
connection and proxied it.


I don't recall the book talking about proxies, but it's been a long 
time. It was mostly about (stateful) firewalls, iirc. The rapid 
expansion of the internet caused a huge need for a big band-aid, 
especially with shitty windows boxes emerging on the net shortly after. 
A stateful firewall walled off for incoming on client subnets was 
perfectly sufficient though, and need to provision clients with proxies 
and the necessary software. The book is not very long and honestly 
that's a feature as it seemed to mostly be trying to get the word out 
that we should be protecting ourselves at the borders until better 
security could get deployed. If NAT's supposed belt and suspenders 
security was such a big feature, I don't recall anybody talking about it 
that way back then. That's why it's always seemed like a post-hoc 
rationalization. When I was at Cisco, all of the internal networks were 
numbered in public address space and I never once heard any clamor for 
the client space to be renumbered into RFC 1918 space for security 
reasons. Admittedly anybody doing so would have faced fierce resistance, 
but if there were any debate at all it was that adding state to network 
flows was a Bad Thing.


NAT has always been about overloading public IP addresses first and 
foremost. The supposed security gains are vastly dwarfed by the decrease 
in functionality that NAT brings with it. One only has to look at the 
mental gymnastics that goes into filling out SDP announcements for VoIP 
to know that any supposed security benefits are not worth the trouble 
that it brings. If it were only security, nobody would have done it. It 
was always about address conservation first and foremost.


Mike

Re: IPv6 mail The Reg does 240/4

[Michael Thomas]

On 2/17/24 2:21 PM, John Levine wrote:

But what happens under the hood at

major mailbox providers is maddeningly opaque so who really knows? It
would be nice if MAAWG published a best practices or something like that
to outline what is actually happening in live deployments.

Unfortunately, spammers can read just as well as we can so it's not
going to happen.


They already have the recon so they don't need any help. The rest of us 
could be helped by what the current art is.


Mike

Re: The Reg does 240/4

[Michael Thomas]

On 2/17/24 10:19 AM, Owen DeLong via NANOG wrote:
Mike, it’s true that Google used to be a lot less strict on IPv4 email 
than IPv6, but they want SPF and /or DKIM on everything now, so it’s 
mostly the same. There is less reputation data available for IPv6 and 
server reputation is a harder problem in IPv6, but reputation systems 
are becoming less relevant.


I kind of get the impression that once you get to aggregates at the 
domain level like DKIM or SPF, addresses as a reputation vehicle don't 
much figure into decision making. But what happens under the hood at 
major mailbox providers is maddeningly opaque so who really knows? It 
would be nice if MAAWG published a best practices or something like that 
to outline what is actually happening in live deployments.


Mike

Re: IPv6 uptake

[Michael Thomas]

On 2/17/24 10:26 AM, Owen DeLong via NANOG wrote:



On Feb 16, 2024, at 14:20, Jay R. Ashworth  wrote:

- Original Message -

From: "Justin Streiner" 
4. Getting people to unlearn the "NAT=Security" mindset that we were forced
to accept in the v4 world.

NAT doesn't "equal" security.

But it is certainly a *component* of security, placing control of what internal
nodes are accessible from the outside in the hands of the people inside.

Uh, no… no it is not. Stateful inspection (which the kind of NAT (actually 
NAPT) you are assuming here depends on) is a component of security. You can do 
stateful inspection without mutilating the header and have all the same 
security benefits without losing or complicating the audit trail.


Exactly. As I said elsewhere, the security properties of NAT were a 
post-hoc rationalization. In the mean time, it has taken on its own life 
as if not NAT'ing (but still having stateful firewalls) would end the 
known security universe. We can seriously lose NAT for v6 and not lose 
anything of worth.


Mike

Re: IPv6 uptake (was: The Reg does 240/4)

[Michael Thomas]

On 2/16/24 6:33 PM, William Herrin wrote:

On Fri, Feb 16, 2024 at 6:10 PM Ryan Hamel  wrote:

Depending on where that rule is placed within your ACL, yes that can happen 
with *ANY* address family.

Hi Ryan,

Correct. The examples illustrated a difference between a firewall
implementing address-overloaded NAT and a firewall implementing
everything except the address translation. Either example could be
converted to the other address family and it would work the same way.


All things aside, I agree with Dan that NAT was never
ever designed to be a security tool. It is used because
of the scarcity of public address space, and it provides
a "defense" depending on how it is implemented, with
minimal effort. This video tells the story of NAT and the
Cisco PIX, straight from the creators
https://youtu.be/GLrfqtf4txw

NAT's story, the modern version of NAT when we talk about IPv4
firewalls, started in the early '90s with the Gauntlet firewall. It
was described as a transparent application layer gateway. Gauntlet
focused on solving enterprise security issues. Gauntlet's technology
converged with what was then 1:1 NAT to produce the address-overloaded
NAT like what later appeared in the Cisco PIX (also first and foremost
a security product) and is present in all our DSL and cable modems
today.

Security came first, then someone noticed it'd be useful for address
conservation too. Gauntlet's customers generally had or could readily
get a supply of public IP addresses. Indeed, when Gauntlet was
released, IP addresses were still available from
hostmas...@internic.net at zero cost and without any significant
documentation. And Gauntlet was expensive: folks who couldn't easily
obtain public IP addresses also couldn't afford it.


Funny, I don't recall Bellovin and Cheswick's Firewall book discussing 
NAT. That was sort of the go-to book for hard-on-the-outside 
soft-on-the-inside defense. Maybe they were unaware of this, or maybe 
they didn't agree with the premise. I didn't hear about NAT until the 
late 90's, iirc. I've definitely not heard of Gauntlet.


As I recall, it was very much an afterthought with cable/DOCSIS to use 
NAT to conserve addresses. The headend DHCP server just gave public 
addresses to whoever asked. DOCSIS CPE at that time was just an L2 
modem. NAT traversal absolutely was not on the table with Packetcable 
back in the late 90's, and believe me we were very concerned about the 
security of MGCP since it was UDP based.


Which is to say that NAT came around to preserve address space. Any 
security properties were sort of a post-hoc rationalization and hotly 
debated given all the things NAT broke.


Mike

Re: IPv6 uptake (was: The Reg does 240/4)

[Michael Thomas]

On 2/16/24 5:37 PM, William Herrin wrote:

On Fri, Feb 16, 2024 at 5:33 PM Michael Thomas  wrote:

So you're not going to address that this is a management plain problem.

Hi Mike,

What is there to address? I already said that NAT's security
enhancement comes into play when a -mistake- is made with the network
configuration. You want me to say it again? Okay, I've said it again.


The implication being that we should keep NAT'ing ipv6 for... a thin 
veil of security. That all of the other things that NAT breaks is worth 
the trouble because we can't trust our fat fingers on firewall configs.


Mike

Re: IPv6 uptake (was: The Reg does 240/4)

[Michael Thomas]

On 2/16/24 5:30 PM, William Herrin wrote:

On Fri, Feb 16, 2024 at 5:22 PM Michael Thomas  wrote:

On 2/16/24 5:05 PM, William Herrin wrote:

Now, I make a mistake on my firewall. I insert a rule intended to
allow packets outbound from 2602:815:6001::4 but I fat-finger it and
so it allows them inbound to that address instead. Someone tries to
telnet to 2602:815:6001::4. What happens? Hacked.

Yes, but if the DHCP database has a mistake it's pretty much the same
situation since it could be numbered with a public address.

Um. No. You'd have to make multiple mistakes cross-contaminating your
public and private ethernet segments yet somehow without completely
breaking your network rendering it inoperable.


So you're not going to address that this is a management plain problem. ok.

Mike

Re: IPv6 uptake (was: The Reg does 240/4)

[Michael Thomas]

On 2/16/24 5:05 PM, William Herrin wrote:

On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas  wrote:

If you know which subnets need to be NAT'd don't you also know which
ones shouldn't exposed to incoming connections (or conversely, which
should be permitted)? It seems to me that all you're doing is moving
around where that knowledge is stored? Ie, DHCP so it can give it
private address rather than at the firewall knowing which subnets not to
allow access? Yes, DHCP can be easily configured to make everything
private, but DHCP for static reachable addresses is pretty handy too.

Hi Mike,

Suppose I have a firewall at 2602:815:6000::1 with an internal network
of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a
switch that accepts telnet connections with a user/password of
admin/admin. On the firewall, I program it to disallow all Internet
packets to 2602:815:6001::/64 that are not part of an established
connection.

Someone tries to telnet to 2602:815:6001::4. What happens? Blocked.

Now, I make a mistake on my firewall. I insert a rule intended to
allow packets outbound from 2602:815:6001::4 but I fat-finger it and
so it allows them inbound to that address instead. Someone tries to
telnet to 2602:815:6001::4. What happens? Hacked.


Yes, but if the DHCP database has a mistake it's pretty much the same 
situation since it could be numbered with a public address. For both you 
can have the default as "reject" or "accept" -- that's just a default 
and depends on how you want to manage your network.


NAT is not without its own set of problems, so if this boils down to a 
subnet management issue there are obviously ways to deal with that to 
avoid NAT's problems. Both DHCP and firewall configs don't have to be 
the ultimate source of truth about any of this. And that's likely a Good 
Thing since you want them to be pretty much as fungible and replaceable 
as possible. If you're exposed to fat fingers for either, you're 
probably already in trouble. Something in the management plain is far 
more likely to care about this kind of thing than hardware vendors who 
see that as a cost center with predictably shitty implementations.


Mike

Re: IPv6 uptake (was: The Reg does 240/4)

[Michael Thomas]

On 2/16/24 3:01 PM, William Herrin wrote:

On Fri, Feb 16, 2024 at 2:19 PM Jay R. Ashworth  wrote:

From: "Justin Streiner" 
4. Getting people to unlearn the "NAT=Security" mindset that we were forced
to accept in the v4 world.

NAT doesn't "equal" security.

But it is certainly a *component* of security, placing control of what internal
nodes are accessible from the outside in the hands of the people inside.

Hi Jay,

Every firewall does that. What NAT does above and beyond is place
control of what internal nodes are -addressable- from the outside in
the hands of the people inside -- so that most of the common mistakes
with firewall configuration don't cause the internal hosts to -become-
accessible.


If you know which subnets need to be NAT'd don't you also know which 
ones shouldn't exposed to incoming connections (or conversely, which 
should be permitted)? It seems to me that all you're doing is moving 
around where that knowledge is stored? Ie, DHCP so it can give it 
private address rather than at the firewall knowing which subnets not to 
allow access? Yes, DHCP can be easily configured to make everything 
private, but DHCP for static reachable addresses is pretty handy too.


Mike

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Michael Thomas]

On 1/15/24 11:02 PM, Saku Ytti wrote:

On Mon, 15 Jan 2024 at 21:08, Michael Thomas  wrote:


An ipv4 free network would be nice, but is hardly needed. There will
always be a long tail of ipv4 and so what? You deal with it at your

I mean Internet free DFZ, so that everyone is not forced to maintain
two stacks at extra cost, fragility and time. Any protocols at the
inside networks are fine, as long as you're meeting the Internet with
IPv6-only stack. I'm sure there are CLNS, IPX, AppleTalk etc networks
there, but that doesn't impose a cost to everyone wanting to play.

Um, so what? There is lots of cruft the world over that would be better 
if it finally died. Somehow we keep on. It's just a cost of doing 
business. If mobile operators can support it with their millions or even 
billions of customers, I think everybody else can too. It's not like 
ipv4 address depletion is a static problem either -- it's only going to 
get worse as time goes on so it's what's really driving opex where v6 is 
pretty much a one-off investment in comparison i'd think.


Mike

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Michael Thomas]

On 1/15/24 12:26 AM, Saku Ytti wrote:

On Mon, 15 Jan 2024 at 10:05, jordi.palet--- via NANOG  wrote:


In actual customer deployments I see the same levels, even up to 85% of IPv6 
traffic. It basically depends on the usage of the caches and the % of 
residential vs corporate customers.

You think you are contributing to the IPv6 cause, by explaining how
positive the situation is. But in reality you are damaging it greatly,
because you're not communicating that we are not on a path to IPv4
free Internet. If we had been on such a path, we would have been IPv4
free for more than a decade. And unless we admit we are not on that
path, we will not work to get on that path.

An ipv4 free network would be nice, but is hardly needed. There will 
always be a long tail of ipv4 and so what? You deal with it at your 
borders as a piece of non-recurring engineering and that is that. The 
mobile operators model seems to be working pretty well for them and 
seems likely that it is an opex cost down for them since they don't have 
to run two networks internally nor deal with the cost of ipv4 subnets 
(or at least not as much? not sure how it exactly works). Worrying about 
whether ipv4 will ever go away misses the point, imo.


Mike

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Michael Thomas]

On 1/15/24 12:56 AM, jordi.palet--- via NANOG wrote:
No, I’m not saying that. I’m saying "in actual deployments", which 
doesn’t mean that everyone is deploying, we are missing many ISPs, we 
are missing many enterprises.


I don't think what's going on internally with enterprise needs to change 
much if they just gatewayed to a v6 upstream instead of v4 at the border 
if they were given that option. The problem has always been with ISP's 
and routers. When v6 first started to percolate (early 90's) i looked at 
it for my embedded OS and the projects that used it and didn't figure it 
would take much effort to implement it. So for hosts i really don't 
think that was a roadblock. But if hosts don't have something upstream 
to sink v6 traffic and especially to access the public internet there's 
not much incentive to implement it or deploy it. ISP's used the excuse 
that routers didn't implement it which was definitely a huge problem but 
as it turns out it was still an excuse since a lot has changed in the 
last 20 years and still rollout continues at a glacial pace.


I think one of the more encouraging trends are ISP's and enterprises 
switching over to v6 internally as a cost saving measure to not run a 
dual network. Aren't Comcast and Facebook examples?


It's sort of disturbing that there are still people on this list that 
want to relitigate something that happened 30 years ago. that reeks of 
religion not tech. By all means, set up CGNAT's in a pique.


Mike

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Michael Thomas]

On 1/12/24 11:54 AM, Darrel Lewis wrote:

On Jan 12, 2024, at 11:47 AM, Seth David Schoen  wrote:

Michael Thomas writes:


I wonder if the right thing to do is to create a standards track RFC that
makes the experimental space officially an add on to rfc 1918. If it works
for you, great, if not your problem. It would at least stop all of these
recurring arguments that we could salvage it for public use when the
knowability of whether it could work is zero.

In 2008 there were two proposals

https://datatracker.ietf.org/doc/draft-fuller-240space/
https://datatracker.ietf.org/doc/draft-wilson-class-e/

where the former was agnostic about how we would eventually be able to
use 240/4, and the latter designated it as RFC 1918-style private space.
Unfortunately, neither proposal was adopted as an RFC then, so we lost a
lot of time in which more vendors and operators could have made more
significant progress on its usability.

Well, we were supposed to all be using IPv6 (only) by now, and making 240/4 
useable was just going to slow that process down.

IMHO, this is what you get when religion is mixed with engineering.


But it wouldn't be globally routable so it wouldn't change much. I'm not 
even sure it would change much on the ground for CGNAT deployment? You 
still need enough public addresses to service the load. It might make it 
easier than partitioning your internal net into multiple 10/8 but on the 
other hand you need to make certain your internal net still works with 
240/4.


I'm mostly throwing this out there as a way to shut down these kinds of 
discussions.


Mike

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Michael Thomas]

On 1/12/24 8:45 AM, Owen DeLong via NANOG wrote:
Frankly, I care less. No matter how you use whatever IPv4 space you 
attempt to cajole into whatever new form of degraded service, the 
simple fact remains. IPv4 is a degraded technology that only continues 
to get worse over time. NAT was bad. CGNAT is even worse (and 
tragically does nothing to eliminate consumer NAT, just layers more 
disaster on top of the existing mess).


The only currently available end to end peer to peer technology, for 
better or worse, is IPv6. Despite its naysayers, it is a proven 
technology that has been shouldering a significant fraction of 
internet traffic for many years now and that fraction continues to grow.


You simply can’t make IPv4 adequate and more hackers to extend its 
life merely expands the amount of pain and suffering we must endure 
before it is finally retired.


I wonder if the right thing to do is to create a standards track RFC 
that makes the experimental space officially an add on to rfc 1918. If 
it works for you, great, if not your problem. It would at least stop all 
of these recurring arguments that we could salvage it for public use 
when the knowability of whether it could work is zero.


Mike

Re: Appropriate venue to find out about the state of art of spear phishing defense?

[Michael Thomas]

On 11/13/23 12:29 PM, Mel Beckman wrote:
We use KnowBe4.com's user training. That's really the only way you can 
fight this, since its a human problem, not a technical one. These guys 
provide fully automated, AI based (well, who knows what that means) 
simulated phishing attacks, largely to give users real-world practical 
experience detecting and fending off attacks. You get a report card on 
each users to, so you know where the weaknesses are in your staff 
knowledge. Their training regimen includes some pretty good 
self-guided instructional videos.


DMARC, SPF, digitally-signed emails, encryption, none of that matters 
if a user can be tricked into letting the crooks in the front door.


I think that both are needed, to be honest. The signatures can be a tool 
in the user's arsenal but if they are clueless and gullible there isn't 
much you can do about that.



Mike

Appropriate venue to find out about the state of art of spear phishing defense?

[Michael Thomas]

I know this is only tangentially relevant to nanog, but I'm curious if 
anybody knows where I can ask what orgs do to combat spear phishing? 
Spear phishing doesn't require that you deploy DMARC since you can know 
your own policy even if you aren't comfortable publishing it to the world.


tia, Mike

Re: [EXTERNAL] DNS filtering in practice, Re: Charter DNS servers returning malware filtered IP addresses

[Michael Thomas]

On 10/28/23 3:13 AM, John Levine wrote:

It appears that Michael Thomas  said:

If you're one of the small minority of retail users that knows enough
about the technology to pick your own resolver, go ahead.  But it's
a reasonable default to keep malware out of Grandma's iPad.

How does this line up with DoH? Aren't they using hardwired resolver
addresses? I would hope they are not doing anything heroic.

Generally, no.  I believe that Chrome probes whatever resolver is configured
into the system and uses that if it does DoH or DoT.

At one point Firefox was going to send everything to their favorite
DoH resolver but they got a great deal of pushback from people who
pointed out that they had policies on their networks and they'd have
to ban Firefox.  Firefox responded with a lame hack
where you can tell your cache to respond to some name and if so
Firefox will use your resolver.


That's probably what I'm remembering with Firefox. But doesn't probing 
the local resolver sort of defeat the point of DoH? That is, I really 
don't want my ISP to be able to snoop on my DNS history. Sending it off 
to one of the well known resolvers at least gives me a chance to know 
whether they are evil or not because there aren't very many of them vs 
every random ISP out there. Since nobody but people like us know about 
those resolvers it seems to me that without preconfiguration meaningful 
DoH is pretty limited?


Or maybe I just don't understand what problem they were trying to solve?

Mike

Re: [EXTERNAL] Re: Charter DNS servers returning malware filtered IP addresses

[Michael Thomas]

On 10/27/23 2:20 PM, John Levine wrote:

It appears that Bryan Fields  said:

-=-=-=-=-=-
-=-=-=-=-=-
On 10/27/23 7:49 AM, John Levine wrote:

But for obvious good reasons,
the vast majority of their customers don't

I'd argue that as a service provider deliberately messing with DNS is an
obvious bad thing.  They're there to deliver packets.

For a network feeding a data center, sure. For a network like
Charter's which is feeding unsophisticated nontechnical users, they
need all the messing they can get.

If you're one of the small minority of retail users that knows enough
about the technology to pick your own resolver, go ahead.  But it's
a reasonable default to keep malware out of Grandma's iPad.


How does this line up with DoH? Aren't they using hardwired resolver 
addresses? I would hope they are not doing anything heroic.


Mike

Re: transit and peering costs projections

[Michael Thomas]

On 10/15/23 8:33 PM, Matthew Petach wrote:



 I think we often forget just how much of a massive inversion the
communications industry has undergone; back in the 80s, when
I started working in networking, everything was DS0 voice channels,
and data was just a strange side business that nobody in the telcos
really understood or wanted to sell to.  At the time, the volume of money
being raked in from those DS0/VGE channels was mammoth compared
to the data networking side; we weren't even a rounding error.  But as 
the

roles reversed and the pyramid inverted, the data networking costs didn't
rise to meet the voice costs (no matter how hard the telcos tried to push
VGE-mileage-based pricing models!

Haha, when I was at Cisco in the late 90's and was working on VoIP stuff 
we were working with Sprint trying to get them onboard for a residential 
voice project. They were really insistent on using AAL2 to conserve 
bandwidth. I told them at the time that the bandwidth for voice was 
going to be insignificant and it wasn't a big deal that RTP wasn't as 
efficient. They looked at me like i had leprosy with body parts falling 
off. Like the next month it was announced that data had surpassed voice 
for the first time. We didn't get the contract, fwiw. But they never 
launched anything either. Was there ever any significant deployment of 
AAL2?


Mike

Re: xfinity not working

[Michael Thomas]

On 10/11/23 11:34 AM, William Herrin wrote:

On Wed, Oct 11, 2023 at 11:12 AM Delong.com  wrote:

There are still some knobs…

e.g. bridge mode or not (usually)

I'm guessing that's only if there's a built-in wifi router. My grand
experience with cable modems counts to exactly two brands and four
models, but in each case the model without wifi was solely a bridge.
The knobs, as such, were: change the password and reboot the modem.


I thought that bridge was the DOCSIS model. Is there a choice these 
days? Back when I was actually working with this, the expectation is the 
modem was pretty dumb and not accessible to the user. It would tftp its 
config from the MSO and that was that.


Mike

Re: what is acceptible jitter for voip and videoconferencing?

[Michael Thomas]

On 9/22/23 1:54 PM, Mark Andrews wrote:

Telnet sessions where  often initiated from half duplex terminals.  Pushing 
that flow control across the network helped those users.

I'm still confused. Did it require the telnet users to actually take 
action? Like they'd manually need to enter the GA option? It's very 
possible that I didn't fully implement it if so since I didn't realize that.


Mike

Re: what is acceptible jitter for voip and videoconferencing?

[Michael Thomas]

On 9/22/23 9:42 AM, Jay Hennigan wrote:

On 9/21/23 17:04, Michael Thomas wrote:

When I wrote my first implementation of telnet ages ago, i was both 
amused and annoyed about the go-ahead option. Obviously patterned 
after audio meat-space protocols, but I was never convinced it wasn't 
a solution in search of a problem. I wonder if CDMA was really an 
outgrowth of those protocols?


Typically seen with half-duplex implementations, like "Over" in 
two-way radio. Still used in TTY/TDD as "GA".


DId that ever actually occur over the internet such that telnet would 
need it? Half duplex seems to be pretty clearly an L1/L2 problem. IIRC, 
it was something of a pain to implement.


Mike

Re: what is acceptible jitter for voip and videoconferencing?

[Michael Thomas]

On 9/21/23 3:31 PM, William Herrin wrote:

On Thu, Sep 21, 2023 at 6:28 AM Tom Beecher  wrote:

My understanding has always been that 30ms was set based on human 
perceptibility. 30ms was the average point at which the average person could 
start to detect artifacts in the audio.

Hi Tom,

Jitter doesn't necessarily cause artifacts in the audio. Modern
applications implement what's called a "jitter buffer." As the name
implies, the buffer collects and delays audio for a brief time before
playing it for the user. This allows time for the packets which have
been delayed a little longer (jitter) to catch up with the earlier
ones before they have to be played for the user. Smart implementations
can adjust the size of the jitter buffer to match the observed
variation in delay so that sound quality remains the same regardless
of jitter.

Indeed, on Zoom I barely noticed audio artifacts for a friend who was
experiencing 800ms jitter. Yes, really, 800ms. We had to quit our
gaming session because it caused his character actions to be utterly
spastic, but his audio came through okay.


When I wrote my first implementation of telnet ages ago, i was both 
amused and annoyed about the go-ahead option. Obviously patterned after 
audio meat-space protocols, but I was never convinced it wasn't a 
solution in search of a problem. I wonder if CDMA was really an 
outgrowth of those protocols?


But it's my impression that gaming is by far more affected by latency 
and thus jitter buffers for voice. Don't some ISP's even cater to gamers 
about latency?


Mike

Re: So what do you think about the scuttlebutt of Musk interfering in Ukraine?

[Michael Thomas]

On 9/14/23 6:34 AM, Dave Taht wrote:
This is one of those threads where I do think folk would benefit from 
hearing from the horses' mouths. In a recent bio of musk published 
this past week, the author claimed that starlink withdrew service over 
crimea based on the knowledge it was going to be used for a surprise 
attack. Starlink - and that author - now state that ( 
https://twitter.com/elonmusk/status/1700345943105638636 )


The onus is meaningfully different if I refused to act upon a request 
from Ukraine vs. made a deliberate change to Starlink to thwart 
Ukraine. At no point did I or anyone at SpaceX promise coverage over 
Crimea. Moreover, our terms of service clearly prohibit Starlink for 
offensive military action, as we are a civilian system, so they were 
again asking for something that was expressly prohibited. SpaceX is 
building Starshield for the US government, which is similar to, but 
much smaller than Starlink, as it will not have to handle millions of 
users. That system will be owned and controlled by the US government.

Quote
Walter Isaacson
@WalterIsaacson
·
Sep 8
To clarify on the Starlink issue: the Ukrainians THOUGHT coverage was 
enabled all the way to Crimea, but it was not. They asked Musk to 
enable it for their drone sub attack on the Russian fleet. Musk did 
not enable it, because he thought, probably correctly, that would 
cause a…Show more 



Furthermore, Musk stated yesterday that had the request come from the 
us government, he would have complied.


I will refrain from editorializing.


I guess this is a lesson on diversity which every military should pay 
attention to. I had forgotten about other wireless options that Bill 
pointed out, though I'm not sure if geostationary latency would fit 
their requirements. But is trying to reclaim your territory "offensive" 
after being invaded? How would other providers interpret that? Or maybe 
this is just a unicorn.


Mike

Re: So what do you think about the scuttlebutt of Musk interfering in Ukraine?

[Michael Thomas]

On 9/14/23 9:26 AM, Mike Hammett wrote:

*nods* likely plenty of similar examples by less polarizing people.


Then lets hear them? It certainly seems like an  operational issue if 
this starts to become common. How is it dealt with if at all beyond 
diversity which is hard to come by with LEO systems?



Mike

So what do you think about the scuttlebutt of Musk interfering in Ukraine?

[Michael Thomas]

Doesn't this bump up against common carrier protections? I sure don't 
want my utilities weaponizing their monopoly status to the whims of any 
random narcissist billionaire.


Mike

Re: Hawaiian ILEC infrastructure and fire

[Michael Thomas]

On 8/17/23 11:26 AM, scott via NANOG wrote:



I don't want to overwhelm the list, but since there's interest here's 
something interesting I just now got from the electric company.  400 
poles and 300 transformers.  Wow!


Those of us from California and the west have watched this in abject 
horror and I myself was completely clueless this was possible.


Mike, who lives 10 miles from where the Caldor fire started that burned 
all the way to Tahoe and grew up going to Paradise to visit my grandparents

Re: Copper wire thefts increase 139% in one California county

[Michael Thomas]

On 7/1/23 9:46 AM, Sean Donelan wrote:


Copper wire thefts of all kinds appear to be increasing in 2023. Not 
just telecommunications copper cables, but also electric and transit 
cables.


San Joaquin County reported a 139% increase in copper wire thefts over 
four months, and one theft in the county left the 911 center unable to 
receive calls.


https://www.latimes.com/california/story/2023-07-01/copper-wire-thefts-cause-delays-for-metro-railways 




It's been happening here in Amador County as well mostly from yahoos 
from Stockton. They're taking out fiber too probably inadvertently.


Mike

Re: Northern Virginia has had enough with data centers

[Michael Thomas]

On 6/26/23 6:06 PM, Ron Yokubaitis wrote:

Dalles: government subsidized Hydroelectric Power, that’s why.


Well that maybe, but electric rates are hella cheap in Oregon regardless.

Mike




Sent from the iPad of Ron Yokubaitis


On Jun 26, 2023, at 7:37 PM, Michael Thomas  wrote:



On 6/24/23 5:28 AM, Owen DeLong wrote:


On Jun 23, 2023, at 18:04, Michael Thomas  wrote:



On 6/23/23 4:01 PM, 
https://urldefense.proofpoint.com/v2/url?u=http-3A__Delong.com=DwIDaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=cGrDT0liF-gD_o4EJ7o_qg=Z1ElQJ6RtDdrUgH7UwCpBHojWq1Iyp4CM49TsykDfXM=BUfOgzy41EDHyDbK_xBslELDt9Xofk6_YBR4nLTQGmo=
 via NANOG wrote:
The electric grid complaints are about the demand on the grid making the entire 
region less stable and proposed construction of new high-voltage tower 
corridors for data centers.
Yeah, I can kind of understand those, but as long as the grid is properly 
planned, it really shouldn’t have a destabilizing effect. In fact, many 
datacenter in California do CoGen and end up providing additional grid 
stability.


Uh, ::cough:: PGE ::cough::

I so wanted to schadenfreude so bad with Texas and their shitty grid, but then 
remembered where I live.

Mike

What’s not to love about a power company that literally qualifies as a 
recidivist felon?

It is my sincere hope to finish my mortgage and then start putting money 
towards electrical independence. (Wind, more solar, batteries, and 
disconnecting Persistent Graft and Extortion).


I'm waiting on a software upgrade for my inverter to hook up a generator to 
refill the battery when it gets too low. Not off the grid, but not at the mercy 
of PGE's fuckery.

How many datacenters are in Norcal? I imagine that it's a lot, but PGE's rates 
are like 2x the rest of the country. At least for residential. I always got a 
kick of Google putting a datacenter in the Dalles in Oregon -- basically 
mainlining the Columbia river.

Mike

Re: Northern Virginia has had enough with data centers

[Michael Thomas]

On 6/24/23 5:28 AM, Owen DeLong wrote:



On Jun 23, 2023, at 18:04, Michael Thomas  wrote:



On 6/23/23 4:01 PM, Delong.com via NANOG wrote:
The electric grid complaints are about the demand on the grid making the entire 
region less stable and proposed construction of new high-voltage tower 
corridors for data centers.
Yeah, I can kind of understand those, but as long as the grid is properly 
planned, it really shouldn’t have a destabilizing effect. In fact, many 
datacenter in California do CoGen and end up providing additional grid 
stability.


Uh, ::cough:: PGE ::cough::

I so wanted to schadenfreude so bad with Texas and their shitty grid, but then 
remembered where I live.

Mike

What’s not to love about a power company that literally qualifies as a 
recidivist felon?

It is my sincere hope to finish my mortgage and then start putting money 
towards electrical independence. (Wind, more solar, batteries, and 
disconnecting Persistent Graft and Extortion).

I'm waiting on a software upgrade for my inverter to hook up a generator 
to refill the battery when it gets too low. Not off the grid, but not at 
the mercy of PGE's fuckery.


How many datacenters are in Norcal? I imagine that it's a lot, but PGE's 
rates are like 2x the rest of the country. At least for residential. I 
always got a kick of Google putting a datacenter in the Dalles in Oregon 
-- basically mainlining the Columbia river.


Mike

Re: Northern Virginia has had enough with data centers

[Michael Thomas]

On 6/23/23 4:01 PM, Delong.com via NANOG wrote:
The electric grid complaints are about the demand on the grid making 
the entire region less stable and proposed construction of new 
high-voltage tower corridors for data centers.

Yeah, I can kind of understand those, but as long as the grid is properly 
planned, it really shouldn’t have a destabilizing effect. In fact, many 
datacenter in California do CoGen and end up providing additional grid 
stability.


Uh, ::cough:: PGE ::cough::

I so wanted to schadenfreude so bad with Texas and their shitty grid, 
but then remembered where I live.


Mike

Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps

[Michael Thomas]

On 6/17/23 4:14 PM, Tom Beecher wrote:


Also: they plan to use Starship when it's available which has 10x
more capacity. If it really is fully reusable as advertised, that
is going to really drive down the launch cost.


Starship is years away from being flight ready. The most recent test 
launch from Texas was not a 'successful failure' as widely portrayed 
in the media.  Reputable people who have been working in this field 
for decades have pointed out tons of massive problems that are not 
quick fixes.


Betting that Starship won't be a factor is not a bet I'd make. And I'm 
definitely not a Musk fan boy. A lot of the same NASA types didn't 
believe they'd get where they are now either. Because... you know, 
vested interests. I'd bet that Starship will be a factor way before the 
Senate Launch System.


Mike

Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps

[Michael Thomas]

Whether or not it makes business sense isn't really what I was talking 
about. I was talking about the home dish costing $1k. That sounds like 
it could easily be reduced significantly unless there is some underlying 
tech reason.


Also: they plan to use Starship when it's available which has 10x more 
capacity. If it really is fully reusable as advertised, that is going to 
really drive down the launch cost.


But your calculations don't take into account that they are not at 
anywhere close to a full constellation: they are only at 4k out of the 
40k they need so they literally can't support higher numbers. Their new 
generation of satellite is also suppose to be doing some in-orbit 
routing or something like that which would I would assume will really 
help on the bandwidth front. How much that affects their maximum 
subscriber base when they are fully deployed I don't know but it's bound 
to be a lot more possible subs than they have now.


I mean, this could be a spectacular flop like Iridium but a lot has 
changed in 20 some years not least of which is the cost of launch.


Mike

On 6/17/23 2:53 PM, Tom Beecher wrote:


As I mentioned elsewhere, I'm not sure that the current economics
are the real economics. I'm pretty sure they've been purposefully
throttling demand because they still don't have the capacity so it
would make sense to overcharge in the mean time. Is there
something inherent in their cpe that makes them much more
expensive than, say, satellite tv dishes? I can see marginally
more because of the LEO aspect, but isn't that mainly just
software? It wouldn't surprise me that the main cost is the truck
roll.

- Starlink currently reports around 1.5M subscribers. At $110 a month, 
that's $165M in revenue,


- A Falcon 9 launch is billed out at $67M. A Falcon 9 can carry up to 
60 Starlink sats. That's ~667 launches to reach the stated goal of 40k 
sats in the constellation. So roughly $45B in just launch costs, if 
you assume the public launch price. (Because if they are launching 
their own stuff, they aren't launching an external paying customer.)

- The reported price per sat is $250k.

Assuming they give themselves a friendly internal discount, the 
orbital buildout cost are in the neighborhood of $30B for launches, 
and $10B for sats.


- The satellite failure rate is stated to be ~ 3% annually. On a 40K 
cluster, that's 1200 a year.


That's about 20 more launches a year, and $300M for replacement sats. 
Let's round off and say that's $1B a year there.


 So far, that's a $40B buildout with a $1B annual run rate. And that's 
just the orbital costs. We haven't even calculated the 
manufacturing costs of the receiver dishes, terrestrial network infra 
cost , opex from staff , R, etc .


Numbers kinda speak for themselves here.

I mean, I get that Musk is sort of a cuckoo bird but say what you
will he does have big ambitions.


Ambition is good. But reality tends to win the day. As does math.




On Sat, Jun 17, 2023 at 4:38 PM Michael Thomas  wrote:


On 6/17/23 1:25 PM, Tom Beecher wrote:


Won't Starlink and other LEO configurations be that backstop
sooner
rather than later?


Unlikely. They will remain niche. The economics don't make sense
for those services to completely replace terrestrial only service.


Why would they put up 4 satellites if their ambition is only
niche? I mean, I get that Musk is sort of a cuckoo bird but say
what you will he does have big ambitions.

From my standpoint, they don't have to completely replace the
incumbents. I'd be perfectly happy just keeping them honest.

As I mentioned elsewhere, I'm not sure that the current economics
are the real economics. I'm pretty sure they've been purposefully
throttling demand because they still don't have the capacity so it
would make sense to overcharge in the mean time. Is there
something inherent in their cpe that makes them much more
expensive than, say, satellite tv dishes? I can see marginally
more because of the LEO aspect, but isn't that mainly just
software? It wouldn't surprise me that the main cost is the truck
roll.

Mike




On Fri, Jun 16, 2023 at 4:17 PM Michael Thomas  wrote:


On 6/16/23 1:09 PM, Mark Tinka wrote:
>
>
> On 6/16/23 21:19, Josh Luthman wrote:
>> Mark,
>>
>> In my world I constantly see people with 0 fixed internet
options.
>> Many of these locations do not even have mobile coverage.
>> Competition is fine in town, but for millions of people in
the US
>> (and I'm going to assume it's worse or comparable in
CA/MX) there is
>> no service.
>>
>> As a company primarily delivering to residents,
competition is not a
>> focus fo

Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps

[Michael Thomas]

On 6/17/23 1:25 PM, Tom Beecher wrote:


Won't Starlink and other LEO configurations be that backstop sooner
rather than later?


Unlikely. They will remain niche. The economics don't make sense for 
those services to completely replace terrestrial only service.


Why would they put up 4 satellites if their ambition is only niche? 
I mean, I get that Musk is sort of a cuckoo bird but say what you will 
he does have big ambitions.


From my standpoint, they don't have to completely replace the 
incumbents. I'd be perfectly happy just keeping them honest.


As I mentioned elsewhere, I'm not sure that the current economics are 
the real economics. I'm pretty sure they've been purposefully throttling 
demand because they still don't have the capacity so it would make sense 
to overcharge in the mean time. Is there something inherent in their cpe 
that makes them much more expensive than, say, satellite tv dishes? I 
can see marginally more because of the LEO aspect, but isn't that mainly 
just software? It wouldn't surprise me that the main cost is the truck 
roll.


Mike




On Fri, Jun 16, 2023 at 4:17 PM Michael Thomas  wrote:


On 6/16/23 1:09 PM, Mark Tinka wrote:
>
>
> On 6/16/23 21:19, Josh Luthman wrote:
>> Mark,
>>
>> In my world I constantly see people with 0 fixed internet options.
>> Many of these locations do not even have mobile coverage.
>> Competition is fine in town, but for millions of people in the US
>> (and I'm going to assume it's worse or comparable in CA/MX)
there is
>> no service.
>>
>> As a company primarily delivering to residents, competition is
not a
>> focus for us and for the urban market it's tough to survive on
a ~1/3
>> take rate.
>
> I should have been clearer... the lack of competition in many
markets
> is not unique to North America. I'd say all of the world suffers
that,
> since there is only so much money and resources to go around.
>
> What I was trying to say is that should a town or village have the
> opportunity to receive competition, where existing services are
> capped, uncapping that via an alternative provider would be low
> hanging fruit to gain local marketshare. Of course, the alternative
> provider would need to show up first, but that's a whole other
thread.
>
Won't Starlink and other LEO configurations be that backstop sooner
rather than later? I don't know if they have caps as well, but
even if
they do they could compete with their caps.

Mike

Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps

[Michael Thomas]

On 6/16/23 3:18 PM, Keith Stokes wrote:

Cox also has a 1.2 TB cap.

If I can believe my graphs, the metered Cox connection (video 
streaming primarily for wife) is about 90 GB the month of April and 
the unmetered ATT fiber WFH for me is about 370 GB. Total LAN is about 
450 GB. Napkin math but it's pretty close.


Modulo P2P nodes, what drives high usage? I guess game downloads are 
getting gigantic these days, but that's not an every day event. Back in 
the bad old days it wasn't inconceivable to go over the lower caps but 
once it's big enough to support video what is left? I mean, how much 4k 
pr0n can randy teenagers watch in one month?



Mike

Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps

[Michael Thomas]

On 6/16/23 1:36 PM, Josh Luthman wrote:
Not everyone can afford $1000 to start up Starlink and then pay $130+ 
per month.  That may be an option for some, but certainly not the 
majority.


If 100% of a town was covered by a single company with data caps, 
those that are crying from hitting 1.2 TB/month will not be enough for 
a competitor to come in and build on top.  A TB/mo now is extremely 
high - In May 2023 we had 4 customers that exceeded that (all 4 of 
these customers mentioned are subscribed to <25 mbps plans; we offer 
gig ftth).


I get the impression that they are still in a beta/early adopter 
situation so unaffordability might be feature not a bug to them to keep 
the system from a success disaster. At least for now. I get the 
impression that some/a lot of this is to bring the internet to the rest 
of the world as one of their goals.


I do wonder how they are numbering them though. Are the they using the 
same scheme that the mobile providers are using with ipv6? hmm.


Mike



On Fri, Jun 16, 2023 at 4:22 PM Mark Tinka  wrote:



On 6/16/23 22:16, Michael Thomas wrote:

> Won't Starlink and other LEO configurations be that backstop sooner
> rather than later? I don't know if they have caps as well, but
even if
> they do they could compete with their caps.

Maybe. I really haven't paid any attention to Starlink, although
there
are credible reports of folk testing it here in South Africa's urban
centres.

I have not heard of any mention of Starlink having caps as part of
their
service. Having said that, for services like this, things change
as the
number of customers using them rises.

Mark.

Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps

[Michael Thomas]

On 6/16/23 1:22 PM, Mark Tinka wrote:



On 6/16/23 22:16, Michael Thomas wrote:

Won't Starlink and other LEO configurations be that backstop sooner 
rather than later? I don't know if they have caps as well, but even 
if they do they could compete with their caps.


Maybe. I really haven't paid any attention to Starlink, although there 
are credible reports of folk testing it here in South Africa's urban 
centres.


I have not heard of any mention of Starlink having caps as part of 
their service. Having said that, for services like this, things change 
as the number of customers using them rises.


I've toyed with getting it which I think I can do here in rural 
California especially given that my ISP installed fiber and inexplicably 
didn't change the rate plans from DSL (given that it's an older 
population here, I doubt that any new over subscription would be much 
problem). But the fact of the matter is that we don't seem to ever be in 
the situation that our 25Mbs service is an actual problem.


Mike

Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps

[Michael Thomas]

On 6/16/23 1:09 PM, Mark Tinka wrote:



On 6/16/23 21:19, Josh Luthman wrote:

Mark,

In my world I constantly see people with 0 fixed internet options.  
Many of these locations do not even have mobile coverage.  
Competition is fine in town, but for millions of people in the US 
(and I'm going to assume it's worse or comparable in CA/MX) there is 
no service.


As a company primarily delivering to residents, competition is not a 
focus for us and for the urban market it's tough to survive on a ~1/3 
take rate.


I should have been clearer... the lack of competition in many markets 
is not unique to North America. I'd say all of the world suffers that, 
since there is only so much money and resources to go around.


What I was trying to say is that should a town or village have the 
opportunity to receive competition, where existing services are 
capped, uncapping that via an alternative provider would be low 
hanging fruit to gain local marketshare. Of course, the alternative 
provider would need to show up first, but that's a whole other thread.


Won't Starlink and other LEO configurations be that backstop sooner 
rather than later? I don't know if they have caps as well, but even if 
they do they could compete with their caps.


Mike

Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps

[Michael Thomas]

On 6/15/23 10:41 PM, Crist Clark wrote:
Comcast still has data caps. My service is 1.2 TB per month. If we get 
close, we get a warning email. If we were to go over (hasn’t happened 
yet), we get billed per additional 500 MB.


However, I just looked at my account usage for the first time for a 
few months, and somehow have had zero usage since March of this year.


Is 1.2 TB enough for a typical cord cutter? I just looked at mine and it 
looks to be about 300GB/month, but we may not be typical for your 
average family with kids, say.


Mike

Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps

[Michael Thomas]

On 6/15/23 3:19 PM, Sean Donelan wrote:


While a lot of ISPs gave up on data caps, the language is still 
lurking in many Terms Of Service.




https://www.fcc.gov/document/chair-rosenworcel-proposes-investigate-impact-data-caps 



proposed Notice of Inquiry to learn more about how broadband providers 
use data caps on consumer plans. Data caps, or usage limits, are a 
common practice where an internet service provider (ISP) restricts how 
much bandwidth or data a consumer uses, though many broadband ISPs 
temporarily or permanently refrained from enforcing or imposing data 
caps in response to the COVID-19 pandemic. In particular, the agency 
would like to better understand the current state of data caps, their 
impact on consumers, and whether the Commission should consider taking 
action to ensure that data caps do not cause harm to competition or 
consumers’ ability to access

broadband Internet services.


So why did they back off? Cost too much in support calls with pissed 
people? Bad publicity? People can't meaningfully use the offered 
bandwidth these days? Something else?


Mike

Re: Are we back to the 2000's again?

[Michael Thomas]

On 6/3/23 4:24 PM, William Herrin wrote:

On Sat, Jun 3, 2023 at 4:09 PM Michael Thomas  wrote:

How can the RIAA even know? I mean, are they putting up honey pots or
something?

IIRC, they went after folks sharing the files via bit torrent rather
than folks who only downloaded them.

Oh yeah. This oh-so-two decades ago. I can't believe this sort of thing 
is still going on. What a pointless waste of money.


Mike

Re: Are we back to the 2000's again?

[Michael Thomas]

On 6/3/23 4:01 PM, William Herrin wrote:

On Sat, Jun 3, 2023 at 2:51 PM Mel Beckman  wrote:

It’s like blaming water companies for people stealing boats :)

It's been a while and the article is light on the facts of the case,
but IIRC what happened was: RIAA made some DMCA complaints to Cox. Cox
decided that since they were the network rather than the host, they
couldn't "remove" the offending material, wouldn't cut the user's
access and, because they have such respect for customer privacy,
wouldn't tell the RIAA who the customers were unless RIAA subpoenaed
them under a John Doe suit.

The court decided that Cox's behavior was sufficient to waive the
DMCA's liability shield for Internet providers and off they went to
trial.


How can the RIAA even know? I mean, are they putting up honey pots or 
something?


Mike

Are we back to the 2000's again?

[Michael Thomas]

Apparently the RIAA is back suing ISP's (Cox in this case) for users 
pirating music. It was pretty bogus back then, but with the uptake of 
TLS for almost everything and DoH to conceal DNS requests what exactly 
is an ISP supposed to do these days? Throw in a VPN and the pirates 
completely cut out the ISP.


Am I missing something?


https://yro.slashdot.org/story/23/06/02/2043209/music-pirates-are-not-terrorists-record-labels-argue-in-court

Mike

Re: Do ISP's collect and analyze traffic of users?

[Michael Thomas]

On 5/19/23 6:09 AM, Justin Streiner wrote:

Hank:

No doubt there is a massive amount of information that can be gathered 
from in-box telemetry.  This thread appears to be more focused on 
providers gathering data from traffic in flight across their 
infrastructure.


Yeah, my curiosity was whether ISP were trying to get in the monetizing 
traffic analysis biz which seems to be a small degree but they can't 
really compete with the much finer grained information that other means 
can provide and that they have no particular expertise in it or an 
institutional desire. For things like Google and Facebook, that kind of 
analysis was part of their initial business plan.


Mike



Thank you
jms

On Fri, May 19, 2023 at 8:49 AM Hank Nussbacher  
wrote:


On 19/05/2023 15:27, Justin Streiner wrote:

It amazes me how people can focus on Netflow metadata and ignore
things
like Microsoft telemetry data from every Windows box, or ignore the
massive amount of html cookies that are traded by companies or how
almost every corporate firewall or anti-spam box "reports" back to
the
mother ship and sends tons of information via secret channels like
hashed DNS lookups just to be avoided.

Regards,
Hank

> There are already so many different ways that organizations can
find
> out all sorts of information about individual users, as others have
> noted (social media interactions, mobile location/GPS data,
call/text
> history, interactions with specific sites, etc), that there
probably
> isn't much incentive for many providers to harvest data beyond
what is
> needed for troubleshooting and capacity planning.  Plus, gathering
> more data - potentially down to the level packet payload - is
not an
> easy problem to solve (read: expensive) and doesn't scale well
at all.
> 100G links are very common today, and 400G is becoming so.  I doubt
> that many infrastructure providers would be able to justify the
major
> investments in extra infrastructure to support this, for a revenue
> stream that likely wouldn't match that investment, which would make
> such an investment a loss-leader.
>
> Content providers - particularly social media platforms - have a
> somewhat different business model, but those providers already have
> many different ways to harvest and sell large troves of user data.
>
> Thank you
> jms

Re: Do ISP's collect and analyze traffic of users?

[Michael Thomas]

On 5/16/23 7:55 AM, Saku Ytti wrote:

Of course there are other monetisation opportunities via other
mechanism than data-in-the-wire, like DNS


And with DoH, that doesn't sound like a very long term opportunity.

Mike

Re: Do ISP's collect and analyze traffic of users?

[Michael Thomas]

On 5/16/23 7:35 AM, Livingood, Jason via NANOG wrote:


+1 to what Josh writes below. I would also differentiate between 
mobile networks (service provisioned to individual devices & often 
carrier s/w on the device) and wireline networks (home devices behind 
a router/gateway/NAT).


I just don't think sale of data is a business for wireline ISPs. If it 
were - given most companies are public - you'd see it in SEC 10K 
filings and on earnings calls. Indeed, they'd be required to talk 
about it with investors if it was a material revenue stream. I see 
none of that. Rather, the focus is on subscription revenue. If you 
want to know about data monetization - focus on services you don't pay 
for...




Why would there be a difference between wireless and wired?

Mike

Re: Do ISP's collect and analyze traffic of users?

[Michael Thomas]

On 5/15/23 9:46 PM, Matthew Petach wrote:



On Mon, May 15, 2023 at 6:42 PM Dave Phelps  wrote:

I think it's safe to assume they are selling such data.


https://www.techdirt.com/2021/08/25/isps-give-netflow-data-to-third-parties-who-sell-it-without-user-awareness-consent/


https://www.vice.com/en/article/dy3z9a/fbi-bought-netflow-data-team-cymru-contract


From the second article:

"Team Cymru’s products can also include data such as URLs visited, 
cookies, and PCAP data"


Really?  From Netflow?

I admit, I'm perhaps a little behind on the latest netflow whiz-bangs,
but I've never seen a netflow record type that included HTTP cookies
or PCAP data before.

Certainly, the products listed on the Team Cymru website don't make 
any mention
of including cookies or PCAP data, at least not from what I've been 
able to

ascertain from digging through their product listing.

Is there some secret "off the menu" product that allows one to purchase a
data feed that includes cookies and PCAP data?

Given the pervasiveness of TLS these days, even if they could get it off 
the remaining unencrypted data I'm not sure it would have a lot of value.


Mike

Do ISP's collect and analyze traffic of users?

[Michael Thomas]

And maybe try to monetize it? I'm pretty sure that they can be compelled 
to do that, but do they do it for their own reasons too? Or is this way 
too much overhead to be doing en mass? (I vaguely recall that netflow, 
for example, can make routers unhappy if there is too much "flow").


Obviously this is likely to depend on local laws but since this is NANOG 
we can limit it to here.


Mike

Re: Namecheap's outbound email flow compromised: valid rdns, spf, dkim and dmarc on phishes

[Michael Thomas]

It makes you wonder why they just don't rekey and put up a different 
selector while deleting the compromised selector?


Yes, this is bad but it has a straightforward solution to the compromise 
-- unlike compromised cert signing keys, natch.


Mike

On 2/12/23 4:01 PM, Eric Kuhnke wrote:

Namecheap has updated their status page item to include

"We have stopped all the emails (that includes Auth codes delivery, 
Trusted Devices’ verification, and Password Reset emails, etc.)"



Yikes.


On Sun, Feb 12, 2023, 3:54 PM Michael Thomas  wrote:

I think that it might be appropriate to name and shame the third
party, since they should know better too. It almost has the whiff
of a scam.

Mike

On 2/12/23 3:49 PM, Eric Kuhnke wrote:

One very possible theory is that whoever runs the outbound
marketing communications and email newsletter demanded the keys
and got them, with execs overriding security experts at Namecheap
who know better.

I would sincerely hope that the people whose job titles at
Namecheap include anything related to network engineering,
network security or cryptography at that company do know better.
Large domain registrars are not supposed to make such a rookie
mistake.


On Sun, Feb 12, 2023, 3:46 PM Michael Thomas  wrote:


On 2/12/23 3:40 PM, Eric Kuhnke wrote:
>

https://www.namepros.com/threads/concerning-e-mail-from-namecheap.1294946/page-2#post-8839257

>
>
> https://lowendtalk.com/discussion/184391/namecheap-hacked
>
> It looks like a third party service they gave their keys to
has been
> compromised. I got several phishes that fully pass as legit
Namecheap
> emails.
>
> https://www.namecheap.com/status-updates/archives/74848
>
>
If they actually gave them their own private keys, they
clearly don't
get how that's supposed to work with DKIM. The right thing to
do is
create a new selector with the third party's signing key.
Private keys
should be kept... private.

Mike

Re: Namecheap's outbound email flow compromised: valid rdns, spf, dkim and dmarc on phishes

[Michael Thomas]

I think that it might be appropriate to name and shame the third party, 
since they should know better too. It almost has the whiff of a scam.


Mike

On 2/12/23 3:49 PM, Eric Kuhnke wrote:
One very possible theory is that whoever runs the outbound marketing 
communications and email newsletter demanded the keys and got them, 
with execs overriding security experts at Namecheap who know better.


I would sincerely hope that the people whose job titles at Namecheap 
include anything related to network engineering, network security or 
cryptography at that company do know better. Large domain registrars 
are not supposed to make such a rookie mistake.



On Sun, Feb 12, 2023, 3:46 PM Michael Thomas  wrote:


On 2/12/23 3:40 PM, Eric Kuhnke wrote:
>

https://www.namepros.com/threads/concerning-e-mail-from-namecheap.1294946/page-2#post-8839257

>
>
> https://lowendtalk.com/discussion/184391/namecheap-hacked
>
> It looks like a third party service they gave their keys to has
been
> compromised. I got several phishes that fully pass as legit
Namecheap
> emails.
>
> https://www.namecheap.com/status-updates/archives/74848
>
>
If they actually gave them their own private keys, they clearly don't
get how that's supposed to work with DKIM. The right thing to do is
create a new selector with the third party's signing key. Private
keys
should be kept... private.

Mike

Re: Namecheap's outbound email flow compromised: valid rdns, spf, dkim and dmarc on phishes

[Michael Thomas]

On 2/12/23 3:40 PM, Eric Kuhnke wrote:
https://www.namepros.com/threads/concerning-e-mail-from-namecheap.1294946/page-2#post-8839257 



https://lowendtalk.com/discussion/184391/namecheap-hacked

It looks like a third party service they gave their keys to has been 
compromised. I got several phishes that fully pass as legit Namecheap 
emails.


https://www.namecheap.com/status-updates/archives/74848


If they actually gave them their own private keys, they clearly don't 
get how that's supposed to work with DKIM. The right thing to do is 
create a new selector with the third party's signing key. Private keys 
should be kept... private.


Mike

Re: About emails impersonating Path Network

[Michael Thomas]

On 2/7/23 11:33 AM, Jay Hennigan wrote:

On 2/7/23 11:18, Michael Thomas wrote:

FWIW, lookalike domains can and do happen with http too. Nothing 
unique about that to email.


Then the bad guys throw in the occasional Cyrillic, etc. character 
that looks like a Roman one and things get even more fun.


At least with spear-phishing attacks you can bound the problem detection 
investigation since you know what your own domain's legit names are. 
Beyond that, I have no idea if any of the mailbox providers are doing 
anything about lookalike attacks. Email at least has the advantage that 
it is in hands of a user's provider who could care. CA's I'm sure 
couldn't care less.


Mike

Re: About emails impersonating Path Network

[Michael Thomas]

On 2/7/23 6:09 AM, Rich Kulawiec wrote:

On Mon, Feb 06, 2023 at 12:41:43PM -0800, Michael Thomas wrote:

This seems like a perfect object lesson on why you should use DKIM and SPF
and make sure the sending domain can set up a p=reject policy for DMARC.

But it's not.  DKIM and SPF are mostly useless against competently executed
email forgery -- and can even be exploited to make it worse.  Thanks to
a combination of increasingly bad user interfaces, user ignorance,
TLD proliferation, and the ill-advised conflation of identification with
authenticity, it's not currently possible to stop email forgery in any
meaningful sense of the word "stop".


There has been a real failing on the UI side, but that not the fault of 
the authentication protocols. Thunderbird which is what I use is 
completely useless and silent on authentication. For others who 
implement some UI indications, some of them aren't very obvious and 
often tentative. There is a Usenix paper which researched email auth and 
part of it was on user visible feedback. The long and short is that it 
was useful, but not a silver bullet. A large part of the problem from my 
read of it is that it wasn't ubiquitous and standardized ala the Lock 
icon on browsers. It's easy to make fun of that, but it is clearly 
better than nothing. MUA vendors are always at liberty to bring their 
requirements for extensions for protocols or even new protocols if it 
would help the user experience by guiding how MUA's make the UI 
decisions on the advice of senders. It's pretty clear that they find 
this niche at best. That is a pity because some uniformity could make 
this a positive feedback loop and up the utility greatly.


FWIW, lookalike domains can and do happen with http too. Nothing unique 
about that to email.


Mike

Re: About emails impersonating Path Network

[Michael Thomas]

This seems like a perfect object lesson on why you should use DKIM and 
SPF and make sure the sending domain can set up a p=reject policy for 
DMARC.


Mike

On 2/6/23 10:25 AM, Konrad Zemek wrote:

Hi Nanog,

It looks like someone with an axe to grind against our company has decided to 
email every AS contact they could find on PeeringDB, impersonating us and 
sometimes spoofing our domains.

We're aware of the emails and are sorry for the inconvenience. We've since 
added SPF records to the domains we own but don't use (the perps have since 
name-squatted some new ones). We're also actively working with law enforcement 
on the matter.

Thanks
Konrad Zemek
CTO Path Network
AS396998

Re: Starlink routing

[Michael Thomas]

On 1/23/23 3:14 PM, Eric Kuhnke wrote:
The original and traditional high-cost way of how this is done for 
MEO/LEO is exemplified by an o3b terminal, which has two active 
motorized tracking antennas. The antenna presently in use for the 
satellite that is overhead follows it until it's descending towards 
the horizon, while at the same time the second antenna aims itself at 
where the next 'rising' satellite is predicted to appear at the 
opposite horizon, and forms a link to it. Make-before-break. If anyone 
has seen photographs in their marketing material/videos of the Oneweb 
beta test earth stations in Alaska they are operating using the same 
general concept.


Oneweb has clearly positioned their market focus for telecoms and ISPs 
and large enterprise end users, because their CPE equipment is 
considerably larger, expensive and more power hungry. The beta test 
sites I've seen installed on top of a telecom equipment shelter occupy 
an area approximately 8 feet long x 4 feet wide including radomes and 
mounting.


I'm trying to understand this so sorry if this comes off dumb. So does 
the base station mediate all handoffs where the CPE is told when/what to 
handoff? Or does the CPE have some part in it (other than receiving the 
handoff)? Does the CPE accept control traffic (L2?) from any bird? Are 
there cases where the CPE needs to de-dup packets due to handoffs?


This is pretty fascinating stuff.

Mike

Re: Starlink routing

[Michael Thomas]

On 1/22/23 3:05 PM, Matthew Petach wrote:



On Sun, Jan 22, 2023 at 2:45 PM Michael Thomas  wrote:

I read in the Economist that the gen of starlink satellites will have
the ability to route messages between each satellite. Would
conventional
routing protocols be up to such a challenge? Or would it have to be
custom made for that problem? And since a lot of companies and
countries
are getting on that action, it seems like fertile ground for (bad)
wheel
reinvention?

Mike



Unlike most terrestrial links, the distances between satellites are 
not fixed,

and thus the latency between nodes is variable, making the concept of
"Shortest Path First" calculation a much more dynamic and challenging
one to keep current, as the latency along a path may be constantly 
changing
as the satellite nodes move relative to each other, without any link 
state actually

changing to trigger a new SPF calculation.


One thing that is in their favor is that while they are moving, they are 
moving in a predictable manner. It seems that each router could, 
essentially, locally update routes until they are told otherwise?





I suspect a form of OLSR might be more advantageous in a dynamic partial
mesh between satellites, but I haven't given it as much deep thought 
as would

be necessary to form an informed opinion.

So, yes--it's likely the routing protocol used will not be entirely 
"off-the-shelf"

but will instead incorporate continuous latency information in the LSDB,
and path selection will be time-bound based on the rate of increase in 
latency

along currently-selected edges in the graph.


Has IETF looked at this, do you know? Even if the routers can't 
interoperate with other systems, it would be good to have some routing 
clue with a lot of eyeballs on it to not make rookie mistakes.


Mike

Starlink routing

[Michael Thomas]

I read in the Economist that the gen of starlink satellites will have 
the ability to route messages between each satellite. Would conventional 
routing protocols be up to such a challenge? Or would it have to be 
custom made for that problem? And since a lot of companies and countries 
are getting on that action, it seems like fertile ground for (bad) wheel 
reinvention?


Mike

Fred Brooks has died

[Michael Thomas]

His Mythical Man Month is a must read for anybody even remotely adjacent 
to coding, and frankly it should be read out of that context too.


RIP Fred and thank you, that was one of the most important books I've 
ever read.


Mike

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Michael Thomas]

On 10/7/22 12:45 AM, Brian Turnbow via NANOG wrote:

The federal law in 47 USC 227(e) says:

(1)In general

  It shall be unlawful for any person within the United  States, or any person
outside the United States if the recipient is  within the United States, in
connection with any voice service or text  messaging service, to cause any
caller identification service to  knowingly transmit misleading or inaccurate
caller identification  information with the intent to defraud, cause harm, or
wrongfully  obtain anything of value, unless such transmission is exempted
pursuant to paragraph (3)(B).

In (3)(B) is a narrow carve-out for law enforcement and court orders.

The important point is that spoofing is illegal with fraudulent intent, OK with
benign intent.

This is a very interesting conversation as there is a ongoing discussion on how 
to ban spoofed calls here in Italy..
Here operators must identify each customer and ensure that they are screening 
incoming numbers.
I assume by "incoming" you mean incoming from the customer? That is, 
you're making sure your customers are not spoofing?

Most do, but some do not and become sources of spoofed traffic.
The biggest problem however comes from out of country originators that allow 
foreign call centers to use Italian numbers.
Are these spoofed or are they actually allocated to them? If they are 
actually allocated, their upstream provider should be enforcing too, right?

Thus the calls come in from an international carrier.
We are moving twords blocking incoming calls from international trunks 
containing Italian from numbers, something we see already in place for carriers 
in other EU countries such as France.
On the other hand, this makes your "incoming" above sound like incoming 
from the phone network. So I'm probably confused.

Most operators here have been against stir/shaken as a means to resolve the 
problems.


What reasons?

Mike

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Michael Thomas]

On 10/4/22 5:23 PM, Peter Beckman wrote:

On Tue, 4 Oct 2022, Michael Thomas wrote:

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.


 How does one carrier that gets DIDs from multiple other carriers
 communicate to the termination carrier selected during LCR that the DID
 set as CallerID is indeed serviced by that carrier and authorized to use
 said DID as CallerID?

 If a call is asynchronous, e.g. the DID carrier is not the terminating
 carrier, how can the termination carrier trust/know definitively that
 someone is allowed to use that CallerID?

 Don't forget the resellers!!!

My point is not that the termination carrier believe that it's 
legitimate (although that would be nice), but to get the originating 
carrier to police things before it ever gets forwarded. The FCC could 
have forced that ages ago in most cases. Requiring the receiving end to 
police things is fraught with false positives where the originating 
carrier has a lot more knowledge of who their customer is.


Mike

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Michael Thomas]

On 10/4/22 3:08 PM, Shane Ronan wrote:
I'm talking about PSTN hops, which like I previously said still 
accounts for a VERY significant amount of calls.



But what percentage of the spam calls? I thought they were mainly coming 
from voip/SIP?


Mike

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Michael Thomas]

On 10/4/22 2:00 PM, sro...@ronan-online.com wrote:
I suppose but that also means they need to go back and figure out 
which prefixes to allow, since historically hasn’t been tracked.



Which is the same thing as when email providers didn't care either. 
Getting them to care is key however you need to get that done.




Also, how does the man in the middle since most calls don’t go from 
originating carrier to terminating carrier, know if the originator did 
their job?


Why do the middle guys need to care? Only the originator and terminator 
have a stake in the spam problem. Of course I'm talking all SIP here, 
not with PSTN hops. Or is that what you're talking about?



Mike





On Oct 4, 2022, at 4:50 PM, Michael Thomas  wrote:




On 10/4/22 1:40 PM, sro...@ronan-online.com wrote:

Except the pstn DB isn’t distributed like DNS is.



Yes, I had forgot about "dip" in that sense. But an originating 
provider doesn't need to do a dip to know that the calling number 
routes to itself. I've been talking about the calling provider not 
the called provider all along.


Mike




On Oct 4, 2022, at 2:40 PM, Michael Thomas  wrote:




On 10/4/22 11:21 AM, Shane Ronan wrote:
Except the cost to do the data dips to determine the authorization 
isn't "free".


Since every http request in the universe requires a "database dip" 
and they are probably a billion times more common, that doesn't 
seem like a very compelling concern.


Mike




On Tue, Oct 4, 2022 at 2:18 PM Michael Thomas  wrote:


On 10/4/22 6:07 AM, Mike Hammett wrote:

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.



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.


Mike



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


*From: *"Shane Ronan" 
<mailto:sh...@ronan-online.com>
*To: *"Michael Thomas"  <mailto:m...@mtcc.com>
*Cc: *nanog@nanog.org
*Sent: *Monday, October 3, 2022 9:54:07 PM
*Subject: *Re: FCC chairwoman: Fines alone aren't enough
(Robocalls)

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.

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.

Shane



On Mon, Oct 3, 2022 at 7:05 PM Michael Thomas 
wrote:

The problem has always been solvable at the ingress
provider. The
problem was that there was zero to negative incentive to
do that. You
don't need an elaborate PKI to tell the ingress provider
which prefixes
customers are allow to assert. It's pretty analogous to
when submission
authentication was pretty nonexistent with email... there
was no
incentive to not be an open relay sewer. Unlike email
spam, SIP
signaling is pretty easy to determine whether it's spam.
All it needed
was somebody to force regulation which unlike email there
was always
jurisdiction with the FCC.

Mike

On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
> We're talking about blocking other carriers.
>
> On 10/3/22, 3:05 PM, "Michael Thomas" 
wrote:
>
>      On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
>      > Because it's illegal for common carriers to
block traffic otherwise.
>
>      Wait, what? It's illegal to police their own users?
>
>      Mike
    >
>      >
>      > On 10/3/22, 2:53 PM, "NANOG on behalf of
Michael Thomas"
 wrote:
>      >
>      >
>      >      On 10/3/22 1:34 PM, Sean Donelan wrote:
>      >      > 'Fines alone aren't enough:' FCC
threatens to blacklist voice
>      >      > providers for flouting robocall rules
>      >      >
>      >      >
https://www.cyberscoop.com/fcc-robocall-fine-database-removal/
&g

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Michael Thomas]

On 10/4/22 1:40 PM, sro...@ronan-online.com wrote:

Except the pstn DB isn’t distributed like DNS is.



Yes, I had forgot about "dip" in that sense. But an originating provider 
doesn't need to do a dip to know that the calling number routes to 
itself. I've been talking about the calling provider not the called 
provider all along.


Mike




On Oct 4, 2022, at 2:40 PM, Michael Thomas  wrote:




On 10/4/22 11:21 AM, Shane Ronan wrote:
Except the cost to do the data dips to determine the authorization 
isn't "free".


Since every http request in the universe requires a "database dip" 
and they are probably a billion times more common, that doesn't seem 
like a very compelling concern.


Mike




On Tue, Oct 4, 2022 at 2:18 PM Michael Thomas  wrote:


On 10/4/22 6:07 AM, Mike Hammett wrote:

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.



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.


Mike



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


*From: *"Shane Ronan" 
<mailto:sh...@ronan-online.com>
*To: *"Michael Thomas"  <mailto:m...@mtcc.com>
*Cc: *nanog@nanog.org
*Sent: *Monday, October 3, 2022 9:54:07 PM
*Subject: *Re: FCC chairwoman: Fines alone aren't enough
(Robocalls)

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.

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.

Shane



On Mon, Oct 3, 2022 at 7:05 PM Michael Thomas 
wrote:

The problem has always been solvable at the ingress
provider. The
problem was that there was zero to negative incentive to do
that. You
don't need an elaborate PKI to tell the ingress provider
which prefixes
customers are allow to assert. It's pretty analogous to
when submission
authentication was pretty nonexistent with email... there
was no
incentive to not be an open relay sewer. Unlike email spam,
SIP
signaling is pretty easy to determine whether it's spam.
All it needed
was somebody to force regulation which unlike email there
was always
jurisdiction with the FCC.

Mike

On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
> We're talking about blocking other carriers.
>
> On 10/3/22, 3:05 PM, "Michael Thomas"  wrote:
>
>      On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
>      > Because it's illegal for common carriers to block
traffic otherwise.
>
>      Wait, what? It's illegal to police their own users?
>
>      Mike
    >
>      >
>      > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael
Thomas"  wrote:
>      >
>      >
>      >      On 10/3/22 1:34 PM, Sean Donelan wrote:
>      >      > 'Fines alone aren't enough:' FCC threatens
to blacklist voice
>      >      > providers for flouting robocall rules
>      >      >
>      >      >
https://www.cyberscoop.com/fcc-robocall-fine-database-removal/
>      >      >
>      >      > [...]
>      >      > “This is a new era. If a provider doesn’t
meet its obligations under
>      >      > the law, it now faces expulsion from
America’s phone networks. Fines
>      >      > alone aren’t enough,” FCC chairwoman
Jessica Rosenworcel said in a
>      >      > statement accompanying the announcement.
“Providers that don’t follow
>      >      > our rules and make it easy to scam
consumers will now face swift
>      >      > consequences.”
>      >      >
>      >

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Michael Thomas]

On 10/4/22 11:58 AM, Tom Beecher wrote:


 Honestly the root of a lot of the problems here is the bellheaded
insistence of still using E.164 addresses in the first place. With
SIP they are complete legacy and there is no reason that my
"telephone number" can't be m...@mtcc.com.


You can do that all you want. You just don't get to interact with the 
PSTN.


What is the "PSTN" these days? It's a bunch of interconnected SIP 
proxies where there is nothing special about the identifiers used. With 
end to end SIP (or middle to middle, etc), the routing is not being done 
with e.164 addresses like in the legacy PSTN. It's just bellheaded 
thinking that e.164 addresses mean anything these days.The only time 
they make any difference is if they need to off ramp to legacy signaling 
which is becoming rarer and rarer.


Mike




On Tue, Oct 4, 2022 at 2:53 PM Michael Thomas  wrote:


On 10/4/22 11:31 AM, Mike Hammett wrote:

What's regulated or implemented is rarely the best course of
action. Does this cause more good or harm?



Honestly the root of a lot of the problems here is the bellheaded
insistence of still using E.164 addresses in the first place. With
SIP they are complete legacy and there is no reason that my
"telephone number" can't be m...@mtcc.com. In fact, that would be
a huge win since I could just use my email address book to make a
call. You could tell that STIR/SHAKEN really went off the rails
when it has heuristics on how to scrape E.164 addresses in the
From: field. At this point we should be mostly ignoring legacy
signaling, IMO.


Mike





-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


*From: *"Shane Ronan" 
<mailto:sh...@ronan-online.com>
*To: *"Michael Thomas"  <mailto:m...@mtcc.com>
*Cc: *"Mike Hammett" 
<mailto:na...@ics-il.net>, nanog@nanog.org
*Sent: *Tuesday, October 4, 2022 1:21:41 PM
*Subject: *Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

Except the cost to do the data dips to determine the
authorization isn't "free".

On Tue, Oct 4, 2022 at 2:18 PM Michael Thomas  wrote:


On 10/4/22 6:07 AM, Mike Hammett wrote:

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.


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.


Mike


-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com



    *From: *"Shane Ronan" 
<mailto:sh...@ronan-online.com>
*To: *"Michael Thomas"  <mailto:m...@mtcc.com>
*Cc: *nanog@nanog.org
*Sent: *Monday, October 3, 2022 9:54:07 PM
*Subject: *Re: FCC chairwoman: Fines alone aren't enough
(Robocalls)

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.

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.

Shane



On Mon, Oct 3, 2022 at 7:05 PM Michael Thomas
 wrote:

The problem has always been solvable at the ingress
provider. The
problem was that there was zero to negative incentive
to do that. You
don't need an elaborate PKI to tell the ingress
provider which prefixes
customers are allow to assert. It's pretty analogous
to when submission
authentication was pretty nonexistent with email...
there was no
incentive to not be an open relay sewer. Unlike email
spam, SIP
signaling is pretty easy to determ

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Michael Thomas]

Back when P-Asserted-Identity was coming into being I screamed at the 
top of my lungs that it was going to get abused. The reply was that the 
telephone network was a closed system so it wasn't a problem. It turns 
out that we were both sort of right. At that time, email submission 
authentication was still pretty uncommon so most ISP's were open relay 
sewers so there was nobody to name and shame, so we figured that it 
would be a good idea to provide that means. That's pretty much the case 
of telephony now since their providers don't care what the identity is 
in the signaling. But it was always the case that they could care and 
not allow spoofing, just like I can't spoof email addresses from my 
gmail account. And very unlike email, telephony has lots of regulatory 
machinery to require that to happen.


Mike

On 10/4/22 11:22 AM, b...@theworld.com wrote:

On October 3, 2022 at 16:05 m...@mtcc.com (Michael Thomas) wrote:
  > The problem has always been solvable at the ingress provider. The
  > problem was that there was zero to negative incentive to do that. You
  > don't need an elaborate PKI to tell the ingress provider which prefixes
  > customers are allow to assert. It's pretty analogous to when submission
  > authentication was pretty nonexistent with email... there was no
  > incentive to not be an open relay sewer. Unlike email spam, SIP
  > signaling is pretty easy to determine whether it's spam. All it needed
  > was somebody to force regulation which unlike email there was always
  > jurisdiction with the FCC.

Analogies to email are always fraught.

How often do LEGITIMATE telco customers make hundreds if not thousands
of calls per hour w/o some explicit arrangement with their telco?

As they say, a telephone company is a vast, detailed billing system
with an added voice feature.

Quite unlike email where it's mostly fire and forget plus or minus
hitting a spam filter precisely because there is no billing, no
incentive. And no voice "snowshoeing".

I doubt robocalls are ever made with anything like spam
roboarmies.

With email it's like every single computer on the net with an IP
address has, in effect, a (potentially) fully functional "originating
switch" (again, some exceptions like port 25 blocking.) People have
run spambots from others' printers etc.

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Michael Thomas]

On 10/4/22 11:31 AM, Mike Hammett wrote:
What's regulated or implemented is rarely the best course of action. 
Does this cause more good or harm?



Honestly the root of a lot of the problems here is the bellheaded 
insistence of still using E.164 addresses in the first place. With SIP 
they are complete legacy and there is no reason that my "telephone 
number" can't be m...@mtcc.com. In fact, that would be a huge win since 
I could just use my email address book to make a call. You could tell 
that STIR/SHAKEN really went off the rails when it has heuristics on how 
to scrape E.164 addresses in the From: field. At this point we should be 
mostly ignoring legacy signaling, IMO.



Mike





-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


*From: *"Shane Ronan" 
*To: *"Michael Thomas" 
*Cc: *"Mike Hammett" , nanog@nanog.org
*Sent: *Tuesday, October 4, 2022 1:21:41 PM
*Subject: *Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

Except the cost to do the data dips to determine the authorization 
isn't "free".


On Tue, Oct 4, 2022 at 2:18 PM Michael Thomas  wrote:


On 10/4/22 6:07 AM, Mike Hammett wrote:

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.


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.


Mike


-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


*From: *"Shane Ronan" 
    <mailto:sh...@ronan-online.com>
*To: *"Michael Thomas"  <mailto:m...@mtcc.com>
*Cc: *nanog@nanog.org
*Sent: *Monday, October 3, 2022 9:54:07 PM
*Subject: *Re: FCC chairwoman: Fines alone aren't enough
(Robocalls)

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.

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.

Shane



On Mon, Oct 3, 2022 at 7:05 PM Michael Thomas 
wrote:

The problem has always been solvable at the ingress
provider. The
problem was that there was zero to negative incentive to
do that. You
don't need an elaborate PKI to tell the ingress provider
which prefixes
customers are allow to assert. It's pretty analogous to
when submission
authentication was pretty nonexistent with email... there
was no
incentive to not be an open relay sewer. Unlike email
spam, SIP
signaling is pretty easy to determine whether it's spam.
All it needed
was somebody to force regulation which unlike email there
was always
jurisdiction with the FCC.

Mike

On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
> We're talking about blocking other carriers.
>
> On 10/3/22, 3:05 PM, "Michael Thomas" 
wrote:
>
>      On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
>      > Because it's illegal for common carriers to block
traffic otherwise.
>
>      Wait, what? It's illegal to police their own users?
>
    >      Mike
>
>      >
>      > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael
Thomas"  wrote:
>      >
>      >
>      >      On 10/3/22 1:34 PM, Sean Donelan wrote:
>      >      > 'Fines alone aren't enough:' FCC threatens
to blacklist voice
>      >      > providers for flouting robocall rules
>      >      >
>      >      >
https://www.cyberscoop.com/fc

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Michael Thomas]

On 10/4/22 11:21 AM, Shane Ronan wrote:
Except the cost to do the data dips to determine the authorization 
isn't "free".


Since every http request in the universe requires a "database dip" and 
they are probably a billion times more common, that doesn't seem like a 
very compelling concern.


Mike




On Tue, Oct 4, 2022 at 2:18 PM Michael Thomas  wrote:


On 10/4/22 6:07 AM, Mike Hammett wrote:

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.



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.


Mike



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


*From: *"Shane Ronan" 
<mailto:sh...@ronan-online.com>
*To: *"Michael Thomas"  <mailto:m...@mtcc.com>
*Cc: *nanog@nanog.org
*Sent: *Monday, October 3, 2022 9:54:07 PM
*Subject: *Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

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.

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.

    Shane



On Mon, Oct 3, 2022 at 7:05 PM Michael Thomas  wrote:

The problem has always been solvable at the ingress provider.
The
problem was that there was zero to negative incentive to do
that. You
don't need an elaborate PKI to tell the ingress provider
which prefixes
customers are allow to assert. It's pretty analogous to when
submission
authentication was pretty nonexistent with email... there was no
incentive to not be an open relay sewer. Unlike email spam, SIP
signaling is pretty easy to determine whether it's spam. All
it needed
was somebody to force regulation which unlike email there was
always
jurisdiction with the FCC.

Mike

On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
> We're talking about blocking other carriers.
    >
> On 10/3/22, 3:05 PM, "Michael Thomas"  wrote:
>
>      On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
>      > Because it's illegal for common carriers to block
traffic otherwise.
>
>      Wait, what? It's illegal to police their own users?
>
>      Mike
    >
>      >
>      > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael
Thomas"  wrote:
>      >
>      >
>      >      On 10/3/22 1:34 PM, Sean Donelan wrote:
>      >      > 'Fines alone aren't enough:' FCC threatens to
blacklist voice
>      >      > providers for flouting robocall rules
>      >      >
>      >      >
https://www.cyberscoop.com/fcc-robocall-fine-database-removal/
>      >      >
>      >      > [...]
>      >      > “This is a new era. If a provider doesn’t
meet its obligations under
>      >      > the law, it now faces expulsion from
America’s phone networks. Fines
>      >      > alone aren’t enough,” FCC chairwoman Jessica
Rosenworcel said in a
>      >      > statement accompanying the announcement.
“Providers that don’t follow
>      >      > our rules and make it easy to scam consumers
will now face swift
>      >      > consequences.”
>      >      >
>      >      > It’s the first such enforcement action by the
agency to reduce the
>      >      > growing problem of robocalls since call ID
verification protocols
>      >      > known as “STIR/SHAKEN” went fully into effect
this summer.
>      >      > [...]
>      >
>      >      Why did we need to wait for STIR/SHAKEN to do this?
>      >
>      >      Mike
>      >
>
>

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Michael Thomas]

On 10/4/22 11:20 AM, Mike Hammett wrote:
Isn't part of STIR/SHAKEN to make it easier to determine the ingress 
provider, or the provider of last blame?


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.



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.



Mike





-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


*From: *"Michael Thomas" 
*To: *"Mike Hammett" , "Shane Ronan" 


*Cc: *nanog@nanog.org
*Sent: *Tuesday, October 4, 2022 1:18:24 PM
*Subject: *Re: FCC chairwoman: Fines alone aren't enough (Robocalls)


On 10/4/22 6:07 AM, Mike Hammett wrote:

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.


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.



Mike


-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

----
*From: *"Shane Ronan" 
*To: *"Michael Thomas" 
*Cc: *nanog@nanog.org
*Sent: *Monday, October 3, 2022 9:54:07 PM
*Subject: *Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

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.

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.

    Shane



On Mon, Oct 3, 2022 at 7:05 PM Michael Thomas  wrote:

The problem has always been solvable at the ingress provider. The
problem was that there was zero to negative incentive to do
that. You
don't need an elaborate PKI to tell the ingress provider which
prefixes
customers are allow to assert. It's pretty analogous to when
submission
authentication was pretty nonexistent with email... there was no
incentive to not be an open relay sewer. Unlike email spam, SIP
signaling is pretty easy to determine whether it's spam. All
it needed
was somebody to force regulation which unlike email there was
always
jurisdiction with the FCC.

Mike

On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
> We're talking about blocking other carriers.
>
> On 10/3/22, 3:05 PM, "Michael Thomas"  wrote:
>
>      On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
>      > Because it's illegal for common carriers to block
traffic otherwise.
>
>      Wait, what? It's illegal to police their own users?
>
    >      Mike
    >
>      >
>      > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael
Thomas"  wrote:
>      >
>      >
>      >      On 10/3/22 1:34 PM, Sean Donelan wrote:
>      >      > 'Fines alone aren't enough:' FCC threatens to
blacklist voice
>      >      > providers for flouting robocall rules
>      >      >
>      >      >
https://www.cyberscoop.com/fcc-robocall-fine-database-removal/
>      >      >
>      >      > [...]
>      >      > “This is a new era. If a provider doesn’t meet
its obligations under
>      >      > the law, it now faces expulsion from America’s
phone networks. Fines
>      >      > alone aren’t enough,” FCC chairwoman Jessica
Rosenworcel said in a
>      >      > statement accompanying the announcement.
“Providers that don’t follow
>      >      > our rules and make it easy to scam consumers
wil

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Michael Thomas]

On 10/4/22 7:05 AM, Jawaid Bazyar wrote:

Phone spam pretty much always involves the knowledge and involvement of the 
provider. There are no phone providers who don't know when one of their 
customers are making millions of robocalls.

International toll fraud also always involves the collusion of corrupt small 
country telephone monopolies.

So unlike email spam, where there are a million ways to send a million emails a 
minute without someone being aware, phone spam is definitively collisional. (Is 
that a word?)


All the more reason why waiting for STIR/SHAKEN was unnecessary. And yes 
the telephony network is a lot easier than email to police.


Mike





On 10/3/22, 5:05 PM, "Michael Thomas"  wrote:

 The problem has always been solvable at the ingress provider. The
 problem was that there was zero to negative incentive to do that. You
 don't need an elaborate PKI to tell the ingress provider which prefixes
 customers are allow to assert. It's pretty analogous to when submission
 authentication was pretty nonexistent with email... there was no
 incentive to not be an open relay sewer. Unlike email spam, SIP
 signaling is pretty easy to determine whether it's spam. All it needed
 was somebody to force regulation which unlike email there was always
 jurisdiction with the FCC.

 Mike

 On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
 > We're talking about blocking other carriers.
 >
 > On 10/3/22, 3:05 PM, "Michael Thomas"  wrote:
 >
 >  On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
 >  > Because it's illegal for common carriers to block traffic 
otherwise.
 >
 >  Wait, what? It's illegal to police their own users?
 >
 >  Mike
 >
 >  >
     >  > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" 
 wrote:
 >  >
 >  >
 >  >  On 10/3/22 1:34 PM, Sean Donelan wrote:
 >  >  > 'Fines alone aren't enough:' FCC threatens to blacklist 
voice
 >  >  > providers for flouting robocall rules
 >  >  >
 >  >  > 
https://www.cyberscoop.com/fcc-robocall-fine-database-removal/
 >  >  >
 >  >  > [...]
 >  >  > “This is a new era. If a provider doesn’t meet its 
obligations under
 >  >  > the law, it now faces expulsion from America’s phone 
networks. Fines
 >  >  > alone aren’t enough,” FCC chairwoman Jessica Rosenworcel 
said in a
 >  >  > statement accompanying the announcement. “Providers that 
don’t follow
 >  >  > our rules and make it easy to scam consumers will now face 
swift
 >  >  > consequences.”
 >  >  >
 >  >  > It’s the first such enforcement action by the agency to 
reduce the
 >  >  > growing problem of robocalls since call ID verification 
protocols
 >  >  > known as “STIR/SHAKEN” went fully into effect this summer.
 >  >  > [...]
 >  >
 >  >  Why did we need to wait for STIR/SHAKEN to do this?
 >  >
 >  >  Mike
 >  >
 >
 >

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Michael Thomas]

On 10/4/22 6:07 AM, Mike Hammett wrote:
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.



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.



Mike



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


*From: *"Shane Ronan" 
*To: *"Michael Thomas" 
*Cc: *nanog@nanog.org
*Sent: *Monday, October 3, 2022 9:54:07 PM
*Subject: *Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

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.


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.


Shane



On Mon, Oct 3, 2022 at 7:05 PM Michael Thomas  wrote:

The problem has always been solvable at the ingress provider. The
problem was that there was zero to negative incentive to do that. You
don't need an elaborate PKI to tell the ingress provider which
prefixes
customers are allow to assert. It's pretty analogous to when
submission
authentication was pretty nonexistent with email... there was no
incentive to not be an open relay sewer. Unlike email spam, SIP
signaling is pretty easy to determine whether it's spam. All it
needed
was somebody to force regulation which unlike email there was always
jurisdiction with the FCC.

Mike

On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
> We're talking about blocking other carriers.
>
    > On 10/3/22, 3:05 PM, "Michael Thomas"  wrote:
>
>      On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
>      > Because it's illegal for common carriers to block traffic
otherwise.
>
>      Wait, what? It's illegal to police their own users?
>
>      Mike
>
    >      >
>      > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas"
 wrote:
>      >
>      >
>      >      On 10/3/22 1:34 PM, Sean Donelan wrote:
>      >      > 'Fines alone aren't enough:' FCC threatens to
blacklist voice
>      >      > providers for flouting robocall rules
>      >      >
>      >      >
https://www.cyberscoop.com/fcc-robocall-fine-database-removal/
>      >      >
>      >      > [...]
>      >      > “This is a new era. If a provider doesn’t meet its
obligations under
>      >      > the law, it now faces expulsion from America’s
phone networks. Fines
>      >      > alone aren’t enough,” FCC chairwoman Jessica
Rosenworcel said in a
>      >      > statement accompanying the announcement.
“Providers that don’t follow
>      >      > our rules and make it easy to scam consumers will
now face swift
>      >      > consequences.”
>      >      >
>      >      > It’s the first such enforcement action by the
agency to reduce the
>      >      > growing problem of robocalls since call ID
verification protocols
>      >      > known as “STIR/SHAKEN” went fully into effect this
summer.
>      >      > [...]
>      >
>      >      Why did we need to wait for STIR/SHAKEN to do this?
>      >
>      >      Mike
>      >
>
>

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Michael Thomas]

The problem has always been solvable at the ingress provider. The 
problem was that there was zero to negative incentive to do that. You 
don't need an elaborate PKI to tell the ingress provider which prefixes 
customers are allow to assert. It's pretty analogous to when submission 
authentication was pretty nonexistent with email... there was no 
incentive to not be an open relay sewer. Unlike email spam, SIP 
signaling is pretty easy to determine whether it's spam. All it needed 
was somebody to force regulation which unlike email there was always 
jurisdiction with the FCC.


Mike

On 10/3/22 3:13 PM, Jawaid Bazyar wrote:

We're talking about blocking other carriers.

On 10/3/22, 3:05 PM, "Michael Thomas"  wrote:

 On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
 > Because it's illegal for common carriers to block traffic otherwise.

 Wait, what? It's illegal to police their own users?

 Mike

 >
 > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" 
 wrote:
 >
 >
 >  On 10/3/22 1:34 PM, Sean Donelan wrote:
 >  > 'Fines alone aren't enough:' FCC threatens to blacklist voice
 >  > providers for flouting robocall rules
 >  >
 >  > https://www.cyberscoop.com/fcc-robocall-fine-database-removal/
 >  >
 >  > [...]
 >  > “This is a new era. If a provider doesn’t meet its obligations 
under
 >  > the law, it now faces expulsion from America’s phone networks. 
Fines
 >  > alone aren’t enough,” FCC chairwoman Jessica Rosenworcel said in a
 >  > statement accompanying the announcement. “Providers that don’t 
follow
 >  > our rules and make it easy to scam consumers will now face swift
 >  > consequences.”
 >  >
 >  > It’s the first such enforcement action by the agency to reduce the
 >  > growing problem of robocalls since call ID verification protocols
 >  > known as “STIR/SHAKEN” went fully into effect this summer.
 >  > [...]
 >
 >  Why did we need to wait for STIR/SHAKEN to do this?
 >
 >  Mike
 >

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Michael Thomas]

On 10/3/22 1:54 PM, Jawaid Bazyar wrote:

Because it's illegal for common carriers to block traffic otherwise.


Wait, what? It's illegal to police their own users?

Mike



On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" 
 wrote:


 On 10/3/22 1:34 PM, Sean Donelan wrote:
 > 'Fines alone aren't enough:' FCC threatens to blacklist voice
 > providers for flouting robocall rules
 >
 > https://www.cyberscoop.com/fcc-robocall-fine-database-removal/
 >
 > [...]
 > “This is a new era. If a provider doesn’t meet its obligations under
 > the law, it now faces expulsion from America’s phone networks. Fines
 > alone aren’t enough,” FCC chairwoman Jessica Rosenworcel said in a
 > statement accompanying the announcement. “Providers that don’t follow
 > our rules and make it easy to scam consumers will now face swift
 > consequences.”
 >
 > It’s the first such enforcement action by the agency to reduce the
 > growing problem of robocalls since call ID verification protocols
 > known as “STIR/SHAKEN” went fully into effect this summer.
 > [...]

 Why did we need to wait for STIR/SHAKEN to do this?

 Mike

Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Michael Thomas]

On 10/3/22 1:34 PM, Sean Donelan wrote:
'Fines alone aren't enough:' FCC threatens to blacklist voice 
providers for flouting robocall rules


https://www.cyberscoop.com/fcc-robocall-fine-database-removal/

[...]
“This is a new era. If a provider doesn’t meet its obligations under 
the law, it now faces expulsion from America’s phone networks. Fines 
alone aren’t enough,” FCC chairwoman Jessica Rosenworcel said in a 
statement accompanying the announcement. “Providers that don’t follow 
our rules and make it easy to scam consumers will now face swift 
consequences.”


It’s the first such enforcement action by the agency to reduce the 
growing problem of robocalls since call ID verification protocols 
known as “STIR/SHAKEN” went fully into effect this summer.

[...]


Why did we need to wait for STIR/SHAKEN to do this?

Mike

Re: VZ FIOS and Intel TCP IPv6 Checksum Offload problems

[Michael Thomas]

On 8/27/22 3:36 PM, Mel Beckman wrote:

No. In fact, a lot of low-end Ethernet interfaces are completely implemented in 
interrupt-driven driver software that runs in the host OS (such as Windows). 
The only thing the hardware provides is the magnetically to transduce binary 
bit streams.

Even MAC-address decode is in software, and as a result, broadcast storms can 
slow these hosts to a crawl as the CPU had to check and discard every broadcast 
packet as “not mine”.

When these tasks are offloaded from the CPU to the Ethernet hardware, the CPU 
doesn’t need to perform these tasks, reducing CPU workload. These also 
offloading resources provide parallel computing and validation of checksums, 
which is otherwise computationally expensive.

I don’t know how this particular ONT bug works, but I’m guessing that it 
results in checksum failures under certain conditions, leading to 
retransmissions.


Yeah, sorry brain fart. I'd be surprised if that were a big issue on 
home networks, but who knows.


Mike



-mel via cell


On Aug 27, 2022, at 3:08 PM, Michael Thomas  wrote:



On 8/27/22 12:00 PM, Sean Donelan wrote:
Hopefully, my pain will help someone else.

I've had sporadic Internet slowdowns and stuck networking since IPv6 was 
enabled on my FIOS ONT a few months ago.

After too much troubleshooting, I found out some older Intel GbE ethernet cards 
have a IPv6 Checksum Offload incompatibility with certain fiber ONT terminals.  
As Verizon is enabling IPv6 on its FIOS network, you might find intermittent 
network problems.

Intermittent are the worst kind of problems.

In some situations where a client machine is connected via some specific 
Optical Network Terminals (ONTs), and data is appended after the packet 
checksum, the network adapter can drop receive packets when using TCP-IPv6 
Checksum Offload for receive traffic.

Intel published an alert in 2017, but I didn't have IPv6 on FIOS then.

https://www.intel.com/content/www/us/en/download/19174/disabling-tcp-ipv6-checksum-offload-capability-with-intel-1-10-gbe-controllers.html


TLDR; turn off TCP IPv6 Checksum Offload

Affects all operating systems (Windows, BSD, Linux, etc) using the affected 
wired Intel ethernet controllers.  Not a problem with Intel WiFi.

My reaction is "offload from what"? Isn't this all done in silicon?

Mike

Re: VZ FIOS and Intel TCP IPv6 Checksum Offload problems

[Michael Thomas]

On 8/27/22 12:00 PM, Sean Donelan wrote:

Hopefully, my pain will help someone else.

I've had sporadic Internet slowdowns and stuck networking since IPv6 
was enabled on my FIOS ONT a few months ago.


After too much troubleshooting, I found out some older Intel GbE 
ethernet cards have a IPv6 Checksum Offload incompatibility with 
certain fiber ONT terminals.  As Verizon is enabling IPv6 on its FIOS 
network, you might find intermittent network problems.


Intermittent are the worst kind of problems.

In some situations where a client machine is connected via some 
specific Optical Network Terminals (ONTs), and data is appended after 
the packet checksum, the network adapter can drop receive packets when 
using TCP-IPv6 Checksum Offload for receive traffic.


Intel published an alert in 2017, but I didn't have IPv6 on FIOS then.

https://www.intel.com/content/www/us/en/download/19174/disabling-tcp-ipv6-checksum-offload-capability-with-intel-1-10-gbe-controllers.html 




TLDR; turn off TCP IPv6 Checksum Offload

Affects all operating systems (Windows, BSD, Linux, etc) using the 
affected wired Intel ethernet controllers.  Not a problem with Intel 
WiFi.


My reaction is "offload from what"? Isn't this all done in silicon?

Mike

Re: Facebook down?

[Michael Thomas]

I can see in the browser debug spew that it's getting 503's on fbcdn.net.

Mike

On 8/11/22 2:36 PM, Joe Loiacono wrote:

Well, makes sense. According to Schrodinger it's both up and down.

On 8/11/2022 5:16 PM, Michael Thomas wrote:


On 8/11/22 2:12 PM, Mel Beckman wrote:

According to Heisenberg, it’s up :)


It's still having problems serving up images. Thankfully their ad 
images are not affected :/


Mike



-mel via cell


On Aug 11, 2022, at 1:44 PM, Michael Thomas  wrote:

And of course the act of sending this mail caused the wave 
function to collapse and it seems to be up again, at least for me.


Mike


On 8/11/22 1:37 PM, Michael Thomas wrote:
They haven't been serving up images for like an hour or so and now 
it's showing their fail whale. Not sure if it's a (internal) 
network problem or not.


I'm in California fwiw.

Mike

Re: Facebook down?

[Michael Thomas]

On 8/11/22 2:12 PM, Mel Beckman wrote:

According to Heisenberg, it’s up :)


It's still having problems serving up images. Thankfully their ad images 
are not affected :/


Mike



-mel via cell


On Aug 11, 2022, at 1:44 PM, Michael Thomas  wrote:

And of course the act of sending this mail caused the wave function to 
collapse and it seems to be up again, at least for me.

Mike


On 8/11/22 1:37 PM, Michael Thomas wrote:
They haven't been serving up images for like an hour or so and now it's showing 
their fail whale. Not sure if it's a (internal) network problem or not.

I'm in California fwiw.

Mike

Re: Facebook down?

[Michael Thomas]

And of course the act of sending this mail caused the wave function to 
collapse and it seems to be up again, at least for me.


Mike

On 8/11/22 1:37 PM, Michael Thomas wrote:
They haven't been serving up images for like an hour or so and now 
it's showing their fail whale. Not sure if it's a (internal) network 
problem or not.


I'm in California fwiw.

Mike

Facebook down?

[Michael Thomas]

They haven't been serving up images for like an hour or so and now it's 
showing their fail whale. Not sure if it's a (internal) network problem 
or not.


I'm in California fwiw.

Mike

Re: NANOG List posts and DMARC

[Michael Thomas via NANOG]

On 8/2/22 12:30 PM, Jim Popovitch via NANOG wrote:

On Tue, 2022-08-02 at 11:24 -0700, Michael Thomas via NANOG wrote:

On 8/2/22 11:18 AM, Chris Adams via NANOG wrote:

Once upon a time, Chris Adams  said:

Once upon a time, Jared Mauch  said:

Can someone flip the option in Mailman for DMARC please, it’s problematic as if 
one posts and does DMARC and has feedback on, our messages are  possibly 
rejected, and the feedback from a post is quite large.

The list is doing the DMARC handling (From rewrite) for senders with a
DMARC p=reject.

Oh, or someone just changed the config per your request. :)  I have
p=none but my From got rewritten on this message.

I think it's been doing this for ages. It was the first time I'd seen
  From rewriting in the wild iirc.

It's been doing it for ages for p=reject, but not p=none (the latter
being Jared's situation)

There are toggles in MM2 to do DMARC address rewriting for p=none and
p=quarantine in addition to p=reject.

I'm sort of surprised that an org would have p=reject when its users use 
outside mailing lists. Most mailing lists probably don't even have From 
rewriting or the mailing list operator is clueless about the problem. 
(think: non-technical mailing lists).


Mike

Re: NANOG List posts and DMARC

[Michael Thomas via NANOG]

On 8/2/22 11:18 AM, Chris Adams via NANOG wrote:

Once upon a time, Chris Adams  said:

Once upon a time, Jared Mauch  said:

Can someone flip the option in Mailman for DMARC please, it’s problematic as if 
one posts and does DMARC and has feedback on, our messages are  possibly 
rejected, and the feedback from a post is quite large.

The list is doing the DMARC handling (From rewrite) for senders with a
DMARC p=reject.

Oh, or someone just changed the config per your request. :)  I have
p=none but my From got rewritten on this message.


I think it's been doing this for ages. It was the first time I'd seen 
From rewriting in the wild iirc.


I'm not understanding what problem Jared is talking about.

Mike

Re: Sigh, friends don't let politicians write tech laws

[Michael Thomas]

On 7/29/22 2:57 PM, Anne Mitchell wrote:



On Jul 29, 2022, at 3:37 PM, John Levine  wrote:

It appears that Michael Thomas  said:

-=-=-=-=-=-


https://www.congress.gov/bill/117th-congress/senate-bill/4409/text?r=9=1

the body of the proposed law:

This bill was filed by a bunch of the usual right wing suspects about
a month ago.  It was referred to committee, like all filed bills, and
I very much doubt it will ever emerge.

I'm inclined to agree, except that as we've seen Google has already attempted to cave, which means 
that they (the bills' sponsors) will feel even more emboldened, and can point to Google's 
"pilot program" as evidence that "even Google admits there is a problem, so we need 
the law to make the other big providers do it."

I believe we can't rely on it being buried without a little help.  It costs 
nothing to send an email to a representative, so..why not provide that help. ;~)


Really? It's completely unworkable. What would even constitute "compliance"?

Mike

Sigh, friends don't let politicians write tech laws

[Michael Thomas]

https://www.congress.gov/bill/117th-congress/senate-bill/4409/text?r=9=1

the body of the proposed law:

"(a) Conduct prohibited.—

(1) IN GENERAL.—It shall be unlawful for an operator of an email service 
to use a filtering algorithm to apply a label to an email sent to an 
email account from a political campaign unless the owner or user of the 
account took action to apply such a label."


where to even start with how bad this would be.

thanks for the heads up from Anne Mitchell

Mike

Re: Does anybody know if part of this enforcement involves STIR/SHAKEN?

[Michael Thomas]

On 7/22/22 4:00 PM, Sean Donelan wrote:

On Fri, 22 Jul 2022, Michael Thomas wrote:
Basically the jist that it's fake auto warranty fraud calls. Or is 
this just requiring providers to do the forensics whichever way to 
enforce this?


https://www.cnn.com/2022/07/21/tech/fcc-robocall-crackdown/index.html



As always speak with your corporate attorney or a licensed attorney 
familar with communications law.


The FCC order is under the TRACED Act of 2019. The order doesn't 
depend on STIR/SHAKEN. The Traceback Consortium and providers use a 
variety of methods to identify the calls.



"By this Order, the Bureau directs all U.S.-based voice service 
providers to investigate promptly the apparently illegal robocall 
traffic identified in section II.A. above. We further direct all voice 
service providers that locate any of the apparently illegal robocall 
traffic
described in this Order to take immediate steps to effectively 
mitigate and prevent further transmission of the apparently unlawful 
calls."

[...]
"If the voice service provider concludes that the identified traffic 
was not illegal, the report must include an explanation as to why the 
provider has reasonably concluded that the identified calls were not 
illegal and what steps the voice service provider took to reach that 
conclusion."

[...]

The order is available
https://www.fcc.gov/document/robocall-enforcement-order-all-us-based-voice-service-providers 




So the FCC could have done this well before with routes that don't 
involve crypto authentication? That's what I've always assumed.


Mike

Does anybody know if part of this enforcement involves STIR/SHAKEN?

[Michael Thomas]

Basically the jist that it's fake auto warranty fraud calls. Or is this 
just requiring providers to do the forensics whichever way to enforce this?


https://www.cnn.com/2022/07/21/tech/fcc-robocall-crackdown/index.html

Mike

Re: What say you, nanog re: Starlink vs 5G?

[Michael Thomas]

On 6/24/22 12:38 PM, Owen DeLong wrote:



On Jun 24, 2022, at 12:33 , Michael Thomas  wrote:


On 6/24/22 9:09 AM, Chris Wright wrote:

The term "5G" among technical circles started vague, became better defined over 
the course of several years, and is becoming vague again. This nuance was never well 
understood in the public eye, nor by mass publications like CNN. This is a battle for 
12GHz, not 5G.

But is what Starlink saying true or not?

It would be a pity to not have an alternative to incumbent telephants.

Mike

It’s not entirely clear, without knowing the technical details of the Starlink 
modulation scheme whether or not they could successfully share the 12Ghz 
spectrum.

I have no reason to disbelieve their claims.

Frankly, I really don’t think that Dish’s idea of providing 5G mobile service 
from satellites is a particularly good or beneficial one and granting them 
12Ghz spectrum for this purpose is probably not really in the public interest.
I thought they were land based? What I read is that being land based 
means that they can transmit at much higher power.


OTOH, I think Starlink is most definitely an interesting product that does 
provide a clear path to reasonable alternatives to the incumbent telephants.
Especially when you factor in mobility when they get there. No more 
roaming fees, all over the world.



Mike

Re: What say you, nanog re: Starlink vs 5G?

[Michael Thomas]

On 6/24/22 9:09 AM, Chris Wright wrote:

The term "5G" among technical circles started vague, became better defined over 
the course of several years, and is becoming vague again. This nuance was never well 
understood in the public eye, nor by mass publications like CNN. This is a battle for 
12GHz, not 5G.


But is what Starlink saying true or not?

It would be a pity to not have an alternative to incumbent telephants.

Mike

What say you, nanog re: Starlink vs 5G?

[Michael Thomas]

https://www.cnn.com/2022/06/23/tech/spacex-dish-fcc-spectrum-scn/index.html

Mike

Re: Upstream bandwidth usage

[Michael Thomas]

On 6/10/22 6:52 AM, Mike Hammett wrote:
Due to the demand being predominately in the downward direction, 
half-duplex (or effectively half-duplex) systems either allocate more 
TDMA slots or more channels to downstream, at the expense of upstream.


Well, my dsl provider has like a 25/5 50/10 so clearly everybody has the 
headroom to get to 10 at least. Marketing, of course, but I wonder how 
many support calls they got because "my internet is slow" from saturated 
upstream with zoom calls. I mean, most users have no clue about such things.



Mike






-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


*From: *"Michael Thomas" 
*To: *nanog@nanog.org
*Sent: *Thursday, June 9, 2022 3:46:24 PM
*Subject: *Re: Upstream bandwidth usage


On 6/9/22 1:26 PM, Mel Beckman wrote:
> With 430 GB versus 32 GV average down versus up usage today, according
> to your article, this is still not a case for symmetrical consumer
> bandwidth. Yes, the upstream usage increased slightly more than the
> downstream usage. But the ratio was still so big that it would take
> decades for them to join. I doubt they ever will. Consumers just don’t
> have that much days up to push yet, and probably never will.
>
> Also, a lot of that Usage can be explained by video conferencing
> during Covid, which has dropped off significantly already.
>
>
If it's so tiny, why shape it aggressively? Why shouldn't I be able to
burst to whatever is available at the moment? I would think most users
would be happy with that.

Mike

Re: Upstream bandwidth usage

[Michael Thomas]

On 6/9/22 4:31 PM, Mel Beckman wrote:

Adam,

Your point on asymmetrical technologies is excellent. But you may not be aware 
that residential optical fiber is also asymmetrical. For example, GPON, the 
latest ITU specified PON standard, and the most widely deployed, calls for a 
2.4 Gbps downstream and a 1.25 Gbps upstream optical line rate.


Why would they mandate such a thing? That seems like purely an operator 
decision.


Mike

Re: Upstream bandwidth usage

[Michael Thomas]

On 6/9/22 1:26 PM, Mel Beckman wrote:
With 430 GB versus 32 GV average down versus up usage today, according 
to your article, this is still not a case for symmetrical consumer 
bandwidth. Yes, the upstream usage increased slightly more than the 
downstream usage. But the ratio was still so big that it would take 
decades for them to join. I doubt they ever will. Consumers just don’t 
have that much days up to push yet, and probably never will.


Also, a lot of that Usage can be explained by video conferencing 
during Covid, which has dropped off significantly already.



If it's so tiny, why shape it aggressively? Why shouldn't I be able to 
burst to whatever is available at the moment? I would think most users 
would be happy with that.


Mike

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[Michael Thomas]

On 6/6/22 4:27 PM, Jim Troutman wrote:

Some usage data:

On a rural FTTX XGS-PON network with primarily 1Gig symmetric 
customers, I see about 1.5mbit/customer average inbound across 7 days, 
peaks at about 10mbit/customer, with 1 minute polling.  Zero 
congestion in middle mile, transit or peering.


Can you tease out the cable cutters? That is, I would expect that you'll 
get more and more going forward until they are the vast majority.


I guess I could look at my own router's stats too :)

Mike

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[Michael Thomas]

On 6/6/22 4:08 PM, Tony Wicks wrote:


  * Do you have any stats on what the average usage was before and
after the build out? I'd expect it to go up just because but was
it dramatic?

Well, Back in the FTTC days of ADSL/VDSL (very little cable) as an ISP 
I seem to remember the average home connection was about 1.2Mb/s. Now 
its about 3Mb/s so no, the usage itself does not jump dramatically 
when the bottlenecks went away. A great example of this is the lowest 
speed on the GPON network recently jumped from 100/20 to 300/100 
across the board and as an ISP we barely noticed anything.  Before 
this the two most popular speeds were the 100/20 and 1000/500 plans, 
50% of users would order the 1000/500 plan, most without really 
knowing why but it was only about $20 different so why not. As an ISP 
the 1G users only used about 10%-20% more overall capacity than the 
100/20 users.



Excellent, so you're printing money catering to people's vanity :)

Mike

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[Michael Thomas]

On 6/6/22 3:36 PM, Tony Wicks wrote:


>This whole thread is about hypothetical futures, so it's not hard to 
imagine downloads filling to available capacity.


>Mike

So, a good example of how this capacity is used, In New Zealand we 
have a pretty broad fibre network covering most of the population. My 
niece asked me to share my backup copy of her wedding photo’s/video’s 
the other day. I have a 4Gb/s / 4Gb/s XGSPON connection and she’s got 
a 1Gb/s / 500Mb/s GPON connection. I simply dropped a copy of the 5.1G 
directory into a one drive folder and shared it, 10 minutes later (one 
drive is still limited in how fast you can upload) she had it all and 
she was very happy. With these speeds its not even a consideration to 
think about capacity, everything just works.


Do you have any stats on what the average usage was before and after the 
build out? I'd expect it to go up just because but was it dramatic?


Mike

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[Michael Thomas]

On 6/6/22 12:00 PM, Christopher Morrow wrote:
is gatekeeping what users MIGHT do, and/or deciding based on corner 
cases helpful to this discussion?
(this isn't meant as a note directly to dorn, just a convenient place 
to interject)


Aside from planning based on a formula like Jason Livingood's plan... 
OR based on build/deploy/upgrade costs into pricing.

most of the rest of the conversation here sounds like gatekeeping:
  "Well, who needs that anyway?"



One takeaway for me on this thread is that once you've installed fiber 
the difference in cost between 1G and 100M is not very big if at all. 
That makes a good case for just doing it for future proofing.


Mike

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[Michael Thomas]

On 6/6/22 11:45 AM, Dorn Hetzel wrote:
Agreed, even with a 16TB drive, that's only 16000*8 ~= 128000 seconds 
of 1-gigabit download rate (under 36 hours) :)



This whole thread is about hypothetical futures, so it's not hard to 
imagine downloads filling to available capacity.


Mike



On Mon, Jun 6, 2022 at 2:26 PM Chris Adams  wrote:

Once upon a time, Michael Thomas  said:
> I meant downloads as in gigantic games. If you give them more
> bandwidth it just encourages the game makes to build bigger game
> downloads.

I don't buy that - users are still constrained on storage,
especially on
consoles.
-- 
Chris Adams