[sidr] rpki-rtr-25 notes

[Wes Hardaker <[e-mail]>]

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