[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[safnog] RPKI discussions

On 12/Apr/15 09:33, Frank Habicht wrote:

> 2. So how was it noticed that this (invalid) more specific was announced?
> Did some networks accept it?
> Oh no! Wasn't this RPKI thing so that mis-originations are not accepted?
> That's why I asked, and only one person in the meeting said he did not
> accept this prefix. Thanks Nishal. But I'm not sure we can call this a
> "network" that was dropping that prefix, can we?
>
> So I'd like to say: this whole local-pref reduction is good for what....?
> Seems to me like the prefixes still make it everywhere they want to go,
> upstream, downstream, RIB, FIB, ...
>
> Is it for testing?
> pro-bono bug chasing for the vendors?
> Or is this a case of false advertising?
>
> I have to admit that i don't know enough about RPKI, so i might be
> missing something. Looking forward to being educated.

So we run RPKI at SEACOM, although we've had to disable it on 64-bit IOS
XE due to a bug in BGP that is triggered by RPKI, causing the box to
crash (the issue is not present in 32-bit IOS, nor is it present in IOS XR).

We use BGPmon to tell us which of our prefixes is coming up with an
Invalid RPKI flag. In our case, we have one IPv6 one which is a /48
originated from a legacy router that will be going away this week, as we
do not de-aggregate. So we have not bothered to create a ROA for that
/48, as all our IPv4 and IPv6 aggregates have ROA's created for them.

The BGPmon output for that example is below:

**************************

You received this email because you are subscribed to BGPmon.net.
For more details about these updates please visit:
https://portal.bgpmon.net/myalerts.php

====================================================================
RPKI Validation Failed (Code: 9)
====================================================================
Your prefix:          2c0f:feb1::/32: 
Prefix Description:   SEACOM-NETv6 
Update time:          2015-04-12 05:03 (UTC)
Detected by #peers:   5
Detected prefix:      2c0f:feb1:99::/48 
Announced by:         AS37100 (SEACOM-AS,MU)
Upstream AS:          AS6939 (HURRICANE - Hurricane Electric, Inc.,US)
ASpath:               200155 6830 6939 37100 
Alert details:        https://portal.bgpmon.net/alerts.php?details&alert_id=52159419
Mark as false alert:  https://portal.bgpmon.net/fp.php?aid=52159419
RPKI Status:          ROA validation failed: Invalid Prefix-Length 


 
--------------------------------------------------------------
 *for questions regarding the change code or other question, please see:
https://portal.bgpmon.net/faq.php


Latest BGPmon news: http://bgpmon.net/blog/
  * BGP Optimizer Causes Thousands Of Fake Routes
  * BGPMon Joins OpenDNS
  * What caused the Google service interruption?

*********************************************

2c0f:feb1::/32 has a ROA, but the /48 de-aggregate you see there does
not. Hence the alarm from BGPmon.  At any rate, we shall take away the
legacy box which has been originating this /48, so this alarm will stop
this week.

Another place that you can freely check the RPKI state of prefixes is
http://bgp.he.net/, in addition to the various validation looking
glasses ran by the RIR's and others.

We initially decided to drop Invalids, otherwise what's the point of
RPKI, yes? While a noble gesture toward the project, it proved
impractical because over 99% of the Invalids were not mis-origination;
they were un-ROA'd de-aggregates. This, of course, had operational
impact to many of our downstream BGP customers, hence our desire to stop
dropping Invalids.

For us, setting a lower LOCAL_PREF for Invalids has no practical value.
So we just stopped acting on RPKI state altogether (and yes, the BGP
RPKI bug did not help either, although this was unique to Cisco).

Given much of the Internet are not implementing RPKI yet, and are not
keen to take the risk to drop Invalids, it has been as slow a start as
IPv6 and DNSSEC. So for now, yes, this could be pro bono chasing of
vendor bugs, which is not an entirely bad thing. For example, in IOS and
IOS XE, the RPKI code automatically applies policy to the default state
of all routes, i.e., Uknown, Invalid or Valid. This, of course, goes
against the spec. which clearly states that policy can only be applied
by the operator, and not by the router itself. A case of Cisco trying to
"plug & play", most certainly. Suffice it to say, because we found this
issue and made noise on the SIDR IETF list, it has now been fixed in
newer code.

In summary - go ahead and do it, if not to get a head start.


>
>
> I'd like to conclude with thanks to Ali and everyone involved for
> organising such a great event!

It was good fun, eh :-)...

Mark.