From p2psip-bounces@ietf.org Tue May 01 08:26:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HirR6-0001oS-Pk; Tue, 01 May 2007 08:26:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HirR5-0001oN-5N for p2psip@ietf.org; Tue, 01 May 2007 08:26:27 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HirR4-0002yy-NO for p2psip@ietf.org; Tue, 01 May 2007 08:26:27 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1HirRB-0000nc-Fl; Tue, 01 May 2007 08:26:34 -0400 In-Reply-To: <894e079b0704301249g3c538639o4d088fd104e11b7e@mail.gmail.com> References: <894e079b0704261659t66b77385j4614cd8b40c5ba22@mail.gmail.com> <894e079b0704292027s4921ed69g3d68e5803c08229b@mail.gmail.com> <3084061F-5C99-44E1-9A83-D8DB464F1BEA@magma.ca> <894e079b0704300824q515f14bdv5347e0d9dbda96ab@mail.gmail.com> <783A4A1F-3A23-4BDE-A9BE-77149AEC5597@magma.ca> <894e079b0704301249g3c538639o4d088fd104e11b7e@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: Philip Matthews Subject: Re: [P2PSIP] Comments on draft draft-matthews-p2psip-bootstrap-mechanisms-00 Date: Tue, 1 May 2007 08:26:24 -0400 To: Medhavi Bhatia X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 1.7 (+) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2011150043==" Errors-To: p2psip-bounces@ietf.org --===============2011150043== Content-Type: multipart/alternative; boundary=Apple-Mail-1--794810 --Apple-Mail-1--794810 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 30-Apr-07, at 15:49 , Medhavi Bhatia wrote: > Hi Philip, > > If I organize the tasks required to become part of the P2P network > in the following categories: > > Step1: Determine which admitting peer to connect to (bootstrap > server/multicast/static config) > Step2: Form a control connection with the admitting peer (bootstrap > server) The way things are currently defined in the Concepts draft, the bootstrap server is logically distinct from the admitting peer. > Step3: Run the P2P protocol to join the p2p network, register > resources, query, exchange routes etc. > > I think the use of OPTIONS applies to step 1. If you use the Multicast method. > SIP/ICE or any connection establishment protocol which works over > NATS applies to steps 1 and 2. Yup. > However registering myself as a bootstrap peer seems to be part of > Step3. Sure. > I assume that the bootstrap server is part of the p2p network. As currently defined in the Concepts draft, the bootstrap server may or may not be part of the P2P overlay. > > I am just trying to put my head together on this one now ;). Try reading the Concepts draft and see if this helps. > > Medhavi. > > On 4/30/07, Philip Matthews < philip_matthews@magma.ca> wrote: > > On 30-Apr-07, at 11:24 , Medhavi Bhatia wrote: > > > Hi Philip, > > > > NAT Traversal brings a lot of complexity to a P2P network. I think > > we need to carefully identify what we are doing for traversing NAT > > from what we need to get the P2P to work itself. I think if we keep > > in mind that another offer-answer protocol (other than SIP) can be > > used with ICE to set up control connections as well then things are > > easier to analyze at least. > > NAT traversal is complex. Unfortunately, it also seems integral to > P2PSIP. What we do NOT want to do is to repeat the SIP experience > and design a P2PSIP system and then try to add NAT Traversal as an > afterthought. > > > > > The bootstrap server seems to have two roles. It helps location of > > a bootstrap peer (P2P part) as well as act as a rendezvous point > > for establishing a control connection to it (NAT Traversal part). > > The functionality provided by SIP OPTIONS and REGISTER (mainly > > location of the bootstrap peer) seems to be related to P2P part. So > > I think the draft seems to have over specified since it is > > discussing the use of SIP to do that. > > I agree that that the bootstrap server does a number of things. > However, I don't see the distinction that you seem to be suggesting. > Can you explain further? > > - Philip > > > > --Apple-Mail-1--794810 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 30-Apr-07, at = 15:49 , Medhavi Bhatia wrote:

Hi = Philip,

If I organize the tasks required to become part of the = P2P network in the following categories:

Step1: Determine which = admitting peer to connect to (bootstrap server/multicast/static = config)
Step2: Form a control connection with the admitting peer = (bootstrap server)
The way things are currently defined = in the Concepts draft, the bootstrap server is logically distinct from = the admitting peer.

Step3: Run = the P2P protocol to join the p2p network, register resources, query, = exchange routes etc.

I think the use of OPTIONS applies to step = 1.
If you use the Multicast = method.

SIP/ICE or any = connection establishment protocol which works over NATS applies to steps = 1 and 2.
Yup.

However registering myself as a bootstrap peer seems to be = part of Step3.
Sure.

I assume that the bootstrap server is part of the p2p = network.
As currently defined in the Concepts draft, = the bootstrap server may or may not be part of the P2P = overlay.

I am just trying to put my = head together on this one now ;).
Try reading the = Concepts draft and see if this helps.


Medhavi.

On = 4/30/07, Philip Matthews < = philip_matthews@magma.ca> wrote:

On 30-Apr-07, = at 11:24 , Medhavi Bhatia wrote:

> Hi Philip,
>
> = NAT Traversal brings a lot of complexity to a P2P network. I = think
> we need to carefully identify what we are doing for = traversing NAT
> from what we need to get the P2P to work itself. = I think if we keep
> in mind that another offer-answer protocol = (other than SIP) can be
> used with ICE to set up control = connections as well then things are
> easier to analyze at = least.

NAT traversal is complex. Unfortunately, it also seems = integral to
P2PSIP. What we do NOT want to do is to repeat the=A0=A0SI= P experience
and design a P2PSIP system and then try to=A0=A0add NAT = Traversal as an
afterthought.

>
> The bootstrap = server seems to have two roles. It helps location of
> a = bootstrap peer (P2P part) as well as act as a rendezvous point
> = for establishing a control connection to it (NAT Traversal = part).
> The functionality provided by SIP OPTIONS and REGISTER = (mainly
> location of the bootstrap peer) seems to be related to = P2P part. So
> I think the draft seems to have over specified = since it is
> discussing the use of SIP to do that.

I agree = that that the bootstrap server does a number of things.
However, I = don't see the distinction that you seem to be suggesting.
Can you = explain further?

- = Philip





= --Apple-Mail-1--794810-- --===============2011150043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2011150043==-- From p2psip-bounces@ietf.org Tue May 01 15:50:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiyMg-0006nq-0v; Tue, 01 May 2007 15:50:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiyMe-0006fW-0d for p2psip@ietf.org; Tue, 01 May 2007 15:50:20 -0400 Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiyMd-0006wL-Ih for p2psip@ietf.org; Tue, 01 May 2007 15:50:19 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1970309wri for ; Tue, 01 May 2007 12:50:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=bM2qJJM0dulsWOyXO24G4rM++Xauq9Zeb+hN61ULCKxAQn2ZY6oyQ3VXUJSJl3U8HvMunN7w/dVlLFZbF0AwcISVS1L3iL0DeiyOfp6G+WKrSgHXBZcns57W1aP+3gJaZzOla/eFwhEBlRNJb9D1m3I6BH0bKy+tHVtlZWVRCio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=DNq6/Sqo5swZkCWGHu+gF9rIF1VDxfwYafnC844aiP5y9fzNtHMO5ld6Tv1JwfRKezZ95dNA4KXmM0NfzrZ6h2VT7nQTCz9vs8nVTthoMnPKiuIeK7OtvtZA0/ayOQ8zgNfHX5KqwHz/FX/LyECfe7k5oiRmQA+RJmUGM0VuIfc= Received: by 10.115.33.1 with SMTP id l1mr306677waj.1178049012099; Tue, 01 May 2007 12:50:12 -0700 (PDT) Received: by 10.114.120.9 with HTTP; Tue, 1 May 2007 12:50:11 -0700 (PDT) Message-ID: <894e079b0705011250g182869bp8bcc2941ac42255f@mail.gmail.com> Date: Tue, 1 May 2007 15:50:12 -0400 From: "Medhavi Bhatia" To: "Philip Matthews" Subject: Re: [P2PSIP] Comments on draft draft-matthews-p2psip-bootstrap-mechanisms-00 In-Reply-To: MIME-Version: 1.0 References: <894e079b0704261659t66b77385j4614cd8b40c5ba22@mail.gmail.com> <894e079b0704292027s4921ed69g3d68e5803c08229b@mail.gmail.com> <3084061F-5C99-44E1-9A83-D8DB464F1BEA@magma.ca> <894e079b0704300824q515f14bdv5347e0d9dbda96ab@mail.gmail.com> <783A4A1F-3A23-4BDE-A9BE-77149AEC5597@magma.ca> <894e079b0704301249g3c538639o4d088fd104e11b7e@mail.gmail.com> X-Google-Sender-Auth: 38fd2025486b8f18 X-Spam-Score: 1.2 (+) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1967363823==" Errors-To: p2psip-bounces@ietf.org --===============1967363823== Content-Type: multipart/alternative; boundary="----=_Part_46374_11062231.1178049012016" ------=_Part_46374_11062231.1178049012016 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Philip, Thanks for the pointer.I think its important to realize that the bootstrap server is only used as a SIP Proxy/Server in this draft and does not have anything to do with the p2p protocol itself (more the reason to use a separate term for introduction server in the p2p network). However, the draft seems to assume that the p2p nodes speak REGISTER and OPTIONS as well. I think it would help if we state this separately somewhere in the draft. Here is one proposal: I think the REGISTER could be replaced by a p2p primitive as another option. This would simplify the p2p node requirements a little. With the current assumptions in the draft, the p2p nodes are speaking ICE over SIP (the SIP connection is discarded after the p2p control connection comes up), OPTIONS, REGISTER and the p2p protocol itself (maybe a different protocol from SIP). Medhavi. On 5/1/07, Philip Matthews wrote: > > > On 30-Apr-07, at 15:49 , Medhavi Bhatia wrote: > > Hi Philip, > > If I organize the tasks required to become part of the P2P network in the > following categories: > > Step1: Determine which admitting peer to connect to (bootstrap > server/multicast/static config) > Step2: Form a control connection with the admitting peer (bootstrap > server) > > The way things are currently defined in the Concepts draft, the bootstrap > server is logically distinct from the admitting peer. > > Step3: Run the P2P protocol to join the p2p network, register resources, > query, exchange routes etc. > > I think the use of OPTIONS applies to step 1. > > If you use the Multicast method. > > SIP/ICE or any connection establishment protocol which works over NATS > applies to steps 1 and 2. > > Yup. > > However registering myself as a bootstrap peer seems to be part of Step3. > > Sure. > > I assume that the bootstrap server is part of the p2p network. > > As currently defined in the Concepts draft, the bootstrap server may or > may not be part of the P2P overlay. > > > I am just trying to put my head together on this one now ;). > > Try reading the Concepts draft and see if this helps. > > > Medhavi. > > On 4/30/07, Philip Matthews < philip_matthews@magma.ca> wrote: > > > > > > On 30-Apr-07, at 11:24 , Medhavi Bhatia wrote: > > > > > Hi Philip, > > > > > > NAT Traversal brings a lot of complexity to a P2P network. I think > > > we need to carefully identify what we are doing for traversing NAT > > > from what we need to get the P2P to work itself. I think if we keep > > > in mind that another offer-answer protocol (other than SIP) can be > > > used with ICE to set up control connections as well then things are > > > easier to analyze at least. > > > > NAT traversal is complex. Unfortunately, it also seems integral to > > P2PSIP. What we do NOT want to do is to repeat the SIP experience > > and design a P2PSIP system and then try to add NAT Traversal as an > > afterthought. > > > > > > > > The bootstrap server seems to have two roles. It helps location of > > > a bootstrap peer (P2P part) as well as act as a rendezvous point > > > for establishing a control connection to it (NAT Traversal part). > > > The functionality provided by SIP OPTIONS and REGISTER (mainly > > > location of the bootstrap peer) seems to be related to P2P part. So > > > I think the draft seems to have over specified since it is > > > discussing the use of SIP to do that. > > > > I agree that that the bootstrap server does a number of things. > > However, I don't see the distinction that you seem to be suggesting. > > Can you explain further? > > > > - Philip > > > > > > > > > > ------=_Part_46374_11062231.1178049012016 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Philip,

Thanks for the pointer.I think its important to realize that the bootstrap server is only used as a SIP Proxy/Server in this draft and does not have anything to do with the p2p protocol itself (more the reason to use a separate term for introduction server in the p2p network). However, the draft seems to assume that the p2p nodes speak REGISTER and OPTIONS as well. I think it would help if we state this separately somewhere in the draft.

Here is one proposal:
I think the REGISTER could be replaced by a p2p primitive as another option. This would simplify the p2p node requirements a little. With the current assumptions in the draft, the p2p nodes are speaking ICE over SIP (the SIP connection is discarded after the p2p control connection comes up), OPTIONS, REGISTER and the p2p protocol itself (maybe a different protocol from SIP).

Medhavi.


On 5/1/07, Philip Matthews <philip_matthews@magma.ca> wrote:

On 30-Apr-07, at 15:49 , Medhavi Bhatia wrote:

Hi Philip,

If I organize the tasks required to become part of the P2P network in the following categories:

Step1: Determine which admitting peer to connect to (bootstrap server/multicast/static config)
Step2: Form a control connection with the admitting peer (bootstrap server)
The way things are currently defined in the Concepts draft, the bootstrap server is logically distinct from the admitting peer.

Step3: Run the P2P protocol to join the p2p network, register resources, query, exchange routes etc.

I think the use of OPTIONS applies to step 1.
If you use the Multicast method.

SIP/ICE or any connection establishment protocol which works over NATS applies to steps 1 and 2.
Yup.

However registering myself as a bootstrap peer seems to be part of Step3.
Sure.

I assume that the bootstrap server is part of the p2p network.
As currently defined in the Concepts draft, the bootstrap server may or may not be part of the P2P overlay.

I am just trying to put my head together on this one now ;).
Try reading the Concepts draft and see if this helps.


Medhavi.

On 4/30/07, Philip Matthews < philip_matthews@magma.ca> wrote:

On 30-Apr-07, at 11:24 , Medhavi Bhatia wrote:

> Hi Philip,
>
> NAT Traversal brings a lot of complexity to a P2P network. I think
> we need to carefully identify what we are doing for traversing NAT
> from what we need to get the P2P to work itself. I think if we keep
> in mind that another offer-answer protocol (other than SIP) can be
> used with ICE to set up control connections as well then things are
> easier to analyze at least.

NAT traversal is complex. Unfortunately, it also seems integral to
P2PSIP. What we do NOT want to do is to repeat the  SIP experience
and design a P2PSIP system and then try to  add NAT Traversal as an
afterthought.

>
> The bootstrap server seems to have two roles. It helps location of
> a bootstrap peer (P2P part) as well as act as a rendezvous point
> for establishing a control connection to it (NAT Traversal part).
> The functionality provided by SIP OPTIONS and REGISTER (mainly
> location of the bootstrap peer) seems to be related to P2P part. So
> I think the draft seems to have over specified since it is
> discussing the use of SIP to do that.

I agree that that the bootstrap server does a number of things.
However, I don't see the distinction that you seem to be suggesting.
Can you explain further?

- Philip






------=_Part_46374_11062231.1178049012016-- --===============1967363823== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1967363823==-- From p2psip-bounces@ietf.org Tue May 01 16:05:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiybP-0003Lz-8e; Tue, 01 May 2007 16:05:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiybO-0003Lt-2x for p2psip@ietf.org; Tue, 01 May 2007 16:05:34 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiybN-0002B9-Gy for p2psip@ietf.org; Tue, 01 May 2007 16:05:34 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1HiybM-0003gs-8l; Tue, 01 May 2007 16:05:32 -0400 In-Reply-To: <894e079b0705011250g182869bp8bcc2941ac42255f@mail.gmail.com> References: <894e079b0704261659t66b77385j4614cd8b40c5ba22@mail.gmail.com> <894e079b0704292027s4921ed69g3d68e5803c08229b@mail.gmail.com> <3084061F-5C99-44E1-9A83-D8DB464F1BEA@magma.ca> <894e079b0704300824q515f14bdv5347e0d9dbda96ab@mail.gmail.com> <783A4A1F-3A23-4BDE-A9BE-77149AEC5597@magma.ca> <894e079b0704301249g3c538639o4d088fd104e11b7e@mail.gmail.com> <894e079b0705011250g182869bp8bcc2941ac42255f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <2F1AC9FE-D8D8-4210-97FD-D04D80FEF5DA@magma.ca> From: Philip Matthews Subject: Re: [P2PSIP] Comments on draft draft-matthews-p2psip-bootstrap-mechanisms-00 Date: Tue, 1 May 2007 16:05:28 -0400 To: Medhavi Bhatia X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 1.2 (+) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1959433850==" Errors-To: p2psip-bounces@ietf.org --===============1959433850== Content-Type: multipart/alternative; boundary=Apple-Mail-6-26749159 --Apple-Mail-6-26749159 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 1-May-07, at 15:50 , Medhavi Bhatia wrote: > Hi Philip, > > Thanks for the pointer.I think its important to realize that the > bootstrap server is only used as a SIP Proxy/Server in this draft > and does not have anything to do with the p2p protocol itself (more > the reason to use a separate term for introduction server in the > p2p network). Yes, in this draft, a bootstrap server does not speak the peer protocol. > However, the draft seems to assume that the p2p nodes speak > REGISTER and OPTIONS as well. I think it would help if we state > this separately somewhere in the draft. The draft clearly states that SIP is used for signaling. REGISTER and OPTIONS are SIP methods, and are defined in 3261. What else should we say??? > > > On 5/1/07, Philip Matthews wrote: > > On 30-Apr-07, at 15:49 , Medhavi Bhatia wrote: > >> Hi Philip, >> >> If I organize the tasks required to become part of the P2P network >> in the following categories: >> >> Step1: Determine which admitting peer to connect to (bootstrap >> server/multicast/static config) >> Step2: Form a control connection with the admitting peer >> (bootstrap server) > The way things are currently defined in the Concepts draft, the > bootstrap server is logically distinct from the admitting peer. > >> Step3: Run the P2P protocol to join the p2p network, register >> resources, query, exchange routes etc. >> >> I think the use of OPTIONS applies to step 1. > If you use the Multicast method. > >> SIP/ICE or any connection establishment protocol which works over >> NATS applies to steps 1 and 2. > Yup. > >> However registering myself as a bootstrap peer seems to be part of >> Step3. > Sure. > >> I assume that the bootstrap server is part of the p2p network. > As currently defined in the Concepts draft, the bootstrap server > may or may not be part of the P2P overlay. >> >> I am just trying to put my head together on this one now ;). > Try reading the Concepts draft and see if this helps. > >> >> Medhavi. >> >> On 4/30/07, Philip Matthews < philip_matthews@magma.ca> wrote: >> >> On 30-Apr-07, at 11:24 , Medhavi Bhatia wrote: >> >> > Hi Philip, >> > >> > NAT Traversal brings a lot of complexity to a P2P network. I think >> > we need to carefully identify what we are doing for traversing NAT >> > from what we need to get the P2P to work itself. I think if we keep >> > in mind that another offer-answer protocol (other than SIP) can be >> > used with ICE to set up control connections as well then things are >> > easier to analyze at least. >> >> NAT traversal is complex. Unfortunately, it also seems integral to >> P2PSIP. What we do NOT want to do is to repeat the SIP experience >> and design a P2PSIP system and then try to add NAT Traversal as an >> afterthought. >> >> > >> > The bootstrap server seems to have two roles. It helps location of >> > a bootstrap peer (P2P part) as well as act as a rendezvous point >> > for establishing a control connection to it (NAT Traversal part). >> > The functionality provided by SIP OPTIONS and REGISTER (mainly >> > location of the bootstrap peer) seems to be related to P2P part. So >> > I think the draft seems to have over specified since it is >> > discussing the use of SIP to do that. >> >> I agree that that the bootstrap server does a number of things. >> However, I don't see the distinction that you seem to be suggesting. >> Can you explain further? >> >> - Philip >> >> >> >> > > --Apple-Mail-6-26749159 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 1-May-07, at = 15:50 , Medhavi Bhatia wrote:

Hi = Philip,

Thanks for the pointer.I think its important to realize = that the bootstrap server is only used as a SIP Proxy/Server in this = draft and does not have anything to do with the p2p protocol itself = (more the reason to use a separate term for introduction server in the = p2p network).
Yes, in this draft, a bootstrap = server does not speak the peer protocol.

However, the draft seems to assume that the p2p nodes = speak REGISTER and OPTIONS as well. I think it would help if we state = this separately somewhere in the draft.

The draft clearly states = that SIP is used for signaling. REGISTER and OPTIONS are SIP methods, = and are defined in 3261. What else should we say???



On 5/1/07, Philip Matthews <philip_matthews@magma.ca> = wrote:

On 30-Apr-07, at = 15:49 , Medhavi Bhatia wrote:

Hi= Philip,

If I organize the tasks required to = become part of the P2P network in the following categories: =

Step1: Determine which admitting peer to connect to (bootstrap = server/multicast/static config)
Step2: Form a control connection with = the admitting peer (bootstrap server)
The way = things are currently defined in the Concepts draft, the bootstrap server = is logically distinct from the admitting peer.

Step3: Run the P2P protocol to = join the p2p network, register resources, query, exchange routes = etc.

I think the use of OPTIONS applies to step = 1.
If you use the Multicast = method.

= SIP/ICE or any connection establishment protocol which works over NATS = applies to steps 1 and 2.
Yup.

However registering myself as = a bootstrap peer seems to be part of = Step3.
Sure.

I assume that the bootstrap = server is part of the p2p network.
As currently = defined in the Concepts draft, the bootstrap server may or may not be = part of the P2P overlay.

I am just trying to put my head together on this one = now ;).
Try reading the Concepts draft and see = if this helps.


Medhavi.

On = 4/30/07, Philip Matthews < = philip_matthews@magma.ca> wrote:

On 30-Apr-07, = at 11:24 , Medhavi Bhatia wrote:

> Hi Philip,
>
> = NAT Traversal brings a lot of complexity to a P2P network. I = think
> we need to carefully identify what we are doing for = traversing NAT
> from what we need to get the P2P to work itself. = I think if we keep
> in mind that another offer-answer protocol = (other than SIP) can be
> used with ICE to set up control = connections as well then things are
> easier to analyze at = least.

NAT traversal is complex. Unfortunately, it also seems = integral to
P2PSIP. What we do NOT want to do is to repeat the=A0=A0SI= P experience
and design a P2PSIP system and then try to=A0=A0add NAT = Traversal as an
afterthought.

>
> The bootstrap = server seems to have two roles. It helps location of
> a = bootstrap peer (P2P part) as well as act as a rendezvous point
> = for establishing a control connection to it (NAT Traversal part). =
> The functionality provided by SIP OPTIONS and REGISTER = (mainly
> location of the bootstrap peer) seems to be related to = P2P part. So
> I think the draft seems to have over specified = since it is
> discussing the use of SIP to do that.

I = agree that that the bootstrap server does a number of things. =
However, I don't see the distinction that you seem to be = suggesting.
Can you explain further?

- = Philip



=



= --Apple-Mail-6-26749159-- --===============1959433850== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1959433850==-- From p2psip-bounces@ietf.org Tue May 01 16:20:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiyq7-00010z-Hv; Tue, 01 May 2007 16:20:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiyq6-0000kA-1g for p2psip@ietf.org; Tue, 01 May 2007 16:20:46 -0400 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hiyq5-0003nR-Jm for p2psip@ietf.org; Tue, 01 May 2007 16:20:46 -0400 Received: by nz-out-0506.google.com with SMTP id z6so2530797nzd for ; Tue, 01 May 2007 13:20:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=UvyY+4ww+D6hISinL0nOexlsKMwPw3BIdbulJ1AKqwJv0g3JyQqJ8KuA7W2n4qcAWV5fb7RX6TODIrIPlqLhNNxOjxHvHPi5R4lGLhXmP8phjwBvp6g+aWd1NtqCpH9nugUZMEGOqGgncdjDRJkNQTw4IkVxUJU0QrWwZ1b0ghQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=hAXgWA3wK9kUT5wi7GrjUXNq07RWwk/RgKlfNFZPw8XzePtaYe91ehBahNNQ4S6+wNBKUaALp3sz8Hejzh193oo3yvLCx7PYbacoUe0fSJ1AGGduwWsifnJLPxukAgENLM4aT05jUpXQHmunvuvUE94vhJeX2wQjGY9oay2rxFs= Received: by 10.115.111.1 with SMTP id o1mr2517476wam.1178050844502; Tue, 01 May 2007 13:20:44 -0700 (PDT) Received: by 10.114.120.9 with HTTP; Tue, 1 May 2007 13:20:44 -0700 (PDT) Message-ID: <894e079b0705011320y5ef9a3a2uba6161c99f80c25d@mail.gmail.com> Date: Tue, 1 May 2007 16:20:44 -0400 From: "Medhavi Bhatia" To: "Philip Matthews" Subject: Re: [P2PSIP] Comments on draft draft-matthews-p2psip-bootstrap-mechanisms-00 In-Reply-To: <2F1AC9FE-D8D8-4210-97FD-D04D80FEF5DA@magma.ca> MIME-Version: 1.0 References: <894e079b0704261659t66b77385j4614cd8b40c5ba22@mail.gmail.com> <894e079b0704292027s4921ed69g3d68e5803c08229b@mail.gmail.com> <3084061F-5C99-44E1-9A83-D8DB464F1BEA@magma.ca> <894e079b0704300824q515f14bdv5347e0d9dbda96ab@mail.gmail.com> <783A4A1F-3A23-4BDE-A9BE-77149AEC5597@magma.ca> <894e079b0704301249g3c538639o4d088fd104e11b7e@mail.gmail.com> <894e079b0705011250g182869bp8bcc2941ac42255f@mail.gmail.com> <2F1AC9FE-D8D8-4210-97FD-D04D80FEF5DA@magma.ca> X-Google-Sender-Auth: 5aac33a24aeec15e X-Spam-Score: 1.2 (+) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1454511178==" Errors-To: p2psip-bounces@ietf.org --===============1454511178== Content-Type: multipart/alternative; boundary="----=_Part_46922_4580412.1178050844433" ------=_Part_46922_4580412.1178050844433 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline > > > The draft clearly states that SIP is used for signaling. REGISTER and > OPTIONS are SIP methods, and are defined in 3261. What else should we say??? > I think the draft creates a requirement for the p2p nodes to implement SIP REGISTER and OPTIONS (which didn't exist previously). One suggestion is to allow alternate protocols to do the same and focus on this draft more on the process/method of bootstrapping and joining a p2p network (what the title and abstract suggest). On 5/1/07, Philip Matthews wrote: > > > > > > On 30-Apr-07, at 15:49 , Medhavi Bhatia wrote: > > > > Hi Philip, > > > > If I organize the tasks required to become part of the P2P network in > > the following categories: > > > > Step1: Determine which admitting peer to connect to (bootstrap > > server/multicast/static config) > > Step2: Form a control connection with the admitting peer (bootstrap > > server) > > > > The way things are currently defined in the Concepts draft, the > > bootstrap server is logically distinct from the admitting peer. > > > > Step3: Run the P2P protocol to join the p2p network, register resources, > > query, exchange routes etc. > > > > I think the use of OPTIONS applies to step 1. > > > > If you use the Multicast method. > > > > SIP/ICE or any connection establishment protocol which works over NATS > > applies to steps 1 and 2. > > > > Yup. > > > > However registering myself as a bootstrap peer seems to be part of > > Step3. > > > > Sure. > > > > I assume that the bootstrap server is part of the p2p network. > > > > As currently defined in the Concepts draft, the bootstrap server may or > > may not be part of the P2P overlay. > > > > > > I am just trying to put my head together on this one now ;). > > > > Try reading the Concepts draft and see if this helps. > > > > > > Medhavi. > > > > On 4/30/07, Philip Matthews < philip_matthews@magma.ca> wrote: > > > > > > > > > On 30-Apr-07, at 11:24 , Medhavi Bhatia wrote: > > > > > > > Hi Philip, > > > > > > > > NAT Traversal brings a lot of complexity to a P2P network. I think > > > > we need to carefully identify what we are doing for traversing NAT > > > > from what we need to get the P2P to work itself. I think if we keep > > > > in mind that another offer-answer protocol (other than SIP) can be > > > > used with ICE to set up control connections as well then things are > > > > easier to analyze at least. > > > > > > NAT traversal is complex. Unfortunately, it also seems integral to > > > P2PSIP. What we do NOT want to do is to repeat the SIP experience > > > and design a P2PSIP system and then try to add NAT Traversal as an > > > afterthought. > > > > > > > > > > > The bootstrap server seems to have two roles. It helps location of > > > > a bootstrap peer (P2P part) as well as act as a rendezvous point > > > > for establishing a control connection to it (NAT Traversal part). > > > > The functionality provided by SIP OPTIONS and REGISTER (mainly > > > > location of the bootstrap peer) seems to be related to P2P part. So > > > > I think the draft seems to have over specified since it is > > > > discussing the use of SIP to do that. > > > > > > I agree that that the bootstrap server does a number of things. > > > However, I don't see the distinction that you seem to be suggesting. > > > Can you explain further? > > > > > > - Philip > > > > > > > > > > > > > > > > > > ------=_Part_46922_4580412.1178050844433 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

The draft clearly states that SIP is used for signaling. REGISTER and OPTIONS are SIP methods, and are defined in 3261. What else should we say???

I think the draft creates a requirement for the p2p nodes to implement SIP REGISTER and OPTIONS (which didn't exist previously). One suggestion is to allow alternate protocols to do the same and focus on this draft more on the process/method of bootstrapping and joining a p2p network (what the title and abstract suggest).

On 5/1/07, Philip Matthews <philip_matthews@magma.ca > wrote:

On 30-Apr-07, at 15:49 , Medhavi Bhatia wrote:

Hi Philip,

If I organize the tasks required to become part of the P2P network in the following categories:

Step1: Determine which admitting peer to connect to (bootstrap server/multicast/static config)
Step2: Form a control connection with the admitting peer (bootstrap server)
The way things are currently defined in the Concepts draft, the bootstrap server is logically distinct from the admitting peer.

Step3: Run the P2P protocol to join the p2p network, register resources, query, exchange routes etc.

I think the use of OPTIONS applies to step 1.
 If you use the Multicast method.

SIP/ICE or any connection establishment protocol which works over NATS applies to steps 1 and 2.
Yup.

However registering myself as a bootstrap peer seems to be part of Step3.
Sure.

I assume that the bootstrap server is part of the p2p network.
As currently defined in the Concepts draft, the bootstrap server may or may not be part of the P2P overlay.

I am just trying to put my head together on this one now ;).
Try reading the Concepts draft and see if this helps.


Medhavi.

On 4/30/07, Philip Matthews < philip_matthews@magma.ca> wrote:

On 30-Apr-07, at 11:24 , Medhavi Bhatia wrote:

> Hi Philip,
>
> NAT Traversal brings a lot of complexity to a P2P network. I think
> we need to carefully identify what we are doing for traversing NAT
> from what we need to get the P2P to work itself. I think if we keep
> in mind that another offer-answer protocol (other than SIP) can be
> used with ICE to set up control connections as well then things are
> easier to analyze at least.

NAT traversal is complex. Unfortunately, it also seems integral to
P2PSIP. What we do NOT want to do is to repeat the  SIP experience
and design a P2PSIP system and then try to  add NAT Traversal as an
afterthought.

>
> The bootstrap server seems to have two roles. It helps location of
> a bootstrap peer (P2P part) as well as act as a rendezvous point
> for establishing a control connection to it (NAT Traversal part).
> The functionality provided by SIP OPTIONS and REGISTER (mainly
> location of the bootstrap peer) seems to be related to P2P part. So
> I think the draft seems to have over specified since it is
> discussing the use of SIP to do that.

I agree that that the bootstrap server does a number of things.
However, I don't see the distinction that you seem to be suggesting.
Can you explain further?

- Philip








------=_Part_46922_4580412.1178050844433-- --===============1454511178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1454511178==-- From p2psip-bounces@ietf.org Thu May 03 09:29:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjbMj-0002BO-0t; Thu, 03 May 2007 09:29:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjbMh-0002BJ-50 for p2psip@ietf.org; Thu, 03 May 2007 09:28:59 -0400 Received: from nz-out-0506.google.com ([64.233.162.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjbMf-0001Td-Ux for p2psip@ietf.org; Thu, 03 May 2007 09:28:59 -0400 Received: by nz-out-0506.google.com with SMTP id z6so564441nzd for ; Thu, 03 May 2007 06:28:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=MGpjw0TOJ6FZzvJ3cN9YucIPKKxC0yXQHEvGPsdthNI3wad2q2ov04wXOJfqSOBACgpqIuWFgfWWZd6GsPdiW1LwHVuYgW6T1Z6V8c6B0DUhExXesOXvaHzcb3Qg5xxP5KVpNLkO7zFeIDKS5GyEC4Ab4Et1u9VW+9Ib4AAmb04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=Z/DYT2eXILBOqTpUkX/n6tA7BvJlYwHHRWPYuvkCS066YG5HaqRoUa6FEyls4/avtctJW+d4mT8dZCXuymbaIbtIWQeYj+pSYjaIQ7GgVpNl/6mppbtBle1wnW7BDYqVTM+RG8E5ZbBjK5kW2KlZA7d5EDR5uUwGPzGr/BhwS6A= Received: by 10.114.81.1 with SMTP id e1mr657084wab.1178198936865; Thu, 03 May 2007 06:28:56 -0700 (PDT) Received: by 10.114.120.9 with HTTP; Thu, 3 May 2007 06:28:56 -0700 (PDT) Message-ID: <894e079b0705030628o37f6cdbcn108b1827d15ae00a@mail.gmail.com> Date: Thu, 3 May 2007 08:28:56 -0500 From: "Medhavi Bhatia" To: p2psip@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: f7baa64bf81937b3 X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [P2PSIP] Question on draft-baset-p2psip-p2pcommon X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0640944125==" Errors-To: p2psip-bounces@ietf.org --===============0640944125== Content-Type: multipart/alternative; boundary="----=_Part_25451_31357699.1178198936579" ------=_Part_25451_31357699.1178198936579 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline It seems to me that the protocol described in this draft could run on the same connection where SIP, STUN/TURN/ICE packets are also being processed. There is no mention in the draft accomodating this and probably the byte encoding specified for P2PP may interfere with the multiplexing of packets. Is this an issue? Medhavi. ------=_Part_25451_31357699.1178198936579 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
It seems to me that the protocol described in this draft could run on the same connection where SIP, STUN/TURN/ICE packets are also being processed. There is no mention in the draft accomodating this and probably the byte encoding specified for P2PP may interfere with the multiplexing of packets. Is this an issue?
 
Medhavi.
------=_Part_25451_31357699.1178198936579-- --===============0640944125== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0640944125==-- From p2psip-bounces@ietf.org Thu May 03 12:36:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjeID-0007Pe-Iq; Thu, 03 May 2007 12:36:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjeIC-0007PZ-6Z for p2psip@ietf.org; Thu, 03 May 2007 12:36:32 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjeIA-0001Zu-08 for p2psip@ietf.org; Thu, 03 May 2007 12:36:32 -0400 Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.21.100]) (user=sa2086 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l43GaJgo008161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 May 2007 12:36:24 -0400 (EDT) Date: Thu, 3 May 2007 12:36:19 -0400 (EDT) From: Salman Abdul Baset To: Medhavi Bhatia Subject: Re: [P2PSIP] Question on draft-baset-p2psip-p2pcommon In-Reply-To: <894e079b0705030628o37f6cdbcn108b1827d15ae00a@mail.gmail.com> Message-ID: References: <894e079b0705030628o37f6cdbcn108b1827d15ae00a@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org It is an issue and it needs to be specified in the draft. The techniques will be similar to what have been specified in sipoutbound and STUN drafts. The STUN draft provides a magic cookie in the common header (bytes 5-8). P2PP can check for the presence of magic cookie. I think there is a need to specify a 'magic cookie' for P2PP so that other protocols can differentiate it. -salman On Thu, 3 May 2007, Medhavi Bhatia wrote: > It seems to me that the protocol described in this draft could run on the > same connection where SIP, STUN/TURN/ICE packets are also being processed. > There is no mention in the draft accomodating this and probably the byte > encoding specified for P2PP may interfere with the multiplexing of packets. > Is this an issue? > > Medhavi. > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu May 03 12:53:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjeYj-0003kL-CE; Thu, 03 May 2007 12:53:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjeYh-0003kF-VT for p2psip@ietf.org; Thu, 03 May 2007 12:53:35 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjeYg-0005a8-Mv for p2psip@ietf.org; Thu, 03 May 2007 12:53:35 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.43) id 1HjeYg-00080Z-Km; Thu, 03 May 2007 12:53:34 -0400 In-Reply-To: <894e079b0705011320y5ef9a3a2uba6161c99f80c25d@mail.gmail.com> References: <894e079b0704261659t66b77385j4614cd8b40c5ba22@mail.gmail.com> <894e079b0704292027s4921ed69g3d68e5803c08229b@mail.gmail.com> <3084061F-5C99-44E1-9A83-D8DB464F1BEA@magma.ca> <894e079b0704300824q515f14bdv5347e0d9dbda96ab@mail.gmail.com> <783A4A1F-3A23-4BDE-A9BE-77149AEC5597@magma.ca> <894e079b0704301249g3c538639o4d088fd104e11b7e@mail.gmail.com> <894e079b0705011250g182869bp8bcc2941ac42255f@mail.gmail.com> <2F1AC9FE-D8D8-4210-97FD-D04D80FEF5DA@magma.ca> <894e079b0705011320y5ef9a3a2uba6161c99f80c25d@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Comments on draft draft-matthews-p2psip-bootstrap-mechanisms-00 Date: Thu, 3 May 2007 12:53:34 -0400 To: Medhavi Bhatia X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 1.2 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 1-May-07, at 16:20 , Medhavi Bhatia wrote: >> The draft clearly states that SIP is used for signaling. REGISTER >> and OPTIONS are SIP methods, and are defined in 3261. What else >> should we say??? > I think the draft creates a requirement for the p2p nodes to > implement SIP REGISTER and OPTIONS (which didn't exist previously). > One suggestion is to allow alternate protocols to do the same and > focus on this draft more on the process/method of bootstrapping and > joining a p2p network (what the title and abstract suggest). > Well .... I agree that the initial discussion around this draft should focus around the general approach to bootstrapping, before concentrating on the details. However, the point of this draft was to give all the details for one way of doing bootstrapping, because we have found that having details is usually necessary before people will think about the general case. If the working group decides to stick with SIP as the protocol for signaling Peer Protocol connections, then I think the draft describes a very good way of doing this. There are some minor details that could be changed, but I think most of the details would stay the same. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu May 03 15:07:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjgeO-00049V-8G; Thu, 03 May 2007 15:07:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjgeN-00049K-1V for p2psip@ietf.org; Thu, 03 May 2007 15:07:35 -0400 Received: from nz-out-0506.google.com ([64.233.162.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjgeL-0001Zr-P3 for p2psip@ietf.org; Thu, 03 May 2007 15:07:35 -0400 Received: by nz-out-0506.google.com with SMTP id z6so696596nzd for ; Thu, 03 May 2007 12:07:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Plk5GKNUUvICZ8nhC0bfLOKbO3nVGnb8/+0NS+iD5jhXgw6qCb/fQq6iGweZtj4ZRhCKDBwAn45kzqzx16j/y5eDlgozvoonYKO0famm+TkFDD3JlagGLCW+7oBJ3BZ7qq7O4071tJMoPbxHoOnhIOAH//Q4DZssJQH6cQRMye4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=I0aI8lLopMKfwnc2raMlWeBJqfLdt4W601Yh+mJR3DpxhMwG9y+WwHZ3Kia1MoOPK9+eqh+AH4lf+4UR9+bBGJDMZ5W62DZUwJwfTDII3c6H2tlc42WdVbBiFwRlhDHKl+ge7VQaSoea+M/ce2VSZGILznf4HBvgrpdU4cUCvKI= Received: by 10.114.94.1 with SMTP id r1mr799501wab.1178219253020; Thu, 03 May 2007 12:07:33 -0700 (PDT) Received: by 10.114.120.9 with HTTP; Thu, 3 May 2007 12:07:32 -0700 (PDT) Message-ID: <894e079b0705031207r12adeed1hc0190dd61cff31d0@mail.gmail.com> Date: Thu, 3 May 2007 15:07:32 -0400 From: "Medhavi Bhatia" To: "Salman Abdul Baset" Subject: Re: [P2PSIP] Question on draft-baset-p2psip-p2pcommon In-Reply-To: MIME-Version: 1.0 References: <894e079b0705030628o37f6cdbcn108b1827d15ae00a@mail.gmail.com> X-Google-Sender-Auth: 1a78338c68e4954d X-Spam-Score: 0.5 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2125319219==" Errors-To: p2psip-bounces@ietf.org --===============2125319219== Content-Type: multipart/alternative; boundary="----=_Part_30836_11091704.1178219252973" ------=_Part_30836_11091704.1178219252973 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Salman, I think that sounds great. What items are we planning for the next rev of the draft. From an implementation standpoint, has anyone implemented this draft yet? The 'magic cookie' approach is frankly unavoidable for a usable implementation since I don't know how you escape the NAT traversal (SIP/ICE) issues otherwise. Medhavi. On 5/3/07, Salman Abdul Baset wrote: > > It is an issue and it needs to be specified in the draft. The techniques > will be similar to what have been specified in sipoutbound and STUN > drafts. > > The STUN draft provides a magic cookie in the common header (bytes 5-8). > P2PP can check for the presence of magic cookie. > > I think there is a need to specify a 'magic cookie' for P2PP so that other > protocols can differentiate it. > > -salman > > > On Thu, 3 May 2007, Medhavi Bhatia wrote: > > > It seems to me that the protocol described in this draft could run on > the > > same connection where SIP, STUN/TURN/ICE packets are also being > processed. > > There is no mention in the draft accomodating this and probably the byte > > encoding specified for P2PP may interfere with the multiplexing of > packets. > > Is this an issue? > > > > Medhavi. > > > ------=_Part_30836_11091704.1178219252973 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Salman,

I think that sounds great. What items are we planning for the next rev of the draft. From an implementation standpoint, has anyone implemented this draft yet? The 'magic cookie' approach is frankly unavoidable for a usable implementation since I don't know how you escape the NAT traversal (SIP/ICE) issues otherwise.

Medhavi.

On 5/3/07, Salman Abdul Baset <salman@cs.columbia.edu> wrote:
It is an issue and it needs to be specified in the draft. The techniques
will be similar to what have been specified in sipoutbound and STUN
drafts.

The STUN draft provides a magic cookie in the common header (bytes 5-8).
P2PP can check for the presence of magic cookie.

I think there is a need to specify a 'magic cookie' for P2PP so that other
protocols can differentiate it.

-salman


On Thu, 3 May 2007, Medhavi Bhatia wrote:

> It seems to me that the protocol described in this draft could run on the
> same connection where SIP, STUN/TURN/ICE packets are also being processed.
> There is no mention in the draft accomodating this and probably the byte
> encoding specified for P2PP may interfere with the multiplexing of packets.
> Is this an issue?
>
> Medhavi.
>

------=_Part_30836_11091704.1178219252973-- --===============2125319219== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2125319219==-- From p2psip-bounces@ietf.org Thu May 03 15:28:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjgym-0004fX-EA; Thu, 03 May 2007 15:28:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjgyk-0004fR-8H for p2psip@ietf.org; Thu, 03 May 2007 15:28:38 -0400 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjgyi-000437-Sg for p2psip@ietf.org; Thu, 03 May 2007 15:28:38 -0400 Received: by wr-out-0506.google.com with SMTP id 71so649408wri for ; Thu, 03 May 2007 12:28:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=WW3fBm7TV6Nc/sBCYreJk8b2UskpgwskgxAHyz+CrN5ryjtz/EYeKLeY8zQ4/NZ1oAd32IcwEunZpADbqLBLXmbM1GXxRvjjshTpr47Go9314eVdZl0f4te9OwjIJpjy3Y7PG1LN5GHosqoC2U+M3GbgCcHbSVePWJN7dynEjkQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=RNXhFLUcBUc9z+6LB4wvDdwW1oIf2h1Jl7cY7ChPrlqQvGkY+YFuMxnxutcrajti0dCD/B3Wp18Lb9MbG3BBasA+ULh8Mke0/abnjpN2BxdSJJLtquT3ooD+Dqm+zV9yZENl1hk7Q5FFOoSgvrItHWy9+9iqMzmQl7koCX7fML4= Received: by 10.114.147.1 with SMTP id u1mr812460wad.1178220515871; Thu, 03 May 2007 12:28:35 -0700 (PDT) Received: by 10.114.120.9 with HTTP; Thu, 3 May 2007 12:28:35 -0700 (PDT) Message-ID: <894e079b0705031228pa6c7ebl267394bbba97118b@mail.gmail.com> Date: Thu, 3 May 2007 15:28:35 -0400 From: "Medhavi Bhatia" To: "Philip Matthews" Subject: Re: [P2PSIP] Comments on draft draft-matthews-p2psip-bootstrap-mechanisms-00 In-Reply-To: MIME-Version: 1.0 References: <894e079b0704261659t66b77385j4614cd8b40c5ba22@mail.gmail.com> <3084061F-5C99-44E1-9A83-D8DB464F1BEA@magma.ca> <894e079b0704300824q515f14bdv5347e0d9dbda96ab@mail.gmail.com> <783A4A1F-3A23-4BDE-A9BE-77149AEC5597@magma.ca> <894e079b0704301249g3c538639o4d088fd104e11b7e@mail.gmail.com> <894e079b0705011250g182869bp8bcc2941ac42255f@mail.gmail.com> <2F1AC9FE-D8D8-4210-97FD-D04D80FEF5DA@magma.ca> <894e079b0705011320y5ef9a3a2uba6161c99f80c25d@mail.gmail.com> X-Google-Sender-Auth: 2e8d3a46439e3f20 X-Spam-Score: 1.4 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0739939863==" Errors-To: p2psip-bounces@ietf.org --===============0739939863== Content-Type: multipart/alternative; boundary="----=_Part_31285_6573238.1178220515816" ------=_Part_31285_6573238.1178220515816 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Philip, I think some of the content in this draft provides a very good foundation and it also provides a good starting point. It is much better if we separate mechanism out from the details since it can help nail down some additional requirements for the P2P protocol. For example, if someone wants to use the mechanisms in the draft for a P2P gaming protocol, they would know what additional things to implement in the gaming protocol. One of the mechanisms used by the draft is SIP/Replaces approach. To me that seems excessive specification again. I don't know why we need SIP on the new P2P connection (besides that it may work if the control connection doesn't get terminated by the BYE) and what benefits it brings to the table except complexity. I think the choice is between three things here: extend SIP for P2P, let SIP and P2PP ride on the same connection (like this draft's approach) or devise some new mechanism to refresh the connection on which P2PP rides. I think in all of these cases the bootstrapping mechanism is still the same... On 5/3/07, Philip Matthews wrote: > > > On 1-May-07, at 16:20 , Medhavi Bhatia wrote: > > >> The draft clearly states that SIP is used for signaling. REGISTER > >> and OPTIONS are SIP methods, and are defined in 3261. What else > >> should we say??? > > > I think the draft creates a requirement for the p2p nodes to > > implement SIP REGISTER and OPTIONS (which didn't exist previously). > > One suggestion is to allow alternate protocols to do the same and > > focus on this draft more on the process/method of bootstrapping and > > joining a p2p network (what the title and abstract suggest). > > > > Well .... I agree that the initial discussion around this draft > should focus around the general approach to bootstrapping, before > concentrating on the details. > > However, the point of this draft was to give all the details for one > way of doing bootstrapping, because we have found that having details > is usually necessary before people will think about the general case. > > If the working group decides to stick with SIP as the protocol for > signaling Peer Protocol connections, then I think the draft describes > a very good way of doing this. There are some minor details that > could be changed, but I think most of the details would stay the same. > > - Philip > ------=_Part_31285_6573238.1178220515816 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Philip,

I think some of the content in this draft provides a very good foundation and it also provides a good starting point. It is much better if we separate mechanism out from the details since it can help nail down some additional requirements for the P2P protocol.

For example, if someone wants to use the mechanisms in the draft for a P2P gaming protocol, they would know what additional things to implement in the gaming protocol.

One of the mechanisms used by the draft is SIP/Replaces approach. To me that seems excessive specification again. I don't know why we need SIP on the new P2P connection (besides that it may work if the control connection doesn't get terminated by the BYE) and what benefits it brings to the table except complexity.

I think the choice is between three things here: extend SIP for P2P, let SIP and P2PP ride on the same connection (like this draft's approach) or devise some new mechanism to refresh the connection on which P2PP rides.

I think in all of these cases the bootstrapping mechanism is still the same...

On 5/3/07, Philip Matthews < philip_matthews@magma.ca> wrote:

On 1-May-07, at 16:20 , Medhavi Bhatia wrote:

>> The draft clearly states that SIP is used for signaling. REGISTER
>> and OPTIONS are SIP methods, and are defined in 3261. What else
>> should we say???

> I think the draft creates a requirement for the p2p nodes to
> implement SIP REGISTER and OPTIONS (which didn't exist previously).
> One suggestion is to allow alternate protocols to do the same and
> focus on this draft more on the process/method of bootstrapping and
> joining a p2p network (what the title and abstract suggest).
>

Well .... I agree that the initial discussion around this draft
should focus around the general approach to bootstrapping, before
concentrating on the details.

However, the point of this draft was to give all the details for one
way of doing bootstrapping, because we have found that having details
is usually necessary before people will think about the general case.

If the working group decides to stick with SIP as the protocol for
signaling Peer Protocol connections, then I think the draft describes
a very good way of doing this. There are some minor details that
could be changed, but I think most of the details would stay the same.

- Philip

------=_Part_31285_6573238.1178220515816-- --===============0739939863== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0739939863==-- From p2psip-bounces@ietf.org Thu May 03 16:34:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hji0E-0001x9-Je; Thu, 03 May 2007 16:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hji0D-0001x3-Gm for p2psip@ietf.org; Thu, 03 May 2007 16:34:13 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hji0C-0005P7-AB for p2psip@ietf.org; Thu, 03 May 2007 16:34:13 -0400 Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.21.100]) (user=sa2086 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l43KY4Bw003658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 May 2007 16:34:07 -0400 (EDT) Date: Thu, 3 May 2007 16:34:04 -0400 (EDT) From: Salman Abdul Baset To: Medhavi Bhatia Subject: Re: [P2PSIP] Question on draft-baset-p2psip-p2pcommon In-Reply-To: <894e079b0705031207r12adeed1hc0190dd61cff31d0@mail.gmail.com> Message-ID: References: <894e079b0705030628o37f6cdbcn108b1827d15ae00a@mail.gmail.com> <894e079b0705031207r12adeed1hc0190dd61cff31d0@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We have a basic implementation for Kademlia and another one in progress for Chord. Both Kademlia and Chord are implemented using P2PP. NAT traversal issues, churn recovery, replication and integration with SIP are some of the issues that need to be addressed/further clarified in the next revision. -s On Thu, 3 May 2007, Medhavi Bhatia wrote: > Hi Salman, > > I think that sounds great. What items are we planning for the next rev of > the draft. From an implementation standpoint, has anyone implemented this > draft yet? The 'magic cookie' approach is frankly unavoidable for a usable > implementation since I don't know how you escape the NAT traversal (SIP/ICE) > issues otherwise. > > Medhavi. > > On 5/3/07, Salman Abdul Baset wrote: > > > > It is an issue and it needs to be specified in the draft. The techniques > > will be similar to what have been specified in sipoutbound and STUN > > drafts. > > > > The STUN draft provides a magic cookie in the common header (bytes 5-8). > > P2PP can check for the presence of magic cookie. > > > > I think there is a need to specify a 'magic cookie' for P2PP so that other > > protocols can differentiate it. > > > > -salman > > > > > > On Thu, 3 May 2007, Medhavi Bhatia wrote: > > > > > It seems to me that the protocol described in this draft could run on > > the > > > same connection where SIP, STUN/TURN/ICE packets are also being > > processed. > > > There is no mention in the draft accomodating this and probably the byte > > > encoding specified for P2PP may interfere with the multiplexing of > > packets. > > > Is this an issue? > > > > > > Medhavi. > > > > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu May 03 16:42:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hji8g-0002CA-Hy; Thu, 03 May 2007 16:42:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hji7N-0001LB-2O for p2psip@ietf.org; Thu, 03 May 2007 16:41:37 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hji3B-0005ho-M1 for p2psip@ietf.org; Thu, 03 May 2007 16:37:18 -0400 Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.21.100]) (user=sa2086 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l43KbCbr004395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 May 2007 16:37:12 -0400 (EDT) Date: Thu, 3 May 2007 16:37:12 -0400 (EDT) From: Salman Abdul Baset To: Medhavi Bhatia Subject: Re: [P2PSIP] Question on draft-baset-p2psip-p2pcommon In-Reply-To: <894e079b0705031207r12adeed1hc0190dd61cff31d0@mail.gmail.com> Message-ID: References: <894e079b0705030628o37f6cdbcn108b1827d15ae00a@mail.gmail.com> <894e079b0705031207r12adeed1hc0190dd61cff31d0@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We have a basic implementation for Kademlia and another one in progress for Chord. Both Kademlia and Chord are implemented using P2PP. NAT traversal issues, churn recovery, replication and integration with SIP are some of the issues that need to be addressed/further clarified in the next revision. -s On Thu, 3 May 2007, Medhavi Bhatia wrote: > Hi Salman, > > I think that sounds great. What items are we planning for the next rev of > the draft. From an implementation standpoint, has anyone implemented this > draft yet? The 'magic cookie' approach is frankly unavoidable for a usable > implementation since I don't know how you escape the NAT traversal (SIP/ICE) > issues otherwise. > > Medhavi. > > On 5/3/07, Salman Abdul Baset wrote: > > > > It is an issue and it needs to be specified in the draft. The techniques > > will be similar to what have been specified in sipoutbound and STUN > > drafts. > > > > The STUN draft provides a magic cookie in the common header (bytes 5-8). > > P2PP can check for the presence of magic cookie. > > > > I think there is a need to specify a 'magic cookie' for P2PP so that other > > protocols can differentiate it. > > > > -salman > > > > > > On Thu, 3 May 2007, Medhavi Bhatia wrote: > > > > > It seems to me that the protocol described in this draft could run on > > the > > > same connection where SIP, STUN/TURN/ICE packets are also being > > processed. > > > There is no mention in the draft accomodating this and probably the byte > > > encoding specified for P2PP may interfere with the multiplexing of > > packets. > > > Is this an issue? > > > > > > Medhavi. > > > > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu May 03 16:53:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjiIU-0006pH-U0; Thu, 03 May 2007 16:53:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjiIS-0006oT-U2 for p2psip@ietf.org; Thu, 03 May 2007 16:53:04 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjiIR-0007lr-LR for p2psip@ietf.org; Thu, 03 May 2007 16:53:04 -0400 Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.21.100]) (user=sa2086 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l43Kr0cc026474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 May 2007 16:53:00 -0400 (EDT) Date: Thu, 3 May 2007 16:53:00 -0400 (EDT) From: Salman Abdul Baset To: Medhavi Bhatia Subject: Re: [P2PSIP] Question on draft-baset-p2psip-p2pcommon Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We have a basic implementation for Kademlia and another one in progress for Chord. Both Kademlia and Chord are implemented using P2PP. NAT traversal issues, churn recovery, replication and integration with SIP are some of the issues that need to be addressed/further clarified in the next revision. -s On Thu, 3 May 2007, Medhavi Bhatia wrote: > Hi Salman, > > I think that sounds great. What items are we planning for the next rev of > the draft. From an implementation standpoint, has anyone implemented this > draft yet? The 'magic cookie' approach is frankly unavoidable for a usable > implementation since I don't know how you escape the NAT traversal (SIP/ICE) > issues otherwise. > > Medhavi. > > On 5/3/07, Salman Abdul Baset wrote: > > > > It is an issue and it needs to be specified in the draft. The techniques > > will be similar to what have been specified in sipoutbound and STUN > > drafts. > > > > The STUN draft provides a magic cookie in the common header (bytes 5-8). > > P2PP can check for the presence of magic cookie. > > > > I think there is a need to specify a 'magic cookie' for P2PP so that other > > protocols can differentiate it. > > > > -salman > > > > > > On Thu, 3 May 2007, Medhavi Bhatia wrote: > > > > > It seems to me that the protocol described in this draft could run on > > the > > > same connection where SIP, STUN/TURN/ICE packets are also being > > processed. > > > There is no mention in the draft accomodating this and probably the byte > > > encoding specified for P2PP may interfere with the multiplexing of > > packets. > > > Is this an issue? > > > > > > Medhavi. > > > > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon May 07 09:54:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl3fs-0007io-DB; Mon, 07 May 2007 09:54:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl3fq-0007id-Di for p2psip@ietf.org; Mon, 07 May 2007 09:54:47 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl3fp-0004nf-1U for p2psip@ietf.org; Mon, 07 May 2007 09:54:46 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Mon, 7 May 2007 15:54:36 +0200 Received: from S4DE9JSAAIG.ost.t-com.de ([10.125.177.192]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 15:54:35 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 7 May 2007 15:54:36 +0200 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB789@S4DE9JSAAIG.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: more draft-baset-p2psip-p2pcommon-01 questions Thread-Index: AceQr2/gwy9jt9TESbavJmyjjlGkzA== From: "Beck01, Wolfgang" To: X-OriginalArrivalTime: 07 May 2007 13:54:35.0479 (UTC) FILETIME=[3F0C3670:01C790AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: p2psip@ietf.org Subject: [P2PSIP] more draft-baset-p2psip-p2pcommon-01 questions X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org some observations on the draft: TLV structure It is not quite clear from the text if TLV objects (eg Peer-ID)are = nested. I guess they are, but it should mentioned somewhere. 7.3.1.1 Address-Info This object describes a single ip-address/port pair. Why does it contain = a number of gathered 4-tuples of address, port, transport, address type? Can this = object appear more than once? Where's the transport field? Maybe this is clear to somebody who knows his ICE, but some = clarifications would be helpful. 7.3.3 P2P-Options This object carries an overlayID-len field. Isn't this redundant? Wolfgang Beck -- T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert = Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*, Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon May 07 19:14:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlCPD-0001fZ-LZ; Mon, 07 May 2007 19:14:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlCPC-0001fT-SZ for p2psip@ietf.org; Mon, 07 May 2007 19:14:10 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlCP8-00032a-Iz for p2psip@ietf.org; Mon, 07 May 2007 19:14:10 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.43) id 1HlCP7-0000vm-LX; Mon, 07 May 2007 19:14:06 -0400 In-Reply-To: <894e079b0705031228pa6c7ebl267394bbba97118b@mail.gmail.com> References: <894e079b0704261659t66b77385j4614cd8b40c5ba22@mail.gmail.com> <3084061F-5C99-44E1-9A83-D8DB464F1BEA@magma.ca> <894e079b0704300824q515f14bdv5347e0d9dbda96ab@mail.gmail.com> <783A4A1F-3A23-4BDE-A9BE-77149AEC5597@magma.ca> <894e079b0704301249g3c538639o4d088fd104e11b7e@mail.gmail.com> <894e079b0705011250g182869bp8bcc2941ac42255f@mail.gmail.com> <2F1AC9FE-D8D8-4210-97FD-D04D80FEF5DA@magma.ca> <894e079b0705011320y5ef9a3a2uba6161c99f80c25d@mail.gmail.com> <894e079b0705031228pa6c7ebl267394bbba97118b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7FFC9793-9CFB-4B5A-903C-8995312251D1@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Comments on draft draft-matthews-p2psip-bootstrap-mechanisms-00 Date: Mon, 7 May 2007 19:13:57 -0400 To: Medhavi Bhatia X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 1.2 (+) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 3-May-07, at 15:28 , Medhavi Bhatia wrote: > Hi Philip, > > I think some of the content in this draft provides a very good > foundation and it also provides a good starting point. It is much > better if we separate mechanism out from the details since it can > help nail down some additional requirements for the P2P protocol. I agree that it would be nice to have a high-level discussion of the mechanisms before delving into the details. To start that off, I will note that four bootstrap mechanisms are listed in the Concepts draft, and draft-matthews-p2psip-bootstrap-mechanisms-00 describes how to implement two of them using SIP. (The other two are also implementable -- we only had time to work out the details for two of them). We decided to use SIP as the signaling protocol in the draft because SIP is an existing protocol that allows the signaling and data channels to take different paths -- this property is used heavily in this draft and personally I don't see how to get around it. > > For example, if someone wants to use the mechanisms in the draft > for a P2P gaming protocol, they would know what additional things > to implement in the gaming protocol. > > One of the mechanisms used by the draft is SIP/Replaces approach. > To me that seems excessive specification again. I don't know why we > need SIP on the new P2P connection (besides that it may work if the > control connection doesn't get terminated by the BYE) and what > benefits it brings to the table except complexity. First, a minor point -- the draft uses "mechanism" in a very specific way, so let's call the SIP/Replaces approach a "technique". Second, I claim we need this SIP/Replaces technique, for otherwise the connection would go down if the bootstrap peer left the overlay. Third, though it is not described in this draft, it turns out that there are other good reasons to want to run the signaling protocol (SIP in this case) on the same connection as the peer protocol -- take a look at draft-matthews-dsip-nat-traversal-00. This draft shows how to leverage the joining peer's connection to the admitting peer into a network of connections. > > I think the choice is between three things here: extend SIP for > P2P, let SIP and P2PP ride on the same connection (like this > draft's approach) or devise some new mechanism to refresh the > connection on which P2PP rides. I don't understand your third choice. However, I see a fourth choice: Use something other than SIP as the signaling protocol. Part of the reason we wrote the draft was to show that the various pieces of the draft could be separated, so one could use, for example, SIP for one part and something else for a different part. > > I think in all of these cases the bootstrapping mechanism is still > the same... > You are right that the basic mechanisms could remain the same, assuming the signaling protocol allowed the signaling and data channels to take different paths. Please understand that we are happy to consider other ways of doing bootstrapping -- we just wanted to get a draft out that showed in detail how to make one way work. As I said before, once people see one way of doing things, ideas for other ways often come out. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue May 08 10:39:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlQqL-0007wY-Au; Tue, 08 May 2007 10:39:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlQqK-0007wR-3G for p2psip@ietf.org; Tue, 08 May 2007 10:39:08 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlQqH-0001q2-Q2 for p2psip@ietf.org; Tue, 08 May 2007 10:39:08 -0400 Received: from flame.cs.columbia.edu (flame.cs.columbia.edu [128.59.16.145]) (user=sa2086 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l48Ecwtx001849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 May 2007 10:39:01 -0400 (EDT) Date: Tue, 8 May 2007 10:38:58 -0400 (EDT) From: Salman Abdul Baset To: "Beck01, Wolfgang" In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F31BB789@S4DE9JSAAIG.ost.t-com.de> Message-ID: References: <1E4CCB2441C5C0409AD8A929482A09F31BB789@S4DE9JSAAIG.ost.t-com.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: p2psip@ietf.org Subject: [P2PSIP] Re: more draft-baset-p2psip-p2pcommon-01 questions X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Inline. > TLV structure > > It is not quite clear from the text if TLV objects (eg Peer-ID)are nested= =2E I guess they are, > but it should mentioned somewhere. Yes, it is indeed among the many clarifications marked for the next version. > 7.3.1.1 Address-Info > This object describes a single ip-address/port pair. Why does it contain = a number > of gathered 4-tuples of address, port, transport, address type? Can this = object > appear more than once? Where's the transport field? > > Maybe this is clear to somebody who knows his ICE, but some clarification= s would > be helpful. I agree that we should describe this in more detail. > 7.3.3 P2P-Options > This object carries an overlayID-len field. Isn't this redundant? > Overlay-ID is the only variable length field in P2P-Options so far, so in that sense you can say it is redundant. However, we still have not discounted the possibility of adding other (variable size) fields to P2P-Options and hence the length field for overlay-ID. Regards, Salman > Wolfgang Beck > > -- > T-Systems Enterprise Services GmbH > Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) > Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert = Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*, > Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* > Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 > Sitz der Gesellschaft: Frankfurt am Main > WEEE-Reg.-Nr. DE87523644 > *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed May 09 05:13:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HliEf-0002yE-1P; Wed, 09 May 2007 05:13:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HliEd-0002y7-CY for p2psip@ietf.org; Wed, 09 May 2007 05:13:23 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HliEb-0007GD-Vb for p2psip@ietf.org; Wed, 09 May 2007 05:13:23 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Wed, 9 May 2007 11:13:20 +0200 Received: from S4DE9JSAAIG.ost.t-com.de ([10.125.177.192]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 11:13:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [P2PSIP] Re: more draft-baset-p2psip-p2pcommon-01 questions Date: Wed, 9 May 2007 11:13:20 +0200 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB78A@S4DE9JSAAIG.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: more draft-baset-p2psip-p2pcommon-01 questions Thread-Index: AceRfsUhI2OgNgL8RNSB8rZzVSDjGgAjDrTw From: "Beck01, Wolfgang" To: X-OriginalArrivalTime: 09 May 2007 09:13:20.0311 (UTC) FILETIME=[497D6C70:01C7921A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > > 7.3.3 P2P-Options > > This object carries an overlayID-len field. Isn't this redundant? > > >=20 > Overlay-ID is the only variable length field in P2P-Options=20 > so far, so in that sense you can say it is redundant.=20 > However, we still have not discounted the possibility of=20 > adding other (variable size) fields to P2P-Options and hence=20 > the length field for overlay-ID. I see. The 'num entries' field in the Routing-Table and Neighbor-Table=20 objects is required for the same reason? I've an issue with the format of Peer-ID. The draft has this wording 'If the Algorithm-Len field queried at join is zero, a length field of 16 bits MUST be present before Peer-ID.' Is it really necessary to have two separate ways to express the algorithm-length; either at Join or later? Are there any P2P-Algorithms that don't know their Peer-ID length at the time of Join? We should really avoid all that accidental complexity that plagues SIP today. For the same reason UDP should be dropped. Thanks to the Common Header, TCP framing is easy. UDP doesn't relieve the client form maintaining session state, it just pushes the load to user space. In SIP, we ended up with cases where implementations have to switch from UDP to TCP. 7.4 The Error object usage is not clear. Where do I put the Error codes that are mentioned in 7.4.2? 8. API 'An application using peer-to-peer protocol issues non-blocking calls to P2PP layer to accomplish the following operations'. This needs some elaboration. How can an application decide when and how an operation has finished? Wolfgang -- T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert = Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*, Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed May 09 14:02:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlqUo-0000yF-R9; Wed, 09 May 2007 14:02:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlqUn-0000yA-Dc for p2psip@ietf.org; Wed, 09 May 2007 14:02:38 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlqUm-00066H-4j for p2psip@ietf.org; Wed, 09 May 2007 14:02:37 -0400 Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5]) (user=sa2086 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l49I2RXj009845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 May 2007 14:02:35 -0400 (EDT) Date: Wed, 9 May 2007 14:02:27 -0400 (EDT) From: Salman Abdul Baset To: "Beck01, Wolfgang" Subject: Re: [P2PSIP] Re: more draft-baset-p2psip-p2pcommon-01 questions In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F31BB78A@S4DE9JSAAIG.ost.t-com.de> Message-ID: References: <1E4CCB2441C5C0409AD8A929482A09F31BB78A@S4DE9JSAAIG.ost.t-com.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > I've an issue with the format of Peer-ID. The draft has this wording > 'If the Algorithm-Len field queried at join is zero, a length field > of 16 bits MUST be present before Peer-ID.' > > Is it really necessary to have two separate ways to express the > algorithm-length; either at Join or later? Are there any P2P-Algorithms > that don't know their Peer-ID length at the time of Join? We should > really avoid all that accidental complexity that plagues SIP today. This was done so that P2PP can potentially be used to implement an unstructured p2p protocol for which Peer-ID may not be of fixed length. The draft addresses one way to accomplish this. There are other approaches such as having a default Peer-ID for unstructured networks and use the 'Unhashed-ID' TLV object to convey the information. I agree that converying peer-IDs for unstructured networks require more consideration. > For the same reason UDP should be dropped. Thanks to the Common Header, > TCP framing is easy. UDP doesn't relieve the client form maintaining > session state, it just pushes the load to user space. In SIP, we ended > up with cases where implementations have to switch from UDP to TCP. I agree that UDP is an issue but consider the case of iterative routing, where the node issuing the query has control over the traversed nodes. It will be a performance hit for the node issuing the query to establish a TCP connection with every node in an iterative mode. > 7.4 > The Error object usage is not clear. Where do I put the Error codes > that are mentioned in 7.4.2? The error codes are essentially response codes and they should be put in the response common header. Sorry for the confusion. > 8. API > 'An application using peer-to-peer protocol issues non-blocking calls > to P2PP layer to accomplish the following operations'. This needs some > elaboration. How can an application decide when and how an operation > has finished? Indeed. The description should clearly say that there is a call-back function mechanism. This needs to be updated in the draft. > > Wolfgang > > -- > T-Systems Enterprise Services GmbH > Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) > Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert = Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*, > Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* > Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 > Sitz der Gesellschaft: Frankfurt am Main > WEEE-Reg.-Nr. DE87523644 > *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu May 10 02:15:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1vs-000123-7S; Thu, 10 May 2007 02:15:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1vq-00011v-Ud for p2psip@ietf.org; Thu, 10 May 2007 02:15:18 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm1vq-0000oB-6H for p2psip@ietf.org; Thu, 10 May 2007 02:15:18 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JHT00JQ6AOAA3@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 10 May 2007 14:14:34 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JHT00DSTAO9R4@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 10 May 2007 14:14:34 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JHT007ZCAO3YO@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 10 May 2007 14:14:33 +0800 (CST) Date: Thu, 10 May 2007 14:14:27 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Comments on draft-jiang-p2psip-peer-protocol-requirement-00 In-reply-to: <894e079b0704301836y678f4250t308d7af2517cf137@mail.gmail.com> To: 'Medhavi Bhatia' Message-id: <002201c792ca$76a9ff50$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceLkSKUSSwmbwlaT4e+N/saakhjVwHNiv7w X-Spam-Score: 1.1 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Sorry for delay response because of seven day's Labor Day holiday in China. Please see inline. ________________________________________ From: Medhavi Bhatia [mailto:mbhatia@3clogic.com] Sent: Tuesday, May 01, 2007 9:36 AM To: p2psip@ietf.org Subject: [P2PSIP] Comments on draft-jiang-p2psip-peer-protocol-requirement-00 It seems this draft is a little out of update and probably needs some re-organization as well. 1. First and foremost the draft needs to split requirements in more categories: requirements pertaining to operate the p2p network itself (join/leave/updates and other operations required for p2p network to work) should be separate from transport level. It seems that other drafts are talking about transport and control connections separate from the p2p protocol itself and the draft needs to lay down requirements for these separately from the p2p protocol. [JiangXingFeng] When I was writing this 00 draft, the criteria for organizing requirements in my mind is : requirements on P2P overlay maintenance and routing, including NAT traversal inherent in P2P communication are called basic requirements. On the other side, transport protocol is very important for P2PSIP, so I place it into the basic requirements. Some other requirements such as availability and efficiency which are necessary to upper applications are called advanced requirements. Maybe the further classification should be taken in the basic requirements. But at present, I don't see any convincing reasons to do this in requirement draft. 2. At the p2p protocol level, the requirements are very vague and say too little. In my understanding, they don't help much at this point to specifically serve as guidance when choosing SIP or a new protocol (comparing the bryan and henning drafts here). [JiangXingFeng] Yes, as a zero draft, it is relative rough. I will flesh it out in the coming revision. On the other side, it is hard to make some requirement more detailed than written in the draft. Any more detailed description will be considered as specific solution which will not in the scope of requirements and incur a lot of argument. 3. Security requirements for the p2p protocol don't exist. There is a section on security, but I am not sure it is giving any requirements for the p2p protocol or the control connection protocol or transport. [JiangXingFeng] In the 00 draft, I only list some problems and threats in P2P security, not present specific requirement. Next revision will address it. 4. Diagnostics collection is quite important, more so since there is no management. I think requirements should be there for this as well since diagnostics should be built into the protocol as well to test if it is working properly. [JiangXingFeng] good suggestion, I will consider it in the next revision. Medhavi. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu May 10 04:01:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm3aC-0006Z7-7L; Thu, 10 May 2007 04:01:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm3aA-0006Yx-T3 for p2psip@ietf.org; Thu, 10 May 2007 04:01:02 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm3a9-0008Lf-Du for p2psip@ietf.org; Thu, 10 May 2007 04:01:02 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Thu, 10 May 2007 10:00:59 +0200 Received: from S4DE9JSAAIG.ost.t-com.de ([10.125.177.192]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 10:00:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [P2PSIP] Re: more draft-baset-p2psip-p2pcommon-01 questions Date: Thu, 10 May 2007 10:00:58 +0200 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB78B@S4DE9JSAAIG.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: more draft-baset-p2psip-p2pcommon-01 questions Thread-Index: AceSZEGrlM+A529JQH+nDenknlZnigAcBVhg From: "Beck01, Wolfgang" To: X-OriginalArrivalTime: 10 May 2007 08:00:58.0848 (UTC) FILETIME=[58307E00:01C792D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > > Is it really necessary to have two separate ways to express the > > algorithm-length; either at Join or later? Are there any=20 > > P2P-Algorithms that don't know their Peer-ID length at the time of=20 > > Join? We should really avoid all that accidental complexity that=20 > > plagues SIP today. >=20 > This was done so that P2PP can potentially be used to=20 > implement an unstructured p2p protocol for which Peer-ID may=20 > not be of fixed length. OK, this makes sense. Can we put a statement into the draft, like "For P2P algorithms with a fixed-length Peer-ID, the field Algorithm-Length of the P2P-Options object MUST contain that length. For P2P algorithms with a variable-length Peer-ID, the field Algorithm-Length of the P2P-Options object MUST be 0 and the Peer-ID MUST have the format | 16 bit length | ID |."? So, if my implementation only supports a p2p algorithm with fixed-length peer-id, I don't need handle two formats of Peer-ID. > > [first charge in the inevitable UDP/TCP battle] > I agree that UDP is an issue but consider the case of=20 > iterative routing, where the node issuing the query has=20 > control over the traversed nodes. It will be a performance=20 > hit for the node issuing the query to establish a TCP=20 > connection with every node in an iterative mode. I am concerned about implementation complexity. TCP is a highly optimized part of the OS. With UDP, you have to implement your own retransmission and message segmentation mechanisms (413 Message too large) or switch to TCP, combining the worst of both worlds. The only advantage of UDP is, that it gives you better control over timeouts in case the remote party doesn't answer at all. Perhaps this should be a per P2P algorithm decision, in a table like (just illustrative) Algorithm | Peer-ID variable? | iterative=20 Alfachord n UDP Betakademlia n TCP Gammabamboo y n=20 .. This would limit the number of options an implementation of a certain P2P-Algorithm has to support. > > 7.4 > > The Error object usage is not clear. Where do I put the Error codes=20 > > that are mentioned in 7.4.2? >=20 > The error codes are essentially response codes and they=20 > should be put in the response common header. Sorry for the confusion. Oops, I overlooked the response code in that header. Wolfgang -- T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert = Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*, Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu May 10 10:05:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9Ge-0003If-BQ; Thu, 10 May 2007 10:05:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9Gd-0003IS-4a for p2psip@ietf.org; Thu, 10 May 2007 10:05:15 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hm9Gb-0005V6-7Z for p2psip@ietf.org; Thu, 10 May 2007 10:05:15 -0400 Received: from source ([192.150.20.142]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Thu, 10 May 2007 07:05:07 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l4AE52Sd015221; Thu, 10 May 2007 07:05:06 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l4AE4x0g027545; Thu, 10 May 2007 07:05:01 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 07:04:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] Comments on draft-jiang-p2psip-peer-protocol-requirement-00 Date: Thu, 10 May 2007 07:04:43 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D228087FA@namail5.corp.adobe.com> In-Reply-To: <894e079b0704301836y678f4250t308d7af2517cf137@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Comments on draft-jiang-p2psip-peer-protocol-requirement-00 Thread-Index: AceLkSHeA8rbv5LbTligMMyTZlxkgAHeifsg References: <894e079b0704301836y678f4250t308d7af2517cf137@mail.gmail.com> From: "Henry Sinnreich" To: "Medhavi Bhatia" , X-OriginalArrivalTime: 10 May 2007 14:04:59.0291 (UTC) FILETIME=[321B9EB0:01C7930C] X-Spam-Score: 1.1 (+) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0962973682==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0962973682== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7930C.31D1E452" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7930C.31D1E452 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Medhavi Bahtia wrote: =20 >4. Diagnostics collection is quite important, more so since there is no management. > I think requirements should be there for this as well since diagnostics should be built into the=20 >protocol as well to test if it is working properly. =20 This is an interesting point and I sympathize with it, since the serious, experimental P2P R&D has shown plenty of tools to assess performance, such as those published for the openDHT.=20 (I must confess my bias: Any P2P proposal not based on measured performance is worthless). =20 Can you elaborate with any suggestion or references? =20 Thanks, Henry =20 ________________________________ From: Medhavi Bhatia [mailto:mbhatia@3clogic.com]=20 Sent: Monday, April 30, 2007 8:36 PM To: p2psip@ietf.org Subject: [P2PSIP] Comments on draft-jiang-p2psip-peer-protocol-requirement-00 =20 It seems this draft is a little out of update and probably needs some re-organization as well. 1. First and foremost the draft needs to split requirements in more categories: requirements pertaining to operate the p2p network itself (join/leave/updates and other operations required for p2p network to work) should be separate from transport level. It seems that other drafts are talking about transport and control connections separate from the p2p protocol itself and the draft needs to lay down requirements for these separately from the p2p protocol.=20 2. At the p2p protocol level, the requirements are very vague and say too little. In my understanding, they don't help much at this point to specifically serve as guidance when choosing SIP or a new protocol (comparing the bryan and henning drafts here).=20 3. Security requirements for the p2p protocol don't exist. There is a section on security, but I am not sure it is giving any requirements for the p2p protocol or the control connection protocol or transport.=20 4. Diagnostics collection is quite important, more so since there is no management. I think requirements should be there for this as well since diagnostics should be built into the protocol as well to test if it is working properly.=20 Medhavi. ------_=_NextPart_001_01C7930C.31D1E452 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Medhavi Bahtia = wrote:

 

>4. Diagnostics collection is quite important, more so since = there is no management.

> I think requirements should be there for this as well since diagnostics should be built into the

>protocol as well to test if it is working = properly.

 

This is an interesting point and I sympathize with it, since the serious, experimental P2P R&D has shown plenty of tools to assess performance, such as those published for the openDHT. =

(I must confess my bias: Any P2P proposal not based on measured = performance is worthless).

 

Can you elaborate with any suggestion or = references?

 

Thanks, Henry

 

From: = Medhavi Bhatia [mailto:mbhatia@3clogic.com]
Sent: Monday, April 30, = 2007 8:36 PM
To: = p2psip@ietf.org
Subject: [P2PSIP] = Comments on draft-jiang-p2psip-peer-protocol-requirement-00<= /p>

 

It seems this = draft is a little out of update and probably needs some re-organization as well.

1. First and foremost the draft needs to split requirements in more = categories: requirements pertaining to operate the p2p network itself = (join/leave/updates and other operations required for p2p network to work) should be = separate from transport level. It seems that other drafts are talking about transport = and control connections separate from the p2p protocol itself and the draft = needs to lay down requirements for these separately from the p2p protocol. =

2. At the p2p protocol level, the requirements are very vague and say = too little. In my understanding, they don't help much at this point to = specifically serve as guidance when choosing SIP or a new protocol (comparing the = bryan and = henning drafts here).

3. Security requirements for the p2p protocol don't exist. There is a = section on security, but I am not sure it is giving any requirements for the p2p protocol or the control connection protocol or transport.

4. Diagnostics collection is quite important, more so since there is no management. I think requirements should be there for this as well since diagnostics should be built into the protocol as well to test if it is = working properly.

Medhavi.

------_=_NextPart_001_01C7930C.31D1E452-- --===============0962973682== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0962973682==-- From p2psip-bounces@ietf.org Fri May 11 17:05:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmcIo-0002Rb-Vd; Fri, 11 May 2007 17:05:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmcIn-0002Pm-5T for p2psip@ietf.org; Fri, 11 May 2007 17:05:25 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmcId-0001um-EN for p2psip@ietf.org; Fri, 11 May 2007 17:05:24 -0400 Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.21.100]) (user=sa2086 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l4BL59OK011154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 May 2007 17:05:09 -0400 (EDT) Date: Fri, 11 May 2007 17:05:09 -0400 (EDT) From: Salman Abdul Baset To: "Beck01, Wolfgang" Subject: Re: AW: [P2PSIP] Re: more draft-baset-p2psip-p2pcommon-01 questions In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F31BB78B@S4DE9JSAAIG.ost.t-com.de> Message-ID: References: <1E4CCB2441C5C0409AD8A929482A09F31BB78B@S4DE9JSAAIG.ost.t-com.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > > This was done so that P2PP can potentially be used to > > implement an unstructured p2p protocol for which Peer-ID may > > not be of fixed length. > OK, this makes sense. Can we put a statement into the draft, like > "For P2P algorithms with a fixed-length Peer-ID, the field > Algorithm-Length of the P2P-Options object MUST contain that length. > For P2P algorithms with a variable-length Peer-ID, the field > Algorithm-Length of the P2P-Options object MUST be 0 and the Peer-ID > MUST have the format | 16 bit length | ID |."? I will add the statement further clarifying this. > > So, if my implementation only supports a p2p algorithm > with fixed-length peer-id, I don't need handle two formats of > Peer-ID. Yes, if your implementation only supports fixed-length Peer-ID, you do not need to handle two formats of Peer-ID. > The only advantage of UDP is, that it gives you better control > over timeouts in case the remote party doesn't answer at all. > > Perhaps this should be a per P2P algorithm decision, in a table > like (just illustrative) > > Algorithm | Peer-ID variable? | iterative > Alfachord n UDP > Betakademlia n TCP > Gammabamboo y n > .. The choice of iterative vs. recursive routing is independent of the DHT algorithm being used. I agree that a table will help clearly state the issues of DHT-specific and DHT-independent mechanisms. > This would limit the number of options an implementation of a certain > P2P-Algorithm has to support. > > > > > > 7.4 > > > The Error object usage is not clear. Where do I put the Error codes > > > that are mentioned in 7.4.2? > > > > The error codes are essentially response codes and they > > should be put in the response common header. Sorry for the confusion. > Oops, I overlooked the response code in that header. > > > Wolfgang > -- > T-Systems Enterprise Services GmbH > Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) > Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert = Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*, > Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* > Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 > Sitz der Gesellschaft: Frankfurt am Main > WEEE-Reg.-Nr. DE87523644 > *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun May 13 23:54:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnRdZ-0005fS-M6; Sun, 13 May 2007 23:54:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnRdY-0005f6-TQ for p2psip@ietf.org; Sun, 13 May 2007 23:54:16 -0400 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnRdY-0001z6-IB for p2psip@ietf.org; Sun, 13 May 2007 23:54:16 -0400 Received: by nz-out-0506.google.com with SMTP id z6so1801242nzd for ; Sun, 13 May 2007 20:54:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=E+rxZCpum+j4PB7tnB4R8p1ppM0et5HuBnLMjUB39mlZMtUEggabjmTHNfNKkUGtAPWlhGXRyZls/JhRIYOmN68Xinl8xjDp+BKW7R2wiv8dG+YAdpmbnyn0zV4+uSsFxhdcXs68KqG970PvNiwEtnsS0Nj5e5x6c7Mgm4bY63A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=HxumQlGPQvqxemU21OIZZPJ8mNCtHV2reUTHdINmG5dmHxXy4MBkeQx/kYo1Uo7mGEVwePFAHGlk9LLIodETXETTHfWgIr0GseLT1cBoqti2DEP9ohJcqGFzcDeduWv4xbZtg4RNokB2GB0Lvhyb/U8/dexcFTqF2UIBDRHQMPc= Received: by 10.114.157.1 with SMTP id f1mr810592wae.1179114855880; Sun, 13 May 2007 20:54:15 -0700 (PDT) Received: by 10.114.120.9 with HTTP; Sun, 13 May 2007 20:54:15 -0700 (PDT) Message-ID: <894e079b0705132054g1b6daafcm4103e2a9fd5265b1@mail.gmail.com> Date: Sun, 13 May 2007 23:54:15 -0400 From: "Medhavi Bhatia" To: "Salman Abdul Baset" Subject: Re: [P2PSIP] Question on draft-baset-p2psip-p2pcommon In-Reply-To: MIME-Version: 1.0 References: <894e079b0705030628o37f6cdbcn108b1827d15ae00a@mail.gmail.com> <894e079b0705031207r12adeed1hc0190dd61cff31d0@mail.gmail.com> X-Google-Sender-Auth: dddc0fcaedb1b65e X-Spam-Score: 0.5 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0538390610==" Errors-To: p2psip-bounces@ietf.org --===============0538390610== Content-Type: multipart/alternative; boundary="----=_Part_150881_14815735.1179114855407" ------=_Part_150881_14815735.1179114855407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Salman, Regarding NAT Traversal, I couldn't see how the lookup handles the scenario of the looked up resource accepting connections only on one of its established connections in the p2p network (ie., through peers it is connected to because of NAT issues). I may have glossed over something. Any idea? Medhavi. On 5/3/07, Salman Abdul Baset wrote: > > We have a basic implementation for Kademlia and another one in progress > for Chord. Both Kademlia and Chord are implemented using P2PP. > > NAT traversal issues, churn recovery, replication and integration with SIP > are some of the issues that need to be addressed/further clarified in the > next revision. > -s > > On Thu, 3 May 2007, Medhavi Bhatia wrote: > > > Hi Salman, > > > > I think that sounds great. What items are we planning for the next rev > of > > the draft. From an implementation standpoint, has anyone implemented > this > > draft yet? The 'magic cookie' approach is frankly unavoidable for a > usable > > implementation since I don't know how you escape the NAT traversal > (SIP/ICE) > > issues otherwise. > > > > Medhavi. > > > > On 5/3/07, Salman Abdul Baset wrote: > > > > > > It is an issue and it needs to be specified in the draft. The > techniques > > > will be similar to what have been specified in sipoutbound and STUN > > > drafts. > > > > > > The STUN draft provides a magic cookie in the common header (bytes > 5-8). > > > P2PP can check for the presence of magic cookie. > > > > > > I think there is a need to specify a 'magic cookie' for P2PP so that > other > > > protocols can differentiate it. > > > > > > -salman > > > > > > > > > On Thu, 3 May 2007, Medhavi Bhatia wrote: > > > > > > > It seems to me that the protocol described in this draft could run > on > > > the > > > > same connection where SIP, STUN/TURN/ICE packets are also being > > > processed. > > > > There is no mention in the draft accomodating this and probably the > byte > > > > encoding specified for P2PP may interfere with the multiplexing of > > > packets. > > > > Is this an issue? > > > > > > > > Medhavi. > > > > > > > > > > ------=_Part_150881_14815735.1179114855407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Salman,

Regarding NAT Traversal, I couldn't see how the lookup handles the scenario of the looked up resource accepting connections only on one of its established connections in the p2p network (ie., through peers it is connected to because of NAT issues). I may have glossed over something. Any idea?

Medhavi.

On 5/3/07, Salman Abdul Baset <salman@cs.columbia.edu> wrote:
We have a basic implementation for Kademlia and another one in progress
for Chord. Both Kademlia and Chord are implemented using P2PP.

NAT traversal issues, churn recovery, replication and integration with SIP
are some of the issues that need to be addressed/further clarified in the
next revision.
-s

On Thu, 3 May 2007, Medhavi Bhatia wrote:

> Hi Salman,
>
> I think that sounds great. What items are we planning for the next rev of
> the draft. From an implementation standpoint, has anyone implemented this
> draft yet? The 'magic cookie' approach is frankly unavoidable for a usable
> implementation since I don't know how you escape the NAT traversal (SIP/ICE)
> issues otherwise.
>
> Medhavi.
>
> On 5/3/07, Salman Abdul Baset <salman@cs.columbia.edu> wrote:
> >
> > It is an issue and it needs to be specified in the draft. The techniques
> > will be similar to what have been specified in sipoutbound and STUN
> > drafts.
> >
> > The STUN draft provides a magic cookie in the common header (bytes 5-8).
> > P2PP can check for the presence of magic cookie.
> >
> > I think there is a need to specify a 'magic cookie' for P2PP so that other
> > protocols can differentiate it.
> >
> > -salman
> >
> >
> > On Thu, 3 May 2007, Medhavi Bhatia wrote:
> >
> > > It seems to me that the protocol described in this draft could run on
> > the
> > > same connection where SIP, STUN/TURN/ICE packets are also being
> > processed.
> > > There is no mention in the draft accomodating this and probably the byte
> > > encoding specified for P2PP may interfere with the multiplexing of
> > packets.
> > > Is this an issue?
> > >
> > > Medhavi.
> > >
> >
>

------=_Part_150881_14815735.1179114855407-- --===============0538390610== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0538390610==-- From p2psip-bounces@ietf.org Mon May 14 22:56:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnnD2-0000We-8e; Mon, 14 May 2007 22:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnnD0-0000W3-Lz for p2psip@ietf.org; Mon, 14 May 2007 22:56:18 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnnCz-0005lk-Dx for p2psip@ietf.org; Mon, 14 May 2007 22:56:18 -0400 Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.21.100]) (user=sa2086 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l4F2uBBB024526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 May 2007 22:56:12 -0400 (EDT) Date: Mon, 14 May 2007 22:56:11 -0400 (EDT) From: Salman Abdul Baset To: Medhavi Bhatia Subject: Re: [P2PSIP] Question on draft-baset-p2psip-p2pcommon In-Reply-To: <894e079b0705132054g1b6daafcm4103e2a9fd5265b1@mail.gmail.com> Message-ID: References: <894e079b0705030628o37f6cdbcn108b1827d15ae00a@mail.gmail.com> <894e079b0705031207r12adeed1hc0190dd61cff31d0@mail.gmail.com> <894e079b0705132054g1b6daafcm4103e2a9fd5265b1@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org You mean connection reuse for peers? It is not explicitly mentioned in the draft but peers should reuse existing connections to send the request. -salman On Sun, 13 May 2007, Medhavi Bhatia wrote: > Hi Salman, > > Regarding NAT Traversal, I couldn't see how the lookup handles the scenario > of the looked up resource accepting connections only on one of its > established connections in the p2p network (ie., through peers it is > connected to because of NAT issues). I may have glossed over something. Any > idea? > > Medhavi. > > On 5/3/07, Salman Abdul Baset wrote: > > > > We have a basic implementation for Kademlia and another one in progress > > for Chord. Both Kademlia and Chord are implemented using P2PP. > > > > NAT traversal issues, churn recovery, replication and integration with SIP > > are some of the issues that need to be addressed/further clarified in the > > next revision. > > -s > > > > On Thu, 3 May 2007, Medhavi Bhatia wrote: > > > > > Hi Salman, > > > > > > I think that sounds great. What items are we planning for the next rev > > of > > > the draft. From an implementation standpoint, has anyone implemented > > this > > > draft yet? The 'magic cookie' approach is frankly unavoidable for a > > usable > > > implementation since I don't know how you escape the NAT traversal > > (SIP/ICE) > > > issues otherwise. > > > > > > Medhavi. > > > > > > On 5/3/07, Salman Abdul Baset wrote: > > > > > > > > It is an issue and it needs to be specified in the draft. The > > techniques > > > > will be similar to what have been specified in sipoutbound and STUN > > > > drafts. > > > > > > > > The STUN draft provides a magic cookie in the common header (bytes > > 5-8). > > > > P2PP can check for the presence of magic cookie. > > > > > > > > I think there is a need to specify a 'magic cookie' for P2PP so that > > other > > > > protocols can differentiate it. > > > > > > > > -salman > > > > > > > > > > > > On Thu, 3 May 2007, Medhavi Bhatia wrote: > > > > > > > > > It seems to me that the protocol described in this draft could run > > on > > > > the > > > > > same connection where SIP, STUN/TURN/ICE packets are also being > > > > processed. > > > > > There is no mention in the draft accomodating this and probably the > > byte > > > > > encoding specified for P2PP may interfere with the multiplexing of > > > > packets. > > > > > Is this an issue? > > > > > > > > > > Medhavi. > > > > > > > > > > > > > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon May 14 23:15:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnnVz-00039f-UR; Mon, 14 May 2007 23:15:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnnVz-00039X-21 for p2psip@ietf.org; Mon, 14 May 2007 23:15:55 -0400 Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnnVw-0001on-KD for p2psip@ietf.org; Mon, 14 May 2007 23:15:55 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1896352wri for ; Mon, 14 May 2007 20:15:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=CnaKLuHUpx2THkA3Fs14kQEWV/7MQOTFFn05Fpj5G2MngHLdGFM3j/EUn4lN79u248SVrkmzrrOJc+1piKRgv1TVRvnBuWys3M56V0sK9TfboXTaAAYy8DoG47FaI27XFUopkwpu6w48wQix9dHey6HYLTaGHc6PNIW6Ovk0lBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=egNtJnFd4nLwxaJgH8kZc9ZExz8fEnndGgiMk4yRp1bQfKZlA1E+tPrUBkN3UmaU2WRZBgOzAfMB+blynbXwEH4Bzpc7br6PQNJOkzkUXTGGJYb6iSdheKMjDUsZdzXiY/Lw94bN9cXEuOANFDakd92NsBff3sw9+9oIobstXH4= Received: by 10.114.181.1 with SMTP id d1mr1321568waf.1179198951616; Mon, 14 May 2007 20:15:51 -0700 (PDT) Received: by 10.114.120.9 with HTTP; Mon, 14 May 2007 20:15:51 -0700 (PDT) Message-ID: <894e079b0705142015q100056f7p38d74fffb72434f2@mail.gmail.com> Date: Mon, 14 May 2007 23:15:51 -0400 From: "Medhavi Bhatia" To: "Salman Abdul Baset" Subject: Re: [P2PSIP] Question on draft-baset-p2psip-p2pcommon In-Reply-To: MIME-Version: 1.0 References: <894e079b0705030628o37f6cdbcn108b1827d15ae00a@mail.gmail.com> <894e079b0705031207r12adeed1hc0190dd61cff31d0@mail.gmail.com> <894e079b0705132054g1b6daafcm4103e2a9fd5265b1@mail.gmail.com> X-Google-Sender-Auth: 1d522d694dc73a0a X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1621249817==" Errors-To: p2psip-bounces@ietf.org --===============1621249817== Content-Type: multipart/alternative; boundary="----=_Part_167142_3712760.1179198951555" ------=_Part_167142_3712760.1179198951555 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I think connection re-use should cover that as long as connections are shared for multiple protocols as and when possible (p2p, sip etc). Basically to establish a SIP session between a source and destination there would be a p2p lookup followed by a SIP message sent through a rendezvous server to one of the directly connected peers of the destination ( I assume this is how it works). On 5/14/07, Salman Abdul Baset wrote: > You mean connection reuse for peers? It is not explicitly mentioned in the > draft but peers should reuse existing connections to send the request. > -salman > > On Sun, 13 May 2007, Medhavi Bhatia wrote: > > > Hi Salman, > > > > Regarding NAT Traversal, I couldn't see how the lookup handles the > scenario > > of the looked up resource accepting connections only on one of its > > established connections in the p2p network (ie., through peers it is > > connected to because of NAT issues). I may have glossed over something. > Any > > idea? > > > > Medhavi. > > > > On 5/3/07, Salman Abdul Baset wrote: > > > > > > We have a basic implementation for Kademlia and another one in > progress > > > for Chord. Both Kademlia and Chord are implemented using P2PP. > > > > > > NAT traversal issues, churn recovery, replication and integration with > SIP > > > are some of the issues that need to be addressed/further clarified in > the > > > next revision. > > > -s > > > > > > On Thu, 3 May 2007, Medhavi Bhatia wrote: > > > > > > > Hi Salman, > > > > > > > > I think that sounds great. What items are we planning for the next > rev > > > of > > > > the draft. From an implementation standpoint, has anyone implemented > > > this > > > > draft yet? The 'magic cookie' approach is frankly unavoidable for a > > > usable > > > > implementation since I don't know how you escape the NAT traversal > > > (SIP/ICE) > > > > issues otherwise. > > > > > > > > Medhavi. > > > > > > > > On 5/3/07, Salman Abdul Baset wrote: > > > > > > > > > > It is an issue and it needs to be specified in the draft. The > > > techniques > > > > > will be similar to what have been specified in sipoutbound and > STUN > > > > > drafts. > > > > > > > > > > The STUN draft provides a magic cookie in the common header (bytes > > > 5-8). > > > > > P2PP can check for the presence of magic cookie. > > > > > > > > > > I think there is a need to specify a 'magic cookie' for P2PP so > that > > > other > > > > > protocols can differentiate it. > > > > > > > > > > -salman > > > > > > > > > > > > > > > On Thu, 3 May 2007, Medhavi Bhatia wrote: > > > > > > > > > > > It seems to me that the protocol described in this draft could > run > > > on > > > > > the > > > > > > same connection where SIP, STUN/TURN/ICE packets are also being > > > > > processed. > > > > > > There is no mention in the draft accomodating this and probably > the > > > byte > > > > > > encoding specified for P2PP may interfere with the multiplexing > of > > > > > packets. > > > > > > Is this an issue? > > > > > > > > > > > > Medhavi. > > > > > > > > > > > > > > > > > > > > > ------=_Part_167142_3712760.1179198951555 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

I think connection re-use should cover that as long as connections are shared for multiple protocols as and when possible (p2p, sip etc). Basically to establish a SIP session between a source and destination there would be a p2p lookup followed by a SIP message sent through a rendezvous server to one of the directly connected peers of the destination ( I assume this is how it works).

On 5/14/07, Salman Abdul Baset <salman@cs.columbia.edu> wrote:
You mean connection reuse for peers? It is not explicitly mentioned in the
draft but peers should reuse existing connections to send the request.
-salman

On Sun, 13 May 2007, Medhavi Bhatia wrote:

> Hi Salman,
>
> Regarding NAT Traversal, I couldn't see how the lookup handles the scenario
> of the looked up resource accepting connections only on one of its
> established connections in the p2p network (ie., through peers it is
> connected to because of NAT issues). I may have glossed over something. Any
> idea?
>
> Medhavi.
>
> On 5/3/07, Salman Abdul Baset < salman@cs.columbia.edu> wrote:
> >
> > We have a basic implementation for Kademlia and another one in progress
> > for Chord. Both Kademlia and Chord are implemented using P2PP.
> >
> > NAT traversal issues, churn recovery, replication and integration with SIP
> > are some of the issues that need to be addressed/further clarified in the
> > next revision.
> > -s
> >
> > On Thu, 3 May 2007, Medhavi Bhatia wrote:
> >
> > > Hi Salman,
> > >
> > > I think that sounds great. What items are we planning for the next rev
> > of
> > > the draft. From an implementation standpoint, has anyone implemented
> > this
> > > draft yet? The 'magic cookie' approach is frankly unavoidable for a
> > usable
> > > implementation since I don't know how you escape the NAT traversal
> > (SIP/ICE)
> > > issues otherwise.
> > >
> > > Medhavi.
> > >
> > > On 5/3/07, Salman Abdul Baset < salman@cs.columbia.edu> wrote:
> > > >
> > > > It is an issue and it needs to be specified in the draft. The
> > techniques
> > > > will be similar to what have been specified in sipoutbound and STUN
> > > > drafts.
> > > >
> > > > The STUN draft provides a magic cookie in the common header (bytes
> > 5-8).
> > > > P2PP can check for the presence of magic cookie.
> > > >
> > > > I think there is a need to specify a 'magic cookie' for P2PP so that
> > other
> > > > protocols can differentiate it.
> > > >
> > > > -salman
> > > >
> > > >
> > > > On Thu, 3 May 2007, Medhavi Bhatia wrote:
> > > >
> > > > > It seems to me that the protocol described in this draft could run
> > on
> > > > the
> > > > > same connection where SIP, STUN/TURN/ICE packets are also being
> > > > processed.
> > > > > There is no mention in the draft accomodating this and probably the
> > byte
> > > > > encoding specified for P2PP may interfere with the multiplexing of
> > > > packets.
> > > > > Is this an issue?
> > > > >
> > > > > Medhavi.
> > > > >
> > > >
> > >
> >
>

------=_Part_167142_3712760.1179198951555-- --===============1621249817== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1621249817==-- From p2psip-bounces@ietf.org Tue May 15 04:20:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnsHA-0002Vd-Ds; Tue, 15 May 2007 04:20:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnsH9-0002VY-Jp for p2psip@ietf.org; Tue, 15 May 2007 04:20:55 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnsH9-00023C-AS for p2psip@ietf.org; Tue, 15 May 2007 04:20:55 -0400 Received: from lion.cs.columbia.edu (IDENT:wGAMhmVng+A+J69BdSxx7kZ1jnKyyQU8@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l4F8KtTY009208 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 15 May 2007 04:20:55 -0400 (EDT) Received: from [192.168.0.100] (pool-71-183-32-102.nycmny.fios.verizon.net [71.183.32.102]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id l4F8KnsA027560 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 15 May 2007 04:20:54 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: p2psip@ietf.org From: Jae Woo Lee Date: Tue, 15 May 2007 04:20:48 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [P2PSIP] Draft revision on SIP UA discovery using Zeroconf X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, We have revised the draft on distributing SIP URIs within a LAN using DNS-SD (aka Zeroconf or "Apple Bonjour"). This is FYI only, as the topic is outside the core charter of the WG, but individual feedback is appreciated. This revision incorporates the feedback on the initial version we received through the mailing lists and in the IETF 68. The list of changes from the previous version and the link to the IETF slides are included below. Title : SIP URI Service Discovery using DNS-SD Author(s) : J. Lee, H. Schulzrinne, W. Kellerer, Z. Despotovic Filename : draft-lee-sip-dns-sd-uri-01.txt Pages : 22 Date : 2007-5-14 This document describes the Session Initiation Protocol Uniform Resource Identifier (SIP URI) advertisement for DNS-based Service Discovery (DNS-SD). Using this mechanism, a SIP user agent (UA) can communicate with another UA even when no SIP registrar is available, as in a wireless ad-hoc network for example. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-sip-dns-sd-uri-01.txt The slides from the IETF 68 can be found at: http://www3.ietf.org/proceedings/07mar/slides/sip-11.pdf CHANGES from version 00 ------------------------ * Expanded "Security Considerations" (section 9) * New "Other Related Mechanisms" (section 7) - Comparison to SIP multicast - "sip" service type used by Asterisk and Ekiga - P2PSIP * Changes in the "User Agent Client Behavior" - Request-URI set from the contact attribute (section 5.1) - RFC3263 not followed in resolving host names (section 5.2) * New "DNS-SD/mDNS Overview" (section 3) * References to the Contact header parsing rules (section 4.2.3) _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue May 15 21:50:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho8el-0001yv-Sr; Tue, 15 May 2007 21:50:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho8ek-0001yn-Sf for p2psip@ietf.org; Tue, 15 May 2007 21:50:23 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho8ei-000711-Su for p2psip@ietf.org; Tue, 15 May 2007 21:50:22 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JI400HFL2EPCH@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 16 May 2007 09:49:37 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JI400EOK2EN8C@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 16 May 2007 09:49:37 +0800 (CST) Received: from Y57503 ([10.164.5.78]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JI4009T32EKLD@szxml03-in.huawei.com> for p2psip@ietf.org; Wed, 16 May 2007 09:49:35 +0800 (CST) Date: Wed, 16 May 2007 09:49:34 +0800 From: Jie Yang To: marcin.matuszewski@nokia.com Message-id: <000801c7975c$743404a0$4e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AceXXHPexHQA91uuR+yYwZx+di4IkQ== X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b555a13c938d1b600d10fbe16e3be8e Cc: p2psip@ietf.org Subject: [P2PSIP] comments on draft-matuszewski-p2psip-security-requirements-00.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2106916090==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============2106916090== Content-type: multipart/alternative; boundary="Boundary_(ID_cqGke9BveBCto6YUXAwuSQ)" This is a multi-part message in MIME format. --Boundary_(ID_cqGke9BveBCto6YUXAwuSQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT hi, Matuszewski: I'm very interested in your draft and found it included most of the requirements on security. Furthermore, I found some other requirements. Users may be most care about the availability of the resources on the overlay. So do the overlay operators. But unfortunately, attacker can deny the existence of resources it was responsible for. This kind of attacks can be referred as "deny of responsibility" attacks and these will compromise the availability of resource. Maybe this issue should be addressed by distributed database algorithm. However, it has some relations with security. So my suggestion is whether we add the requirements of resource availability and "deny of responsibility" attacks to your draft or not. --Boundary_(ID_cqGke9BveBCto6YUXAwuSQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

hi, Matuszewski:

 

I'm very interested in your draft and found it included most of the requirements on security. Furthermore, I found some other requirements.

Users may be most care about the availability of the resources on the overlay. So do the overlay operators.

But unfortunately, attacker can deny the existence of resources it was responsible for. This kind of attacks can be referred as "deny of responsibility" attacks and these will compromise the availability of resource.

Maybe this issue should be addressed by distributed database algorithm. However, it has some relations with security. So my suggestion is whether we add the requirements of resource availability and “deny of responsibility” attacks to your draft or not.

 

--Boundary_(ID_cqGke9BveBCto6YUXAwuSQ)-- --===============2106916090== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2106916090==-- From p2psip-bounces@ietf.org Thu May 17 08:52:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HofST-0008UQ-0g; Thu, 17 May 2007 08:51:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HofSQ-0008TJ-7s for p2psip@ietf.org; Thu, 17 May 2007 08:51:50 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HofSN-0002aZ-BU for p2psip@ietf.org; Thu, 17 May 2007 08:51:50 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4HCpSg2021087; Thu, 17 May 2007 15:51:35 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 15:51:33 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 15:51:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 May 2007 15:53:02 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F04476111@esebe102.NOE.Nokia.com> In-Reply-To: <000801c7975c$743404a0$4e05a40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-matuszewski-p2psip-security-requirements-00.txt Thread-Index: AceXXHPexHQA91uuR+yYwZx+di4IkQBHMirg References: <000801c7975c$743404a0$4e05a40a@china.huawei.com> From: To: X-OriginalArrivalTime: 17 May 2007 12:51:33.0668 (UTC) FILETIME=[190B2640:01C79882] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186 Cc: jan-erik.ekberg@nokia.com, pekka.laitinen@nokia.com, p2psip@ietf.org Subject: [P2PSIP] RE: comments on draft-matuszewski-p2psip-security-requirements-00.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0429330621==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0429330621== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79882.18B97FF2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79882.18B97FF2 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Jie, =20 Thank you for your comments. The attack you mentioned is partly covered in the Denial of Service section. I agree with you this is a serious problem in open distributed systems. This type of attack can be mitigated by storing user records in more then one randomly chosen peer (adding indexes to a user ID: UserID_1, UserID_2, UserID_3).=20 =20 We will try to emphasize this problem in the next version of the document. =20 Marcin =20 ________________________________ From: ext Jie Yang [mailto:yangjie_cn@huawei.com]=20 Sent: 16 May, 2007 04:50 To: Matuszewski Marcin (Nokia-NRC/Helsinki) Cc: p2psip@ietf.org Subject: comments on draft-matuszewski-p2psip-security-requirements-00.txt =09 =09 hi, Matuszewski: =20 I'm very interested in your draft and found it included most of the requirements on security. Furthermore, I found some other requirements.=20 Users may be most care about the availability of the resources on the overlay. So do the overlay operators.=20 But unfortunately, attacker can deny the existence of resources it was responsible for. This kind of attacks can be referred as "deny of responsibility" attacks and these will compromise the availability of resource.=20 Maybe this issue should be addressed by distributed database algorithm. However, it has some relations with security. So my suggestion is whether we add the requirements of resource availability and "deny of responsibility" attacks to your draft or not. =20 ------_=_NextPart_001_01C79882.18B97FF2 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Jie,
 
Thank you for your comments. The attack = you=20 mentioned is partly covered in the Denial of Service = section. I=20 agree with you this is a serious problem in open distributed=20 systems. This type of attack can be mitigated by storing = user=20 records in more then one randomly chosen peer (adding indexes=20 to a user ID: UserID_1, UserID_2, = UserID_3). 
 
We will try to emphasize this problem in the = next version=20 of the document.
 
Marcin   

From: ext Jie Yang=20 [mailto:yangjie_cn@huawei.com]
Sent: 16 May, 2007=20 04:50
To: Matuszewski Marcin = (Nokia-NRC/Helsinki)
Cc:=20 p2psip@ietf.org
Subject: comments on=20 = draft-matuszewski-p2psip-security-requirements-00.txt

hi,=20 Matuszewski:

 

I'm very=20 interested in your draft and found it included most of the = requirements on=20 security. Furthermore, I found some other requirements.=20

Users may=20 be most care about the availability of the resources on the overlay. = So do the=20 overlay operators.

But=20 unfortunately, attacker can deny the existence of resources it was = responsible=20 for. This kind of attacks can be referred as "deny of responsibility" = attacks=20 and these will compromise the availability of resource.=20

Maybe this=20 issue should be addressed by distributed database algorithm. However, = it has=20 some relations with security. So my suggestion is whether we add the=20 requirements of resource availability and “deny of = responsibility” attacks to=20 your draft or not.

 

------_=_NextPart_001_01C79882.18B97FF2-- --===============0429330621== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0429330621==-- From p2psip-bounces@ietf.org Thu May 17 21:57:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Horj9-0005lU-Ad; Thu, 17 May 2007 21:57:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Horj7-0005lL-HB for p2psip@ietf.org; Thu, 17 May 2007 21:57:53 -0400 Received: from nz-out-0506.google.com ([64.233.162.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Horj6-0006SD-Iz for p2psip@ietf.org; Thu, 17 May 2007 21:57:53 -0400 Received: by nz-out-0506.google.com with SMTP id z6so1228527nzd for ; Thu, 17 May 2007 18:57:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=snoFXdbF6hL8DzTOSHVjayAcTZNi4ZMNuAexDaDQRqxoAqAjNFnu+YP1TCQg3+gN4cInRtxEmhoLkdKfXvjI8+uwGmI/YX+6WK4aXB8Nii+iiQbfLkFXNwDgRVnTSTw8qy6cjQmYx0PboPldrWz5X7nIpc10L6BHloSt8o1Msbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=uUdvioqBDGRYDpc/VC3KK58K85Qup+L/W0GATUtx663X6I04m+LuFD/VlPOpm1vtEiScLYifLPJEnOcr4zxGx73uqY1S0QpJTnayhWPk7YYbIEOq9cDukFsXyE1wTrm0+RHe+W5QHy2/lAaqiW4UfGOrBefTyB7C/J7x8xLkEwc= Received: by 10.114.126.1 with SMTP id y1mr579972wac.1179453471703; Thu, 17 May 2007 18:57:51 -0700 (PDT) Received: by 10.114.124.7 with HTTP; Thu, 17 May 2007 18:57:51 -0700 (PDT) Message-ID: <894e079b0705171857r4e930209w7906ee6a8903141f@mail.gmail.com> Date: Thu, 17 May 2007 21:57:51 -0400 From: "Medhavi Bhatia" To: p2psip@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: 2d2c40f7cd2657fd X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [P2PSIP] Comments on draft-marocco-p2psip-interwork-01 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1118920901==" Errors-To: p2psip-bounces@ietf.org --===============1118920901== Content-Type: multipart/alternative; boundary="----=_Part_47954_20351028.1179453471423" ------=_Part_47954_20351028.1179453471423 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I briefly scanned this draft. I think it would work well if some requirements and use cases are mentioned in the beginning. For example, there seem to be two broad categories: outbound sessions originating from P2P nodes and inbound sessions coming in from non P2P devices. SIP Registrations will need to be optional since the legacy device may not always be a SIP proxy (like a gateway). I think the need for an interworking device like a P2P SIP Proxy etc is optional in most cases (and should be avoided). At the media level, I am not sure any interoperability is required since we are using ICE (which works in non P2P environment as well). At the signaling level, the session establishment protocol is SIP which doesnt need interworking as well. The main problem seems to be inbound calls where a legacy device like a gateway may not know the FQDN to route an incoming call to. I think an approach similar to what is used for the bootstrap server would work well here for the P2P SIP Proxy. The proxy can be stateless (since it only need to aid in location). Once the INVITE reaches the destination P2P SIP node, it doesnt need to be in the path. For outbound calls, I dont think any proxy or interworking is required since location is not an issue there. I think the issue pointed out in the draft with using correct URLs when communicating with the legacy node makes sense. Do I have the right understanding of the issues? Medhavi. ------=_Part_47954_20351028.1179453471423 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I briefly scanned this draft. I think it would work well if some requirements and use cases are mentioned in the beginning. For example, there seem to be two broad categories: outbound sessions originating from P2P nodes and inbound sessions coming in from non P2P devices. SIP Registrations will need to be optional since the legacy device may not always be a SIP proxy (like a gateway).
 
I think the need for an interworking device like a P2P SIP Proxy etc is optional in most cases (and should be avoided). At the media level, I am not sure any interoperability is required since we are using ICE (which works in non P2P environment as well). At the signaling level, the session establishment protocol is SIP which doesnt need interworking as well. The main problem seems to be inbound calls where a legacy device like a gateway may not know the FQDN to route an incoming call to. I think an approach similar to what is used for the bootstrap server would work well here for the P2P SIP Proxy. The proxy can be stateless (since it only need to aid in location). Once the INVITE reaches the destination P2P SIP node, it doesnt need to be in the path. For outbound calls, I dont think any proxy or interworking is required since location is not an issue there. I think the issue pointed out in the draft with using correct URLs when communicating with the legacy node makes sense.
 
Do I have the right understanding of the issues?
 
Medhavi.
------=_Part_47954_20351028.1179453471423-- --===============1118920901== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1118920901==-- From p2psip-bounces@ietf.org Fri May 18 03:18:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Howio-0006Ic-Pu; Fri, 18 May 2007 03:17:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Howim-0006IU-GS for p2psip@ietf.org; Fri, 18 May 2007 03:17:52 -0400 Received: from mailn.telecomitalia.it ([217.169.121.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Howij-0002vs-Nm for p2psip@ietf.org; Fri, 18 May 2007 03:17:52 -0400 Received: from ptpxch008rm001.idc.cww.telecomitalia.it ([156.54.205.170]) by mailn.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 09:17:48 +0200 Received: from ptpxch006rm001.idc.cww.telecomitalia.it ([156.54.205.168]) by ptpxch008rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 09:17:48 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 09:17:47 +0200 Message-ID: <464D5356.9000306@telecomitalia.it> Date: Fri, 18 May 2007 09:18:46 +0200 From: Enrico Marocco User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Medhavi Bhatia Subject: Re: [P2PSIP] Comments on draft-marocco-p2psip-interwork-01 References: <894e079b0705171857r4e930209w7906ee6a8903141f@mail.gmail.com> In-Reply-To: <894e079b0705171857r4e930209w7906ee6a8903141f@mail.gmail.com> X-Enigmail-Version: 0.94.2.0 X-OriginalArrivalTime: 18 May 2007 07:17:47.0579 (UTC) FILETIME=[A2FA38B0:01C7991C] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1376969189==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1376969189== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060509090804010506080107" This is a cryptographically signed message in MIME format. --------------ms060509090804010506080107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Medhavi Bhatia wrote: > I briefly scanned this draft. I think it would work well if some > requirements and use cases are mentioned in the beginning. For example, > there seem to be two broad categories: outbound sessions originating > from P2P nodes and inbound sessions coming in from non P2P devices. SIP > Registrations will need to be optional since the legacy device may not > always be a SIP proxy (like a gateway). Registrations with the overlay is nothing but "P2PSIP Resource Record Insertions", as defined in concepts draft. It can be done using SIP, using the peer protocol or even using the client protocol, if one will be defined. OTOH, for registering with a public SIP network, since it is just a _SIP_ network, SIP must be used. So, yes, SIP registrations are optional, but some kind of registration is still required. > I think the need for an interworking device like a P2P SIP Proxy etc is > optional in most cases (and should be avoided). They are optional when all clients and peers have unrestricted connectivity. > At the media level, I am > not sure any interoperability is required since we are using ICE (which > works in non P2P environment as well). I'm not sure ICE is effective if not using relayed and server reflexive candidates. > At the signaling level, the > session establishment protocol is SIP which doesnt need interworking as > well. The main problem seems to be inbound calls where a legacy device > like a gateway may not know the FQDN to route an incoming call to. I > think an approach similar to what is used for the bootstrap server would > work well here for the P2P SIP Proxy. The proxy can be stateless (since > it only need to aid in location). Once the INVITE reaches the > destination P2P SIP node, it doesnt need to be in the path. For outbound > calls, I dont think any proxy or interworking is required since location > is not an issue there. I think the issue pointed out in the draft with > using correct URLs when communicating with the legacy node makes sense. Proxy and relay agent peers are optional only when all clients and peers have full connectivity. In the most conservative case, when only few peers are "unrestricted", they must act as proxies and relays for allowing any other node to establish sessions with user agents on the Internet. -- Ciao, Enrico --------------ms060509090804010506080107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNTE4MDcxODQ2WjAjBgkqhkiG9w0BCQQxFgQUQdSNO1HR 50yS4cHHQyfPsnqf6lEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBADGs8FYGsaubdM7j5eZuqwoa7ajdFvpmlWyFEQ02DATYt7uTqN8f1r++ 9Oz3nTUKWF5WUk2+BJ2S9gTdfHlr4tCcl4eOGvJbATKQKpyGcidwd3nb7E+uYpgJoVzK9CYH j2kzXQlNy/52jGfAgUXpKvG34jUu/EevU7Ukd0zjhHD0eum40dIH/HnxpaSLlAA5MmTLv50r 3lwzSHNM/qj9Pg4lYQXrYGw+j18Qm30EEVOnGPkRlQb5308lVIIJx5fl9WZ64A3pu+uaypF8 20jZcroDV402wjvLMj3SOyeqOg9PH3j8O6DI47EaD5MUs+M6hcytMtMeXqaeY145HfKD8ZQA AAAAAAA= --------------ms060509090804010506080107-- --===============1376969189== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1376969189==-- From p2psip-bounces@ietf.org Fri May 18 05:12:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoyVn-0007QU-UP; Fri, 18 May 2007 05:12:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoyVm-0007QO-Dq for p2psip@ietf.org; Fri, 18 May 2007 05:12:34 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoyVj-0002iE-T8 for p2psip@ietf.org; Fri, 18 May 2007 05:12:34 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JI800B04C7F4G@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 18 May 2007 17:11:40 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JI800G05C7DC8@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 18 May 2007 17:11:39 +0800 (CST) Received: from Y57503 ([10.164.5.78]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JI8001J1C79IY@szxml03-in.huawei.com> for p2psip@ietf.org; Fri, 18 May 2007 17:11:37 +0800 (CST) Date: Fri, 18 May 2007 17:11:33 +0800 From: Jie Yang In-reply-to: <3F18E76823C95E4795181D74BAC7664F04476111@esebe102.NOE.Nokia.com> To: marcin.matuszewski@nokia.com Message-id: <000c01c7992c$87e8a510$4e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AceXXHPexHQA91uuR+yYwZx+di4IkQBHMirgACl64lA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d926c18f94eda32f0a6732c7d97b75a Cc: jan-erik.ekberg@nokia.com, pekka.laitinen@nokia.com, p2psip@ietf.org Subject: [P2PSIP] re: comments on draft-matuszewski-p2psip-security-requirements-00.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0466092839==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0466092839== Content-type: multipart/alternative; boundary="Boundary_(ID_UFtO8L1A4DN41rpo+IKvkQ)" This is a multi-part message in MIME format. --Boundary_(ID_UFtO8L1A4DN41rpo+IKvkQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Marcin, I'm happy that you accepted my suggestion. Today, I read your draft again and I found some other issues that I didn't get very clear. In section 3.2.1 Data access "First and foremost, the data stored in the P2PSIP system must be authentic, i.e., only authorized users are able to insert and modify their the P2PSIP resource (user) records in the P2PSIP system." You mentioned that only "authorized" users can have the privilege to insert and modify records. Do the "authorized" users means only the records' owners or they include some other people? If the records' owner is the only person have the privilege, we just need to check the owner's identity to see if he has the privilege. However, if the authorized users are more than one, we should have a table to list all the users' different privileges. That is to say we need an access control mechanism such as ACL. This is the case in some situations. E.g. Bob has some data that just his friends can read and modify. So, should we make clear that we need an access control mechanism in P2P overlay to avoid abusing users' data? Hive a nice day! Jie ---------------------------------------------------------------------------- --------------------------------------------- Hi Jie, Thank you for your comments. The attack you mentioned is partly covered in the Denial of Service section. I agree with you this is a serious problem in open distributed systems. This type of attack can be mitigated by storing user records in more then one randomly chosen peer (adding indexes to a user ID: UserID_1, UserID_2, UserID_3). We will try to emphasize this problem in the next version of the document. Marcin _____ From: ext Jie Yang [mailto:yangjie_cn@huawei.com] Sent: 16 May, 2007 04:50 To: Matuszewski Marcin (Nokia-NRC/Helsinki) Cc: p2psip@ietf.org Subject: comments on draft-matuszewski-p2psip-security-requirements-00.txt hi, Matuszewski: I'm very interested in your draft and found it included most of the requirements on security. Furthermore, I found some other requirements. Users may be most care about the availability of the resources on the overlay. So do the overlay operators. But unfortunately, attacker can deny the existence of resources it was responsible for. This kind of attacks can be referred as "deny of responsibility" attacks and these will compromise the availability of resource. Maybe this issue should be addressed by distributed database algorithm. However, it has some relations with security. So my suggestion is whether we add the requirements of resource availability and "deny of responsibility" attacks to your draft or not. --Boundary_(ID_UFtO8L1A4DN41rpo+IKvkQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Marcin,

 

I’m happy that you accepted my suggestion. Today, I read your draft again and I found some other issues that I didn’t get very clear.

 

In section

3.2.1           Data access

“First and foremost, the data stored in the P2PSIP system must be

         authentic, i.e., only authorized users are able to insert and modify

         their the P2PSIP resource (user) records in the P2PSIP system.”

 

You mentioned that only “authorized” users can have the privilege to insert and modify records. Do the “authorized” users means only the records’ owners or they include some other people?  If  the records’ owner is the only person have the privilege, we just need to check the owner’s identity to see if he has the privilege.  However, if the authorized users are more than one, we should have a table to list all the users’ different privileges. That is to say we need an access control mechanism such as ACL. This is the case in some situations. E.g. Bob has some data that just his friends can read and modify.

So, should we make clear that we need an access control mechanism in P2P overlay to avoid abusing users’ data?

 

 

Hive a nice day!

 

Jie

 

-------------------------------------------------------------------------------------------------------------------------

Hi Jie,

 

Thank you for your comments. The attack you mentioned is partly covered in the Denial of Service section. I agree with you this is a serious problem in open distributed systems. This type of attack can be mitigated by storing user records in more then one randomly chosen peer (adding indexes to a user ID: UserID_1, UserID_2, UserID_3). 

 

We will try to emphasize this problem in the next version of the document.

 

Marcin   

 

From: ext Jie Yang [mailto:yangjie_cn@huawei.com]
Sent: 16 May, 2007 04:50
To: Matuszewski Marcin (Nokia-NRC/Helsinki)
Cc: p2psip@ietf.org
Subject: comments on draft-matuszewski-p2psip-security-requirements-00.txt

hi, Matuszewski:

 

I'm very interested in your draft and found it included most of the requirements on security. Furthermore, I found some other requirements.

Users may be most care about the availability of the resources on the overlay. So do the overlay operators.

But unfortunately, attacker can deny the existence of resources it was responsible for. This kind of attacks can be referred as "deny of responsibility" attacks and these will compromise the availability of resource.

Maybe this issue should be addressed by distributed database algorithm. However, it has some relations with security. So my suggestion is whether we add the requirements of resource availability and “deny of responsibility” attacks to your draft or not.

 

--Boundary_(ID_UFtO8L1A4DN41rpo+IKvkQ)-- --===============0466092839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0466092839==-- From p2psip-bounces@ietf.org Fri May 18 11:54:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp4mI-0007AL-Dc; Fri, 18 May 2007 11:54:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp4mH-00078z-Gh for p2psip@ietf.org; Fri, 18 May 2007 11:54:01 -0400 Received: from wr-out-0506.google.com ([64.233.184.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp4mH-0002QT-2W for p2psip@ietf.org; Fri, 18 May 2007 11:54:01 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1007985wri for ; Fri, 18 May 2007 08:54:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=MabtBGBcP9KMT039qNbXsOf81UWkvsMQg1sTa8viW2L8EaSsHUIVgJGRzeRt27MH34RuvtadB3M44CUg9jno3OpAJOZBqwH4IX+YBEdNSQmuELSl6uWp/FAhcL3RlpWbwkmE8JSva7oy+IjmtpEcz14mGi5pjP5HJX81PlsXFQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=houMy0V45fQ+PBCCAeAcDp/RzVc2NvG5rokajViEpPplHdYFOuQlV92gYY/Dw72tN2fRo7ZF65VeoKGE44ps4Uy2Aa9aolf3yAoYadIbtbByNuJ3IZYM/3Kc+YCCSORz0bhhpv3q/vMLdx/OduloDKo79kvhKN2YsFBcvJrpHLs= Received: by 10.114.200.2 with SMTP id x2mr886912waf.1179503639307; Fri, 18 May 2007 08:53:59 -0700 (PDT) Received: by 10.114.124.7 with HTTP; Fri, 18 May 2007 08:53:59 -0700 (PDT) Message-ID: <894e079b0705180853t50e29513qeaf6f9ebb615006@mail.gmail.com> Date: Fri, 18 May 2007 11:53:59 -0400 From: "Medhavi Bhatia" To: "Enrico Marocco" Subject: Re: [P2PSIP] Comments on draft-marocco-p2psip-interwork-01 In-Reply-To: <464D5356.9000306@telecomitalia.it> MIME-Version: 1.0 References: <894e079b0705171857r4e930209w7906ee6a8903141f@mail.gmail.com> <464D5356.9000306@telecomitalia.it> X-Google-Sender-Auth: 0e5861fa871737dc X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1571941650==" Errors-To: p2psip-bounces@ietf.org --===============1571941650== Content-Type: multipart/alternative; boundary="----=_Part_56017_19582186.1179503639240" ------=_Part_56017_19582186.1179503639240 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Enrico, Please see inline for some more comments. On 5/18/07, Enrico Marocco wrote: > > Medhavi Bhatia wrote: > > I briefly scanned this draft. I think it would work well if some > > requirements and use cases are mentioned in the beginning. For example, > > there seem to be two broad categories: outbound sessions originating > > from P2P nodes and inbound sessions coming in from non P2P devices. SIP > > Registrations will need to be optional since the legacy device may not > > always be a SIP proxy (like a gateway). > > Registrations with the overlay is nothing but "P2PSIP Resource Record > Insertions", as defined in concepts draft. It can be done using SIP, > using the peer protocol or even using the client protocol, if one will > be defined. OTOH, for registering with a public SIP network, since it > is just a _SIP_ network, SIP must be used. So, yes, SIP registrations > are optional, but some kind of registration is still required. Ok, I didn't think of the scenario where a device has to register with an overlay. I think a better way is for the device to register with a regular SIP Proxy and we figure out how the overlay interworks with it. I think same holds for the reverse scenario as well. > I think the need for an interworking device like a P2P SIP Proxy etc is > > optional in most cases (and should be avoided). > > They are optional when all clients and peers have unrestricted > connectivity. Connectivity is a requirement I think. After the address is know for a P2P node, connectivity may require some help (similar to what functionality a bootstrap node provides) > At the media level, I am > > not sure any interoperability is required since we are using ICE (which > > works in non P2P environment as well). > > I'm not sure ICE is effective if not using relayed and server reflexive > candidates. In any case, ICE interop is not what this draft should focus on. > At the signaling level, the > > session establishment protocol is SIP which doesnt need interworking as > > well. The main problem seems to be inbound calls where a legacy device > > like a gateway may not know the FQDN to route an incoming call to. I > > think an approach similar to what is used for the bootstrap server would > > work well here for the P2P SIP Proxy. The proxy can be stateless (since > > it only need to aid in location). Once the INVITE reaches the > > destination P2P SIP node, it doesnt need to be in the path. For outbound > > calls, I dont think any proxy or interworking is required since location > > is not an issue there. I think the issue pointed out in the draft with > > using correct URLs when communicating with the legacy node makes sense. > > Proxy and relay agent peers are optional only when all clients and peers > have full connectivity. In the most conservative case, when only few > peers are "unrestricted", they must act as proxies and relays for > allowing any other node to establish sessions with user agents on the > Internet. Yeah. I am not debating connectivity is a problem, but it probably can do with a simple stateless SIP Proxy like the bootstrap server. -- > Ciao, > Enrico > > ------=_Part_56017_19582186.1179503639240 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Enrico,
 
Please see inline for some more comments.

 
On 5/18/07, Enrico Marocco <enrico.marocco@telecomitalia.it > wrote:
Medhavi Bhatia wrote:
> I briefly scanned this draft. I think it would work well if some
> requirements and use cases are mentioned in the beginning. For example,
> there seem to be two broad categories: outbound sessions originating
> from P2P nodes and inbound sessions coming in from non P2P devices. SIP
> Registrations will need to be optional since the legacy device may not
> always be a SIP proxy (like a gateway).

Registrations with the overlay is nothing but "P2PSIP Resource Record
Insertions", as defined in concepts draft.  It can be done using SIP,
using the peer protocol or even using the client protocol, if one will
be defined.  OTOH, for registering with a public SIP network, since it
is just a _SIP_ network, SIP must be used.  So, yes, SIP registrations
are optional, but some kind of registration is still required.
 
Ok, I didn't think of the scenario where a device has to register with an overlay. I think a better way is for the device to register with a regular SIP Proxy and we figure out how the overlay interworks with it. I think same holds for the reverse scenario as well.
 

> I think the need for an interworking device like a P2P SIP Proxy etc is
> optional in most cases (and should be avoided).

They are optional when all clients and peers have unrestricted connectivity.
 
Connectivity is a requirement I think. After the address is know for a P2P node, connectivity may require some help (similar to what functionality a bootstrap node provides)

>                                                 At the media level, I am
> not sure any interoperability is required since we are using ICE (which
> works in non P2P environment as well).

I'm not sure ICE is effective if not using relayed and server reflexive
candidates.
 
In any case, ICE interop is not what this draft should focus on.
 

>                                        At the signaling level, the
> session establishment protocol is SIP which doesnt need interworking as
> well. The main problem seems to be inbound calls where a legacy device
> like a gateway may not know the FQDN to route an incoming call to. I
> think an approach similar to what is used for the bootstrap server would
> work well here for the P2P SIP Proxy. The proxy can be stateless (since
> it only need to aid in location). Once the INVITE reaches the
> destination P2P SIP node, it doesnt need to be in the path. For outbound
> calls, I dont think any proxy or interworking is required since location
> is not an issue there. I think the issue pointed out in the draft with
> using correct URLs when communicating with the legacy node makes sense.

Proxy and relay agent peers are optional only when all clients and peers
have full connectivity.  In the most conservative case, when only few
peers are "unrestricted", they must act as proxies and relays for
allowing any other node to establish sessions with user agents on the
Internet.
 
Yeah. I am not debating connectivity is a problem, but it probably can do with a simple stateless SIP Proxy like the bootstrap server.

--
Ciao,
Enrico


------=_Part_56017_19582186.1179503639240-- --===============1571941650== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1571941650==-- From p2psip-bounces@ietf.org Sat May 19 04:27:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpKHk-0003DD-PR; Sat, 19 May 2007 04:27:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpKHj-0003D7-Mq for p2psip@ietf.org; Sat, 19 May 2007 04:27:31 -0400 Received: from maill.telecomitalia.it ([217.169.121.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpKHg-0005FT-2p for p2psip@ietf.org; Sat, 19 May 2007 04:27:31 -0400 Received: from ptpxch009rm001.idc.cww.telecomitalia.it ([156.54.205.171]) by maill.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sat, 19 May 2007 10:27:26 +0200 Received: from ptpxch004rm001.idc.cww.telecomitalia.it ([156.54.205.166]) by ptpxch009rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sat, 19 May 2007 10:27:26 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch004rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 19 May 2007 10:27:25 +0200 Message-ID: <464EB527.7000004@telecomitalia.it> Date: Sat, 19 May 2007 10:28:23 +0200 From: Enrico Marocco User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Medhavi Bhatia Subject: Re: [P2PSIP] Comments on draft-marocco-p2psip-interwork-01 References: <894e079b0705171857r4e930209w7906ee6a8903141f@mail.gmail.com> <464D5356.9000306@telecomitalia.it> <894e079b0705180853t50e29513qeaf6f9ebb615006@mail.gmail.com> In-Reply-To: <894e079b0705180853t50e29513qeaf6f9ebb615006@mail.gmail.com> X-Enigmail-Version: 0.94.2.0 X-OriginalArrivalTime: 19 May 2007 08:27:25.0821 (UTC) FILETIME=[87D11AD0:01C799EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0827001478==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0827001478== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030003050904060902060207" This is a cryptographically signed message in MIME format. --------------ms030003050904060902060207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Medhavi Bhatia wrote: > > I think the need for an interworking device like a P2P SIP Proxy > etc is > > optional in most cases (and should be avoided). > > They are optional when all clients and peers have unrestricted > connectivity. > > Connectivity is a requirement I think. After the address is know for a > P2P node, connectivity may require some help (similar to what > functionality a bootstrap node provides) Use cases collected so far (http://www.p2psip.org/P2PUseCases.php) include some scenarios where peers may have restricted or no connectivity. > > At the media > level, I am > > not sure any interoperability is required since we are using ICE > (which > > works in non P2P environment as well). > > I'm not sure ICE is effective if not using relayed and server reflexive > candidates. > > In any case, ICE interop is not what this draft should focus on. Yeah, I agree that discovery of media relays -- and, in general, of well-known services -- should probably be addressed separately. > Proxy and relay agent peers are optional only when all clients and peers > have full connectivity. In the most conservative case, when only few > peers are "unrestricted", they must act as proxies and relays for > allowing any other node to establish sessions with user agents on the > Internet. > > Yeah. I am not debating connectivity is a problem, but it probably can > do with a simple stateless SIP Proxy like the bootstrap server. Personally I'd prefer to keep roles as distinct as possible, but, yes, the proxy peer is actually a SIP proxy. -- Ciao, Enrico --------------ms030003050904060902060207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNTE5MDgyODIzWjAjBgkqhkiG9w0BCQQxFgQUL+kuvhUH AX98RDIJ0BI/n281Uj4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBADdCVGwwzCAmkgf0MLHuwfaMZzVteGothHuibUXEbjORrQD8jcUfht/X AwE2LMS6aWPBfPpSsVzP+mbEtP1267Mh3z+iGRb2lj5JHeh5eQ+JRRFwdxCvJGGf3NnwpN4o 2FVagN7oeLcXtLiUl/fLuQncjiVnsgjAyKUG9XA5bR8Io+vDVd0f0kQ1SYflJqqLGVxQKlrz q0WCxF5216MtJa0MKKzZWGi+FYh+xWPO87q0OhKGx/HONudfvTf5JOUK7Td8A6v5O3lgwXX1 UcsDaWhXcV/sXiV5Tm9/vf59ylq1Dy/ZHNtpuJrTDKPKCP8g3qnbaQBHIOkgBIBvb5JozbMA AAAAAAA= --------------ms030003050904060902060207-- --===============0827001478== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0827001478==-- From p2psip-bounces@ietf.org Tue May 22 03:40:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqOyY-0006hi-4x; Tue, 22 May 2007 03:40:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqOyW-0006fa-O1 for p2psip@ietf.org; Tue, 22 May 2007 03:40:08 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqOyV-0007ko-0i for p2psip@ietf.org; Tue, 22 May 2007 03:40:08 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JIF007J4MLBZR@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 22 May 2007 15:39:11 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JIF007PYML97O@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 22 May 2007 15:39:11 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JIF005FPML61P@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 22 May 2007 15:39:09 +0800 (CST) Date: Tue, 22 May 2007 15:39:06 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Comments on draft-marocco-p2psip-interwork-01 In-reply-to: <464EB527.7000004@telecomitalia.it> To: 'Enrico Marocco' , 'Medhavi Bhatia' Message-id: <000501c79c44$47423920$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceZ751hoWCoxhSaQ22i+qq6GeyYgQCUZOVA X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Enrico: > Personally I'd prefer to keep roles as distinct as possible, but, yes, > the proxy peer is actually a SIP proxy. IMHO, proxy peer in the interworking draft could be thought of as a bootstrap peer. Finding a proxy peer in the DNS will be reduced to find a bootstrap peer in the DNS. In this way, the caller or its authoritative proxy server could be thought of as a client. In order to communicate with SIP UA in an overlay, the only thing it needs to do is to find a Peer to serve for him. The Peer could be any one in the overlay. In Philip's draft-matthews-p2psip-bootstrap-mechanisms-00, a bootstrap mechanism named bootstrap server mechanism is proposed. It proposes the bootstrap server is a SIP registrar and proxy server. I have a question here, if the bootstrap server has all of UA contact locations, why not using conventional SIP directly? So I think a Dynamic DNS may be an alterative choice for bootstrap server because of its generality. The problems that lies in DDNS mechanism are: 1. how does the method keep the consistence because of peers' churn. 2. Which subset of peers could be granted to register with DNS? If all peers has right to do registration with DNS on behalf of the overlay, DNS database will be populated with a lot of redundant data and receive a lot of request and will bring security threat to DNS. -- Jiang XingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue May 22 04:17:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqPYm-0007B5-S4; Tue, 22 May 2007 04:17:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqPYk-0007At-MS for p2psip@ietf.org; Tue, 22 May 2007 04:17:34 -0400 Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqPYi-0000mG-H2 for p2psip@ietf.org; Tue, 22 May 2007 04:17:34 -0400 Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 10:17:31 +0200 Received: from PTPXCH029BA020.idc.cww.telecomitalia.it ([156.54.240.46]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 10:17:30 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by PTPXCH029BA020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 10:17:29 +0200 Message-ID: <4652A758.7040809@telecomitalia.it> Date: Tue, 22 May 2007 10:18:32 +0200 From: Enrico Marocco User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: JiangXingFeng Subject: Re: [P2PSIP] Comments on draft-marocco-p2psip-interwork-01 References: <000501c79c44$47423920$6905a40a@china.huawei.com> In-Reply-To: <000501c79c44$47423920$6905a40a@china.huawei.com> X-Enigmail-Version: 0.94.2.0 X-OriginalArrivalTime: 22 May 2007 08:17:29.0985 (UTC) FILETIME=[A3E8FF10:01C79C49] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0327891936==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0327891936== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000109050009020909080006" This is a cryptographically signed message in MIME format. --------------ms000109050009020909080006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit JiangXingFeng wrote: > In Philip's draft-matthews-p2psip-bootstrap-mechanisms-00, a bootstrap > mechanism named bootstrap server mechanism is proposed. It proposes the > bootstrap server is a SIP registrar and proxy server. I have a question > here, if the bootstrap server has all of UA contact locations, why not using > conventional SIP directly? It hasn't. It acts just as a front-end for the overlay, storing and retrieving locations in the distributed database. > So I think a Dynamic DNS may be an alterative choice for bootstrap server > because of its generality. The problems that lies in DDNS mechanism are: 1. > how does the method keep the consistence because of peers' churn. 2. Which > subset of peers could be granted to register with DNS? If all peers has > right to do registration with DNS on behalf of the overlay, DNS database > will be populated with a lot of redundant data and receive a lot of request > and will bring security threat to DNS. Registrations of peers -- proxy, bootstrap or whatever -- into DNS are an open issue; it is critical if they are regulated by policies both too restrictive and too permissive. The draft tries to point it out in section 3.1.1 ("Insertion into DNS"). -- Ciao, Enrico --------------ms000109050009020909080006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNTIyMDgxODMyWjAjBgkqhkiG9w0BCQQxFgQULSzJO1qq GoZQh+u10obmMsKSMdQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAEUtXV/nuOdUDkrJbUqQNihC+xoVaRwpW9+uIUAqYeRva8LIWRQsnu7I OTEh+m2j3gOWl5PrCU54c/Gx7NUNS7xLIA1zMCryWJ/+No1X2rwsBA0nChiqllyz7eQJPy2I iyxs3KNLYWG0lArIog9iNHNZdsZfYZFLv4yfVkBypd5cAsicX/Wq8pf6tcPzLJOc4fkX0Rvy dhRMDh/Rg92wuNRV8kuWWPB2DohIwvZIrhn116C6q6iMT5R/xYI44moc29wXvJ5/mc9v+rzn F4BI57bzyFlkjD0SDJ5diTErCvuInTrKGWlWHKOE30HrdCcHGpBkMCikS75juuiXrbj4MSEA AAAAAAA= --------------ms000109050009020909080006-- --===============0327891936== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0327891936==-- From p2psip-bounces@ietf.org Tue May 22 04:42:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqPxC-0008TC-Rx; Tue, 22 May 2007 04:42:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqPxB-0008T4-H8 for p2psip@ietf.org; Tue, 22 May 2007 04:42:49 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqPx8-0007Ia-D1 for p2psip@ietf.org; Tue, 22 May 2007 04:42:49 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JIF00DIYP8HFO@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 22 May 2007 16:36:17 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JIF00D2FP8H62@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 22 May 2007 16:36:17 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JIF0059NP8D1P@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 22 May 2007 16:36:17 +0800 (CST) Date: Tue, 22 May 2007 16:36:13 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Comments on draft-marocco-p2psip-interwork-01 In-reply-to: <4652A758.7040809@telecomitalia.it> To: 'Enrico Marocco' Message-id: <000f01c79c4c$41e717e0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcecSa4NleFCSoaVRwKBuui8+nwnWgAAZY8A X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > JiangXingFeng wrote: > > In Philip's draft-matthews-p2psip-bootstrap-mechanisms-00, a bootstrap > > mechanism named bootstrap server mechanism is proposed. It proposes the > > bootstrap server is a SIP registrar and proxy server. I have a question > > here, if the bootstrap server has all of UA contact locations, why not using > > conventional SIP directly? > > It hasn't. It acts just as a front-end for the overlay, storing and > retrieving locations in the distributed database. Yes, I know the bootstrap server will proxy message to bootstrap peer for the joining peer. But there is still a problem: do all Peers have rights to register with the bootstrap server? How does the bootstrap server to ensure the consistency if the registered peers leaves the overlay gracefully or ungracefully? Certainly, in real deployments, the operator could deploy some server-like peers with high availability and have them register to the bootstrap server. Personally, I don't like this method. -- Jiang XingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue May 22 05:09:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqQN8-0007zQ-Gy; Tue, 22 May 2007 05:09:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqQMv-0007wX-BH for p2psip@ietf.org; Tue, 22 May 2007 05:09:25 -0400 Received: from mailm.telecomitalia.it ([217.169.121.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqQMs-0005VD-8E for p2psip@ietf.org; Tue, 22 May 2007 05:09:25 -0400 Received: from ptpxch007rm001.idc.cww.telecomitalia.it ([156.54.205.169]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 11:09:19 +0200 Received: from ptpxch005rm001.idc.cww.telecomitalia.it ([156.54.205.167]) by ptpxch007rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 11:09:18 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch005rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 11:09:18 +0200 Message-ID: <4652B377.2050305@telecomitalia.it> Date: Tue, 22 May 2007 11:10:15 +0200 From: Enrico Marocco User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: JiangXingFeng Subject: Re: [P2PSIP] Comments on draft-marocco-p2psip-interwork-01 References: <000f01c79c4c$41e717e0$6905a40a@china.huawei.com> In-Reply-To: <000f01c79c4c$41e717e0$6905a40a@china.huawei.com> X-Enigmail-Version: 0.94.2.0 X-OriginalArrivalTime: 22 May 2007 09:09:18.0110 (UTC) FILETIME=[E07F3BE0:01C79C50] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1593288312==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1593288312== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020008030805010308070208" This is a cryptographically signed message in MIME format. --------------ms020008030805010308070208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit JiangXingFeng wrote: >> JiangXingFeng wrote: >>> In Philip's draft-matthews-p2psip-bootstrap-mechanisms-00, a bootstrap >>> mechanism named bootstrap server mechanism is proposed. It proposes the >>> bootstrap server is a SIP registrar and proxy server. I have a question >>> here, if the bootstrap server has all of UA contact locations, why not > using >>> conventional SIP directly? >> It hasn't. It acts just as a front-end for the overlay, storing and >> retrieving locations in the distributed database. > > Yes, I know the bootstrap server will proxy message to bootstrap peer for > the joining peer. But there is still a problem: do all Peers have rights to > register with the bootstrap server? How does the bootstrap server to ensure > the consistency if the registered peers leaves the overlay gracefully or > ungracefully? Certainly, in real deployments, the operator could deploy some > server-like peers with high availability and have them register to the > bootstrap server. Personally, I don't like this method. Different deployments will adopt different policies for managing nearly all kinds of operation -- joins, puts, gets, enrollments, registrations with bootstrap/DNS servers... The protocols needs just to be transparent about the policy and it will be up to the deployment to find the best way for addressing issues like those you mentioned. -- Ciao, Enrico --------------ms020008030805010308070208 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNTIyMDkxMDE1WjAjBgkqhkiG9w0BCQQxFgQUZ/NAP91M PxJ2LQuIkUAjPmMJJFMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAHceRwrT4SJsMBBtBdHy0JXAC7q+AOM7ErBiE0nckdfkKx57BDYECC9E x7H6qHFdUqt0h+4imPRXqzNlctJf2cQwj7i5jTNxVjBMzrhvProrE5xcA+cdE+ObF+495pok WDxDGIExXf2LpzAf45mRBneRa6V1SMeR5lVicNNHijMaoULbSAvC/QQESrPqq+QHeQmVKjks vXPLRLJ8mByE/u9iEREJ4ghcq6dqnGzUGpn4z/yZcnCxtPYpBhQiEh5nC9QUUQp9v0JgYH5U HExCUn/hMjOwaDtVpXWJkjCX6hfQS5msQheg9ev/yPYZKM/XSpPDBoAUO6PYrETCVau1mL4A AAAAAAA= --------------ms020008030805010308070208-- --===============1593288312== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1593288312==-- From p2psip-bounces@ietf.org Tue May 22 07:12:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqSIG-00076u-4X; Tue, 22 May 2007 07:12:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqSIE-00076i-PN for p2psip@ietf.org; Tue, 22 May 2007 07:12:42 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqSID-0000mp-Dz for p2psip@ietf.org; Tue, 22 May 2007 07:12:42 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4MBCMSX004295; Tue, 22 May 2007 14:12:23 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 14:12:18 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 14:12:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 May 2007 14:13:55 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F044DFA52@esebe102.NOE.Nokia.com> In-Reply-To: <000c01c7992c$87e8a510$4e05a40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-matuszewski-p2psip-security-requirements-00.txt Thread-Index: AceXXHPexHQA91uuR+yYwZx+di4IkQBHMirgACl64lAAz+2vQA== References: <3F18E76823C95E4795181D74BAC7664F04476111@esebe102.NOE.Nokia.com> <000c01c7992c$87e8a510$4e05a40a@china.huawei.com> From: To: X-OriginalArrivalTime: 22 May 2007 11:12:18.0614 (UTC) FILETIME=[0F9EC560:01C79C62] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 60b8b0c899e456b83ab883a8a820ab4b Cc: jan-erik.ekberg@nokia.com, pekka.laitinen@nokia.com, p2psip@ietf.org Subject: [P2PSIP] RE: comments on draft-matuszewski-p2psip-security-requirements-00.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0627859273==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0627859273== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79C62.0F8850B4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79C62.0F8850B4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Jie, =20 By authorized users we mean a record owner and other users that are authorized to modify/access the record.=20 =20 Access lists do not work well in a distributed environment. In a P2PSIP overlay authentication data can be distributed among peers. There are other methods that can be used to authorize other network entities (P2PSIP Users/Peers) to modify and access P2PSIP User/Peer records.=20 =20 For example network entities could issue each other tokens that are digitally signed by them. The token would contain at least: - issuer ID, and its public key (or certificate) - target ID, and its public key (or certificate) - authorizing data (e.g., allow target to see issuer's current availability) - validity period =20 Network entities would store all tokens that have been issued to them. When a P2PSIP Client/Peer queries (GET method) status of a user, it appends the request with a token that has the corresponding user as a issuer. P2PSIP Peer validates the token using the issuer's public key, and if it is valid, the relevant status data is released to this P2PSIP Client/Peer. Similarly a P2PSIP Client/Peer may modify records of other users/peers. P2PSIP User/Peer can revocate issued tokens by including revocation data to its DATA entry (during PUT method). =20 Best regards, Marcin Matuszewski=20 =20 =20 =20 ________________________________ From: ext Jie Yang [mailto:yangjie_cn@huawei.com]=20 Sent: 18 May, 2007 12:12 To: Matuszewski Marcin (Nokia-NRC/Helsinki) Cc: p2psip@ietf.org; Ekberg Jan-Erik (Nokia-NRC/Helsinki); Laitinen Pekka (Nokia-NRC/Helsinki) Subject: re: comments on draft-matuszewski-p2psip-security-requirements-00.txt =09 =09 Hi Marcin, =20 I'm happy that you accepted my suggestion. Today, I read your draft again and I found some other issues that I didn't get very clear. =20 In section=20 3.2.1 Data access "First and foremost, the data stored in the P2PSIP system must be authentic, i.e., only authorized users are able to insert and modify their the P2PSIP resource (user) records in the P2PSIP system." =20 You mentioned that only "authorized" users can have the privilege to insert and modify records. Do the "authorized" users means only the records' owners or they include some other people? If the records' owner is the only person have the privilege, we just need to check the owner's identity to see if he has the privilege. However, if the authorized users are more than one, we should have a table to list all the users' different privileges. That is to say we need an access control mechanism such as ACL. This is the case in some situations. E.g. Bob has some data that just his friends can read and modify. So, should we make clear that we need an access control mechanism in P2P overlay to avoid abusing users' data? =20 =20 Hive a nice day! =20 Jie =20 =09 ------------------------------------------------------------------------ ------------------------------------------------- =09 =09 Hi Jie, =20 Thank you for your comments. The attack you mentioned is partly covered in the Denial of Service section. I agree with you this is a serious problem in open distributed systems. This type of attack can be mitigated by storing user records in more then one randomly chosen peer (adding indexes to a user ID: UserID_1, UserID_2, UserID_3).=20 =20 We will try to emphasize this problem in the next version of the document. =20 Marcin =20 =20 =09 ________________________________ From: ext Jie Yang [mailto:yangjie_cn@huawei.com]=20 Sent: 16 May, 2007 04:50 To: Matuszewski Marcin (Nokia-NRC/Helsinki) Cc: p2psip@ietf.org Subject: comments on draft-matuszewski-p2psip-security-requirements-00.txt hi, Matuszewski: =20 I'm very interested in your draft and found it included most of the requirements on security. Furthermore, I found some other requirements.=20 Users may be most care about the availability of the resources on the overlay. So do the overlay operators.=20 But unfortunately, attacker can deny the existence of resources it was responsible for. This kind of attacks can be referred as "deny of responsibility" attacks and these will compromise the availability of resource.=20 Maybe this issue should be addressed by distributed database algorithm. However, it has some relations with security. So my suggestion is whether we add the requirements of resource availability and "deny of responsibility" attacks to your draft or not. =20 ------_=_NextPart_001_01C79C62.0F8850B4 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Jie,
 
By authorized users we mean a record owner and = other users=20 that are authorized to modify/access the record.
 
Access lists do not work well in a distributed = environment.=20 In a P2PSIP overlay authentication data can be distributed among=20 peers. There are other methods that can be used to authorize=20 other network entities (P2PSIP Users/Peers) to modify and=20 access P2PSIP User/Peer records.
 
For example network entities could issue = each other=20 tokens that are digitally signed by them. The token would contain at = least:
-=20 issuer ID, and its public key (or certificate)
- target ID, and its = public=20 key (or certificate)
- authorizing data (e.g., allow target to see = issuer’s=20 current availability)
- validity period
 
Network entities would store all tokens = that have been=20 issued to them.  When a P2PSIP Client/Peer queries (GET method) = status of a=20 user, it appends the request with a token that has the corresponding = user as a=20 issuer. P2PSIP Peer validates the token using the issuer's public key, = and if it=20 is valid, the relevant status data is released to this P2PSIP = Client/Peer.=20 Similarly a P2PSIP Client/Peer may modify records of other=20 users/peers. P2PSIP User/Peer can revocate issued tokens by = including=20 revocation data to its DATA entry (during PUT = method).
 
Best regards,
Marcin = Matuszewski 
 
 
 

From: ext Jie Yang=20 [mailto:yangjie_cn@huawei.com]
Sent: 18 May, 2007=20 12:12
To: Matuszewski Marcin = (Nokia-NRC/Helsinki)
Cc:=20 p2psip@ietf.org; Ekberg Jan-Erik (Nokia-NRC/Helsinki); Laitinen Pekka=20 (Nokia-NRC/Helsinki)
Subject: re: comments on=20 = draft-matuszewski-p2psip-security-requirements-00.txt

Hi = Marcin,

 

I’m happy that you = accepted my=20 suggestion. Today, I read your draft again and I found some other = issues that=20 I didn’t get very clear.

 

In section=20

3.2.1          =20 Data=20 access

“First = and foremost, the=20 data stored in the P2PSIP system must be

  =20       authentic, i.e., only authorized users = are able=20 to insert and modify

  =20       their the P2PSIP resource (user) = records in the=20 P2PSIP system.”

 

You mentioned that only=20 “authorized” users can have the privilege to insert and = modify records. Do the=20 “authorized” users means only the records’ owners or = they include some other=20 people?  If  the records’ owner is the only person = have the=20 privilege, we just need to check the owner’s identity to see if = he has the=20 privilege.  However, if the authorized users are more than one, = we should=20 have a table to list all the users’ different privileges. That = is to say we=20 need an access control mechanism such as ACL. This is the case in some = situations. E.g. Bob has some data that just his friends can read and=20 modify.

So, should we make clear = that we=20 need an access control mechanism in P2P overlay to avoid abusing = users’=20 data?

 

 

Hive a nice=20 day!

 

Jie

 

-------------------------------------------------------------------= ------------------------------------------------------<= /FONT>

Hi=20 Jie,

 

Thank = you for=20 your comments. The attack you mentioned is partly covered in = the=20 Denial of Service section. I agree with you this is a = serious=20 problem in open distributed systems. This type of attack can = be=20 mitigated by storing user records in more then one randomly=20 chosen peer (adding indexes to a user ID: UserID_1, = UserID_2,=20 UserID_3). 

 

We will try = to=20 emphasize this problem in the next version of the = document.

 

Marcin   

 

From: ext Jie Yang=20 [mailto:yangjie_cn@huawei.com]
Sent: 16 May, 2007 = 04:50
To: Matuszewski Marcin=20 (Nokia-NRC/Helsinki)
Cc:=20 p2psip@ietf.org
Subject:=20 comments on=20 = draft-matuszewski-p2psip-security-requirements-00.txt

hi,=20 Matuszewski:

 

I'm very=20 interested in your draft and found it included most of the = requirements on=20 security. Furthermore, I found some other requirements.=20

Users may=20 be most care about the availability of the resources on the overlay. = So do=20 the overlay operators.

But=20 unfortunately, attacker can deny the existence of resources it was=20 responsible for. This kind of attacks can be referred as "deny of=20 responsibility" attacks and these will compromise the availability = of=20 resource.

Maybe=20 this issue should be addressed by distributed database algorithm. = However,=20 it has some relations with security. So my suggestion is whether we = add the=20 requirements of resource availability and “deny of = responsibility” attacks=20 to your draft or not.

 

------_=_NextPart_001_01C79C62.0F8850B4-- --===============0627859273== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0627859273==-- From p2psip-bounces@ietf.org Tue May 22 15:07:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqZho-0000wM-JB; Tue, 22 May 2007 15:07:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqZhf-0000vs-CB for p2psip@ietf.org; Tue, 22 May 2007 15:07:28 -0400 Received: from bay0-omc1-s17.bay0.hotmail.com ([65.54.246.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqZhY-0001j0-KS for p2psip@ietf.org; Tue, 22 May 2007 15:07:27 -0400 Received: from BAYC1-PASMTP03.CEZ.ICE ([65.54.191.163]) by bay0-omc1-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 22 May 2007 12:07:19 -0700 X-Originating-IP: [216.13.42.68] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from phoenix ([216.13.42.68]) by BAYC1-PASMTP03.CEZ.ICE over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2668); Tue, 22 May 2007 12:07:19 -0700 Message-ID: <005901c79ca4$6bd5c5d0$6c500a0a@phoenix> From: "Eric Cooper" To: "JiangXingFeng" , "'Enrico Marocco'" , "'Medhavi Bhatia'" References: <000501c79c44$47423920$6905a40a@china.huawei.com> Subject: Re: [P2PSIP] Comments on draft-marocco-p2psip-interwork-01 Date: Tue, 22 May 2007 15:03:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 22 May 2007 19:07:19.0827 (UTC) FILETIME=[6BAABE30:01C79CA4] X-Spam-Score: 2.2 (++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org [snip] > In Philip's draft-matthews-p2psip-bootstrap-mechanisms-00, a bootstrap > mechanism named bootstrap server mechanism is proposed. It proposes the > bootstrap server is a SIP registrar and proxy server. I have a question > here, if the bootstrap server has all of UA contact locations, why not > using > conventional SIP directly? > In draft-matthews-p2psip-bootstrap-mechanisms-00, the bootstrap server need not be a regular SIP registrar/proxy in the client-server SIP sense, though we do make the observation that, with minor modifications to the URI processing, the code that powers a regular registrar could also power a bootstrap server. The important difference between the bootstrap server in the draft and a regular client-server SIP registrar is that the bootstrap server only needs to store contact information for a small number of peers in the overlay (say 2 or 3). Best Regards, Eric. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue May 22 21:26:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqfcI-000311-CA; Tue, 22 May 2007 21:26:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqfcG-0002zR-GV for p2psip@ietf.org; Tue, 22 May 2007 21:26:16 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqfcF-00065i-1m for p2psip@ietf.org; Tue, 22 May 2007 21:26:16 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JIG00GYXZY8LU@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 23 May 2007 09:25:20 +0800 (CST) Received: from szxip02-in.huawei.com ([172.24.2.34]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JIG009UJZY8RT@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 23 May 2007 09:25:20 +0800 (CST) Received: from unknown (HELO huawei.com) ([172.24.1.18]) by szxip02-in.huawei.com with ESMTP; Wed, 23 May 2007 09:23:23 +0800 Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JIG008PVZY4M4@szxml03-in.huawei.com> for p2psip@ietf.org; Wed, 23 May 2007 09:25:20 +0800 (CST) Date: Wed, 23 May 2007 09:25:16 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Comments on draft-marocco-p2psip-interwork-01 In-reply-to: <005901c79ca4$6bd5c5d0$6c500a0a@phoenix> X-Sender: w To: 'Eric Cooper' Message-id: <000c01c79cd9$381d0250$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcecpGz2chJ75JorROSR7QSwnJt7igANCJHA X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Eric: > > In draft-matthews-p2psip-bootstrap-mechanisms-00, the bootstrap server need > not be a regular SIP registrar/proxy in the client-server SIP sense, though > we do make the observation that, with minor modifications to the URI > processing, the code that powers a regular registrar could also power a > bootstrap server. The important difference between the bootstrap server in > the draft and a regular client-server SIP registrar is that the bootstrap > server only needs to store contact information for a small number of peers > in the overlay (say 2 or 3). > But the bootstrap server has taken the responsibility to proxy the message for the joining peer. It will mean that bootstrap server should understand the peer protocol, whether it takes SIP or other more general protocol. It will make the bootstrap server more involved in the overlay. IMHO, the basic functionality of bootstrap server is to provide the contact points of the overlay to the joining nodes. Regards! JiangXingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue May 22 23:20:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqhOU-0001Iz-CV; Tue, 22 May 2007 23:20:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqhOS-0001IX-Gs for p2psip@ietf.org; Tue, 22 May 2007 23:20:08 -0400 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqhOS-00014g-2u for p2psip@ietf.org; Tue, 22 May 2007 23:20:08 -0400 Received: by nz-out-0506.google.com with SMTP id z6so61361nzd for ; Tue, 22 May 2007 20:20:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=S+SxgI+cmHoAjX79jWyOyxpZsI5O0F8l2QOrt4Fr2duTS9sgxxTrGhUnCuZg5S+mvuIA+KfcQ9S1i4OegKuqXmq2PievNrakhuzml2rmmcGpFTy8Tz9cW93yR/S5DGYnIb/iO08rjHp+CKFy+urjR4ekzL+MG33FoCx/2inWPzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=WZNOQ5d98/4I7Ks8dNO8S0bCudOvK6+0TmYf5eM7i23qY5CLAH+bOez8+wQXUb4hPaataTYIbRbgjZL16hJBcJon/ky3p606DJ6WxyP0U6zVGcqXPopwtfruxlR1lEbz3+EZeILRr0lhC9FkOWnOYX72Pg2kXxnGMdzSELQb/AU= Received: by 10.114.254.1 with SMTP id b1mr79407wai.1179890406433; Tue, 22 May 2007 20:20:06 -0700 (PDT) Received: by 10.114.124.7 with HTTP; Tue, 22 May 2007 20:20:06 -0700 (PDT) Message-ID: <894e079b0705222020y57a2ebf3nd8c9ba10385a3860@mail.gmail.com> Date: Tue, 22 May 2007 23:20:06 -0400 From: "Medhavi Bhatia" To: JiangXingFeng Subject: Re: [P2PSIP] Comments on draft-marocco-p2psip-interwork-01 In-Reply-To: <000c01c79cd9$381d0250$6905a40a@china.huawei.com> MIME-Version: 1.0 References: <005901c79ca4$6bd5c5d0$6c500a0a@phoenix> <000c01c79cd9$381d0250$6905a40a@china.huawei.com> X-Google-Sender-Auth: a3988baf76110c3c X-Spam-Score: 0.5 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0498846083==" Errors-To: p2psip-bounces@ietf.org --===============0498846083== Content-Type: multipart/alternative; boundary="----=_Part_108247_23241411.1179890406359" ------=_Part_108247_23241411.1179890406359 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jiang, The bootstrap server only forwards a control protocol message (needed to establish control connection between joining peer and the p2p network) and not the p2p messages themselves. I don't think the bootstrap server is really part of the p2p network itself as a logical entity (physically there may be a colocated p2p node). Really we should not mix the bootstrap server (which provides a lightweight function in the p2p network and is required for robustness of the same) with an interworking server which is quite stateful. That wont be a good choice. Medhavi. On 5/22/07, JiangXingFeng wrote: > > Hi, Eric: > > > In draft-matthews-p2psip-bootstrap-mechanisms-00, the bootstrap server > need > > not be a regular SIP registrar/proxy in the client-server SIP sense, > though > > we do make the observation that, with minor modifications to the URI > > processing, the code that powers a regular registrar could also power a > > bootstrap server. The important difference between the bootstrap server > in > > the draft and a regular client-server SIP registrar is that the > bootstrap > > server only needs to store contact information for a small number of > peers > > in the overlay (say 2 or 3). > > > But the bootstrap server has taken the responsibility to proxy the message > for the joining peer. It will mean that bootstrap server should understand > the peer protocol, whether it takes SIP or other more general protocol. It > will make the bootstrap server more involved in the overlay. IMHO, the > basic > functionality of bootstrap server is to provide the contact points of the > overlay to the joining nodes. > > Regards! > > JiangXingFeng > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > ------=_Part_108247_23241411.1179890406359 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jiang,

The bootstrap server only forwards a control protocol message (needed to establish control connection between joining peer and the p2p network) and not the p2p messages themselves. I don't think the bootstrap server is really part of the p2p network itself as a logical entity (physically there may be a colocated p2p node). Really we should not mix the bootstrap server (which provides a lightweight function in the p2p network and is required for robustness of the same) with an interworking server which is quite stateful. That wont be a good choice.

Medhavi.

On 5/22/07, JiangXingFeng <jiang.x.f@huawei.com> wrote:
Hi, Eric: >
> In draft-matthews-p2psip-bootstrap-mechanisms-00, the bootstrap server
need
> not be a regular SIP registrar/proxy in the client-server SIP sense,
though
> we do make the observation that, with minor modifications to the URI
> processing, the code that powers a regular registrar could also power a
> bootstrap server.  The important difference between the bootstrap server
in
> the draft and a regular client-server SIP registrar is that the bootstrap
> server only needs to store contact information for a small number of peers
> in the overlay (say 2 or 3).
>
But the bootstrap server has taken the responsibility to proxy the message
for the joining peer. It will mean that bootstrap server should understand
the peer protocol, whether it takes SIP or other more general protocol. It
will make the bootstrap server more involved in the overlay. IMHO, the basic
functionality of bootstrap server is to provide the contact points of the
overlay to the joining nodes.

Regards!

JiangXingFeng


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

------=_Part_108247_23241411.1179890406359-- --===============0498846083== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0498846083==-- From p2psip-bounces@ietf.org Wed May 23 00:04:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqi5L-0004YD-QX; Wed, 23 May 2007 00:04:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqi5K-0004Y8-N5 for p2psip@ietf.org; Wed, 23 May 2007 00:04:26 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqi5J-0006Aq-2x for p2psip@ietf.org; Wed, 23 May 2007 00:04:26 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JIH00ICH79UUW@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 23 May 2007 12:03:30 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JIH00JPH79UAT@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 23 May 2007 12:03:30 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JIH00GE579QF1@szxml03-in.huawei.com> for p2psip@ietf.org; Wed, 23 May 2007 12:03:30 +0800 (CST) Date: Wed, 23 May 2007 12:03:26 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Comments on draft-marocco-p2psip-interwork-01 In-reply-to: <894e079b0705222020y57a2ebf3nd8c9ba10385a3860@mail.gmail.com> To: 'Medhavi Bhatia' Message-id: <001601c79cef$50debd40$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acec6Uc/iFWSKrT4QZCSyDnSEi7XXQAAxzOw X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Medhavi: >The bootstrap server only forwards a control protocol message (needed to establish >control connection between joining peer and the p2p network) and not the p2p >messages themselves. I don't think the bootstrap server is really part of the p2p >network itself as a logical entity (physically there may be a colocated p2p node). >Really we should not mix the bootstrap server (which provides a lightweight function >in the p2p network and is required for robustness of the same) with an interworking >server which is quite stateful. That wont be a good choice. In my opinion, I also like the independence of bootstrap server from the P2P network. It had better only provide service for joining peer to find out existing peers in the overlay. In the bootstrap draft and concept draft, bootstrap server should proxy message between the joining peer and bootstrap peer especially if there are intervening NATs between them. The typical message will be join message, which is embodied as an INVITE message in dSIP solution. In the bootstrap draft, when bootstrap server forwards the INVITE message, it has to modify the message to make the bootstrap peer process the message correctly. IMHO, I think these messages are P2P messages. Comments? Regards! JiangXingfeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed May 23 10:23:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqrjv-0001rU-Qh; Wed, 23 May 2007 10:22:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqrju-0001rP-Of for p2psip@ietf.org; Wed, 23 May 2007 10:22:58 -0400 Received: from bay0-omc3-s21.bay0.hotmail.com ([65.54.246.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqrjt-0002bw-CH for p2psip@ietf.org; Wed, 23 May 2007 10:22:58 -0400 Received: from BAYC1-PASMTP03.CEZ.ICE ([65.54.191.163]) by bay0-omc3-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 23 May 2007 07:22:56 -0700 X-Originating-IP: [216.13.42.68] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from phoenix ([216.13.42.68]) by BAYC1-PASMTP03.CEZ.ICE over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2668); Wed, 23 May 2007 07:22:56 -0700 Message-ID: <003901c79d45$db1ccaf0$6c500a0a@phoenix> From: "Eric Cooper" To: "JiangXingFeng" References: <000c01c79cd9$381d0250$6905a40a@china.huawei.com> Subject: Re: [P2PSIP] Comments on draft-marocco-p2psip-interwork-01 Date: Wed, 23 May 2007 10:22:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 23 May 2007 14:22:56.0760 (UTC) FILETIME=[DBB31780:01C79D45] X-Spam-Score: 2.2 (++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi JiangXingFeng, In the bootstrap draft, one of the major ideas is that we'll use SIP to establish peer protocol connections. This is analogous to the way SIP is used to establish RTP connections for VoIP calls. So, I don't think it is necessary for the bootstrap server to understand the peer protocol (much like the way a pure SIP proxy doesn't need to understand RTP). In the bootstrap draft, we have not said that the peer protocol should be SIP. We took no position whatsoever on that point. As the group explores the requirements for the peer protocol further, it may decide that it is a requirement that the peer protocol be able to establish its own connections. Such a decision would make the bootstrap draft's usage of SIP obsolete. The concepts of bootstrap servers and bootstrap peers may or may not survive. You are right that the basic function of the bootstrap server is to provide contact points to peers joining the the overlay. That is our intention and we thought it was useful to separate that function from the other operations a p2p overlay will require. Best Regards, Eric. ----- Original Message ----- From: "JiangXingFeng" To: "'Eric Cooper'" Cc: Sent: Tuesday, May 22, 2007 9:25 PM Subject: RE: [P2PSIP] Comments on draft-marocco-p2psip-interwork-01 > Hi, Eric: > >> In draft-matthews-p2psip-bootstrap-mechanisms-00, the bootstrap server > need >> not be a regular SIP registrar/proxy in the client-server SIP sense, > though >> we do make the observation that, with minor modifications to the URI >> processing, the code that powers a regular registrar could also power a >> bootstrap server. The important difference between the bootstrap server > in >> the draft and a regular client-server SIP registrar is that the bootstrap >> server only needs to store contact information for a small number of >> peers >> in the overlay (say 2 or 3). >> > But the bootstrap server has taken the responsibility to proxy the message > for the joining peer. It will mean that bootstrap server should understand > the peer protocol, whether it takes SIP or other more general protocol. It > will make the bootstrap server more involved in the overlay. IMHO, the > basic > functionality of bootstrap server is to provide the contact points of the > overlay to the joining nodes. > > Regards! > > JiangXingFeng > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip