Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt

[Stephen Kent <[e-mail]>]

Carlos,

...
> Given that S-BGP failed to gain any traction and most people outside the
> IETF have never heard of it, I don´t think it sets a particularly
> encouraging precedent.
You asked why 3779. I explained. The were many reasons why S-BGP
didn't succeed, but use of 3779 is not likely one of them.
> There is nothing wrong with the extension, nor with the rules per-se.
> Some of us believe that 3779 rules are not a good match for this
> particular problem. They may very well be for other, related, problem
> domains (whole network transfers come to mind now).
The SIDR WG began meeting in 2006, I believe. The SIDR arch doc was 
first posted
(as an accepted WG I-D) on 2/28/07. It cited 3779 as the basis for the RPKI.
It seems curious to me that it has taken 7 years for senior RIR tech 
staff to
determine that there is a problem. You are relatively new to this 
effort, but what
is the excuse for your co-authors?
>> But, then, so are IPv4 and v6 address prefixes.  Do you propose creating
>> separate PKIs
>> for IPv4 and IPv6 addresses?
> Definitely not. Again, S-BGP is not a particularly good data point. I
> propose to *unbundle* the analysis of resource types when validating
> certs. I believe that is clear from my earlier email and from our draft.
The earlier draft did not contain an algorithm for doing what
Geoff has recently suggested as a way to do this. That I-D contained
a set of text that tried to convey what the authors wanted to happen,
but it was sloppy and focused only on EE cert validation. The current
I-D tries to describe a problem space, and it should do so without
prejudice wrt a solution. Your comments suggest otherwise.
(Also, since you keep criticizing S-BGP, how extensive is your 
understanding
the system, beyond knowing the acronym. Have you read any of the papers, 
or are
your comments based on hearsay?)

> ...
>> Should revocation of a cert with a set of prefixes invalidate all
>> the certs below? (hint, the answer is yes.) The examples cited by
>> you and your fellow authors focus only on errors in 3779 extensions,
>> but why are revocation errors not equally important to address?
> The ability of not being able to correct 1 issue out of 2 doesn´t seem
> to be a good argument for leaving the 2 unfixed.
Quite the contrary. If a major rationale for changing path validation is
to deal with mistakes by RPKI CAs, then let's articulate the rationale
clearly and comprehensively, so that it guides our selection of a solution.
if we adopt one fix based on an incomplete description of the problem, it
may cause us to postpone developing a more comprehensive solution. Also
a more comprehensive solution might avoid duplication of mechanisms.
> In addition, revocation errors are way less probable than transient
> registry inaccuracies. I actually don´t see how we would revoke a cert
> by mistake, although I´m not saying it cannot happen. If I had to put
> probabilities to it, I would say 99% of problems will come from registry
> inaccuracies vs 1% revocation errors.
Your numbers seem very speculative to me. At best they are based on
the limited experience that RIRs have with managed CA services for clients.
So I am not convinced that you have a solid basis for projecting one type of
error vs. another when support for CAs run buy net operators is deployed.
> So, if 2 weeks of work (Tim says 1 day, but given he's a particularly
> gifted coder we´ll give everyone else 14 times as much) can solve 99%
> (or 90%, or even 80%) of issues and remove a large roadblock for the
> continuing adoption of OV and RPKI, it seems like a no brainer.
I agree that there is a "no brainer" here, but you would not like
my assessment of why. As Terry noted, the "end of routing as we
know it" or taking an entire country offline, claims that were made
were misleading, wrt OV. So, why do you see resolution of this issue as
a major impediment to continuing adoption of the RPKI?

Steve