Re: [v6ops] Thoughts about wider operational input

[Joe Maimon <[e-mail]>]

Simon wrote:
>
>> On 30 Mar 2022, at 21:16, Joe Maimon <[e-mail]> wrote:
>> JORDI PALET MARTINEZ wrote:
>>> Because if you don't have NAT, you are forced to properly configure a firewall.
>> That is backwards.

Its backwards because the previous statement is only (partially) true 
when reversed.

When you have uni-directional NAT, such as NAPT44, you are forced to 
operate in a condition equivalent to having a firewall with a default 
deny-all(deny-most?) incoming policy.

When you have either IPv4 or IPv6 without that, you may or may not have 
a firewall, properly configured or otherwise.


>>
>> NAT is an operational requirement. You have it because without it something does not work the way you want it to.
> Not for IPv6.

Yes, precisely, which is why IPv6 is more likely to be less secure by 
default for its users. And for it to be at least as secure requires much 
greater efforts in multiple directions.

  You are applying the “lets take IPv4 with all its faults and tack on some extra address bits” attitude.


Dont put words in my mouth. I have no lack of them. My opinion on NAT 
with regard to IPv6 is that its a tool and if people want to use it, it 
should be standardized and available. How about less judgement on other 
peoples choices?

As far as IPv4 with more bits as a better approach to second system 
effect resulting in IPv6? The verdict on that has been in a long time 
ago. It would have been the smart play.

NAT is not an IPv4 fault. Its extremely wide spread adoption is due to 
IPv4 chief fault, only 32 bits.

> We should be taking the opportunity to fix the things that weren’t perfect/right with IPv4.
You tried, you failed.
>
> NAT is not strictly an operation requirement anyway,
For the vast majority of internet users today it is.
> NAT is a sticking plaster on the festering sore of insufficient IP addresses.

Or, NAT is a rather elegant method of multiplexing limited addressing as 
well as supplying other properties that may or may not have value to the 
user of the NAT.

Or did you like the sock proxy days?

That is negatively affects the  end2end dream? Insufficient addresses 
and the general insecurity of the net, vendor behavior, as well as the 
content concentration all did that together.

That it breaks protocols? They get fixed and life goes on. And protocols 
should not have been so brittle.

Side channel setup should have been standardized and used in a method 
that would have made it a fix-it-once problem for NAT's (and firewalls).

>> On 30 Mar 2022, at 22:22, Joe Maimon <[e-mail]> wrote:
>>
>>
>>
>> Simon wrote:
>>> 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.
> Citation ?

https://www.rfc-editor.org/rfc/rfc3724.html

Since the upper level protocol incorporates lower level properties into 
its functionality, it is now dependent on them.

The point I am trying to bring out is that it a valid exercise to 
re-examine the premise, namely that the protocol design was the correct 
and best way to go about it and the network should never have broken it.

I just think we would have been better off if doing that sort of thing 
required some sort of justification perhaps some amount of automatic 
recovery to an alternate, perhaps less efficient method. Some more 
robustness.

>> 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.
> So do you agree that HTTP is fundamentally broken then

A layer violation isnt automatically broken. Its just a red flag that 
maybe you should be rethinking that approach. Thats what design 
principals are for.

>   ? Either that, or it’s a protocol violation to run a service on anything but ports 80 and 443

This particular problem was part of what SRV records try to address.

> ? Put another way, it’s a protocol violation to have a link to say my server:8443 ?

HTTP does not require knowledge of specific port numbers to operate, so 
just because you have embedded it with URL's does not mean that HTTP is 
violating that design principle. Perhaps you are, especially if you dont 
actually control which port actually accepts that connection.

>
>> Just because its common and convenient and usually works or can be made to work does not make it correct.
> And of course, it’s usually done because it is the most sensible way to do it. Lets look at SIP for an example.

This is a great example. SIP was so broken from the get go that it gave 
birth to the SBC. The thing it had going for it was that it was easier 
to fix than H323. And its not like NAT wasnt a thing when it was in 
infancy. Now imagine if there had been much more rigorous attention and 
design to opportunistically creating side channels while preserving the 
ability to transmit data within the channel.

Like SSH does.

Its not just NAT that endangers protocols that do these things, 
firewalls do as well. So lets just strip NAT from this aspect of the 
conversation and now we are just talking about proper firewall friendly 
protocol design. Or do you consider firewalls a fundamental evil as well?

Firewalls exist because of the existence of a fundamental evil present 
in any sufficiently large network. So I guess you would be correct with 
the label, just not where you stuck it.

>> RAM is cheap.
> Not in many lightweight devices it isn’t.

You cant get a smartphone without gigs of ram today. Thats more memory 
than your honking server had back in the day. Yes it is cheap.

>
>
> Simon
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>