Mailing List Archive

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 <list@satchell.net> 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.

It appears that Stephen Satchell <list@satchell.net> 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&T 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

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 <johnl@iecc.com> wrote:

> It appears that Stephen Satchell <list@satchell.net> 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&T 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
>

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.

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

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra@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

On Fri, Feb 16, 2024 at 2:19?PM Jay R. Ashworth <jra@baylink.com> wrote:
> > 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.

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
bill@herrin.us
https://bill.herrin.us/

On 2/16/24 3:01 PM, William Herrin wrote:
> On Fri, Feb 16, 2024 at 2:19?PM Jay R. Ashworth <jra@baylink.com> wrote:
>>> 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.
> 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

----- Original Message -----
> From: "William Herrin" <bill@herrin.us>

> On Fri, Feb 16, 2024 at 2:19?PM Jay R. Ashworth <jra@baylink.com> wrote:
>> > 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.
>
> 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 jra@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

> 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 <bill@herrin.us> wrote:
>
> ?On Fri, Feb 16, 2024 at 2:19?PM Jay R. Ashworth <jra@baylink.com> wrote:
>>> 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.
>
> 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
> bill@herrin.us
> https://bill.herrin.us/

> 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 <bill@herrin.us> wrote:
>
> ?On Fri, Feb 16, 2024 at 2:19?PM Jay R. Ashworth <jra@baylink.com> wrote:
>>> 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.
>
> 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
> bill@herrin.us
> https://bill.herrin.us/

On Fri, Feb 16, 2024 at 3:13?PM Michael Thomas <mike@mtcc.com> 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
bill@herrin.us
https://bill.herrin.us/

On 2/16/24 5:05 PM, William Herrin wrote:
> On Fri, Feb 16, 2024 at 3:13?PM Michael Thomas <mike@mtcc.com> 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

On Fri, Feb 16, 2024 at 5:22?PM Michael Thomas <mike@mtcc.com> 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
bill@herrin.us
https://bill.herrin.us/

On 2/16/24 5:30 PM, William Herrin wrote:
> On Fri, Feb 16, 2024 at 5:22?PM Michael Thomas <mike@mtcc.com> 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

On Fri, Feb 16, 2024 at 5:33?PM Michael Thomas <mike@mtcc.com> 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
bill@herrin.us
https://bill.herrin.us/

Why is your Internal v6 subnet advertised to the Internet?

> On Feb 16, 2024, at 8:08?PM, William Herrin <bill@herrin.us> wrote:
>
> ?On Fri, Feb 16, 2024 at 3:13?PM Michael Thomas <mike@mtcc.com> 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
> bill@herrin.us
> https://bill.herrin.us/

On Fri, Feb 16, 2024 at 5:45?PM <sronan@ronan-online.com> 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
bill@herrin.us
https://bill.herrin.us/

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 <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of sronan@ronan-online.com <sronan@ronan-online.com>
Sent: Friday, February 16, 2024 5:44 PM
To: William Herrin <bill@herrin.us>
Cc: nanog@nanog.org <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 <bill@herrin.us> wrote:
>
> ?On Fri, Feb 16, 2024 at 3:13?PM Michael Thomas <mike@mtcc.com> 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
> bill@herrin.us
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbill.herrin.us%2F&data=05%7C02%7Cryan%40rkhtech.org%7C5672986956c34e345fd208dc2f5a571c%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638437312255883842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=iuKWxWts%2B9buTCz318C7hz6DbuWSST%2FKPZAWbbhSj8Q%3D&reserved=0<https://bill.herrin.us/>

On Fri, Feb 16, 2024 at 6:10?PM Ryan Hamel <ryan@rkhtech.org> 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
hostmaster@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
bill@herrin.us
https://bill.herrin.us/

It appears that William Herrin <bill@herrin.us> 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.

On Fri, Feb 16, 2024 at 7:10?PM John Levine <johnl@iecc.com> 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
bill@herrin.us
https://bill.herrin.us/

> 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, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Fri, Feb 16, 2024 at 7:41?PM John R. Levine <johnl@iecc.com> 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
bill@herrin.us
https://bill.herrin.us/

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 <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of William Herrin <bill@herrin.us>
Sent: Friday, February 16, 2024 8:03 PM
To: John R. Levine <johnl@iecc.com>
Cc: nanog@nanog.org <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 <johnl@iecc.com> 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
bill@herrin.us
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbill.herrin.us%2F&data=05%7C02%7Cryan%40rkhtech.org%7C0de6c54d274c4b231dc608dc2f6dc319%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638437395698409506%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=k19sefOjlCNOBGbiAmhzcFszrOEhf8SQQfs0MQThyaU%3D&reserved=0<https://bill.herrin.us/>