In message <c65d6486.98%terry.mander...@icann.org>
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
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
