> 在 2015年11月6日，13:16，Geoff Huston <gih...@gmail.com> 写道：
>
> I disagree with the assertions Karen
>
>
>> On 6 Nov 2015, at 7:53 AM, Karen Seo <k...@bbn.com> wrote:
>>
>> Folks,
>>
>> I think the authors have brought up some pertinent issues which have helped
>> inspire other work which subsumes them. So I thank them but agree that it
>> seems appropriate to drop this draft since those issues are now being
>> covered in other documents and those documents have additional detail.
>
> this is the overall assertion that I disagree with.
>
>
>> Randy's I-D discusses INR transfers.
>
> This is just one way to think about certificate-mediated transfer of
> resources between address registries. It does not necessarily address the
> brittleness of the overall RPKI when using the existing validation algorithm.
>
>
>> Steve's draft on adverse action provides a detailed analysis of the
>> "operational fragility" of the RPKI in the face of attacks and errors.
>
> As I said in the working group meeting, I oppose the adoption of this draft.
> It is by no means a complete list of “things that could go wrong” and as we
> continually find out in operations each and every day, what actually
> surprises us that goes wrong is stuff that we never expected to go wrong.
> This document pretends to be a comprehensive list of all things that could go
> wrong and such a pretension is at best a dangerously mistaken one. The
> suggested remediations rely on unspecified mechanisms that are at best using
> a liberal application of magic. It leads to a misapprehension that nothing
> else could ever go wrong, and therefore if we just concentrate on these
> things the result would be operationally perfect. I have yet to see such a
> theory of how to attain operational perfection withstand even one week in the
> field.
>
Geoff,
The way I think about “things that could go wrong” is different from you.
No one can enumerate all specific and concrete security problems as we are
moving forwards with RPKI deployment and operations.
But reviewing RPKI operation security on the whole and establish a threat model
is necessary as people did in other areas. One can easily find a bunch of RFCs
that are intended to do so.
RFC 3833 Threat Analysis of the Domain Name System (DNS)
RFC7132 Threat model for BGP Path Security
RFC7375 Secure Telephone Identity Threat Model.
for instance.
And the adverse actions draft is intended to well shape the RPKI operation
security problems by offering taxonomy that helps seek security mechanisms to
safeguard RPKI operations.
Di
>
>> So, if the adverse actions draft is adopted by the WG, we (the WG) could
>> use the requirements stemming from these two IDs as the basis for a
>> solution(s) document.
>
>
> And that in a nutshell is exactly why I oppose the adoption of this document.
> It appears to me that this step assumes that the adverse actions has
> catalogued avery possible problem and now all we need to do now is to replace
> the magic placeholders with some action or other. I’m sorry but this premise
> is just not realistic and this approach in the draft is just not realistic
> for me.
>
>> Just personal preference, but I also find having one document per
>> topic/issue (at least when they're as complex as is the case with the threat
>> analysis) easier to follow and would also like to separate defining of
>> issues and their requirements from describing the solution.
>
>
> Just personal preference, but I would like the Working Group to address some
> basic design issues here that invoke brittleness in all kinds of known and
> unknown ways rather than play hunt the wumpus with some supposedly
> comprehensive list of everything that could ever possibly go wrong. ever.
>
>
> regards,
>
> Geoff
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
