Subject: [sidr] WG Chair Affiliation

From: Geoff Huston <[email-masked]>
Date: Sun, 6 Sep 2009 12:32:52 +1000

WG Co-chair Hat ON

There has been some discussion in the wg chairs list about disclosure  
of affiliation of the WG chairs to the WG.

For the record, I would like to note here that I am employed by APNIC,  
the regional internet registry for the Asia Pacific region. APNIC is  
not in receipt of any funding or grant that is associated with the  
activities being undertaken by this working group, as far as I am aware.

    Geoff Huston

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Sep 2009 09:12:51 -0700

geoff,

since you bring up the subject, which is conflict of interest, not
specifically chair affiliation, excuse me for being my normal tactful
self :).

in the ivtf, many folk do work that concerns their employer, someone has
to pay the costs [0].  it is not whether the emoloyer gets their income
by renting integers (and hopes to get it from renting certificates[1]),
or by selling hardware or software, or by contracting to concerned
users, or by selling gifs of naked furries.

the issue is document authors letting their own and their perception of
their employer's interests override the expressed concerns and consensus
of other wg members and, at the same time, using the wg chair position
as a pulpit for those interests.

randy

---

[0] - http://archive.psg.com/051000.ccr-ivtf.pdf

[1] - what i have seen in the sidr wg has driven me into the group which
      is extremely concerned about the rirs controling routing given
      their clear lack of altruism for the health of the internet.

---

From: David Conrad <[email-masked]>
Date: Fri, 11 Sep 2009 14:53:32 -0700

Hi,

I choose not to get into discussions of conflict of interest aspect of  
this thread as I prefer to remain naive and assume folks are doing  
what they believe is in the best interests of the Internet over the  
long term.  However, I'd like to use a footnote from Randy's note to  
ask what I'm guessing is a stupid question:

>      their clear lack of altruism for the health of the internet.

I, perhaps more than most, have had the recent 'joyful' experience of  
trying to get a security system that has a hierarchical trust model  
actually deployed.  Suffice it to say, it is a non-trivial exercise in  
non-technical negotiation.  From my perhaps biased perspective it  
would seem that while conceptually and technically, hierarchical trust  
models are nice and elegant and simple, they do NOT easily map into  
political and economic realities which are decidedly non- 
hierarchical.  As a result, deployment has required a tremendous  
amount of time and thrust to actually make appreciable forward progress.

So, here we are, coming up with yet another security system with a  
hierarchical trust model (whether there is one root or five or six is  
irrelevant).  However, in this case and as I understand it,  
implementation of this particular security system can (note: not must)  
imply the root or roots has, as Randy notes, the ability to _control  
the routing system_, potentially in real time.

I will admit some skepticism that this will be remotely acceptable,  
either in a political or business sense.  As such, I have to assume I  
misunderstand something fundamental about the intent or trust model of  
SIDR. Could someone enlighten me why enterprises, ISPs, or governments  
who are NOT the roots of this system won't recoil in horror at even  
the idea that their parents, grandparents, great-grandparents, etc. in  
the trust hierarchy potentially could, by intent, whim, or error,  
instantly and completely remove their ability to send/receive Internet  
traffic[1]?

Thanks,
-drc

[1] Note that the actual accuracy of this statement is not  
particularly relevant since there will be folks who will spin the  
capabilities of the system in this way.

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 13 Sep 2009 20:15:36 -0400

In message <[email-masked]>
David Conrad writes:
[ trimmed ]
>  
> Could someone enlighten me why enterprises, ISPs, or governments  

Hi David,

Maybe they'd be OK with this because they are already dependent on DNS
where their parents, grandparents, great-grandparents, etc. in the
[hierarchy] potentially could, [screw up].

DNS has at times been victum of error at or near the top level.

Are you expecting a new round of conspiracy theories?

Curtis

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 13 Sep 2009 22:13:01 -0400

On Fri, Sep 11, 2009 at 5:53 PM, David Conrad <[email-masked]> wrote:
> I, perhaps more than most, have had the recent 'joyful' experience of trying
> to get a security system that has a hierarchical trust model actually
> deployed.  Suffice it to say, it is a non-trivial exercise in non-technical
> negotiation.  From my perhaps biased perspective it would seem that while
> conceptually and technically, hierarchical trust models are nice and elegant
> and simple, they do NOT easily map into political and economic realities
> which are decidedly non-hierarchical.  As a result, deployment has required
> a tremendous amount of time and thrust to actually make appreciable forward
> progress.

Today, in some respects, there is a hierarchy in place for the routing
system, the RADb/IRR datasets which are used to generate route
filters. Hopefully the 'next best thing' will include some bits to
easily verify authorization to announce/use the address blocks in
question, something slightly more accurate than:

route:      216.239.63.0/24
descr:      REACH (Customer Route)
tech-c:     RRNOC1-REACH
origin:     AS24077
remarks:    This auto-generated route object was created
remarks:    for a REACH customer route

vs:

route:      216.239.63.0/24
descr:      Google
origin:     AS15169
notify:     [email-masked]
mnt-by:     MAINT-AS15169
changed:    [email-masked] 20090902
source:     RADB

which one should be used? Today you don't really know so happily AS24077:
aut-num:      AS24077
as-name:      TMHK-Transit-AS-HK-AP
descr:        TMHK Global Transit
country:      HK
person:       Raymond Tong
nic-hdl:      RT236-AP
e-mail:       [email-masked]

Can happily announce a bunch of things that aren't theirs to announce
:( oops... In the first stage of 'tomorrow-tomorrow-land' hopefully
we'll be able to distinguish who's the right origin-AS. In the next
stage we may even be able to tell what AS-PATH's are proper.

> I will admit some skepticism that this will be remotely acceptable, either
> in a political or business sense.  As such, I have to assume I misunderstand
> something fundamental about the intent or trust model of SIDR. Could someone
> enlighten me why enterprises, ISPs, or governments who are NOT the roots of
> this system won't recoil in horror at even the idea that their parents,
> grandparents, great-grandparents, etc. in the trust hierarchy potentially
> could, by intent, whim, or error, instantly and completely remove their
> ability to send/receive Internet traffic[1]?

I'm not sure there's a good answer to this, today we all depend upon
some level of trust with the 'IRR system' which we don't have any real
contractual relationship with, save individual relationships with
'RADb' the others (alt-db, l3-db, reach-db...) all are blindly
trusted. Tomorrow we'd have some relationship (hopefully) with an RIR
(which we have today, save legacy folk). Yes,  the RIR's of the world
will have to step up and provide bullet-proof services, potentially
scaled up far more than what's in place today, and potentially
geographically dispersed, diverse and redundant...

-chris

---

From: David Conrad <[email-masked]>
Date: Mon, 14 Sep 2009 12:58:20 -0700

Curtis,

> [hierarchy] potentially could, [screw up].

The DNS model is somewhat different than what I understand is being  
proposed here.  The folks who manage the top-level (under contract to  
the US government) can merely make requests to change the top-level,  
they do not actually control it.  There are also explicit statements  
that the national level resources (that is, ccTLDs) are considered  
sovereign and the top-level manager can not (under terms of the  
contract with the USG as well as by practices and polices that require  
in-country representation) do anything not explicitly requested by the  
representatives of the nation (more or less -- who the representatives  
are is a bit grey).  The folks who actually control the top-level (an  
independent party to the manager, again under a USG contract), are  
explicitly prohibited from making any change that isn't explicitly  
requested by the manager.  And then there are the folks who actually  
publish the changes who are yet another independent party.

In other words, there is no single entity with 'skin in the game' that  
has control over the top-level.

With SIDR, again as I understand it (and I'm looking forward to being  
corrected), the idea is to have 1 or 5 or 6 trust anchors that are  
administered by the allocating authorities who both manage the top- 
level as well as control the top-level.  There isn't a clear national- 
level analog (that is, there aren't national-level blocks), and the  
only parties being discussed as being involved in administration are  
non-governmental.

Let me simplify this by trying a scenario to see if I understand  
things. Suppose the UK government decides it is inappropriate (for  
whatever reason) to pay the RIPE fees associated with maintenance of  
51/8 (for sake of argument, assume such fees exist).  In the world of  
SIDR, with certificates which can be used to (at least) derive filters  
of good vs. bad blocks of addresses, RIPE can now cause 51/8 to be  
filtered out from any ISP's routing configuration (assuming they auto- 
generate filters from SIDR-based information).

Is this scenario accurate?

> Are you expecting a new round of conspiracy theories?

Expecting: most definitely.  But more to the point, experiencing  
already: yes.

Regards,
-drc

---

From: John Schnizlein <[email-masked]>
Date: Mon, 14 Sep 2009 16:05:26 -0400

David,

What you may be looking for is Steve Kent's Trust Anchor Management  
presentation (and the errata slide 13) - the last items in the SIDR  
materials from IETF 75.

https://datatracker.ietf.org/meeting/75/materials.html

John

On 2009Sep14, at 3:58 PM, David Conrad wrote:

> With SIDR, again as I understand it (and I'm looking forward to  
> being corrected), the idea is to have 1 or 5 or 6 trust anchors that  
> are administered by the allocating authorities who both manage the  
> top-level as well as control the top-level.

---

From: Terry Manderson <[email-masked]>
Date: Tue, 15 Sep 2009 09:51:36 +1000

Hi John,

While I appreciate the work by Steve here to allow a relying party to  
put on the rose coloured validation glasses, it is an inside view  
looking out. That means is allows an organisation to locally say what  
it believes is the RPKI view of the world irrespective of what is said  
globally.

So it certainly has its place - but doesn't address David's position  
completely where an organisation, such as the UK government, might  
wish to validly assert their own independent trust anchor for their  
51/8 SIDR hierarchy and have the rest of the relying parties on the  
internet collect it and validate routes against it. Perhaps some focus  
needs to be placed on truly dealing with multiple (>6) trust anchors  
in a sense where some globally recognised trust anchor repository  
might exist and TAs are vetted for correctness of both the TA's 3779  
extensions and the organisation mooting ownership in some open,  
transparent, and unbiased mode. In this fashion, if an organisation  
(say UK) did wish to secede from RIPE, they could still be a party to  
the global (trusted) routing system by having their own valid and  
recognised TA.

Cheers
Terry

On 15/09/2009, at 6:05 AM, John Schnizlein wrote:

>> being corrected), the idea is to have 1 or 5 or 6 trust anchors  
>> that are administered by the allocating authorities who both manage  
>> the top-level as well as control the top-level.
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Sep 2009 21:03:41 -0400

At 9:51 AM +1000 9/15/09, Terry Manderson wrote:
>Hi John,
>
>While I appreciate the work by Steve here to allow a relying party 
>to put on the rose coloured validation glasses, it is an inside view 
>looking out. That means is allows an organisation to locally say 
>what it believes is the RPKI view of the world irrespective of what 
>is said globally.

Terry,

I think you misunderstand the nature of trust anchors in PKIs.  No 
entity can force all relying parties adopt the entity as a TA, 
period. The acceptance of a TA is always a local matter, if the 
software is properly designed. For example, in most of my browsers I 
can choose to remove the many self-signed CA certs that the browser 
vendor has chosen to present to me as TAs. Only if the user (RP) is 
forced to use software that fails to offer such choices does a third 
party have an ability to impose it's view of who is and is not a TA. 
This "sphere of influence" notion is applicable in some contexts, but 
it is not applicable to all the ISPs in the world.

So, rather than characterizing the local TA management model that I 
presented as "rose coloured validation glasses" I would say that it 
is a realistic representation of what  RPs ought to be able to do, 
and what they will be able to do with the RP software that BBN will 
make available in open source form.

>internet collect it and validate routes against it.

The problem is that nobody, including the UK gov, can ensure that 
every ISP in the world will recognize it as a TA, period. The sooner 
folks get past tjis notion the faster we can have meaningful 
discussions on this topic.

Steve

---

From: Terry Manderson <[email-masked]>
Date: Tue, 15 Sep 2009 11:42:46 +1000

Hi Steve,

On 15/09/2009, at 11:03 AM, Stephen Kent wrote:

> This "sphere of influence" notion is applicable in some contexts,  
> but it is not applicable to all the ISPs in the world.
>

I see slight differences in the RPKI, in that we have overlap and  
uniqueness issues. I agree that no one can force any replying party to  
use any particular single or set of trust anchors. But lets say two  
entities near this sphere of influence have the same prefix in their  
TA which filters down to two contradictory ROAs. How does a relying  
party make that "TA use" statement? How do they reasonably or  
programmatically decide? Does your software help them choose which is  
true? Or is this just a position of the RPKI is TA value agnostic? And  
if that is so, should the drafts be made to reflect that? Last time I  
looked there were numerous references to the IANA->RIR->etc hierarchy  
and technically that is fine - but I think misses David's scenario.

> make available in open source form.

As I said.. I think it is good work. excuse my glib remark, I didn't  
mean to marginalize it. More as a representation of what a relying  
party receives and interprets in BGP and in RPKI versus what is  
announced (by them) and published in RPKI repositories (by them).

>
>> So it certainly has its place - but doesn't address David's  
>> position completely where an organisation, such as the UK  
>> government, might wish to validly assert their own independent  
>> trust anchor for their 51/8 SIDR hierarchy and have the rest of the  
>> relying parties on the internet collect it and validate routes  
>> against it.
>
> every ISP in the world will recognize it as a TA, period.

Sure. But if we are looking for a qualitative trust statement of TAs,  
where does one look? Or don't we? Is this just not a problem to care  
about?

> The sooner folks get past tjis notion the faster we can have  
> meaningful discussions on this topic.
>

Any discussion that helps clarify a situation or lack of understanding  
is meaningful.

Terry

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Sep 2009 22:34:34 -0400

Let me start by saying a couple of positive things:
1) In order to even start on securing this space, we are going to need 
some sort of certificates
2) As far as I can tell, in order for the certificates to make any sense 
they have got to be related to the hierarchy of address assignment. 
(Private addresses are a different matter.

SO I do think the approach we are on is the right approach.

But, Steve, I think you are misunderstanding the issue David Conrad 
raises.  (What follows is my understanding of what he pointed out, and I 
could also be confused.)

If there is such a hierarchy, tehn, look at what happens from a leaf ISP 
down the tree.  They need to reliably be able to advertise their routes, 
and have everyone trust their advertiseements if they sign with the key 
they registered.
Given the scope, this almost inherently requires that there be a single 
(or may a small number of disjoint) starting point.  Otherwise, 
receivers will not have access to and trust of the chains.
But now turn it around.  Suppose that ISP is unsure as to whether they 
actually trust the hierarchy.  Or even if they trust it now, they are 
concerned that with a political change, they might not trust the 
situation then.  Yes, you can argue that the ISP can register with 
whomever they like.  But that is only useful if there is trust chain 
that other people believe between them and that whomever.

This turns into a massive political and public relations pain.

I don't know a better answer.
But ignoring this dimension of the deployment problem will not serve us 
well.

Yours,
Joel

Stephen Kent wrote:
> entity can force all relying parties adopt the entity as a TA, period. 
> The acceptance of a TA is always a local matter, if the software is 
> properly designed. For example, in most of my browsers I can choose to 
> remove the many self-signed CA certs that the browser vendor has chosen 
> to present to me as TAs. Only if the user (RP) is forced to use software 
> that fails to offer such choices does a third party have an ability to 
> impose it's view of who is and is not a TA. This "sphere of influence" 
> notion is applicable in some contexts, but it is not applicable to all 
> the ISPs in the world.
> 
> presented as "rose coloured validation glasses" I would say that it is a 
> realistic representation of what  RPs ought to be able to do, and what 
> they will be able to do with the RP software that BBN will make 
> available in open source form.
> 
> 
> The problem is that nobody, including the UK gov, can ensure that every 
> ISP in the world will recognize it as a TA, period. The sooner folks get 
> past tjis notion the faster we can have meaningful discussions on this 
> topic.
> 
> Steve
> 
> 
> ------------------------------------------------------------------------
>

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 15 Sep 2009 00:16:27 -0400

In message <[email-masked]>
David Conrad writes:
[.. snip, sorry ..]
> Is this scenario accurate?

I haven't a clue.  :-)  I'm out of the layer 8 loop.

My understanding is that an entity with a very large address space
would be entitled to run their own registry.  If it were run the way
the IRR was intended to be run, then anyone with a significant amount
of address space could appeal to ARIN or ICANN or Jon Postel, or just
the other registries to form yet another registry.  Since providers
have to agree to used it (no small hurdle) if address space isn't at
least as cheap as domain names, then it probably won't get any
support.  Natious would not count for anything but their own
infrastructure unless they were providing Internet services and
suballocating.

Address space should also have consistent rules and consistent pricing
from the little guy looking for a /27 for the rack mounts in their
basement to the big providers and nations.  The most important rule is
"no hoarding" - no allocation for addresses that might be used later
but that can't be justified today.  But this is not a techincal
problem and the WG chair would be justified in declaring this
discussion out of scope.  (Hi Goeff, Sandy - had enough yet?)

What ever happended to IPv6?  Is routable address space available to
meer mortals yet?

> Expecting: most definitely.  But more to the point, experiencing  

Sorry to hear that.  Not much has changed in that regard.

As you know there were almost never conspiracy theories or even so
much as ill words spoken regarding the NSFNET program.  :-)

> -drc

Best regards,

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 15 Sep 2009 00:22:30 -0400

In message <[email-masked]>
> https://datatracker.ietf.org/meeting/75/materials.html

Its in a vendor proprietary format.

Never trust anyone that uses vendor proprietary formats.  :-)

Curtis

---

From: Andrei Robachevsky <[email-masked]>
Date: Tue, 15 Sep 2009 09:28:12 +0200

David Conrad wrote on 14-09-2009 21:58:
[...]

> Let me simplify this by trying a scenario to see if I understand things.
> Suppose the UK government decides it is inappropriate (for whatever
> reason) to pay the RIPE fees associated with maintenance of 51/8 (for
> sake of argument, assume such fees exist).  In the world of SIDR, with
> certificates which can be used to (at least) derive filters of good vs.
> bad blocks of addresses, RIPE can now cause 51/8 to be filtered out from
> any ISP's routing configuration (assuming they auto-generate filters
> from SIDR-based information).
> 

IMO, this is unlikely to happen. However, reclamation of address space
is a common practice in the RIR world already today. It happens
according to the address allocation policies. The point here is that any
changes in holdership of the address space are happening in the registry
plane and RPKI is simply a reflection of such changes. May be
potentially more efficient than a whois database or an IRR, but pretty
much the same.

Andrei

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Sep 2009 09:02:25 -0400

>Never trust anyone that uses vendor proprietary formats.  :-)

Oh, I am soooo hurt.  Would PDF be OK, despite it's proprietary 
nature? If you require ASCII art you'll have a very long wait :-).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Sep 2009 11:25:03 -0400

Joel,

My reply was to specific comments made by Terry, not David's message. 
David's message was at a higher level. My response (which I did not 
send) to the question David stated is no, the SDIR model does not 
assume that IANA or the RIR control routing any more than they do 
today. They allocate addresses and ASNs, and the RPKI just takes info 
form the databases maintained by these organizations and represents 
them in a digitally signed format. This format enables ISPS and other 
address space holders to generate signed assertions about what ASNs 
are authorized to originate routes. Thus the issuance of certs by 
IANA and the RIRs enables ISPs (and others) to improve certain 
aspects of routing secruity IF they choose to make use of these certs 
as part of route verification processes.

Nonetheless, I will reply to the comments you made.

>...
>If there is such a hierarchy, tehn, look at what happens from a leaf 
>ISP down the tree.  They need to reliably be able to advertise their 
>routes, and have everyone trust their advertiseements if they sign 
>with the key they registered.

access and trust are both necessary, but are addressed by somewhat 
different mechanisms.

>Given the scope, this almost inherently requires that there be a 
>single (or may a small number of disjoint) starting point. 
>Otherwise, receivers will not have access to and trust of the chains.
>But now turn it around.  Suppose that ISP is unsure as to whether 
>they actually trust the hierarchy.  Or even if they trust it now, 
>they are concerned that with a political change, they might not 
>trust the situation then.  Yes, you can argue that the ISP can 
>register with whomever they like.  But that is only useful if there 
>is trust chain that other people believe between them and that 
>whomever.

I note that there are multiple IRR databases, not just the ones 
operated by the RIRs. Those databases require ISPs (RPs in the RPKI 
context) to learn (via out-of-band means) where to find these 
databases to download the RPSL objects. That is analogous to the RPKI 
situation.

The RPKI design allows very substantial distribution of the RPKI 
data, and the inclusion of URLs in the certs makes it possible to 
discover locations "below" publication points that an RP accepts as 
authoritative. So, the repository side of TA management calls for RPs 
to select TAs and then follow the pointers from those certs. 
Pesonally, I hope that the RIRs offer to host data for their members, 
and sub-allocations, etc. and that most RPs will elect to use those 
registries, at least as starting points. But, a suspicious RP has 
other options.

Your last sentence (above) is correct (despite ending prematurely 
:-)) but it is also a fundamental characteristic of any hierarchic 
system when users of the system want to make provisions to "trust" 
alternatives to the default hierarchy. I think the RPKI design does a 
better job of architecting how to do this than most such systems. A 
few users probably will be sufficiently concerned about misbehavior 
that they will make alternative publication/certification 
arrangements. But, I doubt that this will be true of the vast 
majority of users.

>But ignoring this dimension of the deployment problem will not serve us well.

This is not being ignored. My presentation on how to perform local TA 
management was targeting this issue, and I have received very 
positive feedback from several folks saying that this goes a long way 
toward addressing their concerns. I think the painful experience that 
David noted with regard to DNSSEC root issues is influencing the RPKI 
design.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Sep 2009 11:53:37 -0400

Terry,

>uniqueness issues. I agree that no one can force any replying party 
>to use any particular single or set of trust anchors. But lets say 
>two entities near this sphere of influence have the same prefix in 
>their TA which filters down to two contradictory ROAs. How does a 
>relying party make that "TA use" statement? How do they reasonably 
>or programmatically decide? Does your software help them choose 
>which is true? Or is this just a position of the RPKI is TA value 
>agnostic? And if that is so, should the drafts be made to reflect 
>that? Last time I looked there were numerous references to the 
>IANA->RIR->etc hierarchy and technically that is fine - but I think 
>misses David's scenario.

In the local TA management scheme I described, an RP gets to specify 
the set of resources it believes is associated with a given key 
(cert). The software enables an RP to assert what it "knows" to be 
true, overriding what the repositories and the putative TAs may 
assert. So, if there is a conflict relative to the info that the RP 
says it knows to be true, what the RP says it knows to be true 
prevails (locally). If the conflict arises at a point that is below a 
cert that the RP ad adopted as a TA, and if the RP has no other info 
about the resources in question, then no, the software can't help 
with such a problem problem.

I think references to the IANA->RIR->... hierarchy are appropriate 
for describing the extant allocation process. Moreover, it is 
appropriate to note that the RPKI is designed to mimic that 
hierarchy. It is also important to note that the choice of TAs is 
always a local matter.  If folks want, I can prepare an 
(informational) I-D that describes one way of managing TA locally, as 
per my presentation at the SIDR meeting.

>>>trust anchor for their 51/8 SIDR hierarchy and have the rest of 
>>>the relying parties on the internet collect it and validate routes 
>>>against it.
>>
>Sure. But if we are looking for a qualitative trust statement of 
>TAs, where does one look? Or don't we? Is this just not a problem to 
>care about?

Statements about perceived trust in TAs are useful in PKIs that 
anoint 3rd parties as TAs, independent of real world authorization. 
The RPLI is not such a PKI. Instead it seeks to have the real world 
entities that manage allocation of resources act as CAs. I would urge 
us to NOT try to make the RPKI into a trusted 3rd party PKI.

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 17 Sep 2009 08:59:06 -0400 (Eastern Daylight Time)

On Mon, 14 Sep 2009, Joel M. Halpern wrote:

> 1) In order to even start on securing this space, we are going to need some 
> sort of certificates
> 2) As far as I can tell, in order for the certificates to make any sense they 
> have got to be related to the hierarchy of address assignment. (Private 
> addresses are a different matter.
>

That's good.

>
> But, Steve, I think you are misunderstanding the issue David Conrad raises. 
> (What follows is my understanding of what he pointed out, and I could also be 
> confused.)
>
> If there is such a hierarchy, tehn, look at what happens from a leaf ISP down 
> the tree.  They need to reliably be able to advertise their routes, and have 
> everyone trust their advertiseements if they sign with the key they 
> registered.

I'm not sure what you mean by "the key they registered".

When an ISP receives an address allocation, the allocater signs a cert 
associating that address with a public key, and that public key can come 
the ISP.  Is that what you mean by "the key they registered"?  The cert is 
more a "registration" of the address than it is the registration of the 
key.

> Given the scope, this almost inherently requires that there be a single (or 
> may a small number of disjoint) starting point.  Otherwise, receivers will 
> not have access to and trust of the chains.
> concerned that with a political change, they might not trust the situation 
> then.  Yes, you can argue that the ISP can register with whomever they like. 
> But that is only useful if there is trust chain that other people believe 
> between them and that whomever.

What do you mean about not trusting the hierarchy?  The RPKI hierarchy 
represents the hierarchy of address allocation in a cryptographically 
assured manner.  Are you saying that at some point an ISP might not trust 
the hierarchy by which it receives addresses?

I have difficulty conceiving of a (global) mechanism for allocating 
addresses that would not be hierarchical.  So I think that an ISP that 
was not sure it trusted the address allocation hierarchy would be in a 
difficult state.

I recognize that there is an fear that this system somehow puts ISPs under 
someone's control.  I would answer that there is not any more control than 
is already the case.

We need to emphasize that the cryptography here is just improving the 
assurance of address relationships that already exist.

If there start to be Cert-R-Us signers of RPKI certificates (so "the ISP 
can register with whomever they like"), that statement will no longer be 
true, which would be a very bad thing for the trust model.  As you note.

--Sandy

> This turns into a massive political and public relations pain.

Yep.

> But ignoring this dimension of the deployment problem will not serve us well.

I agree whole-heartedly that we need to keep deployment in mind in all 
our design!

Easing into the current operational practice is important, for one thing.

--Sandy

>>> While I appreciate the work by Steve here to allow a relying party to put 
>>> on the rose coloured validation glasses, it is an inside view looking out. 
>>> That means is allows an organisation to locally say what it believes is 
>>> the RPKI view of the world irrespective of what is said globally.
>> 
>> Terry,
>> 
>> I think you misunderstand the nature of trust anchors in PKIs.  No entity 
>> can force all relying parties adopt the entity as a TA, period. The 
>> acceptance of a TA is always a local matter, if the software is properly 
>> designed. For example, in most of my browsers I can choose to remove the 
>> many self-signed CA certs that the browser vendor has chosen to present to 
>> me as TAs. Only if the user (RP) is forced to use software that fails to 
>> offer such choices does a third party have an ability to impose it's view 
>> of who is and is not a TA. This "sphere of influence" notion is applicable 
>> in some contexts, but it is not applicable to all the ISPs in the world.
>> 
>> realistic representation of what  RPs ought to be able to do, and what they 
>> will be able to do with the RP software that BBN will make available in 
>> open source form.
>> 
>> 
>>> completely where an organisation, such as the UK government, might wish to 
>>> validly assert their own independent trust anchor for their 51/8 SIDR 
>>> hierarchy and have the rest of the relying parties on the internet collect 
>>> it and validate routes against it.
>> 
>> The problem is that nobody, including the UK gov, can ensure that every ISP 
>> in the world will recognize it as a TA, period. The sooner folks get past 
>> tjis notion the faster we can have meaningful discussions on this topic.
>> 
>> Steve
>> 
>>

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 17 Sep 2009 09:54:12 -0400 (Eastern Daylight Time)

> infrastructure unless they were providing Internet services and

Anyone who receives an RPKI certificate to go with their address 
allocation can run their own CA (the rough analogy to a registry).  When 
they sub-allocate addresses, they *should* issue certificates to go with 
it.  (If they don't want their customer to multi-home, then they don't. 
Giving a certificate grants the right to use the address, including 
the right to authorize others to route the address.)

If we have a rooted hierarchy, then people just need to know the root(s), 
and use of the CAs below it comes as part of the package.

Prices for address allocations are not affected by the RPKI.

> discussion out of scope.  (Hi Goeff, Sandy - had enough yet?)

Address allocation policies are a part of the RIR system in response to 
their membership.

The RPKI has no effect on allocation policies - those policies should be 
discussed in your local RIR.  Discussion of address allocation policies 
are not in scope for sidr (*) (That's a wg chair statement, if you are 
looking for one.)

--Sandy

(*) unless a policy in some way impacts the resource certificates.  Can't 
think of a way that could happen, but who knows.

---

From: Andrei Robachevsky <[email-masked]>
Date: Thu, 17 Sep 2009 16:39:22 +0200

Stephen Kent wrote on 16-09-2009 17:53:
[...]
> 
> Statements about perceived trust in TAs are useful in PKIs that anoint
> 3rd parties as TAs, independent of real world authorization. The RPLI is
> not such a PKI. Instead it seeks to have the real world entities that
> manage allocation of resources act as CAs. I would urge us to NOT try to
> make the RPKI into a trusted 3rd party PKI.
>

I agree. However, I envisage a scenario when the RP in your local TA
management scheme announces itself globally as a root CA/TA. And then
the question arises how one can distinguish between these ersatz RPKIs
and associated stuff (repositories, ROAs, etc.)?

Andrei

---

From: David Conrad <[email-masked]>
Date: Thu, 17 Sep 2009 09:05:52 -0700

Sandy,

On Sep 17, 2009, at 5:59 AM, Sandra Murphy wrote:
> I recognize that there is an fear that this system somehow puts ISPs  
> under someone's control.  I would answer that there is not any more  
> control than is already the case.

I suppose it depends on what people are going to do with RPKI.  Today,  
RIR influence on routing is essentially advisory in nature -- if an  
address holder (say) fails to pay their address maintenance fee, RIRs  
can, at most, remove the address holder's blocks from whois  
databases.  However, as I understand it, this has limited effect on  
existing contractual relationships between the address holders and the  
folks who already announce their space (it may have more effect on  
address holders who are attempting to find new ISPs to announce their  
space).  The RIR could potentially reallocate the space, but this  
would likely be a good way of annoying multiple parties (not just the  
folks the address space was reclaimed from).

If RPKI does not change this, then you're right -- there is not any  
more control. However, if filter lists are built or routers check  
origin authenticity in real-time by traversing the RPKI tree(s), there  
would seem to be significantly more control vested in each parent node  
in the path up to the root of the RPKI hierarchy.  My fear is that  
this will simply be unacceptable in a political or business sense.

Regards,
-drc

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 17 Sep 2009 15:25:33 -0400 (Eastern Daylight Time)

On Thu, 17 Sep 2009, David Conrad wrote:

> I suppose it depends on what people are going to do with RPKI.  Today, RIR 
> influence on routing is essentially advisory in nature -- if an address 
> holder (say) fails to pay their address maintenance fee, RIRs can, at most, 
> remove the address holder's blocks from whois databases.  However, as I 
> understand it, this has limited effect on existing contractual relationships 
> between the address holders and the folks who already announce their space 
> (it may have more effect on address holders who are attempting to find new 
> ISPs to announce their space).  The RIR could potentially reallocate the 
> space, but this would likely be a good way of annoying multiple parties (not 
> just the folks the address space was reclaimed from).

Andrei's message acknoledged that address reclamation is a part of RIR 
daily life.  He did not explicitly mention re-allocation to a different 
party, but I can't imagine holding on to unused address space, 
particularly in this current era of address-shortage fears.

>
> If RPKI does not change this, then you're right -- there is not any more 
> control. However, if filter lists are built or routers check origin 
> authenticity in real-time by traversing the RPKI tree(s),

Those who build filter lists either rely on their customers' reports or on 
IRR data, which is based on the RIR address allocations.

>                                                     there would seem to 
> be significantly more control vested in each parent node in the path up to 
> the root of the RPKI hierarchy.  My fear is that this will simply be 
> unacceptable in a political or business sense.

Political and business fears don't have to be rooted in technical truth, 
unfortunately.

It is up to us to make sure people understand who this relates to current 
familiar common practice.

--Sandy

---

From: Randy Bush <[email-masked]>
Date: Fri, 18 Sep 2009 06:56:04 +0900

> Prices for address allocations are not affected by the RPKI.

given that at least some RIRs are exploring how and what to charge for
certs, this is a bit naive.

randy

---

From: Terry Manderson <[email-masked]>
Date: Fri, 18 Sep 2009 12:32:27 +1000

Hi Steve,

On 17/09/2009, at 1:53 AM, Stephen Kent wrote:
> true, overriding what the

"knows" == "believes" ;-)

> repositories and the putative TAs may assert. So, if there is a  
> conflict relative to the info that the RP says it knows to be true,  
> what the RP says it knows to be true prevails (locally). If the  
> conflict arises at a point that is below a cert that the RP ad  
> adopted as a TA, and if the RP has no other info about the resources  
> in question, then no, the software can't help with such a problem  
> problem.

right, so the software isn't currently intended to traverse the  
'assimilated relying party rpki' to pick out conflicts. nor highlight  
that in terms of the TA set chosen by the relying party. (I'm saying  
that is a deficiency, just thinking aloud)

> (informational) I-D that describes one way of managing TA locally,  
> as per my presentation at the SIDR meeting.

I think I would like to see such an I-D.

>> TAs, where does one look? Or don't we? Is this just not a problem  
>> to care about?
>
> entities that manage allocation of resources act as CAs. I would  
> urge us to NOT try to make the RPKI into a trusted 3rd party PKI.
>

while I agree the intent isn't to make a 3rd party PKI, won't that  
happen anyway? At least I see it as likely, irrespective of the  
allocation resource hierarchy.

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Fri, 18 Sep 2009 14:02:41 +1000

Sandy and David,

On 18/09/2009, at 5:25 AM, Sandra Murphy wrote:

>>> I recognize that there is an fear that this system somehow puts  
>>> ISPs under someone's control.  I would answer that there is not  
>>> any more control than is already the case.
>>
>> I suppose it depends on what people are going to do with RPKI.   
>> Today, RIR influence on routing is essentially advisory in nature  
>> -- if an address holder (say) fails to pay their address  
>> maintenance fee, RIRs can, at most, remove the address holder's  
>> blocks from whois databases.  However, as I understand it, this has  
>> limited effect on existing contractual relationships between the  
>> address holders and the folks who already announce their space (it  
>> may have more effect on address holders who are attempting to find  
>> new ISPs to announce their space).  The RIR could potentially  
>> reallocate the space, but this would likely be a good way of  
>> annoying multiple parties (not just the folks the address space was  
>> reclaimed from).
>
> Andrei's message acknoledged that address reclamation is a part of  
> RIR daily life.  He did not explicitly mention

For some class of address holders in some regions, I believe that  
reclamation is not possible (historical?). Are they outside of the  
scope of the RPKI?

> re-allocation to a different party, but I can't imagine holding on  
> to unused address space, particularly in this current era of address- 
> shortage fears.
>

I suspect that the time from reclamation to deaggregation and  
reallocation will progressively grow smaller.

>> origin authenticity in real-time by traversing the RPKI tree(s),
>

I think it goes deeper based on draft-pmohapat-sidr-pfx- 
validate-02.txt finding its way _into_ routers.

> Those who build filter lists either rely on their customers' reports  
> or on IRR data, which is based on the RIR address allocations.

I think Chris's past email regarding  216.239.63.0/24 suggests that  
the various IRRs aren't that tightly bound.

Cheers
Terry

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 18 Sep 2009 08:19:23 -0400 (Eastern Daylight Time)

Curtis was suggesting if address space is not as cheap as domain names, 
then this scheme would not be used.

I picked up on the point that the RPKI does not effect address allocation 
fees.  Which it doesn't.

But Randy has addressed Curtis's point more accurately, as Curtis was 
speaking of the RPKI as if it were a registry, so his comment about 
pricing was probably directed to certs, not addresses.

I would hope that the RIRs would not charge for certs separately from 
charging fees for address allocations.  The RPKI will work best if *ALL* 
address allocations have a corresponding cert.  If that turns out to be a 
cost to the recipient, we're likely to see people who choose not to get 
the corresponding cert.  That would IMHO be a bad thing.

--Sandy

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Sep 2009 13:23:33 -0400

At 12:32 PM +1000 9/18/09, Terry Manderson wrote:
>>In the local TA management scheme I described, an RP gets to 
>>specify the set of resources it believes is associated with a given 
>>key (cert). The software enables an RP to assert what it "knows" to 
>>be true, overriding what the
>

yes, believes is more accurate, but that's why I put the "knows" in quotes :-).

>>adopted as a TA, and if the RP has no other info about the 
>>resources in question, then no, the software can't help with such a 
>>problem problem.
>
>'assimilated relying party rpki' to pick out conflicts. nor 
>highlight that in terms of the TA set chosen by the relying party. 
>(I'm saying that is a deficiency, just thinking aloud)

We were told over a year ago that, because of legitimate transfers, 
looking for duplicates was bad idea, in the repository system.  So, 
I'm not sure if we want to do it in the 'assimilated relying party 
rpki.'

>I think I would like to see such an I-D.

OK, we'll look into generating one.

>allocation resource hierarchy.

One cannot prevent 3rd parties from asserting themselves as TAs, but 
the CP does not accommodate such entities as CAs, nor does the 
repository system facilitate their use. The local TA management 
proposal deals only with LOCAL perceptions of TAs. If an organization 
wants to promote it's (local) view of TAs to others, it is up to that 
entity to develop the necessary tools to do so, and to convince 
others to make use of these tools. I think that represents a 
reasonable tradeoff between allowing local TA management and 
encouraging 3rd party TAs.

Steve

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 19 Sep 2009 19:03:12 -0400

> nature? If you require ASCII art you'll have a very long wait :-).

Steve,

PDF is fine.

<aside>

AFAIK Adobe does publish its formats, xpdf and other readers work, and
open software can usually write PDF, always without a license.  Adobe
has always allowed for free software.  If memory servers me, the open
software community continued to use postscript until Adobe loosenned
restrictions.

It is too bad that IETF has not been as vigalent regarding slides as
with drafts and RFCs.  The XML rfc index is a real improvement.  XML
as an rfc input format doesn't seem to be used often AFAIK and it
should.  DocBook might be good for slides if open tools were more
mature.

</aside>

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 19 Sep 2009 20:45:05 -0400

In message <[email-masked]>
> then this scheme would not be used.

Truly competitive and/or reasonably priced would be a more accurate
translation of "like domain names".

> I picked up on the point that the RPKI does not effect address allocation 

There is an odd problem with address allocation (that might also be
out of scope for SIDR).  If there are multiple places to get addresses
from (truly competitive) then aggregation may be affected.  Perhaps
having a small number but more than one within a geographic region
would serve both goals.  This does not affect the PKI.

> pricing was probably directed to certs, not addresses.

At the top level address allocation and registry are the same thing.
So if certs are issued with addresses CA and registry is the same at
that level.  [We are going down a politically charged rat hole.]

> the corresponding cert.  That would IMHO be a bad thing.

Free cert with your address would be nice.  A reasonable price would
be acceptable.  Again, a layer 8 problem.  And out of scope.  Sorry.

Curtis

---

From: Randy Bush <[email-masked]>
Date: Sun, 20 Sep 2009 12:56:48 +0900

> be acceptable.  

expiration and revocation are serious issues and, as the rirs' claws
continue to uncloak, a very serious worry.

randy

---

From: Sandra Murphy <[email-masked]>
Date: Sun, 20 Sep 2009 06:34:01 -0400 (Eastern Daylight Time)

On Sat, 19 Sep 2009, Curtis Villamizar wrote:

> be acceptable.  Again, a layer 8 problem.

If it is a price paid by an increased cost to an allocation, that's one 
thing.  If it is a price paid by opting in to an optional feature, that's 
very different, and unpleasant in impact to the RPKI.  Not our business to 
argue the price model, but the impact is.

>                                           And out of scope.  Sorry.

The problems of partial deployment (not everyone has a cert for their 
address) are within scope for the wg, I'd say.

There might be different ways of dealing with partial deployment when it 
was viewed as a temporary problem (eventually everone will covert from 
BGP3 to BGP4, etc) versus when it was viewed as a permanent condition and 
too common to be dismissed.

--Sandy

---

From: [email-masked]
Date: Sun, 20 Sep 2009 10:30:18 -0400

> continue to uncloak, a very serious worry.

Hi Randy,

You've been making cryptic comments like this, about RIR misfeasance/ 
malfeasance, for over two years now (or at least that's when I first  
noticed them).
Could you explain what you mean, exactly, and what this worry is based  
on, specifically?

Thanks,

Tom

---

From: Randy Bush <[email-masked]>
Date: Sun, 20 Sep 2009 23:47:16 +0900

> malfeasance, for over two years now (or at least that's when I first  

excuse.  please show where i have alledged malfeasance.  otherwise, do
not put words in my keyboard.

randy

---

From: [email-masked]
Date: Sun, 20 Sep 2009 11:35:50 -0400

> On Sep 20, 2009, at 10:30 AM, [email-masked] wrote:
>
>>
>> You've been making cryptic comments like this, about RIR  
>> misfeasance/malfeasance, for over two years now (or at least that's  
>> when I first noticed them).
>> Could you explain what you mean, exactly, and what this worry is  
>> based on, specifically?
>>
>> Thanks,
>>
>> Tom
>>
>
> On Sep 20, 2009, at 10:47 AM, Randy Bush wrote:
>

I should have known better than to provide such an easy diversionary  
option ;-)
If I mischaracterized your views, please accept my sincere apologies.

Allow me to rephrase:

1. Which RIR "claws" are you referring to, exactly?
2. How have those claws been "cloaked" to date, specifically, and  
what's enabling you to see through that cloak more clearly now?
3. What is the exact nature of the "very serious worry" that this  
development has instilled in you?

Thanks,

TV

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Sun, 20 Sep 2009 12:22:16 -0400

I had a hard time figuring out where to “chain” this message, so I
stuck it here...

Let’s take a step back please.

What is the purpose of RPKI/SIDR? Is it to enforce allocation
policies? Or is it to prevent “bad guys” from spoofing routing
advertisements for the purpose of various forms of malfeasance?

I do believe these are separate problems.

If it is for enforcing allocation policies, it effects the balance of
power between the various actors. Today if there is a legal dispute
between an allocator and an organization with an allocation, it will
be solved through existing civil means. This may take some time. In
the meantime the status quo continues (from a technical/operational
perspective). With RPKI the allocator can revoke the organizations
certificate, while the civil process takes its time, causing harm to
the organization that is now un-routable. Don’t think they won’t do
the revocation. I have personally seen situations where if one party
has “the switch” to enforce their will, they use it.

On the other hand if it is to prevent “bad guys” from spoofing
routing, then the trick is to design it so that is doesn’t effect the
balance of power between the various *legitimate* actors. Judging from
the conversations I have seen, I suspect we don’t have a system that
doesn’t effect the balance of power.

In my opinion, it is a good idea to work on not changing the balance
of power. That may require that the allocation agencies *not* be part
of the key hierarchy.

                        -Jeff

--
========================================================================
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[email-masked]
========================================================================

---

From: Terry Manderson <[email-masked]>
Date: Mon, 21 Sep 2009 16:15:59 +1000

> I'm not sure if we want to do it in the 'assimilated relying party  

So legitimate transfers will breed duplicates? My recollection of that  
discussion that there would be timing in place that certificate  
validity times would be tuned (with sparse use of CRLs) to effect the  
transfers. Or am I mistaken?

I think, if anywhere you needed to go looking for duplicates it would  
be the relying party software (either your software or rcynic) before  
it mades it to the router "decision"

> OK, we'll look into generating one.

:-)

> repository system facilitate their use.

If your software can change the contents of the 3779 extensions, would  
it not be a simple exercise to change the SIA value?

Cheers
Terry

---

From: Basil Dolmatov <[email-masked]>
Date: Mon, 21 Sep 2009 15:24:34 +0400

Stephen Kent пишет:
>  If 
> folks want, I can prepare an (informational) I-D that describes_ one_ 
> way of managing TA locally, as per my presentation at the SIDR meeting.

Folks want.

It would be a nice reference point and would save a lot of explanations 
in future deployment.

dol@

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 21 Sep 2009 10:41:58 -0400 (Eastern Daylight Time)

> advertisements for the purpose of various forms of malfeasance?

I don't believe that any one is trying to enforce allocation policies. 
Policies are not mentioned at all in the PRKI.

Certainly allocation actions are embodied in the RPKI, but not the 
policies that guided them.

> of power. That may require that the allocation agencies *not* be part

We decided way back that the authorization to originate a route to a 
prefix must come from the prefix holder.  And that identification of a 
prefix holder comes from the entity that allocated the prefix.

Which decision are you recommending that we change - that we find a source 
of authorization to originate routes to a prefix *other than* the prefix 
holder?

Or that we find a way to identify the prefix holder *other than* through 
the entity that allocated them the prefix?

--Sandy

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Mon, 21 Sep 2009 11:02:01 -0400

On Mon, Sep 21, 2009 at 10:41:58AM -0400, Sandra Murphy wrote:
> prefix must come from the prefix holder.  And that identification of
> a prefix holder comes from the entity that allocated the prefix.

Who is the “We” in this case? If it is the working group, then I
suggest that a broader consensus is required.

The problem with hierarchies is that people then assume that they are
strict. The guy “higher up” is “in charge” and the guy lower down can
do nothing but accept what is promulgated. In the real world, things
are quite different. Sure, allocations are initially made by an
appropriate registry. However some allocations pre-date the existing
registration system and exactly where they sit is unclear. Then there
are business disputes that always occur. My point is that adding RPKI
can change the dynamics of these interactions, and not necessarily in
a good way.

I believe we need a solution which provides “security” against bad
actors while minimizing the impact on the business dynamics.

I purposely didn’t propose a solution, but I can...

Perhaps the RPKI CA’s should explicitly *not* be the registration
authorities (or perhaps they can be, but that there should also be a
non-affiliated CA that can issue trusted certificates).

Much like it is today with web site certificates. The CA’s do *not*
have to be the DNS registrars for the domain name. Instead the CA uses
WHOIS data to determine if it is appropriate to issue a particular
certificate. Similarly an RPKI CA can consult WHOIS data (or radb
data) to determine the information it needs to issue a certificate.

In this fashion if a dispute happens between the registration
authority and the customer, the registration authority cannot use
certificate revocation (or failure to renew a certificate) as a “tool”
to enhance its negotiating position. Keep in mind that just because an
organization is a registration authority, doesn’t mean that in a given
dispute it is “right” automatically! As Hagrid said: “Not all wizards
are good!” (sorry, couldn’t help myself :-) ).

                        -Jeff

P.S. I am not claiming that the solution I propose is the only one, or
even the best one, but I believe it impacts the business relationships
between the registration authorities and their customers less then if
the registration authorities were also the CA’s (or otherwise in a
position to fail to renew a certificate or revoke an existing
certificate).

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Mon, 21 Sep 2009 11:15:17 -0400

Just to clarify.

On Mon, Sep 21, 2009 at 10:41:58AM -0400, Sandra Murphy wrote:
> prefix must come from the prefix holder.

I agree.

> And that identification of a prefix holder comes from the entity
> that allocated the prefix.

I agree, however I believe it is important that the “entity that
allocated the prefix” should not be in a position to unilaterally make
the prefix unroutable by the prefix holder after the allocation is
complete.

                        -Jeff

---

From: "Ruediger Volk, Deutsche Telekom T-Com - TE141-P1" <[email-masked]>
Date: Mon, 21 Sep 2009 18:38:50 +0200

Hi Jeff,

you are right that concerns for securing the allocation data
and the operational use of routing authorization are different -
even when the routing authorization has to build on the allocation data
(hierarchy).

The concerns for operational use of routing authorization need more attention.

you wrote:
  > I agree, however I believe it is important that the "entity that
  > allocated the prefix" should not be in a position to unilaterally make
yes, this seems to be a crucial concern of operators.
So far I see two factors to deal with it:

(1) agree on policies for operating the RPKI that only allows revocation
(2) muck with the revocation mechanism/implementation

I think both factors should be used: (1) to make explicit the intended rules
and have them implemented most of the time
and (2) as a safety belt against "errors" and interference from whatever
parties...

I guess (2) means that some non standard variation of PKI needs to be invented;
how painful is that going to be for PKI folks?

Other question:
Operators see "uncontrolled" revocation of the authorization chain as
a threat to using the RPKI to control routing.  Are there other
relevant threats?
So far I found only "revocation" and "unexpected expiration";
where "unexpected expiration" should be dealt with by avoiding short
expiration times and processes for advance expiration checking and reminders
(without mucking around with the protocol).

Ruediger

Ruediger Volk

Deutsche Telekom AG -- Internet Backbone Engineering

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 21 Sep 2009 14:01:14 -0400 (EDT)

On Sun, 20 Sep 2009, Jeffrey I. Schiller wrote:

> ... Judging from the conversations I have seen, I suspect we don?t 
> have a system that doesn?t effect the balance of power.
>

Jeff,

I think this WG (and others) have been proceeding with the idea of 
having the RIRs in the key heirarchy because it's logically 
simpler: the key heirarchy would map the business relationships 
present in the allocation heirarchy.

Trying to not upset the balance of power, while a great idea, might 
require mapping the current power structure and possibly establishing 
some more interactive relationships between the participants in it.

Do you have any good ideas of where to start?

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 21 Sep 2009 14:03:45 -0400 (EDT)

> control than is already the case.

David Conrad already responded to this, pointing out the technical 
possibilities.

I think it's also instructive to look back at the message that started 
this thread (also from David Conrad), which astutely observes:

"... their parents, grandparents, great-grandparents, etc. in the 
trust hierarchy potentially could, by intent, whim, or error, 
instantly and completely remove their ability to send/receive Internet 
traffic[1]?
...
[1] Note that the actual accuracy of this statement is not 
particularly relevant since there will be folks who will spin the 
capabilities of the system in this way."

However the system IS used, I'm sympathetic to David's concern that 
the potential for control could be a barrier to deployment.  Which 
leaves us with the question of how to design a system that is 
resistant to capture and control.  Or perhaps, as Jeff Schiller 
proposed, build something that doesn't change the current balance of 
power.

What would we need to do differently in the RPKI design to prevent 
capture and control?

-- Sam

---

From: Andrei Robachevsky <[email-masked]>
Date: Mon, 21 Sep 2009 20:19:17 +0200

Samuel Weiler wrote on 21-09-2009 20:03:
> "... their parents, grandparents, great-grandparents, etc. in the trust
> hierarchy potentially could, by intent, whim, or error, instantly and
> completely remove their ability to send/receive Internet traffic[1]?
> ...
> [1] Note that the actual accuracy of this statement is not particularly
> relevant since there will be folks who will spin the capabilities of the
> system in this way."
> 
> However the system IS used, I'm sympathetic to David's concern that the
> potential for control could be a barrier to deployment.  Which leaves us
> with the question of how to design a system that is resistant to capture
> and control.  Or perhaps, as Jeff Schiller proposed, build something
> that doesn't change the current balance of power.
> 

I think, nothing. The RPKI attests to Internet resource holdings,
nothing more. The worst thing that can happen is when we cannot trust
uniqueness of address allocation.

To mitigate concerns regarding capture and control we need to shift
decision making to the ISP level as much as possible, to their routing
policy definitions. In other words, require a fallback to insecure
routing, rather than dropping the RPKI-invalid announcement off altogether.

Andrei

---

From: Robert Kisteleki <[email-masked]>
Date: Mon, 21 Sep 2009 20:41:36 +0200

Samuel Weiler wrote:
[...]
> What would we need to do differently in the RPKI design to prevent 

I'm sorry for pointing out the obvious, but in _any_ system where you 
receive a certificate from someone else -- like it or not -- that someone 
else will have the means of revoking your cert, or not renewing it. As 
simple as that. It can be an error, a bug, and (horrible dictu) abuse of 
power, the real cause ultimately doesn't really matter.

So you either certify yourself -- which is, IMO exactly as useful as not 
certifying at all --, or actually trusting your parent. So maybe the 
appropriate question is who to trust in this scenario? Someone who actually 
_knows_ what resources you hold at the moment, or someone who may have some 
idea about it, or maybe not, but definitely would _like to be_ your parent 
here for a reasonable sum?

The answer is pretty obvious to me.

Robert

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 21 Sep 2009 14:57:30 -0400

> routing, rather than dropping the RPKI-invalid announcement off altogether.

not 'require' but 'make provisions for' ... which I think is more a
router-os/router-policy-engine implementation (and customers asking
for this knob, akin to 'accept-own-as').

-chris

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 21 Sep 2009 16:39:26 -0400 (Eastern Daylight Time)

> the prefix unroutable by the prefix holder after the allocation is

I have heard many complaints from ISPs about former customers who refuse 
to return allocated address space.  For those, I believe that a way to 
un-do an allocation and to make the prefix unroutable (at least to the 
former customer) would be desireable.  Are you implying that you don't 
think that should be allowed?

Your phrase "after the allocation is complete" seems to view address 
allocation as a permanent transfer.  That is not current reality for PA 
space - are you advocating that it should be?

--Sandy

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Mon, 21 Sep 2009 18:26:23 -0400

> think that should be allowed?

I don’t believe that RPKI should be the enforcement mechanism.

> space - are you advocating that it should be?

I’ve really been thinking about non PA space. I see the appeal of RPKI
to help in cases where an organization isn’t returning space to an ISP
after a contract has terminated. I won’t go so far as to say I am
advocating that all assignments should be permanent, that’s a matter
of civil and contract law. I am saying that if RPKI is or can easily
be used as an enforcement mechanism, then there will be opposition to
its deployment.

                        -Jeff

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Mon, 21 Sep 2009 18:29:23 -0400

> power, the real cause ultimately doesn't really matter.

But in the currently deployed PKI for web certificates, you have a
choice of CA’s. If one is abusing you (makes too many errors, etc.)
you can switch to another. They are all “equal” in the end user’s
browser (I won’t go into EV certs here, that is a whole different
kettle of fish).

I believe the competition between CA’s helps level the playing field
between those issuing certificates and those purchasing them.

                        -Jeff

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 21 Sep 2009 18:49:26 -0400

> browser (I won’t go into EV certs here, that is a whole different

sure, and as it happens you can also have more than one certificate
for mozilla.com .... which is 'bad'.

> between those issuing certificates and those purchasing them.

I'm not sure that's the case, since I can go to startssl.com and get a
cert for free that's good for 1yr and doesn't raise exceptions in +98%
of the user base... or I can go to verisign get the same thing for
1k$. I'm also not sure that the web-ca world tracks at all well with
the routing-ca world.

Is some of the concern here legacy space being pulled under 'RSA' by
hook/crook? Could that be 'fixed' by IANA issuing certs to legacy
address holders as that's likely the closest thing to the NIC that
exists today and doesn't REALLY have the ability to enforce RSA-like
restrictions as an RIR would?

-Chris

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Mon, 21 Sep 2009 23:57:45 -0400

> for mozilla.com .... which is 'bad'.

Exactly how is this bad? Sure for S/MIME encryption you need to know
which certificate to encrypt a message for (though you could do it for
all of them if the number was reasonable). However for authentication
you can have many certificates with the same DN. It works just fine. I
should know, I run the PKI for MIT and on the client side people have
one certificate per computer in general (because getting one on each
computer is easier then having them figure out how to export the
certificate as a pkcs12 object and import it to the other
browser). Yes, we use X.509 certificates for client authentication.

> 1k$. I'm also not sure that the web-ca world tracks at all well with

Your statement proves my point about competition. If it weren’t for
competition you would not have the option of getting one for free, or
even cheap!

> restrictions as an RIR would?

Or we can just have a pseudo-RIR for the legacy space (pseudo because
it doesn’t allocate any new space, just keeps track of the old).

                        -Jeff

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 22 Sep 2009 00:09:50 -0400

In message <[email-masked]>

Hi Jeff,

Nice to hear from you.

Interesting idea.  But if this is a free for all, I can just declare to
the world that I have rights to 18/8?  Or maybe just the subnet that
includes ns.mit.edu.  And then I announce it and everyone believes it.

I think that is the problem we are trying to solve.  Without some form
of authoritative hierarchy we haven't solved anything.

One possibility is that providers can pick who they trust.  If a RIR
causes trouble maybe they get dropped by some providers with an
alternate considered authoritative.  This could make peer pressure a
factor, or it could fragment the web of trust and limit acceptance.

Curtis

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 22 Sep 2009 01:02:40 -0400

> Exactly how is this bad? Sure for S/MIME encryption you need to know

which www.mozilla.com did you visit? (substitute microsoft.com for
updates or bank-of-boston.com for banks..)

Yes, there should be more/better authentication from server to client
(and vice versa) but today as a client you don't know... anyway this
isn't super helpful in the route-object world, I don't think.

> browser). Yes, we use X.509 certificates for client authentication.

hurray :)

> competition you would not have the option of getting one for free, or

yes, example-fail :( sorry about that. I'm still not sure that the DNS
world makes a good example for routing.

> it doesn’t allocate any new space, just keeps track of the old).

Sure, IANA was a simple guess on my part, a pseudo-RIR seems fine to
me. Was the legacy space holder problem the only problem you had with
the RPKI as it's been discussed? (and a psuedo-RIR would satisfy your
concerns I think, right?)

-Chris

---

From: Robert Kisteleki <[email-masked]>
Date: Tue, 22 Sep 2009 09:28:22 +0200

> browser). Yes, we use X.509 certificates for client authentication.

Jeff, tell us, can your users in MIT choose another CA for client 
authentication inside MIT? Can they choose the same DN with all of them (as 
you stated above, it "works just fine")?

Robert

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Tue, 22 Sep 2009 10:41:22 -0400

> updates or bank-of-boston.com for banks..)

It doesn’t matter as long as they are all really mozilla.com. If
www.mozilla.com is a server farm behind a load balancer with each
instance having a different certificate with the same DN, does it
matter. Indeed having someone who is *not* mozilla.com have a
certificate that claims it is, is a problem!

[Note: It would be interesting to test my example above and see what
the browsers do, given its a “corner” case we don’t see in the real
internet, there may well be bugs, but that is besides the point]

What I can assert is that we have people with client side X.509
certificates (different ones, for different computers with different
keys) go to the same website all the time without problem... and have
for 12+ years!

> isn't super helpful in the route-object world, I don't think.

Actually as a client you *do* know. The problem with *knowing* which
website you are going to isn’t one of certificate hierarchy
issues. The problem has to do with fooling the ignorant user into
thinking that paypal.com.broken.into.domain.com is really PayPal etc.
Hopefully RPKI won’t have these problems because we are dealing with
route ranges and AS numbers which are interpreted by code, no humans.

> concerns I think, right?)

This is an important case, but not the only one. For example today
what happens if a route registry decides to raise its price by a
factor of 1,000. People will turn on it (and they know this). But what
happens when they raise the rate by a factor of 1,000 just for some
customers (who they perceive as having deep pockets) and use RPKI to
enforce this mandate. Sure, you can go to court.... and the legal
process will grind... while you are not routed. Now this is a
contrived example, so please don’t start criticizing it. The point is
that when you change the balance of power between parties you open the
door for various forms of abuse.

                        -Jeff

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Tue, 22 Sep 2009 10:45:55 -0400

On Tue, Sep 22, 2009 at 09:28:22AM +0200, Robert Kisteleki wrote:
> authentication inside MIT? Can they choose the same DN with all of
> them (as you stated above, it "works just fine")?

Yes, and we have at least one department that runs their own CA, so
this in fact happens.... and it isn’t a problem for us.

It doesn’t even matter if someone uses the same DN in a different CA
because we only trust a CA if it issues a DN to the correct person. So
it doesn’t matter to use if a departmental CA uses the same DN for a
person as we do... as long as it is the same person!

However, to be honest, our central IT services require a certificate
issued by us. Not because of technical issues but because of trust
issues. I can tell some interesting stories related to this, however
it would be a bit off-topic for this group.

                        -Jeff

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Tue, 22 Sep 2009 10:53:03 -0400

On Tue, Sep 22, 2009 at 12:09:50AM -0400, Curtis Villamizar wrote:
> Interesting idea.  But if this is a free for all, I can just declare
> to the world that I have rights to 18/8?  Or maybe just the subnet
> that includes ns.mit.edu.  And then I announce it and everyone
> believes it.

Well first you would have to convince a CA for RPKI that you are in
fact the legitimate holder of 18/8. Given that the CA’s should check
the WHOIS data for 18/8, they should see that you are not MIT and not
issue the cert.

Now there is always the possibility that someone will make a mistake
and issue the certificate anyway. This is but one reason why
revocation is important, so we can correct such mistakes when they
happen. If a particular CA seems to be making many mistakes, then
maybe it has its certificate revoked and we move on (better hope the
trust anchors behave!).

> factor, or it could fragment the web of trust and limit acceptance.

This is risky (and will happen). The way to avoid problem here is to
have a good set of trust anchors up front, complete with multiple
sources of certificates for each situation. In this fashion if one CA
doesn’t issue a certificate, another can.

At this end of the day, the more I think about this the more I am
beginning to believe that it is the providers (aka ISP’s) who should
run the CA’s (or an organization chartered by them). For at the end of
the day, it is the providers and their customers who are the stake
holders in this game.

From an IETF perspective, if we want RPKI to be deployed, it is the
providers that have to be sold... and selling a system that causes
them to lose control (even to a small degree) of a service which is
essential to their core business, will be a difficult sell.

                        -Jeff

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 22 Sep 2009 09:27:49 -0600

(coffee != sleep) & (!coffee == sleep)
[email-masked] gcia   

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jeffrey I. Schiller
> Sent: Tuesday, September 22, 2009 8:53 AM
> To: Curtis Villamizar
> Cc: [email-masked]
> Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation)
> 
> fact the legitimate holder of 18/8. Given that the CA's should check
Don't we all end up having to trust the same set of RIRs?
We have to trust more then just the one we choose to sign the certs.
We have to trust the set that other ISPs trust too or not accept their certs unless I am missing something here.

> doesn't issue a certificate, another can.
> 
> beginning to believe that it is the providers (aka ISP's) who should
> run the CA's (or an organization chartered by them). For at the end of
Difficult to sell is putting it mildly.
Most ISPs don't run CAs today nor do they have the infrastructure to do so.
Neither will they want to turn over any aspect of routing control to a 3rd party.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 22 Sep 2009 13:13:09 -0400

> Neither will they want to turn over any aspect of routing control to a 3rd party.

As a small correction.. VerizonBusiness does run a CA
(betrusted/baltimore-security/cybertrust)... of course, you may not
want the people who cant' get your phone bill right to control your
routing either :)

So, back on topic, if a party NOT the RIR-set runs the CAs (or many
parties not the RIRs run the CAs),  let's assume that uniqueness is
maintained in address information (singular copies of
netblock/allocation data). Some pointers/links back to the RIR
databases would have to be maintained

For grins, what about RADb running this service? (or the existing set
of IRR's) What sort of implications does this have for stability and
cleanliness of the data? Can we be anymore assured of having
up-to-date data in the CA heirarchy than we can in the current IRR
databases? If we can't be assured of that, how valuable is this new
regime?

-chris

---

From: Ryan Shea <[email-masked]>
Date: Tue, 22 Sep 2009 13:55:30 -0400

> essential to their core business, will be a difficult sell.

To some degree as v4 address space depletion continues providers holding
smaller bits of address space may view the enhancements RPKI brings as a
tool in the war on prefix hijacks.  

Although there is plenty of sense in aligning the RPKI chain of trust
with the resource allocation chain, ISPs may have concerns with the RIRs
being the trust anchors.  The incentive structure for the RIRs is
fundamentally different than that of a certificate provider like
Verisign/Thawte/CyberTrust.  If these trusted root CAs time and again
demonstrate that they are untrustworthy they lose customers, revenue,
and potentially their trusted status.  What entices an RIR toward
vigilance as they validate the supposedly authorized origin of a prefix?

Ryan Shea
Senior Engineer, Network and Info Security
Verizon Business

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Tue, 22 Sep 2009 23:25:48 -0400

On Tue, Sep 22, 2009 at 09:27:49AM -0600, Smith, Donald wrote:
> Don't we all end up having to trust the same set of RIRs?  We have
> to trust more then just the one we choose to sign the certs.  We
> have to trust the set that other ISPs trust too or not accept their
> certs unless I am missing something here.

Yep, just like the browsers which come loaded with a bunch of CA’s.

> Difficult to sell is putting it mildly.  Most ISPs don't run CAs
> today nor do they have the infrastructure to do so.  Neither will
> they want to turn over any aspect of routing control to a 3rd party.

And then there is the whole issue of how hard or easy it will be to
configure routers to actually use this stuff! Keep in mind, most ISP
engineers are not PKI experts (nor security experts!).

                        -Jeff

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Tue, 22 Sep 2009 23:29:51 -0400

> databases? If we can't be assured of that, how valuable is this new

Actually the RADb may be a very appropriate place to run a CA. Another
possibility is some subset of the existing certificate providers. They
understand the PKI stuff, they would have to develop the verification
procedures.

Btw. It isn’t clear to me that the data needs to be super clean to be
useful. It has to contain all the information needed for routes to
work, but if it has extra crud, that isn’t really a problem as long as
your goal isn’t data purity but instead making it harder for “bad
guys” to hijack blocks.

                        -Jeff

---

From: Andrei Robachevsky <[email-masked]>
Date: Wed, 23 Sep 2009 17:48:02 +0200

Ryan Shea wrote on 22-09-2009 19:55:
[...]
> vigilance as they validate the supposedly authorized origin of a prefix?

First of all, validation is performed by a relying party, for instance
an ISP. Secondly, the RIRs do not authorise the origin of a prefix, that
is done by a prefix holder. What the RIRs and LIRs and all other parties
in the chain of resource allocation do is attest to the that at the time
of issuance of a certificate the holder of the address space listed in
the extensions demonstrated possession of the private key. These basic
RPKI data can be used in other application, securing routing, for instance.

Regards,

Andrei

---

From: Ryan Shea <[email-masked]>
Date: Wed, 23 Sep 2009 20:02:29 +0000

> RPKI data can be used in other application, securing routing, for instance.

Perhaps I could clarify.  I am speaking of validation of the information
on the ROA rather than the validation of a chain of authority that
ultimately validates the prefix/origin pairs.

Please correct me if I am misunderstanding or confusing terms here.

As a hypothetical illustration, let's say that RIPE were to issue
2.2.0.0/16 over to Verizon Business (702) and we had an RPKI in place.
Let us also say for the sake of discussion that everyone agreed on RIPE
as the trust anchor for 2.0.0.0/8.  

In the world of SSL/TLS certificates our friends over at CyberTrust (for
example) have an incentive to make sure I am truly associated with the
verizonbusiness.com domain name in the CN field of my cert request
before they their stamp of approval on my certificate request (fax,
mail-from, government & employer id...).  They are doing more than
simply validating that I have the associated private key with the public
key on the cert request.  The ongoing revenue stream for CyberTrust is
directly tied to its reputation.  It has every reason to do their due
diligence and confirm that I am tied to the resource.  As a user with a
root CA store I can decide whether or not to have CyberTrust's CA in my
list.  

An RIR may not have the same incentives to verify that me and my public
key are truly associated with AS702 - so as an RP I need to think about
how much I trust that the public key associated with a ROA that comes
from this RIR.  Further, as a provider I do not have the same ability to
take my business elsewhere with regards to an RIR and allocated
resources.  As a corporation I can choose to end all associations with
CyberTrust, both as a signer of our certificates and as a trusted CA
much easier than cutting all ties with an RIR in a region I operate.
The survival of an RIR is not as intricately tied to its vigilance as
with the SSL model - that is the gist of what I am saying.

-Ryan

---

From: Robert Kisteleki <[email-masked]>
Date: Wed, 23 Sep 2009 23:14:50 +0200

> with the SSL model - that is the gist of what I am saying.

Ryan,

You are stating that only an RIR can certify a resource (which is allocated 
through that RIR). This is not true. On the contrary, _anyone_ can certify 
your resources. The question is, who will the third parties (ie. not you and 
not the certifier(s)!) trust -- the entity whose business is to _know_ who 
has those resources, or someone else?

As Steve have already explained numerous times, anyone can nominate 
themselves to be a Trust Anchor for RPKI (or any other PKI), but that's just 
a self-proclamation. Again, third parties (people who will verify stuff) 
will choose TAs, based on who they trust.

So you're absolutely free to go talk to for example Bert, and ask him to 
certify your allocation. He actually might, as he's a respected pers^H^H^H^H 
individual, everyone knows him, and he has been signing the DNS root for 
years, so he also has a good track record. I for one would trust the guys 
whose business is to manage resources, to certify those resources (no 
offense, Bert :-)

Robert