Subject: [P2PSIP] adding tcp-test option to reload

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 4 Nov 2008 15:33:33 -0500

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-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 4 Nov 2008 19:42:52 -0500

<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-masked] [mailto:[email-masked]] On Behalf Of
Bruce Lowekamp
Sent: Tuesday, November 04, 2008 3:34 PM
To: p2psip
Subject: [P2PSIP] adding tcp-test option to reload

Bruce

---

From: Dan York <[email-masked]>
Date: Wed, 5 Nov 2008 10:17:46 -0500

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

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
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

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 5 Nov 2008 10:47:18 -0500

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-masked]> wrote:
> 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.
>
> 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
>
>

-- 
David A. Bryan
[email-masked]
www.SIPeerior.com

---

From: Dan York <[email-masked]>
Date: Thu, 6 Nov 2008 06:27:34 -0500

David,

Well said...  a couple of points inline prefixed with "DY>":

On Nov 5, 2008, at 10:47 AM, David A. Bryan wrote:

> apply to their application.

DY> Whoa..... wait, wait... you want to put out a protocol that people  
actually *implement*? :-)

DY> Seriously, your point is well taken, we DO need to put out specs  
that people are actually able to implement, but I would argue it from  
a slightly different point...

> The fact that many people do ignore our

DY> ... that part of the reason why we have implementation issues is,  
in fact, that we are trying to do too many things in some of the  
protocols.  However, my experience with non-compatible implementations  
of many of the other SIP protocols is that we have too many "SHOULD"s  
or places where we have options that people can choose.  I mean, look  
at the fact that we've needed to spin up a whole new working group,  
BLISS, primarily because we have about 4 different ways to do Do Not  
Disturb inside of SIP!  (And a number of other reasons...)

DY> In my personal opinion, for solid interop we need fewer SHOULDs  
and should have mainly MUSTs... but to your point, the simpler we can  
make the protocol, the better.
> inside my network, why implement ICE?

DY> Agreed.

> If I am a developer looking to
> TLS. I certainly may not want to use it for testing.

DY> Agreed.

> I think if

DY> So why don't we throw out the TLS mode entirely and just have the  
base be NON-TLS and then write a companion document that explains how  
to do *secure* P2PSIP?

DY> That way for an implementor they can say that they support RFCxxxx  
for P2PSIP and then also RFCyyyy for secure P2PSIP.  This gets around  
all of the SHOULDs that cause interop problems.
> also have strong reasons to demand it be implemented.

DY> Sure, but going back to ensuring *interop*... if we just let  
everyone decide for themselves which parts of the spec they will  
implement, how in the world are we going to be able to do any real  
interop testing?

DY> I would argue we should carve out the interoperable pieces into  
their simplest forms and then advance those as separate RFCs.  That  
way implementors can choose among the RFCs, but at the very least they  
can say they are "RFCxxxx-compliant" and that will be understood by  
other vendors - and can be tested.

My 2 cents,
Dan

---

From: "David A. Bryan" <[email-masked]>
Date: Thu, 6 Nov 2008 08:53:06 -0500

Very good points...in many ways I'd definitely agree the approach of
doing things like this in different drafts, if we could get people to
go for that approach. As you point out -- much easier to specify what
one does and does not support... Problem would be the draft explosion.
Also for this one I think that we could specify a way in the draft for
the two sides to negotiate if they have TLS or not, although that
solves things at a protocol level, not at a "I support XXXX" level...

David (as individual)

On Thu, Nov 6, 2008 at 6:27 AM, Dan York <[email-masked]> wrote:
> DY> Seriously, your point is well taken, we DO need to put out specs that
> people are actually able to implement, but I would argue it from a slightly
> different point...
>
> DY> ... that part of the reason why we have implementation issues is, in
> fact, that we are trying to do too many things in some of the protocols.
>  However, my experience with non-compatible implementations of many of the
> other SIP protocols is that we have too many "SHOULD"s or places where we
> have options that people can choose.  I mean, look at the fact that we've
> needed to spin up a whole new working group, BLISS, primarily because we
> have about 4 different ways to do Do Not Disturb inside of SIP!  (And a
> number of other reasons...)
>
> DY> In my personal opinion, for solid interop we need fewer SHOULDs and
> should have mainly MUSTs... but to your point, the simpler we can make the
> protocol, the better.
>>
>>
> DY> So why don't we throw out the TLS mode entirely and just have the base
> be NON-TLS and then write a companion document that explains how to do
> *secure* P2PSIP?
>
> DY> That way for an implementor they can say that they support RFCxxxx for
> P2PSIP and then also RFCyyyy for secure P2PSIP.  This gets around all of the
> SHOULDs that cause interop problems.
>>
>>
> DY> Sure, but going back to ensuring *interop*... if we just let everyone
> decide for themselves which parts of the spec they will implement, how in
> the world are we going to be able to do any real interop testing?
>
> DY> I would argue we should carve out the interoperable pieces into their
> simplest forms and then advance those as separate RFCs.  That way
> implementors can choose among the RFCs, but at the very least they can say
> they are "RFCxxxx-compliant" and that will be understood by other vendors -
> and can be tested.
>
> My 2 cents,
> Dan
>
> --

---

From: Dan York <[email-masked]>
Date: Thu, 6 Nov 2008 09:38:22 -0500

David,

> one does and does not support... Problem would be the draft explosion.

DY> Well, yes, draft explosion definitely IS a problem. We need only  
look at the fact that we need a Hitchhiker's Guide or Henry's simple  
SIP draft to know that there is a problem.  On the other hand, we're  
all just in this wee minor little process of rearchitecting the entire  
communications infrastructure of the planet... :-)

DY> As much as we don't want an explosion of a zillion drafts, do we  
really want giant documents that are complicated to implement?

DY> Comparing to software development models, are we trying to do the  
monolithic approach of building big giant programs that do  
everything??  Or are we trying to do the UNIX approach of making many  
small utilities and stringing them together?
> solves things at a protocol level, not at a "I support XXXX" level...

DY> Right. So we can make the spec allow them to negotiate... but that  
does nothing to help with whether or not two P2PSIP implementations  
can interoperate.  A vendor can't take the RELOAD spec, implement it,  
and know that they have a prayer of FULL interoperability with someone  
else... because there are optional parts to it.

DY> You've already defined two very clear use cases for where P2PSIP  
would be implemented WITHOUT "security" aspects to the protocol.  So  
why not simplify the main spec and carve those off as separate RFCs?

DY> Let's look at a case where this has worked well - RTP.  If you  
want to implement basic RTP, you implement RFC 3550.  If you want to  
implement Secure RTP, you implement RFC 3711.  Ta da... you're done.   
It's very easy for vendors to specify whether or not they support  
"secure" use of RTP because they can point to their use of "SRTP" as  
defined in RFC 3711.

DY> Now, yes, I'm a "security guy" arguing to REMOVE security  
provisions from the main draft, but that's primarily because I realize  
that if they are left in there as (wink, wink) "options", then NOBODY  
WILL IMPLEMENT THEM. They text is in the RFC and so someone can say  
that they have appeased whomever is doing a security review, but in  
practice no one will implement them and the result is that protocols  
will wind up being LESS secure.

DY> I've also been a product manager responsible for trying to ensure  
proper implementations of various RFCs and in that role I can assure  
you that large RFCs containing SHOULDs are horrible.  I would vastly  
prefer multiple RFCs (where the division makes sense) that *only*  
contain MUSTs.

DY> Why don't we put this on the P2PSIP agenda for IETF 73? (the idea  
of breaking out security aspects into a separate draft)

My 2 cents,
Dan

P.S. And realizing that I'm advocating making MORE work for the WG and  
we just had a long thread on the RAI list about the lack of people to  
*do* things, I'll put my actions behind my mouth and say that if the  
group agrees with this path, I will volunteer to write one of the  
companion drafts.

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 6 Nov 2008 11:19:13 -0500

Dan,

As editor, I thoroughly endorse splitting off parts of the draft into
separate documents.  The base/SIP split that was done recently was
simply the lowest hanging fruit.  I think there should be at least two
more splits into separate documents.

However, security is not one of these.  Two reasons for this:

- security is so intertwined with the base protocol that it would
probably be impossible to split it out and have the result make any
sense.  Signatures are used not only over the entire message, but also
used (and stored) over particular resources.  If we remove security
from the base draft then we wind up with something bizarre that says
"when using security, put the signature here, see rfcYYYY for how to
do it."

- if we remove security (or even TLS) from the base draft, then we
wind up with a draft specifying an "internet protocol" that has a
security section stating "this protocol cannot be run on the internet
without extensions specified in rfcYYYY."  Do we want to do that?

Bruce

On Thu, Nov 6, 2008 at 9:38 AM, Dan York <[email-masked]> wrote:
> DY> Well, yes, draft explosion definitely IS a problem. We need only look at
> the fact that we need a Hitchhiker's Guide or Henry's simple SIP draft to
> know that there is a problem.  On the other hand, we're all just in this wee
> minor little process of rearchitecting the entire communications
> infrastructure of the planet... :-)
>
> DY> As much as we don't want an explosion of a zillion drafts, do we really
> want giant documents that are complicated to implement?
>
> monolithic approach of building big giant programs that do everything??  Or
> are we trying to do the UNIX approach of making many small utilities and
> stringing them together?
>>
> DY> Right. So we can make the spec allow them to negotiate... but that does
> nothing to help with whether or not two P2PSIP implementations can
> interoperate.  A vendor can't take the RELOAD spec, implement it, and know
> that they have a prayer of FULL interoperability with someone else...
> because there are optional parts to it.
>
> DY> You've already defined two very clear use cases for where P2PSIP would
> be implemented WITHOUT "security" aspects to the protocol.  So why not
> simplify the main spec and carve those off as separate RFCs?
>
> DY> Let's look at a case where this has worked well - RTP.  If you want to
> implement basic RTP, you implement RFC 3550.  If you want to implement
> Secure RTP, you implement RFC 3711.  Ta da... you're done.  It's very easy
> for vendors to specify whether or not they support "secure" use of RTP
> because they can point to their use of "SRTP" as defined in RFC 3711.
>
> DY> Now, yes, I'm a "security guy" arguing to REMOVE security provisions
> from the main draft, but that's primarily because I realize that if they are
> left in there as (wink, wink) "options", then NOBODY WILL IMPLEMENT THEM.
> They text is in the RFC and so someone can say that they have appeased
> whomever is doing a security review, but in practice no one will implement
> them and the result is that protocols will wind up being LESS secure.
>
> DY> I've also been a product manager responsible for trying to ensure proper
> implementations of various RFCs and in that role I can assure you that large
> RFCs containing SHOULDs are horrible.  I would vastly prefer multiple RFCs
> (where the division makes sense) that *only* contain MUSTs.
>
> DY> Why don't we put this on the P2PSIP agenda for IETF 73? (the idea of
> breaking out security aspects into a separate draft)
>
> My 2 cents,
> Dan
>
> P.S. And realizing that I'm advocating making MORE work for the WG and we
> just had a long thread on the RAI list about the lack of people to *do*
> things, I'll put my actions behind my mouth and say that if the group agrees
> with this path, I will volunteer to write one of the companion drafts.
>
> --

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 6 Nov 2008 12:44:55 -0500

<as individual>
I don't agree.

In fact, if there was a way to guarantee the protocol wouldn't work without
TLS, I'd prefer to do that.

I'm tired of marketing folks looking to save a buck of development costs
slicing off security and foisting insecure implementations on unsuspecting
consumers, only to be among the loudest voices slamming their engineering
guys for why the security fix is necessary or can't be done yesterday when
the problems show up.

If you don't need security, then use a simple ciphersuite; don't lop off
TLS.

There is plenty of good open source TLS code around.  Use it.

ICE is a little trickier.  I have the same concerns: implementations that
work in some restricted environments escaping into the wild and failing;
followed by horrible work around like opening holes in firewalls or lack of
interoperability.  The problem is that there isn't, yet, lots of good open
source ICE implementations.

So, I want to go the other way.  I want every bit of documentation to say
"it's mandatory"

Brian

-----Original Message-----
From: Dan York [mailto:[email-masked]] 
Sent: Thursday, November 06, 2008 9:38 AM
To: David A. Bryan
Cc: Brian Rosen; p2psip
Subject: Multiple RFCs or one giant RFC? Re: [P2PSIP] adding tcp-test option
to reload

David,

My 2 cents,
Dan

---

From: Dan York <[email-masked]>
Date: Thu, 6 Nov 2008 13:45:51 -0500

Brian,

> guys for why the security fix is necessary or can't be done  

DY> Wearing my "security" hat, I completely agree with you.  It has  
seemed to me that in the past various protocols have gone out with  
security only an afterthought (if at all), resulting in something  
having to be baked on later.  So there's no argument from me on this  
point.  In my ideal world, it's all "secure" from the start.

DY> David was advancing two use cases where security is, in his  
opinion, not really required and was advocating for having a non-TLS  
mode of the protocol.  Wearing my "product manager" hat, I can see his  
points .

DY> My argument is that either: 1) security like TLS should be a MUST  
in the protocol; or 2) it should be carved out into a separate RFC  
that can be referenced and implemented.

DY> What we don't need are "SHOULD"s that will effectively mean that  
the security protection is never implemented.

Dan

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 6 Nov 2008 14:54:57 -0500

Agree with your points. I want a "MUST".  

Brian

-----Original Message-----
From: Dan York [mailto:[email-masked]] 
Sent: Thursday, November 06, 2008 1:46 PM
To: Brian Rosen
Cc: 'David A. Bryan'; 'p2psip'
Subject: Re: Multiple RFCs or one giant RFC? Re: [P2PSIP] adding tcp-test
option to reload

Brian,

Dan

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 06 Nov 2008 13:39:28 -0600

Brian,

Watch out, you may get what you wish for :-)

The bag of issues discussed here such as ICE for NAT traversal and TLS may
look completely different if the p2p overlay and all other application
protocols run securely over HIP in the endpoints.

HIP for P2P SIP has been amply documented in this WG, so I don't need to rub
it in. See http://www.ietf.org/html.charters/hip-charter.html
 
P2PSIP over HIP seems also to work quite well and the code is freely
available.
http://infrahip.hiit.fi/

There are quite a number of early contributions to this WG on using P2PSIP
over HIP, but I would rather let the authors speak up.

So before wishing and rushing to buy, some shopping seems called for.

Henry

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Nov 2008 09:54:53 +0200

Hi,

yes, the HIP WG had this type of discussions long time ago. For some, if 
you use HIP, it must be secure. Others consider that a disadvantage and 
would like to be able to run HIP without security (i.e., only to get 
mobility and multihoming)... of course, there are valid arguments for 
and against both positions. Of course, not all the arguments used in 
these types of discussions are valid :o)

Cheers,

Gonzalo