Last Call Review of draft-ietf-idr-ix-bgp-route-server-09
review-ietf-idr-ix-bgp-route-server-09-secdir-lc-waltermire-2016-06-09-00

Request Review of draft-ietf-idr-ix-bgp-route-server
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-06-07
Requested 2016-05-26
Other Reviews Genart Last Call review of -09 by Ralph Droms (diff)
Genart Telechat review of -10 by Ralph Droms (diff)
Opsdir Last Call review of -09 by Warren Kumari (diff)
Rtgdir Early review of -07 by Geoff Huston (diff)
Review State Completed
Reviewer David Waltermire
Review review-ietf-idr-ix-bgp-route-server-09-secdir-lc-waltermire-2016-06-09
Posted at https://www.ietf.org/mail-archive/web/secdir/current/msg06607.html
Reviewed rev. 09 (document currently at 12)
Review result Has Issues
Draft last updated 2016-06-09
Review completed: 2016-06-09

Review
review-ietf-idr-ix-bgp-route-server-09-secdir-lc-waltermire-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 context:

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.

Regards,
Dave Waltermire