Re: who runs the root, Cogent-TATA peering dispute?
On Fri, May 17, 2024 at 6:53 PM John R. Levine wrote: > On Fri, 17 May 2024, William Herrin wrote: > > That said, ICANN generates the root zone including the servers > > declared authoritative for the zone. > > Nope. Verisign maintains them under contract to ICANN and NTIA and under direction from ICANN. If ICANN told Verisign to make a change they really didn't want to make, Verisign has just enough wiggle room to delay until the NTIA rep can weigh in. Generally, though, ICANN administers, Verisign implements and NTIA funds the effort. > > So they do have an ability to > > say: nope, you've crossed the line to any of the root operators. > > ICANN as the IANA Functions Operator maintains the database of TLD info. > They provide this to Verisign, the Root Zone Maintainer, who create the > root zone and distribute it to the root server operators. Verisign does > this under a contract with NTIA, one of the few bits of the Internet that > is still under a US government contract: > > https://www.ntia.gov/page/verisign-cooperative-agreement This contract is also a part of the story: https://www.icann.org/iana_imp_docs/129-root-zone-maintainer-service-agreement-v-28sep16 Absent interdiction from NTIA it gives ICANN the authority to direct Verisign to do exactly what I said. And Cogent disconnecting the C servers from a sizable part of the Internet is almost certainly sufficient excuse to do it on an "emergency" basis without soliciting comment. > Should ICANN attempt to mess with the distribution of the root zone, let > us just say that the results would not be pretty. Fair. Whether they could, politically, make it stick is a whole other can of worms. > I'm not guessing here, I go to ICANN meetings and talk to these people. And you've been around since the early days too, but the documents don't always match the talk. The talk reflects intentions. Intentions change faster than contracts when something puts pressure on the system. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Cogent-TATA peering dispute?
On Fri, May 17, 2024 at 4:28 PM John Levine wrote: > It appears that William Herrin said: > >I don't understand why Cogent is allowed to operate one of the root > >servers. Doesn't ICANN do any kind of technical background check on > >companies when letting the contract? > > There is no contract for running root servers > and never has been. I stand corrected. https://www.netnod.se/dns/dns-root-server-faq Some of them have MoU's with ICANN (a contract with loosely defined requirements) but apparently not all and it wasn't at ICANN's discretion. That said, ICANN generates the root zone including the servers declared authoritative for the zone. So they do have an ability to say: nope, you've crossed the line to any of the root operators. So Cogent operates a root server because they bought PSI who ran a root server and ICANN has never chosen to throw down the gauntlet. Which is a fair answer to why they're allowed to operate one of the roots. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Cogent-TATA peering dispute?
On Fri, May 17, 2024 at 9:55 AM Ben Cartwright-Cox via NANOG wrote: > Also poking around on RIPE Atlas suggests that for a non-zero amount > of networks in India the C DNS Root Server that cogent runs is > inaccessible: https://atlas.ripe.net/measurements/71894623#probes I don't understand why Cogent is allowed to operate one of the root servers. Doesn't ICANN do any kind of technical background check on companies when letting the contract? For those who haven't been around long enough, this isn't Cogent's first depeering argument. Nor their second. And they're behaving unreasonably. I don't know any of the details -this time- but historically speaking Cogent is behaving badly -again- and you can take that to the bank. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Mailing list SPF Failure
On Thu, May 16, 2024 at 12:03 PM John Levine wrote: > It appears that Michael Thomas said: > >Since probably 99% of the mail from NANOG is through this list, it > >hardly matters since SPF will always fail. > > Sorry, but no. A mailing list puts its own envelope return address on > the message so with a reasonable SPF record, SPF will normally > succeed. Exactly. SPF acts on the -envelope- sender. That means the one presented in the SMTP From:<> command. For mail from nanog, that's: nanog-bounces+addr...@nanog.org, regardless of what the sender's header From address is. The message content (including the message headers) is theoretically not used for SPF validation. In practice, some SPF validators don't have direct access to the SMTP session so they rely on the SMTP session placing the envelope sender in the Return-path header. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Q: is RFC3531 still applicable?
On Wed, May 15, 2024 at 10:09 PM Mel Beckman wrote: > The RFC seems to be concerned with aggregation efficiency, and while that may > be a concern someday, so far computer and memory capacity has far outstripped > prefix growth in the default-free zone. > > If you can explain why a /64 would ever not be enough for a single subnet, > I’m willing to listen. The subnet contains a router that gateways to another /64. For example, there's a home automation controller and the controller implements its own lan of components on a different media type. Instead of assigning a pair of /64's, you assign a /63 and then route a /64 from the /63 to the home automation controller. Except you don't do that either. IPv6 is plentiful and reverse-DNS delegates cleanly on 4-bit boundaries so you think in terms of 4-bit boundaries instead: assign a /60, use a /64 on the immediate LAN and route a /64 to the home automation controller and retain the balance for the next device that wants to implement an internal subnet. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Q: is RFC3531 still applicable?
On Wed, May 15, 2024 at 10:20 AM Randy Bush wrote: > > The minimum addressable on a LAN is a /64. > > not really The minimum (and maximum) subnet mask for a LAN in which -all- of IPv6's technologies work right is /64. If you don't require stateless autoconfiguration or automatic link-local addresses, you can pick any subnet mask you want. In most cases it's desirable to have a size of /64. In a few cases it's not. Short version: use /64 as your IPv6 LAN subnet mask unless you clearly understand the consequences of not doing so and intentionally want them. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Q: is RFC3531 still applicable?
On Tue, May 14, 2024 at 1:12 PM Mel Beckman wrote: > I never could understand the motivation behind RFC3531. Just assign /64s. Say you have a point of presence (pop) where you serve customers, allowing each a /56. You assign a /48 to the pop and route the /48 to the pop rather than routing each /56 individually. Later on you get more than 256 customers. RFC3531 says you should assign the /48 in such a way that more often than not you can expand it to /44 without renumbering instead of assigning another /56 and consuming another slot in your routing table. The motivation is saving that slot in your routing table while also avoiding renumbering the subnets already assigned there. If you're the customer with the /56, RFC3531 doesn't make much sense. Your routing table cost is nil and it's desirable to preserve as large a block in the /56 as possible as long as possible so that you don't have to ask for more, something the ISP may or may not grant your class of service. And of course RFC3531 presumes a hierarchy in your network which is not necessarily true. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Help with removing DNS shinkhole FP from Charter/Spectrum
On Mon, Apr 22, 2024 at 5:54 PM Validin Axon wrote: > Hi Bill, > > I'm not sure where you saw that message, but I got this > message via email after I submitted an unblock request with Spectrum Shield: Howdy, That was Christopher, not me. But you should check the talos link I sent you privately. Also https://ipcheck.proofpoint.com/. Whatever they're detecting, it didn't happen last year. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Help with removing DNS shinkhole FP from Charter/Spectrum
On Mon, Apr 22, 2024 at 5:07 PM John R. Levine wrote: > a complaint would have to show that the > blocking was malicious rather than merited or accidental. In this case it > seems probably accidental, but for all I know there might have been bad > traffic to merit a block. Hi John, I'll try not to belabor it, but accidental that isn't corrected upon formal legal notification becomes negligent and negligent has more or less the same legal status as malicious. The spammers lost because the networks published a terms of use document that the spammers unambiguously violated. Even though it interfered with the spammer's business, the block was merited so the preponderance of the evidence fell in favor of the service provider. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Help with removing DNS shinkhole FP from Charter/Spectrum
On Mon, Apr 22, 2024 at 4:00 PM John Levine wrote: > It appears that William Herrin said: > >If you can't reach a technical POC, use the legal one. Your lawyer can > The only response to a letter like that is "we run our network to > serve our customers and manage it the way we think is best" and you > know what, they're right. Hi John, Respectfully, you're mistaken. Look up "tortious interference." Operators have considerable legal leeway to block traffic for cause, or even by mistake if corrected upon notification, but a lawyer who blows off a cease-and-desist letter without investigating it with the tech staff has committed malpractice. The lawyer doesn't want to commit malpractice. You write the lawyer via certified mail, he's going to talk to the tech staff and you're going to get a response. At that point, you have an open communication pathway to get things fixed. Which was the problem to be solved. > Having said that, I suspect the least bad alternative if you can't > find an out of band contact is to get some of the Spectrum customers > who can't reach you to complain. They're customers, you aren't. My results going through the support front-door at large companies for oddball problems have been less than stellar. Has your experience truly been different? Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Help with removing DNS shinkhole FP from Charter/Spectrum
On Sun, Apr 21, 2024 at 6:21 PM Validin Axon wrote: > Looking for some help/advice. Spectrum is sinkholing my company's domain, > validin[.]com, to 127.0.0.54. Howdy, If you can't reach a technical POC, use the legal one. Your lawyer can find the appropriate recipient and write a cease-and-desist letter for you. After that, it's -their- lawyer's problem to track down the correct technical people. Incidentally, for folks who choose to interdict DNS: whatever your reasons, pointing the DNS to a loopback IP is bad practice. Really bad practice. Minimum good practice points it to a web site you control which provides enough information to get delisted. And provides you with a test point where you can collect information about what you've caused to be interdicted. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Whitebox Routers Beyond the Datasheet
On Fri, Apr 12, 2024 at 6:03 AM Mike Hammett wrote: > What I've kind of come down to (based on little more than spec sheets) > are the EdgeCore AGR400 and the UfiSpace S9600-30DX. > That's wonderful and all, but does it take it from 64k routes > to 512k routes, or does it take it from 256k routes up to > the millions of routes? Hi Mike, You're combining two questions here. Break them apart. How many distinct routes can its line-speed forwarding engine handle (the FIB) and what processing/DRAM is available to handle the routing database (RIB). To take the EdgeCore AGR400, it has an 8-core Xeon and 32 gigs of ram. It's going to handle a BGP RIB in the many millions of routes and a BGP convergence time as fast as anything else you can buy. For switching (FIB), it uses a Broadcom BCM88823. The data sheets on the broadcom 88800 series chips are suspiciously light on information about their internal capacity for forwarding decisions. Just a black box in the diagram described as an "external lookup engine" and some notes in the "packet processing" section that the ingress receive packet processor "handles the main packet processing stage" and "optionally" uses "expandable databases" from an external lookup interface. Large TCAMS are power hungry and the chip is physically small, so I'd bet against it having an DFZ-size embedded TCAM. Smells like a switch chip that typically has something in the single-digit thousands of slots but that's strictly a guess. And with only 8 cores, any software-switched "expandable databases" are going to be wimpy. I'm not familiar with the specific hardware you mentioned, so none of the above is certain. Just based on what I glean from the specs I could find via google and my experience with white-box routing in general. As a rule though, if the marketing materials don't call out a component of the product as impressive, it probably isn't. In general, white box routing is done with a framework like DPDK on machines with large numbers of CPU cores. While they can handle 100gbps, they do it by running the cores in single-thread busywait loops that eliminate the need for interrupts from the network devices. This generates lots of heat and consumes lots of electricity. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Without further comment:
On Sat, Mar 30, 2024 at 9:55 AM Mel Beckman wrote: > Well, Billie goes both ways :) Hi Mel, Billie is usually female while Billy is usually male. Same sound, different spelling. Regards, Bill (Billy in my youth) Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Without further comment:
On Sat, Mar 30, 2024 at 7:38 AM Josh Luthman wrote: > How do you know the poster's gender?? Howdy, As Josh is an uncommon female name, I'm going to play the odds and say that like Bill and I, you're male. Am I mistaken? Regards. Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: TFTP over anycast
On Tue, Feb 27, 2024 at 10:02 AM Javier Gutierrez wrote: > My design is very simplistic, I have 2 sets of firewalls that I > will have advertising a /32 unicast to the network at each > location and it will have a TFTP server behind each firewall. Hi Javier, That sounds straightforward to me with no major failure modes. I would make the firewall part of my OSPF network and then add the tftp servers to OSPF using FRR. Then I'd write a script to monitor the local tftp server and stop frr if it detects any problems with the tftp server. The local tftp server will always be closer than the remote one via OSPF link costs, unless it goes offline. I assume you also have an encrypted channel between the firewalls to handle traffic that stays "inside" your security boundary, as tftp generally should. Where you could get into trouble is if you add a third or additional sites. If there's ever an equal routing cost from any one site to two others, there's a non-zero risk of the failover process failing... and you won't know it until you need it. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: TFTP over anycast
On Fri, Feb 23, 2024 at 6:34 PM Ask Bjørn Hansen wrote: > The relay server `dhcplb` could, maybe, help in that scenario > (dhcplb runs on the anycast IP, the “real” DHCP servers on > unicast IPs behind dhcplb). Although they used the word "anycast", they're just load balancing. Devices behind a load balancer are not "anycast," since the load balancer explicitly decides which machine gets which transaction. Even with clever load balancers like Linux Virtual Server in "routing" mode where the back-end servers all share the virtual IP address, that's load balancing, not anycast routing. An IP is not "anycast" unless it moves via anycast routing. Anycast routing means it's announced into the _routing protocol_ from multiple sources on behalf of multiple distinct machines. In their readme, they comment that their load balancer replaced attempts to use anycast routing with equal cost multipath. That makes good sense. Relying on ECMP for anycasted DHCP would be a disaster during any sort of failure. Add or remove a single route from an ECMP set and the hashed path selection changes for most of the connections. All the DHCP renewals would very suddenly be going to the wrong DHCP server. Where anycast works, it works because ECMP only rarely comes into play. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: TFTP over anycast
On Thu, Feb 22, 2024 at 10:47 AM Javier Gutierrez wrote: > I was wondering if someone had some experience with using anycast for TFTP > or DHCP services? Hi Javier, Anycast for TFTP is more or less the same as anycast for TCP-based protocols: it has corner cases which fail and fail hard, but otherwise it works. Outside the corner cases, the failure mode for tftp clients should be the same as the failure mode when the tftp server goes down in the middle of a transfer and comes back up some time later. The corner cases are variations on the theme that your routing causes packets from a particular source to oscillate between the tftp servers. In the corner cases, the tftp client can't communicate with the -same- tftp server long enough to complete a transfer. Experiments with anycast TCP suggest that the corner cases happen for less than 1% of client sources, but when they do happen tend to be persistent, affecting all communication between that client and the anycast IP address for an extended duration, sometimes weeks or months. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: [External] Re: IPv6 uptake
On Mon, Feb 19, 2024 at 10:31 AM Tim Howe wrote: > On Mon, 19 Feb 2024 10:01:06 -0800 > William Herrin wrote: > > So when the user wants to run a home server, their IPv4 options are to > > create a TCP or UDP port forward for a single service port or perhaps > > create a generic port forward for every port to a single internal > > machine. Protocols other than TCP and UDP not supported. > > OK, but I'm not sure what you are getting at by saying this is > TCP and UDP exclusive... I don't know why it would be; what's the > example you think is typically being denied? Hi Tim, NATs don't generally process protocols like GRE, ESP (IPSEC), SCTP and most of the hundred fifty or so other protocols that sit atop IPv4. They don't have code that would make it possible to process those packets. They're generally TCP, UDP, and ICMP. Anything else is necessarily dropped. > The assumption being that a guardrail for someone being really > self-destructive is removed. In more sophisticated scenarios where subtler errors are possible, I described it as a "security layer" rather than a "guardrail." But yes: we're talking about the same thing. > I still believe that the statement "IPv6 is typically delivered > to "most people" without border security" to be demonstrably false. I concede the claim. I am satisfied with your evidence that I was in error. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: [External] Re: IPv6 uptake
On Mon, Feb 19, 2024 at 9:44 AM Tim Howe wrote: > FWIW, in the decade we have been providing dual-stack by default, I > have made a bit of a hobby out of testing every CPE and SOHO router > that I get may hands on in my PON lab. Hi Tim, I have not, so I'll defer to your experience. > I've never once seen a device > that has v6 support and didn't have a stateful v6 firewall on by > default (if v6 was "on"). Acknowledged. So when the user wants to run a home server, their IPv4 options are to create a TCP or UDP port forward for a single service port or perhaps create a generic port forward for every port to a single internal machine. Protocols other than TCP and UDP not supported. They might also have the option of a "bridge" mode in which only one internal host is usable and the IPv4 functions of the device are disabled. The bridge mode is the only "off" setting for the IPv4 firewall. Correct? Their IPv6 options *might* include these but also include the option to turn the IPv6 firewall off. At which point IPv4 is still firewalled but IPv6 is not and allows all L4 protocols, not just TCP and UDP. Also correct? Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: [External] Re: IPv6 uptake
On Mon, Feb 19, 2024 at 9:23 AM Hunter Fuller wrote: > On Mon, Feb 19, 2024 at 11:16 AM William Herrin wrote: > > > There isn't really an advantage to using v4 NAT. > > I disagree with that one. Limiting discussion to the original security > > context (rather than the wider world of how useful IPv6 is without > > IPv4), IPv6 is typically delivered to "most people" without border > > security, while IPv4 is delivered with a stateful NAT firewall. > > Maybe this is the disconnect. Who delivers v6 without a firewall? > > I've done a lot of T-Mobile and Comcast business connections lately, > and those certainly both provide a firewall on v4 and v6. I'll admit > I'm not currently well-versed in other providers (except ones that > don't provide v6 at all...). Hi Hunter, You may be right. I haven't ordered SOHO service in a long time and in fairness you were talking about Joe's Taco Shop not Joe's home network. I -suspect- that the wifi router provided for Joe's home network doesn't do much more than plain routing on the IPv6 side but I do not know that for a truth. I ordered my wave and comcast services without a router and I didn't keep the centurylink router long enough to test whether it did any filtering on IPv6. I noticed no knobs for IPv6 filtering or port forwarding, so I suspect it did not. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: [External] Re: IPv6 uptake
On Mon, Feb 19, 2024 at 9:00 AM Hunter Fuller wrote: > I guess the point I'm making is, the methods we are using today for v6 > dual WAN, work fine for most people. Hi Hunter, I accept that point. It's wobbly on some of the details, but you're talking "most" people, not everyone. > There isn't really an advantage to using v4 NAT. I disagree with that one. Limiting discussion to the original security context (rather than the wider world of how useful IPv6 is without IPv4), IPv6 is typically delivered to "most people" without border security, while IPv4 is delivered with a stateful NAT firewall. If ISPs got diligent about providing an IPv6 firewall to customers even though they don't need to do so for the customer to use more than one computer, there'd still be a security difference between internal hosts that are externally addressable (a stateful firewall without NAT) and internal hosts which are not. Security doesn't deal with "most people," it deals with people savvy enough to find and exploit the openings and errors in the software most people use. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: [External] Re: IPv6 uptake
On Mon, Feb 19, 2024 at 8:08 AM Hunter Fuller wrote: > On Mon, Feb 19, 2024 at 9:17 AM William Herrin wrote: > > There's also the double-ISP loss scenario that causes Joe to lose all > > global-scope IP addresses. He can overcome that by deploying ULA > > addresses (a third set of IPv6 addresses) on the internal hosts, but > > convincing the internal network protocols to stay on the ULA addresses > > is wonky too. > > In the real world today, most applications seem to use mDNS and > link-local addresses to keep this connectivity working. (I am guessing > Joe's Taco Shop uses something like Square, and just needs his > register to talk to his printer. This already works with mDNS and > link-locals today.) Hi Hunter, Yes and no. The client application has to be programmed to understand link-local addresses or it can't use them at all. You can't just say "connect to fe80::1." Even if there's an fe80::1 on your network, it doesn't work. The client app has to also carry the interface identity into the stack (e.g. fe80::1%eth0) in order to use it. IPv6 link local addresses can't be expressed as a regular DNS target the way ULA and RFC1918 addresses can. No way to add that "%eth0" to the record. They only work with multicast DNS because the matching interface is known based on which interface was used to send the multicast query. And of course link local is -strictly- link local. If you want one subnet to communicate with another, you have to do it with global scope or ULA addresses. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 uptake (was: The Reg does 240/4)
On Mon, Feb 19, 2024 at 6:02 AM Howard, Lee wrote: > Most NATs I've seen in the last 10-15 years are "full cone" NATs: they are > configured so that once there is an > outbound flow, and inbound datagram to that address+port will be forwarded to > the inside address, regardless > of source. Hi Lee, Yes, they do that to help with NAT traversal. This allows two hosts behind separate NATs to establish direct communication with the help of an external server in the establishment phase. The flip side is that your internal hosts are limited to 65k established connections between them or the firewall exhausts its available ports. Without full cone, the number of translations that NAT can do is bounded only by its available RAM. > NAPT just increases the size of the space to scan: just dump your crafted > packets to every address > + every port at your target. Not quite. Full cone slightly reduces NAT's positive security impact. But only slightly. An external source can poke at an internal host on the specific port where the internal host has established an outbound connection, but it can't poke the internal host on any other ports where services might actually be running and waiting for connections. > FWIW, the other enterprise IT security hole I often see: if your VPN is > IPv6-unaware, but your users have IPv6 > at home (like most in the U.S.), your VPN is now split-tunnel, regardless of > policy. You may think all your > packets are going through the VPN to be inspected by the corporate firewall, > but any web site with IPv6 > (about half) will use the local residential route, not the VPN. Yep. Folks who built their security for remote users around the idea of preventing split-tunnels have done the job so very wrong. Another fun thing you can do in Linux is run the VPN software inside a network namespace. The VPN happily takes over the namespace and any software you run inside the namespace, but the rest of the host remains on the public Internet. You can also run the VPN in a VM that shares mounts and clipboard with the host. Regards, Bill Herrin > > Lee > -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 uptake
On Mon, Feb 19, 2024 at 6:52 AM Mike Hammett wrote: > "We can seriously lose NAT for v6 and not lose > anything of worth." > > I'm not going to participate in the security conversation, but we > do absolutely need something to fill the role of NAT in v6. If it's > already there or not, I don't know. Use case: Joe's Taco Shop. > Joe doesn't want a down Internet connection to prevent > transactions from completing, so he purchases two diverse > broadband connections, say a cable connection and a DSL connection. Hi Mike, In IPv6's default operation, if Joe has two connections then each of his computers has two IPv6 addresses and two default routes. If one connection goes down, one of the routes and sets of IP addresses goes away. Network security for that scenario is, of course, challenging. There's a longer list of security-impacting things that can go wrong than with the IPv4 NAT + dual ISP scenario. There's also the double-ISP loss scenario that causes Joe to lose all global-scope IP addresses. He can overcome that by deploying ULA addresses (a third set of IPv6 addresses) on the internal hosts, but convincing the internal network protocols to stay on the ULA addresses is wonky too. There's also 1:1 NAT where Joe can just use ULA addresses internally and have the firewall translate into the address block of the active ISP. However, because this provides a full map between every internal address, protocol and port to external addresses and ports (the entire internal network is addressible from outside), it has no positive impact on security the way IPv4's address-overloaded NAT does. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 uptake (was: The Reg does 240/4)
On Mon, Feb 19, 2024 at 5:29 AM Howard, Lee via NANOG wrote: > In the U.S., the largest operators without IPv6 are (in order by size): > Lumen (CenturyLink) CenturyLink has IPv6 using 6rd. It works fine. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 uptake (was: The Reg does 240/4)
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. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 uptake (was: The Reg does 240/4)
On Sat, Feb 17, 2024 at 10:22 AM Justin Streiner wrote: > Getting back to the recently revised topic of this thread - IPv6 > uptake - what have peoples' experiences been related to > crafting sane v6 firewall rulesets in recent products from the > major firewall players (Palo Alto, Cisco, Fortinet, etc)? Hi Justin, It's been years since I used anything other than Linux to build someone a firewall. It has such a superior toolset, not just for setting rules but for diagnosing things that don't work as expected. The COTS products aren't just painful for IPv6, they're painful for IPv4. I especially despised the Cisco PIX/ASA line. I did use Fortinet's WAF product for a while and it was okay. I only used it as a reverse proxy to a web server, and then only because it was a security compliance requirement for that project. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 uptake (was: The Reg does 240/4)
On Sat, Feb 17, 2024 at 10:03 AM Michael Thomas wrote: > On 2/16/24 5:37 PM, William Herrin wrote: > > 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. Hi Mike, There's no "we" here, no one-size-fits-all answer. Some folks evaluating their scenario with their details will conclude that NAT's security benefit outweighs its performance and functionality implications. Others evaluating other scenarios will reach different answers. For enterprise customers, you're talking about folks who've been doing NAT for two decades and have more recently implemented HTTPS capture and re-encryption in order to scan for malware in transit. Will many of them insist on NAT and its security enhancement when they get around to deploying IPv6? Bet on it. So, what happens when you try to tell such folks that they don't need NAT for security in IPv6? It contradicts their -correct- intuition that NAT has a security benefit, but because they can't quite nail down what's wrong with your claim, it leaves them unsure. And what do people who are unsure about an IPv6 deployment do? Nothing! They put it back on the shelf and return to it in a couple of years. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 uptake (was: The Reg does 240/4)
On Fri, Feb 16, 2024 at 7:41 PM John R. Levine wrote: > > That it's possible to implement network security well without using > > NAT does not contradict the claim that NAT enhances network security. > > I think we're each overgeneralizing from our individual expeience. > > You can configure a V6 firewall to be default closed as easily as you can > configure a NAT. Hi John, We're probably not speaking the same language. You're talking about configuring the function of one layer in a security stack. I'm talking about adding or removing a layer in a security stack. Address overloaded NAT in conjunction with private internal addresses is an additional layer in a security stack. It has security-relevant properties that the other layers don't duplicate. Regardless of how you configure it. Also, you can't "configure" a layer to be default closed. That's a property of the security layer. It either is or it is not. You can configure a layer to be "default deny," which I assume is what you meant. The issue is that anything that can be configured can be accidentally unconfigured. When default-deny is accidentally unconfigured, the network becomes wide open. When NAT is accidentally unconfigured, the network stops functioning entirely. The gate is closed. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 uptake (was: The Reg does 240/4)
On Fri, Feb 16, 2024 at 7:10 PM John Levine wrote: > If you configure your firewall wrong, bad things will happen. I have both > IPv6 and NAT IPv4 on my network here and I haven't found it particularly > hard to get the config correct for IPv6. Hi John, That it's possible to implement network security well without using NAT does not contradict the claim that NAT enhances network security. That it's possible to breach the layer of security added by NAT does not contradict the claim that NAT enhances network security. Any given layer of security can be breached with expense and effort. Breaching every layer of security at the same time is more challenging than breaching any particular one of them. The use of NAT adds a layer of security to the system that is not otherwise there. Think of it like this: you have a guard, you have a fence and you have barbed wire on top of the fence. Can you secure the place without the barbed wire? Of course. Can an intruder defeat the barbed wire? Of course. Is it more secure -with- the barbed wire? Obviously. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 uptake (was: The Reg does 240/4)
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. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 uptake (was: The Reg does 240/4)
On Fri, Feb 16, 2024 at 5:45 PM wrote: > Why is your Internal v6 subnet advertised to the Internet? Because that was the example network -without- NAT. If I made two networks -with- NAT, there would be no difference to show. I make 2602:815:6000::/44 be 199.33.224.0/23, make 2602:815:6001::/64 be 199.33.224.0/24, make 2602:815:600::1 be 199.33.225.1 and make 2602:815:6001::4 be 199.33.224.4, it would be the exact same example with the exact same network security impact. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 uptake (was: The Reg does 240/4)
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. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 uptake (was: The Reg does 240/4)
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. > NAT is not without its own set of problems, NAT's problems are legion. But the question was whether and how NAT improves the security of a network employing it. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 uptake (was: The Reg does 240/4)
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. Now suppose I have a firewall at 199.33.225.1 with an internal network of 192.168.55.0/24. Inside the network on 192.168.55.4 I have a switch that accepts telnet connections with a user/password of admin/admin. On the firewall, I program it to do NAT translation from 192.168.55.0/24 to 199.33.225.1 when sending packets outbound, which also has the effect of disallowing inbound packets to 192.168.55.0/24 which are not part of an established connection. Someone tries to telnet to 192.168.55.4. What happens? The packet never even reaches my firewall because that IP address doesn't go anywhere on the Internet. Now I make a mistake on my firewall. I insert a rule intended to allow packets outbound from 192.168.55.4 but I fat-finger it and so it allows them inbound to that address instead. Someone tries to telnet to 192.168.55.4. What happens? The packet STILL doesn't reach my firewall because that IP address doesn't go anywhere on the Internet. See the difference? Accessible versus accessible and addressable. Not addressable enhances security. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 uptake (was: The Reg does 240/4)
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. The distinction doesn't seem that subtle to me, but a lot of folks making statements about network security on this list don't appear to grasp it. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: The Reg does 240/4
On Thu, Feb 15, 2024 at 11:10 AM Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > I've said it before, and I'll say it again: > > The only thing stopping global IPv6 deployment is > Netflix continuing to offer services over IPv4. > > If Netflix dropped IPv4, you would see IPv6 available *everywhere* > within a month. If only a couple of large businesses would slit their throats by refusing to service a large swath of their paying customers, IPv6 deployment would surely accelerate. -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: The Reg does 240/4
On Thu, Feb 15, 2024 at 3:08 AM Christopher Hawker wrote: > The idea to this is to allow new networks to emerge > onto the internet, without potentially having to fork > out substantial amounts of money. Hi Chris, I think that would be the worst possible use for 240/4. The last thing new entrants need is IP address space with complex and quirky legacy issues. No-sale on the money issue too. I did a cost analysis years ago on the money involved in "the rest of us" accepting a route announcement into the DFZ. The short version is that if you can't afford IPv4 addresses at the current market prices, you don't belong here. Your presence with a /24 will collectively cost us more than you spent, just in the first year. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: The Reg does 240/4
On Wed, Feb 14, 2024 at 9:23 AM Owen DeLong via NANOG wrote: > Think how many more sites could have IPv6 capability already if this wasted > effort had been put into that, instead. "Zero-sum bias is a cognitive bias towards zero-sum thinking; it is people's tendency to intuitively judge that a situation is zero-sum, even when this is not the case. This bias promotes zero-sum fallacies, false beliefs that situations are zero-sum. Such fallacies can cause other false judgements and poor decisions." https://en.wikipedia.org/wiki/Zero-sum_thinking Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: The Reg does 240/4
On Tue, Feb 13, 2024 at 2:34 PM Christopher Hawker wrote: > Having [240/4] reclassified as unicast space is indeed much easier. Hi Chris, If I were spending my time on the effort, that's what I'd pursue. It's a low-impact change with no reasonable counter-argument I've seen. As you noted, half the vendors already treat it as unicast space anyway. > With that, comes the argument - what about legacy hardware > that vendors no longer support, or are out of warranty and no > longer receive software updates? What about legacy hardware that doesn't support CIDR? What about the 1990s Sparc Stations that don't have enough ram to run anything vaguely like a modern web browser? You make the key standards change (from reserved undefined use to reserved unicast use) and over time varying potential uses for those unicast addresses become practical despite the receding legacy equipment. None of us has a crystal ball saying when IPv4 use will start to fall off. It's entirely possible It'll still be going strong in 20 more years. If so, and if 240/4 was defined as unicast now, it'll surely be practical to use it by then. Making the simple standards change also lets us debate the "best" use of the addresses while the needed software change happens in parallel, instead of holding up the software changes while we debate. Allocating them to the RIRs isn't the only practical use of a new set of unicast IP addresses. Other plausible uses include: * More RFC1918 for large organizations. * IXP addresses which only host routers, not the myriad servers and end-user client software. * ICMP unreachable source address block, for use by routers which need to emit a destination unreachable message but do not have a global IP address with which to do so. * A block of designated private-interconnect addresses intended to be used by off-internet networks using overlapping RFC1918 which nevertheless need to interconnect. Indeed, the only use for which we definitely -don't- need more IPv4 addresses is Multicast. So, a rush to deploy 240/4 to RIRs is not really warranted. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: The Reg does 240/4
On Tue, Feb 13, 2024 at 2:03 AM Christopher Hawker wrote: > [Note: I have cross-posted this reply to a thread from NANOG on > AusNOG, SANOG and APNIC-Talk in order to invite more peers > to engage in the discussion on their respective forums.] Chris, Do not cross-post lists. Many of the folks who want to discuss are only subscribed to one of the lists and thus cannot post to the others. This inevitably results in a disjoint and confusing set of posts with replies to messages for which the originals didn't make it to the local list. If you want to discuss something on multiple lists with multiple audiences, start a separate discussion on each. Honestly, how can you not know this. It's only been mailing list etiquette for decades. > we feel it is appropriate for this space to be reclassified as > Unicast space available for delegation by IANA/PTI to RIRs > on behalf of ICANN. That is probably unrealistic. Getting 240/4 reclassified as unicast is at least plausible. As you say, there's no residual value in continuing to hold it in reserve. The opportunity cost has fallen near zero. But before anybody with a clue is willing to see it allocated to RIRs for general Internet use they'll want to see studies and experiments which demonstrate that it's usable enough on the public Internet to be usefully deployed there. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: If I announce 192.0.2.0/24, do I need a discard route? (Looking for a reference…)
On Wed, Jan 31, 2024 at 1:46 PM Warren Kumari wrote: > On Wed, Jan 31, 2024 at 3:56 PM, William Herrin wrote: >> On Wed, Jan 31, 2024 at 12:30 PM Warren Kumari wrote: >> Your router won't announce 192.0.2.0/24 unless it knows a route to >> 192.0.2.0/24 or has been configured to aggregate any internal routes inside >> 192.0.2.0/24 to 192.0.2.0/24. > > It that always true? I'd started off thinking that, but a friend of mine > (yes, the same one that started this argument) convinced me that some forms > of BGP summarization/aggregation don't always generate a "local" route… Hi Warren, I'm not sure what you mean. Aggregation means that if at least one more-specific is present, the aggregate will be announced. If none of the more-specifics are present, the aggregate will not be announced. If you have a default route, I suppose you could end up with a loop, but that would be your fault for failing to tie down the route you were announcing. Another reason why it's best practice to have that explicit route to discard. If you don't have a default route, recognize that there is an -implicit- discard route for default which catches everything for which you do not have a route. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: If I announce 192.0.2.0/24, do I need a discard route? (Looking for a reference…)
On Wed, Jan 31, 2024 at 12:30 PM Warren Kumari wrote: > So, let's say I'm announcing some address space (e.g 192.0.2.0/24), > but I'm only using part of it internally (e.g 192.0.2.0/25). I've always > understood that it's best practice[0] to have a discard route (eg static > to null0/discard or similar[1]) for what I'm announcing. Hi Warren, Your router won't announce 192.0.2.0/24 unless it knows a route to 192.0.2.0/24 or has been configured to aggregate any internal routes inside 192.0.2.0/24 to 192.0.2.0/24. 192.0.2.0/25 doesn't count; it needs to know a route to 192.0.2.0/24. Sending 192.0.2.0/24 to discard guarantees that the router has a route to 192.0.2.0/24. Historically, folks would put 192.0.2.0/24 on the ethernet port. Then, when carrier was lost on the ethernet port for a moment, the router would no longer have a route to 192.0.2.0/24, so it'd withdraw the announcement for 192.0.2.0/24. This is a bad idea for obvious reasons, so best practice was to put a low priority route to discard as a fall-back if the ethernet port briefly lost carrier. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Wed, Jan 24, 2024 at 8:39 AM James Jun wrote: > On Wed, Jan 24, 2024 at 08:16:56AM -0800, William Herrin wrote: > > Sophistry. I buy IP transit from 3 providers, one of which has a 3 AS > > path to 3356. > > Again you omit context. What you're calling context, I call deceptive. For one thing, Centurylink's process is, like a spammer, opt-out rather than opt-in. 3356 enables the local pref unless told through a BGP community not to. There's no evidence that 47787 even knows that Centurylink is preferring them despite shorter AS paths elsewhere, let alone desires that behavior. Indeed, given the prepends that 47787 added, it's quite possible they desire the opposite. For another, a key implication in your "context" is that if one customer intentionally pays 3356 to intentionally send another customer's packets on a longer, slower trip than 3356 otherwise would, that's a legitimate above-board business transaction. Not obviously corrupt. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Wed, Jan 24, 2024 at 8:11 AM James Jun wrote: > You (AS11875) have an operational need for good connectivity > into 3356 but, you made a poor purchasing decision by buying > IP transit for 11875 from a provider who has 10-AS path into > 3356 instead of <=3 AS path. You've done a _bad_ job here > in selecting an inferior pathway into 3356, and what you > SHOULD have done is to select an IP transit provider who > has an optimal AS-path into 3356 to meet your operational > need of having good connectivity into 3356. Sophistry. I buy IP transit from 3 providers, one of which has a 3 AS path to 3356. -Bill -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Wed, Jan 24, 2024 at 5:23 AM Chris Adams wrote: > Once upon a time, William Herrin said: > > On Tue, Jan 23, 2024 at 4:00 PM Chris Adams wrote: > > > Once upon a time, William Herrin said: > > > > Nevertheless, in the protocol's design, the one expressed in the > > > > RFC's, AS path length = distance. > > > > > > The RFC doesn't make any equivalence between AS path length and > > > distance. You are the one trying to make that equivalence, > > > > Respectfully Chris, you are mistaken. > > > > https://datatracker.ietf.org/doc/html/rfc4271#section-9.1.2.2 > > > > "a) Remove from consideration all routes that are not tied for having > > the smallest number of AS numbers present in their AS_PATH > > attributes." > > > > So literally, the first thing BGP does when picking the best next hop > > is to discard all but the routes with the shortest AS path. > > That's literally not the first thing - you skipped section 9.1.1. Phase 1 is local pref. That's what 9.1.1 says. As implied by the word "local," it's set locally by the local operator, not by the origin, though many providers offer haphazard mechanisms that sometimes have some impact if the origin doesn't mind playing whack-a-mole with BGP communities. Unless locally configured to selectively change the local pref off the default, all routes have the same local pref. So it moves to phase 2 (section 9.1.2). This matches what I've been saying for the entire thread: unless the operator intentionally makes the route worse, it follows the shortest AS path. Per the RFC. > It also literally says nothing about distance. BGP is a distance-vector protocol. BGP's authors preferred different terminology so they used different terminology. Nevertheless, BGP is a distance-vector protocol and when you ask what it uses to determine distance, the answer is the AS path length because all the other criteria are policy functions not distance functions. Want to go another few rounds with pedantry over word choice, or can we leave it there? Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Wed, Jan 24, 2024 at 7:02 AM Jon Lewis wrote: > In one of his messages, William complained that the big bad networks are > breaking the BGP rules by ignoring as-path length. To be clear, I don't really care whether you're "breaking the rules." Moreover, if my words suggested that I thought using BGP's local pref capability was "breaking the rules," then either you misunderstood me or I chose my words poorly. What I did say, and stand behind, was that applying local prefs moves BGP's route selection off the _defaults_, and if Centurylink was routing to me based instead on the defaults they'd have made a _good_ route selection instead of a _bad_ one. I do care whether you're routing packets in a reasonable way. When you pick the 10-AS path over the 3-AS path because the 10-AS path arrives from a customer, the odds that you're routing those packets in a _good_ way are very low. I get that a lot of you do that. I'm telling you that when you do, you're doing a _bad_ job. If you think you're justified, well, it's your business. But don't doubt for a second that you've served your customers poorly. And before you suggest that I'm not your customer, let me point out what should be obvious: if none of your paying customers were trying to reach my network, I wouldn't notice which direction you routed my packets, let alone care. It's not about serving me, it's about serving your paying customers. My packets are their packets, and when you send _their_ packets along the scenic route, you have done a bad job. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Wed, Jan 24, 2024 at 12:55 AM Owen DeLong wrote: > BGP is more of a PDVP (Policy Distance Vector Protocol). Hi Owen, That's a distinction without a difference. All but the most rudimentary implementation of a distance-vector protocol supports policy definition and enforcement. BGP has more policy knobs than most, but at its heart it's still a distance-vector protocol and until pushed off its default settings its first differentiator for distance is the length of the AS path. Only link-state protocols tend to lack policy knobs since all nodes must agree about the correct full path, not just the next closest hop. When you twist a policy knob to move BGP off its defaults, you take responsibility for making a better routing choice. And for correcting that choice if it should prove faulty. What I've seen here in this thread is a bunch of folks abdicating that responsibility. That's not unexpected, but it is disappointing. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Tue, Jan 23, 2024 at 4:00 PM Chris Adams wrote: > Once upon a time, William Herrin said: > > Nevertheless, in the protocol's design, the one expressed in the > > RFC's, AS path length = distance. > > The RFC doesn't make any equivalence between AS path length and > distance. You are the one trying to make that equivalence, Respectfully Chris, you are mistaken. https://datatracker.ietf.org/doc/html/rfc4271#section-9.1.2.2 "a) Remove from consideration all routes that are not tied for having the smallest number of AS numbers present in their AS_PATH attributes." So literally, the first thing BGP does when picking the best next hop is to discard all but the routes with the shortest AS path. It also says that BGP implementations are -allowed- to use other selection criteria. And there are many situations where doing so is well advised and improves the result. But AS path length is unambiguously the default, off which a user has to move it. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Tue, Jan 23, 2024 at 3:27 PM Tom Beecher wrote: >> Unless overridden, BGP takes -distance- into account where distance = >> AS path length. > > An AS_PATH length of 10 could be a physical distance of 1 mile. > > An AS_PATH length of 1 could be a physical distance of 1000 miles. Nevertheless, in the protocol's design, the one expressed in the RFC's, AS path length = distance. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Tue, Jan 23, 2024 at 12:34 PM Niels Bakker wrote: > BGP, while a distance vector protocol, famously does not take > latency into account when making routing decisions. Unless overridden, BGP takes -distance- into account where distance = AS path length. Centurylink has overridden that with a localpref so that it DOES NOT take distance into account. Which rather defeats the function of a distance vector protocol. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Tue, Jan 23, 2024 at 12:38 PM Tom Beecher wrote: > 1. Experiment with 53356's TE communities to prevent them from announcing to > upstreams that give you poor performance to 3356. Respectfully, I rejected that approach because it doesn't address the other few hundred instances of this problem, nor even resolves the current issue since Centurylink is demonstrated to then switch to yet another customer via a different one of my upstreams that would require yet another community, if there is one. > 2. See if 47787 will talk to you about their path to 3356. Haha. You're funny. > 3. Pick an upstream that has better / more direct connectivity to 3356, use > them instead of /in parallel with 53356. Haha. You're funny. > 4. Get yourself connected to 3356 directly. I am, just not as a BGP customer. And I won't be as a BGP customer. Opening a ticket with them has not yielded results. Or any response from network engineering at all. Just the frontline support who wants me to reboot my modem. :( > 5. Keep yelling at the clouds about 3356 , even though they are doing the > same thing that (to the best of my knowledge) every large transit provider > does. 6. Pollute the DFZ because in light of what "every large transit provider does," that's the solution that actually works. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Tue, Jan 23, 2024 at 11:45 AM Owen DeLong via NANOG wrote: > The catch to all of that, however, is that he’s not directly peered with 3356 > and many AS operators strip communities. And even if I didn't, the problem isn't just one ISP localprefing to prefer distant routes. Centurylink most directly impacts me, but as others have pointed out: many ISPs do the same darn thing. The only workable solution available to me appears to be tripling my presence in the DFZ tables. Because big operators think it reasonable to localpref distance routes ahead of nearby ones so long as the distant routes arrive from customers. I'll remember that the next time folks complain about the size of the routing table. This one you did to yourselves. Regards, Bill -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Mon, Jan 22, 2024 at 6:43 PM William Herrin wrote: > On Mon, Jan 22, 2024 at 5:59 PM James Jun wrote: > > CL is choosing 3356 47787[x3] 53356 11875[x3] over better path via 1299: > >This is not a Lumen/CenturyLink/Level 3 problem. > > What you need to be doing is > > Hi James, > > My solution has been to add two more-specific routes to -your- routing > table so that my one prefix now consumes three routes. If you and the > others defending Centurylink's behavior are satisfied with that > solution, then we're done here. Of course, I'll probably have to do the same thing with my v6 prefix too. But hey, if that works for you I'll conquer my irritation at the inefficiency. -Bill -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Mon, Jan 22, 2024 at 5:59 PM James Jun wrote: > CL is choosing 3356 47787[x3] 53356 11875[x3] over better path via 1299: >This is not a Lumen/CenturyLink/Level 3 problem. > What you need to be doing is Hi James, My solution has been to add two more-specific routes to -your- routing table so that my one prefix now consumes three routes. If you and the others defending Centurylink's behavior are satisfied with that solution, then we're done here. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Mon, Jan 22, 2024 at 4:16 PM Alex Le Heux wrote: > > On Jan 23, 2024, at 00:43, William Herrin wrote: > > Every packet has two customers: the one sending it and the one > > receiving it. 3356 is providing a service to its customers. ALL of its > > customers. Not just 47787. Sending the packet an extra 5,000 miles > > harms every one of 3356's customers -except for- 47787. > > > > In this case, I am the customer on both ends. 3356's choice to route > > my packet via 47787 serves me poorly. > > Packets don't have customers, ISPs do. And in this case you're not a customer > of the ISP making the routing decision Incorrect. I am a customer of 3356. A residential customer, not a BGP customer. I'm paying them to route my packets too, and they're routing them poorly. Also incorrect: every packet in your network is linked to either one or two customers. Never more. Never less. Routing my packet via 47787 in this case serves neither of us: my Internet access is severely degraded and 47787 is charged money for a packet they need not have handled. Charging your customers to make their service worse doesn't seem like a good business model to me, but maybe that's why I'm not a CEO. > Fact is that all prepending does it provide a vague hint to other > networks about what you would like them to do. Until they tamper with it using localpref, BGP's default behavior with prepends does exactly the right thing, at least in my situation. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Mon, Jan 22, 2024 at 3:34 PM Alex Le Heux wrote: > This is perfectly reasonable routing _if you're 3356_ > > In this profit-driven world, expecting 3356 to do something that's > unprofitable for them just because it happens to be convenient for you is, > well, unreasonable. Hi Alex, Every packet has two customers: the one sending it and the one receiving it. 3356 is providing a service to its customers. ALL of its customers. Not just 47787. Sending the packet an extra 5,000 miles harms every one of 3356's customers -except for- 47787. In this case, I am the customer on both ends. 3356's choice to route my packet via 47787 serves me poorly. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IRR information & BYOIP (Bring Your Own IP) with Cloud Providers
On Mon, Jan 22, 2024 at 1:57 PM Daniel Marks wrote: > AWS allows you to broadcast your own ASN when you BYOIP: > https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-vpc-ip-address-manager-bring-your-own-asn-aws/ True, but even then they're not propagating a BGP announcement from you. They're just using your AS number at the front of the path when they announce the addresses. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Mon, Jan 22, 2024 at 1:55 PM Nick Hilliard wrote: > You have your own ASN, you have control over your own routing policy. > Centurylink probably aren't going to be interested in engaging with you > if you're not a customer. It's a pickle. It's not a pickle for me. I'll announce three prefixes instead of one, and you get to pay for the extra two TCAM slots. It offends my pride to handle it this way, but -you- shoulder the cost. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IRR information & BYOIP (Bring Your Own IP) with Cloud Providers
On Fri, Jan 19, 2024 at 1:55 PM Owen DeLong via NANOG wrote: > Sounds like you’ve got a weird mix of route origination. Why wouldn’t you > advertise to Google via BGP and have your prefix originate from your own ASN? Big Cloud byoip doesn't generally work that way. You register the addresses in their portal and they handle everything else with the expectation that their AS is the sole origin for the prefix in question. At least that's how the AWS offering works. I presume GCP is the same. They're not acting as a general-purpose ISP. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Mon, Jan 22, 2024 at 1:11 PM Andrew Hoyos wrote: > On Jan 22, 2024, at 14:35, William Herrin wrote: >> The best path to me from Centurylink is: 3356 1299 20473 11875 > >> The path Centurylink chose is: 3356 47787 47787 47787 47787 53356 >> 11875 11875 11875 > >> Do you want to tell me again how that's a reasonable path selection, >> or how I'm supposed to pass communities to either 20473 or 53356 which >> tell 3356 to behave itself? > > AS53356 (Free Range Cloud Hosting) appears to have some limited BGP > communities that may help. > https://docs.freerangecloud.com/en/bgp/communities > > implies that you sending 53356:19014 would block announcements to 47787. At which point Centurylink chooses 40676 7489 11875 11875 11875 11875 11875 11875 11875. > This certainly seems like a reasonable path selection, in the context that > 47787 is likely a 3356 customer. That's -why- 3356 chooses the paths. 40676 and 47787 are customers, 1299 is a peer. You're telling me with a straight face that you think that's *reasonable* routing? > That may turn into a game of whack a mole, but the knobs appear to be there > to try something other than prepending to influence 3356’s selection. Whack-a-mole is not a reasonable solution to anything. Besides, I don't want to drop the path to 53356 via 47787. If the path through 20473 fails, the path through 53356 is the next best and I want Centurylink to use it. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Mon, Jan 22, 2024 at 10:19 AM James Jun wrote: > So, as a customer, you actually SHOULD be demanding your ISPs > to positively identify and categorize their routes using local-pref > and communities. Hi James, The best path to me from Centurylink is: 3356 1299 20473 11875 The path Centurylink chose is: 3356 47787 47787 47787 47787 53356 11875 11875 11875 Do you want to tell me again how that's a reasonable path selection, or how I'm supposed to pass communities to either 20473 or 53356 which tell 3356 to behave itself? Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Mon, Jan 22, 2024 at 5:23 AM Jon Lewis wrote: > You may be limited to seeing if your backup providers have community > controls that would let you tell them "don't share with Centurylink" As I already explained, neither the primary nor any of the backup providers directly peer with Centurylink, thus have no communities for controlling announcements to Centurylink. I hate to litter the table with a batch of more-specifics that only originate from the short, preferred link but I'm not hearing any practical alternatives. Treating my distant links as equivalent even though I told you with prepends that they are not leaves me with few knobs I can turn. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Networks ignoring prepends?
On Mon, Jan 22, 2024 at 5:24 AM Patrick W. Gilmore wrote: > Standard practice is to localpref your customers up, which makes prepends > irrelevant. Why would anyone expect different behavior? It gives me, your paying customer, less control over my routing through your network than if I wasn't your paying customer. That seems... backwards. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Networks ignoring prepends?
Howdy, Does anyone have suggestions for dealing with networks who ignore my BGP route prepends? I have a primary ingress with no prepends and then several distant backups with multiple prepends of my own AS number. My intention, of course, is that folks take the short path to me whenever it's reachable. A few years ago, Comcast decided it would prefer the 5000 mile, five-prepend loop to the short 10 mile path. I was able to cure that with a community telling my ISP along that path to not advertise my route to Comcast. Today it's Centurylink. Same story; they'd rather send the packets 5000 miles to the other coast and back than 10 miles across town. I know they have the correct route because when I withdraw the distant ones entirely, they see and use it. But this time it's not just one path; they prefer any other path except the one I want them to use. And Centurylink is not a peer of those ISPs, so there doesn't appear to be any community I can use to tell them not to use the route. I hate to litter the table with a batch of more-specifics that only originate from the short, preferred link but I'm at a loss as to what else to do. Advice would be most welcome. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: "Hypothetical" Datacenter Overheating
On Tue, Jan 16, 2024 at 10:30 AM Chris Adams wrote: > The back-room ISP I started at was at least owned by a company with > their own small machine shop, so we had them make plates we could mount > two Sportsters (sans top) to and slide them into card cages. 20 modems > in a 5U cage! The ISP where I worked bought wall-mounted wire shelves and routed the serial cable through the shelf to stably hold the modems vertically in place and apart from each other. Worked pretty well. The open shelving let air move up past them keeping them cool and offered plenty of tie points for cable management. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: "Hypothetical" Datacenter Overheating
On Mon, Jan 15, 2024 at 11:08 PM Saku Ytti wrote: > On Tue, 16 Jan 2024 at 08:51, wrote: > > A rule of thumb is a few degrees per hour change but YMMV, depends on > > the equipment. Sometimes manufacturer's specs include this. > > Is this common sense, or do you have reference to this, like paper > showing at what temperature change at what rate occurs what damage? It's uncommon sense. You have a computer room humidified to 40% and you inject cold air below the dew point. The surfaces in the room will get wet. See also: https://en.wikipedia.org/wiki/Thermal_stress Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: "Hypothetical" Datacenter Overheating
On Mon, Jan 15, 2024 at 7:14 AM wrote: > I’m more interested in how you lose six chillers all at once. Extreme cold. If the transfer temperature is too low, they can reach a state where the refrigerant liquifies too soon, damaging the compressor. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: "Hypothetical" Datacenter Overheating
On Mon, Jan 15, 2024 at 6:08 AM Mike Hammett wrote: > Let's say that hypothetically, a datacenter you're in had a cooling failure > and escalated to an average of 120 degrees before mitigations started > having an effect. What should be expected in the aftermath? Hi Mike, A decade or so ago I maintained a computer room with a single air conditioner because the boss wouldn't go for n+1. It failed in exactly this manner several times. After the overheat was detected by the monitoring system, it would be brought under control with a combination of spot cooler and powering down to a minimal configuration. But of course it takes time to get people there and set up the mitigations, during which the heat continues to rise. The main thing I noticed was a modest uptick in spinning drive failures for the couple months that followed. If there was any other consequence it was at a rate where I'd have had to be carefully measuring before and after to detect it. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Diversity in threading, Diversity of MUAs (was Re: How threading works
On Sun, Jan 14, 2024 at 10:21 AM John Levine wrote: > If I were you, I would call up Google and demand that they fix this bug. What bug? In a decade and a half, Abe's bizarre subject changing behavior is the only time GMail has failed to group messages exactly as I find convenient. It's doing the right thing. Abe isn't. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)
On Sat, Jan 13, 2024 at 12:58 PM Bryan Fields wrote: > On 1/12/24 3:04 PM, Mu wrote: > > Would it be possible for you to reply in-thread, rather than creating a new > > thread with a new subject line every time you reply to someone? > > > > Trying to follow the conversation becomes very difficult for no reason. > > Threading has nothing to do with subject lines. RFC822 (now 5822) specifies > how this works based on message ID. This thread displays fine in threaded > mode in my MUA and in the archives. Hi Bryan, Respectfully, your MUA is not the only MUA. Others work differently. GMail, for example, follows the message IDs as you say but assumes that if you change the subject line in your reply (more than adding "Re:") then you intend to start a new thread from that point in the discussion. It groups messages accordingly. This is not an unreasonable expectation: if you merely want to continue the current conversation without going off on a new tangent then there's no need for a different subject line. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block
On Sat, Jan 13, 2024 at 6:32 AM Christopher Hawker wrote: > Further, over the last three days you've changed the subject > line of the thread at least 12 times. Can you please stop changing > it because every time you do, it starts a new thread and makes it > rather difficult to keep track of the discussion. I also don't believe > I'm the first one to raise this either. He has indeed been asked to do so before but is too rude to comply. Stop feeding the troll. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Sufficient Buffer Sizes
On Tue, Jan 2, 2024 at 3:02 PM Mike Hammett wrote: > While attempting to ascertain how big of switch buffers I needed in a 100G > switch, I rediscovered this article where I first learned about switch > buffers. > > https://fasterdata.es.net/network-tuning/router-switch-buffer-size-issues/#:~:text=Optimum%20Buffer%20Size=The%20general%20rule%20of%20thumb,1G%20host%20across%20the%20WAN. > > It suggests that 60 meg is what you need at 10G. Is that per interface? Would > it be linear in that I would need 600 meg at 100G? > > Some 100G switches I was looking at only had 36 megs, so that's insufficient > either way you look at it. Hi Mike, My thoughts: 1. 50 ms is -way- too much buffer. A couple links like that in the path and the user will suffer jitter in excess of 100ms which is incredibly disruptive for interactive applications. 2. The article discussed how much buffer to apply to the -slower- interfaces, not the faster ones, the idea being that data entering from the faster interfaces could otherwise overwhelm the slower ones resulting in needless retransmission and head-end blocking. Are the 100G interfaces on your switch the -slower- ones? I don't know the best number, but I suspect the speed at which packets clear an interface is probably a factor in the equation, so that the reasonable buffer depth in ms when a packet clears in 1ms is probably different than the reasonable buffer depth when a packet clears in 1 us. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Arista “IP-SLA” / Active Probing
On Fri, Dec 22, 2023 at 12:13 PM David Zimmerman via NANOG wrote: > I've had a variant of this on our transit routers for enterprise purposes > for a few years. We run DFZ and originate 0/0 and ::/0 internally, but Hi David, There are several variants on Alex's problem. One is that there's an upstream failure reflected in the BGP table but Alex doesn't see it because he's only taking a default route. Your solution, or one like it, should work for that. In a nutshell: 1. Take a full table 2. Filter everything but a selection of representative routes 3. Set static default routes tied to addresses within the representative routes. If the representative routes disappear from the table, the static defaults become invalid and leave the local routing table as well. Or perhaps he has the reverse problem where he wants to advertise his route only if the representative routes are there so that when his anycast node has network problems it drops itself off the Internet and allows others to take over. Another variant is that BGP reports having the entire Internet table but the packets don't get there. The upstream suffers from anything between high packet loss to a misbegotten filtering rule that black holes all his packets. He'd like to do some active polling via static routes to the upstream and drop both advertised and received routes when the polling indicates a path failure. I thought the latter was what he was asking for, but on a second read-through I see he talked about taking a default route via BGP rather than a full table. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Interesting Ali Express web server behavior...
On Sun, Dec 10, 2023 at 12:08 AM Christopher Hawker wrote: > How big would a network need to get, in order to come close to exhausing > RFC1918 address space? AWS. They exhausted it, broke up the regions reusing the address space, then exhausted it again. Exhaustion was one of the motivations for Facebook going IPv6-only internally. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds
On Sat, Dec 2, 2023 at 5:04 PM Rubens Kuhl wrote: > What I've found missing were references to packet loss impact on > performance. It seems to assume cable/fiber environments with little > to no packet loss, while Wi-Fi and 3G/4G/5G are not like that. Wireless environments tend to do L2 retransmission, so they express packet loss as jitter (random change in latency) instead of actual loss. If you're seeing loss, it's generally on a wired segment. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds
On Fri, Dec 1, 2023 at 8:35 PM wrote: > Or has no engineer capable of configuring it, or support staff trained to > handle the issues that will come up. Like I said: lazy. Training to deploy and support a minimalist 6rd deployment where customers who want it can optionally use it is not a challenging task. A man-week from zero to working. Maybe two. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds
On Fri, Dec 1, 2023 at 1:45 PM Shane Ronan wrote: > Unfortunately from my experience it's usually because the small local > ISPs don't have the resources to understand IPv6, and may be using > equipment generations old that may not support IPv6. It's the large > ISPs that don't want to do it because it would increase their operational > costs and require upgrades to operational systems and they see no new > revenue associated. Hi Shane, 6rd works well enough, has been around long enough, and doesn't require any significant equipment upgrades to implement. An ISP who hasn't at least implemented that much is just being lazy. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds
On Thu, Nov 30, 2023 at 4:55 PM Dave Taht wrote: > https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit > > Comments (and cites) welcomed also! The text is still somewhat in flux... Hi Dave, You start off with a decent thesis - beyond 100mbps there really isn't any difference in capability, not for residential use. Just a difference in how quickly some tasks complete. It's not like the difference between 768kbps and 10 mbps where one does streaming video and conferencing while the other does not. But then you get lost in latency. Latency is important but it's only one in a laundry list of things that make the difference between quality and trash in Internet services. * Packet loss. * Service outages. I have a buddy whose phone line has been out for days four times this year. His ILEC neither wants to maintain the copper lines nor install fiber that deep in the woods, so they keep doing mediocre repairs to the infrastructure that don't hold up. * Incomplete connectivity (e.g. Cogent and IPv6). Personally, I'd love to see rulemaking to the effect that only folks with -open- peering policies are eligible for government funds and contracts. But that's my pet peeve, like latency is yours. And if I pitch that, it'll rightly be seen as a pet issue. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Advantages and disadvantages of legacy assets
On Wed, Nov 22, 2023 at 11:22 AM o...@delong.com wrote: > > On Nov 21, 2023, at 01:38, William Herrin wrote: > > Disadvantages: Expensive IRR. No RPKI. No vote in ARIN elections. No > > legal clarity regarding the status of your resources. > > Expensive IRR? ALTDB is free? I don't know anything about ALTDB. RADB is pricey. On Wed, Nov 22, 2023 at 11:16 AM owen--- via NANOG wrote: > Apparently, Tata is rejecting routes that have neither RPKI nor an RIR-based > IRR record created after 1993. Are you sure? The way I read it, that policy applies to -customer- announced routes, not broad Internet routes received from peers and transit. It still seems unwise, but not entirely insane. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Advantages and disadvantages of legacy assets
On Mon, Nov 20, 2023 at 10:59 AM Eric Dugas via NANOG wrote: > Let's say you inherit legacy assets (ASN & IPv4 netblock), what are the first > advantages that come to mind (beside not having to pay annual fees). > > Any disadvantages? The ones I can think of is the lack of RIR routing > security services (in the ARIN region at least). No IRR, no RPKI at all. Hi Eric, Disadvantages: Expensive IRR. No RPKI. No vote in ARIN elections. No legal clarity regarding the status of your resources. Advantages: Free. No legal clarity regarding the status of your resources. I listed legal clarity as both an advantage and disadvantage. When you sign the ARIN registration services agreement (RSA) you get legal clarity: you are bound by the Number Resource Policy Manual (NRPM) which is subject to change with the approval of the ARIN Board of Trustees which usually follows but is not required to follow a fungible community consensus process. Don't like a change? Too bad. You can deal with it or you can cancel your ARIN contract. If you cancel your contract ARIN reclaims the IP addresses and you have no legal recourse whatsoever. Not that ARIN would ever behave badly. They're good people who earnestly endeavor to do right by the community. But if that changes tomorrow, you'll have no recourse. Skip signing and you have whatever common law rights you have to the IP addresses. Whatever those are. When InterNIC, acting as an agent of the U.S. Government, granted the addresses decades ago, they didn't spend a lot of (or really any) words on the question of legal rights. It hasn't been well tested in court. ARIN claims that the NRPM applies to you anyway, but as a matter of history no provision of the NRPM has ever been adversely applied to the legitimate holder of a then-legacy resource. Not even once. The legal foundation for a claim that it can be is weak at best. The legal risk to ARIN, should it ever attempt to do so, is not trivial. In a nutshell, you can either have a lack of clarity as to your rights or you can clearly have no rights. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: .US Harbors Prolific Malicious Link Shortening Service
On Sat, Nov 4, 2023 at 8:54 AM wrote: > Yeah. I wonder why this cannot be reversed really? > First domain registration should cost more.. 50 USD maybe? Dunno. > And then, when you want to extend the domain, price should be > around 5 times lower? Maybe go the other way: you have to pay the same 1-year price as for the other registries but two and three year registrations are discounted to the same price. Criminals burn through the names pretty quickly, so a multiyear registration is not of value to them. That would allow the marketing department their loss leaders without making themselves as attractive to criminals. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: .US Harbors Prolific Malicious Link Shortening Service
On Thu, Nov 2, 2023 at 3:10 PM Allan Liska wrote: > According to Spamhaus malicious domains account for only 1.5% of all .com > domains, but 4.8% of all .us domains > (https://www.spamhaus.org/statistics/tlds/) - compare that to .tk where 6.7% > of all domains are malicious. Hi Allan, Careful. Statistics don't mean much when separated from their context. Spamhaus doesn't appear to have published the raw numbers for anything except the "top ten." Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: .US Harbors Prolific Malicious Link Shortening Service
On Thu, Nov 2, 2023 at 1:30 PM goemon--- via NANOG wrote: > https://krebsonsecurity.com/2023/10/us-harbors-prolific-malicious-link-shortening-service/ > > What hope is there when registrars are actively aiding and abeting criminal > enterprises? I'm confused. Does .com/.net/.org have a different/better vulnerability profile to these third party link shorteners? Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Pulling of Network Maps
On Thu, Oct 26, 2023 at 10:01 AM Tom Beecher wrote: > My experience with maps over the last decade tells me that even most vendors > don't actually know where they are. :) So true. And not that young a problem. I leased some dark fiber more than a decade ago. They sent an unexpectedly expensive build proposal to connect my building. I asked: "Why are you trenching to the manhole down the street instead of the one right outside?" They asked, "what manhole?" Long story short, they dispatched a guy who popped the cover, pumped the water out of the vault and confirmed that they had a location they didn't know about. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: 165 Halsey recurring power issues
On Mon, Oct 23, 2023 at 3:56 PM Eric Kuhnke wrote: > Bulk/high-volume hosting companies, dedicated server companies/small > rack unit count colocation operate on very thin margins. Unless a > customer is paying a LOT more per month they're not economically > going to be connected to true diverse A/B power. Zero sympathy for anyone who advertises A/B power and doesn't at least have them connected to different UPSs. Don't care how big you are; don't advertise fake reliability. I don't need "six nines" to make effective use of your service but if you lie to me, we're done. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: 165 Halsey recurring power issues
On Mon, Oct 23, 2023 at 7:38 AM Babak Pasdar wrote: > A few months ago, 165 Halsey took us down for several hours. They > claimed that a UPS failed causing this issue. Our natural reaction was > that we have A/B redundant power so a failed UPS on the A circuit should > not take down the cabinet. Joe the facility manager claimed that > industry standard A/B power means two circuits to the same UPS, which > makes no sense to me. If they're being truthful (and many folks are not) then A/B power means that your power is redundant back to at least two different UPSes. The UPSes are maintained at under 40% capacity so that a failure of one doesn't cascade to the other. Ideally these UPSes back to two different generators, also maintained at 40% of capacity. In large, fancy data centers they even get power company feeds from two different substations. Don't just ask the sales droid. When they deliver the rack or the cage, ask the data center manager to show you where your power connections run. If they can't or won't... don't believe them. "Industry standard" A/B power does NOT mean two circuits to the same UPS. That's just extra power, not A/B. Joe lied to you. Incidentally, if you're worried about N+1 redundancy, I assume you're hosted at more than one data center from more than one vendor? Buildings and vendors are single points of failure too. Even when built right, stuff happens. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: RPKI unknown for superprefixes of existing ROA ?
On Sun, Oct 22, 2023 at 10:06 AM Tom Beecher wrote: >> And is it your belief that this addresses the described attack vector? >> AFAICT, it does not. > > In the mixed RPKI / non-RPKI environment of today's internet, no it doesn't. I don't see a path to an Internet where a serious network operator can broadly discard routes for which there is no RPKI information. Especially given that many legacy folks are barred by the registry from participating in RPKI. Do you see a path? Then we have to treat this as a case where RPKI is non-performant and operate with the understanding that an AS0 ROA will not, as a practical matter, accomplish the thing it was designed to do. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: RPKI unknown for superprefixes of existing ROA ?
On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher wrote: >> He's saying that someone could come along and advertise 0.0.0.0/1 and >> 128.0.0.0/1 and by doing so they'd hijack every unrouted address block >> regardless of the block's ROA. >> >> RPKI is unable to address this attack vector. > > > https://www.rfc-editor.org/rfc/rfc6483 > > Section 4 >> >> >> A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the >> holder of a prefix that the prefix described in the ROA, and any more >> specific prefix, should not be used in a routing context. And is it your belief that this addresses the described attack vector? AFAICT, it does not. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: RPKI unknown for superprefixes of existing ROA ?
On Sun, Oct 22, 2023 at 9:10 AM William Herrin wrote: > In essence, this means that a ROA to AS0 doesn't work as intended. Let me ground it a bit: He's saying that someone could come along and advertise 0.0.0.0/1 and 128.0.0.0/1 and by doing so they'd hijack every unrouted address block regardless of the block's ROA. RPKI is unable to address this attack vector. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: RPKI unknown for superprefixes of existing ROA ?
On Sun, Oct 22, 2023 at 8:47 AM Job Snijders wrote: > The attacker won’t be drawing traffic towards itself destined for addresses > in the /22, because of LPM Hi Job, The idea is that you have some infrastructure on IP addresses that you don't route on the Internet. Maybe it's the /24 you use to number your routers. Maybe it's a private network. Whatever it is, you intend for that address block to be absent from Internet routing and produce a ROA for AS0 which should, theoretically, force it to be absent from the Internet. Then someone comes along and advertises a portion of the RIR space larger than any allocation. Since your subnet is intentionally absent from the Internet, that larger route draws the packets allowing a hijack of your address space. In essence, this means that a ROA to AS0 doesn't work as intended. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: RPKI unknown for superprefixes of existing ROA ?
On Sat, Oct 21, 2023 at 11:47 AM Mark Tinka wrote: > The question is - who gets to decide how much space is "too large"? I thought Amir's point was that if an announced route is larger than the RIR allocation then unless you're intentionally expecting it, it's invalid. Because there's no alignment with the RIR allocation, it's not possible to express this invalidity in RPKI. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: xfinity not working
On Wed, Oct 11, 2023 at 12:32 PM Delong.com wrote: > Nope… My Surfboard 8611 has that (just Cable<->single ethernet port). Cool. The models I have only bridge. > The SRX-340 provides a backup simple network (SRX LAN ->NAT->$CABLECO) in > case things go wrong with the (usually more reliable multi-homed) network. ( Yeah, that's why I've been messing with Xfinity this week. I've been stalling since I moved in last year, waiting to see how long Centurylink fiber would work flawlessly enough that I didn't need a second carrier. Last year I got a hold of some cable modems, made sure I could reach the Xfinity activation service, and then I set it aside. I figured that in a pinch I could do Internet off my phone long enough to plug everything back in and get Xfinity up and running. After the glitch a couple weeks ago when Centurylink sent me bursts of other peoples' data for a day or so, I figured it was time to put a second provider back in my mix. Imagine my surprise this week when I went ahead and bought service, went back to the activation page, and it didn't work. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: xfinity not working
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. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: xfinity not working
On Tue, Oct 10, 2023 at 6:07 PM Al Whaley wrote: > My understanding is that the internal web page in the consumer modems is > gone. App or nothing. With xfinity, when you plug it a "non-activated" modem, you get a walled garden where you can connect to some of their web servers for the purpose of linking your modem with your account. Except, as noted, it's not presently in good working order.. And anyway, I brought my own modem which has an internal web server and a handful of pages. Mostly status. Since it's the cable modem only (no wifi), there aren't any user-level knobs to turn. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: xfinity not working
On Tue, Oct 10, 2023 at 6:36 PM Crist Clark wrote: > I had a forced modem upgrade with them earlier this year. I vaguely recall it > was not without some frustration, but I managed to get it done. > > I don’t seem to have a problem logging in at > https://login.xfinity.com/login > Is it transient or still persisting for you? Howdy, http://www.xfinity.net/activate only responds if you're on an unactivated cable modem connected to xfinity. https://login.xfinity.com/login only works if you're not. And neither one particularly works with Firefox. It's chrome all the way down. I gave up and installed the app. User name, password, cable modem's mac address. And now it's activated. I know it's bad form to bring this sort of thing to NANOG, but come on guys: get your act together. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
xfinity not working
Howdy, Wondering if any of the folks from Xfinity have tried activating internet service with their own modem and without installing a mobile phone app any time in the recent past. It doesn't work. It just doesn't work. http://www.xfinity.net/activate -> https://idm.xfinity.com/myaccount/account-selector?execution=e4s1 -> https://login.xfinity.com/login Access Denied You don't have permission to access "http://login.xfinity.com/login?; on this server. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: maximum ipv4 bgp prefix length of /24 ?
On Thu, Oct 5, 2023 at 12:11 PM Owen DeLong via NANOG wrote: > So far, that seems to be largely the case, with more than 50% of ASNs > represented in the DFZ in IPv6, we see > roughly 191884 unique destinations in IPv6 and 942750 unique destinations in > IPv4 (admittedly an instantaneous > snapshot a few moments ago from a single DFZ router, YMMV). When you realize that an IPv6 address takes 4 times the space as an IPv4 address that picture isn't so rosy any more. The impact on critical-path router resources isn't quite 4x of course, but as you say: only 50% of the ASes are represented. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Using RFC1918 on Global table as Loopbacks
On Thu, Oct 5, 2023 at 9:42 AM Javier Gutierrez wrote: > the loopback of the core network devices is being set from RFC1918 > while on the global routing table. I'm sure this is not a major issue but > I have mostly seen that ISPs use global IPs for loopbacks on devices > that would and hold global routing. Hi Javier, It depends. If the loopback is used as the address source for unnumbered interfaces and any of the router's interfaces have differing MTUs then you have a red-alarm fire: you've broken path MTU discovery which breaks TCP. The problem is that the router will originate ICMP destination unreachable, fragmentation needed messages from that address. Those packets will then be filtered entering other networks. Without those messages, the client TCP stack doesn't know to reduce its packet size. It fails with the symptom that the initial connection succeeds but then the first large data stream immediately times out and the connection aborts after a couple minutes. Even if you have the same MTU on all interfaces, you've still broken traceroute since the TTL exceeded messages don't get through. On the other hand, if the loopback is only used to anchor BGP, you select the BGP router ID from a different address and all your network-facing interfaces have global IP addresses then everything should work fine. As you change the configuration over time you'll have to be mindful that you're riding a knife edge, but nothing will actually break. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: U.S. test of national alerts on Oct. 4 at 2:20pm EDT (1820 UTC)
On Wed, Oct 4, 2023 at 11:21 AM Sabri Berisha wrote: > Makes me wonder what I have to do to opt out of this. We all remember what > happened in Hawaii. For the national alert you can't. That's intentional. Although for some reason my silenced phone made no noise. I got the alert, it popped up on the screen, but no noise. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
