Hi Alvaro, Thanks for your comments. I hope it is felt that the following edits address them:
https://github.com/paololucente/draft-ietf-grow-bmp-adj-rib-out/commit/76a68ad43b8b4352382f459fdf9c36ce0695a2f3#diff-42c33450ab1d1f6d1ec35e9a12c7bf24 Paolo PS: as part of addressing a comment of Barry Leiba i further edited the text of the xref to be “section 11 of”, see here: https://github.com/paololucente/draft-ietf-grow-bmp-adj-rib-out/commit/f3a9cb578d6f1a93c207f328f4f912c52cda6bcd#diff-42c33450ab1d1f6d1ec35e9a12c7bf24R474 On 3 Jul 2019, at 22:34, Alvaro Retana via Datatracker <[email protected]<mailto:[email protected]>> wrote: Alvaro Retana has entered the following ballot position for draft-ietf-grow-bmp-adj-rib-out-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am balloting Yes because I think this is important and needed work. However, I think the Security Considerations section is incomplete. Right now it just says: "It is not believed that this document adds any additional security considerations." The text should at least point to the Security Considerations from rfc7854. In §5.2, this example is offered: "a comparison between pre-policy and post-policy can be used to validate the outbound policy". While validation is the expected use case, it would be relatively simple to reconstruct the outbound policy itself. This fact means that the new functionality allows BMP receivers to learn information about the monitored peer that otherwise would not be available, which may result in loss of privacy, the ability to craft a route to bypass specific policy, etc.. The point that I'm making here goes beyond gaining unauthorized access to BMP data (which is mentioned in rfc7854), to the potential ability to figure out policy and then craft attacks based on that knowledge. The mitigation is of course to establish these sessions with authorized *and* trusted peers.
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
