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

Shane Amante <shane@castlepoint.net> Mon, 31 October 2011 06:02 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 31CAB21F8C99 for <sidr@ietfa.amsl.com>; Sun, 30 Oct 2011 23:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.176
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5e8H6r1tHPx for <sidr@ietfa.amsl.com>; Sun, 30 Oct 2011 23:02:08 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 8D70321F8C9C for <sidr@ietf.org>; Sun, 30 Oct 2011 23:02:08 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id C6A2B268063; Mon, 31 Oct 2011 00:02:03 -0600 (MDT)
Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Mon, 31 Oct 2011 00:02:03 -0600 (MDT) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; 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 <shane@castlepoint.net>
In-Reply-To: <CAL9jLaa+L-C7+Gp54BpM8FjAj+EFMabwQB9SsPW0N4QnFEfVGw@mail.gmail.com>
Date: Mon, 31 Oct 2011 00:01:46 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <18DE49F0-AAC3-4C02-A122-6B9EF5F6C445@castlepoint.net>
References: <CAL9jLaa+L-C7+Gp54BpM8FjAj+EFMabwQB9SsPW0N4QnFEfVGw@mail.gmail.com>
To: sidr wg list <sidr@ietf.org>
X-Mailer: Apple Mail (2.1251.1)
Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs
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, 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:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtbgpdas.html
http://www.juniper.net/techpubs/en_US/junos11.3/topics/reference/configuration-statement/local-as-edit-protocols-bgp.html

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:
---snip---
   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..
---snip---

Thanks,

-shane



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: <http://tools.ietf.org/wg/sidr/draft-ietf-sidr-bgpsec-reqs/>
>   01 link: <http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs>
>  diff link: <http://tools.ietf.org/wg/sidr/draft-ietf-sidr-bgpsec-reqs/draft-ietf-sidr-bgpsec-reqs-01-from-00.diff.html>
> 
> 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
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr