On Mon, Jun 1, 2015 at 9:39 AM, Måns Nilsson <mansaxel@besserwisser.org> wrote:

Subject: BGP in the Washngton Post Date: Mon, Jun 01, 2015 at 09:24:33AM -0400 Quoting William Herrin (bill@herrin.us):

...

Interesting story about BGP and security in the Washington Post today:

http://www.washingtonpost.com/sf/business/2015/05/31/net-of-insecurity-part-...

sort of dissappointed they did not quote randy using only lower case. looks weird. once past that, good comment.

and in comic sans you mean?

Actually, that's the level of attention given to all kinds of infrastructure just about everywhere. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Jared Mauch" <jared@puck.nether.net> To: "Ca By" <cb.list6@gmail.com> Cc: nanog@nanog.org Sent: Monday, June 1, 2015 10:00:38 AM Subject: Routing Insecurity (Re: BGP in the Washington Post)

On Jun 1, 2015, at 10:08 AM, Ca By <cb.list6@gmail.com> wrote: The article left me with the feeling that there was a secure version of BGP that is available but network operators are too short-term-focused and foolish to deploy it.

I believe the situation is more complicated than that, no? There is no "secure version of BGP". There are a handful of things that help, like RPKI ... but they are far off from hitting the mark of "securing the internet"... not too mention the ARIN RPKI SNAFU with various lawyers that make RPKI impossible for a large part of the internet.

CB

PS. All my ipv4 and ipv6 routes are RPKI signed, but I can't validate because Cisco does not think validation within a VRF is an IOS-XR worthy features

PPS. It does blow my mind that the internet works so well given that its security relies on the good faith and reputation of a few network janitors and plumbers

The issue here is that people treat routing security the same way as the Jennifer Anniston character in "Office Space" and her flair. People do the minimum to make it work and forget about it. This can have catastrophic effects if one does that with your sewers, septic fields, etc but we accept it in the BGP and routing universe for some reason. You even see that with the IRR data, people add and never remove. You can explore your objects here, you might be surprised how old they are or who is injecting garbage today. http://irrexplorer.nlnog.net/ at $dayjob we try to do the right thing and as a result see complaints from customers, prospects and even our vendors that what we do pushes their scale limits and capabilities. Gert asks if you enabled IPv6 on something today, (or did you turn IPv4 off soon I think will be a fair question). What have we (You!) done to improve routing security recently? Do we need a photo or t-shirt of randy bush saying “only you can prevent route hijackings?” - Jared

On Mon, Jun 1, 2015 at 8:21 AM, Mark Tinka <mark.tinka@seacom.mu> wrote:

On 1/Jun/15 17:04, Mike Hammett wrote:

...

Actually, that's the level of attention given to all kinds of infrastructure just about everywhere. ;-)

The difference is that there are standardized (global) guidelines for those infrastructures within their own industry, that lack of compliance can lead to serious fines, jail time or both.

A network operator unmaliciously screwing up their BGP configuration and taking one side of a continent out is unlikely to see any punishment beyond being fired by his employer, or losing his customers if self-employed.

Mark.

Also, the internet usually works pretty good-ish and the janitors clean up the messes pretty quick-ish. That said, i believe the BGP situation is completely hygienic relative to the DDoS issues going on that could be solved by BCP38 and otherwise fixing poorly admin'd DNS, NTP, CHARGEN, and SSDP nodes. The aforementioned janitors are pretty powerless on this front... and... various parties on all side are looking to cash in (booters on one side, web scrubbers on the other)... which is a very dangerous arms race with real money on both sides looking to escalate the harm / fix. CB

In message <CAD6AjGQWs-aKD8axgiRyaYXPB564MswKZsuaOUhjUn--KJXuUg@mail.gmail.com> , Ca By writes:

On Mon, Jun 1, 2015 at 8:21 AM, Mark Tinka <mark.tinka@seacom.mu> wrote:

...

On 1/Jun/15 17:04, Mike Hammett wrote:

...

Actually, that's the level of attention given to all kinds of infrastructure just about everywhere. ;-)

The difference is that there are standardized (global) guidelines for those infrastructures within their own industry, that lack of compliance can lead to serious fines, jail time or both.

A network operator unmaliciously screwing up their BGP configuration and taking one side of a continent out is unlikely to see any punishment beyond being fired by his employer, or losing his customers if self-employed.

Mark.

Also, the internet usually works pretty good-ish and the janitors clean up the messes pretty quick-ish.

That said, i believe the BGP situation is completely hygienic relative to the DDoS issues going on that could be solved by BCP38 and otherwise fixing poorly admin'd DNS, NTP, CHARGEN, and SSDP nodes. The aforementioned janitors are pretty powerless on this front... and... various parties on all side are looking to cash in (booters on one side, web scrubbers on the other)... which is a very dangerous arms race with real money on both sides looking to escalate the harm / fix.

If you have secure BGP deployed then you could extend the authenication to securely authenticate source addresses you emit and automate BCP38 filter generation and then you wouldn't have to worry about DNS, NTP, CHARGEN etc. reflecting spoofed traffic.

CB -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

the possibility of building a true 'Internet kill switch' with effects far beyond what various governmental bodies have managed to do so far in the DNS space.

Could you elaborate ? I don't see how it could be worse. Comparing with DNS is not relevant IMHO. Everyone is managing its own routing policy, not everyone is managing its own DNS root. Denis

Thus spake Roland Dobbins (rdobbins@arbor.net) on Tue, Jun 02, 2015 at 03:05:13PM +0700:

On 2 Jun 2015, at 11:07, Mark Andrews wrote:

...

If you have secure BGP deployed then you could extend the authenication to securely authenticate source addresses you emit and automate BCP38 filter generation and then you wouldn't have to worry about DNS, NTP, CHARGEN etc. reflecting spoofed traffic

This can be and is done by networks which originate routes and which practice good network hygiene, no PKI required.

But then we get into the customer of my customer (of my customer, of my customer . . .) problem, and this aren't quite so clear.

There are also potentially significant drawbacks to incorporating PKI into the routing space, including new potential DoS vectors against PKI-enabled routing elements, the potential for enumeration of routing elements, and the possibility of building a true 'Internet kill switch' with effects far beyond what various governmental bodies have managed to do so far in the DNS space.

Once governments figured out what the DNS was, they started to use it as a ban-hammer - what happens in a PKIed routing system once they figure out what BGP is?

But nobody seems to be discussing these potential drawbacks, very much.

Start here: https://www.cs.bu.edu/~goldbe/papers/hotRPKI_full.pdf Dale

On 3 Jun 2015, at 9:04, Ethan Katz-Bassett wrote:

The same folks also followed up that workshop paper with a longer paper on the topic: https://www.cs.bu.edu/~goldbe/papers/sigRPKI.pdf

Thanks to you and to Dale Carter - I was unaware of these papers. Nonetheless, the risk remains of authorities interfering with the BGP as they've interfered with the DNS. I'm very cognizant of the non-trivial effects of route-hijacking, having been involved in helping get a few of them resolved. Nonetheless, my natural skepticism leads me to wonder whether we aren't better off with the problematic, error-prone system we have (not to mention the enumeration and enhanced DDoS impact of packeting routers doing crypto for their BGP sessions and which aren't protected via iACLs/GTSM). ----------------------------------- Roland Dobbins <rdobbins@arbor.net>

On 5 Jun 2015, at 10:56, David Mandelberg wrote:

Could you elaborate on your enumeration and DDoS concerns?

Crypto = more overhead. Less priority to crypto plus DDoS = routing update issues. One can infer peering relationships in a way not possible before. What about bogus signatures? ----------------------------------- Roland Dobbins <rdobbins@arbor.net>

On Tue, 09 Jun 2015 19:09:45 -0400, David Mandelberg said:

I don't think there's an update issue here. The crypto verification is probably going to be deferred in addition to being low priority. If I understand it correctly, this means that a route can be passed along right away without waiting for the crypto checks.

Forward the route and then check it? Didn't we have a very amusing afternoon a number of years ago when $VENDOR did exactly that with some invalid routing data? Or am I mis-remembering history, and therefor doomed to mis-repeat it?

...

Crypto = more overhead. Less priority to crypto plus DDoS = routing update issues.

I don't think there's an update issue here. The crypto verification is probably going to be deferred in addition to being low priority. If I understand it correctly, this means that a route can be passed along right away without waiting for the crypto checks.

I don't think this quite fits with Postel's law... There's also the size of the table and the ability to pack (compress) the information to consider.

...

One can infer peering relationships in a way not possible before.

How?

The keys are per router, not per AS. You could use a single private/public key pair across the entire AS -- but that's not good security hygiene. There's no way to sign an update without exposing the signer; if you sign at anything below the AS level, you're exposing new information. What about the per NLRI timer? The timer is essentially the amount of time you'd like someone to be able to advertise a route once the peering session is broken. How long are you comfortable with someone advertising your routes after you've taken down your peering with them? What's the performance impact of forcing every route in the table to expire, say, every 24 hours? Given your cost of setting your timers to a few minutes or hours is nil (you're transferring the cost of your increased security onto "everyone else"), why not set it lower? Tragedy of the commons? I'm not saying BGPSEC a bad solution for the questions asked -- I'm saying it's is too heavyweight given the tradeoffs, and that we probably started with the wrong questions in the first place. What's needed is to spend some time thinking about what questions really need to be answered, the lowest cost way to answer those questions, and a complete examination of the tradeoffs involved. Is "what path did this update travel," or "are the BGP semantics being properly followed," really questions that want asking? Or are there other, more pertinent questions available? :-) Russ

rtfm. bgpsec key aggregation is at the descretion of the operator. they could use one key to cover 42 ASs.

I've been reading the presentations and the mailing lists, both of which imply you should use one key per router for security reasons. I would tend to agree with that assessment, BTW. Russ

folk have different threat models. yours (and mine) may be propagation of router compromise. for others, it might be a subtle increase in disclosure of router links. contrary to your original assertion, the protocol supports both.

The increased disclosure is not "subtle." The alternate -- deploying a new key to every eBGP speaker in your network while the security of all your routes is compromised, isn't so "subtle" either. It's a bad tradeoff in either direction -- typical of solutions that ask the wrong questions in the first place. Russ

There have been suggestions that a key-per-AS is easier to manage than a key-per-router, like in provisioning.

Two points -- First, if a single person with console access leaves the company, I must roll the key for all my BGP routes, with the attendant churn, etc. I can't imagine anyone deploying such a thing. Second, a secret only remains secret if two people know it, and one of them is dead -- a basic rule of security is prevent the spread of knowledge. If every person in the organization with console access knows the private key for every router in the network, it's no longer secret. So you can have one key pair per AS, and risk your security. Or you can add more key pairs, either per router, per POP, per region, or at some other level of granularity, and advertise more information about your network as well as make the key pair database larger. Either you weaken your security in one way, or you weaken your security in another. Doesn't sound like much of a "tradeoff" to me. What astounds me is the quietness on this list about this stuff... :-) Russ

On Thu, Jun 11, 2015 at 3:10 PM, David Mandelberg <david@mandelberg.org> wrote:

On 2015-06-11 07:30, Russ White wrote:

...

...

There have been suggestions that a key-per-AS is easier to manage than a key-per-router, like in provisioning.

Two points --

First, if a single person with console access leaves the company, I must roll the key for all my BGP routes, with the attendant churn, etc. I can't imagine anyone deploying such a thing.

I assume the vast majority of these cases are when the person leaves with no indication of malicious intent. In those cases, it might be possible to

it's actually nearly impossible to tell this... so the 'best' option is to do the changes required as quickly as is safe for your network. yes, it sucks... you know what sucks more? when 2 people leave on adjacent days.

Not liking the solution is not a reason to abandon the problem. This sounds like "I don't like eating right and exercising, so keeping my weight under control is the wrong question"

All protocols rely on certain assumptions of what the fields mean - when you send them and when you receive them. Analyzing a protocol for vulnerabilities starts with identifying what happens if those assumptions are broken. (Like the assumption in IP that the source address is the node

Two points. First, I did NOT say, "I don't like this." What I did say was technically precise, and, I think, perfectly clear. It's telling that the folks defending BGPSEC must immediately redirect the discussion into the side alleys of who "likes" what, and "rtfm," and "you can do this only it will cost you, so don't do that even though it's probably the right thing to do," straw man arguments, etc. Second, if you said, "If I eat one carrot a day, and I still can't keep my weight under control," you have some other problem than not being able to control your eating, and you might want to check into it a bit with a doctor. BGPSEC can eat one carrot a day and it's still too fat, IMHO -- it has a very high cost for some gain, counterbalanced by a slate of new risks and problems that must be solved. Again -- the ROI just isn't there. that

sent the packet - spoofing breaks that assumption.) Breaking the semantics creates attacks.

Sorry, Sandy, but this is a narrow view of security. The question is -- "what information is being transmitted, and how can it be validated (once you've actually defined validated?" One possible answer is, "by making certain the protocol's semantics are being followed." There are other possible answers to that questions, however. When your first attempt doesn't meet ROI, you don't ask the same questions -- you go back to the original requirements to see if you asked the right questions in the first place. To do anything else will quickly resolve to the insanity pattern. Russ

In message <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu>, "Dale W. Car der" writes:

Thus spake Roland Dobbins (rdobbins@arbor.net) on Tue, Jun 02, 2015 at 03:05: 13PM +0700:

...

On 2 Jun 2015, at 11:07, Mark Andrews wrote:

...

If you have secure BGP deployed then you could extend the authenication to securely authenticate source addresses you emit and automate BCP38 filter generation and then you wouldn't have to worry about DNS, NTP, CHARGEN etc. reflecting spoofed traffic

This can be and is done by networks which originate routes and which practice good network hygiene, no PKI required.

But it is a manual process or trust the information added to this database is correct. Automating the process even if it is only at the customer/isp edge were customer == isp is tagged as a exception would be a big win.

...

But then we get into the customer of my customer (of my customer, of my customer . . .) problem, and this aren't quite so clear.

There are also potentially significant drawbacks to incorporating PKI into the routing space, including new potential DoS vectors against PKI-enabled routing elements, the potential for enumeration of routing elements, and th e possibility of building a true 'Internet kill switch' with effects far beyond what various governmental bodies have managed to do so far in the DN S space.

Yes, there are trade offs. As for that "Internet kill switch", ISP could theoretically be ordered to block all traffic to a prefix. I know that this is theoretically possible today with Australian legistation and basically has been since the very begining as it is in the telecomunication acts.

...

Once governments figured out what the DNS was, they started to use it as a ban-hammer - what happens in a PKIed routing system once they figure out what BGP is?

But nobody seems to be discussing these potential drawbacks, very much.

Start here: https://www.cs.bu.edu/~goldbe/papers/hotRPKI_full.pdf

Dale -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On 1 Jun 2015, at 22:21, Mark Tinka wrote:

The difference is that there are standardized (global) guidelines for those infrastructures within their own industry, that lack of compliance can lead to serious fines, jail time or both.

1. Ensuring insurance underwriters understand the amount of unsecured risk they have, and working with them to develop the *verifiable* checklists they should be going through before they write 'cyber-' policies. 2. Working with ISO to develop relevant outcome-based standards (e.g., not what you type into your config, but rather the desired result, such as source address validation, detection/classification/traceback/mitigation capabilities, et. al.). 3. Working with regulatory bodies in various regulated verticals to require aforementioned ISOs, same with insurance companies serving those industries (this will have an ink-blot effect reaching down into their supply/service chains). 4. Working with governmental bodies to require aforementioned ISOs in the regulated industries. 5. Working with PCI/DSS to add an availability component, as well as all relevant integrity BCPs. 6. Adding outcome-based requirements surrounding all the relevant BCPs to peering/transit agreements, getting regulators and governments to require same. I really think the insurance industry is going to be the best/easiest route to take (pardon the pun); this has the advantage of not requiring further governmental regulation, and does offer a market-based solution. I know Bill Woodcock has some experience in this general arena. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>

Yes, RPKI protects from fat fingered people, but NOT protects from people doing hijacks knowingly.

the rpki protects from fat fingers as well as the telephone white pages protects from wrong number dialing. it doesn't. for the 312th time (i had to make this clear once again from the floor of nanog this week), ... The RPKI is an X.509 based hierarchy [rfc 6481] which is congruent with the internet IP address allocation administration, the IANA, RIRS, ISPs, ... It is just a database, but is the substrate on which the next two mechanisms are based. It is currently deployed in all five administrative regions. RPKI-based Origin Validation [RFC 6811] uses some of the RPKI data to allow a router to verify that the autonomous system originating an IP address prefix is in fact authorized to do so. This is not crypto checked so can be violated. But it should prevent the vast majority of accidental 'hijackings' on the internet today, e.g. the famous Pakistani accidental announcement of YouTube's address space. RPKI-based origin validation is in shipping code from AlcaLu, Cisco, Juniper, and possibly others. RPKI-based Path Validation, a future technology still being designed [draft-ietf-sidr-bgpsec-overview-06.txt], uses the full crypto information of the RPKI to make up for the embarrassing mistake that, like much of the internet BGP was designed with no thought to securing the BGP protocol itself from being gamed/violated. It allows a receiver of a BGP announcement to cryptographically validate that the autonomous systems through which the announcement passed were indeed those which the sender/forwarder at each hop intended. randy