Telechat Review of draft-ietf-sidr-rpki-rtr-
review-ietf-sidr-rpki-rtr-secdir-telechat-orman-2012-02-08-00

Security review of
The RPKI/Router Protocol, draft-ietf-sidr-rpki-rtr-24

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG. These comments were written primarily for
the benefit of the security area directors. Document editors and WG
chairs should treat these comments just like any other last call
comments.

The protocol defines the communication between a router and an
Autonomous System (AS) cache validated by public keys.  This is part
of a work in progress to secure routing infrastructure.  The caches
implement a "resource public key infrastructure (RPKI)".

I've previously reviewed this document and recommended that the
session identifier be more than 16 bits.  Because this would change
the header length, those deploying the protocol were loathe to
make the change.  In subsequent discussion I recommended that the text
of the document take a strong stance towards using an incremented
counter value between reboots if the cache had persistent storage.

The language of the draft has not changed to reflect the recommendation.  

The draft also has a confusing statement that 

      The Session ID might be a pseudo-random, a monotonically
      increasing value if the cache has reliable storage, etc.

I don't think this makes sense, perhaps there is a typo, and the
qualifiers of "might" and "etc." don't help much.

I also recommended not using the term "monkey in the middle" in place
of the much more common "man in the middle" unless there was a specific
reason with a citation for a definition. 

The statement about SSH transport states:

   It is assumed that the router and cache have exchanged keys out of
   band by some reasonably secured means.

The out-of-band exchange of keys is a persistent problem in IETF protocols,
and I sincerely wish that there were some guidance on this point.  What
is "reasonble"?  The security of the out-of-band exchange should be
commensurate with the security requirements of the application, as should
key updates.  It would be worth eine kleine BCP, perhaps.

Hilarie