On that note, doesn't IPv6 make ICE obsolete? and yet this draft mandates ICE.
--Michael
-------- Original Message --------
Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as
part of the WGLC
From: jc <[email protected]>
Date: Thu, December 17, 2009 1:19 pm
To: Song Haibin <[email protected]>
Cc: 'Salman Abdul Baset' <[email protected]>, 'P2PSIP WG'
<[email protected]>
Nor is ICE good for overlays making use of iterative routing.
Julian
On Dec 16, 2009, at 10:51 PM, Song Haibin wrote:
>
> TLS/DTLS is not good to the DHT algorithms that use iterative routing. And
> it also prevents using of direct response to a certain extent. Having a
> security analysis draft for p2psip for deployers to consider threats and
> possible solution in their deployment scenarios will qualify.
>
> For interoperability, it depends on both the standard and the number of
> deployers who want to obey the standard.
>
> Thanks,
> Haibin
>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:p2psip-bounces@ietf.org] On Behalf Of Salman Abdul Baset
>> Sent: Saturday, December 12, 2009 3:33 AM
>> To: jc
>> Cc: P2PSIP WG
>> Subject: Re: [P2PSIP] Concerns, questions and nits about base
>> -06 as part of the WGLC
>>
>> 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 <[email protected]> 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"
>> <[email protected]> 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 <[email protected]>
>>>>>> Date: Fri, December 11, 2009 7:26 am
>>>>>> To: Ari Keranen <[email protected]>
>>>>>> Cc: P2PSIP WG <[email protected]>
>>>>>>
>>>>>> 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
>>>>>> <[email protected]>
>>>>>> 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
>>>>>>> [email protected]
>>>>>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>>>> _______________________________________________
>>>>>> P2PSIP mailing list
>>>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> P2PSIP mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>>
>>>>
>>>> _______________________________________________
>>>> P2PSIP mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/p2psip
>>> _______________________________________________
>>> P2PSIP mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>
>>
>
>
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
