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

From: Andrei Robachevsky <[email-masked]>
Date: Tue, 07 Jul 2015 17:05:14 +0200

Hi,

Stephen Kent wrote on 01/06/15 18:31:
> Di Ma and I, with help from several folks at BBN, have generated this
> document to try to characterize the set of attacks/errors that might
> adversely impact INR holders in the RPKI context. As we discuss topics
> like RPKI path validation, the Suspenders ideas, and Slurm, it seems
> appropriate to have a common background on the security issues in question.
> 
> We hope this is a suitable start for this sort of discussion, something
> that might become a WG doc, maybe published as an informational RFC (or
> not).
> 
> https://datatracker.ietf.org/doc/draft-kent-sidr-adverse-actions/
> 
> Comments appreciated.
> 

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.

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 3 avoids any references to specific actions in Section 2, which
brings a question of the utility of such classification.

Finally, section 4 does not really depend on the considerations in the
previous sections, and IMO could be written without such lengthy
introduction.

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.

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.

Andrei

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Jul 2015 11:10:56 -0400

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.

> 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.
> 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.
> 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.
> previous sections, and IMO could be written without such lengthy
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.
> view to the RP, who accepts, or discards or de-prefs routing
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,
> may require out-of-band support/solutions.
OK, We'll look into that.

Steve