Re: [sidr] adverse actions -01 posted

[Stephen Kent <[e-mail]>]

Randy,

I read your comments carefully, and I'm puzzled by several of them.

Your said, for example:
> and what tim, and others, are trying to say is that exactly those
> meanings are inappropriate.  we do not really know intent, contracts,
> and business/social context.
the introduction says:

    Thus this document examines the implications of adverse actions with
    respect to
    INRs irrespective of the cause of the actions.


That text was trying to indicate that , for example, nothing to do with 
whether an action is adverse. But, I have revised the intro to make this 
clearer.
> i picked the first example of an 'adverse action' in your document and
> explained how it can be normal operations (and it is said you have fixed
> it, tyvm).  i had hopes you would induce.
Your comments persuaded me to revise the text in question and to note 
that not all examples of competing ROAs or certs represent adverse 
actions. That, IMHO, was an appropriate and adequate change. You didn't 
say that you found the term "adverse" to be a problem.

> tim made a fair suggeston of a lighter word.
Tim offered no suggestion for a different term, which is not helpful. 
Moreover, his tone communicated bias and defensiveness, which is also 
not helpful.

Nonetheless, I have revised the introduction to address the cited 
concerns, but I have not adopted a new term, because:
     - it's reasonable, if one understands the definition
     - nobody has offered any alternative, much less a better 
alternative, that encompasses the full range of actions that may be he 
result of errors, attacks, etc.

Steve
--------

1.Introduction

In the context of this document, any change to the Resource Public

Key Infrastructure (RPKI) [RFC6480] that modifies the set of Internet 
Numeric Resources (INRs) associated with an INR holder, and that is 
contrary to the holder's wishes, is termed "adverse". An action that 
results inan adverse charge (as defined above), may be the result of an 
attack on a CA [RFC7132], an error by a CA, or an error by or an attack 
on a repository operator. *Note that the CA that allocated the affected 
INRs may be acting in accordance with established policy, and thus the 
change may be legally justified, even though viewed as adverse by the 
INR holder. This document examines the implications of adverse actions 
with respect to INRs irrespective of the cause of the actions.*

Additionally, when a ROA or router certificate is created that

"competes" with an existing ROA or router certificate (respectively), 
the creation of the new ROA or router certificate may be adverse.(A 
newer ROA competes with an older ROA if the newer ROA points to a 
different ASN, contains the same or a more specific prefix, and is 
issued by a different CA.A newer router certificate competes with an 
older router certificate if the newer one contains the same ASN a 
different public key, and is issued by a different CA.)Note that 
transferring resources, or changing of upstream providers may yield 
competing ROAs and/or router certificates, under some circumstances. 
Thus not all instances of competition are adverse actions.

As noted above, adverse changes to RPKI data may arise due to several 
types of causes. A CA may make a mistake in managing the RPKI objects it 
signs, or it may be subject to an attack. If an attack allows an 
adversary to use the private key of that CA to sign RPKI objects, then 
the effect is analogous to the CA making mistakes. There is also the 
possibility that a CA or repository operator may be subject to legal 
measures that compel them to make adverse changes to RPKI data.In many 
cases, such actions may be hard to distinguish from mistakes or attacks, 
other than with respect to the time required to remedy the adverse 
action.(Presumably the CA will take remedial action when a mistake or an 
attack is detected, so the effects are similar in these cases. If a CA 
has been legally compelled to effect an adverse change, remediation will 
likely not be swift.)

This document analyzes the various types of actions by a CA (or

independent repository operator) that can adversely affect the INRs

associated with that CA, as well as the INRs of subordinate CAs.The

analysis is based on examination of the data items in the RPKI

repository, as controlled by a CA (or independent repository operator) 
and fetched by Relying Parties (RPs).The analysis is done from the 
perspective of an affected INR holder.