Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)

Terry:

Hi!  Any thoughts on this document?

Thanks!

Alvaro.

On December 22, 2017 at 9:52:21 AM, Tim Bruijnzeels (tim@ripe.net) wrote:

Dear Terry,

We just uploaded version -10 that we hope addresses your points.

This version adds:
- explicit text in the abstract stating that this document considers
validation under a Trust Anchor only, and that overlaps between multiple
TAs are out of scope
- three examples using the validation algorithm in this document:
1- Old OID only
2- New OID only
3- A mix of old and new OIDs in a single RPKI tree
- the deployment considerations section clearly says discussion still needs
to be had, but points at example 3 as a possible deployment scenario

Kind regards,

Tim Bruijnzeels, and co-authors

> On 31 Aug 2017, at 05:29, Terry Manderson <terry.manderson@icann.org>
wrote:
>
> Terry Manderson has entered the following ballot position for
> draft-ietf-sidr-rpki-validation-reconsidered-08: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
>
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thank you for considering the stability of the internet's routing system
during
> administrative changes to resources.
>
> One thing isn't quite clear to me, so I'm balloting this as a DISCUSS
with the
> plan that a small amount discussion will resolve it.
>
> With the definition of the new validation OID (a idea that I like BTW),
at any
> stage of the certificate issuance can the validation OID be switched?
That is a
> TA has a particular OID and down the tree an issued certificate has a
different
> OID? If that can't happen (and please make that clear in the document) is
there
> plan to migrate the set of all issued certificates to the new OID? and
> deprecate the old OID?
>
> Logically speaking a trust anchor cannot be thought of as over-claiming.
(eg
> you trust where the self signed cert came from, and its contents) However
the
> new validation constructs suggest that a TA can over-claim, but it seems
like
> there won't be any warning (as the example in S4.3) to highlight this
possible
> eventuality when (in the model where all RIRs issue a TA) a resource is
> transferred from one RIR to another for the clients use. Is that
interpretation
> correct? OR does this new model espouse the belief that all RIRs each
issue a
> TA that covers 0/0 and ::/0 in perpetuity? In that construct does this
mean
> that RFC6491 should be updated or made historic?
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I get the sense that many of the ramifications for this validation change
are
> yet to be discovered. It worries me that from the shepherd writeup "The
> existing CA/RP code implementations will support this once published."
What
> experiments have been done to identify any gaps and assumptions?
>
>
>

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr