4 ms·

It's not really computationally expensive, it's memory expensive. You need per connection state.

by xxpor 3y ago

blibble 3y ago
it already has stateful firewall so that's: source ip, dest ip, protocol, source port, dest port, connection state (say 16 bytes total) doing NAT too is what, 3 more bytes per connection (8 bits for an offset into an IP table and 16 bits for the translated port)
- p1mrx 3y ago
  Generally an ISP does not have a stateful firewall prior to deploying CGNAT.
- dijit 3y ago
  NAT and Stateful firewalling are commonly bundled together (especially on home systems) but I would not go so far as to say “NAT has a stateful firewall”- I hear such takes all the time and its really frustrating; usually in threads regarding IPv6, incidentally it is usually programmers who think they understand everything about networks because they know how tcp operates.
  - blibble 3y ago
    > but I would not go so far as to say “NAT has a stateful firewall”- > I hear such takes all the time and its really frustrating maybe you'd be less frustrated if you understood what people were saying, because I didn't say that AWS already do 1:1 NAT and there's additionally a stateful firewall, which necessitates connection state tracking adding the extra few bytes to do port translation shouldn't vastly increase the memory required > incidentally it is usually programmers who think they understand everything about networks because they know how tcp operates. from someone who has written a commercial packet filter: in terms of complexity, TCP blows the preceding layers of the stack out of the water
  - lxgr 3y ago
    In almost all NAT implementations, public-side ports are dynamically assigned, which implies that inbound connections aren't possible (unless port forwarding is explicitly configured). Is that really conceptually so different from a stateful firewall allowing inbound packets only for established connections/flows? "NATs are good because otherwise people wouldn't have any firewalls" is a tired take, yes, but I don't see the point being needlessly pedantic about the semantics of NAT vs. stateful firewalls when in this case, the effect is the same: No inbound packets without prior outbound packets (or a connection establishment for TCP).

It's not really computationally expensive, it's memory expensive. You need per connection state.

by xxpor 3y ago

It's not really computationally expensive, it's memory expensive. You need per connection state.

it already has stateful firewall so that's: source ip, dest ip, protocol, source port, dest port, connection state (say 16 bytes total) doing NAT too is what, 3 more bytes per connection (8 bits for an offset into an IP table and 16 bits for the translated port)

p1mrx 3y ago
Generally an ISP does not have a stateful firewall prior to deploying CGNAT.
dijit 3y ago
NAT and Stateful firewalling are commonly bundled together (especially on home systems) but I would not go so far as to say “NAT has a stateful firewall”- I hear such takes all the time and its really frustrating; usually in threads regarding IPv6, incidentally it is usually programmers who think they understand everything about networks because they know how tcp operates.
- blibble 3y ago
  > but I would not go so far as to say “NAT has a stateful firewall”- > I hear such takes all the time and its really frustrating maybe you'd be less frustrated if you understood what people were saying, because I didn't say that AWS already do 1:1 NAT and there's additionally a stateful firewall, which necessitates connection state tracking adding the extra few bytes to do port translation shouldn't vastly increase the memory required > incidentally it is usually programmers who think they understand everything about networks because they know how tcp operates. from someone who has written a commercial packet filter: in terms of complexity, TCP blows the preceding layers of the stack out of the water
- lxgr 3y ago
  In almost all NAT implementations, public-side ports are dynamically assigned, which implies that inbound connections aren't possible (unless port forwarding is explicitly configured). Is that really conceptually so different from a stateful firewall allowing inbound packets only for established connections/flows? "NATs are good because otherwise people wouldn't have any firewalls" is a tired take, yes, but I don't see the point being needlessly pedantic about the semantics of NAT vs. stateful firewalls when in this case, the effect is the same: No inbound packets without prior outbound packets (or a connection establishment for TCP).