Re: [GROW] Benjamin Kaduk's No Objection on draft-ietf-grow-bmp-adj-rib-out-07: (with COMMENT)

[Paolo Lucente <[e-mail]>]

Hi Benjamin,

Inline:

> On 15 Aug 2019, at 19:04, Benjamin Kaduk via Datatracker <[e-mail]> 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