[Note that I do not speak for the authors, just as someone who works on software that contains an implementation of BMP.]
On Wed, Oct 14, 2015 at 09:44:01AM -0700, Stephen Farrell wrote: > "This is an inherently insecure protocol for no particularly > good reason and mostly due to the lack of implementation of > basic security mechanisms (SSH, TLS) but also due to a lack > of customer/operator pressure to ensure those are present, > usable and interoperate, despite evidence that attacks on > the links over which this data will be sent are ongoing." > > I'd not be surprised if you preferred some other text:-) It's refreshingly honest, but works from a slightly different perspective than what the implementors give a darn about. You will note that aside from saying that this works over TCP that the protocol doesn't even mention what *port* it should be working on by default. Mostly, the protocol doesn't give a darn as long as we can get a reliable stream session between two devices. The protocol standardizes the message contents over this stream. The protocol by default suggests TCP. But as overly flippantly noted in the security considerations, you can use something stronger if you desire either integrity or privacy. While I feel your particular pain and anger over the general state of things, my suggestion is we should work on clarifying the text in the above fashion: If you want a secured transport, you can use one. We can even recommend one. Making anything other than stock TCP mandatory will result in implementor torches and pitchforks at this point because we have shipping code and customers use it. :-) > Why is using TLS not a no-brainer for this? Given the likes > of the Belgacom and Gemalto reports, I would love to > 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 > relevant security protocols (SSH, IPsec and TLS) are all > nearly or more than 20 years old. A significant amount of this is simply implementation issues. I'm quite happy to sit down with whomever at the upcoming IETF to help generate some lightbulb moments. While it won't remove your frustration, it will at the very least clarify some of the why involved. At a high level, protocol developers aren't security experts. While routing protocols are treated as system software (in the traditional sense), they are still application level programs for the most part. With a few exceptions, transport services are provided via standard APIs. If the service isn't available to an application developer, it isn't deployed. The question then is why aren't these things more readily available? That's the long conversation. > (And yes, I get that all the stuff as to why AO isn't > available for BGP, but this is not BGP. It's our apparent > need to keep the security level down at the "crap" marker > that I don't get.) The more relevant observation is what piece of your routing ecosystem BMP is implemented in. And given that, it's no surprise that BMP is a very thin wrapper on top of BGP PDUs for the most part. -- Jeff _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
