Re: [Idr] Stephen Farrell's No Objection on draft-ietf-idr-as-migration-03: (with COMMENT)

joel jaeggli <joelja@bogus.com> Thu, 19 February 2015 04:44 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEF31A8704; Wed, 18 Feb 2015 20:44:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.582
X-Spam-Level:
X-Spam-Status: No, score=0.582 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ESTABLISH2=2.492, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPZ09tCaSNFR; Wed, 18 Feb 2015 20:44:47 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B8B1A86F6; Wed, 18 Feb 2015 20:44:46 -0800 (PST)
Received: from mb-aye.local (c-98-248-47-249.hsd1.ca.comcast.net [98.248.47.249]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t1J4ickU041703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 Feb 2015 04:44:39 GMT (envelope-from joelja@bogus.com)
Message-ID: <54E56A31.20508@bogus.com>
Date: Wed, 18 Feb 2015 20:44:33 -0800
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
References: <20150219013655.19791.36741.idtracker@ietfa.amsl.com>
In-Reply-To: <20150219013655.19791.36741.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="rO46bA9Kw0HBIU20dAt13uOrjW4sNL4cS"
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/IrhrHvmpDy2_wlzVga4xAIRFOrY>
Cc: morrowc@ops-netman.net, idr@ietf.org, idr-chairs@ietf.org, draft-ietf-idr-as-migration.all@ietf.org
Subject: Re: [Idr] Stephen Farrell's No Objection on draft-ietf-idr-as-migration-03: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2015 04:44:48 -0000

On 2/18/15 5:36 PM, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-idr-as-migration-03: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> 
> In the security considerations, isn't there a threat of
> hijacking traffic (for whatever purpose) if an
> unauthorised party can migrate?

I wouldn't  expect the threat of hijack, either due to mis-origination
or as-path manipulation to be greater during the merger of two ASNs then
operating them seperately. the opportunity for grievous error exists but
that's not extrinsic to the common administrative domain encompassing
both ASNs.

With respect to a changing the backing asn on a router with changing the
asn on the bgp session with the customer,  the goal is to
leave-pre-eastablished relationships unchanged until they can later be
migrated. that can include the ip addresses in use on both ends, arp
entries, shared secrets if employed and potentially even the tcp session
itself, if supported by the platform.

>