On Mon, Jul 27, 2015 at 5:13 AM, t.petch <[email protected]> wrote: > John > > Looks good. > > My thinking on 'MAY', coloured by comments I have seen previously from > ADs, is that 'MAY' means much the same as 'MAY NOT' and so adds little > to a specification! I would be inclined, although not too strongly, to > be more assertive, something like > > 'Where the security considerations outlined above are a concern, users > of this protocol SHOULD .....' > > I think it right to mention IPsec and TCP-AO here. I wonder at the > absence of SSH, which is probably the only security protocol I have used > to access a router. I wonder too, if the advent of the work of SIDR
we had some similar machinations in SIDR about AO/SSH/IPSEC/etc.... when you look at deployed router gear, OFTEN there is no AO support, IPSEC is tied up in 'other licenses' (or not available in certain places due to ITAR/etc issues) and ssh is often not the 'openssh binary' you have on your desktop... Sometimes it's a kludged together mess that exists ONLY to do client/server 'command line' work, and not as a library (or not in the fully functional ssh binary you normally use) for generically tunneling things :( 'how do I secure transport' is "solved" in the IETF, but very clearly 'not solved' in the real world :( > will lead to X.509 certificates being the norm for routers, which would > facilitate other forms of security but suspect that that is too far off > to consider now. > it's not clear, to me, that the cert for SIDR work on a device is particularly helpful for anything other than loose identity of the device at the far side... Inside a single ASN that map could be (according to the sidr ops docs) "this cert is for my ASN" or "this cert is this particular routing device" (which is really 'bgp speaker' I suppose even). The mechanics of managing certs MIGHT make 'welp, we'll just use certs for auth!' happen though, I grant you. -chris > Tom Petch > > ----- Original Message ----- > From: "John G.Scudder" <[email protected]> > To: "t.petch" <[email protected]> > Cc: "Christopher Morrow" <[email protected]>; > <[email protected]>; <[email protected]>; <[email protected]>; > <[email protected]> > Sent: Friday, July 24, 2015 9:18 AM > > 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
