Subject: Re: [Sidrops] Path validation with RPKI

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 1 Jul 2019 16:39:55 +0200

Hi Kotikalapudi,

On 28 Jun 2019, at 00:53, Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=[email-masked]> wrote:

> 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. Any particular reason these efforts are split between sidrops and grow? And are idr and/or sidr also in some way involved?

The ASPA draft and my draft assume out of band information to validate (parts of) the AS path. The other approach is convey the necessary information in band, and as I was reading this draft I thought this was a good way to do it. Obviously there are limitations to in band, most notably, the ability of a malicious AS to manipulate any in band information in the absense of cryptographic protections like the ones BGPsec offer.

So basically, using the notation I invented last week, RLDM conveys a ^ or / somewhere in the path (assuming origin on the right direction). And as the validating AS knows whether it has a ^ or \ relationship with the next AS, we can detect invalid paths like these:

^??^??
^??/??
\??^??
\??/??

(With more or fewer ? as desired.)

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 ...".

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.

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.

> 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.

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.

> 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? 

Well, sort of. Suppose AS1 is the origin and AS2 and AS3 provide transit. Then that would result in:

AS1 AS2 AS3 or:
AS1 AS3 AS2

But now suppose AS1 gets transit from AS2 and AS2 gets transit from AS3. Then you get:

AS1 AS2 AS3 but not:
AS1 AS3 AS1

So the two different transit scenarios can't be determined from the extended ROA. I don't think this is an issue because the unintended paths that would be declared valid in this case would still have to appear in a BGP AS path, which is very unlikely.

> 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? 

I think the main challenge is not determining this information once, that seems doable. But now if there is a change in the transit providers for AS2, AS2 has to inform all of its customers and these customers have to take action.

Also, if internet exchange route servers are present in the path, then that could potentially add a large number of "transit" ASes.

In this sense, the ASPA approach works better. On the other hand, my approach gives origin ASes more options to determine their policy.

Perhaps a hybrid solution that allows origin ASes to indicate "these ASes, plus any transit ASes specified by these ASes" or "these ASes, and nothing else".

Thanks,

Iljitsch

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Mon, 1 Jul 2019 16:47:54 +0000

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

Iljitsch,

>Indeed, I wasn't aware of this one.
-- snip --
> 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.
> 
> 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.

> > https://datatracker.ietf.org/doc/rfc8374/ 
-- snip --
> 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 --

Thanks,

Sriram