Re: Is soliciting money/rewards for 'responsible' security disclosures when none is stated a thing now?
On Wed, 02 Mar 2022 15:30:29 -0700, Brie said: > I just got this in my e-mail... > I am a web app security hunter. I spent some time on your website and found > some vulnerabilities. I see on your website you take security very > passionately. I've gotten similar spam a number of times over the years (though people offering to do SEO on my site are much more frequent). The odd thing is - as far as I know, I don't *have* a website pgp9WM3pp1ZpR.pgp Description: PGP signature
Re: Starlink terminals deployed in Ukraine
On Wed, 02 Mar 2022 08:51:05 -0500, Dorn Hetzel said: > Yeah, if Russia needs one 1st stage booster for every bird they kill, and > SpaceX needs one 1st stage booster for every 50 they put up Yes, > Russia is bigger than SpaceX, but that's a tremendous ratio. Plus the asymmetry is even worse than that Elon can use that *same* first stage booster to launch *another* 50 next week, while the Russians need to get a *new* booster for shooting down the next bird. That's the *real* game changer in what SpaceX is doing pgpNfxSUtYfvP.pgp Description: PGP signature
Re: VPN recommendations?
On Thu, 10 Feb 2022 10:55:40 -0800, William Herrin said: > My understanding is that Wireguard is software available for general > purpose operating systems. I specifically need a set of hardware > network appliances. Take a general purpose OS, strip down the userspace a bit, stick the whole thing in a box, and call it an appliance. They'll never know the difference. :)
Re: Anyone seeing ping corruption?
On Mon, 20 Dec 2021 22:45:06 +, Steven Champeon said: > Are there even enough dialup connections and ancient modems left that POD > is a thing anyone needs to worry about? It wasn't just dialup and modems. The Ping of Death had to do with sending a packet that was already 64K in size, that would require an ICMP response that would try to include the entire packet - corrupting the memory following the buffer the response was built in. Lots of ethernet-connected Windows systems got BSOD'd that way. Having said that, I'm sure there's still unpatched systems out there. Probably a few that are *still* unpatched against the 1990s IPV4 version, but a lot more likely for the 2013 and 2020 IPv6 versions against Microsoft systems. pgpFCz3rJgAyT.pgp Description: PGP signature
Re: IPv6 woes - RFC
On Wed, 29 Sep 2021 16:09:26 -0400, Victor Kuarsingh said: > - Both providers provide IPv6 and delegate a prefix to the router (let's > pretend the retail staff knew enough to sell this person a consumer box > with 2x WAN interfaces) So... do such boxes exist in any great quantity? Do consumers who can't add a valid number after 'IPv' accidentally contract for Internet service from two different providers often? Do they intentionally do that often? It sounds like a sufficiently rare situation that "clueless lawyer/whatever hires somebody with clue for 2 hours work to configure it all" is a reasonable solution. pgpTz8s7miAkD.pgp Description: PGP signature
Re: [External] Re: uPRF strict more
On Thu, 30 Sep 2021 18:12:51 +0200, Mark Tinka said: > I should have said "If you don't plan to run a full BGP table on a > device without a default a route as well, Am I insufficently caffienated, or is uRPF the least of your problems if you don't have a full table *and* don't have a default route? pgp5WFYI4WSQ6.pgp Description: PGP signature
Re: IPv6 woes - RFC
On Sat, 25 Sep 2021 23:20:26 +0200, Baldur Norddahl said: > We should remember there are also multiple ways to print IPv4 addresses. > You can zero extend the addresses and on some ancient systems you could > also use the integer value. 19:17:38 0 [~] ping 2130706433 PING 2130706433 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.126 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.075 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.063 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.082 ms ^C --- 2130706433 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 84ms rtt min/avg/max/mdev = 0.063/0.086/0.126/0.025 ms Works on Fedora Rawhide based on RedHat, Debian 10, and Android 9. That's a bit more than just 'some ancient systems' - depending whether it works on other Android releases, and what IoT systems do, we may have more systems today that support it than don't support it.
Re: IPv6 woes - RFC
On Wed, 15 Sep 2021 13:38:21 +0900, Masataka Ohta said: > Not. With geographical aggregation, you may route a call > *anywhere* in the destination country. The *real* fun starts when my provider is able to connect calls to my +1 540 etcetc phone number to my phone even if I'm in +371 or +81 or similar pgp_lXcRnSpKv.pgp Description: PGP signature
Re: IPv6 woes - RFC
On Wed, 08 Sep 2021 11:39:50 -0700, Owen DeLong via NANOG said: > The reality is that if we get content dual-stacked and stop requiring IPv4 > for new eyeball installations, thatâs the biggest initial win. The problem is "get content dual-stacked". Somebody made this handy page of the IPv6 status for the Alexa Top 500. http://www.delong.com/ipv6_alexa500.html Awful lot of red spots even in the top 100. Hell, even amazon.com isn't IPv6 yet. And the long tail is going to be the death of a thousand cuts for the call center unless you have a way to deal with those sites. And the devil is in the details. cnn.com itself has a quad-A. But looking at Chrome loading it with the IPvFoo extension, I see that of the 145 addresses it hits, only 38 are IPv6, the rest are IPv4. On the other hand, looking at *who* are the IPv4, they seem to be overwhelmingly ad servers and analytics sites - so maybe hitting cnn.com as IPv6-only is a win for the consumer. I rather suspect that the CFO of CNN would see it differently though (Eerily reminiscent of the factoid that 60% of the cost of a long distance phone call before the AT breakup was keeping the accounting records so they could bill the customer) pgpaqJDQHc0BT.pgp Description: PGP signature
Re: An update on the AfriNIC situation
On Fri, 27 Aug 2021 09:50:01 -0700, Owen DeLong via NANOG said: > > Cloud innovation accounts for 80% of all AFRINIC whois updates in 2021 > > to date and in AFRINIC whois, over 10 million (roughly 10% of all > > AFRINIC space) IP addresses whois information has not been updated in > > more than 10 years. Am I the only person whose spidey sense is tingling, wondering why one organization is churning when other registrants don't show activity for decades? pgpohVTxbU32g.pgp Description: PGP signature
Re: Newbie Questions: How-to monitor/control unauthorized uses of our IPs and DNS zones?
On Fri, 20 Aug 2021 01:32:16 +0700, Pirawat WATANAPONGSE via NANOG said: > 1. How-to monitor whether some outsiders are putting our IP addresses into > their A/ records without me knowing about it? So some bozo sticks an entry in their DNS that says bozo-entry.example.com A your.ip.address.here Who cares? What problem does this cause? You'd never even know it unless somebody/something actually *uses* the DNS record - which will result in traffic to the address. And at that point, you usually don't care what DNS entry was used, except for the case of a webserver serving multiple names and using different TLS certificates for each name. > 2. How-to monitor whether some outside websites are just âshellsâ, with > contents actually being hosted by our servers without me knowing about it? Again - what actual problem are you trying to solve here? If you're being used as a cache or backend site and don't know it, you have *bigger* problems. pgpUmdJb4RO7f.pgp Description: PGP signature
Re: IANA 6to4 assignment status
On Mon, 02 Aug 2021 11:57:54 +0200, Lars Prehn said: > Is there a reason why the status of 2002::/16 in IANA's IPv6 unicast > assignments list [1] is ALLOCATED (with '6to4' as designation and the > note field indicating reservation) rather than RESERVED? It can probably be moved back to 'reserved' once we're *sure* that 6to4 has finally been stamped out, never to return. But I'm sure that *some* ISP or company out there is still using it as their main strategy for migrating to IPv6. pgpPfDbwFPtBE.pgp Description: PGP signature
Re: Can somebody explain these ransomwear attacks?
On Thu, 24 Jun 2021 14:55:12 -0700, JoeSox said: > It gets tricky when 'your' company will lose money $$$ while you wait a > month to restore from your cloud backups. If that's a concern, you've *already* totally screwed the pooch regarding DR planning. pgphow4jPrnvf.pgp Description: PGP signature
Re: aggregation tool that allows a bit of fuzz to aggregating ?
On Sun, 13 Jun 2021 14:47:01 -0800, "babydr DBA James W. Laferriere" said: > But now I am seeing a new trick fro some entities that are transmitting > from every other ipv4 address such as (*) below . And the trust (& crusty) > ol'tool just doesn't allow for a bitt of fuzz in its aggregation filter . > > Hoping someone knows of such a tool and or may have patched the > aggregate tool to accopmlish such a task . > > (*) > ... > 63.81.88.116/32 > 63.81.88.118/32 > 63.81.88.120/32 > 63.81.88.122/32 > 63.81.88.124/32 > 63.81.88.126/32 Not exactly a fix, but it may relieve the pain until you get one: cat inputs | sed -e '/^63.81.88/s/32$/31/' | aggregate If you need a bigger hammer, sed -e 's/32$/31/' is your friend. :)
Re: New minimum speed for US broadband connections
On Tue, 01 Jun 2021 10:10:17 -, scott said: > $10400 / $125 = 84 months or 7 years. > On the high side: 14 years. Plus ongoing monthly costs that drags out the break-even. The big question is how to get a CFO to buy into stuff with a long break-even schedule when short-term profits get emphasized. Telcos strung a lot of copper when they were assured of multiple decades of returns - and even *then* getting it out to rural areas required providing more incentive pgpWLMQJZrFE0.pgp Description: PGP signature
Re: New minimum speed for US broadband connections
On Sun, 30 May 2021 15:56:52 -0500, Blake Dunlap said: > The co op electric serving my families house in bfe tn that doesn't have > either sewer or cable managed to run hard fiber for dirt cheap to all their > subscribers. Its clear from that the problem isnt can't, it's won't. Are you able to share any numbers about costs per mile and/or subscriber? I'm sure a lot of people are curious how the co-op was able to run fiber to places that none of the usual suspects wanted to run coax to. (Of course, it probably helped that a co-op only has to care about eventually breaking even or at least not losing *too* much money, rather than making a profit in the relatively short term) pgpXe2_y2MUMj.pgp Description: PGP signature
Re: OT: Re: Younger generations preferring social media(esque) interactions.
On Thu, 25 Mar 2021 12:51:28 -0400, "Allen McKinley Kitchen (gmail)" said: > how I am called on by younger peers and can remember things that the kids > havenât had time to learn. > > Now that last one has no real network application .. but it makes me feel > good. Oh, there are *tons* of stuff that you can remember that the kids haven't learned yet. We just had a long thread about famous operational issues, and I'm willing to bet that *none* of those ever got mentioned wherever the kids went to school... pgpyMyDrr85q8.pgp Description: PGP signature
Re: 10 years from now... (was: internet futures)
On Fri, 26 Mar 2021 12:42:20 -0700, Michael Thomas said: > dishwasher will probably be common, but that's hardly exciting. LEO > internet providers will be coming online which might make a difference > in the corners of the world where it's hard to get access, but will it > allow internet access to parachute in behind the Great Firewall? At which point, we get to see two very different types of LEO engage in mortal combat pgpa0yUCiLvX5.pgp Description: PGP signature
Re: OT: Re: Younger generations preferring social media(esque) interactions.
On Tue, 23 Mar 2021 17:34:37 -0600, Grant Taylor via NANOG said: > On 3/23/21 4:16 PM, Michael Thomas wrote: > > But they still have the originating domain's From: address. > > My opinion is that messages from the mailing list should not have the > originating domain in the From: address. The message from the mailing > list should be from the mailing list's domain. And if you do that, what's your preferred way of rearranging the RFC822 headers to denote who the mail was originally from? (Hint: this is something that RFC compliant MUAs must be able to figure out, and get it correct). pgp9jcM6wUcrJ.pgp Description: PGP signature
Re: Perhaps it's time to think about enhancements to the NANOG list...?
On Tue, 23 Mar 2021 15:39:49 -, Emil Pfeffer said: > The generational gap is not an issue it is how things need to be. The network > engineering the younger generation deals with is not the same networking the > old > generation deals with but built upon this old networks. This two generations > do > not need the same knowledge and it is in each others best interest that they > stay > separated. The problem comes when the younger generation *does* need access to the same knowledge - and the older generation is unreachable and/or actually gone. pgprryT5lI_mT.pgp Description: PGP signature
Re: Peering and Caching for Epic Games, Fortnite, et al
On Mon, 22 Mar 2021 20:13:46 -0600, Jose Luis Rodriguez said: > experience when downloading the neverending > Fortnite/Spacequest/Blizzard/DigDug updates that run down our pipes. Would > know who they are ) and would really like to link to the source even if it > means trenching through the core of the Earth... How many trenches to various points are you willing to dig? (And I don't think you've even mentioned some of the *large* games out there now, with 100G+ releases...) pgpFBG7iEZU4p.pgp Description: PGP signature
Re: Perhaps it's time to think about enhancements to the NANOG list...?
On Sat, 20 Mar 2021 14:13:04 +0100, Niels Bakker said: > * r...@gsp.org (Rich Kulawiec) [Sat 20 Mar 2021, 14:03 CET]: > >2. This is a low-traffic list, so even without appropriate mail client > >support it's really not a big deal. > > The volume isn't the point, the S:N ratio is. Mails like this thread's > starter are off-topic and reduce the value of the list to its > subscribers. Your reasoning is easy, common and fallacious. Unfortunately, the *rest* of the thread did more damage to Friday's S:N ratio than the original post did. And adding "topic" tags to the subject line doesn't actually help the food-fight scenario, as those can break out even in [TOPIC] tagged threads. To tilt it the rest of the way from sub-optimal to outright pessimal is the fact that some subscribers may find a thread has gone off into the weeds, while others consider all the details interesting. So having a kill-thread command in the MUA is the most realistic place to deal with "this user doesn't want to hear from this thread again". pgpDPtpSfiqta.pgp Description: PGP signature
Re: Famous operational issues
On Tue, 23 Feb 2021 20:46:38 -0800, Randy Bush said: > maybe late '60s or so, we had a few 2314 dasd monsters[0]. think maybe > 4m x 2m with 9 drives with removable disk packs. > > a grave shift operator gets errors on a drive and wonders if maybe they > swap it into another spindle. no luck, so swapped those two drives with > two others. one more iteration, and they had wiped out the entire > array. at that point they called me; so i missed the really creative > part. I suspect every S/360 site that had 2314's had an operator who did that, as I was witness to the same thing. For at least a decade after that debacle, the Manager of Operations was awarding Gold, Silver, and Bronze Danny awards for operational screw-ups. (The 2314 event was the sole Platinum Danny :) And yes, IBM 4341 consoles were all too easy to hit the EPO button on the keyboard, we got guards for the consoles after one of our operators nailed the button a second time in a month. And to tie the S/360 and 4341 together - we were one of the last sites that was still running an S/360 Mod 65J. And plans came through for a new server room on the top floor of a new building. Architect comes through, measures the S/360 and all the peripherals for floorspace and power/cooling - and the CPU, plus *4* meg of memory, and 3 strings of 2314 drives chewed a lot of both. Construction starts. Meanwhile, IBM announces the 4341, and offers us a real sweetheart deal because even at the high maintenance charges we were paying, IBM was losing money. Something insane like the system and peripherals and first 3 years of maintenance, for less than the old system per-year maintenance. Oh, and the power requirements are like 10% of the 360s. So we take delivery of the new system and it's looking pitiful, just one box and 2 small strings of disk in 10K square feet. Lots of empty space. Do all the migrations to the new system over the summer, and life is good. Until fall and winter arrive, and we discover there is zero heat in the room, and the ceiling is uninsulated, and it's below zero outside because this is way upstate NY. And if there was a 360 in the room, it would *still* be needing cooling rather than heating. But it's a 4341 that's shedding only 10% of the heat... Finally, one February morning, the 4341 throws a thermal check. Air was too cold at the intakes. Our IBM CE did a double-take because he'd been doing IBM mainframes for 3 decades and had never seen a thermal check for too cold before. Lots of legal action threatened against the architect, who simply said "If you had *told* me that the system was being replaced, I'd have put heat in the room". A settlement was reached, revised plans were drawn up, there was a whole mess of construction to get ductwork and insulation and other stuff into place, and life was good for the decade or so before I left for a better gig
Re: DoD IP Space
On Mon, 15 Feb 2021 10:51:51 -0800, Sabri Berisha said: > Well, considering this RIPE article that talked about IPv7 already.. > > https://lists.ripe.net/pipermail/ripe-org-closed/1993/msg00024.html Bonus points for those who remember/know where v5 and v8 were from :) pgpdrYkPJgCF0.pgp Description: PGP signature
Re: DoD IP Space
On Sun, 14 Feb 2021 22:25:56 -0800, William Herrin said: > This particular problem could be quickly resolved if the OSes still > getting updates were updated to default name resolution to prioritize > the IPv4 addresses instead. That would allow broken IPv6 > configurations to exist without breaking the user's entire Internet > experience. Which would allow them to leave it turned on so that it > resumes working when the error is eventually found and fixed. Oh, come on Bill. This ain't your first rodeo. You know damned well that if we do that, the errors are in fact *not* eventually found and fixed. In addition, if you do that, even once the error is fixed, the box will not know about that and will continue to use the IPv4 addresses.
Re: DoD IP Space
On Wed, 10 Feb 2021 04:04:43 -0800, Owen DeLong said: > Please explain to me how you uniquely number 40M endpoints with RFC-1918 > without running out of > addresses and without creating partitioned networks. OK.. I'll bite. What network design needs 40M endpoints and can't tolerate partitioned networks? There's eyeball networks out there that have that many endpoints, but they end up partitioned behind multiple NAT boxes. pgp05Fm5NZrWe.pgp Description: PGP signature
Re: DoD IP Space
On Fri, 05 Feb 2021 17:25:34 -0800, Doug Barton said: > I am genuinely curious, how would you explain the problem, and describe > a solution, to an almost exclusively non-technical audience who just > wants to get the bits flowing again? "The people who did Disney's software wrote it for the Internet protocols of last century, so it fails with this century's Internet. Adding insult to injury, the reason you even notice a problem is because it reacts badly to the failure, because it doesn't even include *last* century's well-known methods of error recovery". pgphNxdmn5BHj.pgp Description: PGP signature
Re: DoD IP Space
On Thu, 21 Jan 2021 11:07:42 -0800, Sabri Berisha said: > Financial incentives also work. Perhaps we can convince Mr. Biden to give a > .5% > tax cut to corporations that fully implement v6. That will create some bonus > targets. And how would you define "fully implement v6", anyhow? Case in point: I helped deploy v6 at my employer *last century*, and the entire network was (last I knew) totally v6 ready, and large segments were v6-only. Yet Google *still* says that only 80% or so traffic to them are via v6. The other 20% being end-user devices that aren't using v6 for one reason or another - I'm pretty sure that a lot of those are because companies have told the user to "turn off ipv6" to solve connection problems, and I know that a lot of them are gaming consoles from a vendor that had a brief shining chance to Get It Right on the last iteration(*) but failed to do so And when I retired, I had several clusters of file servers that weren't doing IPv6 because a certain 3-letter vendor who *really* should have been more on the ball didn't have v6 support in the relevant software. Even more problematic: What do you do with a company that's fully v6-ready, but still has several major interconnects to other companies that *aren't* ready, and thus still using v4? (*) The PS4 has ipv6 support in the OS - it will dhcpv6 and answer pings from on and off subnet. However, they didn't include ipv6 support in the development software toolkit, so nothing actually uses it. They appear to have fixed this in the PS5, but that still hits the "other company isn't ready" issue. pgpciOB0nPGnp.pgp Description: PGP signature
Re: Parler
On Wed, 13 Jan 2021 18:41:55 -0500, Matt Corallo said: > In case anyone thought Amazon was being particularly *careful* around their > enforcement of Parler's ban...this is from > today on parler's new host: > > $ dig parler.com ns > ... > parler.com. 300 IN NS ns4.epik.com. > parler.com. 300 IN NS ns3.epik.com. > ... > ns3.epik.com. 108450 IN A 52.55.168.70 It's quite possible that Amazon is playing this *entirely* by the book, and the Parler crew haven't violated the terms of the nameserver hosting agreement so Amazon hasn't cut that off. pgp0i8q7FGMwX.pgp Description: PGP signature
Re: Parler
On Sun, 10 Jan 2021 18:08:24 -0500, Izaac said: > demonstrated consistently different behavior between them, i.e. the > @potus account is used for official communications and @realdonaldtrump > for personal communications with the public. The former is indeed How does that square with the White House Press Secretary's statement (never walked back as far as I know) that @realdonaldtrump tweets were official government policy statements? pgp8E_1wQ3U1l.pgp Description: PGP signature
Re: WhatsApp's New Policy Has...
On Fri, 08 Jan 2021 14:10:41 -0600, Richard Porter said: > I missed that... *he says as he deletes Keybase* Hopefully not before you told your Keybase contacts where you were going. :) pgpytCcsAjPkH.pgp Description: PGP signature
Re: Show NOCs: OIG report: Should you charge extra for NOC tours?
On Thu, 07 Jan 2021 23:35:06 +, "Jay R. Ashworth" said: > > From: "Brandon Svec" > > It is not really different than most other tourist attractions. Some are > > amazed > > and curious to see the largest ball of twine > Those would be people who *don't* do this for a living, mostly... > > and some think it is > > ridiculous. > Those would be people who *do* this for a living, mostly. I could go "meh" about a NOC tour itself. On the other hand, I can think of a number of providers where buying the right person a beer would be significantly enlightening. :) pgpRMmw8ZUOqE.pgp Description: PGP signature
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Tue, 05 Jan 2021 15:48:47 -0500, b...@theworld.com said: > How much faster? If it took one minute of battery life off a 10 year > battery would that be a problem? 30 minutes? I suspect the proper time units are closer to months rather than minutes. > How much power would a bit of circuitry waiting for a "turn on! there's a new > message coming in!" need? You also need a much larger bit of circuitry for frequency decoders, speakers and all the rest of it, and *most* of it has to be on all the time in order to detect that there's a new message coming in. It's going to cost a lot more energy-wise to monitor a frequency continuously than what's monitored inside a smoke alarm. Can you point at NOAA weather alert radio that has a 10 year battery in it? Because you're going to need pretty much the same circuitry if you're trying to cram all this into a smoke alarm. pgp4QSi8_Vy9H.pgp Description: PGP signature
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Mon, 04 Jan 2021 15:33:10 -0500, b...@theworld.com said: > Why wouldn't we just build this into 10-year battery smoke alarms, a > simple radio receiver? First, that means your smoke alarm batteries run down faster, which is a major issue. I didn't bother thinking past that show-stopper, others can do so if they wish... pgp3oaogdfVKJ.pgp Description: PGP signature
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Sun, 03 Jan 2021 18:00:22 -0700, "Keith Medcalf" said: > This is the same thing I tell shithead politicians and pollsters that cause > my phone to ring. If you wish to speak with me then you can pay to install > your own communications equipment at your own expense. Um... Keith? Pretty much all of them *do* pay for their end of the communications equipment. The bigger question is why you pay for *your* end rather than insisting that everybody who wants to talk to you pay for your end. (Hint: Do you require that the annoying sister in law you don't want to hear from also install gear at their expense? Does the answer change if you usually want to hear from her but not today because reasons?) pgpArJK3hSV4B.pgp Description: PGP signature
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Sun, 03 Jan 2021 09:26:07 +, Mark Foster said:' > Yeah my family got a PS4 for Christmas. But we've had an Xbox One for > the last few years. There are quite a few streaming apps, true. But a > lot fewer of those than worldwide telcos, or jurisdictions, or emergency > services. You missed the point - Hulu would *still* have to deal with every single jurisdiction or emergency service in a secure manner. But any given ISP doing business in a given county would only have to deal with a very small number - and the local sheriff's office would only have to notify the small number of providers actually providing access in the county. > So do you want the streaming service to deliver the alert, or do you > want the underlying device doing the streaming, to deliver the alert? > Because I think you've gone down a layer and didn't need to. How do you deliver the alert if the device is on but no streaming service is currently active? And for a lot of devices, that's the usual state of affairs. As far as I know, most people who have a Google or Alexa smart device have it on close to 24/7, but the devices aren't streaming media that much. That's why I think doing it at the streaming service level is one level too high. pgpdmSdJuOZe6.pgp Description: PGP signature
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Sun, 03 Jan 2021 18:59:37 +1300, Mark Foster said: > In my mind it's simple.� The streaming companies need to have a channel > within their streaming system to get a message to a 'currently active > customer' (emergency popup notification that appears when their app is > open or their website is active with an authenticated user).� The Oh geez. Just on my PS4, there's streaming apps for Disney+, Netflix, Hulu, Prime, Playstation Store, Peacock, Tubi, ESPN+, AppleTV, YouTube (less than half of which I actually subscribe to, but I haven't found a big enough crowbar to remove the others, they keep returning) - and that's probably not a complete list. And we get to watch them all do it in subtly different ways, often buggy. Egads. Bonus points for figuring out how to keep two streaming apps from stepping on each other's toes, as often these apps stay semi-alive in the background, which may be enough to cause an alert to be sent to the app. Now you need to avoid a "thundering herd" problem if there's 18 different streaming apps on the device, all of which just got woken up. On resource constrained systems, that's often the start of a death spiral as the system either runs totally out of memory or goes into thrashing mode. And the alternative is just saying "only the streaming app in the foreground gets to handle the alert", but that isn't correct either - I might not *have* a streaming app running in the foreground on the device at the time the alert goes out. (You hit another problem as well - now all the apps have to notify upstream So having every single "streaming" app have to include duplicate code and *still* not get the alert to the user doesn't seem the right direction to go... > streaming company will also know the location of their customer (billing > information) so will know what geographic locations are relevant to that > customer. Billing info may be good enough for stuff that stays at home. It doesn't tell you what zip code a portable device is actually in at the moment - and getting the *right* localized info to the portable device is one of the tricky parts of this. If you're out and about town while visiting your in-laws 3 time zones away from where you live, you want alerts for the town your in-laws live, not for the address the streaming company sends the bill to. And that's assuming that a streaming company even *has* the info in their billing information - I just checked, and Hulu doesn't have a street address for me. So they're going to end up having to do IP based geolocation. Meanwhile, this causes yet another problem - if Hulu has to be able to know what alerts should be piped down to my device, this now means that every single police and public safety agency has to be able to send the alerts to Hulu (and every other streaming company) - and do this securely. That's a *lot* bigger problem than "The Blacksburg VA police department only has to set up agreements with network access providers that might be providing access to devices in Blacksburg". Seriously guys - having the streaming companies do this is at the entirely wrong level. pgppzHA8EUtxt.pgp Description: PGP signature
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Fri, 01 Jan 2021 17:12:40 -0500, Matt Hoppes said: > How would that even work? Force a pop up into web traffic? That's not going to play nicely at all in a world of https:// > What if the end users is using an app on a phone? I'm having a hard time thinking of what app I could *possibly* be using on a phone where I wouldn't want an interruption for a tornado or active shooter alert. This was discussed in detail a while ago - I'm pretty sure the general consensus was that having the phone/game console/smart home control center/ whatever would be running an alert endpoint app that would talk to the ISP/ cellphone tower and register for alerts and then DTRT to notify the relevant carbon-based life forms. pgp5Q3cYZst40.pgp Description: PGP signature
Re: 10g residential CPE
On Mon, 28 Dec 2020 20:02:36 +, Mel Beckman said: > This means your staffing must be large enough to never have any queuing, or > youâre giving away your paying customers' time to non-paying customers. > Neither > approach is scalable in a competitive business environment, because SOMEBODY > is > paying for all those resources, and if itâs your customers, they will buy > elsewhere. Your approach only work until you run out of other peopleâs > money. I dunno. He's been doing it for 7 years, it sounds like it's sustainable in his environment. pgpihFY6TOwD8.pgp Description: PGP signature
Re: [External] Re: 10g residential CPE
On Sun, 27 Dec 2020 17:57:17 +0100, Baldur Norddahl said: > Here in the civilised world we bury the wires ;-) Even the long-haul 765kv and up connections across the power grid? In the US, they're out on towers for a reason - you can fly along them in a helicopter and easily spot parts of cable that are degrading and need repair because they glow brighter on an infrared scope... (Plus, as Hurricane Sandy taught Manhattan, buried wires have their own rather nasty failure modes) pgpaNvJePUX6d.pgp Description: PGP signature
Re: [External] Re: 10g residential CPE
On Sat, 26 Dec 2020 12:58:42 -0800, Michael Thomas said: > can go on for days. We have a generator because of this, but everybody > getting a generator in the middle of the Berkeley Hills would be > something of its own horror show, but it will probably come down to that. Egads. Especially if a lot of those generators are just bought at Home Depot and hooked up to the house wiring without a proper cutover switch for the mains. pgp3KpLpZtF4M.pgp Description: PGP signature
Re: 10g residential CPE
On Sat, 26 Dec 2020 17:50:28 +, Mel Beckman said: > If vendors saw a 10GbE CPE market, they would serve it. Obviously they donât > see a market. Why donât people insisting vendors build their hobby horse see > that? Itâs like theyâre being deliberately obtuse :) The number of people that want a router that does 10GbE is vastly outnumbered by the number of people that want a router that makes their Zoom sessions not suck. Admittedly, many of them don't realize they want that router, mostly because most of them don't realize it's not difficult at all to build one that does that. But that's why companies have an advertising and marketing team. :) pgpveTfXzA_oP.pgp Description: PGP signature
Re: 10g residential CPE
On Sat, 26 Dec 2020 00:32:49 -0500, b...@theworld.com said: > I suppose that depends a lot on what the actual prices of a flat-rate > 1gb vs a fully saturated 10gb. If it's $50 vs $100/mo perhaps some > would say ok I'll risk the $50 overage, if it's $50 vs $500/mo maybe > not. > > And today we have bandwidth-shaping in most any router/cpe (or could) > so even with the 10gb/metered someone in the house with the password > could rate-limit except when they needed it :-) Note that the vast majority of users either use the ISP-provided CPE, or something they picked up at Walmart or Best Buy. This leads to an interesting economic incentive problem. The ISP is obviously not motivated to supply kit that can do bandwidth shaping on a metered drop. Meanwhile, the providers of gear that gets sold at Walmart or Best Buy also have no motivation to add it until enough ISPs are providing metered high-speed service that "We can help prevent overage charges" becomes a viable market differentiation. Anybody got a feel for what percent of the third-party gear currently sold to consumers has sane bufferbloat support in 2020, when we've *known* that de-bufferbloated gear is a viable differentiatior if marketed right (consider the percent of families that have at least one gamer who cares)? pgpy2ZpJwQdKA.pgp Description: PGP signature
Re: The Real AI Threat?
On Thu, 10 Dec 2020 18:56:04 -0500, Max Harmony via NANOG said: > Programs have never done what you *want* them to do, only what you = > *tell* them to do. Amen to that - there was the time many moons ago when we launched a copy of a vendor's network monitoring system, and told it to auto-discover the network. It found all the on-campus subnets and most of the machines, and didnt seem to be doing anything else, so we all headed home. Come in the next morning, and discover that our 56k leased line to Nysernet (yes, *that* many moons ago) was clogged with the monitoring system trying to do SNMP probes against a significant fraction of the Internet in the Northeast. Things apparently went particularly pear-shaped when it discovered the MIT/Boston routing swamp... And of course, we *told* it "discover the network", when we *meant* "discover the network in this one /16.". Fortunately, it didn't support "discover the network and perform security scans on machines" - but I'm sure there's at least one security-scanning package out there that makes this same whoopsie all too easy to do, 3+ decades later... pgpCSjE5gzAPG.pgp Description: PGP signature
Re: AFRINIC IP Block Thefts -- The Saga Continues
On Tue, 17 Nov 2020 10:02:01 -0800, Jay Hennigan said: > In the old days on the NANAE newsgroup, such bogus threats of legal > action were categorized as one calling their "cartooney". People who > huff and puff and threaten to sue rarely do so. If someone actually > plans on suing you, your first hint is typically a knock on the door by > a process server, not repeated threats in an online forum. Right. The thing is that unless you're party to the lawsuit, you don't know if a process server has been involved. Somebody else replied by private email and pointed where the AfriNIC CEO wrote that they had, in fact, actually been sued. So whatever one might think of Elad Cohen, he's apparently not a cartooney. pgp43XmPOfBgS.pgp Description: PGP signature
Re: AFRINIC IP Block Thefts -- The Saga Continues
On Mon, 16 Nov 2020 09:22:33 +, Elad Cohen said: > Did I start legal proceedings with AfriNIC with conspiracy theories or with > facts and data? OK.. I'll probably end up regretting this, but... Is there any actual independently verifiable proof that legal proceeding have been started? pgpJDMI8IoFKd.pgp Description: PGP signature
Re: Telia Not Withdrawing v6 Routes
On Mon, 16 Nov 2020 17:36:58 -0800, Sabri Berisha said: > Also, in the case that I described it wasn't a Junos device. Makes me wonder > how bugs > like that get introduced. One would expect that after 20+ years of writing > BGP code, > handling a withdrawl would be easy-peasy. Handling a withdrawal is easy. Handling one correctly without race conditions when you're seeing withdrawals and additions from multiple bgp sessions concurrently, while also maintaining RIB and FIB consistency and keep forwarding customer packets is a little bit harder. pgpc7WPYbqNGy.pgp Description: PGP signature
Re: Virginia voter registration down due to cable cut
On Tue, 13 Oct 2020 17:11:53 -0400, Christopher Morrow said: > sorry I meant that: 1) yes clearly it's still the middle of > roadwork/backhoe season, 2) i'm surprised that a single path failure > for their production datacenter was enough to take the system offline. > 'spof' there meant: "Wow, a single point of failure in their outside > plant?" Given that back in 2010, they suffered a *disastrous* outage when a storage array failed and took multiple agencies with it https://www.computerworld.com/article/2515423/northrop-grumman-takes-blame-for-va--it-services-outage.html my reaction was more like Surprise, surprise, surprise... That one started when one storage array had a failed memory card, and the backup array encountered issues as well. There were a number of state agencies and universities that had fought for increased self-governance, and a *huge* part of that was "not be forced to outsource their internal IT to VITA", and those units were very glad they had won that fight pgpXflcrjyFc3.pgp Description: PGP signature
Re: Florida: Voter registration website overwhelmed at deadline
On Wed, 07 Oct 2020 22:10:07 -0700, "Constantine A. Murenin" said: > People act like 1.1 million requests per hour is a huge number. > > That's only 305 requests per second! > > Cheapest NVMe SSDs are capable of 160k+ IOPS. > > You can literally serve the whole thing from a single server on a > 100Mbps line, if you design it properly, and don't waste bandwidth on > stock images and silly front-ends. It isn't the stock images and silly front-ends that take all the effort. Those are pretty damned easy to serve up quickly. It's the twisty little maze of databases, all different. You asked for a driver's license number for ID? Well, that just bought you a call to the DMV's servers to check on the validity/status of that ID. Vetting the home address gets equally interesting, especially if it's a PO box or a "suite" at a mailbox-for-rent company. Vetting the existence of the last employer is going to take time as well. Are you going to get the unemployment system, the tax system, the DMV systems, and any others you need to talk to on this "one server"? Oh, and don't forget that the systems in the DMV and tax systems almost certainly have *other* systems they have to talk to Don't forget that these state agencies usually don't have the budget that Amazon or other large commercial organizations have, so you're looking at a *really* high chance that some server in the Department of Revenue isn't sized big/fast enough, so verifying the employer's existence hangs, so the front end hangs On top of all that, even if you're only a *little* bit too slow clearing requests, you end up sitting on a big pile of pending requests, which sucks up memory.. Get 305 requests per second, clear 304 per second, and in a few minutes you're throwing '502 Gateway Error' left right and center because things are wedged up pgpEpdF5UALvs.pgp Description: PGP signature
Re: Gaming Consoles and IPv4
On Sun, 27 Sep 2020 21:33:56 -0400, Daniel Sterling said: > It is true that I've yet to see any FPS game use ipv6. I assume that's cuz > they can't count on users having v6, so they have to support v4, and it > wouldn't be worth their while to have their gaming host support dual-stack. > just a guess there The Playstation 4's OS actually does support IPV6. I've been told that the big hold-up is that the kits sent to developers had libraries that didn't include the IPv6 sockets support, so no getaddrinfo() and friends, so developers couldn't code the support. Does anybody have info from Microsoft or Sony on what their new consoles are doing regarding IPv6? My informant has moved on and is out of the loop regarding the PS5's software innards. pgpKAXZMl3F4M.pgp Description: PGP signature
Re: SRv6
On Thu, 17 Sep 2020 18:24:36 +0200, Mark Tinka said: > On 17/Sep/20 17:56, mark seery wrote: > > Perhaps all the more reason why end-to-end encryption should be part of the > > buyer beware conversation (not arguing against operator encryption in saying > > that - privacy is something everyone in I[C]T has to think about today). > > If gubbermints mandate that l2vpn's and l3vpn's be encrypted, the cloud > bags will simply take over (not that they haven't, already). Are there any actual countries heading that way? Seems like most of them insist they have the ability to snoop unencrypted traffic (where "crypto that has a baked-in back door" counts as unencrypted). pgpwzdXuegf5e.pgp Description: PGP signature
Re: Ipv6 help
On Wed, 26 Aug 2020 18:42:14 +0200, JORDI PALET MARTINEZ via NANOG said: > The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6 . Has anybody heard if they plan to fix that with the imminent Playstation 5? The PS4 OS will actually talk IPV6 far enough to DHCPv6 and answer pings from both on and off subnet, but none of the userspace does it because that API wasn't in the developer's kits at launch. pgp4TBzYh_Kka.pgp Description: PGP signature
Re: Has virtualization become obsolete in 5G?
On Fri, 07 Aug 2020 07:29:49 +0200, Mark Tinka said: > On 6/Aug/20 21:05, Christopher Morrow wrote: > > Isn't this just, really: > > 1) some network gear with SDN bits that live on the next-rack over > > servers/kubes > > 2) services (microservices!) that do the SDN functions AND NFV > > functions AND billing > > (extending IMS to the edge etc) > > I can already see how we are going to spend the next 10 years defining > this :-)... With research consultant reports tagging along every step of the way. :) pgplTTAoPAFMx.pgp Description: PGP signature
Re: questions asked during network engineer interview
On Thu, 23 Jul 2020 10:03:15 +0100, adamv0...@netconsultings.com said: > Hopefully well end up in a world where all checks one can do to figure out > why iBGP session is down along with suggested corrective actions will be coded > in some network self-healing workflow. /me places bets this concept re-surfaces as SDNv3. :) pgp6JQjIlh7Sz.pgp Description: PGP signature
Re: questions asked during network engineer interview
On Tue, 21 Jul 2020 23:04:30 +0200, Robert Raszuk said: > attempt to open innovation into networking ... allowing one to invent > protocols at will as well as setup forwarding tables with arbitrary All of which either get layered onto port 443 or you have to wait for your CGNAT vendor to provide an ALG for it. :) (I'll just note that I've seen almost no overlap between the SDN crew, and things like Google deciding to create and deploy QUIC. :) pgpXD_TFQuvU8.pgp Description: PGP signature
Re: L2VPN/L2transport, Cumulus Linux & hardware suggestion
(re-adding Adam's text that didn't get quoted, but matters) On Wed, 08 Jul 2020 13:49:56 +0300, Saku Ytti said: > On Wed, 8 Jul 2020 at 13:46, Radu-Adrian Feurdean > wrote: > On Wed, Jul 8, 2020, at 00:09, Adam Thompson wrote: > > > Good luck with tunnelling LACP, no matter what boxes you have - LACP > > > has (de facto) hard jitter requirements of under 1msec, or you'll be > > > getting TCP resets coming out your ears due to mis-ordered packets. > > Errr sorry, but at the latest news, TCP was supposed to handle out of > > order packets and reorder them before sending them to upper layer. > Yes, however new reno and the like are tuned for practical Internet. > Practical Internet has lot more packet loss than reordering, so TCP > algorithm considers any amount of reordering a packet loss, causing an > immediate resend, destroying your performance. There's a difference between a TCP *resend*, and a *RESET*. Triggering a resend on a re-order is reasonably sane, sending an RST isn't pgpP8nAK8OtkD.pgp Description: PGP signature
Re: netflix proxy/unblocker false detection
On Fri, 26 Jun 2020 10:21:47 +0200, Mark Tinka said: > Sadly, PlayStation still don't support IPv6. Hopefully, it comes with > the PS5, although I see no reason why the PS4 and PS3 can't. The PS/4 will in fact dhcpv6 at startup, and it will answer pings from both on subnet and from elsewhere, and will properly hand you an RST when there's nobody listening on a TCP port, and a port unreachable for a UDP port. So it's very much a "lights are on but nobody's home" because nothing is using an IPv6 port. One big reason that PS4 doesn't use IPv6 is that although the OS supports it, the developer toolkit doesn't have that API in it, so no games or apps can use it without an incredible amount of pain and suffering. It wouldn't help games that want to talk to Playstation Network until Sony got *that* part working, but if the API was there at least things like the Netflix and Hulu and similar apps could use it pgpEx0LLWYFUs.pgp Description: PGP signature
Re: Contact at Ubiquiti Networks?
On Tue, 26 May 2020 21:53:55 +0200, Baldur Norddahl said: > Even the big guys like Juniper fail at basic functionality. Our brand new > MX204 fails to select the correct source address when doing ARP requests > and apparently that is a known will not fix. 1987 called and wants their bug back. Seriously, how does something *that* basic even make it out of the lab? pgpeYw74EwHOC.pgp Description: PGP signature
Re: Friday Reminder: Web Site Security
On Fri, 15 May 2020 12:15:13 -0700, "Ronald F. Guilmette" said: > This is your helpful Friday reminder to always pay close attention to > the security settings of all of the web sites under your administration. > Otherwise, anonymous skript kiddiez could show up at any moment and > deface one or more of your web sites. (It happens a lot.) Just this week, I have seen an (unconfirmed) report that there is an organized effort that's abusing SSH keys that lack passphrases - if they pwn a system and find one, they go surfing it as far as they can. And yes, I know that automated systems can't use passphrases.. so remember to check to see if you can use 'force-command=' in the known hosts file so that the key can only issue one command. (yes, this means that if the automation host has to do a dozen different things, it needs a dozen keypairs. Security is always tradeoffs.) 'ssh-keygen -H' also helps control things. pgpyxj1nakDYo.pgp Description: PGP signature
Re: RIPE NCC Executive Board election
On Wed, 13 May 2020 17:17:07 -, David Hubbard said: > LOL the IPv4+ thing was a pretty entertaining read. You clearly donât have > even a basic understanding of the v4 packet structure, or that the octet > display concept is simply for human benefit. IPv6 can be implemented with > âsoftware updatesâ too⦠Yes, it was quite the chuckle, approaching the IPv8 proposal and that guy who kept insisting that an octet was misnumbered and could represent 257 addresses... > From: NANOG on behalf of Elad Cohen > > Date: Wednesday, May 13, 2020 at 9:47 AM > To: "Ronald F. Guilmette" , "nanog@nanog.org" > > Subject: Re: RIPE NCC Executive Board election > > Hello Everyone, > My apology for not providing an official response to the first "The Ronald > Show" that took place here many months ago, I was out of hospital after full > anesthesia and it took me months to get back to myself. I'm pretty sure Elad should have used this next part for backing up his assertion that he was totally out of it during April. Because he's doing a really good job here of demonstrating that he doesn't understand how the Internet works well enough to qualify for a seat on the RIPE board: > When in reality I invented three new pantets for the best of the whole > Internet community and I will work to implement them if I will be elected: > > IPv4+ that will mitigate the "IPv4 Exhaustion" problem and will add more (...) > https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html > > Completely mitigating the global email spam problem in a clean and automatic > way: (...) > https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778.html > > Completely mitigating spoofed ip amplification DDoS attacks and spoofed ip > (...) > https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003902.html > pgpNIVEs4cFUw.pgp Description: PGP signature
Re: RIPE NCC Executive Board election
On Wed, 13 May 2020 17:00:14 -0400, Jon Lewis said: > When you've convinced Cisco, Juniper, Arista, and a few other router > vendors to implement, and have submitted patches for the Linux kernel and > userspace to implement IPv4+ (good luck with all that...and expect to be > met with "Can we have some of what you've been smoking?"), then you can > start pushing your next gen IP concepts. Until then, it's a total > non-starter. At least when Dave Taht was pushing his "make the class E space usable", he had patches and testing for multiple systems. Turns out that not many systems check for 'first octet >= 240', but actually test for the class D space and using class E Just Works an amazing percent of the time (Yes, I was surprised myself, but deploying it is still very much in the "effort better spent deploying IPv6" territory...) pgpjih5Xpru8u.pgp Description: PGP signature
Re: An appeal for more bandwidth to the Internet Archive
On Wed, 13 May 2020 10:40:36 +0300, Denys Fedoryshchenko said: > What about introducing some cache offloading, like CDN doing? (Google, > Facebook, Netflix, Akamai, etc) > I think it can be rolled pretty quickly, with minimum labor efforts, at > least for heavy content. The thing is that if you're an 800 pound gorilla, you probably have enough things that would benefit from being cached to make it worthwhile. I'd expect that the Internet Archive is probably mostly long-tail hits with not much hot content. Has anybody modeled how much cache space would it take to significantly improve the bandwidth situation? pgp5Z4mdcbFov.pgp Description: PGP signature
Re: Abuse Desks
On Wed, 29 Apr 2020 11:25:19 -0400, sro...@ronan-online.com said: > Perhaps some organization of Network Operators should come up with an > objective standard of what constitutes âabuseâ and a standard format for > reporting it. > If only there was such an organization. A different organization beat you to it. 7203 An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information. T. Takahashi, K. Landfield, Y. Kadobayashi. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7203) pgp2n9812g8Kx.pgp Description: PGP signature
Re: 24x7 vs 24x7x365 Re: Constant Abuse Reports / Borderline Spamming from RiskIQ
On Wed, 15 Apr 2020 22:06:52 -0700, Ben Cannon said: > I call our NOC â24x7x365â I hear that in my head as âtwenty-four > (hour) - BY > - Seven (days a week) - BY - 365 (days a year, indicating we donât close on > any holidays). x365 is fine, to distinguish from 24x7x360 operations that are running on autopilot on Thanksgiving, Christmas and New Year and such pgpcxn5E2m3PW.pgp Description: PGP signature
Re: The Cost of Paid Peering with Chinese ISPs
On Wed, 01 Apr 2020 20:58:17 -0700, Matt Corallo said: > If your goal is to force companies the world over to host domestically, where > they follow local licensing regimes (yes, including censorship, as well as > data > access), itâs highly effective. You missed the point. There's a distinction between "setting up conducive conditions" and "doing". Both may be morally problematic, but they're different things. Consider the US example of certain US companies who got caught giving the NSA a fiber connection at certain "interesting" points in the network - the legal exposure for the companies and for the intelligence agency were totally different. It's why our legal system recognizes the difference between committing a felony and being an accessory to the crime. We have *enough* trouble with people yelling "Censorship!" when Facebook or Quora or other social media sites owned by private actors enforce AUPs. Let's not let the word get further muddied into uselessness like "terrorism" has been over the last 2 decades. pgpynlcaNt4UE.pgp Description: PGP signature
Re: The Cost of Paid Peering with Chinese ISPs
On Wed, 01 Apr 2020 12:47:22 -0700, Matt Corallo said: > No one suggested it isnât censorship, youâre bating here. Not deploying > enough international capacity is absolutely a form or censorship deployed to > great avail - if international sites load too slow, you can skimp on GF > appliances! So.. who was being "censored" when a recent game release caused capacity problems and slow throughput for others? Censorship, *by definition*, is content-dependent. Capacity issues are either byte-count or packet-count dependent, and don't distinguish between pictures of huge rubber duckies in Tiananmen square, and pictures of Mount Kilimanjaro. pgpbQqu0qreQ8.pgp Description: PGP signature
Re: Sunday traffic curiosity
On Sun, 22 Mar 2020 13:17:59 -0600, Grant Taylor via NANOG said: > As someone who 1) wasn't around during the last Internet scale foray > into multicast and 2) working with multicast in a closed environment, > I'm curios: > > What was wrong with Internet scale multicast? Why did it get abandoned? It failed to scale for some of the exact same reasons QoS failed to scale - what works inside one administrative domain doesn't work once it crosses domain boundaries. Plus, there's a lot more state to keep - if you think spanning tree gets ugly if the tree gets too big, think about what happens when the multicast covers 3,000 people in 117 ASN's, with people from multiple ASN's joining and leaving every few seconds. pgpAD8OWKMaNy.pgp Description: PGP signature
Re: COVID-19 vs. our Networks
On Tue, 17 Mar 2020 11:43:45 -0600, "Keith Medcalf" said: > And before you ask, I get "important news" directly. I'm glad to hear you're someplace on the planet where covid-19 doesn't count as important news. Hopefully the news will arrive to you directly before the virus does. pgp1W4vwcfEXk.pgp Description: PGP signature
Re: COVID-19 vs. our Networks
On Thu, 12 Mar 2020 18:08:05 -0600, "Keith Medcalf" said: > I don't know but we just issued travel restrictions to the United States > as it is now a Hot Spot for the unrestricted spread of the coronavirus > which causes COVID-19. Hopefully they're more sensible restrictions than the US policy that prohibits travel from most of Europe except the UK... but only for foreigners. If you're a US citizen, you're still perfectly welcome to go to Italy and come home with a few extra microbes to pass around a week after you return. The word for anybody who designs a network firewall with that sort of logic is "pwned". Just sayin'. (Fortunately, I'm in a position to hide in my apartment and only emerge for grocery shopping at 2AM until things wind down... Hope everybody else has a good contingency plan) pgpbbsURAhaU5.pgp Description: PGP signature
Re: Chairman Pai Proposes Mandating STIR/SHAKEN To Combat Robocalls
On Sun, 08 Mar 2020 17:17:37 -0400, b...@theworld.com said: > Which primarily leaves the question of why this Kabuki theater by the > FCC et al pretending as if it's some vast, uncontrollable evil like > the corona virus etc.? Because even in today's climate of regulatory capture posing as proper oversight, there's a limit to just how blatant they can be in public before people start saying "Geez, get a room already". pgpkPplNyHswx.pgp Description: PGP signature
Re: China’s Slow Transnational Network
On Sun, 01 Mar 2020 21:00:05 -0800, Pengxiong Zhu said: > There are a few things noteworthy regarding the phenomenon. First of all, > all traffic types are treated equally, HTTP(S), VPN, etc., which means it > is discriminating or differentiating any specific kinds of traffic. This sentence is missing a 'not'. However, I can't tell if it's "not treated equally" or "not discriminating" pgpfNu52qo1O3.pgp Description: PGP signature
Re: ATT Microcell in Austin, TX
On Sun, 16 Feb 2020 16:57:24 -0600, Chris Boyd said: > Since people on here like to talk about the generatorn run time on cell > towers, I thought yâall might like to see an ATT microcell in downtown > Austin, > TX. No apparent generator or battery on it. > https://imgur.com/a/RY9Tg7h Looks to me like a mostly shared-fate design with the traffic signal it appears to be attached to. All depends on what ATT risk management thinks in that situation. They may have decided that sticking a 10-minute battery in the base of that thing is good enough. pgp_HwJXDraJJ.pgp Description: PGP signature
Re: akamai yesterday - what in the world was that
On Thu, 13 Feb 2020 09:39:09 -0800, Ahmed Borno said: > The thread started with bandwidth surges and now power hogging is > mentioned, I wonder what else might happen as a side effect to a small > number of console/gaming companies not taking a direct responsibility in > how they release large updates in a way that is not organized or scheduled > but is rough and abrupt. And I'd not expect it to improve - many of the game producers are leaving the "incremental patch" mode to a "just ship the current image of the whole damned thing", because for them it's cheaper to just push out a single updated image than try to build different images for upgrading from different current levels. After all - it's not like *they* are going to feel the pain of a single 106G upload, it's somebody else who feels the pain of 5 million downloads of a 106G image refresh. Economists call this sort of thing an "externality". pgp2UX7WmfpRk.pgp Description: PGP signature
Re: Prominent horse racing identities (was Re: Elad Cohen)
On Mon, 27 Jan 2020 07:10:02 +, Large Hadron Collider said: > As much as Mr Cohen's minor libel of Spamhaus and ARIN exposes him as perhaps > having something to hide on this subject, Mr Guilmette's message here, among > the other screeds of his I have read, seems to leak anti-Semitism from its > every fetid, infected pore. Man, that must be one really high-frqequency dog whistle, because I'm not seeing it. The closest I can come is the statement that "Cohen sits in impunity in Israel", which combined the next part about him having a US based lawyer, only indicated to me that getting the US legal system to get the Israel legal system to do something is difficult. And tagging on "every fetid, infected pore" certainly demonstrates that you don't have any real intention of being fair-minded. List management: I think we have a good candidate for somebody to be frog-marched to the exit. pgp31rD4Xy46l.pgp Description: PGP signature
Re: akamai yesterday - what in the world was that
On Fri, 24 Jan 2020 08:55:12 -0600, "Aaron Gould" said: > Thanks Jared, When I reminisce with my boss he reminds me that this telco/ISP > here initially started with a 56kbps internet uplink , lol I remember when a "gateway" was a Microvax II with an ethernet card and a bisync card, and fuzzballs were the big thing, and the other end of your connection was either Arpanet or Milnet, and RFCs specified octects for a reason pgp52sAiFUVQr.pgp Description: PGP signature
Re: akamai yesterday - what in the world was that
On Thu, 23 Jan 2020 17:13:15 +0100, Bryan Holloway said: > Game releases are hardly a new thing, but these last two events seem to > be almost an order of magnitude higher than what we're used to (at least > on our predominantly eyeball network.) > > Any thoughts from the community? We're taking steps to accommodate, but > from a capacity-planning perspective, this seems non-linear to me. Be prepared for an entire new world of hurt this holiday season. Sony has already confirmed that PS5 releases will ship on 100Gbyte blu-ray disks. Which means that download sizes will be comparable... pgpnh34uf9O1n.pgp Description: PGP signature
Re: FCC proposes $10 Million fine for spoofed robocalls
On Fri, 20 Dec 2019 00:14:33 -0800, Large Hadron Collider said: > Is it legally a spoofed robo-call if I robo-call someone who has > consented to be robo-called, with the caller-ID of a number that is > affiliated with me but not with the telco I'm calling from? Every 8 weeks, the vampires at the American Red Cross call me to schedule another blood donation, and I'm sure that the number on my caller-ID isn't the actual phone number attached to the specific seat at the call center. And I'm pretty sure that until I answer the call, there's no really good way to distinguish between a robo-call with a recorded message and a robo-dialed call with an actual carbon-based lifeform at the call center on the call... (If I'm wrong on that one, feel free to enlighten me.. :) pgpgLCWaxCcdR.pgp Description: PGP signature
Re: FCC proposes $10 Million fine for spoofed robocalls
On Thu, 19 Dec 2019 16:02:42 -0700, "Keith Medcalf" said: > That stupid people do stupid things has no bearing on me. If there is a > legal requirement for these people to be "notifying" then they are required to > notify. > I do not want to receive robocalls period. End of Line. No Exception. > Ever. For any reason. So... what do you recommend if it's a legally mandated robocall that says "shelter in place - active shooter" or "tornado alert"? pgpyacpY95WDK.pgp Description: PGP signature
Re: FCC proposes $10 Million fine for spoofed robocalls
On Thu, 19 Dec 2019 13:59:00 -0800, Jeff Shultz said: > I've occasionally thought that a tactical air strike on a couple of > call centers might just convince the others of the errors of their > ways. Having a US-owned A10 strafe a Philippines-based call center is probably a bad idea diplomatically. However, we're in an administration that doesn't avoid ideas simply because they're objectively bad, so I'm not going to predict it won't happen pgpdPBgN_GOd7.pgp Description: PGP signature
Re: Software Defined Networks
On Thu, 12 Dec 2019 18:47:29 -0800, Large Hadron Collider said: > Tcl still exists, though I don't think they use it for this anymore. At least on Fedora, expect 5.45.4 is linked against libtcl8.6.so. pgpW5_X20d9ag.pgp Description: PGP signature
Re: Short-circuited traceroutes on FIOS
On Wed, 11 Dec 2019 19:26:09 +0200, Saku Ytti said: > On Wed, 11 Dec 2019 at 19:14, Rob Foehl wrote: > > > Support claims that it was a mistake, but it's also been 15+ months and > > it's pretty deliberate behavior. Draw your own conclusions... > > TTL decrement issues are fairly common across multiple vendors and hw, > can be sw can be hw limit Yes, but you need to screw up gloriously on the decrement if you think that "I decremented and it's zero now" means "therefor it must have been addressed to me, so I'll send an ECHO REPLY instead of TTL EXCEEDED". pgpmaeuPEyxyP.pgp Description: PGP signature
Re: Elephant in the room - Akamai
On Thu, 05 Dec 2019 14:18:07 -0800, Michael Thomas said: > My suspicion is that the root problem was buffer bloat -- i flashed a > new router with openwrt and was a little dismayed that the bufferbloat > code is a plugin you have to enable. The buffer bloat got a lot better Friends don't let friends run factory firmware. :) Hopefully sometime soon the SQM stuff will be added to the default openwrt configs for most of the supported routers, if it hasn't been already. It's been in my config since before the Luci support for SQM got created The big problem is that a lot of eyeball networks have a lot of CPE boxes that were created before the bufferbloat work was done, and often have no real motivation to push software updates to the CPE (if they even have the ability), and a lot of customers have routers that they bought at Best Buy or Walmart that will *never* get a software update. (I also admit having no idea what percentage of the intermediate routers in the ISP's networks have gotten de-bloating code. pgpipUcFxDede.pgp Description: PGP signature
Re: Elephant in the room - Akamai
On Thu, 05 Dec 2019 14:41:30 -0600, "Aaron Gould" said: > Tarko. wow, gaming again ! It's not going away. gaming traffic is growing > in a big way it seems. And it's only going to get worse. Sony has already announced that the Playstation 5 will have a (probably) 1-2 terabyte SSD. And even with that, the game packaging is set up to support only downloading the single-player or multi-player portions of a game because images are going to be pushing 100 gigabytes RSN (some are already well over 40gig). So even with the download restructuring, we're probably going to be seeing a lot of people downloading lots of gigabytes on Day 1 (or a few days before, for games that support it), and re-downloading smaller (but still large) amounts when they want to re-play the game... pgpZd9dnF7KSd.pgp Description: PGP signature
Re: Software Defined Networks
On Wed, 04 Dec 2019 17:56:10 +, Rod Beck said: > Can someone explain what is all the fuss? SDN is like the latest telecom > craze but the articles do a poor job of explaining the advantages. I seek > concrete examples. It's called the "cycle of reincarnation". Way back when, a "router" was a Microvax-II with 2 network cards in it, and everything, down to the packet checksums, was done in software on the Microvax CPU. Then we got "routers" that did a lot of the stuff like checksumming in hardware. Then we went back to software for more advanced features, then the hardware got smart enough to do it. For a while, routers were doing IPv4 support in hardware, and the occasional IPv6 packet got tossed towards the CPU. (That was, of course, once they got smart enough to do something other than "compare first 4 bits == "0100", drop on not-equal". I think a few boxes didn't even check the first 4 bits and assumed that all packets started that way, and hilarity and hijinks ensued Lather, rinse, repeat multiple times over the past 4 decades. And now we're seeing "SDN" which just means "Now that the hardware is smarter and doing a lot of the stuff we used to do in software, the CPU has more free capacity and we can do new clever stuff in software that we couldn't do before". It's *NOT TRULY* a software-defined network. If it was, there wouldn't be any hardware support for checksumming etc, because the checksum to use would be done in software so it could be easily replaced if you had reason to use a different checksum algorithm. (Hint - it's as big a crock as "Software Defined Storage" - which just means that it's software doing things like the RAID, erasure encoding, and logical volumes rather than physical volumes, even though the logical volumes are usually really just RAID-0 concatenations of segments of physical volumes. Meanwhile, "software defined radio" really means "the physical hardware is flexible, and software is used to configure it in case you didn't want the standard channel frequencies in the 2.4 and 5ghz bands". pgpeythyrzz_W.pgp Description: PGP signature
Re: RIPE our of IPv4
On Tue, 03 Dec 2019 14:58:59 -0800, FREDERICK BAKER said: > I think he is saying that companies like Reliance JIO have started with a /22 > of IPv4 and a /32 (or more) of IPv6, As I said - you need IPv4 space to dual-stack. How does Reliance do this without any v4 address space? pgpZzt54PJqbb.pgp Description: PGP signature
Re: RIPE our of IPv4
On Wed, 04 Dec 2019 07:47:25 +1100, Mark Andrews said: > Why not use someone elseâs IPv4 addresses? Really. What is wrong with > using > someone elseâs IPv4 addresses if it achieves the need? As far as I can tell > nothing. Other than the fact that a /24 is being advertised out of one AS and it's part of some other AS's /14 and looks suspiciously like a hijack? And we currently don't deal well with identifying and preventing true hijacks and mess up false positives a lot of the time? pgpUBGTodN9bJ.pgp Description: PGP signature
Re: RIPE our of IPv4
On Tue, 03 Dec 2019 14:12:27 +1100, Mark Andrews said: > Email is often out sourced so you donât need your own IPv4 addresses for > that. > Then there is in the cloud for other services, again you donât need your > own IPv4 > addresses. Are you seriously trying to say "If you're a new company, there's no plausible reason for you to need your own IPv4 addresses, because there's no reason for you to have your own mail servers or web servers"? Because if it *were* true that people don't need v4 addresses so they can dual-stack, we wouldn't have a healthy market buying and selling v4 address space. pgpI6UkYlltNv.pgp Description: PGP signature
Re: RIPE our of IPv4
On Mon, 02 Dec 2019 11:04:24 -0800, Fred Baker said: > > I believe that Dmitry's point is that we will still require IPv4 addresses > > for new > > organizations deploying dual-stack > > I think I understood what you meant, but not what you said. > If someone is dual stack, they are IPv6-capable and IPv4-capable. And they're going to need v4 addresses to be v4-capable, aren't there? A new corporation that's trying to spin up dual-stack is going to need 2 address allocations, a v4 and a v6. pgpcySEVj1r_i.pgp Description: PGP signature
Re: RIPE our of IPv4
On Sat, 30 Nov 2019 13:47:36 -0800, Matthew Kaufman said: > User apps prefer IPv6, Netflix stops, users complain And fallback to IPv4 fails to happen, why, exactly? pgphoWWsRXmVA.pgp Description: PGP signature
Re: RIPE our of IPv4
On Fri, 29 Nov 2019 23:26:04 -0500, Brandon Martin said: > definitely the lagging factor, here. I suspect it's at least partially > because high-ratio NAT44 has been the norm for enterprise deployments > for some time, and, among those who might otherwise be willing to > support first-class dual stack, many enterprise IT folks lack the > education to recognize the nuance between public addressing and > unfiltered public reachability of a given host. I suspect many of them > are already using IPv6 for LAN traffic without even realizing it given > Windows' penchant for doing so since Vista. Judging how long it took to (mostly) stamp out CLASSA/B/C nonsense, we're in for at least a decade of IPv6 firewalls that block all ICMP, plus whatever common IPv6 misconfigurations and misconceptions are out there (I was deploying this stuff literally last century, so I admit not knowing what people are screwing up currently). pgpwdX4RrpNns.pgp Description: PGP signature
Re: replaying captured traffic
On Tue, 26 Nov 2019 13:29:21 -0500, harbor235 said: > I am with you on the easy google fu, however, weeding through the > challenges and a real implementation I was hoping to leverage some > lessons learned and best practices. Well, it's going to depend a *lot* on why exactly you're doing the replay. Doing a replay for forensics, doing a replay for protocol/application correctness testing, and doing a replay for throughput test load generation are 3 very different things. pgpiXTcucXOFV.pgp Description: PGP signature
Re: RIPE our of IPv4
On Tue, 26 Nov 2019 06:46:52 +1100, Mark Andrews said: > > On 26 Nov 2019, at 03:53, Dmitry Sherman wrote: > > > >  I believe itâs Eyeball networkâs matter to free IPv4 blocks and > > move to v6. > It requires both sides to move to IPv6. Why should the cost of maintaining > working networks be borne alone by the eyeball networks? That is what is > mostly happening today with CGN. I believe that Dmitry's point is that we will still require IPv4 addresses for new organizations deploying dual-stack, and eyeball networks can more easily move a /16 or even bigger to mostly IPv6 and a small CGNAT address space than content providers can free up IPv4 addresses during the time that dual stack is still needed. pgpJWJYbH090t.pgp Description: PGP signature
Re: Hulu thinks all my IP addresses are "business class", how to reach them?
On Tue, 19 Nov 2019 13:39:56 -0500, Tom Beecher said: > They are essentially equating 'business' with 'VPN provider'. Not at all surprised. Many moons ago, I had a Tor *relay* running on one machine in my home network, and Hulu decided that my connections from a *different* home machine were "VPN". Now, if I were running a Tor *exit* node, I'd be totally OK with them rejecting my non-Tor connections because they were NATed to the same outside IP address - but Hulu should never have seen any packets from the relay and if I *was* using a VPN I'd have a *different* IP address. Near as I could determine, they were screen scraping the list of Tor relays and conflating them with exit nodes. Never did figure out if it was stupidity or malice driving that. pgpzxIsEJcPBX.pgp Description: PGP signature
Re: Disney+ Streaming
On Tue, 12 Nov 2019 14:58:34 -0500, "Brian J. Murrell" said: > I guess the question is, will Disney content compel users who are not > already streaming to start streaming? I can foresee a lot of families subscribing to Netflix *and* Disney+ because neither one has all the content the family wants to watch. Has anybody seen a significant drop in total streaming traffic due to Netflix users jumping ship to Amazon/Hulu, or are consumers just biting the bullet, coughing up the $$, and streaming more total because across the services there's more stuff they want to watch? pgpswtN64dt8I.pgp Description: PGP signature
Re: all major US carriers received text messages overnight that appear to have been sent around Valentine's Day 2019
On Fri, 08 Nov 2019 11:23:17 -0800, Jared Geiger said: > What likely happened is that messages were queued on host to go out, SMPP > binds go down, queue fills up, host crashes. Then someone realizes the host > is down and brings it back up and the queue empties when the load is low. What I've seen happen more often than that: Server goes partly belly-up, queue fills up. Backup process runs, backing up the queue. (Optionally here: Reboot the server and lose the queue). Much later, the server hits another issue that requires recovering from backups - and they restore a truly ancient copy. I recently got a replay of a bunch of email messages from 2002. I admit not at all understanding what procedure failures (multiple) resulted in reloading a mail spool from 2002. pgpksv4F8soAg.pgp Description: PGP signature
Re: Russian government’s disconnection test
On Sat, 02 Nov 2019 14:49:58 -0400, Christopher Morrow said: > I think the disconnect idea is actually a good one... I don't know > that I want to DO IT, but :) it certainly seems like a reasonable > disaster recovery planning exercise :) (likely doing it is the only > way to really suss out the problems though) Some of us remember disconnecting the uplink when the Morris Worm first started wandering around, and then wondering how we were going to get news of the details so we could patch our boxen so it would be safe to reconnect the cable to the router As more systems moved to secure update distribution schemes with only allowing vendor-signed patches from https:// secured trusted sites, we may find ourselves in a similar "don't dare be only, but have to be to fix the problem" mess if a worm gets loose... (Yes, you can probably ACL the router. Not the sort of thing you want to be doing at oh-dark-thirty if you don't know what ACL is safe to use and you are cut off from a lot of info sources...) pgpVSEII1louV.pgp Description: PGP signature
Re: Request comment: list of IPs to block outbound
On Wed, 23 Oct 2019 09:09:05 -0600, Grant Taylor via NANOG said: > > Easing the operation of CGN at scale serves no purpose except stalling > > necessary change. It is like installing an electric blanket to cure the > > chill from bed-wetting. > > Much like humans can move passenter plains, even an electric blanket can > /eventually/ overcome cold wet bed. Unless somebody gets electrocuted first. pgp_uLaDlmrzf.pgp Description: PGP signature
Re: IP Geolocation
On Wed, 16 Oct 2019 12:50:17 -, Ryland Kremeier said: > >I believe we have found 1 customer that is infected with a botnet or malware. > I've dealt with plenty of botnets working as a repair technician in the past > but never had one change the public IP address of the user. Not entirely sure > what this would accomplish aside from making it much easier to detect. To detect that somebody isn't doing BCP38 filtering of their customers, you mean? :) pgpUmsKQcLcHE.pgp Description: PGP signature
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
On Fri, 11 Oct 2019 12:02:30 +0200, Warren Kumari said: > I haven't found the actual work that is being referenced here, and I > *am* quite skeptical based upon the title / premise -- but, I suspect > (well, hope) that this is just another instance of complex technical > material being munged by marketing / reporters into something > unrecognizable -- note that "This article was originally published by > the UMass News Office." > > Here is an abstract of one of Yang Song, Arun Venkataramani, Lixin > Gao's earlier papers: > "BGP is known to have many security vulnerabilities due to the very > nature of its underlying assumptions of trust among independently > operated networks. () I'm fighting *really* hard to try to avoid collapsing that abstract down to "We realized that malicious actors can force the occurrence of BGP wedgies". (I've seen far too many proposals in the last 48 hours from people who obviously never encountered section (4) of RFC1925...) pgph3KkPdSta2.pgp Description: PGP signature
Re: worse than IPv6 Pain Experiment
On Wed, 09 Oct 2019 17:43:00 -0400, b...@theworld.com said: > URLs are an obvious candidate to consider because they're in use, seem > to basically work to identify routing endpoints, and are far from a > random, out of thin air, choice. So explain in detail how a router gets from "URL" to "which interface to send the packet on". Include in your discussion how anycast works, and how to deal with things like www.google.com, which currently uses DNS and geolocation so not every host on the internet has the same view of what server(s) to contact. Problem example: My employer moved something from a 128.173/16 address to a 198.82/16 address without changing the name. How would your scheme address the fact that the routing may have changed, when the URL/hostname remains the same? Hint: If URLS or hostnames actually identified routing endpoints, we'd not have DNS. pgpDSR49wNpe0.pgp Description: PGP signature
