If you implement a default deny firewall and are running randomised addresses, just how do you open a port ? Or otherwise grant access for inbound connections ?
Randomly assigned IP addresses can be static or dynamic. You assign one static to each machine and let it generate dynamic addresses on its own. For incoming connections you use the static IP of the machine. For outgoing connections you use one of the dynamic IP addresses of the machine.
I am just willing to wait for that or until ipv6 reaches critical mass and I am forced.
Too many people with that attitude is the reason for the mess we have now.
I still think a software solution is possible, but it would have to be done in the browser.
If the browser tries to open IPv4 and IPv6 connection in parallel and use the one that connects first, it will help on reliability in many cases. There are still a couple of issues. If you have an MTU problem the connection may open just fine but break when you transfer data. Sending the request over both connections is a bad idea as it will waste resources, and in some cases sending the request twice will actually cause state changes on the server to happen twice. So, by the time you realize that you have an MTU problem with one connection, it is too late to switch to the other. However you can get around many MTU problems by tweaking your MSS. None of these methods will help in case of the extremely broken DNS server, that I mentioned.
If a DNS server is so broken that the presence of an IPv6 in the cache prevents it from looking up an IPv4 address, then the web site will be inaccessible -- if they don't care to fix it, they'll simply lose viewers.
The problems are not on the IPv6 enabled websites. It is not because the people running those sites don't know how to run a website. They do in fact know how to run a website, and if the problem is on their own side of the connection, they can fix it. In many cases such sites will even find workarounds for problems on the client side or the intermediate network.
The DNS server I mentioned is on the client side. I don't know if the flaw was in the ISP's DNS servers or in the caching DNS server in the router provided by the ISP. In either case if you were a customer of that ISP and let your computer use the defaults, you would be using a broken DNS server.
If you are responsible for a website and you have to keep several nines of availability, how do you deal with such clients? You can't just go and fix the root problem, because it is completely outside of your control. And when you receive an AAAA request you just know the IP address of the DNS server the client is using, you don't know specifically which client. And by the time you have send an AAAA record, it is too late to change your mind.
When there is brokenness on the client side, a site that wants a high reliability will have to not just ensure their own systems work correctly, but also find the best workarounds for problems in other systems. In case of broken IPv6 connectivity, the workaround being used is mainly whitelisting of DNS servers that can receive AAAA records.
For some of the involved content providers the change is then going to be for one day they will pretend every DNS server is on the whitelist. (Care must be taken with the ttl values to ensure the exact time window is going to be predictable.)
If people violate the standard in that way, then collisions can happen. But at least it only happens if both networks violate the standard in the same way. If it does break at least you can blame each administrator independently as he is obviously responsible for misconfiguring his network. (If you want to avoid a situation where an administrator tries to argue that it is easier to fix the other network, then pretend there are three conflicting networks and it is easier for him to fix his own network than to get both of the other networks fixed).
The situation could be even worse, if some joker decided to use the same prefix that he saw some other network using. In such a case it wouldn't be obvious which of the networks didn't make a random choice. The standard could have included an elaborate technique for proving that the random prefix is yours. (Generate an RSA keypair, hash the public key and use the first 40 bits in your prefix. If necessary use the private key to prove that you picked this prefix). But this would be kind of overkill to put in the standard.
The fc00::/8 prefix is specifically reserved for use in case the random assignments somehow don't work out and would require a central authority. How the process for assigning prefixes would work in that case remains an open question, as we haven't seen the need yet, and we might never. If people are stupid enough to violate the standard, chances are that being able to pinpoint exactly who is violating the standard isn't going to help all that much.
Why doesn't glibc patch their DNS resolver to cache the "working/not working" state of IPv6?
The DNS resolver only knows if the DNS resolution worked. It won't know if the actual connection to the resulting IP worked. (And even if it did know that the connection didn't work, the result could be different depending on what communication you did with that IP address, for example it could be that some ports work on IPv4 and others work on IPv6).
Or even better, run the IPv6 and IPv4 DNS queries in parallel and use whichever answer is returned first -- not to discard the slower of the two but to wait for it to succeed and cache the state
The resolver probably already does the lookups in parallel. But in many cases the DNS lookup works but the actual connection fails. And if DNS lookup fails, it is not guaranteed that trying both will help. I have seen a case of a DNS server that would corrupt its own cache if you asked for IPv4 and IPv6 addresses for the same domain name. So the first lookup to reach the DNS server would work, and the other would not. This could lead to a situation where you first lookup the IPv6 address get a correct answer, but then find you cannot connect. Then you try IPv4, but because the DNS server's caching is so broken, the presence of an IPv6 in the cache prevents it from looking up an IPv4 address for the same domain name.
Address randomisation does not even begin to solve the problem
Did you even watch the video you linked to? If you watched the video you would find that address randomization does solve that problem, but only if you use it. What he found was that a lot of servers have IP addresses that are not random, so he could find them by scanning with a few different tricks.
Since the starting point was a bunch of DNS entries, it is not clear that these IP addresses were even supposed to be secret to begin with. But if you do use random addresses, none of the tricks mentioned in that video will find it.
The rest of the video was discussing various attacks that can be performed if you are on the same LAN as the target. Many of those attacks are similar to what you could do with IPv4, and the typical solution with IPv4 would be to configure filters in your switches. Similar attacks against IPv6 requires similar filters, which shouldn't come as a shock to network administrators.
I think the most interesting attack mentioned was that a rogue machine on an IPv4 only network could perform a man-in-the-middle attack by sending out an IPv6 router advertisement and cause other machines on the LAN to believe it was a dual stack network and use IPv6 by default.
He pointed out a few other places where the IPv6 stacks are not as mature as IPv4, and that supposedly you can crash most machines on a LAN through these. But none of this should discourage you from upgrading your network, since the attacks only worked locally, and they would work even if your network was IPv4 only because the attacker could turn on IPv6 on demand.
All in all an interesting video, but the one point you mentioned wasn't being made.
If in a IPv6 NAT-less world, you have a firewall, but no NAT, you see what each individual IP6 address likes or diskiles, regardless the span of a "session".
I suppose an OS could actually easily address that concern. Whenever a connection is established it could be assigned a newly generated random address unless the application had explicitly bound the socket to an IP address. It does mean the gateway will have to keep track of more IP to MAC mappings than it would otherwise, but the number of entries to track isn't going to be more than the number of connections a NAT would have to track today. And if they do expire, it just means you'll have to wait a few microseconds for it to ask for the IP address. When the same kind of expiry happens in a NAT, it causes the connection to break.
NAT doesn't make anything easier except hiding how many systems are behind a gateway.
But even that doesn't really work with IPv4. The main problem is with the IPID field. Any combination of source IP, destination IP, and IPID must not be reused within a packet lifetime. But when two machines behind the NAT sends packets out the gateway mangles the source IP address, and if two packets were send with different source IP but identical IPID, it would have been perfectly valid until they passed the NAT. A typical NAT doesn't touch the IPID field and just pass it on unmodified. Modifying the IPID wouldn't work very well anyway as the state that would need to be tracked gets impractical.
Many systems generate predictable IPID values, and when they go through the NAT unmodified it is fairly easy to count the systems. Even if each system was to generate unpredictable IPID values, any collision would prove that two packets were sent by different systems. Since every packet in a TCP stream is from the same system, this will allow counting systems even if they generate unpredictable IPID values. You could work around this by setting DF on every TCP packet and just put random bits in the IPID field. This would of course have to be done by the sending host. If the NAT did those modifications, it would be breaking communication for hosts that didn't anticipate such modifications.
If your intention with using NAT is to hide how many machines are behind the NAT, then you are better off using NAT with IPv6. With IPv6 the IPID field doesn't exist if it doesn't have to. And the DF bit does not exist either because it is implicitly on, any fragmentation must be done by the sender, intermediate routers are not allowed to do it. This means with IPv6 there is much fewer packets with IPID, that could reveal the number of hosts behind the NAT. And when IPID is included, it is twice as large as in IPv4, which reduces the risk of collisions significantly. That means less risk of the NAT breaking stuff by causing IPID collisions, and with fewer collisions there will be less chance of identifying different systems behind the NAT due to collisions.
a lot of IP device's that do not need a public address, my printer for starters
It may be correct that your printer does not need a public IP address. However the same argument has been used for lots of devices that do need to communicate with the outside world. And there certainly aren't enough IPv4 addresses for the devices that do need a public address for proper operation.
Let's get back to that printer. Let's assume you will never want to print to it from computers outside of the same local network, then you can indeed assign it a link local or unique local address. This however is not an argument in the favor of NAT. That printer then should never communicate with the outside world, and those devices that do need to communicate with the outside world have their own address for communicating with the outside world.
The use of address reserved by RFC 1918 has not been without problems. There may be a lot, but there have still been conflicts. The problem is there isn't exactly one scope within which you want them to be unique. You may have a router in your home that assigns a range of RFC 1918 addresses to a local segment. Your ISP might also be using some RFC 1918 addresses for equipment that you need to communicate with as a customer, but doesn't need to be accessed by anybody outside of that ISP's network. You might also be using a VPN connection from a machine on your local network to some remote site, which makes use of RFC 1918 addresses.
These addresses are all assigned by different people and none of them know at the time they assign the addresses, which other RFC 1918 addresses you will need to communicate with. This leads to conflicts.
With IPv6 there is a replacement for RFC 1918, it is RFC 4193. With RFC 4193 there is first of all a randomly selected 40 bit site ID which reduces the risk of collisions significantly. And each such site will have a 16 bit subnet ID that you can manage locally. With that you get as many subnets as if you had split 10/8 into/24 subnets, and you still avoid all the collisions that would have happened if multiple entities decided to assign the same subnet of 10/8 to things that you needed to communicate with.
So, even for the case of devices that don't need a globally routable address, IPv6 is still better than IPv4.
Setting a fixed time moves the goal to whomever can shave their systems closest to that fixed time.
There would only be to reasons for going that way. One reason would be to be able to complete some heavier calculations before the deadline. But if that was the reason then more processing power and faster algorithms is a much more reliable way to achieve the same than playing the latency games.
The other (more likely) reason for wanting to get close to the deadline is to take benefit of additional information that became available later. You can stop information from the market itself from being used in this way by ensuring it is only published at the same intervals. Let bids be submitted encrypted and then be published after the bid closes for the round.
With this approach the only reason left for playing with the latency is if external information could affect the prices. So, if something comes up in the news that could change the prices, then if such news breaks just before the deadline and automatic trading systems takes this into account, then playing with latencies can matter in those rare cases.
The longer the period, the less likely the news is to break just before the deadline.
That way you'd remove the "legitimate" reasons for worrying about subsecond latencies. If none of the regular traders are dependent on subsecond latencies, then hackers trying to affect prices by affecting those latencies will have a much harder job.
If you try to affect the one remaining place where the latencies matters, namely for external news, you'd have a much higher chance of any significatn impact by manipulating the contents of the news themselves rather than the timing of them.
Isn't this question answered by the "48 kbit/s" in my original post?
No, that just tells how much bandwidth is used for the encoded version. With a CD, you have a 16 bit 44100Hz stereo master, and that is transferred unmodified all the way to the DA converter, which operates at that same spec.
If you are going to use a lossy compression but run the DA converter with the same resolution and rate, then the quality will be worse than CD quality. It may not be much worse, but it will be worse. If you were to use better specs for the playback, but still use a master in CD quality, then a lossy compression would also mean worse quality.
Sure, the way a CD works is not the most efficient way to use 1.4Mbit/s of bandwidth, but it does give the best quality that you can possibly achieve with audio hardware running at 44100Hz 16bit stereo. If you want the most quality out of a given bandwidth, you would be better off with better audio hardware and a lossy compression.
It might be possible to do better than CD quality with 48Kbit/s, but you will need to improve some other aspect such as resolution, rate, number of channels, or all of them. For example 96Khz 24bit stereo compressed with a lossy compression could give better than CD quality with a lower bitrate than a CD would use.
Saying that less than 1% can tell the difference doesn't mean that the quality is the same. It just tells you that less than 1% can tell the difference. If you have two versions that both have artefacts, but they have different artefacts, then it may be possible for most people to tell the difference, but the two may be of the same quality or impossible to quantify, which is the best.
Finally, not all CDs are actually manufactured with CD quality. There is a lot of ways the quality of the sound can be degraded before being put on a CD in the first place. (I have seen 14 bit recordings that were scaled up to 16 bit and then shipped on CD).
But it was the servers that were not responding, which triggered the entire cascade. A bug in the client caused it to crash when it didn't get the expected response from those servers. Once that cascade had started getting those servers up didn't stop the problem. The system wasn't geared to bootstrap from a situation where many clients had been down simultaneously.
People were satisfied with the initial release of v5 and saw no need to update (meaningless bug fixes, no useful features, who cares).
Maybe there are people who think that way, but to me it sounds totally backwards. I usually prefer the updates that are just bugfixes. Being forced to upgrade to a new version with new features because of security bugs in the old version is an annoyance. It would be so much more convenient to install a new version that was identical to what I already had with just that one bug fixed. But instead I may have to upgrade to a new version that adds some features that I never needed, removed some features that I used on a daily basis, fixed one critical security bug, and added a few new bugs (that were not security problems, just making my computer crash once a day or something like that).
What I think would really be much better would be to first of all let users know if an update was bugfixes or adding features, second give users the opportunity to see more details about what is changed in the update, and finally give users a reliable way to downgrade if they should experience problems with the update. I think one of the main reasons for people not installing updates is a history of some companies using automated updates to push their own agenda instead of giving users improved software.
If the skype client finds itself on a publicly accessible IP and with reasonably consistent network access, then it will offer supernode services to other clients.
How large a percentage of the clients actually become supernodes? From the blog it sounds like less than one percent. Would this number have been a lot higher, if NAT had not been so widely deployed.
The supernodes provide 2 important services - directory services, and firewall piercing.
I guess more often it will need to pierce through NAT rather than firewalls. Sounds like this means the more clients use NAT, the more work the supernodes will have to do.
Would it be correct to assume, that if NAT had not been widely deployed, this outage would never have happened?
client crash bug resulted in 40% of the supernodes vanishing instantly (and 40% of the clients).
Actually the blog said 20% of the clients and 25-30% of the supernodes. I'm not sure if the percentage actually means anything in this case. Would the supernodes have been able to handle the load from reconnecting clients if all supernodes had stayed up and only some percentage of clients died?
These supernodes became overloaded, and automatically shutdown to prevent excessive resource usage
Is this a classical case of "it seemed like a good idea at the time"? This behaviour does indeed sound like a perfect recipe for cascading failure.
it would probably be much better to spawn new servers to deal with increased load instead of shutting down working servers.
I wondered about that too. If at least they stayed up and kept responding with a somewhat increased latency, the system might have stayed alive. Obviously the clients should also have had some kind of back-off strategy. It isn't clear if they did in this incident or not.
A CPU getting faster does almost nothing if your process is IO bound.
You are right, that is another aspect to it. It is entirely possible that a problem that required lots of disk I/O 15 years ago would fit in RAM today, maybe it would even fit in L3 cache. Under such circumstances it may be that an unmodified algorithm would run a million times faster on a modern computer compared to a computer from 15 years ago. Even if no part of the machine is a million times faster. In fact having enough RAM could mean close to a million times performance difference on hardware of exactly the same speed if the algorithm does lots of random access.
A known optimum algorithm isn't going to get any better if we already know the best possible time is say log(n). But the implementation of that algorithm can improve many times through optimizing the code for the hardware.
To show that an algorithm is optimal you need to do it within some computational model. Some models consider I/O, others don't. An algorithm which is efficient in both kinds of models tend to be complex and have a somewhat larger constant, but not by several orders of magnitude. For such problems it may have been that if we knew an optimal algorithm at that time, it was with the simple model.
which improvement would be responsible for the increased performance? I'd argue they're inseparable.
You could define your way out of that problem, but the results may not be very useful anyway. For example you could say an algorithm would only be considered optimal if it was optimal on both kinds of hardware (such a definition would make some kind of sense, and it would be possible to implement such an algorithm). With that algorithm you could compare the performance of the two machines, but it would still only measure the hardware improvement on a specific problem, and the number you get out may not apply to any other problem.
When hardware gets faster it applies more or less uniformly to all algorithms you run on that hardware. When an algorithm is improved it applies to just one specific problem. For some problems we already knew close to optimal algorithms 15 years ago, in those cases there was no way algorithmic improvements could have achieved such a speedup. And in fact the article mentions just one specific problem where algorithmic improvements made it about 43.000 times faster on one specific input. In other words, this number is not nearly as general as the summary makes it sound. The are algorithms that were not speeded up nearly as much, and for any algorithms that were bad enough to begin with, there could have been an even larger speedup - without anybody making a fuss about it.
How many bits are there in the optimal coding for this post?
He said it was easily definable, not that it was easily computable. The length of the optimal coding would be the kolmogorov complexity. It is easy to define, but it is undecidable. Computing the length is equivalent to solving the halting problem.
i know some people that demand to use remote X to open a local terminal window rather than SSH'ing to the machine.
Sometimes running xterm over X forwarding over ssh is the best way to work. It's a bit easier to get that working correctly than just plain ssh in those cases where one end of the connection uses ISO 8859-1 and the other end uses UTF-8.
If DNSSEC works perfectly (i.e. data cryptographically validated on the local host), then it may displace some insecure workarounds commonly in place.
It is possible to distribute the known hosts file in a secure way. But of course it is also possible to do it in an insecure way. Those organizations that care enough about security to implement a secure distribution of a known hosts file, shouldn't be forced to trust a key obtained via DNSSEC. A reasonable default would be to refuse to connect to a host for which you get different keys from/etc and from DNSSEC, and assume that keys in the users own known hosts file were obtained from DNSSEC in the first place and just ask the user for confirmation before updating it. Obviously it should be possible to change the configuration to make the policy whatever you want.
Only if the protocol is crappy. Sure, telnet, http without SSL and friends would be vulnerable, but https and ssh would not be directly attackable in this way.
As it stands now, DNSSEC mainly protects those protocols that don't have their own protection built in. I think the majority of attacks you would protect against would be on http. I think it would be a while before https and ssh would see any benefit from DNSSEC.
If SSH however uses DNSSEC assurance as a trusted way of updating known_hosts, it becomes a vector for man in the middle.
If ssh used DNSSEC to update the known hosts file without asking the user for confirmation, it would be a significant drop in security. If ssh updated the known hosts file just because it had use DNSSEC to verify the correctness of the IP address it was connecting to, without having received any information about the new key, that would be plain stupid.
If ssh however could get the public key from DNSSEC and store it in the known hosts file the first time you connect and not yet have the key in your known hosts file, then it would improve security. (As with anything, if the improved security causes users to be less careful, then it may not make the system more secure after all.)
Guess I should say that is SPECIFICALLY what I am talking about. SSHFP records are fingerprints of host public keys.
Nice, I didn't know about RFC 4255 before now. This is the kind of thing I had in mind, I didn't know it already existed.
*If* DNSSEC were implemented in a way where validity is assured by the local system, then known_hosts isn't needed, validity is assured via a chain of trust, and people don't blindly accept new keys for lack of convenient alternatives.
I'd not trust it as an alternative to known hosts, but as a supplement it sounds like a good idea. The problem with the DNSSEC chain of trust is that you have to trust a lot more parties than you do with the known hosts file.
This means that anyone able to spoof their way between you and your nameserver can *still* compromise DNS.
Anybody who could do that could probably pull off the same hijacking without spoofing a DNS record. Even if you have the correct IP of the server you want to talk to, they could hijack your traffic to that IP. It does give them one more point to attack, so it still means there is a reason to protect that part of the communication, however it isn't currently the weakest point.
This is better than the current state of things which is subject to shenanigans in a much wider scope, but still.
Exactly. The immediate problem we are facing is the possibility to poison caching name servers shared by many users. An attacker sends requests and forged responses more or less simultaneously to a server, and with a bit of luck gets a forged record cached. If we can get such servers to verify DNSSEC signatures we may have fixed the weakest point that we currently have. As such it is only a small part of the infrastructure that actually needs to be updated before we start getting some benefit. Once that part is in place we can get a bit more benefit from deploying checking all the way to the clients.
I'm looking at OpenSSH particularly hard here.
The way ssh currently works, it doesn't make a huge difference if the DNS records are signed or not. Either you get a DNS record with an invalid signature, and you just never connect to any server, or you get an incorrect IP and connect after which ssh reports the server has a wrong host key. The attacker could also try to just hijack the TCP connection without giving you an incorrect IP address, in that case ssh would also report a wrong host key.
The real case for ssh using DNSSEC would actually be if host keys could be put in DNS as well. However it is unclear to me if that would be anymore secure or easier to maintain than a known hosts file.
I don't see how captive portals that rely on DNS tricks will work.
In short, they are not supposed to. This is really a dirty hack to work around the lack of any standard way of setting up such a signup system. A slightly cleaner approach, that I don't know how well would work, would be as follows.
Provide some domain to search under through DHCP.
Cause DNS lookups to the domain requested by the user to fail with server error
When search is repeated under search domain, give IP of redirection server.
Once user is signed up allow them to lookup the real DNS records.
Optionally the redirection server could act as transparent proxy if the user is already signed up.
Another mechanism is to only redirect the HTTP request and respond with a 301 or login page. This should still work with DNSSEC.
This is how most of them behaves because it is the most reliable way to work around the problems caused by the records being cached. Some such systems also redirect https, which obviously leads to browsers warning about incorrect certificates. This is very annoying if you had your laptop suspended with some open ajax applications. I wish browsers could be configured to just consider it an error, and not ask me every time it sees an invalid certificate.
The only reason it works with HTTP is that there is no end to end security. It only protects DNS, not the connection you create to the returned IP afterwards. That could of course be implemented using some additional DNS records with public keys. Such a system might actually turn out to be easier to deploy than https, so it could look like a threat to the current CAs.
So the big players, are probably a bit reluctant to enable DNSSEC on their domain because of the users that happen to sit behind the first type of captive portal.
I doubt that is the reason. They are basically allowing somebody to perform a man in the middle attack against the connections to their server. They may think these man in the middle attacks are only used for good purposes, but they have no control over that.
I actually dislike the first mechanism, because even when it can be implemented nicely, many captives portals forget to set DNS response lifetime to 0 seconds so that when you have signed in/up, your DNS resolver will retry the query.
Browser and/or resolver may still cache the entry even if it has ttl 0. In fact some browsers do it deliberately for security reasons. There are some javascript based attacks that can be performed if you change an A record from pointing at a malicious server to point at a site where you want to perform some sort of attack. (Or maybe it was the other way around, sorry, I don't remember all the details). It is a quite broken security model, and arbitrarily caching lookups past expiry is a terrible workaround.
So when connecting to a wifi network I don't know the details about I always first go to a webpage that I don't want to go to.
I went as far as creating a bookmark in my browser for that exact purpose. If I do get through to the server in question, it will redirect me to my own homepage.
If, rather than sending the money on to the scammer, the 'victim' withdrew the money in a cashiers cheque (or even a suitcase full of notes, I guess) and disappeared, surely they can keep the money as long as they can hide (or avoid extradition) and the bank is screwed?
Withdrawing a small amount of cash is fast and easy. Withdrawing a large amount is more involved. That may get delayed for long enough to notice the fraud.
Also, if you run with the money, they know who you are, and it will probably look like you were doing the fraud on your own. The people who manufactured the original forged cheque in this story would probably not stand up and say, hey that was our forged cheque and we want those stolen money.
It would have to either be a hell of a lot of money, or the life you were leaving behind would have to be pretty worthless, otherwise I'd say it wouldn't be worth it. How much does a new identity cost? (Does it come with a warranty against being blown?)
Slashdot Mirror
Randomly assigned IP addresses can be static or dynamic. You assign one static to each machine and let it generate dynamic addresses on its own. For incoming connections you use the static IP of the machine. For outgoing connections you use one of the dynamic IP addresses of the machine.
Too many people with that attitude is the reason for the mess we have now.
If the browser tries to open IPv4 and IPv6 connection in parallel and use the one that connects first, it will help on reliability in many cases. There are still a couple of issues. If you have an MTU problem the connection may open just fine but break when you transfer data. Sending the request over both connections is a bad idea as it will waste resources, and in some cases sending the request twice will actually cause state changes on the server to happen twice. So, by the time you realize that you have an MTU problem with one connection, it is too late to switch to the other. However you can get around many MTU problems by tweaking your MSS. None of these methods will help in case of the extremely broken DNS server, that I mentioned.
The problems are not on the IPv6 enabled websites. It is not because the people running those sites don't know how to run a website. They do in fact know how to run a website, and if the problem is on their own side of the connection, they can fix it. In many cases such sites will even find workarounds for problems on the client side or the intermediate network.
The DNS server I mentioned is on the client side. I don't know if the flaw was in the ISP's DNS servers or in the caching DNS server in the router provided by the ISP. In either case if you were a customer of that ISP and let your computer use the defaults, you would be using a broken DNS server.
If you are responsible for a website and you have to keep several nines of availability, how do you deal with such clients? You can't just go and fix the root problem, because it is completely outside of your control. And when you receive an AAAA request you just know the IP address of the DNS server the client is using, you don't know specifically which client. And by the time you have send an AAAA record, it is too late to change your mind.
When there is brokenness on the client side, a site that wants a high reliability will have to not just ensure their own systems work correctly, but also find the best workarounds for problems in other systems. In case of broken IPv6 connectivity, the workaround being used is mainly whitelisting of DNS servers that can receive AAAA records.
For some of the involved content providers the change is then going to be for one day they will pretend every DNS server is on the whitelist. (Care must be taken with the ttl values to ensure the exact time window is going to be predictable.)
If people violate the standard in that way, then collisions can happen. But at least it only happens if both networks violate the standard in the same way. If it does break at least you can blame each administrator independently as he is obviously responsible for misconfiguring his network. (If you want to avoid a situation where an administrator tries to argue that it is easier to fix the other network, then pretend there are three conflicting networks and it is easier for him to fix his own network than to get both of the other networks fixed).
The situation could be even worse, if some joker decided to use the same prefix that he saw some other network using. In such a case it wouldn't be obvious which of the networks didn't make a random choice. The standard could have included an elaborate technique for proving that the random prefix is yours. (Generate an RSA keypair, hash the public key and use the first 40 bits in your prefix. If necessary use the private key to prove that you picked this prefix). But this would be kind of overkill to put in the standard.
The fc00::/8 prefix is specifically reserved for use in case the random assignments somehow don't work out and would require a central authority. How the process for assigning prefixes would work in that case remains an open question, as we haven't seen the need yet, and we might never. If people are stupid enough to violate the standard, chances are that being able to pinpoint exactly who is violating the standard isn't going to help all that much.
The DNS resolver only knows if the DNS resolution worked. It won't know if the actual connection to the resulting IP worked. (And even if it did know that the connection didn't work, the result could be different depending on what communication you did with that IP address, for example it could be that some ports work on IPv4 and others work on IPv6).
The resolver probably already does the lookups in parallel. But in many cases the DNS lookup works but the actual connection fails. And if DNS lookup fails, it is not guaranteed that trying both will help. I have seen a case of a DNS server that would corrupt its own cache if you asked for IPv4 and IPv6 addresses for the same domain name. So the first lookup to reach the DNS server would work, and the other would not. This could lead to a situation where you first lookup the IPv6 address get a correct answer, but then find you cannot connect. Then you try IPv4, but because the DNS server's caching is so broken, the presence of an IPv6 in the cache prevents it from looking up an IPv4 address for the same domain name.
Did you even watch the video you linked to? If you watched the video you would find that address randomization does solve that problem, but only if you use it. What he found was that a lot of servers have IP addresses that are not random, so he could find them by scanning with a few different tricks.
Since the starting point was a bunch of DNS entries, it is not clear that these IP addresses were even supposed to be secret to begin with. But if you do use random addresses, none of the tricks mentioned in that video will find it.
The rest of the video was discussing various attacks that can be performed if you are on the same LAN as the target. Many of those attacks are similar to what you could do with IPv4, and the typical solution with IPv4 would be to configure filters in your switches. Similar attacks against IPv6 requires similar filters, which shouldn't come as a shock to network administrators.
I think the most interesting attack mentioned was that a rogue machine on an IPv4 only network could perform a man-in-the-middle attack by sending out an IPv6 router advertisement and cause other machines on the LAN to believe it was a dual stack network and use IPv6 by default.
He pointed out a few other places where the IPv6 stacks are not as mature as IPv4, and that supposedly you can crash most machines on a LAN through these. But none of this should discourage you from upgrading your network, since the attacks only worked locally, and they would work even if your network was IPv4 only because the attacker could turn on IPv6 on demand.
All in all an interesting video, but the one point you mentioned wasn't being made.
I suppose an OS could actually easily address that concern. Whenever a connection is established it could be assigned a newly generated random address unless the application had explicitly bound the socket to an IP address. It does mean the gateway will have to keep track of more IP to MAC mappings than it would otherwise, but the number of entries to track isn't going to be more than the number of connections a NAT would have to track today. And if they do expire, it just means you'll have to wait a few microseconds for it to ask for the IP address. When the same kind of expiry happens in a NAT, it causes the connection to break.
But even that doesn't really work with IPv4. The main problem is with the IPID field. Any combination of source IP, destination IP, and IPID must not be reused within a packet lifetime. But when two machines behind the NAT sends packets out the gateway mangles the source IP address, and if two packets were send with different source IP but identical IPID, it would have been perfectly valid until they passed the NAT. A typical NAT doesn't touch the IPID field and just pass it on unmodified. Modifying the IPID wouldn't work very well anyway as the state that would need to be tracked gets impractical.
Many systems generate predictable IPID values, and when they go through the NAT unmodified it is fairly easy to count the systems. Even if each system was to generate unpredictable IPID values, any collision would prove that two packets were sent by different systems. Since every packet in a TCP stream is from the same system, this will allow counting systems even if they generate unpredictable IPID values. You could work around this by setting DF on every TCP packet and just put random bits in the IPID field. This would of course have to be done by the sending host. If the NAT did those modifications, it would be breaking communication for hosts that didn't anticipate such modifications.
If your intention with using NAT is to hide how many machines are behind the NAT, then you are better off using NAT with IPv6. With IPv6 the IPID field doesn't exist if it doesn't have to. And the DF bit does not exist either because it is implicitly on, any fragmentation must be done by the sender, intermediate routers are not allowed to do it. This means with IPv6 there is much fewer packets with IPID, that could reveal the number of hosts behind the NAT. And when IPID is included, it is twice as large as in IPv4, which reduces the risk of collisions significantly. That means less risk of the NAT breaking stuff by causing IPID collisions, and with fewer collisions there will be less chance of identifying different systems behind the NAT due to collisions.
It may be correct that your printer does not need a public IP address. However the same argument has been used for lots of devices that do need to communicate with the outside world. And there certainly aren't enough IPv4 addresses for the devices that do need a public address for proper operation.
/24 subnets, and you still avoid all the collisions that would have happened if multiple entities decided to assign the same subnet of 10/8 to things that you needed to communicate with.
Let's get back to that printer. Let's assume you will never want to print to it from computers outside of the same local network, then you can indeed assign it a link local or unique local address. This however is not an argument in the favor of NAT. That printer then should never communicate with the outside world, and those devices that do need to communicate with the outside world have their own address for communicating with the outside world.
The use of address reserved by RFC 1918 has not been without problems. There may be a lot, but there have still been conflicts. The problem is there isn't exactly one scope within which you want them to be unique. You may have a router in your home that assigns a range of RFC 1918 addresses to a local segment. Your ISP might also be using some RFC 1918 addresses for equipment that you need to communicate with as a customer, but doesn't need to be accessed by anybody outside of that ISP's network. You might also be using a VPN connection from a machine on your local network to some remote site, which makes use of RFC 1918 addresses.
These addresses are all assigned by different people and none of them know at the time they assign the addresses, which other RFC 1918 addresses you will need to communicate with. This leads to conflicts.
With IPv6 there is a replacement for RFC 1918, it is RFC 4193. With RFC 4193 there is first of all a randomly selected 40 bit site ID which reduces the risk of collisions significantly. And each such site will have a 16 bit subnet ID that you can manage locally. With that you get as many subnets as if you had split 10/8 into
So, even for the case of devices that don't need a globally routable address, IPv6 is still better than IPv4.
There would only be to reasons for going that way. One reason would be to be able to complete some heavier calculations before the deadline. But if that was the reason then more processing power and faster algorithms is a much more reliable way to achieve the same than playing the latency games.
The other (more likely) reason for wanting to get close to the deadline is to take benefit of additional information that became available later. You can stop information from the market itself from being used in this way by ensuring it is only published at the same intervals. Let bids be submitted encrypted and then be published after the bid closes for the round.
With this approach the only reason left for playing with the latency is if external information could affect the prices. So, if something comes up in the news that could change the prices, then if such news breaks just before the deadline and automatic trading systems takes this into account, then playing with latencies can matter in those rare cases.
The longer the period, the less likely the news is to break just before the deadline.
That way you'd remove the "legitimate" reasons for worrying about subsecond latencies. If none of the regular traders are dependent on subsecond latencies, then hackers trying to affect prices by affecting those latencies will have a much harder job.
If you try to affect the one remaining place where the latencies matters, namely for external news, you'd have a much higher chance of any significatn impact by manipulating the contents of the news themselves rather than the timing of them.
No, that just tells how much bandwidth is used for the encoded version. With a CD, you have a 16 bit 44100Hz stereo master, and that is transferred unmodified all the way to the DA converter, which operates at that same spec.
If you are going to use a lossy compression but run the DA converter with the same resolution and rate, then the quality will be worse than CD quality. It may not be much worse, but it will be worse. If you were to use better specs for the playback, but still use a master in CD quality, then a lossy compression would also mean worse quality.
Sure, the way a CD works is not the most efficient way to use 1.4Mbit/s of bandwidth, but it does give the best quality that you can possibly achieve with audio hardware running at 44100Hz 16bit stereo. If you want the most quality out of a given bandwidth, you would be better off with better audio hardware and a lossy compression.
It might be possible to do better than CD quality with 48Kbit/s, but you will need to improve some other aspect such as resolution, rate, number of channels, or all of them. For example 96Khz 24bit stereo compressed with a lossy compression could give better than CD quality with a lower bitrate than a CD would use.
Saying that less than 1% can tell the difference doesn't mean that the quality is the same. It just tells you that less than 1% can tell the difference. If you have two versions that both have artefacts, but they have different artefacts, then it may be possible for most people to tell the difference, but the two may be of the same quality or impossible to quantify, which is the best.
Finally, not all CDs are actually manufactured with CD quality. There is a lot of ways the quality of the sound can be degraded before being put on a CD in the first place. (I have seen 14 bit recordings that were scaled up to 16 bit and then shipped on CD).
But it was the servers that were not responding, which triggered the entire cascade. A bug in the client caused it to crash when it didn't get the expected response from those servers. Once that cascade had started getting those servers up didn't stop the problem. The system wasn't geared to bootstrap from a situation where many clients had been down simultaneously.
People were satisfied with the initial release of v5 and saw no need to update (meaningless bug fixes, no useful features, who cares).
Maybe there are people who think that way, but to me it sounds totally backwards. I usually prefer the updates that are just bugfixes. Being forced to upgrade to a new version with new features because of security bugs in the old version is an annoyance. It would be so much more convenient to install a new version that was identical to what I already had with just that one bug fixed. But instead I may have to upgrade to a new version that adds some features that I never needed, removed some features that I used on a daily basis, fixed one critical security bug, and added a few new bugs (that were not security problems, just making my computer crash once a day or something like that).
What I think would really be much better would be to first of all let users know if an update was bugfixes or adding features, second give users the opportunity to see more details about what is changed in the update, and finally give users a reliable way to downgrade if they should experience problems with the update. I think one of the main reasons for people not installing updates is a history of some companies using automated updates to push their own agenda instead of giving users improved software.
CD quality as low as 48k
What rate and resolution would you be using for the recording and playback in that case?
If the skype client finds itself on a publicly accessible IP and with reasonably consistent network access, then it will offer supernode services to other clients.
How large a percentage of the clients actually become supernodes? From the blog it sounds like less than one percent. Would this number have been a lot higher, if NAT had not been so widely deployed.
The supernodes provide 2 important services - directory services, and firewall piercing.
I guess more often it will need to pierce through NAT rather than firewalls. Sounds like this means the more clients use NAT, the more work the supernodes will have to do.
Would it be correct to assume, that if NAT had not been widely deployed, this outage would never have happened?
client crash bug resulted in 40% of the supernodes vanishing instantly (and 40% of the clients).
Actually the blog said 20% of the clients and 25-30% of the supernodes. I'm not sure if the percentage actually means anything in this case. Would the supernodes have been able to handle the load from reconnecting clients if all supernodes had stayed up and only some percentage of clients died?
These supernodes became overloaded, and automatically shutdown to prevent excessive resource usage
Is this a classical case of "it seemed like a good idea at the time"? This behaviour does indeed sound like a perfect recipe for cascading failure.
it would probably be much better to spawn new servers to deal with increased load instead of shutting down working servers.
I wondered about that too. If at least they stayed up and kept responding with a somewhat increased latency, the system might have stayed alive. Obviously the clients should also have had some kind of back-off strategy. It isn't clear if they did in this incident or not.
You are right, that is another aspect to it. It is entirely possible that a problem that required lots of disk I/O 15 years ago would fit in RAM today, maybe it would even fit in L3 cache. Under such circumstances it may be that an unmodified algorithm would run a million times faster on a modern computer compared to a computer from 15 years ago. Even if no part of the machine is a million times faster. In fact having enough RAM could mean close to a million times performance difference on hardware of exactly the same speed if the algorithm does lots of random access.
To show that an algorithm is optimal you need to do it within some computational model. Some models consider I/O, others don't. An algorithm which is efficient in both kinds of models tend to be complex and have a somewhat larger constant, but not by several orders of magnitude. For such problems it may have been that if we knew an optimal algorithm at that time, it was with the simple model.
You could define your way out of that problem, but the results may not be very useful anyway. For example you could say an algorithm would only be considered optimal if it was optimal on both kinds of hardware (such a definition would make some kind of sense, and it would be possible to implement such an algorithm). With that algorithm you could compare the performance of the two machines, but it would still only measure the hardware improvement on a specific problem, and the number you get out may not apply to any other problem.
When hardware gets faster it applies more or less uniformly to all algorithms you run on that hardware. When an algorithm is improved it applies to just one specific problem. For some problems we already knew close to optimal algorithms 15 years ago, in those cases there was no way algorithmic improvements could have achieved such a speedup. And in fact the article mentions just one specific problem where algorithmic improvements made it about 43.000 times faster on one specific input. In other words, this number is not nearly as general as the summary makes it sound. The are algorithms that were not speeded up nearly as much, and for any algorithms that were bad enough to begin with, there could have been an even larger speedup - without anybody making a fuss about it.
He said it was easily definable, not that it was easily computable. The length of the optimal coding would be the kolmogorov complexity. It is easy to define, but it is undecidable. Computing the length is equivalent to solving the halting problem.
Sometimes running xterm over X forwarding over ssh is the best way to work. It's a bit easier to get that working correctly than just plain ssh in those cases where one end of the connection uses ISO 8859-1 and the other end uses UTF-8.
It is possible to distribute the known hosts file in a secure way. But of course it is also possible to do it in an insecure way. Those organizations that care enough about security to implement a secure distribution of a known hosts file, shouldn't be forced to trust a key obtained via DNSSEC. A reasonable default would be to refuse to connect to a host for which you get different keys from /etc and from DNSSEC, and assume that keys in the users own known hosts file were obtained from DNSSEC in the first place and just ask the user for confirmation before updating it. Obviously it should be possible to change the configuration to make the policy whatever you want.
As it stands now, DNSSEC mainly protects those protocols that don't have their own protection built in. I think the majority of attacks you would protect against would be on http. I think it would be a while before https and ssh would see any benefit from DNSSEC.
If ssh used DNSSEC to update the known hosts file without asking the user for confirmation, it would be a significant drop in security. If ssh updated the known hosts file just because it had use DNSSEC to verify the correctness of the IP address it was connecting to, without having received any information about the new key, that would be plain stupid.
If ssh however could get the public key from DNSSEC and store it in the known hosts file the first time you connect and not yet have the key in your known hosts file, then it would improve security. (As with anything, if the improved security causes users to be less careful, then it may not make the system more secure after all.)
Nice, I didn't know about RFC 4255 before now. This is the kind of thing I had in mind, I didn't know it already existed.
I'd not trust it as an alternative to known hosts, but as a supplement it sounds like a good idea. The problem with the DNSSEC chain of trust is that you have to trust a lot more parties than you do with the known hosts file.
Anybody who could do that could probably pull off the same hijacking without spoofing a DNS record. Even if you have the correct IP of the server you want to talk to, they could hijack your traffic to that IP. It does give them one more point to attack, so it still means there is a reason to protect that part of the communication, however it isn't currently the weakest point.
Exactly. The immediate problem we are facing is the possibility to poison caching name servers shared by many users. An attacker sends requests and forged responses more or less simultaneously to a server, and with a bit of luck gets a forged record cached. If we can get such servers to verify DNSSEC signatures we may have fixed the weakest point that we currently have. As such it is only a small part of the infrastructure that actually needs to be updated before we start getting some benefit. Once that part is in place we can get a bit more benefit from deploying checking all the way to the clients.
The way ssh currently works, it doesn't make a huge difference if the DNS records are signed or not. Either you get a DNS record with an invalid signature, and you just never connect to any server, or you get an incorrect IP and connect after which ssh reports the server has a wrong host key. The attacker could also try to just hijack the TCP connection without giving you an incorrect IP address, in that case ssh would also report a wrong host key.
The real case for ssh using DNSSEC would actually be if host keys could be put in DNS as well. However it is unclear to me if that would be anymore secure or easier to maintain than a known hosts file.
In short, they are not supposed to. This is really a dirty hack to work around the lack of any standard way of setting up such a signup system. A slightly cleaner approach, that I don't know how well would work, would be as follows.
This is how most of them behaves because it is the most reliable way to work around the problems caused by the records being cached. Some such systems also redirect https, which obviously leads to browsers warning about incorrect certificates. This is very annoying if you had your laptop suspended with some open ajax applications. I wish browsers could be configured to just consider it an error, and not ask me every time it sees an invalid certificate.
The only reason it works with HTTP is that there is no end to end security. It only protects DNS, not the connection you create to the returned IP afterwards. That could of course be implemented using some additional DNS records with public keys. Such a system might actually turn out to be easier to deploy than https, so it could look like a threat to the current CAs.
I doubt that is the reason. They are basically allowing somebody to perform a man in the middle attack against the connections to their server. They may think these man in the middle attacks are only used for good purposes, but they have no control over that.
Browser and/or resolver may still cache the entry even if it has ttl 0. In fact some browsers do it deliberately for security reasons. There are some javascript based attacks that can be performed if you change an A record from pointing at a malicious server to point at a site where you want to perform some sort of attack. (Or maybe it was the other way around, sorry, I don't remember all the details). It is a quite broken security model, and arbitrarily caching lookups past expiry is a terrible workaround.
I went as far as creating a bookmark in my browser for that exact purpose. If I do get through to the server in question, it will redirect me to my own homepage.
Withdrawing a small amount of cash is fast and easy. Withdrawing a large amount is more involved. That may get delayed for long enough to notice the fraud.
Also, if you run with the money, they know who you are, and it will probably look like you were doing the fraud on your own. The people who manufactured the original forged cheque in this story would probably not stand up and say, hey that was our forged cheque and we want those stolen money.
It would have to either be a hell of a lot of money, or the life you were leaving behind would have to be pretty worthless, otherwise I'd say it wouldn't be worth it. How much does a new identity cost? (Does it come with a warranty against being blown?)
Do you think it is necessary to fine people who do not report what they find? Why wouldn't people just do it, if it was easy to do so?