Subject: [Sidrops] comments on draft-ietf-sidrops-lta-use-cases-03.txt

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Apr 2018 16:21:52 -0400

This version of the document is exhibits improved wording, especially 
for the examples.
Thanks Randy!

I have some suggested edits to reduce the length of a few sentences, and 
provide
more precise wording.

There are critical uses of the RPKI where a local administrative and/
or routing domain, e.g. an end-user site, a particular ISP or content
provider, an organization, a geo-political region, ... may wish to
have a specialized view of the RPKI.

*There are critical use cases of the RPKI where a specialized, local **
*

*   view **of the RPKI may be required. Such views may be needed by a **
*

*   local administrative and/ ****or routing domain, e.g. an end-user 
site, **
*

*   a particular ISP or content ****provider, an organization, a 
geo-political **
*

*   region, ...*

    Someone convinces the RIR's
local court to force the RIR to remove or modify some or all of
Carol's certificates, ROAs, etc. or the resources they represent, and
the operational community wants to retain the ability to route to
Carol's network(s).There is need for some channel through which
operators can exchange local trust, command, and data collections
necessary to propagate patches local to all their RPKI views.

*Someone convinces a court asserting jurisdiction over an RIR**
******to force the RIR to remove or modify some or all of**
******Carol's certificates, ROAs, etc. Such removal or modification may**
*

*   adversely affect the resources they represent. The operational 
community*

*   wants to retain the ability to route to ****Carol's 
network(s).****There is a*

*   need for operators to be able to manage local **RPKI views, and, in 
some
*

*cases, to exchange local view modifications, to facilitate*

*continuity of routing in the face of the court-ordered changes.*

    Bob has a multi-AS network under his administration and some of those
ASs use private ([RFC1918]) or 'borrowed' address space which is not
announced on the global Internet (not to condone borrowing), and he
wishes to certify them for use in his internal routing.

*Bob administers a multi-AS network. Some of those ****ASs use private **
*

*   ([RFC1918]) or 'borrowed' address space **which is not ****announced 
on **
*

*   the global Internet. (This document does not condone such 
"borrowing", **
*

*   but it acknowledges that such behavior takes place.) Bob ****wishes 
to be **
*

*   able to use the RPKI with these address spaces, in his internal 
routing.*

    Alice is responsible for the trusted routing for a large
organization, commercial or geo-political, in which management
requests routing engineering to redirect their competitors' prefixes
to socially acceptable data.Alice is responsible for making the CA
hierarchy have validated certificates for those redirected resources
as well as the rest of the Internet.

*Alice is responsible for the trusted routing for a large**
******organization, commercial or geo-political area. Alice's management**
******requests routing engineering to redirect their competitors' prefixes**
******to "socially acceptable" data.****Alice is responsible for 
producing a*

*   local RPKI view (encompassing ALL prefixes) that accommodates her **
*

*   management's requests.*

    In these examples, it is ultimately the ROAs, not the certificates,
which one wants to modify or replace.But one probably can not
simply create new ROAs as one does not have the private keys needed
to sign them.Hence it is likely that one has to also do something
about the [RFC6480] certificates.

*In these examples, it is ultimately the affected ROAs, not the **
*

*   certificates used to verify them, that one wants to modify or replace.**
*

*However,**one generally cannot ****simply create new ROAs that can be **
*

*   validated using the EE certificates for the ROAs (because one does not*

*   have access to the requisite private keys). ****Hence it is likely 
that **
*

*   one has to do something ****about the [RFC6480] EE certificates used 
to **
*

*   validate the targeted ROAs.*

    The goal is to modify, create, and/or replace ROAs and GhostBuster
Records which are needed to present the localized view of the RPKI
data.

*The goal is to modify, create, and/or replace ROAs and GhostBuster**
******Records that are needed to present the localized view of the RPKI**
****data.*

**

    One can not reissue down from the root trust anchor at the IANA or
from the RIRs' certificates because one does not have the private
keys required.So one has to create a new trust anchor which, for
ease of use, will contain the new/modified certificates and ROAs as
well as the unmodified remainder of the Global RPKI.

*  One can not reissue signed objects under a root trust anchor at the **
*

*   IANA or the RIRs', because one does not have the required private**
******keys.****So one has to create a new trust anchor which, for 
****ease of use, **
*

*   will encompass the new/modified certificates and ROAs, as**
****well as the unmodified remainder of the Global RPKI.*

Only the first use case discussed a need for a local RPKI view to be 
propagated

to other operators. So I'm not comfortable with the wording of the last 
two paragraphs of Section 5.

Steve

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 27 Apr 2018 20:19:05 +0000

poke list in case this didn't make it through the first time.
On Tue, Apr 17, 2018 at 4:22 PM Stephen Kent <[email-masked]> wrote:

> This version of the document is exhibits improved wording, especially for
the examples.

provide

>     There are critical use cases of the RPKI where a specialized, local

>     view of the RPKI may be required. Such views may be needed by a

>     local administrative and/ or routing domain, e.g. an end-user site,

>     a particular ISP or content provider, an organization, a geo-political

>     region, ...

>     Carol's network(s).  There is need for some channel through which

>     Someone convinces a court asserting jurisdiction over an RIR
>     to force the RIR to remove or modify some or all of
>     Carol's certificates, ROAs, etc. Such removal or modification may

>     adversely affect the resources they represent. The operational
community

>     wants to retain the ability to route to Carol's network(s).  There is a

>     need for operators to be able to manage local RPKI views, and, in some

>     cases, to exchange local view modifications, to facilitate

>     continuity of routing in the face of the court-ordered changes.

>     Bob administers a multi-AS network. Some of those ASs use private

>     ([RFC1918]) or 'borrowed' address space which is not announced on

>     the global Internet. (This document does not condone such "borrowing",

>     but it acknowledges that such behavior takes place.) Bob wishes to be

>     able to use the RPKI with these address spaces, in his internal
routing.

>     to socially acceptable data.  Alice is responsible for making the CA

>     organization, commercial or geo-political area. Alice's management
>     to "socially acceptable" data.  Alice is responsible for producing a

>     local RPKI view (encompassing ALL prefixes) that accommodates her

>     management's requests.

>     which one wants to modify or replace.  But one probably can not
>     to sign them.  Hence it is likely that one has to also do something

>     In these examples, it is ultimately the affected ROAs, not the

>     certificates used to verify them, that one wants to modify or replace.

>     However, one generally cannot simply create new ROAs that can be

>     validated using the EE certificates for the ROAs (because one does not

>     have access to the requisite private keys). Hence it is likely that

>     one has to do something about the [RFC6480] EE certificates used to

>     validate the targeted ROAs.

>     Records that are needed to present the localized view of the RPKI
>     data.

>     keys required.  So one has to create a new trust anchor which, for

>     One can not reissue signed objects under a root trust anchor at the

>     IANA or the RIRs', because one does not have the required private
>     keys.  So one has to create a new trust anchor which, for ease of use,

>     will encompass the new/modified certificates and ROAs, as

propagated

> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops