Subject: [Sidrops] Path validation with RPKI

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Jun 2019 12:36:37 +0200

Dear secure interdomain routing operators,

I've been away from the IETF for a while, and I'm new to this mailing list, so I'm not up to date with what's been happening here. I'm not going to let that stop me  :-)  but apologies if I retread worn out paths.

Also, I'm not sure if this work ultimately fits this wg, but I think this is the right place for an initial discussion. I'm also starting this discussion on the RIPE routing-wg list.

A few weeks ago there was a significant route leak through Safe Host and China Telecom. This keeps happening. I think we can stop these route leaks with a relatively modest change to RPKI: by combining the ASes the origin trusts and the ASes the operator of an RPKI relying party server trusts, we have a list of all the ASes that may legitimately appear in the AS path as seen from this particular vantage point.

I believe deployment will be relatively easy, as it works for the two ASes at both ends even if ASes in the middle don't participate.

So this means a change to the ROA format, a change to the RPKI-router protocol, and of course changes to the software involved.

Here is the draft:

https://datatracker.ietf.org/doc/draft-van-beijnum-sidrops-pathrpki/ <https://datatracker.ietf.org/doc/draft-van-beijnum-sidrops-pathrpki/>

There is path filter example code in the appendix to show that this part is easy.  :-)

In case you want to try this out but don't want to compile it yourself, (mostly) the same code is also running here:

http://bgpexpert.com/pathrpki/ <http://bgpexpert.com/pathrpki/>

Probably not too much new information for this group, but some background:

http://www.muada.com/2019/06-13-lets-fix-those-bgp-route-leaks.html <http://www.muada.com/2019/06-13-lets-fix-those-bgp-route-leaks.html>

Note that this is significantly different from the AS-Cones proposal. AS-Cones is a way for transit ASes to filter their peers (and maybe their customers). RPKI path validation is everyone filtering all prefixes they see, regardless of whether these prefixes come in through peering or transit. However, there is no reason the two can't be deployed side by side.

I've also read the ASPA draft, and although there are some overlap between ASPA and RPKI path validation, I'm not entirely clear on the details but they seem to be very different.

Iljitsch

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 27 Jun 2019 22:53:09 +0000

Iljitsch,

Just in case you are not aware, there is another effort in the GROW WG 
for route leaks solution:
https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-00  
 
You mention, "We implement this by extending RPKI ROAs so that 
in addition to the origin AS, they also list all possible transit ASes."
The idea of "extended ROA" was considered during BGPsec 
design discussions. See Section 6.5.2, list item #3 in RFC 8374:
https://tools.ietf.org/html/rfc8374 
The extended ROA was proposed to include the transit AS of the origin AS.
The purpose was to make it easier for resource-constrained stub ASes 
to participate in BGPsec without incurring the upgrade costs.

In your design, you seem to include in the ROA a sequence AS1, AS2, AS3, ... where
AS1 is the origin AS, AS2 is transit of AS2, AS3 is transit of AS3, etc. Is that right? 
Prefix owner may know the origin AS (AS1) and one level higher transit AS (AS2).
But they would typically not know the transit ASes further up in the hierarchy.
Does that pose a challenge for your design? 

Sriram