#7: nits for roa-validation
--------------------------------+-------------------------------------------
Reporter: g...@… | Owner:
Type: defect | Status: new
Priority: major | Milestone: milestone1
Component: roa-validation | Version:
Severity: Active WG Document | Keywords:
--------------------------------+-------------------------------------------
reported by John Scudder:
Comment: I think this text, from S 4.1, is not quite right:
This approach to route object origination validation uses a model of
"positive security" attestations, where information that cannot be
validated within the RPKI framework is intended to interpreted by a
RP as invalid information.
Unless you interpret "unknown" as being a flavor of "invalid" (which would
be terribly confusing!) this conflicts with S 2. It would have been right
to say something to the effect of "... information that conflicts with
validation data within the RPKI framework ...". I think you could make
this change without loss of generality.
Comment: I think you've already gotten feedback on the list suggesting
that S 4.1 needs more clarity regarding the effect of maxLength. I agree.
Comment: Given that you discuss BGP at some length, I think you need to
talk about the case where the origin AS can't be determined, specifically
where the AS_PATH starts with an AS_SET. (The same criticism applies to
draft-pmohapat.) This is actually a somewhat vexing problem because on
one hand, "unknown" seems the only reasonable outcome for such a route,
but on the other, that would seem to provide an easy vector for an
attacker to always be able to get his route to be ranked as "unknown"
instead of "invalid". Then again, as we know origin authentication alone
is trivially easy to attack so I think this is not too much of a practical
concern.
Comment: In S 4.3 I find this to be unclear:
* It is a matter of local configuration as to whether ROA
validation is performed on a per-AS basis rather than a per-BGP
speaker, and the appropriate mechanisms to support a de-coupled
framework of validation of ROAs and the loading of outcomes
into BGP speakers are not considered here.
In fact I only finally got after hearing George's presentation, that what
you mean is whether validation is done on the router or in some off-box
server. I think the red herring was the "per-AS" language.
Question: S 4.2 says "... or even if the maxLength element were to be
omitted from the ROA". Does the definition of a ROA even allow for that?
I thought maxLength was a mandatory element (though I admit I haven't
checked). Depending on the answer you might remove the clause.
Nit: I found your use of the term "route object" confusing given earlier
uses of the term to mean something different (e.g. in the IRR). How about
using the term defined in RFC 4271 Section 1.1:
Route
A unit of information that pairs a set of destinations with the
attributes of a path to those destinations. The set of
destinations are systems whose IP addresses are contained in one
IP address prefix carried in the Network Layer Reachability
Information (NLRI) field of an UPDATE message. The path is the
information reported in the path attributes field of the same
UPDATE message.
You could refer to this as "BGP Route" to disambiguate it from any other
meaning of "route".
If you don't want to do this you might at least note up front that your
use of "route object" is the same as "route" as defined in 4271 S1.1.
Nit: S 4.1 "Routes objects that describe..." should be "Route objects that
describe..." Or of course, just "Routes that describe" if you choose to
adopt my suggestion above.
Regards,
--John
--
Ticket URL: <http://trac.tools.ietf.org/wg/sidr/trac/ticket/7>
sidr <http://tools.ietf.org/sidr/>
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
