Jumping in a bit late, but... (and only for this one point really) On Thu, Oct 15, 2015 at 7:35 AM, Jeffrey Haas <jh...@pfrc.org> wrote: >> Why is using TLS not a no-brainer for this? Given the likes >> of the Belgacom and Gemalto reports, I would love to
TLS is a great plan, now you have to: 1) get certificates to devices (and keys) 2) mint said certs from your internal CA (probably, maybe) 3) update ca certificate data on devices and clients 4) check AND FAIL WHEN BAD THINGS HAPPEN certs presented to clients TLS is great, but its not simple in operational use especially if you want to deal with the full lifecycle of the tls world. The above only matters (really) for 'inside my span of control' bmp monitoring (to my devices from my servers, etc), and doesn't apply in a sane fashion to the 'public service' bmp providers. >> 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 where's tcp/ao support in the vendor gear in the field? where's tcp/ao support in even one popular unix derivative? windows? I'd love to do AO for this and bgp and my ssh sessions and such... but... there's zero support for a protocol that landed in RFC (where are it's 2 competing implementations? how did it make it to Standard without running code?) in june 2010. >> relevant security protocols (SSH, IPsec and TLS) are all >> nearly or more than 20 years old. it's not clear that ssh is viable here, it's also clear that IPSEC is fairly heavyweight and likely not in the code path for management / control-plane traffic on devices, and TLS has it's host (above) of lifecycle issues. The security stuff is important, by verbiage alone, but by actually useful code and standards? not so much. The BMP draft says: "Where the security considerations outlined above are a concern, users of this protocol should consider using some type of transport that provides 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." which actually seems spot on, despite my ranty-bits above. is it time to lift the DISCUSS here? or can we go around the rosebush again about how we would love better security in a world where we are clearly not important enough to actually get better security by default? -chris _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
