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

Rob Austein <sra@hactrn.net> Thu, 07 October 2010 14:03 UTC

Return-Path: <sra@hactrn.net>
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 E20463A6F33; Thu, 7 Oct 2010 07:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.699
X-Spam-Level:
X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_00=-2.599, LONGWORDS=1.803, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 v7Sp-S9fRXO7; Thu, 7 Oct 2010 07:03:34 -0700 (PDT)
Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id B1A933A6F34; Thu, 7 Oct 2010 07:03:33 -0700 (PDT)
Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 89A1F28441; Thu, 7 Oct 2010 14:04:34 +0000 (UTC)
Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2BA3C22829; Thu, 7 Oct 2010 10:04:34 -0400 (EDT)
Date: Thu, 07 Oct 2010 10:04:34 -0400
From: Rob Austein <sra@hactrn.net>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-grow-bgp-graceful-shutdown-requirements.all@tools.ietf.org
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20101007140434.2BA3C22829@thrintun.hactrn.net>
Subject: [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 14:03:35 -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 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 have no serious security concerns regarding this document.