[Came up in some digest summary I receive]
Using Cloud Resources to Dramatically Improve Internet Routing
UMass Amherst researchers to use cloud-based ‘logically centralized
control’
https://www.umass.edu/newsoffice/article/using-cloud-resources-dramatically-improve
-Phil
a message of 9 lines which said:
Using Cloud Resources to Dramatically Improve Internet Routing
UMass Amherst researchers to use cloud-based ‘logically centralized
control’
Executive summary: it's SDN for BGP. Centralizing Internet routing,
what could go wrong? (As the authors say, "One reason is there is no
single entity that has a big picture of what is going on, no
manager". I wonder who will be Internet's manager.)
Otherwise, an impressive amount of WTF. My favorite: "while
communication by servers ___on the ground___ might take hundreds of
milliseconds, in the cloud the same operation may take only one
millisecond from one machine to another" I thought that universities
were full of serious people, but university of Massachusets may be an
exception?
My favorite: "The researchers expect their cloud-based system will be more
secure than the Internet is today [...]" Apparently they're blissfully
unaware that there is no such thing as "cloud security".
---rsk
He adds that while communication by servers on the ground might take hundreds of milliseconds, in the cloud the same operation may take only one millisecond from one machine to another. Its orders of magnitude faster, and in the cloud we can easily afford more bandwidth resources, too. The photons have less distance to travel in the cloud than on the ground. All these factors make outsourcing the decision-making to the cloud more advantageous. The researchers say this new approach of enabling interdomain routing as a service is a radically different approach compared to todays practice.
I think this would work if you re-route the plasma conduits on deck 23 to the output of the main deflector dish.
Centralized Internet routing - sounds like DoH for BGP.
What could possibly go wrong?!
-Hank
Otherwise, an impressive amount of WTF. My favorite: "while
communication by servers ___on the ground___ might take hundreds of
milliseconds, in the cloud the same operation may take only one
millisecond from one machine to another"
My favorite: "The researchers expect their cloud-based system will be
more secure than the Internet is today [...]" Apparently they're
blissfully
unaware that there is no such thing as "cloud security".
I would be interested to know how one connects to their "cloud"? Do I
need an "Evaporation Adapter" for my computer to send to their cloud?
And do I need a "Rain Collector" to receive from it? I suppose I also
need the computer to be outside exposed to the elements -- putting it
under a brolly would interfere with incoming rain from the cloud ...
Plus I suppose it would not work very well at all in the desert, but
downloading would be very high bandwidth in the rainforest (or during
monsoon season).
See RFC 1149 & 2549
Feel that this is more down the line of RFC 7511, no?
—Dennis
I haven't found the actual work that is being referenced here, and I
*am* quite skeptical based upon the title / premise -- but, I suspect
(well, hope) that this is just another instance of complex technical
material being munged by marketing / reporters into something
unrecognizable -- note that "This article was originally published by
the UMass News Office."
Here is an abstract of one of Yang Song, Arun Venkataramani, Lixin
Gao's earlier papers:
"BGP is known to have many security vulnerabilities due to the very
nature of its underlying assumptions of trust among independently
operated networks. Most prior efforts have focused on attacks that can
be addressed using traditional cryptographic techniques to ensure
authentication or integrity, e.g., BGPSec and related works. Although
augmenting BGP with authentication and integrity mechanisms is
critical, they are, by design, far from sufficient to prevent attacks
based on manipulating the complex BGP protocol itself. In this paper,
we identify two serious attacks on two of the most fundamental goals
of BGP-to ensure reachability and to enable ASes to pick routes
available to them according to their routing policies-even in the
presence of BGPSec-like mechanisms. Our key contributions are to (1)
formalize a series of critical security properties, (2) experimentally
validate using commodity router implementations that BGP fails to
achieve those properties, (3) quantify the extent of these
vulnerabilities in the Internet's AS topology, and (4) propose simple
modifications to provably ensure that those properties are satisfied"
I'm assuming that it this were passed through many company /
university news / marketing orgs it would be translated into:
"The core protocol that makes all of the Internet, all e-commerce,
Internet banking and e-coin torrenting malware protection is
vulnerable to hackers stealing your identity. All existing efforts
have failed, because quantum computers can break cryptography. Our
researchers have identified simple attacks which bypass all Internet
security mechanisms and firewalls, and have demonstrated these
vulnerabilities in the wild. In order to protect Internet banking and
blockchain, and to ensure free elections, they have also developed a
simple and effective new system keep everyone secure. Contact us at
licensing@university.org to learn how to license this critical
technology. Click <here> to enroll in University, where you too can
learn to fix the Interwebs and earn lots of money."
W
I'm fighting *really* hard to try to avoid collapsing that abstract down to
"We realized that malicious actors can force the occurrence of BGP wedgies".
(I've seen far too many proposals in the last 48 hours from people who obviously
never encountered section (4) of RFC1925...)
What I find to be the worst part is in the first phrase : "... have received a three-year, $1.2 million grant to develop and test ..."
That makes 200k$/year/person. I find it quite a lot for bu**sh*t-bingo content.
Hank Nussbacher <hank@efes.iucc.ac.il> writes:
Executive summary: it's SDN for BGP. Centralizing Internet routing,
what could go wrong? (As the authors say, "One reason is there is no
single entity that has a big picture of what is going on, no
manager". I wonder who will be Internet's manager.)Otherwise, an impressive amount of WTF. My favorite: "while
communication by servers ___on the ground___ might take hundreds of
milliseconds, in the cloud the same operation may take only one
millisecond from one machine to another" I thought that universities
were full of serious people, but university of Massachusets may be an
exception?
What I find to be the worst part is in the first phrase : "... have received a three-year, $1.2 million grant to develop and test ..."
That makes 200k$/year/person. I find it quite a lot for bu**sh*t-bingo content.
[KT]
Maybe someone should ask the NSF how they are spending their money...
Some things I "like" :
"Shifting interdomain traffic control to the cloud to avoid routers on the ground and “heavy duty switching,” Gao says, "
"The traffic still has to go through the routers on the ground, "
So we don't need routers on the ground, but the routers "on the ground" have still to forward the traffic?
"He adds that while communication by servers on the ground might take hundreds of milliseconds, in the cloud the same operation may take only one millisecond from one machine to another."
Yeah sure, but how they are providing that information to the routers forwarding the data? They are not in the cloud? Or are they? (First citation)
"“It’s orders of magnitude faster, and in the cloud we can easily afford more bandwidth resources, too."
Still not sure what the are trying to tell me...
Is everything forwarded through the cloud, or not?
As in other sentences they are only writing about decision-making...
"All these factors make outsourcing the decision-making to the cloud more advantageous.”
So why we need that high bandwidth in the cloud, if it is only control-plane traffic?
IMO BGP over TLS actually makes a bunch of sense, and can be done using
TLS-PSK to avoid certificates for those who want that.
I wrote a rough idea of what it would need:
https://laptop006.livejournal.com/60532.html
Julien Goodwin <jgoodwin@studio442.com.au> writes:
Hank Nussbacher <hank@efes.iucc.ac.il> writes:
a message of 9 lines which said:
Using Cloud Resources to Dramatically Improve Internet Routing
UMass Amherst researchers to use cloud-based ‘logically centralized
control’Executive summary: it's SDN for BGP. Centralizing Internet routing,
what could go wrong? (As the authors say, "One reason is there is no
single entity that has a big picture of what is going on, no
manager". I wonder who will be Internet's manager.)Centralized Internet routing - sounds like DoH for BGP.
Great idea! Why don't we just run BGP over HTTPS? Everyone already has
a browser, so we can get rid of all these expensive routers.IMO BGP over TLS actually makes a bunch of sense,
Absolutely. And so does DNS over TLS. A lot of sense.
But if you start encoding the BGP protocol data in the TLS session as
HTTP so you can tunnel it over a shared 443 port to some distant
endpoint, and even traverse HTTP proxies, then it would look like a
joke.
Or in the DoH case, would make you wish it was a joke.
Bjørn
And that is just one letter short of the BOFH ...
isn't julien's idea more akin to DOT then DOH ?
Christopher Morrow <morrowc.lists@gmail.com> writes:
isn't julien's idea more akin to DOT then DOH ?
Yes, and I really like Julien's proposal. It even looks pretty
complete. There are just a few details missing around how to make the
MD5 => TLS transition smooth.
Sorry for any confusion caused by an attempt to make a joke on DoH. I
didn't anticipate the sudden turn to serious discussion Which
obviously was a good one. I am all for BGP over TLS, so let's discuss
https://laptop006.livejournal.com/60532.html
Bjørn
Christopher Morrow <morrowc.lists@gmail.com> writes:
isn't julien's idea more akin to DOT then DOH ?
Yes, and I really like Julien's proposal. It even looks pretty
complete. There are just a few details missing around how to make the
MD5 => TLS transition smooth.
At least for those systems that run on Linux (which is most all of the
major's except Juniper) I suspect if we went to the relevant kernel folk
with a clear plan on how handling TCP-MD5 in a way that would make
transitions much easier they'd listen.
The troll response at the top of my post was actually based on a
response from one of the kernel folk, who dislike TCP options even more
than network operators.
Sorry for any confusion caused by an attempt to make a joke on DoH. I
didn't anticipate the sudden turn to serious discussion
obviously was a good one. I am all for BGP over TLS, so let's discuss
https://laptop006.livejournal.com/60532.html
If anyone is at all interested in this I'm happy to discuss and flesh
out anything that's not clear. After I wrote this (over a few bottles of
red on the flight to linux.conf.au this year) I sent it to a bunch of
people that had expressed interest, including a few BGP implementations,
but nobody bit.
Why do you need to do anything? TLS is Transport Layer Security and it's sole purpose is to protect communications from eavesdropping or modification by wiretappers on/in the line between points A and B. MD5 in BGP is used for authentication (rudimentary, but authentication nonetheless).
Why cannot one just put the MD5 authenticated connection inside a TLS connection? What is the advantage to be gained by replacing the authentication mechanism with weaker certificate authentication method available with TLS?