From michaelc@idssoftware.com Thu Oct 1 13:37:07 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7607A3A6AB9 for ; Thu, 1 Oct 2009 13:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmcDC82qHrVm for ; Thu, 1 Oct 2009 13:37:06 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 8ADAC3A69C1 for ; Thu, 1 Oct 2009 13:37:06 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MtSQ4-0000Nf-8d; Thu, 01 Oct 2009 16:38:32 -0400 Message-ID: <4AC5149A.1090308@idssoftware.com> Date: Thu, 01 Oct 2009 13:44:10 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <4AC41D9B.1040504@idssoftware.com> <8BA1841D-F629-4243-8D0B-CDA730BDB942@rtfm.com> In-Reply-To: <8BA1841D-F629-4243-8D0B-CDA730BDB942@rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940ce431b4c074436f711d9d119d6846a73350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] D/TLS with client authentication X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 20:37:07 -0000 Eric Rescorla wrote: > > > On Sep 30, 2009, at 8:10 PM, Michael Chen > wrote: > >> Hi, >> >> In an earlier thread, David A. Bryan asked about implementation >> experience of this draft. Two things pop out immediately from my head >> (they both feel like reinventing the wheel): >> >> 1. Digital signature related requirements seem rehashing what's being >> done in TLS and DTLS. >> 2. Fragmentation handling seems to be reinventing TCP using UDP. >> >> The second one may be unfounded, but I like to toss around an idea >> while implementing the first. What if this draft mandates the >> following regarding TLS and DTLS connections: >> >> A. Client authentication is required for all TLS and DTLS connections; >> B. Both parties (peers) in a D/TLS connection uses the same digital >> credentials (certificates and public/private keys) for the DHT overlay. >> >> For example, say peer X connects to peer Y via TLS. X will get Y's >> overlay certificates and public key during the first part of the TLS >> handshake. Then Y request X (the 'client') to send its certificates >> and public key during client authentication. The TLS session will be >> honored if and only if the overlay information in the certificates >> are validated on both sides. This is fully supported by TLS and DTLS >> (plus a few callbacks). > > This is already true I don't see this being explained in the draft. Are you saying it based on implementation? > > >> The level of trust established this way is equivalent to that >> provided by the current draft-03. The intend is that with these >> mandates, the RELOAD protocol itself can be simplified by removing >> all certificate and signature related requirements. For example, in >> my earlier post, an overhead of 1292 bytes can be trimmed down to >> only 69 bytes!!! (removing the security block and the STORE signature). > >> I still need to think about messages forwarded by instead of >> originated from a peer, but let the discussion begin. > > Uh this is the base case. Which is why the messages have signatures > > Ekr Let's give it some more thought. With client authentication, any two directly connected peers "trust" each other based on their overlay credentials. Therefore, single hop messages like DHT stablization can be exchanged between them with no signature/certificates attached. That's a great saving to consider. If a message is forwarded, say X->Y->Z, Y can doing man in the middle attack. For Z to truly ensure that the message is from X, Z must FETCH X's certificate from the overlay to verify the signature. For that reason, sending the certificate has no real security meaning. --Michael From ekr@rtfm.com Thu Oct 1 13:49:57 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48443A69B1 for ; Thu, 1 Oct 2009 13:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njNJBXQPeD79 for ; Thu, 1 Oct 2009 13:49:57 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id EF67A3A69A1 for ; Thu, 1 Oct 2009 13:49:56 -0700 (PDT) Received: by ywh13 with SMTP id 13so645020ywh.31 for ; Thu, 01 Oct 2009 13:51:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.174.7 with SMTP id w7mr948727age.11.1254430280189; Thu, 01 Oct 2009 13:51:20 -0700 (PDT) In-Reply-To: <4AC5149A.1090308@idssoftware.com> References: <4AC41D9B.1040504@idssoftware.com> <8BA1841D-F629-4243-8D0B-CDA730BDB942@rtfm.com> <4AC5149A.1090308@idssoftware.com> Date: Thu, 1 Oct 2009 13:51:20 -0700 Message-ID: From: Eric Rescorla To: Michael Chen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] D/TLS with client authentication X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 20:49:58 -0000 On Thu, Oct 1, 2009 at 1:44 PM, Michael Chen wro= te: > Eric Rescorla wrote: >> This is already true > > I don't see this being explained in the draft. Are you saying it based on > implementation? 5.5.1.13. The procedures of Section 11 apply to RELOAD as well. However, in this case, the "media" takes the form of application layer protocols (RELOAD or SIP for example) over TLS or DTLS. Consequently, once ICE processing completes, the agent will begin TLS or DTLS procedures to establish a secure connection. The node which sent the Attach request MUST be the TLS server. The other node MUST be the TLS client. The nodes MUST verify that the certificate presented in the handshake matches the identity of the other peer as found in the Attach message. Once the TLS or DTLS signaling is complete, the application protocol is free to use the connection. 12.6.2. Admission to an RELOAD Overlay Instance is controlled by requiring that each peer have a certificate containing its peer ID. The requirement to have a certificate is enforced by using certificate- based mutual authentication on each connection. >>> The level of trust established this way is equivalent to that provided = by >>> the current draft-03. The intend is that with these mandates, the RELOA= D >>> protocol itself can be simplified by removing all certificate and signa= ture >>> related requirements. =A0For example, in my earlier post, an overhead o= f 1292 >>> bytes can be trimmed down to only 69 bytes!!! (removing the security bl= ock >>> and the STORE signature). >> >>> I still need to think about messages forwarded by instead of originated >>> from a peer, but let the discussion begin. >> >> Uh this is the base case. Which is why the messages have signatures >> >> Ekr > > Let's give it some more thought. With client authentication, any two > directly connected peers "trust" each other based on their overlay > credentials. =A0Therefore, single hop messages like DHT stablization can = be > exchanged between them with no signature/certificates attached. =A0That's= a > great saving to consider. Yes, this is a potential optimization. But unless something is seriously wrong with the design (or the overlay is essentially quiescent), then this sort of stabilization traffic should be a small amount of the overall traffic, so it's not clear what the overall savings is. > If a message is forwarded, say X->Y->Z, Y can doing man in the middle > attack. For Z to truly ensure that the message is from X, Z must FETCH X'= s > certificate from the overlay to verify the signature. For that reason, > sending the certificate has no real security meaning. No, this is not correct. Certificates are independently verifiable by chain= ing back to the overlay's root key. That's pretty much the point of certificate= s: you can verify them no matter how you received them. Now, it's true that there is no SECURITY value in sending the certificate along with the message. Data origin authentication authentication is suppli= ed by a digital signature computed using the private key that corresponds to the public key in the certificate. The certificate is attached to the messa= ge to avoid the complexity of a system where you have to hold the message while you try to retrieve the certificate. -Ekr From jouni.maenpaa@ericsson.com Thu Oct 1 22:49:41 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FA93A69EB for ; Thu, 1 Oct 2009 22:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.282 X-Spam-Level: X-Spam-Status: No, score=-5.282 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE4ZnVDYwt27 for ; Thu, 1 Oct 2009 22:49:40 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1AA833A68C3 for ; Thu, 1 Oct 2009 22:49:39 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000003d08-b8-4ac594c9933d Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id C2.CF.15624.9C495CA4; Fri, 2 Oct 2009 07:51:05 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 07:49:49 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 07:49:49 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8799E24EC; Fri, 2 Oct 2009 08:49:48 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 531D721A1F; Fri, 2 Oct 2009 08:49:48 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 07BF1219CB; Fri, 2 Oct 2009 08:49:48 +0300 (EEST) Message-ID: <4AC5947B.1080101@ericsson.com> Date: Fri, 02 Oct 2009 08:49:47 +0300 From: =?ISO-8859-1?Q?Jouni_M=E4enp=E4=E4?= User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Eric Rescorla References: <4AC41D9B.1040504@idssoftware.com> <8BA1841D-F629-4243-8D0B-CDA730BDB942@rtfm.com> <4AC5149A.1090308@idssoftware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 02 Oct 2009 05:49:49.0502 (UTC) FILETIME=[278E95E0:01CA4324] X-Brightmail-Tracker: AAAAAA== Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] D/TLS with client authentication X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 05:49:41 -0000 Hi, >> Let's give it some more thought. With client authentication, any two >> directly connected peers "trust" each other based on their overlay >> credentials. Therefore, single hop messages like DHT stablization can be >> exchanged between them with no signature/certificates attached. That's a >> great saving to consider. > > Yes, this is a potential optimization. But unless something is seriously > wrong with the design (or the overlay is essentially quiescent), then > this sort of stabilization traffic should be a small amount of the overall > traffic, so it's not clear what the overall savings is. Just one comment. I agree that if the overlay is experiencing very little or no churn at all, the amount of stabilization traffic is rather low. However, based on my experiences of running a P2P overlay in PlanetLab, I would say that if the overlay is churning even at a moderate rate, optimizations like this might well be worth doing. When there is churn, you need to increase the amount of stabilization messages and it is not unusual that a considerable percentage of the total traffic is stabilization traffic. -Jouni From michaelc@idssoftware.com Fri Oct 2 07:13:47 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F31228C12B for ; Fri, 2 Oct 2009 07:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZuXEGwt2Jz8 for ; Fri, 2 Oct 2009 07:13:46 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id E0D5428C129 for ; Fri, 2 Oct 2009 07:13:45 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Mtiud-00046H-JF; Fri, 02 Oct 2009 10:15:11 -0400 Message-ID: <4AC60C42.8040507@idssoftware.com> Date: Fri, 02 Oct 2009 07:20:50 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <4AC41D9B.1040504@idssoftware.com> <8BA1841D-F629-4243-8D0B-CDA730BDB942@rtfm.com> <4AC5149A.1090308@idssoftware.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000302040503080506080804" X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940596876057979c35242e96ae4f5778b4f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] D/TLS with client authentication X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 14:13:47 -0000 This is a multi-part message in MIME format. --------------000302040503080506080804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric, Eric Rescorla wrote: > On Thu, Oct 1, 2009 at 1:44 PM, Michael Chen wrote: > >> Eric Rescorla wrote: >> >>> This is already true >>> >> I don't see this being explained in the draft. Are you saying it based on >> implementation? >> > > 5.5.1.13. > > The procedures of Section 11 apply to RELOAD as well. However, in > this case, the "media" takes the form of application layer protocols > (RELOAD or SIP for example) over TLS or DTLS. Consequently, once ICE > processing completes, the agent will begin TLS or DTLS procedures to > establish a secure connection. The node which sent the Attach > request MUST be the TLS server. The other node MUST be the TLS > client. The nodes MUST verify that the certificate presented in the > handshake matches the identity of the other peer as found in the > Attach message. Once the TLS or DTLS signaling is complete, the > application protocol is free to use the connection. > This is vague. It should be explicitly stated using SSL terminology "client authentication". SSL started as a client-server protocol, and in its most common use HTTPS, clients are almost always anonymous. This draft should be explicit about the client authentication mandate. > 12.6.2. > > Admission to an RELOAD Overlay Instance is controlled by requiring > that each peer have a certificate containing its peer ID. The > requirement to have a certificate is enforced by using certificate- > based mutual authentication on each connection. > Here should again explicitly echo that mutual authentication refers to TLS/DTLS server and client authentication during handshake. >>>> The level of trust established this way is equivalent to that provided by >>>> the current draft-03. The intend is that with these mandates, the RELOAD >>>> protocol itself can be simplified by removing all certificate and signature >>>> related requirements. For example, in my earlier post, an overhead of 1292 >>>> bytes can be trimmed down to only 69 bytes!!! (removing the security block >>>> and the STORE signature). >>>> >>>> I still need to think about messages forwarded by instead of originated >>>> from a peer, but let the discussion begin. >>>> >>> Uh this is the base case. Which is why the messages have signatures >>> >>> Ekr >>> >> Let's give it some more thought. With client authentication, any two >> directly connected peers "trust" each other based on their overlay >> credentials. Therefore, single hop messages like DHT stablization can be >> exchanged between them with no signature/certificates attached. That's a >> great saving to consider. >> > > Yes, this is a potential optimization. But unless something is seriously > wrong with the design (or the overlay is essentially quiescent), then > this sort of stabilization traffic should be a small amount of the overall > traffic, so it's not clear what the overall savings is. > This optimization requires hardly any effort either in your part to write or in mine to implement. A short paragraph in the draft saying, "If the message is originated from a directly connected peer, the security block may contain a zero length certificates list, zero length signer ID and zero length signature." >> If a message is forwarded, say X->Y->Z, Y can doing man in the middle >> attack. For Z to truly ensure that the message is from X, Z must FETCH X's >> certificate from the overlay to verify the signature. For that reason, >> sending the certificate has no real security meaning. >> > No, this is not correct. Certificates are independently verifiable by chaining > back to the overlay's root key. That's pretty much the point of certificates: > you can verify them no matter how you received them. > In the attack by Y described above, Y would sign and put its own certificate chain in the security block, so the whole message is verifiably correct. The only way Z can know this is an attack is by enforcing other constrain of this draft. For example, if the STORE resource ID is between Y and Z, then this is an attack. Aha! What if the resource ID in X's request is between X and Y or before X in the ring? Then Z will never notice the attack. Y can map calls to X@domain to Y's destination list. Am I right? > Now, it's true that there is no SECURITY value in sending the certificate > along with the message. Data origin authentication authentication is supplied > by a digital signature computed using the private key that corresponds to > the public key in the certificate. The certificate is attached to the message > to avoid the complexity of a system where you have to hold the message > while you try to retrieve the certificate. > > -Ek A security warning should be included in this draft about the potential danger of trusting the certificate in the SecurityBlock. It's the proper thing to do. One more thing about SecurityBlock.certificates, in an overlay that requires an enrollment server, what is the use case in which the peer's certificate is not issued/signed by the enrollment server? In another word, what is the use case where SecurityBlock.certificates contains more than one (the peer's) certificate? By the way, there is no need to include the certificate chain that issued the enrollment server's certificate, because that chain would have been verified during enrollment by each peer. Thanks --Michael --------------000302040503080506080804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eric,

Eric Rescorla wrote: 
On Thu, Oct 1, 2009 at 1:44 PM, Michael Chen <michaelc@idssoftware.com> wrote:
  
Eric Rescorla wrote:
    
This is already true
      
I don't see this being explained in the draft. Are you saying it based on
implementation?
    

5.5.1.13.

   The procedures of Section 11 apply to RELOAD as well.  However, in
   this case, the "media" takes the form of application layer protocols
   (RELOAD or SIP for example) over TLS or DTLS.  Consequently, once ICE
   processing completes, the agent will begin TLS or DTLS procedures to
   establish a secure connection.  The node which sent the Attach
   request MUST be the TLS server.  The other node MUST be the TLS
   client.  The nodes MUST verify that the certificate presented in the
   handshake matches the identity of the other peer as found in the
   Attach message.  Once the TLS or DTLS signaling is complete, the
   application protocol is free to use the connection.
This is vague. It should be explicitly stated using SSL terminology "client authentication". SSL started as a client-server protocol, and in its most common use HTTPS, clients are almost always anonymous. This draft should be explicit about the client authentication mandate.

12.6.2.

  Admission to an RELOAD Overlay Instance is controlled by requiring
  that each peer have a certificate containing its peer ID.  The
  requirement to have a certificate is enforced by using certificate-
  based mutual authentication on each connection.
Here should again explicitly echo that mutual authentication refers to TLS/DTLS server and client authentication during handshake.

The level of trust established this way is equivalent to that provided by
the current draft-03. The intend is that with these mandates, the RELOAD
protocol itself can be simplified by removing all certificate and signature
related requirements.  For example, in my earlier post, an overhead of 1292
bytes can be trimmed down to only 69 bytes!!! (removing the security block
and the STORE signature).
        
I still need to think about messages forwarded by instead of originated
from a peer, but let the discussion begin.
        
Uh this is the base case. Which is why the messages have signatures

Ekr
      
Let's give it some more thought. With client authentication, any two
directly connected peers "trust" each other based on their overlay
credentials.  Therefore, single hop messages like DHT stablization can be
exchanged between them with no signature/certificates attached.  That's a
great saving to consider.
    

Yes, this is a potential optimization. But unless something is seriously
wrong with the design (or the overlay is essentially quiescent), then
this sort of stabilization traffic should be a small amount of the overall
traffic, so it's not clear what the overall savings is.
This optimization requires hardly any effort either in your part to write or in mine to implement. A short paragraph in the draft saying, "If the message is originated from a directly connected peer, the security block may contain a zero length certificates list, zero length signer ID and zero length signature."

If a message is forwarded, say X->Y->Z, Y can doing man in the middle
attack. For Z to truly ensure that the message is from X, Z must FETCH X's
certificate from the overlay to verify the signature. For that reason,
sending the certificate has no real security meaning.
    
No, this is not correct. Certificates are independently verifiable by chaining
back to the overlay's root key. That's pretty much the point of certificates:
you can verify them no matter how you received them.
In the attack by Y described above, Y would sign and put its own certificate chain in the security block, so the whole message is verifiably correct. The only way Z can know this is an attack is by enforcing other constrain of this draft.  For example, if the STORE resource ID is between Y and Z, then this is an attack.

Aha! What if the resource ID in X's request is between X and Y or before X in the ring? Then Z will never notice the attack.  Y can map calls to X@domain to Y's destination list.  Am I right?

Now, it's true that there is no SECURITY value in sending the certificate
along with the message. Data origin authentication authentication is supplied
by a digital signature computed using the private key that corresponds to
the public key in the certificate. The certificate is attached to the message
to avoid the complexity of a system where you have to hold the message
while you try to retrieve the certificate.

-Ek
A security warning should be included in this draft about the potential danger of trusting the certificate in the SecurityBlock. It's the proper thing to do.

One more thing about SecurityBlock.certificates, in an overlay that requires an enrollment server, what is the use case in which the peer's certificate is not issued/signed by the enrollment server?  In another word, what is the use case where SecurityBlock.certificates contains more than one (the peer's) certificate?

By the way, there is no need to include the certificate chain that issued the enrollment server's certificate, because that chain would have been verified during enrollment by each peer.

Thanks

--Michael
--------------000302040503080506080804-- From ekr@networkresonance.com Fri Oct 2 07:39:06 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE1D3A685A for ; Fri, 2 Oct 2009 07:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[AWL=-1.330, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FebXiyYHC6bY for ; Fri, 2 Oct 2009 07:39:05 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 353073A6821 for ; Fri, 2 Oct 2009 07:39:05 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 5D3155D1FEA; Fri, 2 Oct 2009 07:46:14 -0700 (PDT) Date: Fri, 02 Oct 2009 07:46:13 -0700 From: Eric Rescorla To: Michael Chen In-Reply-To: <4AC60C42.8040507@idssoftware.com> References: <4AC41D9B.1040504@idssoftware.com> <8BA1841D-F629-4243-8D0B-CDA730BDB942@rtfm.com> <4AC5149A.1090308@idssoftware.com> <4AC60C42.8040507@idssoftware.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091002144614.5D3155D1FEA@kilo.networkresonance.com> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] D/TLS with client authentication X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 14:39:06 -0000 At Fri, 02 Oct 2009 07:20:50 -0700, Michael Chen wrote: > > 5.5.1.13. > > > > The procedures of Section 11 apply to RELOAD as well. However, in > > this case, the "media" takes the form of application layer protocols > > (RELOAD or SIP for example) over TLS or DTLS. Consequently, once ICE > > processing completes, the agent will begin TLS or DTLS procedures to > > establish a secure connection. The node which sent the Attach > > request MUST be the TLS server. The other node MUST be the TLS > > client. The nodes MUST verify that the certificate presented in the > > handshake matches the identity of the other peer as found in the > > Attach message. Once the TLS or DTLS signaling is complete, the > > application protocol is free to use the connection. > > > This is vague. It should be explicitly stated using SSL terminology > "client authentication". SSL started as a client-server protocol, and in > its most common use HTTPS, clients are almost always anonymous. This > draft should be explicit about the client authentication mandate. I'll take a look at doing this, but as usual, it would help if you send text. > > Yes, this is a potential optimization. But unless something is seriously > > wrong with the design (or the overlay is essentially quiescent), then > > this sort of stabilization traffic should be a small amount of the overall > > traffic, so it's not clear what the overall savings is. > > > This optimization requires hardly any effort either in your part to > write or in mine to implement. A short paragraph in the draft saying, > "If the message is originated from a directly connected peer, the > security block may contain a zero length certificates list, zero length > signer ID and zero length signature." I'm not convinced this is that simple: it requires carrying this origin information from the connection level around to the signature processing level, as well as new logic for the sender to know when this is safe or not. That's new logic and new code paths, which means new things to get wrong--bad in security systems. I'd like to see some data suggesting this is an important optimization. > >> If a message is forwarded, say X->Y->Z, Y can doing man in the middle > >> attack. For Z to truly ensure that the message is from X, Z must FETCH X's > >> certificate from the overlay to verify the signature. For that reason, > >> sending the certificate has no real security meaning. > >> > > No, this is not correct. Certificates are independently verifiable by chaining > > back to the overlay's root key. That's pretty much the point of certificates: > > you can verify them no matter how you received them. > > > In the attack by Y described above, Y would sign and put its own > certificate chain in the security block, so the whole message is > verifiably correct. The only way Z can know this is an attack is by > enforcing other constrain of this draft. For example, if the STORE > resource ID is between Y and Z, then this is an attack. Huh? How is it in attack for Y to take a message originated by X and claim it was originated by itself? Y can always generate any message it wants and sign it. That's how signature-based message authentication works. Moreover, why would this be an attack on X or Z, since Y is *legitimately* allowed to generate messages and Z would (correctly) conclude that the message came from Y, not X. The fact that Y is copying X's message is irrelevant. > Aha! What if the resource ID in X's request is between X and Y or before > X in the ring? Then Z will never notice the attack. Y can map calls to > X@domain to Y's destination list. Am I right? I have no idea what you are talking about. > > Now, it's true that there is no SECURITY value in sending the certificate > > along with the message. Data origin authentication authentication is supplied > > by a digital signature computed using the private key that corresponds to > > the public key in the certificate. The certificate is attached to the message > > to avoid the complexity of a system where you have to hold the message > > while you try to retrieve the certificate. > > > > -Ek > A security warning should be included in this draft about the potential > danger of trusting the certificate in the SecurityBlock. It's the proper > thing to do. I don't understand what you're talking about here either. The cryptographic elements of an authenticated message in RELOAD are: - The contents - A signature, generated using the sender's private key - The sender's identity - A certificate binding the sender's public key to the sender's identity. In order to validate this, the verifier needs to: - Verify the signature on the certificate (using the CA's public key, which is known a priori) - Verify that the sender's identity matches the identity in the certificate - Verify that the signature on the contents is correct (using the sender's public key, which is found in the certificate). This can be (needs to be) done regardless of the provenance of the certificate because the certificate is directly verifiable. The system does not depend on the certificate being provided by a trusted source. The only time when you do not need to verify the certificate is if you have previously verified it and cached the result. You never trust that the certificate is correct otherwise. > One more thing about SecurityBlock.certificates, in an overlay that > requires an enrollment server, what is the use case in which the peer's > certificate is not issued/signed by the enrollment server? In another > word, what is the use case where SecurityBlock.certificates contains > more than one (the peer's) certificate? When there are elements which need to be verified with different certificates. For instance, if node A stores a value with node B, which then does a replica store to node C, then the B->C store will have two signatures: - The signature over the value, using A's key - The signature over the message, using B's key The SecurityBlock will then contain both A and B's certificates. -Ekr From michaelc@idssoftware.com Fri Oct 2 12:09:48 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628FD3A681C for ; Fri, 2 Oct 2009 12:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnvxU2jQUobn for ; Fri, 2 Oct 2009 12:09:47 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 45DEA3A659B for ; Fri, 2 Oct 2009 12:09:47 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MtnX8-0007k4-PY; Fri, 02 Oct 2009 15:11:14 -0400 Message-ID: <4AC651A6.1050008@idssoftware.com> Date: Fri, 02 Oct 2009 12:16:54 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <4AC41D9B.1040504@idssoftware.com> <8BA1841D-F629-4243-8D0B-CDA730BDB942@rtfm.com> <4AC5149A.1090308@idssoftware.com> <4AC60C42.8040507@idssoftware.com> <20091002144614.5D3155D1FEA@kilo.networkresonance.com> In-Reply-To: <20091002144614.5D3155D1FEA@kilo.networkresonance.com> Content-Type: multipart/alternative; boundary="------------040603090902050701090108" X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940c20839c0a6007fc6e3735a6f8903a470350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] D/TLS with client authentication X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 19:09:48 -0000 This is a multi-part message in MIME format. --------------040603090902050701090108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Rescorla wrote: >>>> If a message is forwarded, say X->Y->Z, Y can doing man in the middle >>>> attack. For Z to truly ensure that the message is from X, Z must FETCH X's >>>> certificate from the overlay to verify the signature. For that reason, >>>> sending the certificate has no real security meaning. >>>> >>>> >>> No, this is not correct. Certificates are independently verifiable by chaining >>> back to the overlay's root key. That's pretty much the point of certificates: >>> you can verify them no matter how you received them. >>> >>> >> In the attack by Y described above, Y would sign and put its own >> certificate chain in the security block, so the whole message is >> verifiably correct. The only way Z can know this is an attack is by >> enforcing other constrain of this draft. For example, if the STORE >> resource ID is between Y and Z, then this is an attack. >> > Huh? > > How is it in attack for Y to take a message originated by X and > claim it was originated by itself? Y can always generate any message > it wants and sign it. That's how signature-based message authentication > works. Moreover, why would this be an attack on X or Z, since Y > is *legitimately* allowed to generate messages and Z would > (correctly) conclude that the message came from Y, not X. The > fact that Y is copying X's message is irrelevant. > >> Aha! What if the resource ID in X's request is between X and Y or before >> X in the ring? Then Z will never notice the attack. Y can map calls to >> X@domain to Y's destination list. Am I right? >> > I have no idea what you are talking about. > Let me try again. Say X just joint the overlay, and its logical position in the ring is X->Y->Z. The overlay has no record of how to contact X. X hash his AoR "X@domain" to its resource ID Rx. Just so happen that the logical position of Rx is Y->Rx->Z. X sends a STORE message via Y to Z that maps Rx to Dx, where Dx is X's destination list. When Y receives this STORE message from X, it replaces Dx with Dy, where Dy is Y's destination list. Then Y sign the message with Y's own cert before forwarding it to Z. The message seems legitimate to Z, so it stores the mapping of Rx to Dy. When A wants to call "X@domain" and FETCH Rx from Z, A gets Dy. A's call to X goes to Y. X can find out about Y's attack when X FETCH Rx from Z. Y does not have an effective attack on the FETCH message, because Y's node-ID is in front of Rx (Y->Rx->Z) and cannot be the owner of Rx. Thanks --Michael --------------040603090902050701090108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eric Rescorla wrote: 
If a message is forwarded, say X->Y->Z, Y can doing man in the middle
attack. For Z to truly ensure that the message is from X, Z must FETCH X's
certificate from the overlay to verify the signature. For that reason,
sending the certificate has no real security meaning.
    
        
No, this is not correct. Certificates are independently verifiable by chaining
back to the overlay's root key. That's pretty much the point of certificates:
you can verify them no matter how you received them.
  
      
In the attack by Y described above, Y would sign and put its own 
certificate chain in the security block, so the whole message is 
verifiably correct. The only way Z can know this is an attack is by 
enforcing other constrain of this draft.  For example, if the STORE 
resource ID is between Y and Z, then this is an attack.
    
Huh?

How is it in attack for Y to take a message originated by X and 
claim it was originated by itself? Y can always generate any message
it wants and sign it. That's how signature-based message authentication
works. Moreover, why would this be an attack on X or Z, since Y
is *legitimately* allowed to generate messages and Z would
(correctly) conclude that the message came from Y, not X. The
fact that Y is copying X's message is irrelevant.
  
Aha! What if the resource ID in X's request is between X and Y or before 
X in the ring? Then Z will never notice the attack.  Y can map calls to 
X@domain to Y's destination list.  Am I right?
    
I have no idea what you are talking about.
Let me try again. Say X just joint the overlay, and its logical position in the ring is X->Y->Z. The overlay has no record of how to contact X. X hash his AoR "X@domain" to its resource ID Rx. Just so happen that the logical position of Rx is Y->Rx->Z. X sends a STORE message via Y to Z that maps Rx to Dx, where Dx is X's destination list.

When Y receives this STORE message from X, it replaces Dx with Dy, where Dy is Y's destination list. Then Y sign the message with Y's own cert before forwarding it to Z. The message seems legitimate to Z, so it stores the mapping of Rx to Dy.  When A wants to call "X@domain" and FETCH Rx from Z, A gets Dy. A's call to X goes to Y.

X can find out about Y's attack when X FETCH Rx from Z.  Y does not have an effective attack on the FETCH message, because Y's node-ID is in front of Rx (Y->Rx->Z) and cannot be the owner of Rx.

Thanks

--Michael
--------------040603090902050701090108-- From michaelc@idssoftware.com Fri Oct 2 12:55:16 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830423A686E for ; Fri, 2 Oct 2009 12:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYK8hph51q5W for ; Fri, 2 Oct 2009 12:55:15 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 34AFC3A67C1 for ; Fri, 2 Oct 2009 12:55:15 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MtoF9-0004lS-5v; Fri, 02 Oct 2009 15:56:43 -0400 Message-ID: <4AC65C4F.6010501@idssoftware.com> Date: Fri, 02 Oct 2009 13:02:23 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <4AC41D9B.1040504@idssoftware.com> <8BA1841D-F629-4243-8D0B-CDA730BDB942@rtfm.com> <4AC5149A.1090308@idssoftware.com> <4AC60C42.8040507@idssoftware.com> <20091002144614.5D3155D1FEA@kilo.networkresonance.com> In-Reply-To: <20091002144614.5D3155D1FEA@kilo.networkresonance.com> Content-Type: multipart/alternative; boundary="------------020103020704090804060507" X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940b60c757ef8a3994ddba3f040fe12ad6e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] D/TLS with client authentication X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 19:55:16 -0000 This is a multi-part message in MIME format. --------------020103020704090804060507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric, In my list post, Z can discover Y's attack if the AoR itself "X@domain" is included in the STORE such that hash("X@domain") = Rx. Since the message is resigned by Y, so Z can conclude that it's illegal for Y to STORE an AoR of "X@domain". Y can only STORE an AoR of "Y@domain" (unless of course a replica). If I am not mistaken, the current STORE does not send the AoR, only the resource ID Rx. Then Z cannot verify how Rx was calculated and cannot discover that Y is storing "X@domain". --Michael Eric Rescorla wrote: > At Fri, 02 Oct 2009 07:20:50 -0700, > Michael Chen wrote: > >>>> If a message is forwarded, say X->Y->Z, Y can doing man in the middle >>>> attack. For Z to truly ensure that the message is from X, Z must FETCH X's >>>> certificate from the overlay to verify the signature. For that reason, >>>> sending the certificate has no real security meaning. >>>> >>>> >>> No, this is not correct. Certificates are independently verifiable by chaining >>> back to the overlay's root key. That's pretty much the point of certificates: >>> you can verify them no matter how you received them. >>> >>> >> In the attack by Y described above, Y would sign and put its own >> certificate chain in the security block, so the whole message is >> verifiably correct. The only way Z can know this is an attack is by >> enforcing other constrain of this draft. For example, if the STORE >> resource ID is between Y and Z, then this is an attack. >> > > Huh? > > How is it in attack for Y to take a message originated by X and > claim it was originated by itself? Y can always generate any message > it wants and sign it. That's how signature-based message authentication > works. Moreover, why would this be an attack on X or Z, since Y > is *legitimately* allowed to generate messages and Z would > (correctly) conclude that the message came from Y, not X. The > fact that Y is copying X's message is irrelevant. > > > >> Aha! What if the resource ID in X's request is between X and Y or before >> X in the ring? Then Z will never notice the attack. Y can map calls to >> X@domain to Y's destination list. Am I right? >> > > I have no idea what you are talking about. > > > >>> Now, it's true that there is no SECURITY value in sending the certificate >>> along with the message. Data origin authentication authentication is supplied >>> by a digital signature computed using the private key that corresponds to >>> the public key in the certificate. The certificate is attached to the message >>> to avoid the complexity of a system where you have to hold the message >>> while you try to retrieve the certificate. >>> >>> -Ek >>> >> A security warning should be included in this draft about the potential >> danger of trusting the certificate in the SecurityBlock. It's the proper >> thing to do. >> > > I don't understand what you're talking about here either. > > The cryptographic elements of an authenticated message in RELOAD > are: > > - The contents > - A signature, generated using the sender's private key > - The sender's identity > - A certificate binding the sender's public key to the sender's > identity. > > In order to validate this, the verifier needs to: > > - Verify the signature on the certificate (using the CA's public > key, which is known a priori) > - Verify that the sender's identity matches the identity in the > certificate > - Verify that the signature on the contents is correct > (using the sender's public key, which is found in the > certificate). > > This can be (needs to be) done regardless of the provenance of the > certificate because the certificate is directly verifiable. The > system does not depend on the certificate being provided by > a trusted source. > > The only time when you do not need to verify the certificate is > if you have previously verified it and cached the result. You > never trust that the certificate is correct otherwise. > > > >> One more thing about SecurityBlock.certificates, in an overlay that >> requires an enrollment server, what is the use case in which the peer's >> certificate is not issued/signed by the enrollment server? In another >> word, what is the use case where SecurityBlock.certificates contains >> more than one (the peer's) certificate? >> > > When there are elements which need to be verified with different > certificates. For instance, if node A stores a value with node > B, which then does a replica store to node C, then the B->C > store will have two signatures: > > - The signature over the value, using A's key > - The signature over the message, using B's key > > The SecurityBlock will then contain both A and B's certificates. > > -Ekr --------------020103020704090804060507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eric,

In my list post, Z can discover Y's attack if the AoR itself "X@domain" is included in the STORE such that  hash("X@domain") = Rx.  Since the message is resigned by Y, so Z can conclude that it's illegal for Y to STORE an AoR of "X@domain".  Y can only STORE an AoR of "Y@domain" (unless of course a replica).

If I am not mistaken, the current STORE does not send the AoR, only the resource ID Rx. Then Z cannot verify how Rx was calculated and cannot discover that Y is storing "X@domain".

--Michael

Eric Rescorla wrote: 
At Fri, 02 Oct 2009 07:20:50 -0700,
Michael Chen wrote:
  
If a message is forwarded, say X->Y->Z, Y can doing man in the middle
attack. For Z to truly ensure that the message is from X, Z must FETCH X's
certificate from the overlay to verify the signature. For that reason,
sending the certificate has no real security meaning.
    
        
No, this is not correct. Certificates are independently verifiable by chaining
back to the overlay's root key. That's pretty much the point of certificates:
you can verify them no matter how you received them.
  
      
In the attack by Y described above, Y would sign and put its own 
certificate chain in the security block, so the whole message is 
verifiably correct. The only way Z can know this is an attack is by 
enforcing other constrain of this draft.  For example, if the STORE 
resource ID is between Y and Z, then this is an attack.
    

Huh?

How is it in attack for Y to take a message originated by X and 
claim it was originated by itself? Y can always generate any message
it wants and sign it. That's how signature-based message authentication
works. Moreover, why would this be an attack on X or Z, since Y
is *legitimately* allowed to generate messages and Z would
(correctly) conclude that the message came from Y, not X. The
fact that Y is copying X's message is irrelevant.


  
Aha! What if the resource ID in X's request is between X and Y or before 
X in the ring? Then Z will never notice the attack.  Y can map calls to 
X@domain to Y's destination list.  Am I right?
    

I have no idea what you are talking about.


  
Now, it's true that there is no SECURITY value in sending the certificate
along with the message. Data origin authentication authentication is supplied
by a digital signature computed using the private key that corresponds to
the public key in the certificate. The certificate is attached to the message
to avoid the complexity of a system where you have to hold the message
while you try to retrieve the certificate.

-Ek
      
A security warning should be included in this draft about the potential 
danger of trusting the certificate in the SecurityBlock. It's the proper 
thing to do.
    

I don't understand what you're talking about here either.

The cryptographic elements of an authenticated message in RELOAD
are:

- The contents
- A signature, generated using the sender's private key
- The sender's identity
- A certificate binding the sender's public key to the sender's
  identity.

In order to validate this, the verifier needs to:

- Verify the signature on the certificate (using the CA's public
  key, which is known a priori)
- Verify that the sender's identity matches the identity in the
  certificate
- Verify that the signature on the contents is correct
  (using the sender's public key, which is found in the
  certificate). 

This can be (needs to be) done regardless of the provenance of the
certificate because the certificate is directly verifiable. The
system does not depend on the certificate being provided by 
a trusted source. 

The only time when you do not need to verify the certificate is
if you have previously verified it and cached the result. You
never trust that the certificate is correct otherwise.


  
One more thing about SecurityBlock.certificates, in an overlay that 
requires an enrollment server, what is the use case in which the peer's 
certificate is not issued/signed by the enrollment server?  In another 
word, what is the use case where SecurityBlock.certificates contains 
more than one (the peer's) certificate?
    

When there are elements which need to be verified with different
certificates. For instance, if node A stores a value with node
B, which then does a replica store to node C, then the B->C 
store will have two signatures:

- The signature over the value, using A's key
- The signature over the message, using B's key

The SecurityBlock will then contain both A and B's certificates.

-Ekr
--------------020103020704090804060507-- From ekr@networkresonance.com Fri Oct 2 13:48:37 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606BC3A6978 for ; Fri, 2 Oct 2009 13:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.54 X-Spam-Level: X-Spam-Status: No, score=0.54 tagged_above=-999 required=5 tests=[AWL=-1.290, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu9sTMzS8Wtc for ; Fri, 2 Oct 2009 13:48:36 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 8E0CE3A6932 for ; Fri, 2 Oct 2009 13:48:36 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id E1D835D2452; Fri, 2 Oct 2009 13:55:47 -0700 (PDT) Date: Fri, 02 Oct 2009 13:55:47 -0700 From: Eric Rescorla To: Michael Chen In-Reply-To: <4AC65C4F.6010501@idssoftware.com> References: <4AC41D9B.1040504@idssoftware.com> <8BA1841D-F629-4243-8D0B-CDA730BDB942@rtfm.com> <4AC5149A.1090308@idssoftware.com> <4AC60C42.8040507@idssoftware.com> <20091002144614.5D3155D1FEA@kilo.networkresonance.com> <4AC65C4F.6010501@idssoftware.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091002205547.E1D835D2452@kilo.networkresonance.com> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] D/TLS with client authentication X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 20:48:37 -0000 At Fri, 02 Oct 2009 13:02:23 -0700, Michael Chen wrote: > > [1 ] > Eric, > > In my list post, Z can discover Y's attack if the AoR itself "X@domain" > is included in the STORE such that hash("X@domain") = Rx. Since the > message is resigned by Y, so Z can conclude that it's illegal for Y to > STORE an AoR of "X@domain". Y can only STORE an AoR of "Y@domain" > (unless of course a replica). > > If I am not mistaken, the current STORE does not send the AoR, only the > resource ID Rx. Then Z cannot verify how Rx was calculated and cannot > discover that Y is storing "X@domain". This is not correct. To recap: When a node receives a store to location Rx, that store is signed with the private key corresponding to the public key in some certificate C. The node then checks that whatever identity is in C is allowed to store at location Rx. The precise checks depend on the kind. For the particular case of AORs (more properly SIP-REGISTRATION) the Access Control Model is USER-NODE-MATCH. (S 7 of draft-ietf-p2psip-sip). This means: The USER-NODE-MATCH policy may only be used with dictionary types. In the USER-NODE-MATCH policy, a given value MUST be written (or overwritten) if and only if the request is signed with a key associated with a certificate whose user name hashes (using the hash function for the overlay) to the Resource-ID for the resource. In addition, the dictionary key MUST be equal to the Node-ID in the certificate. [draft-ietf-p2psip-base; S 6.3.3] Thus, X does not need to supply the AOR, because the check is to take the user name in the certificate and see of it hashes to Rx. This check precludes Y storing at Rx. -Ekr From michaelc@idssoftware.com Fri Oct 2 14:02:01 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF723A6A94 for ; Fri, 2 Oct 2009 14:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vutQE3b6Ga0W for ; Fri, 2 Oct 2009 14:02:01 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 210733A6A7C for ; Fri, 2 Oct 2009 14:02:00 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MtpHk-0006rI-V0; Fri, 02 Oct 2009 17:03:29 -0400 Message-ID: <4AC66BF4.7080103@idssoftware.com> Date: Fri, 02 Oct 2009 14:09:08 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <4AC41D9B.1040504@idssoftware.com> <8BA1841D-F629-4243-8D0B-CDA730BDB942@rtfm.com> <4AC5149A.1090308@idssoftware.com> <4AC60C42.8040507@idssoftware.com> <20091002144614.5D3155D1FEA@kilo.networkresonance.com> <4AC65C4F.6010501@idssoftware.com> <20091002205547.E1D835D2452@kilo.networkresonance.com> In-Reply-To: <20091002205547.E1D835D2452@kilo.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940a680089dfcc842867115d075b593fc65350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] D/TLS with client authentication X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 21:02:01 -0000 Eric, Thanks for the clarification. --Michael Eric Rescorla wrote: > At Fri, 02 Oct 2009 13:02:23 -0700, > Michael Chen wrote: > >> [1 ] >> Eric, >> >> In my list post, Z can discover Y's attack if the AoR itself "X@domain" >> is included in the STORE such that hash("X@domain") = Rx. Since the >> message is resigned by Y, so Z can conclude that it's illegal for Y to >> STORE an AoR of "X@domain". Y can only STORE an AoR of "Y@domain" >> (unless of course a replica). >> >> If I am not mistaken, the current STORE does not send the AoR, only the >> resource ID Rx. Then Z cannot verify how Rx was calculated and cannot >> discover that Y is storing "X@domain". >> > > This is not correct. > > To recap: > When a node receives a store to location Rx, that store is signed > with the private key corresponding to the public key in some > certificate C. The node then checks that whatever identity is in > C is allowed to store at location Rx. The precise checks depend on > the kind. > > For the particular case of AORs (more properly SIP-REGISTRATION) > the Access Control Model is USER-NODE-MATCH. (S 7 of draft-ietf-p2psip-sip). > This means: > > The USER-NODE-MATCH policy may only be used with dictionary types. > In the USER-NODE-MATCH policy, a given value MUST be written (or > overwritten) if and only if the request is signed with a key > associated with a certificate whose user name hashes (using the hash > function for the overlay) to the Resource-ID for the resource. In > addition, the dictionary key MUST be equal to the Node-ID in the > certificate. > > [draft-ietf-p2psip-base; S 6.3.3] > > Thus, X does not need to supply the AOR, because the check is to take the > user name in the certificate and see of it hashes to Rx. This check > precludes Y storing at Rx. > > -Ekr > > > > > From zongning@huawei.com Sun Oct 4 21:19:12 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A613A681D for ; Sun, 4 Oct 2009 21:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.069 X-Spam-Level: X-Spam-Status: No, score=-96.069 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=0.6, J_CHICKENPOX_44=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evkIjWEuZ7kn for ; Sun, 4 Oct 2009 21:19:08 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C15D43A6817 for ; Sun, 4 Oct 2009 21:19:07 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KR000IIKXE78M@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 05 Oct 2009 12:20:31 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KR0004JGXE7C8@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 05 Oct 2009 12:20:31 +0800 (CST) Received: from z63316 ([10.164.12.81]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KR000EORXE6G7@szxml06-in.huawei.com> for p2psip@ietf.org; Mon, 05 Oct 2009 12:20:31 +0800 (CST) Date: Mon, 05 Oct 2009 12:20:30 +0800 From: Ning Zong To: p2psip@ietf.org Message-id: <004d01ca4573$2cc53e00$510ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_C7cfUWD+Jxhy0SAqOUkfQA)" Thread-index: AcpFcjwTvdgOqCVGQueMVFzBQiroigAACoGg Subject: [P2PSIP] FW: New Version Notification for draft-jiang-p2psip-relay-03 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 04:19:12 -0000 This is a multi-part message in MIME format. --Boundary_(ID_C7cfUWD+Jxhy0SAqOUkfQA) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi, all, A new version of I-D "An extension to RELOAD to support Direct Response and Relay Peer routing" - draft-jiang-p2psip-relay-03 has been uploaded to IETF and attached in this message. The main modification is the new section 5 where the authors compare the cost of SRR, DRR and RPR. Comments and suggestions are welcome! Thanks. BR, Ning Zong -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Monday, October 05, 2009 12:12 PM To: zongning@huawei.com Cc: jiang.x.f@huawei.com; ron.even.tlv@gmail.com; zhangyunfei@chinamobile.com Subject: New Version Notification for draft-jiang-p2psip-relay-03 A new version of I-D, draft-jiang-p2psip-relay-03.txt has been successfuly submitted by Ning Zong and posted to the IETF repository. Filename: draft-jiang-p2psip-relay Revision: 03 Title: An extension to RELOAD to support Direct Response and Relay Peer routing Creation_date: 2009-10-03 WG ID: Independent Submission Number_of_pages: 23 Abstract: This document proposes an optional extension to RELOAD to support direct response and relay peer routing modes. RELOAD recommends symmetric recursive routing for routing messages. The new optional extensions provide a shorter route for responses reducing the overhead on intermediary peers and describe the potential cases where these extensions can be used. The IETF Secretariat. --Boundary_(ID_C7cfUWD+Jxhy0SAqOUkfQA) Content-type: text/plain; name=draft-jiang-p2psip-relay-03.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-jiang-p2psip-relay-03.txt P2PSIP X. Jiang Internet-Draft N. Zong Intended status: Standards Track Huawei Technologies Expires: April 6, 2010 R. Even Gesher Erove Y. Zhang China Mobile October 3, 2009 An extension to RELOAD to support Direct Response and Relay Peer routing draft-jiang-p2psip-relay-03 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 6, 2010. Copyright Notice Jiang, et al. Expires April 6, 2010 [Page 1] Internet-Draft P2PSIP relay October 2009 Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document proposes an optional extension to RELOAD to support direct response and relay peer routing modes. RELOAD recommends symmetric recursive routing for routing messages. The new optional extensions provide a shorter route for responses reducing the overhead on intermediary peers and describe the potential cases where these extensions can be used. Jiang, et al. Expires April 6, 2010 [Page 2] Internet-Draft P2PSIP relay October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Backgrounds . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Symmetric Recursive Routing (SRR) . . . . . . . . . . 7 3.1.2. Direct Response Routing (DRR) . . . . . . . . . . . . 7 3.1.3. Relay Peer Routing (RPR) . . . . . . . . . . . . . . . 8 3.2. Scenarios Where DRR can be Used . . . . . . . . . . . . . 9 3.2.1. Managed or Closed P2P System . . . . . . . . . . . . . 9 3.2.2. Wireless Scenarios . . . . . . . . . . . . . . . . . . 9 3.3. Scenarios Where RPR Benefits . . . . . . . . . . . . . . . 10 3.3.1. Managed or Closed P2P System . . . . . . . . . . . . . 10 3.3.2. Using Bootstrap Peers as Relay Peers . . . . . . . . . 10 3.3.3. Wireless Scenarios . . . . . . . . . . . . . . . . . . 10 4. Relationship Between SRR and DRR/RPR . . . . . . . . . . . . . 10 4.1. How DRR Works . . . . . . . . . . . . . . . . . . . . . . 10 4.2. How RPR Works . . . . . . . . . . . . . . . . . . . . . . 11 4.3. How These Three Routing Modes Work Together . . . . . . . 11 5. Comparison on cost of SRR and DRR/RPR . . . . . . . . . . . . 12 5.1. Closed or managed networks . . . . . . . . . . . . . . . . 12 5.2. Open networks . . . . . . . . . . . . . . . . . . . . . . 13 6. Extensions to RELOAD . . . . . . . . . . . . . . . . . . . . . 13 6.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 14 6.2. Modification To RELOAD Message Structure . . . . . . . . . 14 6.2.1. State-keeping Flag . . . . . . . . . . . . . . . . . . 14 6.2.2. Extensive Routing Mode . . . . . . . . . . . . . . . . 14 6.3. Creating a Request . . . . . . . . . . . . . . . . . . . . 15 6.3.1. Creating a Request for DRR . . . . . . . . . . . . . . 15 6.3.2. Creating a request for RPR . . . . . . . . . . . . . . 16 6.4. Request And Response Processing . . . . . . . . . . . . . 16 6.4.1. Destination Peer: Receiving a Request And Sending a Response . . . . . . . . . . . . . . . . . . . . . . 16 6.4.2. Sending Peer: Receiving a Response . . . . . . . . . . 17 6.4.3. Relay Peer Processing . . . . . . . . . . . . . . . . 17 7. Discovery Of Relay Peer . . . . . . . . . . . . . . . . . . . 17 8. Optional Methods to Investigate Node Connectivity . . . . . . 18 8.1. Getting Addresses To Be Used As Candidates for DRR . . . . 19 8.2. Public Reachability Test . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10.1. A new RELOAD Forwarding Option . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 Jiang, et al. Expires April 6, 2010 [Page 3] Internet-Draft P2PSIP relay October 2009 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Jiang, et al. Expires April 6, 2010 [Page 4] Internet-Draft P2PSIP relay October 2009 1. Introduction 1.1. Backgrounds RELOAD [I-D.ietf-p2psip-base] recommends symmetric recursive routing (SRR) for routing messages and describes the extensions that would be required to support additional routing algorithms. Other than SRR, two other routing options: direct response routing (DRR) and relay peer routing (RPR) are also discussed in Appendix D in [I-D.ietf- p2psip-base]. As we show in section 3, DRR and RPR are advantageous over RPR in some scenarios reducing load (CPU and link BW) on intermediary peers . For example, in a closed network where every node is in the same address realm, DRR performs better than SRR. On the other hand, RPR works better in a network where relay peers are provisioned in advance so that relay peers are publicly reachable in the P2P system. In other scenarios, using a combination of these three routing modes together is more likely to bring benefits than if SRR is used alone. Some discussion on connectivity is in Non- Transitive Connectivity and DHTs [http://srhea.net/papers/ntr-worlds05.pdf]. In this draft, we first discuss the problem statement, then the relationship between the three routing modes is presented. In Section 5, we give comparison on the cost of SRR, DRR and RPR in both managed and open networks. An extension to RELOAD to support DRR and RPR is proposed in Section 6. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. We use the terminology and definitions from the Concepts and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] draft extensively in this document. We also use terms defined in NAT behavior discovery [I-D.ietf-behave-nat-behavior-discovery]. Other terms used in this document are defined inline when used and are also defined below for reference. There are two types of roles in the RELOAD architecture: peer and client. Node is used when describing both peer and client. In discussions specific to behavior of a peer or client, the term peer or client is used instead. Publicly Reachable: A node is publicly reachable if it can receive unsolicited messages from any other node in the same overlay. Note: Jiang, et al. Expires April 6, 2010 [Page 5] Internet-Draft P2PSIP relay October 2009 "publicly" does not mean that the nodes must be on the public Internet, because the RELOAD protocol may be used in a closed system. Relay Peer: A type of publicly reachable peer that can receive unsolicited messages from all other nodes in the overlay and forward the responses from destination peers towards the request sender. Direct Response Routing (DRR): refers to a routing mode in which responses to P2PSIP requests are returned to the sending peer directly from the destination peer based on the sending peer's own local transport address(es). For simplicity, the abbreviation DRR is used instead in the following text. Relay Peer Routing (RPR): refers to a routing mode in which responses to P2PSIP requests are sent by the destination peer to a relay peer transport address who will forward the responses towards the sending peer. For simplicity, the abbreviation RPR is used instead in the following text. Symmetric Recursive Routing(SRR): refers to a routing mode in which responses follow the request path in the reverse order to get back to the sending peer. For simplicity, the abbreviation SRR is used instead in the following text. 3. Problem Statement RELOAD is expected to work under a great number of application scenarios. The situations where RELOAD is to be deployed differ greatly. For instance, some deployments are global, such as a Skype- like system intended to provide public service. Some run in closed networks of small scale. SRR works in any situation, but DRR and RPR may work better in some specific scenarios. 3.1. Overview RELOAD is a simple request-response protocol. After sending a request, a node waits for a response from a destination node. There are several ways for the destination node to send a response back to the source node. In this section, we will provide detailed information on three routing modes: SRR, DRR and RPR. Some assumptions are made in the following illustrations. 1) Peer A sends a request destined to a peer who is the responsible peer for Resource-ID k; 2) Peer X is the root peer being responsible for resource k; Jiang, et al. Expires April 6, 2010 [Page 6] Internet-Draft P2PSIP relay October 2009 3) The intermediate peers for the path from A to X are peer B, C, D. 3.1.1. Symmetric Recursive Routing (SRR) For SRR, when the request sent by peer A is received by an intermediate peer B, C or D, each intermediate peer will insert information on the peer from whom they got the request in the via- list as described in RELOAD. As a result, the destination peer X will know the exact path which the request has traversed. Peer X will then send back the response in the reverse path by constructing a destination list based on the via-list in the request. A B C D X | Request | | | | |----------->| | | | | | Request | | | | |----------->| | | | | | Request | | | | |----------->| | | | | | Request | | | | |----------->| | | | | | | | | | Response | | | | |<-----------| | | | Response | | | | |<-----------| | | | Response | | | | |<-----------| | | | Response | | | | |<-----------| | | | | | | | | SRR works in any situation, especially when there are NATs or firewalls. A downside of this solution is that the message takes several hops to return to the client, increasing the bandwidth usage and CPU/battery load of multiple nodes. 3.1.2. Direct Response Routing (DRR) In DRR, peer X receives the request sent by peer A through intermediate peer B, C and D, as in SRR. However, peer X sends the response back directly to peer A based on peer A's local transport address. In this case, the response won't be routed through intermediate peers. Shorter route means less overhead on intermediary peers, especially in the case of wireless network where the CPU and uplink BW is limited. In the absence of NATs or other connectivity issues, this is the optimal routing technique. Note that secure connection requires multiple round trips. Please refer Jiang, et al. Expires April 6, 2010 [Page 7] Internet-Draft P2PSIP relay October 2009 to Section 5 for cost comparison between SRR, DRR/RPR. A B C D X | Request | | | | |----------->| | | | | | Request | | | | |----------->| | | | | | Request | | | | |----------->| | | | | | Request | | | | |----------->| | | | | | | | | | Response | |<-----------+------------+------------+------------| | | | | | 3.1.3. Relay Peer Routing (RPR) If peer A knows it is behind a NAT or NATs, and knows one or more relay peers with whom they have a prior connections, peer A can try RPR. Assume A is associated with relay peer R. When sending the request, peer A includes information describing peer R transport address in the request. When peer X receives the request, peer X sends the response to peer R, which forwards it directly to Peer A on the existing connection. Note that RPR also allows a shorter route for responses compared to SRR, which means less overhead on intermediary peers. Establishing a connection to the relay with TLS requires multiple round trips. Please refer to Section 5 for cost comparison between SRR, DRR/RPR. This technique relies on the relative population of nodes such as A that require relay peers and peers such as R that are capable of serving as a relay peers. It also requires mechanism to enable peers to know which nodes can be used as their relays. This mechanism may be based on configuration, for example as part of the overlay configuration an initial list of relay peers can be supplied. Another option is in a response to ATTACH request the peer can signal that it can be used as a relay peer. Jiang, et al. Expires April 6, 2010 [Page 8] Internet-Draft P2PSIP relay October 2009 A B C D X R | Request | | | | | |----------->| | | | | | | Request | | | | | |----------->| | | | | | | Request | | | | | |----------->| | | | | | | Request | | | | | |----------->| | | | | | | Response | | | | | |---------->| | | | | Response | | |<-----------+------------+------------+------------+-----------| | | | | | | 3.2. Scenarios Where DRR can be Used This section lists several scenarios where using DRR would work, and when the increased efficiency would be advantageous. 3.2.1. Managed or Closed P2P System The properties that make P2P technology attractive, such as the lack of need for centralized severs, self-organization, etc. are attractive for managed systems as well as unmanaged systems. Many of these systems are deployed on private network where nodes are in the same address realm and/or can directly route to each other. In such a scenario, the network administrator can indicate preference for DRR in the peer's configuration file. Peers in such a system would always try DRR first, but peers must also support SRR in case DRR fails. If during the process of establishing a direct connection the responding peer receives a retransmit on a request with SRR as the preferred routing mode he should stop trying to establish a direct connection and use SRR. A node can keep a list of unreachable nodes based on trying DRR and use only SRR for these nodes. The advantage in using DRR is on the network stability since it puts less overhead on the intermediary peers that will not route the responses. The intermediary peers will need to route less messages and save CPU resources as well as the link bandwidth usage. 3.2.2. Wireless Scenarios While some mobile deployments may use clients, in mobile networks with full peers, there is an advantage to using DRR in order to reduce the load on intermediary nodes. Using DRR helps with reducing radio battery usage and bandwidth by the intermediary peers. The service provider may recommend in the configuration using DRR based on his knowledge of the topology. Jiang, et al. Expires April 6, 2010 [Page 9] Internet-Draft P2PSIP relay October 2009 3.3. Scenarios Where RPR Benefits In this section, we will list several scenarios where using RPR would provide improved performance. 3.3.1. Managed or Closed P2P System As described in Section 3.2.1, many P2P systems run in a closed or managed environment so that network administrators can better manage their system. For example, the network administrator can deploy several relay peers which are publicly reachable in the system and indicate their presence in the configuration file. After learning where these relay peers are, peers behind NATs can use RPR with the help from these relay peers. As with DRR, peers must also support SRR in case RPR fails. Another usage is to install relay peers on the managed network boundary allowing external peers to send responses to peers inside the managed network. 3.3.2. Using Bootstrap Peers as Relay Peers Bootstrap peers must be publicly reachable in a RELOAD architecture. As a result, one possible architecture would be to use the bootstrap peers as relay peers for use with RPR. The requirements for being a relay peer are publicly accessible and maintaining a direct connection with its client. As such, bootstrap peers are well suited to play the role of relay peers. 3.3.3. Wireless Scenarios While some mobile deployments may use clients, in mobile networks using peers, RPR, like DRR, may reduce radio battery usage and bandwidth usage by the intermediary peers. The service provider may recommend in the configuration using RPR based on his knowledge of the topology. Such relay peers may also help connectivity to external networks. 4. Relationship Between SRR and DRR/RPR 4.1. How DRR Works DRR is very simple. The only requirement is for the source peers to provide their (publically reachable) transport address to the destination peers, so that the destination peer knows where to send the response. Responses are sent directly to the requesting peer. Jiang, et al. Expires April 6, 2010 [Page 10] Internet-Draft P2PSIP relay October 2009 4.2. How RPR Works RPR is a bit more complicated than DRR. Peers using RPR must maintain a connection with their relay peer(s). This can be done in the same way as establishing a neighbor connection between peers by using the Attach method. A requirement for RPR is for the source peer to convey their relay peer (or peers) transport address in the request, so the destination peer knows where the relay peer are and send the response to a relay peer first. The request should include also the requesting peer information enabling the relay peer to route the response back to the right peer. (Editor's Note: Being a relay peer does not require that the relay peer have more functionality than an ordinary peer. As discussed later, relay peers comply with the same procedure as an ordinary peer to forward messages. The only difference is that there may be a larger traffic burden on relay peers. Relay peers can decide whether to accept a new connection based on their current burden.) 4.3. How These Three Routing Modes Work Together DRR and RPR are not intended to replace SRR. As seen from Section 3, DRR or RPR have better performance in some scenarios, but have limitations as well, see for example section 4.3 in Non-Transitive Connectivity and DHTs [http://srhea.net/papers/ntr-worlds05.pdf]. As a result, it is better to use these three modes together to adapt to each peer's specific situation. In this section, we give some suggestions on how to transition between the routing modes in RELOAD. Editor's Note: What this draft proposes are optional extensions to support DRR/RPR. There is no requirement for implementation to use the strategy described to choose the appropriate mode. A peer can collect statistical data on the success of the different routing modes based on previous transactions and keep a list of non- reachable addresses. Based on the data, the peer will have a clearer view about the success rate of different routing modes. Other than the success rate, the peer can also get data of fine granularity, for example, the number of retransmission the peer needs to achieve a desirable success rate. A typical strategy for the node is as follows. A node chooses to start with DRR or RPR. Based on the success rate as seen from the lost message statistics or responses that used SRR, the node can either continue to offer DRR/RPR first or switch to SRR. Jiang, et al. Expires April 6, 2010 [Page 11] Internet-Draft P2PSIP relay October 2009 The node can decide whether to try DRR or RPR based on other information such as configuration file information. If an overlay runs within a private network and all nodes in the system can reach each other directly, nodes may send most of the transactions with DRR. If a relay peer is provided by the service provider, nodes may prefer RPR over SRR. 5. Comparison on cost of SRR and DRR/RPR The major advantages in using DRR/RPR are in going through less intermediary peers on the response. By doing that it reduces the load on those peers' resources like processing and communication bandwidth. 5.1. Closed or managed networks As described in Section 3, many P2P systems run in a closed or managed environment (e.g. carrier networks) so that network administrators would know that they could safely use DRR/RPR. SRR brings out more routing hops than DRR and RPR. Assuming that there are N nodes in the P2P system and Chord is applied for routing, the number of hops for a response in SRR, DRR and RPR are listed in the following table. Establishing a secure connection between sending/relay peer and responding peer with TLS requires multiple messages. Assuming that TLS is applied, the number of messages for a response in SRR, DRR and RPR are shown in the following table. Mode | Success | No. of Hops | No. of Msgs ---------------------------------------------------- SRR | Yes | logN | logN DRR | Yes | 1 | 4+1 RPR | Yes | 2 | 4+2 From the above comparison, it is clear that: 1) In most cases of N > 2^2=4, DRR/RPR has fewer hops than SRR. Shorter route means less overhead and resource usage on intermediary peers, which is an important consideration for adopting DRR/RPR in the cases where the resource such as CPU and BW is limited, e.g. the case of mobile, wireless network. 2) In the cases of N > 2^6=64, DRR/RPR also has fewer messages than SRR. 3) In the cases where 4 < N < 64, DRR/RPR has more messages than SRR (but still has fewer hops than SRR). So the consideration to use Jiang, et al. Expires April 6, 2010 [Page 12] Internet-Draft P2PSIP relay October 2009 DRR/RPR or SRR depends on other factors like using less resources (bandwidth and processing) from the intermediaries peers. Section 4 provides use cases where DRR/RPR has better chance to work or where the intermediary resources considerations are important. 5.2. Open networks In open network where DRR/RPR is not guaranteed, DRR/RPR can fall back to SRR If it fails after trial, as described in Section 4. Based on the same settings in Section 5.1, the number of hops, number of messages for a response in SRR, DRR and RPR are listed in the following table. Mode | Success | No. of Hops | No. of Msgs ----------------------------------------------------------- SRR | Yes | logN | logN DRR | Yes | 1 | 4+1 | Fail&Fall back to SRR | 1+logN | 4+logN RPR | Yes | 2 | 4+2 | Fail&Fall back to SRR | 2+logN | 4+logN From the above comparison, it can be observed that: 1) Trying DRR/RPR would still have a good chance of fewer hops than SRR. Suppose that P peers are publicly reachable, the number of hops in DRR and SRR is P*1+(N-P)*(1+logN), N*logN, respectively. The condition for fewer hops in DRR is P*1+(N-P)*(1+logN) < N*logN, which is P/N > 1/logN. This means that when the number of peers N grows, the required ratio of publicly reachable peers P/N for fewer hops in DRR decreases. Similar analysis can be easily applied to RPR. Therefore, the chance of trying DRR/RPR with fewer hops than SRR becomes better as the scale of the network increases. 2) In the cases of large network and the success rate of DRR/RPR is good, it is still possible that DRR/RPR has fewer messages than SRR. Otherwise, the consideration to use DRR/RPR or SRR depends on other factors like using less resources from the intermediaries peers. 6. Extensions to RELOAD Adding support for DRR and RPR requires extensions to the current RELOAD protocol. In this section, we define the changes required to the protocol, including changes to message structure and to message processing. Jiang, et al. Expires April 6, 2010 [Page 13] Internet-Draft P2PSIP relay October 2009 6.1. Basic Requirements All peers implementing DRR or RPR MUST support SRR. All peers MUST be able to process requests for routing in SRR, and MAY support DRR or RPR routing requests. Peers that do not support or do not wish to provide DRR or RPR MAY reject these messages. 6.2. Modification To RELOAD Message Structure RELOAD provides an extensible framework to accommodate future extensions. In this section, we define a ForwardingOption structure to support DRR and RPR modes. Additionally we present a state- keeping flag to inform intermediate peers if they are allowed to not maintain state for a transaction. 6.2.1. State-keeping Flag RELOAD allows intermediate peers to maintain state in order to implement SRR, for example for implementing hop-by-hop retransmission. If DRR or RPR is used, the response will not follow the reverse path, and the state in the intermediate peers won't be cleared until such state expires. In order to address this issue, we propose a new flag, state-keeping flag, in the message header to indicate whether the state should be maintained in the intermediate peers. flag : 0x3 IGNORE-STATE-KEEPING If IGNORE-STATE-KEEPING is set, any peer receiving this message and which is not the destination of the message MUST forward the message with the full VIA list and MUST not maintain any internal state. 6.2.2. Extensive Routing Mode This draft introduces a new forwarding option for an extensive routing mode. This option conforms to the description in section 5.3.2.3 in [I-D.ietf-p2psip-base]. We first define a new type to define the new option, EXTENSIVE_ROUTING_MODE_TYPE: The option value will be illustrated in the following figure, defining the ExtensiveRoutingModeOption structure: Jiang, et al. Expires April 6, 2010 [Page 14] Internet-Draft P2PSIP relay October 2009 enum { 0x0, 0x01 (DRR), 0x02(RPR), 255} RouteMode; struct { RouteMode routemode; OverlayLink transport; IpAddressPort ipaddressport; Destination destination<1..2>; } ExtensiveRoutingModeOption; The above structure reuses: Transport, Destination and IpAddressPort structure defined in section 5.3.1.1 and 5.3.2.2 in [I-D.ietf-p2psip- base]. Route mode: refers to which type of routing mode is indicated to the destination peer. Currently, only DRR and RPR are defined. Transport: refers to the transport type which is used to deliver responses from the destination peer to the sending peer or the relay peer. IpAddressPort: refers to the transport address that the destination peer should use to send the response to. This will be a sending node address for DRR and a relay peer address for RPR. Destination: refers to the relay peer or the sending node itself. if the routing mode is DRR, then the destination only contains the sending node's node-id; If the routing mode is RPR, then the destination contains two destinations, which are the relay peer's node-id and the sending node's node-id. 6.3. Creating a Request 6.3.1. Creating a Request for DRR When using DRR for a transaction, the sending peer MUST set the IGNORE-STATE-KEEPING flag in the ForwardingHeader. Additionally, the peer MUST construct and include a ForwardingOptions structure in the ForwardingHeader. When constructing the ForwardingOption structure, the fields MUST be set as follows: 1) The type MUST be set to EXTENSIVE_ROUTING_MODE_TYPE. 2) The ExtensiveRoutingModeOption structure MUST be used for the option field within the ForwardingOptions structure. The fields MUST be defined as follows: 2.1) RouteMode set to 0x01 (DRR). 2.2) Transport set as appropriate for the sender. Jiang, et al. Expires April 6, 2010 [Page 15] Internet-Draft P2PSIP relay October 2009 2.3) IPAddressPort set to the peer's associated transport address. 2.4) The destination structure MUST contain one vaule, defined as type peer and set with the sending peer's own values. 6.3.2. Creating a request for RPR When using RPR for a transaction, the sending peer MUST set the IGNORE- STATE-KEEPING flag in the ForwardingHeader. Additionally, the peer MUST construct and include a ForwardingOptions structure in the ForwardingHeader. When constructing the ForwardingOption structure, the fields MUST be set as follows: 1) The type MUST be set to EXTENSIVE_ROUTING_MODE_TYPE. 2) The ExtensiveRoutingModeOption structure MUST be used for the option field within the ForwardingOptions structure. The fields MUST be defined as follows: 2.1) RouteMode set to 0x02 (RPR). 2.2) Transport set as appropriate for the relay peer. 2.3) IPAddressPort set to the transport address of the relay peer that the sender wishes the message to be relayed through. 2.4) Destination structure MUST contain two values. The first MUST be defined as type peer and set with the values for the relay peer. The second MUST be defined as type peer and set with the sending peer's own values. 6.4. Request And Response Processing This section gives normative text for message processing after DRR and RPR are introduced. Here, we only describe the additional procedures for supporting DRR and RPR. Please refer to [I-D.ietf- p2psip-base] for RELOAD base procedures. 6.4.1. Destination Peer: Receiving a Request And Sending a Response When the destination peer receives a request, it will check the options in the forwarding header. If the destination peer can not understand extensive_routing_mode option in the request, it MUST attempt to use SRR to return a error response to the sending peer. If the routing mode is DRR, the peer MUST construct the Destination list for the response with only one entry, using the sending peer's node-id from the option in the request as the value. Jiang, et al. Expires April 6, 2010 [Page 16] Internet-Draft P2PSIP relay October 2009 If the routing mode is RPR, the destination peer MUST construct a Destination list for the response with two entries. The first MUST be set to the relay peer node-id from the option in the request and the second MUST be the sending node node-id from the option of the request. In the event that the routing mode is set to DRR and there is not exactly one destination, or the routing mode is set to RPR and there are not exactly two destinations the destination peer MUST try to send a error response to the sending peer using SRR. After the peer constructs the destination list for the response, it sends the response to the transport address which is indicated in the IpAddressPort field in the option using the specific transport mode in the Forwardingoption. If the destination peer receives a retransmit with SRR preference on the message he is trying to response to now, the responding peer should abort the DRR/RPR response and use SRR. 6.4.2. Sending Peer: Receiving a Response Upon receiving a response, the peer follows the rules in [I-D.ietf- p2psip-base]. The peer should note if DRR worked in order to decide if to offer DRR again. If the peer does not receive a response until the timeout it SHOULD resend the request using SRR. If the sender used RPR and does not get a response until the timeout, it MAY either resend the message using RPR but with a different relay peer (if available), or resend the message using SRR. 6.4.3. Relay Peer Processing Relay peers are designed to forward responses to nodes who are not publicly reachable. For the routing of the response, this draft still uses the destination list. The only difference from SRR is that the destination list is not the reverse of the via-list, instead it is constructed from the forwarding option as described below. When a relay peer receives a response, it MUST follow the rules in [I-D.ietf-p2psip-base]. It receives the response, validates the message, re-adjust the destination-list and forward the response to the next hop in the destination list based on the connection table. There is no added requirement for relay peer. 7. Discovery Of Relay Peer There are several ways to distribute the information about relay Jiang, et al. Expires April 6, 2010 [Page 17] Internet-Draft P2PSIP relay October 2009 peers throughout the overlay. P2P network providers can deploy some relay peers and advertise them in the configuration file. With the configuration file at hand, peers can get relay peers to try RPR. Another way is to consider relay peer as a service and then some service advertisement and discovery mechanism can also be used for discovering relay peers, for example, using the same mechanism as used in TURN server discovery in base RELOAD [I-D.ietf-p2psip-base]. Another option is to let a peer advertise his capability to be a relay in the response to ATTACH or JOIN. Editor note: This section will be extended if we adopt RPR, but like other configuration information, there may be many ways to obtain this. 8. Optional Methods to Investigate Node Connectivity This section is for informational purposes only for providing some mecahnsism that can be used when the configuration information does not specify if DRR or RPR can be used. It summarizes some methods which can be used for a node to determine its own network location compared with NAT. These methods may help a node to decide which routing mode it may wish to try. Note that there is no foolproof way to determine if a node is publically reachable, other than via out- of-band mechanisms. As such, peers using these mechanisms may be able to optimize traffic, but must be able to fall back to SRR routing if the other routing mechanisms fail. For DRR and RPR to function correctly, a node may attempt to determine whether it is publicly reachable. If it is not, RPR may be chosen to route the response with the help from relay peers, or the peers should fall back to SRR. If the peer believes it is publically reachable, DRR may be attempted. NATs and firewalls are two major contributors preventing DRR and RPR from functioning properly. There are a number of techniques by which a node can get its reflexive address on the public side of the NAT. After obtaining the reflexive address, a peer can perform further tests to learn whether the reflexive address is publicly reachable. If the address appears to be publicly reachable, the nodes to which the address belongs can use DRR for responses and can also be a candidate to serve as a relay peer. Nodes which are not publicly reachable may still use RPR to shorten the response path with the help from relay peers. There are a number of techniques which a node can use to obtain its reflexive address which is on the public side of the NAT. After obtaining the reflexive address, a peer can perform further tests to learn whether the reflexive address is publicly reachable. If the address proves publicly reachable, the nodes to which the address Jiang, et al. Expires April 6, 2010 [Page 18] Internet-Draft P2PSIP relay October 2009 belongs can use DRR for responses and also can be a candidate for relay peer. Nodes that are not publicly reachable may still use RPR to shorten response path with the help of relay peers. Some conditions are unique in P2PSIP architecture which could be leveraged to facilitate the tests. In P2P overlay network, each node only has partial a view of the whole network, and knows of a few nodes in the overlay. P2P routing algorithms can easily deliver a request from a sending node to a peer with whom the sending node has no direct connection. This makes it easy for a node to ask other nodes to send unsolicited messages back to the requester. In the following sections, we first introduce several ways for a node to get the addresses needed for the further tests. Then a test for learning whether a peer may be publicly reachable is proposed. 8.1. Getting Addresses To Be Used As Candidates for DRR In order to test whether a peer may be publicly reachable, the node should first get one or more addresses which will be used by other nodes to send him messages directly. This address is either a local address of a node or a translated address which is assigned by a NAT to the node. STUN is used to get a reflexive address on the public side of a NAT with the help of STUN servers. There is also a STUN usage [I-D.ietf- behave-nat-behavior-discovery] to discover NAT behavior. Under RELOAD architecture, a few infrastructure servers can be leveraged for this usage, such as enrollment servers, diagnostic servers, bootstrap servers, etc. The node can use a STUN Binding request to one of STUN servers to trigger a STUN Binding response which returns the reflexive address from the server's perspective. If the reflexive transport address is the same as the source address of the Binding request, the node can determine that there likely is no NAT between him and the chosen infrastructure server. (Certainly, in some rare cases, the allocated address happens to be the same as the source address. Further tests will detect this case and rule it out in the end.). Usually, these infrastructure severs are publicly reachable in the overlay, so the node can be considered publicly reachable. On the other hand, with the techniques in [I-D.ietf-behave-nat-behavior-discovery], a node can also decide whether it is behind NAT with endpoint-independent mapping behavior. If the node is behind a NAT with endpoint- independent mapping behavior, the reflexive address should also be a candidate for further tests. UPnP-IGD is a mechanism that a node can use to get the assigned Jiang, et al. Expires April 6, 2010 [Page 19] Internet-Draft P2PSIP relay October 2009 address from its residential gateway and after obtaining this address to communicate it with other nodes, the node can receive unsolicited messages from outside, even though it is behind a NAT. So the address obtained through the UPnP mechanism should also be used for further tests. Another way that a node behind NAT can use to learn its assigned address by NAT is NAT-PMP. Like in UPnP-IGD, the address obtained using this mechanism should also be tested further. The above techniques are not exhaustive. These techniques can be used to get candidate transport addresses for further tests. 8.2. Public Reachability Test Using the transport addresses obtained by the above techniques, a node can start a test to learn whether the candidate transport address is publicly reachable. The basic idea for the test is for a node to send a request and expect another node in the overlay to send back a response. If the response is received by the sending node successfully and also the node giving the response has no direct connection with the sending node, the sending node can determine that the address is probably publicly reachable and hence the node may be publicly reachable at the tested transport address. In P2P overlay, a request is routed through the overlay and finally a destination peer will terminate the request and give the response. In a large system, there is a high probability that the destination peer has no direct connection with the sending node. Especially in RELOAD architecture, every node maintains a connection table. So it is easier for a node to check whether it has direct connection with another node. Note: Currently, no existing message in base RELOAD can achieve the test. In our opinion, this kind of test is within diagnostic scope, so authors hope WG can define a new diagnostic message to do that. We don't plan to define the message in this document, for the objective of this draft is to propose an extension to support DRR and RPR. The following text is informative. If a node wants to test whether its transport address is publicly reachable, it can send a request to the overlay. The routing for the test message would be different from other kinds of requests because it is not for storing/fetching something to/from the overlay or locating a specific node, instead it is to get a peer who can deliver the sending node an unsolicited response and which has no direct connection with him. Each intermediate peer receiving the request first checks whether it has a direct connections with the sending Jiang, et al. Expires April 6, 2010 [Page 20] Internet-Draft P2PSIP relay October 2009 peer. If there is a direct connection, the request is routed to the next peer. If there is no direct connection, the intermediate peer terminates the request and sends the response back directly to the sending node with the transport address under test. After performing the test, if the peer determines that it may be publicly reachable, it can try DRR in subsequent transaction, and may advertise that it is a candidate to serve as a relay peer. 9. Security Considerations TBD 10. IANA Considerations 10.1. A new RELOAD Forwarding Option A new RELOAD Forwarding Option type is add to the Registry. Type: 0x1 - extensive_routing_mode 11. Acknowledgements David Bryan has helped extensively with this document, and helped provide some of the text, analysis, and ideas contained here. The authors would like to thank Ted Hardie, Narayanan Vidya, Dondeti Lakshminath and Bruce Lowekamp for their constructive comments. 12. References 12.1. Normative References [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-02 (work in progress), March 2009. [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", draft-ietf-p2psip-concepts-02 (work in progress), July 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Jiang, et al. Expires April 6, 2010 [Page 21] Internet-Draft P2PSIP relay October 2009 12.2. Informative References [ChurnDHT] Rhea, S., "Handling Churn in a DHT", Proceedings of the USENIX Annual Technical Conference. Handling Churn in a DHT, June 2004. [I-D.ietf-behave-nat-behavior-discovery] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using STUN", draft-ietf-behave-nat-behavior-discovery-04 (work in progress), July 2008. [I-D.ietf-behave-tcp] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", draft-ietf-behave-tcp-08 (work in progress), September 2008. [I-D.lowekamp-mmusic-ice-tcp-framework] Lowekamp, B. and A. Roach, "A Proposal to Define Interactive Connectivity Establishment for the Transport Control Protocol (ICE-TCP) as an Extensible Framework", draft-lowekamp-mmusic-ice-tcp-framework-00 (work in progress), October 2008. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. Authors' Addresses Xingfeng Jiang Huawei Technologies Email: jiang.x.f@huawei.com Ning Zong Huawei Technologies Email: zongning@huawei.com Roni Even Gesher Erove Email: ron.even.tlv@gmail.com Jiang, et al. Expires April 6, 2010 [Page 22] Internet-Draft P2PSIP relay October 2009 Yunfei Zhang China Mobile Email: zhangyunfei@chinamobile.com Jiang, et al. Expires April 6, 2010 [Page 23] --Boundary_(ID_C7cfUWD+Jxhy0SAqOUkfQA)-- From sshetty@Tnstate.edu Mon Oct 5 09:44:09 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB75628C227 for ; Mon, 5 Oct 2009 09:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nNFOO6bOZyt for ; Mon, 5 Oct 2009 09:44:08 -0700 (PDT) Received: from TX2EHSOBE003.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by core3.amsl.com (Postfix) with ESMTP id 1725228C210 for ; Mon, 5 Oct 2009 09:44:07 -0700 (PDT) Received: from mail179-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 8.1.340.0; Mon, 5 Oct 2009 16:45:42 +0000 Received: from mail179-tx2 (localhost.localdomain [127.0.0.1]) by mail179-tx2-R.bigfish.com (Postfix) with ESMTP id ED2D6748458 for ; Mon, 5 Oct 2009 16:45:41 +0000 (UTC) X-SpamScore: -13 X-BigFish: VPS-13(zz13feK8c8aizz1202hzz5eeeT5a6ciz2dh6bh61h) X-Spam-TCS-SCL: 0:0 X-FB-SS: 5,5, Received: by mail179-tx2 (MessageSwitch) id 125476113796010_12909; Mon, 5 Oct 2009 16:45:37 +0000 (UCT) Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.235]) by mail179-tx2.bigfish.com (Postfix) with ESMTP id 0A5441088046 for ; Mon, 5 Oct 2009 16:45:36 +0000 (UTC) Received: from Locutus.Tnstate.edu (198.146.80.19) by TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server id 14.0.482.32; Mon, 5 Oct 2009 16:45:32 +0000 Received: from Locutus.Tnstate.edu ([10.52.129.17]) by Locutus.Tnstate.edu ([10.52.129.17]) with mapi; Mon, 5 Oct 2009 11:45:31 -0500 From: "Shetty, Sachin" To: "p2psip@ietf.org" Date: Mon, 5 Oct 2009 11:45:29 -0500 Thread-Topic: CFP: Special Issue on Information Dissemination and New Services in P2P Systems Thread-Index: AcpF2z+EWfyczo/vRcWdhF728Zgx/A== Message-ID: <26F5680453D5A94EA53C2F5208C57CDD59C156CCE1@Locutus.Tnstate.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_26F5680453D5A94EA53C2F5208C57CDD59C156CCE1LocutusTnstat_" MIME-Version: 1.0 X-Reverse-DNS: locutus.tnstate.edu Subject: [P2PSIP] CFP: Special Issue on Information Dissemination and New Services in P2P Systems X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 16:44:09 -0000 --_000_26F5680453D5A94EA53C2F5208C57CDD59C156CCE1LocutusTnstat_ Content-Type: text/plain; charset="windows-1258" Content-Transfer-Encoding: quoted-printable CFP: Special Issue on Information Dissemination and New Services in P2P Sys= tems, Peer-to-Peer Networking and Applications, Springer. http://www.springer.com/cda/content/document/cda_downloaddocument/CFP-12083= -20090728+.pdf?SGWID=3D0-0-45-775598-p173740112 Guest Editors Dr. Min Song, Department of Electrical and Computer Engineering, Old Domini= on University, msong@odu.edu Dr. Sachin Shetty, Department of Electrical and Computer Engineering, Tenne= ssee State University, sshetty@tnstate.edu Dr. Wenbin Jiang, School of Computer Science and Technology, Huazhong Unive= rsity of Science and Technology, jwbhust@gmail.com Dr. E. K. Park, Department of Computer Science and Electrical Engineering U= niversity of Missouri at Kansas City, ekpark@umkc.edu Paper submission deadline: November 1 2009 Background Information dissemination is an important P2P application that has received= considerable research attention in recent years. P2P information dissemina= tion systems range from simple file sharing applications to more complex sy= stems that allows users to securely and efficiently publish, organize, inde= x, search, update and retrieve data in a distributed storage medium. For co= mplex P2P information dissemination systems, there is a need for features w= hich include security, anonymity, fairness, scalability, resource managemen= t, and organization capabilities. For effective information dissemination, = following features of P2P systems and infrastructure need to be updated: di= stributed object location and routing mechanisms, novel approaches to conte= nt replication, caching and migration, encryption, authentication, access c= ontrol, and resource trading and management schemes. As P2P-based technologies play a more and more important role in the Intern= et, a number of new applications and services have been developed in the pa= st few years, including file sharing, music downloading, live streaming, vi= deo on demand, and P2P-based game platform. For these P2P systems, the key= issues to be considered are scalability, robustness, reliability, and secu= rity. Moreover, today's networks are becoming increasingly more heterogeneo= us in terms of both network technologies and traffic, impacted by various f= actors including the wide deployment of wireless networks, diversification = of multimedia formats, various requirements of different users, which broug= ht many new challenges to P2P systems. In this special issue, we solicit original work in areas of information dis= semination and new services in P2P systems. In particular, we seek original= work on networking protocols and algorithm design for information dissemin= ation and on identifying new research and development challenges for new se= rvices in P2P systems. Original research papers from the research, developm= ent, and standardization communities are all welcome. Specific topics inclu= de, but are not limited to: =9F Networking protocols and algorithms for information dissemination =9F Security, scalability, and reliability in information dissemination =9F P2P architectures, overlay and management =9F Semantic P2P =9F Comparative performance analysis of P2P =9F Dependability, resilience, and availability of P2P systems =9F Benchmarking and optimization =9F Business models, economic models, charging mechanisms =9F Real-time streaming =9F Video on demand, P2P IPTV =9F P2P telephony, hybrid approaches =9F Quality of Service in P2Psystems =9F P2P and wireless convergence =9F Mobile P2P, P2P over wireless networks =9F P2P technology and sensors =9F Service-oriented P2P =9F P2P system analysis and design methodologies =9F P2P as target and enabler for management systems =9F Large scale P2P-based measuring and monitoring =9F Digital rights management of P2P =9F Regulatory issues of network operators and service providers Paper Submission Authors are encouraged to submit high-quality, original work that has neith= er appeared in, nor is under consideration by, other journals. Springer off= ers authors, editors and reviewers of Peer-to-Peer Networking and Applicati= ons a web-enabled online manuscript submission and review system. Our onlin= e system offers authors the ability to track the review process of their ma= nuscript. Manuscripts should be submitted to: http://PPNA.edmgr.com. This o= nline system offers easy and straightforward log-in and submission procedur= es, and supports a wide range of submission file formats. Important Dates Paper submission deadline: November 1, 2009 Notification to authors: February 1, 2010 Camera ready papers: March 1, 2010 Date of publication: July 2010 --_000_26F5680453D5A94EA53C2F5208C57CDD59C156CCE1LocutusTnstat_ Content-Type: text/html; charset="windows-1258" Content-Transfer-Encoding: quoted-printable

CFP: Special Issue on Information Dissemination and New Services in P2P Systems,= Peer-to-Peer Networking and Applications, Springer.

http://www.springe= r.com/cda/content/document/cda_downloaddocument/CFP-12083-20090728+.pdf?SGW= ID=3D0-0-45-775598-p173740112

 

Guest Editors

Dr. Min Song, Department of Electrical and Computer Engineering, Old Dominion University, msong@odu.edu

Dr. Sachin Shetty, Department of Electrical and Computer Engineering, Tennessee State University, sshetty@tnstate.ed= u

Dr. Wenbin Jiang, School of Computer Science and Technology, Huazhong University of Science and Technology, jwbhust@gmail.com

Dr. E. K. Park, Department of Computer Sc= ience and Electrical Engineering University of Missouri at Kansas City, ekpark@umkc.edu

Pap= er submission deadline: November 1 2009

Background

Information dissemination is an important= P2P application that has received considerable research attention in recent yea= rs. P2P information dissemination systems range from simple file sharing applications to more complex systems that allows users to securely and efficiently publish, organize, index, search, update and retrieve data in a distributed storage medium. For complex P2P information dissemination syste= ms, there is a need for features which include security, anonymity, fairness, scalability, resource management, and organization capabilities. For effect= ive information dissemination, following features of P2P systems and infrastruc= ture need to be updated: distributed object location and routing mechanisms, nov= el approaches to content replication, caching and migration, encryption, authentication, access control, and resource trading and management schemes= .

 

As P2P-based technologies play a more and more important role in the Internet,= a number of new applications and services have been developed in the past few years, including file sharing, music downloading, live streaming, video on demand, and P2P-based game platform.  For these P2P systems, the key issues to be considered are scalability, robustness, reliability, and secur= ity. Moreover, today's networks are becoming increasingly more heterogeneous in terms of both network technologies and traffic, impacted by various factors including the wide deployment of wireless networks, diversification of multimedia formats, various requirements of different users, which brought = many new challenges to P2P systems.

 

In this special issue, we solicit original work in areas of information dissemination and new services in P2P systems. In particular, we seek origi= nal work on networking protocols and algorithm design for information dissemina= tion and on identifying new research and development challenges for new services= in P2P systems. Original research papers from the research, development, and standardization communities are all welcome. Specific topics include, but a= re not limited to:

 

=9F  Networking protocols and algorithms for information dissemination

=9F  Security, scalability, and reliability in information dissemination=

=9F  P2P architectures, overlay and management

=9F  Semantic P2P

=9F  Comparative performance analysis of P2P

=9F  Dependability, resilience, and availability of P2P systems

=9F  Benchmarking and optimization

=9F  Business models, economic models, charging mechanisms

=9F  Real-time streaming

=9F  Video on demand, P2P IPTV

=9F  P2P telephony, hybrid approaches

=9F  Quality of Service in P2Psystems

=9F  P2P and wireless convergence

=9F  Mobile P2P, P2P over wireless networks

=9F  P2P technology and sensors

=9F  Service-oriented P2P

=9F  P2P system analysis and design methodologies

=9F  P2P as target and enabler for management systems

=9F  Large scale P2P-based measuring and monitoring

=9F  Digital rights management of P2P

=9F  Regulatory issues of network operators and service providers

 

Paper Submission

Authors are encouraged to sub= mit high-quality, original work that has neither appeared in, nor is under consideration by, other journals. Springer offers authors, editors and reviewers of Peer-to-Peer Networking and Applications a web-enabled online manuscript submission and review system. Our online syst= em offers authors the ability to track the review process of their manuscript. Manuscripts should be submitted to: http://PPNA.edmgr.com. T= his online system offers easy and straightforward log-in and submission procedu= res, and supports a wide range of submission file formats.

 <= /p>

Important Dates

Pap= er submission deadline: November 1, 2009

Not= ification to authors: February 1, 2010

Cam= era ready papers: March 1, 2010

Date of publication: July 2010

 

--_000_26F5680453D5A94EA53C2F5208C57CDD59C156CCE1LocutusTnstat_-- From root@core3.amsl.com Tue Oct 6 10:45:01 2009 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6103D3A6858; Tue, 6 Oct 2009 10:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091006174501.6103D3A6858@core3.amsl.com> Date: Tue, 6 Oct 2009 10:45:01 -0700 (PDT) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-base-04.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 17:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : REsource LOcation And Discovery (RELOAD) Base Protocol Author(s) : C. Jennings, et al. Filename : draft-ietf-p2psip-base-04.txt Pages : 149 Date : 2009-10-06 In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC 3979 respectively. They refer only to those RFCs and not any documents that update or supersede them. This document defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-p2psip-base-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-06103110.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Oct 6 10:45:01 2009 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6EDC13A6960; Tue, 6 Oct 2009 10:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091006174501.6EDC13A6960@core3.amsl.com> Date: Tue, 6 Oct 2009 10:45:01 -0700 (PDT) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-sip-02.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 17:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : A SIP Usage for RELOAD Author(s) : C. Jennings, et al. Filename : draft-ietf-p2psip-sip-02.txt Pages : 13 Date : 2009-10-06 This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD), The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system. The SIP Usage provides lookup service for AoRs stored in the overlay. The SIP Usage also defines GRUUs that allow the registrations to map an AoR to a specific node reachable through the overlay. The AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-sip-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-p2psip-sip-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-06103118.I-D@ietf.org> --NextPart-- From fluffy@cisco.com Tue Oct 6 10:50:59 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B123A690D for ; Tue, 6 Oct 2009 10:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVRhsnnv1tai for ; Tue, 6 Oct 2009 10:50:57 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 463323A6903 for ; Tue, 6 Oct 2009 10:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=290; q=dns/txt; s=sjiport02001; t=1254851555; x=1256061155; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20New=20versions=20of=20RELOAD=20and=20sip=20draft|Date: =20Tue,=206=20Oct=202009=2011:52:34=20-0600|Message-Id: =20<8FDC180D-74F4-4875-A4A1-64D1034667C9@cisco.com>|To: =20P2PSIP=20WG=20|Mime-Version:=201.0=20 (Apple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit; bh=CZYw9QoNXR84wH3szN7xvlg92QZJUveOakX1KetdXDo=; b=jwh7CZXiyGD9H304+aNfMoid/hBccORajEFP6hLz/S9xmFl/W71NEq4R PTonPICzs4BdarBm0K36TM9/gQY2rBR7AeaugHAjTuUuyic7UD6QyZBgp dW9yo0Fz5j+d4vzRO9Y9zJnnqEQpyxjAv8NLV1gtKcExyla19gGgAA2YE I=; Authentication-Results: sj-iport-2.cisco.com; dkim=pass (signature verified [TEST]) header.i=fluffy@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFMhy0qrR7MV/2dsb2JhbAC7fIhjAY8tBoQq X-IronPort-AV: E=Sophos;i="4.44,513,1249257600"; d="scan'208";a="211604896" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 06 Oct 2009 17:52:35 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n96HqZlH020143 for ; Tue, 6 Oct 2009 10:52:35 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n96HqYLi013883 for ; Tue, 6 Oct 2009 17:52:34 GMT Message-Id: <8FDC180D-74F4-4875-A4A1-64D1034667C9@cisco.com> From: Cullen Jennings To: P2PSIP WG Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Oct 2009 11:52:34 -0600 X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=290; t=1254851555; x=1255715555; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20New=20versions=20of=20RELOAD=20and=20sip=20draf t |Sender:=20; bh=CZYw9QoNXR84wH3szN7xvlg92QZJUveOakX1KetdXDo=; b=XAbIVrui4mSJgOlI2uPD6CWEswupv7xtx8TlCbCJGyq+coUrmWHfNhxRAK x/iK9ufeA2iQhQJxvwKbdwYxVGXVujJk2iFRQXGe0HQ7QflXIQtkWl5OdTMZ WvLiB04+i5LfwhrzrmcVavaWqOmAN0LRuSr6OOnum+SacchzYXLxk=; Subject: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 17:50:59 -0000 I just submitted draft-ietf-p2psip-base-04 and draft-ietf-p2psip-sip-02 These contain technical changes but do not have a lot of editorial changes. At some point we need to go and reorganize the documents with editorial changes. Cullen From fluffy@cisco.com Tue Oct 6 11:22:19 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5FA3A6896 for ; Tue, 6 Oct 2009 11:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.529 X-Spam-Level: X-Spam-Status: No, score=-106.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkDVWPvZnIBs for ; Tue, 6 Oct 2009 11:22:18 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3B88C3A65A6 for ; Tue, 6 Oct 2009 11:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=7492; q=dns/txt; s=sjiport05001; t=1254853436; x=1256063036; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=2010.3.1=20Self-Generated=20Credentials |Date:=20Tue,=206=20Oct=202009=2012:23:52=20-0600 |Message-Id:=20|To:=20jc=20|Cc:=20Michael =20Chen=20,=20p2psip=20WG=20|Mime-Version:=201.0=20(Apple=20Message=20f ramework=20v936)|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<11FF298A-F4CD-4B5A-86BA-A36549748CC1@orc hidseed.org>|References:=20<2DCCC1BB-32FB-4FAC-9D04-266AB 8607D0B@orchidseed.org>=09=20<4ABB82AD.7030201@idssoftwar e.com>=09=20=20<8b2769930909240949o25600c62hb84a13fdf64 8faa9@mail.gmail.com>=20<4ABC4897.2090501@idssoftware.com >=20 =20<4AC39A64.7030601@idssoftware.com>=20<8B60D024-9EA3-46 BD-AD20-2B76656FB8DB@orchidseed.org>=20<4AC4130B.3000605@ idssoftware.com>=20<11FF298A-F4CD-4B5A-86BA-A36549748CC1@ orchidseed.org>; bh=odJMPar3BZkSZuFVNB+yw8MCefHn5U7u/1TCk3zy20k=; b=MUxdY/vrYkAHvP7HRaJyE6UEeOtgr0d8WEN08O0MWyW6z14bvUbYeZZs FrFhnz3fMqS1eVgVNR2UbuMW5tyGPnIqVlGQXwtyHYVANEVdED+MkyMT7 jw98RFO2cqljqgfAq4d2OTyFJ4p4E60LRmAN1bnVUzIdftMIjm30wfLD6 Q=; Authentication-Results: sj-iport-5.cisco.com; dkim=pass (signature verified [TEST]) header.i=fluffy@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB8oy0qrR7PE/2dsb2JhbAC8C4hjAY8vBoQq X-IronPort-AV: E=Sophos;i="4.44,513,1249257600"; d="scan'208";a="97737156" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 06 Oct 2009 18:23:55 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n96INtEw006825; Tue, 6 Oct 2009 11:23:55 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n96INqvr002373; Tue, 6 Oct 2009 18:23:53 GMT From: Cullen Jennings To: jc In-Reply-To: <11FF298A-F4CD-4B5A-86BA-A36549748CC1@orchidseed.org> Impp: xmpp:cullenfluffyjennings@jabber.org References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> <4ABB82AD.7030201@idssoftware.com> <8b2769930909240949o25600c62hb84a13fdf648faa9@mail.gmail.com> <4ABC4897.2090501@idssoftware.com> <4AC39A64.7030601@idssoftware.com> <8B60D024-9EA3-46BD-AD20-2B76656FB8DB@orchidseed.org> <4AC4130B.3000605@idssoftware.com> <11FF298A-F4CD-4B5A-86BA-A36549748CC1@orchidseed.org> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Oct 2009 12:23:52 -0600 X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7492; t=1254853435; x=1255717435; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=2010.3.1=20Self-Generated=20Cr edentials |Sender:=20; bh=odJMPar3BZkSZuFVNB+yw8MCefHn5U7u/1TCk3zy20k=; b=Y+0w3M6nhATIkjK3ArXBwjMPsjXRpnc5M6mAIrswWPopEN26vO25ESWkEE TO78N9TtjBM0c5h3jmLnR3dTDG7Eu3G3SZQ8e3d8heZvdugGVgHxShSM+Wfl PkFt/NSe56; Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 18:22:19 -0000 For what it's worth, one of the implementations I am using allows a UDP packet to get up two just under 2 MTU before fragmenting at the RELOAD layer. So if the MTU is 1500, the peer might send a 2500 bytes UDP packet and just depend on the network to reassemble the fragment. The packet loss rates on the network this is running on are good enough to run VoIP on it so the extra impact of this fragmentation at the IP layer is not causing problems. On Sep 30, 2009, at 9:08 PM, jc wrote: > > On Sep 30, 2009, at 7:25 PM, Michael Chen wrote: > >> Julian, >> >> My point is that what's left for Reload payload is 1492-1292 = 200 >> bytes. Many Reload messages will have to be fragmented. > > I don't see the problem because TLS over TCP will be doing the same. > You will most likely be fragmenting 100% of all application level > messages and some percentage of RELOAD messages. Also DTLS has a bit > better performance than TLS over TCP. > >> >> --Michael >> >> jc wrote: >>> This is greater than the MTU of an xbox 360 but less than your >>> averge router at 1492. Doesn't DTLS in OpenSSL already have the >>> real path MTU after the handshake? If not I know it can do this >>> for you. You can use that MTU and fragment your packets. >>> >>> Julian >>> >>> Sent from my iPhone >>> >>> On Sep 30, 2009, at 10:50 AM, Michael Chen >>> wrote: >>> >>>> Julian, >>>> >>>> I have no scientific data, just a personal concern. Consider a >>>> Reload STORE request with your 691 byte cert, the total fat (non- >>>> payload) on the wire for a UDP/DTLS transport is: >>>> >>>> DTLS header (13 bytes) >>>> Reload header >>>> Forward header (38 bytes) >>>> Destination list (18 bytes, single hop) >>>> Reload Message >>>> STORE (SIP_REGISTRATION) >>>> AOR >>>> RSA Signature (256 bytes) >>>> Reload Security Block >>>> Certificates (691 bytes) >>>> Signer ID (20+ bytes) >>>> RSA Signature (256 bytes) >>>> DTSL MAC and padding (20+ bytes) >>>> >>>> These are rough numbers, and it total 1292 bytes excluding the >>>> AOR. It is very close to the 1500 byte network packet size (MTU). >>>> >>>> --Michael >>>> >>>> jc wrote: >>>>> >>>>> On Sep 24, 2009, at 9:35 PM, Michael Chen wrote: >>>>> >>>>>> I also want to point out that even with the most simple >>>>>> encoding (JDK keytool), a 1024 bit RSA public key certificate >>>>>> takes up 619 bytes. A production strength 2048 bit RSA cert is >>>>>> 880 bytes. If a peer can only be reached via UDP, the overhead >>>>>> of DTLS + Reload Signature on message leaves very little room >>>>>> for the relevant data fragment (e.g. 1500 packet size), which >>>>>> means UDP transport may be very inefficient. Transport >>>>>> overhead should be a separate discussion thread. >>>>> >>>>> In my RELOAD implementation a 2048 bit RSA public key is 691 >>>>> bytes long, see output below. Do you have statistics that show >>>>> the current fragmentation algorithm to be sub-optimal? >>>>> Julian >>>>> >>>>> * >>>>> * >>>>> *Running 1 test case...* >>>>> *......................+++* >>>>> *........................+++* >>>>> *debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded >>>>> generating RSA key.* >>>>> *..............................+++* >>>>> *..............+++* >>>>> *debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded >>>>> generating RSA key.* >>>>> *debug: X509_NAME* junglecat::x509::allocate_common_name(const >>>>> char*): Allocated* >>>>> *debug: X509_NAME* junglecat::x509::allocate_common_name(const >>>>> char*): Allocated* >>>>> *debug: X509* junglecat::x509::generate_certificate(RSA*, RSA*, >>>>> const char*, const char*, unsigned int, const EVP_MD*): Success* >>>>> *Certificate:* >>>>> * Data:* >>>>> * Version: 3 (0x2)* >>>>> * Serial Number: 1253857645 (0x4abc596d)* >>>>> * Signature Algorithm: sha1WithRSAEncryption* >>>>> * Issuer: CN=common_name_issuer* >>>>> * Validity* >>>>> * Not Before: Sep 25 05:47:25 2009 GMT* >>>>> * Not After : Sep 25 06:47:25 2009 GMT* >>>>> * Subject: CN=common_name* >>>>> * Subject Public Key Info:* >>>>> * Public Key Algorithm: rsaEncryption* >>>>> * RSA Public Key: (2048 bit)* >>>>> * Modulus (2048 bit):* >>>>> * 00:ab:54:2c:7b:9a:d8:3c:4b:b8:08:46:04:ee: >>>>> 02:* >>>>> * 51:8a:94:4c:62:58:d0:ed:50:f8:2f:5a: >>>>> 43:b2:b0:* >>>>> * aa:1a:7c:46:32:ad:93:b3:80:1b:dd: >>>>> 62:d7:72:14:* >>>>> * aa:0e:43:7c:6b: >>>>> 00:a6:56:f3:62:ed:b5:d4:ff:c4:* >>>>> * da:72:6c:ff:8c:75:a2:8a:0c:e9:fb: >>>>> 9d:f0:f3:6f:* >>>>> * d8:65:1e:85:7b:7c:91:cc:b3:8a:eb:f7:ff: >>>>> 1d:c7:* >>>>> * e0:9f:e5:d3:e0:d4:23:3a:e9:0a:9c:be:f7:fc: >>>>> 44:* >>>>> * 59:3f:03:19:65:8c:fd:07:bd:40:c0:40:3c: >>>>> 04:8e:* >>>>> * 46:5c:13:1a: >>>>> 85:68:d8:48:01:f9:03:75:98:e9:1f:* >>>>> * a7:bb:d7:75:c7:dc:6b:3c:eb:6e:6c:ee: >>>>> 21:73:94:* >>>>> * 66:dd:d6:4a:13:79:7b: >>>>> 19:91:75:f8:14:0e:ba:dd:* >>>>> * 01:79:83:0e:3f:e1:9a:10:ea: >>>>> 98:cc:ae:d5:41:d7:* >>>>> * 2d:33:0e:ab:6c:be:49:d3:cd:dd:fe:f4:5e: >>>>> 0c:ef:* >>>>> * b8:cb:ae:bf:80:e4:cf:9e:66:86:42:2a:1c: >>>>> 3a:ca:* >>>>> * d0:d5:ab:ad:34:ba:eb:6e:2d:33:86:4e: >>>>> 29:e8:1b:* >>>>> * cb:ee:f4:d5:8f:2c:d1:f6:10:a6:84:4b:4f: >>>>> 05:2d:* >>>>> * 17:31:09:03:bd:9e:63:32:0f:14:ae:a6:0c: >>>>> 74:aa:* >>>>> * 0a:d3* >>>>> * Exponent: 65537 (0x10001)* >>>>> * Signature Algorithm: sha1WithRSAEncryption* >>>>> * 52:2a:cd:4d:f3:cc:c1:94:5e:5e:09:63:34:f6:fb:9b:c0:52:* >>>>> * dc:98:90:30:88:44:bd:f6:73:0a:e2:ed:6c:f1:bc:26:f0:d9:* >>>>> * 72:c0:a7:d1:79:85:8d:f1:eb:4c:cc:d1:b0:73:fa:8f:de:e1:* >>>>> * 81:9d:32:fa:c6:c3:eb:37:5e:7f:30:c6:7e:a2:34:e0:d1:9d:* >>>>> * af:a2:e7:00:59:68:eb:7c:f6:c1:6d:18:0e:f5:14:5e:cc:c9:* >>>>> * f2:07:f1:60:a3:b4:a3:28:89:23:93:ac:14:d4:1e:69:f5:c7:* >>>>> * b8:90:68:b7:f2:bc:70:6c:2b:7e:01:48:34:77:ae:67:b2:ff:* >>>>> * 0f:b7:15:c6:42:4c:9f:c6:dd:02:ed:06:9b:04:60:4a:74:52:* >>>>> * ee:03:29:0e:e3:75:62:07:92:a3:48:f6:a4:f5:bb:8c:09:b0:* >>>>> * cf:71:12:24:63:33:0f:9f:97:d4:ab:01:da:d7:d8:7f:c8:17:* >>>>> * 94:0e:70:03:7a:f0:5e:14:8b:ec:c8:11:d9:b4:b4:74:2c:4e:* >>>>> * 0c:56:35:c7:0f:b0:9e:6a:df:b2:63:68:3e:05:53:05:86:7c:* >>>>> * 45:82:a4:94:93:12:8e:b4:a2:0d:5f:29:d8:7d:52:d3:ab:8f:* >>>>> * d4:cf:6f:26:b7:36:f6:5f:a4:c7:64:da:a2:ec:da:74:3b:e5:* >>>>> * 8d:2a:7b:21* >>>>> >>>>> *X509 structure size: 92* >>>>> *RSA structure size: 88* >>>>> len:691 >>>>> >>>>> **** No errors detected* >>>>> * >>>>> * >>> >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Tue Oct 6 11:45:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D8428C1E3 for ; Tue, 6 Oct 2009 11:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92rcINK8hPvC for ; Tue, 6 Oct 2009 11:45:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 49FBB28C108 for ; Tue, 6 Oct 2009 11:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1326; q=dns/txt; s=sjiport01001; t=1254854828; x=1256064428; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=2010.3.1=20Self-Generated=20Credentials |Date:=20Tue,=206=20Oct=202009=2012:47:06=20-0600 |Message-Id:=20<6A2649E6-805B-4352-95E9-CA4D516E9339@cisc o.com>|To:=20jc=20|Cc:=20p2psip=20 WG=20|Mime-Version:=201.0=20(Apple=20Mes sage=20framework=20v936)|Content-Transfer-Encoding:=207bi t|In-Reply-To:=20|References:=20<2DCCC1BB-32FB-4FAC-9D04-266A B8607D0B@orchidseed.org>=20; bh=MbtGKW5TR3yMaqHHlLSh8KvqdGddalFz58ExxOmCim8=; b=idJVa6TfU7PCR6r//8h7OLV6+KsejOuyoT+tsQZeJJtPxLlLU4exCJh4 JOYFmKhoshKzpFSaUhaJDufpGXOiOQNirspvsF3OLw4ltD3+bjVk6WjXh /wcn7vRfp5HNnhiXwQeQ/kyLQs9HakHV5GXWX2Rr35sfC/AEZsRACSUdw 0=; Authentication-Results: sj-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=fluffy@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPoty0qrR7PD/2dsb2JhbAC8D4hjAY81BoJLDIFT X-IronPort-AV: E=Sophos;i="4.44,514,1249257600"; d="scan'208";a="251762803" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 06 Oct 2009 18:47:08 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n96Il7sZ003937; Tue, 6 Oct 2009 11:47:07 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n96Il7cb028698; Tue, 6 Oct 2009 18:47:07 GMT From: Cullen Jennings To: jc In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> Message-Id: <6A2649E6-805B-4352-95E9-CA4D516E9339@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Oct 2009 12:47:06 -0600 X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1326; t=1254854828; x=1255718828; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=2010.3.1=20Self-Generated=20Cr edentials |Sender:=20; bh=MbtGKW5TR3yMaqHHlLSh8KvqdGddalFz58ExxOmCim8=; b=AU8CyYldA6+b3ThUhzMD6vShbw4PvVKrV9Bjinx6tXLdjbXvvq/v+3gpAN 9OP8Npafy2yITdUtYIjsFNKevnZZdqPWkWna7JkF4c2R4RWAkFFjeqsYtXXz +Hk8xJ5NEl; Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 18:45:31 -0000 I think there is text about this in section 10.3. It says the information is in SubjectAltName field of the cert with an entry of type rfc822Name for user names and of type URI for node ids. The URI is as described in 13.12. It's all pretty terse but if you think more is needed, send me some text. On Sep 17, 2009, at 3:08 AM, jc wrote: > I looked at some other areas and the problem is the draft doesn't > clearly state fields that X509 certificates MUST contain or > misrepresents them case-wise. > > For instance: > > 7. Certificate Store Usage > user name > Node-ID > > 12.5.1. Authorization > User name > Node-ID > Serial > > There are several other references as well. Since this is a string > variable inside of an X509 certificate the names need to be case > normalized. > > Julian > > On Sep 16, 2009, at 10:30 PM, jc wrote: > >> Hi, >> States "MAY contain any user name of the user choice", this is >> subjectAltName? > > User name or user name? > >> >> Julian >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Tue Oct 6 11:45:35 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E1A28C200 for ; Tue, 6 Oct 2009 11:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.231 X-Spam-Level: X-Spam-Status: No, score=-106.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z299q71vY23 for ; Tue, 6 Oct 2009 11:45:34 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6201128C1FD for ; Tue, 6 Oct 2009 11:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=447; q=dns/txt; s=sjiport01001; t=1254854832; x=1256064432; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=2010.3.1=20Self-Generated=20Credentials |Date:=20Tue,=206=20Oct=202009=2012:47:11=20-0600 |Message-Id:=20<9289F2BD-0803-484A-88D2-627D386B0AFD@cisc o.com>|To:=20neil.young@freenet.de|Cc:=20p2psip=20WG=20

|Mime-Version:=201.0=20(Apple=20Message=20 framework=20v936)|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<4ABBDE47.8090505@freenet.de>|References: =20<2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> =09<4ABB82AD.7030201@idssoftware.com>=09=20<8b276993090 9240949o25600c62hb84a13fdf648faa9@mail.gmail.com>=20<4ABB DE47.8090505@freenet.de>; bh=53viz1D4qorCssK5D8k8suwh5tw+QPL5nNS1bWEj6RU=; b=YwVWayVk5PjW7YoKDvTTg+OILovuQ2UcqxLf51S8segxCyAgoE+vtLK+ uKnwZ4prrJ874YXJVnSpg5NA/zz5r8OlR/mEdGA2W6eqTH99hIfRJQvF5 602rMZhG2HfbQP3eU3mHKqaI4OoYTfKzjtJve12KLRjd+S5k/vjVj13Vd c=; Authentication-Results: sj-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=fluffy@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPoty0qrR7MV/2dsb2JhbAC8D4hjAY81BoQq X-IronPort-AV: E=Sophos;i="4.44,514,1249257600"; d="scan'208";a="251762856" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 06 Oct 2009 18:47:12 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n96IlCRS023508; Tue, 6 Oct 2009 11:47:12 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n96Il7cc028698; Tue, 6 Oct 2009 18:47:12 GMT From: Cullen Jennings To: neil.young@freenet.de In-Reply-To: <4ABBDE47.8090505@freenet.de> Impp: xmpp:cullenfluffyjennings@jabber.org References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> <4ABB82AD.7030201@idssoftware.com> <8b2769930909240949o25600c62hb84a13fdf648faa9@mail.gmail.com> <4ABBDE47.8090505@freenet.de> Message-Id: <9289F2BD-0803-484A-88D2-627D386B0AFD@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Oct 2009 12:47:11 -0600 X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=447; t=1254854832; x=1255718832; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=2010.3.1=20Self-Generated=20Cr edentials |Sender:=20; bh=53viz1D4qorCssK5D8k8suwh5tw+QPL5nNS1bWEj6RU=; b=H9JXrh0ldU3neLiSUEJsewQx21CIcpiH2gHYTv3lpeKhLG7Br6o4MVqMys Klv6RRRguA1EjGvunP3Ml0kVcPYfTF/D0xhTsAIUJO0dJiXARkjIVlnf6WoS 0i2GbAvdi2XPeEW5B9M4ZZSaaLF5tJK6eqXqmYmSJvPNhvpzlHaHM=; Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 18:45:35 -0000 On Sep 24, 2009, at 3:01 PM, neil.young wrote: > Probably the discussion you raised is worth a separate thread. I'm > currently in the situation to evaluate whether RELOAD is the way to > go or not (for our project). The scattered postings in this group > may lead to the conclusion, that RELOAD has no relevance at all. I > would be glad to hear, that this isn't the case. Neil, this is the not case. Hope you are glad now. From fluffy@cisco.com Tue Oct 6 13:07:00 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C427B3A68FF for ; Tue, 6 Oct 2009 13:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpZEBbAfrw5L for ; Tue, 6 Oct 2009 13:06:59 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id ADBA03A6960 for ; Tue, 6 Oct 2009 13:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=880; q=dns/txt; s=sjiport02001; t=1254859718; x=1256069318; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=2010.4.=20=20Searching=20for=20a=20Boot strap=20Peer|Date:=20Tue,=206=20Oct=202009=2014:08:36=20- 0600|Message-Id:=20<3F00B9A6-8FE2-4377-AC9B-5D6A14F8148E@ cisco.com>|To:=20jc=20|Cc:=20p2psi p=20WG=20|Mime-Version:=201.0=20(Apple =20Message=20framework=20v936)|Content-Transfer-Encoding: =207bit|In-Reply-To:=20<4BE1B9C2-2AD7-48D0-BA50-A3683E2E0 75E@orchidseed.org>|References:=20<4BE1B9C2-2AD7-48D0-BA5 0-A3683E2E075E@orchidseed.org>; bh=Eu46meWeSz1YxwBUIF6tLapuLGZIkxFC2CzJksuDyLA=; b=YrCwA18G5c6SbJbjneCCJ3Z7xS2C/IsO6SAA0uFjhOzotSYWosfeIdM9 et7UiETjXMKpS6sAO7G9wabtD8DomDS03ITBLLYwe0iCTbR3K+ynlFFlj /Kxd2mTxRJVvCS8LHayRrFd4QSwE5AROcFA7XZ0j7DJgF0l29fOhLZ/C9 A=; Authentication-Results: sj-iport-2.cisco.com; dkim=pass (signature verified [TEST]) header.i=fluffy@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPdAy0qrR7MV/2dsb2JhbAC8NohjAY85BoQq X-IronPort-AV: E=Sophos;i="4.44,514,1249257600"; d="scan'208";a="211667822" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 06 Oct 2009 20:08:37 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n96K8bVe013771; Tue, 6 Oct 2009 13:08:37 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n96K8aVY014332; Tue, 6 Oct 2009 20:08:37 GMT From: Cullen Jennings To: jc In-Reply-To: <4BE1B9C2-2AD7-48D0-BA50-A3683E2E075E@orchidseed.org> Impp: xmpp:cullenfluffyjennings@jabber.org References: <4BE1B9C2-2AD7-48D0-BA50-A3683E2E075E@orchidseed.org> Message-Id: <3F00B9A6-8FE2-4377-AC9B-5D6A14F8148E@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Oct 2009 14:08:36 -0600 X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=880; t=1254859717; x=1255723717; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=2010.4.=20=20Searching=20for=2 0a=20Bootstrap=20Peer |Sender:=20; bh=Eu46meWeSz1YxwBUIF6tLapuLGZIkxFC2CzJksuDyLA=; b=M/XBmPMG65Cu6YnM4NCCGmMuMUI678XQ88+fCfc2gnD1K+NJTgAnrJ8Kut DoLIetZCT+TMLRzlr/ZtnGxotUUGYktn13oDIHs9bDv5Isno6+Sm+mrAtR2R 1/mevxhx9Dw9K1DdN/iQpx81V2yf/gfxviWr6r1AjJUGqMY+exQfo=; Cc: p2psip WG Subject: Re: [P2PSIP] 10.4. Searching for a Bootstrap Peer X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 20:07:00 -0000 The rev I just submitted did not update all the XML but the XML, and more importantly the schema for it, are out of date and need to be updated. Thanks for sending this and the others - it will get put in on the editorial update. . On Sep 11, 2009, at 11:15 PM, jc wrote: > Hi, > This section states: > > If no cached bootstrap peers are available and the config file has > an broadcast-peers element > > ...however there is no "broadcast-peers" element. Also the draft > doesn't mention anywhere that all nodes must subscribe to the > multicast group "multicast-bootstrap" > if it is found in the configuration file. I assume the later is the > intended to be there but simply missing? > > Julian > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From julian@orchidseed.org Tue Oct 6 13:10:04 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0532E3A69DA for ; Tue, 6 Oct 2009 13:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HphHA+EGzLVN for ; Tue, 6 Oct 2009 13:10:03 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id 1AAAA3A68FF for ; Tue, 6 Oct 2009 13:10:03 -0700 (PDT) Received: from z65-50-24-39.ips.direcpath.com ([65.50.24.39]:50079 helo=[192.168.1.107]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MvGNm-0002T6-Nk; Tue, 06 Oct 2009 13:11:40 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: <8FDC180D-74F4-4875-A4A1-64D1034667C9@cisco.com> Date: Tue, 6 Oct 2009 16:11:02 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <8FDC180D-74F4-4875-A4A1-64D1034667C9@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 20:10:04 -0000 Thanks Cullen and everyone else. Julian On Oct 6, 2009, at 1:52 PM, Cullen Jennings wrote: > > I just submitted > draft-ietf-p2psip-base-04 > and > draft-ietf-p2psip-sip-02 > > These contain technical changes but do not have a lot of editorial > changes. At some point we need to go and reorganize the documents > with editorial changes. > > Cullen > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From julian@orchidseed.org Tue Oct 6 13:13:03 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C36C3A68C5 for ; Tue, 6 Oct 2009 13:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vr4SmhA64dFj for ; Tue, 6 Oct 2009 13:13:02 -0700 (PDT) Received: from n13.c05.mtsvc.net (n13.c05.mtsvc.net [70.32.68.13]) by core3.amsl.com (Postfix) with ESMTP id DA1623A6997 for ; Tue, 6 Oct 2009 13:13:02 -0700 (PDT) Received: from z65-50-24-39.ips.direcpath.com ([65.50.24.39]:50141 helo=[192.168.1.107]) by n13.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MvGQh-0007uN-2r; Tue, 06 Oct 2009 13:14:40 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: <3F00B9A6-8FE2-4377-AC9B-5D6A14F8148E@cisco.com> Date: Tue, 6 Oct 2009 16:14:36 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <4BE1B9C2-2AD7-48D0-BA50-A3683E2E075E@orchidseed.org> <3F00B9A6-8FE2-4377-AC9B-5D6A14F8148E@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] 10.4. Searching for a Bootstrap Peer X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 20:13:03 -0000 ok, great. Thanks again. Julian On Oct 6, 2009, at 4:08 PM, Cullen Jennings wrote: > > The rev I just submitted did not update all the XML but the XML, and > more importantly the schema for it, are out of date and need to be > updated. Thanks for sending this and the others - it will get put in > on the editorial update. . > > On Sep 11, 2009, at 11:15 PM, jc wrote: > >> Hi, >> This section states: >> >> If no cached bootstrap peers are available and the config file has >> an broadcast-peers element >> >> ...however there is no "broadcast-peers" element. Also the draft >> doesn't mention anywhere that all nodes must subscribe to the >> multicast group "multicast-bootstrap" >> if it is found in the configuration file. I assume the later is the >> intended to be there but simply missing? >> >> Julian >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > From dyork@voxeo.com Wed Oct 7 07:29:22 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEEB43A6AA3 for ; Wed, 7 Oct 2009 07:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coB9yXXBBwr3 for ; Wed, 7 Oct 2009 07:29:21 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 6E9D93A6A94 for ; Wed, 7 Oct 2009 07:29:21 -0700 (PDT) Received: from [66.65.229.48] (account dyork HELO pc-00148.lodestar2.local) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 51577871; Wed, 07 Oct 2009 14:30:54 +0000 Message-Id: <7066DEA9-A931-4DE6-B3B9-10E443E1939D@voxeo.com> From: Dan York To: Enrico Marocco In-Reply-To: <4AC3CEF4.3000508@telecomitalia.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 7 Oct 2009 10:30:51 -0400 References: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> <4AC3CEF4.3000508@telecomitalia.it> X-Mailer: Apple Mail (2.936) Cc: P2PSIP WG Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 14:29:22 -0000 Enrico, Thank you for alerting us to this survey and, speaking for the security draft author team, I'll say that it definitely sounds like something we should consider. Thanks. Thank you, as well, for your support of adopting the draft as a WG item. Dan On Sep 30, 2009, at 5:34 PM, Enrico Marocco wrote: > The P2P Research Group is publishing a survey on security issues in > p2p > overlays for realtime communications that I think this draft should in > some ways take into consideration, e.g. discussing how the various > attacks and possible solutions apply to the very specific P2PSIP case. > The survey is draft-irtf-p2prg-rtc-security; IIRC it has passed IRSG > review and is now headed to the IESG. > > Sorry for not pointing this out earlier -- while this was discussed in > Stockholm I was probably in a jet lag coma on those fantastic Swedish > chairs ;-) > > Anyways, I support its adoption as WG item. > > Enrico > > David A. Bryan wrote: >> As Dan mentions below, there was a call in Stockholm to (pending the >> changes requested) adopt this work as a WG item: >> >> http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-00.txt >> >> As the authors feel they have made the requested changes, I'd like to >> ask folks on list to confirm this consensus. Please send comments >> about adoption to the list, and we'll make a call after there has >> been >> time to review and comment (at least a week). >> >> Thanks, >> >> David (as chair) >> >> On Mon, Sep 28, 2009 at 5:31 PM, Dan York wrote: >>> P2PSIP working group members, >>> >>> At IETF 75, we were given the direction to remove the RFC 2119 >>> language from >>> the document and move it from being a normative doc to a purely >>> informational doc. I have now started this and made a number of >>> other >>> changes, including most notably the name change from >>> "p2psip-security-requirements" to "p2psip-security-overview": >>> >>> http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-00.txt >>> >>> Chairs, per the discussion that apparently happened at IETF75, we >>> would like >>> to ask for this to be considered as a working group document. >>> >>> Please note... I made a mistake in the submission process and also >>> submitted >>> this as: >>> >>> http://www.ietf.org/id/draft-matuszewski-p2psip-security-requirements-06.txt >>> >>> They are IDENTICAL except for the name change. >>> >>> Thank you for your consideration, >>> Dan >>> >>> -- >>> Dan York, Director of Conversations >>> Voxeo Corporation http://www.voxeo.com dyork@voxeo.com >>> Phone: +1-407-455-5859 Skype: danyork >>> >>> Join the Voxeo conversation: >>> Blogs: http://blogs.voxeo.com >>> Twitter: http://twitter.com/voxeo http://twitter.com/danyork >>> Facebook: http://www.facebook.com/voxeo >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip -- Dan York, Director of Conversations Voxeo Corporation http://www.voxeo.com dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork Join the Voxeo conversation: Blogs: http://blogs.voxeo.com Twitter: http://twitter.com/voxeo http://twitter.com/danyork Facebook: http://www.facebook.com/voxeo From davidbryan@gmail.com Wed Oct 7 09:15:02 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8D528C1B0 for ; Wed, 7 Oct 2009 09:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.757 X-Spam-Level: X-Spam-Status: No, score=-1.757 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJeaMO4249jF for ; Wed, 7 Oct 2009 09:15:01 -0700 (PDT) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id 5A54B28C172 for ; Wed, 7 Oct 2009 09:15:01 -0700 (PDT) Received: by ywh1 with SMTP id 1so4377354ywh.18 for ; Wed, 07 Oct 2009 09:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=tgNbDfshTn8DJHZa8hcMino2DRYJ9+aFXTEClT0fzWo=; b=EpNldIAKIUMDywon1QeDvMm++SASOjRH8t9tyql9t8kPItrE2wMSmttVdY3Kv02qiw YFecSjTUgIBg0Ux7AfB8cdyte8ScPnEmteeExwGYZI6CaAHmK1Zu2RPFOF+eu8NntSY3 JmSHR92BU9uhv8siLwSCZUh0NABb9GnEWvizE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ROcTYI2gmpyJzXMTx6qyI+AeHZOsABLtSfREqNQct5kQZ4AM3jQJd5OXTjkHazPW8a cUZGT/cdoa07GvZ9FMMv5WaP1F0VkhVF9+cqh4M5sPIvBdBvDeik931aTpfAl6yzgOfG oRCfg9KmGgxdfElJid3g7srn5shUbnNTg1Ny8= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.2.9 with SMTP id 9mr380470ybb.58.1254932198669; Wed, 07 Oct 2009 09:16:38 -0700 (PDT) In-Reply-To: <7066DEA9-A931-4DE6-B3B9-10E443E1939D@voxeo.com> References: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> <4AC3CEF4.3000508@telecomitalia.it> <7066DEA9-A931-4DE6-B3B9-10E443E1939D@voxeo.com> Date: Wed, 7 Oct 2009 12:16:38 -0400 X-Google-Sender-Auth: 88df7734bef26d86 Message-ID: <8b2769930910070916l39dcb637kf9ffb10f9dabbaf8@mail.gmail.com> From: "David A. Bryan" To: Dan York Content-Type: text/plain; charset=ISO-8859-1 Cc: P2PSIP WG Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 16:15:02 -0000 Seeing as we've had no objections for a week, I'll take that as list confirmation of the room consensus Brian called in Stockholm, adopting the security overview as a WG item. David (as chair) On Wed, Oct 7, 2009 at 10:30 AM, Dan York wrote: > Enrico, > > Thank you for alerting us to this survey and, speaking for the security > draft author team, I'll say that it definitely sounds like something we > should consider. Thanks. > > Thank you, as well, for your support of adopting the draft as a WG item. > > Dan > > > On Sep 30, 2009, at 5:34 PM, Enrico Marocco wrote: > >> The P2P Research Group is publishing a survey on security issues in p2p >> overlays for realtime communications that I think this draft should in >> some ways take into consideration, e.g. discussing how the various >> attacks and possible solutions apply to the very specific P2PSIP case. >> The survey is draft-irtf-p2prg-rtc-security; IIRC it has passed IRSG >> review and is now headed to the IESG. >> >> Sorry for not pointing this out earlier -- while this was discussed in >> Stockholm I was probably in a jet lag coma on those fantastic Swedish >> chairs ;-) >> >> Anyways, I support its adoption as WG item. >> >> Enrico >> >> David A. Bryan wrote: >>> >>> As Dan mentions below, there was a call in Stockholm to (pending the >>> changes requested) adopt this work as a WG item: >>> >>> http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-00.txt >>> >>> As the authors feel they have made the requested changes, I'd like to >>> ask folks on list to confirm this consensus. Please send comments >>> about adoption to the list, and we'll make a call after there has been >>> time to review and comment (at least a week). >>> >>> Thanks, >>> >>> David (as chair) >>> >>> On Mon, Sep 28, 2009 at 5:31 PM, Dan York wrote: >>>> >>>> P2PSIP working group members, >>>> >>>> At IETF 75, we were given the direction to remove the RFC 2119 language >>>> from >>>> the document and move it from being a normative doc to a purely >>>> informational doc. I have now started this and made a number of other >>>> changes, including most notably the name change from >>>> "p2psip-security-requirements" to "p2psip-security-overview": >>>> >>>> http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-00.txt >>>> >>>> Chairs, per the discussion that apparently happened at IETF75, we would >>>> like >>>> to ask for this to be considered as a working group document. >>>> >>>> Please note... I made a mistake in the submission process and also >>>> submitted >>>> this as: >>>> >>>> >>>> http://www.ietf.org/id/draft-matuszewski-p2psip-security-requirements-06.txt >>>> >>>> They are IDENTICAL except for the name change. >>>> >>>> Thank you for your consideration, >>>> Dan >>>> >>>> -- >>>> Dan York, Director of Conversations >>>> Voxeo Corporation http://www.voxeo.com dyork@voxeo.com >>>> Phone: +1-407-455-5859 Skype: danyork >>>> >>>> Join the Voxeo conversation: >>>> Blogs: http://blogs.voxeo.com >>>> Twitter: http://twitter.com/voxeo http://twitter.com/danyork >>>> Facebook: http://www.facebook.com/voxeo >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > -- > Dan York, Director of Conversations > Voxeo Corporation http://www.voxeo.com dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork > > Join the Voxeo conversation: > Blogs: http://blogs.voxeo.com > Twitter: http://twitter.com/voxeo http://twitter.com/danyork > Facebook: http://www.facebook.com/voxeo > > > > > > > > > From ekr@rtfm.com Wed Oct 7 09:20:11 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413D33A6902 for ; Wed, 7 Oct 2009 09:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knaebB3E1rqF for ; Wed, 7 Oct 2009 09:20:10 -0700 (PDT) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.210.194]) by core3.amsl.com (Postfix) with ESMTP id E18CF3A6778 for ; Wed, 7 Oct 2009 09:20:09 -0700 (PDT) Received: by yxe32 with SMTP id 32so5354225yxe.5 for ; Wed, 07 Oct 2009 09:21:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.40.37 with SMTP id n37mr98231agn.74.1254932504901; Wed, 07 Oct 2009 09:21:44 -0700 (PDT) In-Reply-To: <8b2769930910070916l39dcb637kf9ffb10f9dabbaf8@mail.gmail.com> References: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> <4AC3CEF4.3000508@telecomitalia.it> <7066DEA9-A931-4DE6-B3B9-10E443E1939D@voxeo.com> <8b2769930910070916l39dcb637kf9ffb10f9dabbaf8@mail.gmail.com> Date: Wed, 7 Oct 2009 09:21:44 -0700 Message-ID: From: Eric Rescorla To: "David A. Bryan" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 16:20:11 -0000 David, I think calling consensus here is slightly premature. I have not had time to review this document and plan to do so today. My impression was Cullen intended to do so as well. -Ekr On Wed, Oct 7, 2009 at 9:16 AM, David A. Bryan wrote: > Seeing as we've had no objections for a week, I'll take that as list > confirmation of the room consensus Brian called in Stockholm, adopting > the security overview as a WG item. > > David (as chair) > > On Wed, Oct 7, 2009 at 10:30 AM, Dan York wrote: >> Enrico, >> >> Thank you for alerting us to this survey and, speaking for the security >> draft author team, I'll say that it definitely sounds like something we >> should consider. =A0Thanks. >> >> Thank you, as well, for your support of adopting the draft as a WG item. >> >> Dan >> >> >> On Sep 30, 2009, at 5:34 PM, Enrico Marocco wrote: >> >>> The P2P Research Group is publishing a survey on security issues in p2p >>> overlays for realtime communications that I think this draft should in >>> some ways take into consideration, e.g. discussing how the various >>> attacks and possible solutions apply to the very specific P2PSIP case. >>> The survey is draft-irtf-p2prg-rtc-security; IIRC it has passed IRSG >>> review and is now headed to the IESG. >>> >>> Sorry for not pointing this out earlier -- while this was discussed in >>> Stockholm I was probably in a jet lag coma on those fantastic Swedish >>> chairs ;-) >>> >>> Anyways, I support its adoption as WG item. >>> >>> Enrico >>> >>> David A. Bryan wrote: >>>> >>>> As Dan mentions below, there was a call in Stockholm to (pending the >>>> changes requested) adopt this work as a WG item: >>>> >>>> http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-00.t= xt >>>> >>>> As the authors feel they have made the requested changes, I'd like to >>>> ask folks on list to confirm this consensus. Please send comments >>>> about adoption to the list, and we'll make a call after there has been >>>> time to review and comment (at least a week). >>>> >>>> Thanks, >>>> >>>> David (as chair) >>>> >>>> On Mon, Sep 28, 2009 at 5:31 PM, Dan York wrote: >>>>> >>>>> P2PSIP working group members, >>>>> >>>>> At IETF 75, we were given the direction to remove the RFC 2119 langua= ge >>>>> from >>>>> the document and move it from being a normative doc to a purely >>>>> informational doc. =A0I have now started this and made a number of ot= her >>>>> changes, including most notably the name change from >>>>> "p2psip-security-requirements" to "p2psip-security-overview": >>>>> >>>>> http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-00.= txt >>>>> >>>>> Chairs, per the discussion that apparently happened at IETF75, we wou= ld >>>>> like >>>>> to ask for this to be considered as a working group document. >>>>> >>>>> Please note... I made a mistake in the submission process and also >>>>> submitted >>>>> this as: >>>>> >>>>> >>>>> http://www.ietf.org/id/draft-matuszewski-p2psip-security-requirements= -06.txt >>>>> >>>>> They are IDENTICAL except for the name change. >>>>> >>>>> Thank you for your consideration, >>>>> Dan >>>>> >>>>> -- >>>>> Dan York, Director of Conversations >>>>> Voxeo Corporation =A0 http://www.voxeo.com =A0dyork@voxeo.com >>>>> Phone: +1-407-455-5859 =A0 =A0Skype: danyork >>>>> >>>>> Join the Voxeo conversation: >>>>> Blogs: http://blogs.voxeo.com >>>>> Twitter: http://twitter.com/voxeo =A0http://twitter.com/danyork >>>>> Facebook: http://www.facebook.com/voxeo >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> >> -- >> Dan York, Director of Conversations >> Voxeo Corporation =A0 http://www.voxeo.com =A0dyork@voxeo.com >> Phone: +1-407-455-5859 =A0 =A0Skype: danyork >> >> Join the Voxeo conversation: >> Blogs: http://blogs.voxeo.com >> Twitter: http://twitter.com/voxeo =A0http://twitter.com/danyork >> Facebook: http://www.facebook.com/voxeo >> >> >> >> >> >> >> >> >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From davidbryan@gmail.com Wed Oct 7 09:29:15 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11BD3A6966 for ; Wed, 7 Oct 2009 09:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVJnYHuhMplk for ; Wed, 7 Oct 2009 09:29:14 -0700 (PDT) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id 337F23A6930 for ; Wed, 7 Oct 2009 09:29:03 -0700 (PDT) Received: by ywh1 with SMTP id 1so4390868ywh.18 for ; Wed, 07 Oct 2009 09:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=aATlQ9J29BLU9XatyPkr1t1oOLjIycQ4MBFRgTSWt78=; b=KhGbriLU/dDvpVA4zqVH8nRMxbr5aUAeyDdxkb7r+myDw7QeBMTh5I+lx7zE70DMWv tt4SVgdgJmAPsrOr8hLD5Dad5hSYdC0eso26dVNKdBnMYbh+hfoFt2TrMvMIa1m0WmE8 qG2iW9dOKkoTBXIgutiTGI5boCRvv8IaS2uww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=R5dkcaCHsEnvahj1JkCWboNKU2YeCzH43opeGt+5EYALa8nBHkc/t3/iQlxrkIUeKu GmEZimMwjHGLzuI16kK2M/cybmMO/tngtnzlspp0xGZmAmtev6tAiAWT2ZLwKT4yuNz4 +7IomNaNwVI5u/043YganCk69B+36lRHOqmXc= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.243.21 with SMTP id q21mr350256ybh.215.1254933040436; Wed, 07 Oct 2009 09:30:40 -0700 (PDT) In-Reply-To: References: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> <4AC3CEF4.3000508@telecomitalia.it> <7066DEA9-A931-4DE6-B3B9-10E443E1939D@voxeo.com> <8b2769930910070916l39dcb637kf9ffb10f9dabbaf8@mail.gmail.com> Date: Wed, 7 Oct 2009 12:30:40 -0400 X-Google-Sender-Auth: b5504c3b9bf552e8 Message-ID: <8b2769930910070930y2503ea6bpb299d1c0c7f38629@mail.gmail.com> From: "David A. Bryan" To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Cc: P2PSIP WG Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 16:29:15 -0000 Eric, I don't agree this is premature in any way. We've allowed over a week on this topic. You never posted saying you were reviewing, you have made no comments on list about the draft since Stockholm. Bruce started a thread on the previous version way back on July 25th, and you didn't comment. Are there others besides yourself (and Cullen)? If so, speak up now. Otherwise, we had consensus in the room and allowed a reasonable time for comments on list. David On Wed, Oct 7, 2009 at 12:21 PM, Eric Rescorla wrote: > David, > > I think calling consensus here is slightly premature. > > I have not had time to review this document and plan to do so today. > > My impression was Cullen intended to do so as well. > > -Ekr > > > > On Wed, Oct 7, 2009 at 9:16 AM, David A. Bryan wrote: >> Seeing as we've had no objections for a week, I'll take that as list >> confirmation of the room consensus Brian called in Stockholm, adopting >> the security overview as a WG item. >> >> David (as chair) >> >> On Wed, Oct 7, 2009 at 10:30 AM, Dan York wrote: >>> Enrico, >>> >>> Thank you for alerting us to this survey and, speaking for the security >>> draft author team, I'll say that it definitely sounds like something we >>> should consider. Thanks. >>> >>> Thank you, as well, for your support of adopting the draft as a WG item. >>> >>> Dan >>> >>> >>> On Sep 30, 2009, at 5:34 PM, Enrico Marocco wrote: >>> >>>> The P2P Research Group is publishing a survey on security issues in p2p >>>> overlays for realtime communications that I think this draft should in >>>> some ways take into consideration, e.g. discussing how the various >>>> attacks and possible solutions apply to the very specific P2PSIP case. >>>> The survey is draft-irtf-p2prg-rtc-security; IIRC it has passed IRSG >>>> review and is now headed to the IESG. >>>> >>>> Sorry for not pointing this out earlier -- while this was discussed in >>>> Stockholm I was probably in a jet lag coma on those fantastic Swedish >>>> chairs ;-) >>>> >>>> Anyways, I support its adoption as WG item. >>>> >>>> Enrico >>>> >>>> David A. Bryan wrote: >>>>> >>>>> As Dan mentions below, there was a call in Stockholm to (pending the >>>>> changes requested) adopt this work as a WG item: >>>>> >>>>> http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-00.txt >>>>> >>>>> As the authors feel they have made the requested changes, I'd like to >>>>> ask folks on list to confirm this consensus. Please send comments >>>>> about adoption to the list, and we'll make a call after there has been >>>>> time to review and comment (at least a week). >>>>> >>>>> Thanks, >>>>> >>>>> David (as chair) >>>>> >>>>> On Mon, Sep 28, 2009 at 5:31 PM, Dan York wrote: >>>>>> >>>>>> P2PSIP working group members, >>>>>> >>>>>> At IETF 75, we were given the direction to remove the RFC 2119 language >>>>>> from >>>>>> the document and move it from being a normative doc to a purely >>>>>> informational doc. I have now started this and made a number of other >>>>>> changes, including most notably the name change from >>>>>> "p2psip-security-requirements" to "p2psip-security-overview": >>>>>> >>>>>> http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-00.txt >>>>>> >>>>>> Chairs, per the discussion that apparently happened at IETF75, we would >>>>>> like >>>>>> to ask for this to be considered as a working group document. >>>>>> >>>>>> Please note... I made a mistake in the submission process and also >>>>>> submitted >>>>>> this as: >>>>>> >>>>>> >>>>>> http://www.ietf.org/id/draft-matuszewski-p2psip-security-requirements-06.txt >>>>>> >>>>>> They are IDENTICAL except for the name change. >>>>>> >>>>>> Thank you for your consideration, >>>>>> Dan >>>>>> >>>>>> -- >>>>>> Dan York, Director of Conversations >>>>>> Voxeo Corporation http://www.voxeo.com dyork@voxeo.com >>>>>> Phone: +1-407-455-5859 Skype: danyork >>>>>> >>>>>> Join the Voxeo conversation: >>>>>> Blogs: http://blogs.voxeo.com >>>>>> Twitter: http://twitter.com/voxeo http://twitter.com/danyork >>>>>> Facebook: http://www.facebook.com/voxeo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> P2PSIP mailing list >>>>>> P2PSIP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>>> >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>> -- >>> Dan York, Director of Conversations >>> Voxeo Corporation http://www.voxeo.com dyork@voxeo.com >>> Phone: +1-407-455-5859 Skype: danyork >>> >>> Join the Voxeo conversation: >>> Blogs: http://blogs.voxeo.com >>> Twitter: http://twitter.com/voxeo http://twitter.com/danyork >>> Facebook: http://www.facebook.com/voxeo >>> >>> >>> >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> > From ekr@networkresonance.com Wed Oct 7 13:31:21 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2ED93A67FB for ; Wed, 7 Oct 2009 13:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.055 X-Spam-Level: X-Spam-Status: No, score=-0.055 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_74=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X98YSKz7m3s2 for ; Wed, 7 Oct 2009 13:31:20 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 728623A6964 for ; Wed, 7 Oct 2009 13:31:20 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 3DF9E5DD808; Wed, 7 Oct 2009 13:39:13 -0700 (PDT) Date: Wed, 07 Oct 2009 13:39:12 -0700 From: Eric Rescorla To: "David A. Bryan" In-Reply-To: <8b2769930910070930y2503ea6bpb299d1c0c7f38629@mail.gmail.com> References: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> <4AC3CEF4.3000508@telecomitalia.it> <7066DEA9-A931-4DE6-B3B9-10E443E1939D@voxeo.com> <8b2769930910070916l39dcb637kf9ffb10f9dabbaf8@mail.gmail.com> <8b2769930910070930y2503ea6bpb299d1c0c7f38629@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091007203913.3DF9E5DD808@kilo.networkresonance.com> Cc: P2PSIP WG Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 20:31:21 -0000 At Wed, 7 Oct 2009 12:30:40 -0400, David A. Bryan wrote: > > Eric, > > I don't agree this is premature in any way. > > We've allowed over a week on this topic. Well, David, since you insist: your mail asking for a consensus call was sent at 12:25 EST on the 30th and stated: As the authors feel they have made the requested changes, I'd like to ask folks on list to confirm this consensus. Please send comments about adoption to the list, and we'll make a call after there has been time to review and comment (at least a week). This mail declaring consensus was posted at 12:16 EST today, so the amount of time you have allowed, rather than being "at least a week" is actually just under a week, so even by the most generous interpretation of the situation, this is slightly premature. Given that you did not provide any real deadline, it is quite premature. > You never posted saying you > were reviewing, you have made no comments on list about the draft > since Stockholm. Bruce started a thread on the previous version way > back on July 25th, and you didn't comment. Because I had already made comments on the previous version during the meeting. > Are there others besides yourself (and Cullen)? If so, speak up now. > Otherwise, we had consensus in the room and allowed a reasonable time > for comments on list. While I agree, we had consensus in the room, this document does not in fact live up to that consensus. I've just listened to the relevant section of the WG meeting and it was quite clear that what the WG hummed for was as a general tutorial/overview of security in the P2P space. However, it was extremely clear that this document was to be non-normative, as stated by Roni, Brian, and myself. Moreover, this is confirmed by Dan's message when this document was posted: At IETF 75, we were given the direction to remove the RFC 2119 language from the document and move it from being a normative doc to a purely informational doc. I have now started this and made a number of other changes, including most notably the name change from "p2psip-security-requirements" to "p2psip-security-overview": While the 2119 language was removed, which is a start (and I realize I focused on this over Jabber, but limited bandwidth is a cost of not being in the room), the document is full of normative text, albeit not rendered in upper case. I count 23 separate instances of the word "must" and "30" of the word "should". For example: S 5.1. protected against attacks(such as Man-in-the-Middle). In order to establish the identity trust association, nodes must authenticate each other with e.g. TLS and DTLS. If transport service security is provided, we can prevent nodes without valid identities to participate in the overlay. This layer must provides reliable and secure hop-by-hop transport service for the P2P overlay. This alone, though, is not enough to secure the P2P system. S 8.1. The user wants available and reliable service that enables him to interact with other users and resources in a secure way. This means that the P2PSIP system must provide: Worse yet, some of these actually contradict design decisions that have already been made in RELOAD: S 8.2.11. The security of P2PSIP systems must guarantee privacy of the P2PSIP network participants. The P2PSIP security should allow the users and P2PSIP network entities to indicate which other users or P2PSIP network entities can retrieve, modify, and delete data stored in their P2PSIP resource (user) records. The owner of a P2PSIP resource (user) record should be able to limit the access to his own resource (user) records, and this feature should be enforced by the P2P network. This is a particularly egregious case since there is no known mechanism for securely providing read-level access in a P2P storage network, which is why RELOAD assumes that data confidentiality will be solved by encryption rather than access control. This material is not even remotely tutorial in nature. Quite the contrary, it is requirements text, regardless of the fact that it's not capitalized. In order for this document to conform to the consensus in Stockholm, then, all this language needs to be removed. If the authors/WG feel it is important, it might be replaced with descriptions of the security consequences of various design choices. However, as it stands, no I don't agree that this document either is acceptable or that it has consensus: the consensus in Stockholm was contingent on changes that have not been made, and the overwhelming silence on the mailing list after this revision is not at all the same as consensus. -Ekr From davidbryan@gmail.com Wed Oct 7 13:54:32 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0230F28C0F0 for ; Wed, 7 Oct 2009 13:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43iNsZCEu58a for ; Wed, 7 Oct 2009 13:54:31 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.211.179]) by core3.amsl.com (Postfix) with ESMTP id D0BE23A67F3 for ; Wed, 7 Oct 2009 13:54:30 -0700 (PDT) Received: by ywh9 with SMTP id 9so5749177ywh.19 for ; Wed, 07 Oct 2009 13:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=AEiCRsXOHUjF9chKYHQj8O5zKKbs6mauw6gzeoqkDF4=; b=Bh3FCefJWHQSFI37vYruEROJ1lcR9eIgfNoRTmvhqdgeUPtJJ6elHP9SzaFc7b09c2 f/WIcqQZjOSFsYEBcq5M9Mx6pW2iPA5tc6HPCLH7/5rOYw5uTzsUvXfcMUHS5GNZb+fH AS0EFeeUPsnzxtOQFpX0sIovfK1jU+IpOzMKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=HNy/vzlt72fVo/SgnlqCXepLq5ftRmc2G29Yo9xVDJ9LUyO1YemB2ZstSQvsQkUeYC aGMJC+2LB4Hp1M33mlIpPKo4ssFr548+66XtVBciIT5cFHoR29alhgpj6S0M2cAMCeL5 1DhXhpuaiqvhtpb106l6q0v0GfKJUGfGm3Xl0= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.87.24 with SMTP id k24mr849003ybb.144.1254948968549; Wed, 07 Oct 2009 13:56:08 -0700 (PDT) In-Reply-To: <20091007203913.3DF9E5DD808@kilo.networkresonance.com> References: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> <4AC3CEF4.3000508@telecomitalia.it> <7066DEA9-A931-4DE6-B3B9-10E443E1939D@voxeo.com> <8b2769930910070916l39dcb637kf9ffb10f9dabbaf8@mail.gmail.com> <8b2769930910070930y2503ea6bpb299d1c0c7f38629@mail.gmail.com> <20091007203913.3DF9E5DD808@kilo.networkresonance.com> Date: Wed, 7 Oct 2009 16:56:08 -0400 X-Google-Sender-Auth: 02be23b6e3c3b151 Message-ID: <8b2769930910071356m669c9b61tc7a3f2600d84a61f@mail.gmail.com> From: "David A. Bryan" To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Cc: P2PSIP WG Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 20:54:32 -0000 Well, I'm not even going to justify ludicrous pedantry over 9 minutes with a response...moving on to potentially substantive issues... >> You never posted saying you >> were reviewing, you have made no comments on list about the draft >> since Stockholm. Bruce started a thread on the previous version way >> back on July 25th, and you didn't comment. > > Because I had already made comments on the previous version during > the meeting. While your points below are worth considering, this particular point by itself is procedurally not relevant. You objected in the meeting, but despite this, consensus was to adopt the document (if the changes were made -- see below). You of course are still welcome to make the same objections on list, but it there is consensus, the fact you objected before the consensus call in the room and make the same objection now doesn't lack of consensus make. See http://tools.ietf.org/html/draft-dusseault-consensus-00 ... With those out of the way, the concern below is a potentially valid one: > While I agree, we had consensus in the room, this document does not in > fact live up to that consensus. I've just listened to the relevant > section of the WG meeting and it was quite clear that what the WG > hummed for was as a general tutorial/overview of security in the P2P > space. However, it was extremely clear that this document was to be > non-normative, as stated by Roni, Brian, and myself. Moreover, this > is confirmed by Dan's message when this document was posted: > > At IETF 75, we were given the direction to remove the RFC 2119 language from > the document and move it from being a normative doc to a purely > informational doc. I have now started this and made a number of other > changes, including most notably the name change from > "p2psip-security-requirements" to "p2psip-security-overview": > > While the 2119 language was removed, which is a start (and I realize I > focused on this over Jabber, but limited bandwidth is a cost of not > being in the room), the document is full of normative text, albeit > not rendered in upper case. I count 23 separate instances of the > word "must" and "30" of the word "should". For example: etc... What do others think of this concern? Do you feel that the document has been sufficiently modified that it reflects the intent of the WG desire to see it moving toward a tutorial? Obviously it is unreasonable to ask that it be perfect before it is adopted as WG item -- this isn't a WG last call, and WG items often are adopted while needing changes, corrections, additional work, etc.. That said, the question to the group is: 1) Do others agree with EKR that the document has not moved sufficiently in the direction requested in Stockholm and thus should NOT be adopted as a WG item or 2) Do people believe the changes request have more or less been made, and it should be adopted. David (as chair) > S 5.1. > protected against attacks(such as Man-in-the-Middle). In order to > establish the identity trust association, nodes must authenticate > each other with e.g. TLS and DTLS. If transport service security is > provided, we can prevent nodes without valid identities to > participate in the overlay. This layer must provides reliable and > secure hop-by-hop transport service for the P2P overlay. This alone, > though, is not enough to secure the P2P system. > > S 8.1. > The user wants available and reliable service that enables him to > interact with other users and resources in a secure way. This means > that the P2PSIP system must provide: > > Worse yet, some of these actually contradict design decisions that > have already been made in RELOAD: > > S 8.2.11. > The security of P2PSIP systems must guarantee privacy of the P2PSIP > network participants. The P2PSIP security should allow the users and > P2PSIP network entities to indicate which other users or P2PSIP > network entities can retrieve, modify, and delete data stored in > their P2PSIP resource (user) records. The owner of a P2PSIP resource > (user) record should be able to limit the access to his own resource > (user) records, and this feature should be enforced by the P2P > network. > > This is a particularly egregious case since there is no known > mechanism for securely providing read-level access in a P2P storage > network, which is why RELOAD assumes that data confidentiality will be > solved by encryption rather than access control. > > This material is not even remotely tutorial in nature. Quite the > contrary, it is requirements text, regardless of the fact that it's > not capitalized. In order for this document to conform to the > consensus in Stockholm, then, all this language needs to be > removed. If the authors/WG feel it is important, it might be replaced > with descriptions of the security consequences of various design > choices. However, as it stands, no I don't agree that this document > either is acceptable or that it has consensus: the consensus in > Stockholm was contingent on changes that have not been made, and the > overwhelming silence on the mailing list after this revision is not at > all the same as consensus. > > -Ekr > From ekr@networkresonance.com Wed Oct 7 14:02:25 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7524028C0F4 for ; Wed, 7 Oct 2009 14:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=0.954, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akSCQeoeC0aj for ; Wed, 7 Oct 2009 14:02:24 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 94C3928C0F0 for ; Wed, 7 Oct 2009 14:02:24 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 7C28350822; Wed, 7 Oct 2009 14:03:57 -0700 (PDT) Date: Wed, 07 Oct 2009 14:03:57 -0700 From: Eric Rescorla To: "David A. Bryan" In-Reply-To: <8b2769930910071356m669c9b61tc7a3f2600d84a61f@mail.gmail.com> References: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> <4AC3CEF4.3000508@telecomitalia.it> <7066DEA9-A931-4DE6-B3B9-10E443E1939D@voxeo.com> <8b2769930910070916l39dcb637kf9ffb10f9dabbaf8@mail.gmail.com> <8b2769930910070930y2503ea6bpb299d1c0c7f38629@mail.gmail.com> <20091007203913.3DF9E5DD808@kilo.networkresonance.com> <8b2769930910071356m669c9b61tc7a3f2600d84a61f@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091007210357.7C28350822@romeo.rtfm.com> Cc: P2PSIP WG Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 21:02:25 -0000 At Wed, 7 Oct 2009 16:56:08 -0400, David A. Bryan wrote: > > Well, I'm not even going to justify ludicrous pedantry over 9 minutes > with a response...moving on to potentially substantive issues... David, Of course, you're mischaracterizing my point, but what's actually ludicrous is you doing a consensus call with no firm deadline and then attempting to ignore feedback that arrives within a time period reasonably implied by your vague deadline. If you intend to be hard about deadlines, then they need to be clearly stated. > >> You never posted saying you > >> were reviewing, you have made no comments on list about the draft > >> since Stockholm. Bruce started a thread on the previous version way > >> back on July 25th, and you didn't comment. > > > > Because I had already made comments on the previous version during > > the meeting. > > While your points below are worth considering, this particular point > by itself is procedurally not relevant. What it's relevant to, David, is your argument that "Bruce started a thread on the previous version way back on July 25th, and you didn't comment." Comments don't go away just because they aren't repeated incessantly. > You of course are still welcome to make the same objections on list, > but it there is consensus, the fact you objected before the consensus > call in the room and make the same objection now doesn't lack of > consensus make. See > http://tools.ietf.org/html/draft-dusseault-consensus-00 ... > > With those out of the way, the concern below is a potentially valid one: The problem here, David, is that you don't have consensus to accept this document in its current state. As I stated, there was consensus in the room to accept the document pending a particular set of changes. I claim those changes have not been made. Absent an affirmative showing on the list or in a meeting that there is consensus that those changes have in fact been made at this time, there simply is no showing of consensus to accept this document as-is and having it published as a WG document is a process error. Silence is not consent. -Ekr From davidbryan@gmail.com Wed Oct 7 14:20:36 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29143A6914 for ; Wed, 7 Oct 2009 14:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.782 X-Spam-Level: X-Spam-Status: No, score=-1.782 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyOUswzkwVwV for ; Wed, 7 Oct 2009 14:20:35 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.211.179]) by core3.amsl.com (Postfix) with ESMTP id 9E4CF3A67A8 for ; Wed, 7 Oct 2009 14:20:35 -0700 (PDT) Received: by ywh9 with SMTP id 9so5772661ywh.19 for ; Wed, 07 Oct 2009 14:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=VvNceEZaJk7nIUMQThxm3B+TuwPC9TMahEV8rn274w4=; b=gqNej+f8mSbc+75YJbVWPJNjX5leOok9WBwnkqjbx88ALTN6cDcdlFmRt73BtFCcFm LDbjtzCprybnMw/2kAyCiGuMI4t5hNMVBVC5rdzmfmWxF7EyK5phHVRuJCU0QRdhe7zG bpYugPp/RqGVId6xLU9lrTJ73nOjmMvvLlD88= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=iZH25VPhl9SJTtMh+1gb5Au+3PkUv7PczDzTY0WzYwxRmlRXAmiuxexzvpMSwZrqEs owhoFmR0n2uABAoLN87D3rLzw5VY6fpQir8G6Ci2yQt78eXBm5t9vvKK4vcto5o6vxKo EyaG+09tlIvBjo8T2Yuk4UnlYTRYBqeEMzSNI= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.151.18.5 with SMTP id v5mr842054ybi.219.1254950529867; Wed, 07 Oct 2009 14:22:09 -0700 (PDT) In-Reply-To: <20091007210357.7C28350822@romeo.rtfm.com> References: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> <4AC3CEF4.3000508@telecomitalia.it> <7066DEA9-A931-4DE6-B3B9-10E443E1939D@voxeo.com> <8b2769930910070916l39dcb637kf9ffb10f9dabbaf8@mail.gmail.com> <8b2769930910070930y2503ea6bpb299d1c0c7f38629@mail.gmail.com> <20091007203913.3DF9E5DD808@kilo.networkresonance.com> <8b2769930910071356m669c9b61tc7a3f2600d84a61f@mail.gmail.com> <20091007210357.7C28350822@romeo.rtfm.com> Date: Wed, 7 Oct 2009 17:22:09 -0400 X-Google-Sender-Auth: cd309d46182746c0 Message-ID: <8b2769930910071422x6ba2375ve7b84911755dbdd4@mail.gmail.com> From: "David A. Bryan" To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Cc: P2PSIP WG Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 21:20:36 -0000 On Wed, Oct 7, 2009 at 5:03 PM, Eric Rescorla wrote: > At Wed, 7 Oct 2009 16:56:08 -0400, > David A. Bryan wrote: >> >> Well, I'm not even going to justify ludicrous pedantry over 9 minutes >> with a response...moving on to potentially substantive issues... > > David, > > Of course, you're mischaracterizing my point, but what's actually > ludicrous is you doing a consensus call with no firm deadline and then > attempting to ignore feedback that arrives within a time period > reasonably implied by your vague deadline. If you intend to be hard > about deadlines, then they need to be clearly stated. I'm not mischaracterizing your point at all. Honestly, did you intent to comment in those 9 minutes? I stated at least a week. There was not serious discussion (other than one post in favor of adoption, and no objections) for several days, so it seemed that since the issue was settled, and the week had passed, it was time to move on. >> >> You never posted saying you >> >> were reviewing, you have made no comments on list about the draft >> >> since Stockholm. Bruce started a thread on the previous version way >> >> back on July 25th, and you didn't comment. >> > >> > Because I had already made comments on the previous version during >> > the meeting. >> >> While your points below are worth considering, this particular point >> by itself is procedurally not relevant. > > What it's relevant to, David, is your argument that "Bruce started a > thread on the previous version way back on July 25th, and you didn't > comment." Comments don't go away just because they aren't repeated > incessantly. > >> You of course are still welcome to make the same objections on list, >> but it there is consensus, the fact you objected before the consensus >> call in the room and make the same objection now doesn't lack of >> consensus make. See >> http://tools.ietf.org/html/draft-dusseault-consensus-00 ... >> >> With those out of the way, the concern below is a potentially valid one: > > The problem here, David, is that you don't have consensus to accept > this document in its current state. As I stated, there was consensus > in the room to accept the document pending a particular set of > changes. I claim those changes have not been made. Absent an > affirmative showing on the list or in a meeting that there is > consensus that those changes have in fact been made at this time, > there simply is no showing of consensus to accept this document as-is > and having it published as a WG document is a process error. Silence > is not consent. I have again asked the list for input on the concern you raised that the document doesn't reflect the changes requested. Do they feel this document has changed sufficiently to meet the requirements for the hum for adoption Brian called in Stockholm? The authors felt they had made the changes, and asked the chairs to verify this on list. The only comment was a positive. You have objected now, so I asked the list again for their thoughts on adoption. As I am sure you are well aware, consensus can be changed, or heck, the group can have consensus to un-adopt a document months later, decide that an editorial team isn't responsive to the WG and choose a different document in it's place, etc. As of now, the question has been posed to the list again. Do they feel the new document has made sufficient changes to meet the intent of the WG's comment in Stockholm, and feel the document should be adopted? As you have objected, we'll declare that no consensus has been reached yet, and we'll see what the thoughts are on list, but there is no process error here. David (as chair) > -Ekr > From ekr@networkresonance.com Wed Oct 7 15:26:55 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A239328C1D8 for ; Wed, 7 Oct 2009 15:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP0bS5bfDPo1 for ; Wed, 7 Oct 2009 15:26:54 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id B623328C1C4 for ; Wed, 7 Oct 2009 15:26:54 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 277275DD86A; Wed, 7 Oct 2009 15:34:48 -0700 (PDT) Date: Wed, 07 Oct 2009 15:34:47 -0700 From: Eric Rescorla To: "David A. Bryan" In-Reply-To: <8b2769930910071422x6ba2375ve7b84911755dbdd4@mail.gmail.com> References: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> <4AC3CEF4.3000508@telecomitalia.it> <7066DEA9-A931-4DE6-B3B9-10E443E1939D@voxeo.com> <8b2769930910070916l39dcb637kf9ffb10f9dabbaf8@mail.gmail.com> <8b2769930910070930y2503ea6bpb299d1c0c7f38629@mail.gmail.com> <20091007203913.3DF9E5DD808@kilo.networkresonance.com> <8b2769930910071356m669c9b61tc7a3f2600d84a61f@mail.gmail.com> <20091007210357.7C28350822@romeo.rtfm.com> <8b2769930910071422x6ba2375ve7b84911755dbdd4@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091007223448.277275DD86A@kilo.networkresonance.com> Cc: P2PSIP WG Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 22:26:55 -0000 At Wed, 7 Oct 2009 17:22:09 -0400, David A. Bryan wrote: > > On Wed, Oct 7, 2009 at 5:03 PM, Eric Rescorla wrote: > > At Wed, 7 Oct 2009 16:56:08 -0400, > > David A. Bryan wrote: > >> > >> Well, I'm not even going to justify ludicrous pedantry over 9 minutes > >> with a response...moving on to potentially substantive issues... > > > > David, > > > > Of course, you're mischaracterizing my point, but what's actually > > ludicrous is you doing a consensus call with no firm deadline and then > > attempting to ignore feedback that arrives within a time period > > reasonably implied by your vague deadline. If you intend to be hard > > about deadlines, then they need to be clearly stated. > > I'm not mischaracterizing your point at all. Honestly, did you intent > to comment in those 9 minutes? As I stated, I intended to send comments today, which seems well within the bounds of "at least a week." > I stated at least a week. There was not > serious discussion (other than one post in favor of adoption, and no > objections) for several days, so it seemed that since the issue was > settled, and the week had passed, it was time to move on. Let's recap: - You posted a consensus call with a vague deadline of "at least a week" - After slightly less than a week, you declared consensus. - I objected that it was premature. At this point, you had the option of just saying "oops, I guess we don't have consensus" and waiting for my review and whatever discussion ensued. Instead, you opted to get defensive, insist that it wasn't premature, assert that you had "allowed over a week on this topic, and generally blow a lot of smoke about how I hadn't commented in time. It was in that context that I observed that you hadn't even waited a full week. Is it nitpicky? Sure. But if you're going to announce vague deadlines and then treat them as hard, that's what you need to expect. > As of now, the question has been posed to the list again. Do they feel > the new document has made sufficient changes to meet the intent of the > WG's comment in Stockholm, and feel the document should be adopted? As > you have objected, we'll declare that no consensus has been reached > yet, and we'll see what the thoughts are on list, but there is no > process error here. I agree that there is not currently a process error. However, if this document is adopted as a WG document based on silence rather than affirmative consensus, that would be a process error. -Ekr From Even.roni@huawei.com Thu Oct 8 10:51:14 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267F73A6827 for ; Thu, 8 Oct 2009 10:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7FoCa-UlbBt for ; Thu, 8 Oct 2009 10:51:12 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 3B5EF3A67CF for ; Thu, 8 Oct 2009 10:51:07 -0700 (PDT) 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 <0KR700AZ8J00N0@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 09 Oct 2009 01:52:48 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KR700MCNJ00RC@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 09 Oct 2009 01:52:48 +0800 (CST) Received: from YOUR6108 (host6.200-3-76.telecom.net.ar [200.3.76.6]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KR7006BHIZUVJ@szxml01-in.huawei.com>; Fri, 09 Oct 2009 01:52:48 +0800 (CST) Date: Thu, 08 Oct 2009 19:52:51 +0200 From: Roni Even In-reply-to: <20091007203913.3DF9E5DD808@kilo.networkresonance.com> To: 'Eric Rescorla' , "'David A. Bryan'" Message-id: <005b01ca4840$2ae5a3c0$80b0eb40$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: he Content-transfer-encoding: 7BIT Thread-index: AcpHjWOSXhgivGmlQ8CXlayuFzHZlAAsgSwg References: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> <4AC3CEF4.3000508@telecomitalia.it> <7066DEA9-A931-4DE6-B3B9-10E443E1939D@voxeo.com> <8b2769930910070916l39dcb637kf9ffb10f9dabbaf8@mail.gmail.com> <8b2769930910070930y2503ea6bpb299d1c0c7f38629@mail.gmail.com> <20091007203913.3DF9E5DD808@kilo.networkresonance.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 17:51:14 -0000 Hi Eric, About RFC 2119 language. My understanding is that since there is no reference to RFC 2119 which says that "In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used." My understanding is that there is no normative text in the document. The meaning of "must" and "should" when not specified by RFC 2119 does not make them normative. Furthermore the document will be an Informational document Roni Even > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf Of Eric Rescorla > Sent: Wednesday, October 07, 2009 10:39 PM > To: David A. Bryan > Cc: P2PSIP WG > Subject: Re: [P2PSIP] Consensus call on security draft > > At Wed, 7 Oct 2009 12:30:40 -0400, > David A. Bryan wrote: > > > > Eric, > > > > I don't agree this is premature in any way. > > > > We've allowed over a week on this topic. > > Well, David, since you insist: your mail asking for a consensus call > was sent at 12:25 EST on the 30th and stated: > > As the authors feel they have made the requested changes, I'd like > to > ask folks on list to confirm this consensus. Please send comments > about adoption to the list, and we'll make a call after there has > been > time to review and comment (at least a week). > > This mail declaring consensus was posted at 12:16 EST today, so the > amount of time you have allowed, rather than being "at least a week" > is actually just under a week, so even by the most generous > interpretation of the situation, this is slightly premature. Given > that you did not provide any real deadline, it is quite premature. > > > > You never posted saying you > > were reviewing, you have made no comments on list about the draft > > since Stockholm. Bruce started a thread on the previous version way > > back on July 25th, and you didn't comment. > > Because I had already made comments on the previous version during > the meeting. > > > > Are there others besides yourself (and Cullen)? If so, speak up now. > > Otherwise, we had consensus in the room and allowed a reasonable time > > for comments on list. > > While I agree, we had consensus in the room, this document does not in > fact live up to that consensus. I've just listened to the relevant > section of the WG meeting and it was quite clear that what the WG > hummed for was as a general tutorial/overview of security in the P2P > space. However, it was extremely clear that this document was to be > non-normative, as stated by Roni, Brian, and myself. Moreover, this > is confirmed by Dan's message when this document was posted: > > At IETF 75, we were given the direction to remove the RFC 2119 > language from > the document and move it from being a normative doc to a purely > informational doc. I have now started this and made a number of > other > changes, including most notably the name change from > "p2psip-security-requirements" to "p2psip-security-overview": > > While the 2119 language was removed, which is a start (and I realize I > focused on this over Jabber, but limited bandwidth is a cost of not > being in the room), the document is full of normative text, albeit > not rendered in upper case. I count 23 separate instances of the > word "must" and "30" of the word "should". For example: > > S 5.1. > protected against attacks(such as Man-in-the-Middle). In order to > establish the identity trust association, nodes must authenticate > each other with e.g. TLS and DTLS. If transport service security > is > provided, we can prevent nodes without valid identities to > participate in the overlay. This layer must provides reliable and > secure hop-by-hop transport service for the P2P overlay. This > alone, > though, is not enough to secure the P2P system. > > S 8.1. > The user wants available and reliable service that enables him to > interact with other users and resources in a secure way. This means > that the P2PSIP system must provide: > > Worse yet, some of these actually contradict design decisions that > have already been made in RELOAD: > > S 8.2.11. > The security of P2PSIP systems must guarantee privacy of the P2PSIP > network participants. The P2PSIP security should allow the users > and > P2PSIP network entities to indicate which other users or P2PSIP > network entities can retrieve, modify, and delete data stored in > their P2PSIP resource (user) records. The owner of a P2PSIP > resource > (user) record should be able to limit the access to his own resource > (user) records, and this feature should be enforced by the P2P > network. > > This is a particularly egregious case since there is no known > mechanism for securely providing read-level access in a P2P storage > network, which is why RELOAD assumes that data confidentiality will be > solved by encryption rather than access control. > > This material is not even remotely tutorial in nature. Quite the > contrary, it is requirements text, regardless of the fact that it's > not capitalized. In order for this document to conform to the > consensus in Stockholm, then, all this language needs to be > removed. If the authors/WG feel it is important, it might be replaced > with descriptions of the security consequences of various design > choices. However, as it stands, no I don't agree that this document > either is acceptable or that it has consensus: the consensus in > Stockholm was contingent on changes that have not been made, and the > overwhelming silence on the mailing list after this revision is not at > all the same as consensus. > > -Ekr > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4488 (20091007) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4488 (20091007) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4491 (20091008) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4491 (20091008) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From melodysong@huawei.com Thu Oct 8 19:29:23 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD983A6811 for ; Thu, 8 Oct 2009 19:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXAt0kEWdRaC for ; Thu, 8 Oct 2009 19:29:22 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 6925A3A67EC for ; Thu, 8 Oct 2009 19:29:22 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KR8005UP6W7M5@szxga02-in.huawei.com> for p2psip@ietf.org; Fri, 09 Oct 2009 10:28:55 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KR800M1O6W7UF@szxga02-in.huawei.com> for p2psip@ietf.org; Fri, 09 Oct 2009 10:28:55 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KR800MT26W62K@szxml06-in.huawei.com> for p2psip@ietf.org; Fri, 09 Oct 2009 10:28:55 +0800 (CST) Date: Fri, 09 Oct 2009 10:28:55 +0800 From: Song Haibin In-reply-to: To: 'Eric Rescorla' , "'David A. Bryan'" Message-id: <041301ca4888$3fd13db0$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcpHalFTBYzAA0rlSCGhAvggsxy9YQBHI74g Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 02:29:23 -0000 Hi Eric, The only comment raised by you during the meeting and in the mailing = list is about the RFC 2119 language. Roni has replied and gave the authors' explanation in the mailing list. We have not received any further = comments after your planned review. Thanks! Haibin =20 >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org]=20 >On Behalf Of Eric Rescorla >Sent: Thursday, October 08, 2009 12:22 AM >To: David A. Bryan >Cc: P2PSIP WG >Subject: Re: [P2PSIP] Consensus call on security draft > >David, > >I think calling consensus here is slightly premature. > >I have not had time to review this document and plan to do so today. > >My impression was Cullen intended to do so as well. > >-Ekr > > > >On Wed, Oct 7, 2009 at 9:16 AM, David A. Bryan=20 > wrote: >> Seeing as we've had no objections for a week, I'll take that as list=20 >> confirmation of the room consensus Brian called in=20 >Stockholm, adopting=20 >> the security overview as a WG item. >> >> David (as chair) >> >> On Wed, Oct 7, 2009 at 10:30 AM, Dan York wrote: >>> Enrico, >>> >>> Thank you for alerting us to this survey and, speaking for the=20 >>> security draft author team, I'll say that it definitely sounds like=20 >>> something we should consider. =A0Thanks. >>> >>> Thank you, as well, for your support of adopting the draft=20 >as a WG item. >>> >>> Dan >>> >>> >>> On Sep 30, 2009, at 5:34 PM, Enrico Marocco wrote: >>> >>>> The P2P Research Group is publishing a survey on security=20 >issues in=20 >>>> p2p overlays for realtime communications that I think this draft=20 >>>> should in some ways take into consideration, e.g.=20 >discussing how the=20 >>>> various attacks and possible solutions apply to the very=20 >specific P2PSIP case. >>>> The survey is draft-irtf-p2prg-rtc-security; IIRC it has=20 >passed IRSG=20 >>>> review and is now headed to the IESG. >>>> >>>> Sorry for not pointing this out earlier -- while this was=20 >discussed=20 >>>> in Stockholm I was probably in a jet lag coma on those fantastic=20 >>>> Swedish chairs ;-) >>>> >>>> Anyways, I support its adoption as WG item. >>>> >>>> Enrico >>>> >>>> David A. Bryan wrote: >>>>> >>>>> As Dan mentions below, there was a call in Stockholm to (pending=20 >>>>> the changes requested) adopt this work as a WG item: >>>>> >>>>>=20 >http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-0 >>>>> 0.txt >>>>> >>>>> As the authors feel they have made the requested changes,=20 >I'd like=20 >>>>> to ask folks on list to confirm this consensus. Please send=20 >>>>> comments about adoption to the list, and we'll make a call after=20 >>>>> there has been time to review and comment (at least a week). >>>>> >>>>> Thanks, >>>>> >>>>> David (as chair) >>>>> >>>>> On Mon, Sep 28, 2009 at 5:31 PM, Dan York wrote: >>>>>> >>>>>> P2PSIP working group members, >>>>>> >>>>>> At IETF 75, we were given the direction to remove the RFC 2119=20 >>>>>> language from the document and move it from being a=20 >normative doc=20 >>>>>> to a purely informational doc. =A0I have now started this=20 >and made a=20 >>>>>> number of other changes, including most notably the name change=20 >>>>>> from "p2psip-security-requirements" to=20 >"p2psip-security-overview": >>>>>> >>>>>>=20 >http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview- >>>>>> 00.txt >>>>>> >>>>>> Chairs, per the discussion that apparently happened at=20 >IETF75, we=20 >>>>>> would like to ask for this to be considered as a working group=20 >>>>>> document. >>>>>> >>>>>> Please note... I made a mistake in the submission=20 >process and also=20 >>>>>> submitted this as: >>>>>> >>>>>> >>>>>>=20 >http://www.ietf.org/id/draft-matuszewski-p2psip-security-requireme >>>>>> nts-06.txt >>>>>> >>>>>> They are IDENTICAL except for the name change. >>>>>> >>>>>> Thank you for your consideration, >>>>>> Dan >>>>>> >>>>>> -- >>>>>> Dan York, Director of Conversations Voxeo Corporation =A0=20 >>>>>> http://www.voxeo.com =A0dyork@voxeo.com >>>>>> Phone: +1-407-455-5859 =A0 =A0Skype: danyork >>>>>> >>>>>> Join the Voxeo conversation: >>>>>> Blogs: http://blogs.voxeo.com >>>>>> Twitter: http://twitter.com/voxeo =A0http://twitter.com/danyork >>>>>> Facebook: http://www.facebook.com/voxeo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> P2PSIP mailing list >>>>>> P2PSIP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>>> >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>> -- >>> Dan York, Director of Conversations >>> Voxeo Corporation =A0 http://www.voxeo.com =A0dyork@voxeo.com >>> Phone: +1-407-455-5859 =A0 =A0Skype: danyork >>> >>> Join the Voxeo conversation: >>> Blogs: http://blogs.voxeo.com >>> Twitter: http://twitter.com/voxeo =A0http://twitter.com/danyork >>> Facebook: http://www.facebook.com/voxeo >>> >>> >>> >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip > From drage@alcatel-lucent.com Fri Oct 9 04:32:55 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56733A6A5A for ; Fri, 9 Oct 2009 04:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.18 X-Spam-Level: X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[AWL=-1.531, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mt5tCux8tIrq for ; Fri, 9 Oct 2009 04:32:54 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 49BBE3A6A53 for ; Fri, 9 Oct 2009 04:32:53 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n99BYRro024214 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Oct 2009 13:34:28 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 9 Oct 2009 13:34:27 +0200 From: "DRAGE, Keith (Keith)" To: Roni Even , "'Eric Rescorla'" , "'David A. Bryan'" Date: Fri, 9 Oct 2009 13:31:03 +0200 Thread-Topic: [P2PSIP] Consensus call on security draft Thread-Index: AcpHjWOSXhgivGmlQ8CXlayuFzHZlAAsgSwgACT68WA= Message-ID: References: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> <4AC3CEF4.3000508@telecomitalia.it> <7066DEA9-A931-4DE6-B3B9-10E443E1939D@voxeo.com> <8b2769930910070916l39dcb637kf9ffb10f9dabbaf8@mail.gmail.com> <8b2769930910070930y2503ea6bpb299d1c0c7f38629@mail.gmail.com> <20091007203913.3DF9E5DD808@kilo.networkresonance.com> <005b01ca4840$2ae5a3c0$80b0eb40$%roni@huawei.com> In-Reply-To: <005b01ca4840$2ae5a3c0$80b0eb40$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 11:32:56 -0000 My view is that using RFC 2119 words in a document even in lower case is ba= d practice. It takes a slip of the editing pen for them later to become upp= ercase. They also raise questions on review as to whether they should have been upp= er case, at which point people promptly forget all previous decisions on th= e matter and make them upper case. Moreover, evaluating such current usage will undoubtedly make the document = become clearer. Just changing upper case to lower case will not result in a= clear informational document. So I would support Eric in asking for a version of this document that does = not include any of the RFC 2119 language words, unless of course there is a= greement that normative material should later be included. (There are some = exceptions to this, e.g. quotation from another RFC). It appears to me that= nobody is diputing that the current consensus is that the document should = be tutorial. regards Keith > -----Original Message----- > From: p2psip-bounces@ietf.org=20 > [mailto:p2psip-bounces@ietf.org] On Behalf Of Roni Even > Sent: Thursday, October 08, 2009 6:53 PM > To: 'Eric Rescorla'; 'David A. Bryan' > Cc: 'P2PSIP WG' > Subject: Re: [P2PSIP] Consensus call on security draft >=20 > Hi Eric, > About RFC 2119 language. > My understanding is that since there is no reference to RFC=20 > 2119 which says that=20 >=20 > "In many standards track documents several words are used to signify > the requirements in the specification. These words are often > capitalized. This document defines these words as they should be > interpreted in IETF documents. Authors who follow these guidelines > should incorporate this phrase near the beginning of their=20 > document: >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as=20 > described in > RFC 2119. >=20 > Note that the force of these words is modified by the requirement > level of the document in which they are used." >=20 >=20 > My understanding is that there is no normative text in the=20 > document. The meaning of "must" and "should" when not=20 > specified by RFC 2119 does not make them normative. > Furthermore the document will be an Informational document=20 >=20 > Roni Even >=20 > > -----Original Message----- > > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On=20 > > Behalf Of Eric Rescorla > > Sent: Wednesday, October 07, 2009 10:39 PM > > To: David A. Bryan > > Cc: P2PSIP WG > > Subject: Re: [P2PSIP] Consensus call on security draft > >=20 > > At Wed, 7 Oct 2009 12:30:40 -0400, > > David A. Bryan wrote: > > > > > > Eric, > > > > > > I don't agree this is premature in any way. > > > > > > We've allowed over a week on this topic. > >=20 > > Well, David, since you insist: your mail asking for a=20 > consensus call=20 > > was sent at 12:25 EST on the 30th and stated: > >=20 > > As the authors feel they have made the requested=20 > changes, I'd like=20 > > to > > ask folks on list to confirm this consensus. Please=20 > send comments > > about adoption to the list, and we'll make a call after=20 > there has=20 > > been > > time to review and comment (at least a week). > >=20 > > This mail declaring consensus was posted at 12:16 EST today, so the=20 > > amount of time you have allowed, rather than being "at least a week" > > is actually just under a week, so even by the most generous=20 > > interpretation of the situation, this is slightly premature. Given=20 > > that you did not provide any real deadline, it is quite premature. > >=20 > >=20 > > > You never posted saying you > > > were reviewing, you have made no comments on list about the draft=20 > > > since Stockholm. Bruce started a thread on the previous=20 > version way=20 > > > back on July 25th, and you didn't comment. > >=20 > > Because I had already made comments on the previous version=20 > during the=20 > > meeting. > >=20 > >=20 > > > Are there others besides yourself (and Cullen)? If so,=20 > speak up now. > > > Otherwise, we had consensus in the room and allowed a reasonable=20 > > > time for comments on list. > >=20 > > While I agree, we had consensus in the room, this document=20 > does not in=20 > > fact live up to that consensus. I've just listened to the relevant=20 > > section of the WG meeting and it was quite clear that what the WG=20 > > hummed for was as a general tutorial/overview of security=20 > in the P2P=20 > > space. However, it was extremely clear that this document was to be=20 > > non-normative, as stated by Roni, Brian, and myself.=20 > Moreover, this is=20 > > confirmed by Dan's message when this document was posted: > >=20 > > At IETF 75, we were given the direction to remove the RFC 2119=20 > > language from > > the document and move it from being a normative doc to a purely > > informational doc. I have now started this and made a number of=20 > > other > > changes, including most notably the name change from > > "p2psip-security-requirements" to "p2psip-security-overview": > >=20 > > While the 2119 language was removed, which is a start (and=20 > I realize I=20 > > focused on this over Jabber, but limited bandwidth is a cost of not=20 > > being in the room), the document is full of normative text,=20 > albeit not=20 > > rendered in upper case. I count 23 separate instances of the word=20 > > "must" and "30" of the word "should". For example: > >=20 > > S 5.1. > > protected against attacks(such as Man-in-the-Middle). =20 > In order to > > establish the identity trust association, nodes must authenticate > > each other with e.g. TLS and DTLS. If transport=20 > service security=20 > > is > > provided, we can prevent nodes without valid identities to > > participate in the overlay. This layer must provides=20 > reliable and > > secure hop-by-hop transport service for the P2P overlay. This=20 > > alone, > > though, is not enough to secure the P2P system. > >=20 > > S 8.1. > > The user wants available and reliable service that enables him to > > interact with other users and resources in a secure way.=20 > This means > > that the P2PSIP system must provide: > >=20 > > Worse yet, some of these actually contradict design decisions that=20 > > have already been made in RELOAD: > >=20 > > S 8.2.11. > > The security of P2PSIP systems must guarantee privacy of=20 > the P2PSIP > > network participants. The P2PSIP security should allow=20 > the users=20 > > and > > P2PSIP network entities to indicate which other users or P2PSIP > > network entities can retrieve, modify, and delete data stored in > > their P2PSIP resource (user) records. The owner of a P2PSIP=20 > > resource > > (user) record should be able to limit the access to his=20 > own resource > > (user) records, and this feature should be enforced by the P2P > > network. > >=20 > > This is a particularly egregious case since there is no known=20 > > mechanism for securely providing read-level access in a P2P storage=20 > > network, which is why RELOAD assumes that data=20 > confidentiality will be=20 > > solved by encryption rather than access control. > >=20 > > This material is not even remotely tutorial in nature. Quite the=20 > > contrary, it is requirements text, regardless of the fact that it's=20 > > not capitalized. In order for this document to conform to the=20 > > consensus in Stockholm, then, all this language needs to be=20 > removed.=20 > > If the authors/WG feel it is important, it might be replaced with=20 > > descriptions of the security consequences of various design=20 > choices.=20 > > However, as it stands, no I don't agree that this document=20 > either is=20 > > acceptable or that it has consensus: the consensus in Stockholm was=20 > > contingent on changes that have not been made, and the overwhelming=20 > > silence on the mailing list after this revision is not at=20 > all the same=20 > > as consensus. > >=20 > > -Ekr > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > >=20 > > __________ Information from ESET NOD32 Antivirus, version of virus=20 > > signature database 4488 (20091007) __________ > >=20 > > The message was checked by ESET NOD32 Antivirus. > >=20 > > http://www.eset.com > >=20 > >=20 > >=20 > >=20 > > __________ Information from ESET NOD32 Antivirus, version of virus=20 > > signature database 4488 (20091007) __________ > >=20 > > The message was checked by ESET NOD32 Antivirus. > >=20 > > http://www.eset.com > >=20 > >=20 > > __________ Information from ESET NOD32 Antivirus, version of virus=20 > > signature database 4491 (20091008) __________ > >=20 > > The message was checked by ESET NOD32 Antivirus. > >=20 > > http://www.eset.com > >=20 > =20 >=20 > __________ Information from ESET NOD32 Antivirus, version of=20 > virus signature database 4491 (20091008) __________ >=20 > The message was checked by ESET NOD32 Antivirus. >=20 > http://www.eset.com > =20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > = From ekr@rtfm.com Fri Oct 9 06:59:19 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2441428C15B for ; Fri, 9 Oct 2009 06:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.582 X-Spam-Level: X-Spam-Status: No, score=-0.582 tagged_above=-999 required=5 tests=[AWL=-1.019, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDr7PQ5qmuAI for ; Fri, 9 Oct 2009 06:59:18 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 3EAAE28C184 for ; Fri, 9 Oct 2009 06:58:48 -0700 (PDT) Received: by yxe30 with SMTP id 30so9638070yxe.29 for ; Fri, 09 Oct 2009 07:00:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.226.13 with SMTP id y13mr1432023agg.107.1255096830023; Fri, 09 Oct 2009 07:00:30 -0700 (PDT) In-Reply-To: <041301ca4888$3fd13db0$1d0ca40a@china.huawei.com> References: <041301ca4888$3fd13db0$1d0ca40a@china.huawei.com> Date: Fri, 9 Oct 2009 07:00:29 -0700 Message-ID: From: Eric Rescorla To: Song Haibin Content-Type: text/plain; charset=ISO-8859-1 Cc: P2PSIP WG Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 13:59:19 -0000 On Thu, Oct 8, 2009 at 7:28 PM, Song Haibin wrote: > Hi Eric, > > The only comment raised by you during the meeting and in the mailing list is > about the RFC 2119 language. This is not correct. If you go listen to the meeting, I complained that this document seemed extremely generic and disconnected to RELOAD. Seeing as we already *have* an architecture and a proposed protocol with a whole bunch of its own security analysis and characteristics, I don't understand what the purpose of this document is. You can see this in the jabber log: 15:05:44] mic: I'm sort of concerned by how generic this is. [15:05:45] Show of hands for readers: a few [15:05:51] 3 peopel had read it [15:06:28] IT seems almost totally detached from RELOAD as it currently is. [15:07:57] Oh, wait. I figured it out. You use recvmsg, and then iterate the cmsghdrs until you find the one with a cmsg_type of IP_TTL [15:08:09] waiting by mic, ekr [15:08:09] So it looks like there's no problem doing the TTL trick on either end [15:09:16] okay heading back [15:09:20] mic: I think Cullen has sort of hit my concern. This seems like a security analysis of some hypothetical unspecified protocol that sort of is vaguely connected to P2PSIP. But we're way beyond that point. We've got a specific architecture and protocol and so it's odd to have a security analysis that's unconnected to that. > Roni has replied and gave the authors' > explanation in the mailing list. We have not received any further comments > after your planned review. As I noted in my previous message, the whole tone of this document remains inappropriate. If you think you're going to do a purely informative document that's a tutorial on P2P/P2PSIP securing in general (which is what the WG hummed for), then while I personally don't see the value in it, I have no objection. However, this document is full of normative/requirements-type language, of which the use of words like must and should (even in lower case) is merely the most obvious manifestation. If you're writing a tutorial document, then it shouldn't be telling people what to do, period. My previous comment identified a number of these passages but what the document needs is a complete scrub of all such material. -Ekr From Even.roni@huawei.com Fri Oct 9 13:38:18 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9179C3A67D4 for ; Fri, 9 Oct 2009 13:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.191 X-Spam-Level: X-Spam-Status: No, score=-0.191 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, SARE_RECV_SPEEDY_AR=0.808] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcooAS7j9wfT for ; Fri, 9 Oct 2009 13:38:17 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C2A5C3A6890 for ; Fri, 9 Oct 2009 13:38:16 -0700 (PDT) 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 <0KR900H1NLEOWH@szxga04-in.huawei.com> for p2psip@ietf.org; Sat, 10 Oct 2009 04:40:00 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KR90059CLEOP0@szxga04-in.huawei.com> for p2psip@ietf.org; Sat, 10 Oct 2009 04:40:00 +0800 (CST) Received: from YOUR6108 (190-49-10-86.speedy.com.ar [190.49.10.86]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KR900LI7LEFOU@szxml02-in.huawei.com>; Sat, 10 Oct 2009 04:40:00 +0800 (CST) Date: Fri, 09 Oct 2009 22:40:03 +0200 From: Roni Even In-reply-to: To: "'DRAGE, Keith (Keith)'" , 'Eric Rescorla' , "'David A. Bryan'" Message-id: <004a01ca4920$b2e58d90$18b0a8b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: he Content-transfer-encoding: 7BIT Thread-index: AcpHjWOSXhgivGmlQ8CXlayuFzHZlAAsgSwgACT68WAAEx3fwA== References: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> <4AC3CEF4.3000508@telecomitalia.it> <7066DEA9-A931-4DE6-B3B9-10E443E1939D@voxeo.com> <8b2769930910070916l39dcb637kf9ffb10f9dabbaf8@mail.gmail.com> <8b2769930910070930y2503ea6bpb299d1c0c7f38629@mail.gmail.com> <20091007203913.3DF9E5DD808@kilo.networkresonance.com> <005b01ca4840$2ae5a3c0$80b0eb40$%roni@huawei.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 20:38:18 -0000 Hi Keith, My question was about what does it mean to have words like "must", "should" when you do not reference RFC 2119. My take is that RFC 2119 defines the normative terminology and if it does not say that the document refers to RFC 2119 terminology than it does not. In this case there is no normative terms in a document. I was also confused about the text in RFC 2119 and do not understand how is the force of the words changes based on the requirement level of the document . This is why I claim that by my understanding of RFC 2119, if you do not reference it than there is no normative text in the document does not matter if it lower or upper case. Also having the document as informational weakens any strength of text in a document Regards Roni Even > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: Friday, October 09, 2009 1:31 PM > To: Roni Even; 'Eric Rescorla'; 'David A. Bryan' > Cc: 'P2PSIP WG' > Subject: Re: [P2PSIP] Consensus call on security draft > > My view is that using RFC 2119 words in a document even in lower case > is bad practice. It takes a slip of the editing pen for them later to > become uppercase. > > They also raise questions on review as to whether they should have been > upper case, at which point people promptly forget all previous > decisions on the matter and make them upper case. > > Moreover, evaluating such current usage will undoubtedly make the > document become clearer. Just changing upper case to lower case will > not result in a clear informational document. > > So I would support Eric in asking for a version of this document that > does not include any of the RFC 2119 language words, unless of course > there is agreement that normative material should later be included. > (There are some exceptions to this, e.g. quotation from another RFC). > It appears to me that nobody is diputing that the current consensus is > that the document should be tutorial. > > regards > > Keith > > > -----Original Message----- > > From: p2psip-bounces@ietf.org > > [mailto:p2psip-bounces@ietf.org] On Behalf Of Roni Even > > Sent: Thursday, October 08, 2009 6:53 PM > > To: 'Eric Rescorla'; 'David A. Bryan' > > Cc: 'P2PSIP WG' > > Subject: Re: [P2PSIP] Consensus call on security draft > > > > Hi Eric, > > About RFC 2119 language. > > My understanding is that since there is no reference to RFC > > 2119 which says that > > > > "In many standards track documents several words are used to signify > > the requirements in the specification. These words are often > > capitalized. This document defines these words as they should be > > interpreted in IETF documents. Authors who follow these > guidelines > > should incorporate this phrase near the beginning of their > > document: > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > > "OPTIONAL" in this document are to be interpreted as > > described in > > RFC 2119. > > > > Note that the force of these words is modified by the requirement > > level of the document in which they are used." > > > > > > My understanding is that there is no normative text in the > > document. The meaning of "must" and "should" when not > > specified by RFC 2119 does not make them normative. > > Furthermore the document will be an Informational document > > > > Roni Even > > > > > -----Original Message----- > > > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > > > Behalf Of Eric Rescorla > > > Sent: Wednesday, October 07, 2009 10:39 PM > > > To: David A. Bryan > > > Cc: P2PSIP WG > > > Subject: Re: [P2PSIP] Consensus call on security draft > > > > > > At Wed, 7 Oct 2009 12:30:40 -0400, > > > David A. Bryan wrote: > > > > > > > > Eric, > > > > > > > > I don't agree this is premature in any way. > > > > > > > > We've allowed over a week on this topic. > > > > > > Well, David, since you insist: your mail asking for a > > consensus call > > > was sent at 12:25 EST on the 30th and stated: > > > > > > As the authors feel they have made the requested > > changes, I'd like > > > to > > > ask folks on list to confirm this consensus. Please > > send comments > > > about adoption to the list, and we'll make a call after > > there has > > > been > > > time to review and comment (at least a week). > > > > > > This mail declaring consensus was posted at 12:16 EST today, so the > > > amount of time you have allowed, rather than being "at least a > week" > > > is actually just under a week, so even by the most generous > > > interpretation of the situation, this is slightly premature. Given > > > that you did not provide any real deadline, it is quite premature. > > > > > > > > > > You never posted saying you > > > > were reviewing, you have made no comments on list about the draft > > > > since Stockholm. Bruce started a thread on the previous > > version way > > > > back on July 25th, and you didn't comment. > > > > > > Because I had already made comments on the previous version > > during the > > > meeting. > > > > > > > > > > Are there others besides yourself (and Cullen)? If so, > > speak up now. > > > > Otherwise, we had consensus in the room and allowed a reasonable > > > > time for comments on list. > > > > > > While I agree, we had consensus in the room, this document > > does not in > > > fact live up to that consensus. I've just listened to the relevant > > > section of the WG meeting and it was quite clear that what the WG > > > hummed for was as a general tutorial/overview of security > > in the P2P > > > space. However, it was extremely clear that this document was to be > > > non-normative, as stated by Roni, Brian, and myself. > > Moreover, this is > > > confirmed by Dan's message when this document was posted: > > > > > > At IETF 75, we were given the direction to remove the RFC 2119 > > > language from > > > the document and move it from being a normative doc to a purely > > > informational doc. I have now started this and made a number of > > > other > > > changes, including most notably the name change from > > > "p2psip-security-requirements" to "p2psip-security-overview": > > > > > > While the 2119 language was removed, which is a start (and > > I realize I > > > focused on this over Jabber, but limited bandwidth is a cost of not > > > being in the room), the document is full of normative text, > > albeit not > > > rendered in upper case. I count 23 separate instances of the word > > > "must" and "30" of the word "should". For example: > > > > > > S 5.1. > > > protected against attacks(such as Man-in-the-Middle). > > In order to > > > establish the identity trust association, nodes must > authenticate > > > each other with e.g. TLS and DTLS. If transport > > service security > > > is > > > provided, we can prevent nodes without valid identities to > > > participate in the overlay. This layer must provides > > reliable and > > > secure hop-by-hop transport service for the P2P overlay. This > > > alone, > > > though, is not enough to secure the P2P system. > > > > > > S 8.1. > > > The user wants available and reliable service that enables him > to > > > interact with other users and resources in a secure way. > > This means > > > that the P2PSIP system must provide: > > > > > > Worse yet, some of these actually contradict design decisions that > > > have already been made in RELOAD: > > > > > > S 8.2.11. > > > The security of P2PSIP systems must guarantee privacy of > > the P2PSIP > > > network participants. The P2PSIP security should allow > > the users > > > and > > > P2PSIP network entities to indicate which other users or P2PSIP > > > network entities can retrieve, modify, and delete data stored in > > > their P2PSIP resource (user) records. The owner of a P2PSIP > > > resource > > > (user) record should be able to limit the access to his > > own resource > > > (user) records, and this feature should be enforced by the P2P > > > network. > > > > > > This is a particularly egregious case since there is no known > > > mechanism for securely providing read-level access in a P2P storage > > > network, which is why RELOAD assumes that data > > confidentiality will be > > > solved by encryption rather than access control. > > > > > > This material is not even remotely tutorial in nature. Quite the > > > contrary, it is requirements text, regardless of the fact that it's > > > not capitalized. In order for this document to conform to the > > > consensus in Stockholm, then, all this language needs to be > > removed. > > > If the authors/WG feel it is important, it might be replaced with > > > descriptions of the security consequences of various design > > choices. > > > However, as it stands, no I don't agree that this document > > either is > > > acceptable or that it has consensus: the consensus in Stockholm was > > > contingent on changes that have not been made, and the overwhelming > > > silence on the mailing list after this revision is not at > > all the same > > > as consensus. > > > > > > -Ekr > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www.ietf.org/mailman/listinfo/p2psip > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > > > signature database 4488 (20091007) __________ > > > > > > The message was checked by ESET NOD32 Antivirus. > > > > > > http://www.eset.com > > > > > > > > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > > > signature database 4488 (20091007) __________ > > > > > > The message was checked by ESET NOD32 Antivirus. > > > > > > http://www.eset.com > > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > > > signature database 4491 (20091008) __________ > > > > > > The message was checked by ESET NOD32 Antivirus. > > > > > > http://www.eset.com > > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of > > virus signature database 4491 (20091008) __________ > > > > The message was checked by ESET NOD32 Antivirus. > > > > http://www.eset.com > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4494 (20091009) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4494 (20091009) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4494 (20091009) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From drage@alcatel-lucent.com Fri Oct 9 16:49:44 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E9F3A694A for ; Fri, 9 Oct 2009 16:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.091 X-Spam-Level: X-Spam-Status: No, score=-5.091 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ne+U8DlBS-lP for ; Fri, 9 Oct 2009 16:49:43 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 7E2C43A691A for ; Fri, 9 Oct 2009 16:49:42 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n99NpKva005828 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 10 Oct 2009 01:51:20 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sat, 10 Oct 2009 01:51:21 +0200 From: "DRAGE, Keith (Keith)" To: Roni Even , "'Eric Rescorla'" , "'David A. Bryan'" Date: Sat, 10 Oct 2009 01:51:14 +0200 Thread-Topic: [P2PSIP] Consensus call on security draft Thread-Index: AcpHjWOSXhgivGmlQ8CXlayuFzHZlAAsgSwgACT68WAAEx3fwAAGuEsw Message-ID: References: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> <4AC3CEF4.3000508@telecomitalia.it> <7066DEA9-A931-4DE6-B3B9-10E443E1939D@voxeo.com> <8b2769930910070916l39dcb637kf9ffb10f9dabbaf8@mail.gmail.com> <8b2769930910070930y2503ea6bpb299d1c0c7f38629@mail.gmail.com> <20091007203913.3DF9E5DD808@kilo.networkresonance.com> <005b01ca4840$2ae5a3c0$80b0eb40$%roni@huawei.com> <004a01ca4920$b2e58d90$18b0a8b0$%roni@huawei.com> In-Reply-To: <004a01ca4920$b2e58d90$18b0a8b0$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 23:49:44 -0000 If I take the first two "must" usages in the document: "Thus, the architecture must consider this issue in the process of both enrollment and modification of P2PSIP resource (user) records in a P2PSIP overlay." "Nevertheless those attacks must be addressed by designers of service specific protocols such as SIP [RFC3261]." Are either of these statements even relevant to a document of tutorial, i.e= . educational nature, that the working group defined this to be. So essentially I am saying, irrespective of whether a reference to RFC 2119= carries a normative nature or not, just changing the "MUST" to a "must" do= es not achieve the purpose you are trying to write this document for. The document, according to the scope defined by the working group, should b= e concentrating on the security issues, rather than writing statements abou= t how the security should be addressed. regards Keith > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com]=20 > Sent: Friday, October 09, 2009 9:40 PM > To: DRAGE, Keith (Keith); 'Eric Rescorla'; 'David A. Bryan' > Cc: 'P2PSIP WG' > Subject: RE: [P2PSIP] Consensus call on security draft >=20 > Hi Keith, > My question was about what does it mean to have words like=20 > "must", "should" > when you do not reference RFC 2119.=20 > My take is that RFC 2119 defines the normative terminology=20 > and if it does not say that the document refers to RFC 2119=20 > terminology than it does not. > In this case there is no normative terms in a document. > I was also confused about the text in RFC 2119 and do not=20 > understand how is the force of the words changes based on the=20 > requirement level of the document . > This is why I claim that by my understanding of RFC 2119, if=20 > you do not reference it than there is no normative text in=20 > the document does not matter if it lower or upper case. Also=20 > having the document as informational weakens any strength of=20 > text in a document Regards Roni Even >=20 > > -----Original Message----- > > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On=20 > > Behalf Of DRAGE, Keith (Keith) > > Sent: Friday, October 09, 2009 1:31 PM > > To: Roni Even; 'Eric Rescorla'; 'David A. Bryan' > > Cc: 'P2PSIP WG' > > Subject: Re: [P2PSIP] Consensus call on security draft > >=20 > > My view is that using RFC 2119 words in a document even in=20 > lower case=20 > > is bad practice. It takes a slip of the editing pen for=20 > them later to=20 > > become uppercase. > >=20 > > They also raise questions on review as to whether they should have=20 > > been upper case, at which point people promptly forget all previous=20 > > decisions on the matter and make them upper case. > >=20 > > Moreover, evaluating such current usage will undoubtedly make the=20 > > document become clearer. Just changing upper case to lower=20 > case will=20 > > not result in a clear informational document. > >=20 > > So I would support Eric in asking for a version of this=20 > document that=20 > > does not include any of the RFC 2119 language words, unless=20 > of course=20 > > there is agreement that normative material should later be included. > > (There are some exceptions to this, e.g. quotation from=20 > another RFC). > > It appears to me that nobody is diputing that the current=20 > consensus is=20 > > that the document should be tutorial. > >=20 > > regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: p2psip-bounces@ietf.org > > > [mailto:p2psip-bounces@ietf.org] On Behalf Of Roni Even > > > Sent: Thursday, October 08, 2009 6:53 PM > > > To: 'Eric Rescorla'; 'David A. Bryan' > > > Cc: 'P2PSIP WG' > > > Subject: Re: [P2PSIP] Consensus call on security draft > > > > > > Hi Eric, > > > About RFC 2119 language. > > > My understanding is that since there is no reference to RFC > > > 2119 which says that > > > > > > "In many standards track documents several words are used=20 > to signify > > > the requirements in the specification. These words are often > > > capitalized. This document defines these words as=20 > they should be > > > interpreted in IETF documents. Authors who follow these > > guidelines > > > should incorporate this phrase near the beginning of their > > > document: > > > > > > The key words "MUST", "MUST NOT", "REQUIRED",=20 > "SHALL", "SHALL > > > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > > > "OPTIONAL" in this document are to be interpreted=20 > as described=20 > > > in > > > RFC 2119. > > > > > > Note that the force of these words is modified by the=20 > requirement > > > level of the document in which they are used." > > > > > > > > > My understanding is that there is no normative text in=20 > the document.=20 > > > The meaning of "must" and "should" when not specified by RFC 2119=20 > > > does not make them normative. > > > Furthermore the document will be an Informational document > > > > > > Roni Even > > > > > > > -----Original Message----- > > > > From: p2psip-bounces@ietf.org=20 > [mailto:p2psip-bounces@ietf.org] On=20 > > > > Behalf Of Eric Rescorla > > > > Sent: Wednesday, October 07, 2009 10:39 PM > > > > To: David A. Bryan > > > > Cc: P2PSIP WG > > > > Subject: Re: [P2PSIP] Consensus call on security draft > > > > > > > > At Wed, 7 Oct 2009 12:30:40 -0400, David A. Bryan wrote: > > > > > > > > > > Eric, > > > > > > > > > > I don't agree this is premature in any way. > > > > > > > > > > We've allowed over a week on this topic. > > > > > > > > Well, David, since you insist: your mail asking for a > > > consensus call > > > > was sent at 12:25 EST on the 30th and stated: > > > > > > > > As the authors feel they have made the requested > > > changes, I'd like > > > > to > > > > ask folks on list to confirm this consensus. Please > > > send comments > > > > about adoption to the list, and we'll make a call after > > > there has > > > > been > > > > time to review and comment (at least a week). > > > > > > > > This mail declaring consensus was posted at 12:16 EST today, so=20 > > > > the amount of time you have allowed, rather than being=20 > "at least a > > week" > > > > is actually just under a week, so even by the most generous=20 > > > > interpretation of the situation, this is slightly=20 > premature. Given=20 > > > > that you did not provide any real deadline, it is quite=20 > premature. > > > > > > > > > > > > > You never posted saying you > > > > > were reviewing, you have made no comments on list about the=20 > > > > > draft since Stockholm. Bruce started a thread on the previous > > > version way > > > > > back on July 25th, and you didn't comment. > > > > > > > > Because I had already made comments on the previous version > > > during the > > > > meeting. > > > > > > > > > > > > > Are there others besides yourself (and Cullen)? If so, > > > speak up now. > > > > > Otherwise, we had consensus in the room and allowed a=20 > reasonable=20 > > > > > time for comments on list. > > > > > > > > While I agree, we had consensus in the room, this document > > > does not in > > > > fact live up to that consensus. I've just listened to=20 > the relevant=20 > > > > section of the WG meeting and it was quite clear that=20 > what the WG=20 > > > > hummed for was as a general tutorial/overview of security > > > in the P2P > > > > space. However, it was extremely clear that this=20 > document was to=20 > > > > be non-normative, as stated by Roni, Brian, and myself. > > > Moreover, this is > > > > confirmed by Dan's message when this document was posted: > > > > > > > > At IETF 75, we were given the direction to remove the=20 > RFC 2119=20 > > > > language from > > > > the document and move it from being a normative doc=20 > to a purely > > > > informational doc. I have now started this and made=20 > a number of=20 > > > > other > > > > changes, including most notably the name change from > > > > "p2psip-security-requirements" to "p2psip-security-overview": > > > > > > > > While the 2119 language was removed, which is a start (and > > > I realize I > > > > focused on this over Jabber, but limited bandwidth is a cost of=20 > > > > not being in the room), the document is full of normative text, > > > albeit not > > > > rendered in upper case. I count 23 separate instances=20 > of the word=20 > > > > "must" and "30" of the word "should". For example: > > > > > > > > S 5.1. > > > > protected against attacks(such as Man-in-the-Middle). > > > In order to > > > > establish the identity trust association, nodes must > > authenticate > > > > each other with e.g. TLS and DTLS. If transport > > > service security > > > > is > > > > provided, we can prevent nodes without valid identities to > > > > participate in the overlay. This layer must provides > > > reliable and > > > > secure hop-by-hop transport service for the P2P=20 > overlay. This=20 > > > > alone, > > > > though, is not enough to secure the P2P system. > > > > > > > > S 8.1. > > > > The user wants available and reliable service that=20 > enables him > > to > > > > interact with other users and resources in a secure way. > > > This means > > > > that the P2PSIP system must provide: > > > > > > > > Worse yet, some of these actually contradict design=20 > decisions that=20 > > > > have already been made in RELOAD: > > > > > > > > S 8.2.11. > > > > The security of P2PSIP systems must guarantee privacy of > > > the P2PSIP > > > > network participants. The P2PSIP security should allow > > > the users > > > > and > > > > P2PSIP network entities to indicate which other=20 > users or P2PSIP > > > > network entities can retrieve, modify, and delete=20 > data stored in > > > > their P2PSIP resource (user) records. The owner of a P2PSIP=20 > > > > resource > > > > (user) record should be able to limit the access to his > > > own resource > > > > (user) records, and this feature should be enforced=20 > by the P2P > > > > network. > > > > > > > > This is a particularly egregious case since there is no known=20 > > > > mechanism for securely providing read-level access in a P2P=20 > > > > storage network, which is why RELOAD assumes that data > > > confidentiality will be > > > > solved by encryption rather than access control. > > > > > > > > This material is not even remotely tutorial in nature.=20 > Quite the=20 > > > > contrary, it is requirements text, regardless of the fact that=20 > > > > it's not capitalized. In order for this document to conform to=20 > > > > the consensus in Stockholm, then, all this language needs to be > > > removed. > > > > If the authors/WG feel it is important, it might be=20 > replaced with=20 > > > > descriptions of the security consequences of various design > > > choices. > > > > However, as it stands, no I don't agree that this document > > > either is > > > > acceptable or that it has consensus: the consensus in Stockholm=20 > > > > was contingent on changes that have not been made, and the=20 > > > > overwhelming silence on the mailing list after this revision is=20 > > > > not at > > > all the same > > > > as consensus. > > > > > > > > -Ekr > > > > _______________________________________________ > > > > P2PSIP mailing list > > > > P2PSIP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/p2psip > > > > > > > > __________ Information from ESET NOD32 Antivirus,=20 > version of virus=20 > > > > signature database 4488 (20091007) __________ > > > > > > > > The message was checked by ESET NOD32 Antivirus. > > > > > > > > http://www.eset.com > > > > > > > > > > > > > > > > > > > > __________ Information from ESET NOD32 Antivirus,=20 > version of virus=20 > > > > signature database 4488 (20091007) __________ > > > > > > > > The message was checked by ESET NOD32 Antivirus. > > > > > > > > http://www.eset.com > > > > > > > > > > > > __________ Information from ESET NOD32 Antivirus,=20 > version of virus=20 > > > > signature database 4491 (20091008) __________ > > > > > > > > The message was checked by ESET NOD32 Antivirus. > > > > > > > > http://www.eset.com > > > > > > > > > > > > > __________ Information from ESET NOD32 Antivirus, version=20 > of virus=20 > > > signature database 4491 (20091008) __________ > > > > > > The message was checked by ESET NOD32 Antivirus. > > > > > > http://www.eset.com > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www.ietf.org/mailman/listinfo/p2psip > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > >=20 > > __________ Information from ESET NOD32 Antivirus, version of virus=20 > > signature database 4494 (20091009) __________ > >=20 > > The message was checked by ESET NOD32 Antivirus. > >=20 > > http://www.eset.com > >=20 > >=20 > >=20 > >=20 > > __________ Information from ESET NOD32 Antivirus, version of virus=20 > > signature database 4494 (20091009) __________ > >=20 > > The message was checked by ESET NOD32 Antivirus. > >=20 > > http://www.eset.com > >=20 > =20 >=20 > __________ Information from ESET NOD32 Antivirus, version of=20 > virus signature database 4494 (20091009) __________ >=20 > The message was checked by ESET NOD32 Antivirus. >=20 > http://www.eset.com > =20 >=20 > = From lin.xiao@nsn.com Sat Oct 10 01:18:56 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03523A6890 for ; Sat, 10 Oct 2009 01:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoJ6nAvM3Vpx for ; Sat, 10 Oct 2009 01:18:56 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 471F93A681E for ; Sat, 10 Oct 2009 01:18:49 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9A8KUsq009894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 10 Oct 2009 10:20:30 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9A8KT4p004154; Sat, 10 Oct 2009 10:20:29 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Oct 2009 10:20:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 10 Oct 2009 16:20:06 +0800 Message-ID: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4CD17BB@CNBEEXC007.nsn-intra.net> In-Reply-To: <8FDC180D-74F4-4875-A4A1-64D1034667C9@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New versions of RELOAD and sip draft Thread-Index: AcpGrc+EKrcTz/SUQhyvSsFmDVhEJgCybzlA From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext Cullen Jennings" , "P2PSIP WG" X-OriginalArrivalTime: 10 Oct 2009 08:20:29.0530 (UTC) FILETIME=[872363A0:01CA4982] Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 08:18:57 -0000 Hi Cullen, I've had a quick review of these two drafts, and still not quite clear with some Client related issues.=20 I know Client is not the first-class concept in RELOAD, but as it has been involved in the RELOAD protocol, RELOAD should give full support to client anyhow, right?=20 In the terminology chapter of RELOAD Base draft, the connection table is defined as: =20 "The set of peers to which a node is directly connected. This includes nodes with which Attach handshakes have been done but which have not sent any Updates." although, the second sentence implies that clients are also involved in, I still suggest to replace the "peers" in the first sentence with "nodes" to make it more clear that both peers and clients can be maintained in the table.=20 In my opinions, connection setup and maintenance between client and its connected peer (responsible peer or arbitrary peer) is a key issue for client support in RELOAD. My question is: Does a peer in RELOAD distinguish if the connection is to a peer or to a client? Because the reaction of the peer could be different when the connection is lost. =20 As a client could set up a connection only with an arbitrary peer. Does this peer distinguish such connection from those it is responsible to? Should this peer inform the client's responsible peer about the Destination List to the client? So that it can still be accessed by other nodes. Or should the Destination List been stored with some usage, say SIP Usage? If so, the SIP usage must be extended to allow a Destination list containing more than one Node IDs. In current SIP usage draft, the SipRegistration structure only allow one address being stored in the Destination List, as: " Destination destination_list<0..2^16-1>;" It should be replaced by: "Destination destination_list [dest_list_length];" =20 to enable a longer list stored by arbitrary connected clients. Anyway, IMHO, RELOAD should make sure to cover all situations a client could meet or at least clearly distinguish issues of clients, especially for arbitrary connected ones, which are left to be solved by other drafts. Thanks. Best Regards, Xiao, Lin =20 -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of ext Cullen Jennings Sent: Wednesday, October 07, 2009 1:53 AM To: P2PSIP WG Subject: [P2PSIP] New versions of RELOAD and sip draft I just submitted draft-ietf-p2psip-base-04 and draft-ietf-p2psip-sip-02 These contain technical changes but do not have a lot of editorial changes. At some point we need to go and reorganize the documents with editorial changes. Cullen _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From melodysong@huawei.com Sat Oct 10 02:18:40 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8082528C133 for ; Sat, 10 Oct 2009 02:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rs8WiIGDpm9I for ; Sat, 10 Oct 2009 02:18:39 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B78CF28C0E4 for ; Sat, 10 Oct 2009 02:18:39 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRA00E9RKLR7E@szxga03-in.huawei.com> for p2psip@ietf.org; Sat, 10 Oct 2009 17:20:15 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRA006QFKLR7I@szxga03-in.huawei.com> for p2psip@ietf.org; Sat, 10 Oct 2009 17:20:15 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRA003CWKLRAZ@szxml06-in.huawei.com> for p2psip@ietf.org; Sat, 10 Oct 2009 17:20:15 +0800 (CST) Date: Sat, 10 Oct 2009 17:20:16 +0800 From: Song Haibin To: 'P2PSIP WG' Message-id: <006e01ca498a$e173af10$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_lNxcThKUFuVrs14x3e7LPg)" Thread-index: AcpJin3lY/Vb8ozdR6Wjj6kLjjkN4QAAC4Zg Subject: [P2PSIP] FW: I-D Action:draft-matuszewski-p2psip-security-overview-01.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 09:18:40 -0000 This is a multi-part message in MIME format. --Boundary_(ID_lNxcThKUFuVrs14x3e7LPg) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT >-----Original Message----- >From: i-d-announce-bounces@ietf.org >[mailto:i-d-announce-bounces@ietf.org] On Behalf Of >Internet-Drafts@ietf.org >Sent: Saturday, October 10, 2009 5:15 PM >To: i-d-announce@ietf.org >Subject: I-D Action:draft-matuszewski-p2psip-security-overview-01.txt > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. > ... > >This document provides a security overview and analysis for >the Peer- to-Peer Session Initiation Protocol (P2PSIP) overlay >network. It discusses security threats for the P2PSIP >architecture and its components. It compares security >difference between client/server >(C/S) and P2P implementations of SIP, and then partitions the >P2PSIP architecture into layers and analyzes the security >issues in each layer and the security relationship among the layers. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-security-overv iew-01.txt > --Boundary_(ID_lNxcThKUFuVrs14x3e7LPg) Content-type: Message/External-body; name=draft-matuszewski-p2psip-security-overview-01.txt Content-transfer-encoding: 7bit Content-disposition: attachment; filename=draft-matuszewski-p2psip-security-overview-01.txt Content-Type: text/plain Content-ID: <2009-10-10020741.I-D@ietf.org> --Boundary_(ID_lNxcThKUFuVrs14x3e7LPg) Content-type: text/plain; name=ATT00108.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT00108.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Boundary_(ID_lNxcThKUFuVrs14x3e7LPg)-- From melodysong@huawei.com Sat Oct 10 02:24:55 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8CC28C108 for ; Sat, 10 Oct 2009 02:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.205 X-Spam-Level: X-Spam-Status: No, score=0.205 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_74=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 322bqBmuBbz7 for ; Sat, 10 Oct 2009 02:24:54 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id D250528C0E8 for ; Sat, 10 Oct 2009 02:24:53 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRA00A9HKW5IU@szxga02-in.huawei.com> for p2psip@ietf.org; Sat, 10 Oct 2009 17:26:30 +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 <0KRA003Z5KW55E@szxga02-in.huawei.com> for p2psip@ietf.org; Sat, 10 Oct 2009 17:26:29 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRA000RBKW5RH@szxml04-in.huawei.com> for p2psip@ietf.org; Sat, 10 Oct 2009 17:26:29 +0800 (CST) Date: Sat, 10 Oct 2009 17:26:30 +0800 From: Song Haibin In-reply-to: To: "'DRAGE, Keith (Keith)'" , 'Roni Even' , 'Eric Rescorla' , "'David A. Bryan'" Message-id: <007801ca498b$c0599aa0$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcpHjWOSXhgivGmlQ8CXlayuFzHZlAAsgSwgACT68WAAEx3fwAAGuEswABQPLdA= Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 09:24:55 -0000 Hi, Just updated the document a bit with removing RFC 2119 requirement languages (no reference to RFC 2119 in this document). The link for the new version is as below: http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-security-overvi ew-01.txt Thanks! Haibin >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] >On Behalf Of DRAGE, Keith (Keith) >Sent: Saturday, October 10, 2009 7:51 AM >To: Roni Even; 'Eric Rescorla'; 'David A. Bryan' >Cc: 'P2PSIP WG' >Subject: Re: [P2PSIP] Consensus call on security draft > >If I take the first two "must" usages in the document: > >"Thus, the architecture must consider this > issue in the process of both enrollment and modification of P2PSIP > resource (user) records in a P2PSIP overlay." > >"Nevertheless those > attacks must be addressed by designers of service specific protocols > such as SIP [RFC3261]." > >Are either of these statements even relevant to a document of >tutorial, i.e. educational nature, that the working group >defined this to be. > >So essentially I am saying, irrespective of whether a >reference to RFC 2119 carries a normative nature or not, just >changing the "MUST" to a "must" does not achieve the purpose >you are trying to write this document for. > >The document, according to the scope defined by the working >group, should be concentrating on the security issues, rather >than writing statements about how the security should be addressed. > >regards > >Keith > >> -----Original Message----- >> From: Roni Even [mailto:Even.roni@huawei.com] >> Sent: Friday, October 09, 2009 9:40 PM >> To: DRAGE, Keith (Keith); 'Eric Rescorla'; 'David A. Bryan' >> Cc: 'P2PSIP WG' >> Subject: RE: [P2PSIP] Consensus call on security draft >> >> Hi Keith, >> My question was about what does it mean to have words like "must", >> "should" >> when you do not reference RFC 2119. >> My take is that RFC 2119 defines the normative terminology and if it >> does not say that the document refers to RFC 2119 >terminology than it >> does not. >> In this case there is no normative terms in a document. >> I was also confused about the text in RFC 2119 and do not understand >> how is the force of the words changes based on the requirement level >> of the document . >> This is why I claim that by my understanding of RFC 2119, if you do >> not reference it than there is no normative text in the >document does >> not matter if it lower or upper case. Also having the document as >> informational weakens any strength of text in a document >Regards Roni >> Even >> >> > -----Original Message----- >> > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >> > Behalf Of DRAGE, Keith (Keith) >> > Sent: Friday, October 09, 2009 1:31 PM >> > To: Roni Even; 'Eric Rescorla'; 'David A. Bryan' >> > Cc: 'P2PSIP WG' >> > Subject: Re: [P2PSIP] Consensus call on security draft >> > >> > My view is that using RFC 2119 words in a document even in >> lower case >> > is bad practice. It takes a slip of the editing pen for >> them later to >> > become uppercase. >> > >> > They also raise questions on review as to whether they should have >> > been upper case, at which point people promptly forget all >previous >> > decisions on the matter and make them upper case. >> > >> > Moreover, evaluating such current usage will undoubtedly make the >> > document become clearer. Just changing upper case to lower >> case will >> > not result in a clear informational document. >> > >> > So I would support Eric in asking for a version of this >> document that >> > does not include any of the RFC 2119 language words, unless >> of course >> > there is agreement that normative material should later be >included. >> > (There are some exceptions to this, e.g. quotation from >> another RFC). >> > It appears to me that nobody is diputing that the current >> consensus is >> > that the document should be tutorial. >> > >> > regards >> > >> > Keith >> > >> > > -----Original Message----- >> > > From: p2psip-bounces@ietf.org >> > > [mailto:p2psip-bounces@ietf.org] On Behalf Of Roni Even >> > > Sent: Thursday, October 08, 2009 6:53 PM >> > > To: 'Eric Rescorla'; 'David A. Bryan' >> > > Cc: 'P2PSIP WG' >> > > Subject: Re: [P2PSIP] Consensus call on security draft >> > > >> > > Hi Eric, >> > > About RFC 2119 language. >> > > My understanding is that since there is no reference to RFC >> > > 2119 which says that >> > > >> > > "In many standards track documents several words are used >> to signify >> > > the requirements in the specification. These words are often >> > > capitalized. This document defines these words as >> they should be >> > > interpreted in IETF documents. Authors who follow these >> > guidelines >> > > should incorporate this phrase near the beginning of their >> > > document: >> > > >> > > The key words "MUST", "MUST NOT", "REQUIRED", >> "SHALL", "SHALL >> > > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >> > > "OPTIONAL" in this document are to be interpreted >> as described >> > > in >> > > RFC 2119. >> > > >> > > Note that the force of these words is modified by the >> requirement >> > > level of the document in which they are used." >> > > >> > > >> > > My understanding is that there is no normative text in >> the document. >> > > The meaning of "must" and "should" when not specified by >RFC 2119 >> > > does not make them normative. >> > > Furthermore the document will be an Informational document >> > > >> > > Roni Even >> > > >> > > > -----Original Message----- >> > > > From: p2psip-bounces@ietf.org >> [mailto:p2psip-bounces@ietf.org] On >> > > > Behalf Of Eric Rescorla >> > > > Sent: Wednesday, October 07, 2009 10:39 PM >> > > > To: David A. Bryan >> > > > Cc: P2PSIP WG >> > > > Subject: Re: [P2PSIP] Consensus call on security draft >> > > > >> > > > At Wed, 7 Oct 2009 12:30:40 -0400, David A. Bryan wrote: >> > > > > >> > > > > Eric, >> > > > > >> > > > > I don't agree this is premature in any way. >> > > > > >> > > > > We've allowed over a week on this topic. >> > > > >> > > > Well, David, since you insist: your mail asking for a >> > > consensus call >> > > > was sent at 12:25 EST on the 30th and stated: >> > > > >> > > > As the authors feel they have made the requested >> > > changes, I'd like >> > > > to >> > > > ask folks on list to confirm this consensus. Please >> > > send comments >> > > > about adoption to the list, and we'll make a call after >> > > there has >> > > > been >> > > > time to review and comment (at least a week). >> > > > >> > > > This mail declaring consensus was posted at 12:16 EST >today, so >> > > > the amount of time you have allowed, rather than being >> "at least a >> > week" >> > > > is actually just under a week, so even by the most generous >> > > > interpretation of the situation, this is slightly >> premature. Given >> > > > that you did not provide any real deadline, it is quite >> premature. >> > > > >> > > > >> > > > > You never posted saying you >> > > > > were reviewing, you have made no comments on list about the >> > > > > draft since Stockholm. Bruce started a thread on the previous >> > > version way >> > > > > back on July 25th, and you didn't comment. >> > > > >> > > > Because I had already made comments on the previous version >> > > during the >> > > > meeting. >> > > > >> > > > >> > > > > Are there others besides yourself (and Cullen)? If so, >> > > speak up now. >> > > > > Otherwise, we had consensus in the room and allowed a >> reasonable >> > > > > time for comments on list. >> > > > >> > > > While I agree, we had consensus in the room, this document >> > > does not in >> > > > fact live up to that consensus. I've just listened to >> the relevant >> > > > section of the WG meeting and it was quite clear that >> what the WG >> > > > hummed for was as a general tutorial/overview of security >> > > in the P2P >> > > > space. However, it was extremely clear that this >> document was to >> > > > be non-normative, as stated by Roni, Brian, and myself. >> > > Moreover, this is >> > > > confirmed by Dan's message when this document was posted: >> > > > >> > > > At IETF 75, we were given the direction to remove the >> RFC 2119 >> > > > language from >> > > > the document and move it from being a normative doc >> to a purely >> > > > informational doc. I have now started this and made >> a number of >> > > > other >> > > > changes, including most notably the name change from >> > > > "p2psip-security-requirements" to "p2psip-security-overview": >> > > > >> > > > While the 2119 language was removed, which is a start (and >> > > I realize I >> > > > focused on this over Jabber, but limited bandwidth is >a cost of >> > > > not being in the room), the document is full of normative text, >> > > albeit not >> > > > rendered in upper case. I count 23 separate instances >> of the word >> > > > "must" and "30" of the word "should". For example: >> > > > >> > > > S 5.1. >> > > > protected against attacks(such as Man-in-the-Middle). >> > > In order to >> > > > establish the identity trust association, nodes must >> > authenticate >> > > > each other with e.g. TLS and DTLS. If transport >> > > service security >> > > > is >> > > > provided, we can prevent nodes without valid identities to >> > > > participate in the overlay. This layer must provides >> > > reliable and >> > > > secure hop-by-hop transport service for the P2P >> overlay. This >> > > > alone, >> > > > though, is not enough to secure the P2P system. >> > > > >> > > > S 8.1. >> > > > The user wants available and reliable service that >> enables him >> > to >> > > > interact with other users and resources in a secure way. >> > > This means >> > > > that the P2PSIP system must provide: >> > > > >> > > > Worse yet, some of these actually contradict design >> decisions that >> > > > have already been made in RELOAD: >> > > > >> > > > S 8.2.11. >> > > > The security of P2PSIP systems must guarantee privacy of >> > > the P2PSIP >> > > > network participants. The P2PSIP security should allow >> > > the users >> > > > and >> > > > P2PSIP network entities to indicate which other >> users or P2PSIP >> > > > network entities can retrieve, modify, and delete >> data stored in >> > > > their P2PSIP resource (user) records. The owner of >a P2PSIP >> > > > resource >> > > > (user) record should be able to limit the access to his >> > > own resource >> > > > (user) records, and this feature should be enforced >> by the P2P >> > > > network. >> > > > >> > > > This is a particularly egregious case since there is no known >> > > > mechanism for securely providing read-level access in a P2P >> > > > storage network, which is why RELOAD assumes that data >> > > confidentiality will be >> > > > solved by encryption rather than access control. >> > > > >> > > > This material is not even remotely tutorial in nature. >> Quite the >> > > > contrary, it is requirements text, regardless of the fact that >> > > > it's not capitalized. In order for this document to >conform to >> > > > the consensus in Stockholm, then, all this language needs to be >> > > removed. >> > > > If the authors/WG feel it is important, it might be >> replaced with >> > > > descriptions of the security consequences of various design >> > > choices. >> > > > However, as it stands, no I don't agree that this document >> > > either is >> > > > acceptable or that it has consensus: the consensus in >Stockholm >> > > > was contingent on changes that have not been made, and the >> > > > overwhelming silence on the mailing list after this >revision is >> > > > not at >> > > all the same >> > > > as consensus. >> > > > >> > > > -Ekr >> > > > _______________________________________________ >> > > > P2PSIP mailing list >> > > > P2PSIP@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/p2psip >> > > > >> > > > __________ Information from ESET NOD32 Antivirus, >> version of virus >> > > > signature database 4488 (20091007) __________ >> > > > >> > > > The message was checked by ESET NOD32 Antivirus. >> > > > >> > > > http://www.eset.com >> > > > >> > > > >> > > > >> > > > >> > > > __________ Information from ESET NOD32 Antivirus, >> version of virus >> > > > signature database 4488 (20091007) __________ >> > > > >> > > > The message was checked by ESET NOD32 Antivirus. >> > > > >> > > > http://www.eset.com >> > > > >> > > > >> > > > __________ Information from ESET NOD32 Antivirus, >> version of virus >> > > > signature database 4491 (20091008) __________ >> > > > >> > > > The message was checked by ESET NOD32 Antivirus. >> > > > >> > > > http://www.eset.com >> > > > >> > > >> > > >> > > __________ Information from ESET NOD32 Antivirus, version >> of virus >> > > signature database 4491 (20091008) __________ >> > > >> > > The message was checked by ESET NOD32 Antivirus. >> > > >> > > http://www.eset.com >> > > >> > > >> > > _______________________________________________ >> > > P2PSIP mailing list >> > > P2PSIP@ietf.org >> > > https://www.ietf.org/mailman/listinfo/p2psip >> > > >> > _______________________________________________ >> > P2PSIP mailing list >> > P2PSIP@ietf.org >> > https://www.ietf.org/mailman/listinfo/p2psip >> > >> > __________ Information from ESET NOD32 Antivirus, version of virus >> > signature database 4494 (20091009) __________ >> > >> > The message was checked by ESET NOD32 Antivirus. >> > >> > http://www.eset.com >> > >> > >> > >> > >> > __________ Information from ESET NOD32 Antivirus, version of virus >> > signature database 4494 (20091009) __________ >> > >> > The message was checked by ESET NOD32 Antivirus. >> > >> > http://www.eset.com >> > >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> signature database 4494 (20091009) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip > From julian@orchidseed.org Sat Oct 10 12:03:25 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B62C3A6805 for ; Sat, 10 Oct 2009 12:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CO+YHlpz0zPQ for ; Sat, 10 Oct 2009 12:03:24 -0700 (PDT) Received: from n19.c05.mtsvc.net (n19.c05.mtsvc.net [70.32.68.19]) by core3.amsl.com (Postfix) with ESMTP id 503D63A6778 for ; Sat, 10 Oct 2009 12:03:23 -0700 (PDT) Received: from adsl-176-184-222.asm.bellsouth.net ([74.176.184.222]:57376 helo=[192.168.1.3]) by n19.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MwhFc-0004tU-ID; Sat, 10 Oct 2009 12:05:10 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-1--131121301 From: jc In-Reply-To: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4CD17BB@CNBEEXC007.nsn-intra.net> Date: Sat, 10 Oct 2009 15:04:29 -0400 Message-Id: <19487C07-153A-4478-853D-864BA38A5303@orchidseed.org> References: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4CD17BB@CNBEEXC007.nsn-intra.net> To: "Xiao, Lin (NSN - CN/Beijing)" X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 19:03:25 -0000 --Apple-Mail-1--131121301 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Xiao, If a node has is not a part of the ring it is a peer otherwise it is a client. For simplicity I keep state of each node internally but this brings no external value. These can be determined outright by checking your connection table against your routing table as well without enumerations but brings complexity to this simple query. /** * Current node klass. May be client or peer, will default to none for pre-bootstrap setup. */ enum { node_klass_none = 0, node_klass_client = 1, node_klass_peer = 2, }; There is no possible way to determine via the base protocol if a node is a client or a peer except by the fact that it may or may not be in the ring. I handle this internally and don't feel that sending this over the wire would bring benefit. What you describe here would require changes to the protocol header and would be defining a first class concept for nodes. Julian Cain On Oct 10, 2009, at 4:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote: > Hi Cullen, > > I've had a quick review of these two drafts, and still not quite clear > with some Client related issues. > > I know Client is not the first-class concept in RELOAD, but as it has > been involved in the RELOAD protocol, RELOAD should give full > support to > client anyhow, right? > > In the terminology chapter of RELOAD Base draft, the connection > table is > defined as: > "The set of peers to which a node is directly connected. This > includes nodes with which Attach handshakes have been done but which > have not sent any Updates." > although, the second sentence implies that clients are also involved > in, > I still suggest to replace the "peers" in the first sentence with > "nodes" to make it more clear that both peers and clients can be > maintained in the table. > > In my opinions, connection setup and maintenance between client and > its > connected peer (responsible peer or arbitrary peer) is a key issue for > client support in RELOAD. My question is: Does a peer in RELOAD > distinguish if the connection is to a peer or to a client? Because the > reaction of the peer could be different when the connection is lost. > > As a client could set up a connection only with an arbitrary peer. > Does > this peer distinguish such connection from those it is responsible to? > Should this peer inform the client's responsible peer about the > Destination List to the client? So that it can still be accessed by > other nodes. Or should the Destination List been stored with some > usage, > say SIP Usage? If so, the SIP usage must be extended to allow a > Destination list containing more than one Node IDs. In current SIP > usage draft, the SipRegistration structure only allow one address > being > stored in the Destination List, as: > " Destination destination_list<0..2^16-1>;" > It should be replaced by: "Destination destination_list > [dest_list_length];" > to enable a longer list stored by arbitrary connected clients. > > Anyway, IMHO, RELOAD should make sure to cover all situations a client > could meet or at least clearly distinguish issues of clients, > especially > for arbitrary connected ones, which are left to be solved by other > drafts. Thanks. > > > Best Regards, > Xiao, Lin > > > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf > Of ext Cullen Jennings > Sent: Wednesday, October 07, 2009 1:53 AM > To: P2PSIP WG > Subject: [P2PSIP] New versions of RELOAD and sip draft > > > I just submitted > draft-ietf-p2psip-base-04 > and > draft-ietf-p2psip-sip-02 > > These contain technical changes but do not have a lot of editorial > changes. At some point we need to go and reorganize the documents with > editorial changes. > > Cullen > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail-1--131121301 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

There is no = possible way to determine via the base protocol if a node is a client or = a peer except by the fact that it may or may not be in the ring. I = handle this internally and don't feel that sending this over the wire = would bring benefit. 

What you = describe here would require changes to the protocol header and would be = defining a first class concept for = nodes.

Julian = Cain

On Oct 10, 2009, at 4:20 AM, Xiao, Lin (NSN = - CN/Beijing) wrote:

Hi = Cullen,

I've had a quick review of these two drafts, and still = not quite clear
with some Client related issues.

I know = Client is not the first-class concept in RELOAD, but as it has
been = involved in the RELOAD protocol, RELOAD should give full support = to
client anyhow, right?

In the terminology chapter of RELOAD = Base draft, the connection table is
defined as:  
=     "The set of peers to which a node is directly = connected.  This
includes nodes with which Attach handshakes = have  been done but which
have not sent any = Updates."
although, the second sentence implies that clients are also = involved in,
I still suggest to replace the "peers" in the first = sentence with
"nodes" to make it more clear that both peers and = clients can be
maintained in the = table. 

In my = opinions, connection setup and maintenance between client and = its
connected peer (responsible peer or arbitrary peer) is a key = issue for
client support in RELOAD.  My question is: Does a peer = in RELOAD
distinguish if the connection is to a peer or to a client? = Because the
reaction of the peer could be different when the = connection is lost.  

As a client could set up a connection = only with an arbitrary peer. Does
this peer distinguish such = connection from those it is responsible to?
Should this peer inform = the client's responsible peer about the
Destination List to the = client? So that it can still be accessed by
other nodes. Or should = the Destination List been stored with some usage,
say SIP Usage? If = so, the SIP usage must be extended to allow a
Destination list = containing more than one Node IDs.  In current SIP
usage draft, = the SipRegistration structure only allow one address being
stored in = the Destination List, as:
 " Destination =          destination_list<= 0..2^16-1>;"
It should be replaced by: "Destination =          destination_list
= [dest_list_length];"  
to enable a longer list stored by = arbitrary connected clients.

Anyway, IMHO, RELOAD should make = sure to cover all situations a client
could meet or at least clearly = distinguish issues of clients, especially
for arbitrary connected = ones, which are left to be solved by other
drafts. = Thanks.


Best Regards,
Xiao, Lin


-----Original = Message-----
From: p2psip-bounces@ietf.org = [mailto:p2psip-bounces@ietf.org] On Behalf
Of ext Cullen = Jennings
Sent: Wednesday, October 07, 2009 1:53 AM
To: P2PSIP = WG
Subject: [P2PSIP] New versions of RELOAD and sip = draft


I just = submitted
draft-ietf-p2psip-base-04
and
draft-ietf-p2psip-sip-02<= br>
These contain technical changes but do not have a lot of = editorial
changes. At some point we need to go and reorganize the = documents with
editorial changes.

Cullen <in my individual = contributor = role>

_______________________________________________
P2PSIP = mailing list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip
_____________________________________________= __
P2PSIP mailing = list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip

= --Apple-Mail-1--131121301-- From michaelc@idssoftware.com Mon Oct 12 15:42:34 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96CB93A689B for ; Mon, 12 Oct 2009 15:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.814 X-Spam-Level: * X-Spam-Status: No, score=1.814 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lsniN+B2WCD for ; Mon, 12 Oct 2009 15:42:33 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 83CBD3A6837 for ; Mon, 12 Oct 2009 15:42:33 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MxTb2-0004EO-Uh; Mon, 12 Oct 2009 18:42:29 -0400 Message-ID: <4AD3B234.4050306@idssoftware.com> Date: Mon, 12 Oct 2009 15:48:20 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Cullen Jennings References: <8FDC180D-74F4-4875-A4A1-64D1034667C9@cisco.com> In-Reply-To: <8FDC180D-74F4-4875-A4A1-64D1034667C9@cisco.com> Content-Type: multipart/alternative; boundary="------------050500070806000406040705" X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940eca78f24d63ba1bbe1297f6fc4c61e64350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Cc: P2PSIP WG Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 22:42:34 -0000 This is a multi-part message in MIME format. --------------050500070806000406040705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cullen, I posted several issues regarding the -03 draft late July but received no reply. I don't see changes related to these issues in the new -04 draft. I want to make sure they are not overlooked: http://www.ietf.org/mail-archive/web/p2psip/current/msg05019.html 1) Section 5.5.1.1, the definition IceCandidate.rel_addr_port does not conform with section 15.1 of the current mmusic-ice-19 draft, which has the following text: " and : convey transport addresses related to the candidate, useful for diagnostics and other purposes. and MUST be present for server reflexive, peer reflexive and relayed candidates." Therefore, the definition of IceCandidate should be: struct { ... select (type){ case host: ; /* Nothing */ case srflx: case prflx: case relay: IpAddressPort rel_addr_port; } ... } IceCandidate; rel_addr_port corresponds to the related address and port of ICE, which MUST present for type "srflx", "prflx" and "relay". 2) In Section 13.6, IANA message codes for AppAttachReq and AppAttachReq are not added. I suggest fill these two values (app_attach_req=5, app_attach_ans=6) in the holes left by the abandoned tunnel_req and tunnel_ans. 3) In Section 6.4.1.2, if the store request has multiple kinds, the current answer structure will send replica node IDs multiple times. For efficiency, I suggest moving the replica node IDs to the outer layer as: struct { KindId kind; uint64 generation_counter; } StoreKindResponse; struct { StoreKindResponse kind_responses<0..216-1>; NodeId replicas<0..216-1>; } StoreAns; 4) It seems that mmusic-ice-tcp-07 has been abandoned. The key members of this draft should address the lack of ice-tcp standard in the next draft, meeting or on the mailing list. That is it so far. Thanks --Michael Cullen Jennings wrote: > > I just submitted > draft-ietf-p2psip-base-04 > and > draft-ietf-p2psip-sip-02 > > These contain technical changes but do not have a lot of editorial > changes. At some point we need to go and reorganize the documents with > editorial changes. > > Cullen > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > --------------050500070806000406040705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cullen,

I posted several issues regarding the -03 draft late July but received no reply. I don't see changes related to these issues in the new -04 draft. I want to make sure they are not overlooked:

 http://www.ietf.org/mail-archive/web/p2psip/current/msg05019.html

1) Section 5.5.1.1, the definition IceCandidate.rel_addr_port does not conform with section 15.1 of the current mmusic-ice-19 draft, which has the following text:

"<rel-addr> and <rel-port>:  convey transport addresses related to the
     candidate, useful for diagnostics and other purposes. <rel-addr>
     and <rel-port> MUST be present for server reflexive, peer
     reflexive and relayed candidates."

Therefore, the definition of IceCandidate should be:

        struct {
          ...
          select (type){
            case host:
              ;          /* Nothing */
            case srflx:
            case prflx:
            case relay:
              IpAddressPort     rel_addr_port;
          }
          ...
        } IceCandidate;

  rel_addr_port
     corresponds to the related address and port of ICE, which MUST
     present for type "srflx", "prflx" and "relay".

2) In Section 13.6, IANA message codes for AppAttachReq and AppAttachReq are not added. I suggest fill these two values (app_attach_req=5, app_attach_ans=6) in the holes left by the abandoned tunnel_req and tunnel_ans.

3) In Section 6.4.1.2, if the store request has multiple kinds, the current answer structure will send replica node IDs multiple times. For efficiency, I suggest moving the replica node IDs to the outer layer as:

        struct {
          KindId                  kind;
          uint64                  generation_counter;
        } StoreKindResponse;

        struct {
          StoreKindResponse       kind_responses<0..216-1>;
          NodeId                  replicas<0..216-1>;
        } StoreAns;

4) It seems that mmusic-ice-tcp-07 has been abandoned. The key members of this draft should address the lack of ice-tcp standard in the next draft, meeting or on the mailing list.

That is it so far. Thanks

--Michael

Cullen Jennings wrote:

I just submitted
draft-ietf-p2psip-base-04
and
draft-ietf-p2psip-sip-02

These contain technical changes but do not have a lot of editorial changes. At some point we need to go and reorganize the documents with editorial changes.

Cullen <in my individual contributor role>

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


--------------050500070806000406040705-- From julian@orchidseed.org Mon Oct 12 16:17:47 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57DAC28C1B0 for ; Mon, 12 Oct 2009 16:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKMwZrhRBcHM for ; Mon, 12 Oct 2009 16:17:46 -0700 (PDT) Received: from n19.c05.mtsvc.net (n19.c05.mtsvc.net [70.32.68.19]) by core3.amsl.com (Postfix) with ESMTP id 790F828C2CE for ; Mon, 12 Oct 2009 16:17:46 -0700 (PDT) Received: from adsl-176-184-222.asm.bellsouth.net ([74.176.184.222]:50494 helo=[192.168.1.3]) by n19.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MxU9C-0002bi-Ac; Mon, 12 Oct 2009 16:17:46 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: <4AD3B234.4050306@idssoftware.com> Date: Mon, 12 Oct 2009 19:17:11 -0400 Content-Transfer-Encoding: 7bit Message-Id: <11899405-D934-46E9-AFAB-D0DDD2EA1E7E@orchidseed.org> References: <8FDC180D-74F4-4875-A4A1-64D1034667C9@cisco.com> <4AD3B234.4050306@idssoftware.com> To: Michael Chen X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 23:17:47 -0000 Michael, 1: I was actually working in that area ATM. There is an exclusion "Only present for type "relay"", however I'm not certain as to why that is. I agree it MUST be as you've stated . 2: There also must be a codes for app_attachlite_req = 29 and app_attachlite_ans = 30. 3: No comment. 4: Seeing that ICE is required for RELOAD as is TLS over TCP I cannot think of any other protocol off the top of my head that is more dependent on that draft than this one. Julian On Oct 12, 2009, at 6:48 PM, Michael Chen wrote: > Cullen, > > I posted several issues regarding the -03 draft late July but > received no reply. I don't see changes related to these issues in > the new -04 draft. I want to make sure they are not overlooked: > > http://www.ietf.org/mail-archive/web/p2psip/current/msg05019.html > > 1) Section 5.5.1.1, the definition IceCandidate.rel_addr_port does > not conform with section 15.1 of the current mmusic-ice-19 draft, > which has the following text: > > " and : convey transport addresses related to the > candidate, useful for diagnostics and other purposes. > and MUST be present for server reflexive, peer > reflexive and relayed candidates." > > Therefore, the definition of IceCandidate should be: > > struct { > ... > select (type){ > case host: > ; /* Nothing */ > case srflx: > case prflx: > case relay: > IpAddressPort rel_addr_port; > } > ... > } IceCandidate; > > rel_addr_port > corresponds to the related address and port of ICE, which MUST > present for type "srflx", "prflx" and "relay". > > 2) In Section 13.6, IANA message codes for AppAttachReq and > AppAttachReq are not added. I suggest fill these two values > (app_attach_req=5, app_attach_ans=6) in the holes left by the > abandoned tunnel_req and tunnel_ans. > > 3) In Section 6.4.1.2, if the store request has multiple kinds, the > current answer structure will send replica node IDs multiple times. > For efficiency, I suggest moving the replica node IDs to the outer > layer as: > > struct { > KindId kind; > uint64 generation_counter; > } StoreKindResponse; > > struct { > StoreKindResponse kind_responses<0..216-1>; > NodeId replicas<0..216-1>; > } StoreAns; > > 4) It seems that mmusic-ice-tcp-07 has been abandoned. The key > members of this draft should address the lack of ice-tcp standard in > the next draft, meeting or on the mailing list. > > That is it so far. Thanks > > --Michael > > Cullen Jennings wrote: >> >> I just submitted >> draft-ietf-p2psip-base-04 >> and >> draft-ietf-p2psip-sip-02 >> >> These contain technical changes but do not have a lot of editorial >> changes. At some point we need to go and reorganize the documents >> with editorial changes. >> >> Cullen >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Thu Oct 15 18:04:18 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A123A696B for ; Thu, 15 Oct 2009 18:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.427 X-Spam-Level: X-Spam-Status: No, score=-106.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnD4++sX+rAx for ; Thu, 15 Oct 2009 18:04:17 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7D95B3A6964 for ; Thu, 15 Oct 2009 18:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1826; q=dns/txt; s=sjiport06001; t=1255655061; x=1256864661; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=20reload=20issues=20update|Date:=20Thu, =2015=20Oct=202009=2019:04:19=20-0600|Message-Id:=20|To:=20jc=20|Cc:=20P2PSIP=20WG=20|Mime-Version:=201.0=20(Apple=20Message=20framework=20v 936)|Content-Transfer-Encoding:=207bit|In-Reply-To:=20 |References:=20=20; bh=Ul+oqp/FsijPBQfyYu0povrf8r9KPxaDxfNMpl7qM8Y=; b=p/4XbJruBnH8268HQS4YV2BbkOoYAvcgy4kOqdrzasMNQNPq9cHi20kL ZyV4QFGEmhj/LBGmx/hFx2Rf6PtrPimPMXtZzVCoVXq3lPIOYVJ8l5Y8U sYjc/U41xTUpdLwhCGi4Lv5yq9ukiMOymAQmbgYBFVOvXxGGpjXvTB/kD c=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOZi10qrR7H+/2dsb2JhbADAcpgqhDAE X-IronPort-AV: E=Sophos;i="4.44,569,1249257600"; d="scan'208";a="410438535" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2009 01:04:21 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9G14KwX008860; Fri, 16 Oct 2009 01:04:20 GMT From: Cullen Jennings To: jc In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 19:04:19 -0600 X-Mailer: Apple Mail (2.936) Cc: P2PSIP WG Subject: Re: [P2PSIP] reload issues update X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 01:04:18 -0000 I see your point. This should be fixed in next rev. On Aug 19, 2009, at 12:09 AM, jc wrote: > Cullen, csv is fine, thx. > > While I am here: > > Section 9 states "at least three" predecessor's and successor's > while section 9.1 states "3". IMHO, section 9.1. needs a bit of > rewording because you may or may not have three peers clockwise or > counterclockwise at any given time. > > So technically in section 9.1 the neighbor table SHOULD contain at > least 3 peers before this peer and at least 3 peers after it in the > DHT ring. > > Are we clearly stating that the neighbor table is indeed at most 6 > node id's with 3 in each direction around the ring? Are we stating > that you should not add to the back or front list if they contain > already three entries? > > 9. Chord Algorithm > The original Chord algorithm specified a single predecessor and a > successor list be stored. chord-reload specifies at least three > of > each. > 9.1. Overview > The neighbor table contains the 3 > peers before this peer and the 3 peers after it in the DHT ring. > Julian Cain > > On Aug 18, 2009, at 8:37 AM, Cullen Jennings wrote: > >> >> I'm still collecting up issues on the reload and sip usage draft >> but the initial list is in a spreadsheet at >> >> http://svn.resiprocate.org/rep/ietf-drafts/p2psip/issues.csv >> >> I realize there are better tools for tracking bugs than a >> spreadsheet in a source code control system but this is something >> everyone can use, works across a wide range of operating systems, >> and allowed multiple people to work offline and make changes. >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > From fluffy@cisco.com Thu Oct 15 18:04:43 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B9A3A684C for ; Thu, 15 Oct 2009 18:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.448 X-Spam-Level: X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IujMzAzSD82 for ; Thu, 15 Oct 2009 18:04:41 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A77193A697A for ; Thu, 15 Oct 2009 18:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=4091; q=dns/txt; s=sjiport01001; t=1255655085; x=1256864685; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=20New=20versions=20of=20RELOAD=20and=20 sip=20draft|Date:=20Thu,=2015=20Oct=202009=2019:04:44=20- 0600|Message-Id:=20<4125E20F-8A5A-40C2-B690-7EBBBBFBFF7B@ cisco.com>|To:=20"Xiao,=20Lin=20(NSN=20-=20CN/Beijing)" =20|Cc:=20"P2PSIP=20WG"=20|Mime-Version:=201.0=20(Apple=20Message=20framework =20v936)|Content-Transfer-Encoding:=207bit|In-Reply-To: =20<5D84FDD8D5DC8646B9F73CF1EFD1BFA4CD17BB@CNBEEXC007.nsn -intra.net>|References:=20<5D84FDD8D5DC8646B9F73CF1EFD1BF A4CD17BB@CNBEEXC007.nsn-intra.net>; bh=AM2oD/ALUUoHrrM5SllL7xycfx2EXOBR/38tuwZ2HrE=; b=w3gG8pk8Z9QAwe703oJbJyDNImbk13hQwkbrQ/0QlVU99WD3xOC3dgPh s126C9QZGHayxSBl3rKN+fQcsi0RO3cQdcOWFtLiKdIrz3O+mWww2RZiS FZAQTuIkWk/2XxjNSektEWtZ19H+PtBKHRD4+9U5S1xpkBGXgbs1gC9ta I=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANZj10qrR7H+/2dsb2JhbADAbpgqhDAE X-IronPort-AV: E=Sophos;i="4.44,569,1249257600"; d="scan'208";a="256833265" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 16 Oct 2009 01:04:45 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9G14KwZ008860; Fri, 16 Oct 2009 01:04:44 GMT From: Cullen Jennings To: "Xiao, Lin (NSN - CN/Beijing)" In-Reply-To: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4CD17BB@CNBEEXC007.nsn-intra.net> Impp: xmpp:cullenfluffyjennings@jabber.org References: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4CD17BB@CNBEEXC007.nsn-intra.net> Message-Id: <4125E20F-8A5A-40C2-B690-7EBBBBFBFF7B@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 19:04:44 -0600 X-Mailer: Apple Mail (2.936) Cc: P2PSIP WG Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 01:04:43 -0000 Thank you, few comments inline.... On Oct 10, 2009, at 2:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote: > Hi Cullen, > > I've had a quick review of these two drafts, and still not quite clear > with some Client related issues. > > I know Client is not the first-class concept in RELOAD, but as it has > been involved in the RELOAD protocol, RELOAD should give full > support to > client anyhow, right? > > In the terminology chapter of RELOAD Base draft, the connection > table is > defined as: > "The set of peers to which a node is directly connected. This > includes nodes with which Attach handshakes have been done but which > have not sent any Updates." > although, the second sentence implies that clients are also involved > in, > I still suggest to replace the "peers" in the first sentence with > "nodes" to make it more clear that both peers and clients can be > maintained in the table. I agree. I changed this - thank you for the careful review to catch things like this. > > In my opinions, connection setup and maintenance between client and > its > connected peer (responsible peer or arbitrary peer) is a key issue for > client support in RELOAD. My question is: Does a peer in RELOAD > distinguish if the connection is to a peer or to a client? Because the > reaction of the peer could be different when the connection is lost. Reload does distinguish at some level but what do you think a node needs to do differently when a connection is lost if the connection when to a peer or client. Clearly how data replication is handled and some of the finger table stuff is handled differently but I think that is covered in the draft. If you see something specific missing, let me know. > > As a client could set up a connection only with an arbitrary peer. > Does > this peer distinguish such connection from those it is responsible to? I don't se the need to. > Should this peer inform the client's responsible peer about the > Destination List to the client? So that it can still be accessed by > other nodes. Or should the Destination List been stored with some > usage, > say SIP Usage? Yes, that is the approach to store destination lists where they are needed. > If so, the SIP usage must be extended to allow a > Destination list containing more than one Node IDs. agree that it needs to allow storing multiple Node IDs but I think it already does that. > In current SIP > usage draft, the SipRegistration structure only allow one address > being > stored in the Destination List, as: > " Destination destination_list<0..2^16-1>;" The destination_list here is an array of Destinations so it allows between 0 and 65K entries in the array. I agree the syntax for specifying arrays might seem a bit weird but I think the structure is what you are pointing out we need to have. > It should be replaced by: "Destination destination_list > [dest_list_length];" > to enable a longer list stored by arbitrary connected clients. > > Anyway, IMHO, RELOAD should make sure to cover all situations a client > could meet or at least clearly distinguish issues of clients, > especially > for arbitrary connected ones, which are left to be solved by other > drafts. Thanks. > > > Best Regards, > Xiao, Lin > > > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf > Of ext Cullen Jennings > Sent: Wednesday, October 07, 2009 1:53 AM > To: P2PSIP WG > Subject: [P2PSIP] New versions of RELOAD and sip draft > > > I just submitted > draft-ietf-p2psip-base-04 > and > draft-ietf-p2psip-sip-02 > > These contain technical changes but do not have a lot of editorial > changes. At some point we need to go and reorganize the documents with > editorial changes. > > Cullen > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Thu Oct 15 18:04:44 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF1C23A697A for ; Thu, 15 Oct 2009 18:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.465 X-Spam-Level: X-Spam-Status: No, score=-106.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqfNmpEzYqxi for ; Thu, 15 Oct 2009 18:04:44 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0090A3A6977 for ; Thu, 15 Oct 2009 18:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=632; q=dns/txt; s=sjiport06001; t=1255655088; x=1256864688; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=20New=20versions=20of=20RELOAD=20and=20 sip=20draft|Date:=20Thu,=2015=20Oct=202009=2019:04:33=20- 0600|Message-Id:=20<4DC6B65F-4448-4E17-B06A-371C8C35F953@ cisco.com>|To:=20jc=20|Cc:=20"Mich ael=20Chen"=20,=20"P2PSIP=20WG" =20|Mime-Version:=201.0=20(Apple=20Messa ge=20framework=20v936)|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<11899405-D934-46E9-AFAB-D0DDD2EA1E7E@orc hidseed.org>|References:=20<8FDC180D-74F4-4875-A4A1-64D10 34667C9@cisco.com>=20<4AD3B234.4050306@idssoftware.com> =20<11899405-D934-46E9-AFAB-D0DDD2EA1E7E@orchidseed.org>; bh=2Sk+cjnUecP9Jqe3Lcrt4gwe/7zUuK2LMJPuwY/TeRU=; b=NFZFRvalq7p2KyOPf3dDOYVjZmbQHKuT9JRRYt+A0w+GuPwOwa/xej5I ka1LidtzADKpc0WeiErYlFHa0JlvWh9IBFL9DLT6lhqOnmlcsU2MGh49D cc8207/iAbmqculleqpDQ8RRFuq/7eqSybuQTt9xl5ud1Rx9T+vFwlwAY g=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABhk10qrR7H+/2dsb2JhbADAbZgqhDAE X-IronPort-AV: E=Sophos;i="4.44,569,1249257600"; d="scan'208";a="410438591" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2009 01:04:35 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9G14KwY008860; Fri, 16 Oct 2009 01:04:34 GMT From: Cullen Jennings To: jc In-Reply-To: <11899405-D934-46E9-AFAB-D0DDD2EA1E7E@orchidseed.org> Impp: xmpp:cullenfluffyjennings@jabber.org References: <8FDC180D-74F4-4875-A4A1-64D1034667C9@cisco.com> <4AD3B234.4050306@idssoftware.com> <11899405-D934-46E9-AFAB-D0DDD2EA1E7E@orchidseed.org> Message-Id: <4DC6B65F-4448-4E17-B06A-371C8C35F953@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 19:04:33 -0600 X-Mailer: Apple Mail (2.936) Cc: P2PSIP WG Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 01:04:44 -0000 agree on all points - fixed in next ver. On Oct 12, 2009, at 5:17 PM, jc wrote: > Michael, > > 1: > > I was actually working in that area ATM. There is an exclusion "Only > present for type "relay"", however I'm not certain as to why that is. > I agree it MUST be as you've stated . > > 2: > > There also must be a codes for app_attachlite_req = 29 and > app_attachlite_ans = 30. > > 3: > > No comment. > > 4: > > Seeing that ICE is required for RELOAD as is TLS over TCP I cannot > think of any other protocol off the top of my head that is more > dependent on that draft than this one. > > Julian From fluffy@cisco.com Thu Oct 15 18:04:52 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40A428C1BC for ; Thu, 15 Oct 2009 18:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.478 X-Spam-Level: X-Spam-Status: No, score=-106.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywb21wwiBGv5 for ; Thu, 15 Oct 2009 18:04:51 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9512228C1BB for ; Thu, 15 Oct 2009 18:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=4635; q=dns/txt; s=sjiport06001; t=1255655095; x=1256864695; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=20I-D=20Action:draft-ietf-p2psip-base-0 3.txt|Date:=20Thu,=2015=20Oct=202009=2019:04:54=20-0600 |Message-Id:=20|To:=20"Craig,=20Dave"=20|Cc: =20"p2psip@ietf.org"=20|Mime-Version:=20 1.0=20(Apple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20|References:=20<20090714000001.D94FA28C458@core3. amsl.com>=20; bh=V4QBk9u/5hkX7dCH67Pz+HqD7id5NwqrsESTMNPsH30=; b=KCEPkqwR8e2ZBF9obDl8urLliDBpPaA+td0P5/gLe0RoaMasP6+95eAJ UhWwD4WIUnEGllgSpWwOJJKbBzCJFlv3rQWri6zkdzYxODv58nQMwebtM wAmNjJ7PTScqxY7v4aoODsLkWkT/gZr4uPm3o4OGiNACQEW2FPTLLU7no M=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABhk10qrR7H+/2dsb2JhbADAbYkRCI8RgkcIgWEE X-IronPort-AV: E=Sophos;i="4.44,569,1249257600"; d="scan'208";a="410438700" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2009 01:04:55 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9G14Kwa008860; Fri, 16 Oct 2009 01:04:54 GMT From: Cullen Jennings To: "Craig, Dave" In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: <20090714000001.D94FA28C458@core3.amsl.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 19:04:54 -0600 X-Mailer: Apple Mail (2.936) Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] I-D Action:draft-ietf-p2psip-base-03.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 01:04:52 -0000 Thanks for the careful read - I fixed up this stuff in next version On Jul 14, 2009, at 6:13 PM, Craig, Dave wrote: > I had a few questions on my interpretation of the latest updates as > well a few typos. > > > 1. I was trying to understand the change made in 3.2.1. Could that > change also be read as follows? > > Note that clients that chose this option MUST process Update > messages from the peer. Those updates can indicate that the peer no > longer owns the Client's Node-ID. The client then forms a > connection to the appropriate peer. > > Done - thanks for text > 2. The change made at the end of 5.4.1. > > All overlay algorithms MUST specify maintenance procedures _that_ > send Updates to all members of the Connection Table... fixed > > > 3. The change made at the beginning on 5.4.2.3 seems to conflict > with that at the end of 5.4.1. If you MUST send Updates to all > members of the connection table, then why is it a SHOULD in 5.4.2.3? fixed - I can't find any explanation of when you would not send the update in 5.4.2.3 so I changed that to a MUST. > > > 4. Should the IceExtension in 5.5.1.1 be a TLV, so stacks not > comprehending the extensions can still Attach? That preserves a > little more of the extensibility in the SDP string encoding. If a node does not understand ICE, it needs to be using AttachLite or else the sending node will think it is doing ICE when it is not and it can become really a mess. The node using ICE may not be in a place where things will work without ICE but it has no way to indicate that if the node that does not understand ICE tries to use the Attach without ICE. > > > 5. In 5.5.2.3, first paragraph, would this read a little easier as, > "... When a connection forms, the node MUST check _that_ the > certificate is for the node that _sent_ AttachLiteReqAns..." > fixed - thanks > > 6. In 5.5.3., first paragraph, "The AppAttach request and its > response contain _an_ application attribute..." > fixed > > 7. In 5.6.2.2., end of paragraph, it looks like a dangling sentence > was not finished being removed. > fixed > > 8. In 5.6.2.2.1. third paragraph, "...looking at the time the ACK > was received and the time when the message was sent." > fixed > > 9. In 5.6.2.2.1. fifth paragraph, was the following intended? "If > all retransmissions for a message fail, _the sending node should > close the connection routing the message_." Should there also be > additional hysteresis to make sure that a failing connection is not > quickly reestablished under a fast chord-reload-ping-frequency? > fixed but did address the hysteresis issue > > 10. In 5.6.3, second paragraph, "take into account space to allow > the via and _destination_ lists to grow." Fixed - > > > 11. In 10.1, your -frequency elements actually specify periods not > occurrences per unit of time. Suggest renaming these to end in "- > period" or "-interval". End users or developers may enter in the > wrong value here if they go by the label name alone. > good point - move to interval > > 12. In 10.1, I found descriptions for the namespace and encoding > requirements for the overlay configuration document. Is it ok to > leave it implicit that these apply to the kind configuration > documents sent in 5.5.6.1? > fixed - nice catch > > 13. In 10.1, "root-cert This element contains PEM encoded X.509v3 > certificates that are a..." > fixed but check what I did as not exactly as you suggested > > 14. In 10.1, Could the following: > > kinds-signature This signature is computed across the prevision > kind from the beginning of the first < of the kind to the end of > the last > of the kind in the same was as the "signature element > described later in this section. > > be reworded as? > > kind-signature This signature is computed across the > kind from the beginning of the first < of the kind to the end of > the last > of the kind in the same way as the "signature element > described later in this section. > fixed > Likewise, kinds-signer in the descriptions appears to be kind-signer > in the example. Suggest updating example with kinds-signer. > fixed > > 15. In 10.5 there's a reference to a broadcast-peers element in the > configuration document that is not defined in 10.1. Is this really > the bootstrap-peer element in 10.1? This was the multicast stuff but I'm suggesting removing this. > From fluffy@cisco.com Thu Oct 15 18:05:02 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8D228C1BF for ; Thu, 15 Oct 2009 18:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.489 X-Spam-Level: X-Spam-Status: No, score=-106.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXDIOObQWt4n for ; Thu, 15 Oct 2009 18:05:01 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9AC1228C1BB for ; Thu, 15 Oct 2009 18:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=433; q=dns/txt; s=sjiport01001; t=1255655105; x=1256864705; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20reload=20configuration=20non-plural=20xml=20elem ents|Date:=20Thu,=2015=20Oct=202009=2019:05:04=20-0600 |Message-Id:=20<53A3A619-C5E7-4FDF-B895-A6F0AD860BD4@cisc o.com>|To:=20jc=20|Cc:=20P2PSIP=20 WG=20|Mime-Version:=201.0=20(Apple=20Mes sage=20framework=20v936)|Content-Transfer-Encoding:=207bi t|In-Reply-To:=20|References:=20; bh=tS1t/skWudclZiQqwSE21e8IOFFBtNcVaIJ+wTSdMxs=; b=0HZkB31PFpOe71uqAGaEs2I2+NNcjblDgc7BsGpUTBDV42w2BRdOQwrY fNOTe7W2i1DB6gSksiUlClCZl07qCCzgc/2F+5aN+IHKGjprFOqV+nhFH /O4SgaSdO2b5SwD/HBGCsa1tI2J4zdmsNlDaJRz6NSgyRnZcx7xogTmf0 k=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANZj10qrR7H+/2dsb2JhbADAbpgqhDAE X-IronPort-AV: E=Sophos;i="4.44,569,1249257600"; d="scan'208";a="256833312" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 16 Oct 2009 01:05:05 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9G14Kwb008860; Fri, 16 Oct 2009 01:05:05 GMT From: Cullen Jennings To: jc In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: Message-Id: <53A3A619-C5E7-4FDF-B895-A6F0AD860BD4@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 19:05:04 -0600 X-Mailer: Apple Mail (2.936) Cc: P2PSIP WG Subject: Re: [P2PSIP] reload configuration non-plural xml elements X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 01:05:02 -0000 Fixed. Again, thanks for careful read. On Aug 22, 2009, at 10:26 PM, jc wrote: > Cullen, > > I didn't catch these until I implemented the configuration parser. > > The descriptions of two of the elements are plural in the draft > while the xml elements themselves are not. > > The two mismatched description element pairs: > > kinds-signature : > kinds-signer : > > Julian From fluffy@cisco.com Thu Oct 15 18:06:22 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A618D3A6964 for ; Thu, 15 Oct 2009 18:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.592 X-Spam-Level: X-Spam-Status: No, score=-105.592 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u4k4Cd9wnW2 for ; Thu, 15 Oct 2009 18:06:21 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8949E3A6805 for ; Thu, 15 Oct 2009 18:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3983; q=dns/txt; s=sjiport02001; t=1255655185; x=1256864785; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=20New=20versions=20of=20RELOAD=20and=20 sip=20draft|Date:=20Thu,=2015=20Oct=202009=2019:06:23=20- 0600|Message-Id:=20<7E5070BB-33EB-4839-9043-8B3C6112B668@ cisco.com>|To:=20Michael=20Chen=20|Cc:=20P2PSIP=20WG=20|Mime-Version: =201.0=20(Apple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4AD3B2 34.4050306@idssoftware.com>|References:=20<8FDC180D-74F4- 4875-A4A1-64D1034667C9@cisco.com>=20<4AD3B234.4050306@ids software.com>; bh=P9mTKHpoL87eWSPfO1Ca/FjB0C+sspuV0Yxve0Np3bs=; b=M8gOoYxvVisNQdkQWfH0YbsuqF6nNej/iV78SwqLZMtGwPZJgr5wdSyh ChTDCqUq+aBxyXkF21pN1X7waHfSrvrdUgzP8Pn+KVjMThjgzYPi7wGim BIuAEk2g3kAwhrpkch2Ii3YlC8L/XAGPyQlAsn4KVTP75cNnpWPhnviaT o=; Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEANZj10qrR7H+/2dsb2JhbACQCrBkmCqEMASBWw X-IronPort-AV: E=Sophos;i="4.44,569,1249257600"; d="scan'208";a="215080912" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 16 Oct 2009 01:06:25 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9G16NXe010034; Fri, 16 Oct 2009 01:06:24 GMT From: Cullen Jennings To: Michael Chen In-Reply-To: <4AD3B234.4050306@idssoftware.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <8FDC180D-74F4-4875-A4A1-64D1034667C9@cisco.com> <4AD3B234.4050306@idssoftware.com> Message-Id: <7E5070BB-33EB-4839-9043-8B3C6112B668@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 19:06:23 -0600 X-Mailer: Apple Mail (2.936) Cc: P2PSIP WG Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 01:06:22 -0000 On Oct 12, 2009, at 4:48 PM, Michael Chen wrote: > Cullen, > > I posted several issues regarding the -03 draft late July but > received no reply. I don't see changes related to these issues in > the new -04 draft. I want to make sure they are not overlooked: > > http://www.ietf.org/mail-archive/web/p2psip/current/msg05019.html > > 1) Section 5.5.1.1, the definition IceCandidate.rel_addr_port does > not conform with section 15.1 of the current mmusic-ice-19 draft, > which has the following text: > > " and : convey transport addresses related to the > candidate, useful for diagnostics and other purposes. > and MUST be present for server reflexive, peer > reflexive and relayed candidates." > > Therefore, the definition of IceCandidate should be: > > struct { > ... > select (type){ > case host: > ; /* Nothing */ > case srflx: > case prflx: > case relay: > IpAddressPort rel_addr_port; > } > ... > } IceCandidate; > > rel_addr_port > corresponds to the related address and port of ICE, which MUST > present for type "srflx", "prflx" and "relay". This was my mistake and an issue of having several people working on text. I thought the problem in 03 was we were missing rel_add_port, I went to look the draft and decided that, oh, someone already dealt with the email from Michael. I did not realize the problem was the with where the "; /*nothing*/ was in the select statement. Sorry we missed this email last time, it will be in the next version. > > 2) In Section 13.6, IANA message codes for AppAttachReq and > AppAttachReq are not added. I suggest fill these two values > (app_attach_req=5, app_attach_ans=6) in the holes left by the > abandoned tunnel_req and tunnel_ans. Added along with the lite version JC pointed out was missing. I did not use use the values 5 and 6 as I wanted to avoid a conflict with anyone that was using tunnel. > > 3) In Section 6.4.1.2, if the store request has multiple kinds, the > current answer structure will send replica node IDs multiple times. > For efficiency, I suggest moving the replica node IDs to the outer > layer as: > > struct { > KindId kind; > uint64 generation_counter; > } StoreKindResponse; > > struct { > StoreKindResponse kind_responses<0..216-1>; > NodeId replicas<0..216-1>; > } StoreAns; > > 4) It seems that mmusic-ice-tcp-07 has been abandoned. The key > members of this draft should address the lack of ice-tcp standard in > the next draft, meeting or on the mailing list. I don't know that ICE-TCP has been abandoned. It is still listed as a key milestone for the MMUSIC WG. I think the authors, chairs, ads, etc decided there was not to much criticality to working on it before the base ICE stuff got done. That said, I agree we should get ice-tcp moving again. Someone could go bug the mmusic WG and point out the charter says it will go to the IESG in Oct 2009. Of course the P2PSIP WGs milestones say this document will got the the IESG in September 2008. > > That is it so far. Thanks > > --Michael > > Cullen Jennings wrote: >> >> >> I just submitted >> draft-ietf-p2psip-base-04 >> and >> draft-ietf-p2psip-sip-02 >> >> These contain technical changes but do not have a lot of editorial >> changes. At some point we need to go and reorganize the documents >> with editorial changes. >> >> Cullen >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >> From fluffy@cisco.com Thu Oct 15 18:06:44 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16343A69C1 for ; Thu, 15 Oct 2009 18:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.436 X-Spam-Level: X-Spam-Status: No, score=-106.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtHziP-QemvP for ; Thu, 15 Oct 2009 18:06:44 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id EA7933A6805 for ; Thu, 15 Oct 2009 18:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1798; q=dns/txt; s=sjiport02001; t=1255655208; x=1256864808; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=20Section=203.5.2=20and=2010.5=20Discre pancies|Date:=20Thu,=2015=20Oct=202009=2019:06:46=20-0600 |Message-Id:=20<4A4500F5-BE8F-4849-A5C1-033DD98D3FE7@cisc o.com>|To:=20jc=20|Cc:=20p2psip=20 WG=20|Mime-Version:=201.0=20(Apple=20Mes sage=20framework=20v936)|Content-Transfer-Encoding:=207bi t|In-Reply-To:=20<1A87218C-3C7F-4D84-AD8B-A009615A083C@or chidseed.org>|References:=20<1A87218C-3C7F-4D84-AD8B-A009 615A083C@orchidseed.org>; bh=feZwcCM+YpmE6BB4KsjQqcPwVOmJ399337XwwMxJnfs=; b=W0iOh9g+4rzS9ERt6SXtuWji3JEIwuIWDDlyzaQDIcTGhunseT7ZAUCk ogfw7YV95jn/D0YnuCUL0rOE9F6U35jB300BMiQioc1MjiOHpyR8hqv8H 0H0JPmqQ1v7bR0wjlySAllGAu6jEC6YrC+DozlV90ySKKtKlpv3vu78b8 U=; Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANZj10qrR7H+/2dsb2JhbADAbpgqhDAE X-IronPort-AV: E=Sophos;i="4.44,569,1249257600"; d="scan'208";a="215080937" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 16 Oct 2009 01:06:47 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9G16NXf010034; Fri, 16 Oct 2009 01:06:47 GMT From: Cullen Jennings To: jc In-Reply-To: <1A87218C-3C7F-4D84-AD8B-A009615A083C@orchidseed.org> Impp: xmpp:cullenfluffyjennings@jabber.org References: <1A87218C-3C7F-4D84-AD8B-A009615A083C@orchidseed.org> Message-Id: <4A4500F5-BE8F-4849-A5C1-033DD98D3FE7@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 19:06:46 -0600 X-Mailer: Apple Mail (2.936) Cc: p2psip WG Subject: Re: [P2PSIP] Section 3.5.2 and 10.5 Discrepancies X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 01:06:44 -0000 I thought about this and talked to a few people. No one could see any reason the bootstrap node had to be a peer (clearly it can be a peer) so I went and updated the terminology to refer to bootstrap node instead of peer. Folks on the list, think about this one - if someone has a good reason that the bootstrap has to be a peer, this will need to be changed back. On Sep 10, 2009, at 4:54 AM, jc wrote: > Hi, > > From subversion(04) draft: > > 3.5.2. Joining, Leaving, and Maintenance Overview > > The first thing the peer needs to do is form a connection to some > "bootstrap node". > > 10.5. Contacting a Bootstrap Peer > > When contacting a bootstrap peer, the joining peer sends a Ping > request to the bootstrap peer's known IP address with the > destination Node-ID set to the joining peer's Node-ID > > When the requester peer finally does receive a response from some > responding peer, it can note the Node-ID in the response and use > this Node-ID to start sending requests to join the Overlay Instance > as described in > > There are two problems here, the first is simply terminology. > > 3.5.2 uses "bootstrap node" > > 10.5 uses "bootstrap peer" > > The second, 10.5 does not mention forming a connection and looks as > if it was based on a UDP bootstrap mechanism or the multicast > bootstrap(10.4). Am I correct that 10.5 is attempting to refer to > 3.5.2 and that 10.5 should clear up the fact that your forming a > connection to a bootstrap peer and not simply sending a datagram to > bootstrap nodes and waiting for responses? > > REgaRDs, > Julian > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Thu Oct 15 18:07:01 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0D1728C1C4 for ; Thu, 15 Oct 2009 18:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.998 X-Spam-Level: X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g7WUk440dcb for ; Thu, 15 Oct 2009 18:07:01 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 149D228C1C6 for ; Thu, 15 Oct 2009 18:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1054; q=dns/txt; s=sjiport06001; t=1255655225; x=1256864825; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20=3D?ISO-8859-1?Q?Re:_[P2PSIP]_10.1.=3DA0_Overlay_Confi guration_-_dra?=3D=0D=0A=20=3D?ISO-8859-1?Q?ft_version_04 ?=3D|Date:=20Thu,=2015=20Oct=202009=2019:07:02=20-0600 |Message-Id:=20|To:=20jc=20|Cc:=20p2psip=20 WG=20|Mime-Version:=201.0=20(Apple=20Mes sage=20framework=20v936)|Content-Transfer-Encoding:=207bi t|In-Reply-To:=20|References:=20; bh=sl2GR6zeNa9JRBWvYwzKTVXn6kfJgXLtWFUul1nk+K0=; b=CiPyFph6eZNf6u1UJwt17xGqcRsSb5426MxgrDxfb0/QEXQJcPH/Nudq Wq+zVcsqCoc8uWtHzD1aQp2Yvq5AfeK2hbVrNeswTgB5/QwFt2DwbkG+K TkTdcv0WkeA2Fqfrq1+sxVz4AZcOh4ziVDUa85KQ1q0k9Ez6uefgv232n 8=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABhk10qrR7H+/2dsb2JhbADAbZgqhDAE X-IronPort-AV: E=Sophos;i="4.44,569,1249257600"; d="scan'208";a="410439516" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2009 01:07:03 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9G16NXg010034; Fri, 16 Oct 2009 01:07:02 GMT From: Cullen Jennings To: jc In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 19:07:02 -0600 X-Mailer: Apple Mail (2.936) Cc: p2psip WG Subject: Re: [P2PSIP] =?iso-8859-1?q?10=2E1=2E=A0_Overlay_Configuration_-_draf?= =?iso-8859-1?q?t_version_04?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 01:07:01 -0000 On Sep 11, 2009, at 6:51 PM, jc wrote: > Hi, > > "required-kinds > This element indicates the kinds that members must support. It has > three attributes:" > > This is incorrect and there are some attributes/elements missing. I > have broken this down below: > > Attributes: > kind.name - Not mentioned but in xml. > kind.id - Not mentioned but in xml. > > Elements: > kind-block - Not Mentioned but in xml. > kind > data-model > max-count > max-size > kind-signature - Not mentioned but in xml. > max-node-multiple - Not always used. > access-control > Hopefully fixed in next version but give it a read - there were a bunch of changes in section 10.1 > Also chord-reload-update-frequency && chord-reload-ping-frequency do > not properly represent themselves within the xml. It is "chord:" > when it should be at least IMHO "chord:reload:". fixed > > Julian > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Thu Oct 15 18:07:10 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A551C28C1C7 for ; Thu, 15 Oct 2009 18:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.428 X-Spam-Level: X-Spam-Status: No, score=-106.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIuj2bVUTprA for ; Thu, 15 Oct 2009 18:07:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0AD8228C1C4 for ; Thu, 15 Oct 2009 18:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=464; q=dns/txt; s=sjiport06001; t=1255655234; x=1256864834; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Usage=20or=20multicast=20for=20discover=20of=20bootstr ap=20nodes|Date:=20Thu,=2015=20Oct=202009=2019:07:13=20-0 600|Message-Id:=20<199B1982-03D7-47C0-99F3-1180A8E40CD0@c isco.com>|To:=20P2PSIP=20WG=20 |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit; bh=6+lCnWVa8tAfORT+sPo3oXyY+r29C2fpOReHjGWnhK0=; b=mHjQI31QZxShLNewO3nJh/BZyp6EA5q9h2eGy879mMWJp9BdTB14zzqc sJmhdLV3Uuf9XSlzTAHIlvfik8XaTYmrqgz1ecIapRlH0HAqIh/n8iE26 srq9TXCXx9KteHCVwjjb+F9Yf2L1IhU4/bq563meF2XITx8XKtCBIEVY3 M=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABhk10qrR7H+/2dsb2JhbADAbZgqhDAE X-IronPort-AV: E=Sophos;i="4.44,569,1249257600"; d="scan'208";a="410439633" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2009 01:07:13 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9G16NXh010034 for ; Fri, 16 Oct 2009 01:07:13 GMT Message-Id: <199B1982-03D7-47C0-99F3-1180A8E40CD0@cisco.com> From: Cullen Jennings To: P2PSIP WG Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 19:07:13 -0600 X-Mailer: Apple Mail (2.936) Subject: [P2PSIP] Usage or multicast for discover of bootstrap nodes X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 01:07:10 -0000 I'm not aware of anyone that is using this. It's currently under- specified in the draft and I'm wondering if we should just remove it from the base draft. It could easily be added to a different extension draft. I'll take it out of the next version so people can see what this would look like but if this turns out not to be what people want, I'll add it back in if folks that want ti can send me the text to help finish it. Thanks, Cullen From fluffy@cisco.com Thu Oct 15 18:07:19 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A65028C1BC for ; Thu, 15 Oct 2009 18:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.439 X-Spam-Level: X-Spam-Status: No, score=-106.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mgvyvg8BueU for ; Thu, 15 Oct 2009 18:07:18 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DD01228C1BB for ; Thu, 15 Oct 2009 18:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=361; q=dns/txt; s=sjiport06001; t=1255655242; x=1256864842; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=2010.3.=20Credentials=20draft-ietf-p2ps ip-base.txt=20revision=203698|Date:=20Thu,=2015=20Oct=202 009=2019:07:22=20-0600|Message-Id:=20|To:=20jc=20|Cc:=20p2psip=20WG=20 |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit|In-Reply-To:=20 |References:=20; bh=kCI7nym8AGUrek9w9o5vsCwkRGTIoSpv45zC1T3Be8M=; b=b4TtYhgO2kqpX2UeDzq+Yva1QsxrCe7Wmzh+7T9iJ33iYz/X/qXgiRuK +jGzPNhXgkWwjMoYWAKZPlYBvs3V/oqKxm+gnjn7nm3PK+ofVz3M5OGs3 bULKyCa0CJ6P6ROs6LZUTo7dZCTcsNcmQgcBGHWNATnj/B7l9qgTjtyIV Y=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABhk10qrR7H+/2dsb2JhbADAbZgqgk8MgVUE X-IronPort-AV: E=Sophos;i="4.44,569,1249257600"; d="scan'208";a="410439691" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2009 01:07:22 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9G16NXi010034; Fri, 16 Oct 2009 01:07:22 GMT From: Cullen Jennings To: jc In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 19:07:22 -0600 X-Mailer: Apple Mail (2.936) Cc: p2psip WG Subject: Re: [P2PSIP] 10.3. Credentials draft-ietf-p2psip-base.txt revision 3698 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 01:07:19 -0000 fixed - thanks On Sep 5, 2009, at 2:18 AM, jc wrote: > I assume this is to say "the server generates and returns a"? > > 6312 > the requested user name is acceptable, the server and returns a > > Julian > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Thu Oct 15 18:07:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27FE028C1BB for ; Thu, 15 Oct 2009 18:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.448 X-Spam-Level: X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrnT96UvRbEx for ; Thu, 15 Oct 2009 18:07:26 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 68A2E3A69A8 for ; Thu, 15 Oct 2009 18:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1505; q=dns/txt; s=sjiport06001; t=1255655250; x=1256864850; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=20Clients=20node-id=20in=20RELOAD|Date: =20Thu,=2015=20Oct=202009=2019:07:29=20-0600|Message-Id: =20<050C22B9-0548-4B2A-8770-588102701470@cisco.com>|To: =20jc=20|Cc:=20Roni=20Even=20,=20"'p2psip'"=20 |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4531 3BCC-3AC1-4522-9FD0-0E7C88643CE8@orchidseed.org> |References:=20<004501ca23ff$2fbe6540$8f3b2fc0$%roni@huaw ei.com>=20<45313BCC-3AC1-4522-9FD0-0E7C88643CE8@orchidsee d.org>; bh=hB7iR2YNLqmiVF0++2uA6dpooWJXknHIkaF5WHpNzyE=; b=nj/OcwJGzKqBLXvXdLpKnwEjJ4M/B5tLjUJgcqE8Yn4HHC2BKiIyNHY/ HjJco79lpScoRcOe8+G3q7ZvMuXiQPqpDPgQfxCyb1tUwsjfHqriB05HB Ser6x+NUQtMZ4dFGltbz5kmqppUoBtzmXoDJeO5rINBB/kjvizKg5Ukgt A=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABhk10qrR7H+/2dsb2JhbADAbZgqhDAE X-IronPort-AV: E=Sophos;i="4.44,569,1249257600"; d="scan'208";a="410439754" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2009 01:07:30 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9G16NXj010034; Fri, 16 Oct 2009 01:07:29 GMT From: Cullen Jennings To: jc In-Reply-To: <45313BCC-3AC1-4522-9FD0-0E7C88643CE8@orchidseed.org> Impp: xmpp:cullenfluffyjennings@jabber.org References: <004501ca23ff$2fbe6540$8f3b2fc0$%roni@huawei.com> <45313BCC-3AC1-4522-9FD0-0E7C88643CE8@orchidseed.org> Message-Id: <050C22B9-0548-4B2A-8770-588102701470@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 19:07:29 -0600 X-Mailer: Apple Mail (2.936) Cc: 'p2psip' , Roni Even Subject: Re: [P2PSIP] Clients node-id in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 01:07:27 -0000 Fixed section E.1 in next version On Aug 23, 2009, at 10:20 AM, jc wrote: > Roni, > Clients have two options described in section 3.2.1 to use the > overlay. The client-id is stored in it's certificate so it's > responsible peer or any other node already has this if a TLS/DTLS > connection handshake has completed. See section 3.1 for more > information. > > As far as section E.1 CONNECT is now an AppAttach message. > > Julian > > On Aug 23, 2009, at 7:36 AM, Roni Even wrote: > >> Hi, >> I looked at the client procedures in RELOAD and I am not sure I >> understand how the client provides its responsible peer his client- >> id. I assume that ATTACH is being used to form the direct >> connection from the client to the responsible peer. >> BTW: In section E.1 the text says - " A node acting as a client >> that has a full implementation of RELOAD and the appropriate >> overlay algorithm is capable of locating its responsible peer in >> the overlay and using CONNECT to establish a direct connection to >> that peer." I think that CONNECT is an old message from the >> individual draft and it should have said ATTACH. >> >> Thanks >> Roni Even >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From julian@orchidseed.org Thu Oct 15 19:03:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22D73A67AD for ; Thu, 15 Oct 2009 19:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhEOcfUNOlOt for ; Thu, 15 Oct 2009 19:03:27 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id 001DF3A6403 for ; Thu, 15 Oct 2009 19:03:26 -0700 (PDT) Received: from adsl-176-184-222.asm.bellsouth.net ([74.176.184.222]:50887 helo=[192.168.1.3]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MycAB-0001zz-RH; Thu, 15 Oct 2009 19:03:30 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: <4A4500F5-BE8F-4849-A5C1-033DD98D3FE7@cisco.com> Date: Thu, 15 Oct 2009 22:02:52 -0400 Content-Transfer-Encoding: 7bit Message-Id: <89E41E44-5476-4274-83CE-69301516E0F8@orchidseed.org> References: <1A87218C-3C7F-4D84-AD8B-A009615A083C@orchidseed.org> <4A4500F5-BE8F-4849-A5C1-033DD98D3FE7@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] Section 3.5.2 and 10.5 Discrepancies X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 02:03:27 -0000 As long as a client can perform lookups on behalf of other nodes this won't be a problem. Julian On Oct 15, 2009, at 9:06 PM, Cullen Jennings wrote: > > I thought about this and talked to a few people. No one could see > any reason the bootstrap node had to be a peer (clearly it can be a > peer) so I went and updated the terminology to refer to bootstrap > node instead of peer. Folks on the list, think about this one - if > someone has a good reason that the bootstrap has to be a peer, this > will need to be changed back. > > > On Sep 10, 2009, at 4:54 AM, jc wrote: > >> Hi, >> >> From subversion(04) draft: >> >> 3.5.2. Joining, Leaving, and Maintenance Overview >> >> The first thing the peer needs to do is form a connection to some >> "bootstrap node". >> >> 10.5. Contacting a Bootstrap Peer >> >> When contacting a bootstrap peer, the joining peer sends a Ping >> request to the bootstrap peer's known IP address with the >> destination Node-ID set to the joining peer's Node-ID >> >> When the requester peer finally does receive a response from some >> responding peer, it can note the Node-ID in the response and use >> this Node-ID to start sending requests to join the Overlay Instance >> as described in >> >> There are two problems here, the first is simply terminology. >> >> 3.5.2 uses "bootstrap node" >> >> 10.5 uses "bootstrap peer" >> > > >> The second, 10.5 does not mention forming a connection and looks as >> if it was based on a UDP bootstrap mechanism or the multicast >> bootstrap(10.4). Am I correct that 10.5 is attempting to refer to >> 3.5.2 and that 10.5 should clear up the fact that your forming a >> connection to a bootstrap peer and not simply sending a datagram to >> bootstrap nodes and waiting for responses? >> >> REgaRDs, >> Julian >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > From julian@orchidseed.org Thu Oct 15 19:12:17 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5061D3A6807 for ; Thu, 15 Oct 2009 19:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D809lyJx0oZ2 for ; Thu, 15 Oct 2009 19:12:16 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id 7053B3A67EA for ; Thu, 15 Oct 2009 19:12:16 -0700 (PDT) Received: from adsl-176-184-222.asm.bellsouth.net ([74.176.184.222]:51195 helo=[192.168.1.3]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MycIk-0006SM-0V; Thu, 15 Oct 2009 19:12:19 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: <199B1982-03D7-47C0-99F3-1180A8E40CD0@cisco.com> Date: Thu, 15 Oct 2009 22:11:43 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <199B1982-03D7-47C0-99F3-1180A8E40CD0@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] Usage or multicast for discover of bootstrap nodes X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 02:12:17 -0000 Cullen, I've implemented multicast bootstrap and have it well defined. It's not a necessity and can be removed for base simplicity. As you said it can be added as an extension draft. In fact I could write the extension draft for multicast bootstrap. Julian On Oct 15, 2009, at 9:07 PM, Cullen Jennings wrote: > > I'm not aware of anyone that is using this. It's currently under- > specified in the draft and I'm wondering if we should just remove it > from the base draft. It could easily be added to a different > extension draft. I'll take it out of the next version so people can > see what this would look like but if this turns out not to be what > people want, I'll add it back in if folks that want ti can send me > the text to help finish it. > > Thanks, Cullen > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From julian@orchidseed.org Thu Oct 15 19:36:56 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EE3A3A6842 for ; Thu, 15 Oct 2009 19:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyObKhkOK1dy for ; Thu, 15 Oct 2009 19:36:55 -0700 (PDT) Received: from n25.c05.mtsvc.net (n25.c05.mtsvc.net [70.32.68.25]) by core3.amsl.com (Postfix) with ESMTP id 77A213A6403 for ; Thu, 15 Oct 2009 19:36:55 -0700 (PDT) Received: from adsl-176-184-222.asm.bellsouth.net ([74.176.184.222]:52369 helo=[192.168.1.3]) by n25.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1Mycgc-0004V2-Go; Thu, 15 Oct 2009 19:36:58 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: <89E41E44-5476-4274-83CE-69301516E0F8@orchidseed.org> Date: Thu, 15 Oct 2009 22:36:23 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <1A87218C-3C7F-4D84-AD8B-A009615A083C@orchidseed.org> <4A4500F5-BE8F-4849-A5C1-033DD98D3FE7@cisco.com> <89E41E44-5476-4274-83CE-69301516E0F8@orchidseed.org> To: jc X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] Section 3.5.2 and 10.5 Discrepancies X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 02:36:56 -0000 Cullen, I may not be on the same page as to what I just said.(old email) This is referring to the fact that you CAN bootstrap off of ANY node? If so then the terminology needs to state otherwise about public ip address as well. Because you CAN bootstrap off of a Client behind the same NAT that is connected to a remote Peer that is inside the ring. I demonstrated this with multicast bootstrap. If that is the case the following may be removed: Because this is the first connection the peer 1461 makes, these nodes must have public IP addresses and therefore can be 1462 connected to directly. from svn: 1451 The first thing the peer needs to do is form a connection to some 1460 "bootstrap node". Because this is the first connection the peer 1461 makes, these nodes must have public IP addresses and therefore can be 1462 connected to directly. Once a peer has connected to one or more 1463 bootstrap nodes, it can form connections in the usual way by routing 1464 Attach messages through the overlay to other nodes. Once a peer has 1465 connected to the overlay for the first time, it can cache the set of 1466 nodes it has connected to with public IP addresses for use as future 1467 bootstrap nodes. If this wasn't the topic please disregard. Julian On Oct 15, 2009, at 10:02 PM, jc wrote: > As long as a client can perform lookups on behalf of other nodes > this won't be a problem. > > Julian > > On Oct 15, 2009, at 9:06 PM, Cullen Jennings wrote: > >> >> I thought about this and talked to a few people. No one could see >> any reason the bootstrap node had to be a peer (clearly it can be a >> peer) so I went and updated the terminology to refer to bootstrap >> node instead of peer. Folks on the list, think about this one - if >> someone has a good reason that the bootstrap has to be a peer, this >> will need to be changed back. >> >> >> On Sep 10, 2009, at 4:54 AM, jc wrote: >> >>> Hi, >>> >>> From subversion(04) draft: >>> >>> 3.5.2. Joining, Leaving, and Maintenance Overview >>> >>> The first thing the peer needs to do is form a connection to some >>> "bootstrap node". >>> >>> 10.5. Contacting a Bootstrap Peer >>> >>> When contacting a bootstrap peer, the joining peer sends a Ping >>> request to the bootstrap peer's known IP address with the >>> destination Node-ID set to the joining peer's Node-ID >>> >>> When the requester peer finally does receive a response from some >>> responding peer, it can note the Node-ID in the response and use >>> this Node-ID to start sending requests to join the Overlay >>> Instance as described in >>> >>> There are two problems here, the first is simply terminology. >>> >>> 3.5.2 uses "bootstrap node" >>> >>> 10.5 uses "bootstrap peer" >>> >> >> >>> The second, 10.5 does not mention forming a connection and looks >>> as if it was based on a UDP bootstrap mechanism or the multicast >>> bootstrap(10.4). Am I correct that 10.5 is attempting to refer to >>> 3.5.2 and that 10.5 should clear up the fact that your forming a >>> connection to a bootstrap peer and not simply sending a datagram >>> to bootstrap nodes and waiting for responses? >>> >>> REgaRDs, >>> Julian >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From julian@orchidseed.org Thu Oct 15 20:11:28 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B0E28C12C for ; Thu, 15 Oct 2009 20:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t61baDmqnFSx for ; Thu, 15 Oct 2009 20:11:27 -0700 (PDT) Received: from n13.c05.mtsvc.net (n13.c05.mtsvc.net [70.32.68.13]) by core3.amsl.com (Postfix) with ESMTP id B114D28C0E3 for ; Thu, 15 Oct 2009 20:11:27 -0700 (PDT) Received: from adsl-176-184-222.asm.bellsouth.net ([74.176.184.222]:53810 helo=[192.168.1.3]) by n13.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MydE0-00016G-KS; Thu, 15 Oct 2009 20:11:30 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: Date: Thu, 15 Oct 2009 23:10:49 -0400 Content-Transfer-Encoding: 7bit Message-Id: <77A94CB4-4B65-489A-BC7A-39B994412B67@orchidseed.org> References: <1A87218C-3C7F-4D84-AD8B-A009615A083C@orchidseed.org> <4A4500F5-BE8F-4849-A5C1-033DD98D3FE7@cisco.com> <89E41E44-5476-4274-83CE-69301516E0F8@orchidseed.org> To: jc X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] Section 3.5.2 and 10.5 Discrepancies X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 03:11:28 -0000 On what I just said. If Client A connects to Client B that is connected to Peer Y then Client A can send a Lookup through Client B to Peer Y performing the bootstrap. Should clients be able to bootstrap off of other clients or is this to be reserved for public ip addresses as currently stated in draft? The confusion of this was created by multicast bootstrap. If multicast bootstrap is removed then this won't be a problem anymore. Julian On Oct 15, 2009, at 10:36 PM, jc wrote: > Cullen, > I may not be on the same page as to what I just said.(old email) > This is referring to the fact that you CAN bootstrap off of ANY > node? If so then the terminology needs to state otherwise about > public ip address as well. Because you CAN bootstrap off of a Client > behind the same NAT that is connected to a remote Peer that is > inside the ring. I demonstrated this with multicast bootstrap. > > If that is the case the following may be removed: > > Because this is the first connection the peer > 1461 makes, these nodes must have public IP addresses and > therefore can be > 1462 connected to directly. > > from svn: > > 1451 The first thing the peer needs to do is form a connection to > some > 1460 "bootstrap node". Because this is the first connection the > peer > 1461 makes, these nodes must have public IP addresses and > therefore can be > 1462 connected to directly. Once a peer has connected to one or > more > 1463 bootstrap nodes, it can form connections in the usual way by > routing > 1464 Attach messages through the overlay to other nodes. Once a > peer has > 1465 connected to the overlay for the first time, it can cache > the set of > 1466 nodes it has connected to with public IP addresses for use > as future > 1467 bootstrap nodes. > > If this wasn't the topic please disregard. > > Julian > > On Oct 15, 2009, at 10:02 PM, jc wrote: > >> As long as a client can perform lookups on behalf of other nodes >> this won't be a problem. >> >> Julian >> >> On Oct 15, 2009, at 9:06 PM, Cullen Jennings wrote: >> >>> >>> I thought about this and talked to a few people. No one could see >>> any reason the bootstrap node had to be a peer (clearly it can be >>> a peer) so I went and updated the terminology to refer to >>> bootstrap node instead of peer. Folks on the list, think about >>> this one - if someone has a good reason that the bootstrap has to >>> be a peer, this will need to be changed back. >>> >>> >>> On Sep 10, 2009, at 4:54 AM, jc wrote: >>> >>>> Hi, >>>> >>>> From subversion(04) draft: >>>> >>>> 3.5.2. Joining, Leaving, and Maintenance Overview >>>> >>>> The first thing the peer needs to do is form a connection to some >>>> "bootstrap node". >>>> >>>> 10.5. Contacting a Bootstrap Peer >>>> >>>> When contacting a bootstrap peer, the joining peer sends a Ping >>>> request to the bootstrap peer's known IP address with the >>>> destination Node-ID set to the joining peer's Node-ID >>>> >>>> When the requester peer finally does receive a response from some >>>> responding peer, it can note the Node-ID in the response and use >>>> this Node-ID to start sending requests to join the Overlay >>>> Instance as described in >>>> >>>> There are two problems here, the first is simply terminology. >>>> >>>> 3.5.2 uses "bootstrap node" >>>> >>>> 10.5 uses "bootstrap peer" >>>> >>> >>> >>>> The second, 10.5 does not mention forming a connection and looks >>>> as if it was based on a UDP bootstrap mechanism or the multicast >>>> bootstrap(10.4). Am I correct that 10.5 is attempting to refer to >>>> 3.5.2 and that 10.5 should clear up the fact that your forming a >>>> connection to a bootstrap peer and not simply sending a datagram >>>> to bootstrap nodes and waiting for responses? >>>> >>>> REgaRDs, >>>> Julian >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > From michaelc@idssoftware.com Thu Oct 15 20:36:57 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CC3A28C113 for ; Thu, 15 Oct 2009 20:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.393 X-Spam-Level: X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[AWL=2.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0f0-AA6+nrc for ; Thu, 15 Oct 2009 20:36:56 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id B541528C0EA for ; Thu, 15 Oct 2009 20:36:56 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Mydcf-000446-DC; Thu, 15 Oct 2009 23:36:57 -0400 Message-ID: <4AD7EBBB.6080004@idssoftware.com> Date: Thu, 15 Oct 2009 20:42:51 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: jc References: <199B1982-03D7-47C0-99F3-1180A8E40CD0@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da9406932682517446f51daa0c9d0cde9aa8d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Cc: P2PSIP WG Subject: Re: [P2PSIP] Usage or multicast for discover of bootstrap nodes X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 03:36:57 -0000 Julian, We implemented UDP broadcast bootstrap as a simple way to form a ring in a private network with no enrollment server (self-signed cert, of course). This is specified in section 5.5.5 and 10.4 of the draft. However, there is a small detail here. We assume the broadcast is always on the Reload port number, i.e. 255.255.255.255:6084 (thus no enrollment server is needed). I believe this should be recommended by the draft. Adding this as an extension would seem too trivial. Cullen, This method (along with LAN multicast) is VERY USEFUL. A private network can have a single long running node connected to the overlay on the public Internet. When other peers boot up, they only need to use broadcast or multicast to join the overlay via that lone "seed" node in their private network. Thanks --Michael jc wrote: > Cullen, > I've implemented multicast bootstrap and have it well defined. It's > not a necessity and can be removed for base simplicity. As you said it > can be added as an extension draft. In fact I could write the > extension draft for multicast bootstrap. > > Julian > > On Oct 15, 2009, at 9:07 PM, Cullen Jennings wrote: > >> >> I'm not aware of anyone that is using this. It's currently >> under-specified in the draft and I'm wondering if we should just >> remove it from the base draft. It could easily be added to a >> different extension draft. I'll take it out of the next version so >> people can see what this would look like but if this turns out not to >> be what people want, I'll add it back in if folks that want ti can >> send me the text to help finish it. >> >> Thanks, Cullen >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From julian@orchidseed.org Thu Oct 15 20:45:55 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00BA3A6810 for ; Thu, 15 Oct 2009 20:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IQNJkJpB1rl for ; Thu, 15 Oct 2009 20:45:54 -0700 (PDT) Received: from n13.c05.mtsvc.net (n13.c05.mtsvc.net [70.32.68.13]) by core3.amsl.com (Postfix) with ESMTP id ACAB83A680B for ; Thu, 15 Oct 2009 20:45:54 -0700 (PDT) Received: from adsl-176-184-222.asm.bellsouth.net ([74.176.184.222]:55165 helo=[192.168.1.3]) by n13.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MydlK-00078P-Rw; Thu, 15 Oct 2009 20:45:58 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: <77A94CB4-4B65-489A-BC7A-39B994412B67@orchidseed.org> Date: Thu, 15 Oct 2009 23:45:17 -0400 Content-Transfer-Encoding: 7bit Message-Id: <9F7B7BB6-6DC8-4DB5-81A8-8F90F5B78D3F@orchidseed.org> References: <1A87218C-3C7F-4D84-AD8B-A009615A083C@orchidseed.org> <4A4500F5-BE8F-4849-A5C1-033DD98D3FE7@cisco.com> <89E41E44-5476-4274-83CE-69301516E0F8@orchidseed.org> <77A94CB4-4B65-489A-BC7A-39B994412B67@orchidseed.org> To: jc X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] Section 3.5.2 and 10.5 Discrepancies X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 03:45:55 -0000 6481 10.4. Contacting a Bootstrap Node 6482 6483 In order to join the overlay, the joining peer MUST contact a peer in 6484 the overlay. Typically this means contacting the bootstrap nodes, 6485 since they are guaranteed to have public IP addresses (the overlay 6486 configuration should not advertise them as bootstrap nodes 6487 otherwise). If the joining peer has cached a list of peers it has 6488 previously been connected with in this overlay, as an optimization it 6489 MAY attempt to use one or more of them as bootstrap nodes before 6490 falling back to the bootstrap nodes listed in the configuration file. Section 3.2 and 10.4 backs up my discussion. Technically speaking a Client performs a bootstrap and when inside the ring will be considered a Peer. So a Peer doesn't join the overlay as stated, a Client does but more-so a Node in general. This could be more clear by stating Node when referring to a Bootstrap or Join procedure instead of a Peer on the Sender side. However in the end this is a "when are you considered a peer vs client" scenario. For instance if you are sending a Join chances are the intentions of the Node is to become a Peer. From 3.2: 1143 We use the term "peer" to identify a node in the overlay that routes 1144 messages for nodes other than those to which it is directly 1145 connected. This states that you are not not a Peer when you send a Join but instead after the Join and Updates have been performed and the Node is inside the ring. Therefore a Client or Node performs Bootstrap and Join procedures not Peers. Julian On Oct 15, 2009, at 11:10 PM, jc wrote: > On what I just said. If Client A connects to Client B that is > connected to Peer Y then Client A can send a Lookup through Client B > to Peer Y performing the bootstrap. Should clients be able to > bootstrap off of other clients or is this to be reserved for public > ip addresses as currently stated in draft? The confusion of this was > created by multicast bootstrap. If multicast bootstrap is removed > then this won't be a problem anymore. > > Julian > > On Oct 15, 2009, at 10:36 PM, jc wrote: > >> Cullen, >> I may not be on the same page as to what I just said.(old email) >> This is referring to the fact that you CAN bootstrap off of ANY >> node? If so then the terminology needs to state otherwise about >> public ip address as well. Because you CAN bootstrap off of a >> Client behind the same NAT that is connected to a remote Peer that >> is inside the ring. I demonstrated this with multicast bootstrap. >> >> If that is the case the following may be removed: >> >> Because this is the first connection the peer >> 1461 makes, these nodes must have public IP addresses and >> therefore can be >> 1462 connected to directly. >> >> from svn: >> >> 1451 The first thing the peer needs to do is form a connection >> to some >> 1460 "bootstrap node". Because this is the first connection the >> peer >> 1461 makes, these nodes must have public IP addresses and >> therefore can be >> 1462 connected to directly. Once a peer has connected to one or >> more >> 1463 bootstrap nodes, it can form connections in the usual way >> by routing >> 1464 Attach messages through the overlay to other nodes. Once a >> peer has >> 1465 connected to the overlay for the first time, it can cache >> the set of >> 1466 nodes it has connected to with public IP addresses for use >> as future >> 1467 bootstrap nodes. >> >> If this wasn't the topic please disregard. >> >> Julian >> >> On Oct 15, 2009, at 10:02 PM, jc wrote: >> >>> As long as a client can perform lookups on behalf of other nodes >>> this won't be a problem. >>> >>> Julian >>> >>> On Oct 15, 2009, at 9:06 PM, Cullen Jennings wrote: >>> >>>> >>>> I thought about this and talked to a few people. No one could see >>>> any reason the bootstrap node had to be a peer (clearly it can be >>>> a peer) so I went and updated the terminology to refer to >>>> bootstrap node instead of peer. Folks on the list, think about >>>> this one - if someone has a good reason that the bootstrap has to >>>> be a peer, this will need to be changed back. >>>> >>>> >>>> On Sep 10, 2009, at 4:54 AM, jc wrote: >>>> >>>>> Hi, >>>>> >>>>> From subversion(04) draft: >>>>> >>>>> 3.5.2. Joining, Leaving, and Maintenance Overview >>>>> >>>>> The first thing the peer needs to do is form a connection to >>>>> some "bootstrap node". >>>>> >>>>> 10.5. Contacting a Bootstrap Peer >>>>> >>>>> When contacting a bootstrap peer, the joining peer sends a Ping >>>>> request to the bootstrap peer's known IP address with the >>>>> destination Node-ID set to the joining peer's Node-ID >>>>> >>>>> When the requester peer finally does receive a response from >>>>> some responding peer, it can note the Node-ID in the response >>>>> and use this Node-ID to start sending requests to join the >>>>> Overlay Instance as described in >>>>> >>>>> There are two problems here, the first is simply terminology. >>>>> >>>>> 3.5.2 uses "bootstrap node" >>>>> >>>>> 10.5 uses "bootstrap peer" >>>>> >>>> >>>> >>>>> The second, 10.5 does not mention forming a connection and looks >>>>> as if it was based on a UDP bootstrap mechanism or the multicast >>>>> bootstrap(10.4). Am I correct that 10.5 is attempting to refer >>>>> to 3.5.2 and that 10.5 should clear up the fact that your >>>>> forming a connection to a bootstrap peer and not simply sending >>>>> a datagram to bootstrap nodes and waiting for responses? >>>>> >>>>> REgaRDs, >>>>> Julian >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> > From julian@orchidseed.org Thu Oct 15 21:07:49 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5FC728C1E4 for ; Thu, 15 Oct 2009 21:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKiA4MbQYIeb for ; Thu, 15 Oct 2009 21:07:49 -0700 (PDT) Received: from n25.c05.mtsvc.net (n25.c05.mtsvc.net [70.32.68.25]) by core3.amsl.com (Postfix) with ESMTP id 42AA428C1D6 for ; Thu, 15 Oct 2009 21:07:49 -0700 (PDT) Received: from adsl-176-184-222.asm.bellsouth.net ([74.176.184.222]:56182 helo=[192.168.1.3]) by n25.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1Mye6a-00027V-Aq for p2psip@ietf.org; Thu, 15 Oct 2009 21:07:52 -0700 From: jc Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 16 Oct 2009 00:07:18 -0400 Message-Id: <54862416-F9EA-4A8B-B345-DC1766E87ACF@orchidseed.org> To: p2psip WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Subject: [P2PSIP] 5.5.5 Ping X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 04:07:49 -0000 Still contains the wording of broadcast. 3774 5.5.5. Ping 3775 3776 Ping is used to test connectivity along a path. A ping can be 3777 addressed to a specific Node-ID, the peer controlling a given 3778 location (by using a resource ID), or to the broadcast Node-ID 3779 (2^128-1). Julian From julian@orchidseed.org Thu Oct 15 21:14:36 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B12A3A6979 for ; Thu, 15 Oct 2009 21:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 960WpG3aNk4v for ; Thu, 15 Oct 2009 21:14:35 -0700 (PDT) Received: from n25.c05.mtsvc.net (n25.c05.mtsvc.net [70.32.68.25]) by core3.amsl.com (Postfix) with ESMTP id 4C7863A68BB for ; Thu, 15 Oct 2009 21:14:35 -0700 (PDT) Received: from adsl-176-184-222.asm.bellsouth.net ([74.176.184.222]:56471 helo=[192.168.1.3]) by n25.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MyeD7-0004cw-SL; Thu, 15 Oct 2009 21:14:38 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: <4AD7EBBB.6080004@idssoftware.com> Date: Fri, 16 Oct 2009 00:14:04 -0400 Content-Transfer-Encoding: 7bit Message-Id: <6513FC28-EA53-40A2-8C00-CDFF64D024A0@orchidseed.org> References: <199B1982-03D7-47C0-99F3-1180A8E40CD0@cisco.com> <4AD7EBBB.6080004@idssoftware.com> To: Michael Chen X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] Usage or multicast for discover of bootstrap nodes X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 04:14:36 -0000 On Oct 15, 2009, at 11:42 PM, Michael Chen wrote: > Julian, > > We implemented UDP broadcast bootstrap as a simple way to form a > ring in a private network with no enrollment server (self-signed > cert, of course). This is specified in section 5.5.5 and 10.4 of the > draft. > > However, there is a small detail here. We assume the broadcast is > always on the Reload port number, i.e. 255.255.255.255:6084 (thus no > enrollment server is needed). I believe this should be recommended > by the draft. Adding this as an extension would seem too trivial. I somewhat agree however this isn't fully defined as Cullen and I have pointed out. Also it seems your experiencing the same effect where you now use internal IP's with Bootstrap because LAN Multicast which as I mentioned in a previous email is forbidden by the draft. So either it needs to be fully removed or fully defined and Cullen has removed it for now. I don't believe the draft should define this because it's actually non-trivial. When do you join the multicast group? How long are you a member? Do you send unicast and receive unicast? What do you do if you receive a stray message of N type? What is the broadcast interval? Do you join a multicast group on all active network interfaces? Do you use loopback? I believe this should be an extension draft because it is non-crucial to the base protocol. If this were to be part of the base protocol draft then as I mentioned in the previous emails there would need to be changes made regarding Clients and Peers as well as the references to External and Routable IP addressing. > > Cullen, > > This method (along with LAN multicast) is VERY USEFUL. A private > network can have a single long running node connected to the overlay > on the public Internet. When other peers boot up, they only need to > use broadcast or multicast to join the overlay via that lone "seed" > node in their private network. > > Thanks > > --Michael > > jc wrote: >> Cullen, >> I've implemented multicast bootstrap and have it well defined. It's >> not a necessity and can be removed for base simplicity. As you said >> it can be added as an extension draft. In fact I could write the >> extension draft for multicast bootstrap. >> >> Julian >> >> On Oct 15, 2009, at 9:07 PM, Cullen Jennings wrote: >> >>> >>> I'm not aware of anyone that is using this. It's currently under- >>> specified in the draft and I'm wondering if we should just remove >>> it from the base draft. It could easily be added to a different >>> extension draft. I'll take it out of the next version so people >>> can see what this would look like but if this turns out not to be >>> what people want, I'll add it back in if folks that want ti can >>> send me the text to help finish it. >>> >>> Thanks, Cullen >>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >> From neil.young@freenet.de Fri Oct 16 06:14:20 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED943A690C for ; Fri, 16 Oct 2009 06:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac6x8OF8zSkz for ; Fri, 16 Oct 2009 06:14:18 -0700 (PDT) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by core3.amsl.com (Postfix) with ESMTP id 1ABEC3A6930 for ; Fri, 16 Oct 2009 06:14:17 -0700 (PDT) Received: from [195.4.92.13] (helo=3.mx.freenet.de) by mout1.freenet.de with esmtpa (ID roland.klabunde@freenet.de) (port 25) (Exim 4.69 #92) id 1MymdQ-0001eX-Ug for p2psip@ietf.org; Fri, 16 Oct 2009 15:14:20 +0200 Received: from p54bd97a5.dip0.t-ipconnect.de ([84.189.151.165]:50772 helo=[192.168.178.38]) by 3.mx.freenet.de with esmtpa (ID roland.klabunde@freenet.de) (port 25) (Exim 4.69 #94) id 1MymdQ-0003x0-M2 for p2psip@ietf.org; Fri, 16 Oct 2009 15:14:20 +0200 Message-ID: <4AD871AC.7020203@freenet.de> Date: Fri, 16 Oct 2009 15:14:20 +0200 From: "neil.young" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: P2PSIP WG Content-Type: multipart/alternative; boundary="------------010907090601010302070709" Subject: [P2PSIP] Question about how to begin X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: neil.young@freenet.de List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 13:14:20 -0000 This is a multi-part message in MIME format. --------------010907090601010302070709 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi, I recently finished the development of a CHORD implementation in C#. I already use a proprietary binary TCP communication protocol for the CHORD messages (findsuccessor, the notify and stabilize routines, the ping etc.). In near future I want to proceed to RELOAD, whereas the desired implementation does not necessarily has to have full RELOAD characteristics as the first result. Especially these items are not required initially, so that the first implementation would more be a REL instead of RELOAD :) 1) Security 2) NAT traversal 3) ICE STUN support 4) Enrollment server Implementors, could you give me please some suggestions, where to start with best under these circumstances? Kind regards --------------010907090601010302070709 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Hi,

I recently finished the development of a CHORD implementation in C#. I already use a proprietary binary TCP communication protocol for the CHORD messages (findsuccessor, the notify and stabilize routines, the ping etc.). In near future I want to proceed to RELOAD, whereas the desired implementation does not necessarily has to have full RELOAD characteristics as the first result. Especially these items are not required initially, so that the first implementation would more be a REL instead of RELOAD :)

1) Security
2) NAT traversal
3) ICE STUN support
4) Enrollment server

Implementors, could you give me please some suggestions, where to start with best under these circumstances? 

Kind regards

 --------------010907090601010302070709-- From fluffy@cisco.com Fri Oct 16 07:44:20 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420D33A68BA for ; Fri, 16 Oct 2009 07:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.457 X-Spam-Level: X-Spam-Status: No, score=-106.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rbby30z7JceE for ; Fri, 16 Oct 2009 07:44:19 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4EFA53A68FC for ; Fri, 16 Oct 2009 07:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3723; q=dns/txt; s=sjiport01001; t=1255704263; x=1256913863; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=20Usage=20or=20multicast=20for=20discov er=20of=20bootstrap=20nodes|Date:=20Fri,=2016=20Oct=20200 9=2008:44:20=20-0600|Message-Id:=20<2C79C96F-EC85-49D9-AE 4D-C1ADE2C1F2FB@cisco.com>|To:=20jc=20,=20Michael=20Chen=20|Cc: =20P2PSIP=20WG=20|Mime-Version:=201.0=20 (Apple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<6513FC 28-EA53-40A2-8C00-CDFF64D024A0@orchidseed.org> |References:=20<199B1982-03D7-47C0-99F3-1180A8E40CD0@cisc o.com>=20=20<4AD7EBBB.6080004@idssoftware.com>=20<6513FC28-EA 53-40A2-8C00-CDFF64D024A0@orchidseed.org>; bh=tLRjNY5q1R+nmbkyztuO4mKqaA/urLtW5f2Z9323LQ8=; b=RKKz2vH7dXehy4mMI9IT7FrFw9ubW7GpaLaENVdeelVw0/9x/GgaiEll M62srm/h5POddD9coylovhQTkRL7DV4X+O30ubJGg9uUUexQrgmzKW1gC eEIKXxh49Nu3frStZqEiJIcVXKTMgwpafeYcjXauSU0Pxk7DA/A44W+Kt w=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAYk2EqrR7H+/2dsb2JhbADBJokYCY8Mgk6BYgQ X-IronPort-AV: E=Sophos;i="4.44,574,1249257600"; d="scan'208";a="257125434" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 16 Oct 2009 14:44:22 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9GEiLDp027537; Fri, 16 Oct 2009 14:44:21 GMT From: Cullen Jennings To: jc , Michael Chen In-Reply-To: <6513FC28-EA53-40A2-8C00-CDFF64D024A0@orchidseed.org> Impp: xmpp:cullenfluffyjennings@jabber.org References: <199B1982-03D7-47C0-99F3-1180A8E40CD0@cisco.com> <4AD7EBBB.6080004@idssoftware.com> <6513FC28-EA53-40A2-8C00-CDFF64D024A0@orchidseed.org> Message-Id: <2C79C96F-EC85-49D9-AE4D-C1ADE2C1F2FB@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Oct 2009 08:44:20 -0600 X-Mailer: Apple Mail (2.936) Cc: P2PSIP WG Subject: Re: [P2PSIP] Usage or multicast for discover of bootstrap nodes X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 14:44:20 -0000 I did not realize you had both implemented the multicast stuff. I think another group also did. Given it has been in the draft for a long time, and people are implementing it, it was a mistake for me to take it out. Lets work to figure out what needs to be specified to make it all work and also figure out the MAYs and MUSTs. On Oct 15, 2009, at 10:14 PM, jc wrote: > > On Oct 15, 2009, at 11:42 PM, Michael Chen wrote: > >> Julian, >> >> We implemented UDP broadcast bootstrap as a simple way to form a >> ring in a private network with no enrollment server (self-signed >> cert, of course). This is specified in section 5.5.5 and 10.4 of >> the draft. >> >> However, there is a small detail here. We assume the broadcast is >> always on the Reload port number, i.e. 255.255.255.255:6084 (thus >> no enrollment server is needed). I believe this should be >> recommended by the draft. Adding this as an extension would seem >> too trivial. > > I somewhat agree however this isn't fully defined as Cullen and I > have pointed out. Also it seems your experiencing the same effect > where you now use internal IP's with Bootstrap because LAN Multicast > which as I mentioned in a previous email is forbidden by the draft. > So either it needs to be fully removed or fully defined and Cullen > has removed it for now. I don't believe the draft should define this > because it's actually non-trivial. When do you join the multicast > group? How long are you a member? Do you send unicast and receive > unicast? What do you do if you receive a stray message of N type? > What is the broadcast interval? Do you join a multicast group on all > active network interfaces? Do you use loopback? > > I believe this should be an extension draft because it is non- > crucial to the base protocol. If this were to be part of the base > protocol draft then as I mentioned in the previous emails there > would need to be changes made regarding Clients and Peers as well as > the references to External and Routable IP addressing. > >> >> Cullen, >> >> This method (along with LAN multicast) is VERY USEFUL. A private >> network can have a single long running node connected to the >> overlay on the public Internet. When other peers boot up, they >> only need to use broadcast or multicast to join the overlay via >> that lone "seed" node in their private network. >> >> Thanks >> >> --Michael >> >> jc wrote: >>> Cullen, >>> I've implemented multicast bootstrap and have it well defined. >>> It's not a necessity and can be removed for base simplicity. As >>> you said it can be added as an extension draft. In fact I could >>> write the extension draft for multicast bootstrap. >>> >>> Julian >>> >>> On Oct 15, 2009, at 9:07 PM, Cullen Jennings wrote: >>> >>>> >>>> I'm not aware of anyone that is using this. It's currently under- >>>> specified in the draft and I'm wondering if we should just remove >>>> it from the base draft. It could easily be added to a different >>>> extension draft. I'll take it out of the next version so people >>>> can see what this would look like but if this turns out not to be >>>> what people want, I'll add it back in if folks that want ti can >>>> send me the text to help finish it. >>>> >>>> Thanks, Cullen >>>> >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>> > From davidbryan@gmail.com Fri Oct 16 08:26:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E47D63A6985 for ; Fri, 16 Oct 2009 08:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bSKTWN2EL3a for ; Fri, 16 Oct 2009 08:26:27 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 3816E3A68EA for ; Fri, 16 Oct 2009 08:26:27 -0700 (PDT) Received: by ywh13 with SMTP id 13so2990484ywh.29 for ; Fri, 16 Oct 2009 08:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yl7j3k130IMvzuE88OyqeOpCi+tDTAnfzXJbv/vTkZM=; b=CpRYS8UtrqvJlPMeBZzgE0bMM0eXfUy59os9mjvpzITzIi1AgzPyI4C8gC2KcXeXSS 3RuUD3crbJilYywv7yqO446edRnhQqLipANYF1Jjtlc3BFwv8O4PC2Kzd/qkmEnD0q8A IPDzt6v4WxUABDXc45Zad5NM7cWzgS69krieg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=Bp8eIXsQgENLdPaQUWb+Z8MHNLQ7Kgl7bbKzfMZy78qAlrAUPQvFUZWrxsGJg6u3u2 2L4T/z2nGGtn9PbGPyW0et5TyoDW9Fsg1KOM1CtXk8Efv+Nlt4+rHTQ+FUX33s1wXWV9 S7TyaztTlZpwwRuT2Mq/uxZ+BTdoJRgvkGfso= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.27.2 with SMTP id a2mr3005117yba.107.1255706788018; Fri, 16 Oct 2009 08:26:28 -0700 (PDT) Date: Fri, 16 Oct 2009 11:26:27 -0400 X-Google-Sender-Auth: 11a0150c29687f07 Message-ID: <8b2769930910160826u4078bc20x33f25391309bd53c@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] Requests for Agenda Time X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 15:26:28 -0000 Hi all, As it looks at this point like we may have two fill-in special guest chairs for IETF-76 (looks like neither Brian nor I will make it), Brian and I want to try to get a draft agenda put together as early as possible to give those folks time to prepare. If you would like a slot on the agenda for Hiroshima, can you please let Brian and I know as soon as possible? I understand some of you may not have the draft submitted yet, but we'd like to hear from you now so we can get the substitutes up to speed. Thanks, David (as chair) From julian@orchidseed.org Fri Oct 16 09:16:46 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C09628C10F for ; Fri, 16 Oct 2009 09:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d300psTZLN86 for ; Fri, 16 Oct 2009 09:16:45 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id CDDD328C124 for ; Fri, 16 Oct 2009 09:16:40 -0700 (PDT) Received: from adsl-176-184-222.asm.bellsouth.net ([74.176.184.222]:54282 helo=[192.168.1.7]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MypTt-000210-NQ; Fri, 16 Oct 2009 09:16:43 -0700 References: <199B1982-03D7-47C0-99F3-1180A8E40CD0@cisco.com> <4AD7EBBB.6080004@idssoftware.com> <6513FC28-EA53-40A2-8C00-CDFF64D024A0@orchidseed.org> <2C79C96F-EC85-49D9-AE4D-C1ADE2C1F2FB@cisco.com> Message-Id: <7C20C19E-2A08-484D-BC72-BDDFAB388243@orchidseed.org> From: jc To: Cullen Jennings In-Reply-To: <2C79C96F-EC85-49D9-AE4D-C1ADE2C1F2FB@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7C144) Mime-Version: 1.0 (iPhone Mail 7C144) Date: Fri, 16 Oct 2009 12:16:32 -0400 X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] Usage or multicast for discover of bootstrap nodes X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 16:16:46 -0000 The first thing that needs to be changed would be all of the points that refer to public ip addressing of bootstrap nodes as a MUST. Multicast introduces a new case where Nodes MAY bootstrap off of Clients which MAY have an internal IP address. A Node MUST be able to bootstrap off any other Node regardless of it's IP addressing and public routability. Sent from my iPhone On Oct 16, 2009, at 10:44 AM, Cullen Jennings wrote: > > I did not realize you had both implemented the multicast stuff. I > think another group also did. Given it has been in the draft for a > long time, and people are implementing it, it was a mistake for me > to take it out. Lets work to figure out what needs to be specified > to make it all work and also figure out the MAYs and MUSTs. > > > On Oct 15, 2009, at 10:14 PM, jc wrote: > >> >> On Oct 15, 2009, at 11:42 PM, Michael Chen wrote: >> >>> Julian, >>> >>> We implemented UDP broadcast bootstrap as a simple way to form a >>> ring in a private network with no enrollment server (self-signed >>> cert, of course). This is specified in section 5.5.5 and 10.4 of >>> the draft. >>> >>> However, there is a small detail here. We assume the broadcast is >>> always on the Reload port number, i.e. 255.255.255.255:6084 (thus >>> no enrollment server is needed). I believe this should be >>> recommended by the draft. Adding this as an extension would seem >>> too trivial. >> >> I somewhat agree however this isn't fully defined as Cullen and I >> have pointed out. Also it seems your experiencing the same effect >> where you now use internal IP's with Bootstrap because LAN >> Multicast which as I mentioned in a previous email is forbidden by >> the draft. So either it needs to be fully removed or fully defined >> and Cullen has removed it for now. I don't believe the draft should >> define this because it's actually non-trivial. When do you join the >> multicast group? How long are you a member? Do you send unicast and >> receive unicast? What do you do if you receive a stray message of N >> type? What is the broadcast interval? Do you join a multicast group >> on all active network interfaces? Do you use loopback? >> >> I believe this should be an extension draft because it is non- >> crucial to the base protocol. If this were to be part of the base >> protocol draft then as I mentioned in the previous emails there >> would need to be changes made regarding Clients and Peers as well >> as the references to External and Routable IP addressing. >> >>> >>> Cullen, >>> >>> This method (along with LAN multicast) is VERY USEFUL. A private >>> network can have a single long running node connected to the >>> overlay on the public Internet. When other peers boot up, they >>> only need to use broadcast or multicast to join the overlay via >>> that lone "seed" node in their private network. >>> >>> Thanks >>> >>> --Michael >>> >>> jc wrote: >>>> Cullen, >>>> I've implemented multicast bootstrap and have it well defined. >>>> It's not a necessity and can be removed for base simplicity. As >>>> you said it can be added as an extension draft. In fact I could >>>> write the extension draft for multicast bootstrap. >>>> >>>> Julian >>>> >>>> On Oct 15, 2009, at 9:07 PM, Cullen Jennings wrote: >>>> >>>>> >>>>> I'm not aware of anyone that is using this. It's currently under- >>>>> specified in the draft and I'm wondering if we should just >>>>> remove it from the base draft. It could easily be added to a >>>>> different extension draft. I'll take it out of the next version >>>>> so people can see what this would look like but if this turns >>>>> out not to be what people want, I'll add it back in if folks >>>>> that want ti can send me the text to help finish it. >>>>> >>>>> Thanks, Cullen >>>>> >>>>> >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> >> > From davidbryan@gmail.com Fri Oct 16 10:58:52 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14EED3A635F for ; Fri, 16 Oct 2009 10:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFWcq3hHWtPy for ; Fri, 16 Oct 2009 10:58:51 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 400083A6833 for ; Fri, 16 Oct 2009 10:58:51 -0700 (PDT) Received: by ywh13 with SMTP id 13so3147539ywh.29 for ; Fri, 16 Oct 2009 10:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=8/kFEwxOdiGlXqLKKaxmIInfwhKXFYvmDDGsJ44YYCA=; b=E6BRf/CbxNb875M32dZwKjBfk7kyY+sTUPN9clb+pzQ/AKv678nOQCv1fhiKXMiRtv czONVRvxkdUVb6G825zqoJ7qTPoK1+iPuRtEMsmz0+84hRMmD5aHrpQcIKXLSu1ehEh+ HGKyzUMr0n7gFfPk/eT7/e7SsiJZvEACGtnzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=YWtYsw1nChmB59ueGEC1dEkxNDYv400B7tQJnMZ7QpGeQW4fuXHnecQBwH0RwSapBr twOlWjgRT96cGXshn5Vc1MEVjJfEZ+PM9aJvewB17XZ39R3i08E8Y2UA5J4y50BhsTWh pWCryyP7HgH0ycGWD2q4P9ia7qTXdfna3MqTw= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.45.36 with SMTP id s36mr3205238ybs.334.1255715931825; Fri, 16 Oct 2009 10:58:51 -0700 (PDT) Date: Fri, 16 Oct 2009 13:58:51 -0400 X-Google-Sender-Auth: 63277374391444c4 Message-ID: <8b2769930910161058n7c107d07k763e625473e91fbe@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] Update/reminders for Hiroshima X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 17:58:52 -0000 As of now, it looks like P2PSIP is scheduled for: P2PSIP Session 1 (2.5 hours) Monday, Afternoon Session II 1520-1720 Room Name: Orchid Centre Friday, October 30 is the early bird registration deadline. Monday, October 19, 2009 is the -00 submission deadline. Monday, October 26, 2009 is the submission deadline for revised drafts. Thanks, David (as Chair) From julian@orchidseed.org Fri Oct 16 11:57:06 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4AF93A696E for ; Fri, 16 Oct 2009 11:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqiykEbwH9bJ for ; Fri, 16 Oct 2009 11:57:05 -0700 (PDT) Received: from n25.c05.mtsvc.net (n25.c05.mtsvc.net [70.32.68.25]) by core3.amsl.com (Postfix) with ESMTP id B75E03A6967 for ; Fri, 16 Oct 2009 11:57:05 -0700 (PDT) Received: from adsl-176-184-222.asm.bellsouth.net ([74.176.184.222]:56617 helo=[192.168.1.3]) by n25.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MyrzB-0000gO-C9; Fri, 16 Oct 2009 11:57:09 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-1-386802694 From: jc In-Reply-To: <4AD871AC.7020203@freenet.de> Date: Fri, 16 Oct 2009 14:56:33 -0400 Message-Id: <840E0862-1AB4-4D06-840F-D069193C0C83@orchidseed.org> References: <4AD871AC.7020203@freenet.de> To: neil.young@freenet.de X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] Question about how to begin X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 18:57:06 -0000 --Apple-Mail-1-386802694 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Neil, Start with enrollment and then move on to security and then ICE. The reasoning here is that you MUST have a configuration file to setup security and you need the security implementation to implement ICE Attach. This is because of where the a Node ID is stored. You will need to implement DNS SRV in order to implement enrollment. I used c- ares for testing and then implemented DNS SRV myself. I use C++ but surely there is DNS SRV support built into .NET? If your looking for an easy to use and highly scalable STUN/TURN server that is up to date have a look at using reTurn in the resiprocate svn repository. There is also Numb STUN/TURN server however it has been obsoleted by rfc5389 and doesn't look to be worked on anymore. As a 2nd option there is the pjnath library as part of the pjsip project. You could code a C# wrapper for pjnath and use that on your client side for the ICE transports, of course you will have to implement TLS and DTLS over these yourself as TLS in pjnath is used as it should be in the context of TURN. Having said that I implemented STUN/TURN and ICE myself to remove these dependancies but did start off using pjnath(GPL) on the client for ICE and reTurn on the server side. Now I shared a common code base between p2p code and managed server code which makes things much easier to maintain. Julian On Oct 16, 2009, at 9:14 AM, neil.young wrote: > Hi, > > I recently finished the development of a CHORD implementation in C#. > I already use a proprietary binary TCP communication protocol for > the CHORD messages (findsuccessor, the notify and stabilize > routines, the ping etc.). In near future I want to proceed to > RELOAD, whereas the desired implementation does not necessarily has > to have full RELOAD characteristics as the first result. Especially > these items are not required initially, so that the first > implementation would more be a REL instead of RELOAD :) > > 1) Security > 2) NAT traversal > 3) ICE STUN support > 4) Enrollment server > > Implementors, could you give me please some suggestions, where to > start with best under these circumstances? > > Kind regards > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail-1-386802694 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

I recently finished the development of a CHORD implementation in C#. I already use a proprietary binary TCP communication protocol for the CHORD messages (findsuccessor, the notify and stabilize routines, the ping etc.). In near future I want to proceed to RELOAD, whereas the desired implementation does not necessarily has to have full RELOAD characteristics as the first result. Especially these items are not required initially, so that the first implementation would more be a REL instead of RELOAD :)

1) Security
2) NAT traversal
3) ICE STUN support
4) Enrollment server

Implementors, could you give me please some suggestions, where to start with best under these circumstances? 

Kind regards
_______________________________________________
P2PSIP mailing = list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip

= --Apple-Mail-1-386802694-- From neil.young@freenet.de Fri Oct 16 13:10:26 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE453A6882 for ; Fri, 16 Oct 2009 13:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VtEQg6odWHx for ; Fri, 16 Oct 2009 13:10:25 -0700 (PDT) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by core3.amsl.com (Postfix) with ESMTP id 1A2B43A6817 for ; Fri, 16 Oct 2009 13:10:24 -0700 (PDT) Received: from [195.4.92.27] (helo=17.mx.freenet.de) by mout1.freenet.de with esmtpa (ID roland.klabunde@freenet.de) (port 25) (Exim 4.69 #92) id 1Myt86-0000SY-KZ; Fri, 16 Oct 2009 22:10:26 +0200 Received: from p54bd97a5.dip0.t-ipconnect.de ([84.189.151.165]:51007 helo=[192.168.178.38]) by 17.mx.freenet.de with esmtpa (ID roland.klabunde@freenet.de) (port 25) (Exim 4.69 #94) id 1Myt86-0003jl-7V; Fri, 16 Oct 2009 22:10:26 +0200 Message-ID: <4AD8D332.1010608@freenet.de> Date: Fri, 16 Oct 2009 22:10:26 +0200 From: "neil.young" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: jc , p2psip WG References: <4AD871AC.7020203@freenet.de> <840E0862-1AB4-4D06-840F-D069193C0C83@orchidseed.org> In-Reply-To: <840E0862-1AB4-4D06-840F-D069193C0C83@orchidseed.org> Content-Type: multipart/alternative; boundary="------------020103030009080207020703" Subject: Re: [P2PSIP] Question about how to begin X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: neil.young@freenet.de List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 20:10:26 -0000 This is a multi-part message in MIME format. --------------020103030009080207020703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Julian, thanks for your detailed answer. At least one of it sound familiar :) I know Benny and his fin pjsip stack. We've already implemented AKA Digest Authentication together in the past... However, the project I'm involved in, is more ore less a demonstrator. It doesn't have productive aims up to now, so we are allowed to call it RELOAD but let significant parts of RELOAD aside. For instance the parts, I've outlined in my initial post. In my limited overview I always treated RELOAD as "just the standardized transport for a DHT". I think I would be happy to have at least the basic RELOAD transport w/o STUN/TURN/ICE/NAT, probably also without TLS, because all of the nodes, participating in the overlay, are in trusted environments... Having this in mind, wouldn't it be better to implement the basic RELOAD transport PDUs and means first, and let all the security and configuration overhead aside? jc schrieb: > Neil, > > Start with enrollment and then move on to security and then ICE. The > reasoning here is that you MUST have a configuration file to setup > security and you need the security implementation to implement ICE > Attach. This is because of where the a Node ID is stored. You will > need to implement DNS SRV in order to implement enrollment. I used > c-ares for testing and then implemented DNS SRV myself. I use C++ but > surely there is DNS SRV support built into .NET? > > If your looking for an easy to use and highly scalable STUN/TURN > server that is up to date have a look at using reTurn in the > resiprocate svn repository. There is also Numb STUN/TURN server > however it has been obsoleted by rfc5389 and doesn't look to be worked > on anymore. As a 2nd option there is the pjnath library as part of the > pjsip project. You could code a C# wrapper for pjnath and use that on > your client side for the ICE transports, of course you will have to > implement TLS and DTLS over these yourself as TLS in pjnath is used as > it should be in the context of TURN. > > Having said that I implemented STUN/TURN and ICE myself to remove > these dependancies but did start off using pjnath(GPL) on the client > for ICE and reTurn on the server side. Now I shared a common code base > between p2p code and managed server code which makes things much > easier to maintain. > > Julian > > On Oct 16, 2009, at 9:14 AM, neil.young wrote: > >> Hi, >> >> I recently finished the development of a CHORD implementation in C#. >> I already use a proprietary binary TCP communication protocol for the >> CHORD messages (findsuccessor, the notify and stabilize routines, the >> ping etc.). In near future I want to proceed to RELOAD, whereas the >> desired implementation does not necessarily has to have full RELOAD >> characteristics as the first result. Especially these items are not >> required initially, so that the first implementation would more be a >> REL instead of RELOAD :) >> >> 1) Security >> 2) NAT traversal >> 3) ICE STUN support >> 4) Enrollment server >> >> Implementors, could you give me please some suggestions, where to >> start with best under these circumstances? >> >> Kind regards >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > --------------020103030009080207020703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Julian,

thanks for your detailed answer. At least one of it sound familiar :) I know Benny and his fin pjsip stack. We've already implemented AKA Digest Authentication together in the past...

However, the project I'm involved in, is more ore less a demonstrator. It doesn't have productive aims up to now, so we are allowed to call it RELOAD but let significant parts of RELOAD aside. For instance the parts, I've outlined in my initial post. In my limited overview I always treated RELOAD as "just the standardized transport for a DHT". I think I would be happy to have at least the basic RELOAD transport w/o STUN/TURN/ICE/NAT, probably also without TLS, because all of the nodes, participating in the overlay, are in trusted environments...

Having this in mind, wouldn't it be better to implement the basic RELOAD transport PDUs and means first, and let all the security and configuration overhead aside?



jc schrieb:
Neil,

Start with enrollment and then move on to security and then ICE. The reasoning here is that you MUST have a configuration file to setup security and you need the security implementation to implement ICE Attach. This is because of where the a Node ID is stored. You will need to implement DNS SRV in order to implement enrollment. I used c-ares for testing and then implemented DNS SRV myself. I use C++ but surely there is DNS SRV support built into .NET?

If your looking for an easy to use and highly scalable STUN/TURN server that is up to date have a look at using reTurn in the resiprocate svn repository. There is also Numb STUN/TURN server however it has been obsoleted by rfc5389 and doesn't look to be worked on anymore. As a 2nd option there is the pjnath library as part of the pjsip project. You could code a C# wrapper for pjnath and use that on your client side for the ICE transports, of course you will have to implement TLS and DTLS over these yourself as TLS in pjnath is used as it should be in the context of TURN.

Having said that I implemented STUN/TURN and ICE myself to remove these dependancies but did start off using pjnath(GPL) on the client for ICE and reTurn on the server side. Now I shared a common code base between p2p code and managed server code which makes things much easier to maintain.

Julian

On Oct 16, 2009, at 9:14 AM, neil.young wrote:

Hi,

I recently finished the development of a CHORD implementation in C#. I already use a proprietary binary TCP communication protocol for the CHORD messages (findsuccessor, the notify and stabilize routines, the ping etc.). In near future I want to proceed to RELOAD, whereas the desired implementation does not necessarily has to have full RELOAD characteristics as the first result. Especially these items are not required initially, so that the first implementation would more be a REL instead of RELOAD :)

1) Security
2) NAT traversal
3) ICE STUN support
4) Enrollment server

Implementors, could you give me please some suggestions, where to start with best under these circumstances? 

Kind regards
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip

--------------020103030009080207020703-- From julian@orchidseed.org Fri Oct 16 14:42:33 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5A03A682B for ; Fri, 16 Oct 2009 14:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdLO3UNJcmBA for ; Fri, 16 Oct 2009 14:42:31 -0700 (PDT) Received: from n25.c05.mtsvc.net (n25.c05.mtsvc.net [70.32.68.25]) by core3.amsl.com (Postfix) with ESMTP id 987F43A65A6 for ; Fri, 16 Oct 2009 14:42:31 -0700 (PDT) Received: from adsl-176-184-222.asm.bellsouth.net ([74.176.184.222]:60231 helo=[192.168.1.3]) by n25.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MyuZG-0006e0-VN; Fri, 16 Oct 2009 14:42:35 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-1-396727059 From: jc In-Reply-To: <4AD8D332.1010608@freenet.de> Date: Fri, 16 Oct 2009 17:41:57 -0400 Message-Id: <64C73231-D454-4E25-9B6D-A2924F220ED1@orchidseed.org> References: <4AD871AC.7020203@freenet.de> <840E0862-1AB4-4D06-840F-D069193C0C83@orchidseed.org> <4AD8D332.1010608@freenet.de> To: neil.young@freenet.de X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] Question about how to begin X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 21:42:33 -0000 --Apple-Mail-1-396727059 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes I should have mentioned that one of my DHT algorithms isn't compatible with p2psip-base because of the hops system. This DHT implements Broadcast and Multicast and thus messages MAY travel well over an 8 bit hop. A broadcast reaches N where N is equal to the total number of nodes in the ring and a multicast reaches N where N is the number of nodes participating in that multicast group as subscribed via the storage system. So, again this isn't a generic transport for all DHT's. On Oct 16, 2009, at 4:10 PM, neil.young wrote: > Hi Julian, > > thanks for your detailed answer. At least one of it sound > familiar :) I know Benny and his fin pjsip stack. We've already > implemented AKA Digest Authentication together in the past... > > However, the project I'm involved in, is more ore less a > demonstrator. It doesn't have productive aims up to now, so we are > allowed to call it RELOAD but let significant parts of RELOAD aside. > For instance the parts, I've outlined in my initial post. In my > limited overview I always treated RELOAD as "just the standardized > transport for a DHT". I think I would be happy to have at least the > basic RELOAD transport w/o STUN/TURN/ICE/NAT, probably also without > TLS, because all of the nodes, participating in the overlay, are in > trusted environments... > > Having this in mind, wouldn't it be better to implement the basic > RELOAD transport PDUs and means first, and let all the security and > configuration overhead aside? > > > > jc schrieb: >> >> Neil, >> >> Start with enrollment and then move on to security and then ICE. >> The reasoning here is that you MUST have a configuration file to >> setup security and you need the security implementation to >> implement ICE Attach. This is because of where the a Node ID is >> stored. You will need to implement DNS SRV in order to implement >> enrollment. I used c-ares for testing and then implemented DNS SRV >> myself. I use C++ but surely there is DNS SRV support built >> into .NET? >> >> If your looking for an easy to use and highly scalable STUN/TURN >> server that is up to date have a look at using reTurn in the >> resiprocate svn repository. There is also Numb STUN/TURN server >> however it has been obsoleted by rfc5389 and doesn't look to be >> worked on anymore. As a 2nd option there is the pjnath library as >> part of the pjsip project. You could code a C# wrapper for pjnath >> and use that on your client side for the ICE transports, of course >> you will have to implement TLS and DTLS over these yourself as TLS >> in pjnath is used as it should be in the context of TURN. >> >> Having said that I implemented STUN/TURN and ICE myself to remove >> these dependancies but did start off using pjnath(GPL) on the >> client for ICE and reTurn on the server side. Now I shared a common >> code base between p2p code and managed server code which makes >> things much easier to maintain. >> >> Julian >> >> On Oct 16, 2009, at 9:14 AM, neil.young wrote: >> >>> Hi, >>> >>> I recently finished the development of a CHORD implementation in >>> C#. I already use a proprietary binary TCP communication protocol >>> for the CHORD messages (findsuccessor, the notify and stabilize >>> routines, the ping etc.). In near future I want to proceed to >>> RELOAD, whereas the desired implementation does not necessarily >>> has to have full RELOAD characteristics as the first result. >>> Especially these items are not required initially, so that the >>> first implementation would more be a REL instead of RELOAD :) >>> >>> 1) Security >>> 2) NAT traversal >>> 3) ICE STUN support >>> 4) Enrollment server >>> >>> Implementors, could you give me please some suggestions, where to >>> start with best under these circumstances? >>> >>> Kind regards >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> --Apple-Mail-1-396727059 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I should have mentioned that one of my DHT algorithms isn't compatible with p2psip-base because of the hops system. This DHT implements Broadcast and Multicast and thus messages MAY travel well over an 8 bit hop. A broadcast reaches N where N is equal to the total number of nodes in the ring and a multicast reaches N where N is the number of nodes participating in that multicast group as subscribed via the storage system. So, again this isn't a generic transport for all DHT's.

On Oct 16, 2009, at 4:10 PM, neil.young wrote:

Hi Julian,

thanks for your detailed answer. At least one of it sound familiar :) I know Benny and his fin pjsip stack. We've already implemented AKA Digest Authentication together in the past...

However, the project I'm involved in, is more ore less a demonstrator. It doesn't have productive aims up to now, so we are allowed to call it RELOAD but let significant parts of RELOAD aside. For instance the parts, I've outlined in my initial post. In my limited overview I always treated RELOAD as "just the standardized transport for a DHT". I think I would be happy to have at least the basic RELOAD transport w/o STUN/TURN/ICE/NAT, probably also without TLS, because all of the nodes, participating in the overlay, are in trusted environments...

Having this in mind, wouldn't it be better to implement the basic RELOAD transport PDUs and means first, and let all the security and configuration overhead aside?



jc schrieb:
Neil,

Start with enrollment and then move on to security and then ICE. The reasoning here is that you MUST have a configuration file to setup security and you need the security implementation to implement ICE Attach. This is because of where the a Node ID is stored. You will need to implement DNS SRV in order to implement enrollment. I used c-ares for testing and then implemented DNS SRV myself. I use C++ but surely there is DNS SRV support built into .NET?

If your looking for an easy to use and highly scalable STUN/TURN server that is up to date have a look at using reTurn in the resiprocate svn repository. There is also Numb STUN/TURN server however it has been obsoleted by rfc5389 and doesn't look to be worked on anymore. As a 2nd option there is the pjnath library as part of the pjsip project. You could code a C# wrapper for pjnath and use that on your client side for the ICE transports, of course you will have to implement TLS and DTLS over these yourself as TLS in pjnath is used as it should be in the context of TURN.

Having said that I implemented STUN/TURN and ICE myself to remove these dependancies but did start off using pjnath(GPL) on the client for ICE and reTurn on the server side. Now I shared a common code base between p2p code and managed server code which makes things much easier to maintain.

Julian

On Oct 16, 2009, at 9:14 AM, neil.young wrote:

Hi,

I recently finished the development of a CHORD implementation in C#. I already use a proprietary binary TCP communication protocol for the CHORD messages (findsuccessor, the notify and stabilize routines, the ping etc.). In near future I want to proceed to RELOAD, whereas the desired implementation does not necessarily has to have full RELOAD characteristics as the first result. Especially these items are not required initially, so that the first implementation would more be a REL instead of RELOAD :)

1) Security
2) NAT traversal
3) ICE STUN support
4) Enrollment server

Implementors, could you give me please some suggestions, where to start with best under these circumstances? 

Kind regards
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip


--Apple-Mail-1-396727059-- From jouni.maenpaa@ericsson.com Mon Oct 19 00:01:29 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF633A6899 for ; Mon, 19 Oct 2009 00:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZmMtQ1bWEpD for ; Mon, 19 Oct 2009 00:01:28 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 8C2643A6810 for ; Mon, 19 Oct 2009 00:01:28 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-1c-4adc0ecda7fb Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 59.BC.08816.DCE0CDA4; Mon, 19 Oct 2009 09:01:33 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 09:01:32 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 09:01:31 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D120424D8 for ; Mon, 19 Oct 2009 10:01:31 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9CC3021A22 for ; Mon, 19 Oct 2009 10:01:31 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5E84421A1F for ; Mon, 19 Oct 2009 10:01:31 +0300 (EEST) Message-ID: <4ADC0ECB.9000306@ericsson.com> Date: Mon, 19 Oct 2009 10:01:31 +0300 From: =?ISO-8859-1?Q?Jouni_M=E4enp=E4=E4?= User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: "p2psip@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 19 Oct 2009 07:01:31.0821 (UTC) FILETIME=[FCF61DD0:01CA5089] X-Brightmail-Tracker: AAAAAA== Subject: [P2PSIP] New Version Notification for draft-maenpaa-p2psip-service-discovery-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 07:01:29 -0000 Hi, We have just submitted a draft which proposes a generic service discovery mechanism for RELOAD. Abstract: REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as part of the base protocol. This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism used in OpenDHT can be applied to RELOAD overlays to provide a generic service discovery mechanism. A URL for this Internet-Draft is: http://www.ietf.org/id/draft-maenpaa-p2psip-service-discovery-00.txt Comments are welcome! Regards, Jouni Maenpaa ------------------------------- A new version of I-D, draft-maenpaa-p2psip-service-discovery-00.txt has been successfuly submitted by Jouni Maenpaa and posted to the IETF repository. Filename: draft-maenpaa-p2psip-service-discovery Revision: 00 Title: Service Discovery Usage for REsource LOcation And Discovery (RELOAD) Creation_date: 2009-10-19 WG ID: Independent Submission Number_of_pages: 13 From davidbryan@gmail.com Tue Oct 20 13:33:06 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185E33A68EA for ; Tue, 20 Oct 2009 13:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dN7iRneuTCgS for ; Tue, 20 Oct 2009 13:33:05 -0700 (PDT) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id 43DEF3A6830 for ; Tue, 20 Oct 2009 13:33:05 -0700 (PDT) Received: by gxk4 with SMTP id 4so5080262gxk.8 for ; Tue, 20 Oct 2009 13:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=tKFAErkB8AkbO/ONLgsmzRWQGpXSCdOtlmXOZwZlFP8=; b=Gi8Eqao+ex2mN7LDH+WHm3EVjnngbLpxDms6T8qzVvuU7NHBKavOuuXkGR6V+PI3DT J8iK1HQipnPMhnlWFZzLP/tgtag88ipY/hMqQ+L/O+V+A5lO7y3ETL78yY2meTh/laLV pJE8XNw/YIe9Q8YGtiQL5U9pqAu55b8aNgPvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=GDZOdLzNaVbuJz/Kp9IhmReU1pYZREj9oDdl+y8qoXzPH9oyP4+JUatALlMaV6uJJH hIawpR6Va1+XcZ7IaEOaMsTgOtmwsVYNYxUJtLR/++4nzFSpH/y66+nYoa1jEXzbJl2J 9iwZY865r04cQbrCvAMUj9RtyU3p9dSzUiUfc= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.151.92.12 with SMTP id u12mr11508138ybl.32.1256070789921; Tue, 20 Oct 2009 13:33:09 -0700 (PDT) Date: Tue, 20 Oct 2009 16:33:09 -0400 X-Google-Sender-Auth: 9c72f4175e9123ad Message-ID: <8b2769930910201333g639c54c4ied47437ca9c1b049@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] Reviews of drafts X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 20:33:06 -0000 So the authors of several drafts have approached me and asked if I can prod the group about comments and reviews. I wanted to send out an email (on their behalf and for the group as a whole) to ask people to please review the drafts. The two in particular I am thinking of/authors asked me about are the base draft (WG item), and the relay draft (ID). For the base draft, we had 4 people in Stockholm, and 4 people in San Francisco offer to do detailed reviews. As far as I know, only one of those 8 has actually completed the review. If you volunteered in either place -- can you please do a review, and share with the authors of the base draft? We have had very good feedback from a few people on specific implementation details on list (thanks!) but the authors still very much need to have the full formal reviews. There is a new version out, so please, if you volunteered, do the review in the next couple of weeks. For the relay draft, in Stockholm there was a great deal of list discussion, but no strong consent if the draft worked in the form it was in at Stockholm. The authors were disappointed specific issues only came up in the meeting, and several of the folks who objected to specific issues committed to reviewing the new draft within two weeks and providing feedback to the authors, so they would be able to address them before the actual meeting. Can those folks provide comments? Thanks, David From lin.xiao@nsn.com Wed Oct 21 00:59:20 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A48FE3A6883 for ; Wed, 21 Oct 2009 00:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqVpPun6C9q4 for ; Wed, 21 Oct 2009 00:59:19 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id E828A3A67AB for ; Wed, 21 Oct 2009 00:59:17 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9L7xLsi006779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Oct 2009 09:59:21 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9L7xGIJ010846; Wed, 21 Oct 2009 09:59:21 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:59:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 15:59:09 +0800 Message-ID: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4D7675F@CNBEEXC007.nsn-intra.net> In-Reply-To: <4125E20F-8A5A-40C2-B690-7EBBBBFBFF7B@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New versions of RELOAD and sip draft Thread-Index: AcpN/KnLp7hyBkumSeaMGJxh9QcDPwEIcAfQ From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext Cullen Jennings" X-OriginalArrivalTime: 21 Oct 2009 07:59:16.0306 (UTC) FILETIME=[62C81320:01CA5224] Cc: P2PSIP WG Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 07:59:20 -0000 Hi Cullen, Thanks for your reply. I agree that RELOAD have covered most of the functionalities of peers and clients. However, there is still a little different between clients and peers while connection is lost besides data replica. What I mean here is the Node ID.=20 Because all the peers in the overlay are connected according to a strict overlay algorithm. The position of a peer in the overlay is decided by its Node ID. If a peer lost its position (disconnected) in the overlay because of moving and NAT, but still want to work as a peer, it must change its Node ID, which means it need do the enrollment again and rejoin the overlay. =20 But, because a client can attach with an arbitrary peer. It is not necessary for a client to change its Node ID when it change its attaching peer. The most important thing here is that, this behavior make it possible for a client to keep session continuity while its attaching peer is switched.=20 Considering to deploy RELOAD in reality, stable nodes are preferred to work as peers while mobile nodes can take the advantage of the client behavior mentioned above. Sessions can be kept with high mobility, as unique Node ID is maintained by clients. I'm not sure if RELOAD has considered this distinction of client, which help clients to be attached with the ovelay as long as it can build at least one connection to the overlay. Br Xiao, Lin -----Original Message----- From: ext Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Friday, October 16, 2009 9:05 AM To: Xiao, Lin (NSN - CN/Beijing) Cc: P2PSIP WG Subject: Re: [P2PSIP] New versions of RELOAD and sip draft Thank you, few comments inline.... On Oct 10, 2009, at 2:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote: > Hi Cullen, > > I've had a quick review of these two drafts, and still not quite clear > with some Client related issues. > > I know Client is not the first-class concept in RELOAD, but as it has=20 > been involved in the RELOAD protocol, RELOAD should give full support=20 > to client anyhow, right? > > In the terminology chapter of RELOAD Base draft, the connection table=20 > is defined as: > "The set of peers to which a node is directly connected. This=20 > includes nodes with which Attach handshakes have been done but which=20 > have not sent any Updates." > although, the second sentence implies that clients are also involved=20 > in, I still suggest to replace the "peers" in the first sentence with=20 > "nodes" to make it more clear that both peers and clients can be=20 > maintained in the table. I agree. I changed this - thank you for the careful review to catch things like this. > > In my opinions, connection setup and maintenance between client and =20 > its > connected peer (responsible peer or arbitrary peer) is a key issue for > client support in RELOAD. My question is: Does a peer in RELOAD > distinguish if the connection is to a peer or to a client? Because the > reaction of the peer could be different when the connection is lost. Reload does distinguish at some level but what do you think a node =20 needs to do differently when a connection is lost if the connection =20 when to a peer or client. Clearly how data replication is handled and =20 some of the finger table stuff is handled differently but I think that =20 is covered in the draft. If you see something specific missing, let me =20 know. > > As a client could set up a connection only with an arbitrary peer. =20 > Does > this peer distinguish such connection from those it is responsible to? I don't se the need to. > Should this peer inform the client's responsible peer about the > Destination List to the client? So that it can still be accessed by > other nodes. Or should the Destination List been stored with some =20 > usage, > say SIP Usage? Yes, that is the approach to store destination lists where they are =20 needed. > If so, the SIP usage must be extended to allow a > Destination list containing more than one Node IDs. agree that it needs to allow storing multiple Node IDs but I think it =20 already does that. > In current SIP > usage draft, the SipRegistration structure only allow one address =20 > being > stored in the Destination List, as: > " Destination destination_list<0..2^16-1>;" The destination_list here is an array of Destinations so it allows =20 between 0 and 65K entries in the array. I agree the syntax for =20 specifying arrays might seem a bit weird but I think the structure is =20 what you are pointing out we need to have. > It should be replaced by: "Destination destination_list > [dest_list_length];" > to enable a longer list stored by arbitrary connected clients. > > Anyway, IMHO, RELOAD should make sure to cover all situations a client > could meet or at least clearly distinguish issues of clients, =20 > especially > for arbitrary connected ones, which are left to be solved by other > drafts. Thanks. > > > Best Regards, > Xiao, Lin > > > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On =20 > Behalf > Of ext Cullen Jennings > Sent: Wednesday, October 07, 2009 1:53 AM > To: P2PSIP WG > Subject: [P2PSIP] New versions of RELOAD and sip draft > > > I just submitted > draft-ietf-p2psip-base-04 > and > draft-ietf-p2psip-sip-02 > > These contain technical changes but do not have a lot of editorial > changes. At some point we need to go and reorganize the documents with > editorial changes. > > Cullen > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Wed Oct 21 05:58:42 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64A1E28C0E0 for ; Wed, 21 Oct 2009 05:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.582 X-Spam-Level: X-Spam-Status: No, score=-105.582 tagged_above=-999 required=5 tests=[AWL=-0.795, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NabxyBx26nn for ; Wed, 21 Oct 2009 05:58:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 23EE728C0E1 for ; Wed, 21 Oct 2009 05:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=6114; q=dns/txt; s=sjiport06001; t=1256129930; x=1257339530; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=20New=20versions=20of=20RELOAD=20and=20 sip=20draft|Date:=20Wed,=2021=20Oct=202009=2006:58:48=20- 0600|Message-Id:=20<4F8DDA23-C176-4F08-9AE4-71EA1FDAF3ED@ cisco.com>|To:=20"Xiao,=20Lin=20(NSN=20-=20CN/Beijing)" =20|Cc:=20"P2PSIP=20WG"=20|Mime-Version:=201.0=20(Apple=20Message=20framework =20v936)|Content-Transfer-Encoding:=207bit|In-Reply-To: =20<5D84FDD8D5DC8646B9F73CF1EFD1BFA4D7675F@CNBEEXC007.nsn -intra.net>|References:=20<5D84FDD8D5DC8646B9F73CF1EFD1BF A4D7675F@CNBEEXC007.nsn-intra.net>; bh=T11jY0XaTqlAArYND9Uawn2xON7NWi62IHKYu+2Dy64=; b=VxZj5VfYMguegRg/1EmZsH5X2c4osAdLcNZetWXi0Amu/pYU4ALGxTbo Qob0nkEre0i749pdRnyNf38t0+E6D4vLFuMRyt3TSK5lzL/KeSP4QVoKy zbpryltna7PcdFazMPpYPiKlRgxpp9Gx+ciIYABhHb6P+u6Hg8LiKCQzm I=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADei3kqrR7Ht/2dsb2JhbADCLJhZhDEE X-IronPort-AV: E=Sophos;i="4.44,597,1249257600"; d="scan'208";a="414319044" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 21 Oct 2009 12:58:49 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9LCwm4H002640; Wed, 21 Oct 2009 12:58:49 GMT From: Cullen Jennings To: "Xiao, Lin (NSN - CN/Beijing)" In-Reply-To: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4D7675F@CNBEEXC007.nsn-intra.net> Impp: xmpp:cullenfluffyjennings@jabber.org References: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4D7675F@CNBEEXC007.nsn-intra.net> Message-Id: <4F8DDA23-C176-4F08-9AE4-71EA1FDAF3ED@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Oct 2009 06:58:48 -0600 X-Mailer: Apple Mail (2.936) Cc: P2PSIP WG Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 12:58:42 -0000 I don't understand why you think a peer would need to change it's NodeID. On Oct 21, 2009, at 1:59 AM, Xiao, Lin (NSN - CN/Beijing) wrote: > Hi Cullen, > > Thanks for your reply. > > I agree that RELOAD have covered most of the functionalities of peers > and clients. However, there is still a little different between > clients > and peers while connection is lost besides data replica. What I mean > here is the Node ID. > > Because all the peers in the overlay are connected according to a > strict > overlay algorithm. The position of a peer in the overlay is decided by > its Node ID. If a peer lost its position (disconnected) in the overlay > because of moving and NAT, but still want to work as a peer, it must > change its Node ID, which means it need do the enrollment again and > rejoin the overlay. > > But, because a client can attach with an arbitrary peer. It is not > necessary for a client to change its Node ID when it change its > attaching peer. The most important thing here is that, this behavior > make it possible for a client to keep session continuity while its > attaching peer is switched. > > Considering to deploy RELOAD in reality, stable nodes are preferred > to > work as peers while mobile nodes can take the advantage of the client > behavior mentioned above. Sessions can be kept with high mobility, as > unique Node ID is maintained by clients. I'm not sure if RELOAD has > considered this distinction of client, which help clients to be > attached > with the ovelay as long as it can build at least one connection to the > overlay. > > Br > Xiao, Lin > > > > -----Original Message----- > From: ext Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, October 16, 2009 9:05 AM > To: Xiao, Lin (NSN - CN/Beijing) > Cc: P2PSIP WG > Subject: Re: [P2PSIP] New versions of RELOAD and sip draft > > > Thank you, few comments inline.... > > On Oct 10, 2009, at 2:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote: > >> Hi Cullen, >> >> I've had a quick review of these two drafts, and still not quite >> clear > >> with some Client related issues. >> >> I know Client is not the first-class concept in RELOAD, but as it has >> been involved in the RELOAD protocol, RELOAD should give full support >> to client anyhow, right? >> >> In the terminology chapter of RELOAD Base draft, the connection table >> is defined as: >> "The set of peers to which a node is directly connected. This >> includes nodes with which Attach handshakes have been done but which >> have not sent any Updates." >> although, the second sentence implies that clients are also involved >> in, I still suggest to replace the "peers" in the first sentence with >> "nodes" to make it more clear that both peers and clients can be >> maintained in the table. > > I agree. I changed this - thank you for the careful review to catch > things like this. > >> >> In my opinions, connection setup and maintenance between client and >> its >> connected peer (responsible peer or arbitrary peer) is a key issue >> for >> client support in RELOAD. My question is: Does a peer in RELOAD >> distinguish if the connection is to a peer or to a client? Because >> the >> reaction of the peer could be different when the connection is lost. > > Reload does distinguish at some level but what do you think a node > needs to do differently when a connection is lost if the connection > when to a peer or client. Clearly how data replication is handled and > some of the finger table stuff is handled differently but I think that > is covered in the draft. If you see something specific missing, let me > know. > >> >> As a client could set up a connection only with an arbitrary peer. >> Does >> this peer distinguish such connection from those it is responsible >> to? > I don't se the need to. > >> Should this peer inform the client's responsible peer about the >> Destination List to the client? So that it can still be accessed by >> other nodes. Or should the Destination List been stored with some >> usage, >> say SIP Usage? > > Yes, that is the approach to store destination lists where they are > needed. > >> If so, the SIP usage must be extended to allow a >> Destination list containing more than one Node IDs. > > agree that it needs to allow storing multiple Node IDs but I think it > already does that. > >> In current SIP >> usage draft, the SipRegistration structure only allow one address >> being >> stored in the Destination List, as: >> " Destination destination_list<0..2^16-1>;" > > The destination_list here is an array of Destinations so it allows > between 0 and 65K entries in the array. I agree the syntax for > specifying arrays might seem a bit weird but I think the structure is > what you are pointing out we need to have. > >> It should be replaced by: "Destination destination_list >> [dest_list_length];" >> to enable a longer list stored by arbitrary connected clients. >> >> Anyway, IMHO, RELOAD should make sure to cover all situations a >> client >> could meet or at least clearly distinguish issues of clients, >> especially >> for arbitrary connected ones, which are left to be solved by other >> drafts. Thanks. >> >> >> Best Regards, >> Xiao, Lin >> >> >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >> Behalf >> Of ext Cullen Jennings >> Sent: Wednesday, October 07, 2009 1:53 AM >> To: P2PSIP WG >> Subject: [P2PSIP] New versions of RELOAD and sip draft >> >> >> I just submitted >> draft-ietf-p2psip-base-04 >> and >> draft-ietf-p2psip-sip-02 >> >> These contain technical changes but do not have a lot of editorial >> changes. At some point we need to go and reorganize the documents >> with >> editorial changes. >> >> Cullen >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > From julian@orchidseed.org Wed Oct 21 09:40:52 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 867D03A6990 for ; Wed, 21 Oct 2009 09:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.556 X-Spam-Level: X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64qsADKu0ptk for ; Wed, 21 Oct 2009 09:40:51 -0700 (PDT) Received: from n19.c05.mtsvc.net (n19.c05.mtsvc.net [70.32.68.19]) by core3.amsl.com (Postfix) with ESMTP id 3A7273A6842 for ; Wed, 21 Oct 2009 09:40:48 -0700 (PDT) Received: from adsl-176-189-182.asm.bellsouth.net ([74.176.189.182]:55978 helo=[10.0.1.12]) by n19.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1N0eF4-0008WJ-MM; Wed, 21 Oct 2009 09:40:55 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4D7675F@CNBEEXC007.nsn-intra.net> Date: Wed, 21 Oct 2009 12:40:48 -0400 Content-Transfer-Encoding: 7bit Message-Id: <5D88B3E2-1527-491B-B0D2-C7195024802B@orchidseed.org> References: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4D7675F@CNBEEXC007.nsn-intra.net> To: "Xiao, Lin (NSN - CN/Beijing)" X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 16:40:52 -0000 The draft doesn't state that you MUST change you NodeID if you lose overlay connectivity. In fact under your given condition you would simply retain it and connect again as a Client when the network is back up. Julian On Oct 21, 2009, at 3:59 AM, Xiao, Lin (NSN - CN/Beijing) wrote: > Hi Cullen, > > Thanks for your reply. > > I agree that RELOAD have covered most of the functionalities of peers > and clients. However, there is still a little different between > clients > and peers while connection is lost besides data replica. What I mean > here is the Node ID. > > Because all the peers in the overlay are connected according to a > strict > overlay algorithm. The position of a peer in the overlay is decided by > its Node ID. If a peer lost its position (disconnected) in the overlay > because of moving and NAT, but still want to work as a peer, it must > change its Node ID, which means it need do the enrollment again and > rejoin the overlay. > > But, because a client can attach with an arbitrary peer. It is not > necessary for a client to change its Node ID when it change its > attaching peer. The most important thing here is that, this behavior > make it possible for a client to keep session continuity while its > attaching peer is switched. > > Considering to deploy RELOAD in reality, stable nodes are preferred > to > work as peers while mobile nodes can take the advantage of the client > behavior mentioned above. Sessions can be kept with high mobility, as > unique Node ID is maintained by clients. I'm not sure if RELOAD has > considered this distinction of client, which help clients to be > attached > with the ovelay as long as it can build at least one connection to the > overlay. > > Br > Xiao, Lin > > > > -----Original Message----- > From: ext Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, October 16, 2009 9:05 AM > To: Xiao, Lin (NSN - CN/Beijing) > Cc: P2PSIP WG > Subject: Re: [P2PSIP] New versions of RELOAD and sip draft > > > Thank you, few comments inline.... > > On Oct 10, 2009, at 2:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote: > >> Hi Cullen, >> >> I've had a quick review of these two drafts, and still not quite >> clear > >> with some Client related issues. >> >> I know Client is not the first-class concept in RELOAD, but as it has >> been involved in the RELOAD protocol, RELOAD should give full support >> to client anyhow, right? >> >> In the terminology chapter of RELOAD Base draft, the connection table >> is defined as: >> "The set of peers to which a node is directly connected. This >> includes nodes with which Attach handshakes have been done but which >> have not sent any Updates." >> although, the second sentence implies that clients are also involved >> in, I still suggest to replace the "peers" in the first sentence with >> "nodes" to make it more clear that both peers and clients can be >> maintained in the table. > > I agree. I changed this - thank you for the careful review to catch > things like this. > >> >> In my opinions, connection setup and maintenance between client and >> its >> connected peer (responsible peer or arbitrary peer) is a key issue >> for >> client support in RELOAD. My question is: Does a peer in RELOAD >> distinguish if the connection is to a peer or to a client? Because >> the >> reaction of the peer could be different when the connection is lost. > > Reload does distinguish at some level but what do you think a node > needs to do differently when a connection is lost if the connection > when to a peer or client. Clearly how data replication is handled and > some of the finger table stuff is handled differently but I think that > is covered in the draft. If you see something specific missing, let me > know. > >> >> As a client could set up a connection only with an arbitrary peer. >> Does >> this peer distinguish such connection from those it is responsible >> to? > I don't se the need to. > >> Should this peer inform the client's responsible peer about the >> Destination List to the client? So that it can still be accessed by >> other nodes. Or should the Destination List been stored with some >> usage, >> say SIP Usage? > > Yes, that is the approach to store destination lists where they are > needed. > >> If so, the SIP usage must be extended to allow a >> Destination list containing more than one Node IDs. > > agree that it needs to allow storing multiple Node IDs but I think it > already does that. > >> In current SIP >> usage draft, the SipRegistration structure only allow one address >> being >> stored in the Destination List, as: >> " Destination destination_list<0..2^16-1>;" > > The destination_list here is an array of Destinations so it allows > between 0 and 65K entries in the array. I agree the syntax for > specifying arrays might seem a bit weird but I think the structure is > what you are pointing out we need to have. > >> It should be replaced by: "Destination destination_list >> [dest_list_length];" >> to enable a longer list stored by arbitrary connected clients. >> >> Anyway, IMHO, RELOAD should make sure to cover all situations a >> client >> could meet or at least clearly distinguish issues of clients, >> especially >> for arbitrary connected ones, which are left to be solved by other >> drafts. Thanks. >> >> >> Best Regards, >> Xiao, Lin >> >> >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >> Behalf >> Of ext Cullen Jennings >> Sent: Wednesday, October 07, 2009 1:53 AM >> To: P2PSIP WG >> Subject: [P2PSIP] New versions of RELOAD and sip draft >> >> >> I just submitted >> draft-ietf-p2psip-base-04 >> and >> draft-ietf-p2psip-sip-02 >> >> These contain technical changes but do not have a lot of editorial >> changes. At some point we need to go and reorganize the documents >> with >> editorial changes. >> >> Cullen >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From michaelc@idssoftware.com Wed Oct 21 10:05:20 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A7B83A67FA for ; Wed, 21 Oct 2009 10:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=1.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-A0BCQ0KiZH for ; Wed, 21 Oct 2009 10:05:19 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 1AC6E3A67E3 for ; Wed, 21 Oct 2009 10:05:19 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N0eco-000438-V9; Wed, 21 Oct 2009 13:05:27 -0400 Message-ID: <4ADF40BF.6060801@idssoftware.com> Date: Wed, 21 Oct 2009 10:11:27 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Cullen Jennings References: <199B1982-03D7-47C0-99F3-1180A8E40CD0@cisco.com> <4AD7EBBB.6080004@idssoftware.com> <6513FC28-EA53-40A2-8C00-CDFF64D024A0@orchidseed.org> <2C79C96F-EC85-49D9-AE4D-C1ADE2C1F2FB@cisco.com> In-Reply-To: <2C79C96F-EC85-49D9-AE4D-C1ADE2C1F2FB@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940fad37d1608eae926a2ce7568cc32f418350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Cc: P2PSIP WG Subject: Re: [P2PSIP] Usage or multicast for discover of bootstrap nodes X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 17:05:20 -0000 Cullen, I believe bootstrap via UDP broadcast on 255.255.255.255:6084 should also be included and clarified as a "MAY." --Michael Cullen Jennings wrote: > > I did not realize you had both implemented the multicast stuff. I > think another group also did. Given it has been in the draft for a > long time, and people are implementing it, it was a mistake for me to > take it out. Lets work to figure out what needs to be specified to > make it all work and also figure out the MAYs and MUSTs. > > > On Oct 15, 2009, at 10:14 PM, jc wrote: > >> >> On Oct 15, 2009, at 11:42 PM, Michael Chen wrote: >> >>> Julian, >>> >>> We implemented UDP broadcast bootstrap as a simple way to form a >>> ring in a private network with no enrollment server (self-signed >>> cert, of course). This is specified in section 5.5.5 and 10.4 of the >>> draft. >>> >>> However, there is a small detail here. We assume the broadcast is >>> always on the Reload port number, i.e. 255.255.255.255:6084 (thus no >>> enrollment server is needed). I believe this should be recommended >>> by the draft. Adding this as an extension would seem too trivial. >> >> I somewhat agree however this isn't fully defined as Cullen and I >> have pointed out. Also it seems your experiencing the same effect >> where you now use internal IP's with Bootstrap because LAN Multicast >> which as I mentioned in a previous email is forbidden by the draft. >> So either it needs to be fully removed or fully defined and Cullen >> has removed it for now. I don't believe the draft should define this >> because it's actually non-trivial. When do you join the multicast >> group? How long are you a member? Do you send unicast and receive >> unicast? What do you do if you receive a stray message of N type? >> What is the broadcast interval? Do you join a multicast group on all >> active network interfaces? Do you use loopback? >> >> I believe this should be an extension draft because it is non-crucial >> to the base protocol. If this were to be part of the base protocol >> draft then as I mentioned in the previous emails there would need to >> be changes made regarding Clients and Peers as well as the references >> to External and Routable IP addressing. >> >>> >>> Cullen, >>> >>> This method (along with LAN multicast) is VERY USEFUL. A private >>> network can have a single long running node connected to the overlay >>> on the public Internet. When other peers boot up, they only need to >>> use broadcast or multicast to join the overlay via that lone "seed" >>> node in their private network. >>> >>> Thanks >>> >>> --Michael >>> >>> jc wrote: >>>> Cullen, >>>> I've implemented multicast bootstrap and have it well defined. It's >>>> not a necessity and can be removed for base simplicity. As you said >>>> it can be added as an extension draft. In fact I could write the >>>> extension draft for multicast bootstrap. >>>> >>>> Julian >>>> >>>> On Oct 15, 2009, at 9:07 PM, Cullen Jennings wrote: >>>> >>>>> >>>>> I'm not aware of anyone that is using this. It's currently >>>>> under-specified in the draft and I'm wondering if we should just >>>>> remove it from the base draft. It could easily be added to a >>>>> different extension draft. I'll take it out of the next version so >>>>> people can see what this would look like but if this turns out not >>>>> to be what people want, I'll add it back in if folks that want ti >>>>> can send me the text to help finish it. >>>>> >>>>> Thanks, Cullen >>>>> >>>>> >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> >> > > > From zongning@huawei.com Thu Oct 22 00:01:46 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5033A67B6 for ; Thu, 22 Oct 2009 00:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.645 X-Spam-Level: X-Spam-Status: No, score=-100.645 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rmVReDkaLw9 for ; Thu, 22 Oct 2009 00:01:45 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 0391D3A67AF for ; Thu, 22 Oct 2009 00:01:45 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRW00CA4M6VQF@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 22 Oct 2009 15:01:44 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRW007EYM6VPK@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 22 Oct 2009 15:01:43 +0800 (CST) Received: from z63316 ([10.164.12.81]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRW00MITM6VK6@szxml06-in.huawei.com> for p2psip@ietf.org; Thu, 22 Oct 2009 15:01:43 +0800 (CST) Date: Thu, 22 Oct 2009 15:01:43 +0800 From: Ning Zong In-reply-to: <004d01ca4573$2cc53e00$510ca40a@china.huawei.com> To: 'Ning Zong' , p2psip@ietf.org Message-id: <001901ca52e5$83540330$510ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcpFcjwTvdgOqCVGQueMVFzBQiroigAACoGgA1xl0UA= Subject: Re: [P2PSIP] FW: New Version Notification for draft-jiang-p2psip-relay-03 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 07:01:46 -0000 The URL for this I-D is as follow: http://www.ietf.org/id/draft-jiang-p2psip-relay-03.txt Comments are invited! BR, Ning Zong -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of Ning Zong Sent: Monday, October 05, 2009 12:21 PM To: p2psip@ietf.org Subject: [P2PSIP] FW: New Version Notification for draft-jiang-p2psip-relay-03 Hi, all, A new version of I-D "An extension to RELOAD to support Direct Response and Relay Peer routing" - draft-jiang-p2psip-relay-03 has been uploaded to IETF and attached in this message. The main modification is the new section 5 where the authors compare the cost of SRR, DRR and RPR. Comments and suggestions are welcome! Thanks. BR, Ning Zong -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Monday, October 05, 2009 12:12 PM To: zongning@huawei.com Cc: jiang.x.f@huawei.com; ron.even.tlv@gmail.com; zhangyunfei@chinamobile.com Subject: New Version Notification for draft-jiang-p2psip-relay-03 A new version of I-D, draft-jiang-p2psip-relay-03.txt has been successfuly submitted by Ning Zong and posted to the IETF repository. Filename: draft-jiang-p2psip-relay Revision: 03 Title: An extension to RELOAD to support Direct Response and Relay Peer routing Creation_date: 2009-10-03 WG ID: Independent Submission Number_of_pages: 23 Abstract: This document proposes an optional extension to RELOAD to support direct response and relay peer routing modes. RELOAD recommends symmetric recursive routing for routing messages. The new optional extensions provide a shorter route for responses reducing the overhead on intermediary peers and describe the potential cases where these extensions can be used. The IETF Secretariat. From lin.xiao@nsn.com Thu Oct 22 00:19:03 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8313A6859 for ; Thu, 22 Oct 2009 00:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqqCFnICPfBe for ; Thu, 22 Oct 2009 00:19:02 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 93C283A67D4 for ; Thu, 22 Oct 2009 00:19:01 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9M7J4Iw016112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2009 09:19:04 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9M7J20l011833; Thu, 22 Oct 2009 09:19:04 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 09:19:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 15:18:56 +0800 Message-ID: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4D76E2A@CNBEEXC007.nsn-intra.net> In-Reply-To: <5D88B3E2-1527-491B-B0D2-C7195024802B@orchidseed.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New versions of RELOAD and sip draft Thread-Index: AcpSbWSq15lstJFER/e3my0NOBznCQAem6DA From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext jc" X-OriginalArrivalTime: 22 Oct 2009 07:19:03.0721 (UTC) FILETIME=[EF2E9190:01CA52E7] Cc: P2PSIP WG Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 07:19:03 -0000 Hi, Maybe I'm wrong, but I consider peers in RELOAD are structured with a DHT algorithm, e.g., in Chord, peer with Node-ID 500 is connected with peer 400 and 600.=20 However, what will happen, if peer 500 totally lose both of the connections due to mobility and NAT, but can set up new ones with peer 100 and peer 300? IMHO, in order to keep the topology structured, if this node still want to be a peer in the overlay it should change its Node ID to, say 200, and rejoin the overlay to enable itself still reachable with the DHT algorithm. If peers in a overlay can not be connected with a strict order, the DHT algorithm for structured topology will not work anymore. Br Xiao, Lin=20 -----Original Message----- From: ext jc [mailto:julian@orchidseed.org]=20 Sent: Thursday, October 22, 2009 12:41 AM To: Xiao, Lin (NSN - CN/Beijing) Cc: ext Cullen Jennings; P2PSIP WG Subject: Re: [P2PSIP] New versions of RELOAD and sip draft The draft doesn't state that you MUST change you NodeID if you lose overlay connectivity. In fact under your given condition you would simply retain it and connect again as a Client when the network is back up. Julian On Oct 21, 2009, at 3:59 AM, Xiao, Lin (NSN - CN/Beijing) wrote: > Hi Cullen, > > Thanks for your reply. > > I agree that RELOAD have covered most of the functionalities of peers > and clients. However, there is still a little different between=20 > clients and peers while connection is lost besides data replica. What=20 > I mean here is the Node ID. > > Because all the peers in the overlay are connected according to a=20 > strict overlay algorithm. The position of a peer in the overlay is=20 > decided by its Node ID. If a peer lost its position (disconnected) in=20 > the overlay because of moving and NAT, but still want to work as a=20 > peer, it must change its Node ID, which means it need do the=20 > enrollment again and rejoin the overlay. > > But, because a client can attach with an arbitrary peer. It is not=20 > necessary for a client to change its Node ID when it change its=20 > attaching peer. The most important thing here is that, this behavior=20 > make it possible for a client to keep session continuity while its=20 > attaching peer is switched. > > Considering to deploy RELOAD in reality, stable nodes are preferred=20 > to work as peers while mobile nodes can take the advantage of the=20 > client behavior mentioned above. Sessions can be kept with high=20 > mobility, as unique Node ID is maintained by clients. I'm not sure if=20 > RELOAD has considered this distinction of client, which help clients=20 > to be attached with the ovelay as long as it can build at least one=20 > connection to the overlay. > > Br > Xiao, Lin > > > > -----Original Message----- > From: ext Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, October 16, 2009 9:05 AM > To: Xiao, Lin (NSN - CN/Beijing) > Cc: P2PSIP WG > Subject: Re: [P2PSIP] New versions of RELOAD and sip draft > > > Thank you, few comments inline.... > > On Oct 10, 2009, at 2:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote: > >> Hi Cullen, >> >> I've had a quick review of these two drafts, and still not quite=20 >> clear > >> with some Client related issues. >> >> I know Client is not the first-class concept in RELOAD, but as it has >> been involved in the RELOAD protocol, RELOAD should give full support >> to client anyhow, right? >> >> In the terminology chapter of RELOAD Base draft, the connection table >> is defined as: >> "The set of peers to which a node is directly connected. This=20 >> includes nodes with which Attach handshakes have been done but which >> have not sent any Updates." >> although, the second sentence implies that clients are also involved=20 >> in, I still suggest to replace the "peers" in the first sentence with >> "nodes" to make it more clear that both peers and clients can be=20 >> maintained in the table. > > I agree. I changed this - thank you for the careful review to catch=20 > things like this. > >> >> In my opinions, connection setup and maintenance between client and=20 >> its connected peer (responsible peer or arbitrary peer) is a key=20 >> issue for client support in RELOAD. My question is: Does a peer in=20 >> RELOAD distinguish if the connection is to a peer or to a client?=20 >> Because the reaction of the peer could be different when the=20 >> connection is lost. > > Reload does distinguish at some level but what do you think a node=20 > needs to do differently when a connection is lost if the connection=20 > when to a peer or client. Clearly how data replication is handled and=20 > some of the finger table stuff is handled differently but I think that > is covered in the draft. If you see something specific missing, let me > know. > >> >> As a client could set up a connection only with an arbitrary peer. >> Does >> this peer distinguish such connection from those it is responsible=20 >> to? > I don't se the need to. > >> Should this peer inform the client's responsible peer about the=20 >> Destination List to the client? So that it can still be accessed by=20 >> other nodes. Or should the Destination List been stored with some=20 >> usage, say SIP Usage? > > Yes, that is the approach to store destination lists where they are=20 > needed. > >> If so, the SIP usage must be extended to allow a Destination list=20 >> containing more than one Node IDs. > > agree that it needs to allow storing multiple Node IDs but I think it=20 > already does that. > >> In current SIP >> usage draft, the SipRegistration structure only allow one address=20 >> being stored in the Destination List, as: >> " Destination destination_list<0..2^16-1>;" > > The destination_list here is an array of Destinations so it allows=20 > between 0 and 65K entries in the array. I agree the syntax for=20 > specifying arrays might seem a bit weird but I think the structure is=20 > what you are pointing out we need to have. > >> It should be replaced by: "Destination destination_list >> [dest_list_length];" >> to enable a longer list stored by arbitrary connected clients. >> >> Anyway, IMHO, RELOAD should make sure to cover all situations a=20 >> client could meet or at least clearly distinguish issues of clients,=20 >> especially for arbitrary connected ones, which are left to be solved=20 >> by other drafts. Thanks. >> >> >> Best Regards, >> Xiao, Lin >> >> >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On=20 >> Behalf Of ext Cullen Jennings >> Sent: Wednesday, October 07, 2009 1:53 AM >> To: P2PSIP WG >> Subject: [P2PSIP] New versions of RELOAD and sip draft >> >> >> I just submitted >> draft-ietf-p2psip-base-04 >> and >> draft-ietf-p2psip-sip-02 >> >> These contain technical changes but do not have a lot of editorial=20 >> changes. At some point we need to go and reorganize the documents=20 >> with editorial changes. >> >> Cullen >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From Neil.Young@Freenet.de Thu Oct 22 01:41:39 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D81C3A677C for ; Thu, 22 Oct 2009 01:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngFpLS0QVo+o for ; Thu, 22 Oct 2009 01:41:38 -0700 (PDT) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by core3.amsl.com (Postfix) with ESMTP id 8DB7A3A63EC for ; Thu, 22 Oct 2009 01:41:37 -0700 (PDT) Received: from [195.4.92.16] (helo=6.mx.freenet.de) by mout0.freenet.de with esmtpa (ID roland.klabunde@freenet.de) (port 25) (Exim 4.70 #1) id 1N0tEu-0005vB-2s; Thu, 22 Oct 2009 10:41:44 +0200 Received: from [141.39.41.223] (port=1578) by 6.mx.freenet.de with esmtpsa (ID roland.klabunde@freenet.de) (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #94) id 1N0tEt-0003iy-Oy; Thu, 22 Oct 2009 10:41:44 +0200 Message-ID: <4AE01A3B.5080500@Freenet.de> Date: Thu, 22 Oct 2009 10:39:23 +0200 From: "Neil.Young" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Xiao, Lin (NSN - CN/Beijing)" References: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4D76E2A@CNBEEXC007.nsn-intra.net> In-Reply-To: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4D76E2A@CNBEEXC007.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Neil.Young@Freenet.de List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 08:41:39 -0000 500 can of course keep it's node id, regardless of whether 400 and/or 600 are there or not. Due to stabilization and by means of the successorcache the predecessor of 400 will notice the absence and bridge directly to 500 as well as 500 will skip 600 after a short time and go to 700 (in order to stay in the picture). Using notify the ring will close again. 400 and 600 may return whenever they want. Regards Xiao, Lin (NSN - CN/Beijing) schrieb: > Hi, > > Maybe I'm wrong, but I consider peers in RELOAD are structured with a > DHT algorithm, e.g., in Chord, peer with Node-ID 500 is connected with > peer 400 and 600. > > However, what will happen, if peer 500 totally lose both of the > connections due to mobility and NAT, but can set up new ones with peer > 100 and peer 300? IMHO, in order to keep the topology structured, if > this node still want to be a peer in the overlay it should change its > Node ID to, say 200, and rejoin the overlay to enable itself still > reachable with the DHT algorithm. > > If peers in a overlay can not be connected with a strict order, the DHT > algorithm for structured topology will not work anymore. > > > Br > Xiao, Lin > > -----Original Message----- > From: ext jc [mailto:julian@orchidseed.org] > Sent: Thursday, October 22, 2009 12:41 AM > To: Xiao, Lin (NSN - CN/Beijing) > Cc: ext Cullen Jennings; P2PSIP WG > Subject: Re: [P2PSIP] New versions of RELOAD and sip draft > > The draft doesn't state that you MUST change you NodeID if you lose > overlay connectivity. In fact under your given condition you would > simply retain it and connect again as a Client when the network is back > up. > > Julian > > On Oct 21, 2009, at 3:59 AM, Xiao, Lin (NSN - CN/Beijing) wrote: > > >> Hi Cullen, >> >> Thanks for your reply. >> >> I agree that RELOAD have covered most of the functionalities of peers >> > > >> and clients. However, there is still a little different between >> clients and peers while connection is lost besides data replica. What >> I mean here is the Node ID. >> >> Because all the peers in the overlay are connected according to a >> strict overlay algorithm. The position of a peer in the overlay is >> decided by its Node ID. If a peer lost its position (disconnected) in >> the overlay because of moving and NAT, but still want to work as a >> peer, it must change its Node ID, which means it need do the >> enrollment again and rejoin the overlay. >> >> But, because a client can attach with an arbitrary peer. It is not >> necessary for a client to change its Node ID when it change its >> attaching peer. The most important thing here is that, this behavior >> make it possible for a client to keep session continuity while its >> attaching peer is switched. >> >> Considering to deploy RELOAD in reality, stable nodes are preferred >> to work as peers while mobile nodes can take the advantage of the >> client behavior mentioned above. Sessions can be kept with high >> mobility, as unique Node ID is maintained by clients. I'm not sure if >> RELOAD has considered this distinction of client, which help clients >> to be attached with the ovelay as long as it can build at least one >> connection to the overlay. >> >> Br >> Xiao, Lin >> >> >> >> -----Original Message----- >> From: ext Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Friday, October 16, 2009 9:05 AM >> To: Xiao, Lin (NSN - CN/Beijing) >> Cc: P2PSIP WG >> Subject: Re: [P2PSIP] New versions of RELOAD and sip draft >> >> >> Thank you, few comments inline.... >> >> On Oct 10, 2009, at 2:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote: >> >> >>> Hi Cullen, >>> >>> I've had a quick review of these two drafts, and still not quite >>> clear >>> >>> with some Client related issues. >>> >>> I know Client is not the first-class concept in RELOAD, but as it has >>> > > >>> been involved in the RELOAD protocol, RELOAD should give full support >>> > > >>> to client anyhow, right? >>> >>> In the terminology chapter of RELOAD Base draft, the connection table >>> > > >>> is defined as: >>> "The set of peers to which a node is directly connected. This >>> includes nodes with which Attach handshakes have been done but which >>> > > >>> have not sent any Updates." >>> although, the second sentence implies that clients are also involved >>> in, I still suggest to replace the "peers" in the first sentence with >>> > > >>> "nodes" to make it more clear that both peers and clients can be >>> maintained in the table. >>> >> I agree. I changed this - thank you for the careful review to catch >> things like this. >> >> >>> In my opinions, connection setup and maintenance between client and >>> its connected peer (responsible peer or arbitrary peer) is a key >>> issue for client support in RELOAD. My question is: Does a peer in >>> RELOAD distinguish if the connection is to a peer or to a client? >>> Because the reaction of the peer could be different when the >>> connection is lost. >>> >> Reload does distinguish at some level but what do you think a node >> needs to do differently when a connection is lost if the connection >> when to a peer or client. Clearly how data replication is handled and >> some of the finger table stuff is handled differently but I think that >> > > >> is covered in the draft. If you see something specific missing, let me >> > > >> know. >> >> >>> As a client could set up a connection only with an arbitrary peer. >>> Does >>> this peer distinguish such connection from those it is responsible >>> to? >>> >> I don't se the need to. >> >> >>> Should this peer inform the client's responsible peer about the >>> Destination List to the client? So that it can still be accessed by >>> other nodes. Or should the Destination List been stored with some >>> usage, say SIP Usage? >>> >> Yes, that is the approach to store destination lists where they are >> needed. >> >> >>> If so, the SIP usage must be extended to allow a Destination list >>> containing more than one Node IDs. >>> >> agree that it needs to allow storing multiple Node IDs but I think it >> already does that. >> >> >>> In current SIP >>> usage draft, the SipRegistration structure only allow one address >>> being stored in the Destination List, as: >>> " Destination destination_list<0..2^16-1>;" >>> >> The destination_list here is an array of Destinations so it allows >> between 0 and 65K entries in the array. I agree the syntax for >> specifying arrays might seem a bit weird but I think the structure is >> what you are pointing out we need to have. >> >> >>> It should be replaced by: "Destination destination_list >>> [dest_list_length];" >>> to enable a longer list stored by arbitrary connected clients. >>> >>> Anyway, IMHO, RELOAD should make sure to cover all situations a >>> client could meet or at least clearly distinguish issues of clients, >>> especially for arbitrary connected ones, which are left to be solved >>> by other drafts. Thanks. >>> >>> >>> Best Regards, >>> Xiao, Lin >>> >>> >>> -----Original Message----- >>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >>> Behalf Of ext Cullen Jennings >>> Sent: Wednesday, October 07, 2009 1:53 AM >>> To: P2PSIP WG >>> Subject: [P2PSIP] New versions of RELOAD and sip draft >>> >>> >>> I just submitted >>> draft-ietf-p2psip-base-04 >>> and >>> draft-ietf-p2psip-sip-02 >>> >>> These contain technical changes but do not have a lot of editorial >>> changes. At some point we need to go and reorganize the documents >>> with editorial changes. >>> >>> Cullen >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From lin.xiao@nsn.com Thu Oct 22 02:45:05 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 754CE3A680B for ; Thu, 22 Oct 2009 02:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQ5KFNyTfaME for ; Thu, 22 Oct 2009 02:45:04 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 9F0963A67AB for ; Thu, 22 Oct 2009 02:45:02 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9M9iomx012493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2009 11:44:50 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9M9ih8X006498; Thu, 22 Oct 2009 11:44:49 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 11:44:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 17:44:36 +0800 Message-ID: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4D9D6A3@CNBEEXC007.nsn-intra.net> In-Reply-To: <007801ca498b$c0599aa0$1d0ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Consensus call on security draft Thread-Index: AcpHjWOSXhgivGmlQ8CXlayuFzHZlAAsgSwgACT68WAAEx3fwAAGuEswABQPLdACXAq4kA== From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext Song Haibin" , "DRAGE, Keith (Keith)" , "Roni Even" , "Eric Rescorla" , "David A. Bryan" X-OriginalArrivalTime: 22 Oct 2009 09:44:48.0969 (UTC) FILETIME=[4BC18390:01CA52FC] Cc: P2PSIP WG Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 09:45:05 -0000 Hi Haibin, Well done! I think this draft should be adopted as WG Item now, as consensus got in IETF#75. Thanks. Br Xiao, Lin=20 -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of ext Song Haibin Sent: Saturday, October 10, 2009 5:27 PM To: 'DRAGE, Keith (Keith)'; 'Roni Even'; 'Eric Rescorla'; 'David A. Bryan' Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Consensus call on security draft Hi, Just updated the document a bit with removing RFC 2119 requirement languages (no reference to RFC 2119 in this document). The link for the new version is as below: http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-security-ov ervi ew-01.txt Thanks! Haibin =20 >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On=20 >Behalf Of DRAGE, Keith (Keith) >Sent: Saturday, October 10, 2009 7:51 AM >To: Roni Even; 'Eric Rescorla'; 'David A. Bryan' >Cc: 'P2PSIP WG' >Subject: Re: [P2PSIP] Consensus call on security draft > >If I take the first two "must" usages in the document: > >"Thus, the architecture must consider this > issue in the process of both enrollment and modification of P2PSIP > resource (user) records in a P2PSIP overlay." > >"Nevertheless those > attacks must be addressed by designers of service specific protocols > such as SIP [RFC3261]." > >Are either of these statements even relevant to a document of tutorial, >i.e. educational nature, that the working group defined this to be. > >So essentially I am saying, irrespective of whether a reference to RFC=20 >2119 carries a normative nature or not, just changing the "MUST" to a=20 >"must" does not achieve the purpose you are trying to write this=20 >document for. > >The document, according to the scope defined by the working group,=20 >should be concentrating on the security issues, rather than writing=20 >statements about how the security should be addressed. > >regards > >Keith > >> -----Original Message----- >> From: Roni Even [mailto:Even.roni@huawei.com] >> Sent: Friday, October 09, 2009 9:40 PM >> To: DRAGE, Keith (Keith); 'Eric Rescorla'; 'David A. Bryan' >> Cc: 'P2PSIP WG' >> Subject: RE: [P2PSIP] Consensus call on security draft >>=20 >> Hi Keith, >> My question was about what does it mean to have words like "must",=20 >> "should" >> when you do not reference RFC 2119.=20 >> My take is that RFC 2119 defines the normative terminology and if it=20 >> does not say that the document refers to RFC 2119 >terminology than it >> does not. >> In this case there is no normative terms in a document. >> I was also confused about the text in RFC 2119 and do not understand=20 >> how is the force of the words changes based on the requirement level=20 >> of the document . >> This is why I claim that by my understanding of RFC 2119, if you do=20 >> not reference it than there is no normative text in the >document does >> not matter if it lower or upper case. Also having the document as=20 >> informational weakens any strength of text in a document >Regards Roni >> Even >>=20 >> > -----Original Message----- >> > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On=20 >> > Behalf Of DRAGE, Keith (Keith) >> > Sent: Friday, October 09, 2009 1:31 PM >> > To: Roni Even; 'Eric Rescorla'; 'David A. Bryan' >> > Cc: 'P2PSIP WG' >> > Subject: Re: [P2PSIP] Consensus call on security draft >> >=20 >> > My view is that using RFC 2119 words in a document even in >> lower case >> > is bad practice. It takes a slip of the editing pen for >> them later to >> > become uppercase. >> >=20 >> > They also raise questions on review as to whether they should have=20 >> > been upper case, at which point people promptly forget all >previous >> > decisions on the matter and make them upper case. >> >=20 >> > Moreover, evaluating such current usage will undoubtedly make the=20 >> > document become clearer. Just changing upper case to lower >> case will >> > not result in a clear informational document. >> >=20 >> > So I would support Eric in asking for a version of this >> document that >> > does not include any of the RFC 2119 language words, unless >> of course >> > there is agreement that normative material should later be >included. >> > (There are some exceptions to this, e.g. quotation from >> another RFC). >> > It appears to me that nobody is diputing that the current >> consensus is >> > that the document should be tutorial. >> >=20 >> > regards >> >=20 >> > Keith >> >=20 >> > > -----Original Message----- >> > > From: p2psip-bounces@ietf.org >> > > [mailto:p2psip-bounces@ietf.org] On Behalf Of Roni Even >> > > Sent: Thursday, October 08, 2009 6:53 PM >> > > To: 'Eric Rescorla'; 'David A. Bryan' >> > > Cc: 'P2PSIP WG' >> > > Subject: Re: [P2PSIP] Consensus call on security draft >> > > >> > > Hi Eric, >> > > About RFC 2119 language. >> > > My understanding is that since there is no reference to RFC >> > > 2119 which says that >> > > >> > > "In many standards track documents several words are used >> to signify >> > > the requirements in the specification. These words are often >> > > capitalized. This document defines these words as >> they should be >> > > interpreted in IETF documents. Authors who follow these >> > guidelines >> > > should incorporate this phrase near the beginning of their >> > > document: >> > > >> > > The key words "MUST", "MUST NOT", "REQUIRED", >> "SHALL", "SHALL >> > > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >> > > "OPTIONAL" in this document are to be interpreted >> as described >> > > in >> > > RFC 2119. >> > > >> > > Note that the force of these words is modified by the >> requirement >> > > level of the document in which they are used." >> > > >> > > >> > > My understanding is that there is no normative text in >> the document.=20 >> > > The meaning of "must" and "should" when not specified by >RFC 2119 >> > > does not make them normative. >> > > Furthermore the document will be an Informational document >> > > >> > > Roni Even >> > > >> > > > -----Original Message----- >> > > > From: p2psip-bounces@ietf.org >> [mailto:p2psip-bounces@ietf.org] On >> > > > Behalf Of Eric Rescorla >> > > > Sent: Wednesday, October 07, 2009 10:39 PM >> > > > To: David A. Bryan >> > > > Cc: P2PSIP WG >> > > > Subject: Re: [P2PSIP] Consensus call on security draft >> > > > >> > > > At Wed, 7 Oct 2009 12:30:40 -0400, David A. Bryan wrote: >> > > > > >> > > > > Eric, >> > > > > >> > > > > I don't agree this is premature in any way. >> > > > > >> > > > > We've allowed over a week on this topic. >> > > > >> > > > Well, David, since you insist: your mail asking for a >> > > consensus call >> > > > was sent at 12:25 EST on the 30th and stated: >> > > > >> > > > As the authors feel they have made the requested >> > > changes, I'd like >> > > > to >> > > > ask folks on list to confirm this consensus. Please >> > > send comments >> > > > about adoption to the list, and we'll make a call after >> > > there has >> > > > been >> > > > time to review and comment (at least a week). >> > > > >> > > > This mail declaring consensus was posted at 12:16 EST >today, so >> > > > the amount of time you have allowed, rather than being >> "at least a >> > week" >> > > > is actually just under a week, so even by the most generous=20 >> > > > interpretation of the situation, this is slightly >> premature. Given >> > > > that you did not provide any real deadline, it is quite >> premature. >> > > > >> > > > >> > > > > You never posted saying you >> > > > > were reviewing, you have made no comments on list about the=20 >> > > > > draft since Stockholm. Bruce started a thread on the previous >> > > version way >> > > > > back on July 25th, and you didn't comment. >> > > > >> > > > Because I had already made comments on the previous version >> > > during the >> > > > meeting. >> > > > >> > > > >> > > > > Are there others besides yourself (and Cullen)? If so, >> > > speak up now. >> > > > > Otherwise, we had consensus in the room and allowed a >> reasonable >> > > > > time for comments on list. >> > > > >> > > > While I agree, we had consensus in the room, this document >> > > does not in >> > > > fact live up to that consensus. I've just listened to >> the relevant >> > > > section of the WG meeting and it was quite clear that >> what the WG >> > > > hummed for was as a general tutorial/overview of security >> > > in the P2P >> > > > space. However, it was extremely clear that this >> document was to >> > > > be non-normative, as stated by Roni, Brian, and myself. >> > > Moreover, this is >> > > > confirmed by Dan's message when this document was posted: >> > > > >> > > > At IETF 75, we were given the direction to remove the >> RFC 2119 >> > > > language from >> > > > the document and move it from being a normative doc >> to a purely >> > > > informational doc. I have now started this and made >> a number of >> > > > other >> > > > changes, including most notably the name change from >> > > > "p2psip-security-requirements" to "p2psip-security-overview": >> > > > >> > > > While the 2119 language was removed, which is a start (and >> > > I realize I >> > > > focused on this over Jabber, but limited bandwidth is >a cost of >> > > > not being in the room), the document is full of normative text, >> > > albeit not >> > > > rendered in upper case. I count 23 separate instances >> of the word >> > > > "must" and "30" of the word "should". For example: >> > > > >> > > > S 5.1. >> > > > protected against attacks(such as Man-in-the-Middle). >> > > In order to >> > > > establish the identity trust association, nodes must >> > authenticate >> > > > each other with e.g. TLS and DTLS. If transport >> > > service security >> > > > is >> > > > provided, we can prevent nodes without valid identities to >> > > > participate in the overlay. This layer must provides >> > > reliable and >> > > > secure hop-by-hop transport service for the P2P >> overlay. This >> > > > alone, >> > > > though, is not enough to secure the P2P system. >> > > > >> > > > S 8.1. >> > > > The user wants available and reliable service that >> enables him >> > to >> > > > interact with other users and resources in a secure way. >> > > This means >> > > > that the P2PSIP system must provide: >> > > > >> > > > Worse yet, some of these actually contradict design >> decisions that >> > > > have already been made in RELOAD: >> > > > >> > > > S 8.2.11. >> > > > The security of P2PSIP systems must guarantee privacy of >> > > the P2PSIP >> > > > network participants. The P2PSIP security should allow >> > > the users >> > > > and >> > > > P2PSIP network entities to indicate which other >> users or P2PSIP >> > > > network entities can retrieve, modify, and delete >> data stored in >> > > > their P2PSIP resource (user) records. The owner of >a P2PSIP >> > > > resource >> > > > (user) record should be able to limit the access to his >> > > own resource >> > > > (user) records, and this feature should be enforced >> by the P2P >> > > > network. >> > > > >> > > > This is a particularly egregious case since there is no known=20 >> > > > mechanism for securely providing read-level access in a P2P=20 >> > > > storage network, which is why RELOAD assumes that data >> > > confidentiality will be >> > > > solved by encryption rather than access control. >> > > > >> > > > This material is not even remotely tutorial in nature.=20 >> Quite the >> > > > contrary, it is requirements text, regardless of the fact that=20 >> > > > it's not capitalized. In order for this document to >conform to >> > > > the consensus in Stockholm, then, all this language needs to be >> > > removed. >> > > > If the authors/WG feel it is important, it might be >> replaced with >> > > > descriptions of the security consequences of various design >> > > choices. >> > > > However, as it stands, no I don't agree that this document >> > > either is >> > > > acceptable or that it has consensus: the consensus in >Stockholm >> > > > was contingent on changes that have not been made, and the=20 >> > > > overwhelming silence on the mailing list after this >revision is >> > > > not at >> > > all the same >> > > > as consensus. >> > > > >> > > > -Ekr >> > > > _______________________________________________ >> > > > P2PSIP mailing list >> > > > P2PSIP@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/p2psip >> > > > >> > > > __________ Information from ESET NOD32 Antivirus, >> version of virus >> > > > signature database 4488 (20091007) __________ >> > > > >> > > > The message was checked by ESET NOD32 Antivirus. >> > > > >> > > > http://www.eset.com >> > > > >> > > > >> > > > >> > > > >> > > > __________ Information from ESET NOD32 Antivirus, >> version of virus >> > > > signature database 4488 (20091007) __________ >> > > > >> > > > The message was checked by ESET NOD32 Antivirus. >> > > > >> > > > http://www.eset.com >> > > > >> > > > >> > > > __________ Information from ESET NOD32 Antivirus, >> version of virus >> > > > signature database 4491 (20091008) __________ >> > > > >> > > > The message was checked by ESET NOD32 Antivirus. >> > > > >> > > > http://www.eset.com >> > > > >> > > >> > > >> > > __________ Information from ESET NOD32 Antivirus, version >> of virus >> > > signature database 4491 (20091008) __________ >> > > >> > > The message was checked by ESET NOD32 Antivirus. >> > > >> > > http://www.eset.com >> > > >> > > >> > > _______________________________________________ >> > > P2PSIP mailing list >> > > P2PSIP@ietf.org >> > > https://www.ietf.org/mailman/listinfo/p2psip >> > > >> > _______________________________________________ >> > P2PSIP mailing list >> > P2PSIP@ietf.org >> > https://www.ietf.org/mailman/listinfo/p2psip >> >=20 >> > __________ Information from ESET NOD32 Antivirus, version of virus=20 >> > signature database 4494 (20091009) __________ >> >=20 >> > The message was checked by ESET NOD32 Antivirus. >> >=20 >> > http://www.eset.com >> >=20 >> >=20 >> >=20 >> >=20 >> > __________ Information from ESET NOD32 Antivirus, version of virus=20 >> > signature database 4494 (20091009) __________ >> >=20 >> > The message was checked by ESET NOD32 Antivirus. >> >=20 >> > http://www.eset.com >> >=20 >> =20 >>=20 >> __________ Information from ESET NOD32 Antivirus, version of virus=20 >> signature database 4494 (20091009) __________ >>=20 >> The message was checked by ESET NOD32 Antivirus. >>=20 >> http://www.eset.com >> =20 >>=20 >>=20 >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From julian@orchidseed.org Thu Oct 22 16:01:56 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3E03A6911 for ; Thu, 22 Oct 2009 16:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIVR8+Kr8uW7 for ; Thu, 22 Oct 2009 16:01:55 -0700 (PDT) Received: from n19.c05.mtsvc.net (n19.c05.mtsvc.net [70.32.68.19]) by core3.amsl.com (Postfix) with ESMTP id A10503A686A for ; Thu, 22 Oct 2009 16:01:55 -0700 (PDT) Received: from adsl-176-189-182.asm.bellsouth.net ([74.176.189.182]:59195 helo=[10.0.1.12]) by n19.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1N16fV-00006Z-KR for p2psip@ietf.org; Thu, 22 Oct 2009 16:02:05 -0700 From: jc Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Thu, 22 Oct 2009 19:02:02 -0400 Message-Id: <180F7979-09C5-406E-BB92-21B07E187150@orchidseed.org> To: P2PSIP WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Subject: [P2PSIP] RELOAD - Kademlia Topology Plugin X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 23:01:56 -0000 Hi, I am converting one of my Kademlia implementations over to a topology plugin object. Would this be of interest as an extension to RELOAD as a Topology Plugin? Cheers, Julian Cain From hsinnrei@adobe.com Thu Oct 22 17:15:19 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6081A28C12D for ; Thu, 22 Oct 2009 17:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koQY8QomzdWY for ; Thu, 22 Oct 2009 17:15:18 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by core3.amsl.com (Postfix) with ESMTP id B0F5328C1A6 for ; Thu, 22 Oct 2009 17:15:17 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKSuD1n9anRqJaFCPAhnHG6f1cYLs5ZTc3@postini.com; Thu, 22 Oct 2009 17:15:28 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9N08Kao008331; Thu, 22 Oct 2009 17:08:20 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9N0FQlT018874; Thu, 22 Oct 2009 17:15:26 -0700 (PDT) Received: from nacas03.corp.adobe.com (10.8.189.121) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 22 Oct 2009 17:15:26 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Thu, 22 Oct 2009 17:15:26 -0700 From: Henry Sinnreich To: jc , P2PSIP WG Date: Thu, 22 Oct 2009 17:15:25 -0700 Thread-Topic: [P2PSIP] RELOAD - Kademlia Topology Plugin Thread-Index: AcpTbD/3ejheIpOQR+6JFe/C1zz5pQACarm0 Message-ID: In-Reply-To: <180F7979-09C5-406E-BB92-21B07E187150@orchidseed.org> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7065FCD68D8hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [P2PSIP] RELOAD - Kademlia Topology Plugin X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 00:15:19 -0000 --_000_C7065FCD68D8hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Julian, Sorry for my ignorance. >I am converting one of my Kademlia implementations over to a >topology plugin object. How much does this differ from the basic idea of P2PP? http://www.p2psip.org/drafts/draft-baset-p2psip-p2pp-01.txt BTW: The P2P SIP web site is an excellent repository http://www.p2psip.org/expiredDrafts.php Thanks, Henry On 10/22/09 6:02 PM, "jc" wrote: Hi, I am converting one of my Kademlia implementations over to a topology plugin object. Would this be of interest as an extension to RELOAD as a Topology Plugin? Cheers, Julian Cain _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --_000_C7065FCD68D8hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [P2PSIP] RELOAD - Kademlia Topology Plugin Julian,

Sorry for my ignorance.

>I am converting one of my Kademlia implementations over to a
>topology plugin object.

How much does this differ from the basic idea of P2PP?

htt= p://www.p2psip.org/drafts/draft-baset-p2psip-p2pp-01.txt

BTW: The P2P SIP web site is an excellent repository
http://www.p2psip.org/e= xpiredDrafts.php

Thanks, Henry


On 10/22/09 6:02 PM, "jc" <j= ulian@orchidseed.org> wrote:

Hi,
I am converting one of my Kademlia implementations over to a topology
plugin object. Would this be of interest as an extension to RELOAD as
a Topology Plugin?

Cheers,
Julian Cain
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.o= rg/mailman/listinfo/p2psip

--_000_C7065FCD68D8hsinnreiadobecom_-- From julian@orchidseed.org Thu Oct 22 17:37:36 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E273A68D7 for ; Thu, 22 Oct 2009 17:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtqXFWTMl+yx for ; Thu, 22 Oct 2009 17:37:36 -0700 (PDT) Received: from n25.c05.mtsvc.net (n25.c05.mtsvc.net [70.32.68.25]) by core3.amsl.com (Postfix) with ESMTP id 0F3683A68B4 for ; Thu, 22 Oct 2009 17:37:35 -0700 (PDT) Received: from adsl-176-189-182.asm.bellsouth.net ([74.176.189.182]:59590 helo=[10.0.1.12]) by n25.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1N18A4-0006h1-J7; Thu, 22 Oct 2009 17:37:46 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-1-925664731 From: jc In-Reply-To: Date: Thu, 22 Oct 2009 20:37:35 -0400 Message-Id: <2A19F517-46C6-4B51-A59F-ADA423625E39@orchidseed.org> References: To: Henry Sinnreich X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] RELOAD - Kademlia Topology Plugin X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 00:37:36 -0000 --Apple-Mail-1-925664731 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Henry, It is a topology plugin for RELOAD. draft-baset-p2psip-p2pp is like p2psip-base, no? Actually isn't draft-baset-p2psip-p2pp one of the precursors that made p2psip-base possible? Julian On Oct 22, 2009, at 8:15 PM, Henry Sinnreich wrote: > Julian, > > Sorry for my ignorance. > > >I am converting one of my Kademlia implementations over to a > >topology plugin object. > > How much does this differ from the basic idea of P2PP? > > http://www.p2psip.org/drafts/draft-baset-p2psip-p2pp-01.txt > > BTW: The P2P SIP web site is an excellent repository > http://www.p2psip.org/expiredDrafts.php > > Thanks, Henry > > > On 10/22/09 6:02 PM, "jc" wrote: > > Hi, > I am converting one of my Kademlia implementations over to a topology > plugin object. Would this be of interest as an extension to RELOAD as > a Topology Plugin? > > Cheers, > Julian Cain > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > --Apple-Mail-1-925664731 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Henry,
It is a topology plugin for RELOAD. draft-baset-p2psip-p2pp is like p2psip-base, no? Actually isn't draft-baset-p2psip-p2pp one of the precursors that made p2psip-base possible?

Julian

On Oct 22, 2009, at 8:15 PM, Henry Sinnreich wrote:

Julian,

Sorry for my ignorance.

>I am converting one of my Kademlia implementations over to a
>topology plugin object.

How much does this differ from the basic idea of P2PP?

http://www.p2psip.org/drafts/draft-baset-p2psip-p2pp-01.txt

BTW: The P2P SIP web site is an excellent repository
http://www.p2psip.org/expiredDrafts.php

Thanks, Henry


On 10/22/09 6:02 PM, "jc" <julian@orchidseed.org> wrote:

Hi,
I am converting one of my Kademlia implementations over to a topology
plugin object. Would this be of interest as an extension to RELOAD as
a Topology Plugin?

Cheers,
Julian Cain
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip


--Apple-Mail-1-925664731-- From hsinnrei@adobe.com Thu Oct 22 17:47:23 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5B328C198 for ; Thu, 22 Oct 2009 17:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jItg6kNGz4gi for ; Thu, 22 Oct 2009 17:47:22 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by core3.amsl.com (Postfix) with ESMTP id BCAEE28C14A for ; Thu, 22 Oct 2009 17:47:21 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKSuD9I7msvd7BDq94QbeQlNp13trH/1iv@postini.com; Thu, 22 Oct 2009 17:47:32 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9N0eOao011689; Thu, 22 Oct 2009 17:40:24 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9N0lSlc023630; Thu, 22 Oct 2009 17:47:30 -0700 (PDT) Received: from excas03.corp.adobe.com (10.8.189.123) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 22 Oct 2009 17:47:28 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Thu, 22 Oct 2009 17:47:25 -0700 From: Henry Sinnreich To: jc Date: Thu, 22 Oct 2009 17:47:24 -0700 Thread-Topic: [P2PSIP] RELOAD - Kademlia Topology Plugin Thread-Index: AcpTeT0TT3CTAYw+SA+mMLkoRNv8+wAASWZq Message-ID: In-Reply-To: <2A19F517-46C6-4B51-A59F-ADA423625E39@orchidseed.org> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C706674C68E2hsinnreiadobecom_" MIME-Version: 1.0 Cc: P2PSIP WG Subject: Re: [P2PSIP] RELOAD - Kademlia Topology Plugin X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 00:47:23 -0000 --_000_C706674C68E2hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 10/22/09 7:37 PM, "jc" wrote: >Actually isn't draft-baset-p2psip-p2pp one of the precursors that made p2p= sip-base possible? Maybe the authors are better qualified to comment. Henry Henry, It is a topology plugin for RELOAD. draft-baset-p2psip-p2pp is like p2psip-= base, no? Actually isn't draft-baset-p2psip-p2pp one of the precursors that= made p2psip-base possible? Julian On Oct 22, 2009, at 8:15 PM, Henry Sinnreich wrote: Julian, Sorry for my ignorance. >I am converting one of my Kademlia implementations over to a >topology plugin object. How much does this differ from the basic idea of P2PP? http://www.p2psip.org/drafts/draft-baset-p2psip-p2pp-01.txt BTW: The P2P SIP web site is an excellent repository http://www.p2psip.org/expiredDrafts.php Thanks, Henry On 10/22/09 6:02 PM, "jc" > wrote: Hi, I am converting one of my Kademlia implementations over to a topology plugin object. Would this be of interest as an extension to RELOAD as a Topology Plugin? Cheers, Julian Cain _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --_000_C706674C68E2hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [P2PSIP] RELOAD - Kademlia Topology Plugin On 10/22/09 7:37 PM, "jc" <julian@orchidseed.org> wrote:

>Actually isn't draft-baset-p2psip-p2pp one of the precursors that made = p2psip-base possible?

Maybe the authors are better qualified to comment.

Henry

Henry,
It is a topology plugin for RELOAD. draft-baset-p2psip-p2pp is like p2psip-= base, no? Actually isn't draft-baset-p2psip-p2pp one of the precursors that= made p2psip-base possible?

Julian

On Oct 22, 2009, at 8:15 PM, Henry Sinnreich wrote:

Julian,

Sorry for my ignorance.

>I am converting one of my Kademlia implementations over to a
>topology plugin object.

How much does this differ from the basic idea of P2PP?

htt= p://www.p2psip.org/drafts/draft-baset-p2psip-p2pp-01.txt

BTW: The P2P SIP web site is an excellent repository
http://www.p2psip.org/e= xpiredDrafts.php

Thanks, Henry


On 10/22/09 6:02 PM, "jc" <j= ulian@orchidseed.org <x-msg://= 6/julian@orchidseed.org> > wrote:

Hi,
I am converting one of my Kademlia implementations over to a topology
plugin object. Would this be of interest as an extension to RELOAD as
a Topology Plugin?

Cheers,
Julian Cain
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org <x-msg://6/P2PSIP@ietf.org>
https://www.ietf.o= rg/mailman/listinfo/p2psip



--_000_C706674C68E2hsinnreiadobecom_-- From fluffy@cisco.com Thu Oct 22 18:41:04 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461C53A692F for ; Thu, 22 Oct 2009 18:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHGhUQgS2Hyb for ; Thu, 22 Oct 2009 18:41:03 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 20E403A63D3 for ; Thu, 22 Oct 2009 18:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1992; q=dns/txt; s=sjiport06001; t=1256262073; x=1257471673; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=20Question=20about=20how=20to=20begin |Date:=20Thu,=2022=20Oct=202009=2019:41:11=20-0600 |Message-Id:=20|To:=20neil.young@freenet.de|Cc:=20P2PSIP=20WG=20

|Mime-Version:=201.0=20(Apple=20Message=20 framework=20v936)|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<4AD871AC.7020203@freenet.de>|References: =20<4AD871AC.7020203@freenet.de>; bh=AA70DYvVOcyT7GyihBo6U9Ael3i75oVXSS6w/ALoRz0=; b=BrMc/tAtfbmyiZiJydhhIZZIXTrkSOnAKZmQ28mmvNeoz4tPIZMckvds 33W211GwRctG+c4NDIsJjJFv9noL3jAH4eSdEq5J0H9nmm8lKFSgvre+k zlOJQL4mu9Xlf/BLf7BXRS4bWW8WWPt8FepAWnDMaox5ajgooOKiwYUQ+ 4=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA2n4EqrRN+K/2dsb2JhbADDEphBhD8E X-IronPort-AV: E=Sophos;i="4.44,608,1249257600"; d="scan'208";a="415679022" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 23 Oct 2009 01:41:13 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n9N1fCcc011450; Fri, 23 Oct 2009 01:41:12 GMT From: Cullen Jennings To: neil.young@freenet.de In-Reply-To: <4AD871AC.7020203@freenet.de> Impp: xmpp:cullenfluffyjennings@jabber.org References: <4AD871AC.7020203@freenet.de> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Oct 2009 19:41:11 -0600 X-Mailer: Apple Mail (2.936) Cc: P2PSIP WG Subject: Re: [P2PSIP] Question about how to begin X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 01:41:04 -0000 I might start with 1) get a minimal transport layer going with TCP 2) get a simple message parser going to deal with RELOAD messages 3) get AttachLite running to bring up a connection between two nodes 4) Fake out the bootstrap stuff and bring up two node where one can send a JOIN to other 5) Add in minimal chord implementation to start managing the DHT ring 6) Initially get Chord going with no finger tables, everything just routes around the edge 7) add UPDATE and finger table to ring 8) add a basic data model and get it so you can store and retrieve some data 9) Go sleep because you have probably been up for 30 hours at this point 10) get DHT so it deal with corner cases of partition, rings with 1 entry 11) do bootstrap 12) make configuration work 13) get enrollment to work 14) add the other data models 15) get rest of methods working 16) get security working 17) make sure you have several Tylenol's handy and go do ICE 18) invent really cool usage on top of it :-) On Oct 16, 2009, at 7:14 AM, neil.young wrote: > Hi, > > I recently finished the development of a CHORD implementation in C#. > I already use a proprietary binary TCP communication protocol for > the CHORD messages (findsuccessor, the notify and stabilize > routines, the ping etc.). In near future I want to proceed to > RELOAD, whereas the desired implementation does not necessarily has > to have full RELOAD characteristics as the first result. Especially > these items are not required initially, so that the first > implementation would more be a REL instead of RELOAD :) > > 1) Security > 2) NAT traversal > 3) ICE STUN support > 4) Enrollment server > > Implementors, could you give me please some suggestions, where to > start with best under these circumstances? > > Kind regards > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Thu Oct 22 18:46:39 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47653A680C for ; Thu, 22 Oct 2009 18:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.453 X-Spam-Level: X-Spam-Status: No, score=-106.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9sgZacm3PPo for ; Thu, 22 Oct 2009 18:46:38 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C96133A63D3 for ; Thu, 22 Oct 2009 18:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=226; q=dns/txt; s=sjiport06001; t=1256262409; x=1257472009; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=20Usage=20or=20multicast=20for=20discov er=20of=20bootstrap=20nodes|Date:=20Thu,=2022=20Oct=20200 9=2019:46:47=20-0600|Message-Id:=20<8FD83EFF-AFDD-4357-AA 47-F397A4C849A2@cisco.com>|To:=20Michael=20Chen=20|Cc:=20jc=20, =20P2PSIP=20WG=20|Mime-Version:=201.0=20 (Apple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4ADF40 BF.6060801@idssoftware.com>|References:=20<199B1982-03D7- 47C0-99F3-1180A8E40CD0@cisco.com>=20=20<4AD7EBBB.6080004@idss oftware.com>=20<6513FC28-EA53-40A2-8C00-CDFF64D024A0@orch idseed.org>=20<2C79C96F-EC85-49D9-AE4D-C1ADE2C1F2FB@cisco .com>=20<4ADF40BF.6060801@idssoftware.com>; bh=RMKMk517YOnfMmF9IdiXdCfNrv5hV98LcdY3/nGLufI=; b=EjCg0Wphj0lBctdsPNzYpn0ijTiTQB662S6/M4l58EwjhZ5bZtN5EZ+D odB3lm14idZHbzBWr4DsCXcmWs16iHCiPVVqisjGXzfUAiDRFeNVW4FBX UC3wNXjL2TPkFb/cpu+EwArddOxYZoEDpJ+ppP5nJMX60u1/Yuuus0nCa A=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADOo4EqrR7Ht/2dsb2JhbADDB4knCY8QglWBagQ X-IronPort-AV: E=Sophos;i="4.44,608,1249257600"; d="scan'208";a="415682183" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 23 Oct 2009 01:46:49 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9N1km1T011478; Fri, 23 Oct 2009 01:46:48 GMT From: Cullen Jennings To: Michael Chen In-Reply-To: <4ADF40BF.6060801@idssoftware.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <199B1982-03D7-47C0-99F3-1180A8E40CD0@cisco.com> <4AD7EBBB.6080004@idssoftware.com> <6513FC28-EA53-40A2-8C00-CDFF64D024A0@orchidseed.org> <2C79C96F-EC85-49D9-AE4D-C1ADE2C1F2FB@cisco.com> <4ADF40BF.6060801@idssoftware.com> Message-Id: <8FD83EFF-AFDD-4357-AA47-F397A4C849A2@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Oct 2009 19:46:47 -0600 X-Mailer: Apple Mail (2.936) Cc: P2PSIP WG Subject: Re: [P2PSIP] Usage or multicast for discover of bootstrap nodes X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 01:46:39 -0000 On Oct 21, 2009, at 11:11 AM, Michael Chen wrote: > > I believe bootstrap via UDP broadcast on 255.255.255.255:6084 should > also be included and clarified as a "MAY." Sounds good - should be in next version .... From fluffy@cisco.com Thu Oct 22 18:53:37 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054AA28C1C3 for ; Thu, 22 Oct 2009 18:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.458 X-Spam-Level: X-Spam-Status: No, score=-106.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXxn5a9Y0I2k for ; Thu, 22 Oct 2009 18:53:36 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 393A728C1B5 for ; Thu, 22 Oct 2009 18:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1002; q=dns/txt; s=sjiport03001; t=1256262826; x=1257472426; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20[P2PSIP]=20Usage=20or=20multicast=20for=20discov er=20of=20bootstrap=20nodes|Date:=20Thu,=2022=20Oct=20200 9=2019:53:24=20-0600|Message-Id:=20<6C51E35B-6324-462D-80 93-70626B292C7A@cisco.com>|To:=20jc=20|Cc:=20Michael=20Chen=20, =20P2PSIP=20WG=20|Mime-Version:=201.0=20 (Apple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<7C20C1 9E-2A08-484D-BC72-BDDFAB388243@orchidseed.org> |References:=20<199B1982-03D7-47C0-99F3-1180A8E40CD0@cisc o.com>=20=20<4AD7EBBB.6080004@idssoftware.com>=20<6513FC28-EA 53-40A2-8C00-CDFF64D024A0@orchidseed.org>=20<2C79C96F-EC8 5-49D9-AE4D-C1ADE2C1F2FB@cisco.com>=20<7C20C19E-2A08-484D -BC72-BDDFAB388243@orchidseed.org>; bh=txbQTlstm1ftbFiE1pDGBrXa5WEPV2afjS7HsUSjcek=; b=Ha/FU3d4FYGnySX5vJVKWZKn+vQW6sBWTwMII1qEluWOunpnWf5oGqiE CCuk1A+k3Gaq3hKDXTd4EG/iSmWo1J3Buf9Fup5XmoEabtH1lIecmEN74 XKA6XucCHD5q9bRnEnYoZDOX22v0OfEMGBVbGe8jzqYw0DB1WSfgFYzbW M=; Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANKp4EqrR7Ht/2dsb2JhbADDHZg8hD8E X-IronPort-AV: E=Sophos;i="4.44,609,1249257600"; d="scan'208";a="198411545" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 23 Oct 2009 01:53:42 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9N1req4016797; Fri, 23 Oct 2009 01:53:40 GMT From: Cullen Jennings To: jc In-Reply-To: <7C20C19E-2A08-484D-BC72-BDDFAB388243@orchidseed.org> Impp: xmpp:cullenfluffyjennings@jabber.org References: <199B1982-03D7-47C0-99F3-1180A8E40CD0@cisco.com> <4AD7EBBB.6080004@idssoftware.com> <6513FC28-EA53-40A2-8C00-CDFF64D024A0@orchidseed.org> <2C79C96F-EC85-49D9-AE4D-C1ADE2C1F2FB@cisco.com> <7C20C19E-2A08-484D-BC72-BDDFAB388243@orchidseed.org> Message-Id: <6C51E35B-6324-462D-8093-70626B292C7A@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Oct 2009 19:53:24 -0600 X-Mailer: Apple Mail (2.936) Cc: P2PSIP WG Subject: Re: [P2PSIP] Usage or multicast for discover of bootstrap nodes X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 01:53:37 -0000 On Oct 16, 2009, at 10:16 AM, jc wrote: > The first thing that needs to be changed would be all of the points > that refer to public ip addressing of bootstrap nodes as a MUST. I think I got most of these but there may be a few places where text still needs to be updated. > Multicast introduces a new case where Nodes MAY bootstrap off of > Clients which MAY have an internal IP address. A Node MUST be able > to bootstrap off any other Node regardless of it's IP addressing and > public routability. > > Sent from my iPhone > > On Oct 16, 2009, at 10:44 AM, Cullen Jennings > wrote: > >> >> I did not realize you had both implemented the multicast stuff. I >> think another group also did. Given it has been in the draft for a >> long time, and people are implementing it, it was a mistake for me >> to take it out. Lets work to figure out what needs to be specified >> to make it all work and also figure out the MAYs and MUSTs. From worldhocs@yahoo.com.tw Thu Oct 22 19:05:25 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D265B3A683C for ; Thu, 22 Oct 2009 19:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.996 X-Spam-Level: X-Spam-Status: No, score=0.996 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOfPMnWmERqL for ; Thu, 22 Oct 2009 19:05:25 -0700 (PDT) Received: from web72303.mail.tp2.yahoo.com (web72303.mail.tp2.yahoo.com [203.188.200.93]) by core3.amsl.com (Postfix) with SMTP id B1A9E3A67E5 for ; Thu, 22 Oct 2009 19:05:24 -0700 (PDT) Received: (qmail 55209 invoked by uid 60001); 23 Oct 2009 02:05:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.tw; s=s1024; t=1256263530; bh=akJZomJ6J0+swJIWcQOM6+7hYMxETVdcWm9ucNvaxNc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=UraLAk1jJ9oaKM50fBmEwm58YTj/2Sa/lxuV28MqdHWixYT5FyxZiI7nmMyd+G6Sqr1TjzRZUcOfptLv68AL4PPySq7VhSOhxv1KkJsAmcmjam9qH1GGnh+oogvddr2kxNfjFRhEY7Ax5XnLhJIS0xGk4bTeOQvFePwgCEOlyVU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.tw; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=r5t0ntljUL1HeKjiqavXG+5En6LY7TKZYpjjnH/2HLntIRJlmmqKekJIJRm9bneNzhPHlpWM1S9DeBe1ibCESnPndv+GfLA6E/XwtnLrjJlLaMr5qUh8pce5y3TGZrfjmWWFohuCBgbW9Qt59UQkZLc/XcVfZYronkvHdL4FvO4=; Message-ID: <944745.54325.qm@web72303.mail.tp2.yahoo.com> X-YMail-OSG: wKng70AVM1ngWWqBnXBHDoe4mRIr45YcJLFo4yc2DE1y1AS8jpY.N3JQkHyG0h1mg3W4cjgWzrndtF_QFdCwlGVEy5pNt9WfL0YNWXvRYUlIPxX5ir9eg4blXXyBYKDLGMcrnNNNU7.qKCx0qOKhs5qTyMf3O0_0BiXuh0ySepXM1OEKNqPN0vwDI615QJTJfqzuYpe__IyeZf7rp7CxNTxJfW_5fjWHG0CRMfSAU3_kkjoYoyKwhINIjVz.Zg5bBGcPMNdymaBBxzHbAPhpHB29crDIttk__58- Received: from [61.61.254.9] by web72303.mail.tp2.yahoo.com via HTTP; Fri, 23 Oct 2009 10:05:30 CST X-Mailer: YahooMailClassic/8.0.7 YahooMailWebService/0.7.361.3 Date: Fri, 23 Oct 2009 10:05:30 +0800 (CST) From: World To: p2psip@ietf.org Cc: p2psip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1007880719-1256263530=:54325" Subject: [P2PSIP] RELOAD implementation performance becnchmark X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 02:05:25 -0000 --0-1007880719-1256263530=:54325 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all, =C2=A0 We are developing the P2PSIP RELOAD protocol using modified Chord as topolo= gy algorithm.=C2=A0Now it's time=C2=A0for us to=C2=A0verify=C2=A0our perfor= mance on this implementation. Could someone conduct me how to do the perfor= mance test and which items should be verified like lookup time, join time, = etc?=C2=A0Are there any performance benchmarking for=C2=A0reference and com= parison?=C2=A0=C2=A0Hope to get your=C2=A0guidance soon. Thanks a lot in ad= vance. =C2=A0 BR, Jeffrey=0A=0A___________________________________________________ =0A =E6=82= =A8=E7=9A=84=E7=94=9F=E6=B4=BB=E5=8D=B3=E6=99=82=E9=80=9A =EF=BC=8D =E6=BA= =9D=E9=80=9A=E3=80=81=E5=A8=9B=E6=A8=82=E3=80=81=E7=94=9F=E6=B4=BB=E3=80=81= =E5=B7=A5=E4=BD=9C=E4=B8=80=E6=AC=A1=E6=90=9E=E5=AE=9A=EF=BC=81 =0A http://= messenger.yahoo.com.tw/ --0-1007880719-1256263530=:54325 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear all,
 
We are developing the P2PSIP RE= LOAD protocol using modified Chord as topology algorithm. Now it's tim= e for us to verify our performance on this implementation. C= ould someone conduct me how to do the performance test and which items shou= ld be verified like lookup time, join time, etc? Are there any perform= ance benchmarking for reference and comparison?  Hope to get= your guidance soon. Thanks a lot in adv= ance.
 
BR,
Jeffrey

___________________________________________________
= =E6=82=A8=E7=9A=84=E7=94=9F=E6=B4=BB=E5=8D=B3=E6=99=82=E9=80=9A =EF=BC=8D = =E6=BA=9D=E9=80=9A=E3=80=81=E5=A8=9B=E6=A8=82=E3=80=81=E7=94=9F=E6=B4=BB=E3= =80=81=E5=B7=A5=E4=BD=9C=E4=B8=80=E6=AC=A1=E6=90=9E=E5=AE=9A=EF=BC=81
= http://messenger.yahoo.com.tw/ --0-1007880719-1256263530=:54325-- From worldhocs@yahoo.com.tw Thu Oct 22 19:12:03 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148513A683C for ; Thu, 22 Oct 2009 19:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.996 X-Spam-Level: X-Spam-Status: No, score=0.996 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AM5CI4qKXtth for ; Thu, 22 Oct 2009 19:12:02 -0700 (PDT) Received: from web72303.mail.tp2.yahoo.com (web72303.mail.tp2.yahoo.com [203.188.200.93]) by core3.amsl.com (Postfix) with SMTP id 9EB813A67E5 for ; Thu, 22 Oct 2009 19:12:02 -0700 (PDT) Received: (qmail 55209 invoked by uid 60001); 23 Oct 2009 02:05:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.tw; s=s1024; t=1256263530; bh=akJZomJ6J0+swJIWcQOM6+7hYMxETVdcWm9ucNvaxNc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=UraLAk1jJ9oaKM50fBmEwm58YTj/2Sa/lxuV28MqdHWixYT5FyxZiI7nmMyd+G6Sqr1TjzRZUcOfptLv68AL4PPySq7VhSOhxv1KkJsAmcmjam9qH1GGnh+oogvddr2kxNfjFRhEY7Ax5XnLhJIS0xGk4bTeOQvFePwgCEOlyVU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.tw; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=r5t0ntljUL1HeKjiqavXG+5En6LY7TKZYpjjnH/2HLntIRJlmmqKekJIJRm9bneNzhPHlpWM1S9DeBe1ibCESnPndv+GfLA6E/XwtnLrjJlLaMr5qUh8pce5y3TGZrfjmWWFohuCBgbW9Qt59UQkZLc/XcVfZYronkvHdL4FvO4=; Message-ID: <944745.54325.qm@web72303.mail.tp2.yahoo.com> X-YMail-OSG: wKng70AVM1ngWWqBnXBHDoe4mRIr45YcJLFo4yc2DE1y1AS8jpY.N3JQkHyG0h1mg3W4cjgWzrndtF_QFdCwlGVEy5pNt9WfL0YNWXvRYUlIPxX5ir9eg4blXXyBYKDLGMcrnNNNU7.qKCx0qOKhs5qTyMf3O0_0BiXuh0ySepXM1OEKNqPN0vwDI615QJTJfqzuYpe__IyeZf7rp7CxNTxJfW_5fjWHG0CRMfSAU3_kkjoYoyKwhINIjVz.Zg5bBGcPMNdymaBBxzHbAPhpHB29crDIttk__58- Received: from [61.61.254.9] by web72303.mail.tp2.yahoo.com via HTTP; Fri, 23 Oct 2009 10:05:30 CST X-Mailer: YahooMailClassic/8.0.7 YahooMailWebService/0.7.361.3 Date: Fri, 23 Oct 2009 10:05:30 +0800 (CST) From: World To: p2psip@ietf.org Cc: p2psip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1007880719-1256263530=:54325" Subject: [P2PSIP] RELOAD implementation performance becnchmark X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 02:12:03 -0000 --0-1007880719-1256263530=:54325 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all, =C2=A0 We are developing the P2PSIP RELOAD protocol using modified Chord as topolo= gy algorithm.=C2=A0Now it's time=C2=A0for us to=C2=A0verify=C2=A0our perfor= mance on this implementation. Could someone conduct me how to do the perfor= mance test and which items should be verified like lookup time, join time, = etc?=C2=A0Are there any performance benchmarking for=C2=A0reference and com= parison?=C2=A0=C2=A0Hope to get your=C2=A0guidance soon. Thanks a lot in ad= vance. =C2=A0 BR, Jeffrey=0A=0A___________________________________________________ =0A =E6=82= =A8=E7=9A=84=E7=94=9F=E6=B4=BB=E5=8D=B3=E6=99=82=E9=80=9A =EF=BC=8D =E6=BA= =9D=E9=80=9A=E3=80=81=E5=A8=9B=E6=A8=82=E3=80=81=E7=94=9F=E6=B4=BB=E3=80=81= =E5=B7=A5=E4=BD=9C=E4=B8=80=E6=AC=A1=E6=90=9E=E5=AE=9A=EF=BC=81 =0A http://= messenger.yahoo.com.tw/ --0-1007880719-1256263530=:54325 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear all,
 
We are developing the P2PSIP RE= LOAD protocol using modified Chord as topology algorithm. Now it's tim= e for us to verify our performance on this implementation. C= ould someone conduct me how to do the performance test and which items shou= ld be verified like lookup time, join time, etc? Are there any perform= ance benchmarking for reference and comparison?  Hope to get= your guidance soon. Thanks a lot in adv= ance.
 
BR,
Jeffrey

___________________________________________________
= =E6=82=A8=E7=9A=84=E7=94=9F=E6=B4=BB=E5=8D=B3=E6=99=82=E9=80=9A =EF=BC=8D = =E6=BA=9D=E9=80=9A=E3=80=81=E5=A8=9B=E6=A8=82=E3=80=81=E7=94=9F=E6=B4=BB=E3= =80=81=E5=B7=A5=E4=BD=9C=E4=B8=80=E6=AC=A1=E6=90=9E=E5=AE=9A=EF=BC=81
= http://messenger.yahoo.com.tw/ --0-1007880719-1256263530=:54325-- From fluffy@cisco.com Thu Oct 22 19:13:07 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E7E3A67E5 for ; Thu, 22 Oct 2009 19:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.022 X-Spam-Level: X-Spam-Status: No, score=-103.022 tagged_above=-999 required=5 tests=[AWL=-3.304, BAYES_00=-2.599, FRT_STRONG2=1.535, J_CHICKENPOX_22=0.6, J_CHICKENPOX_47=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R+Suyr+4AbE for ; Thu, 22 Oct 2009 19:13:06 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 12DBC3A689B for ; Thu, 22 Oct 2009 19:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1889; q=dns/txt; s=sjiport02001; t=1256263996; x=1257473596; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Cullen=20Jennings=20|Subject: =20Re:=20some=20questions=20about=20security=20issues=20i n=20RELOAD=20v04=20draft|Date:=20Thu,=2022=20Oct=202009 =2020:13:10=20-0600|Message-Id:=20<470741FE-AAD3-4643-9B4 F-F2207250224C@cisco.com>|To:=20=3D?GB2312?B?y++z586w?=3D =20|Cc:=20p2psip@ietf.org|Mime-Version: =201.0=20(Apple=20Message=20framework=20v936) |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20|References:=20; bh=b0Mnp4qs6G3kaKObjb9xf8k95QRtR99v8gx9lfcfQ/U=; b=scK9UTP2WGwQuqxi0rPWpIiKAJf4SljUVN8XjEsoTJ15Z4fGZsceMMgy nU+AyUIPLfzIDUn5Y6g9/h+eE7MTv6U6tyiVUZ21q5eKghrDPw5gbcRue wvWrywZMWTXEY3XqEoQbifvcZTxrshVCpnoH7eXRR9hddPln2/ZmLwcle w=; Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEAM6t4EqrR7Hu/2dsb2JhbACEcpUPqHuHCwiRK4EugjpXBII6 X-IronPort-AV: E=Sophos;i="4.44,609,1249257600"; d="scan'208";a="217174779" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 23 Oct 2009 02:13:11 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9N2DA7E008572; Fri, 23 Oct 2009 02:13:11 GMT From: Cullen Jennings To: =?GB2312?B?y++z586w?= In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: Message-Id: <470741FE-AAD3-4643-9B4F-F2207250224C@cisco.com> Content-Type: text/plain; charset=GB2312; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Oct 2009 20:13:10 -0600 X-Mailer: Apple Mail (2.936) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] some questions about security issues in RELOAD v04 draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 02:13:07 -0000 On Oct 15, 2009, at 8:34 PM, =CB=EF=B3=E7=CE=B0 wrote: > hi Cullen and everyone else > I review the secutiry part in the draft and have some questions > 1. In the last paragraph of 1.3=A3=AC > =A1=B0In order to form a TLS connection to any node in the overlay=A3=AC= a new =20 > node needs to know the shared overlay key=A1=AD.=A1=B1 > Does that mean when a node join into the overlay network, the key =20 > management entity should send the shared key to it?Is the procedure =20= > mandatory=A3=BF > I tried to update the text in the draft so this is not so confusing. =20 There are basically two modes major deployment models. In one model, =20 you use certificates signed by the Certificate server that you gt =20 during enrollment and don't use a shared secret. In the other mode, =20 you use a shared secret that everyone find out though some out of band =20= method, and you use self signed certificates. The second mode is not =20 as secure but it would meet the needs of many small ad-hoc formed =20 overlays. > 2. The third paragraph in 12.3 > =A1=B0Each certificate enable an entity to act in two sorts of roles=A3=BA= > As a user,stroing data at specific Resource-IDs=A1=AD > As a overlay peer with the peer the ID(s)=A1=AD=A1=B1 > So =A3=ACcan I comprehend these like=A3=BA The first role is = authorizing a =20 > user to store data =A3=ACand the second role is helping other peers to = =20 > authenticating the certificate owner itself=A3=BF Yes on the first role. On the second role, I think of it more as is =20 authorizing the node to insert itself into the DHT routing fabric at a =20= particular location and to route the messages that end up going =20 through that portion of the overlay. > > thank you! > > > Sun Chongwei > Mobile Life and New Media Lab > Beijing University of Posts and Telecommunications From neil.young@freenet.de Thu Oct 22 23:56:11 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E05A3A69A3 for ; Thu, 22 Oct 2009 23:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxUZAZCZ0iRi for ; Thu, 22 Oct 2009 23:56:10 -0700 (PDT) Received: from mout4.freenet.de (mout4.freenet.de [IPv6:2001:748:100:40::2:6]) by core3.amsl.com (Postfix) with ESMTP id CA0963A6978 for ; Thu, 22 Oct 2009 23:56:09 -0700 (PDT) Received: from [195.4.92.11] (helo=1.mx.freenet.de) by mout4.freenet.de with esmtpa (ID roland.klabunde@freenet.de) (port 25) (Exim 4.69 #92) id 1N1E4Q-0007l2-2x; Fri, 23 Oct 2009 08:56:18 +0200 Received: from p54bd9df3.dip0.t-ipconnect.de ([84.189.157.243]:50811 helo=[192.168.178.38]) by 1.mx.freenet.de with esmtpa (ID roland.klabunde@freenet.de) (port 25) (Exim 4.69 #94) id 1N1E4P-0000dk-Mg; Fri, 23 Oct 2009 08:56:18 +0200 Message-ID: <4AE15388.8080600@freenet.de> Date: Fri, 23 Oct 2009 08:56:08 +0200 From: "neil.young" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Cullen Jennings References: <4AD871AC.7020203@freenet.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060604020602000209080900" Cc: P2PSIP WG Subject: Re: [P2PSIP] Question about how to begin X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: neil.young@freenet.de List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 06:56:11 -0000 This is a multi-part message in MIME format. --------------060604020602000209080900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Cullen, thanks for your comment. Actually I tend to proceed with 9), because I already have that CHORD stuff completely, including data storage and retrieval, finger stuff and so on :). However, your step by step guide does watch the RELOAD path, which I totally left aside up to know. One reason: It seems to be rather instable right now; instable in the sense of "it is constantly changing". I already had made bad experiences with following a draft a couple of years ago. It was the AODV draft from the MANET group. So I don't want to spent too much time into things, which are changing quite often. Thanks for the steps. I'll watch that. Regards Cullen Jennings schrieb: > > I might start with > > 1) get a minimal transport layer going with TCP > 2) get a simple message parser going to deal with RELOAD messages > 3) get AttachLite running to bring up a connection between two nodes > 4) Fake out the bootstrap stuff and bring up two node where one can > send a JOIN to other > 5) Add in minimal chord implementation to start managing the DHT ring > 6) Initially get Chord going with no finger tables, everything just > routes around the edge > 7) add UPDATE and finger table to ring > 8) add a basic data model and get it so you can store and retrieve > some data > 9) Go sleep because you have probably been up for 30 hours at this point > 10) get DHT so it deal with corner cases of partition, rings with 1 entry > 11) do bootstrap > 12) make configuration work > 13) get enrollment to work > 14) add the other data models > 15) get rest of methods working > 16) get security working > 17) make sure you have several Tylenol's handy and go do ICE > 18) invent really cool usage on top of it :-) > > On Oct 16, 2009, at 7:14 AM, neil.young wrote: > >> Hi, >> >> I recently finished the development of a CHORD implementation in C#. >> I already use a proprietary binary TCP communication protocol for the >> CHORD messages (findsuccessor, the notify and stabilize routines, the >> ping etc.). In near future I want to proceed to RELOAD, whereas the >> desired implementation does not necessarily has to have full RELOAD >> characteristics as the first result. Especially these items are not >> required initially, so that the first implementation would more be a >> REL instead of RELOAD :) >> >> 1) Security >> 2) NAT traversal >> 3) ICE STUN support >> 4) Enrollment server >> >> Implementors, could you give me please some suggestions, where to >> start with best under these circumstances? >> >> Kind regards >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > --------------060604020602000209080900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Cullen,

thanks for your comment. Actually I tend to proceed with 9), because I already have that CHORD stuff completely, including data storage and retrieval, finger stuff and so on :). However, your step by step guide does watch the RELOAD path, which I totally left aside up to know. One reason: It seems to be rather instable right now; instable in the sense of "it is constantly changing". I already had made bad experiences with following a draft a couple of years ago. It was the AODV draft from the MANET group. So I don't want to spent too much time into things, which are changing quite often.

Thanks for the steps. I'll watch that.

Regards


Cullen Jennings schrieb:


I might start with

1) get a minimal transport layer going with TCP
2) get a simple message parser going to deal with RELOAD messages
3) get AttachLite running to bring up a connection between two nodes
4) Fake out the bootstrap stuff and bring up  two node where one can send a JOIN to other
5) Add in minimal chord implementation to start managing the DHT ring
6) Initially get Chord going with no finger tables, everything just routes around the edge
7) add UPDATE and finger table to ring
8) add a basic data model and get it so you can store and retrieve some data
9) Go sleep because you have probably been up for 30 hours at this point
10) get DHT so it deal with corner cases of partition, rings with 1 entry
11) do bootstrap
12) make configuration work
13) get enrollment to work
14) add the other data models
15) get rest of methods working
16) get security working
17) make sure you have several Tylenol's handy and go do ICE
18) invent really cool usage on top of it :-)

On Oct 16, 2009, at 7:14 AM, neil.young wrote:

Hi,

I recently finished the development of a CHORD implementation in C#. I already use a proprietary binary TCP communication protocol for the CHORD messages (findsuccessor, the notify and stabilize routines, the ping etc.). In near future I want to proceed to RELOAD, whereas the desired implementation does not necessarily has to have full RELOAD characteristics as the first result. Especially these items are not required initially, so that the first implementation would more be a REL instead of RELOAD :)

1) Security
2) NAT traversal
3) ICE STUN support
4) Enrollment server

Implementors, could you give me please some suggestions, where to start with best under these circumstances?

Kind regards

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

--------------060604020602000209080900-- From root@core3.amsl.com Fri Oct 23 11:15:01 2009 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EBAC13A6963; Fri, 23 Oct 2009 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091023181501.EBAC13A6963@core3.amsl.com> Date: Fri, 23 Oct 2009 11:15:01 -0700 (PDT) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-sip-03.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 18:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : A SIP Usage for RELOAD Author(s) : C. Jennings, et al. Filename : draft-ietf-p2psip-sip-03.txt Pages : 13 Date : 2009-10-23 This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD), The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system. The SIP Usage provides lookup service for AoRs stored in the overlay. The SIP Usage also defines GRUUs that allow the registrations to map an AoR to a specific node reachable through the overlay. The AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-sip-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-p2psip-sip-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23110920.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Oct 23 11:15:02 2009 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EE70C3A6965; Fri, 23 Oct 2009 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091023181501.EE70C3A6965@core3.amsl.com> Date: Fri, 23 Oct 2009 11:15:01 -0700 (PDT) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-base-05.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 18:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : REsource LOcation And Discovery (RELOAD) Base Protocol Author(s) : C. Jennings, et al. Filename : draft-ietf-p2psip-base-05.txt Pages : 149 Date : 2009-10-23 In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC 3979 respectively. They refer only to those RFCs and not to any documents that update or supersede them. This document defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-p2psip-base-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23110930.I-D@ietf.org> --NextPart-- From fluffy@cisco.com Fri Oct 23 11:38:30 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011683A697A for ; Fri, 23 Oct 2009 11:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.356 X-Spam-Level: X-Spam-Status: No, score=-106.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF2YWGSXJnfv for ; Fri, 23 Oct 2009 11:38:29 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 495883A6856 for ; Fri, 23 Oct 2009 11:38:29 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF6V4UqrR7Hu/2dsb2JhbADBfpg2hD8E X-IronPort-AV: E=Sophos;i="4.44,613,1249257600"; d="scan'208";a="198599384" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 23 Oct 2009 18:38:41 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9NIcdob011708 for ; Fri, 23 Oct 2009 18:38:39 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Fri, 23 Oct 2009 12:38:38 -0600 Message-Id: <0DB0BFAA-73E4-4449-A37A-D2FD847A9AF6@cisco.com> To: P2PSIP WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [P2PSIP] New version of draft-ietf-p2psip-base X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 18:38:30 -0000 We just submitted a new version of the base draft at http://www.ietf.org/id/draft-ietf-p2psip-base-05.txt (there is a new version of the sip-usage as well). The major changes are mostly a very long and excruciating editorial pass to try and improve the grammar. At this point, I don't know of any significant issues that need to be resolved. I think the draft is ready for WGLC. I'm sure that during WGLC some major issues will come up, some important decisions will be made about what needs to be mandatory and such, and we will find several small inconsistencies and typos in the draft as well as things that need a clearer explanation. This will take some time and I expect multiple more revisions for this draft before it is published, however, I do think this is the right time to start WGLC. Lets get the issues on the table and then we can start resolving them. Thanks, Cullen From br@brianrosen.net Fri Oct 23 11:54:53 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24CBB28C0D9 for ; Fri, 23 Oct 2009 11:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrplVZ90+KyO for ; Fri, 23 Oct 2009 11:54:52 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 5B7C628C0D7 for ; Fri, 23 Oct 2009 11:54:52 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.216]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N1PHp-0002hK-8Y; Fri, 23 Oct 2009 13:54:53 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 23 Oct 2009 14:54:57 -0400 From: Brian Rosen To: Cullen Jennings , P2PSIP WG Message-ID: Thread-Topic: [P2PSIP] New version of draft-ietf-p2psip-base Thread-Index: AcpUElB92v/1J7wttEODiqIyeRzsMw== In-Reply-To: <0DB0BFAA-73E4-4449-A37A-D2FD847A9AF6@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 18:54:53 -0000 If you think the draft is missing something big, or has some other serious shortcoming that makes it inappropriate to hold a WGLC, please speak up now. We'll give everyone a few days to look over this version, and then decide if we will start it. If you had signed up to review NOW would be the time to do it, on this version. That was NOW, and not "soon", please. Brian On 10/23/09 2:38 PM, "Cullen Jennings" wrote: > > We just submitted a new version of the base draft at > > http://www.ietf.org/id/draft-ietf-p2psip-base-05.txt > > (there is a new version of the sip-usage as well). > > The major changes are mostly a very long and excruciating editorial > pass to try and improve the grammar. > > At this point, I don't know of any significant issues that need to be > resolved. I think the draft is ready for WGLC. > > I'm sure that during WGLC some major issues will come up, some > important decisions will be made about what needs to be mandatory and > such, and we will find several small inconsistencies and typos in the > draft as well as things that need a clearer explanation. This will > take some time and I expect multiple more revisions for this draft > before it is published, however, I do think this is the right time to > start WGLC. Lets get the issues on the table and then we can start > resolving them. > > Thanks, > Cullen > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From stas@khirman.com Fri Oct 23 12:48:04 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9E73A6965 for ; Fri, 23 Oct 2009 12:48:04 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "To" X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5Zl2bwKaQDs for ; Fri, 23 Oct 2009 12:48:03 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 5A17C3A682F for ; Fri, 23 Oct 2009 12:48:03 -0700 (PDT) Received: from pustefix134.perfora.net (pustefix134.perfora.net [172.19.56.138]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MVNsE-1MiHzk2U4U-00YDOx; Fri, 23 Oct 2009 15:48:08 -0400 Message-Id: <23908826.230221256327270539.JavaMail.servlet@perfora> From: stas@khirman.com To: To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 X-Binford: 6100 (more power) X-Mailer: Webmail X-Originating-From: 32254776 X-Routing: US X-Message-Id: <32254776$1256327270482172.19.56.1385242934@pustefix134.perfora.net--1977508735> X-Received: from pustefix134.perfora.net by 79.183.10.39 with HTTP id 32254776 for [lin.xiao@nsn.com, Neil.Young@Freenet.de]; Fri, 23 Oct 2009 21:47:50 CEST Date: Fri, 23 Oct 2009 15:47:50 -0400 X-Provags-ID: V01U2FsdGVkX19E6gO70iad0PL3ApYFBo3CrSlf5j5/j9oFFk0 ZCzJZgaXxGA8Jaa9NUyoMBnPTI/9Lursb1FRm1Nkco9/bWBNxP J5P1cc71eI= Cc: p2psip@ietf.org Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 19:48:04 -0000 IMHO Lin Xiao has a quite valid point. If due changes of topology, node 500 permanently loose its ability to interconnect with close ( in DHT space) nodes, it has to be excluded from DHT ring or have to get a new ID. Otherwise, it will became a permanent dead-end node for lookups for targets in its immediate neighborhood that significantly degrades speed of DHT lookup and ( under some conditions) can event result in DHT space segmentation. >500 can of course keep it's node id, regardless of whether 400 and/or >600 are there or not. Due to stabilization and by means of the >successorcache the predecessor of 400 will notice the absence and bridge >directly to 500 as well as 500 will skip 600 after a short time and go >to 700 (in order to stay in the picture). Using notify the ring will >close again. 400 and 600 may return whenever they want. > >Regards > > >Xiao, Lin (NSN - CN/Beijing) schrieb: >> Hi, >> >> Maybe I'm wrong, but I consider peers in RELOAD are structured with a >> DHT algorithm, e.g., in Chord, peer with Node-ID 500 is connected with >> peer 400 and 600. >> >> However, what will happen, if peer 500 totally lose both of the >> connections due to mobility and NAT, but can set up new ones with peer >> 100 and peer 300? IMHO, in order to keep the topology structured, if >> this node still want to be a peer in the overlay it should change its >> Node ID to, say 200, and rejoin the overlay to enable itself still >> reachable with the DHT algorithm. >> >> If peers in a overlay can not be connected with a strict order, the DHT >> algorithm for structured topology will not work anymore. >> >> >> Br >> Xiao, Lin >> >> -----Original Message----- >> From: ext jc [mailto:julian@orchidseed.org] >> Sent: Thursday, October 22, 2009 12:41 AM >> To: Xiao, Lin (NSN - CN/Beijing) >> Cc: ext Cullen Jennings; P2PSIP WG >> Subject: Re: [P2PSIP] New versions of RELOAD and sip draft >> >> The draft doesn't state that you MUST change you NodeID if you lose >> overlay connectivity. In fact under your given condition you would >> simply retain it and connect again as a Client when the network is back >> up. >> >> Julian >> >> On Oct 21, 2009, at 3:59 AM, Xiao, Lin (NSN - CN/Beijing) wrote: >> >> >>> Hi Cullen, >>> >>> Thanks for your reply. >>> >>> I agree that RELOAD have covered most of the functionalities of peers >>> >> >> >>> and clients. However, there is still a little different between >>> clients and peers while connection is lost besides data replica. What >>> I mean here is the Node ID. >>> >>> Because all the peers in the overlay are connected according to a >>> strict overlay algorithm. The position of a peer in the overlay is >>> decided by its Node ID. If a peer lost its position (disconnected) in >>> the overlay because of moving and NAT, but still want to work as a >>> peer, it must change its Node ID, which means it need do the >>> enrollment again and rejoin the overlay. >>> >>> But, because a client can attach with an arbitrary peer. It is not >>> necessary for a client to change its Node ID when it change its >>> attaching peer. The most important thing here is that, this behavior >>> make it possible for a client to keep session continuity while its >>> attaching peer is switched. >>> >>> Considering to deploy RELOAD in reality, stable nodes are preferred >>> to work as peers while mobile nodes can take the advantage of the >>> client behavior mentioned above. Sessions can be kept with high >>> mobility, as unique Node ID is maintained by clients. I'm not sure if >>> RELOAD has considered this distinction of client, which help clients >>> to be attached with the ovelay as long as it can build at least one >>> connection to the overlay. >>> >>> Br >>> Xiao, Lin >>> >>> >>> >>> -----Original Message----- >>> From: ext Cullen Jennings [mailto:fluffy@cisco.com] >>> Sent: Friday, October 16, 2009 9:05 AM >>> To: Xiao, Lin (NSN - CN/Beijing) >>> Cc: P2PSIP WG >>> Subject: Re: [P2PSIP] New versions of RELOAD and sip draft >>> >>> >>> Thank you, few comments inline.... >>> >>> On Oct 10, 2009, at 2:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote: >>> >>> >>>> Hi Cullen, >>>> >>>> I've had a quick review of these two drafts, and still not quite >>>> clear >>>> >>>> with some Client related issues. >>>> >>>> I know Client is not the first-class concept in RELOAD, but as it has >>>> >> >> >>>> been involved in the RELOAD protocol, RELOAD should give full support >>>> >> >> >>>> to client anyhow, right? >>>> >>>> In the terminology chapter of RELOAD Base draft, the connection table >>>> >> >> >>>> is defined as: >>>> "The set of peers to which a node is directly connected. This >>>> includes nodes with which Attach handshakes have been done but which >>>> >> >> >>>> have not sent any Updates." >>>> although, the second sentence implies that clients are also involved >>>> in, I still suggest to replace the "peers" in the first sentence with >>>> >> >> >>>> "nodes" to make it more clear that both peers and clients can be >>>> maintained in the table. >>>> >>> I agree. I changed this - thank you for the careful review to catch >>> things like this. >>> >>> >>>> In my opinions, connection setup and maintenance between client and >>>> its connected peer (responsible peer or arbitrary peer) is a key >>>> issue for client support in RELOAD. My question is: Does a peer in >>>> RELOAD distinguish if the connection is to a peer or to a client? >>>> Because the reaction of the peer could be different when the >>>> connection is lost. >>>> >>> Reload does distinguish at some level but what do you think a node >>> needs to do differently when a connection is lost if the connection >>> when to a peer or client. Clearly how data replication is handled and >>> some of the finger table stuff is handled differently but I think that >>> >> >> >>> is covered in the draft. If you see something specific missing, let me >>> >> >> >>> know. >>> >>> >>>> As a client could set up a connection only with an arbitrary peer. >>>> Does >>>> this peer distinguish such connection from those it is responsible >>>> to? >>>> >>> I don't se the need to. >>> >>> >>>> Should this peer inform the client's responsible peer about the >>>> Destination List to the client? So that it can still be accessed by >>>> other nodes. Or should the Destination List been stored with some >>>> usage, say SIP Usage? >>>> >>> Yes, that is the approach to store destination lists where they are >>> needed. >>> >>> >>>> If so, the SIP usage must be extended to allow a Destination list >>>> containing more than one Node IDs. >>>> >>> agree that it needs to allow storing multiple Node IDs but I think it >>> already does that. >>> >>> >>>> In current SIP >>>> usage draft, the SipRegistration structure only allow one address >>>> being stored in the Destination List, as: >>>> " Destination destination_list<0..2^16-1>;" >>>> >>> The destination_list here is an array of Destinations so it allows >>> between 0 and 65K entries in the array. I agree the syntax for >>> specifying arrays might seem a bit weird but I think the structure is >>> what you are pointing out we need to have. >>> >>> >>>> It should be replaced by: "Destination destination_list >>>> [dest_list_length];" >>>> to enable a longer list stored by arbitrary connected clients. >>>> >>>> Anyway, IMHO, RELOAD should make sure to cover all situations a >>>> client could meet or at least clearly distinguish issues of clients, >>>> especially for arbitrary connected ones, which are left to be solved >>>> by other drafts. Thanks. >>>> >>>> >>>> Best Regards, >>>> Xiao, Lin >>>> >>>> >>>> -----Original Message----- >>>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >>>> Behalf Of ext Cullen Jennings >>>> Sent: Wednesday, October 07, 2009 1:53 AM >>>> To: P2PSIP WG >>>> Subject: [P2PSIP] New versions of RELOAD and sip draft >>>> >>>> >>>> I just submitted >>>> draft-ietf-p2psip-base-04 >>>> and >>>> draft-ietf-p2psip-sip-02 >>>> >>>> These contain technical changes but do not have a lot of editorial >>>> changes. At some point we need to go and reorganize the documents >>>> with editorial changes. >>>> >>>> Cullen >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip From neil.young@freenet.de Fri Oct 23 13:26:54 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CC373A679F for ; Fri, 23 Oct 2009 13:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.118 X-Spam-Level: X-Spam-Status: No, score=0.118 tagged_above=-999 required=5 tests=[AWL=-1.696, BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiTv2+OwNkmk for ; Fri, 23 Oct 2009 13:26:52 -0700 (PDT) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by core3.amsl.com (Postfix) with ESMTP id E48D73A67FA for ; Fri, 23 Oct 2009 13:26:51 -0700 (PDT) Received: from [195.4.92.16] (helo=6.mx.freenet.de) by mout2.freenet.de with esmtpa (ID roland.klabunde@freenet.de) (port 25) (Exim 4.69 #92) id 1N1Qiy-0003Kg-BY; Fri, 23 Oct 2009 22:27:00 +0200 Received: from p54bd9df3.dip0.t-ipconnect.de ([84.189.157.243]:51088 helo=[192.168.178.38]) by 6.mx.freenet.de with esmtpa (ID roland.klabunde@freenet.de) (port 25) (Exim 4.69 #94) id 1N1Qix-0001me-Lo; Fri, 23 Oct 2009 22:27:00 +0200 Message-ID: <4AE21193.7070108@freenet.de> Date: Fri, 23 Oct 2009 22:26:59 +0200 From: "neil.young" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: stas@khirman.com, p2psip WG References: <23908826.230221256327270539.JavaMail.servlet@perfora> In-Reply-To: <23908826.230221256327270539.JavaMail.servlet@perfora> Content-Type: multipart/alternative; boundary="------------000706000106050400020204" Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: neil.young@freenet.de List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 20:26:54 -0000 This is a multi-part message in MIME format. --------------000706000106050400020204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Given a chord ring of 100 - 200 - 300 - 400 - 500 - 600 (back to 100) and considering to fight a high churn rate of 400 and 600, than a "new ID" for 500 (e.g. somewhere around 150) would be good for 500, but wouldn't be of help for the whole topology. Similarity: You are in a cinema and unfortunately sitting between two persons, constantly talking to each other. You could choose a new free seat somewhere off the middle, where you have been sitting up to now. That would probably help you, but wouldn't make the situation much better for the whole bunch of visitors :) Of course the hyperventilation of 400 and 600 might be annoying, but the ring has to have the ability to always stabilize and cope with this. A new ID - don't know, where this privileged seat should be come from :) I'm not aware of having read about such means anywhere. Regards stas@khirman.com schrieb: > IMHO Lin Xiao has a quite valid point. If due changes of topology, node 500 permanently loose its ability to interconnect with close ( in DHT space) nodes, it has to be excluded from DHT ring or have to get a new ID. > > Otherwise, it will became a permanent dead-end node for lookups for targets in its immediate neighborhood that significantly degrades speed of DHT lookup and ( under some conditions) can event result in DHT space segmentation. > > >> 500 can of course keep it's node id, regardless of whether 400 and/or >> 600 are there or not. Due to stabilization and by means of the >> successorcache the predecessor of 400 will notice the absence and bridge >> directly to 500 as well as 500 will skip 600 after a short time and go >> to 700 (in order to stay in the picture). Using notify the ring will >> close again. 400 and 600 may return whenever they want. >> >> Regards >> >> >> Xiao, Lin (NSN - CN/Beijing) schrieb: >> >>> Hi, >>> >>> Maybe I'm wrong, but I consider peers in RELOAD are structured with a >>> DHT algorithm, e.g., in Chord, peer with Node-ID 500 is connected with >>> peer 400 and 600. >>> >>> However, what will happen, if peer 500 totally lose both of the >>> connections due to mobility and NAT, but can set up new ones with peer >>> 100 and peer 300? IMHO, in order to keep the topology structured, if >>> this node still want to be a peer in the overlay it should change its >>> Node ID to, say 200, and rejoin the overlay to enable itself still >>> reachable with the DHT algorithm. >>> >>> If peers in a overlay can not be connected with a strict order, the DHT >>> algorithm for structured topology will not work anymore. >>> >>> >>> Br >>> Xiao, Lin >>> >>> -----Original Message----- >>> From: ext jc [mailto:julian@orchidseed.org] >>> Sent: Thursday, October 22, 2009 12:41 AM >>> To: Xiao, Lin (NSN - CN/Beijing) >>> Cc: ext Cullen Jennings; P2PSIP WG >>> Subject: Re: [P2PSIP] New versions of RELOAD and sip draft >>> >>> The draft doesn't state that you MUST change you NodeID if you lose >>> overlay connectivity. In fact under your given condition you would >>> simply retain it and connect again as a Client when the network is back >>> up. >>> >>> Julian >>> >>> On Oct 21, 2009, at 3:59 AM, Xiao, Lin (NSN - CN/Beijing) wrote: >>> >>> >>> >>>> Hi Cullen, >>>> >>>> Thanks for your reply. >>>> >>>> I agree that RELOAD have covered most of the functionalities of peers >>>> >>>> >>> >>> >>>> and clients. However, there is still a little different between >>>> clients and peers while connection is lost besides data replica. What >>>> I mean here is the Node ID. >>>> >>>> Because all the peers in the overlay are connected according to a >>>> strict overlay algorithm. The position of a peer in the overlay is >>>> decided by its Node ID. If a peer lost its position (disconnected) in >>>> the overlay because of moving and NAT, but still want to work as a >>>> peer, it must change its Node ID, which means it need do the >>>> enrollment again and rejoin the overlay. >>>> >>>> But, because a client can attach with an arbitrary peer. It is not >>>> necessary for a client to change its Node ID when it change its >>>> attaching peer. The most important thing here is that, this behavior >>>> make it possible for a client to keep session continuity while its >>>> attaching peer is switched. >>>> >>>> Considering to deploy RELOAD in reality, stable nodes are preferred >>>> to work as peers while mobile nodes can take the advantage of the >>>> client behavior mentioned above. Sessions can be kept with high >>>> mobility, as unique Node ID is maintained by clients. I'm not sure if >>>> RELOAD has considered this distinction of client, which help clients >>>> to be attached with the ovelay as long as it can build at least one >>>> connection to the overlay. >>>> >>>> Br >>>> Xiao, Lin >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: ext Cullen Jennings [mailto:fluffy@cisco.com] >>>> Sent: Friday, October 16, 2009 9:05 AM >>>> To: Xiao, Lin (NSN - CN/Beijing) >>>> Cc: P2PSIP WG >>>> Subject: Re: [P2PSIP] New versions of RELOAD and sip draft >>>> >>>> >>>> Thank you, few comments inline.... >>>> >>>> On Oct 10, 2009, at 2:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote: >>>> >>>> >>>> >>>>> Hi Cullen, >>>>> >>>>> I've had a quick review of these two drafts, and still not quite >>>>> clear >>>>> >>>>> with some Client related issues. >>>>> >>>>> I know Client is not the first-class concept in RELOAD, but as it has >>>>> >>>>> >>> >>> >>>>> been involved in the RELOAD protocol, RELOAD should give full support >>>>> >>>>> >>> >>> >>>>> to client anyhow, right? >>>>> >>>>> In the terminology chapter of RELOAD Base draft, the connection table >>>>> >>>>> >>> >>> >>>>> is defined as: >>>>> "The set of peers to which a node is directly connected. This >>>>> includes nodes with which Attach handshakes have been done but which >>>>> >>>>> >>> >>> >>>>> have not sent any Updates." >>>>> although, the second sentence implies that clients are also involved >>>>> in, I still suggest to replace the "peers" in the first sentence with >>>>> >>>>> >>> >>> >>>>> "nodes" to make it more clear that both peers and clients can be >>>>> maintained in the table. >>>>> >>>>> >>>> I agree. I changed this - thank you for the careful review to catch >>>> things like this. >>>> >>>> >>>> >>>>> In my opinions, connection setup and maintenance between client and >>>>> its connected peer (responsible peer or arbitrary peer) is a key >>>>> issue for client support in RELOAD. My question is: Does a peer in >>>>> RELOAD distinguish if the connection is to a peer or to a client? >>>>> Because the reaction of the peer could be different when the >>>>> connection is lost. >>>>> >>>>> >>>> Reload does distinguish at some level but what do you think a node >>>> needs to do differently when a connection is lost if the connection >>>> when to a peer or client. Clearly how data replication is handled and >>>> some of the finger table stuff is handled differently but I think that >>>> >>>> >>> >>> >>>> is covered in the draft. If you see something specific missing, let me >>>> >>>> >>> >>> >>>> know. >>>> >>>> >>>> >>>>> As a client could set up a connection only with an arbitrary peer. >>>>> Does >>>>> this peer distinguish such connection from those it is responsible >>>>> to? >>>>> >>>>> >>>> I don't se the need to. >>>> >>>> >>>> >>>>> Should this peer inform the client's responsible peer about the >>>>> Destination List to the client? So that it can still be accessed by >>>>> other nodes. Or should the Destination List been stored with some >>>>> usage, say SIP Usage? >>>>> >>>>> >>>> Yes, that is the approach to store destination lists where they are >>>> needed. >>>> >>>> >>>> >>>>> If so, the SIP usage must be extended to allow a Destination list >>>>> containing more than one Node IDs. >>>>> >>>>> >>>> agree that it needs to allow storing multiple Node IDs but I think it >>>> already does that. >>>> >>>> >>>> >>>>> In current SIP >>>>> usage draft, the SipRegistration structure only allow one address >>>>> being stored in the Destination List, as: >>>>> " Destination destination_list<0..2^16-1>;" >>>>> >>>>> >>>> The destination_list here is an array of Destinations so it allows >>>> between 0 and 65K entries in the array. I agree the syntax for >>>> specifying arrays might seem a bit weird but I think the structure is >>>> what you are pointing out we need to have. >>>> >>>> >>>> >>>>> It should be replaced by: "Destination destination_list >>>>> [dest_list_length];" >>>>> to enable a longer list stored by arbitrary connected clients. >>>>> >>>>> Anyway, IMHO, RELOAD should make sure to cover all situations a >>>>> client could meet or at least clearly distinguish issues of clients, >>>>> especially for arbitrary connected ones, which are left to be solved >>>>> by other drafts. Thanks. >>>>> >>>>> >>>>> Best Regards, >>>>> Xiao, Lin >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >>>>> Behalf Of ext Cullen Jennings >>>>> Sent: Wednesday, October 07, 2009 1:53 AM >>>>> To: P2PSIP WG >>>>> Subject: [P2PSIP] New versions of RELOAD and sip draft >>>>> >>>>> >>>>> I just submitted >>>>> draft-ietf-p2psip-base-04 >>>>> and >>>>> draft-ietf-p2psip-sip-02 >>>>> >>>>> These contain technical changes but do not have a lot of editorial >>>>> changes. At some point we need to go and reorganize the documents >>>>> with editorial changes. >>>>> >>>>> Cullen >>>>> >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>> >>>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > --------------000706000106050400020204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Given a chord ring of 100 - 200 - 300 - 400 - 500 - 600 (back to 100) and considering to fight a high churn rate of 400 and 600, than a "new ID" for 500 (e.g. somewhere around 150) would be good for 500, but wouldn't be of help for the whole topology. Similarity: You are in a cinema and unfortunately sitting between two persons, constantly talking to each other. You could choose a new free seat somewhere off the middle, where you have been sitting up to now. That would probably help you, but wouldn't make the situation much better for the whole bunch of visitors :)

Of course the hyperventilation of 400 and 600 might be annoying, but the ring has to have the ability to always stabilize and cope with this. A new ID - don't know, where this privileged seat should be come from :) I'm not aware of having read about such means anywhere.

Regards



stas@khirman.com schrieb: 
IMHO Lin Xiao has a quite valid point. If due changes of topology, node 500 permanently loose its ability to interconnect with close ( in DHT space) nodes, it has to be excluded from DHT ring or have to get a new ID.

Otherwise, it will became a permanent dead-end node for lookups for targets in its immediate neighborhood that significantly degrades speed of DHT lookup and ( under some conditions) can event result in DHT space segmentation.

  
500 can of course keep it's node id, regardless of whether 400 and/or 
600 are there or not. Due to stabilization and by means of the 
successorcache the predecessor of 400 will notice the absence and bridge 
directly to 500 as well as 500 will skip 600 after a short time and go 
to 700 (in order to stay in the picture).  Using notify the ring will 
close again. 400 and 600 may return whenever they want.

Regards


Xiao, Lin (NSN - CN/Beijing) schrieb:
    
Hi,

Maybe I'm wrong, but I consider peers in RELOAD are structured with a
DHT algorithm, e.g., in Chord, peer with Node-ID 500 is connected with
peer 400 and 600. 

However, what will happen, if peer 500 totally lose both of the
connections due to mobility and NAT, but can set up new ones with peer
100 and peer 300? IMHO, in order to keep the topology structured, if
this node still want to be a peer in the overlay it should change its
Node ID to, say 200, and rejoin the overlay to enable itself still
reachable with the DHT algorithm.

If peers in a overlay can not be connected with a strict order, the DHT
algorithm for structured topology will not work anymore.


Br
Xiao, Lin 

-----Original Message-----
From: ext jc [mailto:julian@orchidseed.org] 
Sent: Thursday, October 22, 2009 12:41 AM
To: Xiao, Lin (NSN - CN/Beijing)
Cc: ext Cullen Jennings; P2PSIP WG
Subject: Re: [P2PSIP] New versions of RELOAD and sip draft

The draft doesn't state that you MUST change you NodeID if you lose
overlay connectivity. In fact under your given condition you would
simply retain it and connect again as a Client when the network is back
up.

Julian

On Oct 21, 2009, at 3:59 AM, Xiao, Lin (NSN - CN/Beijing) wrote:

  
      
Hi Cullen,

Thanks for your reply.

I agree that RELOAD have covered  most of the functionalities of peers
    
        
  
      
and clients. However, there is still a little different between 
clients and peers while connection is lost besides data replica. What 
I mean here is the Node ID.

Because all the peers in the overlay are connected according to a 
strict overlay algorithm. The position of a peer in the overlay is 
decided by its Node ID. If a peer lost its position (disconnected) in 
the overlay because of moving and NAT, but still want to work as a 
peer, it must change its Node ID, which means it need do the 
enrollment again and rejoin the overlay.

But, because a client can attach with an arbitrary peer. It is not 
necessary for a client to change its Node ID when it change its 
attaching peer. The most important thing here is that, this behavior 
make it possible for a client  to keep session continuity while its 
attaching peer is switched.

Considering to deploy  RELOAD in reality, stable nodes are preferred 
to work as peers while mobile nodes can take the advantage of the 
client behavior mentioned above. Sessions can be kept with high 
mobility, as unique Node ID is maintained by clients. I'm not sure if 
RELOAD has considered this distinction of client, which help clients 
to be attached with the ovelay as long as it can build at least one 
connection to the overlay.

Br
Xiao, Lin



-----Original Message-----
From: ext Cullen Jennings [mailto:fluffy@cisco.com]
Sent: Friday, October 16, 2009 9:05 AM
To: Xiao, Lin (NSN - CN/Beijing)
Cc: P2PSIP WG
Subject: Re: [P2PSIP] New versions of RELOAD and sip draft


Thank you, few comments inline....

On Oct 10, 2009, at 2:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote:

    
        
Hi Cullen,

I've had a quick review of these two drafts, and still not quite 
clear
      
with some Client related issues.

I know Client is not the first-class concept in RELOAD, but as it has
      
          
  
      
been involved in the RELOAD protocol, RELOAD should give full support
      
          
  
      
to client anyhow, right?

In the terminology chapter of RELOAD Base draft, the connection table
      
          
  
      
is defined as:
   "The set of peers to which a node is directly connected.  This 
includes nodes with which Attach handshakes have  been done but which
      
          
  
      
have not sent any Updates."
although, the second sentence implies that clients are also involved 
in, I still suggest to replace the "peers" in the first sentence with
      
          
  
      
"nodes" to make it more clear that both peers and clients can be 
maintained in the table.
      
          
I agree. I changed this - thank you for the careful review to catch 
things like this.

    
        
In my opinions, connection setup and maintenance between client and 
its connected peer (responsible peer or arbitrary peer) is a key 
issue for client support in RELOAD.  My question is: Does a peer in 
RELOAD distinguish if the connection is to a peer or to a client? 
Because the reaction of the peer could be different when the 
connection is lost.
      
          
Reload does distinguish at some level but what do you think a node 
needs to do differently when a connection is lost if the connection 
when to a peer or client. Clearly how data replication is handled and 
some of the finger table stuff is handled differently but I think that
    
        
  
      
is covered in the draft. If you see something specific missing, let me
    
        
  
      
know.

    
        
As a client could set up a connection only with an arbitrary peer.
Does
this peer distinguish such connection from those it is responsible 
to?
      
          
I don't se the need to.

    
        
Should this peer inform the client's responsible peer about the 
Destination List to the client? So that it can still be accessed by 
other nodes. Or should the Destination List been stored with some 
usage, say SIP Usage?
      
          
Yes, that is the approach to store destination lists where they are 
needed.

    
        
If so, the SIP usage must be extended to allow a Destination list 
containing more than one Node IDs.
      
          
agree that it needs to allow storing multiple Node IDs but I think it 
already does that.

    
        
In current SIP
usage draft, the SipRegistration structure only allow one address 
being stored in the Destination List, as:
" Destination          destination_list<0..2^16-1>;"
      
          
The destination_list here is an array of Destinations so it allows 
between 0 and 65K entries in the array. I agree the syntax for 
specifying arrays might seem a bit weird but I think the structure is 
what you are pointing out we need to have.

    
        
It should be replaced by: "Destination          destination_list
[dest_list_length];"
to enable a longer list stored by arbitrary connected clients.

Anyway, IMHO, RELOAD should make sure to cover all situations a 
client could meet or at least clearly distinguish issues of clients, 
especially for arbitrary connected ones, which are left to be solved 
by other drafts. Thanks.


Best Regards,
Xiao, Lin


-----Original Message-----
From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On 
Behalf Of ext Cullen Jennings
Sent: Wednesday, October 07, 2009 1:53 AM
To: P2PSIP WG
Subject: [P2PSIP] New versions of RELOAD and sip draft


I just submitted
draft-ietf-p2psip-base-04
and
draft-ietf-p2psip-sip-02

These contain technical changes but do not have a lot of editorial 
changes. At some point we need to go and reorganize the documents 
with editorial changes.

Cullen <in my individual contributor role>

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
      
          
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
    
        
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
  
      
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
    
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
--------------000706000106050400020204-- From julian@orchidseed.org Fri Oct 23 17:07:50 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E11B28C0E7 for ; Fri, 23 Oct 2009 17:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBvc-d6VX-wr for ; Fri, 23 Oct 2009 17:07:49 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id 237933A67B3 for ; Fri, 23 Oct 2009 17:07:49 -0700 (PDT) Received: from z65-50-24-39.ips.direcpath.com ([65.50.24.39]:54592 helo=[192.168.1.109]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1N1UAk-0000ju-3U; Fri, 23 Oct 2009 17:07:55 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc X-Priority: 3 In-Reply-To: <23908826.230221256327270539.JavaMail.servlet@perfora> Date: Fri, 23 Oct 2009 20:07:48 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <23908826.230221256327270539.JavaMail.servlet@perfora> To: stas@khirman.com X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: Neil.Young@Freenet.de, p2psip@ietf.org Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 00:07:50 -0000 In section 3.2.1. Client Routing contains two algorithms for Client routing. if you choose either of those algorithms then this won't be a problem. The first algorithm would forward through 500 around to 600(a direct connection). The second would use the destination list and form the route to 600 by storing information in the hash table. Finally, it is up to the Topology Plugin to ultimately handle this which Chord does so fine under this condition via it's own update (stabilization) procedures. Julian On Oct 23, 2009, at 3:47 PM, stas@khirman.com wrote: > IMHO Lin Xiao has a quite valid point. If due changes of topology, > node 500 permanently loose its ability to interconnect with close > ( in DHT space) nodes, it has to be excluded from DHT ring or have > to get a new ID. > > Otherwise, it will became a permanent dead-end node for lookups for > targets in its immediate neighborhood that significantly degrades > speed of DHT lookup and ( under some conditions) can event result in > DHT space segmentation. > >> 500 can of course keep it's node id, regardless of whether 400 and/or >> 600 are there or not. Due to stabilization and by means of the >> successorcache the predecessor of 400 will notice the absence and >> bridge >> directly to 500 as well as 500 will skip 600 after a short time and >> go >> to 700 (in order to stay in the picture). Using notify the ring will >> close again. 400 and 600 may return whenever they want. >> >> Regards >> >> >> Xiao, Lin (NSN - CN/Beijing) schrieb: >>> Hi, >>> >>> Maybe I'm wrong, but I consider peers in RELOAD are structured >>> with a >>> DHT algorithm, e.g., in Chord, peer with Node-ID 500 is connected >>> with >>> peer 400 and 600. >>> >>> However, what will happen, if peer 500 totally lose both of the >>> connections due to mobility and NAT, but can set up new ones with >>> peer >>> 100 and peer 300? IMHO, in order to keep the topology structured, if >>> this node still want to be a peer in the overlay it should change >>> its >>> Node ID to, say 200, and rejoin the overlay to enable itself still >>> reachable with the DHT algorithm. >>> >>> If peers in a overlay can not be connected with a strict order, >>> the DHT >>> algorithm for structured topology will not work anymore. >>> >>> >>> Br >>> Xiao, Lin >>> >>> -----Original Message----- >>> From: ext jc [mailto:julian@orchidseed.org] >>> Sent: Thursday, October 22, 2009 12:41 AM >>> To: Xiao, Lin (NSN - CN/Beijing) >>> Cc: ext Cullen Jennings; P2PSIP WG >>> Subject: Re: [P2PSIP] New versions of RELOAD and sip draft >>> >>> The draft doesn't state that you MUST change you NodeID if you lose >>> overlay connectivity. In fact under your given condition you would >>> simply retain it and connect again as a Client when the network is >>> back >>> up. >>> >>> Julian >>> >>> On Oct 21, 2009, at 3:59 AM, Xiao, Lin (NSN - CN/Beijing) wrote: >>> >>> >>>> Hi Cullen, >>>> >>>> Thanks for your reply. >>>> >>>> I agree that RELOAD have covered most of the functionalities of >>>> peers >>>> >>> >>> >>>> and clients. However, there is still a little different between >>>> clients and peers while connection is lost besides data replica. >>>> What >>>> I mean here is the Node ID. >>>> >>>> Because all the peers in the overlay are connected according to a >>>> strict overlay algorithm. The position of a peer in the overlay is >>>> decided by its Node ID. If a peer lost its position >>>> (disconnected) in >>>> the overlay because of moving and NAT, but still want to work as a >>>> peer, it must change its Node ID, which means it need do the >>>> enrollment again and rejoin the overlay. >>>> >>>> But, because a client can attach with an arbitrary peer. It is not >>>> necessary for a client to change its Node ID when it change its >>>> attaching peer. The most important thing here is that, this >>>> behavior >>>> make it possible for a client to keep session continuity while its >>>> attaching peer is switched. >>>> >>>> Considering to deploy RELOAD in reality, stable nodes are >>>> preferred >>>> to work as peers while mobile nodes can take the advantage of the >>>> client behavior mentioned above. Sessions can be kept with high >>>> mobility, as unique Node ID is maintained by clients. I'm not >>>> sure if >>>> RELOAD has considered this distinction of client, which help >>>> clients >>>> to be attached with the ovelay as long as it can build at least one >>>> connection to the overlay. >>>> >>>> Br >>>> Xiao, Lin >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: ext Cullen Jennings [mailto:fluffy@cisco.com] >>>> Sent: Friday, October 16, 2009 9:05 AM >>>> To: Xiao, Lin (NSN - CN/Beijing) >>>> Cc: P2PSIP WG >>>> Subject: Re: [P2PSIP] New versions of RELOAD and sip draft >>>> >>>> >>>> Thank you, few comments inline.... >>>> >>>> On Oct 10, 2009, at 2:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote: >>>> >>>> >>>>> Hi Cullen, >>>>> >>>>> I've had a quick review of these two drafts, and still not quite >>>>> clear >>>>> >>>>> with some Client related issues. >>>>> >>>>> I know Client is not the first-class concept in RELOAD, but as >>>>> it has >>>>> >>> >>> >>>>> been involved in the RELOAD protocol, RELOAD should give full >>>>> support >>>>> >>> >>> >>>>> to client anyhow, right? >>>>> >>>>> In the terminology chapter of RELOAD Base draft, the connection >>>>> table >>>>> >>> >>> >>>>> is defined as: >>>>> "The set of peers to which a node is directly connected. This >>>>> includes nodes with which Attach handshakes have been done but >>>>> which >>>>> >>> >>> >>>>> have not sent any Updates." >>>>> although, the second sentence implies that clients are also >>>>> involved >>>>> in, I still suggest to replace the "peers" in the first sentence >>>>> with >>>>> >>> >>> >>>>> "nodes" to make it more clear that both peers and clients can be >>>>> maintained in the table. >>>>> >>>> I agree. I changed this - thank you for the careful review to catch >>>> things like this. >>>> >>>> >>>>> In my opinions, connection setup and maintenance between client >>>>> and >>>>> its connected peer (responsible peer or arbitrary peer) is a key >>>>> issue for client support in RELOAD. My question is: Does a peer >>>>> in >>>>> RELOAD distinguish if the connection is to a peer or to a client? >>>>> Because the reaction of the peer could be different when the >>>>> connection is lost. >>>>> >>>> Reload does distinguish at some level but what do you think a node >>>> needs to do differently when a connection is lost if the connection >>>> when to a peer or client. Clearly how data replication is handled >>>> and >>>> some of the finger table stuff is handled differently but I think >>>> that >>>> >>> >>> >>>> is covered in the draft. If you see something specific missing, >>>> let me >>>> >>> >>> >>>> know. >>>> >>>> >>>>> As a client could set up a connection only with an arbitrary peer. >>>>> Does >>>>> this peer distinguish such connection from those it is responsible >>>>> to? >>>>> >>>> I don't se the need to. >>>> >>>> >>>>> Should this peer inform the client's responsible peer about the >>>>> Destination List to the client? So that it can still be accessed >>>>> by >>>>> other nodes. Or should the Destination List been stored with some >>>>> usage, say SIP Usage? >>>>> >>>> Yes, that is the approach to store destination lists where they are >>>> needed. >>>> >>>> >>>>> If so, the SIP usage must be extended to allow a Destination list >>>>> containing more than one Node IDs. >>>>> >>>> agree that it needs to allow storing multiple Node IDs but I >>>> think it >>>> already does that. >>>> >>>> >>>>> In current SIP >>>>> usage draft, the SipRegistration structure only allow one address >>>>> being stored in the Destination List, as: >>>>> " Destination destination_list<0..2^16-1>;" >>>>> >>>> The destination_list here is an array of Destinations so it allows >>>> between 0 and 65K entries in the array. I agree the syntax for >>>> specifying arrays might seem a bit weird but I think the >>>> structure is >>>> what you are pointing out we need to have. >>>> >>>> >>>>> It should be replaced by: "Destination destination_list >>>>> [dest_list_length];" >>>>> to enable a longer list stored by arbitrary connected clients. >>>>> >>>>> Anyway, IMHO, RELOAD should make sure to cover all situations a >>>>> client could meet or at least clearly distinguish issues of >>>>> clients, >>>>> especially for arbitrary connected ones, which are left to be >>>>> solved >>>>> by other drafts. Thanks. >>>>> >>>>> >>>>> Best Regards, >>>>> Xiao, Lin >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >>>>> Behalf Of ext Cullen Jennings >>>>> Sent: Wednesday, October 07, 2009 1:53 AM >>>>> To: P2PSIP WG >>>>> Subject: [P2PSIP] New versions of RELOAD and sip draft >>>>> >>>>> >>>>> I just submitted >>>>> draft-ietf-p2psip-base-04 >>>>> and >>>>> draft-ietf-p2psip-sip-02 >>>>> >>>>> These contain technical changes but do not have a lot of editorial >>>>> changes. At some point we need to go and reorganize the documents >>>>> with editorial changes. >>>>> >>>>> Cullen >>>>> >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From melodysong@huawei.com Sun Oct 25 19:32:15 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA403A69C6 for ; Sun, 25 Oct 2009 19:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.55 X-Spam-Level: X-Spam-Status: No, score=0.55 tagged_above=-999 required=5 tests=[AWL=1.045, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6KD7DRq-J9E for ; Sun, 25 Oct 2009 19:32:14 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 872EA3A6A22 for ; Sun, 25 Oct 2009 19:32:14 -0700 (PDT) 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 <0KS300701ODS7Q@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 26 Oct 2009 10:32:17 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS300MNBODSOS@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 26 Oct 2009 10:32:16 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS300AMLODSE3@szxml06-in.huawei.com> for p2psip@ietf.org; Mon, 26 Oct 2009 10:32:16 +0800 (CST) Date: Mon, 26 Oct 2009 10:32:16 +0800 From: Song Haibin In-reply-to: To: 'Brian Rosen' , 'Cullen Jennings' , 'P2PSIP WG' Message-id: <020301ca55e4$8878c100$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpUElB92v/1J7wttEODiqIyeRzsMwByz6CA Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 02:32:15 -0000 Hi, I have not finished the review, but I have several questions on this document. 1). I am not sure how the TRUN usage defined in this document will work well. Who will be responsible for calculating the turnDensity and how? How to update the TURN server information in the overlay when some TURN servers leave the overlay suddenly, to aovid getting the "old" information? 2). In section 4.1.1 "Storage Permissions" said "RELOAD addresses this issue by only allowing any given node to store data at a small number of locations in the overlay, with those locations being determined by the node's certificate." This rule will limit the applications that the protocol could support. E.g, for streaming or file-sharing applications, it is very practical to put the resource providers' address information under the same Resource ID which is the hash of the content name, despite the node ID or username information contained in the certificate of the resource provider. 3). How do you prevent "via list" being modified by the intermediate peers? This is very important because it is related to whether you can get a right returen path for your response. 4). In section 5.4.2.4.2., RouteQuery response should at least include a next hop peer infomation if you want to use this message for the iterative routing. 5). I'm not sure about the necessity of access control policies in section 6.3. I think it will make sense only when these access control policies are generic to all usages that will be built on top of RELOAD. Other than that, I would suggest to remove this section and define these policies in each usage document. Comment 2 is also related to this topic. Thanks! Haibin >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] >On Behalf Of Brian Rosen >Sent: Saturday, October 24, 2009 2:55 AM >To: Cullen Jennings; P2PSIP WG >Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base > > >If you think the draft is missing something big, or has some >other serious shortcoming that makes it inappropriate to hold >a WGLC, please speak up now. >We'll give everyone a few days to look over this version, and >then decide if we will start it. > >If you had signed up to review NOW would be the time to do it, >on this version. That was NOW, and not "soon", please. > >Brian > > >On 10/23/09 2:38 PM, "Cullen Jennings" wrote: > >> >> We just submitted a new version of the base draft at >> >> http://www.ietf.org/id/draft-ietf-p2psip-base-05.txt >> >> (there is a new version of the sip-usage as well). >> >> The major changes are mostly a very long and excruciating editorial >> pass to try and improve the grammar. >> >> At this point, I don't know of any significant issues that >need to be >> resolved. I think the draft is ready for WGLC. >> >> I'm sure that during WGLC some major issues will come up, some >> important decisions will be made about what needs to be >mandatory and >> such, and we will find several small inconsistencies and >typos in the >> draft as well as things that need a clearer explanation. This will >> take some time and I expect multiple more revisions for this draft >> before it is published, however, I do think this is the >right time to >> start WGLC. Lets get the issues on the table and then we can start >> resolving them. >> >> Thanks, >> Cullen >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip > From julian@orchidseed.org Sun Oct 25 22:14:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1257A3A67A5 for ; Sun, 25 Oct 2009 22:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm8Bb9TPqt6f for ; Sun, 25 Oct 2009 22:14:29 -0700 (PDT) Received: from n13.c05.mtsvc.net (n13.c05.mtsvc.net [70.32.68.13]) by core3.amsl.com (Postfix) with ESMTP id EFF653A6405 for ; Sun, 25 Oct 2009 22:14:28 -0700 (PDT) Received: from adsl-176-189-182.asm.bellsouth.net ([74.176.189.182]:63998 helo=[10.0.1.12]) by n13.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1N2Hud-0002vQ-Hw; Sun, 25 Oct 2009 22:14:37 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: <020301ca55e4$8878c100$1d0ca40a@china.huawei.com> Date: Mon, 26 Oct 2009 01:14:30 -0400 Content-Transfer-Encoding: 7bit Message-Id: <88540B39-C938-497F-9838-C78BE202C944@orchidseed.org> References: <020301ca55e4$8878c100$1d0ca40a@china.huawei.com> To: Song Haibin X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 05:14:31 -0000 On Oct 25, 2009, at 10:32 PM, Song Haibin wrote: > Hi, > > I have not finished the review, but I have several questions on this > document. > > 1). I am not sure how the TRUN usage defined in this document will > work > well. Who will be responsible for calculating the turnDensity and > how? How > to update the TURN server information in the overlay when some TURN > servers > leave the overlay suddenly, to aovid getting the "old" information? > > 2). In section 4.1.1 "Storage Permissions" said "RELOAD addresses > this issue > by only allowing any given node to store data at > a small number of locations in the overlay, with those locations > being > determined by the node's certificate." This rule will limit the > applications > that the protocol could support. E.g, for streaming or file-sharing > applications, it is very practical to put the resource providers' > address > information under the same Resource ID which is the hash of the > content > name, despite the node ID or username information contained in the > certificate of the resource provider. This is how the BitTorrent DHT works and it's sloppy and insecure. To solve this problem you could create an extension such as Multicast groups in Overlay networks. I've implemented the following algorithm, it works and is fairly heavily tested. http://dks.sics.se/pub/mcastposter.pdf Julian > > 3). How do you prevent "via list" being modified by the intermediate > peers? > This is very important because it is related to whether you can get > a right > returen path for your response. > > 4). In section 5.4.2.4.2., RouteQuery response should at least > include a > next hop peer infomation if you want to use this message for the > iterative > routing. > > 5). I'm not sure about the necessity of access control policies in > section > 6.3. I think it will make sense only when these access control > policies are > generic to all usages that will be built on top of RELOAD. Other > than that, > I would suggest to remove this section and define these policies in > each > usage document. Comment 2 is also related to this topic. > > Thanks! > Haibin > > > >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] >> On Behalf Of Brian Rosen >> Sent: Saturday, October 24, 2009 2:55 AM >> To: Cullen Jennings; P2PSIP WG >> Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base >> >> >> If you think the draft is missing something big, or has some >> other serious shortcoming that makes it inappropriate to hold >> a WGLC, please speak up now. >> We'll give everyone a few days to look over this version, and >> then decide if we will start it. >> >> If you had signed up to review NOW would be the time to do it, >> on this version. That was NOW, and not "soon", please. >> >> Brian >> >> >> On 10/23/09 2:38 PM, "Cullen Jennings" wrote: >> >>> >>> We just submitted a new version of the base draft at >>> >>> http://www.ietf.org/id/draft-ietf-p2psip-base-05.txt >>> >>> (there is a new version of the sip-usage as well). >>> >>> The major changes are mostly a very long and excruciating editorial >>> pass to try and improve the grammar. >>> >>> At this point, I don't know of any significant issues that >> need to be >>> resolved. I think the draft is ready for WGLC. >>> >>> I'm sure that during WGLC some major issues will come up, some >>> important decisions will be made about what needs to be >> mandatory and >>> such, and we will find several small inconsistencies and >> typos in the >>> draft as well as things that need a clearer explanation. This will >>> take some time and I expect multiple more revisions for this draft >>> before it is published, however, I do think this is the >> right time to >>> start WGLC. Lets get the issues on the table and then we can start >>> resolving them. >>> >>> Thanks, >>> Cullen >>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From lin.xiao@nsn.com Sun Oct 25 23:18:53 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF3CF3A68AD for ; Sun, 25 Oct 2009 23:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsHgYL5+A+CJ for ; Sun, 25 Oct 2009 23:18:52 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id DEBBB3A6851 for ; Sun, 25 Oct 2009 23:18:51 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9Q6J0dK016126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Oct 2009 07:19:00 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9Q6IvDX027213; Mon, 26 Oct 2009 07:18:59 +0100 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 07:18:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 14:18:40 +0800 Message-ID: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4D9E27F@CNBEEXC007.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New versions of RELOAD and sip draft Thread-Index: AcpUPg73Dqz42ax6R1O0fjeOezwyLABw1Sqw From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext jc" , X-OriginalArrivalTime: 26 Oct 2009 06:18:59.0083 (UTC) FILETIME=[344D75B0:01CA5604] Cc: Neil.Young@Freenet.de, p2psip@ietf.org Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 06:18:54 -0000 Hi Julian, You are right. But it's Client Routing for clients, right? A peer, however, can not attaches arbitrarily on the overlay. That is the exact difference between peers and clients in my previous e-mails. If what you mean is that peers can also been found by algrithm 2 when it lost its position in the overlay, the overlay would be messed up with disordered topology structure finally. Br Lin -----Original Message----- From: ext jc [mailto:julian@orchidseed.org]=20 Sent: Saturday, October 24, 2009 8:08 AM To: stas@khirman.com Cc: Xiao, Lin (NSN - CN/Beijing); Neil.Young@Freenet.de; p2psip@ietf.org Subject: Re: [P2PSIP] New versions of RELOAD and sip draft In section 3.2.1. Client Routing contains two algorithms for Client routing. if you choose either of those algorithms then this won't be a problem. The first algorithm would forward through 500 around to 600(a direct connection). The second would use the destination list and form the route to 600 by storing information in the hash table. Finally, it is up to the Topology Plugin to ultimately handle this which Chord does so fine under this condition via it's own update (stabilization) procedures. Julian On Oct 23, 2009, at 3:47 PM, stas@khirman.com wrote: > IMHO Lin Xiao has a quite valid point. If due changes of topology,=20 > node 500 permanently loose its ability to interconnect with close ( in > DHT space) nodes, it has to be excluded from DHT ring or have to get a > new ID. > > Otherwise, it will became a permanent dead-end node for lookups for=20 > targets in its immediate neighborhood that significantly degrades=20 > speed of DHT lookup and ( under some conditions) can event result in=20 > DHT space segmentation. > >> 500 can of course keep it's node id, regardless of whether 400 and/or >> 600 are there or not. Due to stabilization and by means of the=20 >> successorcache the predecessor of 400 will notice the absence and=20 >> bridge directly to 500 as well as 500 will skip 600 after a short=20 >> time and go to 700 (in order to stay in the picture). Using notify=20 >> the ring will close again. 400 and 600 may return whenever they want. >> >> Regards >> >> >> Xiao, Lin (NSN - CN/Beijing) schrieb: >>> Hi, >>> >>> Maybe I'm wrong, but I consider peers in RELOAD are structured with=20 >>> a DHT algorithm, e.g., in Chord, peer with Node-ID 500 is connected=20 >>> with peer 400 and 600. >>> >>> However, what will happen, if peer 500 totally lose both of the=20 >>> connections due to mobility and NAT, but can set up new ones with=20 >>> peer 100 and peer 300? IMHO, in order to keep the topology=20 >>> structured, if this node still want to be a peer in the overlay it=20 >>> should change its Node ID to, say 200, and rejoin the overlay to=20 >>> enable itself still reachable with the DHT algorithm. >>> >>> If peers in a overlay can not be connected with a strict order, the=20 >>> DHT algorithm for structured topology will not work anymore. >>> >>> >>> Br >>> Xiao, Lin >>> >>> -----Original Message----- >>> From: ext jc [mailto:julian@orchidseed.org] >>> Sent: Thursday, October 22, 2009 12:41 AM >>> To: Xiao, Lin (NSN - CN/Beijing) >>> Cc: ext Cullen Jennings; P2PSIP WG >>> Subject: Re: [P2PSIP] New versions of RELOAD and sip draft >>> >>> The draft doesn't state that you MUST change you NodeID if you lose=20 >>> overlay connectivity. In fact under your given condition you would=20 >>> simply retain it and connect again as a Client when the network is=20 >>> back up. >>> >>> Julian >>> >>> On Oct 21, 2009, at 3:59 AM, Xiao, Lin (NSN - CN/Beijing) wrote: >>> >>> >>>> Hi Cullen, >>>> >>>> Thanks for your reply. >>>> >>>> I agree that RELOAD have covered most of the functionalities of=20 >>>> peers >>>> >>> >>> >>>> and clients. However, there is still a little different between=20 >>>> clients and peers while connection is lost besides data replica. >>>> What >>>> I mean here is the Node ID. >>>> >>>> Because all the peers in the overlay are connected according to a=20 >>>> strict overlay algorithm. The position of a peer in the overlay is=20 >>>> decided by its Node ID. If a peer lost its position >>>> (disconnected) in >>>> the overlay because of moving and NAT, but still want to work as a=20 >>>> peer, it must change its Node ID, which means it need do the=20 >>>> enrollment again and rejoin the overlay. >>>> >>>> But, because a client can attach with an arbitrary peer. It is not=20 >>>> necessary for a client to change its Node ID when it change its=20 >>>> attaching peer. The most important thing here is that, this=20 >>>> behavior make it possible for a client to keep session continuity=20 >>>> while its attaching peer is switched. >>>> >>>> Considering to deploy RELOAD in reality, stable nodes are=20 >>>> preferred to work as peers while mobile nodes can take the=20 >>>> advantage of the client behavior mentioned above. Sessions can be=20 >>>> kept with high mobility, as unique Node ID is maintained by=20 >>>> clients. I'm not sure if RELOAD has considered this distinction of=20 >>>> client, which help clients to be attached with the ovelay as long=20 >>>> as it can build at least one connection to the overlay. >>>> >>>> Br >>>> Xiao, Lin >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: ext Cullen Jennings [mailto:fluffy@cisco.com] >>>> Sent: Friday, October 16, 2009 9:05 AM >>>> To: Xiao, Lin (NSN - CN/Beijing) >>>> Cc: P2PSIP WG >>>> Subject: Re: [P2PSIP] New versions of RELOAD and sip draft >>>> >>>> >>>> Thank you, few comments inline.... >>>> >>>> On Oct 10, 2009, at 2:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote: >>>> >>>> >>>>> Hi Cullen, >>>>> >>>>> I've had a quick review of these two drafts, and still not quite=20 >>>>> clear >>>>> >>>>> with some Client related issues. >>>>> >>>>> I know Client is not the first-class concept in RELOAD, but as it=20 >>>>> has >>>>> >>> >>> >>>>> been involved in the RELOAD protocol, RELOAD should give full=20 >>>>> support >>>>> >>> >>> >>>>> to client anyhow, right? >>>>> >>>>> In the terminology chapter of RELOAD Base draft, the connection=20 >>>>> table >>>>> >>> >>> >>>>> is defined as: >>>>> "The set of peers to which a node is directly connected. This=20 >>>>> includes nodes with which Attach handshakes have been done but=20 >>>>> which >>>>> >>> >>> >>>>> have not sent any Updates." >>>>> although, the second sentence implies that clients are also=20 >>>>> involved in, I still suggest to replace the "peers" in the first=20 >>>>> sentence with >>>>> >>> >>> >>>>> "nodes" to make it more clear that both peers and clients can be=20 >>>>> maintained in the table. >>>>> >>>> I agree. I changed this - thank you for the careful review to catch >>>> things like this. >>>> >>>> >>>>> In my opinions, connection setup and maintenance between client=20 >>>>> and its connected peer (responsible peer or arbitrary peer) is a=20 >>>>> key issue for client support in RELOAD. My question is: Does a=20 >>>>> peer in RELOAD distinguish if the connection is to a peer or to a=20 >>>>> client? >>>>> Because the reaction of the peer could be different when the=20 >>>>> connection is lost. >>>>> >>>> Reload does distinguish at some level but what do you think a node=20 >>>> needs to do differently when a connection is lost if the connection >>>> when to a peer or client. Clearly how data replication is handled=20 >>>> and some of the finger table stuff is handled differently but I=20 >>>> think that >>>> >>> >>> >>>> is covered in the draft. If you see something specific missing, let >>>> me >>>> >>> >>> >>>> know. >>>> >>>> >>>>> As a client could set up a connection only with an arbitrary peer. >>>>> Does >>>>> this peer distinguish such connection from those it is responsible >>>>> to? >>>>> >>>> I don't se the need to. >>>> >>>> >>>>> Should this peer inform the client's responsible peer about the=20 >>>>> Destination List to the client? So that it can still be accessed=20 >>>>> by other nodes. Or should the Destination List been stored with=20 >>>>> some usage, say SIP Usage? >>>>> >>>> Yes, that is the approach to store destination lists where they are >>>> needed. >>>> >>>> >>>>> If so, the SIP usage must be extended to allow a Destination list=20 >>>>> containing more than one Node IDs. >>>>> >>>> agree that it needs to allow storing multiple Node IDs but I think=20 >>>> it already does that. >>>> >>>> >>>>> In current SIP >>>>> usage draft, the SipRegistration structure only allow one address=20 >>>>> being stored in the Destination List, as: >>>>> " Destination destination_list<0..2^16-1>;" >>>>> >>>> The destination_list here is an array of Destinations so it allows=20 >>>> between 0 and 65K entries in the array. I agree the syntax for=20 >>>> specifying arrays might seem a bit weird but I think the structure=20 >>>> is what you are pointing out we need to have. >>>> >>>> >>>>> It should be replaced by: "Destination destination_list >>>>> [dest_list_length];" >>>>> to enable a longer list stored by arbitrary connected clients. >>>>> >>>>> Anyway, IMHO, RELOAD should make sure to cover all situations a=20 >>>>> client could meet or at least clearly distinguish issues of=20 >>>>> clients, especially for arbitrary connected ones, which are left=20 >>>>> to be solved by other drafts. Thanks. >>>>> >>>>> >>>>> Best Regards, >>>>> Xiao, Lin >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On=20 >>>>> Behalf Of ext Cullen Jennings >>>>> Sent: Wednesday, October 07, 2009 1:53 AM >>>>> To: P2PSIP WG >>>>> Subject: [P2PSIP] New versions of RELOAD and sip draft >>>>> >>>>> >>>>> I just submitted >>>>> draft-ietf-p2psip-base-04 >>>>> and >>>>> draft-ietf-p2psip-sip-02 >>>>> >>>>> These contain technical changes but do not have a lot of editorial >>>>> changes. At some point we need to go and reorganize the documents=20 >>>>> with editorial changes. >>>>> >>>>> Cullen >>>>> >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From christian.1.schmidt@nsn.com Mon Oct 26 03:25:04 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FA0528C1A9 for ; Mon, 26 Oct 2009 03:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztxGI2wDuArs for ; Mon, 26 Oct 2009 03:25:02 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 86F8328C1A5 for ; Mon, 26 Oct 2009 03:25:00 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9QAOtjk017033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Oct 2009 11:24:56 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9QAOpA1003245; Mon, 26 Oct 2009 11:24:55 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 11:24:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 11:24:43 +0100 Message-ID: In-Reply-To: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4D9D6A3@CNBEEXC007.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Consensus call on security draft Thread-Index: AcpHjWOSXhgivGmlQ8CXlayuFzHZlAAsgSwgACT68WAAEx3fwAAGuEswABQPLdACXAq4kADKz9Ew References: <007801ca498b$c0599aa0$1d0ca40a@china.huawei.com> <5D84FDD8D5DC8646B9F73CF1EFD1BFA4D9D6A3@CNBEEXC007.nsn-intra.net> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "Xiao, Lin (NSN - CN/Beijing)" , "ext Song Haibin" , "DRAGE, Keith (Keith)" , "Roni Even" , "Eric Rescorla" , "David A. Bryan" X-OriginalArrivalTime: 26 Oct 2009 10:24:52.0256 (UTC) FILETIME=[8DE10200:01CA5626] Cc: P2PSIP WG Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 10:25:04 -0000 I am in favour to adopt this version as WG item. BR Christian Schmidt =20 -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of ext Xiao, Lin (NSN - CN/Beijing) Sent: Thursday, October 22, 2009 11:45 AM To: ext Song Haibin; DRAGE, Keith (Keith); Roni Even; Eric Rescorla; David A. Bryan Cc: P2PSIP WG Subject: Re: [P2PSIP] Consensus call on security draft Hi Haibin, Well done! I think this draft should be adopted as WG Item now, as consensus got in IETF#75. Thanks. Br Xiao, Lin=20 -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of ext Song Haibin Sent: Saturday, October 10, 2009 5:27 PM To: 'DRAGE, Keith (Keith)'; 'Roni Even'; 'Eric Rescorla'; 'David A. Bryan' Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Consensus call on security draft Hi, Just updated the document a bit with removing RFC 2119 requirement languages (no reference to RFC 2119 in this document). The link for the new version is as below: http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-security-ov ervi ew-01.txt Thanks! Haibin =20 >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On=20 >Behalf Of DRAGE, Keith (Keith) >Sent: Saturday, October 10, 2009 7:51 AM >To: Roni Even; 'Eric Rescorla'; 'David A. Bryan' >Cc: 'P2PSIP WG' >Subject: Re: [P2PSIP] Consensus call on security draft > >If I take the first two "must" usages in the document: > >"Thus, the architecture must consider this > issue in the process of both enrollment and modification of P2PSIP > resource (user) records in a P2PSIP overlay." > >"Nevertheless those > attacks must be addressed by designers of service specific protocols > such as SIP [RFC3261]." > >Are either of these statements even relevant to a document of tutorial, >i.e. educational nature, that the working group defined this to be. > >So essentially I am saying, irrespective of whether a reference to RFC=20 >2119 carries a normative nature or not, just changing the "MUST" to a=20 >"must" does not achieve the purpose you are trying to write this=20 >document for. > >The document, according to the scope defined by the working group,=20 >should be concentrating on the security issues, rather than writing=20 >statements about how the security should be addressed. > >regards > >Keith > >> -----Original Message----- >> From: Roni Even [mailto:Even.roni@huawei.com] >> Sent: Friday, October 09, 2009 9:40 PM >> To: DRAGE, Keith (Keith); 'Eric Rescorla'; 'David A. Bryan' >> Cc: 'P2PSIP WG' >> Subject: RE: [P2PSIP] Consensus call on security draft >>=20 >> Hi Keith, >> My question was about what does it mean to have words like "must",=20 >> "should" >> when you do not reference RFC 2119.=20 >> My take is that RFC 2119 defines the normative terminology and if it=20 >> does not say that the document refers to RFC 2119 >terminology than it >> does not. >> In this case there is no normative terms in a document. >> I was also confused about the text in RFC 2119 and do not understand=20 >> how is the force of the words changes based on the requirement level=20 >> of the document . >> This is why I claim that by my understanding of RFC 2119, if you do=20 >> not reference it than there is no normative text in the >document does >> not matter if it lower or upper case. Also having the document as=20 >> informational weakens any strength of text in a document >Regards Roni >> Even >>=20 >> > -----Original Message----- >> > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On=20 >> > Behalf Of DRAGE, Keith (Keith) >> > Sent: Friday, October 09, 2009 1:31 PM >> > To: Roni Even; 'Eric Rescorla'; 'David A. Bryan' >> > Cc: 'P2PSIP WG' >> > Subject: Re: [P2PSIP] Consensus call on security draft >> >=20 >> > My view is that using RFC 2119 words in a document even in >> lower case >> > is bad practice. It takes a slip of the editing pen for >> them later to >> > become uppercase. >> >=20 >> > They also raise questions on review as to whether they should have=20 >> > been upper case, at which point people promptly forget all >previous >> > decisions on the matter and make them upper case. >> >=20 >> > Moreover, evaluating such current usage will undoubtedly make the=20 >> > document become clearer. Just changing upper case to lower >> case will >> > not result in a clear informational document. >> >=20 >> > So I would support Eric in asking for a version of this >> document that >> > does not include any of the RFC 2119 language words, unless >> of course >> > there is agreement that normative material should later be >included. >> > (There are some exceptions to this, e.g. quotation from >> another RFC). >> > It appears to me that nobody is diputing that the current >> consensus is >> > that the document should be tutorial. >> >=20 >> > regards >> >=20 >> > Keith >> >=20 >> > > -----Original Message----- >> > > From: p2psip-bounces@ietf.org >> > > [mailto:p2psip-bounces@ietf.org] On Behalf Of Roni Even >> > > Sent: Thursday, October 08, 2009 6:53 PM >> > > To: 'Eric Rescorla'; 'David A. Bryan' >> > > Cc: 'P2PSIP WG' >> > > Subject: Re: [P2PSIP] Consensus call on security draft >> > > >> > > Hi Eric, >> > > About RFC 2119 language. >> > > My understanding is that since there is no reference to RFC >> > > 2119 which says that >> > > >> > > "In many standards track documents several words are used >> to signify >> > > the requirements in the specification. These words are often >> > > capitalized. This document defines these words as >> they should be >> > > interpreted in IETF documents. Authors who follow these >> > guidelines >> > > should incorporate this phrase near the beginning of their >> > > document: >> > > >> > > The key words "MUST", "MUST NOT", "REQUIRED", >> "SHALL", "SHALL >> > > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >> > > "OPTIONAL" in this document are to be interpreted >> as described >> > > in >> > > RFC 2119. >> > > >> > > Note that the force of these words is modified by the >> requirement >> > > level of the document in which they are used." >> > > >> > > >> > > My understanding is that there is no normative text in >> the document.=20 >> > > The meaning of "must" and "should" when not specified by >RFC 2119 >> > > does not make them normative. >> > > Furthermore the document will be an Informational document >> > > >> > > Roni Even >> > > >> > > > -----Original Message----- >> > > > From: p2psip-bounces@ietf.org >> [mailto:p2psip-bounces@ietf.org] On >> > > > Behalf Of Eric Rescorla >> > > > Sent: Wednesday, October 07, 2009 10:39 PM >> > > > To: David A. Bryan >> > > > Cc: P2PSIP WG >> > > > Subject: Re: [P2PSIP] Consensus call on security draft >> > > > >> > > > At Wed, 7 Oct 2009 12:30:40 -0400, David A. Bryan wrote: >> > > > > >> > > > > Eric, >> > > > > >> > > > > I don't agree this is premature in any way. >> > > > > >> > > > > We've allowed over a week on this topic. >> > > > >> > > > Well, David, since you insist: your mail asking for a >> > > consensus call >> > > > was sent at 12:25 EST on the 30th and stated: >> > > > >> > > > As the authors feel they have made the requested >> > > changes, I'd like >> > > > to >> > > > ask folks on list to confirm this consensus. Please >> > > send comments >> > > > about adoption to the list, and we'll make a call after >> > > there has >> > > > been >> > > > time to review and comment (at least a week). >> > > > >> > > > This mail declaring consensus was posted at 12:16 EST >today, so >> > > > the amount of time you have allowed, rather than being >> "at least a >> > week" >> > > > is actually just under a week, so even by the most generous=20 >> > > > interpretation of the situation, this is slightly >> premature. Given >> > > > that you did not provide any real deadline, it is quite >> premature. >> > > > >> > > > >> > > > > You never posted saying you >> > > > > were reviewing, you have made no comments on list about the=20 >> > > > > draft since Stockholm. Bruce started a thread on the previous >> > > version way >> > > > > back on July 25th, and you didn't comment. >> > > > >> > > > Because I had already made comments on the previous version >> > > during the >> > > > meeting. >> > > > >> > > > >> > > > > Are there others besides yourself (and Cullen)? If so, >> > > speak up now. >> > > > > Otherwise, we had consensus in the room and allowed a >> reasonable >> > > > > time for comments on list. >> > > > >> > > > While I agree, we had consensus in the room, this document >> > > does not in >> > > > fact live up to that consensus. I've just listened to >> the relevant >> > > > section of the WG meeting and it was quite clear that >> what the WG >> > > > hummed for was as a general tutorial/overview of security >> > > in the P2P >> > > > space. However, it was extremely clear that this >> document was to >> > > > be non-normative, as stated by Roni, Brian, and myself. >> > > Moreover, this is >> > > > confirmed by Dan's message when this document was posted: >> > > > >> > > > At IETF 75, we were given the direction to remove the >> RFC 2119 >> > > > language from >> > > > the document and move it from being a normative doc >> to a purely >> > > > informational doc. I have now started this and made >> a number of >> > > > other >> > > > changes, including most notably the name change from >> > > > "p2psip-security-requirements" to "p2psip-security-overview": >> > > > >> > > > While the 2119 language was removed, which is a start (and >> > > I realize I >> > > > focused on this over Jabber, but limited bandwidth is >a cost of >> > > > not being in the room), the document is full of normative text, >> > > albeit not >> > > > rendered in upper case. I count 23 separate instances >> of the word >> > > > "must" and "30" of the word "should". For example: >> > > > >> > > > S 5.1. >> > > > protected against attacks(such as Man-in-the-Middle). >> > > In order to >> > > > establish the identity trust association, nodes must >> > authenticate >> > > > each other with e.g. TLS and DTLS. If transport >> > > service security >> > > > is >> > > > provided, we can prevent nodes without valid identities to >> > > > participate in the overlay. This layer must provides >> > > reliable and >> > > > secure hop-by-hop transport service for the P2P >> overlay. This >> > > > alone, >> > > > though, is not enough to secure the P2P system. >> > > > >> > > > S 8.1. >> > > > The user wants available and reliable service that >> enables him >> > to >> > > > interact with other users and resources in a secure way. >> > > This means >> > > > that the P2PSIP system must provide: >> > > > >> > > > Worse yet, some of these actually contradict design >> decisions that >> > > > have already been made in RELOAD: >> > > > >> > > > S 8.2.11. >> > > > The security of P2PSIP systems must guarantee privacy of >> > > the P2PSIP >> > > > network participants. The P2PSIP security should allow >> > > the users >> > > > and >> > > > P2PSIP network entities to indicate which other >> users or P2PSIP >> > > > network entities can retrieve, modify, and delete >> data stored in >> > > > their P2PSIP resource (user) records. The owner of >a P2PSIP >> > > > resource >> > > > (user) record should be able to limit the access to his >> > > own resource >> > > > (user) records, and this feature should be enforced >> by the P2P >> > > > network. >> > > > >> > > > This is a particularly egregious case since there is no known=20 >> > > > mechanism for securely providing read-level access in a P2P=20 >> > > > storage network, which is why RELOAD assumes that data >> > > confidentiality will be >> > > > solved by encryption rather than access control. >> > > > >> > > > This material is not even remotely tutorial in nature.=20 >> Quite the >> > > > contrary, it is requirements text, regardless of the fact that=20 >> > > > it's not capitalized. In order for this document to >conform to >> > > > the consensus in Stockholm, then, all this language needs to be >> > > removed. >> > > > If the authors/WG feel it is important, it might be >> replaced with >> > > > descriptions of the security consequences of various design >> > > choices. >> > > > However, as it stands, no I don't agree that this document >> > > either is >> > > > acceptable or that it has consensus: the consensus in >Stockholm >> > > > was contingent on changes that have not been made, and the=20 >> > > > overwhelming silence on the mailing list after this >revision is >> > > > not at >> > > all the same >> > > > as consensus. >> > > > >> > > > -Ekr >> > > > _______________________________________________ >> > > > P2PSIP mailing list >> > > > P2PSIP@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/p2psip >> > > > >> > > > __________ Information from ESET NOD32 Antivirus, >> version of virus >> > > > signature database 4488 (20091007) __________ >> > > > >> > > > The message was checked by ESET NOD32 Antivirus. >> > > > >> > > > http://www.eset.com >> > > > >> > > > >> > > > >> > > > >> > > > __________ Information from ESET NOD32 Antivirus, >> version of virus >> > > > signature database 4488 (20091007) __________ >> > > > >> > > > The message was checked by ESET NOD32 Antivirus. >> > > > >> > > > http://www.eset.com >> > > > >> > > > >> > > > __________ Information from ESET NOD32 Antivirus, >> version of virus >> > > > signature database 4491 (20091008) __________ >> > > > >> > > > The message was checked by ESET NOD32 Antivirus. >> > > > >> > > > http://www.eset.com >> > > > >> > > >> > > >> > > __________ Information from ESET NOD32 Antivirus, version >> of virus >> > > signature database 4491 (20091008) __________ >> > > >> > > The message was checked by ESET NOD32 Antivirus. >> > > >> > > http://www.eset.com >> > > >> > > >> > > _______________________________________________ >> > > P2PSIP mailing list >> > > P2PSIP@ietf.org >> > > https://www.ietf.org/mailman/listinfo/p2psip >> > > >> > _______________________________________________ >> > P2PSIP mailing list >> > P2PSIP@ietf.org >> > https://www.ietf.org/mailman/listinfo/p2psip >> >=20 >> > __________ Information from ESET NOD32 Antivirus, version of virus=20 >> > signature database 4494 (20091009) __________ >> >=20 >> > The message was checked by ESET NOD32 Antivirus. >> >=20 >> > http://www.eset.com >> >=20 >> >=20 >> >=20 >> >=20 >> > __________ Information from ESET NOD32 Antivirus, version of virus=20 >> > signature database 4494 (20091009) __________ >> >=20 >> > The message was checked by ESET NOD32 Antivirus. >> >=20 >> > http://www.eset.com >> >=20 >> =20 >>=20 >> __________ Information from ESET NOD32 Antivirus, version of virus=20 >> signature database 4494 (20091009) __________ >>=20 >> The message was checked by ESET NOD32 Antivirus. >>=20 >> http://www.eset.com >> =20 >>=20 >>=20 >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From melodysong@huawei.com Mon Oct 26 03:44:57 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACE243A68EF for ; Mon, 26 Oct 2009 03:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.802 X-Spam-Level: * X-Spam-Status: No, score=1.802 tagged_above=-999 required=5 tests=[AWL=-0.903, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_74=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjKfQtiwQETf for ; Mon, 26 Oct 2009 03:44:56 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 962813A68D3 for ; Mon, 26 Oct 2009 03:44:55 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS4003ZDB6WT6@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 26 Oct 2009 18:44:56 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS400CHJB6WNZ@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 26 Oct 2009 18:44:56 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS400KIOB6VJG@szxml04-in.huawei.com> for p2psip@ietf.org; Mon, 26 Oct 2009 18:44:55 +0800 (CST) Date: Mon, 26 Oct 2009 18:44:55 +0800 From: Song Haibin In-reply-to: To: "'Schmidt, Christian 1. (NSN - DE/Munich)'" , "'Xiao, Lin (NSN - CN/Beijing)'" , "'DRAGE, Keith (Keith)'" , 'Roni Even' , 'Eric Rescorla' , "'David A. Bryan'" Message-id: <031601ca5629$5b5dc400$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpHjWOSXhgivGmlQ8CXlayuFzHZlAAsgSwgACT68WAAEx3fwAAGuEswABQPLdACXAq4kADKz9EwAACx7CA= Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 10:44:57 -0000 Hi Christian, Thank you for your comments to this document and for your support for adoption. Haibin >-----Original Message----- >From: Schmidt, Christian 1. (NSN - DE/Munich) >[mailto:christian.1.schmidt@nsn.com] >Sent: Monday, October 26, 2009 6:25 PM >To: Xiao, Lin (NSN - CN/Beijing); ext Song Haibin; DRAGE, >Keith (Keith); Roni Even; Eric Rescorla; David A. Bryan >Cc: P2PSIP WG >Subject: RE: [P2PSIP] Consensus call on security draft > >I am in favour to adopt this version as WG item. > >BR >Christian Schmidt > > > >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] >On Behalf Of ext Xiao, Lin (NSN - CN/Beijing) >Sent: Thursday, October 22, 2009 11:45 AM >To: ext Song Haibin; DRAGE, Keith (Keith); Roni Even; Eric >Rescorla; David A. Bryan >Cc: P2PSIP WG >Subject: Re: [P2PSIP] Consensus call on security draft > >Hi Haibin, > >Well done! I think this draft should be adopted as WG Item >now, as consensus got in IETF#75. Thanks. > > >Br >Xiao, Lin > >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] >On Behalf Of ext Song Haibin >Sent: Saturday, October 10, 2009 5:27 PM >To: 'DRAGE, Keith (Keith)'; 'Roni Even'; 'Eric Rescorla'; 'David A. >Bryan' >Cc: 'P2PSIP WG' >Subject: Re: [P2PSIP] Consensus call on security draft > >Hi, > >Just updated the document a bit with removing RFC 2119 >requirement languages (no reference to RFC 2119 in this >document). The link for the new version is as below: > >http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-se >curity-ov >ervi >ew-01.txt > > >Thanks! >Haibin > > > >>-----Original Message----- >>From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >>Behalf Of DRAGE, Keith (Keith) >>Sent: Saturday, October 10, 2009 7:51 AM >>To: Roni Even; 'Eric Rescorla'; 'David A. Bryan' >>Cc: 'P2PSIP WG' >>Subject: Re: [P2PSIP] Consensus call on security draft >> >>If I take the first two "must" usages in the document: >> >>"Thus, the architecture must consider this >> issue in the process of both enrollment and modification of P2PSIP >> resource (user) records in a P2PSIP overlay." >> >>"Nevertheless those >> attacks must be addressed by designers of service specific >protocols >> such as SIP [RFC3261]." >> >>Are either of these statements even relevant to a document of >tutorial, > >>i.e. educational nature, that the working group defined this to be. >> >>So essentially I am saying, irrespective of whether a reference to RFC >>2119 carries a normative nature or not, just changing the "MUST" to a >>"must" does not achieve the purpose you are trying to write this >>document for. >> >>The document, according to the scope defined by the working group, >>should be concentrating on the security issues, rather than writing >>statements about how the security should be addressed. >> >>regards >> >>Keith >> >>> -----Original Message----- >>> From: Roni Even [mailto:Even.roni@huawei.com] >>> Sent: Friday, October 09, 2009 9:40 PM >>> To: DRAGE, Keith (Keith); 'Eric Rescorla'; 'David A. Bryan' >>> Cc: 'P2PSIP WG' >>> Subject: RE: [P2PSIP] Consensus call on security draft >>> >>> Hi Keith, >>> My question was about what does it mean to have words like "must", >>> "should" >>> when you do not reference RFC 2119. >>> My take is that RFC 2119 defines the normative terminology >and if it >>> does not say that the document refers to RFC 2119 >>terminology than it >>> does not. >>> In this case there is no normative terms in a document. >>> I was also confused about the text in RFC 2119 and do not >understand >>> how is the force of the words changes based on the >requirement level >>> of the document . >>> This is why I claim that by my understanding of RFC 2119, >if you do >>> not reference it than there is no normative text in the >>document does >>> not matter if it lower or upper case. Also having the document as >>> informational weakens any strength of text in a document >>Regards Roni >>> Even >>> >>> > -----Original Message----- >>> > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >>> > Behalf Of DRAGE, Keith (Keith) >>> > Sent: Friday, October 09, 2009 1:31 PM >>> > To: Roni Even; 'Eric Rescorla'; 'David A. Bryan' >>> > Cc: 'P2PSIP WG' >>> > Subject: Re: [P2PSIP] Consensus call on security draft >>> > >>> > My view is that using RFC 2119 words in a document even in >>> lower case >>> > is bad practice. It takes a slip of the editing pen for >>> them later to >>> > become uppercase. >>> > >>> > They also raise questions on review as to whether they >should have >>> > been upper case, at which point people promptly forget all >>previous >>> > decisions on the matter and make them upper case. >>> > >>> > Moreover, evaluating such current usage will undoubtedly make the >>> > document become clearer. Just changing upper case to lower >>> case will >>> > not result in a clear informational document. >>> > >>> > So I would support Eric in asking for a version of this >>> document that >>> > does not include any of the RFC 2119 language words, unless >>> of course >>> > there is agreement that normative material should later be >>included. >>> > (There are some exceptions to this, e.g. quotation from >>> another RFC). >>> > It appears to me that nobody is diputing that the current >>> consensus is >>> > that the document should be tutorial. >>> > >>> > regards >>> > >>> > Keith >>> > >>> > > -----Original Message----- >>> > > From: p2psip-bounces@ietf.org >>> > > [mailto:p2psip-bounces@ietf.org] On Behalf Of Roni Even >>> > > Sent: Thursday, October 08, 2009 6:53 PM >>> > > To: 'Eric Rescorla'; 'David A. Bryan' >>> > > Cc: 'P2PSIP WG' >>> > > Subject: Re: [P2PSIP] Consensus call on security draft >>> > > >>> > > Hi Eric, >>> > > About RFC 2119 language. >>> > > My understanding is that since there is no reference to RFC >>> > > 2119 which says that >>> > > >>> > > "In many standards track documents several words are used >>> to signify >>> > > the requirements in the specification. These words are often >>> > > capitalized. This document defines these words as >>> they should be >>> > > interpreted in IETF documents. Authors who follow these >>> > guidelines >>> > > should incorporate this phrase near the beginning of their >>> > > document: >>> > > >>> > > The key words "MUST", "MUST NOT", "REQUIRED", >>> "SHALL", "SHALL >>> > > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >>> > > "OPTIONAL" in this document are to be interpreted >>> as described >>> > > in >>> > > RFC 2119. >>> > > >>> > > Note that the force of these words is modified by the >>> requirement >>> > > level of the document in which they are used." >>> > > >>> > > >>> > > My understanding is that there is no normative text in >>> the document. >>> > > The meaning of "must" and "should" when not specified by >>RFC 2119 >>> > > does not make them normative. >>> > > Furthermore the document will be an Informational document >>> > > >>> > > Roni Even >>> > > >>> > > > -----Original Message----- >>> > > > From: p2psip-bounces@ietf.org >>> [mailto:p2psip-bounces@ietf.org] On >>> > > > Behalf Of Eric Rescorla >>> > > > Sent: Wednesday, October 07, 2009 10:39 PM >>> > > > To: David A. Bryan >>> > > > Cc: P2PSIP WG >>> > > > Subject: Re: [P2PSIP] Consensus call on security draft >>> > > > >>> > > > At Wed, 7 Oct 2009 12:30:40 -0400, David A. Bryan wrote: >>> > > > > >>> > > > > Eric, >>> > > > > >>> > > > > I don't agree this is premature in any way. >>> > > > > >>> > > > > We've allowed over a week on this topic. >>> > > > >>> > > > Well, David, since you insist: your mail asking for a >>> > > consensus call >>> > > > was sent at 12:25 EST on the 30th and stated: >>> > > > >>> > > > As the authors feel they have made the requested >>> > > changes, I'd like >>> > > > to >>> > > > ask folks on list to confirm this consensus. Please >>> > > send comments >>> > > > about adoption to the list, and we'll make a call after >>> > > there has >>> > > > been >>> > > > time to review and comment (at least a week). >>> > > > >>> > > > This mail declaring consensus was posted at 12:16 EST >>today, so >>> > > > the amount of time you have allowed, rather than being >>> "at least a >>> > week" >>> > > > is actually just under a week, so even by the most generous >>> > > > interpretation of the situation, this is slightly >>> premature. Given >>> > > > that you did not provide any real deadline, it is quite >>> premature. >>> > > > >>> > > > >>> > > > > You never posted saying you >>> > > > > were reviewing, you have made no comments on list about the >>> > > > > draft since Stockholm. Bruce started a thread on >the previous >>> > > version way >>> > > > > back on July 25th, and you didn't comment. >>> > > > >>> > > > Because I had already made comments on the previous version >>> > > during the >>> > > > meeting. >>> > > > >>> > > > >>> > > > > Are there others besides yourself (and Cullen)? If so, >>> > > speak up now. >>> > > > > Otherwise, we had consensus in the room and allowed a >>> reasonable >>> > > > > time for comments on list. >>> > > > >>> > > > While I agree, we had consensus in the room, this document >>> > > does not in >>> > > > fact live up to that consensus. I've just listened to >>> the relevant >>> > > > section of the WG meeting and it was quite clear that >>> what the WG >>> > > > hummed for was as a general tutorial/overview of security >>> > > in the P2P >>> > > > space. However, it was extremely clear that this >>> document was to >>> > > > be non-normative, as stated by Roni, Brian, and myself. >>> > > Moreover, this is >>> > > > confirmed by Dan's message when this document was posted: >>> > > > >>> > > > At IETF 75, we were given the direction to remove the >>> RFC 2119 >>> > > > language from >>> > > > the document and move it from being a normative doc >>> to a purely >>> > > > informational doc. I have now started this and made >>> a number of >>> > > > other >>> > > > changes, including most notably the name change from >>> > > > "p2psip-security-requirements" to >"p2psip-security-overview": >>> > > > >>> > > > While the 2119 language was removed, which is a start (and >>> > > I realize I >>> > > > focused on this over Jabber, but limited bandwidth is >>a cost of >>> > > > not being in the room), the document is full of >normative text, >>> > > albeit not >>> > > > rendered in upper case. I count 23 separate instances >>> of the word >>> > > > "must" and "30" of the word "should". For example: >>> > > > >>> > > > S 5.1. >>> > > > protected against attacks(such as Man-in-the-Middle). >>> > > In order to >>> > > > establish the identity trust association, nodes must >>> > authenticate >>> > > > each other with e.g. TLS and DTLS. If transport >>> > > service security >>> > > > is >>> > > > provided, we can prevent nodes without valid identities to >>> > > > participate in the overlay. This layer must provides >>> > > reliable and >>> > > > secure hop-by-hop transport service for the P2P >>> overlay. This >>> > > > alone, >>> > > > though, is not enough to secure the P2P system. >>> > > > >>> > > > S 8.1. >>> > > > The user wants available and reliable service that >>> enables him >>> > to >>> > > > interact with other users and resources in a secure way. >>> > > This means >>> > > > that the P2PSIP system must provide: >>> > > > >>> > > > Worse yet, some of these actually contradict design >>> decisions that >>> > > > have already been made in RELOAD: >>> > > > >>> > > > S 8.2.11. >>> > > > The security of P2PSIP systems must guarantee privacy of >>> > > the P2PSIP >>> > > > network participants. The P2PSIP security should allow >>> > > the users >>> > > > and >>> > > > P2PSIP network entities to indicate which other >>> users or P2PSIP >>> > > > network entities can retrieve, modify, and delete >>> data stored in >>> > > > their P2PSIP resource (user) records. The owner of >>a P2PSIP >>> > > > resource >>> > > > (user) record should be able to limit the access to his >>> > > own resource >>> > > > (user) records, and this feature should be enforced >>> by the P2P >>> > > > network. >>> > > > >>> > > > This is a particularly egregious case since there is no known >>> > > > mechanism for securely providing read-level access in a P2P >>> > > > storage network, which is why RELOAD assumes that data >>> > > confidentiality will be >>> > > > solved by encryption rather than access control. >>> > > > >>> > > > This material is not even remotely tutorial in nature. >>> Quite the >>> > > > contrary, it is requirements text, regardless of the >fact that >>> > > > it's not capitalized. In order for this document to >>conform to >>> > > > the consensus in Stockholm, then, all this language >needs to be >>> > > removed. >>> > > > If the authors/WG feel it is important, it might be >>> replaced with >>> > > > descriptions of the security consequences of various design >>> > > choices. >>> > > > However, as it stands, no I don't agree that this document >>> > > either is >>> > > > acceptable or that it has consensus: the consensus in >>Stockholm >>> > > > was contingent on changes that have not been made, and the >>> > > > overwhelming silence on the mailing list after this >>revision is >>> > > > not at >>> > > all the same >>> > > > as consensus. >>> > > > >>> > > > -Ekr >>> > > > _______________________________________________ >>> > > > P2PSIP mailing list >>> > > > P2PSIP@ietf.org >>> > > > https://www.ietf.org/mailman/listinfo/p2psip >>> > > > >>> > > > __________ Information from ESET NOD32 Antivirus, >>> version of virus >>> > > > signature database 4488 (20091007) __________ >>> > > > >>> > > > The message was checked by ESET NOD32 Antivirus. >>> > > > >>> > > > http://www.eset.com >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > __________ Information from ESET NOD32 Antivirus, >>> version of virus >>> > > > signature database 4488 (20091007) __________ >>> > > > >>> > > > The message was checked by ESET NOD32 Antivirus. >>> > > > >>> > > > http://www.eset.com >>> > > > >>> > > > >>> > > > __________ Information from ESET NOD32 Antivirus, >>> version of virus >>> > > > signature database 4491 (20091008) __________ >>> > > > >>> > > > The message was checked by ESET NOD32 Antivirus. >>> > > > >>> > > > http://www.eset.com >>> > > > >>> > > >>> > > >>> > > __________ Information from ESET NOD32 Antivirus, version >>> of virus >>> > > signature database 4491 (20091008) __________ >>> > > >>> > > The message was checked by ESET NOD32 Antivirus. >>> > > >>> > > http://www.eset.com >>> > > >>> > > >>> > > _______________________________________________ >>> > > P2PSIP mailing list >>> > > P2PSIP@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/p2psip >>> > > >>> > _______________________________________________ >>> > P2PSIP mailing list >>> > P2PSIP@ietf.org >>> > https://www.ietf.org/mailman/listinfo/p2psip >>> > >>> > __________ Information from ESET NOD32 Antivirus, version >of virus >>> > signature database 4494 (20091009) __________ >>> > >>> > The message was checked by ESET NOD32 Antivirus. >>> > >>> > http://www.eset.com >>> > >>> > >>> > >>> > >>> > __________ Information from ESET NOD32 Antivirus, version >of virus >>> > signature database 4494 (20091009) __________ >>> > >>> > The message was checked by ESET NOD32 Antivirus. >>> > >>> > http://www.eset.com >>> > >>> >>> >>> __________ Information from ESET NOD32 Antivirus, version of virus >>> signature database 4494 (20091009) __________ >>> >>> The message was checked by ESET NOD32 Antivirus. >>> >>> http://www.eset.com >>> >>> >>> >>_______________________________________________ >>P2PSIP mailing list >>P2PSIP@ietf.org >>https://www.ietf.org/mailman/listinfo/p2psip >> > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip > From jouni.maenpaa@ericsson.com Mon Oct 26 03:45:13 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C75D28C233 for ; Mon, 26 Oct 2009 03:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEPsHEEpNbOT for ; Mon, 26 Oct 2009 03:45:12 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 72AD128C231 for ; Mon, 26 Oct 2009 03:45:10 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-0e-4ae57dc2b003 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 81.0A.24026.2CD75EA4; Mon, 26 Oct 2009 11:45:22 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 11:45:22 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 11:45:22 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1CC38256F; Mon, 26 Oct 2009 12:45:22 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D45AB21A22; Mon, 26 Oct 2009 12:45:21 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 89CAC21A21; Mon, 26 Oct 2009 12:45:21 +0200 (EET) Message-ID: <4AE57DC2.3060402@ericsson.com> Date: Mon, 26 Oct 2009 12:45:22 +0200 From: =?ISO-8859-1?Q?Jouni_M=E4enp=E4=E4?= User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: "p2psip@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 26 Oct 2009 10:45:22.0337 (UTC) FILETIME=[6B107910:01CA5629] X-Brightmail-Tracker: AAAAAA== Subject: [P2PSIP] New Version Notification for draft-maenpaa-p2psip-self-tuning-01 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 10:45:13 -0000 Hi, We have just submitted a new version of the draft "A Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)". The initial revision of the draft was presented in IETF 74 in San Francisco. The most important change is that instead of defining a new topology plugin for RELOAD as the previous version did, the new version describes how the default topology plugin of RELOAD can be extended to support self-tuning. In addition, the new version no longer defines any load balancing mechanisms. Abstract: REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay, and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. A URL for this Internet-Draft is: http://www.ietf.org/id/draft-maenpaa-p2psip-self-tuning-01.txt Comments are welcome! Regards, Jouni Maenpaa ------------------------------- A new version of I-D, draft-maenpaa-p2psip-self-tuning-01.txt has been successfuly submitted by Jouni Maenpaa and posted to the IETF repository. Filename: draft-maenpaa-p2psip-self-tuning Revision: 01 Title: A Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD) Creation_date: 2009-10-26 WG ID: Independent Submission Number_of_pages: 20 Abstract: REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay, and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. From fluffy@cisco.com Mon Oct 26 08:45:53 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791513A6877 for ; Mon, 26 Oct 2009 08:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtSlKRbp8GkH for ; Mon, 26 Oct 2009 08:45:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A43E93A68DD for ; Mon, 26 Oct 2009 08:45:51 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisAAFNh5UqQ/uCWe2dsb2JhbACbOAEBFiQGpVuJKAeNVIQ/BA X-IronPort-AV: E=Sophos;i="4.44,626,1249257600"; d="scan'208";a="52796720" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2009 15:46:03 +0000 Received: from ams3-vpn-dhcp5684.cisco.com (ams3-vpn-dhcp5684.cisco.com [10.61.86.51]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9QFk3iK006823; Mon, 26 Oct 2009 15:46:03 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Cullen Jennings In-Reply-To: <020301ca55e4$8878c100$1d0ca40a@china.huawei.com> Date: Mon, 26 Oct 2009 16:46:03 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <020301ca55e4$8878c100$1d0ca40a@china.huawei.com> To: Song Haibin X-Mailer: Apple Mail (2.1076) Cc: P2PSIP WG Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:45:53 -0000 On Oct 26, 2009, at 3:32 , Song Haibin wrote: > Hi, > > I have not finished the review, but I have several questions on this > document. > > 1). I am not sure how the TRUN usage defined in this document will > work > well. Who will be responsible for calculating the turnDensity and how? The idea was to specify the minimal simple thing and allow for much more advanced things to be developed in the future. Right now, the operator of the DHT would specify the turnDensity - they could presumable measure by probing the overlay. Keep in mind the two interesting values for overlays are no one is a TURN server and everyone is a TURN server. > How > to update the TURN server information in the overlay when some TURN > servers > leave the overlay suddenly, to avoid getting the "old" information? The data times out and goes away and and this is part of the reason for finding a bunch. > > 2). In section 4.1.1 "Storage Permissions" said "RELOAD addresses > this issue > by only allowing any given node to store data at > a small number of locations in the overlay, with those locations > being > determined by the node's certificate." This rule will limit the > applications > that the protocol could support. E.g, for streaming or file-sharing > applications, it is very practical to put the resource providers' > address > information under the same Resource ID which is the hash of the > content > name, despite the node ID or username information contained in the > certificate of the resource provider. Sure, but without this rules peers are would have to store an unlimited amount of data on behalf of others. A key premise of this work since before the WG was charter was that the protocol should be possible to use in a way where one could deploy a overlay for some application usage and not have it become used for file sharing. Note that if the overlay wants to allow kinds that have no authorization rules and allow anyone to write anywhere, there is nothing the spec that forbids that. It's up to the usage. So if someone wants to make a file-sharing usage, well storing the whole file in the DHT is probably not the best design but one could certainly make a usage that did exactly that. > > 3). How do you prevent "via list" being modified by the intermediate > peers? > This is very important because it is related to whether you can get > a right > returen path for your response. Well we can't really secure this in any practical way, or more importantly, we can prevent the intermediate peers from misrouting the request. The misroute of the response is no more serious than the misroute of the request. It's a pretty fundamental limitation of an overlay system like this. However, the overlay security of the system does not depend on stopping this. This can be used to DOS the systems but not much else. Keep in mind, the same is true of IP that is running over. > > 4). In section 5.4.2.4.2., RouteQuery response should at least > include a > next hop peer infomation if you want to use this message for the > iterative > routing. Agree this is needed but it is somewhat DHT specific. I forget the details but I think it was Salman who pointed out that for some unstructured overlays, you would need something other than the next hop. Because of that, we made the answer DHT specific. For the Chord DHT specified here, 100% agree with you we need the next hop and the message to return that is defined in Section 9.8 > > 5). I'm not sure about the necessity of access control policies in > section > 6.3. I think it will make sense only when these access control > policies are > generic to all usages that will be built on top of RELOAD. Other > than that, > I would suggest to remove this section and define these policies in > each > usage document. Comment 2 is also related to this topic. Clearly many usage documents can share many of the basic policies so I think it make more sense to define at least the ones needed for the charter of this WG in the base draft. > > Thanks! > Haibin Thanks for reviewing it - much appreciated. Cullen > > > >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] >> On Behalf Of Brian Rosen >> Sent: Saturday, October 24, 2009 2:55 AM >> To: Cullen Jennings; P2PSIP WG >> Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base >> >> >> If you think the draft is missing something big, or has some >> other serious shortcoming that makes it inappropriate to hold >> a WGLC, please speak up now. >> We'll give everyone a few days to look over this version, and >> then decide if we will start it. >> >> If you had signed up to review NOW would be the time to do it, >> on this version. That was NOW, and not "soon", please. >> >> Brian >> >> >> On 10/23/09 2:38 PM, "Cullen Jennings" wrote: >> >>> >>> We just submitted a new version of the base draft at >>> >>> http://www.ietf.org/id/draft-ietf-p2psip-base-05.txt >>> >>> (there is a new version of the sip-usage as well). >>> >>> The major changes are mostly a very long and excruciating editorial >>> pass to try and improve the grammar. >>> >>> At this point, I don't know of any significant issues that >> need to be >>> resolved. I think the draft is ready for WGLC. >>> >>> I'm sure that during WGLC some major issues will come up, some >>> important decisions will be made about what needs to be >> mandatory and >>> such, and we will find several small inconsistencies and >> typos in the >>> draft as well as things that need a clearer explanation. This will >>> take some time and I expect multiple more revisions for this draft >>> before it is published, however, I do think this is the >> right time to >>> start WGLC. Lets get the issues on the table and then we can start >>> resolving them. >>> >>> Thanks, >>> Cullen >>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> > From fluffy@cisco.com Mon Oct 26 08:46:55 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79B2A28C2C1 for ; Mon, 26 Oct 2009 08:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.393 X-Spam-Level: X-Spam-Status: No, score=-108.393 tagged_above=-999 required=5 tests=[AWL=-2.206, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WKTMFDlUogr for ; Mon, 26 Oct 2009 08:46:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9322728C249 for ; Mon, 26 Oct 2009 08:46:51 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisAAFNh5UqQ/uCWe2dsb2JhbACbOAEBFiQGpVuXA4JqAYFUBA X-IronPort-AV: E=Sophos;i="4.44,626,1249257600"; d="scan'208";a="52796807" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2009 15:47:03 +0000 Received: from ams3-vpn-dhcp5684.cisco.com (ams3-vpn-dhcp5684.cisco.com [10.61.86.51]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9QFk3iL006823; Mon, 26 Oct 2009 15:47:03 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Cullen Jennings In-Reply-To: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4D9E27F@CNBEEXC007.nsn-intra.net> Date: Mon, 26 Oct 2009 16:47:03 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4D9E27F@CNBEEXC007.nsn-intra.net> To: "Xiao, Lin (NSN - CN/Beijing)" X-Mailer: Apple Mail (2.1076) Cc: Neil.Young@Freenet.de, p2psip@ietf.org Subject: Re: [P2PSIP] New versions of RELOAD and sip draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:46:55 -0000 I think peers can connect in the same ways as clients. On Oct 26, 2009, at 7:18 , Xiao, Lin (NSN - CN/Beijing) wrote: > Hi Julian, > > You are right. But it's Client Routing for clients, right? A peer, > however, can not attaches arbitrarily on the overlay. That is the > exact > difference between peers and clients in my previous e-mails. If what > you > mean is that peers can also been found by algrithm 2 when it lost its > position in the overlay, the overlay would be messed up with > disordered > topology structure finally. > > Br > Lin > > -----Original Message----- > From: ext jc [mailto:julian@orchidseed.org] > Sent: Saturday, October 24, 2009 8:08 AM > To: stas@khirman.com > Cc: Xiao, Lin (NSN - CN/Beijing); Neil.Young@Freenet.de; p2psip@ietf.org > Subject: Re: [P2PSIP] New versions of RELOAD and sip draft > > > In section 3.2.1. Client Routing contains two algorithms for Client > routing. if you choose either of those algorithms then this won't be a > problem. > > The first algorithm would forward through 500 around to 600(a direct > connection). > > The second would use the destination list and form the route to 600 by > storing information in the hash table. > > Finally, it is up to the Topology Plugin to ultimately handle this > which > Chord does so fine under this condition via it's own update > (stabilization) procedures. > > Julian > > On Oct 23, 2009, at 3:47 PM, stas@khirman.com wrote: > >> IMHO Lin Xiao has a quite valid point. If due changes of topology, >> node 500 permanently loose its ability to interconnect with close >> ( in > >> DHT space) nodes, it has to be excluded from DHT ring or have to >> get a > >> new ID. >> >> Otherwise, it will became a permanent dead-end node for lookups for >> targets in its immediate neighborhood that significantly degrades >> speed of DHT lookup and ( under some conditions) can event result in >> DHT space segmentation. >> >>> 500 can of course keep it's node id, regardless of whether 400 and/ >>> or > >>> 600 are there or not. Due to stabilization and by means of the >>> successorcache the predecessor of 400 will notice the absence and >>> bridge directly to 500 as well as 500 will skip 600 after a short >>> time and go to 700 (in order to stay in the picture). Using notify >>> the ring will close again. 400 and 600 may return whenever they >>> want. >>> >>> Regards >>> >>> >>> Xiao, Lin (NSN - CN/Beijing) schrieb: >>>> Hi, >>>> >>>> Maybe I'm wrong, but I consider peers in RELOAD are structured with >>>> a DHT algorithm, e.g., in Chord, peer with Node-ID 500 is connected >>>> with peer 400 and 600. >>>> >>>> However, what will happen, if peer 500 totally lose both of the >>>> connections due to mobility and NAT, but can set up new ones with >>>> peer 100 and peer 300? IMHO, in order to keep the topology >>>> structured, if this node still want to be a peer in the overlay it >>>> should change its Node ID to, say 200, and rejoin the overlay to >>>> enable itself still reachable with the DHT algorithm. >>>> >>>> If peers in a overlay can not be connected with a strict order, the >>>> DHT algorithm for structured topology will not work anymore. >>>> >>>> >>>> Br >>>> Xiao, Lin >>>> >>>> -----Original Message----- >>>> From: ext jc [mailto:julian@orchidseed.org] >>>> Sent: Thursday, October 22, 2009 12:41 AM >>>> To: Xiao, Lin (NSN - CN/Beijing) >>>> Cc: ext Cullen Jennings; P2PSIP WG >>>> Subject: Re: [P2PSIP] New versions of RELOAD and sip draft >>>> >>>> The draft doesn't state that you MUST change you NodeID if you lose >>>> overlay connectivity. In fact under your given condition you would >>>> simply retain it and connect again as a Client when the network is >>>> back up. >>>> >>>> Julian >>>> >>>> On Oct 21, 2009, at 3:59 AM, Xiao, Lin (NSN - CN/Beijing) wrote: >>>> >>>> >>>>> Hi Cullen, >>>>> >>>>> Thanks for your reply. >>>>> >>>>> I agree that RELOAD have covered most of the functionalities of >>>>> peers >>>>> >>>> >>>> >>>>> and clients. However, there is still a little different between >>>>> clients and peers while connection is lost besides data replica. >>>>> What >>>>> I mean here is the Node ID. >>>>> >>>>> Because all the peers in the overlay are connected according to a >>>>> strict overlay algorithm. The position of a peer in the overlay is >>>>> decided by its Node ID. If a peer lost its position >>>>> (disconnected) in >>>>> the overlay because of moving and NAT, but still want to work as a >>>>> peer, it must change its Node ID, which means it need do the >>>>> enrollment again and rejoin the overlay. >>>>> >>>>> But, because a client can attach with an arbitrary peer. It is not >>>>> necessary for a client to change its Node ID when it change its >>>>> attaching peer. The most important thing here is that, this >>>>> behavior make it possible for a client to keep session continuity >>>>> while its attaching peer is switched. >>>>> >>>>> Considering to deploy RELOAD in reality, stable nodes are >>>>> preferred to work as peers while mobile nodes can take the >>>>> advantage of the client behavior mentioned above. Sessions can be >>>>> kept with high mobility, as unique Node ID is maintained by >>>>> clients. I'm not sure if RELOAD has considered this distinction of >>>>> client, which help clients to be attached with the ovelay as long >>>>> as it can build at least one connection to the overlay. >>>>> >>>>> Br >>>>> Xiao, Lin >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: ext Cullen Jennings [mailto:fluffy@cisco.com] >>>>> Sent: Friday, October 16, 2009 9:05 AM >>>>> To: Xiao, Lin (NSN - CN/Beijing) >>>>> Cc: P2PSIP WG >>>>> Subject: Re: [P2PSIP] New versions of RELOAD and sip draft >>>>> >>>>> >>>>> Thank you, few comments inline.... >>>>> >>>>> On Oct 10, 2009, at 2:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote: >>>>> >>>>> >>>>>> Hi Cullen, >>>>>> >>>>>> I've had a quick review of these two drafts, and still not quite >>>>>> clear >>>>>> >>>>>> with some Client related issues. >>>>>> >>>>>> I know Client is not the first-class concept in RELOAD, but as it >>>>>> has >>>>>> >>>> >>>> >>>>>> been involved in the RELOAD protocol, RELOAD should give full >>>>>> support >>>>>> >>>> >>>> >>>>>> to client anyhow, right? >>>>>> >>>>>> In the terminology chapter of RELOAD Base draft, the connection >>>>>> table >>>>>> >>>> >>>> >>>>>> is defined as: >>>>>> "The set of peers to which a node is directly connected. This >>>>>> includes nodes with which Attach handshakes have been done but >>>>>> which >>>>>> >>>> >>>> >>>>>> have not sent any Updates." >>>>>> although, the second sentence implies that clients are also >>>>>> involved in, I still suggest to replace the "peers" in the first >>>>>> sentence with >>>>>> >>>> >>>> >>>>>> "nodes" to make it more clear that both peers and clients can be >>>>>> maintained in the table. >>>>>> >>>>> I agree. I changed this - thank you for the careful review to >>>>> catch > >>>>> things like this. >>>>> >>>>> >>>>>> In my opinions, connection setup and maintenance between client >>>>>> and its connected peer (responsible peer or arbitrary peer) is a >>>>>> key issue for client support in RELOAD. My question is: Does a >>>>>> peer in RELOAD distinguish if the connection is to a peer or to a >>>>>> client? >>>>>> Because the reaction of the peer could be different when the >>>>>> connection is lost. >>>>>> >>>>> Reload does distinguish at some level but what do you think a node >>>>> needs to do differently when a connection is lost if the >>>>> connection > >>>>> when to a peer or client. Clearly how data replication is handled >>>>> and some of the finger table stuff is handled differently but I >>>>> think that >>>>> >>>> >>>> >>>>> is covered in the draft. If you see something specific missing, >>>>> let > >>>>> me >>>>> >>>> >>>> >>>>> know. >>>>> >>>>> >>>>>> As a client could set up a connection only with an arbitrary >>>>>> peer. >>>>>> Does >>>>>> this peer distinguish such connection from those it is >>>>>> responsible > >>>>>> to? >>>>>> >>>>> I don't se the need to. >>>>> >>>>> >>>>>> Should this peer inform the client's responsible peer about the >>>>>> Destination List to the client? So that it can still be accessed >>>>>> by other nodes. Or should the Destination List been stored with >>>>>> some usage, say SIP Usage? >>>>>> >>>>> Yes, that is the approach to store destination lists where they >>>>> are > >>>>> needed. >>>>> >>>>> >>>>>> If so, the SIP usage must be extended to allow a Destination list >>>>>> containing more than one Node IDs. >>>>>> >>>>> agree that it needs to allow storing multiple Node IDs but I think >>>>> it already does that. >>>>> >>>>> >>>>>> In current SIP >>>>>> usage draft, the SipRegistration structure only allow one address >>>>>> being stored in the Destination List, as: >>>>>> " Destination destination_list<0..2^16-1>;" >>>>>> >>>>> The destination_list here is an array of Destinations so it allows >>>>> between 0 and 65K entries in the array. I agree the syntax for >>>>> specifying arrays might seem a bit weird but I think the structure >>>>> is what you are pointing out we need to have. >>>>> >>>>> >>>>>> It should be replaced by: "Destination destination_list >>>>>> [dest_list_length];" >>>>>> to enable a longer list stored by arbitrary connected clients. >>>>>> >>>>>> Anyway, IMHO, RELOAD should make sure to cover all situations a >>>>>> client could meet or at least clearly distinguish issues of >>>>>> clients, especially for arbitrary connected ones, which are left >>>>>> to be solved by other drafts. Thanks. >>>>>> >>>>>> >>>>>> Best Regards, >>>>>> Xiao, Lin >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >>>>>> Behalf Of ext Cullen Jennings >>>>>> Sent: Wednesday, October 07, 2009 1:53 AM >>>>>> To: P2PSIP WG >>>>>> Subject: [P2PSIP] New versions of RELOAD and sip draft >>>>>> >>>>>> >>>>>> I just submitted >>>>>> draft-ietf-p2psip-base-04 >>>>>> and >>>>>> draft-ietf-p2psip-sip-02 >>>>>> >>>>>> These contain technical changes but do not have a lot of >>>>>> editorial > >>>>>> changes. At some point we need to go and reorganize the documents >>>>>> with editorial changes. >>>>>> >>>>>> Cullen >>>>>> >>>>>> _______________________________________________ >>>>>> P2PSIP mailing list >>>>>> P2PSIP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>>> >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>> >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From lucyyong@huawei.com Mon Oct 26 20:27:53 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1B43A69E8 for ; Mon, 26 Oct 2009 20:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.453 X-Spam-Level: ** X-Spam-Status: No, score=2.453 tagged_above=-999 required=5 tests=[AWL=2.946, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w564cfa-8bdl for ; Mon, 26 Oct 2009 20:27:53 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 002253A6959 for ; Mon, 26 Oct 2009 20:27:53 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS5002TQLMKFW@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 27 Oct 2009 11:27:56 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS50059ZLMK4P@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 27 Oct 2009 11:27:56 +0800 (CST) Received: from j53016H ([10.164.12.52]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS500LWJLMJXO@szxml04-in.huawei.com> for p2psip@ietf.org; Tue, 27 Oct 2009 11:27:56 +0800 (CST) Date: Tue, 27 Oct 2009 11:27:55 +0800 From: lucy yong To: p2psip@ietf.org Message-id: <011b01ca56b5$798b44c0$340ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_ccHKw49XJ47zfSIhb3tl0Q)" Thread-index: AcpWtXk+iCdjwt0pTxKZ2cXhX/wVgQ== Subject: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 03:27:54 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ccHKw49XJ47zfSIhb3tl0Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT +1 Lucy --Boundary_(ID_ccHKw49XJ47zfSIhb3tl0Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

+1

=

Lucy

--Boundary_(ID_ccHKw49XJ47zfSIhb3tl0Q)-- From melodysong@huawei.com Tue Oct 27 02:37:21 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BA0928C1C9 for ; Tue, 27 Oct 2009 02:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.331 X-Spam-Level: X-Spam-Status: No, score=0.331 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxOyaVbenJUo for ; Tue, 27 Oct 2009 02:37:19 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 620CB28C179 for ; Tue, 27 Oct 2009 02:37:19 -0700 (PDT) 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 <0KS6003412QA81@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 27 Oct 2009 17:37:23 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS600I6B2QA5A@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 27 Oct 2009 17:37:22 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS60051T2QAMB@szxml06-in.huawei.com> for p2psip@ietf.org; Tue, 27 Oct 2009 17:37:22 +0800 (CST) Date: Tue, 27 Oct 2009 17:37:22 +0800 From: Song Haibin In-reply-to: To: 'Cullen Jennings' Message-id: <052001ca56e9$15b7dba0$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpWU3BPtCGuqPA8RiyEcvrdbq5F1gAVe41Q Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 09:37:21 -0000 >-----Original Message----- >From: Cullen Jennings [mailto:fluffy@cisco.com] >Sent: Monday, October 26, 2009 11:46 PM >To: Song Haibin >Cc: P2PSIP WG >Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base > > >On Oct 26, 2009, at 3:32 , Song Haibin wrote: > >> Hi, >> >> I have not finished the review, but I have several questions on this >> document. >> >> 1). I am not sure how the TRUN usage defined in this document will >> work well. Who will be responsible for calculating the >turnDensity and >> how? > >The idea was to specify the minimal simple thing and allow for >much more advanced things to be developed in the future. Right >now, the operator of the DHT would specify the turnDensity - >they could presumable measure by probing the overlay. Keep in >mind the two interesting values for overlays are no one is a >TURN server and everyone is a TURN server. > In that case, the turnDensity is really dynamic, especially in an overlay with high churn rate and there are few TURN servers in the overlay. A TURN server has to register its information to the overlay with different times when the turnDensity changes. Does it need to delete some copies of its information or register more copies when the turnDensity changes? I don't think this discovery mechanism in the document is mature to implement. Haibin >> How >> to update the TURN server information in the overlay when some TURN >> servers leave the overlay suddenly, to avoid getting the "old" >> information? > >The data times out and goes away and and this is part of the >reason for finding a bunch. > >> >> 2). In section 4.1.1 "Storage Permissions" said "RELOAD addresses >> this issue >> by only allowing any given node to store data at >> a small number of locations in the overlay, with those locations >> being >> determined by the node's certificate." This rule will limit the >> applications >> that the protocol could support. E.g, for streaming or file-sharing >> applications, it is very practical to put the resource providers' >> address >> information under the same Resource ID which is the hash of the >> content >> name, despite the node ID or username information contained in the >> certificate of the resource provider. > >Sure, but without this rules peers are would have to store an >unlimited amount of data on behalf of others. A key premise of this >work since before the WG was charter was that the protocol should be >possible to use in a way where one could deploy a overlay for some >application usage and not have it become used for file sharing. Note >that if the overlay wants to allow kinds that have no authorization >rules and allow anyone to write anywhere, there is nothing the spec >that forbids that. It's up to the usage. So if someone wants >to make a >file-sharing usage, well storing the whole file in the DHT is >probably >not the best design but one could certainly make a usage that did >exactly that. > >> >> 3). How do you prevent "via list" being modified by the >intermediate >> peers? >> This is very important because it is related to whether you can get >> a right >> returen path for your response. > >Well we can't really secure this in any practical way, or more >importantly, we can prevent the intermediate peers from misrouting >the request. The misroute of the response is no more serious than the >misroute of the request. It's a pretty fundamental limitation of an >overlay system like this. However, the overlay security of the system >does not depend on stopping this. This can be used to DOS the systems >but not much else. Keep in mind, the same is true of IP that is >running over. > >> >> 4). In section 5.4.2.4.2., RouteQuery response should at least >> include a >> next hop peer infomation if you want to use this message for the >> iterative >> routing. > >Agree this is needed but it is somewhat DHT specific. I forget the >details but I think it was Salman who pointed out that for some >unstructured overlays, you would need something other than the next >hop. Because of that, we made the answer DHT specific. For the Chord >DHT specified here, 100% agree with you we need the next hop and the >message to return that is defined in Section 9.8 > >> >> 5). I'm not sure about the necessity of access control policies in >> section >> 6.3. I think it will make sense only when these access control >> policies are >> generic to all usages that will be built on top of RELOAD. Other >> than that, >> I would suggest to remove this section and define these policies in >> each >> usage document. Comment 2 is also related to this topic. > >Clearly many usage documents can share many of the basic >policies so I >think it make more sense to define at least the ones needed for the >charter of this WG in the base draft. > >> >> Thanks! >> Haibin > >Thanks for reviewing it - much appreciated. > >Cullen > >> >> >> >>> -----Original Message----- >>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] >>> On Behalf Of Brian Rosen >>> Sent: Saturday, October 24, 2009 2:55 AM >>> To: Cullen Jennings; P2PSIP WG >>> Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base >>> >>> >>> If you think the draft is missing something big, or has some >>> other serious shortcoming that makes it inappropriate to hold >>> a WGLC, please speak up now. >>> We'll give everyone a few days to look over this version, and >>> then decide if we will start it. >>> >>> If you had signed up to review NOW would be the time to do it, >>> on this version. That was NOW, and not "soon", please. >>> >>> Brian >>> >>> >>> On 10/23/09 2:38 PM, "Cullen Jennings" wrote: >>> >>>> >>>> We just submitted a new version of the base draft at >>>> >>>> http://www.ietf.org/id/draft-ietf-p2psip-base-05.txt >>>> >>>> (there is a new version of the sip-usage as well). >>>> >>>> The major changes are mostly a very long and excruciating editorial >>>> pass to try and improve the grammar. >>>> >>>> At this point, I don't know of any significant issues that >>> need to be >>>> resolved. I think the draft is ready for WGLC. >>>> >>>> I'm sure that during WGLC some major issues will come up, some >>>> important decisions will be made about what needs to be >>> mandatory and >>>> such, and we will find several small inconsistencies and >>> typos in the >>>> draft as well as things that need a clearer explanation. This will >>>> take some time and I expect multiple more revisions for this draft >>>> before it is published, however, I do think this is the >>> right time to >>>> start WGLC. Lets get the issues on the table and then we can start >>>> resolving them. >>>> >>>> Thanks, >>>> Cullen >>>> >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> > From jouni.maenpaa@ericsson.com Tue Oct 27 03:33:26 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B09128C143 for ; Tue, 27 Oct 2009 03:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2IjPlPbfgNK for ; Tue, 27 Oct 2009 03:33:24 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 487EE28C0E0 for ; Tue, 27 Oct 2009 03:33:23 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-86-4ae6cc63b197 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 1C.FE.24026.36CC6EA4; Tue, 27 Oct 2009 11:33:07 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 11:33:07 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 11:33:07 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CEAB424FE; Tue, 27 Oct 2009 12:33:06 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 96C9121A22; Tue, 27 Oct 2009 12:33:06 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3F41121A1F; Tue, 27 Oct 2009 12:33:06 +0200 (EET) Message-ID: <4AE6CC62.5070200@ericsson.com> Date: Tue, 27 Oct 2009 12:33:06 +0200 From: =?ISO-8859-1?Q?Jouni_M=E4enp=E4=E4?= User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Song Haibin , 'P2PSIP WG' References: <052001ca56e9$15b7dba0$1d0ca40a@china.huawei.com> In-Reply-To: <052001ca56e9$15b7dba0$1d0ca40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 27 Oct 2009 10:33:07.0157 (UTC) FILETIME=[DF46A850:01CA56F0] X-Brightmail-Tracker: AAAAAA== Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 10:33:26 -0000 Hi Haibin, > In that case, the turnDensity is really dynamic, especially in an > overlay with high churn rate and there are few TURN servers in the > overlay. A TURN server has to register its information to the overlay > with different times when the turnDensity changes. Does it need to > delete some copies of its information or register more copies when the > turnDensity changes? I don't think this discovery mechanism in the > document is mature to implement. In the following draft that we submitted last week: http://www.ietf.org/id/draft-maenpaa-p2psip-service-discovery-00.txt we are proposing a generic service discovery mechanism for RELOAD. As indicated in the RELOAD base draft, RELOAD currently defines a TURN-specific service discovery mechanism, but is lacking a generic mechanism for service discovery. So if you are interested in an alternative, more generic service discovery mechanism, you could have a look at our draft. Regards, Jouni Song Haibin wrote: >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Monday, October 26, 2009 11:46 PM >> To: Song Haibin >> Cc: P2PSIP WG >> Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base >> >> >> On Oct 26, 2009, at 3:32 , Song Haibin wrote: >> >>> Hi, >>> >>> I have not finished the review, but I have several questions on this >>> document. >>> >>> 1). I am not sure how the TRUN usage defined in this document will >>> work well. Who will be responsible for calculating the >> turnDensity and >>> how? >> The idea was to specify the minimal simple thing and allow for >> much more advanced things to be developed in the future. Right >> now, the operator of the DHT would specify the turnDensity - >> they could presumable measure by probing the overlay. Keep in >> mind the two interesting values for overlays are no one is a >> TURN server and everyone is a TURN server. >> > > > > In that case, the turnDensity is really dynamic, especially in an overlay > with high churn rate and there are few TURN servers in the overlay. A TURN > server has to register its information to the overlay with different times > when the turnDensity changes. Does it need to delete some copies of its > information or register more copies when the turnDensity changes? I don't > think this discovery mechanism in the document is mature to implement. > > > Haibin > >>> How >>> to update the TURN server information in the overlay when some TURN >>> servers leave the overlay suddenly, to avoid getting the "old" >>> information? >> The data times out and goes away and and this is part of the >> reason for finding a bunch. >> > >>> 2). In section 4.1.1 "Storage Permissions" said "RELOAD addresses >>> this issue >>> by only allowing any given node to store data at >>> a small number of locations in the overlay, with those locations >>> being >>> determined by the node's certificate." This rule will limit the >>> applications >>> that the protocol could support. E.g, for streaming or file-sharing >>> applications, it is very practical to put the resource providers' >>> address >>> information under the same Resource ID which is the hash of the >>> content >>> name, despite the node ID or username information contained in the >>> certificate of the resource provider. >> Sure, but without this rules peers are would have to store an >> unlimited amount of data on behalf of others. A key premise of this >> work since before the WG was charter was that the protocol should be >> possible to use in a way where one could deploy a overlay for some >> application usage and not have it become used for file sharing. Note >> that if the overlay wants to allow kinds that have no authorization >> rules and allow anyone to write anywhere, there is nothing the spec >> that forbids that. It's up to the usage. So if someone wants >> to make a >> file-sharing usage, well storing the whole file in the DHT is >> probably >> not the best design but one could certainly make a usage that did >> exactly that. >> >>> 3). How do you prevent "via list" being modified by the >> intermediate >>> peers? >>> This is very important because it is related to whether you can get >>> a right >>> returen path for your response. >> Well we can't really secure this in any practical way, or more >> importantly, we can prevent the intermediate peers from misrouting >> the request. The misroute of the response is no more serious than the >> misroute of the request. It's a pretty fundamental limitation of an >> overlay system like this. However, the overlay security of the system >> does not depend on stopping this. This can be used to DOS the systems >> but not much else. Keep in mind, the same is true of IP that is >> running over. >> >>> 4). In section 5.4.2.4.2., RouteQuery response should at least >>> include a >>> next hop peer infomation if you want to use this message for the >>> iterative >>> routing. >> Agree this is needed but it is somewhat DHT specific. I forget the >> details but I think it was Salman who pointed out that for some >> unstructured overlays, you would need something other than the next >> hop. Because of that, we made the answer DHT specific. For the Chord >> DHT specified here, 100% agree with you we need the next hop and the >> message to return that is defined in Section 9.8 >> >>> 5). I'm not sure about the necessity of access control policies in >>> section >>> 6.3. I think it will make sense only when these access control >>> policies are >>> generic to all usages that will be built on top of RELOAD. Other >>> than that, >>> I would suggest to remove this section and define these policies in >>> each >>> usage document. Comment 2 is also related to this topic. >> Clearly many usage documents can share many of the basic >> policies so I >> think it make more sense to define at least the ones needed for the >> charter of this WG in the base draft. >> >>> Thanks! >>> Haibin >> Thanks for reviewing it - much appreciated. >> >> Cullen >> >>> >>> >>>> -----Original Message----- >>>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] >>>> On Behalf Of Brian Rosen >>>> Sent: Saturday, October 24, 2009 2:55 AM >>>> To: Cullen Jennings; P2PSIP WG >>>> Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base >>>> >>>> >>>> If you think the draft is missing something big, or has some >>>> other serious shortcoming that makes it inappropriate to hold >>>> a WGLC, please speak up now. >>>> We'll give everyone a few days to look over this version, and >>>> then decide if we will start it. >>>> >>>> If you had signed up to review NOW would be the time to do it, >>>> on this version. That was NOW, and not "soon", please. >>>> >>>> Brian >>>> >>>> >>>> On 10/23/09 2:38 PM, "Cullen Jennings" wrote: >>>> >>>>> We just submitted a new version of the base draft at >>>>> >>>>> http://www.ietf.org/id/draft-ietf-p2psip-base-05.txt >>>>> >>>>> (there is a new version of the sip-usage as well). >>>>> >>>>> The major changes are mostly a very long and excruciating editorial >>>>> pass to try and improve the grammar. >>>>> >>>>> At this point, I don't know of any significant issues that >>>> need to be >>>>> resolved. I think the draft is ready for WGLC. >>>>> >>>>> I'm sure that during WGLC some major issues will come up, some >>>>> important decisions will be made about what needs to be >>>> mandatory and >>>>> such, and we will find several small inconsistencies and >>>> typos in the >>>>> draft as well as things that need a clearer explanation. This will >>>>> take some time and I expect multiple more revisions for this draft >>>>> before it is published, however, I do think this is the >>>> right time to >>>>> start WGLC. Lets get the issues on the table and then we can start >>>>> resolving them. >>>>> >>>>> Thanks, >>>>> Cullen >>>>> >>>>> >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Tue Oct 27 04:40:54 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B723A68E9 for ; Tue, 27 Oct 2009 04:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.047 X-Spam-Level: X-Spam-Status: No, score=-106.047 tagged_above=-999 required=5 tests=[AWL=-3.082, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3l6KNqzauiB for ; Tue, 27 Oct 2009 04:40:53 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AAEB73A67A1 for ; Tue, 27 Oct 2009 04:40:52 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEAAGZ55kqQ/uCWe2dsb2JhbACEc5ZJAQEWJAakMIcMCJEegS6COlcEgj8 X-IronPort-AV: E=Sophos;i="4.44,632,1249257600"; d="scan'208";a="52868371" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 27 Oct 2009 11:41:05 +0000 Received: from ams3-vpn-dhcp5824.cisco.com (ams3-vpn-dhcp5824.cisco.com [10.61.86.191]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9RBf4BZ018917; Tue, 27 Oct 2009 11:41:05 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=GB2312; format=flowed; delsp=yes From: Cullen Jennings In-Reply-To: <012701ca56b7$c843c950$340ca40a@china.huawei.com> Date: Tue, 27 Oct 2009 12:41:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8DA4537F-308E-42C7-98E5-41C958D9BF81@cisco.com> References: <012701ca56b7$c843c950$340ca40a@china.huawei.com> To: "lucy yong" X-Mailer: Apple Mail (2.1076) Cc: P2PSIP WG Subject: Re: [P2PSIP] =?gb2312?b?tPC4tDogIE5ldyB2ZXJzaW9uIG9mICBkcmFmdC1pZXRm?= =?gb2312?b?LXAycHNpcC1iYXNl?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 11:40:54 -0000 I'm a bit confused on how splitting the text across 4 drafts that all =20= normatively reference each other will help. An implementor will still =20= have to read all of them to do anything and it makes it hard to keep =20 them consistent. If there are parts of the draft that you think don't =20= need to be implemented and could just be removed, well that would help =20= make it shorter and I'd be very happy to get recommendations and how =20 to make it easier for implementors by making less stuff that needed to =20= be implemented. Cullen On Oct 27, 2009, at 4:44 , lucy yong wrote: > Hi Cullen and Chairs, > > I volunteered to review this draft in last IETF meeting and read =20 > chapter 1~4 > and some in the rest of v4. > > IMHO, the draft contains too much contents and too long. It would be =20= > nice if > it can be split into two or three drafts. One is about overlay =20 > framework and > another is Overlay protocol. > > Two major protocols for overlay management and data storage are =20 > specified in > current draft, which can be specified in two drafts as well. > > There are other protocols that apply to overlay network. If we =20 > complete the > framework draft, all protocol drafts can be developed in parallel. =20 > Having > such BIG and HEAVY draft is hard to get consensuses and make any =20 > change in > later. > > Regards, > Lucy > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: p2psip-bounces@ietf.org = [mailto:p2psip-bounces@ietf.org] =B4=FA=B1=ED =20 > Cullen > Jennings > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA10=D4=C224=C8=D5 2:39 > =CA=D5=BC=FE=C8=CB: P2PSIP WG > =D6=F7=CC=E2: [P2PSIP] New version of draft-ietf-p2psip-base > > > We just submitted a new version of the base draft at > > http://www.ietf.org/id/draft-ietf-p2psip-base-05.txt > > (there is a new version of the sip-usage as well). > > The major changes are mostly a very long and excruciating editorial > pass to try and improve the grammar. > > At this point, I don't know of any significant issues that need to be > resolved. I think the draft is ready for WGLC. > > I'm sure that during WGLC some major issues will come up, some > important decisions will be made about what needs to be mandatory and > such, and we will find several small inconsistencies and typos in the > draft as well as things that need a clearer explanation. This will > take some time and I expect multiple more revisions for this draft > before it is published, however, I do think this is the right time to > start WGLC. Lets get the issues on the table and then we can start > resolving them. > > Thanks, > Cullen > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From lucyyong@huawei.com Tue Oct 27 05:20:34 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78433A685B for ; Tue, 27 Oct 2009 05:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.218 X-Spam-Level: * X-Spam-Status: No, score=1.218 tagged_above=-999 required=5 tests=[AWL=-3.817, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQDfh+kz8egn for ; Tue, 27 Oct 2009 05:20:33 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id D7D843A67D1 for ; Tue, 27 Oct 2009 05:20:33 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS600131AALMK@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 27 Oct 2009 05:20:46 -0700 (PDT) Received: from y736742 (137.91.88.117.broad.nj.js.dynamic.163data.com.cn [117.88.91.137]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS600JSJAAFEU@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 27 Oct 2009 05:20:45 -0700 (PDT) Date: Tue, 27 Oct 2009 07:20:49 -0500 From: Yong Lucy In-reply-to: <8DA4537F-308E-42C7-98E5-41C958D9BF81@cisco.com> To: 'Cullen Jennings' Message-id: <006f01ca56ff$ec6d3670$bf05a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcpW+niuvYxuZSxsRfKtYnAulejYJwAAOQWw References: <012701ca56b7$c843c950$340ca40a@china.huawei.com> <8DA4537F-308E-42C7-98E5-41C958D9BF81@cisco.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] =?gb2312?b?tPC4tDogIE5ldyB2ZXJzaW9uIG9mICBkcmFmdC1pZXRm?= =?gb2312?b?LXAycHNpcC1iYXNl?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 12:20:34 -0000 Splitting text will make each draft focusing on one subject in overlay network. Although an implementer may need to read all of them, he/she = don't need to read them in the same level detail. If each draft addresses one subject, there is no issue on keeping consistent because one draft can reference another RFC and does not repeat the same text. IETF has been working on this style well for long.=20 Regards, Lucy > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, October 27, 2009 6:41 AM > To: lucy yong > Cc: P2PSIP WG > Subject: Re: =B4=F0=B8=B4: [P2PSIP] New version of = draft-ietf-p2psip-base >=20 >=20 > I'm a bit confused on how splitting the text across 4 drafts that all > normatively reference each other will help. An implementor will still > have to read all of them to do anything and it makes it hard to keep > them consistent. If there are parts of the draft that you think don't > need to be implemented and could just be removed, well that would help > make it shorter and I'd be very happy to get recommendations and how > to make it easier for implementors by making less stuff that needed to > be implemented. >=20 > Cullen >=20 > On Oct 27, 2009, at 4:44 , lucy yong wrote: >=20 > > Hi Cullen and Chairs, > > > > I volunteered to review this draft in last IETF meeting and read > > chapter 1~4 > > and some in the rest of v4. > > > > IMHO, the draft contains too much contents and too long. It would be > > nice if > > it can be split into two or three drafts. One is about overlay > > framework and > > another is Overlay protocol. > > > > Two major protocols for overlay management and data storage are > > specified in > > current draft, which can be specified in two drafts as well. > > > > There are other protocols that apply to overlay network. If we > > complete the > > framework draft, all protocol drafts can be developed in parallel. > > Having > > such BIG and HEAVY draft is hard to get consensuses and make any > > change in > > later. > > > > Regards, > > Lucy > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: p2psip-bounces@ietf.org = [mailto:p2psip-bounces@ietf.org] =B4=FA=B1=ED > > Cullen > > Jennings > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA10=D4=C224=C8=D5 2:39 > > =CA=D5=BC=FE=C8=CB: P2PSIP WG > > =D6=F7=CC=E2: [P2PSIP] New version of draft-ietf-p2psip-base > > > > > > We just submitted a new version of the base draft at > > > > http://www.ietf.org/id/draft-ietf-p2psip-base-05.txt > > > > (there is a new version of the sip-usage as well). > > > > The major changes are mostly a very long and excruciating editorial > > pass to try and improve the grammar. > > > > At this point, I don't know of any significant issues that need to = be > > resolved. I think the draft is ready for WGLC. > > > > I'm sure that during WGLC some major issues will come up, some > > important decisions will be made about what needs to be mandatory = and > > such, and we will find several small inconsistencies and typos in = the > > draft as well as things that need a clearer explanation. This will > > take some time and I expect multiple more revisions for this draft > > before it is published, however, I do think this is the right time = to > > start WGLC. Lets get the issues on the table and then we can start > > resolving them. > > > > Thanks, > > Cullen > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > > > From br@brianrosen.net Tue Oct 27 09:47:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C613A69BF for ; Tue, 27 Oct 2009 09:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.476 X-Spam-Level: * X-Spam-Status: No, score=1.476 tagged_above=-999 required=5 tests=[AWL=-3.610, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oXAAFpq1aeS for ; Tue, 27 Oct 2009 09:47:30 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id CDEE93A6886 for ; Tue, 27 Oct 2009 09:47:25 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.216]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N2pCj-0000Kp-Bp; Tue, 27 Oct 2009 11:47:29 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 27 Oct 2009 12:47:31 -0400 From: Brian Rosen To: Yong Lucy , Cullen Jennings Message-ID: Thread-Topic: [P2PSIP] =?Big5?B?tarOYA==?=: New version of draft-ietf-p2psip-base Thread-Index: AcpW+niuvYxuZSxsRfKtYnAulejYJwAAOQWwAAp0ALI= In-Reply-To: <006f01ca56ff$ec6d3670$bf05a8c0@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] =?big5?b?tarOYCA6ICBOZXcgdmVyc2lvbiBvZiBkcmFmdC1pZXRm?= =?big5?b?LXAycHNpcC1iYXNl?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 16:47:31 -0000 Having dealt with both kinds, I lean towards one document with everything. I really don't like having to refer back to other documents to get the picture, and I can always skim through the parts I don't care about. I fin= d that I retain parts of the "skim" which keeps the big picture in my head better. I just did this over in ecrit (-framework and -phonebcp). It was a mistake= : we should have had one document. Brian On 10/27/09 8:20 AM, "Yong Lucy" wrote: > Splitting text will make each draft focusing on one subject in > overlay network. Although an implementer may need to read all of them, he/she > don't need to read them in the same level detail. If each draft addresses > one subject, there is no issue on keeping consistent because one draft > can reference another RFC and does not repeat the same text. IETF has > been working on this style well for long. Regards, Lucy > -----Original > Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: > Tuesday, October 27, 2009 6:41 AM > To: lucy yong > Cc: P2PSIP WG > Subject: > Re: =B4=F0=B8=B4: [P2PSIP] New version of draft-ietf-p2psip-base > > > I'm a bit > confused on how splitting the text across 4 drafts that all > normatively > reference each other will help. An implementor will still > have to read all > of them to do anything and it makes it hard to keep > them consistent. If > there are parts of the draft that you think don't > need to be implemented and > could just be removed, well that would help > make it shorter and I'd be very > happy to get recommendations and how > to make it easier for implementors by > making less stuff that needed to > be implemented. > > Cullen individual contributor role> > > On Oct 27, 2009, at 4:44 , lucy yong > wrote: > > > Hi Cullen and Chairs, > > > > I volunteered to review this draft > in last IETF meeting and read > > chapter 1~4 > > and some in the rest of > v4. > > > > IMHO, the draft contains too much contents and too long. It would > be > > nice if > > it can be split into two or three drafts. One is about > overlay > > framework and > > another is Overlay protocol. > > > > Two major > protocols for overlay management and data storage are > > specified in > > > current draft, which can be specified in two drafts as well. > > > > There are > other protocols that apply to overlay network. If we > > complete the > > > framework draft, all protocol drafts can be developed in parallel. > > > Having > > such BIG and HEAVY draft is hard to get consensuses and make any > > > change in > > later. > > > > Regards, > > Lucy > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE > =C8=CB: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] =B4=FA=B1=ED > > Cullen > > > Jennings > > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA10=D4=C224=C8=D5 2:39 > > =CA=D5=BC=FE=C8=CB: P2PSIP WG > > =D6=F7=CC=E2: > [P2PSIP] New version of draft-ietf-p2psip-base > > > > > > We just submitted a > new version of the base draft at > > > > > http://www.ietf.org/id/draft-ietf-p2psip-base-05.txt > > > > (there is a new > version of the sip-usage as well). > > > > The major changes are mostly a very > long and excruciating editorial > > pass to try and improve the grammar. > > > > > At this point, I don't know of any significant issues that need to be > > > resolved. I think the draft is ready for WGLC. > > > > I'm sure that during > WGLC some major issues will come up, some > > important decisions will be made > about what needs to be mandatory and > > such, and we will find several small > inconsistencies and typos in the > > draft as well as things that need a > clearer explanation. This will > > take some time and I expect multiple more > revisions for this draft > > before it is published, however, I do think this > is the right time to > > start WGLC. Lets get the issues on the table and then > we can start > > resolving them. > > > > Thanks, > > Cullen contributor role> > > > > > > > _______________________________________________ > > P2PSIP mailing list > > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > > > > _______________________________________________ P2PSIP mailing > list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From davidbryan@gmail.com Tue Oct 27 13:32:49 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B49328C14E for ; Tue, 27 Oct 2009 13:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4ifKp8zpG8H for ; Tue, 27 Oct 2009 13:32:48 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id A86C03A69C1 for ; Tue, 27 Oct 2009 13:32:48 -0700 (PDT) Received: by yxe30 with SMTP id 30so110629yxe.29 for ; Tue, 27 Oct 2009 13:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mI0dHVxb9soP6jYOhL9seZdlqzBzG4GZ8WIpNNhRGi0=; b=Vdw5xu3td2U0yoS9jy3AsfY5XeYIDNgNnv4gUslUo0MO1aYDHj02uid95rrhtrs8Fw Om6mwP2YUiKu/zk2r6P1V4vypH6vafoIB7a71s78tI8QQ0wBfPqlzurc6sEzaafZbfx3 88jSCIPxo89yRCdUBjt+S5Tt5UTD15/gtd4FA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=Vd+R4Ej+E3VJRkbyZe4L/i2uRT7GTilj1ap05ExExHdj5XGUJLLsklQ2YIbnwvEla0 vSqYgJkOlqr76vJwIlzQ6R2S+uQ2U/Aa844OwrCNeJSYwH+d2fpgypAWzNbExqs/nh9O lZ1856lLnlVJoEDqMEBoTxz+rXSBnYNGb1FGI= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.72.25 with SMTP id u25mr2234251yba.273.1256675579651; Tue, 27 Oct 2009 13:32:59 -0700 (PDT) Date: Tue, 27 Oct 2009 16:32:59 -0400 X-Google-Sender-Auth: efb3756e936d0e60 Message-ID: <8b2769930910271332jf34924dide78f7b73111c5d6@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Peterson, Jon" Subject: [P2PSIP] List of Agenda Requests so Far X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 20:32:49 -0000 Right now, we have the following agenda requests. We will publish the draft agenda tomorrow. Please check the list below to ensure that if you requested a slot, we have it on this list. If we don=92t, please sent email to Brian and I right away: we may have missed one! Remember that having a request here does not necessarily mean you will get agenda time. Slots are based on a priority determined at least in part on volume of list discussion, open questions from the previous meeting, whether a draft is a WG item or not, and clear open discussion issues. Thanks, David (as chair) As of 20:00 UT on Oct 27, 2009, slots have been requested for the following drafts: REsource LOcation And Discovery (RELOAD) Base Protocol draft-ietf-p2psip-base-05 http://www.ietf.org/id/draft-ietf-p2psip-base-05.txt P2PSIP Security Overview and Risk Analysis draft-matuszewski-p2psip-security-overview-01 http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-01.txt Load balancing models for DHT-based Peer-to-Peer Networks draft-harjula-p2psip-loadbalancing-survey-00 http://www.ietf.org/id/draft-harjula-p2psip-loadbalancing-survey-00.txt An extension to RELOAD to support Direct Response and Relay Peer routing draft-jiang-p2psip-relay-03 http://www.ietf.org/id/draft-jiang-p2psip-relay-03.txt A Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD) draft-maenpaa-p2psip-self-tuning-01 http://www.ietf.org/id/draft-maenpaa-p2psip-self-tuning-01.txt Service Discovery Usage for REsource LOcation And Discovery (RELOAD) draft-maenpaa-p2psip-service-discovery-00 http://www.ietf.org/id/draft-maenpaa-p2psip-service-discovery-00.txt From davidbryan@gmail.com Wed Oct 28 14:12:59 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D8B28C155 for ; Wed, 28 Oct 2009 14:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQPgSSC4EGqW for ; Wed, 28 Oct 2009 14:12:58 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 2B9F928C14E for ; Wed, 28 Oct 2009 14:12:58 -0700 (PDT) Received: by ywh13 with SMTP id 13so1212900ywh.29 for ; Wed, 28 Oct 2009 14:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1Jz5/PygcMp7E2oqMNWa8C3Hn0VF7tvvlLKaA45VjpA=; b=PmJnRFiRT1byuQ/MtYPFbrY1vE0nXQTQflWA+V4GoJcrabdvBIJdIBZXph6W5Cy1CP MTGE7zcXH5zfVE5irjlRiQaSo2fXBvUNXc2fWGzcWv+Eo7HzRXMwuLGbSSVwYUPQex2F F4DNvScXS2fddffO6HGPxjQZB5beFCVEEq6CU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=XfewZT+nJrFQrIoZfAWSIMIgT0NCn5dM+8MpWTmHnCX1EXm8HIHOfZJMW9LvsjidBj keYW+xFXOj2bbt8WF9BZWOBUat14dww43ABPrXe6MIhAr4wlFL4uhkxQMqUIv1ZyDDJQ ASOPi7Zr6CgaWPTI6E58zrf5nyDUOnOW4IJe0= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.16.2 with SMTP id 2mr818055ybp.251.1256764390917; Wed, 28 Oct 2009 14:13:10 -0700 (PDT) Date: Wed, 28 Oct 2009 17:13:10 -0400 X-Google-Sender-Auth: fe7659315366d5c9 Message-ID: <8b2769930910281413t11ecbe18q36f5227e2d6142e1@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Cc: "Peterson, Jon" Subject: [P2PSIP] Draft Agenda for P2PSIP Hiroshima Meeting Posted X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 21:12:59 -0000 I've put a draft agenda for Hiroshima up on the meeting materials page: http://www.ietf.org/proceedings/09nov/agenda/p2psip.html Please let Brian or I know if you have any concerns. Also, for many of the drafts, I don't yet know who the speaker will be. If your draft is on the agenda, can you please send me an email and let me know who the speaker will be? (I will also be handling the materials upload tasks, so please send slides to me, not the fill in chairs (Spencer Dawkins and Jon Peterson), unless of course it is a last minute change, since obviously they will be running the slides) Thanks, David (as chair) From michaelc@idssoftware.com Fri Oct 30 14:57:23 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE9E3A6A2E for ; Fri, 30 Oct 2009 14:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiwXRMLrUa4k for ; Fri, 30 Oct 2009 14:57:22 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 1DC9E3A6A13 for ; Fri, 30 Oct 2009 14:57:21 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N3zTX-0001e1-6T; Fri, 30 Oct 2009 17:57:39 -0400 Message-ID: <4AEB62C4.9050009@idssoftware.com> Date: Fri, 30 Oct 2009 14:03:48 -0800 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940544d4ea2cc8d9dcf3ee09adbd0a91676350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Subject: [P2PSIP] StoredData and its Signature X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 21:57:23 -0000 Cullen, The definition of StoredData the opening of Section 6 and its Signature in Section 6.1 are confusing: struct { uint32 length; uint64 storage_time; uint32 lifetime; StoredDataValue value; Signature signature; } StoredData; The contents of this structure are as follows: length The length of the rest of the structure in octets. ... value The data value itself, as described in Section 6.2. signature A signature over the data value. Section 6.1 describes the signature computation. The element is formatted as described in Section 5.3.4 6.1. Data Signature Computation Each StoredData .... The input to the signature algorithm is: resource_id + kind + StoredData + SignerIdentity Where these values are: ... StoredData The contents of the stored data value, as described in the previous sections, with the lifetime set to 0. 1) "length" seems to suggest it equals (sizeof(StoredData) - sizeof(length)), which means the size of StoredDataValue and Signature must be obtained before signing. No big deal, but the text should more explicit and precise. Suggestion: length The size of the StoredData structure in octets excluding the size of length itself. 2) The big problem is the signature input. In Section 6 the term "data value" appears in both the definition of "value" and "signature", seems to suggest that the 3rd input block for the signature only refer to the "value" field. In Section 6.1, the instruction of setting "lifetime" to 0 before signing suggest the signature includes the rest of the fields PLUS the signature itself (the 3rd input block is "+ StoredData +"). If I am not mistaken, the correct definition for the signature input should be: resource_id + kind + storage_time + lifetime + value + SignerIdentity The fact that "length" includes the size of the signature is somewhat awkward to be in the input. Excluding it does not degrade the security of the signature. If it is up to me, instead of setting "lifetime" to 0 before signing, why not exclude it all together? 3) "SignerIdentity" in this section should refer to its definition in Section 5.3.4 to prevent people from reading it as simply a 20-byte SHA1 hash value. SignerIdentity The signer identity as defined in Section 5.3.4, which MUST include a hash of the signer's certificate. Thanks --Michael From julian@orchidseed.org Fri Oct 30 23:16:04 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8A83A63C9 for ; Fri, 30 Oct 2009 23:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eh-0hpATipB for ; Fri, 30 Oct 2009 23:16:03 -0700 (PDT) Received: from n19.c05.mtsvc.net (n19.c05.mtsvc.net [70.32.68.19]) by core3.amsl.com (Postfix) with ESMTP id 604173A67B2 for ; Fri, 30 Oct 2009 23:16:03 -0700 (PDT) Received: from adsl-176-189-182.asm.bellsouth.net ([74.176.189.182]:51497 helo=[10.0.1.12]) by n19.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1N47G6-0005ka-5X; Fri, 30 Oct 2009 23:16:19 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: <4AEB62C4.9050009@idssoftware.com> Date: Sat, 31 Oct 2009 02:16:13 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <4AEB62C4.9050009@idssoftware.com> To: Michael Chen X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] StoredData and its Signature X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 06:16:04 -0000 On Oct 30, 2009, at 6:03 PM, Michael Chen wrote: > Cullen, > > The definition of StoredData the opening of Section 6 and its > Signature in Section 6.1 are confusing: > > struct { > uint32 length; > uint64 storage_time; > uint32 lifetime; > StoredDataValue value; > Signature signature; > } StoredData; > > The contents of this structure are as follows: > > length > The length of the rest of the structure in octets. > ... > > value > The data value itself, as described in Section 6.2. > > signature > A signature over the data value. Section 6.1 describes the > signature computation. The element is formatted as described in > Section 5.3.4 > > 6.1. Data Signature Computation > > Each StoredData .... The input to the signature algorithm is: > > resource_id + kind + StoredData + SignerIdentity > > Where these values are: > ... > > StoredData > The contents of the stored data value, as described in the > previous sections, with the lifetime set to 0. > > 1) "length" seems to suggest it equals (sizeof(StoredData) - sizeof > (length)), which means the size of StoredDataValue and Signature > must be obtained before signing. No big deal, but the text should > more explicit and precise. Suggestion: > > length > The size of the StoredData structure in octets excluding the size > of length itself. The wording is wrong and it should be simply "length = sizeof (StoredData)" because "the length is the size in octets of StoredData excluding all other fields". Please correct me if I am wrong, it's late. > > 2) The big problem is the signature input. In Section 6 the term > "data value" appears in both the definition of "value" and > "signature", seems to suggest that the 3rd input block for the > signature only refer to the "value" field. In Section 6.1, the > instruction of setting "lifetime" to 0 before signing suggest the > signature includes the rest of the fields PLUS the signature itself > (the 3rd input block is "+ StoredData +"). > > If I am not mistaken, the correct definition for the signature input > should be: > > resource_id + kind + storage_time + lifetime + value + > SignerIdentity > > The fact that "length" includes the size of the signature is > somewhat awkward to be in the input. Excluding it does not degrade > the security of the signature. If it is up to me, instead of > setting "lifetime" to 0 before signing, why not exclude it all > together? Where does the length field include the sizeof(signature)? See above. > > 3) "SignerIdentity" in this section should refer to its definition > in Section 5.3.4 to prevent people from reading it as simply a 20- > byte SHA1 hash value. > > SignerIdentity > The signer identity as defined in Section 5.3.4, which MUST > include > a hash of the signer's certificate. > > > Thanks > > --Michael > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From michaelc@idssoftware.com Sat Oct 31 07:45:16 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D62B3A6939 for ; Sat, 31 Oct 2009 07:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.552, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yd9NwCFX+Qbu for ; Sat, 31 Oct 2009 07:45:15 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 08C583A692C for ; Sat, 31 Oct 2009 07:45:14 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N4FCu-0002Ns-Ew; Sat, 31 Oct 2009 10:45:32 -0400 Message-ID: <4AEC4EFF.1000409@idssoftware.com> Date: Sat, 31 Oct 2009 06:51:43 -0800 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: jc References: <4AEB62C4.9050009@idssoftware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940559810ec0892a46ca488fca6187e25ea350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Cc: P2PSIP WG Subject: Re: [P2PSIP] StoredData and its Signature X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 14:45:16 -0000 Julian, The StoredData structure includes the signature, so the draft's definition: length The length of the >>**rest**<< of the structure in octets. would mean it includes the signature. --Michael jc wrote: > > On Oct 30, 2009, at 6:03 PM, Michael Chen wrote: > >> Cullen, >> >> The definition of StoredData the opening of Section 6 and its >> Signature in Section 6.1 are confusing: >> >> struct { >> uint32 length; >> uint64 storage_time; >> uint32 lifetime; >> StoredDataValue value; >> Signature signature; >> } StoredData; >> >> The contents of this structure are as follows: >> >> length >> The length of the rest of the structure in octets. >> ... >> >> value >> The data value itself, as described in Section 6.2. >> >> signature >> A signature over the data value. Section 6.1 describes the >> signature computation. The element is formatted as described in >> Section 5.3.4 >> >> 6.1. Data Signature Computation >> >> Each StoredData .... The input to the signature algorithm is: >> >> resource_id + kind + StoredData + SignerIdentity >> >> Where these values are: >> ... >> >> StoredData >> The contents of the stored data value, as described in the >> previous sections, with the lifetime set to 0. >> >> 1) "length" seems to suggest it equals (sizeof(StoredData) - >> sizeof(length)), which means the size of StoredDataValue and >> Signature must be obtained before signing. No big deal, but the text >> should more explicit and precise. Suggestion: >> >> length >> The size of the StoredData structure in octets excluding the size >> of length itself. > > The wording is wrong and it should be simply "length = > sizeof(StoredData)" because "the length is the size in octets of > StoredData excluding all other fields". Please correct me if I am > wrong, it's late. > >> >> 2) The big problem is the signature input. In Section 6 the term >> "data value" appears in both the definition of "value" and >> "signature", seems to suggest that the 3rd input block for the >> signature only refer to the "value" field. In Section 6.1, the >> instruction of setting "lifetime" to 0 before signing suggest the >> signature includes the rest of the fields PLUS the signature itself >> (the 3rd input block is "+ StoredData +"). >> >> If I am not mistaken, the correct definition for the signature input >> should be: >> >> resource_id + kind + storage_time + lifetime + value + SignerIdentity >> >> The fact that "length" includes the size of the signature is somewhat >> awkward to be in the input. Excluding it does not degrade the >> security of the signature. If it is up to me, instead of setting >> "lifetime" to 0 before signing, why not exclude it all together? > > Where does the length field include the sizeof(signature)? See above. > >> >> 3) "SignerIdentity" in this section should refer to its definition in >> Section 5.3.4 to prevent people from reading it as simply a 20-byte >> SHA1 hash value. >> >> SignerIdentity >> The signer identity as defined in Section 5.3.4, which MUST include >> a hash of the signer's certificate. >> >> >> Thanks >> >> --Michael >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > > From michaelc@idssoftware.com Sat Oct 31 08:45:16 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AE433A68C1 for ; Sat, 31 Oct 2009 08:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQwGBZJ4khkb for ; Sat, 31 Oct 2009 08:45:15 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 924FB3A687C for ; Sat, 31 Oct 2009 08:45:15 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N4G8z-0001OP-85; Sat, 31 Oct 2009 11:45:33 -0400 Message-ID: <4AEC5D10.4030402@idssoftware.com> Date: Sat, 31 Oct 2009 07:51:44 -0800 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: jc References: <4AEB62C4.9050009@idssoftware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940210e69fc6c4699818c3a5117172f61a8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Cc: P2PSIP WG Subject: Re: [P2PSIP] StoredData and its Signature X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 15:45:16 -0000 Julian, Reading into it more, I am suggesting the following minimalist correction: A) The definintion of 'length' Section 6 should be: length The size of the StoredData structure excluding 'length' and 'signature'. B) In Section 6.1, the input to the signature algorithm should be: resource_id + kind + stored_data + SignerIdentity Where these values are: ... stored_data The contents of the StoredData structure excluding the 'signature' as described in the previous sections, with the lifetime set to 0. SignerIdentity The signer identity as defined in Section 5.3.4, which MUST include a hash of the signer's certificate. It is an obvious style of this draft that a length value of a structure never includes the bytes occupied by the length itself. Thanks --Michael jc wrote: > > On Oct 30, 2009, at 6:03 PM, Michael Chen wrote: > >> Cullen, >> >> The definition of StoredData the opening of Section 6 and its >> Signature in Section 6.1 are confusing: >> >> struct { >> uint32 length; >> uint64 storage_time; >> uint32 lifetime; >> StoredDataValue value; >> Signature signature; >> } StoredData; >> >> The contents of this structure are as follows: >> >> length >> The length of the rest of the structure in octets. >> ... >> >> value >> The data value itself, as described in Section 6.2. >> >> signature >> A signature over the data value. Section 6.1 describes the >> signature computation. The element is formatted as described in >> Section 5.3.4 >> >> 6.1. Data Signature Computation >> >> Each StoredData .... The input to the signature algorithm is: >> >> resource_id + kind + StoredData + SignerIdentity >> >> Where these values are: >> ... >> >> StoredData >> The contents of the stored data value, as described in the >> previous sections, with the lifetime set to 0. >> >> 1) "length" seems to suggest it equals (sizeof(StoredData) - >> sizeof(length)), which means the size of StoredDataValue and >> Signature must be obtained before signing. No big deal, but the text >> should more explicit and precise. Suggestion: >> >> length >> The size of the StoredData structure in octets excluding the size >> of length itself. > > The wording is wrong and it should be simply "length = > sizeof(StoredData)" because "the length is the size in octets of > StoredData excluding all other fields". Please correct me if I am > wrong, it's late. > >> >> 2) The big problem is the signature input. In Section 6 the term >> "data value" appears in both the definition of "value" and >> "signature", seems to suggest that the 3rd input block for the >> signature only refer to the "value" field. In Section 6.1, the >> instruction of setting "lifetime" to 0 before signing suggest the >> signature includes the rest of the fields PLUS the signature itself >> (the 3rd input block is "+ StoredData +"). >> >> If I am not mistaken, the correct definition for the signature input >> should be: >> >> resource_id + kind + storage_time + lifetime + value + SignerIdentity >> >> The fact that "length" includes the size of the signature is somewhat >> awkward to be in the input. Excluding it does not degrade the >> security of the signature. If it is up to me, instead of setting >> "lifetime" to 0 before signing, why not exclude it all together? > > Where does the length field include the sizeof(signature)? See above. > >> >> 3) "SignerIdentity" in this section should refer to its definition in >> Section 5.3.4 to prevent people from reading it as simply a 20-byte >> SHA1 hash value. >> >> SignerIdentity >> The signer identity as defined in Section 5.3.4, which MUST include >> a hash of the signer's certificate. >> >> >> Thanks >> >> --Michael >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > >