BGP Wedgies
RFC 4264

Note: This ballot was opened for revision 03 and is now closed.

(Bill Fenner) Yes

(Russ Housley) Yes

Comment (2005-06-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  Very interesting document.  It deserves an editorial review.  There
  are a few typos that caused me pause, and they are pretty easy to fix.
  I think that the figures could use more of the page width to make them
  easier to read.

  I agree with David Black's GEN-ART comment.  It would be good to
  add a paragraph that talks about attackers making use of BGP Wedgies
  to cause traffic to flow in a manner of their choosing.

(David Kessens) Yes

(Allison Mankin) Yes

(Alex Zinin) Yes

(Brian Carpenter) No Objection

Comment (2005-06-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
(from David Black's Gen-ART review)

The Security Considerations section needs to have an additional
paragraph added on exploitation of BGP Wedgies by an attacker.
A common theme running through the examples is that starting from
an intended/desired routing state, loss of a connection can flip
the collection of networks into an undesired state from which not
only will they not flop back automatically when connectivity is
restored, but from which significant administrative effort (based
on knowledge that may not be locally available) may be required to
cause a flop back into the intended/desired routing state.  If
an attacker can deliberately cause the initial loss of connectivity
thereby producing the initial flip, the network impacts of the
resulting state being undesired/unintended may be long-lived, far
outliving the temporary interruption of connectivity required to
cause them.  If those impacts (e.g., cost, bandwidth limits) are
significant, this could be an attractive attack vector, and
examples of possible impacts should be listed.

(Ted Hardie) No Objection

(Sam Hartman) No Objection

(Bert Wijnen) No Objection

Comment (2005-06-09 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Figure 2 has:
                    backup|  |primary for 192.9.200.0/25
                 primary|  |backup  for 192.9.200.128/25

and the para underneath figure 2 also speaks about those IP
addresses. I guess the fact that I had the pen for ID-Checklist
has sort of pre-conditioned me to see such things and state that
it is not in line with RFC3330, which suggests:

   192.0.2.0/24 - This block is assigned as "TEST-NET" for use in
   documentation and example code.  ...

Can easily be fixed in AUTH48 or with RFC-Editor note.
Bert