Last Call 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)|
|Authors||Cristel Pelsser , Antonio Jose Elizond Armengol , Bruno Decraene , Zubair Ahmad , Tomonori Takeda , Pierre Francois|
|Draft last updated||2010-10-07|
Secdir Last Call review of -??
by Rob Austein
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.