Stephen, On Fri, Oct 16, 2015 at 03:32:48PM +0100, Stephen Farrell wrote: > On 14/10/15 21:35, Jeffrey Haas wrote: > > It's refreshingly honest, > > Do we agree that the above is in fact the situation? If we do, > then I think the easiest way to handle my DISCUSS is to figure > out how best to phrase that.
I'll leave that to the authors to fight out since I think we both have complementary opinions here. You're "there is no security, only Zuul". I'm "we can spackle on security if you care to, the spec is pretty quiet about requirements for transport". > > 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. > > Is that the case really? Has it been done in any real and interesting > networks? (For BMP or BGP) If so can you send me a pointer to a > description of what was done and (ideally) how well that worked? TCP-MD5 is pervasive and fairly well used. The lack of useful key rollover in those environments was discussed in KARP. If you want to today, you can use IPSEC to protect BGP sessions, but those tend to be static SAs. There are customers who use this, (with IKE even!), but they are not common. While my employer hasn't protected BMP using MD5 or IPSEC, we can leverage the existing code fairly quickly if there was the push to. (And probably worth prodding the product management to do since it's mostly low hanging fruit.) For things that resemble applications rather than routing like BMP, there are common tricks you can do that give you secure transport. The most typical and trivial is to configure a tunnel between the two endpoints that have the appropriate security properties. The application, using the typical host stack, will exchange its traffic over the tunnel. Firewalling can enforce the traffic not egressing other interfaces without altering the application. BGP itself could (and has) worked over such tunnels, but typically must be configured in "multi-hop" mode to permit the exchanged nexthops to be evaluated differently than they would if they used the tunnel interface. The goal is to let the routing go over one transport but the nexthops in the protocol must direct traffic to real interfaces. This decoupling in such tunneled circumstances is not a good operational practice, although there are interesting ways the bad parts could be mitigated. The issue with such tunneling in the context of routing has always been related to operational impact and bootstrapping and timeliness issues in a real network. KARP highlighted many of those issues, but obviously did not conclude on them. So, to answer your original question: Yes, that's the case. You can do stuff even if you don't put it in the code. -- Jeff _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
