Re: [sidr] Slides for "RPKI Over BitTorrent" presentation

Eric Osterweil <eosterweil@verisign.com> Sun, 01 April 2012 19:44 UTC

Return-Path: <eosterweil@verisign.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 42EB121F8A25 for <sidr@ietfa.amsl.com>; Sun, 1 Apr 2012 12:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
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 ljpVA2SoXXyQ for <sidr@ietfa.amsl.com>; Sun, 1 Apr 2012 12:44:35 -0700 (PDT)
Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id C957421F8A23 for <sidr@ietf.org>; Sun, 1 Apr 2012 12:44:06 -0700 (PDT)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKT3iwBop/Z9PdZVJLjFJCPEmFfy4g7K55@postini.com; Sun, 01 Apr 2012 12:44:07 PDT
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q31Ji5Wo000843; Sun, 1 Apr 2012 15:44:05 -0400
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.142]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 15:44:03 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <20120330181017.A9BE46EFC01@minas-ithil.hactrn.net>
Date: Sun, 1 Apr 2012 12:44:01 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <939E1E56-C9EE-4210-81EC-DDE124BAE9E1@verisign.com>
References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <A76204B3-5EF3-4212-9136-B8E3266C7D17@tcb.net> <20120329100434.BBE5A6EE29F@minas-ithil.hactrn.net> <1DC0A868-0B15-448E-93E6-C61CC89AB6A6@lacnic.net> <4F75B916.6000807@gmail.com> <20120330181017.A9BE46EFC01@minas-ithil.hactrn.net>
To: Rob Austein <sra@hactrn.net>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 01 Apr 2012 19:44:04.0825 (UTC) FILETIME=[CB96BC90:01CD103F]
Cc: sidr@ietf.org
Subject: Re: [sidr] Slides for "RPKI Over BitTorrent" presentation
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sun, 01 Apr 2012 19:44:36 -0000

Hey Rob,

One more meta-comment on this thread: we (as designers) should not expect to be prescribing exactly how operators will run their systems.  Here in the very early stages we are seeing the early adopters deploy in ways that make _their_ operations easy.  imho, this is always going to be the bottom line/starting point.  If a solution requires a specific operational model (when others are technically correct), and the overall system scalability can suffer this way, I think we have a fundamental problem.  

More succinctly, operators shouldn't need to know why you want their certs in a hierarchy.  Rather, we should recognize that they are telling us that flat structures make their lives easier, and we should use that to reengineer what _they_ need.

Just my 0.02,

Eric

On Mar 30, 2012, at 11:10 AM, Rob Austein wrote:

> While I will admit to some astonishment that the following explanation
> could possibly be news to long-time participants in this WG (given how
> much time I've spent whining about this issue over the last five years
> or so both in public and in private), let me quote from the slides:
> 
>    * How efficient [fetching RPKI repositories using rsync] is
>      depends heavily on how the publication repositories are
>      organized.
> 
>    * In an efficiently organized repository, filesystem hierarchy
>      follows X.509 certificate hierarchy, so that one can pick up
>      significant subtrees with a single rsync connection.
> 
>    * To date, the RIRs have chosen to deploy flat hierarchies where
>      there is no relationship at all between filesystem hierarchy
>      within the repository and certificate hierarchy.
> 
> To make that more concrete, here's an example.  Let's assume we have
> the following trivial hierarchy: Bob and Betty are issued by Alice,
> Carol and Carl are issued by Bob, Dave, and Dana are issued by Carol,
> Dara is issued by Carl, and and all of these are hosted in a single
> repository.
> 
> In an inefficient, "flat" repository, the publication points for
> objects issued by these entities would look something like this:
> 
>    rsync://example.org/rpki/Alice/
>    rsync://example.org/rpki/Betty/
>    rsync://example.org/rpki/Bob/
>    rsync://example.org/rpki/Carl/
>    rsync://example.org/rpki/Carol/
>    rsync://example.org/rpki/Dana/
>    rsync://example.org/rpki/Dara/
>    rsync://example.org/rpki/Dave/
> 
> In a hierarchical repository, the same publication points would look
> more like this:
> 
>    rsync://example.org/rpki/Alice/
>    rsync://example.org/rpki/Alice/Betty/
>    rsync://example.org/rpki/Alice/Bob/
>    rsync://example.org/rpki/Alice/Bob/Carl/
>    rsync://example.org/rpki/Alice/Bob/Carl/Dara/
>    rsync://example.org/rpki/Alice/Bob/Carol/
>    rsync://example.org/rpki/Alice/Bob/Carol/Dana/
>    rsync://example.org/rpki/Alice/Bob/Carol/Dave/
> 
> Assuming top-down tree walk (the normal case), retrieving objects
> issued by this set of entities takes eight rsync connections with the
> flat repository, as opposed to one rsync connection with the
> hierarchical repository.
> 
> In practice one might want a slightly more complex structure to limit
> the size of individual directories, but it doesn't matter so long as
> the filesystem hierarchy is organized in such a way that picking up
> an issuer's publication point picks up a non-trivial number of its
> subjects' publication points automatically.   It doesn't have to be
> perfect, just has to do enough better than the flat model to amortize
> the cost of setting up and tearing down the rsync connection over a
> significantly larger number of files.
> 
> This is not about PKI, it's purely an rsync efficiency issue.
> 
> Presumably there are scaling limitations to the hierarchical approach,
> but anecdotal evidence among the people I've asked ("I tried ... and
> it worked") suggests that, if the underlying networks and filesystems
> are in good shape, a single rsync connection ought to be able to
> handle up to at least 10,000 small files, perhaps a lot more than
> that.  Note that this is just talking about rsync itself: mileage
> might vary significantly if the underlying networks or filesystems are
> seriously broken.  Also note that these anecdotal estimates have not
> been tested in any rigorous fashion as far as I know, so that's
> another entry on my list of things we ought to be measuring.
> 
> Hope this helps to clarify the change I've been suggesting.
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr