Subject: Re: [sidr] am I missing something?

From: Sandra Murphy <[email-masked]>
Date: Thu, 6 Nov 2008 16:03:29 -0500 (Eastern Standard Time)

On Fri, 24 Oct 2008, Terry Manderson wrote:

> I was re-reading draft-ietf-sidr-res-certs-13 to get something clear in my 
> head about SIA values and I got wildly side-tracked.
>
> in section 1, it says:
>
> "In the context of the public Internet, and the use of public number 
> resources within this context, it is intended that Resource Certificates are 
> used in a manner that is explicitly aligned to the public number resource 
> distribution function"
>
> My impression is that the allocation chain goes IANA->RIR->NIR/LIR->ORG. And 
> for legacy space there is a IANA->ORG structure. That is the way public 
> numbers are distributed, yes?
>
> Wouldn't/Shouldn't there be a request for IANA to sign over "stuff" in the 
> IANA considerations section? (or have I got the purpose of that section 
> completely wrong?)

One clarification in res-cert-14 (section 1, page 4-5) indicates:

    While this profile describes the structure of a default Trust Anchor
    for this PKI, Relying Parties (RPs) in this PKI are free to select
    the trust anchors upon which they rely, and thus the PKI as viewed by
    RPs need not match the public resource allocation hierarchy as
    described here.

So while the intent of the RPKI is to mirror the allocation hierarchy, the 
relying party may select a trust anchor that is not the IANA, so the RPKI 
mirrors only the allocation relationship of the public resource allocation 
hierarchy, not necessarily the tree itself with IANA at the apex.

There's no requirement that IANA sign anything (or any requirement that 
any other part of the existing public resource allocation hierarchy sign 
anything), so there's no need for an IANA considerations section.

Does that clear up your question?

--Sandy

>
> Apologies for the newbie-ness of the question.
>
> Terry
> Speaking for Terry, I don't get to speak for anyone else.. and sometimes not 
> even me! (just don't ask ;)
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Danny McPherson <[email-masked]>
Date: Sun, 16 Nov 2008 21:43:57 -0700

On Nov 6, 2008, at 2:03 PM, Sandra Murphy wrote:
> So while the intent of the RPKI is to mirror the allocation hierarchy,

Is it?

> the relying party may select a trust anchor that is not the IANA, so  
> the RPKI mirrors only the allocation relationship of the public  
> resource allocation hierarchy, not necessarily the tree itself with  
> IANA at the apex.
>
> There's no requirement that IANA sign anything (or any requirement  
> that any other part of the existing public resource allocation  
> hierarchy sign anything), so there's no need for an IANA  
> considerations section.
>

This discussion, and that of BOAs et al. have me wondering if we
shouldn't be talking more about where that apex falls, and if it's
one or six, and the implications of all these things, as they're
sure to have considerable impact on operational and deployability
work we do here.

I believe there are indeed considerable IANA implications in this
discussion and this is something that needs to be well understood
when architecting solutions in this area.

With that, I'm quite interested in understanding any perspectives
folks are willing to provide.

Thanks!

-danny

---

From: Randy Bush <[email-masked]>
Date: Mon, 17 Nov 2008 01:00:17 -0600

> when architecting solutions in this area.

perhaps, given the origin of the document, an iana hating section would
be more expected.

there are only two parties with authority to say publicly what is or is
not route-able, the iana, who owns all the special kink, and the public
holder of the space in question.  this seems trivially obvious.

in addition, if there are private routing domains, then there are likely
to be corresponding trust systems.  as these exceptions will have to be
manually configured, the anathema of the wise operator, it would seem
prudent to minimize their occurrence.

> folks are willing to provide.

the iana is the root of the allocation tree.  hence it should be the
root of rpki trust.  this is also trivially obvious.  it is just not
acceptable to some folk who focus on power as opposed to technology.  i
assume they will not be getting their next /8 from the iana.

but pig wrestling <http://en.wiktionary.org/wiki/wrestling_with_a_pig>
is futile and boring.

randy