Skip to main content

BGP Wedgies
draft-ietf-grow-bgp-wedgies-03

Yes

(Alex Zinin)
(Allison Mankin)
(Bill Fenner)
(David Kessens)

No Objection

(Sam Hartman)
(Ted Hardie)

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

Alex Zinin Former IESG member
Yes
Yes () Unknown

                            
Allison Mankin Former IESG member
Yes
Yes () Unknown

                            
Bill Fenner Former IESG member
Yes
Yes () Unknown

                            
David Kessens Former IESG member
Yes
Yes () Unknown

                            
Russ Housley Former IESG member
Yes
Yes (2005-06-06) Unknown
  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.
Bert Wijnen Former IESG member
No Objection
No Objection (2005-06-09) Unknown
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
Brian Carpenter Former IESG member
No Objection
No Objection (2005-06-06) Unknown
(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.
Sam Hartman Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection () Unknown