Skip to main content

Last Call Review of draft-ietf-grow-bgp-graceful-shutdown-requirements-
review-ietf-grow-bgp-graceful-shutdown-requirements-secdir-lc-austein-2010-10-07-00

Request Review of draft-ietf-grow-bgp-graceful-shutdown-requirements
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-10-05
Requested 2010-09-11
Authors Cristel Pelsser , Antonio Jose Elizond Armengol , Bruno Decraene , Zubair Ahmad , Tomonori Takeda , Pierre Francois
Draft last updated 2010-10-07
Completed reviews Secdir Last Call review of -?? by Rob Austein
Assignment Reviewer Rob Austein
State Completed
Review review-ietf-grow-bgp-graceful-shutdown-requirements-secdir-lc-austein-2010-10-07
Completed 2010-10-07
review-ietf-grow-bgp-graceful-shutdown-requirements-secdir-lc-austein-2010-10-07-00
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.