Document: draft-ietf-idr-bgp-vuln-01.txt
Trigger: IESG Evaluation, 2 December 2004
Reviewer: Elwyn Davies
AD: Alex Zinin
Review Date: 1 December 2004

Intended status: Informational

Summary: This document appears to be in good shape for approval as Informational.  There are a very small number of typos/language nits and readability could be improved by factoring out some common wording on the consequences of BGP connection reset to Idle state which is repeated to the point of irritation. Also there are a couple of abbreviations that need expansion and references to the BGP spec for definitions.

Review:
Generally the draft is in good shape and appears to cover the topic *very* thoroughly.

A small terminology section would help with pointers to definitions of a few terms (peer, BGP speaker, AS, NLRI and the various path attributes) and there need to be expansions of a couple of acronyms (notably AS, NLRI).

The following text or minor variants of it appears a numbers of times (especially in Section 3.1).  

The BGP speaker would disconnect the connection, release all associated BGP resources, delete all associated routes, run its decision process and cause the state to return to Idle.  The deletion of routes can cause a cascading effect of routing changes propagating through other peers. Also, optionally, an implementation specific peer oscillation damping may be performed.  The peer oscillation damping process can affect how soon the connection can be restarted.  Consequently, the ability of an outsider to spoof this message can lead to a severe disruption of routing over a wide area.

Whilst this does not compromise the technical quality of the document, it sure gets boring reading it for the sixth or seventh time.  If the document is reworked again, it would improve readability if the text could be factored out and some suitable shorter reference used to replace most of it.

Section 3.5.1: I suspect there should be some additional references to various generic attacks (such as SYN flooding) that could be quoted here.  Also maybe a reference to the TCP standard for the names of packets.

Some editorial nits:

Section 3.1.4, Event 24 text: s/one small bit less/a small amount less/

Section 3.1.5.3, last sentence of 'Originating Routes' sub-section: s/to become/becoming/
Section 4.2, para 2: s/in unique conditions/in a unique position/

Globally: Section headers and many paragraphs are separated by multiple blank lines where one would be sufficient.  The length of the list of events could be much reduced and readability improved by removing blank lines.