[secdir] SECDIR Review of draft-ietf-idr-bgp-enhanced-route-refresh-06

"Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com> Sat, 31 May 2014 07:07 UTC

Return-Path: <zhangdacheng@huawei.com>
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 021ED1A006C; Sat, 31 May 2014 00:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ToENlb4w0Zcg; Sat, 31 May 2014 00:07:10 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4691A0421; Sat, 31 May 2014 00:07:09 -0700 (PDT)
Received: from (EHLO lhreml204-edg.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHQ08109; Sat, 31 May 2014 07:07:04 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com ( by lhreml204-edg.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Sat, 31 May 2014 08:06:27 +0100
Received: from NKGEML401-HUB.china.huawei.com ( by lhreml401-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Sat, 31 May 2014 08:07:03 +0100
Received: from NKGEML507-MBS.china.huawei.com ([]) by nkgeml401-hub.china.huawei.com ([]) with mapi id 14.03.0158.001; Sat, 31 May 2014 15:06:57 +0800
From: "Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-idr-bgp-enhanced-route-refresh.all@tools.ietf.org" <draft-ietf-idr-bgp-enhanced-route-refresh.all@tools.ietf.org>
Thread-Topic: SECDIR Review of draft-ietf-idr-bgp-enhanced-route-refresh-06
Thread-Index: AQHPfJ7p3QZODynSR0imiS0zqxqnMw==
Date: Sat, 31 May 2014 07:06:57 +0000
Message-ID: <C72CBD9FE3CA604887B1B3F1D145D05E7BC70045@nkgeml507-mbs.china.huawei.com>
References: <CAMm+LwgckDX4U+7ZiwxLxf+O1_gy5hzNLN5uAupd8TrdqVW1FQ@mail.gmail.com>
In-Reply-To: <CAMm+LwgckDX4U+7ZiwxLxf+O1_gy5hzNLN5uAupd8TrdqVW1FQ@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/xEOmvmkKxfeqFhZzLKJoxGnDtrk
Subject: [secdir] SECDIR Review of draft-ietf-idr-bgp-enhanced-route-refresh-06
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: Sat, 31 May 2014 07:07:12 -0000

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 short document tries to enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. In order to achieve this, the "Reserved" field of the ROUTE-REFRESH message is redefined to indicate the beginning and the ending of a route refresh. I agree this extension will not introduce new security issues to the BGP protocol.

The document is clear. I consider it ready with a few issues:

I suggest defining how a BGP speaker should handle a EoRR without receiving the associated BoRR especially when the peer does not support graceful start. 

The description in the last paragraph of section 4 is not very clear. It would be better to briefly explain why the introduced procedures can simplify the interaction with the BGP Graceful Restart. In addition, the EOR and EoR messages (the typos of EoRR?) mentioned in this paragraph are not defined elsewhere.