RE: IPv4 flag day

[Gary Sparkes via NANOG <nanog () lists nanog org>]

My main point boils down to NAT extending and providing additional vectors and complexity above and beyond just a 
firewall. Heck, as a component alone it's a DoS vector as well. See: https://arxiv.org/html/2410.21984v1

This ONE technique we've been discussing - note that we've only been discussing one that I have experience with using 
for legitimate purposes - is neat in expanding the scope of attackability and flexibility. Not needing to control any 
aspect of network on any end at all. But it's not the only way. 

As for the beachhead, it could be as simple as a web page loading something in the background. Doesn't have to be fancy 
like a dedicated VPN appliance plugged into a person's desk.

For ICMP, we really only need timeout exceeded and echo request/reply, packet too large isn't required (and that's what 
breaks PMTU) nor is dest unreach. 

With some kind of C&C infra, of course, it provides far more options. Game development libraries are especially useful 
as starting points here. Ancient Skype was my favorite example of easily getting around corporate firewalls in the past.

If we want to get fancier, we can go this route if ALGs are in play - https://github.com/samyk/slipstream, for example. 
(mitigations and detections have since become available, this was in 2020, but it's still useful in some aspects) - 
article about this one: 
https://www.securityweek.com/nat-slipstreaming-visiting-malicious-site-can-expose-local-network-services-remote-attacks/

Or this - https://samy.pl/natpin/ - (no idea if it still works, it's from 2010, but it was just a web page that'd port 
forward any arbitrary port back to the machine it ran on, written in just javascript)

There are, of course, many ways to tighten and mitigate a portion of potential vectors, and not all apply to every 
situation (like the ALG route above). But, that's again, throwing more and more complexity and management on top of 
what a simple firewall would otherwise handle in a much cleaner, clearer, and safer way. 

And not all NAT implementations are created equal.... https://ieeexplore.ieee.org/document/11076087 

Tl;dr https://weberblog.net/why-nat-has-nothing-to-do-with-security/

(I probably should note that all this only applies to PAT type NAT)

All that being said, all types of NAT are useful and have advantages in plenty of scenarios and shouldn't be avoided, 
just approached and managed carefully as deployed. But removing NAT removes operational complexity and additional 
vectors. 

-----Original Message-----
From: William Herrin via NANOG <nanog () lists nanog org> 
Sent: Thursday, June 18, 2026 10:29 PM
To: Arie Vayner <ariev () vayner net>
Cc: North American Network Operators Group <nanog () lists nanog org>; William Herrin <bill () herrin us>
Subject: Re: IPv4 flag day

On Thu, Jun 18, 2026 at 12:55 PM Arie Vayner <ariev () vayner net> wrote:
> Unless I'm missing something, the pwnat mechanism will actually work 
> through any stateful packet inspection (be it NAT or just a firewall) 
> that allows Traceroute to work.


Hi Arie,

You're not missing anything. It's a novel mechanism for escalating a beachhead, but Gary hasn't explained why it 
wouldn't work just as well with any other firewall that allows internal machines to initiate outbound connections by 
default. Everybody needs ICMP destination unreachable messages from arbitrary sources to reach back to the origin. Path 
MTU discovery fails if they do not. With any kind of firewall. ICMP Time exceeded is not as crucial but traceroute 
breaks without it so most firewalls propagate it inward too.

Interesting as it is, the thought experiment fails to support Gary's claim that NAT specifically makes a network 
vulnerable.

Regards,
Bill Herrin

--
For hire. https://bill.herrin.us/resume/ _______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/4RW6QTMWCWBJWKQHGSIWXQERC7OUQZDL/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/2R4V523OAVCK6XB77A2LLQSGQL6G5AT3/