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

Randy Bush <randy@psg.com> Tue, 31 January 2012 21:28 UTC

Return-Path: <randy@psg.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C5821F856A; Tue, 31 Jan 2012 13:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level:
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnLyrekxFlsP; Tue, 31 Jan 2012 13:28:15 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id E270121F8569; Tue, 31 Jan 2012 13:28:15 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <randy@psg.com>) id 1RsLFM-0000kJ-Pr; Tue, 31 Jan 2012 21:28:12 +0000
Date: Wed, 01 Feb 2012 06:28:11 +0900
Message-ID: <m2y5snlfys.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Lisa Dusseault <lisa.dusseault@gmail.com>
In-Reply-To: <CAEi+uC6repb=dgZ9wr4bJDX--5-n+RN1p4vNr7aqHyyDGBR5SQ@mail.gmail.com>
References: <CAEi+uC6repb=dgZ9wr4bJDX--5-n+RN1p4vNr7aqHyyDGBR5SQ@mail.gmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Cc: draft-ietf-sidr-rpki-rtr.all@tools.ietf.org, apps-discuss@ietf.org, IESG <iesg@ietf.org>
Subject: Re: [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: Tue, 31 Jan 2012 21:28:16 -0000

hi lisa,

> I noted that this draft is clear and mature for a v0 protocol.

thanks

> 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

you are basically correct.


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

definitely

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

exactly.

> 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?

no error code as no session to transport it.  but explaining why the
defense would be good.  thanks.

but, truth be told, no implementors are playing tls.  given peter's
concerns about tls, we would consider just dropping it if it is not too
much of a change at this late date.

randy