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. >
- [Idr] Stephen Farrell's No Objection on draft-iet… Stephen Farrell
- Re: [Idr] Stephen Farrell's No Objection on draft… joel jaeggli