BGP Monitoring Protocol (BMP)
draft-ietf-grow-bmp-17

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.)