Re: [sidr] pCNT & prepending

Stephen Kent <> Thu, 28 July 2011 20:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5A8221F8AC9 for <>; Thu, 28 Jul 2011 13:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.571
X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3CzCIaxWPGCx for <>; Thu, 28 Jul 2011 13:50:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 38EF521F8AAC for <>; Thu, 28 Jul 2011 13:50:06 -0700 (PDT)
Received: from ([]:59829 helo=[]) by with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1QmXWv-000Pce-Jp; Thu, 28 Jul 2011 16:50:05 -0400
Mime-Version: 1.0
Message-Id: <p0624080fca572d4618ba@[]>
In-Reply-To: <>
References: <>
Date: Thu, 28 Jul 2011 16:49:52 -0400
To: Danny McPherson <>
From: Stephen Kent <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: sidr wg list <>
Subject: Re: [sidr] pCNT & prepending
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: Thu, 28 Jul 2011 20:50:06 -0000

At 11:02 AM -0400 7/28/11, Danny McPherson wrote:
>Doug et al,
>I like the general objective of pCNT and this seems a good idea to 
>me.  My only comment at the microphone was that if we add this for 
>compression, then validation should require that pCNT MUST be equal 
>to the number of _contiguous ASx appearances in the path (i.e., no 
>more, no less, and only contiguous).
>I do wonder if pCNT=0 for transparent route servers introduces the 
>opportunity for some sort of downgrade attack of sorts..

There is a valid secruity concern when we allow 0 as a valid pCNT value.

I think Roque's suggestion of an EKU to mark an EE cert as being 
associated with a route server is helpful here.  Yes, this is a 
self-assertion, and thus not authoritative. But, it could be a 
convenient mechanism to assist in configuration for checking when 
it's OK to receive an update with a 0 pCNT value. Specifically, if we 
agree that an ISP knows when a configured peer is an RS, then we can 
mandate that an ISP check to make sure that an update received from a 
peer with a 0 pCNT is, in fact, coming from what it believes is an 
RS. Having a marker in a cert that says "HI, I'm an RS" at least 
makes this intent clear.  (One also could imagine that, since IXPs 
are well known and the route servers at IXPs are known, a third party 
could scan the RPKI looking for certs that claim to be associated 
with RSes, and checking to see if they appear to be legit.)

BGPSEC also could mandate some configuration capabilities that enable 
ASes further along a path to filter routes based on 0 pCNT values in 
a path. For example, one might say that any AS can be configured to 
drop a route with 2 or more 0 pCNT hops in a row, or more than 2 
total, or whatever.  If we can reach agreement on any general rules 
with regard to 0 pCNT values, these rules can become part of the 
validation standard.