Skip to main content

Last Call Review of draft-ietf-sidr-rpki-rtr-

Request Review of draft-ietf-sidr-rpki-rtr
Requested revision No specific revision (document currently at 26)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-12-13
Requested 2011-12-03
Authors Randy Bush , Rob Austein
I-D last updated 2011-12-21
Completed reviews Secdir Last Call review of -?? by Hilarie Orman
Secdir Telechat review of -?? by Hilarie Orman
Assignment Reviewer Hilarie Orman
State Completed
Request Last Call review on draft-ietf-sidr-rpki-rtr by Security Area Directorate Assigned
Completed 2011-12-21
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

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

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."