Subject: [sidr] RPKI <-> allocation consistency

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 10 Aug 2012 20:45:03 +0000

speaking as regular ol' member

About allocation <-> RPKI consistency

The RPKI is a certification of resource holding.  Because the allocation databases continue to also record allocations, there's duplication of information between the RPKI and the allocation databases.

Having duplicate records of the same data always presents an issue of consistency.  We know we have this issue (have known it from the beginning), any resource certification outside the allocation system would, so we need to work on how to handle it.

Handling it is out-of-band.  Consistency will be a matter of process, to ensure that allocation actions are bound to issuance of consistent CA certificates (if and when one is issued) and vice versa.  Monitoring the two to spot inconsistencies will be another process.

Duplicates may be valid.  There may be reasons for multiple CA certificates being issued for exactly the same prefix space.  Transfer (or at least the only method of transfer discussed in the wg) would result in multiple CA certificates being issued for exactly the same prefix space, for make-before-break purposes.

We already have a potential for inconsistency.  As noted in the IAB statement on the RPKI, multiple trust anchors present a risk of conflicting certifications for the same address block.  We do not yet have a single root trust anchor.  No need for panic, the RIRs are aware and I trust they have process in mind to ensure consistency.   (This is a contentious issue - hopefully that's worded with sufficient care and balance.)  But that's another case where consistency is/will be ensured by process.

The sky's not falling, we're OK, we can do this, etc.

--Sandy, speaking as regular ol' member

---

From: Danny McPherson <[email-masked]>
Date: Wed, 22 Aug 2012 22:41:16 -0400

Admittedly, I'm not certain what triggered this, but clearly, your email to me suggests that others have expressed concern of consistency and collisions, a concern expressed by the IAB as well.  As such, I have a question below.

> We already have a potential for inconsistency.  As noted in the IAB statement on the RPKI, multiple trust anchors present a risk of conflicting certifications for the same address block.  We do not…

Sandy (or others in the know), can you shed any light on the process you have in mind to ensure consistency?  Particularly from the perspective of a prospective RP?  Pointers to process (e.g., RIR processes in the works) are fine.

Thanks, 

-danny

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 23 Aug 2012 10:21:24 -0400

> Sandy (or others in the know), can you shed any light on the process you have in mind to ensure consistency?  Particularly from the perspective of a prospective RP?  Pointers to process (e.g., RIR…

Indeed, I vaguely recall some conversations (on the list?) about the specific consistency model that the RPKI is trying to achieve.  I wasn't able to unearth the thread, but what was the conclusion?  That is, what is the consistency model that the RPKI design team is striving for?

Thanks,

Eric

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 23 Aug 2012 16:09:44 +0000

Speaking as regular ol' member

On Wednesday, August 22, 2012 10:41 PM, Danny McPherson said:

>Admittedly, I'm not certain what triggered this, but clearly, 
>your email to me suggests that others have expressed concern 
>of consistency and collisions, a concern expressed by the 
>IAB as well.  As such, I have a question below.

The trigger was some of the concerns expressed as part of the call for adoption of the grandparenting draft.  Some of the comments concerned the content, where suggestions were made of potential grandparent RPKI actions.

Note that the concerns in the email exchange were principally about inconsistencies between the RPKI and the allocation system. 

I am well aware of the IAB concerns (and thank you for leading that effort!) and refer to them later in my message.  

>
>Sandy (or others in the know), can you shed any light on the 
>process you have in mind to ensure consistency?  Particularly from 
>the perspective of a prospective RP?  Pointers to process (e.g., 
>RIR processes in the works) are fine.

IMHO (speaking as regular ol' member), the SIDR process in mind is as the IAB statement says: a single trust anchor.   The origin ops document says "It is assumed that eventually there will be a single root trust anchor for the public address space."

It has been pointed out that the CP says that 
   Each CA operating within the context of this PKI MUST employ
   procedures to ensure that each certificate it issues accurately
   reflects its records 
which is another "process in mind" about consistency of the RPKI and the allocation system.

I don't speak for the RIRs.  But the NRO has made a public request that ICANN "enter into discussions" to task ICANN with the management of the global trust anchor, which is a good step.  I have no view of the progress of that discussion.  I'd be curious to hear from anyone who does and may (is permitted to) speak of it!

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 23 Aug 2012 15:46:21 -0400

> IMHO (speaking as regular ol' member), the SIDR process in mind is as the IAB statement says: a single trust anchor.   The origin ops document says "It is assumed that eventually there will be a si…

A single trust anchor is certainly an important goal, and I think it would likely disambiguate a lot of the problems that seem to be getting raised.  However, until then why don't we still need to propose a concrete consistency processes? Is the RPKI not intended to be useful before then?

> which is another "process in mind" about consistency of the RPKI and the allocation system.

I think this is one very important point worth making some comments about, openly.  What are the current plans to help the RPKI's structure remain consistent with the allocation hierarchy?  Saying something like the above seems to be tantamount to simply charging each participant with the responsibility to try really really extra super hard to be a good citizen.  However, as an RP, that's clearly cold comfort.  Without outlining a transparent and rigorous process, how can consumers (the RPs) ever hope to have faith that the structure defined by the RPKI has any meaningful correlation with the actual allocation hierarchy?  I think this needs to be outlined more clearly, or the overall RPKI design needs some rework in order to obviate the need for the specification of these unspecified processes.

Eric

---

From: Stephen Kent <[email-masked]>
Date: Sat, 25 Aug 2012 05:19:19 -0400

Eric,

The short answer to your question is that each CA is supposed to ensure 
that the certs it issues match its allocation database. This applies to 
both cert issuance and cert revocation. A quick look at the RPKI RFCs 
provides a few examples of statements about the RPKI consistency model.

Steve
-----

RFC 6487 (Certificate Profile)

Intro:

Resource certificates are to be used in a manner that is consistent

with the RPKI Certificate Policy (CP) [RFC6484].*They are issued by*

*entities that assign and/or allocate public INRs, and thus the RPKI*

*is aligned with the public INR distribution function.*

*The specific goal for the associated RPKI is to precisely match the INR*

*allocation structure through an aligned certificate structure*

*that describes the allocation and its context within the INR*

*distribution hierarchy.*

RFC 6484 (RPKI CP)

Overview

*This PKI is designed to support validation of claims by current*

*holders of INRs, in accordance with the records of the organizations*

*that act as Certification Authorities (CAs) in this PKI.*

**

Section 3.3.2.Identification and Authentication for Re-Key after Revocation

*Each CA operating within the context of this PKI MUST employ*

*procedures to ensure that each certificate it issues accurately*

*reflects its records with regard to the organization to which the CA*

*has distributed the INRs identified in the certificate.**The specific*

*procedures employed for this purpose MUST be described by the CPS for*

*each CA.*

Section 3.4.Identification and Authentication for Revocation Request

procedures to ensure that:

*oan organization requesting revocation is the legitimate holder of*

*the certificate to be revoked.*

o*each certificate it revokes accurately reflects its records with*

*regard to the organization to which the CA has distributed the*

*INRs identified in the certificate*.

Section 4.2.2.Approval or Rejection of Certificate Applications

*Certificate applications MUST be approved based on the normal*

*business practices of the entity operating the CA, based on the CA's*

*records of INR holders.*

---

From: Eric Osterweil <[email-masked]>
Date: Mon, 27 Aug 2012 14:07:01 -0400

Thanks Steve, this is very helpful!

However, I was also referring to the consistency model as viewed by the RPs.  I think this wasn't clear in my email, sorry.  Clearly the structure served by CAs (which you outlined below) is a critical first step.  To that point, I think I mentioned some of this in a follow-on email to this thread.  However, I think the consistency model of the RPs (i.e. will they all have the same view/time ordered view/partial view/etc. of these certs) is an important consideration too, right?

Eric

On Aug 25, 2012, at 5:19 AM, Stephen Kent wrote:

> Eric,
> 
> The short answer to your question is that each CA is supposed to ensure that the certs it issues match its allocation database. This applies to both cert issuance and cert revocation. A quick look at the RPKI RFCs provides a few examples of statements about the RPKI consistency model.
> 
> Steve
> -----
> 
>    with the RPKI Certificate Policy (CP) [RFC6484].  They are issued by
>    entities that assign and/or allocate public INRs, and thus the RPKI
>    is aligned with the public INR distribution function.
>  
>    The specific goal for the associated RPKI is to precisely match the INR
>    allocation structure through an aligned certificate structure
>    that describes the allocation and its context within the INR
>    distribution hierarchy.
>  
>  
>  
>  
> RFC 6484 (RPKI CP)
>  
> Overview
>  
>  
>    This PKI is designed to support validation of claims by current
>    holders of INRs, in accordance with the records of the organizations
>    that act as Certification Authorities (CAs) in this PKI.
>  
>  
> Section 3.3.2.  Identification and Authentication for Re-Key after Revocation
>  
>    reflects its records with regard to the organization to which the CA
>    has distributed the INRs identified in the certificate.  The specific
>    procedures employed for this purpose MUST be described by the CPS for
>    each CA.
>  
>  
> Section 3.4.  Identification and Authentication for Revocation Request
>  
>    o  an organization requesting revocation is the legitimate holder of
>       the certificate to be revoked.
>  
>    o  each certificate it revokes accurately reflects its records with
>       regard to the organization to which the CA has distributed the
>       INRs identified in the certificate.
>  
> Section 4.2.2.  Approval or Rejection of Certificate Applications
>  
>    Certificate applications MUST be approved based on the normal
>    business practices of the entity operating the CA, based on the CA's
>    records of INR holders.
> 
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Aug 2012 00:23:04 -0400

Eric,

It seems likely that not all RPs will have the same view of INR 
allocation, e.g., due to differences
in when RPs fetch data from repositories. This seems analogous to the 
transient inconsistencies that
ISPs see today if they use IRR or other INR data sources, for similar 
reasons.

I think Rob Austein has referred to the repository system as being 
"loosely consistent," a reasonable target for a large scale, distributed 
database with entries maintained by a large group of folks.

Steve

---

From: Eric Osterweil <[email-masked]>
Date: Tue, 28 Aug 2012 10:09:15 -0400

On Aug 28, 2012, at 12:23 AM, Stephen Kent wrote:

> Eric,
> 
> It seems likely that not all RPs will have the same view of INR allocation, e.g., due to differences
> in when RPs fetch data from repositories. This seems analogous to the transient inconsistencies that
> ISPs see today if they use IRR or other INR data sources, for similar reasons.

Maybe yes, and maybe no.  I don't necessarily want to diverge into that topic now (though a separate thread would be ok).  I'm more focused on the pragmatic issues that come up when implementing.  So far, my concerns seem to be pretty specific to this design, but I'm sort of seeking guidance here...

> 
> I think Rob Austein has referred to the repository system as being "loosely consistent," a reasonable target for a large scale, distributed database with entries maintained by a large group of folks.

I admit that my memory/cache consistency background is a little rusty (though I used to be quite dialed in on it), but I don't recall ever coming across that model before.  What are the access/ordering guarantees in ``loose consistency?''  Again, it only matters from a pragmatic perspective.  I am having trouble ensuring that I have the right idea here.

Thanks a lot!

Eric

---

From: Brian Dickson <[email-masked]>
Date: Tue, 28 Aug 2012 11:08:48 -0400

> ISPs see today if they use IRR or other INR data sources, for similar

 I think there are a couple of things that are important, in the duality
between INRA<->RPKI<->RP and Originator<->RP<->...<->RP relationships.

For example, in the IRR world, there are a number of reasonably well-known
processes used by the largest network operators, for IRR-update ->
filter-update schedules (and mechanisms).

And as such, recipients of new INRs have published rules they need to
follow, to ensure their announcements won't be blocked by filters that have
yet to be updated.

So, there are a couple of analogous elements in the RPKI ecosystem that,
IMHO, need to be described, proscribed, or categorized:

What model for the processes of maintaining sync between INR and RPKI
should be followed? A high-level finite state machine (FSM) model should be
an eventual goal, so that implementors have a crystal clear model to follow.

At any point in time, what states should any particular element be able to
be in?

How should an RP interpret each of those states?

How can an RP identify the timeline it needs to follow, if it wants to be
as current as possible, with as little overhead and work required? Clearly
once-per-second polling won't scale.

Is there any corresponding place in the RPKI that would allow an Originator
to identify expected latency between ROA issuance, and the update towards a
given RP which would guarantee that the RP will accept an announcement (in
BGPSEC)?

This is the level of modeling I'd hope to see, to understand how the
overall system behaves, as a potential RP.

Brian

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Aug 2012 14:55:27 -0400

Eric,

Perhaps what you are looking for is some text in an operations doc, 
suggesting what
an RP can expect, depending on how it elects to interact with the 
repository system,
maintain its local cache, etc.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 29 Aug 2012 01:25:41 -0400

Brian,

As I mentioned in my rely to Eric, I think this is a topic to be 
addressed in an RPKI
operational considerations doc. We have draft-ietf-sidr-origin-ops-19 in 
progress now,
so I suggest you discuss this with the author of that doc. Nonetheless, 
I'll offer my
views on a few of the topics you mentioned:

> ...
> should be followed? A high-level finite state machine (FSM) model 
> should be an eventual goal, so that implementors have a crystal clear 
> model to follow.
I rarely see FSMs in RFCs these days, although I agree that they are 
valuable in many contexts. Do
we have an FSM for IRR data use by RPs?
> At any point in time, what states should any particular element be 
> able to be in?
>
> How can an RP identify the timeline it needs to follow, if it wants to 
> be as current as possible, with as little overhead and work required? 
> Clearly once-per-second polling won't scale.
As I mentioned at the SIDR interim, each manifest contains a next issue 
date/time, which is a
way for the CA to tell RPs when the RPs should expect to see new objects 
published. An RP could use
that value as an indication of when to check the pub point for the CA in 
question (vs. using some
fixed, periodic checking interval for all CAs).
> Is there any corresponding place in the RPKI that would allow an 
> Originator to identify expected latency between ROA issuance, and the 
> update towards a given RP which would guarantee that the RP will 
> accept an announcement (in BGPSEC)?
I don't think that the term "guarantee" is applicable here, given the 
vagaries of communication :-) .

Steve

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 29 Aug 2012 11:12:01 -0400

On Wed, Aug 29, 2012 at 1:25 AM, Stephen Kent <[email-masked]> wrote:
> Brian,
>
> As I mentioned in my rely to Eric, I think this is a topic to be addressed
> in an RPKI

i had actually thought that both of the ops docs had this data, yes.
  <http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19#section-3>
  <http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-05#section-3>

I had thought were the likely locations. Some of what both Eric and
Brian are poking at is what Danny poked at long ago:

"As a number resource 'owner' (user? lessor? operator?) how long does
it take for my shiny new ROA to get from me to 'everywhere I care
about?'" the 'everywhere I care about' is probably 'everywhere' and is
probably here more of a guideline than a hard rule... I suspect given
the origin-ops + bgpsec-ops docs suggestions you're looking at ~12 hrs
from start/finish for today's 4-ASHOP interwebs. (just a guess,
someone could do the math... in fact, this is one of the math bits I
was asking about in a previous message:
<http://www.ietf.org/mail-archive/web/sidr/current/msg04939.html>)

> so I suggest you discuss this with the author of that doc. Nonetheless, I'll
> offer my
>> Originator to identify expected latency between ROA issuance, and the update
>> towards a given RP which would guarantee that the RP will accept an
>> announcement (in BGPSEC)?
>

for quite some time the discussion has been: "Hey, all of your
internal caches, in the most simplistic deployment, may not have all
the same data. Additionally, you will have to gather from all over the
globe data at all publication points, by the time you finish gathering
you may also be behind."

I don't see that that has changed much ... has it? I do think that
understanding "hey, this publication of a new ROA/CRL/EE takes 12hrs
to get everywhere[*]" is important though.

-chris

[*]: 'everywhere' means 'to each asn/RP', I think inside that ASN it's
harder to decide if the job is done, BUT it's on the local AS operator
to 'get it done'.

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

---

From: Andy Newton <[email-masked]>
Date: Wed, 29 Aug 2012 15:22:45 +0000

On 8/29/12 11:12 AM, "Christopher Morrow" <[email-masked]> wrote:

>"As a number resource 'owner' (user? lessor? operator?) Š"

'holder' is probably closer to the concept you want.

-andy

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 30 Aug 2012 10:54:17 -0400

> 'holder' is probably closer to the concept you want.

sounds good to me.

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 30 Aug 2012 10:59:09 -0400

On Aug 28, 2012, at 2:55 PM, Stephen Kent wrote:

> Eric,
> 
> Perhaps what you are looking for is some text in an operations doc, suggesting what
> an RP can expect, depending on how it elects to interact with the repository system,

Actually, I was looking for some intuition/guidance for people in a position to take a systematic look at how to implement the design.  I'm not sure which draft, or which section, etc.  Basically, I'm trying to get things worked out, but I keep having issues w/ ensuring that ingestion of data by a process at (say) one router has something/anything to do with the ingestion of the same thing at (say) another router.  Consistency models tell me what properties I can rely on at time t_0 at location r_0 vs time t_1 at r_1, etc.  Right now, I'm having a lot of trouble ensuring that anything agrees with anything else in the Interwebz and I don't know if I should just let that be the case, or there is some sort of consistency I need to adhere to...

Eric

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 30 Aug 2012 13:17:13 -0400

> Actually, I was looking for some intuition/guidance for people in a position to take a systematic look at how to implement the design.  I'm not sure which draft, or which section, etc.  Basically,…

right, for the whole system you want to know:
  'how long between ROA create and ROA-foo on router'

I think what you really want (because across the whole of the realm
it's a 'simple' model, where inside islands there is potentially lots
more fudgery) is:
  1) 'how long from roa-create -> roa-at-all-ASNs'
  2) 'what model of timing makes sense for 'once a ROA is at a remote
ASN, how long before that data is available on 1 routing-device, then
all routing-devices in that realm'
  3) should this set of numbers apply to ALL objects in the RPKI
equally? or should some object types have different timing
requirements?

-chris

(using ROA as the unit, you could use CRL update, EE-cert, etc... 'one
item in the RPKI')

---

From: Brian Dickson <[email-masked]>
Date: Thu, 30 Aug 2012 14:30:03 -0400

On Thu, Aug 30, 2012 at 1:17 PM, Christopher Morrow <[email-masked]
> wrote:

> > Actually, I was looking for some intuition/guidance for people in a
> position to take a systematic look at how to implement the design.  I'm not
> sure which draft, or which section, etc.  Basically, I'm trying to get
> things worked out, but I keep having issues w/ ensuring that ingestion of
> data by a process at (say) one router has something/anything to do with the
> ingestion of the same thing at (say) another router.  Consistency models
> tell me what properties I can rely on at time t_0 at location r_0 vs time
> t_1 at r_1, etc.  Right now, I'm having a lot of trouble ensuring that
> anything agrees with anything else in the Interwebz and I don't know if I
> should just let that be the case, or there is some sort of consistency I
> need to adhere to...
> >
>

I think this extends out to the several kinds of "consistency" questions I
have, as well.

For example:

There are a whole bunch of documents that detail bits and pieces of the
RPKI, some of which have some ASCII-art showing parts of the system.

However, there is a severe lack of detail on the things it is about,
specifically IP prefixes (INRs) that are protected via the whole system.

In fact, in the one document that I think should be most critical, on
validating ROAs, there are almost no references to IP blocks, and what few
there are get referred to either indirectly (via another RFC reference) or
using inconsistent terminology.

After reviewing the whole mess of docs, and following the mutual implicit
or explicit cross-references, I have some questions that don't seem to have
been answered by the docs (both the published RFCs and current I-Ds).

(1) What is the presumed model for INRs themselves?
Are INRs presumed to be exclusive, and allocations hierarchical (with the
occasional instance of an entire allocation being handed off without being
divided)?
That is to say, is a given piece of address space (contiguous power-of-2
block) always under the exclusive control of one party, based on
longest-match rules of IP routing?
(I'm pretty sure that the existing assignment methods starting at
IANA->RIRs is built entirely on exclusivity, modulo RFC1918 space.)

(2) If INRs are meant to be exclusive, why does the RPKI not enforce that
exclusivity?
It appears, having looked at the docs in the context of grandparenting,
that despite the assertion that validation is a top-down activity, it is
fundamentally a bottom-up process (looking for an eventual match against a
trust anchor).
And, in essence, there is no requirement that INR "delegations" that occur
at any given CA, need to be unique, which presumably contradicts the nature
of INRs.
(Note here - the presumption is not uniqueness by ASN, but uniqueness by
organization controlling ROA assignment, where that single org could/would
issue ROAs for multiple ASNs.)
I believe that enforcing exclusivity of INR blocks within each CA's set of
signed objects, is all that is needed to achieve global uniqueness. A CA's
ROA(s) could be matched against delegations, requiring a zero-overlap, or
alternatively modifying the ROA validation process to somehow disambiguate
things.

(3) If an ROA is issued by CA_1 for A.B.C.D/X (max length X+Y, Y>=1), and
the same CA_1 also signs a delegation on A.B.C.D/(X+1) to CA_2, who issues
an ROA for A.B.C.D/(X+1) (max length (X+1)+Y, Y>=0), that two parties are
then legitimately able to originate (conflicting) BGP routes for
A.B.C.D/X+1 - something that I doubt CA_2 would be happy about (even as a
possibility, let alone an actuality).

(4) ROAs appear to be "containers" for (possibly) multiple prefixes. Is it
strictly necessary for every prefix in a ROA to validate properly, for a
ROA to validate? Or, if not, how does that work for partial validity,
prefix-by-prefix?

(5) Everything in the validation and RPKI seems to be forward-lookup
oriented from an ASN perspective. What about trying to look up information
on a given prefix, if you don't have the ASN(s)? It seems like it would
require an exhaustive search of every pub point under any published CA that
contained a covering address for the prefix in question. Is that correct,
and did anyone look at this originally when designing the RPKI? What if you
have one ASN that you know is announcing a given prefix, but want to find
out if any other ASN has a valid ROA which includes the same prefix (or
covering prefix, or child prefix)?

(6) What about an informational RFC to tie all the relevant bits together,
e.g. with big ASCII-art diagrams, high-level text describing relationships,
and pointers to detailed technical RFCs? Without this, trying to understand
any of this, let along trying to implement, is rather unwieldy.

(7) This also points towards the number of places the docs "punt" on
critical issues. E.g. the question of INR->RPKI timing ("...is a
side-effect...") is pretty vague. I also think the issue of "bogon" space
could/should be addressed, so that unused space can not only _not_ be part
of any ROA, but that unused space can authoritatively be excluded from
routing tables via BGPSEC mechanisms. (There is no reason to wait for
everyone to deploy BGPSEC to achieve this piece of low hanging fruit.)
Since INRs are allocated top-down, Reserved space can trivially be
authenticated and placed into a "black list" dynamically.

Any comments, from anyone, on any of these, are welcome.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Thu, 30 Aug 2012 14:59:40 -0400

> we have an FSM for IRR data use by RPs?

I don't know about FSM _diagram, but the RIPE database (which includes not
only IRR data but also authoritative INR data and RPKI data), is fully
documented here:
http://www.ripe.net/data-tools/support/documentation
And in particular the manual, including how a request turns into an
"inetnum" (and RPKI object, now) is here:
http://www.ripe.net/lir-services/training/material/LIR-Training-Course/LIR-Handbook.pdf

The language used in the objects, RPSL, is memorialized here:
http://tools.ietf.org/html/rfc2622
(Published in 1999, updated by: http://tools.ietf.org/html/rfc4012)

The history of the IRRs, language, and tools, is well documented here:
http://tools.ietf.org/html/rfc4277#page-15

And it might be well noted, that the RADB dates back to the Routing Arbiter
project, and to its predecessor-in-interest (PRDB) which predates BGP
version 4. RIPE-81 -> RIPE-181 -> RPSL.

But, as author or co-author of several SIDR docs, I'm presuming you're
already familiar with the above?
You wouldn't really try implementing a system for (securely) registering
internet routing information, without being completely familiar with prior
art in the field, would you?

Brian

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 30 Aug 2012 15:23:16 -0400

> (2) If INRs are meant to be exclusive, why does the RPKI not enforce that

more than one origin ASN may be valid for a single prefix?

---

From: Arturo Servin <[email-masked]>
Date: Thu, 30 Aug 2012 16:12:41 -0400

I think at least different RIRs have different time to publish ROAs and certificates.

	At least from our side it was a decision taken long ago and if we needed to change it to help the world to be a happier place we could do it.

Regards,
as

---

From: Brian Dickson <[email-masked]>
Date: Fri, 31 Aug 2012 08:34:39 -0400

On Thu, Aug 30, 2012 at 3:23 PM, Christopher Morrow <[email-masked]

> more than one origin ASN may be valid for a single prefix?

In the same paragraph you snip-quoted, was the following:
(Note here - the presumption is not uniqueness by ASN, but uniqueness by
organization controlling ROA assignment, where that single org could/would
issue ROAs for multiple ASNs.)

Same org == same CA.

So, does it not make sense that the RPKI, meaning its design, architecture,
procedures, etc., should actually enforce exclulsivity?

This is pretty fundamental to the number resource tree, and to routing
validation.

If this is a design flaw in the RPKI, I think it is one that needs to be
addressed.

Since origin validation is dependent on the RPKI and its validation rules,
it's kind of "square one" for all things SIDR.

Brian

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 31 Aug 2012 15:24:11 +0200

Hi,

On 31 Aug 2012, at 14:34, Brian Dickson wrote:
> So, does it not make sense that the RPKI, meaning its design, architecture, procedures, etc., should actually enforce exclulsivity?

I think that INRs appearing on certs in multiple locations, different TAs, or different branches, are not really a *technical* problem. Meaning that if these certs are used to sign objects they are just complementary. It doesn't matter whether one CA signs a set of objects or the same set (content) is signed by multiple CAs. Plus, this feature is actually needed when doing make-before-break transfers of live networks.

Of course it's important that information is correct. But the notion that uniqueness of resources in the tree guarantees correctness seems fundamentally flawed to me. Correctness is assumed by transitive trust placed in the TA(s), and can only be manually verified by comparing certs to public registration databases.

Regards,

Tim

---

From: Brian Dickson <[email-masked]>
Date: Fri, 31 Aug 2012 10:12:57 -0400

On Fri, Aug 31, 2012 at 9:24 AM, Tim Bruijnzeels <[email-masked]> wrote:

> So, does it not make sense that the RPKI, meaning its design,
> architecture, procedures, etc., should actually enforce exclulsivity?
>
>
> I think that INRs appearing on certs in multiple locations, different TAs,
> or different branches, are not really a *technical* problem. Meaning that
> if these certs are used to sign objects they are just complementary. It
> doesn't matter whether one CA signs a set of objects or the same set
> (content) is signed by multiple CAs. Plus, this feature is actually needed
> when doing make-before-break transfers of live networks.
>
>
I think maybe it would help to do a worked example (straw man), on an
example where a live network would be transitioned from one CA to another
(versus one ASN to another).

Do you have an example in mind?

I think distinguishing PI vs PA (semantic attributes, but necessarily
something to consider) in detailing the straw man would help.

Are you thinking of situations where the owner (organization) changes but
the announcing ASN does not?
Or where the ASN changes but the owner (organization) does not?
Or where both owner and ASN change?

Thanks,
Brian

> Of course it's important that information is correct. But the notion that
> uniqueness of resources in the tree guarantees correctness seems
> fundamentally flawed to me. Correctness is assumed by transitive trust
> placed in the TA(s), and can only be manually verified by comparing certs
> to public registration databases.
>

If correctness cannot be confirmed via automated mechanism, this is a fatal
scaling flaw.

Or do you mean that this is a corollary of the uniqueness? In which case, I
don't see how you reach that conclusion, and it would be helpful to show
the steps in getting there.

Brian

P.S. I'm arguing not only uniqueness, but completeness, i.e. that the
entire number space must be enumerated, where the state of every number or
block in the space is well defined, and no overlaps occur. Enumeration
would need to occur at each "manifest" level, as either "ROA", "used but no
ROA", "reserved (bogon)", "unassigned", or "delegated", with corresponding
references to actual signed objects. And enumeration must be specifically
possible with minimal cost/effort, so that RPs can confirm the uniqueness
(via the ROA validation prior to rpki-rtr).

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 31 Aug 2012 23:43:05 -0400

> procedures, etc., should actually enforce exclulsivity?

see tim's note.