Thanks for your comments, Tom. > On Jul 21, 2015, at 10:26 AM, t.petch <[email protected]> wrote: > > Looking at the Security Considerations, I would like to see more. > > An SNMP MIB module calls out which objects might be sensitive to a GET > (or SET) while this just has a blanket warning. The Internet only exists > because this kind of information is propagated to all and sundry so if > this introduces a threat, then I think more detail is needed,
I take your point. On the other hand, I'm not prepared to write a thorough exploration of any conceivable misuse of the information that's exposed, since the information is (at least!) "everything that's in BGP, now and in the future". I've expanded the text a little to try to address the question, but if you (or others in the WG) think a more thorough treatment is needed, please send text (or a reference to an existing document). > especially > as the I-D goes on to say 'MAY use some type of secure transport' which > is somewhat open! I'm not quite sure how this relates to your previous point since the transport part is specific to authentication, data integrity and transport protection. Possibly you were expecting confidentiality from the transport as well, or possibly you are thinking of what we were when that text was written, namely that authentication prevents an imposter from directly receiving the information. I've tried to address that too. > If, for example, this is more sensitive because it is > exposing Adj-RIB-in pre the application of policy, then I think that > that needs saying; or whatever. > > I think that the last paragaph makes a good point, identifying a threat, > but weakens it by calling for mutual authentication, which can be a pig > to > achieve. If the threat is masquerade of a monitored router, then only > the router needs authentication which is much easier, and so more likely > to happen. I added some text to indicate why I think mutual is desirable. > /IPSec/IPsec/ Fixed. Proposed section below. No new draft issued, since I anticipate we may iterate on this. Please take a look and ideally either suggest modifications or ack and I'll publish it as -13. --John 11. Security Considerations This document defines a mechanism to obtain a full dump or provide continuous monitoring of a BGP speaker's local BGP table, including received BGP messages. This capability could allow an outside party to obtain information not otherwise obtainable. For example, although it's hard to consider the content of BGP routes in the public Internet to be confidential, BGP is used in private contexts as well, for example for L3VPN [RFC4364]. As another example, a clever attacker might be able to infer the content of the monitored router's import policy by comparing the pre-policy routes exposed by BMP, to post-policy routes exported in BGP. Implementations of this protocol MUST require manual configuration of the monitored and monitoring devices. Users of this protocol MAY use some type of transport providing mutual authentication, data integrity and transport protection, such as IPsec [RFC4303] or TCP-AO [RFC5925]. If confidentiality is considered a concern, a transport providing that as well could be selected. Unless a transport that provides mutual authentication is used, an attacker could masquerade as the monitored router and trick a monitoring station into accepting false information, or could masquerade as a monitoring station and gain unauthorized access to BMP data. Unless a transport that provides confidentiality is used, a passive attacker could gain access to BMP data in flight. However, BGP is not commonly deployed over a transport providing confidentiality, so it's debatable whether it's crucial to provide confidentiality once the data is propagated into BMP. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
