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

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