Subject: [sidr] Two ROA Format issues from the meeting

From: Matt Lepinski <[email-masked]>
Date: Mon, 17 Nov 2008 16:01:19 -0500

Two issues came up during the ROA Format presentation at IETF 73:

1) Should the ROA Format draft explicitly prohibit a ROA with 
overlapping prefixes?
(E.g. A ROA that says AS # 1 can originate routes to 10/8, 10.10/16 and 
10.20/16)

2) Should the ROA Format draft prohibit the use of the "Inherit" Flag in 
the RFC 3779 IP Address extension of the EE certificate corresponding to 
the ROA?

In both cases, implementors have claimed that the prohibition would 
improve implementation efficiency and/or ease of coding/testing. The 
trade off is that in certain cases such prohibitations would require 
putting additional bits in the repository (I.e. in the first case, an 
ISP may sometimes need to issue an additional ROA; and in the second 
case, some ISPs may need to create larger EE certificates).

I don't have a strong opinion, although my inclination is towards 
writing both of these prohibitions into the document. In any case, I'd 
very much like to resolve these issues quickly. (Since I believe that 
the ROA Format draft is otherwise ready for last call).

- Matt Lepinski

_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Geoff Huston <[email-masked]>
Date: Tue, 18 Nov 2008 08:40:23 +1100

WG Chair hat off

On 18/11/2008, at 8:01 AM, Matt Lepinski wrote:

> (E.g. A ROA that says AS # 1 can originate routes to 10/8, 10.10/16  
> and 10.20/16)

What do you mean by overlap Matt?

a) 10.0.0.0/8 maxlength=9 and 10.0.0.0/24 maxlength=24

or

b) 10.0.0.0/8 maxlength=24 and 10.0.0.0/16 maxlength=16

or

c) 10.0.0.0/8 maxlength=17 and 10.0.0.0/16 maxlength=24

seems to me that b) is the only case where the second item is  
completely subsumed by the first, yet all three contain "overlapping  
prefixes"

It also seems to me that all these cases are essentially harmless.

My opinion is NOT to put this prohibition into the document, assuming  
of course that there is some clarity over what is meant precisely by  
"overlapping prefixes" in the first place

   Geoff

---

From: Matt Lepinski <[email-masked]>
Date: Mon, 17 Nov 2008 17:27:59 -0500

Geoff,

My understanding of the discussion at the meeting was that the proposed 
prohibition would cover all three cases that you list below. The 
proposal was raised by Rob Kisteleki and Rob Austein, so I defer to 
either of them who would like to clarify.

Either way, it seems to be a small issue, and so I'm inclined to do 
whatever makes implementation of the spec easiest.

- Matt Lepinski

---

From: Randy Bush <[email-masked]>
Date: Mon, 17 Nov 2008 16:34:54 -0600

> prohibition would cover all three cases that you list below.

yep.  i would just say prohibit please except ...

ruediger was the only user/rp to express concerns.  so i would like to
have a chance to discuss further with him before finalizing.  and, of
course, to hear from any other roa producers/consumers.

randy

---

From: Robert Kisteleki <[email-masked]>
Date: Mon, 17 Nov 2008 17:25:23 -0600

Hi,

I'd defer the actual decision to those with more operational experience. My 
only wish is that whatever the decision is, it should be explicitly 
documented in the document (ie. "overlaps can happen and they are fine" or 
"there should be no overlaps at all").

Geoff: my definition of overlap would be (B) and (C) - ie. one or more IP 
addresses covered by two or more entries. (A) does not contain an overlap. I 
think this is consistent with what Ruediger said at the mike.

Cheers,
Robert

---

From: Rob Austein <[email-masked]>
Date: Mon, 17 Nov 2008 23:05:36 -0600

> either of them who would like to clarify.

For those who didn't hear my comments at the meeting: RFC 3779 doesn't
allow overlaps.  Checking whether a ROA is covered by an RFC 3779
certificate is a bit easier if one doesn't need to implement the merge
operation necessary to allow overlaps when converting from a ROA to an
RFC 3779 resource set.  If there's a useful purpose served by allowing
overlaps, fine, I'll implement the merge, but until Ruidiger's
comments today I had not heard anybody claim that allowing these
overlaps serves a useful purpose.

So at this point I'm waiting for the outcome of the discussion between
Randy and Ruidiger to find out whether these overlaps are useful.
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Geoff Huston <[email-masked]>
Date: Tue, 18 Nov 2008 16:44:39 +1100

Wg chair hat off

On 18/11/2008, at 9:27 AM, Matt Lepinski wrote:

> Geoff,
>
> My understanding of the discussion at the meeting was that the  
> proposed prohibition would cover all three cases that you list  
> below. The proposal was raised by Rob Kisteleki and Rob Austein, so  
> I defer to either of them who would like to clarify.
>

I could possibly understand this "prohibition" if it was restricted to  
enumeration of those cases where the 'overlap' was one where there was  
no additional information provided in the overlap. But in the cases I  
enumerated below only in case b) is the overlap redundant in that the  
announced prefixes that would be matched by the ROA are identical with  
or without the overlapping more specific. In cases a) and c) the  
overlap defines additional more specifics

Why are cases a) and c) potentially useful?

One possible scenario is  in TE use, where a prefix holder wants to  
load share across two upstreams through the use of more specifics and  
have mutual backup via an aggregate

ROA 1: 10.0.0.0/8 maxlength = 8 10.0.0.0/16 maxlength=16, AS 1

ROA 2: 10.0.0.0/8 maxlength = 8 10.128.0.0/16 maxlength=16, AS 1

now if I have this right what this equates to is an explicit authority  
for AS 1 and AS 2 to advertise only a certain subset of more specifics  
as well as the covering aggregate.

There may well be other scenarios of such selective authorities.

>>> (E.g. A ROA that says AS # 1 can originate routes to 10/8,  
>>> 10.10/16  and 10.20/16)
>>
>>
>> completely subsumed by the first, yet all three contain  
>> "overlapping  prefixes"
>>
>> My opinion is NOT to put this prohibition into the document,  
>> assuming  of course that there is some clarity over what is meant  
>> precisely by  "overlapping prefixes" in the first place
>>
>>  Geoff
>>
>>
>>
>>
>
>

---

From: George Michaelson <[email-masked]>
Date: Tue, 18 Nov 2008 16:38:29 -0600

As a matter of record, the APNIC implementation allows for creation of  
overlapping prefixes in a ROA.

We do not support any change to this.

-George

---

From: Roque Gagliano <[email-masked]>
Date: Wed, 19 Nov 2008 16:17:29 -0600

Hi Geoff,

I have been thinking on the scenario introduced by a ccTLD that has  
its DNS server inside a University network and has a different routing  
policy even if inside the network. They may want to avoid accidental  
de-aggregation of the university block at large and only allowed it  
for a small portion (example the ccTLD). There is even

ROA 1: University: ROA 1: 10.0.0.0/16 maxlength = 16, AS 1.
ROA 2: ccTLD Net: ROA 2: 10.0.0.0/23 maxlength = 24, AS 1.

I can also see a case in local anycast implementations where you only  
want a more specific for the prefix you are anycasting and not  
necessarily for the rest of the possibilities.

In conclusion, I believe that overlapped ROAs will be useful and  
should be supported in RPKI architecture.

r.

On Nov 17, 2008, at 11:44 PM, Geoff Huston wrote:

> I could possibly understand this "prohibition" if it was restricted  
> to enumeration of those cases where the 'overlap' was one where  
> there was no additional information provided in the overlap. But in  
> the cases I enumerated below only in case b) is the overlap  
> redundant in that the announced prefixes that would be matched by  
> the ROA are identical with or without the overlapping more specific.  
> In cases a) and c) the overlap defines additional more specifics
>
> load share across two upstreams through the use of more specifics  
> and have mutual backup via an aggregate
>
>
> now if I have this right what this equates to is an explicit  
> authority for AS 1 and AS 2 to advertise only a certain subset of  
> more specifics as well as the covering aggregate.
>