Subject: [GROW] Kathleen Moriarty's No Objection on draft-ietf-grow-bmp-17: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 10 Feb 2016 08:12:23 -0800

Kathleen Moriarty has entered the following ballot position for
draft-ietf-grow-bmp-17: 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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.