NAT, ATM, decentralized search – and other outrageous opinions from the 1990s

The end of the year is often a time for people in tech to make predictions, but rather than making our own, today we’ll look back on some of the bold predictions of the past – specifically the inaugural Outrageous Opinion session held at SIGCOMM in 1995. One of my most lasting contributions to the SIGCOMM community would have …

[Flak]

Year End Reminiscing

Thank you for the memory lane, which pretty much spans my career in this sector, which much of it spent in the carrier / service provider space.

My fascination at the beginning was with ISDN and SDH as deterministic technologies, followed by (Frame Relay and) ATM. I was obsessed with QoS which I thought was absolutely vital for services such as digital voice and video. And it probably was at the time, with other packet based technologies such as Ethernet and MPLS and real time, rate adaptive codecs for voice and video still in their infancy.

I remember talking to a client about their Cisco CallManager installation (early 2000's) and they told me they ran it on a LAN that didn't have QoS enabled. I could not believe it at the time and asked them about performance. Some 500 staff used that system in a single building (calls out still relied on ISDN30) without any complaints from staff. Their view was that bandwidth overprovision made QoS on the LAN irrelevant to them.

Today, I see their outrageous opinion as visionary. It has borne out in reality where people work from home on domestic Wifi with voice and video calls.

Another outrageous opinion came from a UK local authority IT director who said around 2010 that he would like to see his whole council just communicating over the Internet - not via an MPLS VPN. To me he was a total heretic at the time, but I think today this would be (almost) entirely possible.

Keep them coming please, always willing to learn.

While some may not stand the test of time, others will and may prove to be prophetic!

[Malcolm Weir]

Re: Year End Reminiscing

As engineers, we tend to like elegant and efficient solutions. But time after time it turns out that inelegant and/or inefficient approaches Work Just Fine if you throw enough resources at the problem, which is usually easier and often much cheaper. For example, Fibre Channel is extremely elegant as a technology, but for only a trivial amount of money you can get an appreciable fraction of a terabit of Ethernet, which will sledgehammer the problem; deterministic solutions are great, but with enough gigahertz cores you can sweep most of those concerns under the rug; spatial efficiency is cool, but another few gigabytes isn't going to break the bank... etc.

[Version 1.0]

Re: Year End Reminiscing

An accurate statement from an earlier environment:

"Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin." - John von Neumann, 1951.

[toejam++]

Re: Year End Reminiscing

The cheap sledgehammer approach is what killed ATM at my employer in '99. We were rolling ATM across the campus to support voice and data. Then some 3Com Corebuilder and Superstack kit ended up in our lab. The combination of 802.3ad and 802.1Q across Gigabit Ethernet gave us fat pipes on the cheap, with quality of service to keep voice flowing during the rare edge case where something saturated the backhaul links. Not having to mess with LANE was just icing on the cake.

[Jellied Eel]

Re: Year End Reminiscing

Another outrageous opinion came from a UK local authority IT director who said around 2010 that he would like to see his whole council just communicating over the Internet - not via an MPLS VPN. To me he was a total heretic at the time, but I think today this would be (almost) entirely possible.

Good luck with that. It'll work as long as you're not concerned about congestion on your connections, or your ISPs. Which was kinda the point of tag-switching, which then became MPLS. Which then allowed tin-slingers to re-purpose ATM switches and give some deterministic qualities to 'IP' networks.

[Crypto Monad]

Re: Year End Reminiscing

Back then, people said that QoS was mandatory: you couldn't possibly do voice calling, let alone videoconferencing, without it.

And here we are, first with Skype and then with Zoom, Teams, Meets, WhatsApp etc all proving the opposite: there is zero QoS on the Internet and it works just fine. Your corporate network, which has tons of bandwidth compared to your external Internet link, has even less need of QoS.

[Jellied Eel]

Re: Year End Reminiscing

And here we are, first with Skype and then with Zoom, Teams, Meets, WhatsApp etc all proving the opposite: there is zero QoS on the Internet and it works just fine.

Nope, I suspect you just don't notice when it doesn't. But then people often don't understand how QoS and CoS really work, namely when there's congestion. So currently real-time stuff sorta works because the 'solution' has been to throw bandwidth at the problem. When that stops due to lack of money to invest in capacity upgrades, those apps will gradually degrade.

I also kinda wonder if 'works just fine' is because we're now into a generation that doesn't know any better. So people who've never made say, an ISDN call think that a heavily compressed and lossy VoIP call is acceptable. Huh, say again, I didn't catch that, you're breaking up..

Having wider broadband connections has helped a bit. So not that long ago when xDSL connections were 2Mbps, on a video call it was usually obvious when someone was sending a large file or attachment.

[Elongated Muskrat]

Re: Year End Reminiscing

That doesn't hold true, because it's a trivial observation that the cost of capacity decreases over time, and also that capacity increase on the internet is driven by two things (used to be just one thing): porn, and "influencers" video-streaming themselves. This provides plenty of bandwidth for all the lesser, proper, uses.

[Anonymous Coward]

Re: Year End Reminiscing

"Your corporate network, which has tons of bandwidth compared to your external Internet link, has even less need of QoS."

It seems there are still people around that rely on wishful thinking and maybe even salestalk magick to convince "the market" that latency doesn't matter.

Well the real world at the sharp end says it does still matter, especially if you want to be able to rely on systems, be it for voice calls or for data storage or whatever. Not everywhere, obviously. But it can't be completely ignored.

[Graham Cobb]

Re: Year End Reminiscing

The thing we learned, in the '90s, was that what matters is that seriously delayed traffic is dropped, not delivered late. Real-time systems (and people) found it much easier to fix lost traffic (which happens all the time, even in the best regulated environments) than delayed traffic (and high variability of latency).

For us, as router builders, it meant small buffer queues - that was the key factor in making the network layer more reliable overall.

[PRR]

Re: Year End Reminiscing

> ...with Skype and then with Zoom, Teams, Meets, WhatsApp etc all proving the opposite: there is zero QoS on the Internet and it works just fine.

I grant your point, for some poor excuse for "fine".

I have worked in radio, telephone, and sound reinforcement. Last week we ZOOMed the whole family in three states and another country. Most ZOOM(etc) sound is crap or worse. If I delivered that warbley bassless garble to any of my old customers I would not submit an invoice.

Yes, I admit the ZOOM/etc programmers have made about the best of a poor channel. (Dunno why they don't degrade the video faster. Most webcams don't have the resolution to lip-read fluidly. Or why bass is lost so easy, making a toilet-paper roll resonance, like a 1973 fuzz-pedal.)

[Jellied Eel]

Re: Year End Reminiscing

Yes, I admit the ZOOM/etc programmers have made about the best of a poor channel. (Dunno why they don't degrade the video faster. Most webcams don't have the resolution to lip-read fluidly. Or why bass is lost so easy, making a toilet-paper roll resonance, like a 1973 fuzz-pedal.

Again I think it depends on what you're used to. I had fun once with a link from a Singapore broadcast studio to the UK. Quality looked fine to this simple network engineer, looked & sounded lousy to the broadcast engineer. Ended up being a combination of latency and choice of codec. But that's all part of the fun with this stuff, eg-

https://en.wikipedia.org/wiki/Opus_(audio_format)#Bandwidth_and_sampling_rate

with 4 or 6kHz audio being a common default. Then there's also the latency that can lead to annoying lipsync problems, and then frame size, which will affect how much is dropped into the bit bucket when there's congestion. It's a far cry from the days when DJs could reliably broadcast from home studios, and most of their audience would be none the wiser. Downside to that Singapore job is now I've been shown and heard the problems, I can't unsee or hear them. QoS/CoS and proper network engineering can still do IP broadcast, but over the general Internet, it's fundamentally going to be best efforts.

[A Non e-mouse]

Re: Year End Reminiscing

In my experience, it's not the network that's the cause of poor performance but the end. user: Either their mic, speaker, camera or local environment (e.g. background noise, bad lighting, pets or little ones running into the room, etc)

Sure, if you have broadcast quality setups, you're going to be more aware of the poor quality of the network.

[Peter Gathercole]

Re: Year End Reminiscing

The thing that really bugs me about the end users and their audio is that they don't read up about their new super-duper noise cancelling multi mic. setup on their laptops.

They set up/enter the call sitting close to their laptops, and then lean back in their chairs to the extent that the noise cancellation system thinks that they are in the background, and suddenly you can't hear them talk.

I keep telling these people to either sit forward close(er) to the laptop, turn off the noise cancellation feature, or get a headset, but the next call, they do the same thing again. I personally use a wired headset so that I don't even have bluetooth to contend with (but the laptop I'm using has a 3.5mm jack still!)

What is really needed is a preview, where you can record and then hear how you sound when talking, both for volume and clarity, but it seems that this is not a feature I've seen in the video conferencing systems that I've used (or if it is, it is hidden somewhere in the menus).

[Trixr]

Re: Year End Reminiscing

Products like Teams, Webex etc do in fact have a "preview" feature - it's a test channel you can call up and talk to, then it'll play back your recorded audio.

[Peter Gathercole]

Re: Year End Reminiscing

I use Webex. This must be one of the (many) features that are not in the Linux Webex client. Come on CISCO, why haven't you make the Linux client feature compatible with the other platforms yet?

My work does not use Teams (thank God!)

[doublelayer]

Re: Year End Reminiscing

I'm not sure they're trying for high quality sound. I agree that it's not good enough for a lot of uses, but they are probably willing to forego the customers who need studio-quality sound. Those people, and I have at times been one of them, are really particular about their needs and may not be great at understanding when the network really is the limiting factor preventing it from happening. Meanwhile, there are a lot of people who, if they weren't using a videoconference, would be using a conference call over traditional phone lines. The sound on those is generally even worse, but people put up with it. These are the majority of users who will be easy to please with the basic audio and who will be using whatever cheap laptop microphone they have, which doesn't help improve the quality. If I choose to use more of my bandwidth on the audio, I can produce significant improvements without making a real dent in my available bandwidth, but most of the people I'm talking to wouldn't care that I had.

[Anonymous Coward]

Re: Year End Reminiscing

And here we are, first with Skype and then with Zoom, Teams, Meets, WhatsApp etc all proving the opposite: there is zero QoS on the Internet and it works just fine. Your corporate network, which has tons of bandwidth compared to your external Internet link, has even less need of QoS.

When my employer rolled out Teams and people started using it, I recall many a meeting where we reverted to Skype because Teams wasn't just "bad", it was unintelligible. Once the complaints started rolling in, our It people fiddled with the networks to give Teams it's own pipeline (mumble mumble, something about multiple pipes in the VPN, mumble mumble) like Skype had in order to make it work. Unfortunately, Teams now "works"* as well as Skype so is used a lot.

So no, on our scale - lot the largest UK Gov dept, but one of the larger ones - it doesn't "just work" without some network engineering to make it work.

* I say "unfortunately" because I hate Teams, I really really hate it. There's a saying about polishing a turd, and then there's Teams which I feel seems to have been through the "how can we add annoyances for users" department more than once.

[Rikki Tikki]

"there are few things more annoying than tech people discussing economics from a position of ignorance,"

Hear! hear! Have a beer -->

[HuBo]

To end end-to-end or not to end end-to-end, that is the question (in the end-to-end)

Much like the in-memory (or near-memory) processing of dataflow architectures, that is rescuing distributed computing from assured bottlenecking, I hereby dare to outrageously opine that in-network computing will indubitably become the order of tomorrow, the bees-knees of innovation that, in time, realizes SUN Microsystem's visionary outlook of the past's future, that the network, is the computer. Ergo QED, the end to end-to-end, CQFD.

[Bebu]

et vice versa

"there are few things more annoying than tech people discussing economics from a position of ignorance,"

Economists discussing technology or pretty much anything from a position of ignorance is certainly one of those few.

Politicians ignorant by construction top the list if they claim any economic credentials.

[Doctor Syntax]

Re: et vice versa

IOW "few" isn't really that few at all.

[John Brown (no body)]

Re: et vice versa

It seems that many, if not most, UK top level politicians are PPE grads. On the other hand, in a discussion on the radio the other day about exactly that topic, the point was raised that having a degree in economics does NOT make one an economist :-)

[Anonymous Coward]

Re: et vice versa

My day job is persuading government economists (Who rarely stay in post for three years) at a quango about engineering issues that have lead times in excess of 5-10 years and lifetimes measured in decades.

As such, being an engineer requires knowledge of the law, economics, Accountancy, physics, geology to say nothing of engineering itself.

It is as well as we engineers are gluttons for punishment, for there are few other professions where you need to know quite a lot about all of it to get anything done.

[Anonymous Coward]

Economists discussing technology or pretty much anything from a position of ignorance is certainly one of those few.

Indeed !!!

But don't forget those other abominations of nature: beancounters and marketing droids.

Happy New Year.

.

[abend0c4]

Living with NAT became more important

Unfortunately, it's NAT that has resulted in end-to-end services that are almost all mediated by a third party - whether it's your video-calling, text messaging, or home intruder system. Even your "smart" switch is only as "smart" as its connection to its likely transient manufacturer's cloud presence. It's also one factor in the lack of choice in the smartphone space - the major platforms fill in the missing functionality (such as the delivery of notifications) without which apps would be considerably less useful and which would eat your battery if each app had to poll for messages.

I think it's more correct to say if became more important for network operators at a time of rapid growth and limited technical skills. I don't think anyone was particularly against NAT as a transitional arrangement, but it clearly wasn't and isn't the desirable default position.

My outrageous opinion for the end of the year is that "prevailing views" are often justified, even when they appear to be in direct conflict. The challenge is to find a third way, but the usual response is simply to stop listening. One of the challenges of the various forums in which networking standards have been developed is that there is far too much specialisation and too many vested interests: this is partly unavoidable as the work needs specialists and it needs funding, but there's an absence of oversight on the integration of the various components and the experience of the end user. There's even a hostility to the existence of anything of the sort. But I'd say it was sorely needed.

[Doctor Syntax]

Re: Living with NAT became more important

"the experience of the end user"

The end users do get a say and it can be a decisive one. While the experts are trying to pick the winners and losers it's the end users' choice that determines them.

[Paul Crawford]

Re: Living with NAT became more important

I think it's more correct to say if became more important for network operators at a time of rapid growth and limited technical skills. I don't think anyone was particularly against NAT as a transitional arrangement, but it clearly wasn't and isn't the desirable default position.

NAT solved two very pressing problems as the internet got much bigger:

1) The ISP only needed to assign a single public IP address, useful as IPv4 started to become scarce

2) The default of NAT is to block incoming connections, in the early days of Windows being open to all that would save you from being pawned in under 15 mins. Still handy for all sorts of crap-by-design and/or never updated/fire-walled stuff on your LAN.

Later on it also provided a small degree is anonymity as the public IP was not tied to any specific machine (though in reality it was to a household in most cases). So NAT has been an astonishingly useful tool, much to the annoyance of the IPv6 champions where every device being uniquely addressable and available seemed like a good idea at the time.

[Nanashi]

Re: Living with NAT became more important

NAT doesn't actually block incoming connections. The need to do that is served by firewalls, not NAT. It's true that before NAT was common firewalls weren't either, but that doesn't mean that NAT blocks connections.

Also the IPs used for outbound connections in v6 generally aren't tied to a specific machine either; machines pick random addresses and cycle them regularly.

[Paul Crawford]

Re: Living with NAT became more important

NAT doesn't actually block incoming connections.

Without defining port-forwarding, NAT has no route for incoming connections that are not in response to an outgoing one. That to me is tantamount to blocking!

[Nanashi]

Re: Living with NAT became more important

If NAT worked like that then it would indeed be tantamount to blocking, but it doesn't. NAT has no routes, whether you define a port forward or not. Routes live in your routing table, and your routing table still exists and works like normal when you're doing NAT.

Just to be completely clear: inbound connections work both to and over a router that's NATing outbound connections, without needing to configure a port forward. The port forward is used in situations where the inbound connection is addressed to the wrong machine, but connections addressed to the right machine can be left alone and will work. Even if "the right machine" is one that you didn't want to permit a connection to.

[Peter Gathercole]

Re: Living with NAT became more important

It is my understanding that when NAT is deployed, only the external system for which a NAT translation has been set up when the outbound session is established will be able to send inbound packets through the NAT translation, and even that has to reply down the established connection using the correct inbound port number.

The router that is doing the NAT matches both the external IP address and the port number to the entry in the translation table. A system with a different IP address trying to use the inbound IP/Port address pair will not be able to use the translation to get packets to the system behind the NAT. It may be possible for the actual external system for which the translation entry was set up to inject a side-band attack down the connection, but even this is unlikely due to TCP packet sequence numbering unless the initiating program is complicit in the process (like a botnet talking to it's C&C server).

Packets that do not match will be dropped by the router doing the NAT, meaning that it is pretty much as safe as a firewall rule.

I'm pretty certain I tested this using GRC's Shields Up! service many years ago when I first looked into NAT.

If my understanding is wrong, please post a link to a description of how it really works.

[Nanashi]

Re: Living with NAT became more important

> Packets that do not match will be dropped by the router doing the NAT, meaning that it is pretty much as safe as a firewall rule.

This is the part you're getting wrong. When a packet doesn't match any active NAT translations or static rules, the behavior isn't "drop the packet", it's "don't apply NAT to the packet". The packet will still be processed by the rest of the router, which will be perfectly happy to route it onto your LAN if the firewall doesn't drop it.

This is quite hard to test for most people, because most people don't have the address space to connect their LAN to the Internet in the first place (which is why they're using NAT), so they need to test from a machine connected just upstream of their router, and also because firewalls are very common in routers and can be difficult or impossible to disable.

[ShortLegs]

Re: Living with NAT became more important

"The packet will still be processed by the rest of the router, which will be perfectly happy to route it onto your LAN if the firewall doesn't drop it."

With what IP address in the header? Broadcast address? the network address?

[Nanashi]

Re: Living with NAT became more important

With whatever IP was already in the header when the packet arrived.

[I could be a dog really]

Re: Living with NAT became more important

What you are mssing is that with NAT, if there is not an existing translation in the table then the inbound packet will be dropped simply because there is no way to know where to send it. Translations will be in the table for two reasons : 1) there's port forwarding rule defined (either static, or via that abomination whose name currently escapes me that allows software running on a device to ask the router to open a port forwarding table entry for it), or 2) there has been recent outbound traffic that matches the inbound packet.

Absent one of those two, NAT WILL drop unsolicited inbound traffic.

What is annoying is that too many people have jumped on this as meaning a connection cannot be secure without it - which is, as anyone who knows a modicum about network security, a load of bovine manure. There was a bit of truth a couple of decades ago, but now even budget routers have stateful firewalls that's a moot point. But I have genuinely met people who claimed to be network experts who claimed that it was impossible to run anything securely without a layer of NAT - which was demonstrably false, not that they'd take our own small hosting facility with stuff (even VoIP phones) running in our Class C /24 IP allocation.

[Nanashi]

Re: Living with NAT became more important

There is a way to know where to send it. IP packets have a "destination IP" header that specifies where the packet is meant to go. The router simply looks at that.

You can put in bold and capitalize it all you want, but NAT won't actually do that. This is something I've tested multiple times on a real network - applying NAT to outbound connections and with no state table entries or port forwards, the unsolicited inbound traffic worked just fine. If NATing outbound connections somehow dropped inbound ones, then why weren't my inbound connections dropped when I tried it?

In my last comment I said that it's hard for most people to test this, but your hosting facility with its /24 would make it easy for you if you wanted to try yourself.

> What is annoying is that too many people have jumped on this as meaning a connection cannot be secure without it

Yeah, exactly. That's partly why I try and explain this to people. It should be immediately obvious that a connection can be secure without NAT... not just because there are other ways to secure it but because NAT doesn't secure it in the first place.

[I could be a dog really]

Re: Living with NAT became more important

If you make an outbound connection, then that creates an entry in the mapping table. The inbound packets then have a known destination. That is how NA(P)T works - as I explained but you clearly didn't read.

If there is no entry in the mapping table, then when an inbound packet arrives, the router does NOT know where to send it. The destination address in the packet header is the EXTERNAL address for the gateway - it is NOT an internal (usually RFC1918) address. Since the gateway does not have an internal address, nor an entry in the table to tell it how to translate the packet, it cannot know where to deliver it to.

The alternative is that you have pre-configured rules for where certain traffic should be sent, and possibly a rule for "and anything you don't know about goes to ..."

Let's try an analogy - it's not a good one, but let's run with it.

You live in a block of flats with a big communal post box, and individual ones for each flat. [Someone] periodically looks in the communal box, grabs any post, and sorts it to the individual boxes. It's a bit different to NAT, because the postal items will have a person's name and/or flat number of them while IP packets do not - but bear with me.

So what happens if you see a plain envelope without a name or flat number ? It is just addressed to (for example) 10 High Street.

The static NAT rules are (very vaguely) a bit like someone having told the others "I'm expecting a letter from X" - so if you see such a letter with no name or flat number, you turn it over, see it's from X, and deliver it accordingly.

And really straining the analogy a bit here, you see a letter without name or flat number, look at the back and see it's from Y, then remember that you posted a letter for another resident last week addressed to Y - so you consider that's it's probably a reply to that and deliver it accordingly. That's (very roughly) the equivalent of the connection tracking table that maps internal and external addresses & ports. Don't forget that in the general case, you may be mapping "many" internal addresses to multiple external addresses, and especially when devices use a well known port for source port (e.g. SIP phones using port 5060 as SOURCE port on outbound packets) you may be changing the port number as well as the address (hence Network Address and Port Translation (NAPT))

[Nanashi]

Re: Living with NAT became more important

I know how NAT works already. What we're talking about here is unsolicited inbound connections that don't match any port forwards. NAT isn't applied to these connections, so what NAT does when it's applied doesn't matter, because it's not being applied.

> The destination address in the packet header is the EXTERNAL address for the gateway - it is NOT an internal (usually RFC1918) address.

No, it might an internal address. Packets can technically arrive with any IP whatsoever in the dest IP field, which of course includes whatever IPs are being used on the local network. In fact the point of having a gateway is so it can receive packets addressed to the machines behind it.

If a packet comes in addressed to the router, and no NAT state entries or port forwards apply to that packet, the router still knows where to deliver it: it gets delivered to the router itself. But nothing guarantees that an inbound packet will be addressed to the router, and if it happens to be addressed to a machine on the LAN then that's where it'll get delivered.

[I could be a dog really]

Re: Living with NAT became more important

You should try learning a bit about networking basics !

If you are getting inbound packets with an RFC1918 address then something is badly broken. All ISPs should, and most do, drop all such packets at their boundaries. If they receive a packet for (say) 192.168.1.57, which of their customers (tens of thousands, hundreds of thousands, possibly more) do they send it to ? They have no idea, so they get dropped.

There is the special case where you NAT between different networks (e.g. a corporate and a key tech supplier) by arrangement - been there, done that. But that's not the general case of consumers - almost all of which will be using router defaults of 192.168.0.0/24 or 192.168.1.0/24, so literally millions of sites around the world.

[Nanashi]

Re: Living with NAT became more important

I've been talking about the most basic of networking basics the whole time. You're the one that's been getting them wrong. It doesn't really get much more basic than "If your router receives a packet, it'll forward it according to its routing table".

You can receive inbound packets with an RFC1918 destination without things being badly broken; all it needs is for your ISP or someone else on your immediate upstream network to send them to you. And they won't get blocked by NAT.

[I could be a dog really]

Re: Living with NAT became more important

Only, you should NEVER EVER be getting RFC1918 addressed packets from up-stream except in very limited situations. You certainly will not get them from the internet in general as they'll be dropped - unless your ISP is truly incompetent.

So since you won't be getting then, your router won't be able to do anything with them - and the other packets it can't do anything with.

So, in the general case (connecting stuff via the internet), your NAT gateway won't be routing inbound packets unless there's an entry in the connections tracking table or a static rule configured.

[Nanashi]

Re: Living with NAT became more important

Of course you shouldn't, but that doesn't mean it's not possible. You can't rely on an attacker being kind and polite enough to not send you packets you think you shouldn't be getting.

It's true that routers can't do anything with packets they don't receive, but if they do receive a packet addressed to your LAN then they can and will route it on to your LAN, even when there's no NAT state table entry or static rule configured. NAT can't prevent your router from receiving such a packet either.

[abend0c4]

Re: Living with NAT became more important

Your response is, of course, perfectly correct and you could implement an equivalent firewall in the absence of NAT that permitted only outbound connections by default.

The fact that you've been down-voted only illustrates that the lack of skill I mentioned has persisted.

However, the truly scary thing is that the people who believe their LAN is being protected by NAT are often the same people who are quite happy for their no-brand IoT box to provide a bidirectional relay to an unspecified server in the darkest reaches of the Internet.

HINT: Outbound connections are as dangerous as inbound connections if you didn't initiate them and don't know what they're doing.

If you're willingly inviting the Trojan Horse through the gates, there's not much that can be done to protect you.

[Peter Gathercole]

Re: Living with NAT became more important

And don't get me started on the other abomination that is Universal Plug and Play (uPnP), which can render almost all careful firewall configuration irrelevant if it is enabled.

[dark_15]

Re: Living with NAT became more important

You are confusing Stateful Packet Inspection (SPI) with Network Address Translation (NAT).

All NAT does is translate one address to another - which is great for IPv4 scarcity. As an example I can configure some switches (Nexus 3k comes to mind) to stateless translate src/dst IP's or Ports from one value to another. There's no firewall, no SPI, and the switch doesn't maintain a NAT/Session table.

SPI (OTOH) monitors network flow pairs (called a session) between two hosts, and creates a session table to track these flow pairs. Most SOHO routers and enterprise firewalls do this by default. And in pretty much in all the stateful firewall deployments when the device receives a packet the logic goes (and apologies for the formatting, I don't have the minimum posts to use HTML tags yet):

* Is this packet part of an existing session? If yes, forward the packet. If no, proceed

* (This varies on platform) - Does the packet match any of my static or destination NAT rules? If yes, perform this NAT operation and proceed. If no, just proceed

* Do I have a route to the source/destination IPs of the packet (located in the IP header)? If no, drop the packet. If yes, proceed

* Do I have a security policy that matches the source/destination IPs, source/destination Ports, and Protocol? If no, drop the packet. If yes, proceed

* (This varies on platform) - Does the packet match any of my source NAT rules? If yes, perform this NAT operation and proceed. If no, just proceed

* Perform other network security functions (IPS/AV/Application Identification/etc)

* Add the flow pair into the session table

* Forward the packet along

You'll notice that NAT operations are done separately from the security functions. This is why I can set public IPs on my hosts and still have full SPI/Firewall functions without the need of NAT.

Now, Source-NAT with Port Address Translation is stateful since we need something like a firewall to track all the translations. But even this stateful inspection can be bypassed with things like NAT Slipstreaming, or NAT busting/punching with a C&C Server. Remember Skype? That's what it did.

A separate service maintains a list of IP addresses used by Skype, and when two hosts want to communicate it would have Host A send a TCP packet to Host B and wait for a response (Host B's firewall will drop this packet). This creates the first flow on Host A's firewall, and leave a TCP session in an Open state for about 30 seconds. Host A tells the service it opened a connection with a specific Source Port.

The service tells Host B to send a TCP packet with the Destination Port of Host A's Source Port. This creates the first flow on Host B's firewall, but it also completes the flow on Host A's firewall, allowing the Skype call to work as expected - without ever having to deal with port forwarding.

[Paul 14]

Summary of the NAT Security debate....

Was security benefit the primary reason for NAT adoption in the 1990s? No - that was address availability.

Was there some security benefit in the 1990s to widespread NAT adoption? Certainly, particularly for unprotected home users with early Windows versions. NAT would probably disable the original Back Orifice exploit, for example.

Was this security benefit flawed? Of course it was. All security has flaws, but this especially as security wasn't the main objective of NAT.

Has NAT ever provided the same security benefit as a properly configured firewall? Of course not.

Did/Does NAT add any additional security benefit if you have a properly configured firewall? Probably not*

Does NAT provide the same degree of security benefit today as it did in the 1990s? No; since NAT today is commonplace any modern exploit will expect it and work around it.

Does using IPv6 without NAT mean greater security risk than IPv4 with NAT? Not really, because it's only something like the difference between a wide open door and no door at all. A proper security gate - ie a properly configured firewall - is an essential way to mitigate security risk in either case.

Was/is there a danger with people believing NAT provides more security than it really does? Absolutely, with bells on.

*Some might argue that NAT provides additional "security through obscurity", which despite being a much maligned idea, is still put forward by some analysts as having some marginal value - the argument being "why make things easy for an attacker when you can make them complicated". The counter to that is that making anything obscure for an attacker probably also makes it complicated for your own people, which can increase other risks around human error, response times, and limitation of resources - ie time spent working with needlessly complicated configurations could be better spent on more effective security measures.

[Elongated Muskrat]

Re: Summary of the NAT Security debate....

I think, as well as the "security through obscurity" aspect, there is the theory of "attack surface", and the more layers an attacker has to go through to reach the attack surface, the more of it is covered.

If you think of the resource the hacker is trying to reach as a sphere, and each layer of security being a layer on top of this, but with some holes in it; the more layers you have, the less likely all those holes will line up. Some have more holes than others (so the NAT layer is probably mostly hole, and the firewall layer is probably only a bit holey). NAT could still conceivably help prevent some attacks, or make some harder, and because you don't know exactly what exploits are going to be used against you, the more layers of defence you have the better; even if some are pretty much ineffective, they may add a marginal benefit in combination with other layers against an unknown attack.

[I could be a dog really]

Re: Summary of the NAT Security debate....

The downside being all the effort needed to workaround the borkage of NAT (or more correctly, NAPT, Network Address and Port Translation*). In some ways, the invention of NAPT set us back a couple of decades by removing (for many) the idea that there was still a problem to be addressed.

I reckon if half the effort (and investment) that went into NAT - implementing it, working around it's borkage - had gone into IPv6 then we'd be wondering what the fuss was by now and IPv4 would be like vinyl records, Betamax video tapes, etc.

* Implementations differ widely. Some try and keep the port number the same unless it's already in use for another device. Lets say you have two SIP VoIP phones, both use the SIP port (normally 5060, usually UDP) to call out to the "phone system". The first one may get to use port 5060, the second one will get translated to a different number.

[Pete Sdev]

Natty

One of the (unintended) side effects of NAT was/is the increased security and privacy it provides (if you don't live alone).

Something that when designing IPv6 was in myopic fashion completely ignored.

[Nanashi]

Re: Natty

Nah, this wasn't ignored. NAT simply doesn't provide any increased security, and privacy extensions are a thing.

[Pete Sdev]

Re: Natty

For the record, I didn't downvote your comment. I will elaborate however on what I mean.

I was always amused on seeing adverts for cat food despite not owning/being owned by a cat. One of my then housemates,however, did.

Note that this diffusion occurs out-of-the-box with IPv4+NAT - no configuration, additional software, or expert knowledge required.

Nah, this wasn't ignored

If you can post the link to the relevant mailing list archive or similar I'll gladly be corrected. My current impression is that IPv6 was designed on a dogmatic "everything should be host to host because that's how the Internet was originally intended" while ignoring the contemporary real world consequences of that architecture.

Another example: After connecting to a VPN for privacy I checked online if it was working as intended. While my IPv4 address was detected as that of the VPN server, my original IPv6 address was still leaking. Ah yes, my bad, forgot to disable IPv6 on the new router. Your average home user has no chance.

NAT isn't more secure in itself. However it's a lot easier to secure a router (and even that gets fraked up as we know) which has a limited task and fixed hardware compared to securing a general purpose user device. Also the router will be usually running a BSD or Linux; the average PC willl be running Windows.

Arguably as the Internet is a network of networks, you only need to know about the gateway, not every device on its network.

NAT has it's problems for when you do need to connect peer to peer, but solutions were found.

[Paul Crawford]

Re: Natty

NAT has it's problems for when you do need to connect peer to peer, but solutions were found.

Alas, I am thinking of UPnP which blew away many of the security gains from NAT's default behaviour!

But it is a tricky problem for Joe Average who has no networking knowledge at all but wants XYZ service to "just work".

[Jellied Eel]

Re: Natty

Alas, I am thinking of UPnP which blew away many of the security gains from NAT's default behaviour!

But it is a tricky problem for Joe Average who has no networking knowledge at all but wants XYZ service to "just work"

Yep. That's always been the problem, along with badly thought out apps. So Universal Pwn n Plunder makes it easy for all sorts of apps to blow holes in your firewall and start listening for incoming requests. User just clicks 'accept' and holes are opened up to the world wild web, until maybe someone notices that's a rather glaring vulnerability and patches it. Often that's after skiddies have already exploited it. Once inside the network, it's usually easy to open sessions to the outside and plunder stuff.

NAT on it's own did help prevent some external connections, but with UPnP added, it's pretty much a waste of time unless there's a decent firewall that can do a decent job of stateful inspection.

[Nanashi]

Re: Natty

>Note that this diffusion occurs out-of-the-box with IPv4+NAT - no configuration, additional software, or expert knowledge required.

It also happens on v6 without NAT, thanks to privacy extensions which are typically enabled without needing configuration, additional software or expert knowledge.

>If you can post the link to the relevant mailing list archive or similar I'll gladly be corrected. My current impression is that IPv6 was designed on a dogmatic "everything should be host to host because that's how the Internet was originally intended" while ignoring the contemporary real world consequences of that architecture.

Of course I don't have a convenient mailing list quote covering this. They didn't sit around having inane conversations about how they weren't doing something that makes no sense in the first place. You're right that v6 was designed to have enough address space for everyone; my correction here was to point out that NAT doesn't provide increased security and that v6 has a thing to obscure which machine is doing a given connection, and therefore that v6's design isn't "myopically ignoring security and privacy". In fact security and privacy are both covered in v6.

>Another example: After connecting to a VPN for privacy I checked online if it was working as intended. While my IPv4 address was detected as that of the VPN server, my original IPv6 address was still leaking. Ah yes, my bad, forgot to disable IPv6 on the new router. Your average home user has no chance.

This is simply an example of you wanting to put your traffic over a VPN but forgetting to do so (and then, apparently, disabling the entire protocol stack for some reason instead of doing what you wanted to do in the first place). It has nothing to do with the design of v6.

Average home users stand no chance with anything. It's up to us to know what we're doing, for their sake, or else to step back and leave things in the hands of people who do know.

>NAT isn't more secure in itself. However it's a lot easier to secure a router (and even that gets fraked up as we know) which has a limited task and fixed hardware compared to securing a general purpose user device.

This is true enough, but why is NAT even being mentioned here? If anything it gets in the way of securing the router, because if you think NAT is giving you security, you're more likely to fail to implement actual security (i.e. a firewall).

[Pete Sdev]

Re: Natty

It also happens on v6 without NAT, thanks to privacy extensions

1) This actually proves my point somewhat because this shouldn't have been a damm extension but something properly addressed in the core protocol. (Also see how well Windows initially implemented the privacy extension...)

2) The level of diffussion isn't equivalent.

This is true enough, but why is NAT even being mentioned here?

Because NAT was mentioned in the original article ^^.

Under IP4+NAT the outside world only saw the external IP address of the router and it's only possible to connect to (and thus attack) the router on this level. (Leaving aside for the moment the fur cough that was UPnP as others have mentioned).

Under IPv6 every device gets it's own external address. Which solves some problems but creates others which IPv4+NAT didn't have (unintentionally as I originally mentioned). Those are partly addressed by firewalling as you rightly point out.

The thing is, by changing the behaviour not merely expanding the address space (and adding useful things like QoS and co.) there were negative real-world consequences.

Saying "oh you need the extension for privacy" and "now you need a proper firewall" is a bit like selling a new care with "brakes extra" and "you need to install your own seatbelts".

[xyz123]

Google et al need a new command structure for search.

Index banks/official websites for government. Add a single search word to the START of your search to ONLY list verified sites.

example: Verifiedsite hsbc

this would ONLY return HSBC.com, HSBC.co.uk, HSBC.HK etc. Nothing else.

In that way you 100% knock out ALL fake websites when looking for something financial/government related.

Sort of a subsearch option. Or even make it an extra button instead of typing verifiedsite

so for example you'd get something like:

https://imgur.com/a/xiYJZrF

[Blackjack]

Since I was a kid (teen) what I most remember about 1995 is how 3D gaming was going to be the future, we would connect anywhere in the world to play games online, and that 2D games were doomed to die. Computers? They were just the things not called Nintendo or Sega I used to play videogames and help me with schoolwork, this being 1995 said help came in the form of using Word or a CD based digital encyclopedia.

I did see a vision were we carried portable screens everywhere in the future but it was a PDA like thing of some sort, not a mobile phone.

What worries me the most about the modern internet is all the walled gardens and the fact a lot of people get their news from Social Media.

I miss Internet forums, they barely exist nowadays. I don't want to use Discord and Mastodon is not forum like enough for my taste.