Just finished (finally) scanning the rpki-rtr document (-25 version) and
have a few notes about it. Over all, though, nicely done ID. Thanks!
A) It's too early for nit edits, but this one just jumped at me and I
couldn't ignore it.
5.1, 3rd paragraph(/sentence): is only -> is *the* only
B) 5.9: the 2nd and 4th paragraphs seem to contradict each other. I
suspect that the intent is that you can send a generic error after a
particular PDU, but the way it's phrased is a bit odd and it jumped
out at me too. How about:
If the error is generic (e.g. "Internal Error") and not associated
with the PDU it is responding to, the Erroneous PDU field ...
Note that with this exception rule you could still end up in some
state where the generic error isn't fatal and you need to respond
with a specific and a generic error, but you can't send 2 error
reports. Thus, hopefully generic errors will always be fatal?
C) 5.10 seems to indicate rcynic (a very fine tool) is ubiquitous
because it's quoting it like everyone knows what it is (and
always will). I'd leave the example tool name out.
D) 7. Transport.... Multiple issues
D.1) "Unfortunately there is no protocol to do so on all currently used
platforms".
I actually doubt the validity of that statement. I suspect SSH is
likely available on them all. Or at least "nearly all" (and I
doubt anything will ever reach "all"). I'd bet TLS is nearly
ubiquitous as well, though probably less than SSH.
D.2) The ordering of the 5th-8th(ish) paragraphs seems weird. I'd group
them together by subject such that the sections that talked about
unprotected TCP should be next to each other and the ones that
talked about the protected ones be together. Thus, I think just
moving the 2 unprotected paragraphs ("Caches and routers MUST..."
and "If unprotected TCP...") to positions 5 and 6 would solve most
of the oddities.
D.3) I'm not sure that the whole concept of "MUST implement unprotected"
is going to fly through a security review. I know I'd flag it.
Generally I'm not sure it's wise to mandate insecurity, though I do
agree it may be a nice feature to have (did I really just say that???)
D.4) There is some confusion regarding whether routers "use" vs "can be
configured to use". EG: "Caches and routers SHOULD use TCP-AO..."
IMHO, this indicates they have a choice. "SHOULD be able to use"
might be a better wording choice implying its subject to
configuration by the operator. If you want a more complete list of
places where I think this might be a problem, I can supply one of
course.
D.5) "If available to the operator...". How would the router know
what's available to the operator? Or does this mean that if the
device already implements protocol X, it must offer it as a
configuration choice for rpki-rtr transport? If so, that's not
entirely clear.
D.6) I'd order the sub-sections to be in the same order as the list
above it. IE, TCP-AO is first in the list, so the TCP-AO
sub-section should probably come first.
E) 7.1 SSH transport "Client routers SHOULD verify the public key of the
cache". Similar to D.4, I'd change this to "Client routers MUST
be able to verify the public key of the cache".
F) 7.2 TLS transports: the CN field is really being deprecated and I'd
suggest using the subject alt name instead (SAN).
G) section 8, paragraph 2 implies that the cache needs a list of names
for the peer and I'm not sure this is true. In fact much of that
paragraph talks about the router/client side only, so I'd split the
paragraph in two: one for cache requirements and one for the router
requirements.
H) section 8: I'd change "Key" to either "TheirKey" or "ItsKey"
I) section 8: "it would be prudent for the client"... This seems like a
good place for the word SHOULD to sneak in there somewhere.
J) section 8: "if data from multiple caches are held, implementations
MUST NOT distinguish between data sources when performing
validation".
This one confuses me. It's unclear, after reading the entire
document, why you have a preference ordered list if the data from
them all must be treated equally. Is the goal to have a preference
order list because you want to really only have, ideally, a single
cache and the others are fallbacks? Or is it because you want to
have N/M established at any point? Either way, if they're all equal
then what happens when popular #1 is overloaded and slower and issues
an announcement after #2 has issued a withdrawl, or vice versa.
Either way you end up in a race-condition based state. This should
probably be discussed and at least mentioned, even if you choose
not to solve it by a preference setting somewhere. Though I'd
certainly want to leave room in the configuration engine to allow for
a preference setting even if implementing it is optional.
K) I didn't dive heavily into the security considerations because of
some of the above that I suspect may affect it. I'd be happy to if
it's ready to be dived into though.
Again, nicely done document. Clear and straight forward (though at
times I had to predict what was coming ahead to make sense of the
current paragraph, I think that's generally hard to avoid).
--
Wes Hardaker
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
