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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 15 Aug 2019 10:04:59 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-grow-bmp-adj-rib-out-07: No Objection

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:
----------------------------------------------------------------------

Thank you for the discussion about my Discuss point; it seems that
the document will probably be clear enough to the intended audience
that I do not need to press the point further, even if it remains somewhat
unclear to readers in a broader audience.

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.Section 8

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.

---

From: Paolo Lucente <[email-masked]>
Date: Sat, 17 Aug 2019 17:10:44 +0000

Hi Benjamin,

Inline:

> On 15 Aug 2019, at 19:04, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 

Thank you for the ’no objection’.

> 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 :-)
===

> information would be made available otherwise), and not just provide a rule to be

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