Ballot for draft-ietf-grow-bmp
Yes
No Objection
Note: This ballot was opened for revision 15 and is now closed.
Thank you for a clear and well-written document. This was easy to read and understand. I do have a couple questions. a) In Section 4.2, I see special casing for an "L3VPN Instance Peer". Will the same thing be necessary for an EVPN peer? Are there other future cases to be considered? b) In Sec 4.4, for the type=0 String, it may be useful to specify that the language is unspecified and based on the configuration. A similar description for the other information strings would be useful. I'm sure that Barry could suggest better text.
The shepherd write-up says that IPR was declared, but the datatracker shows nothing for this draft or its predecessor. === (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. -- Yes. ===
I support Stephen's and Kathleen's discuss positions concerning the lack of MTI security. I'm balloting no-objection (for now) so that those conversations can happen on their respective threads. 3.2: The says no message is ever sent by the monitoring station, but the last paragraph in the section mentions a monitoring station sending a termination message. Also, does the strategy for retrying failed connection attempts apply to reconnects after the fail or an existing connection? The 3rd paragraph from the end talks about redundant connections happening when both parties are configured as active. But previous paragraphs suggested that only passive endpoints will listen for a connection. How could this result in redundant connections? Is there logic to make sure the endpoints do not terminate both redundant connections? IANA Considerations: Several of the tables reserve an experimental range of 65531 through 65534. Is it really the intent to have experimental ranges with only 4 code-points each?
Considering that 1. BMP will simply transmit the PDU 2. The use cases is monitoring 3. The correlation between BMP and draft-ietf-idr-bgp-model is possible (at least manually) 4. It's implemented today I'll remove my DISCUSS COMMENT: - From the write-up: -- The BMP protocol has been a GROW document for quite sometime. The -- length of time has allowed the document to have multiple implementations -- completed, along with incorporating working group feedback into the spec -- and polishing the document. Btw, don't forget, for future documents, the experimental RFC 6982 "Improving Awareness of Running Code: The Implementation Status Section" - following nits need to be addressed in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs)
Comments and questions from the recent Gen-ART review by Vijay Gurbani deserve to be looked at.
thanks for addressing my discuss points: The statements on authenticated access and confidentiality are helpful, but this is a new protocol and should not start out with the security property levels of the current BGP deployments. Efforts have been made to publish RFCs to fix BGP security and the vulnerabilities have been published - even in the Washington Post. I'd like to see more security required for the properties mentioned to prevent active and passive attacks getting dumps of the BGP data, which was not previously available. If this is not possible per the suggestions below, please explain why. If there is a good reason, it would be helpful to remove the text that says its okay to leave security out because BGP isn't secure and just include the security considerations. Now for specifics: 1. In the Security considerations, it is not only a passive attacker, but also an active one that could gain access to the session if it is not encrypted (protected for confidentiality). An active attacker might change routes causing network disruption. A passive attacker might better understand the possible paths to an AS, assisting with a more effective DDoS attack. The latter point is important to consider in the first paragraph of this section that currently says, "although it's hard to consider the content of BGP routes in the public Internet to be confidential," I think this is a bit of an overstatement as the exact routes and paths are not published for each router and could be used for DoS attacks - for example taking out one or more paths to a network AS. What I am suggesting for #1 is a simple text change to address the fuller set of security considerations. Change from: Unless a transport that provides confidentiality is used, a passive attacker could gain access to BMP data in flight. To: Unless a transport that provides confidentiality is used, a passive or active attacker could gain access to or tamper the BMP data in flight. 2. The last paragraph would be the right place to require session encryption and authentication for sessions (unless there is a good explanation as to why this is not needed). If the transport may vary, then it's okay to leave IPsec as a suggestion. It would be nice if there was an MTI for transport, so the security protections could be consistent and interoperability would be easier between implementations. This also came up in the SecDir review. https://www.ietf.org/mail-archive/web/secdir/current/msg06011.html In any case, it would be good to discuss this and see if there are good reasons to leave it as-is or to change the text to improve security, preventing a few attack types.
I found myself wondering when you can start route mirroring, and whether there was any guidance about what to do when a BGP speaker runs out of buffers so that route mirroring is no longer complete.
I'm clearing my discuss as promised as you've now added text on using IPsec that would work if someone wanted to do that. I'm still sad that you didn't decide to write down how to do this over TLS, as that'd really be more likely to be used I think. But perhaps you'll do that in future, which'd be good. (Or if you wanted to do that for this document still, I'd be happier:-) In any case, the discuss is cleared, but I'm also happy to continue chatting about how to do TLS for this if that's useful. Old comments below, I didn't check these. Happy to chat about 'em more, but we don't have to unless you want to. Separate to the discuss, I have some non-blocking points, that I think resonate with Kathleen's discuss: Why is using TLS not a no-brainer for this? Given the likes of the Belgacom and Gemalto reports, I would love to understand why people are still willing to buy and sell equipment without such basic features. The "explanation" that nobody needs it or nobody provides it seems off base here - this is new code and a new interface, and the relevant security protocols (SSH, IPsec and TLS) are all nearly or more than 20 years old. And that is all the more the case for a new protocol like this that is not likely in the critical path and where the monitoring statiion may be off to the side so the traffic flows via BMP in places where BGP doesn't go implying different threat levels, that may need different protection. My best guess as to causes for now is that people are just used to doing nothing and have done that for so long they seem to think that doing nothing is the only possibility. (That's how business models get disrupted isn't it?) Can you educate me some more on this? (And yes, I get that all the stuff as to why AO isn't available for BGP, but this is not BGP. It's our apparent need to keep the security level down at the "crap" marker that I don't get.)