Subject: Re: [sidr] Use cases for RPKI in SIDR

From: Curtis Villamizar <[email-masked]>
Date: Sat, 04 Jul 2009 17:27:41 -0400

In message <[email-masked]>
Terry Manderson writes:
>  
>  
> Hi All,
>  
> In IETF 74 a call was made to the SIDR-WG to define the organisational use
> cases that would precipitate use of the RPKI certificates and objects in a
> routing sense.
>  
> Shortly after, a small group of interested individuals began proposing text
> and discussing approaches. This culminated in an informational individual
> submission that takes the following approach:
>  
>     - Define organisation's use cases based on current observations and
> desires
>     - Ask the work group if there are any omissions
>     - Work toward documenting the broad RPKI actions that an organisation
> (in origination) needs to do before a relying party can make any
> interpretations of (in)validity.
>  
> This might then be used by the WG and authors of other drafts to ask
> questions pertaining to the completeness, direction, and applicability of
> the work from a clear use case basis.
>  
> It can also be used as common ground for developing the understanding of WG
> participants and observers in the technology.
>  
> The draft is attached for your review, and the authors and I would be most
> appreciative if you could read this document and either before, or at, IETF
> 75 provide your comments.
>  
> Cheers
> Russ, Sriram, and Terry.

There seem to be a few classes of requirements missing.

  1. Third party aggregation.

    AS X wants to form and aggregate based on components originated by
    another set of AS.

  2.  Hostile aggregation avoidance.

    AS Y does not want their component included in the aggregate
    formed by AS X.  [Note: This can currently be communicated in BGP
    communities to an immediate peer or through RPSL.  For any method,
    there is no way to enforce the requrest to AS X.]

  3.  Peer preference.

    AS Y would like to indicate a preference for a given peer or AS
    path.  [This can be done through RPSL, and to an extent using AS
    Path padding.  AS Path padding is by far more commonly used,
    though it only affects choice of among immediate peers.]

If this is a requirements document it doesn't make sense to list only
the requirements covered by a predetermined solution.

It seems that to cover a larger set of requirements (and become
useful) the RPKI must separate the AS authority from route authority
and require origination to be declared by both.  A way ti handle third
party aggregation is necessary.  A more powerful way to indicate
return path routing preferences then the current AS Path padding would
be nice.  This brings us back to the issue of whether the charter is
misguided having not really come from an evaluation of requirements
but apparently from a desire to do something easy as an interim with
the only requirement that it use a specific technology (PKI).

Another note: Is there any plan to fill in the "how" in the examples
provided or is that going to be left as an exercise to the reader?

Curtis

---

From: Terry Manderson <[email-masked]>
Date: Wed, 8 Jul 2009 16:57:08 -0700

Hi Curtis,

Thanks for reading and providing feedback on the document.

>     AS X wants to form and aggregate based on components originated by

By this do you mean that AS X wants to additionally originate the prefixes
from AS Y, or perhaps simply aggregate two contiguous prefixes into one
announcement?

>     there is no way to enforce the requrest to AS X.]

Right, so where AS X is doing aggregation as in "1." above, AS Y wishes to
say "thou shalt not aggregate my routes". Yeah?

> the requirements covered by a predetermined solution.

Sure. I'm more than happy to accept and list all possible or potential
needs.

[...]

> provided or is that going to be left as an exercise to the reader?

Yes.. I intentionally left out 'how' as it would have wrongly drawn the
discussion to interpretation of RPKI objects instead of listing the
use-cases. Once the use cases are solid, effort can then be given to
documenting suggested ways to achieve the outcomes using RPKI objects.

Cheers
Terry

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 08 Jul 2009 22:09:57 -0400

In message <[email-masked]>
> from AS Y, or perhaps simply aggregate two contiguous prefixes into one

AS-{A,B,C..} are connected to AS-X and maybe one other (AS-Y).  If
both AS-X and AS-Y aggregate, things are OK.  If AS-X and AS-Y
exchange more specifics only among themselves all is fine.

Example: After CANET fragmented (mid-1990s) most of the 1,500 or so
component routes were announced to ANS or InternetMCI with ANS and MCI
forming aggregates.  This took some coordination but wasn't bad.  It
predated BGP communities and was mostly coordinated through the IRR.

Other example: Most of OZ used to be homed into two US providers both
with beachheads in OZ.  They could have done the same but AFAIK they
did not.  They may have at one time used BGP communities to deal with
this but a lot has changed since and I don't know how that evolved.

> say "thou shalt not aggregate my routes". Yeah?

Example: Sprintlink advertising /8 routes.  They didn't do that for
very long due to a bit of an uproar.

> documenting suggested ways to achieve the outcomes using RPKI objects.

OK.  Thanks.

Curtis

---

From: Terry Manderson <[email-masked]>
Date: Wed, 8 Jul 2009 22:06:23 -0700

Hi Curtis,

> this but a lot has changed since and I don't know how that evolved.

That is clearer, Thanks.

> very long due to a bit of an uproar.

O.k.. I will add paragraphs shortly which cover the cases and run that past
the co-authors and hopefully push out an increment in the next week.

Cheers,
Terry

---

From: Geoff Huston <[email-masked]>
Date: Thu, 9 Jul 2009 15:47:22 +1000

On 09/07/2009, at 12:09 PM, Curtis Villamizar wrote:

> did not.

(I'm not sure it happened exactly that way here in OZ, but that's  
another story for another time.:-) )

Back onto the topic. the requirement of proxy or third party  
aggregation is something that I've seen from time to time.

The way I've seen this phrased is that ASes X, Y and Z announce an  
aggregatable set of prefixes to AS A, and AS A wants to to announce a  
single covering aggregate.

Geoff

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 09 Jul 2009 23:07:17 -0400

> single covering aggregate.

That is certainly the simplest case.  Difficult to handle variations
are an A and B or A is one hop removed.

The concern for the simple case is that A isn't authoritative for the
prefixes that A is aggregating.  The issue with the more difficult
cases is that the boundary of aggregation needs to be defined somehow
such that providers know which should be announcing the more specifics
and how far they are supposed to go and who is authorized to announce
and aggregate containing those more specifics.

I'm not at a provider anymore so I don't know how badly aggregation
practices have deteriorated or what the registries are up to.

Curtis

---

From: Geoff Huston <[email-masked]>
Date: Fri, 10 Jul 2009 15:43:56 +1000

> practices have deteriorated or what the registries are up to.

You are right that there may be indirection going on here and a more  
general description is that ASes X, Y and Z announce an aggregeatable  
set of prefixes and AS A wishes to announce a single covering aggregate.

The difficulty here lies in attempting to describe the authorities  
that may need to be involved here but of course in the scope of the  
use cases document such difficulties can be conveniently ignored

    Geoff