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

DougM lists <dougm.tlist@gmail.com> Thu, 29 March 2012 15:08 UTC

Return-Path: <dougm.tlist@gmail.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 518EB21F87EB for <sidr@ietfa.amsl.com>; Thu, 29 Mar 2012 08:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 d06AKhbjUUGW for <sidr@ietfa.amsl.com>; Thu, 29 Mar 2012 08:08:07 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D42921F87EA for <sidr@ietf.org>; Thu, 29 Mar 2012 08:08:06 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so2288361bku.31 for <sidr@ietf.org>; Thu, 29 Mar 2012 08:08:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=1mmQ0OBvASDQWJ7dm+xyWupyBiWu0fKCCiKzryiggVo=; b=P9hH2N0HrEaXaMa2vE9jiAR3pyCaGg6CBPpSghP3K6S5JadlSBaAWrxxUo+kACdv0E dtTbouO1jU30DI5yS7YKSlcaw7zofdrtR0kZS/UYfVFMzDVgzjgaNf9YwL3E9ah4bNKS gp/xK5SXjkGrDwdAPc9MIRPn8LbJlvjR8D4znkF9sLEAfb8ATBvvnKxF7vMkrFe67RBR nzIfbT/yRjPpuYMCAFgB4VVZxA3jak+DJctbEpTYEpZoDVBQ601LkSi+DESpoa7QoiC5 b65ZraayLxCiWyUXtBYJKDzC/BERTcducTOr7wfHzY3NYVj0ZIPbI6SusgvAsKRRxR0+ VIig==
Received: by 10.204.156.65 with SMTP id v1mr13677680bkw.109.1333033685621; Thu, 29 Mar 2012 08:08:05 -0700 (PDT)
Received: from [130.129.87.191] (dhcp-57bf.meeting.ietf.org. [130.129.87.191]) by mx.google.com with ESMTPS id s16sm14444007bkt.3.2012.03.29.08.08.04 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 08:08:04 -0700 (PDT)
Message-ID: <4F747AD3.2040009@gmail.com>
Date: Thu, 29 Mar 2012 11:08:03 -0400
From: DougM lists <dougm.tlist@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: sidr@ietf.org
References: <20120328081939.GA19843@slice> <CA796250-4EA9-468D-BB4A-4C1187D2148F@tcb.net> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <00857EED-F2E7-4E41-884E-F25492CF3BF1@ericsson.com>
In-Reply-To: <00857EED-F2E7-4E41-884E-F25492CF3BF1@ericsson.com>
Content-Type: multipart/alternative; boundary="------------090304040306020700040507"
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: Thu, 29 Mar 2012 15:08:08 -0000

On 3/29/2012 3:58 AM, Jakob Heitz wrote:
>  Any place that does not receive a new BGP update can not be helped.
>  Even with a beacon.

Just to be clear, the explicit expire time approach to freshness does 
work to age-out updates along a update path that is no longer 
bgp-reachable from the origin.    It is the only technique that will 
help all withdrawl suppression, etc scenarios.

That is a slightly different point than this thread (how to indicate 
that a router has updated RPKI state).  But if you were doing origin 
beacons like the -01 draft, you may not need to do this.

Actually from the belt-and-suspenders approach discussed yesterday 
(combining coarse beaconing with pre-staging two rtr keys and doing 
faster paced roll) ... what we need to do is expedite / trigger CRL 
retrievalal / processing (of router old key).

The important part of a key roll, is invalidating the old key.   We 
can't pre-stage the CRL, so while we can move to the new key at the 
speed of BGP convergence, we can only revoke the old key at the speed of 
RPKI publication, data distribution, and cache-to-rtr.

Frankly if we limited the granularity of the beacon to days, I suspect 
that will be faster than the global CRL pipeline.

dougm

>
>  Therefore, a freshness indicator in the BGP update itself is enough
>  to invalidate less fresh updates.
>
>  Only freshen the BGP update when you actually have a dispute with
>  your old provider.
>
>  -- Jakob Heitz.
>
>
>  On Mar 29, 2012, at 9:51 AM, "Jakob Heitz" <jakob.heitz@ericsson.com>
>  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.
> >
> > Here is the key point: The new update will reach everywhere that it
> > needs to go. Won't it?
> >
> > No expiry time needed.
> >
> > -- Jakob Heitz. _______________________________________________
> > sidr mailing list sidr@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidr
>  _______________________________________________ sidr mailing list
>  sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr