Re: [secdir] SECDIR Review of draft-ietf-idr-bgp-enhanced-route-refresh-06
"Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com> Mon, 09 June 2014 09:29 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88C11A0027; Mon, 9 Jun 2014 02:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvVLyX4efBE6; Mon, 9 Jun 2014 02:29:02 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC3E1A0026; Mon, 9 Jun 2014 02:29:01 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFF46558; Mon, 09 Jun 2014 09:28:59 +0000 (GMT)
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Jun 2014 10:28:59 +0100
Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.167]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 9 Jun 2014 17:28:54 +0800
From: "Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com>
To: "Keyur Patel (keyupate)" <keyupate@cisco.com>, "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: AQHPfJ7p3QZODynSR0imiS0zqxqnM5tfhdsAgAkLBBA=
Date: Mon, 09 Jun 2014 09:28:54 +0000
Message-ID: <C72CBD9FE3CA604887B1B3F1D145D05E7BC71377@nkgeml507-mbs.china.huawei.com>
References: <C72CBD9FE3CA604887B1B3F1D145D05E7BC70045@nkgeml507-mbs.china.huawei.com> <CFB35024.74816%keyupate@cisco.com>
In-Reply-To: <CFB35024.74816%keyupate@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.139]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/7rlZyeNNnhuemC_Ux3jr1-PYKZo
Subject: Re: [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: Mon, 09 Jun 2014 09:29:03 -0000
> -----Original Message----- > From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] > Sent: Wednesday, June 04, 2014 1:11 AM > To: Zhangdacheng (Dacheng); iesg@ietf.org; secdir@ietf.org; > draft-ietf-idr-bgp-enhanced-route-refresh.all@tools.ietf.org > Subject: Re: SECDIR Review of draft-ietf-idr-bgp-enhanced-route-refresh-06 > > Hi Dacheng, > > Thanks a lot for the draft review. My comments are inlined. #Keyur > > On 5/31/14 12:06 AM, "Zhangdacheng (Dacheng)" > <zhangdacheng@huawei.com> > wrote: > > >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. > > #Keyur: The received EoRR message without an associated BoRR message > would pretty much be a no-op operation (as no routes are marked Stale). This > behavior is consistent with/without GR. > > How about if we add the following line (Section 4, end of 5th paragraph > after: "Such purged routes MAY be logged for future analysis.") > > A BGP speaker MAY ignore any EoRR message received without a prior receipt > of an associated BoRR message. Such messages MAY be logged for future > analysis. > [Dacheng Zhang:] That is good. > > > > > > >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. > > Keyur: Good Point. How about adding the 2nd (clarification) line to the last > paragraph of section 4: > > > The following procedures are specified in order to simplify the > interaction with the BGP Graceful Restart [RFC4724]. In particular, > these procedures ensure that > End-of-RIB (³EoR²) defined in Graceful Restart and EoRR as defined > in this specification > are kept separate, thereby avoiding any premature cleanup of stale routes. > For a BGP > speaker that supports the BGP Graceful Restart, it MUST NOT send a > BoRR for an AFI/SAFI to a neighbor before it sends the EoR for the > AFI/SAFI to the neighbor. A BGP speaker that has received the > Graceful Restart Capability from its neighbor, MUST ignore any BoRRs > for an AFI/SAFI from the neighbor before the speaker receives the EoR > for the given AFI/SAFI from the neighbor. The BGP speaker SHOULD log > an error of the condition for further analysis. > [Dacheng Zhang:] The new paragraph is much better. Thanks. ^_^ > > Regards, > Keyur > > > > >Cheers > > > >Dacheng > >
- [secdir] SECDIR Review of http://tools.ietf.org/h… Phillip Hallam-Baker
- [secdir] SECDIR Review of draft-ietf-idr-bgp-enha… Zhangdacheng (Dacheng)
- Re: [secdir] SECDIR Review of draft-ietf-idr-bgp-… Keyur Patel (keyupate)
- Re: [secdir] SECDIR Review of draft-ietf-idr-bgp-… Zhangdacheng (Dacheng)