It doesn't obscure the network very well, though. There are a couple of papers on techniques for identifying the hosts and relationships of hosts behind NAT. Assuming the hosts make regular connections to the outside world, the information that can be gathered is pretty complete.
Also, you could get very similar effects with v6 by doing translation of the bottom 64 bits. Indeed, it's often recommended that hosts do this themselves: choose a different, random, value for the bottom 64 bits of each network request. That approach doesn't suffer from all of the limitations of NAT.
And port 1234 on the device at XXX:XX:XX::1 (a publicly-routable IPv6 address) has a remotely exploitable security hole. It's behind a cheap commercial Linksys router with a default-configured firewall which rejects inbound connections. How does a cracker in N. Korea casually exploit it?
Well, if the router config still has the default password, he logs into the router and modifies the firewall to allow access to what he wants.
Which is exactly the same situation if the Linksys is doing NAT.
Can Aunt Myrtle install a NATing router connected to her cable modem? If so, then she can install a non-NATing router in exactly the same way that provides exactly the same firewall, just without the NAT.
That doesn't surprise me. However, I suspect that the ISPs who do NAT do it primarily to conserve address space, rather than so that they can force their customers to pay a premium for the privilege of being a producer, as asserted by shentino.
Why use DHCPv6? I much prefer stateless autoconfiguration. I was amazed at how well it works. The first time I fired up the radvd daemon on my home gateway (which is using a tunnel broker service to get v6), I was amazed at how every device on the LAN instantly had v6 access, with no action whatsoever on my part.
I don't have any comment on PXE/bootp. Haven't looked into that in the v6 world. It seems like v6 should make that trivial, though. Just pick a standard reserved local suffix to hold the boot service. The booting device should wait for a router advertisement to find out what network it's on, append the standard suffix and open a connection to get boot code. Done. That's just off the top of my head, of course.
None of the other providers seem to be even making a peep about it.
Comcast is planning to start deploying residential IPv6 this year. They haven't said how long it will take for a full rollout to all of their customers, but if they do get there, that will be a significant chunk of the US residential market that has native IPv6.
Of course there is - it allows all manner of insecure and misconfigured gear to avoid being probed from the other side of the planet?
That's not an advantage of NAT. That's an advantage of a stateful firewall that disallows inbound connections. NAT is not required to get the same benefit.
All of the machines in my home have public IPv6 addresses, but I have a firewall that blocks inbound connections to all of them. Same security result. No address translation.
Depends on the context. I absolutely want to disallow inbound connections to the machines in my home, except on a controlled basis. The same applies for corporate networks. But ISPs shouldn't do the same. On the other hand, how many ISPs do NAT? I'm not aware of any where I live.
Now, you'd think that means these devices are publically accessible, but noooo. If 99% of their '9.x.x.x' equipment that does have internet access attempts a connection, it gets NATed outbound to a different address entirely!
That's not my experience. HTTP connections often pass through a proxy, which means the target site sees a different IP, but that's not NAT. If you use a non-proxyable connection (e.g. SSH), the target host sees the real IP.
That's the way it seems to work from multiple US sites, anyway. I did see some actual NATing from sites in Asia.
I happen to know that IBM uses a good chunk of the 9.0.0.0 space.
For what? Do all their PCs have public IPs?
At present, yes. Also their phones. But the employees' PCs are a fraction of IBM's computers. Keep in mind that IBM runs large data centers all over the world.
Yes, were IBM to go through a very large and expensive network restructuring to move many of the internal networks to NAT, they could probably give a few million addresses back. Maybe as many as 15 million. And at the 2009 rate that would buy us 26 days.
Where I work has an entire class B and all of our PCs are public and we're talking now about NAT'ing them all, for security reasons.
That's silly.
There's no security value to NAT. NAT does provide a stateful firewall that disallows inbound connections, but you can do that just as well without NAT, and with a great deal more flexibility.
No, not really. There's companies with whole fucking/8 [iana.org] that have no real purpose to own them, but they've just always had them:
The block you listed contain a total of 301,989,888 addresses. At 2009's rate of 203 million addresses per year, returning those blocks would buy us less than 18 months. Big whoop.
Also, some of those companies actually do make significant use of the addresses they have. For example, I happen to know that IBM uses a good chunk of the 9.0.0.0 space.
Fat Man was fat because the physics package was a large sphere of explosives surrounding a sub-critical sphere of plutonium. Little Boy was long and thin, with a uranium "bullet" at one end and a uranium "spike" at the other.
You do not need nuclear reactors to make nuclear weapons. You can make nuclear fission weapons by using U-235 or Plutonium. If you have a centrifuge cascade like Iran does, or some other means to separate fuel, you can make U-235 weapons without owning a single nuclear reactor. The bomb dropped on Hiroshima (Little Boy) was of this type.
Not quite true. You can't make Plutonium based weapons without a reactor, because it is an artificial element. It exists only as a trace in Uranium ores, and can't be extracted in meaningful quantities, it has to be made. The first nuclear weapons were made with the first reactors.
Little Boy was a U-235 gun-type bomb. The very first nuclear weapon was made from refined uranium, no reactor required. Fat Man was a plutonium bomb.
Your example misses the point precisely because it's just as clear in one line than in eight.
Except it's not "just as clear" in one line, it's clearer.
More lines, less lines, more comments, less comments -- the goal is clarity. More precisely, the goal is to minimize the level of effort required to understand and modify the code, and part of the effort required to understand is the effort required to read, and part of the effort required to modify is the effort required to update any comments.
All of the costs have to be considered, an an appropriate tradeoff chosen.
If data-hiding is always enforced, there are page after page of code which require absolutely zero comments because they are just get/set methods.
Somewhat off-topic, but getters and setters are one of the things I most dislike about current Java programming style. They're made somewhat necessary by the language, and very necessary by the libraries, but that's really unfortunate. Everyone should take a gander at how Python approaches properties and be enlightened.
For those who aren't familiar with Python (note: I'm not holding Python up as some paragon of language virtue; just pointing out that this is one thing the language gets right), in Python there is no need to write getters and setters.
Typically, properties start their life represented directly as private data fields. By hiding the data fields and exposing them only through getters and setters, we make it possible to change the representation of the property from a field to something else later, or to attach a little additional behavior. It's fairly rare that the flexibility is ever used, however. Generally, those fields wrapped in getFoo/setFoo methods just stay fields forever, and the getters and setters stay simple forever, meaning that there was no value in hiding the data to begin with. It would have worked just as well to make them public fields.
In Python, if your property's most convenient and useful representation is a public field, you make it a public field. If at some future point in time that changes, then you can reimplement the property with a getter and a setter, and client code doesn't have to change.
Thus, you eliminate page after page of useless boilerplate code, without losing flexibility. A future version of Java should allow private fields to be annotated as properties, causing getters and setters to be implicitly generated, and recommended Java style should change to use field-style properties rather than getter/setter-style properties wherever they make sense. Client code should always use the getters/setters. Some code generation tools do this already, but it should be moved into the standard compiler. Or something equivalent should be done. Having pages of getters and setters in our code, even if auto-generated, is just dumb.
We also know that the most secured airline in the world (El Al) hasn't had any successful attacks.
Have you ever flown El Al? I have, and I can tell you that, unlike the TSA, El Al does *not* engage in security theatre. Israeli airport security doesn't ban nail clippers or pocket knives or liquids. They don't bother with pat downs, either, nor do they x-ray your baggage, and Schneier knows all of this. In fact, he's written essays in which he pointed to El Al's approach as the right way to do airline security and contrasted it with what we do.
Israeli airport security is focused on identifying and removing terrorists, not their weapons. That's because it's fundamentally impossible to deny them weapons, and the Israelis understand that. They do search your belongings. By hand. Thoroughly. But they do it less to see what you have than to watch your reaction while they do it. While one agent is searching your stuff, two more are watching you. And they also ask a lot of questions about who you are, why you're traveling, where you've been, where you're going, etc., and they demand proof of your statements. They quizzed me in detail about every person I'd met with while in Israel, and then they actually called some of them on the phone to verify my statements. They also separated me from the people I was traveling with, asked us all questions individually, and then conferred with one another to compare the answers.
That's what real, serious airport security looks like. And it does work. The security theatre we have doesn't, not against anyone with a clue. It's trivial to smuggle a weapon onto a plane; I've done it accidentally! Really smart terrorists won't bother bringing anything through the front door, either. Have maintenance, cleaning crews, etc. bring the weapons in. US airport security in those areas is laughable. Not so on El Al flights.
You're right that security can be effective. Schneier is right that what we do is not security.
The first generation IS a hybrid, but then you implant that with extracted DNA, and so forth so that after several generations you get something that is pretty much equivalent to the extinct species.
How will that recover the mitochondrial DNA? What they need to do is to replace that as well, not just continue implanting the chromosomal DNA. Eventually we may learn how to do that, but we can't do it yet.
I rather type in 49.1.4.22 than 2001:db8:85a3::8a2e:370:7334
Meh. Besides the question about why you'd type either given the existence of DNS, my machine's IPv6 address is 2001:470:c:36b::1. Since pretty much EVERY IPv6 address in use in the near future begins with 2001, you don't really have to remember that, which means all I really have to remember is 470:c:36b. I think that's easier than any IPv4 address I've ever had.
Yeah, because just because you're underwater, the regular physics rulebook doesn't apply anymore. If you think that making "small changes in buoyancy" will give you any energy benefits at all, you must be living in some alternate universe where all the 100mpg carburetor people are teleported from. Sheesh.
It's not an issue of "normal physics" not applying, but rather of exploiting normal physics in an unusual, and very efficient, way. For example, the Slocum electric glider runs for 30 days on 260 C-cell batteries, meaning nominal power consumption is only 3.4W, to move a 110-lb glider at a velocity of 0.4 m/s. At that speed, it will cover just over 1000 km during a 30-day journey. That is phenomenal efficiency.
A previous/. article quite some time ago talked about the invention of these underwater gliders and how they could travel enormous distances on very, very little power. Basically they operate by making small changes in buoyancy. When slightly heavier than the water around them, they sink, but the water flowing over their wings drives them forward for significant distance for every meter they descend. Then they reverse it to become slightly lighter than the water, rising and again moving forward. Because this takes so little energy, they can travel thousands of kilometers on internal batteries.
However, there are other variants that don't use stored energy for propulsion at all, instead making use of temperature differentials to change their buoyancy. In deep, cold water they become positively buoyant, but when they're warmed by surface water they become negatively buoyant.
The article isn't very clear, but I don't think this one is thermally-powered.
For example, consider the following. Say bad things about PHP all you want (it deserves it) but one of the things you don't generally see with PHP code is a buffer overflow, where you try to copy a bunch of strings and concatenate them together and you run out of room and don't notice it and you go clobbering memory. That's because the string manipulation code goes through a bunch of checks when you're appending strings. You can't just skip these checks and hope that everything will work the same.
Of course, the same is true of the C++ std::string class.
Not that your point is wrong, but you chose a poor example.
David Weber's "Honor Harrington" series does a good job with space battles, too. In particular he addresses the issue of how difficult it is to engage an opponent who doesn't want to engage and has three degrees of freedom in which to escape -- basically you have to trick them somehow into building up a large enough velocity on a vector that brings them within your weapons envelope. Either that or you have to have a HUGE advantage in delta-v. He has to invent a lot of physics to address problems like the fact that navigation even around an area as small (hah!) as a solar system requires accelerations measured in hundreds of gravities in order to bring fleets into contact in mere days rather than months or years, and explores some interesting tactical and strategic implications of those technologies.
Orson Scott Card wrote a short story which unifies many of the world's flood myths and explains them as a sudden rise in the level of the Red Sea at the close of the last ice age.
Speculative fiction, not science, but pretty entertaining and a little bit interesting.
Agreed. And my original point was that a good way to determine if the system is working as intended is to see whether or not the disclosures are used as a resource by people looking for solutions to problems.
In software, at least, the recommended approach it to *avoid* looking at the patent database for fear of invoking the treble damages that come with willful infringement. There is no expectation of utility in patent searches, just an expectation of risk, because odds are so high that you've independently reinvented something.
That's proof that the system is broken, that it is impeding rather than encouraging progress. The system should be modified until the patent database becomes a valuable resource for engineers or, if that's not possible, it should be removed. If we can't find a way for it to foster innovation, at least we should prevent it from hampering innovation.
Slashdot Mirror
It doesn't obscure the network very well, though. There are a couple of papers on techniques for identifying the hosts and relationships of hosts behind NAT. Assuming the hosts make regular connections to the outside world, the information that can be gathered is pretty complete.
Also, you could get very similar effects with v6 by doing translation of the bottom 64 bits. Indeed, it's often recommended that hosts do this themselves: choose a different, random, value for the bottom 64 bits of each network request. That approach doesn't suffer from all of the limitations of NAT.
And port 1234 on the device at XXX:XX:XX::1 (a publicly-routable IPv6 address) has a remotely exploitable security hole. It's behind a cheap commercial Linksys router with a default-configured firewall which rejects inbound connections. How does a cracker in N. Korea casually exploit it?
Well, if the router config still has the default password, he logs into the router and modifies the firewall to allow access to what he wants.
Which is exactly the same situation if the Linksys is doing NAT.
You can. I can. Aunt Myrtle can't.
Can Aunt Myrtle install a NATing router connected to her cable modem? If so, then she can install a non-NATing router in exactly the same way that provides exactly the same firewall, just without the NAT.
That doesn't surprise me. However, I suspect that the ISPs who do NAT do it primarily to conserve address space, rather than so that they can force their customers to pay a premium for the privilege of being a producer, as asserted by shentino.
Why use DHCPv6? I much prefer stateless autoconfiguration. I was amazed at how well it works. The first time I fired up the radvd daemon on my home gateway (which is using a tunnel broker service to get v6), I was amazed at how every device on the LAN instantly had v6 access, with no action whatsoever on my part.
I don't have any comment on PXE/bootp. Haven't looked into that in the v6 world. It seems like v6 should make that trivial, though. Just pick a standard reserved local suffix to hold the boot service. The booting device should wait for a router advertisement to find out what network it's on, append the standard suffix and open a connection to get boot code. Done. That's just off the top of my head, of course.
None of the other providers seem to be even making a peep about it.
Comcast is planning to start deploying residential IPv6 this year. They haven't said how long it will take for a full rollout to all of their customers, but if they do get there, that will be a significant chunk of the US residential market that has native IPv6.
Of course there is - it allows all manner of insecure and misconfigured gear to avoid being probed from the other side of the planet?
That's not an advantage of NAT. That's an advantage of a stateful firewall that disallows inbound connections. NAT is not required to get the same benefit.
All of the machines in my home have public IPv6 addresses, but I have a firewall that blocks inbound connections to all of them. Same security result. No address translation.
Depends on the context. I absolutely want to disallow inbound connections to the machines in my home, except on a controlled basis. The same applies for corporate networks. But ISPs shouldn't do the same. On the other hand, how many ISPs do NAT? I'm not aware of any where I live.
Now, you'd think that means these devices are publically accessible, but noooo. If 99% of their '9.x.x.x' equipment that does have internet access attempts a connection, it gets NATed outbound to a different address entirely!
That's not my experience. HTTP connections often pass through a proxy, which means the target site sees a different IP, but that's not NAT. If you use a non-proxyable connection (e.g. SSH), the target host sees the real IP.
That's the way it seems to work from multiple US sites, anyway. I did see some actual NATing from sites in Asia.
For what? Do all their PCs have public IPs?
At present, yes. Also their phones. But the employees' PCs are a fraction of IBM's computers. Keep in mind that IBM runs large data centers all over the world.
Yes, were IBM to go through a very large and expensive network restructuring to move many of the internal networks to NAT, they could probably give a few million addresses back. Maybe as many as 15 million. And at the 2009 rate that would buy us 26 days.
Where I work has an entire class B and all of our PCs are public and we're talking now about NAT'ing them all, for security reasons.
That's silly.
There's no security value to NAT. NAT does provide a stateful firewall that disallows inbound connections, but you can do that just as well without NAT, and with a great deal more flexibility.
It has not yet become a big enough of a problem for the large sections of unused address by universities such as MIT and Harvard to be recalled.
At over 200 million new addresses needed per year, returning all of those class As wouldn't buy more than 2-3 years.
No, not really. There's companies with whole fucking /8 [iana.org] that have no real purpose to own them, but they've just always had them:
The block you listed contain a total of 301,989,888 addresses. At 2009's rate of 203 million addresses per year, returning those blocks would buy us less than 18 months. Big whoop.
Also, some of those companies actually do make significant use of the addresses they have. For example, I happen to know that IBM uses a good chunk of the 9.0.0.0 space.
Fat Man was fat because the physics package was a large sphere of explosives surrounding a sub-critical sphere of plutonium. Little Boy was long and thin, with a uranium "bullet" at one end and a uranium "spike" at the other.
You do not need nuclear reactors to make nuclear weapons. You can make nuclear fission weapons by using U-235 or Plutonium. If you have a centrifuge cascade like Iran does, or some other means to separate fuel, you can make U-235 weapons without owning a single nuclear reactor. The bomb dropped on Hiroshima (Little Boy) was of this type.
Not quite true. You can't make Plutonium based weapons without a reactor, because it is an artificial element. It exists only as a trace in Uranium ores, and can't be extracted in meaningful quantities, it has to be made. The first nuclear weapons were made with the first reactors.
Little Boy was a U-235 gun-type bomb. The very first nuclear weapon was made from refined uranium, no reactor required. Fat Man was a plutonium bomb.
Your example misses the point precisely because it's just as clear in one line than in eight.
Except it's not "just as clear" in one line, it's clearer.
More lines, less lines, more comments, less comments -- the goal is clarity. More precisely, the goal is to minimize the level of effort required to understand and modify the code, and part of the effort required to understand is the effort required to read, and part of the effort required to modify is the effort required to update any comments.
All of the costs have to be considered, an an appropriate tradeoff chosen.
If data-hiding is always enforced, there are page after page of code which require absolutely zero comments because they are just get/set methods.
Somewhat off-topic, but getters and setters are one of the things I most dislike about current Java programming style. They're made somewhat necessary by the language, and very necessary by the libraries, but that's really unfortunate. Everyone should take a gander at how Python approaches properties and be enlightened.
For those who aren't familiar with Python (note: I'm not holding Python up as some paragon of language virtue; just pointing out that this is one thing the language gets right), in Python there is no need to write getters and setters.
Typically, properties start their life represented directly as private data fields. By hiding the data fields and exposing them only through getters and setters, we make it possible to change the representation of the property from a field to something else later, or to attach a little additional behavior. It's fairly rare that the flexibility is ever used, however. Generally, those fields wrapped in getFoo/setFoo methods just stay fields forever, and the getters and setters stay simple forever, meaning that there was no value in hiding the data to begin with. It would have worked just as well to make them public fields.
In Python, if your property's most convenient and useful representation is a public field, you make it a public field. If at some future point in time that changes, then you can reimplement the property with a getter and a setter, and client code doesn't have to change.
Thus, you eliminate page after page of useless boilerplate code, without losing flexibility. A future version of Java should allow private fields to be annotated as properties, causing getters and setters to be implicitly generated, and recommended Java style should change to use field-style properties rather than getter/setter-style properties wherever they make sense. Client code should always use the getters/setters. Some code generation tools do this already, but it should be moved into the standard compiler. Or something equivalent should be done. Having pages of getters and setters in our code, even if auto-generated, is just dumb.
We also know that the most secured airline in the world (El Al) hasn't had any successful attacks.
Have you ever flown El Al? I have, and I can tell you that, unlike the TSA, El Al does *not* engage in security theatre. Israeli airport security doesn't ban nail clippers or pocket knives or liquids. They don't bother with pat downs, either, nor do they x-ray your baggage, and Schneier knows all of this. In fact, he's written essays in which he pointed to El Al's approach as the right way to do airline security and contrasted it with what we do.
Israeli airport security is focused on identifying and removing terrorists, not their weapons. That's because it's fundamentally impossible to deny them weapons, and the Israelis understand that. They do search your belongings. By hand. Thoroughly. But they do it less to see what you have than to watch your reaction while they do it. While one agent is searching your stuff, two more are watching you. And they also ask a lot of questions about who you are, why you're traveling, where you've been, where you're going, etc., and they demand proof of your statements. They quizzed me in detail about every person I'd met with while in Israel, and then they actually called some of them on the phone to verify my statements. They also separated me from the people I was traveling with, asked us all questions individually, and then conferred with one another to compare the answers.
That's what real, serious airport security looks like. And it does work. The security theatre we have doesn't, not against anyone with a clue. It's trivial to smuggle a weapon onto a plane; I've done it accidentally! Really smart terrorists won't bother bringing anything through the front door, either. Have maintenance, cleaning crews, etc. bring the weapons in. US airport security in those areas is laughable. Not so on El Al flights.
You're right that security can be effective. Schneier is right that what we do is not security.
The first generation IS a hybrid, but then you implant that with extracted DNA, and so forth so that after several generations you get something that is pretty much equivalent to the extinct species.
How will that recover the mitochondrial DNA? What they need to do is to replace that as well, not just continue implanting the chromosomal DNA. Eventually we may learn how to do that, but we can't do it yet.
I rather type in 49.1.4.22 than 2001:db8:85a3::8a2e:370:7334
Meh. Besides the question about why you'd type either given the existence of DNS, my machine's IPv6 address is 2001:470:c:36b::1. Since pretty much EVERY IPv6 address in use in the near future begins with 2001, you don't really have to remember that, which means all I really have to remember is 470:c:36b. I think that's easier than any IPv4 address I've ever had.
Yeah, because just because you're underwater, the regular physics rulebook doesn't apply anymore. If you think that making "small changes in buoyancy" will give you any energy benefits at all, you must be living in some alternate universe where all the 100mpg carburetor people are teleported from. Sheesh.
I shouldn't feed trolls, but... Here's the wiki page on underwater gliders, with links to more information about how they work.
It's not an issue of "normal physics" not applying, but rather of exploiting normal physics in an unusual, and very efficient, way. For example, the Slocum electric glider runs for 30 days on 260 C-cell batteries, meaning nominal power consumption is only 3.4W, to move a 110-lb glider at a velocity of 0.4 m/s. At that speed, it will cover just over 1000 km during a 30-day journey. That is phenomenal efficiency.
A previous /. article quite some time ago talked about the invention of these underwater gliders and how they could travel enormous distances on very, very little power. Basically they operate by making small changes in buoyancy. When slightly heavier than the water around them, they sink, but the water flowing over their wings drives them forward for significant distance for every meter they descend. Then they reverse it to become slightly lighter than the water, rising and again moving forward. Because this takes so little energy, they can travel thousands of kilometers on internal batteries.
However, there are other variants that don't use stored energy for propulsion at all, instead making use of temperature differentials to change their buoyancy. In deep, cold water they become positively buoyant, but when they're warmed by surface water they become negatively buoyant.
The article isn't very clear, but I don't think this one is thermally-powered.
For example, consider the following. Say bad things about PHP all you want (it deserves it) but one of the things you don't generally see with PHP code is a buffer overflow, where you try to copy a bunch of strings and concatenate them together and you run out of room and don't notice it and you go clobbering memory. That's because the string manipulation code goes through a bunch of checks when you're appending strings. You can't just skip these checks and hope that everything will work the same.
Of course, the same is true of the C++ std::string class.
Not that your point is wrong, but you chose a poor example.
David Weber's "Honor Harrington" series does a good job with space battles, too. In particular he addresses the issue of how difficult it is to engage an opponent who doesn't want to engage and has three degrees of freedom in which to escape -- basically you have to trick them somehow into building up a large enough velocity on a vector that brings them within your weapons envelope. Either that or you have to have a HUGE advantage in delta-v. He has to invent a lot of physics to address problems like the fact that navigation even around an area as small (hah!) as a solar system requires accelerations measured in hundreds of gravities in order to bring fleets into contact in mere days rather than months or years, and explores some interesting tactical and strategic implications of those technologies.
He also writes great stories.
Orson Scott Card wrote a short story which unifies many of the world's flood myths and explains them as a sudden rise in the level of the Red Sea at the close of the last ice age.
Speculative fiction, not science, but pretty entertaining and a little bit interesting.
Agreed. And my original point was that a good way to determine if the system is working as intended is to see whether or not the disclosures are used as a resource by people looking for solutions to problems.
In software, at least, the recommended approach it to *avoid* looking at the patent database for fear of invoking the treble damages that come with willful infringement. There is no expectation of utility in patent searches, just an expectation of risk, because odds are so high that you've independently reinvented something.
That's proof that the system is broken, that it is impeding rather than encouraging progress. The system should be modified until the patent database becomes a valuable resource for engineers or, if that's not possible, it should be removed. If we can't find a way for it to foster innovation, at least we should prevent it from hampering innovation.