[secdir] Review of draft-ietf-sidr-rpki-rtr-20

["Hilarie Orman" <[e-mail]>]

security review of
The RPKI/Router Protocol, draft-ietf-sidr-rpki-rtr-20

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'll accept on faith that the records in the cache are secured by
public keys in a reasonable fashion.  The problem addressed by the
protocol is: how do routers securely obtain the records, under the
hypothesis that they will not actually carry out validation?  The
answer is a simple protocol that concentrates assuring record
freshness and punts security to some preconfigured point-to-point
communication with some kind of transport security.  This document
cheerily anticipates the debut of I-cant-Believe-Its-Not-TCPMD5
(TCP-AO).

The draft makes reference to "monkey in the middle attacks".  I can't
decide if this is more insulting to men or monkeys, but in any case, it
needs some kind of reference to distinguish it from the more normal
MITM term.

The Security Considerations state:
      The identity of the cache server MUST be verified and
      authenticated by the router client, and vice versa, before any
      data are exchanged.
yet there is no explanation of what this means, in general, because
the protocol has no authentication component.  Some of the transports
can do this, but not all.  More explanation is needed.

The cache identifies its boot instance via a nonce, and the client
routers are supposed to record the nonce and discard all records if
the nonce changes.  The nonce is only 16 bits, though, and the
probability of two boot instances choosing the same nonce is too high,
in my opinion.

"Commensurate" is an odd term.  It simply means "don't use the serial
number if the nonce doesn't match." 

Hilarie