Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
Julien Goodwin <jgoodwin@studio442.com.au> writes:
On 20/10/19 11:08 pm, Bjørn Mork wrote:
Hank Nussbacher <hank@efes.iucc.ac.il> writes:
On 07/10/2019 17:42, Stephane Bortzmeyer wrote:
On Fri, Oct 04, 2019 at 03:52:26PM -0400, Phil Pishioneri <pgp+nanog@psu.edu> 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
On Sun, Oct 20, 2019 at 6:10 AM Bjørn Mork <bjorn@mork.no> wrote:
Julien Goodwin <jgoodwin@studio442.com.au> writes:
On 20/10/19 11:08 pm, Bjørn Mork wrote:
Hank Nussbacher <hank@efes.iucc.ac.il> writes:
On 07/10/2019 17:42, Stephane Bortzmeyer wrote:
On Fri, Oct 04, 2019 at 03:52:26PM -0400, Phil Pishioneri <pgp+nanog@psu.edu> 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 ?
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
On 21/10/19 6:30 pm, Bjørn Mork wrote:
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 :-) 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.
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.
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.
On 2019-10-21 16:30, Keith Medcalf wrote:
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 MD5 authentication is built into TCP options.. not obvious how you would transport it over TLS which afaik doesn't offer similar functionality. You'd probably have to basically tunnel TCP frames inside TLS, which doesn't really sound ideal (reimplement TCP in userspace?) Either that or maybe use some other simpler MD5 based authentication (unrelated to the TCP implementation currently used in BGP).. but then that raises lots of questions like why even use MD5. Rob
On Monday, 21 October, 2019 09:44, Robert McKay <robert@mckay.com> wrote:
On 2019-10-21 16: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).
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 MD5 authentication is built into TCP options.. not obvious how you would transport it over TLS which afaik doesn't offer similar functionality.
AHA! I understand now and sit corrected. I was under the mistaken impression that MD5 authentication was an application level thing, not a TCP level thing.
You'd probably have to basically tunnel TCP frames inside TLS, which doesn't really sound ideal (reimplement TCP in userspace?)
Either that or maybe use some other simpler MD5 based authentication (unrelated to the TCP implementation currently used in BGP).. but then that raises lots of questions like why even use MD5.
You are correct. There is no point in using or moving the current MD5 authentication method when it can just be "turned off" and some (perhaps better alternate) authentication method used as provided by the TLS wrapper. This of course presumes that if one turns off MD5 that the additional TCP option header is not used ... -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
On 21 Oct 2019, at 12:05, Keith Medcalf <kmedcalf@dessus.com> wrote:
On Monday, 21 October, 2019 09:44, Robert McKay <robert@mckay.com> wrote:
The MD5 authentication is built into TCP options.. not obvious how you would transport it over TLS which afaik doesn't offer similar functionality.
AHA! I understand now and sit corrected. I was under the mistaken impression that MD5 authentication was an application level thing, not a TCP level thing.
Well, TLS exists within a TCP session, and that TCP session could incorporate the MD5 signature option. I guess. Julien's BGP-STARTTLS idea is interesting. I wonder about the practicality of deploying certificates to every BGP speaker that are useful for strict checking by neighbours, though. Perhaps I've been too long with my hands out of routers and things have moved on, but it seems to me that the history of certificate management in routers is not a rich tapestry of triumph. Without strict checking in both directions, the threat model with TLS looks pretty similar to that with TCP-MD5 with not very secret secrets, which I gather is one of the deficiencies that the TLS proposal seeks to address. Joe
Joe Abley <jabley@hopcount.ca> wrote:
Well, TLS exists within a TCP session, and that TCP session could incorporate the MD5 signature option. I guess.
AIUI this might be useful to make it a bit harder to kill the TCP session, tho I think modern TCPs are less vulnerable to off-path RST injection than TCPs were when TCP-MD5 was introduced Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ German Bight, Humber, Thames: Cyclonic, mainly northeast, becoming west later, 3 to 5, occasionally 6 at first. Slight or moderate. Occasional rain. Good, occasionally poor.
On Oct 21, 2019, at 12:30 PM, Joe Abley <jabley@hopcount.ca> wrote:
On 21 Oct 2019, at 12:05, Keith Medcalf <kmedcalf@dessus.com> wrote:
On Monday, 21 October, 2019 09:44, Robert McKay <robert@mckay.com> wrote:
The MD5 authentication is built into TCP options.. not obvious how you would transport it over TLS which afaik doesn't offer similar functionality.
AHA! I understand now and sit corrected. I was under the mistaken impression that MD5 authentication was an application level thing, not a TCP level thing.
Well, TLS exists within a TCP session, and that TCP session could incorporate the MD5 signature option. I guess.
Julien's BGP-STARTTLS idea is interesting. I wonder about the practicality of deploying certificates to every BGP speaker that are useful for strict checking by neighbours, though. Perhaps I've been too long with my hands out of routers and things have moved on, but it seems to me that the history of certificate management in routers is not a rich tapestry of triumph.
It’s not. I talked about this in the security area session at IETF several meetings ago — the requirements operators have around this space, and it’s quite a pain to be honest. I’ve seen enough people have issues with managing a password that certificates would be even harder when there’s a router swap. The issue isn’t that most people want privacy, it’s they want transport integrity which in general the TLS community seems to think everyone NEEDS both.
Without strict checking in both directions, the threat model with TLS looks pretty similar to that with TCP-MD5 with not very secret secrets, which I gather is one of the deficiencies that the TLS proposal seeks to address.
This is a whole mess of trouble here due to the disconnect in how routers are managed, the technical capabilities of vendors and where the protocol split lives here. I will take routers that don’t reboot when we commit them and devices that can be managed automatically vs the keyboard jockey days that we’re all used to.
On 10/21/19 11:04 AM, Jared Mauch wrote:
I’ve seen enough people have issues with managing a password that certificates would be even harder when there’s a router swap.
I think that's an unfortunate state of affair. I don't know how to get around the PEBKAC problem.
The issue isn’t that most people want privacy, it’s they want transport integrity which in general the TLS community seems to think everyone NEEDS both.
The biggest argument that I've seen is that you can't truly have privacy without integrity. Lest you be speaking over an encrypted channel with an unauthenticated MitM. My understanding is that authentication is the most important issue and that privacy is a nice add-on. With that in mind, I wonder if we couldn't have each router be it's own CA and issue /client/ certificates for and to each neighbor to use to authenticate back to the local router. This has the added advantage that you wouldn't need to worry about different routers trusting the same CA or bother with PKI. Everything would be local router centric. The neighbor would effectively be using a super fancy key that a neighbor provided for use when talking to said neighbor. I think that using /client/ certificates would also allow for certificate rotation in that the router can issue a new /client/ certificate while still trusting the existing /client/ certificate. Then once the client updates to using the new /client/ certificate, the router can revoke the old /client/ certificate using standard CRL methods. All of this would be centric to the local router. I suspect that it would likely be okay to have longer lived certificates in such a configuration. -- Grant. . . . unix || die
On 22/10/19 4:04 am, Jared Mauch wrote:
On Oct 21, 2019, at 12:30 PM, Joe Abley <jabley@hopcount.ca> wrote:
On 21 Oct 2019, at 12:05, Keith Medcalf <kmedcalf@dessus.com> wrote:
On Monday, 21 October, 2019 09:44, Robert McKay <robert@mckay.com> wrote:
The MD5 authentication is built into TCP options.. not obvious how you would transport it over TLS which afaik doesn't offer similar functionality.
AHA! I understand now and sit corrected. I was under the mistaken impression that MD5 authentication was an application level thing, not a TCP level thing.
Well, TLS exists within a TCP session, and that TCP session could incorporate the MD5 signature option. I guess.
Julien's BGP-STARTTLS idea is interesting. I wonder about the practicality of deploying certificates to every BGP speaker that are useful for strict checking by neighbours, though. Perhaps I've been too long with my hands out of routers and things have moved on, but it seems to me that the history of certificate management in routers is not a rich tapestry of triumph.
It’s not. I talked about this in the security area session at IETF several meetings ago — the requirements operators have around this space, and it’s quite a pain to be honest.
I’ve seen enough people have issues with managing a password that certificates would be even harder when there’s a router swap.
The issue isn’t that most people want privacy, it’s they want transport integrity which in general the TLS community seems to think everyone NEEDS both.
Yeah, I come from the perspective not just of a (now former AS15169) operator, but also often being one of a network's very few peers, sometimes the only non-transit a network had. IMO, *requiring* certificates or similar is a step too far at the moment, however building something that allows for easy extension to certificates (or whatever) is sensible.
Without strict checking in both directions, the threat model with TLS looks pretty similar to that with TCP-MD5 with not very secret secrets, which I gather is one of the deficiencies that the TLS proposal seeks to address.
This is a whole mess of trouble here due to the disconnect in how routers are managed, the technical capabilities of vendors and where the protocol split lives here.
I will take routers that don’t reboot when we commit them and devices that can be managed automatically vs the keyboard jockey days that we’re all used to.
My personal major gripe with certificate based systems is that many routers don't have an RTC and won't know what time it is until they can NTP, which likely requires protocol adjacencies, and then a dependency loop.
On Tue, Oct 22, 2019 at 6:35 AM Julien Goodwin <nanog@studio442.com.au> wrote:
On 22/10/19 4:04 am, Jared Mauch wrote:
On Oct 21, 2019, at 12:30 PM, Joe Abley <jabley@hopcount.ca> wrote:
On 21 Oct 2019, at 12:05, Keith Medcalf <kmedcalf@dessus.com> wrote:
On Monday, 21 October, 2019 09:44, Robert McKay <robert@mckay.com> wrote:
The MD5 authentication is built into TCP options.. not obvious how you would transport it over TLS which afaik doesn't offer similar functionality.
AHA! I understand now and sit corrected. I was under the mistaken impression that MD5 authentication was an application level thing, not a TCP level thing.
Well, TLS exists within a TCP session, and that TCP session could incorporate the MD5 signature option. I guess.
Julien's BGP-STARTTLS idea is interesting. I wonder about the practicality of deploying certificates to every BGP speaker that are useful for strict checking by neighbours, though. Perhaps I've been too long with my hands out of routers and things have moved on, but it seems to me that the history of certificate management in routers is not a rich tapestry of triumph.
It’s not. I talked about this in the security area session at IETF several meetings ago — the requirements operators have around this space, and it’s quite a pain to be honest.
I’ve seen enough people have issues with managing a password that certificates would be even harder when there’s a router swap.
The issue isn’t that most people want privacy, it’s they want transport integrity which in general the TLS community seems to think everyone NEEDS both.
Yeah, I come from the perspective not just of a (now former AS15169) operator, but also often being one of a network's very few peers, sometimes the only non-transit a network had.
IMO, *requiring* certificates or similar is a step too far at the moment, however building something that allows for easy extension to certificates (or whatever) is sensible.
TLS in the traditional sense 'requires' that there be an X.509 certificate to use in authenticating (and to some extent authorizing - can you be a CA? sign email? etc...) endpoints, ideally you do 'tls mutual authentication'... The x.509 system, to be effective here would require a TrustAnchor / Root-of-Trust that both parties agreed was acceptable... Julien, you are asserting that: "yea, but that's hard, because Julien-net and Chris-net may agree on 'bobs bait and tackle CA', but certainly Jared-net is obstinate and will required only the CA at "Sams Veggie Hut & CA"" ... so we'd end up with managing a 'worse' version of the web-PKI on network devices. To get around that you propose we hopscotch over to 'TLS with preshared keys (PSK)'... ok, that smells nice, it's NOT a kernel/tcp option (hurray) it's possibly safer-ish. I think Jared's point that; "this is just gussied up md5..." isn't wrong, it is nice that this isn't in the kernel path (tcp-md5/tcp-ao HA)... I think that really it'd need some method to change PSK though over time in a sane fashion, ie the 'key table' that is used in other places for this sort of problem. Internally folk that wanted could use their own CA infra to operate / use certs on their iBGP sessions, or customer sessions... and maybe later in our lifetime we could re-use the certs that RPKI distributes as the certs for bgp session security ? (I think there are some pretty draconian restrictions on the certs here, but I don't remember off the top of my head what those are right now.)
Without strict checking in both directions, the threat model with TLS looks pretty similar to that with TCP-MD5 with not very secret secrets, which I gather is one of the deficiencies that the TLS proposal seeks to address.
This is a whole mess of trouble here due to the disconnect in how routers are managed, the technical capabilities of vendors and where the protocol split lives here.
I will take routers that don’t reboot when we commit them and devices that can be managed automatically vs the keyboard jockey days that we’re all used to.
My personal major gripe with certificate based systems is that many routers don't have an RTC and won't know what time it is until they can NTP, which likely requires protocol adjacencies, and then a dependency loop.
this is also a problem, but really ... your igp should get you to an NTP source... or we'd all get to that fairly quickly, right? :) (some of this is updating 'best practices' in building / maintaining a network, right?)
TLS in the traditional sense 'requires' that there be an X.509 certificate to use in authenticating (and to some extent authorizing - can you be a CA? sign email? etc...) endpoints, ideally you do 'tls mutual authentication'...
That is incorrect. I believe that an endpoint (lets call it Alice) can connect to another endpoint (lets call it Bob) and Alice can say to Bob, "Hello Dude, lets negotiate a secret key between us". "Yokkely dokelly", says Bob, "Lets do that". They then exchange some stuff to and fro and then Alice says "Righty then, lets encrypt!" and Bob says, "Yabba Doodle Doo". At this point further communications are encrypted and secure against eavesdropping. Alice still has no idea who she is talking to (other than it is the dude that picked up the phone), and Bob has no idea who he is talking too other than the fact it is whoever rang him up. The Security part in Transport Layer Security is Encryption. Authentication is lathered on top as an afterthought and requires external measures be taken in order to have *any* effect whatsoever. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
Once upon a time, Keith Medcalf <kmedcalf@dessus.com> said:
I believe that an endpoint (lets call it Alice) can connect to another endpoint (lets call it Bob) and Alice can say to Bob, "Hello Dude, lets negotiate a secret key between us". "Yokkely dokelly", says Bob, "Lets do that". They then exchange some stuff to and fro and then Alice says "Righty then, lets encrypt!" and Bob says, "Yabba Doodle Doo".
At this point further communications are encrypted and secure against eavesdropping. Alice still has no idea who she is talking to (other than it is the dude that picked up the phone), and Bob has no idea who he is talking too other than the fact it is whoever rang him up.
But if Alice and Bob don't know that they're talking to each other, they could already be being eavesdropped on. Chuck could have answered Alice's call, turned around and called Bob, connected the two, and be listening in (and potentially even modifying communications between Alice and Bob). This is why encryption without some type of endpoint authentication is not secure. I could see BGP over TLS requiring each end sharing a CA public cert in advance - this would allow each end to re-gen keys at will. The BGP config could easily limit a particular peer to a particular CA (so when I peer with Google, they send me or otherwise publish their BGP CA, and I limit my Google peers to that CA). This could replace trying to securely share MD5 keys today - a BGP CA could be published (possibly even at RIRs). -- Chris Adams <cma@cmadams.net>
On 10/22/2019 14:07, Keith Medcalf wrote:
That is incorrect.
I believe that an endpoint (lets call it Alice) can connect to another endpoint (lets call it Bob) and Alice can say to Bob, "Hello Dude, lets negotiate a secret key between us". "Yokkely dokelly", says Bob, "Lets do that". They then exchange some stuff to and fro and then Alice says "Righty then, lets encrypt!" and Bob says, "Yabba Doodle Doo".
At this point further communications are encrypted and secure against eavesdropping. Alice still has no idea who she is talking to (other than it is the dude that picked up the phone), and Bob has no idea who he is talking too other than the fact it is whoever rang him up.
The Security part in Transport Layer Security is Encryption. Authentication is lathered on top as an afterthought and requires external measures be taken in order to have*any* effect whatsoever.
This is unauthenticated Diffie-Hellmann key agreement, essentially. As has been pointed out, it only works if you know that, during the initial agreement, you can trust that you are talking directly to who you want to talk to without fear of a man in the middle (a passive observer will still be foiled). TLS supports this in the form of anonymous TLS. Something similar is normally used for opportunistic TLS upgrade with e.g. SMTP, but there at least one end (the "server") still presents a certificate; the client just doesn't validate it. Password-authenticated DHKA fixes the above problem, but then you're back to the status quo of a preshared secret. This is, in fact, how the DHE* suite of TLS ciphersuites works, AFAIK. Use PKI to exchange one secret (with trust of who you're talking to, where applicable, due to the PKI), then use authenticated DH to establish a session secret using that as the PSK. Then throw away that session secret when you're done. One thing that comes to mind in the context of what others have done is to have each router maintain, internally, its own long-term CA and issue a peer certificate when a session is first started to its peer. This has the same problem in that the initial session establishment could be meddled with but, assuming that does not happen (and it does not, in practice, seem especially likely except maybe on an IX), the peer can identify itself for the long term. THrow alarm bells if an unknown peer again tries to talk on that configured peer. That at least gets you some form of long-term security (at the cost of possibly NO security if the above assumptions are not met), and it happens automatically. You could do the same thing with a symmetric secret being automatically established using DHKA or similar, too, of course. -- Brandon Martin
No,
On Oct 22, 2019, at 2:08 PM, Keith Medcalf <kmedcalf@dessus.com> wrote:
At this point further communications are encrypted and secure against eavesdropping.
The problem isn't the protocol being eavesdropped on. The data is already published publicly by many people. The problem is one of mutual authentication and authorization of the transport. - Jared
On Tuesday, 22 October, 2019 13:26, Jared Mauch <jared@puck.nether.net> wrote:
No,
On Oct 22, 2019, at 2:08 PM, Keith Medcalf <kmedcalf@dessus.com> wrote:
At this point further communications are encrypted and secure against eavesdropping.
The problem isn't the protocol being eavesdropped on. The data is already published publicly by many people.
The problem is one of mutual authentication and authorization of the transport.
I see. It is an AIC problem, not a CIA problem. TLS in its default usage is a CIA thing because, well, it was designed to solve CIA problems where even temporary secrecy is more important than being down for a week. As had been pointed out though, TLS does allow for non-CIA configuration and usage such as by using PSK or fingerprint authentication. SSH is also an AIC thing. It solves the problem by recording the fingerprint on first connect and alarming if the fingerprint is not subsequently what was expected. Cannot TLS be configured to do the same thing bidirectionally? -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
On Oct 22, 2019, at 6:31 PM, Keith Medcalf <kmedcalf@dessus.com> wrote:
I see. It is an AIC problem, not a CIA problem. TLS in its default usage is a CIA thing because, well, it was designed to solve CIA problems where even temporary secrecy is more important than being down for a week. As had been pointed out though, TLS does allow for non-CIA configuration and usage such as by using PSK or fingerprint authentication. SSH is also an AIC thing. It solves the problem by recording the fingerprint on first connect and alarming if the fingerprint is not subsequently what was expected. Cannot TLS be configured to do the same thing bidirectionally?
I’ve had enough of a problem with the management side of my router w/ SSH(host) keys that imagining trying to scale that to lets say 200 peers at an IXP would make it insane to touch. In my home network I ended up placing a rule due to how often I would play with embedded devices, eg: Host 10.0.0.* StrictHostKeyChecking no UserKnownHostsFile=/dev/null Because each time I have a new device come up with a hostname (eg: raspberrypi.local) I would have to clear out my known hosts file. This local policy allows me to make this simpler. I think something like that is really what’s desired, but when was the last time you managed to keep the ssh daemon key on your router when you swap hardware? The simpler the tools the better. Things like ACME made it much easier for someone to manage their TLS certs and config. There’s much to be desired from the management plane of these devices. No wonder people with scale roll their own code.. Routers haven’t advanced much past the early 90s in sophistication in how you configure them. We’re still in the late 90s with kickstart techniques and manual patching vs enmasse configuration changes. I see the limitations on both the technical side and the human side. Try to tell someone who has been caretaking all the routers to become a sysadmin and watch what happens. It’s up to us as consumers of the technology to push our vendors for something better. I can’t have a router reboot itself when you type commit or similar which is still the state of the industry. - Jared
Sent: Tuesday, October 22, 2019 8:26 PM To: Keith Medcalf <kmedcalf@dessus.com>
No,
On Oct 22, 2019, at 2:08 PM, Keith Medcalf <kmedcalf@dessus.com> wrote:
At this point further communications are encrypted and secure against eavesdropping.
The problem isn't the protocol being eavesdropped on. The data is already published publicly by many people.
The problem is one of mutual authentication and authorization of the transport.
Yes the information is public but if the routing information exchanged over a given peering session is tempered with that could potentially cause some problems right? But then again, as Jeff mentioned, with GTSM this vector is limited to a local link between two eBGP speakers (or whole IGP domain for iBGP sessions but let's leave that one out for now). So move from bilateral peering over common IX-LAN to direct peering Or if a direct link is still not to be trusted do MACSEC. Then it's all about you and the peer -if he/she screws you over de-peer. adam
I do not have much to contribute but this. We already have ( choose your poison(s) ) Dark Fiber + MACsec + BCP38 + ACL + MD5 + MPLS + IRRD + GRE + IPsec + yadi yada PS: Yup, I have SRX300s doing BGP over NNI -and- a GRE + IPsec on LTE as a backup. What is the real endgame from the people(s) proposing "BGP over TLS"? It feel like someone is trying to create a job for himself over a solution in search of a problem. ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 2019-10-23 10:42, adamv0025@netconsultings.com wrote:
Sent: Tuesday, October 22, 2019 8:26 PM To: Keith Medcalf <kmedcalf@dessus.com>
No,
On Oct 22, 2019, at 2:08 PM, Keith Medcalf <kmedcalf@dessus.com> wrote: At this point further communications are encrypted and secure against eavesdropping.
The problem isn't the protocol being eavesdropped on. The data is already published publicly by many people.
The problem is one of mutual authentication and authorization of the transport.
Yes the information is public but if the routing information exchanged over a given peering session is tempered with that could potentially cause some problems right?
But then again, as Jeff mentioned, with GTSM this vector is limited to a local link between two eBGP speakers (or whole IGP domain for iBGP sessions but let's leave that one out for now). So move from bilateral peering over common IX-LAN to direct peering Or if a direct link is still not to be trusted do MACSEC. Then it's all about you and the peer -if he/she screws you over de-peer.
adam
On Wed, Oct 23, 2019 at 11:18 AM Alain Hebert <ahebert@pubnix.net> wrote:
I do not have much to contribute but this.
We already have ( choose your poison(s) )
Dark Fiber + MACsec + BCP38 + ACL + MD5 + MPLS + IRRD + GRE + IPsec + yadi yada
much of this isn't solving the problem though, and adding complexity and layers to the problem, right?
PS: Yup, I have SRX300s doing BGP over NNI -and- a GRE + IPsec on LTE as a backup.
sure everyone can cook up a loony solution.. but in the general case of my iBGP cross-country (or cross-ocean) it'd be nice to not have to do a bunch of really heavyweight things just to get better authen/integrity/<privacy> for my bgp traffic, I think.
What is the real endgame from the people(s) proposing "BGP over TLS"? It feel like someone is trying to create a job for himself over a solution in search of a problem.
----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
On 2019-10-23 10:42, adamv0025@netconsultings.com wrote:
Sent: Tuesday, October 22, 2019 8:26 PM To: Keith Medcalf <kmedcalf@dessus.com>
No,
On Oct 22, 2019, at 2:08 PM, Keith Medcalf <kmedcalf@dessus.com>
wrote:
At this point further communications are encrypted and secure against
eavesdropping.
The problem isn't the protocol being eavesdropped on. The data is already published publicly by many people.
The problem is one of mutual authentication and authorization of the transport.
Yes the information is public but if the routing information exchanged over a given peering session is tempered with that could potentially cause some problems right?
But then again, as Jeff mentioned, with GTSM this vector is limited to a local link between two eBGP speakers (or whole IGP domain for iBGP sessions but let's leave that one out for now). So move from bilateral peering over common IX-LAN to direct peering Or if a direct link is still not to be trusted do MACSEC. Then it's all about you and the peer -if he/she screws you over de-peer.
adam
On Wed, Oct 23, 2019 at 10:43 AM <adamv0025@netconsultings.com> wrote:
Sent: Tuesday, October 22, 2019 8:26 PM To: Keith Medcalf <kmedcalf@dessus.com>
No,
On Oct 22, 2019, at 2:08 PM, Keith Medcalf <kmedcalf@dessus.com> wrote:
At this point further communications are encrypted and secure against eavesdropping.
The problem isn't the protocol being eavesdropped on. The data is already published publicly by many people.
The problem is one of mutual authentication and authorization of the transport.
Yes the information is public but if the routing information exchanged over a given peering session is tempered with that could potentially cause some problems right?
'mutual authentication' CAN be the thing (via tcp md5 today) that does this 'do not tamper' part. there ARE problems with tcp-md5... some are "because we collectively didnt' squeak enough to get key-tables" some are: "err, doing low-level-kernel-muckery is gross".
But then again, as Jeff mentioned, with GTSM this vector is limited to a local link between two eBGP speakers (or whole IGP domain for iBGP sessions but let's leave that one out for now).
ibgp, it turns out, is important.
So move from bilateral peering over common IX-LAN to direct peering Or if a direct link is still not to be trusted do MACSEC. Then it's all about you and the peer -if he/she screws you over de-peer.
and it burning a 100g port on a chassis for ~1g (or less) of traffic is worthwhile... there's lots of variables here... options are nice to have... better security for /not just my IX/ bgp would be nice too :)
> From: Christopher Morrow <morrowc.lists@gmail.com> > Sent: Wednesday, October 23, 2019 6:53 PM > Subject: Re: BGP over TLS > > On Wed, Oct 23, 2019 at 10:43 AM <adamv0025@netconsultings.com> wrote: > > > > > Sent: Tuesday, October 22, 2019 8:26 PM > > > To: Keith Medcalf <kmedcalf@dessus.com> > > > > > > No, > > > > > > > > > > On Oct 22, 2019, at 2:08 PM, Keith Medcalf <kmedcalf@dessus.com> > > > wrote: > > > > > > > > At this point further communications are encrypted and secure > > > > against > > > eavesdropping. > > > > > > The problem isn't the protocol being eavesdropped on. The data is > > > already published publicly by many people. > > > > > > The problem is one of mutual authentication and authorization of the > > > transport. > > > > > Yes the information is public but if the routing information exchanged > > over a given peering session is tempered with that could potentially > > cause some problems right? > > 'mutual authentication' CAN be the thing (via tcp md5 today) that does this > 'do not tamper' part. > there ARE problems with tcp-md5... some are "because we collectively didnt' > squeak enough to get key-tables" > some are: "err, doing low-level-kernel-muckery is gross". > > > But then again, as Jeff mentioned, with GTSM this vector is limited to > > a local link between two eBGP speakers (or whole IGP domain for iBGP > > sessions but let's leave that one out for now). > > ibgp, it turns out, is important. > Well yes and that's why we all have internet plane RR infrastructure separate to the RR infrastructure(s) distributing information for other services right? And is also why we all filter non-standard or even non-usual BGP attributes and unusually long AS paths and community lists on ingress to our AS, just to safeguard our BGP infrastructure. ...yeah about that. > > So move from bilateral peering over common IX-LAN to direct peering Or > > if a direct link is still not to be trusted do MACSEC. > > Then it's all about you and the peer -if he/she screws you over de-peer. > > and it burning a 100g port on a chassis for ~1g (or less) of traffic is > worthwhile... Sure cause the usual math is if I have 100G to IX LAN which is half empty then going direct means 100G x number of peers I'd like to move to direct peering... > there's lots of variables here... options are nice to have... better security for > /not just my IX/ bgp would be nice too :) Well yes I do agree with that statement on a sentimental level almost. But pragmatically I'd have to ask what big of a problem is BGP over TLS going to solve and how much would it cost. Ideally the solution would tick all these 3 together: 1) it's a panacea (solves all aspects of the problem), 2) it's zero effort (development and getting it to the network) 3) it solves a huge problem, (operators are struggling with the effects of this problem on a daily bases) adam
On Thu, Oct 24, 2019 at 9:33 AM <adamv0025@netconsultings.com> wrote:
From: Christopher Morrow <morrowc.lists@gmail.com> Sent: Wednesday, October 23, 2019 6:53 PM Subject: Re: BGP over TLS
On Wed, Oct 23, 2019 at 10:43 AM <adamv0025@netconsultings.com> wrote:
Sent: Tuesday, October 22, 2019 8:26 PM To: Keith Medcalf <kmedcalf@dessus.com>
No,
On Oct 22, 2019, at 2:08 PM, Keith Medcalf <kmedcalf@dessus.com> wrote:
At this point further communications are encrypted and secure against eavesdropping.
The problem isn't the protocol being eavesdropped on. The data is already published publicly by many people.
The problem is one of mutual authentication and authorization of the transport.
Yes the information is public but if the routing information exchanged over a given peering session is tempered with that could potentially cause some problems right?
'mutual authentication' CAN be the thing (via tcp md5 today) that does this 'do not tamper' part. there ARE problems with tcp-md5... some are "because we collectively didnt' squeak enough to get key-tables" some are: "err, doing low-level-kernel-muckery is gross".
But then again, as Jeff mentioned, with GTSM this vector is limited to a local link between two eBGP speakers (or whole IGP domain for iBGP sessions but let's leave that one out for now).
ibgp, it turns out, is important.
Well yes and that's why we all have internet plane RR infrastructure separate to the RR infrastructure(s) distributing information for other services right? And is also why we all filter non-standard or even non-usual BGP attributes and unusually long AS paths and community lists on ingress to our AS, just to safeguard our BGP infrastructure. ...yeah about that.
sounds right, yes. There's at least 1 BCP that talks about this... and some BCOP's from ripe/nanog as well I think?
So move from bilateral peering over common IX-LAN to direct peering Or if a direct link is still not to be trusted do MACSEC. Then it's all about you and the peer -if he/she screws you over de-peer.
and it burning a 100g port on a chassis for ~1g (or less) of traffic is worthwhile... Sure cause the usual math is if I have 100G to IX LAN which is half empty then going direct means 100G x number of peers I'd like to move to direct peering...
Sorry, I skipped a sentence figuring it wasn't worth typing, but ... "100g is the new 10g which was the new 1g ... and on 100g platforms you often don't get 1g as well... it's harder to delivery 10G (almost) than 100g :( " So default at the edge is moving to 100g for some folk
there's lots of variables here... options are nice to have... better security for /not just my IX/ bgp would be nice too :)
Well yes I do agree with that statement on a sentimental level almost.
But pragmatically I'd have to ask what big of a problem is BGP over TLS going to solve and how much would it cost. Ideally the solution would tick all these 3 together: 1) it's a panacea (solves all aspects of the problem), 2) it's zero effort (development and getting it to the network) 3) it solves a huge problem, (operators are struggling with the effects of this problem on a daily bases)
sure... I don't have a cogent answer to all of these, but if you believe there's a need for authentication / integrity / privacy on some/all of your BGP sessions, you probably want: 1) something that rotates regularly instead of static md5 would be great because everyone's md5 secret is public, regardless of your efforts to secure that data :( 2) something that doesn't require operator interference to enable/rotate/manage would be nice one main complaint about md5 is it's very hard to setup reliably, folk don't record the keys, etc. "argh, peer didn't come up, rm-rf-key.. look working now!" making that more straightforward and less error prone would be good. -chris
From: Christopher Morrow <morrowc.lists@gmail.com> Sent: Friday, October 25, 2019 7:08 AM
So move from bilateral peering over common IX-LAN to direct peering Or if a direct link is still not to be trusted do MACSEC. Then it's all about you and the peer -if he/she screws you over de-peer.
and it burning a 100g port on a chassis for ~1g (or less) of traffic is worthwhile... Sure cause the usual math is if I have 100G to IX LAN which is half empty then going direct means 100G x number of peers I'd like to move to direct peering...
Sorry, I skipped a sentence figuring it wasn't worth typing, but ... "100g is the new 10g which was the new 1g ... and on 100g platforms you often don't get 1g as well... it's harder to delivery 10G (almost) than 100g :( "
So default at the edge is moving to 100g for some folk
Nah that's just advertising, 100G is still not quite there yet: 100G SR4 99,- 40G SR4 39,- 10G SR 18,- 1000BASE-T 18,- 1000BASE-SX 6,- 100G LR 799,- 40G LR 279,- 10G LR 24,- 1G LX 7,- Yes these are just indicative transceiver prices, but it sort of speaks to the argument of 100G for anything cause it doesn't matter. Also from the forwarding chip perspective, 100G being a new 10G is currently has a faint chance only on the most "simplest" merchant silicon, it will take a long time till this notion trickles down and is reflected in prices of vendor NPUs/PFEs or cards. e.g. try comparing list prices of a 32 port 10G card to a 32 port 100G card and then tell me it doesn't really matter whether you'll burn a 10G or 100G port for the 1g peer :) adam
Christopher Morrow <morrowc.lists@gmail.com> writes:
The x.509 system, to be effective here would require a TrustAnchor / Root-of-Trust that both parties agreed was acceptable...
As in a shared TrustAnchor? No. Both ends could use a simple self signed certificate and be configured to trust the other. A hash of the peers public key would be sufficient for the BGP peer configuration. Or you could use more complex PKI models, with a CA hierarchy or whatever. The point is that TLS doesn't force you to do that Authenticating the peer by its public key hash is as simple as using an TCP-MD5 password.
To get around that you propose we hopscotch over to 'TLS with preshared keys (PSK)'...ok, that smells nice,
Maybe. Personally I don't see the point.
My personal major gripe with certificate based systems is that many routers don't have an RTC and won't know what time it is until they can NTP, which likely requires protocol adjacencies, and then a dependency loop.
this is also a problem, but really ... your igp should get you to an NTP source... or we'd all get to that fairly quickly, right? :) (some of this is updating 'best practices' in building / maintaining a network, right?)
You may ignore notAfter and notBegin like DANE does. The ntp issue is another reason. But IMHO the most important one is that you don't want any sort of forced key rotation, where the configuration that was valid yesterday suddenly becomes invalid. That's a policy designed for a completely different usecase than running a routing protocol. You'll probably want to trust your configured pinned peer key for as long as it is part of your configuration. And if you are using a CA, then you'll probably want to use a CRL to withdraw specific certificates instead of depending on a timeout. And before someone claims that notAfter and notBegin validation is mandated by the RFC 5280 certificate policy - The good authors of RFC 5280 anticipated that their "Internet applications" policy wouldn't necessarily fit all: Some communities will need to supplement, or possibly replace, this profile in order to meet the requirements of specialized application domains or environments with additional authorization, assurance, or operational requirements. However, for basic applications, common representations of frequently used attributes are defined so that application developers can obtain necessary information without regard to the issuer of a particular certificate or certificate revocation list (CRL). BTW, using TLS for management protocols is not completely unknown. We already have RADSEC (RFC 6614) and syslog-tls (RFC 5425), and probably others I haven't touched yet. The certificate management problem is pretty much the same for all these. You have a closed group of clients/servers/peers using explicitly configured sessions. You want both ends to authenticate each other. You don't necessarily want an umbrella trust anchor in the form of a CA. Defining trust per session is fine, using pinned certificates. Bjørn
On Tue, Oct 22, 2019 at 2:21 PM Bjørn Mork <bjorn@mork.no> wrote:
Christopher Morrow <morrowc.lists@gmail.com> writes:
The x.509 system, to be effective here would require a TrustAnchor / Root-of-Trust that both parties agreed was acceptable...
As in a shared TrustAnchor? No. Both ends could use a simple self
as an option, sure. not a great one as you say. (and I agree, today's 'web pki' model just isn't sane for networking)
signed certificate and be configured to trust the other. A hash of the peers public key would be sufficient for the BGP peer configuration.
This is effectively the same as the md5 problem, right? and there'd have to be a bunch of not-standard machinations in the tls connection to support this behavior... never mind: "Was that E5S or E5s gosh.. can you send me this over IM please?" :) (passing around the fingerprints is hard)
Or you could use more complex PKI models, with a CA hierarchy or whatever. The point is that TLS doesn't force you to do that
right, I think I said that in the next paragraph: "Hey, you could use psk..."
Authenticating the peer by its public key hash is as simple as using an TCP-MD5 password.
err... is it though? 'foobarbaz' is a long simpler than: SHA1 Fingerprint=A2:A8:74:E7:3C:20:49:E4:2D:5A:6E:97:EF:B2:65:C7:59:44:1A:6E
To get around that you propose we hopscotch over to 'TLS with preshared keys (PSK)'...ok, that smells nice,
Maybe. Personally I don't see the point.
I think ... if we are working away from a static 'key' and to something that could be machine managed in a secure fashion (certs, for instance) we'd be in a better place for: bgp session security bgp session integrity bgp session authentication
My personal major gripe with certificate based systems is that many routers don't have an RTC and won't know what time it is until they can NTP, which likely requires protocol adjacencies, and then a dependency loop.
this is also a problem, but really ... your igp should get you to an NTP source... or we'd all get to that fairly quickly, right? :) (some of this is updating 'best practices' in building / maintaining a network, right?)
You may ignore notAfter and notBegin like DANE does. The ntp issue is
I don't know what those fields are but: notBefore=Oct 3 17:13:51 2019 GMT notAfter=Dec 26 17:13:51 2019 GMT maybe you mean these? sure, you CAN ignore those, but that's also 'non-standard, outside openssl-like behavior' so likely to cause problems :( and, you really do want certs with expiry that's 'short' so you don't need to worry about CRL distribution and such. I think anyway.
another reason. But IMHO the most important one is that you don't want any sort of forced key rotation, where the configuration that was valid yesterday suddenly becomes invalid. That's a policy designed for a completely different usecase than running a routing protocol.
there are many examples of (outside x509/ssl) key management systems that use date initiated keys though, on network devices. most vendors support a key table for ISIS and OSPF... and LDP (I believe)
You'll probably want to trust your configured pinned peer key for as long as it is part of your configuration. And if you are using a CA,
that seems .. bad. What if someone gets the key material that's not your peer? https://arstechnica.com/information-technology/2019/10/hackers-steal-secret-... this doesnt' happen too often... wait, yes it does. You want the ability to CRL or expire or make a lost cert less useful. keys/certs/secrets that last forever are not a thing.
then you'll probably want to use a CRL to withdraw specific certificates instead of depending on a timeout.
CRLs imply some external dependency, maybe that's ok depending on your deployment, but I imagine that if we get to a world with a CA per peer-as, there are going to be folk very busy getting CRLs and not so busy getting routes done. there's a tradeoff for each of these things, I imagine a well reasoned paper (juilien?) and some standards (possibly) + implementer work would be necessary to get true forward movement. (and desire to actually do this work)
And before someone claims that notAfter and notBegin validation is mandated by the RFC 5280 certificate policy - The good authors of RFC 5280 anticipated that their "Internet applications" policy wouldn't necessarily fit all:
Some communities will need to supplement, or possibly replace, this profile in order to meet the requirements of specialized application domains or environments with additional authorization, assurance, or operational requirements. However, for basic applications, common representations of frequently used attributes are defined so that application developers can obtain necessary information without regard to the issuer of a particular certificate or certificate revocation list (CRL).
BTW, using TLS for management protocols is not completely unknown. We already have RADSEC (RFC 6614) and syslog-tls (RFC 5425), and probably others I haven't touched yet. The certificate management problem is pretty much the same for all these. You have a closed group of clients/servers/peers using explicitly configured sessions. You want both ends to authenticate each other. You don't necessarily want an umbrella trust anchor in the form of a CA. Defining trust per session is fine, using pinned certificates.
to each his/her own I suspect... on the 'use pinned certs' thing. I am hoping we can imagine a better world and move there.
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
On Oct 21, 2019, at 3:25 PM, Brandon Martin <lists.nanog@monmotha.net> 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
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
On Oct 21, 2019, at 4:17 PM, Brandon Martin <lists.nanog@monmotha.net> 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
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
Jeffrey Haas <jhaas@pfrc.org> writes:
Exactly how the cert lifetime interacts with peering sessions is likely to be several flavors of ugly.
If you pin the key, then there is no reason to care about expiration. You could define the certificate as valid for as long as the pinned key matches. This is similar to what DANE does. Bjørn
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 <jhaas@pfrc.org> wrote:
Exactly how the cert lifetime interacts with peering sessions is likely to be several flavors of ugly.
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
participants (17)
-
adamv0025＠netconsultings.com -
Alain Hebert -
Bjørn Mork -
Brandon Martin -
Brielle -
Chris Adams -
Christopher Morrow -
Grant Taylor -
Jared Mauch -
Jeffrey Haas -
Joe Abley -
Julien Goodwin -
Keith Medcalf -
Radu-Adrian Feurdean -
Randy Bush -
Robert McKay -
Tony Finch