Re: [secdir] Review of draft-ietf-grow-bgp-graceful-shutdown-requirements-04

<bruno.decraene@orange-ftgroup.com> Thu, 07 October 2010 16:35 UTC

Return-Path: <bruno.decraene@orange-ftgroup.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547B73A709E; Thu, 7 Oct 2010 09:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.005
X-Spam-Level:
X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbxTN1IPrHrJ; Thu, 7 Oct 2010 09:35:33 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 154C73A706B; Thu, 7 Oct 2010 09:35:33 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D3674FC400A; Thu, 7 Oct 2010 18:36:33 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id C7A43FC4008; Thu, 7 Oct 2010 18:36:33 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 18:36:31 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 07 Oct 2010 18:36:36 +0200
Message-ID: <FE8F6A65A433A744964C65B6EDFDC240018F62BA@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <20101007140434.2BA3C22829@thrintun.hactrn.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [secdir] Review of draft-ietf-grow-bgp-graceful-shutdown-requirements-04
Thread-Index: ActmKLSnhbG2SLOdTK2g22OuzegQDQAFCGCg
References: <20101007140434.2BA3C22829@thrintun.hactrn.net>
From: bruno.decraene@orange-ftgroup.com
To: sra@hactrn.net
X-OriginalArrivalTime: 07 Oct 2010 16:36:31.0785 (UTC) FILETIME=[CC5C9990:01CB663D]
X-Mailman-Approved-At: Sun, 10 Oct 2010 08:25:45 -0700
Cc: draft-ietf-grow-bgp-graceful-shutdown-requirements.all@tools.ietf.org, zubair.ahmad@orange-ftgroup.com, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Review of draft-ietf-grow-bgp-graceful-shutdown-requirements-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 07 Oct 2010 16:35:34 -0000

Rob,

Thanks for your review of the document and your comments.

I share your analysis.

More inline.

Regards,
Bruno

> -----Original Message-----
> From: Rob Austein [mailto:sra@hactrn.net]
> Sent: Thursday, October 07, 2010 4:05 PM
> To: iesg@ietf.org; secdir@ietf.org;
draft-ietf-grow-bgp-graceful-shutdown-
> requirements.all@tools.ietf.org
> Subject: [secdir] Review of draft-ietf-grow-bgp-graceful-shutdown-
> requirements-04
> 
> 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 draft discusses requirements for a proposed BGP extension to
> allow graceful transition between redundant sessions during planned
> maintenance windows.  Unexpected failures are out of scope, the point
> of the exercise is just to minimize avoidable traffic loss.   While
> the draft does not say so in so many words, a high-level description
> of the desired mechanism might be the ability to give a neighbor some
> advance notice of a planned change along with a hint of what the
> normal BGP data will look like after that change, so that the neighbor
> can prepare for the change.
> 
> As far as I can tell, the required mechanism is likely to be harmless,
> assuming it can be kept simple: as described, the protocol extension
> would be a conversation between adjacent routers, either of which
> could bring down the session or inject garbage into the session
> anyway, so the probability that the extension would introduce a new
> attack vector seems low.  In theory an evil neighbor might do
> something nasty by providing misleading advance information, but
> again, said neighbor could do the same thing now and have it take
> effect immediately, so there's no obvious gain here for an attacker.
> 
> The security considerations section is weak, although as this is a
> requirements document it is not entirely unreasonable to postpone real
> security considerations until the discussion of solutions.  A
> paragraph (like the preceding one in this review) giving a brief
> explanation of why this kind of mechanism is likely to be harmless
> would be nice, but given the lateness of this review (mea culpa) I
> will leave it up to the IESG to decide whether to ask for this.

I can propose to update the security section with the following:

"7.	Security Considerations

At the requirements level, this graceful shutdown mechanism is expected
to not affect the security of the BGP protocol, especially if it can be
kept simple. No new sessions are required and the additional ability to
signal the graceful shutdown is not expected to bring additional attack
vector as BGP neighbours already have the ability to send incorrect or
misleading information or even shut down the session.

Security considerations MUST be addressed by the proposed solutions. In
particular they SHOULD address the issues of bogus g-shut messages and
how they would affect the network(s), as well as the impact of hiding a
g-shut message so that g-shut is not performed.

The solution SHOULD NOT increase the ability for one AS to selectively
influence routing decision in the peer AS (inbound Traffic Engineering)
outside the case of the BGP session shutdown. Otherwise, the peer AS
SHOULD have means to detect such behavior."



If this is fine for you and the IESG, I can commit the change in the
document. Otherwise, comments are welcomed.


> I have no serious security concerns regarding this document.