Re: [sidr] Injecting idea of "freshness of repository data" into BGP

Eric Osterweil <eosterweil@verisign.com> Sun, 01 April 2012 19:56 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 7EF4721F8800 for <sidr@ietfa.amsl.com>; Sun, 1 Apr 2012 12:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.299
X-Spam-Level:
X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, 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 Sd17YW7QWitp for <sidr@ietfa.amsl.com>; Sun, 1 Apr 2012 12:56:48 -0700 (PDT)
Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id BD6D921F87BF for <sidr@ietf.org>; Sun, 1 Apr 2012 12:56:45 -0700 (PDT)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKT3iy++UKLifJadqu6odkUu8EfuA3+NSi@postini.com; Sun, 01 Apr 2012 12:56:47 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 q31Jug8S001092; Sun, 1 Apr 2012 15:56:42 -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:56:41 -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: <20120329081625.GA9609@slice>
Date: Sun, 1 Apr 2012 12:56:38 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <C80C23B3-C6D9-44CA-A020-144890CA0274@verisign.com>
References: <20120328081939.GA19843@slice> <CA796250-4EA9-468D-BB4A-4C1187D2148F@tcb.net> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice>
To: Jeffrey Haas <jhaas@pfrc.org>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 01 Apr 2012 19:56:41.0569 (UTC) FILETIME=[8EA4B510:01CD1041]
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP
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:56:48 -0000

On Mar 29, 2012, at 1:16 AM, Jeffrey Haas wrote:

> Jakob,
> 
> On Thu, Mar 29, 2012 at 03:51:10AM -0400, Jakob Heitz wrote:
>> Could we not put a freshness indication into the BGP update?
>> Then everyone that receives the new update would know to invalidate the less fresh paths.
> 
> Just to be clear, this is not a route freshness mechanism I am
> recommending.  What I am recommending is a signal that a repository has
> newer data that may be needed for validation.
> 
> Given such a mechanism, we may be able to reduce the work upon the
> repository mirroring system (distributed or not) by not having to regularly
> poll for new objects frequently unless the repository indicates there is new
> data present.


The RPKI and BGP have orthogonal data and distribution models though.  The RPKI is disseminating certs and ROAs that reflect the _policy_ of resource allocations and holders.  BGP is disseminating reachability and routing information.  While the former is being used to semantically inform the latter, they do not have a tight coupling.  In fact, the loose coupling between them is currently only oneway (cache to router if I'm not mistaken).  IIRC, once the RPKI data has been cached, it is an unsigned, unverifiable tuple that gets pushed to a router.  How can we start from there and get secure information flowing the other way, exactly?

The idea of adding freshness to the RPKI does not have anything to do with the reachability of BGP[SEC].  I think this is actually hitting on a new requirement that needs to be documented: the _resource certification system (RPKI)_ must provide a freshness model.  I would suggest that this stay as far from BGP as we can get it.  BGP is a great soft-state protocol (where some may define ``great'' differently), but I don't currently tweet or update my fb status over it.

Eric