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

Stephen Kent <kent@bbn.com> Mon, 01 August 2011 21:19 UTC

Return-Path: <kent@bbn.com>
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 0CCFB21F8CE1 for <sidr@ietfa.amsl.com>; Mon, 1 Aug 2011 14:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.572
X-Spam-Level:
X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 eHyiiZIdvfli for <sidr@ietfa.amsl.com>; Mon, 1 Aug 2011 14:19:00 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7E55E21F8C90 for <sidr@ietf.org>; Mon, 1 Aug 2011 14:19:00 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:58073 helo=[10.84.131.231]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1QnztA-000NrE-HW; Mon, 01 Aug 2011 17:19:04 -0400
Mime-Version: 1.0
Message-Id: <p06240801ca5cc6f407b3@[10.243.32.72]>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E5DA24E7A@EUSAACMS0701.eamcs.ericsson.se >
References: <m2sjplf3v5.wl%randy@psg.com> <CA5C6F74.5BE9B%dougm.tlist@gmail.com> <7309FCBCAE981B43ABBE69B31C8D21390E5DA24E7A@EUSAACMS0701.eamcs.ericsson.se >
Date: Mon, 01 Aug 2011 17:18:51 -0400
To: Jakob Heitz <jakob.heitz@ericsson.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [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: Mon, 01 Aug 2011 21:19:01 -0000

At 3:16 PM -0400 8/1/11, Jakob Heitz wrote:
>It is easy enough to tell, but should we?
>It is also easy to protect other bgp attributes that affect path selection.

maybe, or maybe not. The AS path info can be protected using the RPKI,
because each ISP gets a cert that enumerates all AS#'s associated 
with that ISP.
So, when a router signs an AS path entry, the authorization of the 
router to represent can be verified using the RPKI data.  Other 
attributes may not
correspond to data that we can verify, based on the RPKI.

>However, the real question is:
>Do we want to invalidate an update if someone changes such an attribute?

in the case of As path, sinec we know that ISPs make use of AS path to
distinguish between different routes for the same prefix, it makes sense to
reject (or at least penalize locally) a route if the path sig data is invalid.

>Remember, if we send a route to an AS, even if it is less preferred
>than another route, then that route will be used if the preferred route
>becomes infeasible.

More precisely, the route MAY become the preferred route if the previous
preferred route becomes ...

>Therefore, there is not as much value in
>protecting attributes as there is in protecting the path.

I don't agree.  because the AS path length if a very important attribute
in pat selection, it merits protection.

>I thought there was a statement some time ago that we only protect
>the path, not the attributes.

that have been a lot of statements on this list over time :-).

>A prepend is not a change in path. It is more like an attribute.

Prepedning is a way that ISP use BGP to effect traffic engineering,
at a distance.  A route, technically, is a set of prefixes (NLRI) plus
an AS path.  I believe we are trying to protect routes. Biut I agree that
we ought to be more precise in the way we say this.

Steve