Subject: [secdir] Review of RPKI/Router Protocol, draft-ietf-sidr-rpki-rtr-24

From: "Hilarie Orman" <[email-masked]>
Date: Sun, 29 Jan 2012 16:37:44 -0700

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

---

From: Rob Austein <[email-masked]>
Date: Mon, 30 Jan 2012 11:26:48 -0500

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

Hi, Hilarie.  I'm a little confused.  All of the following was added
in response to your previous comments:

      Should a cache erroneously reuse a Session ID so that a router
      does not realize that the session has changed (old session ID and
      new session ID have same numeric value), the router may become
      confused as to the content of the cache.  The time it takes the
      router to discover it is confused will depend on whether the
      serial numbers are also reused.  If the serial numbers in the old
      and new sessions are different enough, the cache will respond to
      the router's Serial Query with a Cache Reset, which will solve the
      problem.  If, however, the serial numbers are close, the cache may
      respond with a Cache Response, which may not be enough to bring
      the router into sync.  In such cases, it's likely but not certain
      that the router will detect some discrepancy between the state
      that the cache expects and its own state.  For example, the Cache
      Response may tell the router to drop a record which the router
      does not hold, or may tell the router to add a record which the
      router already has.  In such cases, a router will detect the error
      and reset the session.  The one case in which the router may stay
      out of sync is when nothing in the Cache Response contradicts any
      data currently held by the router.

      Using persistent storage for the session identifier or a clock-
      based scheme for generating session identifiers should avoid the
      risk of session identifier collisions.

> qualifiers of "might" and "etc." don't help much.

No doubt this could be phrased better.

A cache which has neither a usable clock nor persistent storage hasn't
got many options, at which point pseudo-random looks like the best of
a bad lot.  Of course, a cache without a usable clock can't do RPKI
validation either, so perhaps this is a silly corner case.

Relying on stable storage buys less than you might think here, because
the most likely reason why the cache might have to generate a new
session ID is that something has happened to its stable storage.

The best option I know of is to use clock-based serial numbers (that
is, use seconds-since-epoch as the serial number), at which point the
session ID for practical purposes becomes a constant.

Full disclosure: I never thought the session ID was necessary in the
first place, we added it in response to a plea from the router guys.
So far the only real use I've found for it is when replaying
historical data for test purposes.