[secdir] Secdir review of draft-ietf-idr-as-migration-04

Paul Wouters <paul@nohats.ca> Wed, 22 April 2015 14:25 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 348741A9302; Wed, 22 Apr 2015 07:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LFDsFggeskoT; Wed, 22 Apr 2015 07:25:28 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549231AC3C2; Wed, 22 Apr 2015 07:24:43 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lX3tZ6Ww3z7YR; Wed, 22 Apr 2015 16:24:38 +0200 (CEST)
Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=BKskxb3r
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id D_IUWVyM-csK; Wed, 22 Apr 2015 16:24:38 +0200 (CEST)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 22 Apr 2015 16:24:38 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca []) by bofh.nohats.ca (Postfix) with ESMTP id 3D923809F8; Wed, 22 Apr 2015 10:24:37 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1429712677; bh=faUvmWTu6Z8oPh2nhbFl9b/WyqQtGBocZIm7qeqNrK8=; h=Date:From:To:Subject; b=BKskxb3rUz4qODslOfnb0ojWcXNeJ/SRWDgfe/slgH9Nl89Bm44nypBhVHwu4Jjm7 y61cSowWw9YdkuJV4puaNTTQKKtIM52JEdrMSGjNvyBvKTElmDrA6+rNtKek1iNdim D2k3yIdRCRNsy9oTaKSZxG+2V8Dk+sXabM9DB1kc=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t3MEOaTN004017; Wed, 22 Apr 2015 10:24:36 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Wed, 22 Apr 2015 10:24:36 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-idr-as-migration.all@tools.ietf.org
Message-ID: <alpine.LFD.2.10.1504221013510.29890@bofh.nohats.ca>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/iwMzd3XOL94c5MNMjdwMrQr3CxY>
Subject: [secdir] Secdir review of draft-ietf-idr-as-migration-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Apr 2015 14:25:30 -0000

Secdir review of draft-ietf-idr-as-migration-04

[Note: I am not a BGP expert]

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes a common AS migration deployment scenario, and
lists the features and practises that are used in an AS migration for
reference in future BGP work. Additionally, it is a useful document
for those BGP administrators that need to perform such an AS migration.

I think this draft is Ready.

My only suggestion would be to consider to emphasize the warning paragraph
at the end of section 3.2 on routing loops either by creating its own
sub-section or by mentioning this again in the Security Considerations.

(But I might be more sensitive to routing loops than real BGP administrators)