Personally, I think the slippery slope we are risking here is the other way...in the RAI in general we keep throwing more and more mandatory things into our protocols, and the spec itself becomes more and more irrelevant when people ignore parts of the spec that do not apply to their application. The fact that many people do ignore our "sage advice" is a symptom of what is wrong with the default approach of making everything mandatory. In my mind, this is why SIP compatibility is so elusive. Who actually implements everything we say is mandatory in the many SIP specs? With no guidance other then "you must do it all", we end up with non-compatible implementations.
If I am a carrier and am building a P2PSIP system for use exclusively inside my network, why implement ICE? If I am a developer looking to use P2PSIP on motes for a small sensor network, I may not want to use TLS. I certainly may not want to use it for testing. I think if anything we should just plain support a non-TLS mode. Don't call it a "test-mode". Just call it a non-TLS mode. We need to stop assuming that implementors are not able to decide for themselves when it is or is not appropriate for something as basic as security to be implemented. The IETF is not the only group capable of making the decision of whether this is needed -- let the implementors who actually understand their particular application make the decision -- and just make it optional. If the application needs TLS, the implementors will be smart enough to do so and their customers will also have strong reasons to demand it be implemented. David (as individual) On Wed, Nov 5, 2008 at 10:17 AM, Dan York <[EMAIL PROTECTED]> wrote: > Bruce, > > While I completely understand the desire to have an easy way for > implementations to test TCP connectivity, I do agree with Brian that it's a > slippery slope. For implementors trying to rush a product to market (and to > a degree isn't everyone?), I would expect that if a "no security" mode is an > option in the spec, it will be taken as the path of easiest implementation > and any number of warnings will simply be ignored - and as a result you'll > have countless insecure RELOAD implementations out there. > > Can't a developer simply NOT implement TLS when doing their initial > development? > > Or perhaps someone could make a "reference test implementation" available > for developers to use that supports both "TLS" and "non-TLS" connections? > That would give developers something to work with... but yet leave the spec > as is so that "conforming" implementations must use TLS. > > My 2 cents, > Dan > > > On Nov 4, 2008, at 7:42 PM, Brian Rosen wrote: > >> <as individual> >> I don't like this idea. I think that you are on a slippery slope and I >> think it's not that hard. >> >> I'm not implementing reload at the moment, so I can't speak from >> experience >> in this instance. >> >> Brian >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf >> Of >> Bruce Lowekamp >> Sent: Tuesday, November 04, 2008 3:34 PM >> To: p2psip >> Subject: [P2PSIP] adding tcp-test option to reload >> >> There has been significant conversation around whether requiring both >> TLS and ICE for a minimally functional reload implementation is too >> big of a hurdle during development. Most developers first implement >> something without these two components first regardless, but they need >> to solve nodes exchanging identifiers (without TLS) on their own and >> their protocols are not interoperable for testing purposes. The >> reload authors would like to propose adding the following text, or >> something similar, to introduce a tcp test mode options: >> >> TCP Test Mode is a transport based on TCP but no security >> layer. It SHOULD NOT be used in any production environment as it >> has many security vulnerabilities. It is meant only as simple test >> mode to facilitate testing and interoperability before moving to >> full TLS. When a new TCP session of this type is formed, both ends >> of the connection MUST write their binary Node-ID to the wire >> before sending any other messages over the session. This allows >> both sides to discover the Node-ID of the other side and use this >> in a similar way to the Node-ID discovered when using TLS or DTLS >> from the certificate in the TLS handshake. This mode MUST not be >> used unless the configuration for the overlay instance >> specifically allows it. >> >> Bruce >> _______________________________________________ >> P2PSIP mailing list >> [EMAIL PROTECTED] >> https://www.ietf.org/mailman/listinfo/p2psip >> >> _______________________________________________ >> P2PSIP mailing list >> [EMAIL PROTECTED] >> https://www.ietf.org/mailman/listinfo/p2psip > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation [EMAIL PROTECTED] > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Build voice applications based on open standards. > Find out how at http://www.voxeo.com/free > > > > > > _______________________________________________ > P2PSIP mailing list > [EMAIL PROTECTED] > https://www.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan [EMAIL PROTECTED] www.SIPeerior.com _______________________________________________ P2PSIP mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2psip
