Re: [v6ops] Thoughts about wider operational input

[Nick Buraglio <[e-mail]>]

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]> 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.
>
> 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]> 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]
> https://www.ietf.org/mailman/listinfo/v6ops
>