On 05/12/2015 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. > - 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").
more like: ipsec does not appear to enjoy widescale production deployment for router control plane traffic, while tls scores better in this department. > - Therefore, we should ditch the IPSec proposal and adopt the TLS > proposal. this would be my preference. > 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. would suggest to replace "This document does not specify any security mechanism for BMP." with: > Where the security considerations outlined above are a concern, users of > this protocol should consider using Transport Layer Security [RFC5246] > to secure BMP. This presupposes that there is a mechanism defined further up the document to support TLS. STARTTLS looks like it would be messy because BMP is not a line-oriented ASCII format so any implementation would require some hack using information tlvs, i.e. it would be semantically different from every other starttls implementation. So it may be easier to use encrypted sockets. Nick _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
