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

Terry Manderson <terry.manderson@icann.org> Wed, 28 March 2012 08:30 UTC

Return-Path: <terry.manderson@icann.org>
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 BD8DB21F8899 for <sidr@ietfa.amsl.com>; Wed, 28 Mar 2012 01:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.545
X-Spam-Level:
X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 4ovyLudoQ54v for <sidr@ietfa.amsl.com>; Wed, 28 Mar 2012 01:30:09 -0700 (PDT)
Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 355A821F8890 for <sidr@ietf.org>; Wed, 28 Mar 2012 01:30:06 -0700 (PDT)
Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 28 Mar 2012 01:30:05 -0700
From: Terry Manderson <terry.manderson@icann.org>
To: Jeffrey Haas <jhaas@pfrc.org>, "sidr@ietf.org" <sidr@ietf.org>
Date: Wed, 28 Mar 2012 01:30:03 -0700
Thread-Topic: [sidr] Injecting idea of "freshness of repository data" into BGP
Thread-Index: Ac0Mu5MAdvpX0+KIQjuOtxoyEGbdHQAAWW6c
Message-ID: <CB99092B.23A02%terry.manderson@icann.org>
In-Reply-To: <20120328081939.GA19843@slice>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415804203_10487216"
MIME-Version: 1.0
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: Wed, 28 Mar 2012 08:30:16 -0000

Jeff,

On 28/03/12 6:19 PM, "Jeffrey Haas" <jhaas@pfrc.org> wrote:

> Per my mic comment at IETF 83:
> During the San Diego interim session we had discussed potentially signaling
> in BGP the idea that a given AS may have fresher data available in its
> repository.
> 
> My original thought had been something along the lines of a new AFI/SAFI
> that contains this data.  Matt L., in discussing this point at the mic with
> me, suggested something that has resemblence to the serial number field in
> DNS.  For example, this field could go into the "reserved" field that a
> route originator puts into the signature.  If the serial number increases,
> this could suggest that fresher information is present in that originator's
> repository.

I think this is interesting. I think I would further like an
assessment/disussion of this "serial number" being consistent between the
BGP information, the RPKI repository, and this through the validated cache
and presented to the router via rpki-rtr.

It may well present far too many error situations by doing that, but may
also provide a brilliant statement of a consistent view matching origination
intent in a time and space perspective.

0.02c

> 
> Discussion around this mechanism:
> - If this is part of a given route's signature block, the issue is that a
>   given origin may be seen with a number of serial numbers  depending on
>   propagation of BGP routes.
> - Such a serial number is important not only for the originator of a route,
>   but also all parties participating in the signature.
>   This particular details suggests to me that such signaling probably should
>   be separate from the signatures.
> - By being part of the signature, we get some level of freshness in things
>   in a route-by-route basis and less likely that a completely separate
>   "route" that is repository freshness is dropped.
>