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

"Keyur Patel (keyupate)" <keyupate@cisco.com> Tue, 03 June 2014 17:11 UTC

Return-Path: <keyupate@cisco.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 7E69B1A02FB; Tue, 3 Jun 2014 10:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 eysO6jsxXIWj; Tue, 3 Jun 2014 10:11:16 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BBA1A0234; Tue, 3 Jun 2014 10:11:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2979; q=dns/txt; s=iport; t=1401815471; x=1403025071; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=wU7JG2eS/AjTwkmYELyVDmpR7ZSTLLt7YyyM0PoiMsg=; b=UUa1SyV7U3VlONCt7VncpECT6o34h1ce22VJYY5N/v5CcegKLGVRRjmQ BJYuc8DlR51zRdqtLPGsED6TkGRDHO2lcETKpG0718CyKgvpTFy2igzRg XSANBLNWCm8V24jP1dYCsGuhD51m5t+b7DIHsGNZLi0nYoahg8MJItI5f w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoILAHABjlOtJV2U/2dsb2JhbABZgweBKqo4AwEBAQUBmBwBgQwWdIIsgQsBCHglAgQBEohC0yMXhVWJBIRABIlvjBOECJMzgziCLw
X-IronPort-AV: E=Sophos;i="4.98,966,1392163200"; d="scan'208";a="327072448"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP; 03 Jun 2014 17:11:02 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s53HB2id002972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 17:11:02 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.72]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 3 Jun 2014 12:11:02 -0500
From: "Keyur Patel (keyupate)" <keyupate@cisco.com>
To: "Zhangdacheng (Dacheng)" <zhangdacheng@huawei.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: AQHPfJ7p3QZODynSR0imiS0zqxqnM5tfhdsA
Date: Tue, 3 Jun 2014 17:11:02 +0000
Message-ID: <CFB35024.74816%keyupate@cisco.com>
In-Reply-To: <C72CBD9FE3CA604887B1B3F1D145D05E7BC70045@nkgeml507-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [128.107.163.125]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <23156A0CE73DAF41A1A6784C736770DF@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/qda3uli6RPoaOSDHUPvo-WC26ig
X-Mailman-Approved-At: Tue, 03 Jun 2014 10:15:38 -0700
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: Tue, 03 Jun 2014 17:11:25 -0000

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.


> 
>
>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.


Regards,
Keyur

>
>Cheers
>
>Dacheng
>