[p2p-sip] Re: Skype security evaluation: A role model?

[dean.willis at softarmor.com (Dean Willis)]

On Oct 23, 2005, at 2:42 PM, Henry Sinnreich wrote:

>
> Add P2PSIP security to the agenda of the P2PSIP BOF at the 64 IETF?

Note for the procedurally-oriented:

We're not having a BOF at IETF 64.

We're having an ad-hoc meeting after IETF 64 at a conveniently nearby  
facility.


I'm getting more excited about P2P with each passing second. But the  
IETF BOF procedure is the first step to forming a working group, and  
we don't yet have a consensus, even among ourselves, that this work  
should be done at the IETF or that it needs its own working group. I  
suspect it does and it does, but we're not there yet. Maybe we will  
be after this ad-hoc.

--
Dean
From jr at tuffit.com  Mon Oct 31 05:58:04 2005
From: jr at tuffit.com (John Risson)
Date: Mon Oct 31 06:01:39 2005
Subject: [p2p-sip] RE: [P2P SIP] Hierarchical P2P architecture
Message-ID: <000801c5de09$f9d22d20$0100000a@tuffit1>

There is a new tech report for (sip) location services on hierarchic
dhts at http://www.ee.unsw.edu.au/~timm/pubs/reports/index.html#3. The
design minimizes the impact of failure - the hierarchy partitions dht
failure/recovery traffic. It also improves mobility - objects/users can
move to a different part of the dht hierarchy without impacting the root
dht. All comments welcome.
 
Rgds . John. 
 
-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of David A. Bryan
Sent: Friday, September 02, 2005 10:37 AM
To: zze-BAILLY Marc RD-CORE-LAN
Cc: [e-mail]
Subject: Re: [p2p-sip] [P2P SIP] Hierarchical P2P architecture
 
I definitely agree this is important. I think there is even a slightly
more fundamental issue touched on here that needs to be discussed, which
is interconnection of groups (realms?) of P2P SIP users. One way (and
one I think is a good one) is to interconnect them in a P2P way, but we
should also discuss other approaches, such as nodes that participate in
each realm and serve as "gateways" between them, or even techniques
using the PSTN to bridge (ugh), etc.
 
Also related to this, this list has touched on at least 3 different
applications but using similar routing technology -- connecting nodes,
interconnecting groups of nodes, and using P2P to load balance servers.
I think it would be interesting to see if, at all possible, we can use
the same protocol for all applications (maybe not, but it would nice!)
 
--David
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20051031/be254523/attachment.html
From afisk at speedymail.org  Mon Oct 31 15:23:36 2005
From: afisk at speedymail.org (Adam Fisk)
Date: Mon Oct 31 15:24:43 2005
Subject: [p2p-sip] dhts
Message-ID: <[e-mail]>

I just wanted to pipe in on the DHT question to caution against the 
Chord bandwagon.  Sure, Chord is nice to reference because most people 
have heard of it.  That's really just because Chord was the first 
prominent DHT algorithm, though, and that's still it's primary 
distinguishing characteristic.  Other algorithms such as Kademlia are 
significantly more robust and have less rigid routing schemes, though. 

We should be clear that Chord should only be referenced *because people 
know it* and should not seriously be considered for real world 
implementations.  I'd actually prefer it if people stopped referencing 
Chord in the various drafts simply because it contributed to the 
misconception that it's a good option.

Thanks.

-Adam
From srisuresh at yahoo.com  Mon Oct 31 17:08:52 2005
From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Mon Oct 31 17:09:18 2005
Subject: [p2p-sip] Draft: Requirements for SIP-based Peer-to-Peer
	InternetTelephony
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>

First off, good requirements set. Thanks for putting them together. Couple of
comemnts on the draft.

1. I would suggest including the <draft-ford-behave-app-01.txt> draft as a
reference in the context of firewall/NAT traversal. The recommendation in the
draft about how P2P apps could adapt to traverse NATs would be directly
relevant here. Also talked in the draft are security concerns with P2P NAT
traversal.

2. Usage Scenarios - Please expand on section 7.1 with a diagram - specifically
descrbing a P2P SIP setup as opposed to a traditional SIP. What
servers/services are prevalent in traditional SIP setup vs a P2P SIP setup.

Additional comments in line below.

regards,
suresh

--- Salman Abdul Baset <[e-mail]> wrote:

> Thanks for your comments. Please see my comments inline:
> 
> > > 4.5.  NAT and Firewall Traversal
> > >    R1.  The peer-to-peer system SHOULD distribute the functionality of
> > >    NAT and firewall traversal servers to the end-points.
> >
> > I don't see why this must be a requirement. Your other requirements talk
> > about being flexible on where services are located (i.e. centralized or
> > distributed). Given this flexibility, which I agree with, why require
> > that
> > a certain service be distributed? Why not leave the choice up to the
> > builder of
> > the particular P2P overlay network? If that builder wants to provide a
> > centralized NAT and Firewall Traversal scheme, why not let him?
> 

[suresh] I too disagree with the requirement, but for a different reason. I
beleve, the requirement is that P2P nodes should be able to traverese the
FW/NAT devices enroute. Why should the functionality of NAT/firewall traversal
servers be distributed to the end-points? And, why is this a requirement?

I do not see why services required for P2P shoudl be mandated as part of P2P
end nodes.

> I agree that the choice should be left to the bundler of the P2P overlay
> network for deciding which services should be centralized and which should
> be distributed. However, at some point the P2P bundler will need to decide
> whether the overlay network it is building has degenerated into a typical
> SIP-based network and still being marketed as P2P:)
> 

[suresh] I think, it woudl be a good idea to draw a picture to contrast between
a traditional SIP network and a P2P SIP network. Endpoint Identity and location
of P2P nodes (and the associated service) is the key distinction, in my
opinion. 

> > On the other hand, I would agree that the design should SUPPORT making
> > the NAT and
> > Firewall Traversal distributable, but I think you have already covered
> > that in 4.1.
> 
> We think that distributed NAT and firewall traversal is one of the key
> motivations to build a P2P overlay, so we decided to keep it as a seperate
> requirement. 

[suresh] I agree, NAT and firewall traveral is a key requirement for P2P
overlay.

>              There are two requirements in this section. I think one
> option is to delete R1 and keep R2 which says:
> 
> "A peer with NAT and firewall traversal capabilities SHOULD be selected
> such that it does not introduce significant delay between the
> communicating peers."
> 

[suresh] The above requirement is disctinct from R1, in my opinion. I woudl not
suggest eliminating R1. R2 above is similar to Req-3 in
<draft-ford-behave-app-01.txt>, which talks about design guidelines for P2P
applications in the context of NAT traversal.  

> The other option is to include this section as a subsection of 4.1.
> 

[suresh] Please see my comment earlier about rewording R1.

> >
> > > 5.4.1.  Centralized Lookup
> > >    Value-added services such as reliable voicemail storage can be
> > >    provided by a central authority in a P2P network.  The system
> > SHOULD
> > >    allow the peers to efficiently locate the centralized service
> > >    providers or resources.
> >
> > This is just a minor comment. The first sentence seems to imply that
> > voicemail
> > is preferably implemented as a centralized service. I disagree with that
> > implication, and suggest that the first sentence be reworded or simply
> > removed.
> >
> > I DO agree with the requirement in the second sentence.
> 
> The sentence says '...reliable voicemail storage can be provided...'. I
> guess the 'can' should be changed to 'might'.
> 

[suresh] That sounds good.

> 
> > > 6.1.  Support for different DHTs
> > >    Any protocol specification SHOULD be able to incorporate different
> > >    DHT algorithms based on the P2P service provider requirements.
> >
> > Isn't this the same as requirement 4.3??
> 
> We wanted to emphasize that a 'P2P Protocol Spec' must support multiple
> DHTs. Since this requirement fell under 'Architecture' and 'Protocol Spec
> Requirements', we decided to keep it in both. I think cross-referencing
> the sections will be helpful.
> 
> regards,
> --
> Salman Baset
> 

regards,
suresh

> 
> >
> > - Philip Matthews
> >   Nimcat Networks (now a part of Avaya)
> >
> > PS. Please note that my e-mail address has recently changed to
> >        [e-mail]
> >     Mail sent to my old address ([e-mail]) will
> >     be forwarded for a period, but will eventually be returned.
> >
> >
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Salman Abdul Baset
> > Sent: October 28, 2005 13:16
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: [p2p-sip] Draft: Requirements for SIP-based Peer-to-Peer
> > InternetTelephony
> >
> > We have attempted to compile the requirements for SIP-based peer-to-peer
> > Internet telephony in a draft. It is available at:
> > http://www1.cs.columbia.edu/~salman/drafts/draft-baset-sipping-p2preq-00
> > .txt
> >
> > Title: Requirements for SIP-based Peer-to-Peer Internet Telephony
> > Abstract:
> > This document defines requirements for designing peer-to-peer voice,
> > text, and real-time multimedia communication system protocols.
> >
> > Comments are requested.
> >
> > Regards,
> > Salman, Henning, Eunsoo, Kishore
> > _______________________________________________
> > p2p-sip mailing list
> > [e-mail]
> > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
> >
> >
> _______________________________________________
> p2p-sip mailing list
> [e-mail]
> http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
>