Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)

[Christopher Morrow <[e-mail]>]

Jumping in a bit late, but... (and only for this one point really)

On Thu, Oct 15, 2015 at 7:35 AM, Jeffrey Haas <[e-mail]> 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