Subject: grow: FYI: [[email-masked]: GET-ART review of draft-ietf-grow-bgp-wedgies-02.txt]

From: David Meyer <[email-masked]>
Date: Mon, 6 Jun 2005 08:03:32 -0700

----- Forwarded message from [email-masked] -----

> From: [email-masked]
> To: [email-masked], [email-masked], [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> Subject: GET-ART review of draft-ietf-grow-bgp-wedgies-02.txt
> Date: Mon, 6 Jun 2005 11:00:32 -0400 
> 
> Intended status: Informational
> 
> Background for those who may be unaware of GenART:
> GenART is the Area Review Team for the General Area of the IETF.
> We advise the General Area Director (i.e. the IETF/IESG chair) by
> providing more in depth reviews than he could do himself of documents
> that come up for final decision in IESG telechat.  I was selected
> as the GenART member to review this document.  Below is my review,
> which was written specifically with an eye to the GenART process, but
> since I believe that it will be useful to have these comments more
> widely distributed, others outside the GenART group are included.
> 
> Review criteria for WG submissions: "Is this document a reasonable
> contribution to the area of Internet engineering which it covers? If
> not, what changes would make it so?"
> 
> This draft is basically ready for publication, but has nits that
> should be fixed before publication.
> 
> The draft is well-written, as its description of BGP Wedgie
> scenarios is accessible to this reviewer who is definitely not
> a BGP expert.
> 
> 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.
> 
> I would hope that this issue can be satisfactorily addressed
> without lodging a "Discuss" against this draft.  Consultation
> with one of the Security Area Directors may be useful.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------

----- End forwarded message -----