Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)
RFC 8671

Note: This ballot was opened for revision 06 and is now closed.

Ignas Bagdonas Yes

Comment (2019-07-11 for -06)
Thank you for this work - the industry needs it.

A nit: s/ template-based/template

Warren Kumari Yes

Alvaro Retana Yes

Comment (2019-07-03 for -06)
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.

Deborah Brungard No Objection

Alissa Cooper No Objection

Roman Danyliw No Objection

Comment (2019-07-10 for -06)
I support Ben’s DISCUSS about the Peer Down and Up Notification (i.e., Section 6.3).

Section 8, I also share Alvaro’s and Ben’s concern about whether any new information is leaked if pre- and post-policy information is combined

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-08-15)
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.

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

Barry Leiba (was Discuss) No Objection

Comment (2019-07-17 for -06)
Thanks for addressing my comments!

Two former DISCUSS points that have been addressed in the working version in github:

— Section 4 —

   The existing flags are defined in section 4.2 [RFC7854] and the
   remaining bits are reserved for future use.  They SHOULD be
   transmitted as 0 and their values MUST be ignored on receipt.

Why “SHOULD”?  That’s inconsistent with Section 4.2 of 7854, which says “MUST”.  Failing to set the reserved bits to 0 will cause interoperability problems with future extensions.

   The following fields in the Per-Peer Header are redefined:

You aren’t redefining them completely, right?  Don’t you mean, “When the O flag is set to 1, the following fields in the Per-Peer Header are redefined:” ?

---

And some editorial comments, also addressed in github:

Throughout: there are five instances of “use-case”.  “Use case” should not be hyphenated (unless it’s used as a modifier, which it isn’t here).

— Section 1 —

   An example of pre-policy verses post-policy is

You mean “versus”, with a “u” (and also a second time later in the section).

   This document updates section
   4.2 [RFC7854] per-peer header by adding a new flag

That’s an odd way to do the citation.  Also, “per-peer header” is misplaced:

NEW
This document updates the per-peer header in section 4.2 of [RFC7854] by adding a new flag
END

The other places in the document that say “section 4.2 [RFC7854]” should also be changed to “section 4.2 of [RFC7854]”.

— Section 6.3.1 —

      The Information field contains a free-form
      UTF-8 string whose length is given by the Information Length
      field.

As one UTF-8 character can be more than one byte, it’s best to specify whether the length is in bytes or characters.  I would say, “whose byte length is given....” (also in Section 9.3)

— Section 9.3 —
The sentence, “The value is administratively given by the Information Length field.” appears to be a copy/paste error, and should be deleted.

Adam Roach No Objection

Comment (2019-07-10 for -06)
I support Barry's discuss points.

Martin Vigoureux No Objection

Comment (2019-07-09 for -06)
Hello,

Somehow related to Benjamin's comment, I'm not sure how to interpret this change:

   The following fields in the Per-Peer Header are redefined:

   o  Peer Address: The remote IP address associated with the TCP
      session over which the encapsulated PDU is sent.

   o  Peer AS: The Autonomous System number of the peer from which the
      encapsulated PDU was sent.

   o  Peer BGP ID: The BGP Identifier of the peer from which the
      encapsulated PDU was sent.

In which context are these new definitions valid? i.e., for O=1 only? Whatever the answer I think it wouldn't hurt to make that clear.

Also, I read that a requirement has changed:
in rfc7854
     *  The remaining bits are reserved for future use.  They MUST be
         transmitted as 0 and their values MUST be ignored on receipt.
in your draft
   The existing flags are defined in section 4.2 [RFC7854] and the
   remaining bits are reserved for future use.  They SHOULD be
   transmitted as 0 and their values MUST be ignored on receipt.

Is that intentional?

Finally:
   o  Post-Policy Adj-RIB-Out: The result of applying outbound policy to
      an Adj-RIB-Out. This MUST be what is actually sent to the peer.
Maybe I'm reading incorrectly the last sentence but I'm under the impression that setting such requirement is outside the scope of this document. Shouldn't it rather say: "This is what is actually sent to the peer."

Éric Vyncke No Objection

Magnus Westerlund No Objection