Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

Shane Amante <> Mon, 31 October 2011 06:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 31CAB21F8C99 for <>; Sun, 30 Oct 2011 23:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.176
X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C5e8H6r1tHPx for <>; Sun, 30 Oct 2011 23:02:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8D70321F8C9C for <>; Sun, 30 Oct 2011 23:02:08 -0700 (PDT)
Received: by (Postfix, from userid 0) id C6A2B268063; Mon, 31 Oct 2011 00:02:03 -0600 (MDT)
Received: from ( []) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by with SMTP; for; Mon, 31 Oct 2011 00:02:03 -0600 (MDT) (envelope-from
X-Avenger: version=0.7.8;; client-ip=; client-port=64722; syn-fingerprint=65535:54:1:64:M1452,N,W2,N,N,T,S; data-bytes=0
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Shane Amante <>
In-Reply-To: <>
Date: Mon, 31 Oct 2011 00:01:46 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: sidr wg list <>
X-Mailer: Apple Mail (2.1251.1)
Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs
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: Mon, 31 Oct 2011 06:02:09 -0000

I do have one question about this draft.  In looking at all of the requirements for BGPSec, are AS migration scenarios in- or out-of-scope for BGPSec?  IOW, when one SP (AS A) buys/merges with another SP (AS B) what typically happens is they will consolidate to a single ASN, e.g.: either AS A or AS B.  The primary goal is to (try to) do that rapidly _without_ requiring /any/ coordination and as little disruption as possible across a very large set of the SP's customers.  As such, several years ago [several] vendors have implemented features that satisfy this requirement:

There are several permutations of the aforementioned feature; however, the overall goal of these features is to NOT alter the AS_PATH length, either on receipt or transmission of the AS_PATH (during the length of time of the migration), since AS_PATH length plays a crucial role in BGP's path selection algorithm and, ultimately, the amount of traffic sent or received to that SP.

I am unaware of any draft or RFC within the IETF that one could refer to with more detail on the above features, but I may be misinformed.  However, I will state (emphatically) that these features are currently being used now and will continue to be used in the future.

If ASN migrations are not going to be accounted for in BGPSEC, then would it be prudent to explicitly say so in Req #3.4 wrt "operational considerations for deployment" in the "e.g." part:
   3.4   A BGPsec design MUST provide analysis of the operational
         considerations for deployment and particularly of incremental
         deployment, e.g, contiguous islands, non-contiguous islands,
         universal deployment, etc..



On Oct 28, 2011, at 12:40 PM, Christopher Morrow wrote:
> Seems that the authors, at least, expect this doc to be prepared for
> WGLC, could we do that concluding 11/11/11 please?
> Draft link: <>
>   01 link: <>
>  diff link: <>
> Abstract:
> "This document describes requirements for a future BGP security
>   protocol design to provide cryptographic assurance that the origin AS
>   had the right to announce the prefix and to provide assurance of the
>   AS Path of the announcement."
> Thanks!
> -Chris
> <wg-co-chair-haircut == completed>
> _______________________________________________
> sidr mailing list