
Quick fix for an early Internet problem lives on a quarter-century later (2015) - uncle_stupid
http://www.washingtonpost.com/sf/business/2015/05/31/net-of-insecurity-part-2/
======
Animats
BGP was intended for a specific niche. Earlier, there was the ARPANET,
operated by BBN out of Boston, and peripheral stuff connected to it. Early
Internet thinking was that there was a "core" with its own routing protocol,
and BGP was how the core communicated with small peripheral networks. BGP
wasn't intended as the core routing protocol.

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.)

------
cryptarch
Related project: [http://www.scion-architecture.net/](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](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](https://news.ycombinator.com/item?id=9930929)

------
no_protocol
> 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.

~~~
klodolph
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.

~~~
no_protocol
> 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.

~~~
klodolph
> 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.

~~~
sagonar
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.

~~~
klodolph
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.

~~~
MaulingMonkey
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.

~~~
klodolph
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.

------
dmit
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)

~~~
Asooka
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.

~~~
barrkel
> 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.

------
analogwzrd
There's a motto in my department at work: Nothing is more permanent than a
temporary solution.

~~~
outworlder
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.

------
vocatus_gate
"Temporary is permanent."

"Test is production."

These two mantras have saved me and coworkers from making stupid "temporary"
fixes countless times through the years.

------
detaro
from 2015, discussion here back then:
[https://news.ycombinator.com/item?id=9636141](https://news.ycombinator.com/item?id=9636141)

------
d33
A related, interesting read:
[https://security.stackexchange.com/q/56069/15648-what-
securi...](https://security.stackexchange.com/q/56069/15648-what-security-
mechanisms-are-used-in-bgp-and-why-do-they-fail)

------
TranceMan
BGP at 18 from the guy himself:

[https://m.youtube.com/watch?v=_Mn4kKVBdaM](https://m.youtube.com/watch?v=_Mn4kKVBdaM)

------
johansch
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.

~~~
slv77
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.

~~~
johansch
Thank you for sharing!

------
witty_username
Why isn't the sensitive data sent encrypted?

~~~
detaro
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.

~~~
witty_username
So, why would the US military care if sensitive data is being routed through
Beijing?

~~~
detaro
(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.

------
swehner
IPv6?

