[sidr] pCNT & (AS_PATH) prepending: Is it in scope?

Shane Amante <shane@castlepoint.net> Thu, 28 July 2011 19:01 UTC

Return-Path: <shane@castlepoint.net>
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 530051F0C3C for <sidr@ietfa.amsl.com>; Thu, 28 Jul 2011 12:01:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpIfDu8PSPjQ for <sidr@ietfa.amsl.com>; Thu, 28 Jul 2011 12:01:10 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3761F0CD7 for <sidr@ietf.org>; Thu, 28 Jul 2011 12:00:32 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id 83E25268037; Thu, 28 Jul 2011 13:00:31 -0600 (MDT)
Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Thu, 28 Jul 2011 13:00:31 -0600 (MDT) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=56271; data-bytes=0
From: Shane Amante <shane@castlepoint.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Jul 2011 13:00:29 -0600
Message-Id: <19BD9B69-B1EE-495E-8795-38DDE3BF6D4A@castlepoint.net>
To: sidr@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [sidr] pCNT & (AS_PATH) prepending: Is it in scope?
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, 28 Jul 2011 19:01:11 -0000

Hi,

I have a question for the WG.  In a series of e-mail exchanges earlier this year, I had thought it was concluded that BGPSEC was merely being used as a means to express that a BGP UPDATE had passed through a series of ASN's, i.e.: it's an expression of a "breadcrumbs", if you will, that can [later] be validated by receiver that are further downstream.  IOW, it's not a validation of the TE policies (e.g.: AS_PATH prepending) applied by ASN's.

I went back to the BGPSEC requirements:
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs-00
... and, if I look at Req #3.19:
   3.19  A BGPsec design SHOULD NOT presume to know the intent of the
         originator of a NLRI, nor that of any AS on the AS Path.

What was the intended meaning of the word "intent"?  I thought that word was meant to say that BGPsec was not intended to validate TE policies that may, or may not, be applied to the NLRI.  If that is correct, then why is the WG looking at signing an BGP attribute that expresses the the number of times an ASN may be prepended?  Or, has the WG had a change of direction and I haven't kept up to speed?

I would note that the reason I'm asking the above is that it may not be the originator that is performing AS_PATH prepending.  Specifically, a customer may use a provider's BGP TE communities to ask the provider to perform AS_PATH prepending (selectively) on their behalf.  But, since these BGP TE communities are not signed, then how would a receiver of the NLRI know that an AS_PATH should or should not have been prepended by an intermediate/transit ASN?

Thanks,

-shane