George and Geoff --
Some comments, questions, and nits for you (in that order).
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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
