Skip to main content

Last Call Review of draft-ietf-idr-ix-bgp-route-server-09

Request Review of draft-ietf-idr-ix-bgp-route-server
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-06-07
Requested 2016-05-26
Authors Elisa Jasinska , Nick Hilliard , Robert Raszuk , Niels Bakker
I-D last updated 2016-06-09
Completed reviews Genart Last Call review of -09 by Ralph Droms (diff)
Genart Telechat review of -10 by Ralph Droms (diff)
Secdir Last Call review of -09 by David Waltermire (diff)
Opsdir Last Call review of -09 by Warren "Ace" Kumari (diff)
Rtgdir Early review of -07 by Geoff Huston (diff)
Assignment Reviewer David Waltermire
State Completed
Request Last Call review on draft-ietf-idr-ix-bgp-route-server by Security Area Directorate Assigned
Reviewed revision 09 (document currently at 12)
Result Has issues
Completed 2016-06-09
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.

Summary: ready with (potential) issues.

This standards track draft describes a method to exchange routing information
between 3 or more BGP peers on shared network access media. The approach is
intended to reduce the overhead involved in sharing routes in densely populated
interconnection points through the use of a common route broker.

I found the draft clearly articulates the problem it is trying to solve.

The following is a minor nit on the organization of the text:

In general the security considerations section covers the issues fairly well.
In the first paragraph, the last sentence suggests that steps should be taken
to address path hiding, but the text does not point to the text in section
2.3.2 on this topic. One way to improve this consideration would be to move the
text in 2.3.3 to the end of this paragraph. Section 2.3.3 is adjacent to the
security consideration section, so I don't see this as a significant change.

Some (potentially) minor issues:

A number of the requirements in section 2.2 and the subsections define
requirements that differ and often conflict with requirements in RFC 4271. It
would be good to indicate this at the start of 2.2.  Should this relationship
also be called out in the abstract?

I am not an expert in BGP security, so please consider this issue in that

The statement at the end of the security considerations section points the
reader to RFC7454. I was left wondering if this draft changes any of
considerations in RFC7454. It would be beneficial if some text was added to
this draft speaking to this point. Again not being an expert in BGP security, I
am not certain what the new text should say on this matter.

Dave Waltermire