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

[safnog] RPKI discussions

Hi all,

Thanks for starting the conversation Frank, and Mark for your input.
This is one of those areas where it's vital that we understand how each other is implementing a technology, so that we can all accurately predict the behaviour of the routing system.
At Workonline, we're still at the point of evaluating validation server code (and I'd be keen to hear any experience on that), although we have all our ROAs registered (and hopefully correct).
We run a fair few XE boxes too, so would love that Bug ID if you have it Mark?
Our short term plan is to de-PREF invalids and to mark prefixes with a validation status community for export. The community gives our customers the option of filtering without needing to re-validate. The lower LOCAL_PREF is of pretty limited value as you've both pointed out, but does give a highjacked remote network a means of fighting back reactively (even if that requires them to temporarily loose a bunch of more specifics).
All of this of course protects only from the very least sophisticated attacks/accidents, but it is a start. Anything that doesn't provide for path validation is less than half a solution anyway.
Looking forward to Windhoek already :-)

Cheers,

Ben Maddison

Director
Workonline Communications (Pty) Ltd

Office:???? 021 200 9000
Fax:???????? 086 614 2342
Cell:??????? +27 (0) 82?415 5545
Email:????? benmaddison at workonline.co.za
SIP:	sip:benm at workonline.co.za

?



-----Original Message-----
From: Mark Tinka [mailto:mark.tinka at seacom.mu] 
Sent: 12 April 2015 10:50 AM
To: Frank Habicht; safnog at safnog.org
Subject: Re: [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.


_______________________________________________
safnog mailing list
safnog at safnog.org
http://lists.safnog.org/listinfo/safnog