Re: [sidr] draft-kent-sidr-adverse-actions-00.txt

[Stephen Kent <[e-mail]>]

Andrei,

Thanks for taking the time to read the adverse actions doc. I realize that
it's dense in places, and appreciate feedback to improve it.


> In my opinion it'd be useful to have an analysis of implications of
> adverse actions with respect to Internet Number Resources (INRs). I
> understand that probably the intention of this document is to introduce
> a common vocabulary that can be used for discussion of other issues and
> solutions, rather than provide solutions on its own.
Yes, the intent is not to propose solutions here, but to establish
a taxonomy of actions that can have adverse impacts on RPKI RPs,
so that we have a common basis for evaluating proposals.
> However, I found the document hard to read. It looks like the 3 main
> sections are not really linked together and the analysis of implications
> is scattered through the draft.
> Section 2 catalogs all various bad things that can happen, but does not
> provide guidance on the severity of different actions.
Section 2 describes the current set of RPKI objects and defines the
classes of actions that can befall them. In so doing it notes the
top-level implications of each type of action in the context of the
object. You're right that the severity of the impact is not described.
In part the severity depends on where in the RPKI hierarchy the adverse
event takes place. We can add text to each action (identified as "A-x.x")
to provide some insights about the severity of the action.
> Section 3 avoids any references to specific actions in Section 2, which
> brings a question of the utility of such classification.
This section establishes scenarios to place actions into context, i.e.,
to indicate which classes of actions can be effected by which actors
based on the scenario. It does not refer to individual actions from
Section 2, but rather notes what classes of actions can be effected
by a bad actor. Without the characterization of types of actions in
Section 2, one would not be able to make brief statements about what
bad things can happen in a given scenario. For example, text in this section
notes when modification, revocation or injection actions can be effected
by a INR holder, or by a parent or by an outsourced repository operator, 
etc.
So I think the utility of the taxonomy in Section 2 is evident here, even
though we don't cite specific actions in Section 3.
> Finally, section 4 does not really depend on the considerations in the
> previous sections, and IMO could be written without such lengthy
> introduction.
The recommendations in Section 4 result from the analysis in Sections
2 and 3. The recommendations are justified based on that analysis.
We can add text to this section to point to the basis for each 
recommendation
to make that linkage more apparent.
> I think one of the main problems is that the "analysis is performed from
> the perspective of an affected INR holder". IMO, it'd be easier to
> analyze operational impact of various actions if we move the point of
> view to the RP, who accepts, or discards or de-prefs routing
> announcements.
We chose to use the perspective if the INR holder because we were
worried that a more diffuse perspective would result in a redundant 
taxonomy.
(Actions by an INR holder affect its own resources and those of any 
subordinate
INR holders, for example.)  Nonetheless, I agree that the  RP 
perspective is
a very valuable one. We already note the impact on RPs of most of the 
actions
described in Section 2. But we could add text to discuss the impact on 
RPs in
places where it is missing/sparse. We also could add a section to pull 
together
this info if you think it would make the exposition clearer,
> This could also allow to classify actions, or group them, by severity of
> the impact, and provide focus on the most critical attack vectors that
> may require out-of-band support/solutions.
OK, We'll look into that.

Steve