Re: [sidr] pCNT & prepending

Doug Montgomery <> Thu, 28 July 2011 15:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A585D21F8C5B for <>; Thu, 28 Jul 2011 08:53:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I4UvRNea2iiI for <>; Thu, 28 Jul 2011 08:53:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A43A621F8BD0 for <>; Thu, 28 Jul 2011 08:53:37 -0700 (PDT)
Received: by vws18 with SMTP id 18so3894113vws.27 for <>; Thu, 28 Jul 2011 08:53:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=wbA/Sv8dlmkucJYa8hDh1AoxxJEDL/lohxe9+Svbdyg=; b=PXzH9yv+08vvOxHl2qlS8rB76VubKE1V+clZxeHIWw5A5HwW0dPJO2D/IMsrZU8ONQ znz7ITY5lRf/OSZiYFY48tWWU1ObDPdPhc7WYRaxjgq4pF4WAJhfF+Sr7sr4uRhoPFXY IYK7aMznzeoTff83+yB4Rju5EQcladyMeW6n4=
Received: by with SMTP id ee2mr172008vdb.461.1311868417042; Thu, 28 Jul 2011 08:53:37 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id r12sm386133vcq.12.2011. (version=SSLv3 cipher=OTHER); Thu, 28 Jul 2011 08:53:36 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/
Date: Thu, 28 Jul 2011 11:53:32 -0400
From: Doug Montgomery <>
To: Highwayman <>, Doug Montgomery <>
Message-ID: <>
Thread-Topic: [sidr] pCNT & prepending
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
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 15:53:43 -0000

I think we would all benefit from your offer to survey the RS community to
see if solutions that did not effect PATH_LENGTH but do make the RS AS#
visible somewhere in the protocol (we can quibble about the syntax of
carrying that in AS_PATH vs PATH_SIGs later).

If one requires dropping routes with pCNT=0 from peers that are not
administratively configured to be route servers, then allowing a
unscrupulous transit provider to propogate that, now requires collusion
between two AS's.   There are other issues that come up if we consider
those scenarios.

One could think of having RS's somehow announce/declare themselves (e.g.,
an RPKI object/flag) ... But I will point out that if I am unscrupulous I
will just announce myself and proceed.

Anyway, again ... Let's get the requirement right before we talk about the
encoding / mechanisms - you offer to survey if "translucent" supports the
use case / business model of the RS community is an important step towards
getting the requirement right.


On 7/28/11 11:31 AM, "Highwayman" <> wrote:

>It's not clear to me how the system is protected from some unscrupulous
>transit provider setting their AS's to zero width, in order to attract
>more traffic.  Unless there is a side channel for ASN which may validly
>announce themselves in this way ?
>I agree that transparency is the minimum requirement. I do not, yet,
>discount the emotional demand for Route Server users to not be seen to be
>RS users.  For many years we peered at LINX and, frankly, would not have
>dreamt of either using the RS, or be seen to be using it -- we were big
>boys -- notwithstanding, we peered openly... go figure :-)
>Chris Hall.                  +44 7970 277 383 (iPhone)
>On 28 Jul 2011, at 11:11, "Montgomery, Douglas" <> wrote:
>> Danny,
>> Yes, that is certainly the idea if we agree to protect prepending (as
>>opposed to just avoiding multiple Sigs in the the presence of
>> If we protect prepending, the pCNT must be carried in the protocol,
>>covered by the Sig and verified ... i.e., what you suggest below .. in
>> Note, that if you don't want to protect prepending ... only avoid
>>repeating sigs ..., then you don't have to carry pCNT in the protocol.
>>Just update the Sig verification algorithm treat sequences of repeated
>>AS's as one.
>> If we like the "translucent" approach to support RS, then we need to
>>carry pCNT in BGSSEC.   You are right we do need enhanced
>>receive/process rules such as:
>> 1. Only accept pCNT=0 from peers that are configured to be route
>> 2. Don't accept paths with multiple pCNT=0 entries in a row.
>> Anyway, if we like this approach, we can talk the details of the
>>receiving rules / process rules to protect potential abuse.
>> dougm
>> Doug Montgomery - Manager Internet and Scalable Systems Research Group
>>/ Information Technology Laboratory / NIST
>> ________________________________________
>> From: [] On Behalf Of Danny
>>McPherson []
>> Sent: Thursday, July 28, 2011 11:02 AM
>> To: sidr wg list
>> Subject: [sidr] pCNT & prepending
>> 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..
>> -danny
>> _______________________________________________
>> sidr mailing list
>> _______________________________________________
>> sidr mailing list
>sidr mailing list