On Sat, Dec 05, 2015 at 12:12:48PM +0000, Nick Hilliard wrote: > tls will satisfy usability, presence in shipping code and likelihood of > deployment. It comes at the cost of either using a different port number > or else adding startls into the protocol. It's understandable why there > would be opposition to implementing this at revision -16 and with code > widely deployed in the field. But from the point of view of the question > "where do we want to be a couple of years down the road from now?", it's a > pile better than ipsec from an operations point of view.
I'll publicly state a portion of the conversation I had with Stephen Farrell about why crypto doesn't show up in BGP related stuff. The excuse people keep on offering is that BMP is not BGP - why not put on your layer of frosting and add TLS? Because it is very likely that BMP is just a thin layer of protocol on top of someone's BGP implementation. They're not separate things. They might be but they're probably not. Protocol developers are also not security people. For the most part, if security services are available, they come in two flavors: - Managed out of stack. IPsec configuration is usually something you tell the system to apply to your transport layer. It's managed by the kernel. If the thing screws up, it happens in the OS layer. TCP-MD5 will usually happen this way if your BGP code isn't implementing your TCP stack. TCP-AO would presumably act the same way. - Managed in-stack. TLS or SSH could be done this way. You're running those services right in your code for your transport session. You also may have the option to use TLS or SSH in a tunnel mode. But then you have to worry about yet another program dying or being in the middle, or having flow control or CPU cycle contention for your routing. BGP developers tend to be overly sensitive with transport layer issues. We spend a lot time understanding a lot of the weird conditions in the protocol because routing outages that are Internet impacting happen because of weird things impacting TCP. A few lost packets at the wrong time, a bit of window congestion and there goes your peering sessions with short timers. And now you want to throw another layer on top of that? And you want that layer to make it even more difficult to diagnose what went wrong for forensics purposes? There will be *no more* ability to send a few packet snippets and say "what's going on in BGP" without help from the end application or without completely doing an informed man-in-the-middle on the crypto layers. Stephen's response is basically "you're a giant company. Go do the thing!" Fine. I or one of my coworkers could do the security thing. But when there's an outage related to that thing, we'll have to throw any issues relating to the security layers over the wall to the people who work on them. They've not had to deal with transport sessions that last *months* and occasionally years. It'll be fun. Issues could be found and knocked out through rigorous testing over time. But bugs will happen meanwhile. So... who is willing to sign your network up for this grand experiment at securing your BMP? -- Jeff _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
