Re: IPv4 flag day

On Thu, Jun 18, 2026 at 9:03 AM Gary Sparkes <[email protected]> wrote:
> Code running in a browser isn't a concern? That foothold can be extremely minimal, non-persistent, and enable far greater attack/leveraging than otherwise available.
>
> But yes, this technique of allowing inbound traffic flows to bypass NAT is something that's somewhat common (STUN servers anyone?) to support NAT legitimately, so it's hard to keep out of the mix.
>
> As I've noted in previous parts of this discussion, this is an example of the kind of NAT support network code I've ripped out of applications I maintain. So in 1:many NAT scenarios, it's no longer plug-and-play. But it's far simpler and easier to maintain.


Hi Gary,

Configure two firewalls identically. Changing nothing else, configure
the second to implement 1:many NAT. Now, demonstrate a use of the
technology you describe here where the NAT version of that firewall is
more vulnerable than with the one without it.

Your claim was that NAT _enables_ the sort of attack you describe.
That it is vulnerable when the alternative is not. Show me.

No one in this discussion has posited that NAT is a cure-all against
every attack vector. I think you're probably arguing against a straw
man.

Regards,
Bill Herrin


-- 
For hire. https://bill.herrin.us/resume/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/H6LVYI5EHCGJJ4M7FB2A3DWAH2WDKZZR/