BGP in the Washngton Post

Mailman List Mirror (Read Only)
21

Thus spake Roland Dobbins (rdobbins@arbor.net) on Tue, Jun 02, 2015 at 03:05:
13PM +0700:
>
>
> >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.

22

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

23

Hijacking this thread. I've requested both our main vendors for 'loose rpki'
years ago, nothing has happened.
SP trying to deploy RPKI may have negative business impact, if far-end
fat-fingers and fail RPKI, then my connectivity to them is broken, while
competitor who isn't running RPKI still works fine. Essentially suits may view
deploying RPKI as spending money to lose money.

Comfortable slow-start would be to have 'loose rpki' which essentially has 3
adj-ribs, verified-rpki, missing-rpki, failed-rpki. Then loc-rib is build from
each of these, so that no overlapping routes are installed from inferior ribs.
That is, if verified-rpki has 192.0.2.0/24, missing/failed-rpki cannot install
it or more-specific of it.

Net result is, we will always use verified-rpki route if existing, but if no
other options exist, we're happy to use any available route.

JunOS allows routing-policy to match on verified status, but this cannot
obviously override more-specifics.

24

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

25

I don't believe this is entirely true, and BGPSEC certainly doesn't solve most of what I'm concerned about from a routing security perspective. See, e.g.:

https://tools.ietf.org/html/draft-ietf-grow-simple-leak-attack-bgpsec-no-help-04

That said, a Internet number resource certification infrastructure, be it RPKI or something with s single root and scalable(!), is certainly necessary, and can be used to bootstrap policy databases (e.g., IRRs) that address both the inter-domain routing (e.g., origin "validation") and data plane anti-spoofing security problems, and perhaps not require operators (enterprises and nation states alike) to trade the autonomy and flexibility they have in routing today for what others see as their infrastructure security needs.

After all, stability, resiliency, and availability are ALSO factors in the risk management gumbo that need to be considered by organizations, and the tight coupling of RPKI and BGPSEC as designed, are quite possibly not as attractive to some operators as the designers might suggest, particularly in light of new external dependencies, competitive markets, Internet governance, geopolitical climate, etc..

Many that haven't deployed or have lost interest in having the conversation have done so deliberately, and would prefer a routing by rumor paradigm that affords autonomy and flexibility to one where new control points and exorbitant costs and complexity simply scare the heck out of them, the primitives of which surely extend to many of the luminaries quoted in those articles.

YMMV,

-danny

26

Could you elaborate on your enumeration and DDoS concerns? If you're
concerned about the public finding out exactly how many routers you have
because you've published one BGPsec router key per router, you can
choose to use the same router key on multiple routers. If you're
concerned about all the crypto work overloading a router, the plan (as
far as I've heard) is for the routers to do the BGPsec crypto work in
the background as a low priority. I.e., incoming signed routes will
initially be treated like unsigned routes, and the BGPsec validation
will be kicked off in the background. Once the validation is complete,
then routing decisions can be made based on the BGPsec validity.

27

And a different set of folks (including me) are working on a different
mechanism to protect against attacks from on high. Any feedback would be
appreciated.

https://tools.ietf.org/html/draft-kent-sidr-suspenders-03

28

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?

29

Could you elaborate on your enumeration and DDoS concerns?

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.

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

How?

What about bogus signatures?

If I understand correctly, these routes (and all newly received routes) will initially be treated similarly to unsigned routes. Once BGPsec validation completes, then local policy determines what to do with the validation results.

30

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?

31

Actually, it was collusion. $VENDOR-A forwarded the bad data all over, and every
$VENDOR-B router that saw it went walkies...

It's the memory that goes first. I can't remember what goes second....

32

> 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?

:slight_smile:

Russ

33

The keys are per router, not per AS.

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

randy

34

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

35

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.

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.

randy

36

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

37

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 that sent the packet - spoofing breaks that assumption.) Breaking the semantics creates attacks.

--Sandy

38

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

Key-per-router was brought up as providing the means to excise one misbehaving router that is in some risky sort of environment, which is a different management pain.

In terms of security, from outside the AS, you are basing your decisions on your trust in the AS in the key-per-AS case, and you are basing your decisions on your trust in the AS that certified the router in the key-per-router case.

The local operator's environment and policy rule in choosing the technique.

The draft draft-ietf-sidr-bgpsec-ops-05 says:

   A site/operator MAY use a single certificate/key in all their
   routers, one certificate/key per router, or any granularity in
   between.

--Sandy

39

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"

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.

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

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

40

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

:slight_smile:

Russ