Re: [v6ops] Thoughts about wider operational input

Simon wrote:
> On 30 Mar 2022, at 07:31, Chongfeng Xie <xiechf@chinatelecom.cn 
> <mailto:xiechf@chinatelecom.cn>> wrote:
>
>> Hi， Mark，
>> Some enterprises do not want to expose their real address in the 
>> network to the outside, so they will use NAT, whether nat44 or nat64 
>> or even nat66 in the future. Therefore, NAT may always exist with the 
>> needs of customers.
>>
>> The technology itself is not right or wrong. It is inappropriate to 
>> directly state whether a technology is good or bad, but whether the 
>> technology is appropriate for specific scenarios. You said there was 
>> a lot of issues with IPv6+NAT，under what scenario? What's are the 
>> issues ? Is it a stateless IPv6+NAT or a stateful IPv6+NAT?
>
> Any form of NAT breaks things<period> That’s the short answer.
>
> Longer answer, any protocol that embeds addresses in it gets broken - 
> e.g. during session setup one end tells the other, please contact me 
> at address X and port Y. That is quite common once you get past a 
> basic “open connection, squirt some data, close session”. Examples 
> that come immediately to mind :

In OSI speak thats a layering violation. An upper level protocol 
incorporates details and assumptions about lower layers as part of its 
operations. Unfortunately, TCP/IP and its application protocols are rife 
with them. Well more than one should expect were proper attention have 
been given to ensure that there was absolutely no equivalent proper way 
to do it.

Just because its common and convenient and usually works or can be made 
to work does not make it correct. Worse, sometimes its considered quite 
clever. PMTUD comes to mind.

<snip>
>
> They all involve developers, and support people, putting effort into 
> implementing the workaround code and support (e.g. adding the settings 
> to the config pages) and users waste effort getting them set up right. 
> All effort that could be better put to productive use rather than 
> fighting broken networks.

In theory, the protocols are broken. If they hadnt taken the easy way 
out, we would not have to work around so many of them.

<snip>
>
>
>
> NAT does no more than even the most basic packet-filter firewall can 
> do if set to a  default of “deny inbound, permit outbound”.

Correct. Which is a good thing. The point is that if turning off NAT 
means no internet communications, you can be fairly certain it will be 
on. No such assumption exist without NAT.

IPv4 NAPT comes a lot closer to secure by default than IPv6 with basic 
state aware packet filters.

> How many decades have all the relevant OSs supported at least a basic 
> packet filter ?

NAT was widespread well before state tracking packet filters were.

> What’s more, a basic packet filter needs less resources (no connection 
> tracking table) than a NAT gateway - a stateful firewall will need (I 
> think) a similar level of resources in terms of tracking connections 
> (perhaps a bit less as it doesn’t need to store two address/port pairs 
> for the inside end of each connection like a NAT gateway does).
>
>
> Simon
>
>
RAM is cheap. Lookup per packet is expensive.

It should be obvious that state-less packet filters are rarely useful or 
even used on the internet of today.

Thats because along with not keeping state, they also require you to do 
things like this if you want your users to browse the web.

access-list out permit any any tcp port 80
access-list in permit any tcp port 80 any port range 1025-65535

Not very convenient or secure.

I know when I can use them and its for situations where the traffic 
flows are extremely well and tightly defined.

Keeping state is what allows a packet filter to have meaningful security 
AND still allow practical bi-directional traffic.

And at that point its the same tracking code as the translation feature 
would need. Not having to munch and mangle bits is some amount of 
performance win, but thats not what you were describing.

State-less packet filters are not germain to an IPv6 vs NAT security 
discussion.

Joe
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops