Subject: Re: [sidr] draft-ietf-res-certs

From: Danny McPherson <[email-masked]>
Date: Wed, 3 Dec 2008 11:19:16 -0700

On Nov 6, 2008, at 1:00 PM, Geoff Huston wrote:

> WG Chair Hat OFF
>
> Since Sandy's Last Call on this document there have been a few  
> changes to the document which I should note here.
>
> The first set of changes concerns the revision from -13 to -14 (http://smakd.potaroo.net/cgi-bin/htmlwdiff?f1=..%2fall-ids%2fdraft-ietf-sidr-res-certs-14.txt&f2=..%2fall-ids%2fdraft-ietf-sidr-res-certs-13.txt 
> )
>
> Following advice from Steve Kent, the section on Trust Anchors was
> revised (section 6). The change has concerned the terminology used to
> described the various structures proposed in the TA model.

Indeed, and these changes, from -13 -> -14, and, certainly,
-14 to -15, seem quite significant, in particular those in
the introductory section of 6.3.  Can you provide a pointer
to the discussion that led to these changes post WG LC?

Also, given these changes, and in particular the sensitive
nature of their content, I would suggest that the WG fully
re-LC this document after this discussion is revisited on the
mailing list and consensus is reached regarding this topic:

<http://tools.ietf.org/wg/sidr/draft-ietf-sidr-res-certs/draft-ietf-sidr-res-certs-15-from-14.diff.html 

Thanks!

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

---

From: David Conrad <[email-masked]>
Date: Wed, 3 Dec 2008 14:33:36 -0800

[No hat]

Hi,

I have been avoiding raising any issues on the res-cert draft for  
political reasons, however I believe the draft is flawed in a non- 
political way in that section 6.3 makes reference to IANA acting in  
some capacity as a trust anchor yet the IANA Considerations section  
states:

"[Note to IANA, to be removed prior to publication: there are no IANA  
considerations stated in this document.]"

Either IANA is acting in some capacity as a trust anchor and as a  
result there ARE IANA considerations

- OR -

IANA is not acting in in some capacity as a trust anchor in which case  
the absence of IANA considerations is appropriate, but section 6.3  
needs to be revised to make explicit that IANA is NOT involved in the  
RPKI trust hierarchy.

You can't have both.

Hopefully this comment will not trigger political sensitivities  
regarding IANA's role in the RPKI.

Back under my rock.

Regards,
-drc

---

From: Geoff Huston <[email-masked]>
Date: Thu, 4 Dec 2008 09:50:48 +1100

WG Chair Hat OFF

The text you refer to was provided by Steve Kent. I understand that  
the text was proposed on the basis that the original text did not  
describe a valid PKIX construct.

---

From: Danny McPherson <[email-masked]>
Date: Wed, 3 Dec 2008 16:10:19 -0700

On Dec 3, 2008, at 3:33 PM, David Conrad wrote:

> "[Note to IANA, to be removed prior to publication: there are no  
> IANA considerations stated in this document.]"
>
> IANA is not acting in in some capacity as a trust anchor in which  
> case the absence of IANA considerations is appropriate, but section  
> 6.3 needs to be revised to make explicit that IANA is NOT involved  
> in the RPKI trust hierarchy.
>
> You can't have both.
>

FWIW, I raised the same concern yesterday on the list via
comments made on the sidr-arch draft:

---
IANA Considerations surely should include some guidance to
IANA about investigation and preparation for anything that might
be required WRT serving as a TA.  Also, for legacy space, etc..

In general, I like to see more description and discussion of the
TA model here, as others (e.g., Roque on 11/17/08) and previous
discussions seem to support as well.
---

-danny

---

From: John Curran <[email-masked]>
Date: Thu, 4 Dec 2008 00:33:14 -0500

On Dec 3, 2008, at 5:33 PM, David Conrad wrote:
> ...

David -

As I read the draft, the IANA's role as a trust anchor is no different
than any of the RIR's (i.e. each acting as their own trust anchor for
their own RPKI hierarchy):

  S 6.3:
  "This observation motivates a two-tier trust anchor model for the
  RPKI. The top tier trust anchor for each RIR (and IANA) will be a
  self-signed certificate that contains no resource extensions. ... "

Setting aside the relative merits of having each RIR and IANA using
a separate RPKI hierarchy, it's somewhat understandable that there
is no IANA Considerations section, since there is no new requirements
for namespace management being put or changed on the IANA, per BCP26.
As written, the IANA might, at its discretion, decide to make use of
res certs, but that's not mandatory for this document to be useful.

While there is no new namespace of identifiers to be managed, I think
that it might be valuable to document the communities expectations for
the IANA in an "IANA Considerations" section.  Per the current draft,
this wouldn't necessary mention any IANA role as a trust anchor but
instead simply be note to the effect that "This document defines a
standard profile for certificates supporting validation of assertions
of right-to-use for Internet numbering resources, and that the IANA
should provide support for such assertions for the Internet numbering
resources which it manages."

/John

---

From: John Curran <[email-masked]>
Date: Thu, 4 Dec 2008 02:08:06 -0500

> described the various structures proposed in the TA model.

The clarifications and additions in section 6.3 are a major
step forward in understanding the intent of the draft with
respect to Trust Anchors.  With the improved understanding,
there are some questions raised as to how exactly the full
set of assertions should be obtained for any given Internet
numbering resource.

The draft uses the term "default trust anchor collection" in
section 6.3 ("Relying Parties can assemble the default trust
anchor collection by using the registry TA certificate for each
nominated trust anchor...") but doesn't specify how to navigate
the multiple RPKI hierarchies that occur only in the presence
of a "trust anchor collection", nor does it provide guidance
on to perform overall interpretation of multiple valid assertions
which might occur in presence of a "trust anchor collection".

The semantic logic regarding how to handle sets of overlapping
and contradictory assertions is essential for consistent
interpretation of the certificates contained in the full set
of RIR/IANA RPKI hierarchies.  Note that RFC 3779 not only
doesn't provide any assistance in resolving this situation,
it specifically sets rules to prevent such an situation from
occurring:
"Sections 2 and 3 specify several rules about the encoding of the  
extensions defined in this specification that MUST be followed. These  
encoding rules serve the following purposes. First, they result in a  
unique encoding of the extension's value; two instances of an  
extension can be compared for equality octet-by-octet.  Second, they  
achieve the minimal size encoding of the information. Third, they  
allow relying parties to use one-pass algorithms when performing  
certification path validation; in particular, the relying parties do  
not need to sort the information, or to implement extra code in the  
subset checking algorithms to handle several boundary cases (adjacent,  
overlapping, or subsumed ranges)."
In its present form, the draft departs from the single certificate
hierarchy envisioned in RFC 3779 ("IP address space is currently
managed by a hierarchy nominally rooted at IANA, but managed by
the RIRs"), and thus makes numerous combinations of conflicting
assertions possible for the same numbering resource.  Without
unstated information on how to obtain and correctly interpret
such combinations, the ambiguities that result prevent using
the proposed model with multiple RPKI hierarchies to ascertain
information for a given numbering resource with any degree of
certainty.  As this is *the* utility value of an RPKI system
for many in the community, I'd recommend we either correct the
model or supply the missing information which will allow for
deterministic use of the total RPKI infrastructure.

/John

---

From: David Conrad <[email-masked]>
Date: Thu, 4 Dec 2008 09:38:48 -0800

John,

> their own RPKI hierarchy):

Yes, that is my interpretation of the draft as well.

> res certs, but that's not mandatory for this document to be useful.

I don't want to go too far afield on a meta-point, but in the Brave  
New Internet in which we find ourselves, IANA does not do things at  
its discretion.  IANA implements decisions others make (presumably via  
some community-based consensus) through IANA Consideration sections or  
by specific direction of the IAB, IESG, etc.  The alternative would be  
"top down" decision making (oh, the horror) and would require IANA  
staff to have a level of expertise in a wide array of topic areas that  
is most likely not reasonable to assume.

With respect to the draft, if SIDR is indicating IANA needs to  
maintain an RPKI trust anchor (regardless of what it is covering), I  
believe an IANA considerations section needs to state IANA is directed  
to do this.  I understand that some folks are working on appropriate  
wording.

Regards,
-drc

---

From: Geoff Huston <[email-masked]>
Date: Fri, 5 Dec 2008 17:50:15 +1100

On 05/12/2008, at 4:38 AM, David Conrad wrote:

> its discretion.  IANA implements decisions others make (presumably  
> via some community-based consensus) through IANA Consideration  
> sections or by specific direction of the IAB, IESG, etc.  The  
> alternative would be "top down" decision making (oh, the horror) and  
> would require IANA staff to have a level of expertise in a wide  
> array of topic areas that is most likely not reasonable to assume.
>
> believe an IANA considerations section needs to state IANA is  
> directed to do this.  I understand that some folks are working on  
> appropriate wording.

WG CHair Hat Off

 From time to time the IETF heads into areas where its role intersects  
with the roles of other bodies, and its ability to direct the IANA to  
do, or not do, certain things has some relationship with the roles of  
these other bodies as well. In this case the draft's authors, namely  
myself, George Michaelson and Rob Loomans, have been made aware of  
some degree of intersection of interests between the RIRs and the IANA  
in terms of the roles of various bodies in terms of the publication of  
putative TA material that may be used by relying parties.

The draft deliberately does not prescribe any particular solution over  
and above any other, but proposes a way in which the RIRs and IANA can  
publish putative TA material in a manner that is useful to relying  
parties, should they choose to uses this material as their nominated  
Trust Anchors.

i.e. to state this clearly using wording comparable to David Conrad's  
note, the draft does not provide any particular direction to IANA, and  
while some folk may be off working on some appropriate wording to  
suggest to add to the draft that does provide such direction, other  
folk, including myself as a co-author of the document, are currently  
of the view that the current wording is entirely appropriate for the  
circumstance that we find ourselves in. No doubt the politics of the  
formation of rough consensus gathering in the IETF will sort all this  
out in the fullness of time.

My personal opinion follows:

The draft is not advocating that IANA does, or does not do any  
particular action with respect to the publication of TA material. In  
looking at the abundance of heat and absence of light that the topic  
of IANA signing of the root zone of the DNS has managed to generate  
over the years so far, and with the end still not yet in sight, and  
with the various statements of vague equivocation being made by many  
bodies, including that of the IAB (!), its all to easy to see that  
this general topic of the assumption of a "root" authority is one that  
is not simple, and that this topic when related to the address space  
may well bring out many more interests and many more perspectives than  
are evident in the current set of interested parties in the SIDR  
discussion. It would've been a tragedy, and perhaps a fatal one, if  
the DNSSEC standards had been contingent on the adoption of a single  
nominated process for iANA to sign the root zone of the DNS using IANA- 
generated keys. Obviously the DNSSEC documents would not have been  
published as RFCs yet, and the DNSSEC specifications would still be  
sitting in some strange half life as quasi-standards awaiting the  
termination of a process that is both overly political and potentially  
non-terminating! The signal that would give to DNS users as to the  
viability of DNSSEC would be less than a wholesome endorsement.

I personally see no merit whatsoever in consigning the SIDR work into  
a similar indeterminate twilight awaiting the termination of a  
political process that really has no clear outcome once the matter  
really gets the level of heat applied to it over the expression of  
national political interests into the Internet's infrastructure. Once  
the issue of authority over the address space is raised, then in the  
same fashion as the DNS where the matter has headed off into the realm  
of international politics, I personally suspect that we would see a  
statement of overarching interest being made by the NTIA within the US  
Government, citing some continuity of USG address management dating  
back through to the ARPA programs, and I also suspect that we'd see  
strong, perhaps vehement, statements of opposition coming from other  
national interests who would take the view, with some rational  
foundation, that one government has no right to hold such a privileged  
position with respect to an international public network while all  
other governments and treaty organizations are shut out of the process  
completely. The alignment of interests that are vehemently opposed to  
the USG exercising such a special role, and in particular given the  
rather unique ability to undertake a revocation apply a new level of  
political concern to the picture. It may well be that this particular  
looming political imbroglio over the authority of the address space is  
unavoidable, and that no matter what the IETF does or does not do, we  
are going to have to ensure the political stoush. Or, just maybe, we  
in the IETF can attempt to avoid the issue to some extent and insist  
that beauty, or in this case the choice of Trust Anchors, is in the  
eye of the beholder, or in this case is in the eye of relying parties.  
Maybe its better for the IETF to avoid being prescriptive as to where  
or how putative trust should be asserted as a part of the IETF's  
technology standard, and allow the technology to progress and be  
published as an Internet Standard without being stalled up on an issue  
which is not readily tractable given the breadth and diversity of  
interests. But some folk are perhaps more interested in politicizing  
the IETF and its outcomes, and forcing the IETF to take a stance that  
may well be interpreted as an outrageously partisan stance from a  
broader international political perspective. I _personally_ would view  
that development with some sorrow, as I suspect that we've seen too  
much of the IETF being branded as the compliant lapdog of a single  
government's interests for the past two decades, and as the IETF we've  
strived to get beyond all that and concentrate on developing and  
standardizing technology to the best of our collective abilities in  
the same fashion as, or hopefully better than, any other international  
standards organization. The way we've done that is to avoid taking  
sides arbitrarily in political debates and attempting to look at  
situations as objectively and as rationally as possible and perform a  
scoped task that relates to the development of technology. A little  
more of that form of rational process would, I believe, assist the  
SIDR WG to make the appropriate call here as well.

Geoff

---

From: David Conrad <[email-masked]>
Date: Fri, 5 Dec 2008 00:28:04 -0800

Geoff,

[No hat. Really.  Personal opinion only]

On Dec 4, 2008, at 10:50 PM, Geoff Huston wrote:
> From time to time the IETF heads into areas where its role  
> intersects with the roles of other bodies,

Yep.  Like (say) IPv6 and IPSEC requirements and the interaction with  
national crypto laws where the decision was made to choose the  
technically correct solution in the face of concerns that national  
laws would make deployment more difficult or even impossible (I  
remember a particularly interesting plenary in Danbury where that  
topic was 'discussed')...

> particular action with respect to the publication of TA material.
[many, many words elided]
> A little more of that form of rational process would, I believe,  
> assist the SIDR WG to make the appropriate call here as well.

This may come as a surprise, but I do not necessarily disagree with  
what you have said.  Because of personal experience, I am probably  
more aware of the political ramifications of single root issues than  
most here and as a result can see arguments both ways as to  
appropriate directions to take regarding trust anchor(s).

However, I am unaware of any public discussion in which those trust  
anchor issues have been broached much less addressed.  In the case of  
DNSSEC, there was little, if any, discussion about the operational  
realities of attempting to deploy DNSSEC including trust anchor issues  
and IANA's role.  As a (arguably) direct result, we're now 12 years  
into deployment and have gotten minimal traction.  It would be tragic  
to repeat that particularly sad history with RPKI.  Presumably, the  
goal here is to get something that can actually be deployed...

I would gently suggest that attempting to ignore the politically  
sensitive issues (whether they be national politics or ICANN/RIR  
politics) by not addressing the underlying cause of those issues is  
leading us down the exact same potentially non-terminal path you  
express concerns about (particularly when the NRO representative at  
the ICANN meeting waves a bouquet of red flags at the assembled  
governance officials during the plenary and when it becomes a topic of  
discussion and not necessarily in a good way (I'm told) at the IGF).   
The ant mound has already been stirred.  Pretending you're not covered  
in honey is unlikely to have a positive outcome.

If you wish to argue that the treatment of trust anchors should not be  
in the res-certs draft, that's fine as long as you follow it up with  
'it should be in X' (and you define 'X' :-)).  I believe it important  
that there be an open discussion about the pros and cons of the  
various trust anchor models and any recommendation be made in a  
transparent manner. I reiterate my belief that if IANA is going to be  
a participant in a trust anchor or anchors, it needs to be called out  
explicitly in the IANA Considerations section, but that's merely my  
opinion (like the entirety of this note).

FWIW.

Regards,
-drc

---

From: Geoff Huston <[email-masked]>
Date: Fri, 5 Dec 2008 21:31:00 +1100

WG Chair Hat OFF

On 05/12/2008, at 7:28 PM, David Conrad wrote:

> Yep.  Like (say) IPv6 and IPSEC requirements and the interaction  
> with national crypto laws where the decision was made to choose the  

ahh, but they were many fine words!  :-)

> anchor issues have been broached much less addressed.  In the case  
> of DNSSEC, there was little, if any, discussion about the  
> operational realities of attempting to deploy DNSSEC including trust  
> anchor issues and IANA's role.  As a (arguably) direct result, we're  
> now 12 years into deployment and have gotten minimal traction.  It  
> would be tragic to repeat that particularly sad history with RPKI.   
> Presumably, the goal here is to get something that can actually be  
> deployed...

There are of course many possible reasons for this rather sad state of  
affairs in DNSSEC, but I must admit that I find it rather difficult to  
believe that a lack of an IETF debate on this topic would be at the  
heart of this particular saga (DNSSEC).

> governance officials during the plenary and when it becomes a topic  
> of discussion and not necessarily in a good way (I'm told) at the  
> IGF).  The ant mound has already been stirred.  Pretending you're  
> not covered in honey is unlikely to have a positive outcome.

I'm sorry, but I'm completely unaware of this circumstance you are  
reporting here. However, I suppose that it is illustrative of the  
state of affairs we live in these days where these matters enjoy such  
political sensitivity.

>
>
> If you wish to argue that the treatment of trust anchors should not  
> be in the res-certs draft, that's fine as long as you follow it up  
> with 'it should be in X' (and you define 'X' :-)).  I believe it  
> important that there be an open discussion about the pros and cons  
> of the various trust anchor models and any recommendation be made in  
> a transparent manner. I reiterate my belief that if IANA is going to  
> be a participant in a trust anchor or anchors, it needs to be called  
> out explicitly in the IANA Considerations section, but that's merely  
> my opinion (like the entirety of this note).
>

I am arguing that the res-cert draft is appropriately phrased in  
making no particular call on IANA to represent itself as the "root" TA  
fpr the RPKI, and arguing that the draft is appropriate in that it  
paints the picture that the selection of TA material is a matter for  
relying parties to determine and simply describes how TA material can  
be packaged in a way that creates stable TA material. i.e. I am not  
heading down the path of saying where it should be - I am limiting  
myself to a "not here please" statement.

My related observation is pretty much the same as yours - these are  
thorny matters with many interests and perspectives. I for one don't  
see this matter being resolved by a simple SIDR WG discussion - oh no  
- thats just the opening statements in something that I fear will  
carry on, like DNSSEC, for a decade or longer.  So maybe I should just  
reconcile myself to the fact that progress on these drafts is not  
going to be glacial - its going to be geological, and I should spare  
my fingers the trouble of typing too much too early, becuase it seems  
that this particualr set of issues is going to be hanging around for  
decades, like this complete set of SIDR WG drafts. Oh what fun. not.

---

From: John Curran <[email-masked]>
Date: Fri, 5 Dec 2008 09:11:47 -0500

On Dec 5, 2008, at 5:31 AM, Geoff Huston wrote:
> making no particular call on IANA to represent itself as the "root"  
> TA fpr the RPKI, and arguing that the draft is appropriate in that  
> it paints the picture that the selection of TA material is a matter  
> for relying parties to determine and simply describes how TA  
> material can be packaged in a way that creates stable TA material.  
> i.e. I am not heading down the path of saying where it should be - I  
> am limiting myself to a "not here please" statement.

Geoff -

That indirection would be a wonderful, elegant solution to
the situation, but unfortunately in its present form it
creates much larger problem than it solves.

In particular, we need to keep in mind that the usefulness of
the RPKI system for most parties is going to be predicated
upon providing a well-understood, deterministic mechanism for
verification of assertions across the entire Internet numbering
resource space.

The ability to perform such validation is well-defined in a
world with a single PKI hierarchy covering the resource space,
and (with all due respect to drc :-) it would be understandable
if an IETF WG decided omit specification of the TA entity in
the IANA Considerations section due to the inherently political
nature of the question, and with the hope that the Trust Anchor
determination for such a system would indeed be addressed
someplace else. While this would fail to allow for immediate
implementation of the full desired functionality, advancing a
res-cert draft without the TA specified would still allow for
technical validation of the solution and insertion of the
appropriate TA once that matter had been settled "elsewhere".

However, the res-cert-15 draft sidesteps this issue instead
by introduction of the alternative of having a "trust anchor
collection"; i.e. multiple RPKI certificate hierarchies to
cover the entire Internet numbering resource space.   This
proposal of multiple PKI hierarchies for a single resource
space is completely new technical construct which lacks
definition of many desired operations such as the process
for overall assertion validation, and process for transfer
of resources between RPKI hierarchies.

As a result, the IETF is being encouraged to advance an
incomplete *technical* solution.  Even if a well-understood
and accepted set of "trust anchor collection" material is
determined elsewhere sometime in the future, it's inclusion
still leaves unaddressed how a third-party makes use of the
constellations of RPKI certificate hierarchies to come up
with a generally understood consistent answer in validation
of any given RPKI assertion, nor would it address how routine
PKI functions should be implemented between the multiple RPKI
hierarchies that have been introduced as the "solution" to the
TA specification problem.

It's not the omission of the "root" TA for RPKI which is the
issue, it's the introduction of the ill-defined technical
construct of a  "trust anchor constellation" which (IMHO) makes
the current res-cert draft fundamentally flawed.

> see this matter being resolved by a simple SIDR WG discussion - oh  
> no - thats just the opening statements in something that I fear will  
> carry on, like DNSSEC, for a decade or longer.  So maybe I should  
> just reconcile myself to the fact that progress on these drafts is  
> not going to be glacial - its going to be geological, and I should  
> spare my fingers the trouble of typing too much too early, becuase  
> it seems that this particualr set of issues is going to be hanging  
> around for decades, like this complete set of SIDR WG drafts. Oh  
> what fun. not.

The set of changes getting from res-cert-13 to res-cert-15
introduces technical ambiguity as noted above, and it seems
quite appropriate that incomplete specifications move at
glacial pace, if at all.

/John

---

From: Roque Gagliano <[email-masked]>
Date: Fri, 5 Dec 2008 12:40:01 -0200

> discussions seem to support as well.

Hi Danny,

I want to clarified that it was my understanding before the meeting  
that TA material information was going to be in the version 04 arch  
document (that was the issue that I raised in the 11/17 email),  
however during the IETF73 version 15 of the cert-profile came out and  
included that information.

As we discussed at the SIDR meeting, we should avoid having  
information duplicated in different documents and as arch document  
should not have formating information, the cert profile doc should  
then be the correct place to have this information.

So, I do not have an open point on this issue.

Regards,
Roque

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Dec 2008 14:56:35 -0500

At 2:08 AM -0500 12/4/08, John Curran wrote:
>extensions defined in this specification that MUST be followed. 
>These encoding rules serve the following purposes. First, they 
>result in a unique encoding of the extension's value; two instances 
>of an extension can be compared for equality octet-by-octet. 
>Second, they achieve the minimal size encoding of the information. 
>Third, they allow relying parties to use one-pass algorithms when 
>performing certification path validation; in particular, the relying 
>parties do not need to sort the information, or to implement extra 
>code in the subset checking algorithms to handle several boundary 
>cases (adjacent, overlapping, or subsumed ranges)."

John,

I'm not sure what you mean by "multiple valid assertions." If you 
mean multiple ROAs that identify different AS'es, then that is an 
allowed outcome, as I believe Randy has separately noted. If the ROAs 
all can be validated, then they are all equally "good" in the eyes of 
the RPKI model. This is true whether we have one TA or multiple TAs.

It think the point to which you may be alluding is that if we have 
the five RIRs and IANA as TAs, then a mismatch between IANA's 
allocation database and the database of any RIR, or between the 
databases of any RIRs, will not automatically be detected by the RFC 
3779 path validation mechanism.  That observation is correct, but 
there's more ...

I once proposed developing software to detect conflicting allocations 
(sub-allocations). The proposed was shot down by folks who argued 
that transfer of address space among users would cause too many false 
positives to make detection mechanisms worthwhile. Thus, even if we 
were to adopt a model where IANA is the only default TA, lower tiers 
in the nominal hierarchy can still make mistakes that result in 
conflicts. The limitation imposed by the 3779 path validation 
criteria is that such errors are limited to the set of resources held 
by the CA in question. So, if we adopt a model with IANA as the only 
root, we do reduce the range of errors that can result in conflicting 
allocations, but we do not prevent all such (potential) conflicts.

I can think of ways to help relying parties to detect possible 
IANA/RIR and RIR/RIR allocation conflicts in a model where both RIRs 
and IANA are TAs, but, as noted above, we have to remember that this 
will not deal with all such conflicts.

Finallly, we have to remember that, ultimately, each RP gets to make 
its own TA choices. We are offering a default (or putative) set of 
TAs as part of the architecture, but we cannot mandate which entities 
each relying party will select. Also, ISPs that use RFC 1918 
addresses and choose to make use of the RPKI, they will need to 
(locally) override the public address space hierarchy anyway.

Steve

P.S.  Irrespective of my analysis above, yes, I do prefer a 
singly-rooted PKI, with IANA as the only TA, but I can live with a 
set of TAs so long as I can count them on my fingers, and they all 
are authoritative for the resources in question :-).
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Heather Schiller <[email-masked]>
Date: Tue, 09 Dec 2008 11:07:54 -0500

Stephen Kent wrote:
> singly-rooted PKI, with IANA as the only TA, but I can live with a set 
> of TAs so long as I can count them on my fingers, and they all are 
> authoritative for the resources in question :-).

Steve, That's the concern -- what happens if 2 RIR's assert authority to 
the same resource?

   --Heather

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 9 Dec 2008 12:09:05 -0500 (Eastern Standard Time)

On Tue, 9 Dec 2008, Heather Schiller wrote:

> Stephen Kent wrote:
>> 
>> Steve
>> 
>> 
>> P.S.  Irrespective of my analysis above, yes, I do prefer a singly-rooted 
>> PKI, with IANA as the only TA, but I can live with a set of TAs so long as 
>> I can count them on my fingers, and they all are authoritative for the 
>> resources in question :-).
> Steve, That's the concern -- what happens if 2 RIR's assert authority to the 
> same resource?

That was my interpretation of John's concern, too.

I believe that part of the freedom granted to relying parties ("granted" 
because there's no way to prevent them) is not only that relying parties 
are free to choose their trust anchors, but also that the relying parties 
are free to say what they trust their trust anchors to speak 
authoritatively for.

So the relying parties can take care to ensure that they do not grant 
overlapping authority to their trust anchors.  It should be the case that 
relying parties who mess that up, mess themselves up, not other people.

--Sandy

---

From: Heather Schiller <[email-masked]>
Date: Tue, 09 Dec 2008 13:38:39 -0500

Sandra Murphy wrote:
>> Steve, That's the concern -- what happens if 2 RIR's assert authority 
>> to the same resource?
> 
> are free to choose their trust anchors, but also that the relying 
> parties are free to say what they trust their trust anchors to speak 
> authoritatively for.
> 
> overlapping authority to their trust anchors.  It should be the case 
> that relying parties who mess that up, mess themselves up, not other 
> people.
> 
> --Sandy
> 
> 
> 

It sounds like you are suggesting that it is up to the operator to 
decide who is authoritative for a set of resources.  This seems 
illogical because the operator doesn't control the resources and who is 
authoritative for them.  Deciding which RIR should be authoritative for 
a resource is non trivial and should not be left up to individual 
operators.  Appointing a single TA - and having it delegate downward 
resolves this conflict.  ..alternatively find some other way to ensure 
that multiple TA's can not have a conflict.

--Heather

---

From: k claffy <[email-masked]>
Date: Tue, 9 Dec 2008 19:33:33 -0800

On Tue, Dec 09, 2008 at 12:09:05PM -0500, Sandra Murphy wrote:
  On Tue, 9 Dec 2008, Heather Schiller wrote:
  >>PKI, with IANA as the only TA, but I can live with a set of TAs so long 
  >>as I can count them on my fingers, and they all are authoritative for the 

zoinks.  that seems like an awful lot of trust to take
out of the architecture and put back into the oft
overtired or overworked or counterincented fingers sidr 
is trying to secure against.  are you still going with
'secure' in the title?

another problem, this relatively radical change in the
architecture turns a whole class of people who are guaranteed
to be proponents of sidr (like caida, whose research it will
make easier because it will reduce the amount of work we have
to do to resolve addresses to science) into people whose lives
sidr will make much harder for little benefit.

so, you at least have some marketing issues. 

but i see even deeper problems.  it now sounds like a dlv-based
bgp, and afaict for the same reasons.  geoff explains to drc:

        carry on, like DNSSEC, for a decade or longer.

as justified as that fear is, i can't imagine widespread support
for pulling another IPv6 to avoid pulling another DNSSEC.  
(i'm no DNSSEC fan, but we should acknowledge that the root is
closer to getting signed than it's ever been (thanks to meatspace
governments recognizing the alternatives are worse), while
IPv6 still doesn't even have any scalable routing architecture
to even talk about deploying.  but i asked vixie to tune in
here, since he no doubt has some hard-earned wisdom from tilting
at dlv that is relevant.)
seems to me we've got a long history of 'let's leave that
(economic/ownership/trust) part of this problem for some set
of people who is not us' in recent ietf attempts to retrofit
societal needs back into the Internet architecture, and scant
evidence that even the designers are happy with the results.
i agree that the trust architecture merits a separate draft,
but i don't see a good case for postponing that draft.  especially
since geoff and others are pushing hard for the RIRs to allow for 
legitimate sale of ipv4 addresses to the highest bidder, asap.
if we're gonna turn the economic and the ownership 
architectures for IP addresses upside down at the same time,
we'd best make the trust architecture exceedingly clear.

k

---

From: Geoff Huston <[email-masked]>
Date: Wed, 10 Dec 2008 19:12:08 +1100

On 10/12/2008, at 3:07 AM, Heather Schiller wrote:

> Stephen Kent wrote:
>> Steve
>> P.S.  Irrespective of my analysis above, yes, I do prefer a singly- 
>> rooted PKI, with IANA as the only TA, but I can live with a set of  
>> TAs so long as I can count them on my fingers, and they all are  
> Steve, That's the concern -- what happens if 2 RIR's assert  
> authority to the same resource?
>

WG chair hat off

And no I'm not Steve either. :-)

There is no protection anywhere in the RPKI to prevent overlap as an  
intrinsic property of the RPKI in the case where a single issuer may  
certify the same resource to two different entities simultaneously.  
Certificates do not generally prevent this situation of overlap.

And in some cases this may be a feature rather than a bug. When you  
consider the case of a transfer of resources between two entities it  
may be prudent to certify the new entity with the resources while the  
old entity is also certified with the resources in order to allow  
relying parties to synchronise their local cached state of the  
distributed repository with the new entity's certified resources  
before the CA revokes the old entity's certificate that included the  
transferred resources.

As far as I can tell certificates cannot provide any particular  
"protection in terms of duplication. The protection, and assurance, is  
reliant on the accuracy and integrity of the processes used by all  
involved parties in the correct and diligent administration of number  
resources. I don't see how certificates can provide any intrinsic  
protection against procedural failures - it is incumbent on the CAs  
here to be very diligent in their administration of these resources  
and ensure that their records, and their issued certificates are  
accurate.

As far as I understand the situation this statement applies  
irrespective of any particular TA model.

regards,

   Geoff

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Dec 2008 16:54:22 -0500

At 12:09 PM -0500 12/9/08, Sandra Murphy wrote:
>So the relying parties can take care to ensure that they do not 
>grant overlapping authority to their trust anchors.  It should be 
>the case that relying parties who mess that up, mess themselves up, 
>not other people.
>
>--Sandy

yes, the effects of an RP error in managing it TA info is local to that RP.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Dec 2008 16:54:22 -0500

At 1:38 PM -0500 12/9/08, Heather Schiller wrote:
>illogical because the operator doesn't control the resources and who 
>is authoritative for them.  Deciding which RIR should be 
>authoritative for a resource is non trivial and should not be left 
>up to individual operators.  Appointing a single TA - and having it 
>delegate downward resolves this conflict.  ..alternatively find some 
>other way to ensure that multiple TA's can not have a conflict.
>
>
>--Heather

Heather,

In ANY PKI, each RP is always the final arbiter of who he/she 
perceives to be authoritative. The best we can do here is to provide 
a default TA (or set of TAs), that are easy for RPs to adopt, and 
that reflect the extant resource allocation system. That's what we 
have done, almost :-).

I have a lot of exposure to attempts to create PKIs that cross 
organizations boundaries, in various parts of the world. Compared the 
other efforts with which I am familiar, this is a very, very good 
effort. We have avoided creating third parties to act as CAs. We 
don't have bridge CAs (which could not work with the 3779 path 
validation description). We're debating the downside of offering 6 
TAs, all of which are legitimate, authoritative entities in the 
resource allocation system, vs 1. I think we're pretty close.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Dec 2008 16:54:22 -0500

>authority to the same resource?

If two RIRs claim to be authoritative for the same address block, and 
if they both allocate that block to lower tier entities (e.g., ISPs), 
then certs and ROAs issued by those entities will validated by RP 
software using the default TA set. Note, though that an equivalent 
problem can arise of one RIR accidentally allocates the same block to 
two ISPs. We can't reliably detect and automatically reject this, 
because when address space transfers are in process, they look the 
same (in terms of RPKI objects).

Yes, it would be preferable if we had a way to detect inter-RIR 
conflicts when they represent errors.  There is at least one possible 
solution to this, even if both IANA and the RIRs are represented as 
"default" or "nominal" trust anchors, but it would be cleaner if IANA 
was the sole TA.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Dec 2008 16:54:22 -0500

>   are free to say what they trust their trust anchors to speak

that's correct.

>is trying to secure against.  are you still going with

yes, I am :-). The insecurity that results from an RP making errors 
primarily affects that RP, i.e., he/she is vulnerable to viewing 
invalid origin assertions as being authentic, but no other RPs suffer 
the same fate.

>sidr will make much harder for little benefit.

On what basis do you assert that there is little benefit from this 
infrastructure?

>         carry on, like DNSSEC, for a decade or longer.

I am less pessimistic that Geoff in this regard, but I do think it 
would be preferable to move forward with our 6 TA model, and work the 
politics to to enable migration to a single TA (IANA) model. It will 
be easy to make this migration if the community agrees.

>for pulling another IPv6 to avoid pulling another DNSSEC.

I don't understand this metaphor. I fear you've been hanging out with 
Randy too much :-)!

>at dlv that is relevant.)

I agree that we're getting close on IANA as the single DNSSEC root. 
This too has been a political issue, after a long technical 
development process. I am hoping we have a shorter tech development 
process for the RPKI.

>we'd best make the trust architecture exceedingly clear.

We can split off the discussion of trust anchors options and 
management into a separate I-D, if enough folks believe that will 
help.  But, I also agree with you that if we just use this document 
restructuring to defer the problem, we  are not making great progress.

Steve

---

From: Andrew Newton <[email-masked]>
Date: Fri, 12 Dec 2008 14:37:16 -0500

On Dec 11, 2008, at 4:54 PM, Stephen Kent wrote:

> If two RIRs claim to be authoritative for the same address block,  
> and if they both allocate that block to lower tier entities (e.g.,  
> ISPs), then certs and ROAs issued by those entities will validated  
> by RP software using the default TA set. Note, though that an  
> equivalent problem can arise of one RIR accidentally allocates the  
> same block to two ISPs. We can't reliably detect and automatically  
> reject this, because when address space transfers are in process,  
> they look the same (in terms of RPKI objects).
>
> conflicts when they represent errors.  There is at least one  
> possible solution to this, even if both IANA and the RIRs are  
> represented as "default" or "nominal" trust anchors, but it would be  
> cleaner if IANA was the sole TA.
>
> Steve

Steve,

I want to be sure I understand this.  The double allocation conflict  
can originate from anywhere in the tree, even from the root, right?   
So this conflict is only tangential to the nature of the trust  
anchor(s)?

-andy

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Dec 2008 16:53:25 -0500

At 2:37 PM -0500 12/12/08, Andrew Newton wrote:
>So this conflict is only tangential to the nature of the trust anchor(s)?
>
>-andy

Yes, that's right. The use of 3779 extensions does not prevent an 
authorized holder of resources from issuing two certs for a subset of 
the resources.  It does provide hard evidence of such an allocation, 
which in itself helps identify where an error was made, if indeed, 
the actions reflects an error (e.g., vs. a transfer of the resource). 
Use of CRLs also allows one to remedy an error in a highly visible 
fashion.

Steve

---

From: David Conrad <[email-masked]>
Date: Fri, 12 Dec 2008 15:02:48 -0800

On Dec 12, 2008, at 1:53 PM, Stephen Kent wrote:
>> The double allocation conflict can originate from anywhere in the  
>> tree, even from the root, right?  So this conflict is only  
>> tangential to the nature of the trust anchor(s)?
> Yes, that's right.

Sorry, I'm a bit confused, but perhaps that's because I misunderstood  
the original issue.  My reading of the issue in question is:

Assume you as an RP have accepted TAs 1 through 6 to certify blocks of  
address space they allocate and (say) TA 2 decides to certify the same  
block as TA 3.  This seems fundamentally different to me than 'further  
down the tree', i.e., either ISP X doubly allocating a block to two  
customers or ISP X and ISP Y receiving the same allocation.  In both  
of the 'further down the tree' cases, there is a parent that can  
'adjudicate' the conflict either via the chain of trust defined by the  
RPKI or via contractual relationships.  In the case of multiple TAs  
certifying the same block, no such parent exists and the RP gets a  
choice: either accept the fact that a block has been allocated to  
multiple entities and deal with it (somehow), figure out which of the  
assertions to believe from which TA, or stop believing one of the  
TAs.  None of these seem particularly appealing.

If I didn't misunderstand the issue, this seems like a potentially  
serious problem, particularly if the TAs have difficulty working/ 
playing well together (perish the thought) and/or turn out to be  
competitors in the fullness of time.

Did I misunderstand?

Regards,
-drc

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Dec 2008 10:42:15 -0500

At 3:02 PM -0800 12/12/08, David Conrad wrote:
>Sorry, I'm a bit confused, but perhaps that's because I 
>misunderstood the original issue.  My reading of the issue in 
>question is:
>
>Assume you as an RP have accepted TAs 1 through 6 to certify blocks 
>of address space they allocate and (say) TA 2 decides to certify the 
>same block as TA 3.  This seems fundamentally different to me than 
>'further down the tree', i.e., either ISP X doubly allocating a 
>block to two customers or ISP X and ISP Y receiving the same 
>allocation.  In both of the 'further down the tree' cases, there is 
>a parent that can 'adjudicate' the conflict either via the chain of 
>trust defined by the RPKI or via contractual relationships.  In the 
>case of multiple TAs certifying the same block, no such parent 
>exists and the RP gets a choice: either accept the fact that a block 
>has been allocated to multiple entities and deal with it (somehow), 
>figure out which of the assertions to believe from which TA, or stop 
>believing one of the TAs.  None of these seem particularly appealing.
>
>serious problem, particularly if the TAs have difficulty 
>working/playing well together (perish the thought) and/or turn out 
>to be competitors in the fullness of time.
>
>Did I misunderstand?
>
>Regards,
>-drc

David,

You are correct that in the case of a duplicate allocation by any 
entity farther down the tree, there is a single entity (the CA in 
question) that can resolve the conflict. However, from the 
perspective of relying party software, the problem is the same, i.e., 
the conflicting assertions (certs and ROAs) both validate.  I thought 
that was the focus of the question.

As you note, if two RIRs issue conflicting certs, and both are TAs, 
then the out-of-band resolution of the conflict requires cooperation 
across organizational boundaries. If the community agrees that 
records maintained by IANA re allocation of address blocks to RIRs 
are the preferred way to avoid/resolve such conflicts, then certs 
issued by IANA to the RIRs, reflecting such allocations, would 
provide a solution (at least from the RP software perspective).  Note 
that such certs could be issued by IANA even if each RIR is a 
"default" TA, and used by RP software as an independent check on the 
consistency of the RPKI TA certs issued by RIRs to themselves.

Steve

---

From: Danny McPherson <[email-masked]>
Date: Mon, 15 Dec 2008 14:35:09 -0700

>  Note that such certs could be issued by IANA even if each RIR is a  

Steve,
Can you expand upon this comment?  Would this be a normal
model to operate or is there some offshoot?

Somewhat related...

Here's one of my issues with multiple RIRs being TAs.  Some
RIRs invest much more heavily in security than others, and NONE
currently have an operational role in routing on the Internet
(this talk of weekends, holidays, et al., illustrates the issue).

If someone were to launch a targeted attack they could first
compromise the least secure RIR (TA), and then they can do what
they wish and affect ANY resource, right?.  Whereas, with a single
TA model, the attack surface would only involve a single RIR and
IANA up my validation path, is that correct?  What other factors
should be considered here?

What about security of the repository in a multi-TA model, are
there things that should be considered there?

-danny

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Dec 2008 09:31:02 -0500

At 2:35 PM -0700 12/15/08, Danny McPherson wrote:
>>"default" TA, and used by RP software as an independent check on 
>>the consistency of the RPKI TA certs issued by RIRs to themselves.
>
>Steve,

This is definitely a special case. In a "normal' RP environment, 
there would be no provision to perform this sort of cross check. I 
fairness, however, use of the 3779 extension in path validation is 
not supported by most RPs anyway, so the RPKI is special. Also, since 
we see a need to provide tools to enable an RP to manage TAs to allow 
for use of RFC 1918 addresses (locally), it would be simple to add 
this cross check into such code.

>should be considered here?

I agree with your analysis. Having RIRs be TAs without a cross check 
capability does increase the overall system vulnerability, for the 
reasons you cited above.

>there things that should be considered there?

I don't think the repository system incurs significant additional 
risks due to adoption of a multi-TA model, since each RIR seems like 
a "natural" host for repository data  for its members. Also, we put 
in a number of safeguards (based on data being signed by the 
cognizant authorities, typically ISPs) to minimize the risks posed by 
attacks against repositories But I admit to not having looked into 
this issue closely.

Steve