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

From: Rob Austein <[email-masked]>
Date: Thu, 07 Oct 2010 10:04:34 -0400

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.

---

From: Rob Austein <[email-masked]>
Date: Thu, 07 Oct 2010 13:43:34 -0400

At Thu, 7 Oct 2010 18:36:36 +0200, Bruno Decraene wrote:
...
> If this is fine for you and the IESG, I can commit the change in the
> document. Otherwise, comments are welcomed.

Proposed update would satisfy me.  Whether you should make that
change, hold off on it, fold it into a paper airplane and sail it out
the window, ... would be for your AD or WG chairs to decide, not me.

---

From: <[email-masked]>
Date: Thu, 7 Oct 2010 18:36:36 +0200

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:[email-masked]]
> Sent: Thursday, October 07, 2010 4:05 PM
> To: [email-masked]; [email-masked];
draft-ietf-grow-bgp-graceful-shutdown-
> [email-masked]
> Subject: [secdir] Review of draft-ietf-grow-bgp-graceful-shutdown-
> requirements-04
> 

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."