Re: [Sidrops] Path validation with RPKI

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

[Including GROW list because some members there would be interested
given the RLP draft has home in GROW] 

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   

>Indeed, I wasn't aware of this one.
-- snip --
> 
> I think that could work well. But: I have two issues:
> 
> The first issue: this uses the large communities feature. I'm not sure how this is
> implemented, but with regular communities, routers must sometimes be
> configured to propagate them, and can be configured to _not_ propagate
> them. If this is the same for large communities, then the feature won't be as
> robust as it could be, as the community may not be propagated over eBGP
> sessions. And less than well meaning networks have plausible deniability "oh
> no we turn off large communities because of ...".

The current feeling in GROW is that it is possible to make transitivity work for 
Large Communities. Ruediger talks about providing strong policy
guidance for operators about this.  

> 
> So it would be better to make this its own transitive path attribute. The BGP
> spec is very clear on how these need to be propagated.
> 
> Second, this is makes the whole thing not work:
> 
>    2.  Else, when propagating a route that already includes a DO (i.e.,
>        was received with a DO) to a customer or lateral peer, replace
>        the DO value with the local ASN.
> 
> So assume the following path:
> 
> 5 4 3 2 1
> 
> With 5 being the validating AS (which would normally not show up in the AS
> path) and 1 being the origin AS. Now suppose the relationships are:
> 
> 5 ^ 4 \ 3 ^ 2 \ 1
> 
> AS 2 includes DO=2. So if AS 5 has access to that information, it can determine
> that this is an invalid path. However, AS 4 replaces DO=2 with DO=4. However,
> now AS 5 only gets to see that the prefixes it gets from AS 4 are from peering,
> which is not news to AS 5. The actionable fact that AS 2 was sending the prefix
> in question over peering and that prefix is now leaked by AS 4 is now hidden
> from AS 5, so AS 5 is not in the position to take any action.
> 

AS5 can take action. No issue there. I'll explain.
Is 3 not doing RLP? If 3 is doing RLP, it would not propagate the update to 4.
But to try to get to your point, let us say 3 is not participating in RLP
and leaked the update to 4. Now, 4 detects the update to be a route leak
because it does not expect a DO set in a route received on a customer link.
If 4 has an alternate path for the prefix that is clean (not route leak),
it would prefer that. Else, 4 accepts and propagates the leaked route from 
3 (customer) in order to avoid unreachability. Yes, 4 replaces DO=2 with DO=4,
but there is something more that 4 does. The draft specifies (p. 5):

   2.  Leak detected (L) indication: ASN of the first RLP-aware AS in
       the path to assert that it forwarded the route from a customer or
       lateral peer despite detecting a leak (to avoid unreachability).

So 4 also adds L = 4. This L informs 5 that the route is tainted (Leaked).
5 would prefer an alternate route that is clean, if available.
So, yes, 5 can take action.

This will become even more clear if you take look at slide 14, scenario 2
in our scenario analyses slide deck:
https://www.nist.gov/sites/default/files/documents/2018/10/22/rlp_using_bgp_community-v4.pdf 

> What needs to happen is that the community or attribute is ONLY added when
> it's not present and a prefix is sent over a ^ or / relationships, and then
> subsequently never touched.

We did consider this. But it is not necessary because L 
prevents what you apprehended. 
It was felt that DO should convey the latest AS that needs to assert down only.
In general, that AS is in closer proximity to the receiver in question
than the very first AS that initially set DO.

> 
> > 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://datatracker.ietf.org/doc/rfc8374/ 
-- snip --
> > 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.
> 
> It says:
> 
>        This approach was rejected due to possible complications with the
>        creation and use of a new RPKI object, namely, the extended ROA.
> 
> What would be the possible complications with creating such extended ROAs?
> Obviously there is some extra work, but I can't imagine any show stoppers.

It was many years ago (the design phase). 
I think it was just the extra work that concerned us.

>  -- snip --
> Iljitsch

Thanks,

Sriram