"Steve's Infeasible Third Coming"
IPv4 addresses are a rapidly dwindling commodity [...] ICANN distributed the last big chunks of available IPv4 addresses to the five continental Regional Internet Registries earlier this year. The RIRs in turn are running out of supplies to allocate to ISPs and other network operators - El Reg Somewhere in the near future... …
So for us analogue meatbags (no offence), how many? OK I realise there may be limits on how many different colour a human eye can tell apart, and therefore want to pay for ;) And how come you allowed B&W into a colour lab, wasn't it slightly greenish, like on 3-colour plus no black cartridge printers ;)
Reminds me of when I tried to convince a fellow hifi nut that although when you buy speakers, you may well be able to buy them with digital input, but .......well, you know ;)
...so the nerd war ensues. Before long someone will have to bring up whether or not the light being emitted is a wave or particle and then someone will take another point of view and the whole thing will go all to hell in a slit experiment. Eventually the density of the argument will reach singularity and it will all circle in upon itself with little more than hawking radiation leaking out of the thread. Time will stop. The universe will freeze. Hope will be gone. Eternity itself will become infinitely infinite. Blackless black. Deathless death. Meaningless meaningless.
Thus a new Internet is born.
As my old boss and world authority on colour vision would have pointed out, it's not what you can measure, it's what you perceive.
He has astonished many people over the years by turning a "red" piece of paper into a "green" piece of paper by doing nothing more than holding up a larger piece of multi-coloured paper behind it, thus demonstrating that what they had been taught in school about "coloured light" was patently wrong or at best a misleading over-simplification.
Just watch how the use of Class A addresses (most of which are owned by American entities) are used to bolster the US economy because US companies will have access to Ipv4 well beyond the rest of the world (Class A addresses account for HALF of the 4 billion Ipv4 address available).
You can forget this bulls**t about not monetising IP addresses, selling them maybe difficult (but not impossible) so they'll lease them out instead.
I "got" a copy of "Fifty Shades" but you know, by golly it was unsexy. Probably Guantanamo is more sexy.
Is it for the American market, dressed up as "English teatime afternoon light bondage" , but, not too many corpses... so clearly no CSI tie-in possible :P
I would actually recommend this instead: - http://www.goodreads.com/book/show/14060248-fifty-shames-of-earl-grey
Pff. NAT in the sense of address hiding(*) provides one very specific form of security. With a couple of exceptions in the UDP space, connection initiation is outbound only, since the translator doesn't know what to do with an inbound connection. This prevents an external attacker from reaching in directly to an internal machine.
So, no, there are no security aids in NAT, except in one specific but very, very, very common case.
(*) NAT can be used in various ways. The most common is where you hide an RFC1918 privately-numbered network behind a single public (or "less private" - see "Carrier-Grade NAT") IP address, although as I hope you know, those in the know sometimes call this NAPT or PAT. Less common are methods for renumbering IP networks without renumbering them, and also for hiding a private-numbered host behind one port of a public IP (port forwardiing) so that only the intended port can be reached.
Even in your very specific example it is not NAT that is providing the security: it is the firewall that is preventing an inbound connection just like the lock on my front door (mostly) prevents you from entering my flat. NAT is not the security, the firewall is. Any firewall will provide this exact same level of security whether or not NAT is being employed. (ever hear of transparent mode: no NAT, same security)
What NAT does do is allow you to obscure your assigned IP from the heathens at large. However as everyone on this board knows, there is no security through obscurity.
Kirbin: I didn't mention a firewall. NAT / PAT / NAPT is a separate function from firewalls, and a box might do one, the other, or even both. The point is that the translator (note, to repeat myself, not the firewall) doesn't know how to handle an incoming packet that doesn't match an outgoing connection profile, so it drops it.
There are exceptions, in that for certain UDP situations, a (dynamically created) translation may say "from this internal IP/port, use this external IP/port, wherever it is going, and allow anyone who sends to that external port to hit the internal IP/port". This is called "cone NAT", and severely weakens the coincidental security model of NAPT. Restricted cone NAT uses the same external port for all communications from a given internal IP/port, but only allows external packets from previous destinations.
Restricted cone is less protective than fully-restrictive NAPT that uses a separate external port for each IP/port quad-tuple, but more protective than fully-open cone NAT. The trade-off, as usual, is that open cone NAT is less unfriendly to protocols with a peer-to-peer element, but also less protective.
But once again, none of this has anything to do with firewalls, except in so far as devices that do either often do both.
Relevant note: I work in the IPS engine of a firewall-with-UTM-and-NAT-and-stuff, and I'm specifically responsible for, among other things, the code that handles all the various NAT modes. Some people might think this qualifies me to talk knowledgeably about this subject.
FAIL for you, sorry.
It's nice you can do cool stuff with NAT and IPS. Tell me, in a network with enough public IPs for every internal need, what can you do with NAT that I can't do with stateful ACLs?
Relevant note: I've been building packet filters since the late '80s. I had a hand in developing the early ip masquerade code in Linux-386 and worked closely with a large firewall vendor on their early NAT implementations. Some believe this qualifies me as a subject matter expert. ymmv
No, you try again! Any router, server and host that performs PAT or port forwarding is offering the feature of preventing external hosts directly connecting to inside hosts, all this without any additional packet filtering. We all know this can be defeated but it is still useful as an added layer of protection which I'm not ready to give up for the sake of the beauty of IPv6 protocol.
And you know what, some bunch of Linux guys will come up with NAT6 and it will be a success, everybody else will adopt it no matter if those who created IPv6 will like it or not. And best of all, you're free not to use it.
I'm afraid you're confusing firewallness with NATness. Pray tell, how is "preventing external hosts directly connecting to inside hosts" a function of NAT at all? NAT simply creates a temporary ACL that says: a trusted host sent a packet to host A on port Z; allow return traffic from that host and port; drop everything else. Once the connection is torn down that temporary ACL goes away. How is that different than a reflexive or stateful ACL other than there's NAT to muck things up.
Give me a stateful packet filter and I can do everything your NAT can do and then some. Give you a NAT only box, even with packet filtering, and you can't come close unless you include fixes for IPSEC, FTP, RSTP, SIP, IM, etc..
The thing about ACLs is(are?) that they are not likely to appear on any consumer grade kit (out of the box) any time soon.
Add to the mix wide open windows/SMB shares, and the usual disable-every-security-feature-to-get-it-to-work-itus, and im a bit worried. Many home networks security consists of "if you've got the wifi password, you can access everything. What do you mean its your address/surname?". Unless the belkin (et al) routers are going to be a drop-in replacement, with the ACL features there is going to be quite interesting times ahead.
Im not exactly comfortable with the idea that my potentially buggy code will be addressable from anywhere on the internet. If i was confident it was secure, i wouldn't call it a test server. While i might be able to cobble something together myself, its not something im going to be proficient at, because its something have never had to do before. (and my first hello world was decades ago :s)
Sorry to ramble, but there is a lot of FUD about IPv6, and that needs to be rectified before the article (however good) starts to hit a little too close to home...
I'm pretty sure *DSL routers from Zyxel et al have included stateful firewalls for years. Netfiliter is built into the Linux kernel and it's just a matter of building a web GUI. I distinctly remember setting up port forwarding on one of those, and it involved (a) setting up DNAT and (b) opening the firewall from the Internet to the internal host.
Many consumer-grade IPv6-capable home routers do already include "Simple Security" ACLs that provide equivalent blocking for inbound IPv6 traffic as they do for IPv4 traffic.
Described at http://tools.ietf.org/html/rfc6092
With firewalls there is a clear distinction between the more professional units and the models aimed for the residential markets. Most of the residential devices come with an enabled filter that mimics the behaviour of standard IPv4 NAT, blocking incoming connections by default. ...
NAT wasn't invented for security, but for convenience. It provides a little of both (in that you *cannot* directly talk to my IP from the Internet even if I don't configure a firewall specifically prohibiting that, because you aren't party to any connection established from INSIDE the NAT, which means you have no idea of - and no way to contact - internal IP addresses, and anything you try to fake will be rejected).
NAT will still exist on IPv6. I guarantee you. If you're a company it's just too easy to migrate all your IPv4 external addresses to IPv6 addresses and keep the same configuration.
Which brings me to the point I bring up everywhere someone publishes an article about how great IPv6 is:
# dig AAAA theregister.co.uk
It's so good, we can't even be bothered to use it!
And, yes, I have an IPv6 accessible website, with IPv6-accesible tunnelling, email, SSH, and even public NTP services. Guess what? Apart from remote upstream NTP servers that I selected BECAUSE they were IPv6 compatible, I see zero IPv6 traffic.
IPv6 is a fabulous idea. How about using it WHERE you promote it? I have the same problem with Slashdot, too. They always whine on about IPv6 and don't even TRY the simplest of IPv6 deployments on their production site. If the Registers and Slashdots of the world can't be bothered to do it (or can't manage it) where does that leave the idea that "everyone" should move over?
I deply IPv6 for a living. I do not deploy NAT. Why? NAT breaks protocols and introduces unnecessary complications in what can be very confusing security policies. If I deploy a good firewall that prevents inbound connections to my IP (v4 or v6) address, then who gives a rats ass if you know my IP or not? You still can't reach it. NAT does nothing to improve this posture.
NAT translates addresses; period. Firewalls prevent inbound connections; period. The two may dance but saying NAT is security is like saying a towel over your head is effective protection from a ravenous lion. (Ravenous Bugblatter Beasts are another matter and outside of this discussion)
The only reason I have ever deployed IPv4 NAT was because there weren't enough public addresses available to use internally. Transparent is the only way to go. Everything else is doctrine you'd be best off forgetting.
I agree with you, to a point. NAT functionality basically demands some packet-state-inspection, which provides the "security" but I wouldn't rely on it alone.
But NAT breaks only broken protocols. FTP DATA, some other historic ones, almost everything else has hole-punching of some kind nowadays. If you embed IP information into data packets you break not only NAT but IPv6, too. FTP over IPv6 isn't going to work unless you use yet-another-bodge, for example. So the protocol breakage isn't really that much a problem and is the result of people not understanding what data should be in the payload and what data should be in the header. Seriously, can you imagine if we had to have "HTTPv6" that only works on IPv6 rather than just talking standard HTTP over whatever-we-like? That's how stupid NAT-broken protocols are.
The problem is that NAT has a history of deployment. IPv6 - well, doesn't. So faced with a paid-by-the-hour IT guy, the majority of people who are forced to move to IPv6 will keep some level of NAT - for whatever reason. You only had one IP address before, you allocate out internal addresses, you have to migrate the bare essentials as quickly as possible, so what you do is change the external address for ONE of the internals (your NAT-router) to IPv6 and let everything else sort itself out with ZERO changes. It's not the recommended way, or the best way, or the most sensible way, but it's the cheapest way, the lowest-impact way and the way that companies WILL migrate for the most part. Deploying whole new firewall rules for every possible tweak you've done to them for a few hundred computers, modifying your DHCP setup to issue IPv6 addresses to internal clients, etc. it plays with EVERYTHING you touch (and everything better be as IPv6 ready as everything else).
Or you could just set up a 6-4 tunnel, or just assign an IPv6 address to your external interface and you're done. I wouldn't do it personally, but it's what will happen when ISP's stop handing out IPv4 addresses (and, let's face it, the "convenience" of NAT is what's keeping them running at the moment despite there being no more IPv4 IP's left to allocate for a lot of numbering organisiations - a lot of cheap ISP's just use NAT and will never see a "shortage" of IP's).
It's not a question of design, or intention, or best practices. Anyone who follows those is already set up and not worrying. It's a question of convenience and cost. And that means that most people who are "forced" onto IPv6 on a tight budget (read: almost every company that doesn't make millions) will do what's cheapest and what makes best use of their existing investment in their configuration.
And, even then, if you somehow imagine that the decree will go out to purge all IPv4 addresses from even internal networks, that won't happen until the very last possible second and until then they'll still to IPv4 internally.
IPv6 is a great idea, hindered by the fact that the people who preach about it have no concept of what will happen to those users on the periphery of IPv6 connectivity and how they WILL go about doing things quickly and cheaply. Stop focusing on NAT-problems that will never affect anyone who doesn't deploy a NAT themselves (so why should you care unless you're dealing in broken protocols?), and focus on getting websites and services to provide service over IPv6 in the first place. When they have both types of address and routing, then you can argue about their internal setup.
Complexity in anything is an avenue to mistakes. Mistakes lower security and so yes, NAT is bad. NAT isn't complex for me, but it might be for the guy who comes up behind me. These "idiotic" protocols were not broken before NAT and many a manhour was wasted trying to rewrite them to accomodate NAT. NAT is the problem here, not the solution. Just because all this work happened while you were still suckling mommy's teat doesn't make the current state of affairs the correct one.
And no, imbedding an IP into a data portion of the packet is not breaking it. It is only broken in the face of NAT which does not inspect the data. If all endpoints IPs are visible end to end, it doesn't matter what's imbedded in the packet, they still arrive at their destination unmolested.
I will give one accedence to FTP, it's strange goose anyway but only broken for stateless firewalls; all the NAT in the world will not fix this.
My original point stands: NAT does not improve security, it merely adds a level of obscurity and to beat a dead horse, security through obscurity is nothing in the face of persistent threats.
>These "idiotic" protocols were not broken before NAT
Some of these were just very poorly thought-out, but then as several do date from the very early days it isn't surprising that as the Internet has evolved somethings get broken...
What is surprising is given both the poor quality of documentation (the RFC's) and the origins of the Internet in academia, is that the Internet has (largely) survived the test of time and hasn't been plagued with more problems...
>security through obscurity is nothing in the face of persistent threats
...and an AES private key is just an obscure string of characters...
Fundamentally all forms of security are just exercises in obscurity...
One of the reasons I may employ NAT w/ IPV6 is because IP addresses still may cost an arm and a leg. If they are free, sure give me a million and I'll be happy for a while. If they cost *anything*, I'll be happy to use some kind of NAT. Repressed regimes? Greedy business practices? Restrictive ISP contracts? NAT will be useful.
well at least with IPv6 the enforcement agencies will have a greater certainty of identifying our online profiles. Won't matter if your wireless network password has been revealed, as they'll know which machine in your household was downloading those torrents.or whatever.Google will know you just bought that new smart tv & send online adverts to your home accordingly. Used your smart phone at the arrivals hall at the airport, be prepared for loads of holiday adds online at home for weeks after you get back.
At least with NAT there was some obscurity along with the protection of not being directly accessible from the wild web. IPv6 has the *potential to present Personally Identifiable Information to remote parties by just sending a ping. i don't believe that most implementations will use a robust method of obfuscating the MAC of the connecting machine, especially public connections.
@ AC, MAC based identification (which is the ultimate cookie in some regards) is only an issue if you use SLAAC, if you are using DHCPv6 or offerings such as MS's privacy addressing which generate pseudo random portions of the IPv6 address (i.e. the last 64 bits) then this can be mitigated...
I'd love to see the universities etc booted off the /8 and /16 subnets they hog - encourage them to speed up IPv6 as well as freeing up address space for other users to ease the shortage overall. It's galling to see them say so complacently "oh, we'll be fine, we've got 10 IP addresses per student" - particularly when they have whole slabs of that address space firewalled off to be outbound-only anyway, so RFC1918 space would be perfectly adequate!
The ISPs are starting to wake up to it though: enough geeks shouting about it on customer support forums to get it on the radar. The kit's supported it for a decade now, they just need to get round to configuring it!
James, if they obtained their IP address space in compliance with the rules set down by ARIN, RIPE, which do not state that allocated IP's must be internet reachable they are entitled to hold onto them....
that aside reclaiming address space will at best delay slightly IPv4 exhaustion and not address the real issue.
Will, I assume, generate their own "Virgin Kit idents", stuff that looks like it has just rolled of the line, no history at all gov'.
Like pre-paid mobiles they will be (we are told) the domain of the "terrorist", "bad people" and never just the protestor against the state or poor soul who wishes to go back to a time where they weren't personally chased from cradle to grave by advertisers.
We are nearing the end of the internet honeymoon, we soon shall be traceable from pre-birth to post-death by any number of simple commercial databases and companies with good "data load" will merge with others, we may even show surprise at some combinations but the goal is common to gather, validate and exploit data on you.
There will be trading in data, data futures and derivatives and at some stage datagate where it is discovered some data trader has fabricated half of all the demographics derivatives he was dealing and that has infected and devalued (to the end user only obviously) the pension fund you were hoping would see you through in some kind of comfort.
Later to ease the accurate correlation of the "six" and "hudb" (Human database pronounced "Hub") the information that we will be told "powers our own personal health plan" they will migrate to DNA fingerprints. All that "Junk DNA" it's not junk at all it's great for identity and "Serving you precisely" (TM EurasiaData inc. 2040)
It's what gets you those specifically attractive (to DNA level) offers from the 'tailers and a diet that will increase your insurance costs if you ignore.
Be careful if you reply to this, it's all on record and your great great grandchildren may have to prove they are not carrying recessive "regyness" or a tendency to question the state and motivation of IT.
My coat? that depends what you mean by me.
I think that companies such as GE should have to give up the bulk of their /8 allocations. I think it's an absolute nonsense for every computer on every desk to have a real world IPv4 address when everyone is forced to go via a restrictive proxy and firewall.
They don't have more than 1 or 2 /24's worth of machines that need to be reachable from the public internet.
reachable from? perhaps no. Reachable to? Most certainly. I work for a very small hosting company and while we have only 2 /24s worth of publicly reachable hosts, we have at least twice as many internal devices supporting these hosts that occasionally need to download virus updates, OS updates, code files, database backups, NTP. etc. Think switches, routers, internal firewalls, database servers, NAS components, SAN components, monitors, smart PDUs and UPSes, NTP disbursers, user machines etc.
Should GE and HP and Apple have to give up unused space? Maybe. Will it make a difference? no.
"Implementing dynamic NAT automatically creates a firewall between your internal network and outside networks or the Internet. Dynamic NAT allows only connections that originate inside the stub domain. Essentially, this means that a computer on an external network cannot connect to your computer unless your computer has initiated the contact. So you can browse the Internet and connect to a site, even download a file. But somebody else can't simply latch onto your IP address and use it to connect to a port on your computer."
Whether you like it or not, NAT inherently provides some security on a network, that wasn't what it was designed for but it's how it functions.
You boast (unnecessarily) about your great achievements, knowledge and advanced skills in ACLs . But why create and constantly maintain a list of ACLs when 3 lines of code (in Cisco devices anyway) will get NAT functioning for any home user/small business. I don't think anyone was suggesting you actually use NAT when you have enough public IPs for your organisation?
"Pray tell, how is "preventing external hosts directly connecting to inside hosts" a function of NAT at all? NAT simply creates a temporary ACL..."
Read that back, of course it is a (non primary) function of NAT. NAT doesn't "prevent" external hosts as such, it just doesn't know what to do with the packets as there's no mention of it in the state table, and drops them. NAT doesn't create temporary ACLs, it uses a lookup table, these are not the same! However, you can use ACLs in conjunction with NAT pools.
Instead of storing what IP-Address you had at a given time, or what IPv6 prefix you had, it'll store every connection you make. If you browse at the Reg, it'll carefully note every connection. It'll know that you accessed the Reg, when and even how long. Just like data retention laws allow for every phone call to be tabulated.
On IPv6 you instead have huge address ranges. You get a prefix which, depending on your ISP might even change regularly. Within that prefix your computer will randomly grab an address for outgoing connections.
Currently IP-addresses are completely irrelevant when it comes to tracking, that is all done, and probably will be done with IPv6 via cookies and other tools.
One should also note that there is usually little reason to switch local private networks to IPv6. You can still work with IPv4 internally. Nobody is going to take away the software stack from you. In fact in some companies you can even just replace the proxy and mail servers with IPv6 capable ones and you are set for the moment.
First, I enjoyed the story. Thanks!
I'm using IPV6 specifically for it's capacity to traverse NAT, I'm running Miredo (a free Teredo implementation) at home, along with an account on the only Dynamic DNS service I found that supports IPV6 AAAA records (freedns.afraid.org -- they have other domains though, I'm under linuxmaniac.net). I don't have control over my upstream to just set up port forwarding, so every once in a while it's real nice to be able to ssh into my home systems anyway. Teredo is incompatible with certain types of NAT (for instance, trying to contact one of my home machines now randomly craps out, while another works fine.)
I've found as well, Verizon Wireless hands out just an IPV4 address (used to always be public, but now sometimes is NAT'ed) on 2G or 3G. But 4G you get both an IPv4 address (usually NAT'ed) *and* a public IPv6 address. (Actually you get 2 IPV6 addresses; although Verizon Wireless doesn't support VoLTE (Voice over LTE) -- voice calls run over CDMA -- the texts, picture messages, and actual call setup run over LTE on this extra IPV6 address, so the CDMA radio only has to turn on when you're actually in a call, or of course when you're outside the LTE service area.) It does seem to me that when you're having to roll out a new network anyway would be a logical time to start implementing IPV6 -- in this case LTE, but if someone was still going from EDGE to HSPA+, I'd hope newer HSPA+ equipment would do IPV6 too.
Biting the hand that feeds IT © 1998–2019