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

Terry Manderson <> Wed, 28 March 2012 08:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD8DB21F8899 for <>; Wed, 28 Mar 2012 01:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.545
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4ovyLudoQ54v for <>; Wed, 28 Mar 2012 01:30:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 355A821F8890 for <>; Wed, 28 Mar 2012 01:30:06 -0700 (PDT)
Received: from ([]) by ([]) with mapi; Wed, 28 Mar 2012 01:30:05 -0700
From: Terry Manderson <>
To: Jeffrey Haas <>, "" <>
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: <>
In-Reply-To: <20120328081939.GA19843@slice>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: yes
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-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Mar 2012 08:30:16 -0000


On 28/03/12 6:19 PM, "Jeffrey Haas" <> 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.


> 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.