Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01

Randy Bush <randy@psg.com> Thu, 05 May 2016 22:51 UTC

Return-Path: <randy@psg.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B826B12D825 for <sidr@ietfa.amsl.com>; Thu, 5 May 2016 15:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level:
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6GZSmC25llB for <sidr@ietfa.amsl.com>; Thu, 5 May 2016 15:51:55 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 492ED12B013 for <sidr@ietf.org>; Thu, 5 May 2016 15:51:55 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from <randy@psg.com>) id 1ayS7d-0007bi-J0; Thu, 05 May 2016 22:51:53 +0000
Date: Fri, 06 May 2016 07:51:51 +0900
Message-ID: <m2r3dgnmns.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Matthias Waehlisch <m.waehlisch@fu-berlin.de>
In-Reply-To: <alpine.WNT.2.00.1605051758070.2308@mw-PC>
References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> <CAL9jLaa6rcJ42cFyJEW1XTcvMfqnLr++VE7kHgpOG1ywL4S1JA@mail.gmail.com> <alpine.WNT.2.00.1605051758070.2308@mw-PC>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue")
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/m6dQEkzjhBm4MzS7V8y83fTchkE>
Cc: sidr <sidr@ietf.org>
Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 May 2016 22:51:57 -0000

>> mostly because I don't see a clear method to ensure that 'third party' has:
>>   1) up-to-date information
>   Same with RTR cache server.

i would not load routers from rpki caches i do not own and control

>>   2) my best interest at heart
>   If you peer with a route server, you should establish a trust relation 
> anyway.

in my heart i agree with chris, a prudent operator does not outsource
security.

otoh, i also do not think a prudent operator outsources bgp, i.e. uses a
route server.

putting the two together, if you are willing to outsource bgp to a route
server, then outsourcing bgp security to the route server is not much of
a leap.

chris, think of it as shooting yourself in the foot with a two-barrelled
gun instead of one with one barrel.  :)

randy