[apps-discuss] APPSDIR review of draft-ietf-sidr-rpki-rtr-25

Lisa Dusseault <lisa.dusseault@gmail.com> Mon, 30 January 2012 18:03 UTC

Return-Path: <lisa.dusseault@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7DFC711E8086; Mon, 30 Jan 2012 10:03:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id E-TmnBUjNOBr; Mon, 30 Jan 2012 10:03:36 -0800 (PST)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8260C11E8081; Mon, 30 Jan 2012 10:03:33 -0800 (PST)
Received: by bkbzt4 with SMTP id zt4so3776964bkb.31 for <multiple recipients>; Mon, 30 Jan 2012 10:03:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=VrDhRwiJCzzfvMVJQiTn3j1OFDYayUTYIsuOUnQ7024=; b=cWy2OM8ZRyQOPjRDX1qoDQ4nASZGnEC//GwbOhoTJ3Cq7z9fF0uHtizStYtrhm1HUq jlLmMfS5HKyS8E1gk0DU20S2ZQIMocEMJ3AiEaBz3sAtSQbovxSqhF+TevAtke1w89lV c3BLkLqYT0iQZ1iqSifnFgO4PDgQBwiZlCM7Q=
MIME-Version: 1.0
Received: by with SMTP id im14mr5803808bkc.133.1327946612584; Mon, 30 Jan 2012 10:03:32 -0800 (PST)
Received: by with HTTP; Mon, 30 Jan 2012 10:03:32 -0800 (PST)
Date: Mon, 30 Jan 2012 10:03:32 -0800
Message-ID: <CAEi+uC6repb=dgZ9wr4bJDX--5-n+RN1p4vNr7aqHyyDGBR5SQ@mail.gmail.com>
From: Lisa Dusseault <lisa.dusseault@gmail.com>
To: apps-discuss@ietf.org, draft-ietf-sidr-rpki-rtr.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=000e0cdfdb601fb2f804b7c2aa4e
Cc: IESG <iesg@ietf.org>
Subject: [apps-discuss] APPSDIR review of draft-ietf-sidr-rpki-rtr-25
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jan 2012 18:03:37 -0000

Document: draft-ietf-sidr-rpki-rtr-25

Title: The RPKI/Router Protocol
Reviewer: Lisa Dusseault
Review Date: Jan 30
IETF Last Call Date: Nov 29 2011
IESG Telechat Date: Feb 2 2012?
Summary: Ready for publication on the standards track.

I reviewed draft-ietf-sidr-rpki-rtr-25 for the Apps Area group.

I noted that this draft is clear and mature for a v0 protocol.  It
describes a protocol that has been implemented at least in part in five
different implementations.  It has undergone lively discussion in an active
WG and in IETF Last Call.  The latest document iterations show a great deal
of stability.  This all suggests to me that if any flaws in architecture or
suitability exist, I am not going to be good at identifying them, as I am
not a routing domain expert.  Thus, I reviewed this document mostly from
the point of view of an outsider (can a reader with general Internet
expertise understand the document?) and I looked for general issues such as
IANA registry issues.

Section 7 (Transport)

I'm not qualified to judge the tradeoffs between supporting unprotected
TCP, waiting for TCP-AO, or doing something else, but I did note this had
been extensively discussed during IETF last call.

I read this section and then made some inferences:

 - Only a human administrator can tell if a collection of routers and
caches using RPKI are "on the same trusted and controlled network"
 - A human administrator would configure the routers and caches to use TCP,
based on their trust of the local network.
 - A router would not attempt to use the RPKI-rtr port with unprotected TCP
unless it was configured by the human administrator to do so
 - Thus, there is not a downgrade attack unless a human is involved in the
decision to downgrade the security configuration

I also infer that while a cache implementation MUST generically implement
unprotected TCP as a transport, that an instance of a cache may well be
configured simply not to respond to TCP requests on the RPKI-rtr port.

If these inferences are wrong, then I do have concerns about the
possibility of a downgrade attack.  However, I believe these inferences are
correct (and supported by text in section 11, e.g. "must rely on network
design and operational controls to provide protection") and are probably
the inferences any reasonably informed reader would make.  I did read the
architecture draft referenced in the introduction, but did not read all the
other WG drafts relating to RPKI.

Section 7.2 (TLS transport)

It's not clear to me why routers would need to provide a client certificate
to caches, because I had not assumed that the data transported in RPKI-RTR
was sensitive, only that it needed to be valid and authorized. I'm guessing
it has something to do with being able to manage load on very central
caches by dropping requests from unauthorized routers, which would be
either maliciously or unintentionally configured to use a cache that was
not set up to handle the load of those unauthorized routers.  If this is a
correct guess, I wonder if it would be helpful to be a bit more explicit
about this possibility?  Will there need to be an error code added, to be
used when a cache has to reject an unauthorized router request?

Section 11 (security considerations)

Except for my confusion around why routers need to identify themselves to
caches (what's the threat model for needing that), I appreciate the clarity
of this section.

Lisa D.