Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
No attachments to the ml, but I gotcha covered ;) https://web.archive.org/web/20200109210214/https://noia.network/technology -- Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com pgp key: B178313E | also on Signal On Thu, Jan 9, 2020 at 12:39 PM Töma Gavrichenkov wrote: > I'm attaching the original pic in case they will replace it. > > The true knowledge would then be preserved! > > On Thu, Jan 9, 2020, 11:05 PM Töma Gavrichenkov wrote: > >> This is the deadliest IPv6 packet structure infographics I've ever seen >> in my life. >> >> https://noia.network/assets/concept-basics.jpg >> >> On Thu, Jan 9, 2020, 7:29 PM Aistis Zenkevičius >> wrote: >> >>> So, a bit like this then: https://noia.network/technology >>> >>> -Aistis >>> >>> >>> -Original Message- >>> From: NANOG On Behalf Of Phil Pishioneri >>> Sent: 2019 m. spalio 4 d., penktadienis 22:52 >>> To: NANOG list >>> Subject: "Using Cloud Resources to Dramatically Improve Internet Routing" >>> >>> [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 >>> >>>
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
I'm attaching the original pic in case they will replace it. The true knowledge would then be preserved! On Thu, Jan 9, 2020, 11:05 PM Töma Gavrichenkov wrote: > This is the deadliest IPv6 packet structure infographics I've ever seen in > my life. > > https://noia.network/assets/concept-basics.jpg > > On Thu, Jan 9, 2020, 7:29 PM Aistis Zenkevičius > wrote: > >> So, a bit like this then: https://noia.network/technology >> >> -Aistis >> >> >> -Original Message- >> From: NANOG On Behalf Of Phil Pishioneri >> Sent: 2019 m. spalio 4 d., penktadienis 22:52 >> To: NANOG list >> Subject: "Using Cloud Resources to Dramatically Improve Internet Routing" >> >> [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 >> >>
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
Looks like my RIPE IPv6 trainings have done me no good. I'm definitely going to complain. On Thu, Jan 9, 2020, 11:17 PM Matthew Petach wrote: > > Whoa... > > So IPv6 is just a segment routing wrapper around IPv4. > > !insert mandatory "I know kung fu" meme <-- here > > ^_^ > > > On Thu, Jan 9, 2020 at 12:07 PM Töma Gavrichenkov > wrote: > >> This is the deadliest IPv6 packet structure infographics I've ever seen >> in my life. >> >> https://noia.network/assets/concept-basics.jpg >> >> On Thu, Jan 9, 2020, 7:29 PM Aistis Zenkevičius >> wrote: >> >>> So, a bit like this then: https://noia.network/technology >>> >>> -Aistis >>> >>> >>> -Original Message- >>> From: NANOG On Behalf Of Phil Pishioneri >>> Sent: 2019 m. spalio 4 d., penktadienis 22:52 >>> To: NANOG list >>> Subject: "Using Cloud Resources to Dramatically Improve Internet Routing" >>> >>> [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 >>> >>>
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
Whoa... So IPv6 is just a segment routing wrapper around IPv4. !insert mandatory "I know kung fu" meme <-- here ^_^ On Thu, Jan 9, 2020 at 12:07 PM Töma Gavrichenkov wrote: > This is the deadliest IPv6 packet structure infographics I've ever seen in > my life. > > https://noia.network/assets/concept-basics.jpg > > On Thu, Jan 9, 2020, 7:29 PM Aistis Zenkevičius > wrote: > >> So, a bit like this then: https://noia.network/technology >> >> -Aistis >> >> >> -Original Message- >> From: NANOG On Behalf Of Phil Pishioneri >> Sent: 2019 m. spalio 4 d., penktadienis 22:52 >> To: NANOG list >> Subject: "Using Cloud Resources to Dramatically Improve Internet Routing" >> >> [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 >> >>
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
This is the deadliest IPv6 packet structure infographics I've ever seen in my life. https://noia.network/assets/concept-basics.jpg On Thu, Jan 9, 2020, 7:29 PM Aistis Zenkevičius wrote: > So, a bit like this then: https://noia.network/technology > > -Aistis > > > -Original Message- > From: NANOG On Behalf Of Phil Pishioneri > Sent: 2019 m. spalio 4 d., penktadienis 22:52 > To: NANOG list > Subject: "Using Cloud Resources to Dramatically Improve Internet Routing" > > [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 > >
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
Interested in this new fangled 'concensus' protocol . ok not really. :) On Thu, Jan 9, 2020 at 12:00 PM Matt Corallo wrote: > lol no that’s even worse. “We put routing on the blockchain to make it > secure and scalable the two things blockchains generally aren’t, now > please buy our token “. > > > On Jan 9, 2020, at 11:28, Aistis Zenkevičius wrote: > > > > So, a bit like this then: https://noia.network/technology > > > > -Aistis > > > > > > -Original Message- > > From: NANOG On Behalf Of Phil Pishioneri > > Sent: 2019 m. spalio 4 d., penktadienis 22:52 > > To: NANOG list > > Subject: "Using Cloud Resources to Dramatically Improve Internet Routing" > > > > [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 > > > >
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
lol no that’s even worse. “We put routing on the blockchain to make it secure and scalable the two things blockchains generally aren’t, now please buy our token “. > On Jan 9, 2020, at 11:28, Aistis Zenkevičius wrote: > > So, a bit like this then: https://noia.network/technology > > -Aistis > > > -Original Message- > From: NANOG On Behalf Of Phil Pishioneri > Sent: 2019 m. spalio 4 d., penktadienis 22:52 > To: NANOG list > Subject: "Using Cloud Resources to Dramatically Improve Internet Routing" > > [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 >
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
"noia" is Italian for boredom ... maybe these folks want to spice up life a little :D On Thu, Jan 9, 2020 at 5:28 PM Aistis Zenkevičius wrote: > So, a bit like this then: https://noia.network/technology > > -Aistis > > > -Original Message- > From: NANOG On Behalf Of Phil Pishioneri > Sent: 2019 m. spalio 4 d., penktadienis 22:52 > To: NANOG list > Subject: "Using Cloud Resources to Dramatically Improve Internet Routing" > > [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 > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
RE: "Using Cloud Resources to Dramatically Improve Internet Routing"
So, a bit like this then: https://noia.network/technology -Aistis -Original Message- From: NANOG On Behalf Of Phil Pishioneri Sent: 2019 m. spalio 4 d., penktadienis 22:52 To: NANOG list Subject: "Using Cloud Resources to Dramatically Improve Internet Routing" [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
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
On 10/21/19 4:41 PM, Jeffrey Haas wrote: I'm not someone qualified, but I'll regurgitate what I've distilled from past conversations with those who are.:-) Presuming your key is strong enough, it may be infeasible to break it in a time that's of interest to the parties involved. The primary issue is the usual issue of trying to keep anything secret: eventually disclosure becomes an issue. And if you have no procedure for periodically updating your keys, it becomes a problem. Going back to my thought of using IKE vs. a static SPI, we run into the same problem with rekeying the long-term secret. If it's symmetric, you have to get both parties involved. That will be true if it's IKE with a PSK, a static SPI, or TCP-MD5. I guess the meat of my question is, given modern cryptography (algorithms, best practices, actual system implementations, etc.), is the periodic re-keyed offered by IKE with PSK any better than simply establishing a static SPI (treating the SPI session secret as a slightly less human-friendly PSK)? If not, then you can do away with IKE entirely which drastically simplifies things. It's also the status quo for many implementations of OSPFv3-over-IPsec that I've seen. My impression is that any means by which a long-lived session using the same symmetric cipher secret can compromise the security of either that session or any other session keyed using the same "parent" keying material is now considered a weakness in the cipher or cryptosystem, as appropriate, and modern ciphers and systems as such do not exhibit such deficiencies. It's also no worse than TCP-MD5 which, as you pointed out, requires both ends to cooperate in a re-keying, too. I'm not even aware of any mechanisms to allow key overlap during a re-keying process in TCP-MD5 which might otherwise be one advantage of IKE using PSK. If your SPI secret gets disclosed, you re-key manually. If your TCP-MD5 secret gets disclosed, you rep-key manually. If your IKE PSK secret gets disclosed, you re-key manually. My only real goal, here, is to be as good or better than TCP-MD5 to address earlier concerns about people not liking TCP options while also not resorting to TLS. (As a note, I'm thinking out loud with all this, not trying to suggest policy proposal) -- Brandon Martin
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
> On Oct 21, 2019, at 4:17 PM, Brandon Martin wrote: > > On 10/21/19 3:37 PM, Jeffrey Haas wrote: >> BGP over ipsec works fine. But that said, it's mostly done with pre-shared >> keys. > > Is anybody actually doing it in practice? Absolutely. In the SP sector? Less clear. >> The ugly issue of ipsec is that the ecosystem really wants IKE to do the >> good things people associate with long lived sessions. I don't even vaguely >> pretend to be an ipsec/ike expert, but the wrangling over this and router >> bootstrapping issues generated a lot of heat and a small amount of light in >> IETF a while back. > > Yes. ipsec (IP layer) itself isn't too bad. IKE is a complex mess. A > functional mess, perhaps, but a mess nonetheless. I'd really like to hear > from someone actually qualified on the cryptography side of things to chime > in on whether long-lived symmetric keys are even really a problem anymore. > If they're not, just generating a decent "session" key and statically > defining an SPI is a lot more straightforward. I'm not someone qualified, but I'll regurgitate what I've distilled from past conversations with those who are. :-) Presuming your key is strong enough, it may be infeasible to break it in a time that's of interest to the parties involved. The primary issue is the usual issue of trying to keep anything secret: eventually disclosure becomes an issue. And if you have no procedure for periodically updating your keys, it becomes a problem. The problem is exacerbated by the fact that inter-provider key sharing is a PITA. If you're having situations where you have to hit this list as a NOC of last resort, now try to imagine a regular cadence of conversations to update your key. And then deal with the fact that key rotation for TCP-MD5 can be hit or miss. In practice, this means that if you had someone that knew your keys and was kicked out of your company, they have the ability to do bad stuff. The ability to more easily update your session keys is one of the big wins for tcp-ao. A lot of the issues behind transport security are mitigated - and this is a point I end up raising to various IETF security reviewers on a regular basis when talking about control plane protocols: - It's possible to reduce the attack surface by using things like GTSM. You've acquired the key somehow? Great - now get packets to that link. - Similarly, protecting the link itself through things like MACSEC is a way to reduce the attack surface. - What are the actual attacks they can do? For BGP, knocking over the session is often the goal. The necessary man in the middle for an active hijack if you can insert yourself into the conversation is absolutely doable... but you're better off just hijacking a router through another compromise and then simply injecting bad routing data. Where much of this puts us is iBGP is of far more interest to an active attacker. Protection of internal routing infrastructure, including firewalls that are properly configured, again can help here. And this becomes even more tasty if you're in an environment making use of SDN-ish stuff. > > OSPFv3 hopefully taught people some lessons with its initial lack of built-in > authentication. "Just use ipsec". This one, IMNSHO, can be blamed on specific IETF religion at the time. The fallouts around this are one of my more favored examples of "this needed operational review". > >> And if you have a rather scaled out router, imagine the cpu melting that >> goes with a cold startup scenario where you have to get all of those IKE >> sessions up to start up your BGP. Now think what that does to your restart >> time. > > Indeed, though I've seen a trend toward putting rather hefty CPUs on the > control planes of "real" routers, nowadays, which I guess is welcome. It > doesn't really contribute much to the overall cost of something that can push > 100s of Gbps in hardware, anyway. Believe me, implementors are happy to have some extra cycles available. However, too many target platforms are either still under-powered or have operational requirements that push them toward slower CPUs. And even for large enough platforms, security computation can eat every spare cycle you have. Generally, a conversation with crypto experts will eventually devolve to "key lengths/cipher is now considered weak, use the next one" - which is shorthand for saying "if you have available cpu, you're not using strong enough crypto". :-) -- Jeff
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
This was one thing I highlighted to the people telling me how I secure my network wrong. If it's HTTP and you lose a few clients maybe they don't care. If it's BGP I have one client and I care a lot and that session dropping can be gigs to tbps of traffic. Sent from my iCar > On Oct 21, 2019, at 4:20 PM, Jeffrey Haas wrote: > > Exactly how the cert lifetime interacts with peering sessions is likely to be > several flavors of ugly.
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
> On Oct 21, 2019, at 3:25 PM, Brandon Martin wrote: > > On 10/21/19 11:30 AM, Keith Medcalf wrote: >> 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? > > Self-issued certificates with either CA pinning or end-certificate hash > pinning is arguably more secure than a shared passphrase as used by TCP-MD5 > in that someone with knowledge of the secrets of one end cannot use it to > impersonate the other end whereas a shared passphrase is inherently shared > and symmetric in that respect. Whether that really provides much value in > the context of a BGP session is perhaps questionable. Considering a lot of hand-wringing from the various security conscious folk is over the ability to easily re-key, I think it mostly just complicates things. Certs are effectively a much nicer single use key. Exactly how the cert lifetime interacts with peering sessions is likely to be several flavors of ugly. > > Wouldn't ipsec be a "cleaner" solution to this (buginess of implementations > and difficulty of configuration aside)? It would also solve the TCP-RST > injection issues that TCP-MD5 was intended to resolve. You can use null > encryption with ESP or even just AH if you want authentication without > confidentiality, too. Or are we all going to admit that ipsec is almost dead > in that it's just too darned complex? Just run BGP over TCP as normal and > install a security policy that says it must use ipsec with appropriate > (agreed-upon) authentication. "Just", right? BGP over ipsec works fine. But that said, it's mostly done with pre-shared keys. The ugly issue of ipsec is that the ecosystem really wants IKE to do the good things people associate with long lived sessions. I don't even vaguely pretend to be an ipsec/ike expert, but the wrangling over this and router bootstrapping issues generated a lot of heat and a small amount of light in IETF a while back. And if you have a rather scaled out router, imagine the cpu melting that goes with a cold startup scenario where you have to get all of those IKE sessions up to start up your BGP. Now think what that does to your restart time. -- Jeff
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
On 10/21/19 3:37 PM, Jeffrey Haas wrote: > BGP over ipsec works fine. But that said, it's mostly done with pre-shared > keys. Is anybody actually doing it in practice? Every transit and peering document I've ever seen just talks about TCP-MD5 (if it talks about authentication at all). > The ugly issue of ipsec is that the ecosystem really wants IKE to do the good > things people associate with long lived sessions. I don't even vaguely > pretend to be an ipsec/ike expert, but the wrangling over this and router > bootstrapping issues generated a lot of heat and a small amount of light in > IETF a while back. Yes. ipsec (IP layer) itself isn't too bad. IKE is a complex mess. A functional mess, perhaps, but a mess nonetheless. I'd really like to hear from someone actually qualified on the cryptography side of things to chime in on whether long-lived symmetric keys are even really a problem anymore. If they're not, just generating a decent "session" key and statically defining an SPI is a lot more straightforward. OSPFv3 hopefully taught people some lessons with its initial lack of built-in authentication. "Just use ipsec". Ever tried to configure ipsec for multicast destinations/sources? Ugh. Authentication trailer is much simpler AND solves other issues as noted in the spec for it. Unfortunately, it's still new enough that getting gear that supports it can be somewhat difficult, and it certainly rules out most end-of-sale or extended-support gear that might otherwise be perfectly serviceable but isn't receiving feature updates. > And if you have a rather scaled out router, imagine the cpu melting that goes > with a cold startup scenario where you have to get all of those IKE sessions > up to start up your BGP. Now think what that does to your restart time. Indeed, though I've seen a trend toward putting rather hefty CPUs on the control planes of "real" routers, nowadays, which I guess is welcome. It doesn't really contribute much to the overall cost of something that can push 100s of Gbps in hardware, anyway. -- Brandon Martin
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
On 10/21/2019 1:25 PM, Brandon Martin wrote: Wouldn't ipsec be a "cleaner" solution to this (buginess of implementations and difficulty of configuration aside)? It would also solve the TCP-RST injection issues that TCP-MD5 was intended to resolve. You can use null encryption with ESP or even just AH if you want authentication without confidentiality, too. Or are we all going to admit that ipsec is almost dead in that it's just too darned complex? Just run BGP over TCP as normal and install a security policy that says it must use ipsec with appropriate (agreed-upon) authentication. "Just", right? I've used BGP over IPSec before in my labs between EdgeRouter models for testing purposes. Other then making sure there is either a connected route or static route (if doing multihop) to the other side, its works. But like you said, interop issues and all may cause issues... Speaking of issues, if you run StrongSwan for IPSec with BGP on the same router/system, make sure to disable charon's processing of routes or you'll be burning major CPU cycles. See: https://wiki.strongswan.org/issues/1196 -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
On 10/21/19 11:30 AM, Keith Medcalf wrote: > 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? Self-issued certificates with either CA pinning or end-certificate hash pinning is arguably more secure than a shared passphrase as used by TCP-MD5 in that someone with knowledge of the secrets of one end cannot use it to impersonate the other end whereas a shared passphrase is inherently shared and symmetric in that respect. Whether that really provides much value in the context of a BGP session is perhaps questionable. As has been pointed out elsewhere in the thread, TLS does also support PSK-based authentication and keying rather than certificates. It's not commonly used since the normal uses of TLS are one-server<->many-clients which doesn't lend itself well to such things, but it's at least defined. Wouldn't ipsec be a "cleaner" solution to this (buginess of implementations and difficulty of configuration aside)? It would also solve the TCP-RST injection issues that TCP-MD5 was intended to resolve. You can use null encryption with ESP or even just AH if you want authentication without confidentiality, too. Or are we all going to admit that ipsec is almost dead in that it's just too darned complex? Just run BGP over TCP as normal and install a security policy that says it must use ipsec with appropriate (agreed-upon) authentication. "Just", right? -- Brandon Martin
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
On Mon, Oct 21, 2019, at 17:30, Keith Medcalf wrote: > 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). TLS can also be used for authentication (in several ways), even if it's not the most appropriate for this situation.
RE: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
>On 21/10/19 6:30 pm, Bjørn Mork wrote: >> 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. 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? -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
On 21/10/19 6:30 pm, Bjørn Mork wrote: > Christopher Morrow 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 :-) Which > 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.
BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
Christopher Morrow 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
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
On Sun, Oct 20, 2019 at 6:10 AM Bjørn Mork wrote: > > Julien Goodwin writes: > > On 20/10/19 11:08 pm, Bjørn Mork wrote: > >> Hank Nussbacher writes: > >>> On 07/10/2019 17:42, Stephane Bortzmeyer wrote: > On Fri, Oct 04, 2019 at 03:52:26PM -0400, > Phil Pishioneri wrote > 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. isn't julien's idea more akin to DOT then DOH ?
RE: "Using Cloud Resources to Dramatically Improve Internet Routing"
On Sunday, 20 October, 2019 06:08, Bjørn Mork wrote: >Hank Nussbacher writes: >> 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. >The future is BoH And that is just one letter short of the BOFH ... -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
Julien Goodwin writes: > On 20/10/19 11:08 pm, Bjørn Mork wrote: >> Hank Nussbacher writes: >>> On 07/10/2019 17:42, Stephane Bortzmeyer wrote: On Fri, Oct 04, 2019 at 03:52:26PM -0400, Phil Pishioneri wrote 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
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
On 20/10/19 11:08 pm, Bjørn Mork wrote: > Hank Nussbacher writes: >> On 07/10/2019 17:42, Stephane Bortzmeyer wrote: >>> On Fri, Oct 04, 2019 at 03:52:26PM -0400, >>> Phil Pishioneri wrote >>> 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, 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
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
Von: na...@radu-adrian.feurdean.net Gesendet: 20. Oktober 2019 12:45 An: nanog@nanog.org Betreff: Re: "Using Cloud Resources to Dramatically Improve Internet Routing" On Mon, Oct 7, 2019, at 16:42, Stephane Bortzmeyer wrote: > 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?
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
Hank Nussbacher writes: > On 07/10/2019 17:42, Stephane Bortzmeyer wrote: >> On Fri, Oct 04, 2019 at 03:52:26PM -0400, >> Phil Pishioneri wrote >> 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. The future is BoH Bjørn
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
On Mon, Oct 7, 2019, at 16:42, Stephane Bortzmeyer wrote: > 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.
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
On Fri, 11 Oct 2019 12:02:30 +0200, Warren Kumari said: > 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. () 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...) pgph3KkPdSta2.pgp Description: PGP signature
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
On Mon, Oct 7, 2019 at 4:45 PM Stephane Bortzmeyer wrote: > > On Fri, Oct 04, 2019 at 03:52:26PM -0400, > Phil Pishioneri wrote > 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? 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 licens...@university.org to learn how to license this critical technology. Click to enroll in University, where you too can learn to fix the Interwebs and earn lots of money." W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
Feel that this is more down the line of RFC 7511, no? ;-) —Dennis On Tue, Oct 8, 2019 at 07:25 J. Hellenthal via NANOG wrote: > See RFC 1149 & 2549 > > ;-) > > -- > J. Hellenthal > > The fact that there's a highway to Hell but only a stairway to Heaven says > a lot about anticipated traffic volume. > > > On Oct 7, 2019, at 11:29, Keith Medcalf wrote: > > > > > >> On Monday, 7 October, 2019 08:55, Rich Kulawiec wrote: > >> > >> On Mon, Oct 07, 2019 at 04:42:11PM +0200, Stephane Bortzmeyer wrote: > > > >>> 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). > > > > :) > > > > -- > > The fact that there's a Highway to Hell but only a Stairway to Heaven > > says a lot about anticipated traffic volume. > > > > > > >
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
See RFC 1149 & 2549 ;-) -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Oct 7, 2019, at 11:29, Keith Medcalf wrote: > > >> On Monday, 7 October, 2019 08:55, Rich Kulawiec wrote: >> >> On Mon, Oct 07, 2019 at 04:42:11PM +0200, Stephane Bortzmeyer wrote: > >>> 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). > > :) > > -- > The fact that there's a Highway to Hell but only a Stairway to Heaven > says a lot about anticipated traffic volume. > > >
RE: "Using Cloud Resources to Dramatically Improve Internet Routing"
On Monday, 7 October, 2019 08:55, Rich Kulawiec wrote: >On Mon, Oct 07, 2019 at 04:42:11PM +0200, Stephane Bortzmeyer wrote: >> 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). :) -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
On 07/10/2019 17:42, Stephane Bortzmeyer wrote: On Fri, Oct 04, 2019 at 03:52:26PM -0400, Phil Pishioneri wrote 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. What could possibly go wrong?! -Hank
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
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. At 03:52 PM 04/10/2019, Phil Pishioneri wrote: [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 -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
On Mon, Oct 07, 2019 at 04:42:11PM +0200, Stephane Bortzmeyer wrote: > 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". ---rsk
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
On Fri, Oct 04, 2019 at 03:52:26PM -0400, Phil Pishioneri wrote 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?
