Hi Benjamin, Inline:
> On 15 Aug 2019, at 19:04, Benjamin Kaduk via Datatracker <[email protected]> > wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-grow-bmp-adj-rib-out-07: No Objection Thank you for the ’no objection’. > Section 1 > > An example of pre-policy verses post-policy is > when an inbound policy applies attribute modification or filters. > Pre-policy would contain information prior to the inbound policy > changes or filters of data. Post policy would convey the changed > data or would not contain the filtered data. > > I think we had some discussion relating to my question about policy > being used to inject new data, and even some suggested edits from Jeff, > but I couldn't find those in the -07. Perhaps I just missed them, though. I have now added the comment from Jeff as part of Other Considerations as per draft-ietf-grow-local-rib: https://github.com/paololucente/draft-ietf-grow-bmp-adj-rib-out/blob/master/draft-ietf-grow-bmp-adj-rib-out.txt#L373-#L377 Rationale being: in case of any changes, ie, policy being used to inject new data, the collector should be notified with a PEER DOWN/PEER UP sequence. I also provided some extra feedback as part of my last message, let me report it here for your conveniency: === To your point, i feel we are good, let me explain. Slightly before in the introduction we have: "The Adj-RIB-In post-policy conveys to a BMP receiver all RIB data after policy filters and/or modifications have been applied.” Which says _all_ RIB data (that is: new, changed or removed). Then, continuing, an example is given: “An example of pre-policy versus post-policy is when an inbound policy applies attribute modification or filters." Related to this we have the concluding sentence: “Post policy would convey the changed data or would not contain the filtered data.” Where “changed” does not refer to new/changed/removed RIB data but rather to modified by the policy. Having done some homeworks i feel i can also say: this paragraph was pretty much copy/pasted by rfc7854 :-) === > Section 8 > > I agree with the conclusion from discussions on Alvaro's point, that > implementations > SHOULD only use this with trusted/authorized monitoring devices. But I think > it's > the role of the security considerations to clarify why this is the case > (i.e., that new > information would be made available otherwise), and not just provide a rule > to be > blindly adhered to. Also here i feel we are good. If you see section 11 of RFCs7854 (Security Considerations), referenced in Security Considerations of this document, it pretty much already explains all the whys of: "Implementations of this protocol SHOULD require to establish sessions with authorized and trusted monitoring devices" For example it says: "This document defines a mechanism to obtain a full dump or provide continuous monitoring of a BGP speaker's BGP routes, including received BGP messages. This capability could allow an outside party to obtain information not otherwise obtainable.” I’d not know what else to add since imo the security problem statement is already pretty well formulated there. But i’m open to suggestions. Paolo _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
