Re: [v6ops] Thoughts about wider operational input

["Ackermann, Michael" <[e-mail]>]

Hi Nick

As a typical clueless enterprise guy, I am not only way behind in responding to  emails and to your note below,  but also attempting to get good info & advice from all the messages on this chain from you and Joe and Simon, Paolo  and many other SME's who have responded.
My belated response to what you wrote below, is that it sounds well thought out,  objective and pretty right on to me,  based on my experiences.
At most organizations I work with or talk to,  NAT is not going away,  no matter what we think or say.   I say sometimes that it has become part of our network architecture thinking.   This was originally due to address limitations and (decreasingly now) due to perceived Security benefits.  You called that address obfuscation and that seems to be the most prevalent security sub driver, I see.   We now have FWs, Proxies, IPS, micro segmentation and many other Security tools and techniques that may obviate the need for NAT in most situations, but like you say,  IT AIN'T GOIN AWAY.

I also agree that enterprises are driven by cost and risk models.   Part of that is that if something appears to be working today, we are concerned that if we change it,  in any way,  that introduces risk.   Another reason NAT AIN'T GOIN AWAY SOON,  even if we do find better alternatives and set new directions.
I personally am in favor of NAT reduction or elimination because my role is primarily: diagnostics, performance and monitoring,  all of which NAT certainly does not help me with.   But in the bigger picture there are those that think they still want/need it, so I accept that.

But what I also say,  to the few enterprises that listen to ANYTHING about IPv6,  is that if we continue to scale NAT up,  at the pace we historically have,  the NAT solution may become a problem or the source of  problems on it's own.    So we need to consider alternatives.  And,  that IPv6 may provide some better alternatives.   I then (if anyone is still listening),  go on to talk about GUA end to end (which I think will be great for some,  but not all situations), or ULAs, etc.      My hope/dream is that these and other alternatives eventually produce deployments with less NAT,  but even in my dreams it may not all be eliminated.

What I would like to know,  from all of you SME's,  is if what I am saying in the previous paragraph, is good advice to prospective IPv6 enterprises and if I should change or add anything?      I definitely do not want to give enterprises any bad advice,  because if we/they finally do go down the IPv6 road,  and have issues,  they will recoil.   And we will have lost another decade.
For example I do frequently get interest & questions about ULA implementations and usually provide caveats that ULA still has some issues that need to be addressed, before enterprises seriously deploy it.   But there are some very good people already looking into this and I have great confidence that these issues will be handled.

So once again thanks for all the great info / advice  and my ears are wide open for more.

Have a great weekend all!

Mike

From: v6ops <[e-mail]> On Behalf Of Nick Buraglio
Sent: Thursday, March 31, 2022 5:33 PM
To: Simon <[e-mail]>
Cc: v6ops list <[e-mail]>
Subject: Re: [v6ops] Thoughts about wider operational input

[External email]
For 20+ years security vendors have conflated NAT and Firewall. That isn't going to go away, frankly, and from the point of view of the security engineer at an organization of a sufficient size, it doesn't matter if it is technically correct or not. Obfuscating addressing is a very engrained design model, largely because of this fact. I believe there is no a way around that at least in the short term, probably also in the long term.
Understanding that what "enterprises" want is going to be driven by two things: cost and risk. Address obfuscation is very, very, very (95%?) present in enterprise architectures. Deviating from that is largely a non-starter because it deviates from existing risk profiles and completely changes the decades old architectures of application proxies and address translation devices in strategic locations and like Joe M. has stated, the fail closed model is by-and-large a requirement for many large organizations.
If we want to understand what the enterprises want, we need to understand their cost models and risk profiles.  Enterprises aren't going to fret much about state tables, they'll buy bigger boxes. They aren't going to worry as much about performance as, say, a service provider or a supercomputing center. They care that their compliance requirements are met [see address obfuscation, default deny, etc.], that their risk remains as low as possible, and that their widget sells.
I hate to say it because I truly want the end to end connectivity, but I believe that address translation with IPv6 is not going anywhere, and in fact, will probably encourage deployment of v6 in the enterprise space.  It's a useful tool to get to where they want to be (again, see risk and cost).
I think we need to rectify the fact that enterprises don't necessarily want end to end connectivity for the above reasons, and I have seen significant evidence pointing to that fact.

nb

On Thu, Mar 31, 2022 at 12:33 PM Simon <[e-mail]<mailto:[e-mail]>> wrote:


> On 30 Mar 2022, at 21:16, Joe Maimon <[e-mail]<mailto:[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.

ONLY if you start from the premise that NAT is not in fundamental conflict with IP basics - namely that "packets can be routed from any end point to any other end point" (with the modern security proviso of "subject to administrative policies".)
In any case, I'm used to configuring a firewall anyway. Most CE devices come with a stateful firewall installed and configured - most of them even with sensible defaults !

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

Not for IPv6. You are applying the "lets take IPv4 with all its faults and tack on some extra address bits" attitude. We should be taking the opportunity to fix the things that weren't perfect/right with IPv4.
And for the record, in my last job we were lucky enough to have a whole /24 to play in - and we did, without NAT for the most part. And guess what, it worked very well thank you.
NAT is not strictly an operation requirement anyway, NAT is a sticking plaster on the festering sore of insufficient IP addresses. I would argue that NAT is the fundamental evil that is holding back adoption of a proper fix to the underlying problem - because it's been "sold" as a solution by people who do not also mention that it's broken and should be treated as a stopgap at most rather than the saviour of the internet it's been hailed as.

Most of the discussions in this thread have come down to "the problems with NAT haven't been a big enough pain point to trigger properly adopting IPv6" - mostly because many of the people making the decisions don't actually get to see the problems and costs they are subjected to.
In a way there's a parallel with the Y2k problem - I was one of many IT people doing work up front only to have both users and management ask "so what was the fuss about". Of course, by fixing most problems invisibly up front, and the remaining ones as they cropped up, management never saw the underlying problem.


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

> 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 ? Either that, or it's a protocol violation to run a service on anything but ports 80 and 443 ? Put another way, it's a protocol violation to have a link to say my server:8443 ?

> 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.

The device (lets assume a simple phone to keep things simple) needs to talk SIP in order to control sessions. But it makes complete sense to use a different protocol to transfer the audio streams (multiple) - and note what I said about the audio streams not necessarily going to the same place as the SIP user registration.
What you've said is that it should be "illegal" to allow my phone to exchange audio streams directly with someone else's phone - OSI layer violation. Yet that is the most efficient way to do it (where it's possible). The alternative is something like IAX where the application is effectively embedding a chunk of protocol stack - the ability to multiplex the packets of multiple streams inherent in IP (TCP or UDP) over one network - into the application. And in the world where all the traffic must be carried in one session, it means your voice traffic must pass through an "exchange" at both ends, adding delay and jitter as well as processing load to what would otherwise be a very lightweight application.

>> 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.

Again, citation. According to whom, other than the "NAT is beautiful" brigade are they broken ?

> RAM is cheap.

Not in many lightweight devices it isn't.



Simon

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


The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.


This message was secured by Zix(R).