Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC

[jc <[e-mail]>]

Salman,
If you see my other email, yes the iterative nature of Kademlia makes D/TLS  too expensive, it would have to be made recursive to obey the draft. 

I agree about "Attempting" to connect all Nodes even if it MUST TURN them. This is a big failure that won't see success.

> In general, for Internet scale deployment, the idea of trying to make all nodes, no matter what their connectivity, fully participate in the overlay as a peer is highly questionable.

I see this as impossible. Peers and Nodes' need revisited. For instance, it's cheaper to Peer than to TURN so what good is TURN for the Overlay connections? TURN is useless to the Overlay IMHO, this could be used for call routing and app layer services. If you are a Node and you MUST TURN you should Peer instead IMHO.

Julian Cain

On Dec 11, 2009, at 2:33 PM, Salman Abdul Baset wrote:

> Kademlia does iterative routing with parallel requests, and iterative routing has to pay the penalty of TLS/DTLS connection establishment at every hop which is at least 1.5 RTT.
> 
> The alternative is to devise a secure transport protocol or optimize DTLS/TLS to reduce the connection establishment penalty. Security folks may argue that it is a non-starter at IETF.
> 
> Yet, another alternative is to design a custom secure transport. But interoperability is the obvious looser.
> 
> In general, for Internet scale deployment, the idea of trying to make all nodes, no matter what their connectivity, fully participate in the overlay as a peer is highly questionable.
> 
> -s
> 
> On Fri, 11 Dec 2009, jc wrote:
> 
>> Some individuals may not care to use tls or dtls. These standards aren't practical in all cases. Encrypted transports a MUST but mechanism should be optional. This is better than people not using this draft and resolves conearns about the underlying transports lack of performance in certain use cases.
>> 
>> Thinking Chord only as a topology plugin is too narrow from a security performance perspective. I have bad experience with Kademlia as a topology plugin. If you understand Kademlia you should understand how the routing table functions and how the transports reflect that. All topology plugins will be forced to tune themselves to d/tls which the result is a less efficient system.
>> 
>> I don't see where anyone mentioned throw out encryption entirely but I may be wrong.
>> 
>> Julian
>> 
>> Sent from my iPhone
>> 
>> On Dec 11, 2009, at 1:16 PM, Brian Rosen <[e-mail]> wrote:
>> 
>>> <as individual>
>>> I disagree.
>>> 
>>> The problem is that we have a whole lot of history and experience.
>>> 
>>> The experience is that if we don't insist, and make security integral to the
>>> protocol, it doesn't get implemented and we have a majority of insecure
>>> systems.
>>> 
>>> If we do insist, the cost of the security is reasonable: the dire
>>> predictions that it's too costly, too hard, ... don't happen.
>>> 
>>> No amount of text explaining when the security mechanism is or isn't
>>> appropriate works.  You have to make the mechanism integral to the operation
>>> of the protocol, as we have done here.
>>> 
>>> I don't see anything in p2psip which would be different then our history and
>>> experience.  The costs aren't as bad as you fear.  The probability of nearly
>>> every system being implemented insecurely is very high if you make it
>>> optional.
>>> 
>>> Don't do that.
>>> 
>>> Brian
>>> 
>>> 
>>> On 12/11/09 12:49 PM, "Michael Chen" <[e-mail]> wrote:
>>> 
>>>> I too agree with the three of you. D/TLS should be optional. Several of my
>>>> previous post voice concerns about redundancy and efficiency of the transport
>>>> layer.
>>>> 
>>>> --Michael
>>>>> -------- Original Message --------
>>>>> Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as
>>>>> part of the WGLC
>>>>> From: jc <[e-mail]>
>>>>> Date: Fri, December 11, 2009 7:26 am
>>>>> To: Ari Keranen <[e-mail]>
>>>>> Cc: P2PSIP WG <[e-mail]>
>>>>> 
>>>>> I said this about 7 months ago and I still agree that there should be
>>>>> no mandatory transport layer encryption as this should be provided
>>>>> outside of the scope of this draft.
>>>>> 
>>>>> Julian
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen <[e-mail]>
>>>>> wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> David A. Bryan wrote:
>>>>>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some Contexts
>>>>>>> I’ve raised this issue before, but I’m hoping that now that
>>>>>>> people have had a bit more time to think about all the use cases,
>>>>>>> see what it means in the real world, etc., there might be a bit mo
>>>>>>> re support for modifying the requirement for TLS/DTLS. TLS/DTLS ma
>>>>>>> kes sense in some cases, but if we are expecting RELOAD to be reus
>>>>>>> able, it is clear to me that it does not make sense in all cases.
>>>>>>> It was familiar
>>>>>>> to the editors, and well understood, so it made sense as a proposal,
>>>>>>> but I disagree with it being the mandatory/only solution.
>>>>>> 
>>>>>> I fully agree with David that making (D)TLS mandatory is not a good
>>>>>> idea, especially concerning re-usability of the protocol in scenarios
>>>>>> where you already have similar security features provided by the
>>>>>> underlying system.
>>>>>> 
>>>>>> 
>>>>>> Cheers,
>>>>>> Ari
>>>>>> _______________________________________________
>>>>>> P2PSIP mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>>> _______________________________________________
>>>>> P2PSIP mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>> 
>>>> 
>>>> _______________________________________________
>>>> P2PSIP mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/p2psip
>>> 
>>> 
>>> _______________________________________________
>>> P2PSIP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/p2psip
>> _______________________________________________
>> P2PSIP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/p2psip
>>