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.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
