"Is BGP safe yet?" test

Mailman List Mirror (Read Only)
41

essentially agree. my pedantic quibble is that i would like to
differentiate between the RPKI, which is a database, and ROV, which
uses it.

And I think that is a very important distinction to be clear about.
Right now, it's not completely arrest-worthy to use RPKI and ROV
interchangeably, but I think considering that other use-cases might
come from the database itself in the future, being explicit about it
and how it can be used is appropriate pedantry.

i have been pushing this rock uphill for over a decade. to expand, a
bit of text from long ago, so hence a bit out of date, but still clear

    RPKI

    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 (ROV)

    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.

    BGPsec

    RPKI-based Path Validation, AKA BGPsec, a future technology still
    being designed [draft-ietf-sidr-bgpsec-overview], 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.

currently, bgosec still has no traction. there are other proposals in
the space, e.g. ASPA. but the point is that they USE the rpki, they are
not the rpki.

randy

42

That’s an interesting idea. I’m not sure that LACNIC would want to issue a ROA for RIPE IP space after RIPE issues an AS0 ROA, though. And you’d at least need some kind of time delay to give other RIRs and operators and chance to discuss the matter before allowing RIPE to issue the AS0 ROA, eg in my example mitigation strategy.

43

Right until RIPE finishes deploying AS0 ROAs for bogons, which I recall is moving forward :p.

44

Not sure how this helps? If RIPE (or a government official/court) decides the sanctions against Iranian LIRs prevents them from issuing number resources to said LIRs, they would just remove the delegation. They’d probably then issue an AS0 ROA to replace out given the “AS0 ROA for bogons” policy. In an hour or so these LIRs are now disconnected from the world.

45

Not sure how this helps? If RIPE (or a government official/court) decides the sanctions against Iranian LIRs prevents them from issuing number resources to said LIRs, they would just remove the delegation. They’d probably then issue an AS0 ROA to replace out given the “AS0 ROA for bogons” policy. In an hour or so these LIRs are now disconnected from the world.

1) there are other ways the black helicopter people can do their
business, this is but one new lever.
2) this is the sort of thing that local TAL / SLURM are meant to help 'fix'.
3) see the long discussions of this in the sidr/sidr-ops wg lists :frowning:

46

All 5 RIRs can issue ROAs for all the IP address spaces. They don’t as a matter of coordinated operations, but that doesn’t prevent court orders determining that to be done.

Rubens

47

Sure. This kinda falls under my point that we should be talking about basic mitigation, then. I’m not aware of any previous discussion of creating policy that instructs RIRs to do so. Again, with a basic step like that, plus a validator-enforced time delay between when a RIR can remove a ROA for some IP space and when it can be replaced, RPKI would be drastically de-risked. Once you start going down that road, there would be way more desire on the part of OFAC and other small committees to enforce policy using other levers.

48

Baldur Norddahl писал 2020-04-21 02:49:

My company is in Europe. Lets say an attacker joins the IX in Seattle
a long way from here and a place we definitely are not present at. We
do however use Hurricane Electric as transit and they are peering
freely at Seattle. Everyone there thus sees our prefix with an as path
length of two. The attacker can originate the prefixes himself and
that way his fake announcements win at Seattle by having the length 1.
With RPKI he needs to use our ASN to originate and have his own ASN in
between to facilitate peering. Thus the fake path also has the length
of two. The real announcement wins by virtue of being the oldest
announcement and the attack fails.

The situation is even worse for the attacker if he needs an IP transit
company to pick up the fake announcement. We have Telia, which filters
invalids, and if the attacker tries to get his fake prefix picked up
by them, his path will end up being one longer than ours, so he can
never succeed.

There are of course plenty of situations where the attack still
succeeds. I am not claiming this is a magical bullet. Just saying it
might do more than some thinks it will. Definitely better than
nothing.

I think that for peering sessions regular filters can do their job more directly and effectively. But I see that discussion moved away from initial topic to general dispute about RPKI usefullness. The initial topic though initially was about public web page that claimes your network secure or insecure based on evaluation of only one technology checking one particular specially crafted prefix.

Kind regards,
Andrey

49

From: "Andrey Kostin" <ankost@podolsk.ru>

Would be interesting to hear your opinion on this:
https://isbgpsafeyet.com/

We have cases when residential customers ask support "why is your
service isn't safe?" pointing to that article. It's difficult to answer
correctly considering that the asking person usually doesn't know what
BGP is and what it's used for, save for understanding it's function,
design and possible misuses.

Well, given how little the BCP38 website below has moved that football, you're
not likely in much danger... :slight_smile:

Cheers,
-- jra

50

Or a miscreant. [insert-least-favorite-rir] is now part of your attack surface.

-danny

51

Jay R. Ashworth писал 2020-04-22 11:02:

Well, given how little the BCP38 website below has moved that football, you're
not likely in much danger... :slight_smile:

Cheers,
-- jra

BCP38 website doesn't proclaim anybody in person to be unsafe, but if it would be possible to make such test it'd be more useful than that RPKI test.

BTW, has anybody yet thought/looked into extending RPKI-RTR protocol for validation of prefixes received from peer-as to make ingress filtering more dynamic and move away prefix filters from the routers?

Kind regards,
Andrey

52

Do you really want those things in soft-state and not with some giant operational buffer to absorb all the brokenness that's sure to arise?

-danny

53

a question about the data types here...
So, a neighbor with no downstream ASN could be filtered directly with
ROA == prefixlist-content.
A neighbor with a downstream ASN has to be ROA (per asn downstream) ==
prefixlist-content.

So you'd now have to do some calculations which are more complicated
than just; "is roa for this prefix here and valid" to construct a
prefix-list.
correct?

54

Sorry, and this sidesteps the intent of the peer as well. For instance
you may have
a peer with 2 'downstream' asn, only 1 of which they wish to provide
transit to you
(from you?) for... how would you know this intent/policy from the
peer's perspective?
today you know that (most likely) from IRR data.

is your answer ASPA / AS-Cone ?

55

>
>> That’s an interesting idea. I’m not sure that LACNIC would want
>> to issue a ROA for RIPE IP space after RIPE issues an AS0 ROA,
>> though. And you’d at least need some kind of time delay to give
>> other RIRs and operators and chance to discuss the matter before
>> allowing RIPE to issue the AS0 ROA, eg in my example mitigation
>> strategy.
>
> All 5 RIRs can issue ROAs for all the IP address spaces. They don't as
> a matter of coordinated operations, but that doesn't prevent court
> orders determining that to be done.

Or a miscreant. [insert-least-favorite-rir] is now part of your attack
surface.

Or a slip of the keyboard / software ooops / mistake -- but, in spite
of this, I think that RPKI / ROAs / ROV is a good thing; as with
everything, this is an engineering trade off, and to me this feels
well worth it...

I do think that CloudFlare does some great things for the Internet -
they've moved DNSSEC forward immensely, significantly increased the
adoption of HTTPS/TLS, the OctoRPKI/GoRTR stuff is nice and easy,
their hosted RPKI cache, etc -- but their marketing pushes like this
feel overly aggressive.

W

56

❦ 22 avril 2020 12:51 -04, Andrey Kostin:

BTW, has anybody yet thought/looked into extending RPKI-RTR protocol
for validation of prefixes received from peer-as to make ingress
filtering more dynamic and move away prefix filters from the routers?

It could be used as is if the client implementations were a bit more
flexible.

With BIRD, you decide which AS to match. So you can match on the
neighbor AS instead of the origin AS. Then, you can use something like
GoRTR which accepts using JSON files instead of the RPKI as source. BIRD
also allows you to have several ROA tables. So, you can check against
the "real" RPKI as well as against your custom IRR-based RPKI.

57

Christopher Morrow писал 2020-04-22 14:05:

a question about the data types here...
So, a neighbor with no downstream ASN could be filtered directly with
ROA == prefixlist-content.
A neighbor with a downstream ASN has to be ROA (per asn downstream) ==
prefixlist-content.

So you'd now have to do some calculations which are more complicated
than just; "is roa for this prefix here and valid" to construct a
prefix-list.
correct?

Sorry, and this sidesteps the intent of the peer as well. For instance
you may have
a peer with 2 'downstream' asn, only 1 of which they wish to provide
transit to you
(from you?) for... how would you know this intent/policy from the
peer's perspective?
today you know that (most likely) from IRR data.

is your answer ASPA / AS-Cone ?

ASPA/As-Cone is a concept about whole as-path verification afaik, but I may be mistaken.
ROA validation prevents hijacking but doesn't prevent route-leaks. If my transit providers already do ROV, effect of doing it in local network will be limited to direct peers only and expected to be considerably small. For route-leaks prevention we still have to rely on IRR and filters configured directly on routers. Maintaining filters on routers is quite intensive task and they took a lot of space in the configuration. Adopting validation or similar mechanism for it could make it more dynamic and less resources-consuming. Or maybe I'm trying to invent a bicycle?

Kind regards,
Andrey

58

Vincent Bernat писал 2020-04-22 15:26:

❦ 22 avril 2020 12:51 -04, Andrey Kostin:

BTW, has anybody yet thought/looked into extending RPKI-RTR protocol
for validation of prefixes received from peer-as to make ingress
filtering more dynamic and move away prefix filters from the routers?

It could be used as is if the client implementations were a bit more
flexible.

With BIRD, you decide which AS to match. So you can match on the
neighbor AS instead of the origin AS. Then, you can use something like
GoRTR which accepts using JSON files instead of the RPKI as source. BIRD
also allows you to have several ROA tables. So, you can check against
the "real" RPKI as well as against your custom IRR-based RPKI.

That's what I meant. So I guess IX operators already can use BIRD on route-servers for prefix filtering. I think it could be useful on hw routers as well.

Kind regards,
Andrey