Hiya, On 05/12/15 19:10, John G. Scudder wrote: > Hi Nick, Randy and Stephen, > > If I understand you correctly, the proposition is: > > - The IPSec option I offered and the TLS option you offered are semantically > identical from the perspective of their security properties.
Almost. There are API differences between 'em as IPsec is usually in the kernel and so it's presence/absence isn't visible to the application but yes, security wise pretty much every thing one can do with one can be done with the other in theory. > - TLS would be deployed at such time as it's implemented but IPSec won't even > though already available because of (something I am not entirely clear on, > but depending on one's level of sarcasm it's either something like "TLS is > better architected" or "IPSec is unfashionable"). I think it is fair to say deployment should be easier with TLS as soon as it's available on the endpoints, which ought not be hard. That's not really down to fashion but due more to what Randy and Nick said - TLS is much more widely used, but TLS is also easier for a specific application to use, without affecting the rest of the machine on which it's running. > - Therefore, we should ditch the IPSec proposal and adopt the TLS proposal. > As you say, that's clearly a WG decision. > If that is the WG consensus, that's what we'll do, of course. I'd appreciate > it if one of those advocating this option would send specific text to be used > as a replacement for the paragraph I offered, so that the WG knows exactly > what they're choosing between. > I think if the WG want TLS, there's one more decision to make: use another port or follow the STARTTLS approach. The latter is probably more work in terms of crafting text but the real reason to pick one over the other is probably down to which the WG think would be operationally easier. I'd not try guess that myself and would defer to those who deploy this stuff. If the former, (another port), then all you'd need to say would be something like: Where the security considerations outlined above are a concern, users of this protocol SHOULD use TLS [RFC5246] following the relevant best current practices set out in BCP 195 [RFC7525]. TLS will likely be used with specific ports dedicated for that and mutually agreed between peers. I forget if BMP has ports allocated or not, if it does, the above I guess ought be accompanied by a new port allocation for a BMP/TLS port. In the above I don't call out use of per-shared keys, since with TLS it's usually easier to use self-signed certs etc but the precise details would be better left to someone who'd started to use that. There's loads of fairly easy ways to get interop, if we assume that folks use fairly standard TLS libraries and tooling. In the latter case (STARTTLS), there'd be some more text to write so I won't guess at it now. Cheers, S. > Thanks, > > --John > >> On Dec 5, 2015, at 7:12 AM, Nick Hilliard <[email protected]> wrote: >> >> On 05/12/2015 02:51, John Scudder wrote: >>> I do not understand your point. Wasn't actually intended as a wiggle, >>> but as an option that you can actually do with existing shipping code. >>> Maybe we can discuss Monday. >> >> in a lot of years, I've never once seen or heard of anyone using ipsec to >> secure router-to-host or router-to-router management plane communications. >> Maybe it happens, who knows. No doubt the option works in most if not all >> mainline router management plane stacks, and no doubt there are people who >> implement this. I've never come across these people, that's all. >> >> The point that Randy seems to be making is that this is tickbox security >> from a practical point of view. It satisfies the ietf's requirement's for >> mandating encryption everywhere. It will certainly work. It will probably >> interoperate well and it will be every bit as secure as ipsec is. But it >> will only rarely if ever be used in production because ipsec is painful to >> deploy and has problematic failure modes. >> >> The security considerations section in this ID explicitly states that there >> are security risks associated with leaking bgp information. If the ietf >> believes this, then there should be a recommendation to secure the protocol >> with some form of encryption mechanism (not just authentication), and an >> encryption mechanism which is likely to be deployed in production. If the >> ietf doesn't believe this, then the section should be removed. >> >> 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. >> >> Nick > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
