How is this a fix again? How is security the issue here? It's not like someone snuck onto the internets and did something malicious, a provider with BGP peering agreements sent out bad routes that their peers didn't filter.
The problem is not something that additionally encrypting/signing messages will fix, it's a problem of network operators blindly trusting routes from their providers and passing them along.
The only fix here is for operators to properly filter routes from people they peer with. Period.
Things to avoid tend to be better indicators than things to go for. I'd avoid:
* Companies that aren't open about issues. If there isn't a public forum, status RSS feed, status twitter account, etc. BAD NEWS * Companies that offer unlimited anything. By definition, unlimited means that they are overselling and while things may be great now, they'll suffer in the long run * Linux hosts that don't give you SSH access. CPanel/Fantastico/Whatever do plenty of things, but there is no substitute for having shell access * Anything at all that makes you feel funny. There are _plenty_ of options out there and if something doesn't feel right, you're better off going somewhere else. * Companies that won't respond to you personally for pre-sales questions. When I was looking for colo space, this turned out to be the most important factor. The better they communicate with you before they have any of your money, the better off things will be in the long run. * Anything that seems to be too good to be true. i.e. If you have a need for a lot of disk/bandwidth/cpu, and "unlimited" is $5/month, BAD NEWS
I run ithought dot org and host a reasonable number of sites, and try to adhere to all of the above. One thing you won't be able to find out easily with hosts is something I do: I won't accept customers that seem like they aren't a fit for the hardware I have. Shared hosting is what it is and if a customer is going to drive up the load on servers such that it affects other customers, but doesn't want to pay for dedicated hardware or a VM, their actions shouldn't hurt other shared hosting customers that are only using a very small amount of resources.
Most of the cloud stuff is plenty nice if you want to manage it (S3, SliceHost, etc) but don't underestimate what is involved with keeping server OSs up to date, tuned, and monitored. If you're core competency isn't tweaking server software you should let someone else worry about that for you until it makes sense for you to hire an Operations person/team.
I do have a job and I have used OpenVZ in a production environment:) Scrapped 2 machines running VMware ESX, put OpenVZ on them, and we can handle over 3x the number of Virtual Machines ("containers" in OpenVZ land) on the same hardware without paying the cost of VMware licenses. Highly recommended.
Same Provider at both (N) locations, Same IPs for servers/services, Just don't advertise the prefixes via BGP from the backup location until the primary one goes down.
So who is going to pay for this alternative? Some of the costs include:
-land right of way (railroad companies became telco companies and have right of way between major cites which lets them bury the fiber where they want) (ever priced buying rights to a 10 foot wide strip of land from Atlanta to Dallas?)
-burying the fiber
-routers that go at these speeds (Ever priced a router that will do a few 10GbE interfaces at wire speed?)
-power/cooling/squarefeet/etc in datacenters
-people do do and manage all of this
This also brings us to:
-Isn't whoever does all of this going to want to make money off of it?
-Won't multiple providers running links over multiple paths mean higher costs for everyone due to the infrastructure costs involved?
RTFA. They didn't create a client that is "selfish" by trying to avoid uploading. They created a client that is selfish by first allocating more upload capacity to other clients that will send them more when they upload more, and only allocate the remaining upload capacity to clients where benefits from increased uploading are not certain. If you read their paper, they regularly bring up the effects of this on the entire network and they don't know if it's good, bad, or has any effect on the network (and not for a lack of trying)
Performance is definitely going to be an issue. Switches and Routers are _much_ different than ethernet cards in a box. If you wanted to do non-blocking wire speed transfers through your 40 port router, your PCI bus would need to be able to handle a _lot_ of traffic. Not only would it need to be atleast 40x the speed of your interfaces to prevent queuing delays on ports, but it would need to be twice again as fast because all the data would have to go nic->cpu->nic (real switches do most processing on the line cards that the interfaces are on "fast path", only thing that require extra processing like source routed packets need to take the "slow path" and hit the CPU)
Perhaps if you explained more about the goals of your project, someone might be able to give feedback on a better way to do things?
Slashdot Mirror
Accepting a bad route from a peer and accepting a cryptographically signed bad route from a peer are the same thing.
How is this a fix again? How is security the issue here? It's not like someone snuck onto the internets and did something malicious, a provider with BGP peering agreements sent out bad routes that their peers didn't filter.
The problem is not something that additionally encrypting/signing messages will fix, it's a problem of network operators blindly trusting routes from their providers and passing them along.
The only fix here is for operators to properly filter routes from people they peer with. Period.
Great, just what we need. More corn subsidies.
I don't know the last time I looked at everything in stdio.h for problems so it's tough to say...
Things to avoid tend to be better indicators than things to go for. I'd avoid:
* Companies that aren't open about issues. If there isn't a public forum, status RSS feed, status twitter account, etc. BAD NEWS
* Companies that offer unlimited anything. By definition, unlimited means that they are overselling and while things may be great now, they'll suffer in the long run
* Linux hosts that don't give you SSH access. CPanel/Fantastico/Whatever do plenty of things, but there is no substitute for having shell access
* Anything at all that makes you feel funny. There are _plenty_ of options out there and if something doesn't feel right, you're better off going somewhere else.
* Companies that won't respond to you personally for pre-sales questions. When I was looking for colo space, this turned out to be the most important factor. The better they communicate with you before they have any of your money, the better off things will be in the long run.
* Anything that seems to be too good to be true. i.e. If you have a need for a lot of disk/bandwidth/cpu, and "unlimited" is $5/month, BAD NEWS
I run ithought dot org and host a reasonable number of sites, and try to adhere to all of the above. One thing you won't be able to find out easily with hosts is something I do: I won't accept customers that seem like they aren't a fit for the hardware I have. Shared hosting is what it is and if a customer is going to drive up the load on servers such that it affects other customers, but doesn't want to pay for dedicated hardware or a VM, their actions shouldn't hurt other shared hosting customers that are only using a very small amount of resources.
Most of the cloud stuff is plenty nice if you want to manage it (S3, SliceHost, etc) but don't underestimate what is involved with keeping server OSs up to date, tuned, and monitored. If you're core competency isn't tweaking server software you should let someone else worry about that for you until it makes sense for you to hire an Operations person/team.
I do have a job and I have used OpenVZ in a production environment :) Scrapped 2 machines running VMware ESX, put OpenVZ on them, and we can handle over 3x the number of Virtual Machines ("containers" in OpenVZ land) on the same hardware without paying the cost of VMware licenses. Highly recommended.
A +1 to ZenOSS from me. Quality product and commercial support is great.
Bunches of Linux servers (200+) running CentoOS, RHEL, CentOS, Gentoo, and a few others, all with recent versions of NTP, and all said something like:
Dec 31 18:59:59 aurora Clock: inserting leap second 23:59:60 UTC
when GMT rolled over.
Same Provider at both (N) locations, Same IPs for servers/services, Just don't advertise the prefixes via BGP from the backup location until the primary one goes down.
So who is going to pay for this alternative? Some of the costs include: -land right of way (railroad companies became telco companies and have right of way between major cites which lets them bury the fiber where they want) (ever priced buying rights to a 10 foot wide strip of land from Atlanta to Dallas?) -burying the fiber -routers that go at these speeds (Ever priced a router that will do a few 10GbE interfaces at wire speed?) -power/cooling/squarefeet/etc in datacenters -people do do and manage all of this This also brings us to: -Isn't whoever does all of this going to want to make money off of it? -Won't multiple providers running links over multiple paths mean higher costs for everyone due to the infrastructure costs involved?
RTFA. They didn't create a client that is "selfish" by trying to avoid uploading. They created a client that is selfish by first allocating more upload capacity to other clients that will send them more when they upload more, and only allocate the remaining upload capacity to clients where benefits from increased uploading are not certain. If you read their paper, they regularly bring up the effects of this on the entire network and they don't know if it's good, bad, or has any effect on the network (and not for a lack of trying)
Performance is definitely going to be an issue. Switches and Routers are _much_ different than ethernet cards in a box. If you wanted to do non-blocking wire speed transfers through your 40 port router, your PCI bus would need to be able to handle a _lot_ of traffic. Not only would it need to be atleast 40x the speed of your interfaces to prevent queuing delays on ports, but it would need to be twice again as fast because all the data would have to go nic->cpu->nic (real switches do most processing on the line cards that the interfaces are on "fast path", only thing that require extra processing like source routed packets need to take the "slow path" and hit the CPU) Perhaps if you explained more about the goals of your project, someone might be able to give feedback on a better way to do things?