Subject: [Sidrops] rfc7607 & multiple ROAs covering same resource

From: Job Snijders <[email-masked]>
Date: Tue, 21 Mar 2017 14:54:23 +0100

Hi all,

While implementing some ordering-dependent routing policy I came across
an IPv4 resource for which two ROAs exist: one authorises AS 0, another
one authorises a regular RIR assigned ASN.

This made me question my assumptions around AS 0: does a ROA with AS 0
preclude other valid ROAs? Should they co-exist?

Reading https://tools.ietf.org/html/rfc7607, I (unfortunatly) see no
mention or codification on how to proceed when multiple ROAs exist for a
resource, in context of AS 0.

When I asked the owner of the ROAs whether this was intentional, the
answer was "yes". It is now my understanding that the existence of one
valid RPKI ROA does not preclude the existence of another valid RPKI
ROA, even when one of the ROAs authorises AS 0 as the origin. Is this
understanding shared within this group?

If so, should we file an errata on RFC 7607 to request clarification on
this issue when the document is updated?

Kind regards,

Job

---

From: Declan Ma <[email-masked]>
Date: Tue, 21 Mar 2017 23:22:36 +0800

Job,

[RFC6483] states “A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context.”

I believe this issue bears relevance with how RP software responds to multiple ROAs existence with ROA 0 included. 

As for the example you provide, if both ROAs have been validated successfully, it is up to RPs to generate output to BGP speakers.  

Even a ROA with AS 0 doesn’t preclude other valid ROAs, we should not encourage this operation. 

Declan(Di) 

> 在 2017年3月21日，21:54，Job Snijders <[email-masked]> 写道：
> 
> Hi all,
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Job Snijders <[email-masked]>
Date: Tue, 21 Mar 2017 16:50:18 +0100

Hi Declan,

On Tue, Mar 21, 2017 at 11:22:36PM +0800, Declan Ma wrote:
> [RFC6483] states “A ROA with a subject of AS 0 (AS 0 ROA) is an
> attestation by the holder of a prefix that the prefix described in the
> ROA, and any more specific prefix, should not be used in a routing
> context.”
> 
> I believe this issue bears relevance with how RP software responds to
> multiple ROAs existence with ROA 0 included. 
> 
> As for the example you provide, if both ROAs have been validated
> successfully, it is up to RPs to generate output to BGP speakers.  
> 

How and why would you discourage this, if it is a valid mode of
operation? Clarity is king. There may be legitimate use cases for doing
this.

Kind regards,

Job

---

From: Declan Ma <[email-masked]>
Date: Wed, 22 Mar 2017 00:00:21 +0800

Job,

> 在 2017年3月21日，23:50，Job Snijders <[email-masked]> 写道：
> 
> Hi Declan,
> 

There MAY be legitimate use cases for doing this.

These cases should be justified before the WG discuss how to update RFC 7607.

I am open to this operation, hoping to see more detailed context in which you said the owner of the ROAs was intentional to do that. 

Declan (Di)

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 21 Mar 2017 17:56:36 +0000

RFC 7607 does use the word "only":

   This allows a resource holder to signal
   that a prefix (and the more specifics) should not be routed by
   publishing a ROA listing AS 0 as the only origin.

https://tools.ietf.org/html/rfc6483

   In an environment of a collection of valid ROAs, a route's validity
   state is considered to be "valid" if any ROA provides a "valid"
   outcome.  It's validity state is considered to be "invalid" if one
   (or more) ROAs provide an "invalid" outcome and no ROAs provide a
   "valid" outcome.

The ROA for AS 0 provides an "invalid" outcome.
However, the other ROA provides a "valid" outcome.
Therefore, the final outcome is "valid".

Thanks,
Jakob.

> -----Original Message-----
> From: Sidrops [mailto:[email-masked]] On Behalf Of Declan Ma
> Sent: Tuesday, March 21, 2017 9:00 AM
> To: Job Snijders <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Sidrops] rfc7607 & multiple ROAs covering same resource
> 
> Job,
>

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 21 Mar 2017 14:26:29 -0400

To add to this, there's a fairly obvious use case for having two extant ROAs, one for AS 0 and one for another ASN -- make-before-break. I'm not sure why you'd persistently have both of them, but it seems harmless. Or at least "mostly harmless" to quote D. Adams.

As for 7606 itself, I think nothing needs to be changed. The text related to ROAs is only there to provide motivation -- the only normative language in the RFC is in section 2, and it doesn't talk about ROAs or route validation. I just reread the section and it seems clear to me. In short: don't put AS 0 on the wire in a BGP message. The conversation we're now having is evidence no good deed goes unpunished -- if the motivating text had been omitted and only section 2 published, we'd be good I guess.

The 6483 section 4 language trips over itself a bit -- if it were still in draft I'd suggest removing the "by convention" language since it's nonsense. But it's harmless nonsense (or at least "mostly harmless") since in the very next clause it says "this is not a strict requirement".

Doesn't seem like there's a problem in need of fixing.

--John

> On Mar 21, 2017, at 1:56 PM, Jakob Heitz (jheitz) <[email-masked]> wrote:
>

---

From: Declan Ma <[email-masked]>
Date: Wed, 22 Mar 2017 10:01:56 +0800

John,

> 在 2017年3月22日，02:26，John G. Scudder <[email-masked]> 写道：
> 

Agreed. “Make-before-break”  is making sense here  :-)

> As for 7606 itself, I think nothing needs to be changed. The text related to ROAs is only there to provide motivation -- the only normative language in the RFC is in section 2, and it doesn't talk about ROAs or route validation. I just reread the section and it seems clear to me. In short: don't put AS 0 on the wire in a BGP message. The conversation we’re now having is evidence no good deed goes unpunished -- if the motivating text had been omitted and only section 2 published, we'd be good I guess.
> 
> The 6483 section 4 language trips over itself a bit -- if it were still in draft I'd suggest removing the "by convention" language since it's nonsense. But it’s harmless nonsense (or at least "mostly harmless") since in the very next clause it says "this is not a strict requirement".
> 
> Doesn’t seem like there's a problem in need of fixing.

Right. It also seems to me there is no need of fixing. 

I comprehended “by convention” as a sort of suggestion, while “not a strict requirement” do leaves it to operator to do at its discretion. 

Huh, one is free to have multiple ROAs existence with ROA 0 included. Yet I believe the very implication is quite conspicuous. 

Declan (Di)

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Mar 2017 18:39:40 -0500

> preclude other valid ROAs?

no.  give 42 roas (incl some with as==0), if one validates the origin
as, the announcement is valid.

of course, at 43 roas, all bets are off :)

randy