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

From: "Michael Chen" <[email-masked]>
Date: Thu, 17 Dec 2009 16:12:49 -0700

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-masked]>

Date: Thu, December 17, 2009 1:19 pm

To: Song Haibin <[email-masked]>

Cc: 'Salman Abdul Baset' <[email-masked]>, 'P2PSIP WG'

<[email-masked]>

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-masked]

>> [mailto:[email-masked]] 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-masked]> 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-masked]> 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-masked]>

>>>>>> Date: Fri, December 11, 2009 7:26 am

>>>>>> To: Ari Keranen <[email-masked]>

>>>>>> Cc: P2PSIP WG <[email-masked]>

>>>>>> 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-masked]>

>>>>>> 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-masked]

>>>>>>> https://www.ietf.org/mailman/listinfo/p2psip

>>>>>> _______________________________________________

>>>>>> P2PSIP mailing list

>>>>>> [email-masked]

>>>>>> https://www.ietf.org/mailman/listinfo/p2psip

>>>>> _______________________________________________

>>>>> P2PSIP mailing list

>>>>> [email-masked]

>>>>> https://www.ietf.org/mailman/listinfo/p2psip

>>>> _______________________________________________

>>>> P2PSIP mailing list

>>>> [email-masked]

>>>> https://www.ietf.org/mailman/listinfo/p2psip

>>> _______________________________________________

>>> P2PSIP mailing list

>>> [email-masked]

>>> https://www.ietf.org/mailman/listinfo/p2psip

_______________________________________________

P2PSIP mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/p2psip

---

From: Emil Ivov <[email-masked]>
Date: Fri, 18 Dec 2009 01:36:03 +0200

> On that note, doesn't IPv6 make ICE obsolete? and yet this draft  

In an IPv6 only world, probably. Until then, and I really hope we both  
get to live that long, IPv6 is just one more reason to use ICE.

Cheers,
Emil

---

From: jc <[email-masked]>
Date: Thu, 17 Dec 2009 23:27:47 -0500

> On that note, doesn't IPv6 make ICE obsolete? and yet this draft mandates ICE.

It does, however it's irrelevant if you cannot obtain an IPv6 address which constitutes most of the world's ISP's. There are only three IPv6 capable pops in the intercontinental United States as of April 2009 and the DoD has failed to meet their deadline last year. I'm not sure why ICE was made mandatory in RELOAD as a base protocol but would love to know the rational. ICE should be used "less" going forward not "more", however that sadly isn't the case.