Hi Gert, Job, routing-wg, Disclaimer: I'm not offering a solution, just a possibility, facilitator hat on. In the context of the upcoming RIPE+iNOG Network Operator Tools hackathon in June (details at https://labs.ripe.net/Members/ becha/join-network-operators-tools-hackathon ), I would say that this would make for a great project proposal (an improvement for an existing RIPE tool / NLNOG Ring / standalone tool etc.). Of course the best option would be to join us and hack on it in person - but if that doesn't fly, formulate a proposal and either find an advocate who's attending or send it to me as a proxy of last resort. Cheers, Cristian -- Cristian Sirbu www.trueneutral.eu | inog.net | twitter.com/cmsirbu *PGP* 2C940C28 08F2378F 45C74E11 8AFA4E29 *710D0D66* On Tue, May 1, 2018 at 7:53 PM, Job Snijders <job@ntt.net> wrote:

Dear Gert,

On Tue, May 01, 2018 at 08:44:22PM +0200, Gert Doering wrote:

...

is there an online looking glass to see RPKI status for ``everything a given AS announces / transits''?

Say, I want to check my AS (AS5539) plus all downstream customers (... visible at the vantage point of said tool, of course).

I have found whois.bgpmon.net, which I can use by feeding prefix after prefix into whois and then parsing the reply, but that's a bit cumbersome for "give me all there is to know". Basically

show ip bgp reg _5539_

I ran a terrible one-off for you on lg01.infra.ring.nlnog.net:

$ birdc 'show route where bgp_path ~ [= * 5539 * =] primary all' | egrep "unreach|ext_comm" | sed 's/unreach.*//' | paste - - | sed 's/0x1./not-found/;s/0x0./valid/;s/0x2./invalid/' 109.230.244.0/23 BGP.ext_community: (generic, 0x43000000, not-found 194.97.64.0/19 BGP.ext_community: (generic, 0x43000000, valid 185.5.184.0/23 BGP.ext_community: (generic, 0x43000000, not-found 185.54.120.0/22 BGP.ext_community: (generic, 0x43000000, valid 194.39.121.0/24 BGP.ext_community: (generic, 0x43000000, not-found 149.62.56.0/21 BGP.ext_community: (generic, 0x43000000, not-found 193.189.94.0/24 BGP.ext_community: (generic, 0x43000000, not-found 193.189.94.0/23 BGP.ext_community: (generic, 0x43000000, not-found 31.214.222.0/23 BGP.ext_community: (generic, 0x43000000, not-found 91.223.129.0/24 BGP.ext_community: (generic, 0x43000000, not-found 82.118.35.0/24 BGP.ext_community: (generic, 0x43000000, invalid 82.118.32.0/19 BGP.ext_community: (generic, 0x43000000, valid 193.151.47.0/24 BGP.ext_community: (generic, 0x43000000, not-found 193.149.32.0/19 BGP.ext_community: (generic, 0x43000000, valid 195.30.0.0/16 BGP.ext_community: (generic, 0x43000000, valid 185.143.68.0/23 BGP.ext_community: (generic, 0x43000000, not-found 195.24.96.0/19 BGP.ext_community: (generic, 0x43000000, valid 193.97.129.0/24 BGP.ext_community: (generic, 0x43000000, not-found 194.97.128.0/19 BGP.ext_community: (generic, 0x43000000, valid

$ birdc6 'show route where bgp_path ~ [= * 5539 * =] primary all' | egrep "unreach|ext_comm" | sed 's/unreach.*//' | paste - - | sed 's/0x1./not-found/;s/0x0./valid/;s/0x2./invalid/' 2a07:3340::/48 BGP.ext_community: (generic, 0x43000000, not-found 2001:608::/32 BGP.ext_community: (generic, 0x43000000, valid 2a02:7c40::/33 BGP.ext_community: (generic, 0x43000000, not-found 2001:4150::/32 BGP.ext_community: (generic, 0x43000000, valid 2001:67c:158c::/48 BGP.ext_community: (generic, 0x43000000, valid

...

and then for each prefix returned, check RPKI status, flag green/red/yellow.

The RIPE LIRportal RPKI dashboard sort of does the job for all ASes that I have created ROAs for (so, if I maintain my customer ROAs, I would see them) but I cannot query an arbitrary AS, or "the whole customer cone".

(I expected RIPE Stats to have something like this in the BGP widget, but to my surprise, no...)

A while back I injected RPKI steroids into http://lg.ring.nlnog.net/ so that it displays the "RPKI Origin Validation State" for each prefix it displays.

This doesn't allow you to do 'show ip bgp reg _5539_' as you requested, but that is something I can consider building into the thing.

Kind regards,

Job

-- Cristian Sirbu www.trueneutral.eu | inog.net | twitter.com/cmsirbu *PGP* 2C940C28 08F2378F 45C74E11 8AFA4E29 *710D0D66*

Hi, On Tue, May 01, 2018 at 03:33:22PM -0400, Jay Borkenhagen wrote:

I know it's not precisely what you were asking for, but RPKI origin validation is configured on our route-server.ip.att.net, freely accessible via telnet.

You could run something like:

show route aspath-regex ".*5539.*" terse active-path | match /

I just ran that command and I see some prefixes validating in all three categories: Valid, Invalid, and Not Found.

Thanks, this is also useful information.

Of course, this method is influenced significantly by how the as7018 network learns routes that pass through as5539: if our best path to some destination does not come via 5539, it won't show up using this method.

Indeed :-) The information I was looking for is nicely visible, though... and what I was afraid I'd see... too much "N". The only "I" is something I was aware but had forgotten about ;-) - a sink-a-more-specific-/24 test that nicely exposes the problem of "strict /22" ROAs. thanks! Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hi, On Wed, May 02, 2018 at 06:11:23PM +0000, Job Snijders wrote:

On Wed, May 02, 2018 at 08:07:16PM +0200, Gert Doering wrote:

...

The information I was looking for is nicely visible, though... and what I was afraid I'd see... too much "N". The only "I" is something I was aware but had forgotten about ;-) - a sink-a-more-specific-/24 test that nicely exposes the problem of "strict /22" ROAs.

"problem" - just create a separate additional ROA for the /24!

I should have worded this as "the issue you run into if you create a single ROA with a fixed length *and* then decide to announce something else" - and indeed, since MaxLength opens room for spoofed-source-with-more-specific hijacks, this is why we set up our ROAs strictly.

I recommend to make separate ROAs for everything you announce in BGP. The use of MaxLength is easily abused. See this Internet-Draft for more considerations:

https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen

How would you recommend handling the case "normally I only announce a /16, but in case one of our customers i DDoSed, I want to announce the affected IP address as part of their /24 out of upstream-that-does-regional-blackholing"? If I create the /24 ROAs up front, I'm back in square one ("while I am not announcing the /24, someone else could hijack with a faked origin AS"). If I do not create the /24 ROAs up front, I have propagation delays (and might not be able to reach the RIPE RPKI tool at all while the DDoS goes on). *scratch head* Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

On Wed, 2 May 2018, Job Snijders wrote:

...

How would you recommend handling the case

"normally I only announce a /16, but in case one of our customers i DDoSed, I want to announce the affected IP address as part of their /24 out of upstream-that-does-regional-blackholing"?

If I create the /24 ROAs up front, I'm back in square one ("while I am not announcing the /24, someone else could hijack with a faked origin AS").

If I do not create the /24 ROAs up front, I have propagation delays (and might not be able to reach the RIPE RPKI tool at all while the DDoS goes on).

*scratch head*

If your DDoS mitigator depends on BGP hijacking to deliver their scrubbing services to you ... indeed you'll have challenges. I have no good answer, this is an architectural flaw where one has to make a trade-off between wanting to protect against hijacks and having the ability to insert more-specifics for legitimate purposes.

RPKI origin validation does not protect against path manipulation. Even if you announcing the /24, someone else could hijack with a faked origin A. It just gets more difficult because there are competing announcements. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl

On Wed, 2 May 2018, Job Snijders wrote:

...

...

...

*scratch head*

If your DDoS mitigator depends on BGP hijacking to deliver their scrubbing services to you ... indeed you'll have challenges. I have no good answer, this is an architectural flaw where one has to make a trade-off between wanting to protect against hijacks and having the ability to insert more-specifics for legitimate purposes.

RPKI origin validation does not protect against path manipulation.

Even if you announcing the /24, someone else could hijack with a faked origin A. It just gets more difficult because there are competing announcements.

For path validation there are other tricks!

yeah ... my point was that the previous discussion was a bit misleading. If you want that ROAs comply only with the current BGP annoucements, you have to deal with a (ROA) delay when you change the origins. If you want that ROAs comply with potential BGP annoucements, you should create the /24. It's not such a head scratching decision.

It is a bit of a poor man's solution, but so much better than nothing. It only protects a subset of all ASNs, but combined with RPKI Origin Validation this would be extremely effective.

https://www.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pd... https://www.youtube.com/watch?v=CSLpWBrHy10

Thanks for the pointers. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl

On May 2, 2018, at 2:29 PM, Job Snijders <job@ntt.net> wrote:

If your DDoS mitigator depends on BGP hijacking to deliver their scrubbing services to you ... indeed you'll have challenges. I have no good answer, this is an architectural flaw where one has to make a trade-off between wanting to protect against hijacks and having the ability to insert more-specifics for legitimate purposes.

The DDoS mitigator might try announcing the affected prefix’s more specific, faking the legitimate origin’s AS as the origin. If BGPSec is not around to protect the path, it would work/help. (I think this is what Matthias was saying, also, which makes this a +1.) Also - current best practice to protect origination is to use route filters based on some IRR or the other. In the current world, the DDoS mitigator has the same problem - to authoritatively originate the affected more specific prefix, the mitigator has to wait for propagation from the IRR. I’ve been told one strategy is to have a large collection of peers who understand that they should be forgiving of the announcements from the mitigator. [And the bad-guys know this as well. Lots of cases where the mis-origination is registered in some IRR or the other. And in some cases, the explanation from the embarrassed upstream of the mis-originator was that they were told the mis-originator was a DDoS mitigator.] That same large-number-of-very-understanding-peers strategy works for DDoS mitigation in an RPKI OV world. I’m not advocating that strategy, by the way. —Sandy

Some providers can siphon off the victim IP addresses to scrubber devices within the confines of the autonomous system - and the outside world (the DFZ) never sees these more-specifics.

Hi, On Wed, May 02, 2018 at 11:18:08AM +0200, Tim Bruijnzeels wrote:

If it???s just origin you???re after then this may help: http://localcert.ripe.net:8088/bgp-preview

This is cool :-) (It does not do "give me the full customer cone of AS <X>", but since the ASes I'm interested in rightn ow only have a few customer ASes anyway, it's definitely good enough)

This ???BGP Preview??? page lists the announcements seen by RIS Route Collectors, does the RPKI analysis, and let???s you filter by IP or ASN as you wish. It does not do any AS path inspection.

It's definitely nice. And FAST! [..]

Also, you may know that we are getting very close now to releasing the RPKI Validator 3.0. We are currently dealing with some minor last issue (related to rpki-rtr and BGPSec keys) but we will have an official pre-production release ready before RIPE 76 and I plan to present it during the Opensource WG. The 3.0 version has a similar BGP Preview page. If you already want to give it a spin you can find a link to the beta releases on GitHub, and please let us know if you find any issues :)

https://github.com/RIPE-NCC/rpki-validator-3/wiki/RIPE-NCC-RPKI-Validator-3-...

Not promising anything right now, a bit busy... but thanks for the link. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Dear Gert & routing-wg list, The first RPKI validation data call is available on RIPEstat. It simply allows to get the validation status of an AS and prefix, given as arguments. Please find the detailed documentation here: https://stat.ripe.net/docs/data_api#RPKI In action: https://stat.ripe.net/data/rpki-validation/data.json?resource=AS3333&prefix=2001:67c:2e8::/48 This data call is released as a test as we want to first get a feeling for the demand but more features related to RPKI will be implemented if requested. Cheers, Christian Christian Teuschel | Human behind RIPEstat Follow me on Twitter: @NCC_RIPEstat On 08/05/2018 14:30, Christian Teuschel wrote:

Hi all,

After looking into the requirements and checking on what is already available, I believe we can start out with a simple validation check for a given prefix and ASN, which will be available as a RIPEstat Data API call. From there we can take it further and implement more sophisticated applications, e.g. generation of a prefix list for a set of ASNs.

ETA for a beta version will be before the end of this month.

Cheers, Christian

On 03/05/2018 14:58, Christian Teuschel wrote:

...

Hi Gert,

On 01/05/2018 20:44, Gert Doering wrote:

...

(I expected RIPE Stats to have something like this in the BGP widget, but to my surprise, no...)

I have to admit that this has been lingering on my todo list for quite some time and I don't want to delay it any further. Tomorrow I will look into what it takes to provide at least a simple prefix-for-AS valid/not valid data call. Please expect a follow-up soon!

---

Kind regards, Christian

Christian Teuschel | Human behind RIPEstat Follow me on Twitter: @NCC_RIPEstat