[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.
- [secdir] Review of draft-ietf-grow-bgp-graceful-s… Rob Austein
- Re: [secdir] Review of draft-ietf-grow-bgp-gracef… Rob Austein
- Re: [secdir] Review of draft-ietf-grow-bgp-gracef… bruno.decraene