Mailing List Archive

On Sun, 18 Feb 2024, 05:29 Owen DeLong via NANOG, <nanog@nanog.org> 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

>

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&T and all of the mobile carriers.

Lee

-----Original Message-----
From: NANOG <nanog-bounces+leehoward=hilcostreambank.com@nanog.org> 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 mike@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 <bill@herrin.us> wrote:
>> On Sat, Feb 17, 2024 at 10:34?AM Michael Thomas <mike at mtcc.com> 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

Bottom-posted with old school formatting by hand.

-----Original Message-----
From: NANOG <nanog-bounces+leehoward=hilcostreambank.com@nanog.org> On Behalf Of William Herrin
Sent: Friday, February 16, 2024 8:05 PM
To: Michael Thomas <mike@mtcc.com>
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

On Mon, Feb 19, 2024 at 5:29?AM Howard, Lee via NANOG <nanog@nanog.org> 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
bill@herrin.us
https://bill.herrin.us/

" 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. When ISP fails, traffic will have to exit ISP B. He's not getting a /48, LOA, BGP, etc. to do it on his own, he's just going to do simple NAT.



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

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

----- Original Message -----

From: "Michael Thomas" <mike@mtcc.com>
To: nanog@nanog.org
Sent: Saturday, February 17, 2024 12:50:46 PM
Subject: Re: IPv6 uptake


On 2/17/24 10:26 AM, Owen DeLong via NANOG wrote:
>
>> On Feb 16, 2024, at 14:20, Jay R. Ashworth <jra@baylink.com> wrote:
>>
>> ----- Original Message -----
>>> From: "Justin Streiner" <streinerj@gmail.com>
>>> 4. Getting people to unlearn the "NAT=Security" mindset that we were forced
>>> to accept in the v4 world.
>> NAT doesn't "equal" security.
>>
>> But it is certainly a *component* of security, placing control of what internal
>> nodes are accessible from the outside in the hands of the people inside.
> Uh, no… no it is not. Stateful inspection (which the kind of NAT (actually NAPT) you are assuming here depends on) is a component of security. You can do stateful inspection without mutilating the header and have all the same security benefits without losing or complicating the audit trail.

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

Mike

On Mon, Feb 19, 2024 at 6:52?AM Mike Hammett <nanog@ics-il.net> 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
bill@herrin.us
https://bill.herrin.us/

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


This sounds like a disaster.



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

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

----- Original Message -----

From: "William Herrin" <bill@herrin.us>
To: "Mike Hammett" <nanog@ics-il.net>
Cc: nanog@nanog.org
Sent: Monday, February 19, 2024 9:16:52 AM
Subject: Re: IPv6 uptake

On Mon, Feb 19, 2024 at 6:52 AM Mike Hammett <nanog@ics-il.net> 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
bill@herrin.us
https://bill.herrin.us/

On Mon, Feb 19, 2024 at 6:02?AM Howard, Lee
<LeeHoward@hilcostreambank.com> 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
bill@herrin.us
https://bill.herrin.us/

>
> 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. When ISP fails, traffic will have to exit ISP B. He's not
> getting a /48, LOA, BGP, etc. to do it on his own, he's just going to do
> simple NAT.


If you are asserting that the business is just taking the
dynamic allocations from ISP A and ISP B, and NAT'ing internal stuff to
those , then sure, that works, until ISP A goes down, and the NAT device
must detect that so it no longer uses those addresses until it comes back
up. Which is of course doable, but is no longer 'simple' NAT.

On Mon, Feb 19, 2024 at 9:53?AM Mike Hammett <nanog@ics-il.net> 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. When ISP fails, traffic will have to exit ISP B. He's not
> getting a /48, LOA, BGP, etc. to do it on his own, he's just going to do
> simple NAT.
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> ------------------------------
> *From: *"Michael Thomas" <mike@mtcc.com>
> *To: *nanog@nanog.org
> *Sent: *Saturday, February 17, 2024 12:50:46 PM
> *Subject: *Re: IPv6 uptake
>
>
> On 2/17/24 10:26 AM, Owen DeLong via NANOG wrote:
> >
> >> On Feb 16, 2024, at 14:20, Jay R. Ashworth <jra@baylink.com> wrote:
> >>
> >> ?----- Original Message -----
> >>> From: "Justin Streiner" <streinerj@gmail.com>
> >>> 4. Getting people to unlearn the "NAT=Security" mindset that we were
> forced
> >>> to accept in the v4 world.
> >> NAT doesn't "equal" security.
> >>
> >> But it is certainly a *component* of security, placing control of what
> internal
> >> nodes are accessible from the outside in the hands of the people inside.
> > Uh, no… no it is not. Stateful inspection (which the kind of NAT
> (actually NAPT) you are assuming here depends on) is a component of
> security. You can do stateful inspection without mutilating the header and
> have all the same security benefits without losing or complicating the
> audit trail.
>
> Exactly. As I said elsewhere, the security properties of NAT were a
> post-hoc rationalization. In the mean time, it has taken on its own life
> as if not NAT'ing (but still having stateful firewalls) would end the
> known security universe. We can seriously lose NAT for v6 and not lose
> anything of worth.
>
> Mike
>
>
>
>