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 (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)
Bottom-posted with old school formatting by hand. -Original Message- From: NANOG On Behalf Of William Herrin Sent: Friday, February 16, 2024 8:05 PM To: Michael Thomas Cc: nanog@nanog.org Subject: Re: IPv6 uptake (was: The Reg does 240/4) > 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. 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. Most devices now have a more or less constant flow of heartbeats or updates to somewhere on the Internet. In practice, NAPT just increases the size of the space to scan: just dump your crafted packets to every address + every port at your target. If that increased scanning target is your security, you're better off with the increased target of IPv6. IT administrators don't usually know what kind of NAT they have deployed. 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. Lee
RE: IPv6 uptake (was: The Reg does 240/4)
If you ever want to know which providers in a country are lagging, Geoff Huston is here to help: https://stats.labs.apnic.net/ipv6/US In the U.S., the largest operators without IPv6 are (in order by size): Verizon FiOS (they deployed to 50%, discovered a bug, and rolled back) Frontier Lumen (CenturyLink) CableVision CableOne Suddenlink Windstream US Cellular Brightspeed Comcast, Charter, and Cox each have fully deployed IPv6, along with AT and all of the mobile carriers. Lee -Original Message- From: NANOG On Behalf Of Michael Thomas Sent: Sunday, February 18, 2024 3:29 PM To: nanog@nanog.org Subject: Re: IPv6 uptake (was: The Reg does 240/4) [You don't often get email from m...@mtcc.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments. On 2/18/24 8:47 AM, Greg Skinner via NANOG wrote: > On Feb 17, 2024, at 11:27 AM, William Herrin wrote: >> On Sat, Feb 17, 2024 at 10:34?AM Michael Thomas wrote: >> >>> Funny, I don't recall Bellovin and Cheswick's Firewall book >>> discussing NAT. >> And mine too, since I hadn't heard of "Firewalls and Internet >> Security: Repelling the Wily Hacker" and have not read it. > For what it's worth, both editions of Bellovin and Cheswick's > Firewalls book are online. [1] Also, there are discussions about NAT > and how it influenced IPng (eventually IPv6) on the big-internet list. > [2] FWIW, while at Cisco I started to get wind of some NAT-like proposal being floated by 3COM at Packetcable back in the late 90's, early 2000's (sorry, I have no memory of the specifics now). That was pretty horrifying to me and others as the implication was that we'd have to implement it in our routers, which I'm sure 3COM viewed as a feature, not a bug. We pushed back that implementing IPv6 was a far better option if it came down to that. That sent me and Steve Deering off on an adventure to figure out how we might actually make good on that alternative in the various service provider BU's. Unsurprisingly the BU's were not very receptive not just because of the problems with v6 vs hardware forwarding, but mostly because providers weren't asking for it. They weren't asking for CGNAT like things either though so it was mostly the status quo. IOS on the other hand was taking IPv6 much more seriously so that providers could at least deploy it in the small for testing, pilots, etc even if it was a patchwork in the various platforms. The problem with v6 uptake has always been on the provider side. BU's wouldn't have wanted to respin silicon but if providers were asking for it and it gave them a competitive advantage, they'd have done it in a heartbeat. It's heartening to hear that a lot of big providers and orgs are using IPv6 internally to simplify management along with LTE's use of v6. I don't know what's happening in MSO land these days, but it would be good to hear if they too are pushing a LTE-like solution. I do know that Cablelabs pretty early on -- around the time I mentioned above -- has been pushing for v6. Maybe Jason Livingood can clue us in. Getting cable operators onboard too would certainly be a good thing, though LTE doesn't have to deal with things like brain dead v4-only wireless routers on their network. Mike
Re: IPv6 uptake (was: The Reg does 240/4)
On Sun, 18 Feb 2024, 05:29 Owen DeLong via NANOG, wrote: > Most firewalls are default deny. Routers are default allow unless you put > a filter on the interface. > This is not relevant though. NAT when doing port overloading, as is the case for most CPE, is not default-deny or default-allow. The OS processes the packet just like normal and sends an ICMP back unless there is another firewall that says drop. NAPT adds temporary rewrite rules for each flow that goes outbound. NAT adds nothing to security (Bill and I agree to disagree on this), but at > best, it complicates the audit trail. > It absolutely does add something. Whether that something is valuable or not depends on your vantage point, and I'd say it's better than nothing, but there are better solutions available. M >
Re: IPv6 uptake (was: The Reg does 240/4)
On 2/18/24 8:47 AM, Greg Skinner via NANOG wrote: On Feb 17, 2024, at 11:27 AM, William Herrin wrote: On Sat, Feb 17, 2024 at 10:34?AM Michael Thomas wrote: Funny, I don't recall Bellovin and Cheswick's Firewall book discussing NAT. And mine too, since I hadn't heard of "Firewalls and Internet Security: Repelling the Wily Hacker" and have not read it. For what it's worth, both editions of Bellovin and Cheswick's Firewalls book are online. [1] Also, there are discussions about NAT and how it influenced IPng (eventually IPv6) on the big-internet list. [2] FWIW, while at Cisco I started to get wind of some NAT-like proposal being floated by 3COM at Packetcable back in the late 90's, early 2000's (sorry, I have no memory of the specifics now). That was pretty horrifying to me and others as the implication was that we'd have to implement it in our routers, which I'm sure 3COM viewed as a feature, not a bug. We pushed back that implementing IPv6 was a far better option if it came down to that. That sent me and Steve Deering off on an adventure to figure out how we might actually make good on that alternative in the various service provider BU's. Unsurprisingly the BU's were not very receptive not just because of the problems with v6 vs hardware forwarding, but mostly because providers weren't asking for it. They weren't asking for CGNAT like things either though so it was mostly the status quo. IOS on the other hand was taking IPv6 much more seriously so that providers could at least deploy it in the small for testing, pilots, etc even if it was a patchwork in the various platforms. The problem with v6 uptake has always been on the provider side. BU's wouldn't have wanted to respin silicon but if providers were asking for it and it gave them a competitive advantage, they'd have done it in a heartbeat. It's heartening to hear that a lot of big providers and orgs are using IPv6 internally to simplify management along with LTE's use of v6. I don't know what's happening in MSO land these days, but it would be good to hear if they too are pushing a LTE-like solution. I do know that Cablelabs pretty early on -- around the time I mentioned above -- has been pushing for v6. Maybe Jason Livingood can clue us in. Getting cable operators onboard too would certainly be a good thing, though LTE doesn't have to deal with things like brain dead v4-only wireless routers on their network. Mike
Re: IPv6 uptake (was: The Reg does 240/4)
On 2/17/24 11:27 AM, William Herrin wrote: On Sat, Feb 17, 2024 at 10:34 AM Michael Thomas wrote: I didn't hear about NAT until the late 90's, iirc. I've definitely not heard of Gauntlet. Then there are gaps in your knowledge. Funny, I don't recall Bellovin and Cheswick's Firewall book discussing NAT. And mine too, since I hadn't heard of "Firewalls and Internet Security: Repelling the Wily Hacker" and have not read it. I see that the book was published in 1994. In 1994 Gauntlet was calling their process "transparent application layer gateways," not NAT. What was called NAT in 1994 was stateless 1:1 NAT, where one IP mapped to exactly one IP in both directions. Stateless 1:1 NAT had no impact on security. But that's not the technology we're talking about in 2024. Stateless 1:1 NAT is so obsolete that support was dropped from the Linux kernel a long time ago. That actually caused a problem for me in 2017. I had a use where I wanted 1:1 NAT and wanted to turn off connection tracking so that I could do asymmetric routing through the stateless translators. No go. So it does not surprise me that a 1994 book on network security would not have discussed NAT. They'd have referred to the comparable contemporary technology, which was "transparent application layer gateways." Those behaved like what we now call NAT but did the job a different way: instead of modifying packets, they terminated the connection and proxied it. I don't recall the book talking about proxies, but it's been a long time. It was mostly about (stateful) firewalls, iirc. The rapid expansion of the internet caused a huge need for a big band-aid, especially with shitty windows boxes emerging on the net shortly after. A stateful firewall walled off for incoming on client subnets was perfectly sufficient though, and need to provision clients with proxies and the necessary software. The book is not very long and honestly that's a feature as it seemed to mostly be trying to get the word out that we should be protecting ourselves at the borders until better security could get deployed. If NAT's supposed belt and suspenders security was such a big feature, I don't recall anybody talking about it that way back then. That's why it's always seemed like a post-hoc rationalization. When I was at Cisco, all of the internal networks were numbered in public address space and I never once heard any clamor for the client space to be renumbered into RFC 1918 space for security reasons. Admittedly anybody doing so would have faced fierce resistance, but if there were any debate at all it was that adding state to network flows was a Bad Thing. NAT has always been about overloading public IP addresses first and foremost. The supposed security gains are vastly dwarfed by the decrease in functionality that NAT brings with it. One only has to look at the mental gymnastics that goes into filling out SDP announcements for VoIP to know that any supposed security benefits are not worth the trouble that it brings. If it were only security, nobody would have done it. It was always about address conservation first and foremost. Mike
Re: IPv6 uptake (was: The Reg does 240/4)
On Feb 17, 2024, at 11:27 AM, William Herrin wrote: > > On Sat, Feb 17, 2024 at 10:34?AM Michael Thomas wrote: > >> Funny, I don't recall Bellovin and Cheswick's Firewall book discussing >> NAT. > > And mine too, since I hadn't heard of "Firewalls and Internet > Security: Repelling the Wily Hacker" and have not read it. For what it's worth, both editions of Bellovin and Cheswick's Firewalls book are online. [1] Also, there are discussions about NAT and how it influenced IPng (eventually IPv6) on the big-internet list. [2] —gregbo [1] https://www.wilyhacker.com [2] https://mailarchive.ietf.org/arch/browse/big-internet/
Re: IPv6 uptake (was: The Reg does 240/4)
Concerning the firewall book. Firewalls and Internet Security, Second Edition PDF online at https://www.wilyhacker.com/fw2e.pdf "Some people think that NAT boxes are a form of firewall. In some sense, they are, but they're low-end ones."
Re: IPv6 uptake (was: The Reg does 240/4)
On 17/02/2024, 19:27:20, "William Herrin" wrote: 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. And that was a very desired feature plus the address isolation, then and for decades since. The clients IP stack was not trusted to interact directly with external hosts. See socks proxy too (and later Squid). It is still in use today in some places. There were stateful firewalls but trust was reduced when the Firewall 1 undocumented and not unconfigurable default DNS UDP inbound rule was discovered, it let anyone on the Internets "DNS" packets reach any host on the inside they could guess the address of. The "what if the product does allow packets in it is expected not to" consideration drove having unreachable internal addressing. Clicking on rules and assuming it is all good forever more through product revisions was not sufficient. Every version would need a significant re audit and probably miss any real problem. How are people validating their firewall does what they think it does? brandon
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)
I can’t speak to Cisco as I don’t have recent experience there. Juniper, Linux, Palo Alto, and most others I’ve dealt with in the last 5 years pose no significant difference in writing policy for IPv6 vs. the process for IPv4. OwenOn Feb 17, 2024, at 10:23, Justin Streiner wrote:We went pretty deep into the weeds on NAT in this thread - far deeper than I expected ;)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)? On the last major v6 deployment I did, working with the firewalls was definitely one of the major pain points because the support / stability was really lacking, or there wasn't full feature parity between their v4 and v6 capabilities.Thank youjmsOn Fri, Feb 16, 2024 at 11:04 PM William Herrinwrote: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)
> 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. > NAT is like the barbed wire. Anyone with a pair of wire cutters doesn’t need to defeat the barbed wire, they just cut the fence instead. But I understand how the barbed wire makes you and management feel warm and fuzzy. The problem here is that NAT is also like a big blind spot in the video cameras that should be helping you spot the guy cutting the fence. Owen
Re: IPv6 uptake (was: The Reg does 240/4)
Bill, same scenario, but instead of fat fingering an outbound rule, you fat finger a port map for inbound connections to a different host and get the destination address wrong. Still hacked. NAT doesn’t prevent fat fingers from getting you hacked, it just changes the nature of the required fat fingering. Care to talk about trying to track down a compromised host through the audit trail given an abuse report that doesn’t include the source port number? (Oracle even one that happens to include it)? Owen > On Feb 16, 2024, at 17:05, William Herrin wrote: > > On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas wrote: >> If you know which subnets need to be NAT'd don't you also know which >> ones shouldn't exposed to incoming connections (or conversely, which >> should be permitted)? It seems to me that all you're doing is moving >> around where that knowledge is stored? Ie, DHCP so it can give it >> private address rather than at the firewall knowing which subnets not to >> allow access? Yes, DHCP can be easily configured to make everything >> private, but DHCP for static reachable addresses is pretty handy too. > > Hi Mike, > > Suppose I have a firewall at 2602:815:6000::1 with an internal network > of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a > switch that accepts telnet connections with a user/password of > admin/admin. On the firewall, I program it to disallow all Internet > packets to 2602:815:6001::/64 that are not part of an established > connection. > > Someone tries to telnet to 2602:815:6001::4. What happens? Blocked. > > Now, I make a mistake on my firewall. I insert a rule intended to > allow packets outbound from 2602:815:6001::4 but I fat-finger it and > so it allows them inbound to that address instead. Someone tries to > telnet to 2602:815:6001::4. What happens? Hacked. > > 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 2/16/24 6:33 PM, William Herrin wrote: On Fri, Feb 16, 2024 at 6:10 PM Ryan Hamel wrote: Depending on where that rule is placed within your ACL, yes that can happen with *ANY* address family. Hi Ryan, Correct. The examples illustrated a difference between a firewall implementing address-overloaded NAT and a firewall implementing everything except the address translation. Either example could be converted to the other address family and it would work the same way. All things aside, I agree with Dan that NAT was never ever designed to be a security tool. It is used because of the scarcity of public address space, and it provides a "defense" depending on how it is implemented, with minimal effort. This video tells the story of NAT and the Cisco PIX, straight from the creators https://youtu.be/GLrfqtf4txw NAT's story, the modern version of NAT when we talk about IPv4 firewalls, started in the early '90s with the Gauntlet firewall. It was described as a transparent application layer gateway. Gauntlet focused on solving enterprise security issues. Gauntlet's technology converged with what was then 1:1 NAT to produce the address-overloaded NAT like what later appeared in the Cisco PIX (also first and foremost a security product) and is present in all our DSL and cable modems today. Security came first, then someone noticed it'd be useful for address conservation too. Gauntlet's customers generally had or could readily get a supply of public IP addresses. Indeed, when Gauntlet was released, IP addresses were still available from hostmas...@internic.net at zero cost and without any significant documentation. And Gauntlet was expensive: folks who couldn't easily obtain public IP addresses also couldn't afford it. Funny, I don't recall Bellovin and Cheswick's Firewall book discussing NAT. That was sort of the go-to book for hard-on-the-outside soft-on-the-inside defense. Maybe they were unaware of this, or maybe they didn't agree with the premise. I didn't hear about NAT until the late 90's, iirc. I've definitely not heard of Gauntlet. As I recall, it was very much an afterthought with cable/DOCSIS to use NAT to conserve addresses. The headend DHCP server just gave public addresses to whoever asked. DOCSIS CPE at that time was just an L2 modem. NAT traversal absolutely was not on the table with Packetcable back in the late 90's, and believe me we were very concerned about the security of MGCP since it was UDP based. Which is to say that NAT came around to preserve address space. Any security properties were sort of a post-hoc rationalization and hotly debated given all the things NAT broke. Mike
Re: IPv6 uptake (was: The Reg does 240/4)
Most firewalls are default deny. Routers are default allow unless you put a filter on the interface. NAT adds nothing to security (Bill and I agree to disagree on this), but at best, it complicates the audit trail. Owen > On Feb 16, 2024, at 15:19, Jay R. Ashworth wrote: > > - Original Message - >> From: "William Herrin" > >> 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. >> >> 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. > > You bet. I knew someone would chime in, but whether they'd be agreeing > with me -- as you are -- or yelling at me, wasn't clear. > > It's a default deny (NAT) vs default allow (firewall) question, and > I prefer default deny -- at least inbound. You *can* run NAT as default > deny outbound, too, but it's much less tolerable for general internet > connectivity -- in some dedicated circumstances, it can be workable. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > j...@baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: IPv6 uptake (was: The Reg does 240/4)
> On Feb 16, 2024, at 14:20, Jay R. Ashworth wrote: > > - Original Message - >> From: "Justin Streiner" > >> 4. Getting people to unlearn the "NAT=Security" mindset that we were forced >> to accept in the v4 world. > > NAT doesn't "equal" security. > > But it is certainly a *component* of security, placing control of what > internal > nodes are accessible from the outside in the hands of the people inside. Uh, no… no it is not. Stateful inspection (which the kind of NAT (actually NAPT) you are assuming here depends on) is a component of security. You can do stateful inspection without mutilating the header and have all the same security benefits without losing or complicating the audit trail. Owen
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)
We went pretty deep into the weeds on NAT in this thread - far deeper than I expected ;) 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)? On the last major v6 deployment I did, working with the firewalls was definitely one of the major pain points because the support / stability was really lacking, or there wasn't full feature parity between their v4 and v6 capabilities. Thank you jms On Fri, Feb 16, 2024 at 11:04 PM William Herrin wrote: > 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 2/16/24 5:37 PM, William Herrin wrote: On Fri, Feb 16, 2024 at 5:33 PM Michael Thomas wrote: So you're not going to address that this is a management plain problem. Hi Mike, What is there to address? I already said that NAT's security enhancement comes into play when a -mistake- is made with the network configuration. You want me to say it again? Okay, I've said it again. The implication being that we should keep NAT'ing ipv6 for... a thin veil of security. That all of the other things that NAT breaks is worth the trouble because we can't trust our fat fingers on firewall configs. Mike
Re: IPv6 uptake (was: The Reg does 240/4)
> > 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. > Bill- In a security context, NAT/PAT only provides *obfuscation* of the internal numbering and source ports of the networks on the inside of the NAT/PAT device. "Security by obscurity" is a well debunked maxim by now. Any perceived benefits that obscurity provides are gone as soon as the information attempting to be hidden can be discovered, or the methods by which it functions are known. It may slightly deter the lazy, but techniques to discover the otherwise 'hidden' numbering and port usage have existed for decades. On Fri, Feb 16, 2024 at 10:28 PM William Herrin wrote: > 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)
Again Bill, the NAT process layer is not involved in dropping unwanted traffic until the packet is at least four/five levels deep. On ingress, a firewall will check if there is any flow/stream associated to it, ensure the packet follows the applicable protocol state machine, process it against the inbound interface rules, do any DPI rule processing, THEN NAT lookup, and egress routing + ACLs on the outbound ACL. https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113396-asa-packet-flow-00.html On a standard LAN -> WAN firewall configured with a single public IPv4 IP; your protection comes from the connect state/flow tables primarily. No one would be touching NAT configurations at the same rate as zone and policy configurations, unless it's for complex VPN setups. Using NAT as a defense in depth strategy against deploying v6 is only hurting yourself. I have yet to come across an enterprise that uses it between internal VLANs or policies/zones, where the same threat potential can be, especially in a DMZ. Ryan Hamel From: NANOG on behalf of William Herrin Sent: Friday, February 16, 2024 8:03 PM To: John R. Levine Cc: nanog@nanog.org Subject: Re: IPv6 uptake (was: The Reg does 240/4) Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbill.herrin.us%2F=05%7C02%7Cryan%40rkhtech.org%7C0de6c54d274c4b231dc608dc2f6dc319%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638437395698409506%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=k19sefOjlCNOBGbiAmhzcFszrOEhf8SQQfs0MQThyaU%3D=0<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)
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. Once you start making exceptions, it depends on the nature of the exceptions, the way you tell the router about them (CLI, web crudware, whatever) and doubtless other stuff too. Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
Re: 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)
It appears that William Herrin said: >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. Or you set up port forwarding for some other device but you mistype the internal address an forward it to the switch. Or the switch helpfully uses UPNP to do its own port forwarding and you forget to turn it off. 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. Normally the ISP will give you an IPv6 /56 or larger so you can have multiple segments behind the router each with a /64 and different policies for each segment.
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)
sronan, A subnet can come from the ISP (residential/small business), or business is utilizing BGP with their upstream. When V6 is in use, a firewall does not need to perform NAT, just stateful flow inspection and applying the applicable rules based on the zone and/or interface. Bill, Depending on where that rule is placed within your ACL, yes that can happen with *ANY* address family. --- 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 Ryan Hamel From: NANOG on behalf of sro...@ronan-online.com Sent: Friday, February 16, 2024 5:44 PM To: William Herrin Cc: nanog@nanog.org Subject: Re: IPv6 uptake (was: The Reg does 240/4) Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Why is your Internal v6 subnet advertised to the Internet? > On Feb 16, 2024, at 8:08 PM, William Herrin wrote: > > On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas wrote: >> If you know which subnets need to be NAT'd don't you also know which >> ones shouldn't exposed to incoming connections (or conversely, which >> should be permitted)? It seems to me that all you're doing is moving >> around where that knowledge is stored? Ie, DHCP so it can give it >> private address rather than at the firewall knowing which subnets not to >> allow access? Yes, DHCP can be easily configured to make everything >> private, but DHCP for static reachable addresses is pretty handy too. > > Hi Mike, > > Suppose I have a firewall at 2602:815:6000::1 with an internal network > of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a > switch that accepts telnet connections with a user/password of > admin/admin. On the firewall, I program it to disallow all Internet > packets to 2602:815:6001::/64 that are not part of an established > connection. > > Someone tries to telnet to 2602:815:6001::4. What happens? Blocked. > > Now, I make a mistake on my firewall. I insert a rule intended to > allow packets outbound from 2602:815:6001::4 but I fat-finger it and > so it allows them inbound to that address instead. Someone tries to > telnet to 2602:815:6001::4. What happens? Hacked. > > 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbill.herrin.us%2F=05%7C02%7Cryan%40rkhtech.org%7C5672986956c34e345fd208dc2f5a571c%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638437312255883842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=iuKWxWts%2B9buTCz318C7hz6DbuWSST%2FKPZAWbbhSj8Q%3D=0<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)
Why is your Internal v6 subnet advertised to the Internet? > On Feb 16, 2024, at 8:08 PM, William Herrin wrote: > > On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas wrote: >> If you know which subnets need to be NAT'd don't you also know which >> ones shouldn't exposed to incoming connections (or conversely, which >> should be permitted)? It seems to me that all you're doing is moving >> around where that knowledge is stored? Ie, DHCP so it can give it >> private address rather than at the firewall knowing which subnets not to >> allow access? Yes, DHCP can be easily configured to make everything >> private, but DHCP for static reachable addresses is pretty handy too. > > Hi Mike, > > Suppose I have a firewall at 2602:815:6000::1 with an internal network > of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a > switch that accepts telnet connections with a user/password of > admin/admin. On the firewall, I program it to disallow all Internet > packets to 2602:815:6001::/64 that are not part of an established > connection. > > Someone tries to telnet to 2602:815:6001::4. What happens? Blocked. > > Now, I make a mistake on my firewall. I insert a rule intended to > allow packets outbound from 2602:815:6001::4 but I fat-finger it and > so it allows them inbound to that address instead. Someone tries to > telnet to 2602:815:6001::4. What happens? Hacked. > > 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 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 2/16/24 5:30 PM, William Herrin wrote: On Fri, Feb 16, 2024 at 5:22 PM Michael Thomas wrote: On 2/16/24 5:05 PM, William Herrin wrote: Now, I make a mistake on my firewall. I insert a rule intended to allow packets outbound from 2602:815:6001::4 but I fat-finger it and so it allows them inbound to that address instead. Someone tries to telnet to 2602:815:6001::4. What happens? Hacked. Yes, but if the DHCP database has a mistake it's pretty much the same situation since it could be numbered with a public address. Um. No. You'd have to make multiple mistakes cross-contaminating your public and private ethernet segments yet somehow without completely breaking your network rendering it inoperable. So you're not going to address that this is a management plain problem. ok. Mike
Re: IPv6 uptake (was: The Reg does 240/4)
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 2/16/24 5:05 PM, William Herrin wrote: On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas wrote: If you know which subnets need to be NAT'd don't you also know which ones shouldn't exposed to incoming connections (or conversely, which should be permitted)? It seems to me that all you're doing is moving around where that knowledge is stored? Ie, DHCP so it can give it private address rather than at the firewall knowing which subnets not to allow access? Yes, DHCP can be easily configured to make everything private, but DHCP for static reachable addresses is pretty handy too. Hi Mike, Suppose I have a firewall at 2602:815:6000::1 with an internal network of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a switch that accepts telnet connections with a user/password of admin/admin. On the firewall, I program it to disallow all Internet packets to 2602:815:6001::/64 that are not part of an established connection. Someone tries to telnet to 2602:815:6001::4. What happens? Blocked. Now, I make a mistake on my firewall. I insert a rule intended to allow packets outbound from 2602:815:6001::4 but I fat-finger it and so it allows them inbound to that address instead. Someone tries to telnet to 2602:815:6001::4. What happens? Hacked. Yes, but if the DHCP database has a mistake it's pretty much the same situation since it could be numbered with a public address. For both you can have the default as "reject" or "accept" -- that's just a default and depends on how you want to manage your network. NAT is not without its own set of problems, so if this boils down to a subnet management issue there are obviously ways to deal with that to avoid NAT's problems. Both DHCP and firewall configs don't have to be the ultimate source of truth about any of this. And that's likely a Good Thing since you want them to be pretty much as fungible and replaceable as possible. If you're exposed to fat fingers for either, you're probably already in trouble. Something in the management plain is far more likely to care about this kind of thing than hardware vendors who see that as a cost center with predictably shitty implementations. Mike
Re: IPv6 uptake (was: The Reg does 240/4)
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)
> a lot of folks > making statements about network security on this list don't appear to > grasp it. If your network is secure, it isn’t even possible to “accidentally” open inbound ports in the first place. You either allow it to happen or you don’t via security policy, anything else means your “security” relies on humans not making a mistake, and that’s not security. Using NAT as a “line of defense” means you implicitly don’t trust your authorization system, which means you don't actually have a security posture to begin with. Using the same logic, you might as well go buy another firewall to put in front of your actual Firewall just in case you accidentally misconfigure it. Notice how you’re not actually securing anything, you’re putting a band aid on your insecure process. -Dan > On Feb 16, 2024, at 18:04, William Herrin wrote: > > On Fri, Feb 16, 2024 at 2:19 PM Jay R. Ashworth wrote: >>> From: "Justin Streiner" >>> 4. Getting people to unlearn the "NAT=Security" mindset that we were forced >>> to accept in the v4 world. >> >> NAT doesn't "equal" security. >> >> But it is certainly a *component* of security, placing control of what >> internal >> nodes are accessible from the outside in the hands of the people inside. > > Hi Jay, > > Every firewall does that. What NAT does above and beyond is place > control of what internal nodes are -addressable- from the outside in > the hands of the people inside -- so that most of the common mistakes > with firewall configuration don't cause the internal hosts to -become- > accessible. > > 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: IPv6 uptake (was: The Reg does 240/4)
- Original Message - > From: "William Herrin" > 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. > > 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. You bet. I knew someone would chime in, but whether they'd be agreeing with me -- as you are -- or yelling at me, wasn't clear. It's a default deny (NAT) vs default allow (firewall) question, and I prefer default deny -- at least inbound. You *can* run NAT as default deny outbound, too, but it's much less tolerable for general internet connectivity -- in some dedicated circumstances, it can be workable. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: IPv6 uptake (was: The Reg does 240/4)
On 2/16/24 3:01 PM, William Herrin wrote: On Fri, Feb 16, 2024 at 2:19 PM Jay R. Ashworth wrote: From: "Justin Streiner" 4. Getting people to unlearn the "NAT=Security" mindset that we were forced to accept in the v4 world. NAT doesn't "equal" security. But it is certainly a *component* of security, placing control of what internal nodes are accessible from the outside in the hands of the people inside. Hi Jay, Every firewall does that. What NAT does above and beyond is place control of what internal nodes are -addressable- from the outside in the hands of the people inside -- so that most of the common mistakes with firewall configuration don't cause the internal hosts to -become- accessible. If you know which subnets need to be NAT'd don't you also know which ones shouldn't exposed to incoming connections (or conversely, which should be permitted)? It seems to me that all you're doing is moving around where that knowledge is stored? Ie, DHCP so it can give it private address rather than at the firewall knowing which subnets not to allow access? Yes, DHCP can be easily configured to make everything private, but DHCP for static reachable addresses is pretty handy too. Mike
Re: IPv6 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: IPv6 uptake (was: The Reg does 240/4)
- Original Message - > From: "Justin Streiner" > 4. Getting people to unlearn the "NAT=Security" mindset that we were forced > to accept in the v4 world. NAT doesn't "equal" security. But it is certainly a *component* of security, placing control of what internal nodes are accessible from the outside in the hands of the people inside. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: IPv6 uptake (was: The Reg does 240/4)
On 2/15/24 9:40 PM, Justin Streiner wrote: The Internet edge and core portion of deploying IPv6 - dual-stack or otherwise - is fairly easy. I led efforts to do this at a large .edu starting in 2010/11. The biggest hurdles are/were/might still be: 1. Coming up with a good address plan that will do what you want and scale as needed. It should also be flexible enough to accommodate re-writes if you think of something that needs to be added/changed down the road Several of the resources and books I picked up over the past five years discuss this. At the leaf level, coming up with a address plan is easy. For example, I define two subnets: one for public access, one for LAN use. Each subnet has 64K addresses, far more than I need. The firewall protects the LANnet 2. For providers who run older kit, v6 support might still be a bit dodgy. You might also run into things like TCAM exhaustion, neighbor table exhaustion, etc. The point at which box X tips over is often not well defined and depends on your use case and configuration. Above my use level as a leaf node. It may explain part of the situation I have with my upstream ISP...but I think the problem is more related to account management and not a technical one. 3. The last time I checked, v6 support in firewalls and other middle-mile devices was still poor. Hopefully that has gotten better in the last 6-7 years. My current day job doesn't have me touching firewalls, so I haven't kept up on developments here. I recall coming up with a base firewall ruleset for Cisco ASAs to balance security with the functionality v6 needs to work correctly. Hopefully firewall vendors have gotten better about building templates to handle some of the heavy lifting. In Linux, there have been significant advances in firewall support. Part of that support was in the kernel, part was in the tools. The advent of NFT (NFTABLES) further improves things. My replacement firewall design is to use YAML to define the rules; a Python driver converts the data into rules to implement the policy. Can't speak for others. By the way, instead of improving IPTABLES to handle IPv6, the community build IP6TABLES to support IPv6. I was told that all I needed to do with my BASH-implemented firewall driver was to add IP6TABLE commands to the existing IPTABLES rules. I would have done that if my upstream provider wasn't so IPv6-hostile. I think that would have been a mistake. 4. Getting people to unlearn the "NAT=Security" mindset that we were forced to accept in the v4 world. That was EASY for me to unlearn. With IPv4, I never had the luxury of subnetting large swaths of addresses. With IPv6, that's easy, even in home networks. That said, I'm thinking about giving up completely on IPv6 -- too many hurdles put in the way by my 800-pound-gorilla ISP. I'm too old to fight the battle any more; the ROI isn't worth the effort. I'll be dead before the lack of IPv6 connectivity becomes a personal problem.
Re: IPv6 uptake (was: The Reg does 240/4)
The Internet edge and core portion of deploying IPv6 - dual-stack or otherwise - is fairly easy. I led efforts to do this at a large .edu starting in 2010/11. The biggest hurdles are/were/might still be: 1. Coming up with a good address plan that will do what you want and scale as needed. It should also be flexible enough to accommodate re-writes if you think of something that needs to be added/changed down the road :) 2. For providers who run older kit, v6 support might still be a bit dodgy. You might also run into things like TCAM exhaustion, neighbor table exhaustion, etc. The point at which box X tips over is often not well defined and depends on your use case and configuration. 3. The last time I checked, v6 support in firewalls and other middle-mile devices was still poor. Hopefully that has gotten better in the last 6-7 years. My current day job doesn't have me touching firewalls, so I haven't kept up on developments here. I recall coming up with a base firewall ruleset for Cisco ASAs to balance security with the functionality v6 needs to work correctly. Hopefully firewall vendors have gotten better about building templates to handle some of the heavy lifting. 4. Getting people to unlearn the "NAT=Security" mindset that we were forced to accept in the v4 world. Thank you jms On Thu, Feb 15, 2024 at 8:43 PM John Levine wrote: > It appears that Stephen Satchell said: > >Several people in NANOG have opined that there are a number of mail > >servers on the Internet operating with IPv6 addresses. OK. I have a > >mail server, which has been on the Internet for decades. On IPv4. > > > >For the last four years, every attempt to get a PTR record in ip6.arpa > >from my ISP has been rejected, usually with a nasty dismissive. > > I don't think you'll get much disagreement that AT is not a great ISP. > > One straightforward workaround is to get an IPv6 tunnel from > Hurricane. It's free, it works, and they will delegate the rDNS > anywhere you want. My local ISP doesn't do IPv6 at all (they're a > rural phone company who of course say you are the only person who's > ever asked) so until they do, HE is a quite adequate option. > > R's, > John >
Re: IPv6 uptake (was: The Reg does 240/4)
It appears that Stephen Satchell said: >Several people in NANOG have opined that there are a number of mail >servers on the Internet operating with IPv6 addresses. OK. I have a >mail server, which has been on the Internet for decades. On IPv4. > >For the last four years, every attempt to get a PTR record in ip6.arpa >from my ISP has been rejected, usually with a nasty dismissive. I don't think you'll get much disagreement that AT is not a great ISP. One straightforward workaround is to get an IPv6 tunnel from Hurricane. It's free, it works, and they will delegate the rDNS anywhere you want. My local ISP doesn't do IPv6 at all (they're a rural phone company who of course say you are the only person who's ever asked) so until they do, HE is a quite adequate option. R's, John
Re: IPv6 uptake (was: The Reg does 240/4)
Well all that shows is that your ISP is obstructionist. If they can can enter a PTR record or delegate the reverse range to you for your IPv4 server they can do it for your IPv6 addresses. In most cases it is actually easier as address space is assigned on nibble boundaries (/48, /52, /56, /60, :64) so there isn’t a need to do multiple delegations and RFC2317 style “delegations” aren’t needed in IPv6. If there is a non nibble assignment just do multiple sequential delegations (2, 4 or 8). It isn’t hard to type the reverse prefix into a zone then ns then the name of a server, bump the serial and reload it. e.g. e.b.c.2.6.0.7.d.0.2.2.2.ip6.arpa. ns ns1.example.com. Good luck. -- Mark Andrews > On 16 Feb 2024, at 04:48, Stephen Satchell wrote: > > Several people in NANOG have opined that there are a number of mail servers > on the Internet operating with IPv6 addresses. OK. I have a mail server, > which has been on the Internet for decades. On IPv4. > > For the last four years, every attempt to get a PTR record in ip6.arpa from > my ISP has been rejected, usually with a nasty dismissive. > > Today, I'm trying again to get that all-important PTR record. If I'm > successful, then I expect to have my mail server fully up and running in the > IPv6 space within 72 hours, or when the DNS changes propagate, whichever is > longer.