Quick fix for an early Internet problem lives on a quarter-century later (2015)(washingtonpost.com)
washingtonpost.com
Quick fix for an early Internet problem lives on a quarter-century later (2015)
http://www.washingtonpost.com/sf/business/2015/05/31/net-of-insecurity-part-2/
14 comments
Related project: http://www.scion-architecture.net/
SCION is a BGP replacement that's in development at the ETH Zurich network security group; it promises isolation of routing hijack attacks (by means of so-called "isolation domains", planned to be grouped by jurisdiction AFAIK). It's even already deployed in a bunch of places (edit: https://www.scion-architecture.net/#deployment).
It also has cool extensions like SIBRA, which provides DDoS protection by means of bandwith reservation, and HORNET (which you might've heard of before), which is a high-speed anonymous communication network (which is sadly not yet available to the public in implemented/working form).
Previous HN discussion on HORNET: https://news.ycombinator.com/item?id=9930929
SCION is a BGP replacement that's in development at the ETH Zurich network security group; it promises isolation of routing hijack attacks (by means of so-called "isolation domains", planned to be grouped by jurisdiction AFAIK). It's even already deployed in a bunch of places (edit: https://www.scion-architecture.net/#deployment).
It also has cool extensions like SIBRA, which provides DDoS protection by means of bandwith reservation, and HORNET (which you might've heard of before), which is a high-speed anonymous communication network (which is sadly not yet available to the public in implemented/working form).
Previous HN discussion on HORNET: https://news.ycombinator.com/item?id=9930929
> BGP won out because it was simple, solved the problem at hand and proved versatile enough to keep data flowing as the Internet doubled in size, again and again and again.
So if you want to replace it, make something that is equally simple and solves the new problem(s) at hand without un-solving the original one. If you don't do that, people have no incentive to switch.
It sounds like the (vaguely described) new alternative is more complex. If it was better for business, things would have gravitated toward it quickly.
So if you want to replace it, make something that is equally simple and solves the new problem(s) at hand without un-solving the original one. If you don't do that, people have no incentive to switch.
It sounds like the (vaguely described) new alternative is more complex. If it was better for business, things would have gravitated toward it quickly.
It's unreasonable to demand that a new solution be "equally simple". History is full of simple solutions that aren't good enough that get replaced with more comprehensive yet complicated solutions. HTTPS isn't as simple as HTTP, C++ isn't as simple as C, democracy isn't as simple as monarchy, the courts aren't as simple as mob justice.
> HTTPS isn't as simple as HTTP, C++ isn't as simple as C, democracy isn't as simple as monarchy
Right, none of those have led to obsolescence even with long periods of time to grow.
Instead, think of replacements that have caused something to basically just disappear.
I'm not convinced this is the best example, but I think it helps get my point across. This is from a user's perspective, not a manufacturer's. Maybe someone can share better examples from software if these aren't appropriate.
When a new type of cable connector enters the market, it has to be at least as simple as the old one or do something more than the old one did. Serial or parallel plugs have screws to help hold the cable in place, newer plug types like FireWire or USB don't need the screws, so they are simpler. Now we are seeing new types of plugs that work "upside down" so they are even simpler for consumers to use.
I guess a better example might be media distribution. From a user's perspective, the compact cassette was just as simple to use as the 8-track. Or BluRay replacing DVD replacing CD.
Would high speed internet be as popular if it required a time consuming arcane ritual to establish a connection, compared to the simple bleep bloop of a dial-up modem?
So if you want the users of BGP (network operators) to switch to something better, make it just as simple for them to use, while providing additional benefits. Yeah it isn't easy, but it's certainly been done in other arenas.
Right, none of those have led to obsolescence even with long periods of time to grow.
Instead, think of replacements that have caused something to basically just disappear.
I'm not convinced this is the best example, but I think it helps get my point across. This is from a user's perspective, not a manufacturer's. Maybe someone can share better examples from software if these aren't appropriate.
When a new type of cable connector enters the market, it has to be at least as simple as the old one or do something more than the old one did. Serial or parallel plugs have screws to help hold the cable in place, newer plug types like FireWire or USB don't need the screws, so they are simpler. Now we are seeing new types of plugs that work "upside down" so they are even simpler for consumers to use.
I guess a better example might be media distribution. From a user's perspective, the compact cassette was just as simple to use as the 8-track. Or BluRay replacing DVD replacing CD.
Would high speed internet be as popular if it required a time consuming arcane ritual to establish a connection, compared to the simple bleep bloop of a dial-up modem?
So if you want the users of BGP (network operators) to switch to something better, make it just as simple for them to use, while providing additional benefits. Yeah it isn't easy, but it's certainly been done in other arenas.
> Instead, think of replacements that have caused something to basically just disappear.
Okay, SSH and Telnet. SSH is not as simple to use as Telnet. Windows users have to download a client, even in 2016. Server key changes cause warnings. People are often using encrypted key pairs instead of password authentication.
These (network admins who care about BGP) are sophisticated users. A secure version of BGP is not going to be as simple for them to use. It's just not happening that way, that's the way it always goes with security. More security makes the product more difficult to use, and a secure version of BGP is going to be more difficult to use.
Yes, you can find examples of simpler products that have replaced more complicated products, but that's rather poor support for the idea that replacements must be simpler or they won't be accepted. We're replacing magnetic strips with chip & pin for our credit cards, which are more complicated for everyone. Unencrypted HTTP may never completely die out, but HTTPS is everywhere and is only getting more common.
Or if you want simpler examples, think of the smart phone replacing the flip phone (less battery life, more complicated, more expensive) or the MP3 player replacing the cassette player (more expensive, more complicated, you have to get a computer and rip your CDs or buy digital music online). Or think of locks replacing simple latches on doors, now you need to carry a house key with you.
Or if you want examples more similar to BGP, think about spanning tree protocol. It's simple and it gets the job done. It's also completely dead in the modern data center, replaced by things like the far more sophisticated software defined networking. BGP is headed for the same fate.
Okay, SSH and Telnet. SSH is not as simple to use as Telnet. Windows users have to download a client, even in 2016. Server key changes cause warnings. People are often using encrypted key pairs instead of password authentication.
These (network admins who care about BGP) are sophisticated users. A secure version of BGP is not going to be as simple for them to use. It's just not happening that way, that's the way it always goes with security. More security makes the product more difficult to use, and a secure version of BGP is going to be more difficult to use.
Yes, you can find examples of simpler products that have replaced more complicated products, but that's rather poor support for the idea that replacements must be simpler or they won't be accepted. We're replacing magnetic strips with chip & pin for our credit cards, which are more complicated for everyone. Unencrypted HTTP may never completely die out, but HTTPS is everywhere and is only getting more common.
Or if you want simpler examples, think of the smart phone replacing the flip phone (less battery life, more complicated, more expensive) or the MP3 player replacing the cassette player (more expensive, more complicated, you have to get a computer and rip your CDs or buy digital music online). Or think of locks replacing simple latches on doors, now you need to carry a house key with you.
Or if you want examples more similar to BGP, think about spanning tree protocol. It's simple and it gets the job done. It's also completely dead in the modern data center, replaced by things like the far more sophisticated software defined networking. BGP is headed for the same fate.
I think that from an end users point of view SSH is as simple as telnet.
Sure there are ways to use ssh keys and so on, but the base operation is as simple, ssh machine instead of telnet machine.
Regarding need to download ssh, the same has been true about telnet since (at least) windows 7. (Telnet is NOT included by default in windows 7)
Warnings about server key change, is something i feel happens very rarely with a workaround described in the error message. I feel this is a very minor issue
The other ssh added complexity is optional stuff. and is something i feel made ssh better than telnet, example: You can forward X11 connection between unix machine using ssh.(Sure you use telnet and xhost/ DISPLAY et.c )
SSH-keys are also a optional feature, that are not forced on the user, but can simplify remote login.
Sure there are more complexity inside ssh and the protocol, but the simplest use of ssh is about as simple as telnet.
Regarding need to download ssh, the same has been true about telnet since (at least) windows 7. (Telnet is NOT included by default in windows 7)
Warnings about server key change, is something i feel happens very rarely with a workaround described in the error message. I feel this is a very minor issue
The other ssh added complexity is optional stuff. and is something i feel made ssh better than telnet, example: You can forward X11 connection between unix machine using ssh.(Sure you use telnet and xhost/ DISPLAY et.c )
SSH-keys are also a optional feature, that are not forced on the user, but can simplify remote login.
Sure there are more complexity inside ssh and the protocol, but the simplest use of ssh is about as simple as telnet.
Yeah, I'm not buying it. I'm an end-user of SSH and I've experienced WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED or all sorts of bizarre problems with authentication just failing for reasons that took me hours to diagnose. That, and configuring servers to reject password authentication, converting private keys between the different formats expected by different clients, the unhelpful errors like "Permission denied (publickey)." which actually means "you typed your password in wrong" but Telnet will actually tell you that your password is wrong. How many users have discovered that after upgrading SSH that their known_hosts file is now hashed?
The protocol itself is a total mess. Having implemented servers for the Telnet protocol, I can say that Telnet is a little bit of a mess, but SSH is a total nightmare by comparison.
You're right though, that if you look at a very tiny slice of SSH then it almost looks like SSH is simpler than Telnet, once you've gone through the work of generating a key pair, securing the private key, and installing the public key on your server.
The protocol itself is a total mess. Having implemented servers for the Telnet protocol, I can say that Telnet is a little bit of a mess, but SSH is a total nightmare by comparison.
You're right though, that if you look at a very tiny slice of SSH then it almost looks like SSH is simpler than Telnet, once you've gone through the work of generating a key pair, securing the private key, and installing the public key on your server.
And if you're going to cherry pick tiny slices, I'd rather pick the slice:
"SSH lets me communicate with a server securely, more simply than via Telnet."
By the same vein, HTTPS is "simpler" than HTTP in this regard.
Ditto for many possible BGP replacements.
"SSH lets me communicate with a server securely, more simply than via Telnet."
By the same vein, HTTPS is "simpler" than HTTP in this regard.
Ditto for many possible BGP replacements.
That seems like wordplay, to me. Does a car make it "simpler" to travel 60 miles an hour down the freeway, compared to walking?
SSH is more complex and more secure than Telnet.
SSH is more complex and more secure than Telnet.
Being "simple" is the privilege of those things riding the first big wave.
Simplicity decays exponentially after that.
Simplicity decays exponentially after that.
Good point. Instead of decay, I frame it up as complexity gradually increasing as tool is expanded in capabilities and environment it operates. The modern setup of those old, "simple" protocols is anything but simple. It's a huge mess of messes.
The solutions that replace such messes are often complicated themselves due to the operating environment and existing interfaces if nothing else. This doesn't even get into the politics of replacing someone in the Internet backbone. :)
The solutions that replace such messes are often complicated themselves due to the operating environment and existing interfaces if nothing else. This doesn't even get into the politics of replacing someone in the Internet backbone. :)
Similarly, UTF-8 was designed on a diner placemat.
https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt
https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt
UTF-8 was also designed under rather severe restrictions: you want to keep binary compatibility with 7-bit ASCII, i.e. 128 out of 256 possible byte values are taken and you want to encode the entirety of Unicode including any future additions. This means you need variable-length encoding. You also want to detect if the stream is well-formed and you want to detect if you're starting decoding in the middle of a character. UTF-8 is one of very few possible solutions that cover all requirements.
BGP had a lot more to work with since you're designing an entire protocol that doesn't need any backwards compatibility with anything else.
BGP had a lot more to work with since you're designing an entire protocol that doesn't need any backwards compatibility with anything else.
> You also want to detect if the stream is well-formed and you want to detect if you're starting decoding in the middle of a character
These are positive characteristics of the UTF-8 design, but weren't necessary pre-requisites. Other encodings don't have the same redundancy (for integrity check) or freedom from boundary ambiguity.
These are positive characteristics of the UTF-8 design, but weren't necessary pre-requisites. Other encodings don't have the same redundancy (for integrity check) or freedom from boundary ambiguity.
I've also always enjoyed that El Torito[0] was named after the Mexican restaurant where it was designed:
"Stevens and Merkin went out to lunch at the El Torito Grill. Stan Merkin had calamari fajitas and Curtis Stevens had steak fajitas, both with fresh tortillas. They wrote the basics of the specification on a napkin. The rest, as they say, is history."[1]
[0] https://en.wikipedia.org/wiki/El_Torito_(CD-ROM_standard)
[1] https://web.archive.org/web/19991008045553/http://www.cdpage...
"Stevens and Merkin went out to lunch at the El Torito Grill. Stan Merkin had calamari fajitas and Curtis Stevens had steak fajitas, both with fresh tortillas. They wrote the basics of the specification on a napkin. The rest, as they say, is history."[1]
[0] https://en.wikipedia.org/wiki/El_Torito_(CD-ROM_standard)
[1] https://web.archive.org/web/19991008045553/http://www.cdpage...
There's a motto in my department at work: Nothing is more permanent than a temporary solution.
Yes, I learned this pretty early in my career, from a (technically literate) client.
"I've added a temporary solution for X" "These temporary solutions are usually permanent"
Sure enough. The temporary workaround was eventually deployed.
There's another one that I've learned, loosely translated to English it would be "The Symmetrical Workaround Theory". It states that workarounds usually come in pairs. If you fail to figure out where the other half of the workaround goes, a bug will take its place.
"I've added a temporary solution for X" "These temporary solutions are usually permanent"
Sure enough. The temporary workaround was eventually deployed.
There's another one that I've learned, loosely translated to English it would be "The Symmetrical Workaround Theory". It states that workarounds usually come in pairs. If you fail to figure out where the other half of the workaround goes, a bug will take its place.
I've heard a similar quote:
"Broken code gets fixed, but shitty code lasts forever."
"Broken code gets fixed, but shitty code lasts forever."
"Temporary is permanent."
"Test is production."
These two mantras have saved me and coworkers from making stupid "temporary" fixes countless times through the years.
"Test is production."
These two mantras have saved me and coworkers from making stupid "temporary" fixes countless times through the years.
from 2015, discussion here back then: https://news.ycombinator.com/item?id=9636141
A related, interesting read: https://security.stackexchange.com/q/56069/15648-what-securi...
[deleted]
BGP at 18 from the guy himself:
https://m.youtube.com/watch?v=_Mn4kKVBdaM
https://m.youtube.com/watch?v=_Mn4kKVBdaM
I get the feeling that the core Internet protocols (in the 80s and early 90s) were built by people who were like 75% sysadmins and 25% developers/system architects. Typically sysadmins employed by US universities. (I don't want to cast any shade on their accomplishments! They made brilliant things for the time.)
Then things got stuck because the Internet started hyper-scaling in the mid 90s.
This is just an outside observation though; it would obviously be great to hear any insider perspectives from people who were there.
Then things got stuck because the Internet started hyper-scaling in the mid 90s.
This is just an outside observation though; it would obviously be great to hear any insider perspectives from people who were there.
It sounds like you're suggesting that a lot of system admin/developer types that were left in a room without adult supervision and, oops, the Internet!
The truth was that there was no lack of experienced architect/developer types at the time working on networking standards. The OSI model, for example, traces its roots back to 1977! The struggle was that the "adults in the room" were typically were older and held senior positions in large corporations and government agencies. The standards that they created were typically developed through a consensus protocol and by committee where the single biggest aim was to make sure that no company would gain or lose a competitive advantage based on the standard.
These standards were always pitched as being just over the horizon and, if anything, did a lot of early damage by delaying rollout of simpler protocols. I personally won't ever get back the hours that I spent studying protocols that were never relevant and never would be.
The truth was that there was no lack of experienced architect/developer types at the time working on networking standards. The OSI model, for example, traces its roots back to 1977! The struggle was that the "adults in the room" were typically were older and held senior positions in large corporations and government agencies. The standards that they created were typically developed through a consensus protocol and by committee where the single biggest aim was to make sure that no company would gain or lose a competitive advantage based on the standard.
These standards were always pitched as being just over the horizon and, if anything, did a lot of early damage by delaying rollout of simpler protocols. I personally won't ever get back the hours that I spent studying protocols that were never relevant and never would be.
Thank you for sharing!
That divide did not exist at the time. Intimate knowledge of the systems involved was a requirement to do either task. It wasn't until later that people were able to choose the set of abstractions that enabled them to focus on a task the the point that other considerations could be missed. People wrote entire bespoke operating systems to serve as early arpanet nodes. The arrival of unix was bemoaned by many because it removed this requirement for mastery -- this gave rise to the era of copy-and-paste systems administration and works-on-my-machine development.
We're still digging our way out of that hole, by implementing more layers of abstraction. Hence the current popularity of cloud computing: the ultimate copy-and-paste deployment, combined with works-on-my-machine development, where all machines can now be 'my machine'.
We're still digging our way out of that hole, by implementing more layers of abstraction. Hence the current popularity of cloud computing: the ultimate copy-and-paste deployment, combined with works-on-my-machine development, where all machines can now be 'my machine'.
You were around in the 80s Internet scene?
Some of us are a lot older than than you might think :)
You seem to have misinterpreted my simple question as statement of disbelief? Why would you do that, since I explicitly asked for statements of people who where around at the time? confused
(Perhaps I misread you - in that case: thanks to the grand-parent comment for sharing :) ).
(Perhaps I misread you - in that case: thanks to the grand-parent comment for sharing :) ).
I don't want to cast any shade on their accomplishments!
Yeah, considering the gigantic backhanded compliment that follows, you do. You're just saying "sorry not sorry."
Yeah, considering the gigantic backhanded compliment that follows, you do. You're just saying "sorry not sorry."
I beg to disagree. I do think that what was designed back then (TCP, DNS, etc) was elegant. It was a great foundation.. but because they were so elegant and good-enough, and because of the Internet hyperscaling in the 90s and onwards, there was never an opportunity to improve on it.
Forgetting that security wasn't designed into it the fact that it was an honor system (email as well) was just plain naive on the part of the academics.
Or it was a compromise that wasn't worth it.
We could make cars with bullet-proof glass that would make them extremely difficult to break into, but to most people, the cost is not worth the benefit, so it's not done.
Given the state of encryption technology in the 80s, it's possible that any attempts to secure the protocol would have been rendered pointless by technological advances. Or, it would be more brittle than a non-secure competitor and would have fallen out of use.
We could make cars with bullet-proof glass that would make them extremely difficult to break into, but to most people, the cost is not worth the benefit, so it's not done.
Given the state of encryption technology in the 80s, it's possible that any attempts to secure the protocol would have been rendered pointless by technological advances. Or, it would be more brittle than a non-secure competitor and would have fallen out of use.
Why isn't the sensitive data sent encrypted?
The issue is not that a third party can read contents, it is that a participant in the protocol (which could encrypt/decrypt) can do malicious things, so encryption wouldn't do anything.
Newer proposals include signatures and other steps to solve this, but as the article discusses uptake is slow and it makes operations more complicated. The weakness of BGP against hijacking also means that it's quite simple and very flexible, which operators like.
Newer proposals include signatures and other steps to solve this, but as the article discusses uptake is slow and it makes operations more complicated. The weakness of BGP against hijacking also means that it's quite simple and very flexible, which operators like.
So, why would the US military care if sensitive data is being routed through Beijing?
(I misunderstood your question and thought you referred to BGP protocol data, which is why I mostly answered about BGP, but...)
The attacker could have just thrown the data away, totally interrupting all these communications. Even if encrypted, traffic patterns could be interesting and harder to obtain otherwise.
The attacker could have just thrown the data away, totally interrupting all these communications. Even if encrypted, traffic patterns could be interesting and harder to obtain otherwise.
IPv6?
Mutually mistrustful routing is hard. I wrote some stuff on this in the early 1980s. The best I came up with was a scheme where forgeries would be detected, and once the source of the forgeries had been kicked off the network, the system would heal itself. (Asymmetric cryptographic signing had been invented but wasn't yet used or trusted.)