From gonzalo.camarillo@ericsson.com Fri Jul 1 04:39:00 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEDB21F8606 for ; Fri, 1 Jul 2011 04:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+OUK0jl6uCa for ; Fri, 1 Jul 2011 04:38:59 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4E521F8603 for ; Fri, 1 Jul 2011 04:38:58 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-bf-4e0db1d16d7c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6C.A8.20773.1D1BD0E4; Fri, 1 Jul 2011 13:38:57 +0200 (CEST) Received: from [131.160.126.185] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Fri, 1 Jul 2011 13:38:55 +0200 Message-ID: <4E0DB1D0.6060703@ericsson.com> Date: Fri, 1 Jul 2011 14:38:56 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [P2PSIP] AD review: draft-ietf-p2psip-base-15 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2011 11:39:00 -0000 Folks, the P2PSIP WG chairs are in the process of requesting the publication of the following draft: https://datatracker.ietf.org/doc/draft-ietf-p2psip-base/ At this point, they are working with the secretary to fix the state of the document in the tracker (it should be publication requested) and to upload the document's PROTO write up. While that gets fixed, I have done my AD review (see below) in order to gain some time. As soon as these comments are addressed, I will start the IETF LC on this draft. Cheers, Gonzalo Review of draft-ietf-p2psip-base-15: I have also included a number nits in this review because I spotted them while reviewing the document. While some of them could have been caught by the RFC editor at a later point, I chose to report them now anyway. The last paragraph of page 8 says: This specification also defines how RELOAD is used with the Chord DHT algorithm, which is mandatory to implement. However, the draft says later: This specification defines a DHT based on Chord. The draft should always talk about a Chord-based DHT or something along those lines, then. The draft references a few drafts that have expired such as the following two: http://tools.ietf.org/html/draft-ietf-p2psip-sip-05 http://tools.ietf.org/html/draft-ietf-p2psip-concepts-03 We need to have non-expired versions of those drafts in the repository during the IETF LC and the IESG review. Chairs, please make sure that happens. On page 12, in the "Overlay Link Layer" bullet there is a normative MAY. Given that Section 1 consists on an introduction, the statement is not about the protocol, and the RFC 2119 terms have not been introduced yet (they are introduced in Section 2), I would s/MAY/may/. Last two words of page 13: s/An usage/A usage/ Page 18 in the Kind bullet: s/story/store/ First paragraph of page 19: when talking about unstructured and structured P2P networks, reference the IAB RFC that discusses them: RFC 5694. Section 3 is an overview section. However, Section 3.2.1 contains a few normative statements. They should probably be replaced by non-normative statements. Section 3.3 starts with: This section will discuss the requirements RELOAD's routing capabilities must meet... Now that RELOAD is (virtually) finished, the sentences should talk about the requirements as those that were used when designing RELOAD and that RELOAD meets instead. Page 24 says: Symmetric recursive routing requires that a message follow a path through the overlay to the destination without returning to the originating node: each peer forwards the message closer to its destination. The return path of the response is then the same path followed in reverse. The fact that recursive routing is defined as a path that does not "return" and then the following sentence talks about the return path can be confusing. The authors may want to slightly rephrase that sentence to avoid that. The following two references: o [I-D.maenpaa-p2psip-service-discovery] o [I-D.maenpaa-p2psip-self-tuning] should be replaced with the following ones: o draft-ietf-p2psip-service-discovery o draft-ietf-p2psip-self-tuning The structure of Section 5.1 is confusing. Section 5.1 presents three possible cases in three bullets. Those bullets seems to be expanded in the three (sub)sections that follow (Sections 5.1.1, 5.1.2, and 5.1.3). If that is the intent, Section 5.1 needs to be clearer. Right now, the link between the bullets and those three sections is confusing. For example, the first bullet uses the term peer while the first sentence in Section 5.1.1 uses the term node. The third bullet refers to Section 5.3.2.2 but does not mention Section 5.1.3. Section 5.1.2 talks about "the other three cases" but it is not clear what other three cases it refers to. Section 5.2.1 defines a set of timers by value. Why doesn't it define the timers by name and then provides default values instead? First paragraph of Section 5.3.1: "define TLS. [RFC5246]". The period goes after the reference. The last paragraph of Section 5.3.1 says: For instance, "uint16 array<0..2^8-2>;" represents up to 254 bytes but only up to 127 values of two bytes (16 bits) each. Doing s/but only up to/which corresponds to up to/ (or something similar) would make the sentence clearer. Section 5.3.2 says: (the string 'RELO' with the high bit of the first byte set.). The first period should be removed. Section 5.5.1.3 says: o In this case, the "stream" refers not to RTP or other types of media, but rather to a connection for RELOAD itself or for SIP signaling. The connection could also be for other application-layer protocols other than SIP. Section 5.5.1.5 says: Therefore it is RECOMMENDED that full ICE be used even for a node that has a public, unfiltered IP address, to take advantage of STUN connectivity checks, etc. This sentence seems to indicate that each node defines whether or not to use full ICE. However, the previous paragraph talks about the use of ICE being an overlay-wide setting that affects every node in a given overlay. Last paragraph of page 66: include a reference to ICE TCP when talking about new uses of ICE. The three bullets at the beginning of page 67 prioritize different transport protocols. The second bullet talks about "stream-oriented protocols". However, that is not the main feature that makes TCP better than the protocols in the third bullet. The main feature is that it offers "well-understood congestion and flow control", as the protocols in the first bullet do. The bullets should be clearer that bullet two is better than bullet three because of its congestion avoidance properties and worse than bullet 1 because of its lack of message orientation and HOLB avoidance. The same bullets and other sections in the draft talk about DCCP. Does the WG think DCCP could be an appropriate transport for RELOAD? Section 5.5.1.10 says: When neither side has provided an No-ICE candidate, connectivity checks and nominations are used as in regular ICE. The same question as before. Isn't the use of ICE an overlay-wide property? First sentence of Section 5.5.1.13: s/(RELOAD)/(e.g., RELOAD)/ Section 5.6 explicitly talks about "three Overlay Link protocols" but Section 5.6.1 says: The only currently defined overlay link protocols are TLS and DTLS. That sentence should include both DTLS with and without ICE for consistency. Section 5.6.1.4: note that Baset's proposal for TCP over UDP encapsulation was just one of the existing the proposals for TCP over UDP encapsulation. Section 5.6.3.1 says: "simple, inefficient, scheme". Remove the second comma. Section 6.4.1.2 talks about the Stat method for the same time. Add a forward reference to Section 6.4.3, which describes it). For example, adding "(see Section 6.4.3) would be enough. Second paragraph of Section 14: for consistency with the other paragraphs, instead of writing the initials, the given names are Jouni, Gonzalo, and Jani respectively. ID nits complains about the following references: ** Downref: Normative reference to an Informational RFC: RFC 2818 ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Downref: Normative reference to an Informational RFC: RFC 3447 ** Downref: Normative reference to an Informational RFC: RFC 6091 ** Downref: Normative reference to an Informational RFC: RFC 6234 Can the authors confirm that all these downrefs need to be normative references? Also, should the reference to RFC 2988 be updated to refer to RFC 6298? I am also working on getting an XML reviewer to have a look at Sections 10.1 and 10.1.1 of the draft. If you are interested, let me know. From gonzalo.camarillo@ericsson.com Fri Jul 1 04:47:58 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A8021F871C for ; Fri, 1 Jul 2011 04:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoICWPual8bq for ; Fri, 1 Jul 2011 04:47:58 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B7A8E21F8716 for ; Fri, 1 Jul 2011 04:47:57 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-29-4e0db3ec21ba Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1E.D9.20773.CE3BD0E4; Fri, 1 Jul 2011 13:47:56 +0200 (CEST) Received: from [131.160.126.185] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 1 Jul 2011 13:47:56 +0200 Message-ID: <4E0DB3EC.1040705@ericsson.com> Date: Fri, 1 Jul 2011 14:47:56 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E00F7CE.7080402@acm.org> In-Reply-To: <4E00F7CE.7080402@acm.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2011 11:47:59 -0000 Hi, please, let me know whether or not these modifications will be included in the base draft at this point. Thanks, Gonzalo On 21/06/2011 10:58 PM, Marc Petit-Huguenin wrote: > I read the paper and this modification makes sense to me (for example without > this modification a peer that is purely used for routing and storage purpose, > like a bootstrap peer, had to invent a valid, unique, and useless username just > to acquire a certificate). > > So I support its inclusion in draft-ietf-p2psip-base. > > On 06/09/2011 10:47 AM, Diego Suarez wrote: >> I think it would require a (slight) modification in the base document. >> Current P2PSIP certification model is based on a single PKC (including >> both usernames and nodeIDs) that uniquely identifies a user and her >> devices. On the other hand, our model is base on a split certification. >> Devices and users are independent. Each device has its own PKC including >> a nodeID and a PK. Similarly, each user has her own PKC including her >> username and a PK. This approach do not prevent a centralized entity >> (such as an offline CA) to have information related to the devices each >> user (or company, etc.) has registered, but permits, among other >> improvements, a user to be connected to the system through devices she >> has not registered herself such as a phone issued by a telco or a fixed >> phone in a laboratory shared by all the members of a research group. > > >> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: >> Does this model really required modifications in the base document, or can it be >> designed as an extension? (Unfortunately the paper is not freely available, so >> it is difficult to know really what is needed for this). > >> On 06/09/2011 07:31 AM, Diego Suarez wrote: >>>>> Hi, >>>>> >>>>> I had in mind writing a draft about this, but since I'm running out of >>>>> time, I would like to summarize a new certification model for P2PSIP I >>>>> have been working on, in case it is of interest for the group. >>>>> Further details can be found in paper: >>>>> >>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, Advantages of >>>>> identity certificate segregation in P2PSIP systems, Communications, >>>>> IET, vol. 5, pp. 879889, Apr. 2011. >>>>> >>>>> >>>>> The idea is to split the certification of users and devices. Devices are >>>>> identified by PKCs including a nodeID and the PK of the device, while >>>>> users are identified by PKCs including a username and the PK of the >>>>> user. Similar models have been used before in other communications >>>>> systems, such as GSM where devices and users are separately represented >>>>> by the international mobile equipment identity (IMEI) stored in the >>>>> phones and the international mobile subscriber identity (IMSI) stored in >>>>> the user subscriber identity module (SIM), respectively. >>>>> >>>>> Motivations of this model are: >>>>> >>>>> - Users and devices are different entities performing different >>>>> roles within a P2PSIP system. Devices are nodes of the P2P >>>>> overlay network (represented by a nodeID) that offer services >>>>> (to route messages, to store data, . . .) to the system, while >>>>> users (represented by an username) utilize these services, >>>>> usually to establish media communications using SIP. >>>>> >>>>> - Support for mobility scenarios where a user may be logged at different >>>>> devices at the same time using the same PKC. >>>>> >>>>> - Support several users to be logged in the same device (like a fixed >>>>> phone) at the same time. >>>>> >>>>> - Support for user independent hard-coded devices. >>>>> >>>>> - Interoperability with SIP. SIP certificates are not valid in actual >>>>> P2PSIP since they don't include a nodeID. >>>>> >>>>> cheers >>>>> >>>>> Diego Suárez >>>>> >>>>> >>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: >>>>>> Unless something major comes up, we plan to request the newest version >>>>>> of the base draft, draft-ietf-p2psip-base-15, be published. I'll put >>>>>> in the request in a week (June 16th or 17th). If there are any further >>>>>> comments from the last call a while ago (or further comments on the >>>>>> comments since then), please send them to the list ASAP. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> David (as chair) >>>>>> _______________________________________________ >>>>>> 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 petithug@acm.org Fri Jul 1 09:19:01 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434BE1F0C4F for ; Fri, 1 Jul 2011 09:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLdV9isMsBOi for ; Fri, 1 Jul 2011 09:19:00 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 38D2F1F0C5A for ; Fri, 1 Jul 2011 09:19:00 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id B83402199E for ; Fri, 1 Jul 2011 18:18:16 +0200 (CEST) Message-ID: <4E0DF36E.50607@acm.org> Date: Fri, 01 Jul 2011 09:18:54 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] draft-ietf-p2psip-sip-05 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2011 16:19:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have two small comments on this draft: - - Section 7: "The data stored is a SipRegistrationData..." It should be "SipRegistration" - - Section 7: "The rfc822Name does not include the scheme so..." I think that this sentence should be also somewhere at the beginning of the draft, as it is confusing to see that the term AOR is used everywhere in relation to the Resource Name, where in fact it is not an AOR at all. Perhaps the best is to define a new term (indicating the relationship with AOR) in section 3, and to substitute the word AOR everywhere in the spec with this new term. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4N82wACgkQ9RoMZyVa61e1CACeOVJIHaf7Surtis0/uudKtybX 5kYAn23lG5volZB6oghdMcnq7/JsKwtl =isEe -----END PGP SIGNATURE----- From petithug@acm.org Fri Jul 1 15:44:19 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF3111E81F9 for ; Fri, 1 Jul 2011 15:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7uhNpELmL3z for ; Fri, 1 Jul 2011 15:44:18 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDE511E81F7 for ; Fri, 1 Jul 2011 15:44:18 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 8475B2199E; Sat, 2 Jul 2011 00:43:35 +0200 (CEST) Message-ID: <4E0E4DBE.5060302@acm.org> Date: Fri, 01 Jul 2011 15:44:14 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: Diego Suarez References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> In-Reply-To: <1307641649.5184.17.camel@santeles> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2011 22:44:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Diego, How does this work with an access control policy like USER-NODE-MATCH, which requires both a Node-ID and a username in the SignerIdentity? If the Node-ID and the username are in separate certificates, wouldn't that require to extend the SignerIdentity structure to store multiple identities? Thanks. On 06/09/2011 10:47 AM, Diego Suarez wrote: > I think it would require a (slight) modification in the base document. > Current P2PSIP certification model is based on a single PKC (including > both usernames and nodeIDs) that uniquely identifies a user and her > devices. On the other hand, our model is base on a split certification. > Devices and users are independent. Each device has its own PKC including > a nodeID and a PK. Similarly, each user has her own PKC including her > username and a PK. This approach do not prevent a centralized entity > (such as an offline CA) to have information related to the devices each > user (or company, etc.) has registered, but permits, among other > improvements, a user to be connected to the system through devices she > has not registered herself such as a phone issued by a telco or a fixed > phone in a laboratory shared by all the members of a research group. > > > On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: > Does this model really required modifications in the base document, or can it be > designed as an extension? (Unfortunately the paper is not freely available, so > it is difficult to know really what is needed for this). > > On 06/09/2011 07:31 AM, Diego Suarez wrote: >>>> Hi, >>>> >>>> I had in mind writing a draft about this, but since I'm running out of >>>> time, I would like to summarize a new certification model for P2PSIP I >>>> have been working on, in case it is of interest for the group. >>>> Further details can be found in paper: >>>> >>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, Advantages of >>>> identity certificate segregation in P2PSIP systems, Communications, >>>> IET, vol. 5, pp. 879889, Apr. 2011. >>>> >>>> >>>> The idea is to split the certification of users and devices. Devices are >>>> identified by PKCs including a nodeID and the PK of the device, while >>>> users are identified by PKCs including a username and the PK of the >>>> user. Similar models have been used before in other communications >>>> systems, such as GSM where devices and users are separately represented >>>> by the international mobile equipment identity (IMEI) stored in the >>>> phones and the international mobile subscriber identity (IMSI) stored in >>>> the user subscriber identity module (SIM), respectively. >>>> >>>> Motivations of this model are: >>>> >>>> - Users and devices are different entities performing different >>>> roles within a P2PSIP system. Devices are nodes of the P2P >>>> overlay network (represented by a nodeID) that offer services >>>> (to route messages, to store data, . . .) to the system, while >>>> users (represented by an username) utilize these services, >>>> usually to establish media communications using SIP. >>>> >>>> - Support for mobility scenarios where a user may be logged at different >>>> devices at the same time using the same PKC. >>>> >>>> - Support several users to be logged in the same device (like a fixed >>>> phone) at the same time. >>>> >>>> - Support for user independent hard-coded devices. >>>> >>>> - Interoperability with SIP. SIP certificates are not valid in actual >>>> P2PSIP since they don't include a nodeID. >>>> >>>> cheers >>>> >>>> Diego Suárez >>>> >>>> >>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: >>>>> Unless something major comes up, we plan to request the newest version >>>>> of the base draft, draft-ietf-p2psip-base-15, be published. I'll put >>>>> in the request in a week (June 16th or 17th). If there are any further >>>>> comments from the last call a while ago (or further comments on the >>>>> comments since then), please send them to the list ASAP. >>>>> >>>>> Thanks, >>>>> >>>>> David (as chair) >>>>> _______________________________________________ >>>>> 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 > > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4OTbsACgkQ9RoMZyVa61fT2wCgqvIOHjARLO47zfHLRTYFrgt7 XYYAn1tF6/fhwO0bfttpuy4ELx3c0kjC =NS7V -----END PGP SIGNATURE----- From loopp2psip@gmail.com Sat Jul 2 09:28:28 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3065511E808C for ; Sat, 2 Jul 2011 09:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UloNPb6fRFm0 for ; Sat, 2 Jul 2011 09:28:27 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAB0228006 for ; Sat, 2 Jul 2011 09:28:26 -0700 (PDT) Received: by wyj26 with SMTP id 26so3152321wyj.31 for ; Sat, 02 Jul 2011 09:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=L+2sf0RNMAy1Whj/YyDClRDckWjkbXwSB0jWY+Mcgv4=; b=ByNAkguQwZAOqe9hfonYlMMrfpiAHpNNrgFpmazn+KCWZvTBhEKIV+DZOWaWbe0YPp dXjpxZJNOHrw9Fha5s2lzYhURtHejU4pvFq0TkR2FMZ+N9mXWcl2YMkA8Xu+oHt3hB7o rNvpH5Pb9W6G/LZX65cqIBbY8lP985qrAGfyw= Received: by 10.227.182.2 with SMTP id ca2mr4009893wbb.89.1309624105579; Sat, 02 Jul 2011 09:28:25 -0700 (PDT) Received: from [192.168.1.3] (96.134.16.95.dynamic.jazztel.es [95.16.134.96]) by mx.google.com with ESMTPS id fi5sm3106643wbb.5.2011.07.02.09.28.21 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Jul 2011 09:28:23 -0700 (PDT) From: Diego Suarez To: Marc Petit-Huguenin In-Reply-To: <4E0E4DBE.5060302@acm.org> References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E0E4DBE.5060302@acm.org> Content-Type: text/plain; charset="UTF-8" Date: Sat, 02 Jul 2011 18:28:19 +0200 Message-ID: <1309624099.5232.23.camel@santeles> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2011 16:28:28 -0000 Hi, >From my point of view, in this case the user has to both prove she is in possession of the PKC that includes the required username and also prove she is operating from the required node. However, modifying the SignerIdentity to include multiple identities ( the user and the device ) would not really prove that since only one signature could be included (either the user's signature or the device's one). Therefore, I'd modify the SecurityBlock instead to allow the inclusion of more than only one signature. For this case, the securityBlock would include two signatures. One with the SignerIdentity of the user and the signature of the user's PKC (including the username ) and another with the SignerIdentity of the device and the signature of the device's PKC ( including the nodeID). cheers On Fri, 2011-07-01 at 15:44 -0700, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Diego, > > How does this work with an access control policy like USER-NODE-MATCH, which > requires both a Node-ID and a username in the SignerIdentity? If the Node-ID > and the username are in separate certificates, wouldn't that require to extend > the SignerIdentity structure to store multiple identities? > > Thanks. > > On 06/09/2011 10:47 AM, Diego Suarez wrote: > > I think it would require a (slight) modification in the base document. > > Current P2PSIP certification model is based on a single PKC (including > > both usernames and nodeIDs) that uniquely identifies a user and her > > devices. On the other hand, our model is base on a split certification. > > Devices and users are independent. Each device has its own PKC including > > a nodeID and a PK. Similarly, each user has her own PKC including her > > username and a PK. This approach do not prevent a centralized entity > > (such as an offline CA) to have information related to the devices each > > user (or company, etc.) has registered, but permits, among other > > improvements, a user to be connected to the system through devices she > > has not registered herself such as a phone issued by a telco or a fixed > > phone in a laboratory shared by all the members of a research group. > > > > > > On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: > > Does this model really required modifications in the base document, or can it be > > designed as an extension? (Unfortunately the paper is not freely available, so > > it is difficult to know really what is needed for this). > > > > On 06/09/2011 07:31 AM, Diego Suarez wrote: > >>>> Hi, > >>>> > >>>> I had in mind writing a draft about this, but since I'm running out of > >>>> time, I would like to summarize a new certification model for P2PSIP I > >>>> have been working on, in case it is of interest for the group. > >>>> Further details can be found in paper: > >>>> > >>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, Advantages of > >>>> identity certificate segregation in P2PSIP systems, Communications, > >>>> IET, vol. 5, pp. 879889, Apr. 2011. > >>>> > >>>> > >>>> The idea is to split the certification of users and devices. Devices are > >>>> identified by PKCs including a nodeID and the PK of the device, while > >>>> users are identified by PKCs including a username and the PK of the > >>>> user. Similar models have been used before in other communications > >>>> systems, such as GSM where devices and users are separately represented > >>>> by the international mobile equipment identity (IMEI) stored in the > >>>> phones and the international mobile subscriber identity (IMSI) stored in > >>>> the user subscriber identity module (SIM), respectively. > >>>> > >>>> Motivations of this model are: > >>>> > >>>> - Users and devices are different entities performing different > >>>> roles within a P2PSIP system. Devices are nodes of the P2P > >>>> overlay network (represented by a nodeID) that offer services > >>>> (to route messages, to store data, . . .) to the system, while > >>>> users (represented by an username) utilize these services, > >>>> usually to establish media communications using SIP. > >>>> > >>>> - Support for mobility scenarios where a user may be logged at different > >>>> devices at the same time using the same PKC. > >>>> > >>>> - Support several users to be logged in the same device (like a fixed > >>>> phone) at the same time. > >>>> > >>>> - Support for user independent hard-coded devices. > >>>> > >>>> - Interoperability with SIP. SIP certificates are not valid in actual > >>>> P2PSIP since they don't include a nodeID. > >>>> > >>>> cheers > >>>> > >>>> Diego Suárez > >>>> > >>>> > >>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: > >>>>> Unless something major comes up, we plan to request the newest version > >>>>> of the base draft, draft-ietf-p2psip-base-15, be published. I'll put > >>>>> in the request in a week (June 16th or 17th). If there are any further > >>>>> comments from the last call a while ago (or further comments on the > >>>>> comments since then), please send them to the list ASAP. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> David (as chair) > >>>>> _______________________________________________ > >>>>> 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 > > > > > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk4OTbsACgkQ9RoMZyVa61fT2wCgqvIOHjARLO47zfHLRTYFrgt7 > XYYAn1tF6/fhwO0bfttpuy4ELx3c0kjC > =NS7V > -----END PGP SIGNATURE----- From petithug@acm.org Sat Jul 2 10:04:17 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C472611E80AD for ; Sat, 2 Jul 2011 10:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBojQ5D8KfwS for ; Sat, 2 Jul 2011 10:04:16 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 975DD11E8073 for ; Sat, 2 Jul 2011 10:04:16 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 0E80C2199E; Sat, 2 Jul 2011 19:03:30 +0200 (CEST) Message-ID: <4E0F4F8D.9080108@acm.org> Date: Sat, 02 Jul 2011 10:04:13 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: Diego Suarez References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E0E4DBE.5060302@acm.org> <1309624099.5232.23.camel@santeles> In-Reply-To: <1309624099.5232.23.camel@santeles> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2011 17:04:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/02/2011 09:28 AM, Diego Suarez wrote: > Hi, > >>From my point of view, in this case the user has to both prove she is in > possession of the PKC that includes the required username and also prove > she is operating from the required node. However, modifying the > SignerIdentity to include multiple identities ( the user and the > device ) would not really prove that since only one signature could be > included (either the user's signature or the device's one). > > Therefore, I'd modify the SecurityBlock instead to allow the inclusion > of more than only one signature. > > For this case, the securityBlock would include two signatures. One with > the SignerIdentity of the user and the signature of the user's PKC > (including the username ) and another with the SignerIdentity of the > device and the signature of the device's PKC ( including the nodeID). Right, something like this: struct { GenericCertificate certificates<0..2^16-1>; Signature signatures<0..2^16-1>; } SecurityBlock; Note that StoredData also needs to be modified: struct { uint32 length; uint64 storage_time; uint32 lifetime; StoredDataValue value; Signature signatures<0..2^16-1>; } StoredData; > > cheers > > > On Fri, 2011-07-01 at 15:44 -0700, Marc Petit-Huguenin wrote: > Hi Diego, > > How does this work with an access control policy like USER-NODE-MATCH, which > requires both a Node-ID and a username in the SignerIdentity? If the Node-ID > and the username are in separate certificates, wouldn't that require to extend > the SignerIdentity structure to store multiple identities? > > Thanks. > > On 06/09/2011 10:47 AM, Diego Suarez wrote: >>>> I think it would require a (slight) modification in the base document. >>>> Current P2PSIP certification model is based on a single PKC (including >>>> both usernames and nodeIDs) that uniquely identifies a user and her >>>> devices. On the other hand, our model is base on a split certification. >>>> Devices and users are independent. Each device has its own PKC including >>>> a nodeID and a PK. Similarly, each user has her own PKC including her >>>> username and a PK. This approach do not prevent a centralized entity >>>> (such as an offline CA) to have information related to the devices each >>>> user (or company, etc.) has registered, but permits, among other >>>> improvements, a user to be connected to the system through devices she >>>> has not registered herself such as a phone issued by a telco or a fixed >>>> phone in a laboratory shared by all the members of a research group. >>>> >>>> >>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: >>>> Does this model really required modifications in the base document, or can it be >>>> designed as an extension? (Unfortunately the paper is not freely available, so >>>> it is difficult to know really what is needed for this). >>>> >>>> On 06/09/2011 07:31 AM, Diego Suarez wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I had in mind writing a draft about this, but since I'm running out of >>>>>>> time, I would like to summarize a new certification model for P2PSIP I >>>>>>> have been working on, in case it is of interest for the group. >>>>>>> Further details can be found in paper: >>>>>>> >>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, Advantages of >>>>>>> identity certificate segregation in P2PSIP systems, Communications, >>>>>>> IET, vol. 5, pp. 879889, Apr. 2011. >>>>>>> >>>>>>> >>>>>>> The idea is to split the certification of users and devices. Devices are >>>>>>> identified by PKCs including a nodeID and the PK of the device, while >>>>>>> users are identified by PKCs including a username and the PK of the >>>>>>> user. Similar models have been used before in other communications >>>>>>> systems, such as GSM where devices and users are separately represented >>>>>>> by the international mobile equipment identity (IMEI) stored in the >>>>>>> phones and the international mobile subscriber identity (IMSI) stored in >>>>>>> the user subscriber identity module (SIM), respectively. >>>>>>> >>>>>>> Motivations of this model are: >>>>>>> >>>>>>> - Users and devices are different entities performing different >>>>>>> roles within a P2PSIP system. Devices are nodes of the P2P >>>>>>> overlay network (represented by a nodeID) that offer services >>>>>>> (to route messages, to store data, . . .) to the system, while >>>>>>> users (represented by an username) utilize these services, >>>>>>> usually to establish media communications using SIP. >>>>>>> >>>>>>> - Support for mobility scenarios where a user may be logged at different >>>>>>> devices at the same time using the same PKC. >>>>>>> >>>>>>> - Support several users to be logged in the same device (like a fixed >>>>>>> phone) at the same time. >>>>>>> >>>>>>> - Support for user independent hard-coded devices. >>>>>>> >>>>>>> - Interoperability with SIP. SIP certificates are not valid in actual >>>>>>> P2PSIP since they don't include a nodeID. >>>>>>> >>>>>>> cheers >>>>>>> >>>>>>> Diego Suárez >>>>>>> >>>>>>> >>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: >>>>>>>> Unless something major comes up, we plan to request the newest version >>>>>>>> of the base draft, draft-ietf-p2psip-base-15, be published. I'll put >>>>>>>> in the request in a week (June 16th or 17th). If there are any further >>>>>>>> comments from the last call a while ago (or further comments on the >>>>>>>> comments since then), please send them to the list ASAP. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> David (as chair) - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4PT4sACgkQ9RoMZyVa61dPvACeITly6/Zqumz4e4ZrAn1yGI4x ay4AoJ11vmCRDkL8pXuN71qaZXhw5JTZ =Tp+D -----END PGP SIGNATURE----- From bbl@lowekamp.net Sat Jul 2 13:54:03 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269D921F85E3 for ; Sat, 2 Jul 2011 13:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqIsDhWUl0oi for ; Sat, 2 Jul 2011 13:54:02 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id EBF8121F85D1 for ; Sat, 2 Jul 2011 13:54:01 -0700 (PDT) Received: by ewy19 with SMTP id 19so1719852ewy.31 for ; Sat, 02 Jul 2011 13:54:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.5.74 with SMTP id 50mr1382243eek.141.1309640039494; Sat, 02 Jul 2011 13:53:59 -0700 (PDT) Received: by 10.14.189.14 with HTTP; Sat, 2 Jul 2011 13:53:59 -0700 (PDT) In-Reply-To: <4E0F4F8D.9080108@acm.org> References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E0E4DBE.5060302@acm.org> <1309624099.5232.23.camel@santeles> <4E0F4F8D.9080108@acm.org> Date: Sat, 2 Jul 2011 16:53:59 -0400 Message-ID: From: Bruce Lowekamp To: Marc Petit-Huguenin , Diego Suarez Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2011 20:54:03 -0000 With the current definition of the protocol, split routing IDs and user IDs can be achieved by having the host node participate as a peer (or as a client, honestly) using its own cert and the attached users represented as virtual clients, i.e. generate messages as if they are on separate nodes attached to the host node as a client. If you wanted to implement it "natively," other than the USER-NODE-MATCH, as mentioned before, I can only find two changes that would need to be made to support split identities. For processing StoreReq: o For original (non-replica) stores, the StoreReq is signed by a credential which is authorized to write this kind at this Resource-Id. If this check fails, the request MUST be rejected with an Error_Forbidden error. and the definition of credential in beginning of 10.3. Assuming that there is not something I'm missing with using virtual clients, I'd rather not make any changes. This is a complicated enough protocol, and I think adding special cases for something like split identities just makes it more complicated. If any changes were made, I would think it should be something to make it possible for an extension to specify the change, but as long as the current protocol is capable of handling the functional goals, I'd rather no changes be made. Bruce On Sat, Jul 2, 2011 at 1:04 PM, Marc Petit-Huguenin wrot= e: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/02/2011 09:28 AM, Diego Suarez wrote: >> Hi, >> >>>From my point of view, in this case the user has to both prove she is in >> possession of the PKC that includes the required username and also prove >> she is operating from the required node. However, modifying the >> SignerIdentity to include multiple identities ( the user and the >> device ) would not really prove that since only one signature could be >> included (either the user's signature or the device's one). >> >> Therefore, I'd modify the SecurityBlock instead to allow the inclusion >> of more than only one signature. >> >> For this case, the securityBlock would include two signatures. One with >> the SignerIdentity of the user and the signature of the user's PKC >> (including the username ) and another with the SignerIdentity of the >> device and the signature of the device's PKC ( including the nodeID). > > Right, something like this: > > struct { > =C2=A0 GenericCertificate certificates<0..2^16-1>; > =C2=A0 Signature =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0signatures<0..2^16-1>; > =C2=A0 } SecurityBlock; > > Note that StoredData also needs to be modified: > > struct { > =C2=A0 uint32 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0length; > =C2=A0 uint64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0storage_time; > =C2=A0 uint32 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lifetime; > =C2=A0 StoredDataValue value; > =C2=A0 Signature =C2=A0 =C2=A0 =C2=A0 signatures<0..2^16-1>; > =C2=A0 } StoredData; > >> >> cheers >> >> >> On Fri, 2011-07-01 at 15:44 -0700, Marc Petit-Huguenin wrote: >> Hi Diego, >> >> How does this work with an access control policy like USER-NODE-MATCH, w= hich >> requires both a Node-ID and a username in the SignerIdentity? =C2=A0If t= he Node-ID >> and the username are in separate certificates, wouldn't that require to = extend >> the SignerIdentity structure to store multiple identities? >> >> Thanks. >> >> On 06/09/2011 10:47 AM, Diego Suarez wrote: >>>>> I think it would require a (slight) modification in the base document= . >>>>> Current P2PSIP certification model is based on a single PKC (includin= g >>>>> both usernames and nodeIDs) that uniquely identifies a user and her >>>>> devices. On the other hand, our model is base on a split certificatio= n. >>>>> Devices and users are independent. Each device has its own PKC includ= ing >>>>> a nodeID and a PK. Similarly, each user has her own PKC including her >>>>> username and a PK. This approach do not prevent a centralized entity >>>>> (such as an offline CA) to have information related to the devices ea= ch >>>>> user (or company, etc.) has registered, but permits, among other >>>>> improvements, a user to be connected to the system through devices sh= e >>>>> has not registered herself such as a phone issued by a telco or a fix= ed >>>>> phone in a laboratory shared by all the members of a research group. >>>>> >>>>> >>>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: >>>>> Does this model really required modifications in the base document, o= r can it be >>>>> designed as an extension? =C2=A0(Unfortunately the paper is not freel= y available, so >>>>> it is difficult to know really what is needed for this). >>>>> >>>>> On 06/09/2011 07:31 AM, Diego Suarez wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I had in mind writing a draft about this, but since I'm running ou= t of >>>>>>>> time, I would like to summarize a new certification model for P2PS= IP I >>>>>>>> have been working on, in case it is of interest for the group. >>>>>>>> Further details can be found in paper: >>>>>>>> >>>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, =C2=A0Advantag= es of >>>>>>>> identity certificate segregation in P2PSIP systems, =C2=A0Communic= ations, >>>>>>>> IET, vol. 5, pp. 879 889, Apr. 2011. >>>>>>>> >>>>>>>> >>>>>>>> The idea is to split the certification of users and devices. Devic= es are >>>>>>>> identified by PKCs including a nodeID and the PK of the device, wh= ile >>>>>>>> users are identified by PKCs including a username and the PK of th= e >>>>>>>> user. Similar models have been used before in other communications >>>>>>>> systems, such as GSM where devices and users are separately repres= ented >>>>>>>> by the international mobile equipment identity (IMEI) stored in th= e >>>>>>>> phones and the international mobile subscriber identity (IMSI) sto= red in >>>>>>>> the user subscriber identity module (SIM), respectively. >>>>>>>> >>>>>>>> Motivations of this model are: >>>>>>>> >>>>>>>> - Users and devices are different entities performing different >>>>>>>> roles within a P2PSIP system. Devices are nodes of the P2P >>>>>>>> overlay network (represented by a nodeID) that offer services >>>>>>>> (to route messages, to store data, . . .) to the system, while >>>>>>>> users (represented by an username) utilize these services, >>>>>>>> usually to establish media communications using SIP. >>>>>>>> >>>>>>>> - Support for mobility scenarios where a user may be logged at dif= ferent >>>>>>>> devices at the same time using the same PKC. >>>>>>>> >>>>>>>> - Support several users to be logged in the same device (like a fi= xed >>>>>>>> phone) at the same time. >>>>>>>> >>>>>>>> - Support for user independent hard-coded devices. >>>>>>>> >>>>>>>> - Interoperability with SIP. SIP certificates are not valid in act= ual >>>>>>>> P2PSIP since they don't include a nodeID. >>>>>>>> >>>>>>>> cheers >>>>>>>> >>>>>>>> Diego Su=C3=A1rez >>>>>>>> >>>>>>>> >>>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: >>>>>>>>> Unless something major comes up, we plan to request the newest ve= rsion >>>>>>>>> of the base draft, draft-ietf-p2psip-base-15, be published. I'll = put >>>>>>>>> in the request in a week (June 16th or 17th). If there are any fu= rther >>>>>>>>> comments from the last call a while ago (or further comments on t= he >>>>>>>>> comments since then), please send them to the list ASAP. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> David (as chair) > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk4PT4sACgkQ9RoMZyVa61dPvACeITly6/Zqumz4e4ZrAn1yGI4x > ay4AoJ11vmCRDkL8pXuN71qaZXhw5JTZ > =3DTp+D > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From loopp2psip@gmail.com Mon Jul 4 02:51:37 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AF521F859A for ; Mon, 4 Jul 2011 02:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.693 X-Spam-Level: X-Spam-Status: No, score=-2.693 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKb1rL8zavTQ for ; Mon, 4 Jul 2011 02:51:36 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 52D2821F84F4 for ; Mon, 4 Jul 2011 02:51:36 -0700 (PDT) Received: by wyj26 with SMTP id 26so3842370wyj.31 for ; Mon, 04 Jul 2011 02:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=hEYUNrefcfUqvrPw1AXRdOQ0um8PTLsO24DJ/ORJg3Y=; b=JkKztlWb3tfCU1ibUCM2yXhjc8Qja6rGkKLNIP0aryHq+YbGDWJj3YKOfJwuayfWnc ZwNrMdd8g/JiWQxol1OxDdM7SQDND8Uy2rt20qBNazAr6Rem/Aw5wMuR54z4Br63q5qH u8ucn13jLrVM806BRUkoBtk4VhEshhZqB+Mbk= Received: by 10.227.196.209 with SMTP id eh17mr5236860wbb.92.1309773095370; Mon, 04 Jul 2011 02:51:35 -0700 (PDT) Received: from [192.168.1.3] (96.134.16.95.dynamic.jazztel.es [95.16.134.96]) by mx.google.com with ESMTPS id fi5sm4337367wbb.56.2011.07.04.02.51.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jul 2011 02:51:32 -0700 (PDT) From: Diego Suarez To: Bruce Lowekamp In-Reply-To: References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E0E4DBE.5060302@acm.org> <1309624099.5232.23.camel@santeles> <4E0F4F8D.9080108@acm.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 04 Jul 2011 11:51:29 +0200 Message-ID: <1309773089.5716.43.camel@santeles> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2011 09:51:37 -0000 Hi, Actually, I see this "virtual client" method more complicated and confusing than splitting the identities of users and devices. With this model, you are gonna have a device identified by a PKC that includes a username and a nodeID acting as a peer, but only using its nodeID. And several users connected to the device as virtual clients identified by PKCs including a username and a nodeID, but only using their usernames. One of the more confusing things I see here is the access control. Imagine we have a device, with PKC ( # user = device1, nodeID = 100 # ) and two users ( # user = user1, nodeID = 200 # and # user = user2, nodeID = 300 # ) connected to that device acting as virtual clients. If user1 wants to perform a USER-NODE-MATCH access control related to the peer she is operating from ( actually the nodeID = 100 nor the virtual one with nodeID = 200 ) and her username ( user = user1 ), she is gonna have to create a request signed with her PKC and the PKC of the device. This request need to be doubled signed ( by the peer to grant the nodeID = 100 and by the user to grant the user = user 1 ). However, this double signed request intended for nodeID = 100 and user = user1 is gonna include two users = device1 and user1 and two nodeID = 100 and 200. This is confusing for me. Therefore, from my point of view, it makes sense to me to remove the username from the device and the node from the users since we are not using them and confuse the access control. Also, splitting identities have another advantages like greater interoperability with traditional SIP systems. Imagine a company running a SIP system, where users are identified by a PKC including a SIP username, that wants to extend its coverage interconnecting it with a P2PSIP system. With the actual certification model, SIP PKCs are not valid for the new P2PSIP side of the system. All the users have to be re-certificated to have a PKC including the old SIP username and a nodeID. However, with the split proposal SIP certificates are still valid in the P2PSIP side of the system and interoperable within the two networks, and only the devices intended to be used in the P2PSIP side have to be certified with a nodeID. cheers On Sat, 2011-07-02 at 16:53 -0400, Bruce Lowekamp wrote: > With the current definition of the protocol, split routing IDs and > user IDs can be achieved by having the host node participate as a peer > (or as a client, honestly) using its own cert and the attached users > represented as virtual clients, i.e. generate messages as if they are > on separate nodes attached to the host node as a client. > > If you wanted to implement it "natively," other than the > USER-NODE-MATCH, as mentioned before, I can only find two changes that > would need to be made to support split identities. > > For processing StoreReq: > o For original (non-replica) stores, the StoreReq is signed by a > credential which is authorized to write this kind at this > Resource-Id. If this check fails, the request MUST be rejected > with an Error_Forbidden error. > > and the definition of credential in beginning of 10.3. > > > Assuming that there is not something I'm missing with using virtual > clients, I'd rather not make any changes. This is a complicated > enough protocol, and I think adding special cases for something like > split identities just makes it more complicated. If any changes were > made, I would think it should be something to make it possible for an > extension to specify the change, but as long as the current protocol > is capable of handling the functional goals, I'd rather no changes be > made. > > Bruce > > > > > On Sat, Jul 2, 2011 at 1:04 PM, Marc Petit-Huguenin wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 07/02/2011 09:28 AM, Diego Suarez wrote: > >> Hi, > >> > >>>From my point of view, in this case the user has to both prove she is in > >> possession of the PKC that includes the required username and also prove > >> she is operating from the required node. However, modifying the > >> SignerIdentity to include multiple identities ( the user and the > >> device ) would not really prove that since only one signature could be > >> included (either the user's signature or the device's one). > >> > >> Therefore, I'd modify the SecurityBlock instead to allow the inclusion > >> of more than only one signature. > >> > >> For this case, the securityBlock would include two signatures. One with > >> the SignerIdentity of the user and the signature of the user's PKC > >> (including the username ) and another with the SignerIdentity of the > >> device and the signature of the device's PKC ( including the nodeID). > > > > Right, something like this: > > > > struct { > > GenericCertificate certificates<0..2^16-1>; > > Signature signatures<0..2^16-1>; > > } SecurityBlock; > > > > Note that StoredData also needs to be modified: > > > > struct { > > uint32 length; > > uint64 storage_time; > > uint32 lifetime; > > StoredDataValue value; > > Signature signatures<0..2^16-1>; > > } StoredData; > > > >> > >> cheers > >> > >> > >> On Fri, 2011-07-01 at 15:44 -0700, Marc Petit-Huguenin wrote: > >> Hi Diego, > >> > >> How does this work with an access control policy like USER-NODE-MATCH, which > >> requires both a Node-ID and a username in the SignerIdentity? If the Node-ID > >> and the username are in separate certificates, wouldn't that require to extend > >> the SignerIdentity structure to store multiple identities? > >> > >> Thanks. > >> > >> On 06/09/2011 10:47 AM, Diego Suarez wrote: > >>>>> I think it would require a (slight) modification in the base document. > >>>>> Current P2PSIP certification model is based on a single PKC (including > >>>>> both usernames and nodeIDs) that uniquely identifies a user and her > >>>>> devices. On the other hand, our model is base on a split certification. > >>>>> Devices and users are independent. Each device has its own PKC including > >>>>> a nodeID and a PK. Similarly, each user has her own PKC including her > >>>>> username and a PK. This approach do not prevent a centralized entity > >>>>> (such as an offline CA) to have information related to the devices each > >>>>> user (or company, etc.) has registered, but permits, among other > >>>>> improvements, a user to be connected to the system through devices she > >>>>> has not registered herself such as a phone issued by a telco or a fixed > >>>>> phone in a laboratory shared by all the members of a research group. > >>>>> > >>>>> > >>>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: > >>>>> Does this model really required modifications in the base document, or can it be > >>>>> designed as an extension? (Unfortunately the paper is not freely available, so > >>>>> it is difficult to know really what is needed for this). > >>>>> > >>>>> On 06/09/2011 07:31 AM, Diego Suarez wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I had in mind writing a draft about this, but since I'm running out of > >>>>>>>> time, I would like to summarize a new certification model for P2PSIP I > >>>>>>>> have been working on, in case it is of interest for the group. > >>>>>>>> Further details can be found in paper: > >>>>>>>> > >>>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, Advantages of > >>>>>>>> identity certificate segregation in P2PSIP systems, Communications, > >>>>>>>> IET, vol. 5, pp. 879 889, Apr. 2011. > >>>>>>>> > >>>>>>>> > >>>>>>>> The idea is to split the certification of users and devices. Devices are > >>>>>>>> identified by PKCs including a nodeID and the PK of the device, while > >>>>>>>> users are identified by PKCs including a username and the PK of the > >>>>>>>> user. Similar models have been used before in other communications > >>>>>>>> systems, such as GSM where devices and users are separately represented > >>>>>>>> by the international mobile equipment identity (IMEI) stored in the > >>>>>>>> phones and the international mobile subscriber identity (IMSI) stored in > >>>>>>>> the user subscriber identity module (SIM), respectively. > >>>>>>>> > >>>>>>>> Motivations of this model are: > >>>>>>>> > >>>>>>>> - Users and devices are different entities performing different > >>>>>>>> roles within a P2PSIP system. Devices are nodes of the P2P > >>>>>>>> overlay network (represented by a nodeID) that offer services > >>>>>>>> (to route messages, to store data, . . .) to the system, while > >>>>>>>> users (represented by an username) utilize these services, > >>>>>>>> usually to establish media communications using SIP. > >>>>>>>> > >>>>>>>> - Support for mobility scenarios where a user may be logged at different > >>>>>>>> devices at the same time using the same PKC. > >>>>>>>> > >>>>>>>> - Support several users to be logged in the same device (like a fixed > >>>>>>>> phone) at the same time. > >>>>>>>> > >>>>>>>> - Support for user independent hard-coded devices. > >>>>>>>> > >>>>>>>> - Interoperability with SIP. SIP certificates are not valid in actual > >>>>>>>> P2PSIP since they don't include a nodeID. > >>>>>>>> > >>>>>>>> cheers > >>>>>>>> > >>>>>>>> Diego Suárez > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: > >>>>>>>>> Unless something major comes up, we plan to request the newest version > >>>>>>>>> of the base draft, draft-ietf-p2psip-base-15, be published. I'll put > >>>>>>>>> in the request in a week (June 16th or 17th). If there are any further > >>>>>>>>> comments from the last call a while ago (or further comments on the > >>>>>>>>> comments since then), please send them to the list ASAP. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> > >>>>>>>>> David (as chair) > > > > - -- > > Marc Petit-Huguenin > > Personal email: marc@petit-huguenin.org > > Professional email: petithug@acm.org > > Blog: http://blog.marc.petit-huguenin.org > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.11 (GNU/Linux) > > > > iEYEARECAAYFAk4PT4sACgkQ9RoMZyVa61dPvACeITly6/Zqumz4e4ZrAn1yGI4x > > ay4AoJ11vmCRDkL8pXuN71qaZXhw5JTZ > > =Tp+D > > -----END PGP SIGNATURE----- > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > From petithug@acm.org Mon Jul 4 11:22:59 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BD31F0C37; Mon, 4 Jul 2011 11:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.657 X-Spam-Level: X-Spam-Status: No, score=-101.657 tagged_above=-999 required=5 tests=[AWL=-0.868, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mb7C-lWg5NNh; Mon, 4 Jul 2011 11:22:58 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 503371F0C34; Mon, 4 Jul 2011 11:22:51 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 7A0062199E; Mon, 4 Jul 2011 20:21:56 +0200 (CEST) Message-ID: <4E1204F5.3080808@acm.org> Date: Mon, 04 Jul 2011 11:22:45 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: [P2PSIP] Fwd: I-D Action: draft-petithuguenin-p2psip-proportional-quota-01.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2011 18:22:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This new version fixes some issues in the draft. Also a reference implementation is now available. Comments, suggestions and questions are welcome. Please follow-up in the p2psip mailing-list. Changelog: o Changed "storing peer" to "signer" as this works also for replica peers. o The default quota algorithm is per peer, not per Resource-ID. o Changed the constants in the XML extension accordingly. o Added running code considerations for reference implementation. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-p2psip-proportional-quota-01.txt Date: Mon, 04 Jul 2011 11:18:41 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Proportional Quota in REsource LOcation And Discovery (RELOAD) Author(s) : Jonathan Rosenberg Cullen Jennings Marc Petit-Huguenin Filename : draft-petithuguenin-p2psip-proportional-quota-01.txt Pages : 7 Date : 2011-07-04 This document defines an extension to RELOAD [I-D.ietf-p2psip-base] that limits the number of a specific kind element that can be stored by one RELOAD peer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-p2psip-proportional-quota-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-p2psip-proportional-quota-01.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4SBPQACgkQ9RoMZyVa61dG4QCgq03U4tYWhRjlMUbQaVQetPnk D7IAn0rnNzp1nR6k7AXh7IsvZfHk1ML2 =L8VG -----END PGP SIGNATURE----- From internet-drafts@ietf.org Tue Jul 5 01:39:09 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B1521F87D3; Tue, 5 Jul 2011 01:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONAvWyP37QTY; Tue, 5 Jul 2011 01:39:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E02121F87B8; Tue, 5 Jul 2011 01:39:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110705083908.10311.25426.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2011 01:39:08 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-self-tuning-04.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2011 08:39:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Proto= col Working Group of the IETF. Title : A Self-tuning Distributed Hash Table (DHT) for REsource = LOcation And Discovery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo Camarillo Jani Hautakorpi Filename : draft-ietf-p2psip-self-tuning-04.txt Pages : 20 Date : 2011-07-05 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/internet-drafts/draft-ietf-p2psip-self-tuning-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-self-tuning-04.txt From internet-drafts@ietf.org Tue Jul 5 02:28:36 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEF421F8788; Tue, 5 Jul 2011 02:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1EVbBMRmeIu; Tue, 5 Jul 2011 02:28:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9812C21F873E; Tue, 5 Jul 2011 02:28:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110705092835.26105.64030.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2011 02:28:35 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-service-discovery-03.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2011 09:28:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Proto= col Working Group of the IETF. Title : Service Discovery Usage for REsource LOcation And Discov= ery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo Camarillo Filename : draft-ietf-p2psip-service-discovery-03.txt Pages : 14 Date : 2011-07-05 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/internet-drafts/draft-ietf-p2psip-service-discovery-03.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-service-discovery-03.t= xt From petithug@acm.org Tue Jul 5 16:17:53 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82AE21F871E for ; Tue, 5 Jul 2011 16:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJFu7YyDrDg7 for ; Tue, 5 Jul 2011 16:17:53 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id F025B21F86AF for ; Tue, 5 Jul 2011 16:17:52 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 580DC2199E for ; Wed, 6 Jul 2011 01:16:55 +0200 (CEST) Message-ID: <4E139B9E.7090903@acm.org> Date: Tue, 05 Jul 2011 16:17:50 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Fwd: I-D Action: draft-petithuguenin-p2psip-access-control-03.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2011 23:17:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Changelog: o Moved the access-control-code element from the kind element to the configuration element so the code can be shared between kinds. A new "name" attribute is used to name the access control policy. o Added configuration object to pass information about the whole overlay. o Added evaluate functions to retrieve extensions parameters. o Renamed the signature attribute to signer. o Filled Security section. o Added temporary namespace to IANA section. o The content of the access-control-code is now UTF-8 encoded, compressed with gzip and converted back to characters with base64. o Fixed the implementation of the service discovery access control policy. o Added code for VIPR policy. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-p2psip-access-control-03.txt Date: Tue, 05 Jul 2011 16:14:53 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Configuration of Access Control Policy in REsource LOcation And Discovery (RELOAD) Base Protocol Author(s) : Marc Petit-Huguenin Filename : draft-petithuguenin-p2psip-access-control-03.txt Pages : 13 Date : 2011-07-05 This document describes an extension to the REsource LOcation And Discovery (RELOAD) base protocol to distribute the code of new Access Control Policies without having to upgrade the RELOAD implementations in an overlay. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-p2psip-access-control-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-p2psip-access-control-03.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4Tm50ACgkQ9RoMZyVa61djDwCfcdPmXEu0k6rLQD6bAyfRHgeK 7YUAn3HT7+Q/67E3ldufxM1yE+uuFCKy =2o/I -----END PGP SIGNATURE----- From fluffy@cisco.com Thu Jul 7 15:34:24 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF2621F8882 for ; Thu, 7 Jul 2011 15:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.277 X-Spam-Level: X-Spam-Status: No, score=-105.277 tagged_above=-999 required=5 tests=[AWL=-2.678, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ux0bVWMYSoOx for ; Thu, 7 Jul 2011 15:34:23 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB5B21F8854 for ; Thu, 7 Jul 2011 15:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5703; q=dns/txt; s=iport; t=1310078055; x=1311287655; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rMn6nAJwsbi2y9UV2RA4a6IFxHJi3n83vDLdIZymqs8=; b=HK6CFkNNFmGFUR4e5IZGQXfYoSnGB2fz0eIOrrT05IEHXIOQCT2m8D3R 9LyWWKId9T/tv/fkZ5qTkFeVF6yVgRyRkJvpS06lwIUTkvttiTG8a7q+F useAcWF/Wpd7wU+z5hzwK8kCHW93dezMZD+PLLXQdM2EkPX9D5I0IEFIl 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIEzFk6rRDoI/2dsb2JhbABGDac+d4h7pQydb4MjgxUEh0mKfIR8i2I X-IronPort-AV: E=Sophos;i="4.65,496,1304294400"; d="scan'208";a="848729" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 07 Jul 2011 22:34:15 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p67MYDGL000349; Thu, 7 Jul 2011 22:34:13 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <4E0DB3EC.1040705@ericsson.com> Date: Thu, 7 Jul 2011 16:34:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E00F7CE.7080402@acm.org> <4E0DB3EC.1040705@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1084) Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2011 22:34:24 -0000 This would break all the current deployments and implementation and not = just in a way where some new software would need to be pushed out - all = new certificates would need to be issues. =46rom my point of view, this = is too late for this change and instead it could be addressed with an = extension. On Jul 1, 2011, at 5:47 AM, Gonzalo Camarillo wrote: > Hi, >=20 > please, let me know whether or not these modifications will be = included > in the base draft at this point. >=20 > Thanks, >=20 > Gonzalo >=20 > On 21/06/2011 10:58 PM, Marc Petit-Huguenin wrote: >> I read the paper and this modification makes sense to me (for example = without >> this modification a peer that is purely used for routing and storage = purpose, >> like a bootstrap peer, had to invent a valid, unique, and useless = username just >> to acquire a certificate). >>=20 >> So I support its inclusion in draft-ietf-p2psip-base. >>=20 >> On 06/09/2011 10:47 AM, Diego Suarez wrote: >>> I think it would require a (slight) modification in the base = document. >>> Current P2PSIP certification model is based on a single PKC = (including >>> both usernames and nodeIDs) that uniquely identifies a user and her >>> devices. On the other hand, our model is base on a split = certification. >>> Devices and users are independent. Each device has its own PKC = including >>> a nodeID and a PK. Similarly, each user has her own PKC including = her >>> username and a PK. This approach do not prevent a centralized entity >>> (such as an offline CA) to have information related to the devices = each >>> user (or company, etc.) has registered, but permits, among other >>> improvements, a user to be connected to the system through devices = she >>> has not registered herself such as a phone issued by a telco or a = fixed >>> phone in a laboratory shared by all the members of a research group. >>=20 >>=20 >>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: >>> Does this model really required modifications in the base document, = or can it be >>> designed as an extension? (Unfortunately the paper is not freely = available, so >>> it is difficult to know really what is needed for this). >>=20 >>> On 06/09/2011 07:31 AM, Diego Suarez wrote: >>>>>> Hi,=20 >>>>>>=20 >>>>>> I had in mind writing a draft about this, but since I'm running = out of >>>>>> time, I would like to summarize a new certification model for = P2PSIP I >>>>>> have been working on, in case it is of interest for the group. >>>>>> Further details can be found in paper: >>>>>>=20 >>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, =1CAdvantages = of >>>>>> identity certificate segregation in P2PSIP systems,=1D = Communications, >>>>>> IET, vol. 5, pp. 879=13889, Apr. 2011. >>>>>>=20 >>>>>>=20 >>>>>> The idea is to split the certification of users and devices. = Devices are >>>>>> identified by PKCs including a nodeID and the PK of the device, = while >>>>>> users are identified by PKCs including a username and the PK of = the >>>>>> user. Similar models have been used before in other = communications >>>>>> systems, such as GSM where devices and users are separately = represented >>>>>> by the international mobile equipment identity (IMEI) stored in = the >>>>>> phones and the international mobile subscriber identity (IMSI) = stored in >>>>>> the user subscriber identity module (SIM), respectively. >>>>>>=20 >>>>>> Motivations of this model are: >>>>>>=20 >>>>>> - Users and devices are different entities performing different >>>>>> roles within a P2PSIP system. Devices are nodes of the P2P >>>>>> overlay network (represented by a nodeID) that offer services >>>>>> (to route messages, to store data, . . .) to the system, while >>>>>> users (represented by an username) utilize these services, >>>>>> usually to establish media communications using SIP. >>>>>>=20 >>>>>> - Support for mobility scenarios where a user may be logged at = different >>>>>> devices at the same time using the same PKC. >>>>>>=20 >>>>>> - Support several users to be logged in the same device (like a = fixed >>>>>> phone) at the same time. >>>>>>=20 >>>>>> - Support for user independent hard-coded devices. >>>>>>=20 >>>>>> - Interoperability with SIP. SIP certificates are not valid in = actual >>>>>> P2PSIP since they don't include a nodeID. >>>>>>=20 >>>>>> cheers >>>>>>=20 >>>>>> Diego Su=E1rez >>>>>>=20 >>>>>>=20 >>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: >>>>>>> Unless something major comes up, we plan to request the newest = version >>>>>>> of the base draft, draft-ietf-p2psip-base-15, be published. I'll = put >>>>>>> in the request in a week (June 16th or 17th). If there are any = further >>>>>>> comments from the last call a while ago (or further comments on = the >>>>>>> comments since then), please send them to the list ASAP. >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> David (as chair) >>>>>>> _______________________________________________ >>>>>>> P2PSIP mailing list >>>>>>> P2PSIP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> P2PSIP mailing list >>>>>> P2PSIP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>=20 >>=20 >>=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Thu Jul 7 15:34:25 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6B621F88AF for ; Thu, 7 Jul 2011 15:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.174 X-Spam-Level: X-Spam-Status: No, score=-105.174 tagged_above=-999 required=5 tests=[AWL=-2.575, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEsqfYleJzFR for ; Thu, 7 Jul 2011 15:34:25 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 20A1421F8854 for ; Thu, 7 Jul 2011 15:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1334; q=dns/txt; s=iport; t=1310078065; x=1311287665; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cZFXeb7Lv2U3UbO6heLYfo8WiOPv0NnGeb1ADDDwpjU=; b=Gw0atsdXYSSwpJpKjJiGF2sBUncTqrmX3/xG/s/ZRgL91MW7kPJPWSwd hLOoXDC0PExVgTvrnyV0iDGk5GyODHTMbyKYhOTs73R2JfvhaLER6jrGz 08xAxwgCv0/RiLZus4IH75q46cCTGvIIQMuGz9a1KmZ3CuIIE8LXLNVKW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIEzFk6rRDoI/2dsb2JhbABTpz53iHulDJ1vhjgEh0mKfIR8i2I X-IronPort-AV: E=Sophos;i="4.65,496,1304294400"; d="scan'208";a="849510" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-1.cisco.com with ESMTP; 07 Jul 2011 22:34:24 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p67MYDGM000349; Thu, 7 Jul 2011 22:34:23 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <20110610232556.61e8c06078a3b23a733c71e914c0b9df.a0b4262438.wbe@email00.secureserver.net> Date: Thu, 7 Jul 2011 16:34:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8485D628-3374-4503-9093-A04C3A91170A@cisco.com> References: <20110610232556.61e8c06078a3b23a733c71e914c0b9df.a0b4262438.wbe@email00.secureserver.net> To: Michael Chen X-Mailer: Apple Mail (2.1084) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Relax base-15 section 10.2 language X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2011 22:34:25 -0000 I agree - that was the intent and the later text more or less says that. = I have fixed this to be consistent with the later text.=20 On Jun 11, 2011, at 12:25 AM, Michael Chen wrote: > Hi, >=20 > Section 10.2, second paragraph says, "The node first determines the > overlay name. This value is provided by the user or some other out of > band provisioning mechanism. The out of band mechanisms may also = provide > an optional URL for the configuration server." >=20 > I believe the first sentence should be relaxed as "The node MAY first > determines the overlay name." A node should be allowed to start with > nothing but an arbitrary (out-of-band) URL to the configuration = server, > and that the overlay name will be whatever retrieved in the > configuration XML. This practice also means the node need not query = the > DNS or construct the "/.well-known/p2psip-enroll" URL. >=20 > For example, someone send you an email with a configuration URL. You > just click on that URL to join the overlay that someone setup. That > overlay name could be a 200 character hex string that would be very > painful to type in. >=20 > Thanks >=20 > --Michael >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Thu Jul 7 16:17:27 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0170D21F8854 for ; Thu, 7 Jul 2011 16:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF-7el1Zjl52 for ; Thu, 7 Jul 2011 16:17:26 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id E8CFC21F8853 for ; Thu, 7 Jul 2011 16:17:25 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 5BBCB2199E; Fri, 8 Jul 2011 01:16:17 +0200 (CEST) Message-ID: <4E163E7F.1000209@acm.org> Date: Thu, 07 Jul 2011 16:17:19 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: Cullen Jennings References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E00F7CE.7080402@acm.org> <4E0DB3EC.1040705@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2011 23:17:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/07/2011 03:34 PM, Cullen Jennings wrote: > > This would break all the current deployments and implementation and not just > in a way where some new software would need to be pushed out - all new > certificates would need to be issues. From my point of view, this is too late > for this change and instead it could be addressed with an extension. I agree that it is probably too late, but I am concerned that this modification is not really possible in an extension, but instead requires a new version of the protocol because it needs two signatures in SecureBlock and StoredData. > > On Jul 1, 2011, at 5:47 AM, Gonzalo Camarillo wrote: > >> Hi, >> >> please, let me know whether or not these modifications will be included in >> the base draft at this point. >> >> Thanks, >> >> Gonzalo >> >> On 21/06/2011 10:58 PM, Marc Petit-Huguenin wrote: >>> I read the paper and this modification makes sense to me (for example >>> without this modification a peer that is purely used for routing and >>> storage purpose, like a bootstrap peer, had to invent a valid, unique, >>> and useless username just to acquire a certificate). >>> >>> So I support its inclusion in draft-ietf-p2psip-base. >>> >>> On 06/09/2011 10:47 AM, Diego Suarez wrote: >>>> I think it would require a (slight) modification in the base document. >>>> Current P2PSIP certification model is based on a single PKC (including >>>> both usernames and nodeIDs) that uniquely identifies a user and her >>>> devices. On the other hand, our model is base on a split >>>> certification. Devices and users are independent. Each device has its >>>> own PKC including a nodeID and a PK. Similarly, each user has her own >>>> PKC including her username and a PK. This approach do not prevent a >>>> centralized entity (such as an offline CA) to have information related >>>> to the devices each user (or company, etc.) has registered, but >>>> permits, among other improvements, a user to be connected to the system >>>> through devices she has not registered herself such as a phone issued >>>> by a telco or a fixed phone in a laboratory shared by all the members >>>> of a research group. >>> >>> >>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: Does this >>>> model really required modifications in the base document, or can it be >>>> designed as an extension? (Unfortunately the paper is not freely >>>> available, so it is difficult to know really what is needed for this). >>> >>>> On 06/09/2011 07:31 AM, Diego Suarez wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I had in mind writing a draft about this, but since I'm running >>>>>>> out of time, I would like to summarize a new certification model >>>>>>> for P2PSIP I have been working on, in case it is of interest for >>>>>>> the group. Further details can be found in paper: >>>>>>> >>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, Advantages >>>>>>> of identity certificate segregation in P2PSIP systems, >>>>>>> Communications, IET, vol. 5, pp. 879889, Apr. 2011. >>>>>>> >>>>>>> >>>>>>> The idea is to split the certification of users and devices. >>>>>>> Devices are identified by PKCs including a nodeID and the PK of >>>>>>> the device, while users are identified by PKCs including a >>>>>>> username and the PK of the user. Similar models have been used >>>>>>> before in other communications systems, such as GSM where devices >>>>>>> and users are separately represented by the international mobile >>>>>>> equipment identity (IMEI) stored in the phones and the >>>>>>> international mobile subscriber identity (IMSI) stored in the >>>>>>> user subscriber identity module (SIM), respectively. >>>>>>> >>>>>>> Motivations of this model are: >>>>>>> >>>>>>> - Users and devices are different entities performing different >>>>>>> roles within a P2PSIP system. Devices are nodes of the P2P >>>>>>> overlay network (represented by a nodeID) that offer services (to >>>>>>> route messages, to store data, . . .) to the system, while users >>>>>>> (represented by an username) utilize these services, usually to >>>>>>> establish media communications using SIP. >>>>>>> >>>>>>> - Support for mobility scenarios where a user may be logged at >>>>>>> different devices at the same time using the same PKC. >>>>>>> >>>>>>> - Support several users to be logged in the same device (like a >>>>>>> fixed phone) at the same time. >>>>>>> >>>>>>> - Support for user independent hard-coded devices. >>>>>>> >>>>>>> - Interoperability with SIP. SIP certificates are not valid in >>>>>>> actual P2PSIP since they don't include a nodeID. >>>>>>> >>>>>>> cheers >>>>>>> >>>>>>> Diego Suárez >>>>>>> >>>>>>> >>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: >>>>>>>> Unless something major comes up, we plan to request the newest >>>>>>>> version of the base draft, draft-ietf-p2psip-base-15, be >>>>>>>> published. I'll put in the request in a week (June 16th or >>>>>>>> 17th). If there are any further comments from the last call a >>>>>>>> while ago (or further comments on the comments since then), >>>>>>>> please send them to the list ASAP. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4WPn0ACgkQ9RoMZyVa61eLNQCgi614Bs6sdoajQ+ASRC/36JWk 5y8An1wyr5TbRVqZ6VTCEnfUfz0GIKud =viZ4 -----END PGP SIGNATURE----- From fluffy@cisco.com Thu Jul 7 16:19:07 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4A921F88E5 for ; Thu, 7 Jul 2011 16:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.079 X-Spam-Level: X-Spam-Status: No, score=-105.079 tagged_above=-999 required=5 tests=[AWL=-2.480, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOvkSPql97VY for ; Thu, 7 Jul 2011 16:19:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9FB21F88E4 for ; Thu, 7 Jul 2011 16:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=833; q=dns/txt; s=iport; t=1310080747; x=1311290347; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=60LjNQ7Vis6RLtuJsQgkf9PRMew25QVL+lOANax1BRA=; b=Fti2xLBOBBXaKkdZoY6kNxMB1M8KU6sfhM7yChUhpUV3YDmmUg3mo7dL wLnBD9hdS+0Yc8aIlcB58cZxmAPh5SEmwJ9I3GvZoBVcTy2OXOzgZ1I+S ilNNaKU4wI3ss30hnWrUWaTdeNjaniEC8n8NMxDxhwPymTv4/823oA5uj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANc9Fk6rRDoI/2dsb2JhbABTpz53iHulIp1zhjgEh0mKfIR8i2I X-IronPort-AV: E=Sophos;i="4.65,496,1304294400"; d="scan'208";a="859994" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-2.cisco.com with ESMTP; 07 Jul 2011 23:19:06 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p67NJ4ex004837; Thu, 7 Jul 2011 23:19:05 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E0DF36E.50607@acm.org> Date: Thu, 7 Jul 2011 17:19:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <794DC8D4-0DA3-43F0-B2C1-D28BD61B67A9@cisco.com> References: <4E0DF36E.50607@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-sip-05 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2011 23:19:07 -0000 On Jul 1, 2011, at 10:18 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > I have two small comments on this draft: >=20 > - - Section 7: "The data stored is a SipRegistrationData..." fixed > It should be "SipRegistration" >=20 > - - Section 7: "The rfc822Name does not include the scheme so..." >=20 > I think that this sentence should be also somewhere at the beginning = of the > draft, as it is confusing to see that the term AOR is used everywhere = in > relation to the Resource Name, where in fact it is not an AOR at all. >=20 > Perhaps the best is to define a new term (indicating the relationship = with AOR) > in section 3, and to substitute the word AOR everywhere in the spec = with this > new term. I stuck with AOR but tired to clear this up.=20 From fluffy@cisco.com Thu Jul 7 17:22:50 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5E621F86F3 for ; Thu, 7 Jul 2011 17:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.99 X-Spam-Level: X-Spam-Status: No, score=-104.99 tagged_above=-999 required=5 tests=[AWL=-2.391, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQTOeMkNuPOh for ; Thu, 7 Jul 2011 17:22:49 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B3E8621F871B for ; Thu, 7 Jul 2011 17:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2392; q=dns/txt; s=iport; t=1310084569; x=1311294169; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=T0L43djz0uTvmvIw+DvzbyLOKfpjzpj0NjN3wdO7IR0=; b=kr24ZqSMWl9aaBibsLhAKJH9O/7K7Z8VvhChuvaf+lLs83Apz6+/R/ew Xc2UdYEwJzUPhSrTIn50ENpmhDTvL6ByDUIJb2x/e6oP67grzofbVG3Os MAiaufah/gRMf//qJORweJRWnREAF5FZwKUXgNuzxD2eOoF3/2hT3bLc6 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACJNFk6rRDoG/2dsb2JhbABTpz53iHulTp10hjgEh0mKfIR8i2I X-IronPort-AV: E=Sophos;i="4.65,496,1304294400"; d="scan'208";a="870514" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 08 Jul 2011 00:22:49 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p680Mlmf028568; Fri, 8 Jul 2011 00:22:48 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <21f1u6hael1utmpg3svvn2a6s3agncb5ov@hive.bjoern.hoehrmann.de> Date: Thu, 7 Jul 2011 18:22:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <45B798A3-37AD-49C9-99AC-A9B3A587B55A@cisco.com> References: <48AF46F9-5E4A-4D62-8DE0-EE6916D30F98@cisco.com> <21f1u6hael1utmpg3svvn2a6s3agncb5ov@hive.bjoern.hoehrmann.de> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1084) Cc: ietf-types@iana.org, P2PSIP Mailing List Subject: Re: [P2PSIP] [ietf-types] Registration of media type application/p2p-overlay+xml X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 00:22:50 -0000 On May 28, 2011, at 3:16 AM, Bjoern Hoehrmann wrote: > * Cullen Jennings wrote: > > To: ietf-types@iana.org > > > > Subject: Registration of media type application/p2p-overlay+xml >=20 > There is no reason to include this part in the specification. fixed - thanks =20 >=20 > > Type name: application > > > > Subtype name: p2p-overlay+xml > > > > Required parameters: none > > > > Optional parameters: none >=20 > Why are you using the +xml convention but do not specify the type in a > manner consistent with application/xml? I may have missed what part of 3023 part we violate but I read it and = could not see anything. Clearly the desire was to support UTF-8 which we = do.=20 > Without a very good reason I'd > think you should either add the "charset" parameter We are mandating UTF-8 as the charset which gives us the benefits would = hope. We don't want to have multiple charsets supported as we have noted = this reduces interoperability when some implementations don't bother to = implement charsets other than UTF-8. It's arbitrary choice that = increases what you need to implement and test, reduces interoperability, = and provides not benefits to the end user beyond what they get with = UTF-8.=20 > or drop the "+xml". It is xml so it seems like it is useful to use the +xml convention so = that systems that process that can use it.=20 >=20 > > Encoding considerations: Must be binary encoded. The contents = MUST > > be valid XML compliant with the relax NG grammar specified in RFC- > > AAAA and use the UTF-8[RFC3629] character encoding. >=20 > This should either just say "binary" or just reference RFC 3023 as RFC > 3023 suggests. Ok - removed this and moved it to additional info as it seems like = useful information.=20 >=20 > > Interoperability considerations: Same as application/xml as = defined > > in [RFC3023]. >=20 > If there are no known interoperability issues beyond those of the type > application/xml, that is what you should say; the considerations here > are certainly not the same. > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 = http://bjoern.hoehrmann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 = http://www.bjoernsworld.de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 = http://www.websitedev.de/ >=20 From internet-drafts@ietf.org Thu Jul 7 17:40:42 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EB621F8A42; Thu, 7 Jul 2011 17:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vM-nw7d64uJ; Thu, 7 Jul 2011 17:40:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C7A21F8A35; Thu, 7 Jul 2011 17:40:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110708004041.25774.42532.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2011 17:40:41 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-sip-06.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 00:40:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Proto= col Working Group of the IETF. Title : A SIP Usage for RELOAD Author(s) : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Filename : draft-ietf-p2psip-sip-06.txt Pages : 13 Date : 2011-07-07 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-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-sip-06.txt From internet-drafts@ietf.org Thu Jul 7 17:40:53 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53A921F8A4C; Thu, 7 Jul 2011 17:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIkCzzIA8mtR; Thu, 7 Jul 2011 17:40:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650B321F8A35; Thu, 7 Jul 2011 17:40:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110708004053.25490.14808.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2011 17:40:53 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-base-16.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 00:40:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Proto= col Working Group of the IETF. Title : REsource LOcation And Discovery (RELOAD) Base Protocol Author(s) : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Filename : draft-ietf-p2psip-base-16.txt Pages : 160 Date : 2011-07-07 This specification 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-base-16.txt From michaelc@IDSSOFTWARE.COM Thu Jul 7 17:48:52 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9118D21F8A3E for ; Thu, 7 Jul 2011 17:48:52 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6uDU-1v5xqp for ; Thu, 7 Jul 2011 17:48:52 -0700 (PDT) Received: from smtpoutwbe07.prod.mesa1.secureserver.net (smtpoutwbe07.prod.mesa1.secureserver.net [208.109.78.209]) by ietfa.amsl.com (Postfix) with SMTP id 11E9F21F8A05 for ; Thu, 7 Jul 2011 17:48:52 -0700 (PDT) Received: (qmail 18253 invoked from network); 8 Jul 2011 00:48:51 -0000 Received: from unknown (HELO gem-wbe30.prod.mesa1.secureserver.net) (64.202.189.164) by smtpoutwbe07.prod.mesa1.secureserver.net with SMTP; 8 Jul 2011 00:48:51 -0000 Received: (qmail 24302 invoked by uid 99); 8 Jul 2011 00:48:51 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.5.08 Message-Id: <20110707174850.61e8c06078a3b23a733c71e914c0b9df.97c67717b4.wbe@email00.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Thu, 07 Jul 2011 17:48:50 -0700 Mime-Version: 1.0 Subject: [P2PSIP] Configuration sequence number includes 0 or not X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 00:48:52 -0000 Hi, The base-15 draft definition for the configuration sequence number in section 10.1 says it is a number between 1 and 65534. This conflicts with section 5.3.2.1 last sentence, where it describes the wrapping of sequence number is setting it to 0 when it reaches 65535. Was sequence 0 intended for anything? Thanks --Michael From derhoermi@gmx.net Thu Jul 7 17:56:01 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D77F21F88FE for ; Thu, 7 Jul 2011 17:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.663 X-Spam-Level: X-Spam-Status: No, score=-3.663 tagged_above=-999 required=5 tests=[AWL=-1.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9pQA3O6DciF for ; Thu, 7 Jul 2011 17:56:00 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4E31121F88FD for ; Thu, 7 Jul 2011 17:56:00 -0700 (PDT) Received: (qmail invoked by alias); 08 Jul 2011 00:55:58 -0000 Received: from dslb-094-223-185-199.pools.arcor-ip.net (EHLO HIVE) [94.223.185.199] by mail.gmx.net (mp003) with SMTP; 08 Jul 2011 02:55:58 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/UCcI8lbjUEXVMFdICV/wxC6JqJ+FMMf0pho1p+Z PwgIio2R2yG2Vj From: Bjoern Hoehrmann To: Cullen Jennings Date: Fri, 08 Jul 2011 02:56:09 +0200 Message-ID: <2mjc179va7kqeh3qn9755immj91mdgug0n@hive.bjoern.hoehrmann.de> References: <48AF46F9-5E4A-4D62-8DE0-EE6916D30F98@cisco.com> <21f1u6hael1utmpg3svvn2a6s3agncb5ov@hive.bjoern.hoehrmann.de> <45B798A3-37AD-49C9-99AC-A9B3A587B55A@cisco.com> In-Reply-To: <45B798A3-37AD-49C9-99AC-A9B3A587B55A@cisco.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: ietf-types@iana.org, P2PSIP Mailing List Subject: Re: [P2PSIP] [ietf-types] Registration of media type application/p2p-overlay+xml X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 00:56:01 -0000 * Cullen Jennings wrote: >We are mandating UTF-8 as the charset which gives us the benefits would >hope. We don't want to have multiple charsets supported as we have noted >this reduces interoperability when some implementations don't bother to >implement charsets other than UTF-8. It's arbitrary choice that >increases what you need to implement and test, reduces interoperability, >and provides not benefits to the end user beyond what they get with >UTF-8. I am thinking about this situation: Content-Type: application/p2p-overlay+xml;charset=iso-8859-2 ... and I am comparing it to this situation: Content-Type: application/xml;charset=iso-8859-2 ... The question is how implementations determine the encoding. I am saying there should be no difference between the two cases, so long as you use the `+xml` convention and an `application` type. That would require to either define a charset parameter, or remove the `+xml`. I do not care whether some `application/p2p-overlay+xml` implementations only support UTF-8, I just do not want this to be the same as: Content-Type: application/p2p-overlay+xml;dkjfashdkf=sdjhfaskdjfhas ... namely, an unrecognized parameter with an unrecognized value. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From denglingli@chinamobile.com Thu Jul 7 18:35:45 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417CA21F883E for ; Thu, 7 Jul 2011 18:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.574 X-Spam-Level: **** X-Spam-Status: No, score=4.574 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzJ8KP2OArZr for ; Thu, 7 Jul 2011 18:35:44 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB1921F86F2 for ; Thu, 7 Jul 2011 18:35:44 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 200FDA6B7 for ; Fri, 8 Jul 2011 09:35:42 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 18752A6B2 for ; Fri, 8 Jul 2011 09:35:42 +0800 (CST) Received: from denglingli ([10.2.2.84]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011070809354044-3531 ; Fri, 8 Jul 2011 09:35:40 +0800 From: =?gb2312?B?tcvB6cDyL2RlbmdsaW5nbGk=?= To: Date: Fri, 8 Jul 2011 09:35:16 +0800 Message-ID: <001701cc3d0f$49ff65a0$ddfe30e0$@chinamobile.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acw9D0YOQ8tezy4QRUmhRfpCSyo/fQ== X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-08 09:35:40, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-08 09:35:42, Serialize complete at 2011-07-08 09:35:42 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01CC3D52.5822A5A0" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18246.003 X-TM-AS-Result: No--5.167-7.0-31-10 X-imss-scan-details: No--5.167-7.0-31-10;No--5.167-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: [P2PSIP] new draft submissions for client promotion and one-hop algorithm X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 01:35:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0018_01CC3D52.5822A5A0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="gb2312" Dear all, A draft is newly submitted, which proposes extensions to RELOAD to support flexible client promotion and demotion modes. RELOAD aims at providing a uniform protocol for both overlay clients and peers, where promotion of a client to peer is triggered and completed at the client's pleasure. It is proposed that RELOAD provide a more restrictive framework to enable passive promotion and demotion, where decisions are made by the network rather than individual user-owned nodes. The mentioned submission entitled can be accessed at http://datatracker.ietf.org/doc/draft-peng-p2psip-promotion/ Another submission for one-hop algorithm as an alternative for chord-reload is also available and be welcome for comments: http://datatracker.ietf.org/doc/draft-peng-p2psip-one-hop-plugin/ Any comments are highly appreciated. BR Lingli Deng ------=_NextPart_000_0018_01CC3D52.5822A5A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"

 

Dear all,

 

A draft is newly submitted, which proposes extensions to = RELOAD to support flexible client promotion and demotion modes. RELOAD = aims at providing a uniform protocol for both overlay clients and peers, = where promotion of a client to peer is triggered and completed at the = client's pleasure. It is proposed that RELOAD provide a more restrictive = framework to enable passive promotion and demotion, where decisions are = made by the network rather than individual user-owned = nodes.

 

The mentioned submission entitled = can be accessed at htt= p://datatracker.ietf.org/doc/draft-peng-p2psip-promotion/ =

 

Another = submission for one-hop algorithm as an alternative for chord-reload is = also available and be welcome for comments:

http://datatracker.ietf.org/doc/draft-peng-p2psip-one-hop-plugin/ =  

 

Any comments are highly = appreciated.

 

BR

Lingli Deng

 

------=_NextPart_000_0018_01CC3D52.5822A5A0-- From fluffy@cisco.com Thu Jul 7 19:04:51 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCE521F8678 for ; Thu, 7 Jul 2011 19:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.908 X-Spam-Level: X-Spam-Status: No, score=-104.908 tagged_above=-999 required=5 tests=[AWL=-2.309, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm+xYTM4HBLY for ; Thu, 7 Jul 2011 19:04:50 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B5F4721F8672 for ; Thu, 7 Jul 2011 19:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1861; q=dns/txt; s=iport; t=1310090690; x=1311300290; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=H2vmYQwIFaojUrSj55IyiIlCvOySUmYFDRlbCJP5BVY=; b=MYyCLPPf+kHY5B2x7EMbzRcwbATxbufDWI9vJSeQIq180ynxe1UHKRe5 Jxmi7okj/eLe3YqDme0DOKUkoy31fMs+36QeeDQ0kdnpz9wkD3knxYq75 yZPY+EkKMS5VeMK9Akx0lXZi1VJvvP8vEYemDo8G47cLBNK9/KPoAUuGQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANVkFk6rRDoG/2dsb2JhbABTpz53rmudeYY4BIdJinyEfIti X-IronPort-AV: E=Sophos;i="4.65,496,1304294400"; d="scan'208";a="889258" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-3.cisco.com with ESMTP; 08 Jul 2011 02:04:50 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6824m3g021230; Fri, 8 Jul 2011 02:04:48 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <2mjc179va7kqeh3qn9755immj91mdgug0n@hive.bjoern.hoehrmann.de> Date: Thu, 7 Jul 2011 20:04:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <71C1C9E3-27E5-43D5-801D-01256609DC79@cisco.com> References: <48AF46F9-5E4A-4D62-8DE0-EE6916D30F98@cisco.com> <21f1u6hael1utmpg3svvn2a6s3agncb5ov@hive.bjoern.hoehrmann.de> <45B798A3-37AD-49C9-99AC-A9B3A587B55A@cisco.com> <2mjc179va7kqeh3qn9755immj91mdgug0n@hive.bjoern.hoehrmann.de> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1084) Cc: ietf-types@iana.org, P2PSIP Mailing List Subject: Re: [P2PSIP] [ietf-types] Registration of media type application/p2p-overlay+xml X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 02:04:51 -0000 On Jul 7, 2011, at 6:56 PM, Bjoern Hoehrmann wrote: > * Cullen Jennings wrote: > >We are mandating UTF-8 as the charset which gives us the benefits = would > >hope. We don't want to have multiple charsets supported as we have = noted > >this reduces interoperability when some implementations don't bother = to > >implement charsets other than UTF-8. It's arbitrary choice that > >increases what you need to implement and test, reduces = interoperability, > >and provides not benefits to the end user beyond what they get with > >UTF-8. >=20 > I am thinking about this situation: >=20 > Content-Type: application/p2p-overlay+xml;charset=3Diso-8859-2 >=20 > > ... >=20 > and I am comparing it to this situation: >=20 > Content-Type: application/xml;charset=3Diso-8859-2 >=20 > > ... >=20 > The question is how implementations determine the encoding. I am = saying > there should be no difference between the two cases, so long as you = use > the `+xml` convention and an `application` type. That would require to > either define a charset parameter, or remove the `+xml`. I do not care > whether some `application/p2p-overlay+xml` implementations only = support > UTF-8, I just do not want this to be the same as: >=20 > Content-Type: application/p2p-overlay+xml;dkjfashdkf=3Dsdjhfaskdjfhas >=20 > > ... >=20 > namely, an unrecognized parameter with an unrecognized value. We do use this in protocols that don't have a Content-Type header or = place to cary the chartset but I see your point with not wanting to = treat charset as an unknown parameter. Do you see any problem with = saying, if there is a chartset parameter, it MUST be UTF-8? From bbl@lowekamp.net Thu Jul 7 19:24:09 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E317121F8993 for ; Thu, 7 Jul 2011 19:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLQiDbh+WqwN for ; Thu, 7 Jul 2011 19:24:08 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 45CF221F89C0 for ; Thu, 7 Jul 2011 19:24:08 -0700 (PDT) Received: by ewy19 with SMTP id 19so598207ewy.31 for ; Thu, 07 Jul 2011 19:24:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.0.82 with SMTP id 58mr439807eea.237.1310091845143; Thu, 07 Jul 2011 19:24:05 -0700 (PDT) Received: by 10.14.189.14 with HTTP; Thu, 7 Jul 2011 19:24:05 -0700 (PDT) In-Reply-To: <1309773089.5716.43.camel@santeles> References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E0E4DBE.5060302@acm.org> <1309624099.5232.23.camel@santeles> <4E0F4F8D.9080108@acm.org> <1309773089.5716.43.camel@santeles> Date: Thu, 7 Jul 2011 22:24:05 -0400 Message-ID: From: Bruce Lowekamp To: Diego Suarez Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 02:24:10 -0000 Diego, Please take some time understanding how real clients work in reload. Then just have the virtual clients use the same messages. The virtual clients use their own nodeids, not the host's nodeid. It all works fine. I don't see a real problem with a host node having an "admin@example.com" or "node12345@example.com" name attached to it. Routers pretty much always have DNS names that are descriptive of where they are to admins, even though routing protocols don't require it. Regarding certs, 6072 has the following text: If the certificate is signed by a trusted certification authority, and one of the names in the SubjectAltName matches the original URI, then this certificate MAY be used, but only for exactly the original It's been awhile since I've looked at that in detail, but it appears to me that a reload cert could be perfectly valid for use with 6072 as long as it has the sip uri in it. Though I'm not immediately convinced that this is that useful, regardless. Bruce On Mon, Jul 4, 2011 at 5:51 AM, Diego Suarez wrote: > Hi, > > Actually, I see this "virtual client" method more complicated and > confusing than splitting the identities of users and devices. > > With this model, you are gonna have a device identified by a PKC that > includes a username and a nodeID acting as a peer, but only using its > nodeID. And several users connected to the device as virtual clients > identified by PKCs including a username and a nodeID, but only using > their usernames. > > One of the more confusing things I see here is the access control. > Imagine we have a device, with PKC ( # user =3D device1, nodeID =3D 100 #= ) > and two users ( # user =3D user1, nodeID =3D 200 # and # user =3D user2, > nodeID =3D 300 # ) connected to that device acting as virtual clients. > > If user1 wants to perform a USER-NODE-MATCH access control related to > the peer she is operating from ( actually the nodeID =3D 100 nor the > virtual one with nodeID =3D 200 ) and her username ( user =3D user1 ), sh= e > is gonna have to create a request signed with her PKC and the PKC of the > device. This request need to be doubled signed ( by the peer to grant > the nodeID =3D 100 and by the user to grant the user =3D user 1 ). Howeve= r, > this double signed request intended for nodeID =3D 100 and user =3D user1= is > gonna include two users =3D device1 and user1 and two nodeID =3D 100 and > 200. This is confusing for me. Therefore, from my point of view, it > makes sense to me to remove the username from the device and the node > from the users since we are not using them and confuse the access > control. > > Also, splitting identities have another advantages like greater > interoperability with traditional SIP systems. Imagine a company running > a SIP system, where users are identified by a PKC including a SIP > username, that wants to extend its coverage interconnecting it with a > P2PSIP system. With the actual certification model, SIP PKCs are not > valid for the new P2PSIP side of the system. All the users have to be > re-certificated to have a PKC including the old SIP username and a > nodeID. However, with the split proposal SIP certificates are still > valid in the P2PSIP side of the system and interoperable within the two > networks, and only the devices intended to be used in the P2PSIP side > have to be certified with a nodeID. > > > cheers > > > > > On Sat, 2011-07-02 at 16:53 -0400, Bruce Lowekamp wrote: >> With the current definition of the protocol, split routing IDs and >> user IDs can be achieved by having the host node participate as a peer >> (or as a client, honestly) using its own cert and the attached users >> represented as virtual clients, i.e. generate messages as if they are >> on separate nodes attached to the host node as a client. >> >> If you wanted to implement it "natively," other than the >> USER-NODE-MATCH, as mentioned before, I can only find two changes that >> would need to be made to support split identities. >> >> For processing StoreReq: >> o =C2=A0For original (non-replica) stores, the StoreReq is signed by a >> =C2=A0 =C2=A0 =C2=A0 credential which is authorized to write this kind a= t this >> =C2=A0 =C2=A0 =C2=A0 Resource-Id. =C2=A0If this check fails, the request= MUST be rejected >> =C2=A0 =C2=A0 =C2=A0 with an Error_Forbidden error. >> >> and the definition of credential in beginning of 10.3. >> >> >> Assuming that there is not something I'm missing with using virtual >> clients, I'd rather not make any changes. =C2=A0This is a complicated >> enough protocol, and I think adding special cases for something like >> split identities just makes it more complicated. =C2=A0If any changes we= re >> made, I would think it should be something to make it possible for an >> extension to specify the change, but as long as the current protocol >> is capable of handling the functional goals, I'd rather no changes be >> made. >> >> Bruce >> >> >> >> >> On Sat, Jul 2, 2011 at 1:04 PM, Marc Petit-Huguenin w= rote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > On 07/02/2011 09:28 AM, Diego Suarez wrote: >> >> Hi, >> >> >> >>>From my point of view, in this case the user has to both prove she is= in >> >> possession of the PKC that includes the required username and also pr= ove >> >> she is operating from the required node. However, modifying the >> >> SignerIdentity to include multiple identities ( the user and the >> >> device ) would not really prove that since only one signature could b= e >> >> included (either the user's signature or the device's one). >> >> >> >> Therefore, I'd modify the SecurityBlock instead to allow the inclusio= n >> >> of more than only one signature. >> >> >> >> For this case, the securityBlock would include two signatures. One wi= th >> >> the SignerIdentity of the user and the signature of the user's PKC >> >> (including the username ) and another with the SignerIdentity of the >> >> device and the signature of the device's PKC ( including the nodeID). >> > >> > Right, something like this: >> > >> > struct { >> > =C2=A0 GenericCertificate certificates<0..2^16-1>; >> > =C2=A0 Signature =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0signatures<0..2^16-= 1>; >> > =C2=A0 } SecurityBlock; >> > >> > Note that StoredData also needs to be modified: >> > >> > struct { >> > =C2=A0 uint32 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0length; >> > =C2=A0 uint64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0storage_time; >> > =C2=A0 uint32 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lifetime; >> > =C2=A0 StoredDataValue value; >> > =C2=A0 Signature =C2=A0 =C2=A0 =C2=A0 signatures<0..2^16-1>; >> > =C2=A0 } StoredData; >> > >> >> >> >> cheers >> >> >> >> >> >> On Fri, 2011-07-01 at 15:44 -0700, Marc Petit-Huguenin wrote: >> >> Hi Diego, >> >> >> >> How does this work with an access control policy like USER-NODE-MATCH= , which >> >> requires both a Node-ID and a username in the SignerIdentity? =C2=A0I= f the Node-ID >> >> and the username are in separate certificates, wouldn't that require = to extend >> >> the SignerIdentity structure to store multiple identities? >> >> >> >> Thanks. >> >> >> >> On 06/09/2011 10:47 AM, Diego Suarez wrote: >> >>>>> I think it would require a (slight) modification in the base docum= ent. >> >>>>> Current P2PSIP certification model is based on a single PKC (inclu= ding >> >>>>> both usernames and nodeIDs) that uniquely identifies a user and he= r >> >>>>> devices. On the other hand, our model is base on a split certifica= tion. >> >>>>> Devices and users are independent. Each device has its own PKC inc= luding >> >>>>> a nodeID and a PK. Similarly, each user has her own PKC including = her >> >>>>> username and a PK. This approach do not prevent a centralized enti= ty >> >>>>> (such as an offline CA) to have information related to the devices= each >> >>>>> user (or company, etc.) has registered, but permits, among other >> >>>>> improvements, a user to be connected to the system through devices= she >> >>>>> has not registered herself such as a phone issued by a telco or a = fixed >> >>>>> phone in a laboratory shared by all the members of a research grou= p. >> >>>>> >> >>>>> >> >>>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: >> >>>>> Does this model really required modifications in the base document= , or can it be >> >>>>> designed as an extension? =C2=A0(Unfortunately the paper is not fr= eely available, so >> >>>>> it is difficult to know really what is needed for this). >> >>>>> >> >>>>> On 06/09/2011 07:31 AM, Diego Suarez wrote: >> >>>>>>>> Hi, >> >>>>>>>> >> >>>>>>>> I had in mind writing a draft about this, but since I'm running= out of >> >>>>>>>> time, I would like to summarize a new certification model for P= 2PSIP I >> >>>>>>>> have been working on, in case it is of interest for the group. >> >>>>>>>> Further details can be found in paper: >> >>>>>>>> >> >>>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, =C2=A0Advan= tages of >> >>>>>>>> identity certificate segregation in P2PSIP systems, =C2=A0Commu= nications, >> >>>>>>>> IET, vol. 5, pp. 879 889, Apr. 2011. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> The idea is to split the certification of users and devices. De= vices are >> >>>>>>>> identified by PKCs including a nodeID and the PK of the device,= while >> >>>>>>>> users are identified by PKCs including a username and the PK of= the >> >>>>>>>> user. Similar models have been used before in other communicati= ons >> >>>>>>>> systems, such as GSM where devices and users are separately rep= resented >> >>>>>>>> by the international mobile equipment identity (IMEI) stored in= the >> >>>>>>>> phones and the international mobile subscriber identity (IMSI) = stored in >> >>>>>>>> the user subscriber identity module (SIM), respectively. >> >>>>>>>> >> >>>>>>>> Motivations of this model are: >> >>>>>>>> >> >>>>>>>> - Users and devices are different entities performing different >> >>>>>>>> roles within a P2PSIP system. Devices are nodes of the P2P >> >>>>>>>> overlay network (represented by a nodeID) that offer services >> >>>>>>>> (to route messages, to store data, . . .) to the system, while >> >>>>>>>> users (represented by an username) utilize these services, >> >>>>>>>> usually to establish media communications using SIP. >> >>>>>>>> >> >>>>>>>> - Support for mobility scenarios where a user may be logged at = different >> >>>>>>>> devices at the same time using the same PKC. >> >>>>>>>> >> >>>>>>>> - Support several users to be logged in the same device (like a= fixed >> >>>>>>>> phone) at the same time. >> >>>>>>>> >> >>>>>>>> - Support for user independent hard-coded devices. >> >>>>>>>> >> >>>>>>>> - Interoperability with SIP. SIP certificates are not valid in = actual >> >>>>>>>> P2PSIP since they don't include a nodeID. >> >>>>>>>> >> >>>>>>>> cheers >> >>>>>>>> >> >>>>>>>> Diego Su=C3=A1rez >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: >> >>>>>>>>> Unless something major comes up, we plan to request the newest= version >> >>>>>>>>> of the base draft, draft-ietf-p2psip-base-15, be published. I'= ll put >> >>>>>>>>> in the request in a week (June 16th or 17th). If there are any= further >> >>>>>>>>> comments from the last call a while ago (or further comments o= n the >> >>>>>>>>> comments since then), please send them to the list ASAP. >> >>>>>>>>> >> >>>>>>>>> Thanks, >> >>>>>>>>> >> >>>>>>>>> David (as chair) >> > >> > - -- >> > Marc Petit-Huguenin >> > Personal email: marc@petit-huguenin.org >> > Professional email: petithug@acm.org >> > Blog: http://blog.marc.petit-huguenin.org >> > -----BEGIN PGP SIGNATURE----- >> > Version: GnuPG v1.4.11 (GNU/Linux) >> > >> > iEYEARECAAYFAk4PT4sACgkQ9RoMZyVa61dPvACeITly6/Zqumz4e4ZrAn1yGI4x >> > ay4AoJ11vmCRDkL8pXuN71qaZXhw5JTZ >> > =3DTp+D >> > -----END PGP SIGNATURE----- >> > _______________________________________________ >> > P2PSIP mailing list >> > P2PSIP@ietf.org >> > https://www.ietf.org/mailman/listinfo/p2psip >> > > > > From bbl@lowekamp.net Thu Jul 7 19:28:11 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2781421F899D for ; Thu, 7 Jul 2011 19:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.621 X-Spam-Level: X-Spam-Status: No, score=-0.621 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMs084x9Lr8u for ; Thu, 7 Jul 2011 19:28:10 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 65FD921F8998 for ; Thu, 7 Jul 2011 19:28:10 -0700 (PDT) Received: by ewy19 with SMTP id 19so598938ewy.31 for ; Thu, 07 Jul 2011 19:28:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.100.65 with SMTP id y41mr417752eef.205.1310092087568; Thu, 07 Jul 2011 19:28:07 -0700 (PDT) Received: by 10.14.189.14 with HTTP; Thu, 7 Jul 2011 19:28:07 -0700 (PDT) In-Reply-To: <001701cc3d0f$49ff65a0$ddfe30e0$@chinamobile.com> References: <001701cc3d0f$49ff65a0$ddfe30e0$@chinamobile.com> Date: Thu, 7 Jul 2011 22:28:07 -0400 Message-ID: From: Bruce Lowekamp To: =?UTF-8?B?6YKT54G16I6JL2RlbmdsaW5nbGk=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] new draft submissions for client promotion and one-hop algorithm X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 02:28:11 -0000 Thanks for submitting the drafts. A quick question on the promotion draft. Could this be implemented as a topology plugin? The base draft has always been vague on selecting peers vs clients, mostly in hope that future extensions or topology plugins could implement their own methods for peer promotion, etc. Bruce 2011/7/7 =E9=82=93=E7=81=B5=E8=8E=89/denglingli : > > > Dear all, > > > > A draft is newly submitted, which proposes extensions to RELOAD to suppor= t > flexible client promotion and demotion modes. RELOAD aims at providing a > uniform protocol for both overlay clients and peers, where promotion of a > client to peer is triggered and completed at the client's pleasure. It is > proposed that RELOAD provide a more restrictive framework to enable passi= ve > promotion and demotion, where decisions are made by the network rather th= an > individual user-owned nodes. > > > > The mentioned submission entitled can be accessed at > http://datatracker.ietf.org/doc/draft-peng-p2psip-promotion/ > > > > Another submission for one-hop algorithm as an alternative for chord-relo= ad > is also available and be welcome for comments: > > http://datatracker.ietf.org/doc/draft-peng-p2psip-one-hop-plugin/ > > > > Any comments are highly appreciated. > > > > BR > > Lingli Deng > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From denglingli@chinamobile.com Thu Jul 7 19:50:41 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B4F21F8999 for ; Thu, 7 Jul 2011 19:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.76 X-Spam-Level: ** X-Spam-Status: No, score=2.76 tagged_above=-999 required=5 tests=[AWL=2.685, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XntMpOdO7Xak for ; Thu, 7 Jul 2011 19:50:40 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D4FEA21F8994 for ; Thu, 7 Jul 2011 19:50:39 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id A46AEA67B; Fri, 8 Jul 2011 10:50:38 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 849CE9FDC; Fri, 8 Jul 2011 10:50:38 +0800 (CST) Received: from denglingli ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011070810503654-5979 ; Fri, 8 Jul 2011 10:50:36 +0800 From: =?UTF-8?B?6YKT54G16I6JL2RlbmdsaW5nbGk=?= To: "'Bruce Lowekamp'" References: <001701cc3d0f$49ff65a0$ddfe30e0$@chinamobile.com> In-Reply-To: Date: Fri, 8 Jul 2011 10:50:12 +0800 Message-ID: <002b01cc3d19$c22fa1c0$468ee540$@chinamobile.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI4mA1A4WNy7Lm4MmThl6GUu0gukAKWobVgk/RLMhA= X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-08 10:50:36, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-08 10:50:38, Serialize complete at 2011-07-08 10:50:38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18246.003 X-TM-AS-Result: No--21.155-7.0-31-10 X-imss-scan-details: No--21.155-7.0-31-10;No--21.155-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Cc: p2psip@ietf.org Subject: [P2PSIP] =?utf-8?b?562U5aSNOiAgbmV3IGRyYWZ0IHN1Ym1pc3Npb25zIGZv?= =?utf-8?q?r_client_promotion_and_one-hop_algorithm?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 02:50:41 -0000 Thank you Bruce. Yes, we have noticed that and agree that the decision of peer promotion = is basically dependent on the specific overlay algorithm. However, some = general issues need to be addressed outside TP in order to enable such = procedure, for instance: o Who triggers the passive procedure? Either triggered independently by = a single (e.g. overloading) peer; or triggered globally by the = centralized overlay administration. o How to collect candidate stats to make an informed decision? Either = collected by self-reports; or involving kind of mutual evaluation. o How to choose from qualified candidates? Randomly selected, or locally = optimized, or even globally optimized choice. Different answers to the above questions compose different practical = solutions. However, RELOAD only needs to provide generic messaging = interaction to support them. Above all, separate authorizations for = peers and clients may be needed as well. As an initial step, we may describe an illustrative scenario and discuss = potential extensions to RELOAD in order to support it. In our example, the passive client promotion procedure is triggered = locally by an overloading peer. Candidacy collection is achieved by = ProbeReq/Res messages, where the overloading peer seeks help from its = directly connected clients through specially marked ProbeReq messages = and interested clients binds its state report and peer certificate with = ProbeRes. Promotion decision is made locally by the overloading peer and = the selected client gets and explicit delegation signed by the local = decision maker, where a new type of message would be employed. The = selected client may initialize the normal peer joining procedure = afterwards, where relevant JoinReq is accompanied by the correspondent = signed delegation. BR=20 Lingli -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Bruce Lowekamp [mailto:bbl@lowekamp.net]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B47=E6=9C=888=E6=97=A5 = 10:28 =E6=94=B6=E4=BB=B6=E4=BA=BA: =E9=82=93=E7=81=B5=E8=8E=89/denglingli =E6=8A=84=E9=80=81: p2psip@ietf.org =E4=B8=BB=E9=A2=98: Re: [P2PSIP] new draft submissions for client = promotion and one-hop algorithm Thanks for submitting the drafts. A quick question on the promotion = draft. Could this be implemented as a topology plugin? The base draft = has always been vague on selecting peers vs clients, mostly in hope that = future extensions or topology plugins could implement their own methods = for peer promotion, etc. Bruce 2011/7/7 =E9=82=93=E7=81=B5=E8=8E=89/denglingli = : > > > Dear all, > > > > A draft is newly submitted, which proposes extensions to RELOAD to=20 > support flexible client promotion and demotion modes. RELOAD aims at=20 > providing a uniform protocol for both overlay clients and peers, where = > promotion of a client to peer is triggered and completed at the=20 > client's pleasure. It is proposed that RELOAD provide a more=20 > restrictive framework to enable passive promotion and demotion, where=20 > decisions are made by the network rather than individual user-owned = nodes. > > > > The mentioned submission entitled can be accessed at=20 > http://datatracker.ietf.org/doc/draft-peng-p2psip-promotion/ > > > > Another submission for one-hop algorithm as an alternative for=20 > chord-reload is also available and be welcome for comments: > > http://datatracker.ietf.org/doc/draft-peng-p2psip-one-hop-plugin/ > > > > Any comments are highly appreciated. > > > > BR > > Lingli Deng > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > __________ Information from ESET NOD32 Antivirus, version of virus = signature database 6268 (20110705) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From peng.yonglin@zte.com.cn Thu Jul 7 20:37:00 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A1B21F886D; Thu, 7 Jul 2011 20:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.19 X-Spam-Level: X-Spam-Status: No, score=-90.19 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvCnopCP6ZYw; Thu, 7 Jul 2011 20:36:59 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6333621F886B; Thu, 7 Jul 2011 20:36:58 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131323465113155; Fri, 8 Jul 2011 11:31:52 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 13796.3672386229; Fri, 8 Jul 2011 11:36:37 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p683aUnd052034; Fri, 8 Jul 2011 11:36:30 +0800 (GMT-8) (envelope-from peng.yonglin@zte.com.cn) To: "Randy Presuhn" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: peng.yonglin@zte.com.cn Date: Fri, 8 Jul 2011 11:36:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-08 11:36:32, Serialize complete at 2011-07-08 11:36:32 Content-Type: multipart/alternative; boundary="=_alternative 0013D6D2482578C7_=" X-MAIL: mse02.zte.com.cn p683aUnd052034 Cc: p2psip@ietf.org, hao.zhenwu@zte.com.cn, meng.yu@zte.com.cn, opsawg@ietf.org Subject: Re: [P2PSIP] =?gb2312?b?W09QU0FXR10gV2UgaGF2ZSBzdWJtaXR0ZWQgYSBkcmFm?= =?gb2312?b?dHMgb24gU05NUCB1c2FnZXMgZm9yIFAyUCBuZXR3b3Jrcy4gV2Ugd291bGQg?= =?gb2312?b?bGlrZSB0byBnZXQgc29tZSBzdWdnZXN0aW9ucyBmcm9tIFNOTVAgZXhwZXJ0?= =?gb2312?b?cyBvbiB0aGUgc2NlbmFyaW8gYW5kIGRlc2lnbiBmb3IgUDJQIG5ldHdvcmsg?= =?gb2312?b?bWFuYWdlbWVudC4gVGhlIGxpbmsgdG8gdGhlIGRyYWZ0IGlzIGluIHRoZSBi?= =?gb2312?b?b2R5IG9mIHRoaXMgZW1haWwuIHRoYW5rc6Oh?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 03:37:00 -0000 This is a multipart message in MIME format. --=_alternative 0013D6D2482578C7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIHRoYW5rIHlvdSBmb3IgeW91ciBzdWdnZXN0aW9ucyB2ZXJ5IG11Y2guDQoNClRoZSB3YXkg b2Ygbm90aWZpY2F0aW9uIGlzIHRoZSBzYW1lIGFzIFNOTVAsIHdoaWNoIGlzIGltcGxlbWVudGVk IGJ5IFRyYXAuDQoNCk91ciBzZWN1cml0eSBjb25zaWRhdGlvbnMgYXJlIGFzIGZvbGxvd3M6DQpU aGVyZSBhcmUgdGhyZWUgc29sdXRpb25zIHRvIHRoZSBzZWN1cml0eSBwcm9ibGVtIGluIFNOTVAg VXNhZ2UgZm9yIA0KUkVMT0FELiBUaGUgZmlyc3Qgb3B0aW9uIGlzIHNoYXJlZCBrZXkgYmFzZWQg c29sdXRpb24sIHdoaWNoIGlzIFNOTVB2MyANCnNlY3VyaXR5IHNvbHV0aW9uIChVU00pLiBUaGUg c2Vjb25kIG9wdGlvbiBpcyBQS0kgYmFzZWQgc2VjdXJpdHkgc29sdXRpb24sIA0Kd2hpY2ggaXMg dG8gdXNlIHRoZSBjZXJ0aWZpY2F0ZSBvZiBSRUxPQUQgdG8gYXV0aGVudGljYXRlIGFuZCBlbmNy eXB0IHRoZSANClNOTVAgbWVzc2FnZXMuIFRoZSB0aGlyZCBvcHRpb24gaXMgRFRMUyBiYXNlZCBz ZWN1cml0eSBzb2x1dGlvbiwgd2hpY2ggDQp1c2VzIHRoZSBzZWN1cmUgRFRMUyBsaW5rcyB0byB0 cmFuc2ZlciB0aGUgU05NUCBtZXNzYWdlLg0KVGhlIHNlY29uZCBhbmQgdGhpcmQgb3B0aW9ucyBh cmVuoa90IHN1cHBvcnRlZCBieSBjdXJyZW50IFNOTVAgbWFuYWdlciBhbmQgDQphZ2VudCwgYW5k IG5lZWQgbGFyZ2UgY2hhbmdlcy4gU28gd2UgcmVjb21tZW5kIHRoZSBmaXJzdCBvcHRpb24uIEJ1 dCBpdKGvcyANCmRpZmZpY3VsdCB0byBkaXN0cmlidXRlIHNlY3VyZWx5IHRoZSBrZXlzIHRvIGxh cmdlIG51bWJlcnMgb2YgYWdlbnRzIGluIA0KdGhlIFNOTVAgc2VjdXJpdHkgc29sdXRpb24uIElu IHRoaXMgZG9jdW1lbnQsIHdlIGRpc3RyaWJ1dGUgdGhlIGtleSB0byANCmVhY2ggYWdlbnQgYnkg dGhlIGNlcnRpZmljYXRlIG1lY2hhbmlzbSBvZiBSRUxPQUQuIA0KDQoNCg0KKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K08ogvP6junBlbmcueW9uZ2xp bkB6dGUuY29tLmNuDQrE2iDP36O6ODE1NDMNCs3iIM/fo7owMjUtNTI4NzE1NDMNCsrWILv6o7ox Mzc3NjYzNzI3NA0KtKsg1eajujAyNS01Mjg3MjE4Nw0KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKg0KDQoNCg0KDQoiUmFuZHkgUHJlc3VobiIgPHJhbmR5 X3ByZXN1aG5AbWluZHNwcmluZy5jb20+IA0Kt6K8/sjLOiAgb3BzYXdnLWJvdW5jZXNAaWV0Zi5v cmcNCjIwMTEtMDYtMTAgMDE6MTYNCg0KytW8/sjLDQo8b3BzYXdnQGlldGYub3JnPg0Ks63LzQ0K DQrW98ziDQpSZTogW09QU0FXR10gICAgV2UgaGF2ZSBzdWJtaXR0ZWQgYSBkcmFmdHMgb24gU05N UCB1c2FnZXMgZm9yIFAyUCANCm5ldHdvcmtzLiBXZSB3b3VsZCBsaWtlIHRvIGdldCBzb21lIHN1 Z2dlc3Rpb25zIGZyb20gU05NUCBleHBlcnRzIG9uIHRoZSANCnNjZW5hcmlvIGFuZCBkZXNpZ24g Zm9yIFAyUCBuZXR3b3JrIG1hbmFnZW1lbnQuIFRoZSBsaW5rIHRvIHRoZSBkcmFmdCBpcyANCmlu IHRoZSBib2R5IG9mIHRoaXMgZW1haWwuIHRoYW5rc6OhDQoNCg0KDQoNCg0KDQpIaSAtDQoNCj4g RnJvbTogPHBlbmcueW9uZ2xpbkB6dGUuY29tLmNuPg0KPiBUbzogPG9wc2F3Z0BpZXRmLm9yZz4N Cj4gQ2M6IDxoYW8uemhlbnd1QHp0ZS5jb20uY24+DQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAw OCwgMjAxMSA4OjQzIFBNDQo+IFN1YmplY3Q6IFtPUFNBV0ddIFdlIGhhdmUgc3VibWl0dGVkIGEg ZHJhZnRzIG9uIFNOTVAgdXNhZ2VzIGZvciBQMlAgDQpuZXR3b3Jrcy4gV2Ugd291bGQgbGlrZSB0 byBnZXQgc29tZSBzdWdnZXN0aW9ucyBmcm9tIFNOTVANCmV4cGVydHMgb24gdGhlIHNjZW5hcmlv IGFuZCBkZXNpZ24gZm9yIFAyUCBuZXR3b3JrIG1hbmFnZW1lbnQuIFRoZSBsaW5rIHRvIA0KdGhl IGRyYWZ0IGlzIGluIHRoZSBib2R5IG9mIHRoaXMgZW1haWwuIHRoYW5rc6OhDQo+DQo+IGh0dHA6 Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1wZW5nLXAycHNpcC1zbm1wLTAxLnR4dA0KLi4uDQoN ClNraW1taW5nIHRoZSBkcmFmdCwgaXQgd2FzIHVuY2xlYXIgdG8gbWUgaG93IGEgZmV3IGRldGFp bHMgd291bGQgd29yaw0KaW4gdGhpcyBhcHByb2FjaC4gIEkgdGhpbmsgaXQgd291bGQgYmUgaGVs cGZ1bCB0byBleHBsaWNpdGx5IHRhbGsgYWJvdXQNCiAgKDEpIGhvdyBub3RpZmljYXRpb25zIGFy ZSBpbnRlbmRlZCB0byB3b3JrDQogICgyKSBrZXkgcHJvdmlzaW9uaW5nIChpbmRlZWQsIHByb3Zp c2lvbmluZyBpbiBnZW5lcmFsKQ0KICAoMykgd2hhdCBzZWN1cml0eSBtb2RlbCBpcyBpbiB1c2UN Cg0KSSAqdGhpbmsqIGl0IG1pZ2h0IGJlIGhlbHBmdWwgdG8gdHJlYXQgdGhpcyBhcyBhIG5ldyB0 cmFuc3BvcnQNCm1vZGVsLCBidXQgeW91J2xsIG5lZWQgdG8gdGhpbmsgdGhyb3VnaCBqdXN0IGhv dyBhdXRoZW50aWNhdGlvbg0KYW5kIHByaXZhY3kgYXJlIHRvIGJlIGhhbmRsZWQgKGUuZy4sIGlz IGl0IGp1c3QgVVNNIGF0b3AgUkVMT0FELA0Kb3IgZG9lcyBSRUxPQUQgcHJvdmlkZSB0aGUgc2Vj dXJpdHkgc2VydmljZXM/KS4gIFRoaXMgZGVjaXNpb24NCm1heSBpbnRlcnJhY3Qgd2l0aCBob3cs IGZvciBleGFtcGxlLCBub3RpZmljYXRpb24gYW5kIERpc21hbg0KdGFyZ2V0cyBhcmUgY29uZmln dXJlZC4gIEluIHBhcnRpY3VsYXIsIGNvbnNpZGVyIHdoZXRoZXIgeW91IG5lZWQNCnRvIHN1cHBv cnQgdGhlIGNhc2Ugd2hlcmUgb25seSAqc29tZSogb2YgdGhlIFNOTVAgaW50ZXJyYWN0aW9ucw0K YmV0d2VlbiB0d28gc3lzdGVtcyBhcmUgY2FycmllZCB2aWEgUkVMT0FELg0KDQpSYW5keQ0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPUFNBV0cg bWFpbGluZyBsaXN0DQpPUFNBV0dAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb3BzYXdnDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGlj ZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3Bl cnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9u IGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRv IG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBj b250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQg YW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9t IHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmll d3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwg c2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNw YW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0013D6D2482578C7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCB0aGFuayB5b3UgZm9yIHlv dXIgc3VnZ2VzdGlvbnMgdmVyeQ0KbXVjaC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPlRoZSB3YXkgb2Ygbm90aWZpY2F0aW9uIGlzIHRoZSBzYW1lDQph cyBTTk1QLCB3aGljaCBpcyBpbXBsZW1lbnRlZCBieSBUcmFwLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+T3VyIHNlY3VyaXR5IGNvbnNpZGF0aW9ucyBh cmUgYXMgZm9sbG93czo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlRoZXJlIGFyZSB0aHJlZSBzb2x1dGlvbnMgdG8gdGhlIHNlY3VyaXR5DQpwcm9ibGVtIGluIFNO TVAgVXNhZ2UgZm9yIFJFTE9BRC4gVGhlIGZpcnN0IG9wdGlvbiBpcyBzaGFyZWQga2V5IGJhc2Vk DQpzb2x1dGlvbiwgd2hpY2ggaXMgU05NUHYzIHNlY3VyaXR5IHNvbHV0aW9uIChVU00pLiBUaGUg c2Vjb25kIG9wdGlvbiBpcw0KUEtJIGJhc2VkIHNlY3VyaXR5IHNvbHV0aW9uLCB3aGljaCBpcyB0 byB1c2UgdGhlIGNlcnRpZmljYXRlIG9mIFJFTE9BRA0KdG8gYXV0aGVudGljYXRlIGFuZCBlbmNy eXB0IHRoZSBTTk1QIG1lc3NhZ2VzLiBUaGUgdGhpcmQgb3B0aW9uIGlzIERUTFMNCmJhc2VkIHNl Y3VyaXR5IHNvbHV0aW9uLCB3aGljaCB1c2VzIHRoZSBzZWN1cmUgRFRMUyBsaW5rcyB0byB0cmFu c2ZlciB0aGUNClNOTVAgbWVzc2FnZTwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUg c2Vjb25kIGFuZCB0aGlyZCBvcHRpb25zIGFyZW6hr3QNCnN1cHBvcnRlZCBieSBjdXJyZW50IFNO TVAgbWFuYWdlciBhbmQgYWdlbnQsIGFuZCBuZWVkIGxhcmdlIGNoYW5nZXMuIFNvDQp3ZSByZWNv bW1lbmQgdGhlIGZpcnN0IG9wdGlvbi4gQnV0IGl0oa9zIGRpZmZpY3VsdCB0byBkaXN0cmlidXRl IHNlY3VyZWx5DQp0aGUga2V5cyB0byBsYXJnZSBudW1iZXJzIG9mIGFnZW50cyBpbiB0aGUgU05N UCBzZWN1cml0eSBzb2x1dGlvbi4gSW4gdGhpcw0KZG9jdW1lbnQsIHdlIGRpc3RyaWJ1dGUgdGhl IGtleSB0byBlYWNoIGFnZW50IGJ5IHRoZSBjZXJ0aWZpY2F0ZSBtZWNoYW5pc20NCm9mIFJFTE9B RC4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQo8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq PGJyPg0K08ogvP6junBlbmcueW9uZ2xpbkB6dGUuY29tLmNuPGJyPg0KxNogz9+jujgxNTQzPGJy Pg0KzeIgz9+jujAyNS01Mjg3MTU0Mzxicj4NCsrWILv6o7oxMzc3NjYzNzI3NDxicj4NCrSrINXm o7owMjUtNTI4NzIxODc8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPjxiPiZxdW90O1JhbmR5IFByZXN1aG4mcXVvdDsNCiZsdDtyYW5keV9wcmVz dWhuQG1pbmRzcHJpbmcuY29tJmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO29wc2F3Zy1ib3VuY2VzQGlldGYub3JnPC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDYtMTAgMDE6MTY8L2Zv bnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrV vP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0 O29wc2F3Z0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9k aXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbT1BTQVdHXSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtXZQ0KaGF2ZSBzdWJtaXR0ZWQgYSBkcmFmdHMgb24gU05NUCB1c2FnZXMgZm9yIFAyUCBu ZXR3b3Jrcy4gV2Ugd291bGQgbGlrZQ0KdG8gZ2V0IHNvbWUgc3VnZ2VzdGlvbnMgZnJvbSBTTk1Q IGV4cGVydHMgb24gdGhlIHNjZW5hcmlvIGFuZCBkZXNpZ24gZm9yDQpQMlAgbmV0d29yayBtYW5h Z2VtZW50LiBUaGUgbGluayB0byB0aGUgZHJhZnQgaXMgaW4gdGhlIGJvZHkgb2YgdGhpcyBlbWFp bC4NCnRoYW5rc6OhPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yPjx0dD5IaSAtPGJyPg0KPGJyPg0KJmd0OyBGcm9tOiAmbHQ7cGVuZy55b25nbGlu QHp0ZS5jb20uY24mZ3Q7PGJyPg0KJmd0OyBUbzogJmx0O29wc2F3Z0BpZXRmLm9yZyZndDs8YnI+ DQomZ3Q7IENjOiAmbHQ7aGFvLnpoZW53dUB6dGUuY29tLmNuJmd0Ozxicj4NCiZndDsgU2VudDog V2VkbmVzZGF5LCBKdW5lIDA4LCAyMDExIDg6NDMgUE08YnI+DQomZ3Q7IFN1YmplY3Q6IFtPUFNB V0ddIFdlIGhhdmUgc3VibWl0dGVkIGEgZHJhZnRzIG9uIFNOTVAgdXNhZ2VzIGZvciBQMlANCm5l dHdvcmtzLiBXZSB3b3VsZCBsaWtlIHRvIGdldCBzb21lIHN1Z2dlc3Rpb25zIGZyb20gU05NUDxi cj4NCmV4cGVydHMgb24gdGhlIHNjZW5hcmlvIGFuZCBkZXNpZ24gZm9yIFAyUCBuZXR3b3JrIG1h bmFnZW1lbnQuIFRoZSBsaW5rDQp0byB0aGUgZHJhZnQgaXMgaW4gdGhlIGJvZHkgb2YgdGhpcyBl bWFpbC4gdGhhbmtzo6E8YnI+DQomZ3Q7PGJyPg0KJmd0OyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aWQvZHJhZnQtcGVuZy1wMnBzaXAtc25tcC0wMS50eHQ8YnI+DQouLi48YnI+DQo8YnI+DQpTa2lt bWluZyB0aGUgZHJhZnQsIGl0IHdhcyB1bmNsZWFyIHRvIG1lIGhvdyBhIGZldyBkZXRhaWxzIHdv dWxkIHdvcms8YnI+DQppbiB0aGlzIGFwcHJvYWNoLiAmbmJzcDtJIHRoaW5rIGl0IHdvdWxkIGJl IGhlbHBmdWwgdG8gZXhwbGljaXRseSB0YWxrDQphYm91dDxicj4NCiAmbmJzcDsoMSkgaG93IG5v dGlmaWNhdGlvbnMgYXJlIGludGVuZGVkIHRvIHdvcms8YnI+DQogJm5ic3A7KDIpIGtleSBwcm92 aXNpb25pbmcgKGluZGVlZCwgcHJvdmlzaW9uaW5nIGluIGdlbmVyYWwpPGJyPg0KICZuYnNwOygz KSB3aGF0IHNlY3VyaXR5IG1vZGVsIGlzIGluIHVzZTxicj4NCjxicj4NCkkgKnRoaW5rKiBpdCBt aWdodCBiZSBoZWxwZnVsIHRvIHRyZWF0IHRoaXMgYXMgYSBuZXcgdHJhbnNwb3J0PGJyPg0KbW9k ZWwsIGJ1dCB5b3UnbGwgbmVlZCB0byB0aGluayB0aHJvdWdoIGp1c3QgaG93IGF1dGhlbnRpY2F0 aW9uPGJyPg0KYW5kIHByaXZhY3kgYXJlIHRvIGJlIGhhbmRsZWQgKGUuZy4sIGlzIGl0IGp1c3Qg VVNNIGF0b3AgUkVMT0FELDxicj4NCm9yIGRvZXMgUkVMT0FEIHByb3ZpZGUgdGhlIHNlY3VyaXR5 IHNlcnZpY2VzPykuICZuYnNwO1RoaXMgZGVjaXNpb248YnI+DQptYXkgaW50ZXJyYWN0IHdpdGgg aG93LCBmb3IgZXhhbXBsZSwgbm90aWZpY2F0aW9uIGFuZCBEaXNtYW48YnI+DQp0YXJnZXRzIGFy ZSBjb25maWd1cmVkLiAmbmJzcDtJbiBwYXJ0aWN1bGFyLCBjb25zaWRlciB3aGV0aGVyIHlvdSBu ZWVkPGJyPg0KdG8gc3VwcG9ydCB0aGUgY2FzZSB3aGVyZSBvbmx5ICpzb21lKiBvZiB0aGUgU05N UCBpbnRlcnJhY3Rpb25zPGJyPg0KYmV0d2VlbiB0d28gc3lzdGVtcyBhcmUgY2FycmllZCB2aWEg UkVMT0FELjxicj4NCjxicj4NClJhbmR5PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPUFNBV0cgbWFpbGluZyBsaXN0 PGJyPg0KT1BTQVdHQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vcHNhd2c8YnI+DQo8L3R0PjwvZm9udD4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0lu Zm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3Jt YXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMm bmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3Mm bmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9u Jm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5i c3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5i c3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNw O3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhp cyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFp bCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRo Jm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRl ZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5i c3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hh dmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3Im bmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2Vk Jm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3Nh Z2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMm bmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtz eXN0ZW0uDQo8L3ByZT4= --=_alternative 0013D6D2482578C7_=-- From j.schoenwaelder@jacobs-university.de Thu Jul 7 22:33:25 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A368F21F88F9; Thu, 7 Jul 2011 22:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.146 X-Spam-Level: X-Spam-Status: No, score=-102.146 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SGDQlRbt5F7; Thu, 7 Jul 2011 22:33:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C206E21F88FC; Thu, 7 Jul 2011 22:33:18 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4EFDE20BE0; Fri, 8 Jul 2011 07:33:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fwsPE+W9VGys; Fri, 8 Jul 2011 07:33:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E97F20BDD; Fri, 8 Jul 2011 07:33:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3F22D199E07C; Fri, 8 Jul 2011 07:33:14 +0200 (CEST) Date: Fri, 8 Jul 2011 07:33:14 +0200 From: Juergen Schoenwaelder To: peng.yonglin@zte.com.cn Message-ID: <20110708053314.GA11313@elstar.local> Mail-Followup-To: peng.yonglin@zte.com.cn, p2psip@ietf.org, hao.zhenwu@zte.com.cn, li.lichun1@zte.com.cn, opsawg@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 07 Jul 2011 22:35:01 -0700 Cc: hao.zhenwu@zte.com.cn, opsawg@ietf.org, p2psip@ietf.org Subject: Re: [P2PSIP] =?utf-8?q?=5BOPSAWG=5D_We_have_submitted_a_drafts_on_SNM?= =?utf-8?q?P_usages_for_P2P_networks=2E_We_would_like_to_get_some_suggesti?= =?utf-8?q?ons_from_SNMP_experts_on_the_scenario_and_design_for_P2P_networ?= =?utf-8?q?k_management=2E_The_link_to_the_draft_is_in_the_body_of_this_em?= =?utf-8?b?YWlsLiB0aGFua3PvvIE=?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder 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, 08 Jul 2011 05:33:25 -0000 On Fri, Jul 08, 2011 at 11:36:26AM +0800, peng.yonglin@zte.com.cn wrote: > Our security considations are as follows: > There are three solutions to the security problem in SNMP Usage for > RELOAD. The first option is shared key based solution, which is SNMPv3 > security solution (USM). The second option is PKI based security solution, > which is to use the certificate of RELOAD to authenticate and encrypt the > SNMP messages. The third option is DTLS based security solution, which > uses the secure DTLS links to transfer the SNMP message. > The second and third options aren’t supported by current SNMP manager and > agent, and need large changes. Are you aware that SNMP over DTLS has recently been advanced to Draft Standard, after interoperability testing of several SNMP stacks? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From fengkai_sunny@139.com Fri Jul 8 00:08:26 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B6621F88D7 for ; Fri, 8 Jul 2011 00:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.813 X-Spam-Level: * X-Spam-Status: No, score=1.813 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FR_IMPORT_CSS=1.889, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqcio6EV6P19 for ; Fri, 8 Jul 2011 00:08:25 -0700 (PDT) Received: from n9-58.mail.139.com (n9-58.mail.139.com [221.176.9.58]) by ietfa.amsl.com (Postfix) with ESMTP id 262E021F88D1 for ; Fri, 8 Jul 2011 00:08:23 -0700 (PDT) Received: from Bumblebee (unknown [218.206.178.250]) by cmapp-5-08 (Coremail) with SMTP id MKwQrJD73+_jrBZO7ztHAA--.57047S2; Fri, 08 Jul 2011 15:08:20 +0800 (CST) Date: Fri, 08 Jul 2011 15:08:18 +0800 From: "=?utf-8?B?5Yav5oG6?=" To: "p2psip" X-Mailer: NetEase Flash Mail 2.0.2.30 X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="====003__MESSAGE__ID__54yg6f6h6y456345====" X-CM-TRANSID: MKwQrJD73+_jrBZO7ztHAA--.57047S2 X-Coremail-Antispam: 1UD129KBjvJXoWrtFW7uryfAr48Gw43JFyUGFg_yoW8Jr43pF 95Grn5Jas7Jw1jy3W8Z3Z7Zr1S9Fy0kanxJ3ZxG3yFk398Gw1vyryxtrsrXay5AFWFqFyD JryYyr1UZ3s8ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUcIb7IF0VCYb41lb7IF0VCF04k20xv_GrWkM7k042IE4IxYO2xF xVAqjxCEw4Av424lb7Iv0xC_Cr1lb4IE77IF4wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rV WrJVCq3wAqjxCE34x0Y48IcwAqx4xG6xAIxVCFxsxG0wAv7VCjz48v1sIEY20_AF4lYx0E 2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4UM4x0Y48IcxkI7VAKI48JM4 xvF2IEb7IF0Fy264kE64k0F24lw4CEF2IF47xS0VAv8wCF04k20xvY0x0EwIxGrwCF04k2 0xvE74AGY7Cv6cx26F1xMI8E67AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr4UvcSsGvf C2KfnxnUUI43ZEXa7IU1mFAJUUUUU== Message-Id: <4E16ACE5.045139.24555@n9-58.mail.139.com> X-CM-SenderInfo: Subject: [P2PSIP] new draft submission for draft-peng-p2psip-one-hop-plugin-00.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 07:08:26 -0000 --====003__MESSAGE__ID__54yg6f6h6y456345==== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQogICAgSSBoYXZlIHN1Ym1pdHRlZCBuZXcgZHJhZnQgZm9yIHAycHNpcDogdGhl IE9uZSBIb3AgTG9va3VwcyBBbGdvcml0aG0gUGx1Z2luIGZvciBSRUxPQUQuDQogICAgTG9va2lu ZyBmb3J3YXJkIHRvIHlvdXIgY29tbWVudHMuDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LXBlbmctcDJwc2lwLW9uZS1ob3AtcGx1Z2luLTAwLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IExpbmdsaSBEZW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3Np dG9yeS4NCkZpbGVuYW1lOiAgZHJhZnQtcGVuZy1wMnBzaXAtb25lLWhvcC1wbHVnaW4NClJldmlz aW9uOiAgMDANClRpdGxlOiAgIE9uZSBIb3AgTG9va3VwcyBBbGdvcml0aG0gUGx1Z2luIGZvciBS RUxPQUQNCkNyZWF0aW9uIGRhdGU6ICAyMDExLTA3LTAyDQpXRyBJRDogICBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMzANCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVu dCBwcm9wb3NlcyBhbiBpbXBsZW1lbnRhdGlvbiBvZiBvdmVybGF5IHBsdWdpbiBhbGdvcml0aG0N CiAgIHdoaWNoIGlzIGNhbGxlZCBvbmUgaG9wIGxvb2t1cHMgdG8gcHJvdmlkZSBleGFtcGxlcyBh bmQgcmVmZXJlbmNlcw0KICAgZm9yIHRoZSByZXNlYXJjaCBvZiBvbmUgaG9wIGJhc2VkIFJFTE9B RC4gIFdpdGggdGhlIGRldmVsb3BtZW50IG9mDQogICB0aGUgcmVhbCB0aW1lIGNvbW11bmljYXRp b25zLCB0aGVyZSBhcmUgaGlnaCBkZW1hbmRzIGZvciB0aGUNCiAgIGltcHJvdmVtZW50IG9mIHJv dXRpbmcgZWZmaWNpZW5jeS4gIEluIHRoZSBvbmUgaG9wIGFsZ29yaXRobSwgZWFjaA0KICAgcGVl ciBtYWludGFpbnMgY29tcGxldGUgbWVtYmVyc2hpcCBpbmZvcm1hdGlvbiB3aGljaCBjYW4gZ3Vh cmFudGVlDQogICBvbmUgaG9wIGxvb2t1cHMgdG8gaW1wcm92ZSB0aGUgcm91dGluZyBlZmZpY2ll bmN5LiAgRm9yIHRoZSBSRUxPQUQsDQogICB1c2luZyB0aGUgb25lIGhvcCBsb29rdXBzIGFsZ29y aXRobSB0byBjb25zdHJ1Y3QgVG9wb2xvZ3kgUGx1Z2luIHdpdGgNCiAgIHRoZSBzYW1lIFJFTE9B RCBjb3JlIGNhbiBoYXZlIGEgYmV0dGVyIHN1cHBvcnQgZm9yIFZvSVAgYXBwbGljYXRpb25zLA0K ICAgYW5kIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBvbmUgaG9wIGxvb2t1cHMgYWxnb3JpdGhtIHBs dWdpbiBpcyBiYXNlZA0KICAgb24gdGhlIG1ldGhvZHMgcHJvdmlkZWQgYnkgUkVMQU9ELg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA== --====003__MESSAGE__ID__54yg6f6h6y456345==== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPFNUWUxFIHR5cGU9dGV4dC9jc3M+IDwhLS1AaW1wb3J0IHVy bChFOlxQcm9ncmFtIEZpbGVzXE5ldGVhc2Vc572R5piT6Zeq55S16YKuXFxkYXRhXHNjcm9sbGJh ci5jc3MpOyAtLT48L1NUWUxFPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9 dXRmLTgiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPFNUWUxFPkJMT0NLUVVPVEV7bWFyZ2lu LVRvcDogMHB4OyBtYXJnaW4tQm90dG9tOiAwcHg7IG1hcmdpbi1MZWZ0OiAyZW19OyAJCQkJCQkJ CQlPTCwgVUx7bWFyZ2luLVRvcDogMHB4OyBtYXJnaW4tQm90dG9tOiAwcHh9OyAJCQkJCQkJCQlw e21hcmdpbi1Ub3A6MGVtOyBtYXJnaW4tQm90dG9tOjBweDsgcGFkZGluZzowcHg7fTsgCQkJCQkJ CQkJYm9keXtGT05ULVNJWkU6MTJwdDsgRk9OVC1GQU1JTFk65a6L5L2TLHNlcmlmO307IAkJCQkJ CQkJCTwvU1RZTEU+DQoNCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNvbnRlbnQ9Ik1TSFRNTCA5LjAw LjgxMTIuMTY0MzAiPjxCQVNFIA0KdGFyZ2V0PV9ibGFuaz48L0hFQUQ+DQo8Qk9EWSANCnN0eWxl PSJMSU5FLUhFSUdIVDogMS4zOyBCT1JERVItUklHSFQtV0lEVEg6IDBweDsgTUFSR0lOOiAxMnB4 OyBCT1JERVItVE9QLVdJRFRIOiAwcHg7IEJPUkRFUi1CT1RUT00tV0lEVEg6IDBweDsgQk9SREVS LUxFRlQtV0lEVEg6IDBweCIgDQptYXJnaW5oZWlnaHQ9IjAiIG1hcmdpbndpZHRoPSIwIj4NCjxQ PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+RGVhciBhbGwsPC9GT05UPjwvUD4NCjxQPjxG T05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgaGF2ZSBzdWJt aXR0ZWQgbmV3IGRyYWZ0IA0KZm9yIHAycHNpcDogdGhlIE9uZSBIb3AgTG9va3VwcyBBbGdvcml0 aG0gUGx1Z2luIGZvciBSRUxPQUQuPC9GT05UPjwvUD4NCjxQPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IExvb2tpbmcgZm9yd2FyZCB0byB5b3VyIA0KY29t bWVudHMuPC9GT05UPjwvUD4NCjxQPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05U PiZuYnNwOzwvUD4NCjxQPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPiZuYnNw OzwvUD4NCjxQPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+QSBuZXcgdmVyc2lvbiBvZiBJ LUQsIA0KZHJhZnQtcGVuZy1wMnBzaXAtb25lLWhvcC1wbHVnaW4tMDAudHh0IGhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgDQpMaW5nbGkgRGVuZyBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGIHJlcG9zaXRvcnkuPC9GT05UPjwvUD4NCjxQPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+RmlsZW5hbWU6Jm5ic3A7IA0KZHJhZnQtcGVuZy1wMnBzaXAtb25lLWhvcC1wbHVnaW48QlI+ UmV2aXNpb246Jm5ic3A7IDAwPEJSPlRpdGxlOiZuYnNwOyZuYnNwOyBPbmUgDQpIb3AgTG9va3Vw cyBBbGdvcml0aG0gUGx1Z2luIGZvciBSRUxPQUQ8QlI+Q3JlYXRpb24gZGF0ZTombmJzcDsgMjAx MS0wNy0wMjxCUj5XRyANCklEOiZuYnNwOyZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248QlI+ TnVtYmVyIG9mIHBhZ2VzOiAzMDwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPkFic3RyYWN0OjxCUj4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyAN CmFuIGltcGxlbWVudGF0aW9uIG9mIG92ZXJsYXkgcGx1Z2luIGFsZ29yaXRobTxCUj4mbmJzcDsm bmJzcDsgd2hpY2ggaXMgY2FsbGVkIA0Kb25lIGhvcCBsb29rdXBzIHRvIHByb3ZpZGUgZXhhbXBs ZXMgYW5kIHJlZmVyZW5jZXM8QlI+Jm5ic3A7Jm5ic3A7IGZvciB0aGUgDQpyZXNlYXJjaCBvZiBv bmUgaG9wIGJhc2VkIFJFTE9BRC4mbmJzcDsgV2l0aCB0aGUgZGV2ZWxvcG1lbnQgb2Y8QlI+Jm5i c3A7Jm5ic3A7IA0KdGhlIHJlYWwgdGltZSBjb21tdW5pY2F0aW9ucywgdGhlcmUgYXJlIGhpZ2gg ZGVtYW5kcyBmb3IgdGhlPEJSPiZuYnNwOyZuYnNwOyANCmltcHJvdmVtZW50IG9mIHJvdXRpbmcg ZWZmaWNpZW5jeS4mbmJzcDsgSW4gdGhlIG9uZSBob3AgYWxnb3JpdGhtLCANCmVhY2g8QlI+Jm5i c3A7Jm5ic3A7IHBlZXIgbWFpbnRhaW5zIGNvbXBsZXRlIG1lbWJlcnNoaXAgaW5mb3JtYXRpb24g d2hpY2ggY2FuIA0KZ3VhcmFudGVlPEJSPiZuYnNwOyZuYnNwOyBvbmUgaG9wIGxvb2t1cHMgdG8g aW1wcm92ZSB0aGUgcm91dGluZyANCmVmZmljaWVuY3kuJm5ic3A7IEZvciB0aGUgUkVMT0FELDxC Uj4mbmJzcDsmbmJzcDsgdXNpbmcgdGhlIG9uZSBob3AgbG9va3VwcyANCmFsZ29yaXRobSB0byBj b25zdHJ1Y3QgVG9wb2xvZ3kgUGx1Z2luIHdpdGg8QlI+Jm5ic3A7Jm5ic3A7IHRoZSBzYW1lIFJF TE9BRCBjb3JlIA0KY2FuIGhhdmUgYSBiZXR0ZXIgc3VwcG9ydCBmb3IgVm9JUCBhcHBsaWNhdGlv bnMsPEJSPiZuYnNwOyZuYnNwOyBhbmQgdGhlIA0KaW1wbGVtZW50YXRpb24gb2Ygb25lIGhvcCBs b29rdXBzIGFsZ29yaXRobSBwbHVnaW4gaXMgYmFzZWQ8QlI+Jm5ic3A7Jm5ic3A7IG9uIA0KdGhl IG1ldGhvZHMgcHJvdmlkZWQgYnkgUkVMQU9ELjwvRk9OVD48L1A+DQo8UD48Rk9OVCANCmZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPC9GT05U PjwvUD4NCjxQPjxCUj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlRoZSBJRVRGIA0KU2Vj cmV0YXJpYXQ8QlI+PC9GT05UPjwvUD48L0JPRFk+PC9IVE1MPg== --====003__MESSAGE__ID__54yg6f6h6y456345====-- From peng.yonglin@zte.com.cn Fri Jul 8 02:32:40 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEF821F897D; Fri, 8 Jul 2011 02:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.19 X-Spam-Level: X-Spam-Status: No, score=-90.19 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAIZTIPultTe; Fri, 8 Jul 2011 02:32:40 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1F47821F8976; Fri, 8 Jul 2011 02:32:38 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48643465113155; Fri, 8 Jul 2011 17:31:18 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.5408727031; Fri, 8 Jul 2011 17:28:47 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p689SfGd005352; Fri, 8 Jul 2011 17:28:41 +0800 (GMT-8) (envelope-from peng.yonglin@zte.com.cn) In-Reply-To: <20110708053314.GA11313@elstar.local> To: Juergen Schoenwaelder MIME-Version: 1.0 X-KeepSent: 4039DC2A:358D9B47-482578C7:00335539; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: peng.yonglin@zte.com.cn Date: Fri, 8 Jul 2011 17:28:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-08 17:28:42, Serialize complete at 2011-07-08 17:28:42 Content-Type: multipart/alternative; boundary="=_alternative 0034229A482578C7_=" X-MAIL: mse01.zte.com.cn p689SfGd005352 Cc: hao.zhenwu@zte.com.cn, opsawg@ietf.org, p2psip@ietf.org Subject: [P2PSIP] =?gb2312?b?tPC4tDogUmU6IFtPUFNBV0ddIFdlIGhhdmUgc3VibWl0?= =?gb2312?b?dGVkIGEgZHJhZnRzIG9uIFNOTVAgdXNhZ2VzIGZvciBQMlAgbmV0d29ya3Mu?= =?gb2312?b?IFdlIHdvdWxkIGxpa2UgdG8gZ2V0IHNvbWUgc3VnZ2VzdGlvbnMgZnJvbSBT?= =?gb2312?b?Tk1QIGV4cGVydHMgb24gdGhlIHNjZW5hcmlvIGFuZCBkZXNpZ24gZm9yIFAy?= =?gb2312?b?UCBuZXR3b3JrIG1hbmFnZW1lbnQuIFRoZSBsaW5rIHRvIHRoZSBkcmFmdCBp?= =?gb2312?b?cyBpbiB0aGUgYm9keSBvZiB0aGlzIGVtYWlsLiB0aGFua3OjoQ==?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 09:32:40 -0000 This is a multipart message in MIME format. --=_alternative 0034229A482578C7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SXMgdGhlIHN0YW5kYXJkIHdoaWNoIHlvdSByZWZlciB0byBSRkM1OTUzID8NCg0KDQoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQrTyiC8/qO6cGVuZy55 b25nbGluQHp0ZS5jb20uY24NCsTaIM/fo7o4MTU0Mw0KzeIgz9+jujAyNS01Mjg3MTU0Mw0KytYg u/qjujEzNzc2NjM3Mjc0DQq0qyDV5qO6MDI1LTUyODcyMTg3DQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCg0KDQpKdWVyZ2VuIFNjaG9lbndhZWxk ZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gDQoyMDExLTA3LTA4IDEz OjMzDQrH67TwuLQguPgNCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGph Y29icy11bml2ZXJzaXR5LmRlPg0KDQoNCsrVvP7Iyw0KcGVuZy55b25nbGluQHp0ZS5jb20uY24N CrOty80NCnAycHNpcEBpZXRmLm9yZywgaGFvLnpoZW53dUB6dGUuY29tLmNuLCBsaS5saWNodW4x QHp0ZS5jb20uY24sIA0Kb3BzYXdnQGlldGYub3JnDQrW98ziDQpSZTogW09QU0FXR10gV2UgaGF2 ZSBzdWJtaXR0ZWQgYSBkcmFmdHMgb24gU05NUCB1c2FnZXMgZm9yIFAyUCBuZXR3b3Jrcy4gDQpX ZSB3b3VsZCBsaWtlIHRvIGdldCBzb21lIHN1Z2dlc3Rpb25zIGZyb20gU05NUCBleHBlcnRzIG9u IHRoZSBzY2VuYXJpbyANCmFuZCBkZXNpZ24gZm9yIFAyUCBuZXR3b3JrIG1hbmFnZW1lbnQuIFRo ZSBsaW5rIHRvIHRoZSBkcmFmdCBpcyBpbiB0aGUgDQpib2R5IG9mIHRoaXMgZW1haWwuIHRoYW5r c6OhDQoNCg0KDQoNCg0KDQpPbiBGcmksIEp1bCAwOCwgMjAxMSBhdCAxMTozNjoyNkFNICswODAw LCBwZW5nLnlvbmdsaW5AenRlLmNvbS5jbiB3cm90ZToNCg0KPiBPdXIgc2VjdXJpdHkgY29uc2lk YXRpb25zIGFyZSBhcyBmb2xsb3dzOg0KPiBUaGVyZSBhcmUgdGhyZWUgc29sdXRpb25zIHRvIHRo ZSBzZWN1cml0eSBwcm9ibGVtIGluIFNOTVAgVXNhZ2UgZm9yIA0KPiBSRUxPQUQuIFRoZSBmaXJz dCBvcHRpb24gaXMgc2hhcmVkIGtleSBiYXNlZCBzb2x1dGlvbiwgd2hpY2ggaXMgU05NUHYzIA0K PiBzZWN1cml0eSBzb2x1dGlvbiAoVVNNKS4gVGhlIHNlY29uZCBvcHRpb24gaXMgUEtJIGJhc2Vk IHNlY3VyaXR5IA0Kc29sdXRpb24sIA0KPiB3aGljaCBpcyB0byB1c2UgdGhlIGNlcnRpZmljYXRl IG9mIFJFTE9BRCB0byBhdXRoZW50aWNhdGUgYW5kIGVuY3J5cHQgDQp0aGUgDQo+IFNOTVAgbWVz c2FnZXMuIFRoZSB0aGlyZCBvcHRpb24gaXMgRFRMUyBiYXNlZCBzZWN1cml0eSBzb2x1dGlvbiwg d2hpY2ggDQo+IHVzZXMgdGhlIHNlY3VyZSBEVExTIGxpbmtzIHRvIHRyYW5zZmVyIHRoZSBTTk1Q IG1lc3NhZ2UuDQo+IFRoZSBzZWNvbmQgYW5kIHRoaXJkIG9wdGlvbnMgYXJlbqGvdCBzdXBwb3J0 ZWQgYnkgY3VycmVudCBTTk1QIG1hbmFnZXIgDQphbmQgDQo+IGFnZW50LCBhbmQgbmVlZCBsYXJn ZSBjaGFuZ2VzLg0KDQpBcmUgeW91IGF3YXJlIHRoYXQgU05NUCBvdmVyIERUTFMgaGFzIHJlY2Vu dGx5IGJlZW4gYWR2YW5jZWQgdG8gRHJhZnQNClN0YW5kYXJkLCBhZnRlciBpbnRlcm9wZXJhYmls aXR5IHRlc3Rpbmcgb2Ygc2V2ZXJhbCBTTk1QIHN0YWNrcz8NCg0KL2pzDQoNCi0tIA0KSnVlcmdl biBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgN ClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJl bWVuLCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3 LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3Vy aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29s ZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21t dW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2Js aWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Ns b3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBl bWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBh bmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0 eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdl LiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGlu ZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVz ZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0034229A482578C7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklzIHRoZSBzdGFuZGFyZCB3aGlj aCB5b3UgcmVmZXIgdG8gUkZDNTk1Mw0KPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKjxicj4NCtPKILz+o7pwZW5nLnlvbmdsaW5AenRlLmNvbS5jbjxicj4N CsTaIM/fo7o4MTU0Mzxicj4NCs3iIM/fo7owMjUtNTI4NzE1NDM8YnI+DQrK1iC7+qO6MTM3NzY2 MzcyNzQ8YnI+DQq0qyDV5qO6MDI1LTUyODcyMTg3PGJyPg0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5KdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2No b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wNy0wOCAxMzozMzwvZm9udD4NCjx0YWJs ZSBib3JkZXI+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCBiZ2NvbG9yPXdoaXRlPg0KPGRpdiBhbGln bj1jZW50ZXI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsfrtPC4tCC4+Dxicj4NCkp1 ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5 LmRlJmd0OzwvZm9udD48L2Rpdj48L3RhYmxlPg0KPGJyPg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnBlbmcueW9uZ2xpbkB6dGUuY29tLmNuPC9mb250 Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj5wMnBzaXBAaWV0Zi5vcmcsIGhhby56aGVud3VAenRlLmNvbS5jbiwNCmxp LmxpY2h1bjFAenRlLmNvbS5jbiwgb3BzYXdnQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5S ZTogW09QU0FXR10gV2UgaGF2ZSBzdWJtaXR0ZWQgYSBkcmFmdHMNCm9uIFNOTVAgdXNhZ2VzIGZv ciBQMlAgbmV0d29ya3MuIFdlIHdvdWxkIGxpa2UgdG8gZ2V0IHNvbWUgc3VnZ2VzdGlvbnMNCmZy b20gU05NUCBleHBlcnRzIG9uIHRoZSBzY2VuYXJpbyBhbmQgZGVzaWduIGZvciBQMlAgbmV0d29y ayBtYW5hZ2VtZW50Lg0KVGhlIGxpbmsgdG8gdGhlIGRyYWZ0IGlzIGluIHRoZSBib2R5IG9mIHRo aXMgZW1haWwuIHRoYW5rc6OhPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5PbiBGcmksIEp1bCAwOCwgMjAxMSBhdCAxMTozNjoyNkFNICsw ODAwLCBwZW5nLnlvbmdsaW5AenRlLmNvbS5jbg0Kd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBPdXIg c2VjdXJpdHkgY29uc2lkYXRpb25zIGFyZSBhcyBmb2xsb3dzOjxicj4NCiZndDsgVGhlcmUgYXJl IHRocmVlIHNvbHV0aW9ucyB0byB0aGUgc2VjdXJpdHkgcHJvYmxlbSBpbiBTTk1QIFVzYWdlIGZv cg0KPGJyPg0KJmd0OyBSRUxPQUQuIFRoZSBmaXJzdCBvcHRpb24gaXMgc2hhcmVkIGtleSBiYXNl ZCBzb2x1dGlvbiwgd2hpY2ggaXMgU05NUHYzDQo8YnI+DQomZ3Q7IHNlY3VyaXR5IHNvbHV0aW9u IChVU00pLiBUaGUgc2Vjb25kIG9wdGlvbiBpcyBQS0kgYmFzZWQgc2VjdXJpdHkgc29sdXRpb24s DQo8YnI+DQomZ3Q7IHdoaWNoIGlzIHRvIHVzZSB0aGUgY2VydGlmaWNhdGUgb2YgUkVMT0FEIHRv IGF1dGhlbnRpY2F0ZSBhbmQgZW5jcnlwdA0KdGhlIDxicj4NCiZndDsgU05NUCBtZXNzYWdlcy4g VGhlIHRoaXJkIG9wdGlvbiBpcyBEVExTIGJhc2VkIHNlY3VyaXR5IHNvbHV0aW9uLCB3aGljaA0K PGJyPg0KJmd0OyB1c2VzIHRoZSBzZWN1cmUgRFRMUyBsaW5rcyB0byB0cmFuc2ZlciB0aGUgU05N UCBtZXNzYWdlLjxicj4NCiZndDsgVGhlIHNlY29uZCBhbmQgdGhpcmQgb3B0aW9ucyBhcmVuoa90 IHN1cHBvcnRlZCBieSBjdXJyZW50IFNOTVAgbWFuYWdlcg0KYW5kIDxicj4NCiZndDsgYWdlbnQs IGFuZCBuZWVkIGxhcmdlIGNoYW5nZXMuPGJyPg0KPGJyPg0KQXJlIHlvdSBhd2FyZSB0aGF0IFNO TVAgb3ZlciBEVExTIGhhcyByZWNlbnRseSBiZWVuIGFkdmFuY2VkIHRvIERyYWZ0PGJyPg0KU3Rh bmRhcmQsIGFmdGVyIGludGVyb3BlcmFiaWxpdHkgdGVzdGluZyBvZiBzZXZlcmFsIFNOTVAgc3Rh Y2tzPzxicj4NCjxicj4NCi9qczxicj4NCjxicj4NCi0tIDxicj4NCkp1ZXJnZW4gU2Nob2Vud2Fl bGRlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEphY29icyBVbml2ZXJzaXR5 DQpCcmVtZW4gZ0dtYkg8YnI+DQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgQ2FtcHVzIFJpbmcgMSwgMjg3NTkNCkJyZW1lbiwgR2VybWFueTxicj4N CkZheDogJm5ic3A7ICs0OSA0MjEgMjAwIDMxMDMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZsdDtodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLyZndDs8YnI+DQo8YnI+DQo8L2Zv bnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2Vj dXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWlu ZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtw cm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24u Jm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25m aWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUm bmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2Fu ZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2Um bmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRp b24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2Fu eSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUm bmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNw O2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZu YnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZu YnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZu YnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtu b3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNz YWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlz Jm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtp bmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDti ZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFt Jm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0034229A482578C7_=-- From loopp2psip@gmail.com Fri Jul 8 04:17:00 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E0421F8622 for ; Fri, 8 Jul 2011 04:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.813 X-Spam-Level: X-Spam-Status: No, score=0.813 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PKLQg12CsKq for ; Fri, 8 Jul 2011 04:16:59 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAFA21F865B for ; Fri, 8 Jul 2011 04:16:58 -0700 (PDT) Received: by wyj26 with SMTP id 26so1437493wyj.31 for ; Fri, 08 Jul 2011 04:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=0NKrcBL2V8lVCD1DkRn9TekT79ip0Q7rvHV8LCsFS1Q=; b=fpBxMnXppDJ6HLcF3BtONFk8jYZh5Og4J88qnVMQTbs5t87yTYEQIWNZhlu0zuiUpk ig5HHoguPfHQTVqXsYCwDLJRHGOiECUGI5vg2H61wmUMikBUFSqQlP0Tk2mbFerlUxV8 jZDZy2j0Ch4TeB4Q7YHVyiPkpkh9nnOwKY80E= Received: by 10.227.174.69 with SMTP id s5mr1683257wbz.80.1310123816143; Fri, 08 Jul 2011 04:16:56 -0700 (PDT) Received: from [163.117.205.20] ([163.117.205.20]) by mx.google.com with ESMTPS id p14sm3355415wbh.64.2011.07.08.04.16.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jul 2011 04:16:54 -0700 (PDT) From: Diego Suarez To: Bruce Lowekamp In-Reply-To: References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E0E4DBE.5060302@acm.org> <1309624099.5232.23.camel@santeles> <4E0F4F8D.9080108@acm.org> <1309773089.5716.43.camel@santeles> Content-Type: text/plain; charset="UTF-8" Date: Fri, 08 Jul 2011 13:15:12 +0200 Message-ID: <1310123712.22737.73.camel@toedo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 11:17:00 -0000 Hi Bruce, Answers inline. On Thu, 2011-07-07 at 22:24 -0400, Bruce Lowekamp wrote: > Diego, > > Please take some time understanding how real clients work in reload. > Then just have the virtual clients use the same messages. The virtual > clients use their own nodeids, not the host's nodeid. It all works > fine. I agree, this works fine for clients, but, from my point of view, it does not for several users connected to the same device. The fact that clients ( or virtual clients ) use their own nodeIDs and not the host's nodeIDs is precisely what I see as the problem of using virtual clients to allow several users to be connected to the same device. Since virtual clients are not using the device's nodeID, they cannot perform operations ( like NODE-MATCH or USER-NODE-MATCH accesses) from that device like they should if they were actually connected to the system from it. As I've said in my previous mail, they only way I see to allow so is the device adding an extra signature to the message, with the already commented problem of two users and two nodeIDs in it. > I don't see a real problem with a host node having an > "admin@example.com" or "node12345@example.com" name attached to it. > Routers pretty much always have DNS names that are descriptive of > where they are to admins, even though routing protocols don't require > it. Neither do I except for cases, like the presented before, of several users in the same device. > > Regarding certs, 6072 has the following text: > > If the certificate is signed by a trusted certification authority, > and one of the names in the SubjectAltName matches the original URI, > then this certificate MAY be used, but only for exactly the original > > It's been awhile since I've looked at that in detail, but it appears > to me that a reload cert could be perfectly valid for use with 6072 as > long as it has the sip uri in it. Though I'm not immediately > convinced that this is that useful, regardless. The problem is not with RELOAD certs being used in SIP systems, but with SIP certs being used in RELOAD systems. Since SIP certs do not have nodeIDs, they are not valid in RELOAD. cheers > > Bruce > > > > On Mon, Jul 4, 2011 at 5:51 AM, Diego Suarez wrote: > > Hi, > > > > Actually, I see this "virtual client" method more complicated and > > confusing than splitting the identities of users and devices. > > > > With this model, you are gonna have a device identified by a PKC that > > includes a username and a nodeID acting as a peer, but only using its > > nodeID. And several users connected to the device as virtual clients > > identified by PKCs including a username and a nodeID, but only using > > their usernames. > > > > One of the more confusing things I see here is the access control. > > Imagine we have a device, with PKC ( # user = device1, nodeID = 100 # ) > > and two users ( # user = user1, nodeID = 200 # and # user = user2, > > nodeID = 300 # ) connected to that device acting as virtual clients. > > > > If user1 wants to perform a USER-NODE-MATCH access control related to > > the peer she is operating from ( actually the nodeID = 100 nor the > > virtual one with nodeID = 200 ) and her username ( user = user1 ), she > > is gonna have to create a request signed with her PKC and the PKC of the > > device. This request need to be doubled signed ( by the peer to grant > > the nodeID = 100 and by the user to grant the user = user 1 ). However, > > this double signed request intended for nodeID = 100 and user = user1 is > > gonna include two users = device1 and user1 and two nodeID = 100 and > > 200. This is confusing for me. Therefore, from my point of view, it > > makes sense to me to remove the username from the device and the node > > from the users since we are not using them and confuse the access > > control. > > > > Also, splitting identities have another advantages like greater > > interoperability with traditional SIP systems. Imagine a company running > > a SIP system, where users are identified by a PKC including a SIP > > username, that wants to extend its coverage interconnecting it with a > > P2PSIP system. With the actual certification model, SIP PKCs are not > > valid for the new P2PSIP side of the system. All the users have to be > > re-certificated to have a PKC including the old SIP username and a > > nodeID. However, with the split proposal SIP certificates are still > > valid in the P2PSIP side of the system and interoperable within the two > > networks, and only the devices intended to be used in the P2PSIP side > > have to be certified with a nodeID. > > > > > > cheers > > > > > > > > > > On Sat, 2011-07-02 at 16:53 -0400, Bruce Lowekamp wrote: > >> With the current definition of the protocol, split routing IDs and > >> user IDs can be achieved by having the host node participate as a peer > >> (or as a client, honestly) using its own cert and the attached users > >> represented as virtual clients, i.e. generate messages as if they are > >> on separate nodes attached to the host node as a client. > >> > >> If you wanted to implement it "natively," other than the > >> USER-NODE-MATCH, as mentioned before, I can only find two changes that > >> would need to be made to support split identities. > >> > >> For processing StoreReq: > >> o For original (non-replica) stores, the StoreReq is signed by a > >> credential which is authorized to write this kind at this > >> Resource-Id. If this check fails, the request MUST be rejected > >> with an Error_Forbidden error. > >> > >> and the definition of credential in beginning of 10.3. > >> > >> > >> Assuming that there is not something I'm missing with using virtual > >> clients, I'd rather not make any changes. This is a complicated > >> enough protocol, and I think adding special cases for something like > >> split identities just makes it more complicated. If any changes were > >> made, I would think it should be something to make it possible for an > >> extension to specify the change, but as long as the current protocol > >> is capable of handling the functional goals, I'd rather no changes be > >> made. > >> > >> Bruce > >> > >> > >> > >> > >> On Sat, Jul 2, 2011 at 1:04 PM, Marc Petit-Huguenin wrote: > >> > -----BEGIN PGP SIGNED MESSAGE----- > >> > Hash: SHA1 > >> > > >> > On 07/02/2011 09:28 AM, Diego Suarez wrote: > >> >> Hi, > >> >> > >> >>>From my point of view, in this case the user has to both prove she is in > >> >> possession of the PKC that includes the required username and also prove > >> >> she is operating from the required node. However, modifying the > >> >> SignerIdentity to include multiple identities ( the user and the > >> >> device ) would not really prove that since only one signature could be > >> >> included (either the user's signature or the device's one). > >> >> > >> >> Therefore, I'd modify the SecurityBlock instead to allow the inclusion > >> >> of more than only one signature. > >> >> > >> >> For this case, the securityBlock would include two signatures. One with > >> >> the SignerIdentity of the user and the signature of the user's PKC > >> >> (including the username ) and another with the SignerIdentity of the > >> >> device and the signature of the device's PKC ( including the nodeID). > >> > > >> > Right, something like this: > >> > > >> > struct { > >> > GenericCertificate certificates<0..2^16-1>; > >> > Signature signatures<0..2^16-1>; > >> > } SecurityBlock; > >> > > >> > Note that StoredData also needs to be modified: > >> > > >> > struct { > >> > uint32 length; > >> > uint64 storage_time; > >> > uint32 lifetime; > >> > StoredDataValue value; > >> > Signature signatures<0..2^16-1>; > >> > } StoredData; > >> > > >> >> > >> >> cheers > >> >> > >> >> > >> >> On Fri, 2011-07-01 at 15:44 -0700, Marc Petit-Huguenin wrote: > >> >> Hi Diego, > >> >> > >> >> How does this work with an access control policy like USER-NODE-MATCH, which > >> >> requires both a Node-ID and a username in the SignerIdentity? If the Node-ID > >> >> and the username are in separate certificates, wouldn't that require to extend > >> >> the SignerIdentity structure to store multiple identities? > >> >> > >> >> Thanks. > >> >> > >> >> On 06/09/2011 10:47 AM, Diego Suarez wrote: > >> >>>>> I think it would require a (slight) modification in the base document. > >> >>>>> Current P2PSIP certification model is based on a single PKC (including > >> >>>>> both usernames and nodeIDs) that uniquely identifies a user and her > >> >>>>> devices. On the other hand, our model is base on a split certification. > >> >>>>> Devices and users are independent. Each device has its own PKC including > >> >>>>> a nodeID and a PK. Similarly, each user has her own PKC including her > >> >>>>> username and a PK. This approach do not prevent a centralized entity > >> >>>>> (such as an offline CA) to have information related to the devices each > >> >>>>> user (or company, etc.) has registered, but permits, among other > >> >>>>> improvements, a user to be connected to the system through devices she > >> >>>>> has not registered herself such as a phone issued by a telco or a fixed > >> >>>>> phone in a laboratory shared by all the members of a research group. > >> >>>>> > >> >>>>> > >> >>>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: > >> >>>>> Does this model really required modifications in the base document, or can it be > >> >>>>> designed as an extension? (Unfortunately the paper is not freely available, so > >> >>>>> it is difficult to know really what is needed for this). > >> >>>>> > >> >>>>> On 06/09/2011 07:31 AM, Diego Suarez wrote: > >> >>>>>>>> Hi, > >> >>>>>>>> > >> >>>>>>>> I had in mind writing a draft about this, but since I'm running out of > >> >>>>>>>> time, I would like to summarize a new certification model for P2PSIP I > >> >>>>>>>> have been working on, in case it is of interest for the group. > >> >>>>>>>> Further details can be found in paper: > >> >>>>>>>> > >> >>>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, Advantages of > >> >>>>>>>> identity certificate segregation in P2PSIP systems, Communications, > >> >>>>>>>> IET, vol. 5, pp. 879 889, Apr. 2011. > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> The idea is to split the certification of users and devices. Devices are > >> >>>>>>>> identified by PKCs including a nodeID and the PK of the device, while > >> >>>>>>>> users are identified by PKCs including a username and the PK of the > >> >>>>>>>> user. Similar models have been used before in other communications > >> >>>>>>>> systems, such as GSM where devices and users are separately represented > >> >>>>>>>> by the international mobile equipment identity (IMEI) stored in the > >> >>>>>>>> phones and the international mobile subscriber identity (IMSI) stored in > >> >>>>>>>> the user subscriber identity module (SIM), respectively. > >> >>>>>>>> > >> >>>>>>>> Motivations of this model are: > >> >>>>>>>> > >> >>>>>>>> - Users and devices are different entities performing different > >> >>>>>>>> roles within a P2PSIP system. Devices are nodes of the P2P > >> >>>>>>>> overlay network (represented by a nodeID) that offer services > >> >>>>>>>> (to route messages, to store data, . . .) to the system, while > >> >>>>>>>> users (represented by an username) utilize these services, > >> >>>>>>>> usually to establish media communications using SIP. > >> >>>>>>>> > >> >>>>>>>> - Support for mobility scenarios where a user may be logged at different > >> >>>>>>>> devices at the same time using the same PKC. > >> >>>>>>>> > >> >>>>>>>> - Support several users to be logged in the same device (like a fixed > >> >>>>>>>> phone) at the same time. > >> >>>>>>>> > >> >>>>>>>> - Support for user independent hard-coded devices. > >> >>>>>>>> > >> >>>>>>>> - Interoperability with SIP. SIP certificates are not valid in actual > >> >>>>>>>> P2PSIP since they don't include a nodeID. > >> >>>>>>>> > >> >>>>>>>> cheers > >> >>>>>>>> > >> >>>>>>>> Diego Suárez > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: > >> >>>>>>>>> Unless something major comes up, we plan to request the newest version > >> >>>>>>>>> of the base draft, draft-ietf-p2psip-base-15, be published. I'll put > >> >>>>>>>>> in the request in a week (June 16th or 17th). If there are any further > >> >>>>>>>>> comments from the last call a while ago (or further comments on the > >> >>>>>>>>> comments since then), please send them to the list ASAP. > >> >>>>>>>>> > >> >>>>>>>>> Thanks, > >> >>>>>>>>> > >> >>>>>>>>> David (as chair) > >> > > >> > - -- > >> > Marc Petit-Huguenin > >> > Personal email: marc@petit-huguenin.org > >> > Professional email: petithug@acm.org > >> > Blog: http://blog.marc.petit-huguenin.org > >> > -----BEGIN PGP SIGNATURE----- > >> > Version: GnuPG v1.4.11 (GNU/Linux) > >> > > >> > iEYEARECAAYFAk4PT4sACgkQ9RoMZyVa61dPvACeITly6/Zqumz4e4ZrAn1yGI4x > >> > ay4AoJ11vmCRDkL8pXuN71qaZXhw5JTZ > >> > =Tp+D > >> > -----END PGP SIGNATURE----- > >> > _______________________________________________ > >> > P2PSIP mailing list > >> > P2PSIP@ietf.org > >> > https://www.ietf.org/mailman/listinfo/p2psip > >> > > > > > > > From loopp2psip@gmail.com Fri Jul 8 04:32:11 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BC221F857F for ; Fri, 8 Jul 2011 04:32:11 -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=2.206, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMtdp9I46PBQ for ; Fri, 8 Jul 2011 04:32:10 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D1DBF21F8583 for ; Fri, 8 Jul 2011 04:32:07 -0700 (PDT) Received: by wyj26 with SMTP id 26so1447701wyj.31 for ; Fri, 08 Jul 2011 04:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=NxSt+u3PnHknZSJPG3jFrfComm12UXYaTkP8scIydFk=; b=PQqVAzgcUdwQSBq5N9Je7s0liWNTYdwnuPocyqAcHR31H74gRZQI/0olzH3k9nWh1D KpSab0e2M8TB2FriNYQ0dNO3EVljbyDxjpRO6i8M7KxiRENXbHqbdSjUH2CMF/m0WV8F MMTr6w5efatBwwUQnsvzE3pdSFWnL2onNT/5Y= Received: by 10.216.60.17 with SMTP id t17mr557185wec.29.1310124725358; Fri, 08 Jul 2011 04:32:05 -0700 (PDT) Received: from [163.117.205.20] ([163.117.205.20]) by mx.google.com with ESMTPS id u64sm5297168weq.28.2011.07.08.04.32.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jul 2011 04:32:04 -0700 (PDT) From: Diego Suarez To: Marc Petit-Huguenin In-Reply-To: <4E163E7F.1000209@acm.org> References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E00F7CE.7080402@acm.org> <4E0DB3EC.1040705@ericsson.com> <4E163E7F.1000209@acm.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 08 Jul 2011 13:30:21 +0200 Message-ID: <1310124621.22737.86.camel@toedo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 11:32:11 -0000 Hi, The last I would like is to stop, break or delay the actual deployments. If you find split certification useful, it is fine with me to address it with an extension. However, as Marc's said, in order to be possible it would need a change in the actual draft anyway to allow multiple signatures in SecureBlock and StoredData. cheers On Thu, 2011-07-07 at 16:17 -0700, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/07/2011 03:34 PM, Cullen Jennings wrote: > > > > This would break all the current deployments and implementation and not just > > in a way where some new software would need to be pushed out - all new > > certificates would need to be issues. From my point of view, this is too late > > for this change and instead it could be addressed with an extension. > > I agree that it is probably too late, but I am concerned that this modification > is not really possible in an extension, but instead requires a new version of > the protocol because it needs two signatures in SecureBlock and StoredData. > > > > > On Jul 1, 2011, at 5:47 AM, Gonzalo Camarillo wrote: > > > >> Hi, > >> > >> please, let me know whether or not these modifications will be included in > >> the base draft at this point. > >> > >> Thanks, > >> > >> Gonzalo > >> > >> On 21/06/2011 10:58 PM, Marc Petit-Huguenin wrote: > >>> I read the paper and this modification makes sense to me (for example > >>> without this modification a peer that is purely used for routing and > >>> storage purpose, like a bootstrap peer, had to invent a valid, unique, > >>> and useless username just to acquire a certificate). > >>> > >>> So I support its inclusion in draft-ietf-p2psip-base. > >>> > >>> On 06/09/2011 10:47 AM, Diego Suarez wrote: > >>>> I think it would require a (slight) modification in the base document. > >>>> Current P2PSIP certification model is based on a single PKC (including > >>>> both usernames and nodeIDs) that uniquely identifies a user and her > >>>> devices. On the other hand, our model is base on a split > >>>> certification. Devices and users are independent. Each device has its > >>>> own PKC including a nodeID and a PK. Similarly, each user has her own > >>>> PKC including her username and a PK. This approach do not prevent a > >>>> centralized entity (such as an offline CA) to have information related > >>>> to the devices each user (or company, etc.) has registered, but > >>>> permits, among other improvements, a user to be connected to the system > >>>> through devices she has not registered herself such as a phone issued > >>>> by a telco or a fixed phone in a laboratory shared by all the members > >>>> of a research group. > >>> > >>> > >>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: Does this > >>>> model really required modifications in the base document, or can it be > >>>> designed as an extension? (Unfortunately the paper is not freely > >>>> available, so it is difficult to know really what is needed for this). > >>> > >>>> On 06/09/2011 07:31 AM, Diego Suarez wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> I had in mind writing a draft about this, but since I'm running > >>>>>>> out of time, I would like to summarize a new certification model > >>>>>>> for P2PSIP I have been working on, in case it is of interest for > >>>>>>> the group. Further details can be found in paper: > >>>>>>> > >>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, Advantages > >>>>>>> of identity certificate segregation in P2PSIP systems, > >>>>>>> Communications, IET, vol. 5, pp. 879889, Apr. 2011. > >>>>>>> > >>>>>>> > >>>>>>> The idea is to split the certification of users and devices. > >>>>>>> Devices are identified by PKCs including a nodeID and the PK of > >>>>>>> the device, while users are identified by PKCs including a > >>>>>>> username and the PK of the user. Similar models have been used > >>>>>>> before in other communications systems, such as GSM where devices > >>>>>>> and users are separately represented by the international mobile > >>>>>>> equipment identity (IMEI) stored in the phones and the > >>>>>>> international mobile subscriber identity (IMSI) stored in the > >>>>>>> user subscriber identity module (SIM), respectively. > >>>>>>> > >>>>>>> Motivations of this model are: > >>>>>>> > >>>>>>> - Users and devices are different entities performing different > >>>>>>> roles within a P2PSIP system. Devices are nodes of the P2P > >>>>>>> overlay network (represented by a nodeID) that offer services (to > >>>>>>> route messages, to store data, . . .) to the system, while users > >>>>>>> (represented by an username) utilize these services, usually to > >>>>>>> establish media communications using SIP. > >>>>>>> > >>>>>>> - Support for mobility scenarios where a user may be logged at > >>>>>>> different devices at the same time using the same PKC. > >>>>>>> > >>>>>>> - Support several users to be logged in the same device (like a > >>>>>>> fixed phone) at the same time. > >>>>>>> > >>>>>>> - Support for user independent hard-coded devices. > >>>>>>> > >>>>>>> - Interoperability with SIP. SIP certificates are not valid in > >>>>>>> actual P2PSIP since they don't include a nodeID. > >>>>>>> > >>>>>>> cheers > >>>>>>> > >>>>>>> Diego Suárez > >>>>>>> > >>>>>>> > >>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: > >>>>>>>> Unless something major comes up, we plan to request the newest > >>>>>>>> version of the base draft, draft-ietf-p2psip-base-15, be > >>>>>>>> published. I'll put in the request in a week (June 16th or > >>>>>>>> 17th). If there are any further comments from the last call a > >>>>>>>> while ago (or further comments on the comments since then), > >>>>>>>> please send them to the list ASAP. > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk4WPn0ACgkQ9RoMZyVa61eLNQCgi614Bs6sdoajQ+ASRC/36JWk > 5y8An1wyr5TbRVqZ6VTCEnfUfz0GIKud > =viZ4 > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From gonzalo.camarillo@ericsson.com Fri Jul 8 04:37:36 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523DE21F87E7 for ; Fri, 8 Jul 2011 04:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.634 X-Spam-Level: X-Spam-Status: No, score=-106.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UP1KLlWTvzjg for ; Fri, 8 Jul 2011 04:37:35 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 10FA221F87CD for ; Fri, 8 Jul 2011 04:37:34 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-55-4e16ebfdb72f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D4.B2.09774.DFBE61E4; Fri, 8 Jul 2011 13:37:34 +0200 (CEST) Received: from [131.160.36.41] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Fri, 8 Jul 2011 13:37:33 +0200 Message-ID: <4E16EBFD.3000203@ericsson.com> Date: Fri, 8 Jul 2011 14:37:33 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: P2PSIP WG References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E00F7CE.7080402@acm.org> <4E0DB3EC.1040705@ericsson.com> In-Reply-To: <4E0DB3EC.1040705@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 11:37:36 -0000 Hi, I have just requested an IETF LC for this draft. Therefore, these comments will be considered as IETF LC comments. Cheers, Gonzalo On 01/07/2011 2:47 PM, Gonzalo Camarillo wrote: > Hi, > > please, let me know whether or not these modifications will be included > in the base draft at this point. > > Thanks, > > Gonzalo > > On 21/06/2011 10:58 PM, Marc Petit-Huguenin wrote: >> I read the paper and this modification makes sense to me (for example without >> this modification a peer that is purely used for routing and storage purpose, >> like a bootstrap peer, had to invent a valid, unique, and useless username just >> to acquire a certificate). >> >> So I support its inclusion in draft-ietf-p2psip-base. >> >> On 06/09/2011 10:47 AM, Diego Suarez wrote: >>> I think it would require a (slight) modification in the base document. >>> Current P2PSIP certification model is based on a single PKC (including >>> both usernames and nodeIDs) that uniquely identifies a user and her >>> devices. On the other hand, our model is base on a split certification. >>> Devices and users are independent. Each device has its own PKC including >>> a nodeID and a PK. Similarly, each user has her own PKC including her >>> username and a PK. This approach do not prevent a centralized entity >>> (such as an offline CA) to have information related to the devices each >>> user (or company, etc.) has registered, but permits, among other >>> improvements, a user to be connected to the system through devices she >>> has not registered herself such as a phone issued by a telco or a fixed >>> phone in a laboratory shared by all the members of a research group. >> >> >>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: >>> Does this model really required modifications in the base document, or can it be >>> designed as an extension? (Unfortunately the paper is not freely available, so >>> it is difficult to know really what is needed for this). >> >>> On 06/09/2011 07:31 AM, Diego Suarez wrote: >>>>>> Hi, >>>>>> >>>>>> I had in mind writing a draft about this, but since I'm running out of >>>>>> time, I would like to summarize a new certification model for P2PSIP I >>>>>> have been working on, in case it is of interest for the group. >>>>>> Further details can be found in paper: >>>>>> >>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, Advantages of >>>>>> identity certificate segregation in P2PSIP systems, Communications, >>>>>> IET, vol. 5, pp. 879889, Apr. 2011. >>>>>> >>>>>> >>>>>> The idea is to split the certification of users and devices. Devices are >>>>>> identified by PKCs including a nodeID and the PK of the device, while >>>>>> users are identified by PKCs including a username and the PK of the >>>>>> user. Similar models have been used before in other communications >>>>>> systems, such as GSM where devices and users are separately represented >>>>>> by the international mobile equipment identity (IMEI) stored in the >>>>>> phones and the international mobile subscriber identity (IMSI) stored in >>>>>> the user subscriber identity module (SIM), respectively. >>>>>> >>>>>> Motivations of this model are: >>>>>> >>>>>> - Users and devices are different entities performing different >>>>>> roles within a P2PSIP system. Devices are nodes of the P2P >>>>>> overlay network (represented by a nodeID) that offer services >>>>>> (to route messages, to store data, . . .) to the system, while >>>>>> users (represented by an username) utilize these services, >>>>>> usually to establish media communications using SIP. >>>>>> >>>>>> - Support for mobility scenarios where a user may be logged at different >>>>>> devices at the same time using the same PKC. >>>>>> >>>>>> - Support several users to be logged in the same device (like a fixed >>>>>> phone) at the same time. >>>>>> >>>>>> - Support for user independent hard-coded devices. >>>>>> >>>>>> - Interoperability with SIP. SIP certificates are not valid in actual >>>>>> P2PSIP since they don't include a nodeID. >>>>>> >>>>>> cheers >>>>>> >>>>>> Diego Suárez >>>>>> >>>>>> >>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: >>>>>>> Unless something major comes up, we plan to request the newest version >>>>>>> of the base draft, draft-ietf-p2psip-base-15, be published. I'll put >>>>>>> in the request in a week (June 16th or 17th). If there are any further >>>>>>> comments from the last call a while ago (or further comments on the >>>>>>> comments since then), please send them to the list ASAP. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> David (as chair) >>>>>>> _______________________________________________ >>>>>>> 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 bbl@lowekamp.net Fri Jul 8 06:40:32 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AC421F8ACD for ; Fri, 8 Jul 2011 06:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.596 X-Spam-Level: X-Spam-Status: No, score=0.596 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpYEDsqQ9mPZ for ; Fri, 8 Jul 2011 06:40:31 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A202C21F8ACC for ; Fri, 8 Jul 2011 06:40:30 -0700 (PDT) Received: by eye13 with SMTP id 13so773977eye.31 for ; Fri, 08 Jul 2011 06:40:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.5.74 with SMTP id 50mr589809eek.141.1310132429463; Fri, 08 Jul 2011 06:40:29 -0700 (PDT) Received: by 10.14.189.14 with HTTP; Fri, 8 Jul 2011 06:40:29 -0700 (PDT) In-Reply-To: <1310123712.22737.73.camel@toedo> References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E0E4DBE.5060302@acm.org> <1309624099.5232.23.camel@santeles> <4E0F4F8D.9080108@acm.org> <1309773089.5716.43.camel@santeles> <1310123712.22737.73.camel@toedo> Date: Fri, 8 Jul 2011 09:40:29 -0400 Message-ID: From: Bruce Lowekamp To: Diego Suarez Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 13:40:32 -0000 On Fri, Jul 8, 2011 at 7:15 AM, Diego Suarez wrote: > Hi Bruce, > > Answers inline. > > > On Thu, 2011-07-07 at 22:24 -0400, Bruce Lowekamp wrote: >> Diego, >> >> Please take some time understanding how real clients work in reload. >> Then just have the virtual clients use the same messages. =C2=A0The virt= ual >> clients use their own nodeids, not the host's nodeid. =C2=A0It all works >> fine. > > I agree, this works fine for clients, but, from my point of view, it > does not for several users connected to the same device. The fact that > clients ( or virtual clients ) use their own nodeIDs and not the host's > nodeIDs is precisely what I see as the problem of using virtual clients > to allow several users to be connected to the same device. Since virtual > clients are not using the device's nodeID, they cannot perform > operations ( like NODE-MATCH or USER-NODE-MATCH accesses) from that > device like they should if they were actually connected to the system > from it. As I've said in my previous mail, they only way I see to allow > so is the device adding an extra signature to the message, with the > already commented problem of two users and two nodeIDs in it. > Since a client is using its own nodeid, NODE-MATCH and USER-NODE-MATCH are performed using the client's nodeid. In the case of the sip usage, it's done using USER-NODE-MATCH. This is the client's rfc822Name and the client's nodeid. In that registration, it stores a destination list that starts with the peer and finishes with the client's nodeid (in most cases, would be only these two entries). This is how clients are supported in reload and for the sip usage. > >> I don't see a real problem with a host node having an >> "admin@example.com" or "node12345@example.com" name attached to it. >> Routers pretty much always have DNS names that are descriptive of >> where they are to admins, even though routing protocols don't require >> it. > > Neither do I except for cases, like the presented before, of several > users in the same device. > >> >> Regarding certs, 6072 has the following text: >> >> =C2=A0 =C2=A0If the certificate is signed by a trusted certification aut= hority, >> =C2=A0 =C2=A0and one of the names in the SubjectAltName matches the orig= inal URI, >> =C2=A0 =C2=A0then this certificate MAY be used, but only for exactly the= original >> >> It's been awhile since I've looked at that in detail, but it appears >> to me that a reload cert could be perfectly valid for use with 6072 as >> long as it has the sip uri in it. =C2=A0Though I'm not immediately >> convinced that this is that useful, regardless. > > The problem is not with RELOAD certs being used in SIP systems, but with > SIP certs being used in RELOAD systems. Since SIP certs do not have > nodeIDs, they are not valid in RELOAD. > > cheers > >> >> Bruce >> >> >> >> On Mon, Jul 4, 2011 at 5:51 AM, Diego Suarez wrot= e: >> > Hi, >> > >> > Actually, I see this "virtual client" method more complicated and >> > confusing than splitting the identities of users and devices. >> > >> > With this model, you are gonna have a device identified by a PKC that >> > includes a username and a nodeID acting as a peer, but only using its >> > nodeID. And several users connected to the device as virtual clients >> > identified by PKCs including a username and a nodeID, but only using >> > their usernames. >> > >> > One of the more confusing things I see here is the access control. >> > Imagine we have a device, with PKC ( # user =3D device1, nodeID =3D 10= 0 # ) >> > and two users ( # user =3D user1, nodeID =3D 200 # and # user =3D user= 2, >> > nodeID =3D 300 # ) connected to that device acting as virtual clients. >> > >> > If user1 wants to perform a USER-NODE-MATCH access control related to >> > the peer she is operating from ( actually the nodeID =3D 100 nor the >> > virtual one with nodeID =3D 200 ) and her username ( user =3D user1 ),= she >> > is gonna have to create a request signed with her PKC and the PKC of t= he >> > device. This request need to be doubled signed ( by the peer to grant >> > the nodeID =3D 100 and by the user to grant the user =3D user 1 ). How= ever, >> > this double signed request intended for nodeID =3D 100 and user =3D us= er1 is >> > gonna include two users =3D device1 and user1 and two nodeID =3D 100 a= nd >> > 200. This is confusing for me. Therefore, from my point of view, it >> > makes sense to me to remove the username from the device and the node >> > from the users since we are not using them and confuse the access >> > control. >> > >> > Also, splitting identities have another advantages like greater >> > interoperability with traditional SIP systems. Imagine a company runni= ng >> > a SIP system, where users are identified by a PKC including a SIP >> > username, that wants to extend its coverage interconnecting it with a >> > P2PSIP system. With the actual certification model, SIP PKCs are not >> > valid for the new P2PSIP side of the system. All the users have to be >> > re-certificated to have a PKC including the old SIP username and a >> > nodeID. However, with the split proposal SIP certificates are still >> > valid in the P2PSIP side of the system and interoperable within the tw= o >> > networks, and only the devices intended to be used in the P2PSIP side >> > have to be certified with a nodeID. >> > >> > >> > cheers >> > >> > >> > >> > >> > On Sat, 2011-07-02 at 16:53 -0400, Bruce Lowekamp wrote: >> >> With the current definition of the protocol, split routing IDs and >> >> user IDs can be achieved by having the host node participate as a pee= r >> >> (or as a client, honestly) using its own cert and the attached users >> >> represented as virtual clients, i.e. generate messages as if they are >> >> on separate nodes attached to the host node as a client. >> >> >> >> If you wanted to implement it "natively," other than the >> >> USER-NODE-MATCH, as mentioned before, I can only find two changes tha= t >> >> would need to be made to support split identities. >> >> >> >> For processing StoreReq: >> >> o =C2=A0For original (non-replica) stores, the StoreReq is signed by = a >> >> =C2=A0 =C2=A0 =C2=A0 credential which is authorized to write this kin= d at this >> >> =C2=A0 =C2=A0 =C2=A0 Resource-Id. =C2=A0If this check fails, the requ= est MUST be rejected >> >> =C2=A0 =C2=A0 =C2=A0 with an Error_Forbidden error. >> >> >> >> and the definition of credential in beginning of 10.3. >> >> >> >> >> >> Assuming that there is not something I'm missing with using virtual >> >> clients, I'd rather not make any changes. =C2=A0This is a complicated >> >> enough protocol, and I think adding special cases for something like >> >> split identities just makes it more complicated. =C2=A0If any changes= were >> >> made, I would think it should be something to make it possible for an >> >> extension to specify the change, but as long as the current protocol >> >> is capable of handling the functional goals, I'd rather no changes be >> >> made. >> >> >> >> Bruce >> >> >> >> >> >> >> >> >> >> On Sat, Jul 2, 2011 at 1:04 PM, Marc Petit-Huguenin wrote: >> >> > -----BEGIN PGP SIGNED MESSAGE----- >> >> > Hash: SHA1 >> >> > >> >> > On 07/02/2011 09:28 AM, Diego Suarez wrote: >> >> >> Hi, >> >> >> >> >> >>>From my point of view, in this case the user has to both prove she= is in >> >> >> possession of the PKC that includes the required username and also= prove >> >> >> she is operating from the required node. However, modifying the >> >> >> SignerIdentity to include multiple identities ( the user and the >> >> >> device ) would not really prove that since only one signature coul= d be >> >> >> included (either the user's signature or the device's one). >> >> >> >> >> >> Therefore, I'd modify the SecurityBlock instead to allow the inclu= sion >> >> >> of more than only one signature. >> >> >> >> >> >> For this case, the securityBlock would include two signatures. One= with >> >> >> the SignerIdentity of the user and the signature of the user's PKC >> >> >> (including the username ) and another with the SignerIdentity of t= he >> >> >> device and the signature of the device's PKC ( including the nodeI= D). >> >> > >> >> > Right, something like this: >> >> > >> >> > struct { >> >> > =C2=A0 GenericCertificate certificates<0..2^16-1>; >> >> > =C2=A0 Signature =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0signatures<0..2^= 16-1>; >> >> > =C2=A0 } SecurityBlock; >> >> > >> >> > Note that StoredData also needs to be modified: >> >> > >> >> > struct { >> >> > =C2=A0 uint32 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0length; >> >> > =C2=A0 uint64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0storage_time; >> >> > =C2=A0 uint32 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lifetime; >> >> > =C2=A0 StoredDataValue value; >> >> > =C2=A0 Signature =C2=A0 =C2=A0 =C2=A0 signatures<0..2^16-1>; >> >> > =C2=A0 } StoredData; >> >> > >> >> >> >> >> >> cheers >> >> >> >> >> >> >> >> >> On Fri, 2011-07-01 at 15:44 -0700, Marc Petit-Huguenin wrote: >> >> >> Hi Diego, >> >> >> >> >> >> How does this work with an access control policy like USER-NODE-MA= TCH, which >> >> >> requires both a Node-ID and a username in the SignerIdentity? =C2= =A0If the Node-ID >> >> >> and the username are in separate certificates, wouldn't that requi= re to extend >> >> >> the SignerIdentity structure to store multiple identities? >> >> >> >> >> >> Thanks. >> >> >> >> >> >> On 06/09/2011 10:47 AM, Diego Suarez wrote: >> >> >>>>> I think it would require a (slight) modification in the base do= cument. >> >> >>>>> Current P2PSIP certification model is based on a single PKC (in= cluding >> >> >>>>> both usernames and nodeIDs) that uniquely identifies a user and= her >> >> >>>>> devices. On the other hand, our model is base on a split certif= ication. >> >> >>>>> Devices and users are independent. Each device has its own PKC = including >> >> >>>>> a nodeID and a PK. Similarly, each user has her own PKC includi= ng her >> >> >>>>> username and a PK. This approach do not prevent a centralized e= ntity >> >> >>>>> (such as an offline CA) to have information related to the devi= ces each >> >> >>>>> user (or company, etc.) has registered, but permits, among othe= r >> >> >>>>> improvements, a user to be connected to the system through devi= ces she >> >> >>>>> has not registered herself such as a phone issued by a telco or= a fixed >> >> >>>>> phone in a laboratory shared by all the members of a research g= roup. >> >> >>>>> >> >> >>>>> >> >> >>>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: >> >> >>>>> Does this model really required modifications in the base docum= ent, or can it be >> >> >>>>> designed as an extension? =C2=A0(Unfortunately the paper is not= freely available, so >> >> >>>>> it is difficult to know really what is needed for this). >> >> >>>>> >> >> >>>>> On 06/09/2011 07:31 AM, Diego Suarez wrote: >> >> >>>>>>>> Hi, >> >> >>>>>>>> >> >> >>>>>>>> I had in mind writing a draft about this, but since I'm runn= ing out of >> >> >>>>>>>> time, I would like to summarize a new certification model fo= r P2PSIP I >> >> >>>>>>>> have been working on, in case it is of interest for the grou= p. >> >> >>>>>>>> Further details can be found in paper: >> >> >>>>>>>> >> >> >>>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, =C2=A0Ad= vantages of >> >> >>>>>>>> identity certificate segregation in P2PSIP systems, =C2=A0Co= mmunications, >> >> >>>>>>>> IET, vol. 5, pp. 879 889, Apr. 2011. >> >> >>>>>>>> >> >> >>>>>>>> >> >> >>>>>>>> The idea is to split the certification of users and devices.= Devices are >> >> >>>>>>>> identified by PKCs including a nodeID and the PK of the devi= ce, while >> >> >>>>>>>> users are identified by PKCs including a username and the PK= of the >> >> >>>>>>>> user. Similar models have been used before in other communic= ations >> >> >>>>>>>> systems, such as GSM where devices and users are separately = represented >> >> >>>>>>>> by the international mobile equipment identity (IMEI) stored= in the >> >> >>>>>>>> phones and the international mobile subscriber identity (IMS= I) stored in >> >> >>>>>>>> the user subscriber identity module (SIM), respectively. >> >> >>>>>>>> >> >> >>>>>>>> Motivations of this model are: >> >> >>>>>>>> >> >> >>>>>>>> - Users and devices are different entities performing differ= ent >> >> >>>>>>>> roles within a P2PSIP system. Devices are nodes of the P2P >> >> >>>>>>>> overlay network (represented by a nodeID) that offer service= s >> >> >>>>>>>> (to route messages, to store data, . . .) to the system, whi= le >> >> >>>>>>>> users (represented by an username) utilize these services, >> >> >>>>>>>> usually to establish media communications using SIP. >> >> >>>>>>>> >> >> >>>>>>>> - Support for mobility scenarios where a user may be logged = at different >> >> >>>>>>>> devices at the same time using the same PKC. >> >> >>>>>>>> >> >> >>>>>>>> - Support several users to be logged in the same device (lik= e a fixed >> >> >>>>>>>> phone) at the same time. >> >> >>>>>>>> >> >> >>>>>>>> - Support for user independent hard-coded devices. >> >> >>>>>>>> >> >> >>>>>>>> - Interoperability with SIP. SIP certificates are not valid = in actual >> >> >>>>>>>> P2PSIP since they don't include a nodeID. >> >> >>>>>>>> >> >> >>>>>>>> cheers >> >> >>>>>>>> >> >> >>>>>>>> Diego Su=C3=A1rez >> >> >>>>>>>> >> >> >>>>>>>> >> >> >>>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: >> >> >>>>>>>>> Unless something major comes up, we plan to request the new= est version >> >> >>>>>>>>> of the base draft, draft-ietf-p2psip-base-15, be published.= I'll put >> >> >>>>>>>>> in the request in a week (June 16th or 17th). If there are = any further >> >> >>>>>>>>> comments from the last call a while ago (or further comment= s on the >> >> >>>>>>>>> comments since then), please send them to the list ASAP. >> >> >>>>>>>>> >> >> >>>>>>>>> Thanks, >> >> >>>>>>>>> >> >> >>>>>>>>> David (as chair) >> >> > >> >> > - -- >> >> > Marc Petit-Huguenin >> >> > Personal email: marc@petit-huguenin.org >> >> > Professional email: petithug@acm.org >> >> > Blog: http://blog.marc.petit-huguenin.org >> >> > -----BEGIN PGP SIGNATURE----- >> >> > Version: GnuPG v1.4.11 (GNU/Linux) >> >> > >> >> > iEYEARECAAYFAk4PT4sACgkQ9RoMZyVa61dPvACeITly6/Zqumz4e4ZrAn1yGI4x >> >> > ay4AoJ11vmCRDkL8pXuN71qaZXhw5JTZ >> >> > =3DTp+D >> >> > -----END PGP SIGNATURE----- >> >> > _______________________________________________ >> >> > P2PSIP mailing list >> >> > P2PSIP@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/p2psip >> >> > >> > >> > >> > > > > From iesg-secretary@ietf.org Fri Jul 8 08:10:16 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0AF21F8B16; Fri, 8 Jul 2011 08:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEgKsLBX57jx; Fri, 8 Jul 2011 08:10:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E7A21F8874; Fri, 8 Jul 2011 08:10:15 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110708150954.460.63430.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 08:09:54 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] Last Call: (REsource LOcation And Discovery (RELOAD) Base Protocol) to Proposed Standard X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 08 Jul 2011 15:10:16 -0000 The IESG has received a request from the Peer-to-Peer Session Initiation Protocol WG (p2psip) to consider the following document: - 'REsource LOcation And Discovery (RELOAD) Base Protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. In particular, this document contains normative references to documents of lower maturity levels. Two of those documents are not in the downref registry: RFC 6091 and RFC 6234. The IESG is interested in community feedback on whether these downward references are appropriate. Abstract This specification 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-p2psip-base/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-p2psip-base/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1191/ From loopp2psip@gmail.com Fri Jul 8 09:53:10 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0A521F8BC2 for ; Fri, 8 Jul 2011 09:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[AWL=-1.753, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VOd4YjNGUHf for ; Fri, 8 Jul 2011 09:53:09 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE0A721F8BC0 for ; Fri, 8 Jul 2011 09:53:08 -0700 (PDT) Received: by wwe5 with SMTP id 5so1450471wwe.13 for ; Fri, 08 Jul 2011 09:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=fnfNycZxVEQdA8e+jOTrY3LCDK67bjvnQ7Sw56ISJrU=; b=dXQa6a64g5YNIMEDauXhC0gIer1tumbWOz/0hi4QT6zx4EtObMIlDuxIX/lY1STpzR Lwf1FZe+6BGXjAosdQT1dKD7wUF6N52MwR7y/Eq/Z59jkbmrB653dW+hV0dVADMbPiF5 gzrSwzWWLot7a0swZoHrbNXYK6HoStNNW3Cr8= Received: by 10.216.62.203 with SMTP id y53mr1875056wec.108.1310143987522; Fri, 08 Jul 2011 09:53:07 -0700 (PDT) Received: from [192.168.1.3] (96.134.16.95.dynamic.jazztel.es [95.16.134.96]) by mx.google.com with ESMTPS id l53sm5459266weq.47.2011.07.08.09.53.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jul 2011 09:53:05 -0700 (PDT) From: Diego Suarez To: Bruce Lowekamp In-Reply-To: References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E0E4DBE.5060302@acm.org> <1309624099.5232.23.camel@santeles> <4E0F4F8D.9080108@acm.org> <1309773089.5716.43.camel@santeles> <1310123712.22737.73.camel@toedo> Content-Type: text/plain; charset="UTF-8" Date: Fri, 08 Jul 2011 18:53:02 +0200 Message-ID: <1310143982.6132.75.camel@santeles> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 16:53:10 -0000 Hi, I have the impression I am not explaining myself well. I am not saying that clients in RELOAD do not work well, I am just saying that I do not see how they can be used to allow several users to be connected to the same the device; at least not with full functionalities. Lets go back to the example: Imagine we have a device, with PKC ( # user = device1, nodeID = 100 # ) and two users ( # user = user1, nodeID = 200 # and # user = user2, nodeID = 300 # ) connected to that device acting as virtual clients. As you have said, during registration, users store a destination list that start with the device ( nodeID = 100 ) and finishes with the client's nodeID ( nodeID = 200 for user1 and nodeID = 300 for user2). This works well, and allows other peers of the system to reach them. However, the problem is with the access control. Being virtual clients, users can perform NODE-USER-MATCH accesses related to their client's nodeIDs and usernames: 200-user1 for user1 and 300-user2 for user2. Nevertheless, this is not what we want in this case. In this case, where user1 and user2 are supposed to be connected to the same device (nodeID = 100), they should be allowed to perform NODE-USER-MATCH accesses related to this device and their usernames: 100-user1 for user1 and 100-user2 for user2. Because, if not, we are not really implementing this functionality. In order to be fully implemented, several users connected to the same device should have the same functionalities that a single user connected to this device has, and this is not the case using virtual clients. cheers On Fri, 2011-07-08 at 09:40 -0400, Bruce Lowekamp wrote: > On Fri, Jul 8, 2011 at 7:15 AM, Diego Suarez wrote: > > Hi Bruce, > > > > Answers inline. > > > > > > On Thu, 2011-07-07 at 22:24 -0400, Bruce Lowekamp wrote: > >> Diego, > >> > >> Please take some time understanding how real clients work in reload. > >> Then just have the virtual clients use the same messages. The virtual > >> clients use their own nodeids, not the host's nodeid. It all works > >> fine. > > > > I agree, this works fine for clients, but, from my point of view, it > > does not for several users connected to the same device. The fact that > > clients ( or virtual clients ) use their own nodeIDs and not the host's > > nodeIDs is precisely what I see as the problem of using virtual clients > > to allow several users to be connected to the same device. Since virtual > > clients are not using the device's nodeID, they cannot perform > > operations ( like NODE-MATCH or USER-NODE-MATCH accesses) from that > > device like they should if they were actually connected to the system > > from it. As I've said in my previous mail, they only way I see to allow > > so is the device adding an extra signature to the message, with the > > already commented problem of two users and two nodeIDs in it. > > > > Since a client is using its own nodeid, NODE-MATCH and USER-NODE-MATCH > are performed using the client's nodeid. In the case of the sip > usage, it's done using USER-NODE-MATCH. This is the client's > rfc822Name and the client's nodeid. In that registration, it stores a > destination list that starts with the peer and finishes with the > client's nodeid (in most cases, would be only these two entries). > This is how clients are supported in reload and for the sip usage. > > > > >> I don't see a real problem with a host node having an > >> "admin@example.com" or "node12345@example.com" name attached to it. > >> Routers pretty much always have DNS names that are descriptive of > >> where they are to admins, even though routing protocols don't require > >> it. > > > > Neither do I except for cases, like the presented before, of several > > users in the same device. > > > >> > >> Regarding certs, 6072 has the following text: > >> > >> If the certificate is signed by a trusted certification authority, > >> and one of the names in the SubjectAltName matches the original URI, > >> then this certificate MAY be used, but only for exactly the original > >> > >> It's been awhile since I've looked at that in detail, but it appears > >> to me that a reload cert could be perfectly valid for use with 6072 as > >> long as it has the sip uri in it. Though I'm not immediately > >> convinced that this is that useful, regardless. > > > > The problem is not with RELOAD certs being used in SIP systems, but with > > SIP certs being used in RELOAD systems. Since SIP certs do not have > > nodeIDs, they are not valid in RELOAD. > > > > cheers > > > >> > >> Bruce > >> > >> > >> > >> On Mon, Jul 4, 2011 at 5:51 AM, Diego Suarez wrote: > >> > Hi, > >> > > >> > Actually, I see this "virtual client" method more complicated and > >> > confusing than splitting the identities of users and devices. > >> > > >> > With this model, you are gonna have a device identified by a PKC that > >> > includes a username and a nodeID acting as a peer, but only using its > >> > nodeID. And several users connected to the device as virtual clients > >> > identified by PKCs including a username and a nodeID, but only using > >> > their usernames. > >> > > >> > One of the more confusing things I see here is the access control. > >> > Imagine we have a device, with PKC ( # user = device1, nodeID = 100 # ) > >> > and two users ( # user = user1, nodeID = 200 # and # user = user2, > >> > nodeID = 300 # ) connected to that device acting as virtual clients. > >> > > >> > If user1 wants to perform a USER-NODE-MATCH access control related to > >> > the peer she is operating from ( actually the nodeID = 100 nor the > >> > virtual one with nodeID = 200 ) and her username ( user = user1 ), she > >> > is gonna have to create a request signed with her PKC and the PKC of the > >> > device. This request need to be doubled signed ( by the peer to grant > >> > the nodeID = 100 and by the user to grant the user = user 1 ). However, > >> > this double signed request intended for nodeID = 100 and user = user1 is > >> > gonna include two users = device1 and user1 and two nodeID = 100 and > >> > 200. This is confusing for me. Therefore, from my point of view, it > >> > makes sense to me to remove the username from the device and the node > >> > from the users since we are not using them and confuse the access > >> > control. > >> > > >> > Also, splitting identities have another advantages like greater > >> > interoperability with traditional SIP systems. Imagine a company running > >> > a SIP system, where users are identified by a PKC including a SIP > >> > username, that wants to extend its coverage interconnecting it with a > >> > P2PSIP system. With the actual certification model, SIP PKCs are not > >> > valid for the new P2PSIP side of the system. All the users have to be > >> > re-certificated to have a PKC including the old SIP username and a > >> > nodeID. However, with the split proposal SIP certificates are still > >> > valid in the P2PSIP side of the system and interoperable within the two > >> > networks, and only the devices intended to be used in the P2PSIP side > >> > have to be certified with a nodeID. > >> > > >> > > >> > cheers > >> > > >> > > >> > > >> > > >> > On Sat, 2011-07-02 at 16:53 -0400, Bruce Lowekamp wrote: > >> >> With the current definition of the protocol, split routing IDs and > >> >> user IDs can be achieved by having the host node participate as a peer > >> >> (or as a client, honestly) using its own cert and the attached users > >> >> represented as virtual clients, i.e. generate messages as if they are > >> >> on separate nodes attached to the host node as a client. > >> >> > >> >> If you wanted to implement it "natively," other than the > >> >> USER-NODE-MATCH, as mentioned before, I can only find two changes that > >> >> would need to be made to support split identities. > >> >> > >> >> For processing StoreReq: > >> >> o For original (non-replica) stores, the StoreReq is signed by a > >> >> credential which is authorized to write this kind at this > >> >> Resource-Id. If this check fails, the request MUST be rejected > >> >> with an Error_Forbidden error. > >> >> > >> >> and the definition of credential in beginning of 10.3. > >> >> > >> >> > >> >> Assuming that there is not something I'm missing with using virtual > >> >> clients, I'd rather not make any changes. This is a complicated > >> >> enough protocol, and I think adding special cases for something like > >> >> split identities just makes it more complicated. If any changes were > >> >> made, I would think it should be something to make it possible for an > >> >> extension to specify the change, but as long as the current protocol > >> >> is capable of handling the functional goals, I'd rather no changes be > >> >> made. > >> >> > >> >> Bruce > >> >> > >> >> > >> >> > >> >> > >> >> On Sat, Jul 2, 2011 at 1:04 PM, Marc Petit-Huguenin wrote: > >> >> > -----BEGIN PGP SIGNED MESSAGE----- > >> >> > Hash: SHA1 > >> >> > > >> >> > On 07/02/2011 09:28 AM, Diego Suarez wrote: > >> >> >> Hi, > >> >> >> > >> >> >>>From my point of view, in this case the user has to both prove she is in > >> >> >> possession of the PKC that includes the required username and also prove > >> >> >> she is operating from the required node. However, modifying the > >> >> >> SignerIdentity to include multiple identities ( the user and the > >> >> >> device ) would not really prove that since only one signature could be > >> >> >> included (either the user's signature or the device's one). > >> >> >> > >> >> >> Therefore, I'd modify the SecurityBlock instead to allow the inclusion > >> >> >> of more than only one signature. > >> >> >> > >> >> >> For this case, the securityBlock would include two signatures. One with > >> >> >> the SignerIdentity of the user and the signature of the user's PKC > >> >> >> (including the username ) and another with the SignerIdentity of the > >> >> >> device and the signature of the device's PKC ( including the nodeID). > >> >> > > >> >> > Right, something like this: > >> >> > > >> >> > struct { > >> >> > GenericCertificate certificates<0..2^16-1>; > >> >> > Signature signatures<0..2^16-1>; > >> >> > } SecurityBlock; > >> >> > > >> >> > Note that StoredData also needs to be modified: > >> >> > > >> >> > struct { > >> >> > uint32 length; > >> >> > uint64 storage_time; > >> >> > uint32 lifetime; > >> >> > StoredDataValue value; > >> >> > Signature signatures<0..2^16-1>; > >> >> > } StoredData; > >> >> > > >> >> >> > >> >> >> cheers > >> >> >> > >> >> >> > >> >> >> On Fri, 2011-07-01 at 15:44 -0700, Marc Petit-Huguenin wrote: > >> >> >> Hi Diego, > >> >> >> > >> >> >> How does this work with an access control policy like USER-NODE-MATCH, which > >> >> >> requires both a Node-ID and a username in the SignerIdentity? If the Node-ID > >> >> >> and the username are in separate certificates, wouldn't that require to extend > >> >> >> the SignerIdentity structure to store multiple identities? > >> >> >> > >> >> >> Thanks. > >> >> >> > >> >> >> On 06/09/2011 10:47 AM, Diego Suarez wrote: > >> >> >>>>> I think it would require a (slight) modification in the base document. > >> >> >>>>> Current P2PSIP certification model is based on a single PKC (including > >> >> >>>>> both usernames and nodeIDs) that uniquely identifies a user and her > >> >> >>>>> devices. On the other hand, our model is base on a split certification. > >> >> >>>>> Devices and users are independent. Each device has its own PKC including > >> >> >>>>> a nodeID and a PK. Similarly, each user has her own PKC including her > >> >> >>>>> username and a PK. This approach do not prevent a centralized entity > >> >> >>>>> (such as an offline CA) to have information related to the devices each > >> >> >>>>> user (or company, etc.) has registered, but permits, among other > >> >> >>>>> improvements, a user to be connected to the system through devices she > >> >> >>>>> has not registered herself such as a phone issued by a telco or a fixed > >> >> >>>>> phone in a laboratory shared by all the members of a research group. > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: > >> >> >>>>> Does this model really required modifications in the base document, or can it be > >> >> >>>>> designed as an extension? (Unfortunately the paper is not freely available, so > >> >> >>>>> it is difficult to know really what is needed for this). > >> >> >>>>> > >> >> >>>>> On 06/09/2011 07:31 AM, Diego Suarez wrote: > >> >> >>>>>>>> Hi, > >> >> >>>>>>>> > >> >> >>>>>>>> I had in mind writing a draft about this, but since I'm running out of > >> >> >>>>>>>> time, I would like to summarize a new certification model for P2PSIP I > >> >> >>>>>>>> have been working on, in case it is of interest for the group. > >> >> >>>>>>>> Further details can be found in paper: > >> >> >>>>>>>> > >> >> >>>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, Advantages of > >> >> >>>>>>>> identity certificate segregation in P2PSIP systems, Communications, > >> >> >>>>>>>> IET, vol. 5, pp. 879 889, Apr. 2011. > >> >> >>>>>>>> > >> >> >>>>>>>> > >> >> >>>>>>>> The idea is to split the certification of users and devices. Devices are > >> >> >>>>>>>> identified by PKCs including a nodeID and the PK of the device, while > >> >> >>>>>>>> users are identified by PKCs including a username and the PK of the > >> >> >>>>>>>> user. Similar models have been used before in other communications > >> >> >>>>>>>> systems, such as GSM where devices and users are separately represented > >> >> >>>>>>>> by the international mobile equipment identity (IMEI) stored in the > >> >> >>>>>>>> phones and the international mobile subscriber identity (IMSI) stored in > >> >> >>>>>>>> the user subscriber identity module (SIM), respectively. > >> >> >>>>>>>> > >> >> >>>>>>>> Motivations of this model are: > >> >> >>>>>>>> > >> >> >>>>>>>> - Users and devices are different entities performing different > >> >> >>>>>>>> roles within a P2PSIP system. Devices are nodes of the P2P > >> >> >>>>>>>> overlay network (represented by a nodeID) that offer services > >> >> >>>>>>>> (to route messages, to store data, . . .) to the system, while > >> >> >>>>>>>> users (represented by an username) utilize these services, > >> >> >>>>>>>> usually to establish media communications using SIP. > >> >> >>>>>>>> > >> >> >>>>>>>> - Support for mobility scenarios where a user may be logged at different > >> >> >>>>>>>> devices at the same time using the same PKC. > >> >> >>>>>>>> > >> >> >>>>>>>> - Support several users to be logged in the same device (like a fixed > >> >> >>>>>>>> phone) at the same time. > >> >> >>>>>>>> > >> >> >>>>>>>> - Support for user independent hard-coded devices. > >> >> >>>>>>>> > >> >> >>>>>>>> - Interoperability with SIP. SIP certificates are not valid in actual > >> >> >>>>>>>> P2PSIP since they don't include a nodeID. > >> >> >>>>>>>> > >> >> >>>>>>>> cheers > >> >> >>>>>>>> > >> >> >>>>>>>> Diego Suárez > >> >> >>>>>>>> > >> >> >>>>>>>> > >> >> >>>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: > >> >> >>>>>>>>> Unless something major comes up, we plan to request the newest version > >> >> >>>>>>>>> of the base draft, draft-ietf-p2psip-base-15, be published. I'll put > >> >> >>>>>>>>> in the request in a week (June 16th or 17th). If there are any further > >> >> >>>>>>>>> comments from the last call a while ago (or further comments on the > >> >> >>>>>>>>> comments since then), please send them to the list ASAP. > >> >> >>>>>>>>> > >> >> >>>>>>>>> Thanks, > >> >> >>>>>>>>> > >> >> >>>>>>>>> David (as chair) > >> >> > > >> >> > - -- > >> >> > Marc Petit-Huguenin > >> >> > Personal email: marc@petit-huguenin.org > >> >> > Professional email: petithug@acm.org > >> >> > Blog: http://blog.marc.petit-huguenin.org > >> >> > -----BEGIN PGP SIGNATURE----- > >> >> > Version: GnuPG v1.4.11 (GNU/Linux) > >> >> > > >> >> > iEYEARECAAYFAk4PT4sACgkQ9RoMZyVa61dPvACeITly6/Zqumz4e4ZrAn1yGI4x > >> >> > ay4AoJ11vmCRDkL8pXuN71qaZXhw5JTZ > >> >> > =Tp+D > >> >> > -----END PGP SIGNATURE----- > >> >> > _______________________________________________ > >> >> > P2PSIP mailing list > >> >> > P2PSIP@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/p2psip > >> >> > > >> > > >> > > >> > > > > > > > From bbl@lowekamp.net Fri Jul 8 16:06:35 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DF921F8C7B for ; Fri, 8 Jul 2011 16:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.764 X-Spam-Level: X-Spam-Status: No, score=0.764 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fU0n9PFGOlkp for ; Fri, 8 Jul 2011 16:06:34 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B867E21F8C71 for ; Fri, 8 Jul 2011 16:06:33 -0700 (PDT) Received: by ewy19 with SMTP id 19so934773ewy.31 for ; Fri, 08 Jul 2011 16:06:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.5.74 with SMTP id 50mr730475eek.141.1310166392317; Fri, 08 Jul 2011 16:06:32 -0700 (PDT) Received: by 10.14.189.14 with HTTP; Fri, 8 Jul 2011 16:06:32 -0700 (PDT) In-Reply-To: <1310143982.6132.75.camel@santeles> References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E0E4DBE.5060302@acm.org> <1309624099.5232.23.camel@santeles> <4E0F4F8D.9080108@acm.org> <1309773089.5716.43.camel@santeles> <1310123712.22737.73.camel@toedo> <1310143982.6132.75.camel@santeles> Date: Fri, 8 Jul 2011 19:06:32 -0400 Message-ID: From: Bruce Lowekamp To: Diego Suarez Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2011 23:06:35 -0000 inline On Fri, Jul 8, 2011 at 12:53 PM, Diego Suarez wrote: > Hi, > > I have the impression I am not explaining myself well. I am not saying > that clients in RELOAD do not work well, I am just saying that I do not > see how they can be used to allow several users to be connected to the > same the device; at least not with full functionalities. > > Lets go back to the example: > Imagine we have a device, with PKC ( # user =3D device1, nodeID =3D 100 #= ) > and two users ( # user =3D user1, nodeID =3D 200 # and # user =3D user2, > nodeID =3D 300 # ) connected to that device acting as virtual clients. > > As you have said, during registration, users store a destination list > that start with the device ( nodeID =3D 100 ) and finishes with the > client's nodeID ( nodeID =3D 200 for user1 and nodeID =3D 300 for user2). > This works well, and allows other peers of the system to reach them. > > However, the problem is with the access control. Being virtual clients, > users can perform NODE-USER-MATCH accesses related to their client's > nodeIDs and usernames: 200-user1 for user1 and 300-user2 for user2. > Nevertheless, this is not what we want in this case. In this case, where > user1 and user2 are supposed to be connected to the same device (nodeID > =3D 100), they should be allowed to perform NODE-USER-MATCH accesses > related to this device and their usernames: 100-user1 for user1 and > 100-user2 for user2. why? It works as designed when they use their client nodeid. In fact, using the host's nodeid here gives the exact opposite behavior of what you would want---if one of the multiple users switches to a different device, they may wind up with a stale entry pointing to the device they are no longer at, whereas if the user uses their own certificate&nodeid, when they register their route to the new host the old one is automatically removed because they're using the same client nodeid. > Because, if not, we are not really implementing > this functionality. what functionality? > In order to be fully implemented, several users > connected to the same device should have the same functionalities that a > single user connected to this device has, and this is not the case using > virtual clients. could you clarify what you're referring to here? I don't know what functionality I would expect multiple users signed into the same device to have that wouldn't be provided using their own nodeids. Bruce > > cheers > > > > On Fri, 2011-07-08 at 09:40 -0400, Bruce Lowekamp wrote: >> On Fri, Jul 8, 2011 at 7:15 AM, Diego Suarez wrot= e: >> > Hi Bruce, >> > >> > Answers inline. >> > >> > >> > On Thu, 2011-07-07 at 22:24 -0400, Bruce Lowekamp wrote: >> >> Diego, >> >> >> >> Please take some time understanding how real clients work in reload. >> >> Then just have the virtual clients use the same messages. =C2=A0The v= irtual >> >> clients use their own nodeids, not the host's nodeid. =C2=A0It all wo= rks >> >> fine. >> > >> > I agree, this works fine for clients, but, from my point of view, it >> > does not for several users connected to the same device. The fact that >> > clients ( or virtual clients ) use their own nodeIDs and not the host'= s >> > nodeIDs is precisely what I see as the problem of using virtual client= s >> > to allow several users to be connected to the same device. Since virtu= al >> > clients are not using the device's nodeID, they cannot perform >> > operations ( like NODE-MATCH or USER-NODE-MATCH accesses) from that >> > device like they should if they were actually connected to the system >> > from it. As I've said in my previous mail, they only way I see to allo= w >> > so is the device adding an extra signature to the message, with the >> > already commented problem of two users and two nodeIDs in it. >> > >> >> Since a client is using its own nodeid, NODE-MATCH and USER-NODE-MATCH >> are performed using the client's nodeid. =C2=A0In the case of the sip >> usage, it's done using USER-NODE-MATCH. =C2=A0This is the client's >> rfc822Name and the client's nodeid. =C2=A0In that registration, it store= s a >> destination list that starts with the peer and finishes with the >> client's nodeid (in most cases, would be only these two entries). >> This is how clients are supported in reload and for the sip usage. >> >> > >> >> I don't see a real problem with a host node having an >> >> "admin@example.com" or "node12345@example.com" name attached to it. >> >> Routers pretty much always have DNS names that are descriptive of >> >> where they are to admins, even though routing protocols don't require >> >> it. >> > >> > Neither do I except for cases, like the presented before, of several >> > users in the same device. >> > >> >> >> >> Regarding certs, 6072 has the following text: >> >> >> >> =C2=A0 =C2=A0If the certificate is signed by a trusted certification = authority, >> >> =C2=A0 =C2=A0and one of the names in the SubjectAltName matches the o= riginal URI, >> >> =C2=A0 =C2=A0then this certificate MAY be used, but only for exactly = the original >> >> >> >> It's been awhile since I've looked at that in detail, but it appears >> >> to me that a reload cert could be perfectly valid for use with 6072 a= s >> >> long as it has the sip uri in it. =C2=A0Though I'm not immediately >> >> convinced that this is that useful, regardless. >> > >> > The problem is not with RELOAD certs being used in SIP systems, but wi= th >> > SIP certs being used in RELOAD systems. Since SIP certs do not have >> > nodeIDs, they are not valid in RELOAD. >> > >> > cheers >> > >> >> >> >> Bruce >> >> >> >> >> >> >> >> On Mon, Jul 4, 2011 at 5:51 AM, Diego Suarez w= rote: >> >> > Hi, >> >> > >> >> > Actually, I see this "virtual client" method more complicated and >> >> > confusing than splitting the identities of users and devices. >> >> > >> >> > With this model, you are gonna have a device identified by a PKC th= at >> >> > includes a username and a nodeID acting as a peer, but only using i= ts >> >> > nodeID. And several users connected to the device as virtual client= s >> >> > identified by PKCs including a username and a nodeID, but only usin= g >> >> > their usernames. >> >> > >> >> > One of the more confusing things I see here is the access control. >> >> > Imagine we have a device, with PKC ( # user =3D device1, nodeID =3D= 100 # ) >> >> > and two users ( # user =3D user1, nodeID =3D 200 # and # user =3D u= ser2, >> >> > nodeID =3D 300 # ) connected to that device acting as virtual clien= ts. >> >> > >> >> > If user1 wants to perform a USER-NODE-MATCH access control related = to >> >> > the peer she is operating from ( actually the nodeID =3D 100 nor th= e >> >> > virtual one with nodeID =3D 200 ) and her username ( user =3D user1= ), she >> >> > is gonna have to create a request signed with her PKC and the PKC o= f the >> >> > device. This request need to be doubled signed ( by the peer to gra= nt >> >> > the nodeID =3D 100 and by the user to grant the user =3D user 1 ). = However, >> >> > this double signed request intended for nodeID =3D 100 and user =3D= user1 is >> >> > gonna include two users =3D device1 and user1 and two nodeID =3D 10= 0 and >> >> > 200. This is confusing for me. Therefore, from my point of view, it >> >> > makes sense to me to remove the username from the device and the no= de >> >> > from the users since we are not using them and confuse the access >> >> > control. >> >> > >> >> > Also, splitting identities have another advantages like greater >> >> > interoperability with traditional SIP systems. Imagine a company ru= nning >> >> > a SIP system, where users are identified by a PKC including a SIP >> >> > username, that wants to extend its coverage interconnecting it with= a >> >> > P2PSIP system. With the actual certification model, SIP PKCs are no= t >> >> > valid for the new P2PSIP side of the system. All the users have to = be >> >> > re-certificated to have a PKC including the old SIP username and a >> >> > nodeID. However, with the split proposal SIP certificates are still >> >> > valid in the P2PSIP side of the system and interoperable within the= two >> >> > networks, and only the devices intended to be used in the P2PSIP si= de >> >> > have to be certified with a nodeID. >> >> > >> >> > >> >> > cheers >> >> > >> >> > >> >> > >> >> > >> >> > On Sat, 2011-07-02 at 16:53 -0400, Bruce Lowekamp wrote: >> >> >> With the current definition of the protocol, split routing IDs and >> >> >> user IDs can be achieved by having the host node participate as a = peer >> >> >> (or as a client, honestly) using its own cert and the attached use= rs >> >> >> represented as virtual clients, i.e. generate messages as if they = are >> >> >> on separate nodes attached to the host node as a client. >> >> >> >> >> >> If you wanted to implement it "natively," other than the >> >> >> USER-NODE-MATCH, as mentioned before, I can only find two changes = that >> >> >> would need to be made to support split identities. >> >> >> >> >> >> For processing StoreReq: >> >> >> o =C2=A0For original (non-replica) stores, the StoreReq is signed = by a >> >> >> =C2=A0 =C2=A0 =C2=A0 credential which is authorized to write this = kind at this >> >> >> =C2=A0 =C2=A0 =C2=A0 Resource-Id. =C2=A0If this check fails, the r= equest MUST be rejected >> >> >> =C2=A0 =C2=A0 =C2=A0 with an Error_Forbidden error. >> >> >> >> >> >> and the definition of credential in beginning of 10.3. >> >> >> >> >> >> >> >> >> Assuming that there is not something I'm missing with using virtua= l >> >> >> clients, I'd rather not make any changes. =C2=A0This is a complica= ted >> >> >> enough protocol, and I think adding special cases for something li= ke >> >> >> split identities just makes it more complicated. =C2=A0If any chan= ges were >> >> >> made, I would think it should be something to make it possible for= an >> >> >> extension to specify the change, but as long as the current protoc= ol >> >> >> is capable of handling the functional goals, I'd rather no changes= be >> >> >> made. >> >> >> >> >> >> Bruce >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Sat, Jul 2, 2011 at 1:04 PM, Marc Petit-Huguenin wrote: >> >> >> > -----BEGIN PGP SIGNED MESSAGE----- >> >> >> > Hash: SHA1 >> >> >> > >> >> >> > On 07/02/2011 09:28 AM, Diego Suarez wrote: >> >> >> >> Hi, >> >> >> >> >> >> >> >>>From my point of view, in this case the user has to both prove = she is in >> >> >> >> possession of the PKC that includes the required username and a= lso prove >> >> >> >> she is operating from the required node. However, modifying the >> >> >> >> SignerIdentity to include multiple identities ( the user and th= e >> >> >> >> device ) would not really prove that since only one signature c= ould be >> >> >> >> included (either the user's signature or the device's one). >> >> >> >> >> >> >> >> Therefore, I'd modify the SecurityBlock instead to allow the in= clusion >> >> >> >> of more than only one signature. >> >> >> >> >> >> >> >> For this case, the securityBlock would include two signatures. = One with >> >> >> >> the SignerIdentity of the user and the signature of the user's = PKC >> >> >> >> (including the username ) and another with the SignerIdentity o= f the >> >> >> >> device and the signature of the device's PKC ( including the no= deID). >> >> >> > >> >> >> > Right, something like this: >> >> >> > >> >> >> > struct { >> >> >> > =C2=A0 GenericCertificate certificates<0..2^16-1>; >> >> >> > =C2=A0 Signature =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0signatures<0.= .2^16-1>; >> >> >> > =C2=A0 } SecurityBlock; >> >> >> > >> >> >> > Note that StoredData also needs to be modified: >> >> >> > >> >> >> > struct { >> >> >> > =C2=A0 uint32 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0length; >> >> >> > =C2=A0 uint64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0storage_time; >> >> >> > =C2=A0 uint32 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lifetime; >> >> >> > =C2=A0 StoredDataValue value; >> >> >> > =C2=A0 Signature =C2=A0 =C2=A0 =C2=A0 signatures<0..2^16-1>; >> >> >> > =C2=A0 } StoredData; >> >> >> > >> >> >> >> >> >> >> >> cheers >> >> >> >> >> >> >> >> >> >> >> >> On Fri, 2011-07-01 at 15:44 -0700, Marc Petit-Huguenin wrote: >> >> >> >> Hi Diego, >> >> >> >> >> >> >> >> How does this work with an access control policy like USER-NODE= -MATCH, which >> >> >> >> requires both a Node-ID and a username in the SignerIdentity? = =C2=A0If the Node-ID >> >> >> >> and the username are in separate certificates, wouldn't that re= quire to extend >> >> >> >> the SignerIdentity structure to store multiple identities? >> >> >> >> >> >> >> >> Thanks. >> >> >> >> >> >> >> >> On 06/09/2011 10:47 AM, Diego Suarez wrote: >> >> >> >>>>> I think it would require a (slight) modification in the base= document. >> >> >> >>>>> Current P2PSIP certification model is based on a single PKC = (including >> >> >> >>>>> both usernames and nodeIDs) that uniquely identifies a user = and her >> >> >> >>>>> devices. On the other hand, our model is base on a split cer= tification. >> >> >> >>>>> Devices and users are independent. Each device has its own P= KC including >> >> >> >>>>> a nodeID and a PK. Similarly, each user has her own PKC incl= uding her >> >> >> >>>>> username and a PK. This approach do not prevent a centralize= d entity >> >> >> >>>>> (such as an offline CA) to have information related to the d= evices each >> >> >> >>>>> user (or company, etc.) has registered, but permits, among o= ther >> >> >> >>>>> improvements, a user to be connected to the system through d= evices she >> >> >> >>>>> has not registered herself such as a phone issued by a telco= or a fixed >> >> >> >>>>> phone in a laboratory shared by all the members of a researc= h group. >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote= : >> >> >> >>>>> Does this model really required modifications in the base do= cument, or can it be >> >> >> >>>>> designed as an extension? =C2=A0(Unfortunately the paper is = not freely available, so >> >> >> >>>>> it is difficult to know really what is needed for this). >> >> >> >>>>> >> >> >> >>>>> On 06/09/2011 07:31 AM, Diego Suarez wrote: >> >> >> >>>>>>>> Hi, >> >> >> >>>>>>>> >> >> >> >>>>>>>> I had in mind writing a draft about this, but since I'm r= unning out of >> >> >> >>>>>>>> time, I would like to summarize a new certification model= for P2PSIP I >> >> >> >>>>>>>> have been working on, in case it is of interest for the g= roup. >> >> >> >>>>>>>> Further details can be found in paper: >> >> >> >>>>>>>> >> >> >> >>>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, =C2= =A0Advantages of >> >> >> >>>>>>>> identity certificate segregation in P2PSIP systems, =C2= =A0Communications, >> >> >> >>>>>>>> IET, vol. 5, pp. 879 889, Apr. 2011. >> >> >> >>>>>>>> >> >> >> >>>>>>>> >> >> >> >>>>>>>> The idea is to split the certification of users and devic= es. Devices are >> >> >> >>>>>>>> identified by PKCs including a nodeID and the PK of the d= evice, while >> >> >> >>>>>>>> users are identified by PKCs including a username and the= PK of the >> >> >> >>>>>>>> user. Similar models have been used before in other commu= nications >> >> >> >>>>>>>> systems, such as GSM where devices and users are separate= ly represented >> >> >> >>>>>>>> by the international mobile equipment identity (IMEI) sto= red in the >> >> >> >>>>>>>> phones and the international mobile subscriber identity (= IMSI) stored in >> >> >> >>>>>>>> the user subscriber identity module (SIM), respectively. >> >> >> >>>>>>>> >> >> >> >>>>>>>> Motivations of this model are: >> >> >> >>>>>>>> >> >> >> >>>>>>>> - Users and devices are different entities performing dif= ferent >> >> >> >>>>>>>> roles within a P2PSIP system. Devices are nodes of the P2= P >> >> >> >>>>>>>> overlay network (represented by a nodeID) that offer serv= ices >> >> >> >>>>>>>> (to route messages, to store data, . . .) to the system, = while >> >> >> >>>>>>>> users (represented by an username) utilize these services= , >> >> >> >>>>>>>> usually to establish media communications using SIP. >> >> >> >>>>>>>> >> >> >> >>>>>>>> - Support for mobility scenarios where a user may be logg= ed at different >> >> >> >>>>>>>> devices at the same time using the same PKC. >> >> >> >>>>>>>> >> >> >> >>>>>>>> - Support several users to be logged in the same device (= like a fixed >> >> >> >>>>>>>> phone) at the same time. >> >> >> >>>>>>>> >> >> >> >>>>>>>> - Support for user independent hard-coded devices. >> >> >> >>>>>>>> >> >> >> >>>>>>>> - Interoperability with SIP. SIP certificates are not val= id in actual >> >> >> >>>>>>>> P2PSIP since they don't include a nodeID. >> >> >> >>>>>>>> >> >> >> >>>>>>>> cheers >> >> >> >>>>>>>> >> >> >> >>>>>>>> Diego Su=C3=A1rez >> >> >> >>>>>>>> >> >> >> >>>>>>>> >> >> >> >>>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: >> >> >> >>>>>>>>> Unless something major comes up, we plan to request the = newest version >> >> >> >>>>>>>>> of the base draft, draft-ietf-p2psip-base-15, be publish= ed. I'll put >> >> >> >>>>>>>>> in the request in a week (June 16th or 17th). If there a= re any further >> >> >> >>>>>>>>> comments from the last call a while ago (or further comm= ents on the >> >> >> >>>>>>>>> comments since then), please send them to the list ASAP. >> >> >> >>>>>>>>> >> >> >> >>>>>>>>> Thanks, >> >> >> >>>>>>>>> >> >> >> >>>>>>>>> David (as chair) >> >> >> > >> >> >> > - -- >> >> >> > Marc Petit-Huguenin >> >> >> > Personal email: marc@petit-huguenin.org >> >> >> > Professional email: petithug@acm.org >> >> >> > Blog: http://blog.marc.petit-huguenin.org >> >> >> > -----BEGIN PGP SIGNATURE----- >> >> >> > Version: GnuPG v1.4.11 (GNU/Linux) >> >> >> > >> >> >> > iEYEARECAAYFAk4PT4sACgkQ9RoMZyVa61dPvACeITly6/Zqumz4e4ZrAn1yGI4x >> >> >> > ay4AoJ11vmCRDkL8pXuN71qaZXhw5JTZ >> >> >> > =3DTp+D >> >> >> > -----END PGP SIGNATURE----- >> >> >> > _______________________________________________ >> >> >> > P2PSIP mailing list >> >> >> > P2PSIP@ietf.org >> >> >> > https://www.ietf.org/mailman/listinfo/p2psip >> >> >> > >> >> > >> >> > >> >> > >> > >> > >> > > > > From duanshihui@mail.ritt.com.cn Sat Jul 9 08:19:16 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEA021F8786 for ; Sat, 9 Jul 2011 08:19:16 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.182 X-Spam-Level: ** X-Spam-Status: No, score=2.182 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803, RCVD_DOUBLE_IP_LOOSE=0.76, RDNS_NONE=0.1, SARE_RECV_IP_FROMIP1=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6sJpdw7u+Ys for ; Sat, 9 Jul 2011 08:19:16 -0700 (PDT) Received: from mail.ritt.com.cn (unknown [114.242.138.101]) by ietfa.amsl.com (Postfix) with SMTP id 31D1421F87C5 for ; Sat, 9 Jul 2011 08:19:14 -0700 (PDT) X-EYOU-SPAMVALUE: 0 X-EYOU-DEALDRC: X-EMDG-VER: 2011-01-28 Received: (eyou anti_spam gateway 3.0); Sat, 09 Jul 2011 23:17:28 +0800 Message-ID: <510224648.28389@mail.ritt.com.cn> X-EYOUMAIL-SMTPAUTH: duanshihui@mail.ritt.com.cn Received: from 123.117.180.75 by 114.242.138.101 with SMTP; Sat, 09 Jul 2011 23:17:28 +0800 From: "duan" To: Date: Sat, 9 Jul 2011 23:19:14 +0800 Message-ID: <002701cc3e4b$9046cc50$b0d464f0$@ritt.com.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01CC3E8E.9E6A0C50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw+S44dYBXw/OLvRYyQZT2Y8VTFmg== Content-Language: zh-cn x-cr-hashedpuzzle: AJ8E BI4/ BqdH COvH CTIZ DF80 DqqK D8Yv E2fs FSbP FZ7o F3cX GXVf Gmj2 HW5P HYYu; 1; cAAyAHAAcwBpAHAAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {1F618843-6549-4C5D-A210-AD19D4375B73}; ZAB1AGEAbgBzAGgAaQBoAHUAaQBAAG0AYQBpAGwALgByAGkAdAB0AC4AYwBvAG0ALgBjAG4A; Sat, 09 Jul 2011 15:19:11 GMT; bgBlAHcAIABkAHIAYQBmAHQAIABzAHUAYgBtAGkAcwBzAGkAbwBuACAAZgBvAHIAIABkAHIAYQBmAHQALQBwAGUAbgBnAC0AcAAyAHAAcwBpAHAALQBsAG8AYQBkAGIAYQBsAGEAbgBjAGUALQAwADAALgB0AHgAdAA= x-cr-puzzleid: {1F618843-6549-4C5D-A210-AD19D4375B73} Subject: [P2PSIP] new draft submission for draft-peng-p2psip-loadbalance-00.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2011 15:19:16 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ ------=_NextPart_000_0028_01CC3E8E.9E6A0C50 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear all, I have submitted new draft for p2psip: Load Balance Consideration for = p2psip network. Sorry for late to post this message. Looking forward to your comments. =20 Title : Load Balance Consideration for p2psip network Author(s) : Jin.Peng Lifeng.Le Baohong.He Shihui.Duan Filename : draft-peng-p2psip-loadbalance-00.txt Pages : 13 Date : 2011-07-04 Abstract=A3=BA This document introduces the practical load balance problems in DHT- based P2P systems and analyses the reasons of these problems. In this document, it introduces some typical mature load balance solutions for Object Load Balance and Routing Load Balance. This document can be taken as a background investigation for implementing load balance in P2PSIP protocol. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-peng-p2psip-loadbalance-00.txt =20 =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/ draft-peng-p2psip-loadbalance-00.txt =20 ------=_NextPart_000_0028_01CC3E8E.9E6A0C50 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Dear = all,

I have submitted new draft for p2psip: Load Balance Consideration for p2psip = network.

Sorry for late to post this message.

    Looking = forward to your comments.

 

         = Title           : Load Balance Consideration for p2psip network

         = Author(s)       : Jin.Peng

          =          Lifeng.Le

                   Baohong= .He

          =          Shihui.Duan

         = Filename        : draft-peng-p2psip-loadbalance-00.txt

         = Pages           : 13

         = Date            : 2011-07-04

Abstract=A3=BA

This document introduces the practical load balance problems in = DHT-

   based P2P = systems and analyses the reasons of these problems. In this

   document, it = introduces some typical mature load balance solutions

   for Object Load = Balance and Routing Load Balance. This document can

   be taken as a = background investigation for implementing load balance

   in P2PSIP = protocol.

 

A URL for this Internet-Draft = is:

http://www.ietf.org/internet-drafts/draft-peng-p2psip-loadbal= ance-00.txt

 

Internet-Drafts are also = available by anonymous FTP at:

ftp://ftp.ietf.org/internet-= drafts/

 

This Internet-Draft can be = retrieved at:

ftp://ftp.ietf.org/internet-drafts/ draft-peng-p2psip-loadbalance-00.txt

 

------=_NextPart_000_0028_01CC3E8E.9E6A0C50-- From loopp2psip@gmail.com Sat Jul 9 10:25:53 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C5F21F866C for ; Sat, 9 Jul 2011 10:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.356 X-Spam-Level: X-Spam-Status: No, score=-0.356 tagged_above=-999 required=5 tests=[AWL=-1.169, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wymU+wcld3ow for ; Sat, 9 Jul 2011 10:25:51 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE65021F865A for ; Sat, 9 Jul 2011 10:25:50 -0700 (PDT) Received: by wwe5 with SMTP id 5so1877948wwe.13 for ; Sat, 09 Jul 2011 10:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=/ajyUR+I4M7aG6ZFXD1B5SuhD7igltSr7bvaSSrvBVA=; b=ZzBZUnP99M9F6L32iXcGeAmEjAit+tGMImNZmjvChBadaYqolytx9zv6u5J6tEcUgf pd+Qncf12lWwVyTdOH/TcKK2zErc2ymTxH1IaidDtTjvf6t9YbjjnLkW4E6ysSoRHkde za5VGX+ZNhj43nk9TNZaJSVNuDuGc+4K8oYw8= Received: by 10.227.178.135 with SMTP id bm7mr2799909wbb.52.1310232348668; Sat, 09 Jul 2011 10:25:48 -0700 (PDT) Received: from [192.168.1.3] (96.134.16.95.dynamic.jazztel.es [95.16.134.96]) by mx.google.com with ESMTPS id p14sm4361030wbh.13.2011.07.09.10.25.45 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Jul 2011 10:25:46 -0700 (PDT) From: Diego Suarez To: Bruce Lowekamp In-Reply-To: References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E0E4DBE.5060302@acm.org> <1309624099.5232.23.camel@santeles> <4E0F4F8D.9080108@acm.org> <1309773089.5716.43.camel@santeles> <1310123712.22737.73.camel@toedo> <1310143982.6132.75.camel@santeles> Content-Type: text/plain; charset="UTF-8" Date: Sat, 09 Jul 2011 19:25:43 +0200 Message-ID: <1310232343.5262.27.camel@santeles> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2011 17:25:53 -0000 First of all, I would like to introduce the motivation of the idea of split certification, since I think it is an important point in this discussion and would help to clarify why I think that virtual clients do not really allow several users to be connected from the same device. Also, it could help to clarify if I taking a false premise to support split certification when I should not. As far as I understood, the idea of nodeIDs in RELOAD is to represent devices, despite usernames and nodeIDs are included in the same certificate. Draft says: "If a user has more than one device, typically they would get one certificate for each device. This allows each device to act as a separate peer." However, it also exist the possibility of having a single certificate with several nodeIDs. In this case, a user with two devices ( for example a mobile and a fixed phone ) would have a certificate with a username and two nodeIDs, one for each device; being able to be connected to network and contactable in both devices at the same time. Regarding the first alternative, there is something I have not clear: If a user has a different certificate for each device she has, would these certificates have the same username and different nodeIDs? and if so, would the PK be the same in all the certificates or a different PK in each one?; or would the user have a different username, a different nodeID and a different PK in each certificate?. Said this, if we want each device to have its own certificate, why don't make it simpler a split device's identity from the user's identity? The second alternative (several nodeIDs in a single cert) works well for me if the user if using the same devices all the time, for example a user with one cert with a nodeID for her mobile phone and another nodeID for her office fixed phone; but has some limitations. What happens if the user is out for one week in another office and wants to be connected from there ? The simple answer seems to be "use the nodeID she was using in the other office". But, is it not weird to bother in the first place to give a different nodeID to each user's device and now use the same nodeID for two different ones? Also, won't be useful to have each device identified by a unique nodeID within the network for security reasons or to have permanent statistics about its past behavior for network maintenance or routing purposes? With this in mind, it came to me the idea of a split certification. With split certification, users would be identified always by the same certificate independently of the device they are using (something that does not happen in the first alternative). Also, devices would be always identified by the same and unique cert (something that does not happen in the second). Besides, users could be connected to as many devices as they want without have to been re-certified to get more nodeIDs. I think this would simplify the certification of the system and improve its maintenance. Also, extra improvements come with this alternative, like greater interoperability with SIP ( as I've already commented in previous mails ) or the easy deployment of more secure networks formed by hard coded (including a certificate with a nodeID) devices. The comments to the other improvement I see of this alternative, related to several users connected to the same device, are inline. On Fri, 2011-07-08 at 19:06 -0400, Bruce Lowekamp wrote: > inline > > On Fri, Jul 8, 2011 at 12:53 PM, Diego Suarez wrote: > > Hi, > > > > I have the impression I am not explaining myself well. I am not saying > > that clients in RELOAD do not work well, I am just saying that I do not > > see how they can be used to allow several users to be connected to the > > same the device; at least not with full functionalities. > > > > Lets go back to the example: > > Imagine we have a device, with PKC ( # user = device1, nodeID = 100 # ) > > and two users ( # user = user1, nodeID = 200 # and # user = user2, > > nodeID = 300 # ) connected to that device acting as virtual clients. > > > > As you have said, during registration, users store a destination list > > that start with the device ( nodeID = 100 ) and finishes with the > > client's nodeID ( nodeID = 200 for user1 and nodeID = 300 for user2). > > This works well, and allows other peers of the system to reach them. > > > > However, the problem is with the access control. Being virtual clients, > > users can perform NODE-USER-MATCH accesses related to their client's > > nodeIDs and usernames: 200-user1 for user1 and 300-user2 for user2. > > Nevertheless, this is not what we want in this case. In this case, where > > user1 and user2 are supposed to be connected to the same device (nodeID > > = 100), they should be allowed to perform NODE-USER-MATCH accesses > > related to this device and their usernames: 100-user1 for user1 and > > 100-user2 for user2. > > why? It works as designed when they use their client nodeid. Well, I've said before, if the idea of RELOAD is to have each device be identified by a different nodeID, from my point of view two users operating from the same device should be using the same nodeID. Two users connected to the same device, using different nodeIDs, that also reuse later with another devices are not actually breaking the certification idea of 1device = 1nodeID? > In > fact, using the host's nodeid here gives the exact opposite behavior > of what you would want---if one of the multiple users switches to a > different device, they may wind up with a stale entry pointing to the > device they are no longer at, whereas if the user uses their own > certificate&nodeid, when they register their route to the new host the > old one is automatically removed because they're using the same client > nodeid. I think this would be a fail of the implementation not of the proposal and that can also happen with the actual model of RELOAD. Imagine a user with a cert (including a username and two nodeIDs ) connected to two different devices. If she disconnects from one of the devices but forgets to remove that entry point, she may also wind up with a stale entry pointing to a device she is no longer at. > > > Because, if not, we are not really implementing > > this functionality. > > what functionality? > > > In order to be fully implemented, several users > > connected to the same device should have the same functionalities that a > > single user connected to this device has, and this is not the case using > > virtual clients. > > could you clarify what you're referring to here? I don't know what > functionality I would expect multiple users signed into the same > device to have that wouldn't be provided using their own nodeids. > I would try to clarify what I mean with an example that presents three possible cases that can occur in RELOAD: case 1: User1 with cert ( user = user1, nodeID = 100 ) is connected to the network using a device. Therefore she can perform any access related to her user( USER-MATCH = user1 ), nodeID ( NODE-MATCH = 100 ) or the combination of both (USER-NODE-MATCH = user1-100). case 2: The same User1 with the same cert is connected to the network using the same device. But now, also User2 ( user = user2, nodeID = 200 ) and User3 ( user = user3, nodeID = 300 ) are connected to that device as virtual clients. User1 can perform the same kind of accesses than in case 1. User2 can perform accesses related her user( USER-MATCH = user2 ), virtual nodeID ( NODE-MATCH = 200 ) or the combination of both (USER-NODE-MATCH = user2-200). User3 is ( USER-MATCH = user3 ), virtual nodeID ( NODE-MATCH = 300 ) or the combination of both (USER-NODE-MATCH = user3-300). case 3: A "non-user" device ( user = lab1, nodeID = 100 ) is connected to the network. Two users, User2 and User3 (with the same credentials that in the previous case) are connected to that device. So, User2 and User3 can perform the same accesses than in case 3. In this three examples, taking a look a the accesses related to NODE, the important thing here, we see different cases of users presumably connected to the same device, that should have the same functionalities over that device but actually they have not. Precisely, User1 can perform accesses on behalf of the device, while user2 and user3 cannot. I would expect for all the cases the same rights for a user, either she has full control over the device ( to perform accesses like NODE-MATCH = 100 ) or she does not have any control at all over it. But not these different possibilities depending on how the user is connected to the device. This is what I wanted to mean with no having full functionalities. Furthermore, in case 2 we are forcing User1 to be connected to the network while User2 and User3 wish to continue using the device. It would be possible here that User1 entered in an ‘invisible mode’ by removing her contact information from the network. In such case, User1 seemed to be offline for the other users of the network (neither they could have the knowledge that she is online or access to her contact information) but she would be actually online since she could access to all the resources of the network, like her voicemail or the contact information of other users to initiate media calls. cheers > Bruce > > > > > > cheers > > > > > > > > On Fri, 2011-07-08 at 09:40 -0400, Bruce Lowekamp wrote: > >> On Fri, Jul 8, 2011 at 7:15 AM, Diego Suarez wrote: > >> > Hi Bruce, > >> > > >> > Answers inline. > >> > > >> > > >> > On Thu, 2011-07-07 at 22:24 -0400, Bruce Lowekamp wrote: > >> >> Diego, > >> >> > >> >> Please take some time understanding how real clients work in reload. > >> >> Then just have the virtual clients use the same messages. The virtual > >> >> clients use their own nodeids, not the host's nodeid. It all works > >> >> fine. > >> > > >> > I agree, this works fine for clients, but, from my point of view, it > >> > does not for several users connected to the same device. The fact that > >> > clients ( or virtual clients ) use their own nodeIDs and not the host's > >> > nodeIDs is precisely what I see as the problem of using virtual clients > >> > to allow several users to be connected to the same device. Since virtual > >> > clients are not using the device's nodeID, they cannot perform > >> > operations ( like NODE-MATCH or USER-NODE-MATCH accesses) from that > >> > device like they should if they were actually connected to the system > >> > from it. As I've said in my previous mail, they only way I see to allow > >> > so is the device adding an extra signature to the message, with the > >> > already commented problem of two users and two nodeIDs in it. > >> > > >> > >> Since a client is using its own nodeid, NODE-MATCH and USER-NODE-MATCH > >> are performed using the client's nodeid. In the case of the sip > >> usage, it's done using USER-NODE-MATCH. This is the client's > >> rfc822Name and the client's nodeid. In that registration, it stores a > >> destination list that starts with the peer and finishes with the > >> client's nodeid (in most cases, would be only these two entries). > >> This is how clients are supported in reload and for the sip usage. > >> > >> > > >> >> I don't see a real problem with a host node having an > >> >> "admin@example.com" or "node12345@example.com" name attached to it. > >> >> Routers pretty much always have DNS names that are descriptive of > >> >> where they are to admins, even though routing protocols don't require > >> >> it. > >> > > >> > Neither do I except for cases, like the presented before, of several > >> > users in the same device. > >> > > >> >> > >> >> Regarding certs, 6072 has the following text: > >> >> > >> >> If the certificate is signed by a trusted certification authority, > >> >> and one of the names in the SubjectAltName matches the original URI, > >> >> then this certificate MAY be used, but only for exactly the original > >> >> > >> >> It's been awhile since I've looked at that in detail, but it appears > >> >> to me that a reload cert could be perfectly valid for use with 6072 as > >> >> long as it has the sip uri in it. Though I'm not immediately > >> >> convinced that this is that useful, regardless. > >> > > >> > The problem is not with RELOAD certs being used in SIP systems, but with > >> > SIP certs being used in RELOAD systems. Since SIP certs do not have > >> > nodeIDs, they are not valid in RELOAD. > >> > > >> > cheers > >> > > >> >> > >> >> Bruce > >> >> > >> >> > >> >> > >> >> On Mon, Jul 4, 2011 at 5:51 AM, Diego Suarez wrote: > >> >> > Hi, > >> >> > > >> >> > Actually, I see this "virtual client" method more complicated and > >> >> > confusing than splitting the identities of users and devices. > >> >> > > >> >> > With this model, you are gonna have a device identified by a PKC that > >> >> > includes a username and a nodeID acting as a peer, but only using its > >> >> > nodeID. And several users connected to the device as virtual clients > >> >> > identified by PKCs including a username and a nodeID, but only using > >> >> > their usernames. > >> >> > > >> >> > One of the more confusing things I see here is the access control. > >> >> > Imagine we have a device, with PKC ( # user = device1, nodeID = 100 # ) > >> >> > and two users ( # user = user1, nodeID = 200 # and # user = user2, > >> >> > nodeID = 300 # ) connected to that device acting as virtual clients. > >> >> > > >> >> > If user1 wants to perform a USER-NODE-MATCH access control related to > >> >> > the peer she is operating from ( actually the nodeID = 100 nor the > >> >> > virtual one with nodeID = 200 ) and her username ( user = user1 ), she > >> >> > is gonna have to create a request signed with her PKC and the PKC of the > >> >> > device. This request need to be doubled signed ( by the peer to grant > >> >> > the nodeID = 100 and by the user to grant the user = user 1 ). However, > >> >> > this double signed request intended for nodeID = 100 and user = user1 is > >> >> > gonna include two users = device1 and user1 and two nodeID = 100 and > >> >> > 200. This is confusing for me. Therefore, from my point of view, it > >> >> > makes sense to me to remove the username from the device and the node > >> >> > from the users since we are not using them and confuse the access > >> >> > control. > >> >> > > >> >> > Also, splitting identities have another advantages like greater > >> >> > interoperability with traditional SIP systems. Imagine a company running > >> >> > a SIP system, where users are identified by a PKC including a SIP > >> >> > username, that wants to extend its coverage interconnecting it with a > >> >> > P2PSIP system. With the actual certification model, SIP PKCs are not > >> >> > valid for the new P2PSIP side of the system. All the users have to be > >> >> > re-certificated to have a PKC including the old SIP username and a > >> >> > nodeID. However, with the split proposal SIP certificates are still > >> >> > valid in the P2PSIP side of the system and interoperable within the two > >> >> > networks, and only the devices intended to be used in the P2PSIP side > >> >> > have to be certified with a nodeID. > >> >> > > >> >> > > >> >> > cheers > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > On Sat, 2011-07-02 at 16:53 -0400, Bruce Lowekamp wrote: > >> >> >> With the current definition of the protocol, split routing IDs and > >> >> >> user IDs can be achieved by having the host node participate as a peer > >> >> >> (or as a client, honestly) using its own cert and the attached users > >> >> >> represented as virtual clients, i.e. generate messages as if they are > >> >> >> on separate nodes attached to the host node as a client. > >> >> >> > >> >> >> If you wanted to implement it "natively," other than the > >> >> >> USER-NODE-MATCH, as mentioned before, I can only find two changes that > >> >> >> would need to be made to support split identities. > >> >> >> > >> >> >> For processing StoreReq: > >> >> >> o For original (non-replica) stores, the StoreReq is signed by a > >> >> >> credential which is authorized to write this kind at this > >> >> >> Resource-Id. If this check fails, the request MUST be rejected > >> >> >> with an Error_Forbidden error. > >> >> >> > >> >> >> and the definition of credential in beginning of 10.3. > >> >> >> > >> >> >> > >> >> >> Assuming that there is not something I'm missing with using virtual > >> >> >> clients, I'd rather not make any changes. This is a complicated > >> >> >> enough protocol, and I think adding special cases for something like > >> >> >> split identities just makes it more complicated. If any changes were > >> >> >> made, I would think it should be something to make it possible for an > >> >> >> extension to specify the change, but as long as the current protocol > >> >> >> is capable of handling the functional goals, I'd rather no changes be > >> >> >> made. > >> >> >> > >> >> >> Bruce > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> On Sat, Jul 2, 2011 at 1:04 PM, Marc Petit-Huguenin wrote: > >> >> >> > -----BEGIN PGP SIGNED MESSAGE----- > >> >> >> > Hash: SHA1 > >> >> >> > > >> >> >> > On 07/02/2011 09:28 AM, Diego Suarez wrote: > >> >> >> >> Hi, > >> >> >> >> > >> >> >> >>>From my point of view, in this case the user has to both prove she is in > >> >> >> >> possession of the PKC that includes the required username and also prove > >> >> >> >> she is operating from the required node. However, modifying the > >> >> >> >> SignerIdentity to include multiple identities ( the user and the > >> >> >> >> device ) would not really prove that since only one signature could be > >> >> >> >> included (either the user's signature or the device's one). > >> >> >> >> > >> >> >> >> Therefore, I'd modify the SecurityBlock instead to allow the inclusion > >> >> >> >> of more than only one signature. > >> >> >> >> > >> >> >> >> For this case, the securityBlock would include two signatures. One with > >> >> >> >> the SignerIdentity of the user and the signature of the user's PKC > >> >> >> >> (including the username ) and another with the SignerIdentity of the > >> >> >> >> device and the signature of the device's PKC ( including the nodeID). > >> >> >> > > >> >> >> > Right, something like this: > >> >> >> > > >> >> >> > struct { > >> >> >> > GenericCertificate certificates<0..2^16-1>; > >> >> >> > Signature signatures<0..2^16-1>; > >> >> >> > } SecurityBlock; > >> >> >> > > >> >> >> > Note that StoredData also needs to be modified: > >> >> >> > > >> >> >> > struct { > >> >> >> > uint32 length; > >> >> >> > uint64 storage_time; > >> >> >> > uint32 lifetime; > >> >> >> > StoredDataValue value; > >> >> >> > Signature signatures<0..2^16-1>; > >> >> >> > } StoredData; > >> >> >> > > >> >> >> >> > >> >> >> >> cheers > >> >> >> >> > >> >> >> >> > >> >> >> >> On Fri, 2011-07-01 at 15:44 -0700, Marc Petit-Huguenin wrote: > >> >> >> >> Hi Diego, > >> >> >> >> > >> >> >> >> How does this work with an access control policy like USER-NODE-MATCH, which > >> >> >> >> requires both a Node-ID and a username in the SignerIdentity? If the Node-ID > >> >> >> >> and the username are in separate certificates, wouldn't that require to extend > >> >> >> >> the SignerIdentity structure to store multiple identities? > >> >> >> >> > >> >> >> >> Thanks. > >> >> >> >> > >> >> >> >> On 06/09/2011 10:47 AM, Diego Suarez wrote: > >> >> >> >>>>> I think it would require a (slight) modification in the base document. > >> >> >> >>>>> Current P2PSIP certification model is based on a single PKC (including > >> >> >> >>>>> both usernames and nodeIDs) that uniquely identifies a user and her > >> >> >> >>>>> devices. On the other hand, our model is base on a split certification. > >> >> >> >>>>> Devices and users are independent. Each device has its own PKC including > >> >> >> >>>>> a nodeID and a PK. Similarly, each user has her own PKC including her > >> >> >> >>>>> username and a PK. This approach do not prevent a centralized entity > >> >> >> >>>>> (such as an offline CA) to have information related to the devices each > >> >> >> >>>>> user (or company, etc.) has registered, but permits, among other > >> >> >> >>>>> improvements, a user to be connected to the system through devices she > >> >> >> >>>>> has not registered herself such as a phone issued by a telco or a fixed > >> >> >> >>>>> phone in a laboratory shared by all the members of a research group. > >> >> >> >>>>> > >> >> >> >>>>> > >> >> >> >>>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: > >> >> >> >>>>> Does this model really required modifications in the base document, or can it be > >> >> >> >>>>> designed as an extension? (Unfortunately the paper is not freely available, so > >> >> >> >>>>> it is difficult to know really what is needed for this). > >> >> >> >>>>> > >> >> >> >>>>> On 06/09/2011 07:31 AM, Diego Suarez wrote: > >> >> >> >>>>>>>> Hi, > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> I had in mind writing a draft about this, but since I'm running out of > >> >> >> >>>>>>>> time, I would like to summarize a new certification model for P2PSIP I > >> >> >> >>>>>>>> have been working on, in case it is of interest for the group. > >> >> >> >>>>>>>> Further details can be found in paper: > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, Advantages of > >> >> >> >>>>>>>> identity certificate segregation in P2PSIP systems, Communications, > >> >> >> >>>>>>>> IET, vol. 5, pp. 879 889, Apr. 2011. > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> The idea is to split the certification of users and devices. Devices are > >> >> >> >>>>>>>> identified by PKCs including a nodeID and the PK of the device, while > >> >> >> >>>>>>>> users are identified by PKCs including a username and the PK of the > >> >> >> >>>>>>>> user. Similar models have been used before in other communications > >> >> >> >>>>>>>> systems, such as GSM where devices and users are separately represented > >> >> >> >>>>>>>> by the international mobile equipment identity (IMEI) stored in the > >> >> >> >>>>>>>> phones and the international mobile subscriber identity (IMSI) stored in > >> >> >> >>>>>>>> the user subscriber identity module (SIM), respectively. > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> Motivations of this model are: > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> - Users and devices are different entities performing different > >> >> >> >>>>>>>> roles within a P2PSIP system. Devices are nodes of the P2P > >> >> >> >>>>>>>> overlay network (represented by a nodeID) that offer services > >> >> >> >>>>>>>> (to route messages, to store data, . . .) to the system, while > >> >> >> >>>>>>>> users (represented by an username) utilize these services, > >> >> >> >>>>>>>> usually to establish media communications using SIP. > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> - Support for mobility scenarios where a user may be logged at different > >> >> >> >>>>>>>> devices at the same time using the same PKC. > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> - Support several users to be logged in the same device (like a fixed > >> >> >> >>>>>>>> phone) at the same time. > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> - Support for user independent hard-coded devices. > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> - Interoperability with SIP. SIP certificates are not valid in actual > >> >> >> >>>>>>>> P2PSIP since they don't include a nodeID. > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> cheers > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> Diego Suárez > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: > >> >> >> >>>>>>>>> Unless something major comes up, we plan to request the newest version > >> >> >> >>>>>>>>> of the base draft, draft-ietf-p2psip-base-15, be published. I'll put > >> >> >> >>>>>>>>> in the request in a week (June 16th or 17th). If there are any further > >> >> >> >>>>>>>>> comments from the last call a while ago (or further comments on the > >> >> >> >>>>>>>>> comments since then), please send them to the list ASAP. > >> >> >> >>>>>>>>> > >> >> >> >>>>>>>>> Thanks, > >> >> >> >>>>>>>>> > >> >> >> >>>>>>>>> David (as chair) > >> >> >> > > >> >> >> > - -- > >> >> >> > Marc Petit-Huguenin > >> >> >> > Personal email: marc@petit-huguenin.org > >> >> >> > Professional email: petithug@acm.org > >> >> >> > Blog: http://blog.marc.petit-huguenin.org > >> >> >> > -----BEGIN PGP SIGNATURE----- > >> >> >> > Version: GnuPG v1.4.11 (GNU/Linux) > >> >> >> > > >> >> >> > iEYEARECAAYFAk4PT4sACgkQ9RoMZyVa61dPvACeITly6/Zqumz4e4ZrAn1yGI4x > >> >> >> > ay4AoJ11vmCRDkL8pXuN71qaZXhw5JTZ > >> >> >> > =Tp+D > >> >> >> > -----END PGP SIGNATURE----- > >> >> >> > _______________________________________________ > >> >> >> > P2PSIP mailing list > >> >> >> > P2PSIP@ietf.org > >> >> >> > https://www.ietf.org/mailman/listinfo/p2psip > >> >> >> > > >> >> > > >> >> > > >> >> > > >> > > >> > > >> > > > > > > > From j.schoenwaelder@jacobs-university.de Fri Jul 8 02:50:13 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F044221F88E3; Fri, 8 Jul 2011 02:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.196 X-Spam-Level: X-Spam-Status: No, score=-102.196 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-cpxzWQwKjB; Fri, 8 Jul 2011 02:50:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3F21E21F88BA; Fri, 8 Jul 2011 02:50:12 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D6DB20BE7; Fri, 8 Jul 2011 11:50:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id f3i+636gLPxf; Fri, 8 Jul 2011 11:50:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5BD7820BEA; Fri, 8 Jul 2011 11:50:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 421E519B7638; Fri, 8 Jul 2011 11:49:58 +0200 (CEST) Date: Fri, 8 Jul 2011 11:49:57 +0200 From: Juergen Schoenwaelder To: peng.yonglin@zte.com.cn Message-ID: <20110708094957.GA85730@elstar.local> Mail-Followup-To: peng.yonglin@zte.com.cn, hao.zhenwu@zte.com.cn, li.lichun1@zte.com.cn, opsawg@ietf.org, p2psip@ietf.org References: <20110708053314.GA11313@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 11 Jul 2011 09:43:29 -0700 Cc: hao.zhenwu@zte.com.cn, opsawg@ietf.org, p2psip@ietf.org Subject: Re: [P2PSIP] =?utf-8?b?562U5aSNOiBSZTogW09QU0FXR10gV2UgaGF2ZSBzdWJt?= =?utf-8?q?itted_a_drafts_on_SNMP_usages_for_P2P_networks=2E_We_would_like?= =?utf-8?q?_to_get_some_suggestions_from_SNMP_experts_on_the_scenario_and_?= =?utf-8?q?design_for_P2P_network_management=2E_The_link_to_the_draft_is_i?= =?utf-8?q?n_the_body_of_this_email=2E_thanks=EF=BC=81?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder 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, 08 Jul 2011 09:50:13 -0000 On Fri, Jul 08, 2011 at 05:28:36PM +0800, peng.yonglin@zte.com.cn wrote: > Is the standard which you refer to RFC5953 ? Yes. The revision that got approved as Draft Standard is sitting in the RFC editor queue. For more details about the interoperability tests, see . /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From internet-drafts@ietf.org Mon Jul 11 11:07:54 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E653C11E8142; Mon, 11 Jul 2011 11:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0jZcPg9TnMA; Mon, 11 Jul 2011 11:07:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8031F21F8E6E; Mon, 11 Jul 2011 11:07:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711180754.19478.23345.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 11:07:54 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-base-17.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2011 18:07:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Proto= col Working Group of the IETF. Title : REsource LOcation And Discovery (RELOAD) Base Protocol Author(s) : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Filename : draft-ietf-p2psip-base-17.txt Pages : 160 Date : 2011-07-11 This specification 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-base-17.txt From prvs=166b0aa0f=Alexander.Knauf@haw-hamburg.de Mon Jul 11 13:01:30 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A4911E8185 for ; Mon, 11 Jul 2011 13:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJ3OW44HcKiq for ; Mon, 11 Jul 2011 13:01:30 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id A7CB211E818F for ; Mon, 11 Jul 2011 13:01:29 -0700 (PDT) Received: from dehawshub01.mailcluster.haw-hamburg.de ([141.22.200.36]) by mail6.is.haw-hamburg.de with ESMTP/TLS/RC4-MD5; 11 Jul 2011 22:01:27 +0200 Received: from dehawscas01.mailcluster.haw-hamburg.de (141.22.200.33) by DEHAWSHUB01.mailcluster.haw-hamburg.de (141.22.200.36) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 11 Jul 2011 22:01:28 +0200 Received: from [192.168.0.101] (141.22.200.51) by haw-mailer.haw-hamburg.de (141.22.200.80) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 11 Jul 2011 22:01:27 +0200 Message-ID: <4E1B5698.3050806@haw-hamburg.de> Date: Mon, 11 Jul 2011 22:01:28 +0200 From: Alexander Knauf User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: P2PSIP Mailing List References: <20110711195340.1259.23073.idtracker@ietfa.amsl.com> In-Reply-To: <20110711195340.1259.23073.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110711195340.1259.23073.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Fwd: New Version Notification for draft-knauf-p2psip-share-01.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2011 20:01:30 -0000 Hi all, we just uploaded a new version of our draft for Shared Resources in RELOAD. Please take a look http://www.ietf.org/id/draft-knauf-p2psip-share-01.txt Best regards, Alexander Change Log: 1. Integrated the USER-PATTERN-MATCH access policy into USER-CHAIN- MATCH 2. Access Control List Kind uses USER-CHAIN-ACL exclusively 3. Resources to be shared use USER-CHAIN-ACL exclusively 4. More precise specification of mandatory User_name and Resource_name fields for Shared Resources 5. Added mechanism for isolating stored data to prevent race conditions while concurrent storing 6. XML Extension for variable resource names uses its own namespace 7. Many editorial improvements A new version of I-D, draft-knauf-p2psip-share-01.txt has been successfully submitted by Alexander Knauf and posted to the IETF repository. Filename: draft-knauf-p2psip-share Revision: 01 Title: A Usage for Shared Resources in RELOAD (ShaRe) Creation date: 2011-07-11 WG ID: Individual Submission Number of pages: 22 Abstract: This document defines a RELOAD Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name which is useful whenever peer-independent rendezvous processes are required. The IETF Secretariat From prvs=166b0aa0f=Alexander.Knauf@haw-hamburg.de Mon Jul 11 13:18:05 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C8421F8F82 for ; Mon, 11 Jul 2011 13:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByvL0v3BxxN1 for ; Mon, 11 Jul 2011 13:18:04 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id 67C5021F854D for ; Mon, 11 Jul 2011 13:17:44 -0700 (PDT) Received: from dehawshub01.mailcluster.haw-hamburg.de ([141.22.200.36]) by mail3.is.haw-hamburg.de with ESMTP/TLS/RC4-MD5; 11 Jul 2011 22:17:40 +0200 Received: from dehawscas01.mailcluster.haw-hamburg.de (141.22.200.33) by DEHAWSHUB01.mailcluster.haw-hamburg.de (141.22.200.36) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 11 Jul 2011 22:17:40 +0200 Received: from [192.168.0.101] (141.22.200.51) by haw-mailer.haw-hamburg.de (141.22.200.80) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 11 Jul 2011 22:17:40 +0200 Message-ID: <4E1B5A65.3010108@haw-hamburg.de> Date: Mon, 11 Jul 2011 22:17:41 +0200 From: Alexander Knauf User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: P2PSIP Mailing List References: <20110711201315.10958.58158.idtracker@ietfa.amsl.com> In-Reply-To: <20110711201315.10958.58158.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110711201315.10958.58158.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Fwd: New Version Notification for draft-knauf-p2psip-disco-03.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2011 20:18:05 -0000 Hello again, and finally, a new version of our draft for Distributed Conference Control (DisCo), link: http://www.ietf.org/id/draft-knauf-p2psip-disco-03.txt regards, Alexander Change Log 1. DisCo-Registration uses now only the USER-CHAIN-ACL access control policy. 2. Adapted mechanisms for storing DisCo-Registrations to new requirements of Shared Resources draft [I-D.knauf-p2psip-share] A new version of I-D, draft-knauf-p2psip-disco-03.txt has been successfully submitted by Alexander Knauf and posted to the IETF repository. Filename: draft-knauf-p2psip-disco Revision: 03 Title: A RELOAD Usage for Distributed Conference Control (DisCo) Creation date: 2011-07-11 WG ID: Individual Submission Number of pages: 46 Abstract: This document defines a RELOAD Usage for Distributed Conference Control (DisCo) with SIP. DisCo preserves conference addressing through a single SIP URI by splitting its semantic of identifier and locator using a new Kind data structure. Conference members are enabled to select conference controllers based on proximity awareness and to recover from failures of indivihttp://www.ietf.org/id/draft-knauf-p2psip-share-01.txtdual resource instances. DisCo proposes call delegation to balance the load at focus peers. The IETF Secretariat From peng.yonglin@zte.com.cn Mon Jul 11 18:36:05 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9FC11E83FD; Mon, 11 Jul 2011 18:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.705 X-Spam-Level: X-Spam-Status: No, score=-92.705 tagged_above=-999 required=5 tests=[AWL=2.516, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbjQhEtXG2ra; Mon, 11 Jul 2011 18:36:04 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id BDD6811E83FE; Mon, 11 Jul 2011 18:36:03 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 48643465113155; Tue, 12 Jul 2011 09:33:27 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 17394.3465113155; Tue, 12 Jul 2011 09:35:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6C1ZnDY035798; Tue, 12 Jul 2011 09:35:53 +0800 (GMT-8) (envelope-from peng.yonglin@zte.com.cn) To: p2psip@ietf.org, opsawg@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: peng.yonglin@zte.com.cn Date: Tue, 12 Jul 2011 09:35:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-12 09:35:54, Serialize complete at 2011-07-12 09:35:54 Content-Type: multipart/alternative; boundary="=_alternative 0008CA55482578CB_=" X-MAIL: mse01.zte.com.cn p6C1ZnDY035798 Cc: hao.zhenwu@zte.com.cn, meng.yu@zte.com.cn Subject: [P2PSIP] SNMP Usage for RELOAD draft is updated X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2011 01:36:05 -0000 This is a multipart message in MIME format. --=_alternative 0008CA55482578CB_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIA0KDQpUaGUgdXBkYXRlZCBkcmFmdCBjYW4gYmUgYWNjZXNzZWQgYXQgDQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wZW5nLXAycHNpcC1zbm1wLTAyDQoNClRoZSBtYWpvciBj aGFuZ2UgaXMgYWRkaW5nIHRoZSBpbnRyb2R1Y3Rpb24gYWJvdXQgdGhlIHNlY3VyaXR5IHNvbHV0 aW9ucyANCmluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBjaGFwdGVyLg0KDQpBbnkgY29t bWVudHMgYXJlIHdlbGVjb21lLiANCg0KVGhhbmtzLg0KDQoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqDQrTyiC8/qO6cGVuZy55b25nbGluQHp0ZS5jb20u Y24NCsTaIM/fo7o4MTU0Mw0KzeIgz9+jujAyNS01Mjg3MTU0Mw0KytYgu/qjujEzNzc2NjM3Mjc0 DQq0qyDV5qO6MDI1LTUyODcyMTg3DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBv ZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBj b25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWlu dGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVu dHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBm aWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNv bGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5 IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Ig cGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4 cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRl ci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5 IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0008CA55482578CB_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCA8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSB1cGRhdGVkIGRyYWZ0IGNhbiBi ZSBhY2Nlc3NlZCBhdA0KPC9mb250PjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXBlbmctcDJwc2lwLXNubXAtMDIiPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 InNhbnMtc2VyaWYiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlbmctcDJwc2lw LXNubXAtMDI8L2ZvbnQ+PC9hPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5UaGUgbWFqb3IgY2hhbmdlIGlzIGFkZGluZyB0aGUgaW50cm9kdWN0aW9uDQphYm91dCB0 aGUgc2VjdXJpdHkgc29sdXRpb25zIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBjaGFw dGVyLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QW55 IGNvbW1lbnRzIGFyZSB3ZWxlY29tZS4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5UaGFua3MuPGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCtPKILz+o7pwZW5nLnlvbmdsaW5AenRl LmNvbS5jbjxicj4NCsTaIM/fo7o4MTU0Mzxicj4NCs3iIM/fo7owMjUtNTI4NzE1NDM8YnI+DQrK 1iC7+qO6MTM3NzY2MzcyNzQ8YnI+DQq0qyDV5qO6MDI1LTUyODcyMTg3PGJyPg0KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvZm9udD4NCjxicj48cHJl Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7 VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJz cDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJz cDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50 cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZu YnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNw O3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZu YnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4N ClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNt aXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDth bmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7 dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZu YnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNw O2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmln aW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdz Jm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZu YnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0K VGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2Zv ciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtB bnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0008CA55482578CB_=-- From peng.yonglin@zte.com.cn Mon Jul 11 18:59:49 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0504911E8407; Mon, 11 Jul 2011 18:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.448 X-Spam-Level: X-Spam-Status: No, score=-91.448 tagged_above=-999 required=5 tests=[AWL=-1.258, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0-Mbot6mmCX; Mon, 11 Jul 2011 18:59:48 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 72C4711E8277; Mon, 11 Jul 2011 18:59:47 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48643465113155; Tue, 12 Jul 2011 09:58:17 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.5408727031; Tue, 12 Jul 2011 09:59:29 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6C1xONr061567; Tue, 12 Jul 2011 09:59:24 +0800 (GMT-8) (envelope-from peng.yonglin@zte.com.cn) In-Reply-To: <20110708094957.GA85730@elstar.local> To: Juergen Schoenwaelder MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: peng.yonglin@zte.com.cn Date: Tue, 12 Jul 2011 09:59:23 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-12 09:59:24, Serialize complete at 2011-07-12 09:59:24 Content-Type: multipart/alternative; boundary="=_alternative 000AF21F482578CB_=" X-MAIL: mse01.zte.com.cn p6C1xONr061567 Cc: p2psip@ietf.org, hao.zhenwu@zte.com.cn, meng.yu@zte.com.cn, opsawg@ietf.org Subject: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ILTwuLQ6IFJlOiBbT1BTQVdHXSBXZSBo?= =?gb2312?b?YXZlIHN1Ym1pdHRlZCBhIGRyYWZ0cyBvbiBTTk1QIHVzYWdlcyBmb3IgUDJQ?= =?gb2312?b?IG5ldHdvcmtzLiBXZSB3b3VsZCBsaWtlIHRvIGdldCBzb21lIHN1Z2dlc3Rp?= =?gb2312?b?b25zIGZyb20gU05NUCBleHBlcnRzIG9uIHRoZSBzY2VuYXJpbyBhbmQgZGVz?= =?gb2312?b?aWduIGZvciBQMlAgbmV0d29yayBtYW5hZ2VtZW50LiBUaGUgbGluayB0byB0?= =?gb2312?b?aGUgZHJhZnQgaXMgaW4gdGhlIGJvZHkgb2YgdGhpcyBlbWFpbC4gdGhhbmtz?= =?gb2312?b?o6E=?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2011 01:59:49 -0000 This is a multipart message in MIME format. --=_alternative 000AF21F482578CB_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhlIHNvbHV0aW9uIGluIHRoaXMgUkZDIGlzIGdvb2QsIHdlIHdpbGwgdGhpbmsgb3ZlciBpdC4g DQpJbiBTTk1QIFVzYWdlIGZvciBSRUxPQUQsIHdlIGFsc28gaW50cm9kdWNlIHRoZSBzb2x1dGlv biB0aGF0IGV4Y2hhbmdlcyANCnNlY3JldCBrZXlzIGJ5IHRoZSBjZXJ0aWZpY2F0ZSBvZiBSRUxP QUQuIFdlIGhvcGUgeW91ciBzdWdnZXN0aW9ucy4gDQpUaGFua3MuIA0KDQoNCioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCtPKILz+o7pwZW5nLnlvbmds aW5AenRlLmNvbS5jbg0KxNogz9+jujgxNTQzDQrN4iDP36O6MDI1LTUyODcxNTQzDQrK1iC7+qO6 MTM3NzY2MzcyNzQNCrSrINXmo7owMjUtNTI4NzIxODcNCioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KDQoNCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8 ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiANCjIwMTEtMDctMDggMTc6NDkN CsfrtPC4tCC4+A0KSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2Jz LXVuaXZlcnNpdHkuZGU+DQoNCg0KytW8/sjLDQpwZW5nLnlvbmdsaW5AenRlLmNvbS5jbg0Ks63L zQ0KaGFvLnpoZW53dUB6dGUuY29tLmNuLCBsaS5saWNodW4xQHp0ZS5jb20uY24sIG9wc2F3Z0Bp ZXRmLm9yZywgDQpwMnBzaXBAaWV0Zi5vcmcNCtb3zOINClJlOiC08Li0OiBSZTogW09QU0FXR10g V2UgaGF2ZSBzdWJtaXR0ZWQgYSBkcmFmdHMgb24gU05NUCB1c2FnZXMgZm9yIFAyUCANCm5ldHdv cmtzLiBXZSB3b3VsZCBsaWtlIHRvIGdldCBzb21lIHN1Z2dlc3Rpb25zIGZyb20gU05NUCBleHBl cnRzIG9uIHRoZSANCnNjZW5hcmlvIGFuZCBkZXNpZ24gZm9yIFAyUCBuZXR3b3JrIG1hbmFnZW1l bnQuIFRoZSBsaW5rIHRvIHRoZSBkcmFmdCBpcyANCmluIHRoZSBib2R5IG9mIHRoaXMgZW1haWwu IHRoYW5rc6OhDQoNCg0KDQoNCg0KDQpPbiBGcmksIEp1bCAwOCwgMjAxMSBhdCAwNToyODozNlBN ICswODAwLCBwZW5nLnlvbmdsaW5AenRlLmNvbS5jbiB3cm90ZToNCg0KPiBJcyB0aGUgc3RhbmRh cmQgd2hpY2ggeW91IHJlZmVyIHRvIFJGQzU5NTMgPw0KDQpZZXMuIFRoZSByZXZpc2lvbiB0aGF0 IGdvdCBhcHByb3ZlZCBhcyBEcmFmdCBTdGFuZGFyZCBpcyBzaXR0aW5nIGluDQp0aGUgUkZDIGVk aXRvciBxdWV1ZS4gRm9yIG1vcmUgZGV0YWlscyBhYm91dCB0aGUgaW50ZXJvcGVyYWJpbGl0eQ0K dGVzdHMsIHNlZSA8ZHJhZnQtc2Nob2Vudy1pc21zLWludGVyb3BlcmFiaWxpdHktcmVwb3J0LTAx LnR4dD4uDQoNCi9qcw0KDQotLSANCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFj b2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAg ICAgIENhbXB1cyBSaW5nIDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEg MjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCg0K DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mg b3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJl Y2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFu ZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21t dW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRl ZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlz IG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2Fn ZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0g c3lzdGVtLg0K --=_alternative 000AF21F482578CB_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBzb2x1dGlvbiBpbiB0aGlz IFJGQyBpcyBnb29kLCB3ZQ0Kd2lsbCB0aGluayBvdmVyIGl0LiA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluIFNOTVAgVXNhZ2UgZm9yIFJFTE9BRCwgd2UgYWxz byBpbnRyb2R1Y2UNCnRoZSBzb2x1dGlvbiB0aGF0IGV4Y2hhbmdlcyBzZWNyZXQga2V5cyBieSB0 aGUgY2VydGlmaWNhdGUgb2YgUkVMT0FELiBXZQ0KaG9wZSB5b3VyIHN1Z2dlc3Rpb25zLiA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcy4gPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0K08ogvP6junBlbmcu eW9uZ2xpbkB6dGUuY29tLmNuPGJyPg0KxNogz9+jujgxNTQzPGJyPg0KzeIgz9+jujAyNS01Mjg3 MTU0Mzxicj4NCsrWILv6o7oxMzc3NjYzNzI3NDxicj4NCrSrINXmo7owMjUtNTI4NzIxODc8YnI+ DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPC9mb250 Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkp1ZXJnZW4g U2Nob2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlJmd0 OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTA3 LTA4IDE3OjQ5PC9mb250Pg0KPHRhYmxlIGJvcmRlcj4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIGJn Y29sb3I9d2hpdGU+DQo8ZGl2IGFsaWduPWNlbnRlcj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+x+u08Li0ILj4PGJyPg0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndh ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7PC9mb250PjwvZGl2PjwvdGFibGU+DQo8YnI+ DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7I yzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+cGVuZy55 b25nbGluQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmhhby56aGVud3VAenRlLmNvbS5j biwgbGkubGljaHVuMUB6dGUuY29tLmNuLA0Kb3BzYXdnQGlldGYub3JnLCBwMnBzaXBAaWV0Zi5v cmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiC08Li0OiBSZTogW09QU0FXR10gV2UgaGF2ZSBzdWJt aXR0ZWQNCmEgZHJhZnRzIG9uIFNOTVAgdXNhZ2VzIGZvciBQMlAgbmV0d29ya3MuIFdlIHdvdWxk IGxpa2UgdG8gZ2V0IHNvbWUgc3VnZ2VzdGlvbnMNCmZyb20gU05NUCBleHBlcnRzIG9uIHRoZSBz Y2VuYXJpbyBhbmQgZGVzaWduIGZvciBQMlAgbmV0d29yayBtYW5hZ2VtZW50Lg0KVGhlIGxpbmsg dG8gdGhlIGRyYWZ0IGlzIGluIHRoZSBib2R5IG9mIHRoaXMgZW1haWwuIHRoYW5rc6OhPC9mb250 PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3Rh YmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5PbiBG cmksIEp1bCAwOCwgMjAxMSBhdCAwNToyODozNlBNICswODAwLCBwZW5nLnlvbmdsaW5AenRlLmNv bS5jbg0Kd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBJcyB0aGUgc3RhbmRhcmQgd2hpY2ggeW91IHJl ZmVyIHRvIFJGQzU5NTMgPzxicj4NCjxicj4NClllcy4gVGhlIHJldmlzaW9uIHRoYXQgZ290IGFw cHJvdmVkIGFzIERyYWZ0IFN0YW5kYXJkIGlzIHNpdHRpbmcgaW48YnI+DQp0aGUgUkZDIGVkaXRv ciBxdWV1ZS4gRm9yIG1vcmUgZGV0YWlscyBhYm91dCB0aGUgaW50ZXJvcGVyYWJpbGl0eTxicj4N CnRlc3RzLCBzZWUgJmx0O2RyYWZ0LXNjaG9lbnctaXNtcy1pbnRlcm9wZXJhYmlsaXR5LXJlcG9y dC0wMS50eHQmZ3Q7Ljxicj4NCjxicj4NCi9qczxicj4NCjxicj4NCi0tIDxicj4NCkp1ZXJnZW4g U2Nob2Vud2FlbGRlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEphY29icyBV bml2ZXJzaXR5DQpCcmVtZW4gZ0dtYkg8YnI+DQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2FtcHVzIFJpbmcgMSwgMjg3NTkNCkJyZW1lbiwgR2Vy bWFueTxicj4NCkZheDogJm5ic3A7ICs0OSA0MjEgMjAwIDMxMDMgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZsdDtodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLyZndDs8YnI+DQo8 YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9u Jm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJz cDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xl bHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdh bml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMm bmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUm bmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVj eSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7 ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2Nv bW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2Fu ZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQm bmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3Nv bGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZu YnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDty ZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVh c2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4m bmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDto YXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQm bmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8 L3ByZT4= --=_alternative 000AF21F482578CB_=-- From davidbryan@gmail.com Tue Jul 12 14:19:41 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58DF11E8080 for ; Tue, 12 Jul 2011 14:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMx1Zg8FBxr3 for ; Tue, 12 Jul 2011 14:19:41 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 207AD11E8077 for ; Tue, 12 Jul 2011 14:19:41 -0700 (PDT) Received: by qyk9 with SMTP id 9so2499998qyk.10 for ; Tue, 12 Jul 2011 14:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=Fd9/+m03gy+oZV1xqs2PDN1IVNU98C/NG6fFYvPeKHM=; b=Eo+CEqkIWzeO/F48XvK+TNva56BgsX7+pCkzZxYH6iT5lJFzgkZakAZHsRSHaTJGJA OWp5S8wx98bo+octpeV0oEGZZTkpv0TPfqtJ19PsQka6XEonKXLpz5rdP0NL7ckgoSvE wrMxQyundpzwj+tmwooBWwi7t9IMbhIZV+y1g= MIME-Version: 1.0 Received: by 10.229.229.195 with SMTP id jj3mr362419qcb.232.1310505580548; Tue, 12 Jul 2011 14:19:40 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.229.229.135 with HTTP; Tue, 12 Jul 2011 14:19:40 -0700 (PDT) Date: Tue, 12 Jul 2011 14:19:40 -0700 X-Google-Sender-Auth: wbyqctCX69-GCIVsWZA7r0GCtfs Message-ID: From: "David A. Bryan" To: P2PSIP WG Content-Type: multipart/alternative; boundary=0016e689702a9ad4c904a7e5db81 Subject: [P2PSIP] Draft agenda posted X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2011 21:19:41 -0000 --0016e689702a9ad4c904a7e5db81 Content-Type: text/plain; charset=ISO-8859-1 The draft agenda for the P2PSIP session has been posted: http://www.ietf.org/proceedings/81/agenda/p2psip.txt Please take a look and let us know if we missed a request or you have any comments. David and Brian (as chairs) --0016e689702a9ad4c904a7e5db81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The draft agenda for the P2PSIP session has been posted:

http://www.ietf.org/p= roceedings/81/agenda/p2psip.txt

Please take a look and let us kn= ow if we missed a request or you have any comments.

David and Brian (as chairs)
--0016e689702a9ad4c904a7e5db81-- From zongning@huawei.com Tue Jul 12 18:15:30 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2938811E80DF for ; Tue, 12 Jul 2011 18:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxCWh0cmbM9M for ; Tue, 12 Jul 2011 18:15:29 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7A38911E80D9 for ; Tue, 12 Jul 2011 18:15:29 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO80050TZHQ5K@szxga05-in.huawei.com> for p2psip@ietf.org; Wed, 13 Jul 2011 09:15:27 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO80046FZHQIZ@szxga05-in.huawei.com> for p2psip@ietf.org; Wed, 13 Jul 2011 09:15:26 +0800 (CST) Received: from z-20684ca876cc4 (servers.szgwbn.net [211.162.76.115]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LO8006U8ZHGZ0@szxml12-in.huawei.com>; Wed, 13 Jul 2011 09:15:26 +0800 (CST) Date: Wed, 13 Jul 2011 09:15:39 +0800 From: Ning Zong To: "David A. Bryan" , P2PSIP WG Message-id: <0LO8006UHZHLZ0@szxml12-in.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 5.0 [en] Content-type: multipart/alternative; boundary="Boundary_(ID_IuN0giCLR/jKumao46KJyQ)" Subject: Re: [P2PSIP] Draft agenda posted X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jul 2011 01:15:30 -0000 This is a multi-part message in MIME format. --Boundary_(ID_IuN0giCLR/jKumao46KJyQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, David, We have requested a time slot for Direct Response Routing (DRR) and Relay Peer Routing (RPR) drafts, but I can not see them on the draft agenda. Thanks. BR, Ning Zong The draft agenda for the P2PSIP session has been posted: http://www.ietf.org/proceedings/81/agenda/p2psip.txt Please take a look and let us know if we missed a request or you have any comments. David and Brian (as chairs) --Boundary_(ID_IuN0giCLR/jKumao46KJyQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi, David,
 
We have requested a time slot for Direct Response Routing (DRR) and Relay Peer Routing (RPR) drafts, but I can not see them on the draft agenda.
Thanks.
 
BR,
Ning Zong
 
The draft agenda for the P2PSIP session has been posted:

http://www.ietf.org/proceedings/81/agenda/p2psip.txt

Please take a look and let us know if we missed a request or you have any comments.

David and Brian (as chairs)
--Boundary_(ID_IuN0giCLR/jKumao46KJyQ)-- From fengkai_sunny@139.com Tue Jul 12 19:18:25 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EEB9E8025 for ; Tue, 12 Jul 2011 19:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.331 X-Spam-Level: ** X-Spam-Status: No, score=2.331 tagged_above=-999 required=5 tests=[AWL=-0.518, BAYES_00=-2.599, FR_IMPORT_CSS=1.889, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gIoRvMwhNk8 for ; Tue, 12 Jul 2011 19:18:25 -0700 (PDT) Received: from n9-48.mail.139.com (n9-48.mail.139.com [221.176.9.48]) by ietfa.amsl.com (Postfix) with ESMTP id AFB039E8023 for ; Tue, 12 Jul 2011 19:18:24 -0700 (PDT) Received: from Bumblebee (unknown [218.206.178.250]) by cmapp-4-08 (Coremail) with SMTP id JqwQrJC7z_RlAB1OM51MAA--.58272S2; Wed, 13 Jul 2011 10:18:14 +0800 (CST) Date: Wed, 13 Jul 2011 10:18:13 +0800 From: "=?utf-8?B?5Yav5oG6?=" To: "David A. Bryan" ,"P2PSIP WG" X-Mailer: NetEase Flash Mail 2.0.2.30 X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="====003__MESSAGE__ID__54yg6f6h6y456345====" X-CM-TRANSID: JqwQrJC7z_RlAB1OM51MAA--.58272S2 X-Coremail-Antispam: 1UD129KBjvdXoWrZw1xGF43Aw45GFWfGrW3ZFb_yoW3JwcE9F 48KwsxXFWrXFWDWFsayayUKFWqq3sav3W3C3Z8XrW7C34jga13Gws7GanFgF1xAa98WFn5 uFZ3u3s3t3saqjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUjakYjxAI6xkYrwAYjxAI6xAIw28IcVW8Ww4lb7IF0VCFI7km07C2 6c804VAKzcIF0wAYjsxI4VWxJwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG6r Wj6s0DM2k07cx0zVAaqwAqjxCE34x0Y48IcwAqx4xG67k08I80eVWUJVW8JwAqx4xG62kE wI0EbcxfMc02F40Ew4AK048IF2xKxVWUJVW8JwAv7VCjz48v1sIEY20_AF4lYx0E2Ix0cI 8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IE b7IF0Fy264kE64k0F24lw4CEF2IF47xS0VAv8wCF04k20xvY0x0EwIxGrwCF04k20xvE74 AGY7Cv6cx26F1xMxCIbVA2zIxYr2IEbsI20wC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI 7VAKI48JYxBIdaVFxhVjvjDU0xZFpf9x07jnL05UUUUU= Message-Id: <4E1D0068.0402B8.30300@n9-48.mail.139.com> X-CM-SenderInfo: Subject: [P2PSIP] =?utf-8?b?5Zue5aSNOiAgIERyYWZ0IGFnZW5kYSBwb3N0ZWQ=?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jul 2011 02:18:25 -0000 --====003__MESSAGE__ID__54yg6f6h6y456345==== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDaGFpciwNCg0KSSBhbSBzb3JyeSBpdCBpcyBhIGxpdHRsZSBsYXRlIHRvIHNlbmQgdGhp cyBhZ2VuZGEgcmVxdWVzdC4NCg0KV2Ugd291bGQgbGlrZSB0byByZXF1ZXN0IGZvciBhIHNob3J0 IHNsb3QgYXJvdW5kIDEwbWlucyBmb3IgcmVwcmVzZW50aW5nIG91ciBpZGVhcyBmb3IgdGhlIG9u ZSBob3AgbG9va3VwcyBhbGdvcml0aG0gcGx1Z2luIGZvciBSRUxPQUQuDQoNClRoZSByZWxhdGVk IGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDoNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtcGVuZy1wMnBzaXAtb25lLWhvcC1wbHVnaW4vDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2gh DQoNCg0KMjAxMS0wNy0xMw0KDQoNCg0K5Yav5oG6DQoNCg0KDQrlj5Hku7bkuro6ICJEYXZpZCBB LiBCcnlhbiIgPGRicnlhbkBldGhlcm5vdC5vcmc+DQrlj5HpgIHml7bpl7Q6IDIwMTEtMDctMTMg MDU6MTkNCuS4uyDpopg6IFtQMlBTSVBdIERyYWZ0IGFnZW5kYSBwb3N0ZWQNCuaUtuS7tuS6ujog UDJQU0lQIFdHIDxwMnBzaXBAaWV0Zi5vcmc+DQoNCg0KDQpUaGUgZHJhZnQgYWdlbmRhIGZvciB0 aGUgUDJQU0lQIHNlc3Npb24gaGFzIGJlZW4gcG9zdGVkOg0KDQpodHRwOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzgxL2FnZW5kYS9wMnBzaXAudHh0DQoNClBsZWFzZSB0YWtlIGEgbG9vayBh bmQgbGV0IHVzIGtub3cgaWYgd2UgbWlzc2VkIGEgcmVxdWVzdCBvciB5b3UgaGF2ZSBhbnkgY29t bWVudHMuDQoNCkRhdmlkIGFuZCBCcmlhbiAoYXMgY2hhaXJzKQ== --====003__MESSAGE__ID__54yg6f6h6y456345==== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPFNUWUxFIHR5cGU9dGV4dC9jc3M+IDwhLS1AaW1wb3J0IHVy bChFOlxQcm9ncmFtIEZpbGVzXE5ldGVhc2Vc572R5piT6Zeq55S16YKuXFxkYXRhXHNjcm9sbGJh ci5jc3MpOyAtLT48L1NUWUxFPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9 dXRmLTgiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPFNUWUxFPkJMT0NLUVVPVEV7bWFyZ2lu LVRvcDogMHB4OyBtYXJnaW4tQm90dG9tOiAwcHg7IG1hcmdpbi1MZWZ0OiAyZW19OyA8L1NUWUxF Pg0KDQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250ZW50PSJNU0hUTUwgOS4wMC44MTEyLjE2NDMw Ij48QkFTRSANCnRhcmdldD1fYmxhbms+PC9IRUFEPg0KPEJPRFkgDQpzdHlsZT0iQk9SREVSLVJJ R0hULVdJRFRIOiAwcHg7IE1BUkdJTjogMTJweDsgQk9SREVSLVRPUC1XSURUSDogMHB4OyBCT1JE RVItQk9UVE9NLVdJRFRIOiAwcHg7IEJPUkRFUi1MRUZULVdJRFRIOiAwcHgiIA0KbWFyZ2luaGVp Z2h0PSIwIiBtYXJnaW53aWR0aD0iMCI+PFNUQVRJT05FUlk+DQo8RElWPg0KPERJVj48Rk9OVCBj b2xvcj0jMDAwMDAwIHNpemU9ND5EZWFyIENoYWlyLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT00PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxCTE9DS1FVT1RFIHN0eWxlPSJNQVJHSU4tUklH SFQ6IDBweCIgZGlyPWx0cj4NCiAgPERJVj48Rk9OVCBzaXplPTQ+SSBhbSBzb3JyeSBpdCBpcyBh IGxpdHRsZSBsYXRlIHRvIHNlbmQgdGhpcyBhZ2VuZGEgDQogIHJlcXVlc3QuPC9GT05UPjwvRElW PjwvQkxPQ0tRVU9URT4NCjxESVY+PEZPTlQgc2l6ZT00PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxC TE9DS1FVT1RFIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCIgZGlyPWx0cj4NCiAgPERJVj48Rk9O VCBzaXplPTQ+V2Ugd291bGQgbGlrZSB0byByZXF1ZXN0IGZvciBhIHNob3J0IHNsb3QgYXJvdW5k IDEwbWlucyBmb3IgDQogIHJlcHJlc2VudGluZyBvdXIgaWRlYXMgZm9yIHRoZSBvbmUgaG9wIGxv b2t1cHMgYWxnb3JpdGhtIHBsdWdpbiBmb3IgDQogIFJFTE9BRC48L0ZPTlQ+PC9ESVY+DQogIDxE SVY+PEZPTlQgc2l6ZT00PjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTQ+ VGhlIHJlbGF0ZWQgZHJhZnQgY2FuIGJlIGZvdW5kIGF0OjwvRk9OVD48L0RJVj4NCiAgPERJVj48 Rk9OVCBzaXplPTQ+PEEgDQogIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtcGVuZy1wMnBzaXAtb25lLWhvcC1wbHVnaW4vIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXBlbmctcDJwc2lwLW9uZS1ob3AtcGx1Z2luLzwvQT48L0ZPTlQ+PC9E SVY+DQogIDxESVY+PEZPTlQgc2l6ZT00PjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9O VCBzaXplPTQ+VGhhbmsgeW91IHZlcnkgbXVjaCE8L0ZPTlQ+PC9ESVY+PC9CTE9DS1FVT1RFPg0K PERJVj48Rk9OVCBzaXplPTQ+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0j MDAwMDAwIHNpemU9NCBmYWNlPeWNjuaWh+alt+S9kz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW IGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9I2MwYzBjMCBzaXplPTIgDQpmYWNlPVZlcmRhbmE+MjAx MS0wNy0xMzwvRk9OVD48L0RJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPEhSIHN0eWxl PSJXSURUSDogMTIycHg7IEhFSUdIVDogMnB4IiBhbGlnbj1sZWZ0IFNJWkU9Mj4NCg0KPERJVj48 Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNQQU4gDQppZD1fRmxhc2hT aWduTmFtZT7lhq/mgbo8L1NQQU4+PC9GT05UPjwvRElWPjwvRk9OVD4NCjxESVY+DQo8SFI+DQo8 L0RJVj4NCjxESVY+5Y+R5Lu25Lq6OiAiRGF2aWQgQS4gQnJ5YW4iICZsdDtkYnJ5YW5AZXRoZXJu b3Qub3JnJmd0OzwvRElWPg0KPERJVj7lj5HpgIHml7bpl7Q6IDIwMTEtMDctMTMgMDU6MTk8L0RJ Vj4NCjxESVY+5Li7IOmimDogW1AyUFNJUF0gRHJhZnQgYWdlbmRhIHBvc3RlZDwvRElWPg0KPERJ Vj7mlLbku7bkuro6IFAyUFNJUCBXRyAmbHQ7cDJwc2lwQGlldGYub3JnJmd0OzwvRElWPg0KPERJ Vj48QlI+PEJSPjwvRElWPlRoZSBkcmFmdCBhZ2VuZGEgZm9yIHRoZSBQMlBTSVAgc2Vzc2lvbiBo YXMgYmVlbiANCnBvc3RlZDo8QlI+PEJSPjxBIA0KaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9w cm9jZWVkaW5ncy84MS9hZ2VuZGEvcDJwc2lwLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9j ZWVkaW5ncy84MS9hZ2VuZGEvcDJwc2lwLnR4dDwvQT48QlI+PEJSPlBsZWFzZSANCnRha2UgYSBs b29rIGFuZCBsZXQgdXMga25vdyBpZiB3ZSBtaXNzZWQgYSByZXF1ZXN0IG9yIHlvdSBoYXZlIGFu eSANCmNvbW1lbnRzLjxCUj48QlI+RGF2aWQgYW5kIEJyaWFuIChhcyANCmNoYWlycyk8QlI+PC9E SVY+PC9TVEFUSU9ORVJZPjwvQk9EWT48L0hUTUw+ --====003__MESSAGE__ID__54yg6f6h6y456345====-- From petithug@acm.org Wed Jul 13 09:35:04 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B9B11E8160 for ; Wed, 13 Jul 2011 09:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BS5pFMW3HMaP for ; Wed, 13 Jul 2011 09:35:04 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id E9A1021F8642 for ; Wed, 13 Jul 2011 09:35:03 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 007C42199E; Wed, 13 Jul 2011 18:33:34 +0200 (CEST) Message-ID: <4E1DC934.4080701@acm.org> Date: Wed, 13 Jul 2011 09:35:00 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: Alexander Knauf References: <20110711195340.1259.23073.idtracker@ietfa.amsl.com> <4E1B5698.3050806@haw-hamburg.de> In-Reply-To: <4E1B5698.3050806@haw-hamburg.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Fwd: New Version Notification for draft-knauf-p2psip-share-01.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jul 2011 16:35:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alexander, Just a quick question on this draft: Section 3 states that resource_name is the initial field and user_name is the second field in Kinds that will use the USER-CHAIN-ACL ACP, but the AccessControlListItem structure does not follow this rule as the first field is length. This is still implementable as the ACP code needs anyway to know how to parse the AccessControlListItem structure, but that requires it to be processed differently from the other shared resources. Was that the intent? Thanks. On 07/11/2011 01:01 PM, Alexander Knauf wrote: > Hi all, > > we just uploaded a new version of our draft for Shared Resources in RELOAD. > Please take a look > > http://www.ietf.org/id/draft-knauf-p2psip-share-01.txt > > Best regards, > > Alexander > > Change Log: > > 1. Integrated the USER-PATTERN-MATCH access policy into USER-CHAIN- > MATCH > > 2. Access Control List Kind uses USER-CHAIN-ACL exclusively > > 3. Resources to be shared use USER-CHAIN-ACL exclusively > > 4. More precise specification of mandatory User_name and > Resource_name fields for Shared Resources > > 5. Added mechanism for isolating stored data to prevent race > conditions while concurrent storing > > 6. XML Extension for variable resource names uses its own namespace > > 7. Many editorial improvements > > > > A new version of I-D, draft-knauf-p2psip-share-01.txt has been successfully > submitted by Alexander Knauf and posted to the IETF repository. > > Filename: draft-knauf-p2psip-share > Revision: 01 > Title: A Usage for Shared Resources in RELOAD (ShaRe) > Creation date: 2011-07-11 > WG ID: Individual Submission > Number of pages: 22 > > Abstract: > This document defines a RELOAD Usage for managing shared write access > to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic > primitive for enabling various coordination and notification schemes > among distributed peers. Access in ShaRe is controlled by a > hierarchical trust delegation scheme maintained within an access > list. A new USER-CHAIN-ACL access policy allows authorized peers to > write a Shared Resource without owning its corresponding certificate. > This specification also adds mechanisms to store Resources with a > variable name which is useful whenever peer-independent rendezvous > processes are required. > > > > > The IETF Secretariat - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4dyTIACgkQ9RoMZyVa61fRwwCfa2ogfZPEyaWVjed2IVJeNVKd xZYAmgIn5io/h79UCXRiWLusQMvejS+d =4mR2 -----END PGP SIGNATURE----- From wang.wei108@zte.com.cn Wed Jul 13 23:23:55 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F5C21F8AB9; Wed, 13 Jul 2011 23:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.993 X-Spam-Level: X-Spam-Status: No, score=-96.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRyvnxi6gvGc; Wed, 13 Jul 2011 23:23:54 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7C63821F8508; Wed, 13 Jul 2011 23:23:50 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48643465113155; Thu, 14 Jul 2011 14:22:14 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.4995755854; Thu, 14 Jul 2011 14:21:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6E6LL0c019315; Thu, 14 Jul 2011 14:21:21 +0800 (GMT-8) (envelope-from wang.wei108@zte.com.cn) In-Reply-To: <8D213570E6754D439F01F81DB80966C0@davidPC> To: "David Harrington" MIME-Version: 1.0 X-KeepSent: B4001D81:C8A4B402-482578CD:0021CC3E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.wei108@zte.com.cn Date: Thu, 14 Jul 2011 14:19:49 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-14 14:21:22, Serialize complete at 2011-07-14 14:21:22 Content-Type: multipart/alternative; boundary="=_alternative 0022EB5D482578CD_=" X-MAIL: mse01.zte.com.cn p6E6LL0c019315 Cc: hao.zhenwu@zte.com.cn, "opsawg@ietf.org" , p2psip@ietf.org Subject: [P2PSIP] =?gb2312?b?tPC4tDogQW4gU05NUCBVc2FnZSBmb3IgUkVMT0FE?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jul 2011 06:23:55 -0000 This is a multipart message in MIME format. --=_alternative 0022EB5D482578CD_= Content-Type: text/plain; charset="US-ASCII" Hi David, Thanks for your careful review and useful advises. We will try to resolve all these problems when developing the detailed protocols. Our goal is to adopt SNMP in management of network equipments deployed based on P2P technology. However, we lack expertise in SNMPv3. Therefore, we would like to invite experts from opsawg to build this protocol together. If anyone would like to look into this problem, please feel free to contact us. For the name of "An SNMP usage for RELOAD", we follow the convention of RELOAD, where the applications supported by RELOAD are called RELOAD usages. We use the RELOAD protocol for SNMP manager discovery and connection setup. So, we choose to name it as a "usage". Thanks Wang Wei "David Harrington" writes 2011-07-12 21:54:15: > Hi, > > > The term "An SNMP Usage" piqued my interest, because it seems, in some > ways, incorrect terminology from an SNMP perspective. > I might recommend a title of "How to Use SNMP to manage nodes in a > RELOAD environment" > > I am an Area Director, and a member of the MIB Doctors, the Operations > directorate, the Security directorate, and (by default) the Transport > and Services directorate, and an editor for SNMPv3 documents. > So I took a quick look at this proposal, and have a few (fairly major) > comments. > Don't be discouraged by my comments; but be aware that there are some > serious issues that need to be considered for your proposal. > > 1) Use SNMPv3 terminology > Apparently, you come from the RELOAD side of things, not the SNMP > side. > Your text doesn't use the common SNMP terminology for various > SNMP-related things. > You will have a better chance of success if you describe SNMP-related > things using the normal SNMPv3 terminology. > This isn't critical; your ideas seem reasonable, but since you don't > use the standard terminology, you might mean slightly different things > than what it would mean if you used the standard terminology. > > (I don't have a RELOAD background, so some of my comments might seem > wrong because I don't know the RELOAD concepts and terminology. Now > you'll understand my point ;-) > > 2) Use SNMPv3 > It is important to make sure you are talking about SNMPv3. SNMPv1 and > SNMPv2 have been declared Historic, and no new work should be done > using those protocols. However, any MIB module should be able to be > used with any version of SNMP. > My concern is that SNMPv3 has assumptions about security associations, > and you need to make sure those are considered. > > 3) Use MIB modules > You are talking about the manager getting information from a managed > node. The right way to approach "information from a node" is to define > a MIB module that contains the information for the managed node. SNMP > (typically) only carries information from MIB modules. So when you > talk about the information about a node, you probably should talk > about a MIB module at the managed node. If the functionality is > different at the O-node and R-node, you might need different MIB > modules, or have one MIB module that supports both roles. > > 4) Use SNMP EngineID > You talk about a Node ID in the RELOAD network. There is also an > identifier in the SNMP network, called the SnmpEngineID. It might be > possible to use the SnmpEngineID as a RELOAD Node ID, but SnmpEngineID > is not user-friendly. SnmpEngineID is needed for two SNMP endpoints to > talk to each other. So you might want to have the SnmpEngineID > included in the Registration information. > > Typically, two SNMP nodes need to be pre-configured to talk because > SNMP has access control for the MIB database, and the user needs to be > configured to have access to the database. So a discovery mechanism to > determine where to find a manager might be superfluous, since a > security association between the manager and managed node might need > to be pre-established anyway. > > I am not trying to convince you not to do this discovery work, but to > be aware it might not make sense. OTOH, a mechanism that would allow > an agent to find its manager, especially in a NAT environment, could > be very useful for SNMP. See also RFC5343. > > 5) Consider using PROXY-MIB > SNMPv3 uses hop-to-hop security, but the management is end-to-end. > SnmpEngeinID is used both during authentication/authorization at a > hop-by-hop level, and is contained in the SNMP message to identify the > source node for the information. (so, for example, a trap message to > manager A from node C is identified as being from node C, even if the > SNMP message gets relayed via node B, and SNMP message security is > done C-to-B, and then B-to-A. The contents of the varbinds are still > identified as being from node C. > > There is a PROXY-MIB in RFC3413(?) to specify how to relay SNMP > messages. This allows node A to have a security association with B, > and B to have a security association with C, without requiring A to > have a security association directly with C. > I do not believe this is in wide-spread use, but it was designed into > SNMP explicitly to help get through intermediaries, such as firewalls. > (NATs and ICE were not widely deployed at that time, but it can also > be applied to getting around NATs.) > > 6) Consider using MIDCOM-MIB > This was written after SNMPv3 completed, and before ICE. It was > designed to deal with NATs and firewalls, and other middle boxes. I > believe it is not widely deployed. I think the IETF community prefers > ICE for getting around NATs, but for doing SNMP management through a > RELOAD-managed middlebox, it might be helpful. maybe not. > > 7) Use existing SNMPv3-supported security protocols > USM is the mandatory-to-implement security for SNMPv3, because SNMPv3 > needs to work when a network is not working well, and USM is > self-contained in SNMPv3. However, for normal management tasks, and > much easier key distribution, operators greatly prefer using therir > already-widely-deployed security solutions, such as SSH, TLS, and > DTLS. Operators particulary disliked having to maintain a whole > different security infrastructure just for carrying SNMP. > > RFC5590, 5591, 5592, and 5953 add support for using existing security > infrastructure for SNMPv3+ messages. This might be a better approach > than designing a RELOAD-specific solution for carrying SNMP securely. > > 8) Be aware of address translation issues for SNMP > It is important for the information conveyed using SNMP to be > accurate. and that means if the managed node puts its IP address into > a MIB, and that MIB is translated into SNMP varbinds, and those > varbinds go through a NAT (or here a RELOAD proxy), that the IP > address inside the varbind is not modified. RFC 2962 discusses ALG > considerations for SNMP. I think your proposal is, to a degree, an ALG > for SNMP (but your proposal lacks enough detail for me to be sure). > Please be sure to read RFC2962. > > This even has an IESG Note attached: > This document describes an SNMP application layer gateway (ALG), > which may be useful in certain environments. The document does > also > list the issues and problems that can arise when used as a generic > SNMP ALG. Specifically, when using SNMPv3's authentication and > privacy mechanisms this approach may be very problematic and > jeopardize the SNMP security. The reader is urged to carefully > consider these issues before deciding to deploy this type of SNMP > ALG. > > 9) Using SNMP to do configuration can be problematic > Because SNMPv1 was not secure, and CLI can be used to do > configuration, many SNMP agents do not really support SETs. if they do > support SETs, those SETs often never get saved to NVRAM. So > recommending SNMP to configure nodes could be a problem in many > implementations. I'm not telling you not to do this, but be aware of > the problems (maybe write this into an "Operations and Management > Considerations" section). > > I hope this helps, > > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0022EB5D482578CD_= Content-Type: text/html; charset="US-ASCII"
Hi David,

      Thanks for your careful review and useful advises. We will try to
resolve all these problems when developing the detailed protocols. Our
goal is to adopt SNMP in management of network equipments deployed based
on P2P technology. However, we lack expertise in SNMPv3. Therefore, we
would like to invite experts from opsawg to build this protocol together.
If anyone would like to look into this problem, please feel free to contact us.
 
      For the name of "An SNMP usage for RELOAD", we follow the convention
of RELOAD, where the applications supported by RELOAD are called RELOAD usages.
We use the RELOAD protocol for SNMP manager discovery and connection setup.
So, we choose to name it as a "usage".

Thanks
Wang Wei

 

"David Harrington" <ietfdbh@comcast.net> writes 2011-07-12 21:54:15:

> Hi,
>
>
> The term "An SNMP Usage" piqued my interest, because it seems, in some
> ways, incorrect terminology from an SNMP perspective.
> I might recommend a title of "How to Use SNMP to manage nodes in a
> RELOAD environment"
>
> I am an Area Director, and a member of the MIB Doctors, the Operations
> directorate, the Security directorate, and (by default) the Transport
> and Services directorate, and an editor for SNMPv3 documents.
> So I took a quick look at this proposal, and have a few (fairly major)
> comments.
> Don't be discouraged by my comments; but be aware that there are some
> serious issues that need to be considered for your proposal.
>
> 1) Use SNMPv3 terminology
> Apparently, you come from the RELOAD side of things, not the SNMP
> side.
> Your text doesn't use the common SNMP terminology for various
> SNMP-related things.
> You will have a better chance of success if you describe SNMP-related
> things using the normal SNMPv3 terminology.
> This isn't critical; your ideas seem reasonable, but since you don't
> use the standard terminology, you might mean slightly different things
> than what it would mean if you used the standard terminology.
>
> (I don't have a RELOAD background, so some of my comments might seem
> wrong because I don't know the RELOAD concepts and terminology. Now
> you'll understand my point ;-)
>
> 2) Use SNMPv3
> It is important to make sure you are talking about SNMPv3. SNMPv1 and
> SNMPv2 have been declared Historic, and no new work should be done
> using those protocols. However, any MIB module should be able to be
> used with any version of SNMP.
> My concern is that SNMPv3 has assumptions about security associations,
> and you need to make sure those are considered.
>
> 3) Use MIB modules
> You are talking about the manager getting information from a managed
> node. The right way to approach "information from a node" is to define
> a MIB module that contains the information for the managed node. SNMP
> (typically) only carries information from MIB modules. So when you
> talk about the information about a node, you probably should talk
> about a MIB module at the managed node. If the functionality is
> different at the O-node and R-node, you might need different MIB
> modules, or have one MIB module that supports both roles.
>
> 4) Use SNMP EngineID
> You talk about a Node ID in the RELOAD network. There is also an
> identifier in the SNMP network, called the SnmpEngineID. It might be
> possible to use the SnmpEngineID as a RELOAD Node ID, but SnmpEngineID
> is not user-friendly. SnmpEngineID is needed for two SNMP endpoints to
> talk to each other. So you might want to have the SnmpEngineID
> included in the Registration information.  
>
> Typically, two SNMP nodes need to be pre-configured to talk because
> SNMP has access control for the MIB database, and the user needs to be
> configured to have access to the database. So a discovery mechanism to
> determine where to find a manager might be superfluous, since a
> security association between the manager and managed node might need
> to be pre-established anyway.
>
> I am not trying to convince you not to do this discovery work, but to
> be aware it might not make sense. OTOH, a mechanism that would allow
> an agent to find its manager, especially in a NAT environment, could
> be very useful for SNMP. See also RFC5343.
>
> 5) Consider using PROXY-MIB
> SNMPv3 uses hop-to-hop security, but the management is end-to-end.
> SnmpEngeinID is used both during authentication/authorization at a
> hop-by-hop level, and is contained in the SNMP message to identify the
> source node for the information. (so, for example, a trap message to
> manager A from node C is identified as being from node C, even if the
> SNMP message gets relayed via node B, and SNMP message security is
> done C-to-B, and then B-to-A. The contents of the varbinds are still
> identified as being from node C.
>
> There is a PROXY-MIB in RFC3413(?) to specify how to relay SNMP
> messages. This allows node A to have a security association with B,
> and B to have a security association with C, without requiring A to
> have a security association directly with C.
> I do not believe this is in wide-spread use, but it was designed into
> SNMP explicitly to help get through intermediaries, such as firewalls.
> (NATs and ICE were not widely deployed at that time, but it can also
> be applied to getting around NATs.)
>
> 6) Consider using MIDCOM-MIB
> This was written after SNMPv3 completed, and before ICE. It was
> designed to deal with NATs and firewalls, and other middle boxes. I
> believe it is not widely deployed. I think the IETF community prefers
> ICE for getting around NATs, but for doing SNMP management through a
> RELOAD-managed middlebox, it might be helpful. maybe not.
>
> 7) Use existing SNMPv3-supported security protocols
> USM is the mandatory-to-implement security for SNMPv3, because SNMPv3
> needs to work when a network is not working well, and USM is
> self-contained in SNMPv3. However, for normal management tasks, and
> much easier key distribution, operators greatly prefer using therir
> already-widely-deployed security solutions, such as SSH, TLS, and
> DTLS. Operators particulary disliked having to maintain a whole
> different security infrastructure just for carrying SNMP.
>
> RFC5590, 5591, 5592, and 5953 add support for using existing security
> infrastructure for SNMPv3+ messages. This might be a better approach
> than designing a RELOAD-specific solution for carrying SNMP securely.
>
> 8) Be aware of address translation issues for SNMP
> It is important for the information conveyed using SNMP to be
> accurate. and that means if the managed node puts its IP address into
> a MIB, and that MIB is translated into SNMP varbinds, and those
> varbinds go through a NAT (or here a RELOAD proxy), that the IP
> address inside the varbind is not modified. RFC 2962 discusses ALG
> considerations for SNMP. I think your proposal is, to a degree, an ALG
> for SNMP (but your proposal lacks enough detail for me to be sure).
> Please be sure to read RFC2962.
>
> This even has an IESG Note attached:
>    This document describes an SNMP application layer gateway (ALG),
>    which may be useful in certain environments.  The document does
> also
>    list the issues and problems that can arise when used as a generic
>    SNMP ALG.  Specifically, when using SNMPv3's authentication and
>    privacy mechanisms this approach may be very problematic and
>    jeopardize the SNMP security.  The reader is urged to carefully
>    consider these issues before deciding to deploy this type of SNMP
>    ALG.
>
> 9) Using SNMP to do configuration can be problematic
> Because SNMPv1 was not secure, and CLI can be used to do
> configuration, many SNMP agents do not really support SETs. if they do
> support SETs, those SETs often never get saved to NVRAM. So
> recommending SNMP to configure nodes could be a problem in many
> implementations. I'm not telling you not to do this, but be aware of
> the problems (maybe write this into an "Operations and Management
> Considerations" section).
>
> I hope this helps,
>
> David Harrington
> Director, IETF Transport Area
> ietfdbh@comcast.net (preferred for ietf)
> dbharrington@huaweisymantec.com
> +1 603 828 1401 (cell)
>
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0022EB5D482578CD_=-- From prvs=16918b134=Alexander.Knauf@haw-hamburg.de Thu Jul 14 01:46:47 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A45721F8763 for ; Thu, 14 Jul 2011 01:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 060PekfCyVPY for ; Thu, 14 Jul 2011 01:46:43 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id 6136721F8702 for ; Thu, 14 Jul 2011 01:46:42 -0700 (PDT) Received: from dehawshub02.mailcluster.haw-hamburg.de ([141.22.200.52]) by mail6.is.haw-hamburg.de with ESMTP/TLS/RC4-MD5; 14 Jul 2011 10:46:41 +0200 Received: from dehawscas01.mailcluster.haw-hamburg.de (141.22.200.33) by DEHAWSHUB02.mailcluster.haw-hamburg.de (141.22.200.52) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 14 Jul 2011 10:46:41 +0200 Received: from [141.22.26.154] (141.22.200.51) by haw-mailer.haw-hamburg.de (141.22.200.80) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 14 Jul 2011 10:46:41 +0200 Message-ID: <4E1EACF4.2030301@haw-hamburg.de> Date: Thu, 14 Jul 2011 10:46:44 +0200 From: Alexander Knauf User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <20110711195340.1259.23073.idtracker@ietfa.amsl.com> <4E1B5698.3050806@haw-hamburg.de> <4E1DC934.4080701@acm.org> In-Reply-To: <4E1DC934.4080701@acm.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Fwd: New Version Notification for draft-knauf-p2psip-share-01.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jul 2011 08:46:47 -0000 Hi Marc, Am 13.07.2011 18:35, schrieb Marc Petit-Huguenin: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Alexander, > > Just a quick question on this draft: > > Section 3 states that resource_name is the initial field and user_name is the > second field in Kinds that will use the USER-CHAIN-ACL ACP, but the > AccessControlListItem structure does not follow this rule as the first field is > length. This is still implementable as the ACP code needs anyway to know how to > parse the AccessControlListItem structure, but that requires it to be processed > differently from the other shared resources. Was that the intent? Well, the text of section 3 than might be unclear. If we write "... initial field within the Kind data structure...", we mean the "inner" Data structure of the Kind definition that one carrying the application data, thus in the Access Control List list Kind the "AccessControlListData". best regards, Alexander > > Thanks. > > On 07/11/2011 01:01 PM, Alexander Knauf wrote: >> Hi all, >> >> we just uploaded a new version of our draft for Shared Resources in RELOAD. >> Please take a look >> >> http://www.ietf.org/id/draft-knauf-p2psip-share-01.txt >> >> Best regards, >> >> Alexander >> >> Change Log: >> >> 1. Integrated the USER-PATTERN-MATCH access policy into USER-CHAIN- >> MATCH >> >> 2. Access Control List Kind uses USER-CHAIN-ACL exclusively >> >> 3. Resources to be shared use USER-CHAIN-ACL exclusively >> >> 4. More precise specification of mandatory User_name and >> Resource_name fields for Shared Resources >> >> 5. Added mechanism for isolating stored data to prevent race >> conditions while concurrent storing >> >> 6. XML Extension for variable resource names uses its own namespace >> >> 7. Many editorial improvements >> >> >> >> A new version of I-D, draft-knauf-p2psip-share-01.txt has been successfully >> submitted by Alexander Knauf and posted to the IETF repository. >> >> Filename: draft-knauf-p2psip-share >> Revision: 01 >> Title: A Usage for Shared Resources in RELOAD (ShaRe) >> Creation date: 2011-07-11 >> WG ID: Individual Submission >> Number of pages: 22 >> >> Abstract: >> This document defines a RELOAD Usage for managing shared write access >> to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic >> primitive for enabling various coordination and notification schemes >> among distributed peers. Access in ShaRe is controlled by a >> hierarchical trust delegation scheme maintained within an access >> list. A new USER-CHAIN-ACL access policy allows authorized peers to >> write a Shared Resource without owning its corresponding certificate. >> This specification also adds mechanisms to store Resources with a >> variable name which is useful whenever peer-independent rendezvous >> processes are required. >> >> >> >> >> The IETF Secretariat > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk4dyTIACgkQ9RoMZyVa61fRwwCfa2ogfZPEyaWVjed2IVJeNVKd > xZYAmgIn5io/h79UCXRiWLusQMvejS+d > =4mR2 > -----END PGP SIGNATURE----- -- /************************************************* * Alexander Knauf B.Sc. * AG INET * Dept. Informatik * HAW Hamburg * Berliner Tor 7 * D-20099 Hamburg, Germany * Room: 580 * Net: http://inet.cpt.haw-hamburg.de/members/knauf * Phone: +49 40 42875 - 8067 * Fax: +49 40 42875 - 8409 *************************************************/ From petithug@acm.org Thu Jul 14 07:36:17 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E1B21F86EB for ; Thu, 14 Jul 2011 07:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLvKIi620mrT for ; Thu, 14 Jul 2011 07:36:12 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id DB60821F86E0 for ; Thu, 14 Jul 2011 07:36:11 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 294552199E; Thu, 14 Jul 2011 16:34:38 +0200 (CEST) Message-ID: <4E1EFED6.6040809@acm.org> Date: Thu, 14 Jul 2011 07:36:06 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: Alexander Knauf References: <20110711195340.1259.23073.idtracker@ietfa.amsl.com> <4E1B5698.3050806@haw-hamburg.de> <4E1DC934.4080701@acm.org> <4E1EACF4.2030301@haw-hamburg.de> In-Reply-To: <4E1EACF4.2030301@haw-hamburg.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Fwd: New Version Notification for draft-knauf-p2psip-share-01.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jul 2011 14:36:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/2011 01:46 AM, Alexander Knauf wrote: > Hi Marc, > > Am 13.07.2011 18:35, schrieb Marc Petit-Huguenin: > Hi Alexander, > > Just a quick question on this draft: > > Section 3 states that resource_name is the initial field and user_name is the > second field in Kinds that will use the USER-CHAIN-ACL ACP, but the > AccessControlListItem structure does not follow this rule as the first field is > length. This is still implementable as the ACP code needs anyway to know how to > parse the AccessControlListItem structure, but that requires it to be processed > differently from the other shared resources. Was that the intent? >> Well, the text of section 3 than might be unclear. If we write "... initial >> field within the Kind data >> structure...", we mean the "inner" Data structure of the Kind definition that >> one carrying the application data, thus in the Access Control List list Kind the >> "AccessControlListData". But for new Kinds (i.e. excluding the ACCESS-CONTROL-LIST Kind that needs to be understood by the USER-CHAIN-ACL ACP code), the USER-CHAIN-ACL ACP code does not know what is the inner Data structure, because the layout of the data is lost for the peer receiving the Store request (which sees only a byte stream). For example some Kinds use a longer "header" containing a type, or would not use an inner Data structure at all, and so on. I see in fact two solutions: 1. The resource_name and user_name are really the first fields, i.e. USER-CHAIN-ACL looks something like this: struct { opaque to_user<0..2^16-1>; KindId kind; Boolean allow_delegation; } AccessControlListData struct { opaque resource_name<0..2^16-1>; opaque user_name<0..2^16-1>; uint16 length; AccessControlListData data; } AccessControlListItem; 2. Add a new variable in the kind that contain the offset to the inner Data structure, so e.g. with the original AccessControlListItem you can use a kind description that looks something like this: ARRAY USER-PATTERN-MATCH 100 100 .*-conf-$USER@$DOMAIN 2 There is a 3rd solution, which is to use ECMAScript scripts for each shared resource so the ACP code always knows where the user_name and resource_name values are in the byte stream, but I think it is a bad idea to use script as a permanent solution, for reasons I explained in the Security Section of my draft. With the text that is in your draft, there is no other solution than to release a new version of the RELOAD implementation that understand each new shared resource structure, and be sure that all peers use this new version before you can start storing the new shared structure in the overlay. Depending on your use case, that could be OK, but this need, IMO, to be clearly stated in your draft (and in this case, it does not matter where the user_name and resource_name variables are). - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4e/tUACgkQ9RoMZyVa61eQiQCeL2NCrL2JY0XNp/rl1JHQYgwB bpsAnjNh+xEll8lwZV9zibfTp6qO9ZRA =+cGn -----END PGP SIGNATURE----- From petithug@acm.org Fri Jul 15 10:55:52 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B70B21F8C0F for ; Fri, 15 Jul 2011 10:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0xJ+xS2-OyM for ; Fri, 15 Jul 2011 10:55:47 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 4B68321F8BF4 for ; Fri, 15 Jul 2011 10:55:44 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 8C1272199E; Fri, 15 Jul 2011 19:54:06 +0200 (CEST) Message-ID: <4E207F1C.9080500@acm.org> Date: Fri, 15 Jul 2011 10:55:40 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: Cullen Jennings References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E00F7CE.7080402@acm.org> <4E0DB3EC.1040705@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: [P2PSIP] Breaking RELOAD [was Re: Identity certificate segregation] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2011 17:55:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/07/2011 03:34 PM, Cullen Jennings wrote: > > This would break all the current deployments and implementation and not just > in a way where some new software would need to be pushed out - all new > certificates would need to be issues. From my point of view, this is too late > for this change and instead it could be addressed with an extension. About this "breaking current deployment" thing, it seems to me that anyway when RELOAD will be published as an RFC, the version number with be incremented to 1.0 (0x0a), so implementations of the RFC will *not* be compatible with *any* of the current implementations. And because of this, I really do not understand why the authors of RELOAD are fighting so hard to not break things that will be broken anyway - there was multiple instances of things that could have been improved in the document but stayed because of this (the fragment bit is one example of this). Having been there multiple times I really understand the plight of early implementers but I would never ever use this as a justification to keep useless stuff in a protocol. What should have been done is simply to increment the version each time a new version of the draft would have broken interoperability - and we had the possibility to do that 8 times (versions 0.1 to 0.9). > > On Jul 1, 2011, at 5:47 AM, Gonzalo Camarillo wrote: > >> Hi, >> >> please, let me know whether or not these modifications will be included in >> the base draft at this point. >> [...] - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4gfxoACgkQ9RoMZyVa61cxtQCeK9nUyj9XzOp0+8q9Mdhtp9Sg 3QoAoJaA4VCBUqtphhjrUMyAiaVmsNRc =gx2i -----END PGP SIGNATURE----- From ietfdbh@comcast.net Tue Jul 12 06:54:27 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C92F21F912C for ; Tue, 12 Jul 2011 06:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZGRUAkeS1S9 for ; Tue, 12 Jul 2011 06:54:26 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 19D1921F9128 for ; Tue, 12 Jul 2011 06:54:26 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 71kg1h0011ap0As5B1uSDz; Tue, 12 Jul 2011 13:54:26 +0000 Received: from davidPC ([67.189.235.106]) by omta22.westchester.pa.mail.comcast.net with comcast id 71uR1h00M2JQnJT3i1uRdc; Tue, 12 Jul 2011 13:54:26 +0000 From: "David Harrington" To: , , Date: Tue, 12 Jul 2011 09:54:15 -0400 Message-ID: <8D213570E6754D439F01F81DB80966C0@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Thread-Index: AcxAmy+lDlJYdqvWRFebDjrnGVEo6A== X-Mailman-Approved-At: Fri, 15 Jul 2011 11:35:19 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] An SNMP Usage for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2011 13:54:27 -0000 Hi, The term "An SNMP Usage" piqued my interest, because it seems, in some ways, incorrect terminology from an SNMP perspective. I might recommend a title of "How to Use SNMP to manage nodes in a RELOAD environment" I am an Area Director, and a member of the MIB Doctors, the Operations directorate, the Security directorate, and (by default) the Transport and Services directorate, and an editor for SNMPv3 documents. So I took a quick look at this proposal, and have a few (fairly major) comments. Don't be discouraged by my comments; but be aware that there are some serious issues that need to be considered for your proposal. 1) Use SNMPv3 terminology Apparently, you come from the RELOAD side of things, not the SNMP side. Your text doesn't use the common SNMP terminology for various SNMP-related things. You will have a better chance of success if you describe SNMP-related things using the normal SNMPv3 terminology. This isn't critical; your ideas seem reasonable, but since you don't use the standard terminology, you might mean slightly different things than what it would mean if you used the standard terminology. (I don't have a RELOAD background, so some of my comments might seem wrong because I don't know the RELOAD concepts and terminology. Now you'll understand my point ;-) 2) Use SNMPv3 It is important to make sure you are talking about SNMPv3. SNMPv1 and SNMPv2 have been declared Historic, and no new work should be done using those protocols. However, any MIB module should be able to be used with any version of SNMP. My concern is that SNMPv3 has assumptions about security associations, and you need to make sure those are considered. 3) Use MIB modules You are talking about the manager getting information from a managed node. The right way to approach "information from a node" is to define a MIB module that contains the information for the managed node. SNMP (typically) only carries information from MIB modules. So when you talk about the information about a node, you probably should talk about a MIB module at the managed node. If the functionality is different at the O-node and R-node, you might need different MIB modules, or have one MIB module that supports both roles. 4) Use SNMP EngineID You talk about a Node ID in the RELOAD network. There is also an identifier in the SNMP network, called the SnmpEngineID. It might be possible to use the SnmpEngineID as a RELOAD Node ID, but SnmpEngineID is not user-friendly. SnmpEngineID is needed for two SNMP endpoints to talk to each other. So you might want to have the SnmpEngineID included in the Registration information. Typically, two SNMP nodes need to be pre-configured to talk because SNMP has access control for the MIB database, and the user needs to be configured to have access to the database. So a discovery mechanism to determine where to find a manager might be superfluous, since a security association between the manager and managed node might need to be pre-established anyway. I am not trying to convince you not to do this discovery work, but to be aware it might not make sense. OTOH, a mechanism that would allow an agent to find its manager, especially in a NAT environment, could be very useful for SNMP. See also RFC5343. 5) Consider using PROXY-MIB SNMPv3 uses hop-to-hop security, but the management is end-to-end. SnmpEngeinID is used both during authentication/authorization at a hop-by-hop level, and is contained in the SNMP message to identify the source node for the information. (so, for example, a trap message to manager A from node C is identified as being from node C, even if the SNMP message gets relayed via node B, and SNMP message security is done C-to-B, and then B-to-A. The contents of the varbinds are still identified as being from node C. There is a PROXY-MIB in RFC3413(?) to specify how to relay SNMP messages. This allows node A to have a security association with B, and B to have a security association with C, without requiring A to have a security association directly with C. I do not believe this is in wide-spread use, but it was designed into SNMP explicitly to help get through intermediaries, such as firewalls. (NATs and ICE were not widely deployed at that time, but it can also be applied to getting around NATs.) 6) Consider using MIDCOM-MIB This was written after SNMPv3 completed, and before ICE. It was designed to deal with NATs and firewalls, and other middle boxes. I believe it is not widely deployed. I think the IETF community prefers ICE for getting around NATs, but for doing SNMP management through a RELOAD-managed middlebox, it might be helpful. maybe not. 7) Use existing SNMPv3-supported security protocols USM is the mandatory-to-implement security for SNMPv3, because SNMPv3 needs to work when a network is not working well, and USM is self-contained in SNMPv3. However, for normal management tasks, and much easier key distribution, operators greatly prefer using therir already-widely-deployed security solutions, such as SSH, TLS, and DTLS. Operators particulary disliked having to maintain a whole different security infrastructure just for carrying SNMP. RFC5590, 5591, 5592, and 5953 add support for using existing security infrastructure for SNMPv3+ messages. This might be a better approach than designing a RELOAD-specific solution for carrying SNMP securely. 8) Be aware of address translation issues for SNMP It is important for the information conveyed using SNMP to be accurate. and that means if the managed node puts its IP address into a MIB, and that MIB is translated into SNMP varbinds, and those varbinds go through a NAT (or here a RELOAD proxy), that the IP address inside the varbind is not modified. RFC 2962 discusses ALG considerations for SNMP. I think your proposal is, to a degree, an ALG for SNMP (but your proposal lacks enough detail for me to be sure). Please be sure to read RFC2962. This even has an IESG Note attached: This document describes an SNMP application layer gateway (ALG), which may be useful in certain environments. The document does also list the issues and problems that can arise when used as a generic SNMP ALG. Specifically, when using SNMPv3's authentication and privacy mechanisms this approach may be very problematic and jeopardize the SNMP security. The reader is urged to carefully consider these issues before deciding to deploy this type of SNMP ALG. 9) Using SNMP to do configuration can be problematic Because SNMPv1 was not secure, and CLI can be used to do configuration, many SNMP agents do not really support SETs. if they do support SETs, those SETs often never get saved to NVRAM. So recommending SNMP to configure nodes could be a problem in many implementations. I'm not telling you not to do this, but be aware of the problems (maybe write this into an "Operations and Management Considerations" section). I hope this helps, David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From fluffy@cisco.com Sat Jul 16 09:41:34 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E488221F8745 for ; Sat, 16 Jul 2011 09:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.316 X-Spam-Level: X-Spam-Status: No, score=-104.316 tagged_above=-999 required=5 tests=[AWL=-1.717, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S55BDNhSZoVs for ; Sat, 16 Jul 2011 09:41:34 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E7DD121F85D9 for ; Sat, 16 Jul 2011 09:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=4404; q=dns/txt; s=iport; t=1310834494; x=1312044094; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=PG3butzSrMfYI7/+v4j+P7oipZFE57W98+LgoEqlM7I=; b=SvEYgZToGPD80BzN//34RxpDDT8P5WX377DeFssRtDzll63Bd06Fgg/Q wB6p9It/ij5+a6rpABdyJ7zJSDoNkdDP7xfGhj7LJoEJwG59ZyQlx1Tpt r6MGDpjti5WUQInX4a/U8RM/HVZ+87B/3BBdpv1fgkur3zhddoPJw0koG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAO/IU6rRDoH/2dsb2JhbABFDad1d6tvnUaDJII5XwSHVIsShQGLdA X-IronPort-AV: E=Sophos;i="4.67,214,1309737600"; d="scan'208";a="3594539" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 16 Jul 2011 16:41:32 +0000 Received: from [10.21.86.178] ([10.21.86.178]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6GGfVNc007531; Sat, 16 Jul 2011 16:41:31 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E207F1C.9080500@acm.org> Date: Sat, 16 Jul 2011 09:41:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E00F7CE.7080402@acm.org> <4E0DB3EC.1040705@ericsson.com> <4E207F1C.9080500@acm.org> To: "Marc Petit-Huguenin" X-Mailer: Apple Mail (2.1084) Cc: P2PSIP WG Subject: Re: [P2PSIP] Breaking RELOAD [was Re: Identity certificate segregation] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2011 16:41:35 -0000 I think all the people that implemented early version know that changes = can, and will, break backwards compatibility. I don't recall very = many places where I used this as augment for one way or another. I = recall some places where it was 6 of one of half a dozen of the other = and it made no fundamental difference to the protocol so we decided to = go which what was already implemented.=20 That said some types of changes are very easy to move into a fully = operational deployed DHT. Others are not. For example, a change that you = can detect the version number and then just have the software do the = right things is pretty easy particularly if both the new code and old = code can exist in the ring at the same time. A change where every device = in the ring needs to get a new certificate and you can' have a mixed = ring with the old and new certificates at the same time is not easy to = deploy.=20 To the point of this specific proposal for change. This fundamentally = changes the security model and nearly every part of this protocol that = has anything to do with security - which is most of it. The suggestions = is several years late - it was many years ago that this WG made the = decision about what the general security model was doing to be. If = people want this, it seems like a fine thing to do in version 2.0 of the = protocol. Thought my previous email suggested that one could look at = doing it in an extension, closer examination of that makes me think = there would be some real hard problems in trying to do that as it = requires all the security component to be re-thought and redesigned. = Given the current level of energy in the WG, that would take several = years to happen. I have pretty much zero interest in doing that, I'd = like to actually have an RFC for this in the next year instead of = several years from now. As practical improvement of the protocol, I have = not seen a single use case proposed where this improves things so much = we can actually do something interesting that we can no do with the = current proposal.=20 On Jul 15, 2011, at 10:55 , Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 07/07/2011 03:34 PM, Cullen Jennings wrote: > > > > This would break all the current deployments and implementation and = not just > > in a way where some new software would need to be pushed out - all = new > > certificates would need to be issues. =46rom my point of view, this = is too late > > for this change and instead it could be addressed with an extension. >=20 > About this "breaking current deployment" thing, it seems to me that = anyway when > RELOAD will be published as an RFC, the version number with be = incremented to > 1.0 (0x0a), so implementations of the RFC will *not* be compatible = with *any* of > the current implementations. And because of this, I really do not = understand > why the authors of RELOAD are fighting so hard to not break things = that will be > broken anyway - there was multiple instances of things that could have = been > improved in the document but stayed because of this (the fragment bit = is one > example of this). Having been there multiple times I really = understand the > plight of early implementers but I would never ever use this as a = justification > to keep useless stuff in a protocol. What should have been done is = simply to > increment the version each time a new version of the draft would have = broken > interoperability - and we had the possibility to do that 8 times = (versions 0.1 > to 0.9). >=20 > > > > On Jul 1, 2011, at 5:47 AM, Gonzalo Camarillo wrote: > > > >> Hi, > >> > >> please, let me know whether or not these modifications will be = included in > >> the base draft at this point. > >> >=20 > [...] >=20 > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iEYEARECAAYFAk4gfxoACgkQ9RoMZyVa61cxtQCeK9nUyj9XzOp0+8q9Mdhtp9Sg > 3QoAoJaA4VCBUqtphhjrUMyAiaVmsNRc > =3Dgx2i > -----END PGP SIGNATURE----- >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From petithug@acm.org Sat Jul 16 11:12:51 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB54321F8745 for ; Sat, 16 Jul 2011 11:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qna+eI8lKikE for ; Sat, 16 Jul 2011 11:12:51 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id C1F3821F86E6 for ; Sat, 16 Jul 2011 11:12:50 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 1F8DE2199E; Sat, 16 Jul 2011 20:11:08 +0200 (CEST) Message-ID: <4E21D49F.9000100@acm.org> Date: Sat, 16 Jul 2011 11:12:47 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: Cullen Jennings References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E00F7CE.7080402@acm.org> <4E0DB3EC.1040705@ericsson.com> <4E207F1C.9080500@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Breaking RELOAD [was Re: Identity certificate segregation] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2011 18:12:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/16/2011 09:41 AM, Cullen Jennings wrote: > > I think all the people that implemented early version know that changes can, > and will, break backwards compatibility. I don't recall very many places > where I used this as augment for one way or another. I recall some places > where it was 6 of one of half a dozen of the other and it made no fundamental > difference to the protocol so we decided to go which what was already > implemented. Well, I kind of disagree here. The problem is that *future* implementers will not have access to the whole history of the development of the RELOAD protocol when trying to decipher the specification. The RELOAD specification is *not* developer friendly (but it is not specific to this spec). I am still not saying that a protocol must be developer-friendly, just that the text describing it should be, and that when it makes no fundamental difference to the protocol, making it easier for future developers should have priority over not breaking compatibility. > > That said some types of changes are very easy to move into a fully > operational deployed DHT. Others are not. For example, a change that you can > detect the version number and then just have the software do the right things > is pretty easy particularly if both the new code and old code can exist in > the ring at the same time. A change where every device in the ring needs to > get a new certificate and you can' have a mixed ring with the old and new > certificates at the same time is not easy to deploy. I still do not see this as a good reason to stop fixing stuff in the protocol. What is the point of having internet *drafts* if they are to be considered as standard track RFCs? > > To the point of this specific proposal for change. This fundamentally changes > the security model and nearly every part of this protocol that has anything > to do with security - which is most of it. The suggestions is several years > late - it was many years ago that this WG made the decision about what the > general security model was doing to be. If people want this, it seems like a > fine thing to do in version 2.0 of the protocol. Thought my previous email > suggested that one could look at doing it in an extension, closer examination > of that makes me think there would be some real hard problems in trying to do > that as it requires all the security component to be re-thought and > redesigned. OK, now we agree. > Given the current level of energy in the WG, that would take > several years to happen. I have pretty much zero interest in doing that, I'd > like to actually have an RFC for this in the next year instead of several > years from now. As practical improvement of the protocol, I have not seen a > single use case proposed where this improves things so much we can actually > do something interesting that we can no do with the current proposal. > > > > On Jul 15, 2011, at 10:55 , Marc Petit-Huguenin wrote: > > On 07/07/2011 03:34 PM, Cullen Jennings wrote: >>>> >>>> This would break all the current deployments and implementation and not >>>> just in a way where some new software would need to be pushed out - all >>>> new certificates would need to be issues. From my point of view, this >>>> is too late for this change and instead it could be addressed with an >>>> extension. > > About this "breaking current deployment" thing, it seems to me that anyway > when RELOAD will be published as an RFC, the version number with be > incremented to 1.0 (0x0a), so implementations of the RFC will *not* be > compatible with *any* of the current implementations. And because of this, I > really do not understand why the authors of RELOAD are fighting so hard to > not break things that will be broken anyway - there was multiple instances of > things that could have been improved in the document but stayed because of > this (the fragment bit is one example of this). Having been there multiple > times I really understand the plight of early implementers but I would never > ever use this as a justification to keep useless stuff in a protocol. What > should have been done is simply to increment the version each time a new > version of the draft would have broken interoperability - and we had the > possibility to do that 8 times (versions 0.1 to 0.9). > >>>> >>>> On Jul 1, 2011, at 5:47 AM, Gonzalo Camarillo wrote: >>>> >>>>> Hi, >>>>> >>>>> please, let me know whether or not these modifications will be >>>>> included in the base draft at this point. >>>>> > > [...] > >> > Cullen Jennings For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4h1J0ACgkQ9RoMZyVa61cFxQCfTPJuP/YveHmTK4AMZfonQK3m Q+IAmgJN8sYZMzfygCqnocSYuosMsJT9 =o9Rj -----END PGP SIGNATURE----- From bbl@lowekamp.net Sat Jul 16 18:27:53 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461D221F86EB for ; Sat, 16 Jul 2011 18:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.424 X-Spam-Level: X-Spam-Status: No, score=-0.424 tagged_above=-999 required=5 tests=[AWL=0.741, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcwLjyp7tBjO for ; Sat, 16 Jul 2011 18:27:51 -0700 (PDT) Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id BED2921F86E5 for ; Sat, 16 Jul 2011 18:27:50 -0700 (PDT) Received: by eya28 with SMTP id 28so1852280eya.21 for ; Sat, 16 Jul 2011 18:27:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.9.215 with SMTP id 63mr1715702eet.94.1310866068041; Sat, 16 Jul 2011 18:27:48 -0700 (PDT) Received: by 10.14.127.1 with HTTP; Sat, 16 Jul 2011 18:27:47 -0700 (PDT) In-Reply-To: <1310232343.5262.27.camel@santeles> References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E0E4DBE.5060302@acm.org> <1309624099.5232.23.camel@santeles> <4E0F4F8D.9080108@acm.org> <1309773089.5716.43.camel@santeles> <1310123712.22737.73.camel@toedo> <1310143982.6132.75.camel@santeles> <1310232343.5262.27.camel@santeles> Date: Sat, 16 Jul 2011 21:27:47 -0400 Message-ID: From: Bruce Lowekamp To: Diego Suarez Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 17 Jul 2011 01:27:53 -0000 On Sat, Jul 9, 2011 at 1:25 PM, Diego Suarez wrote: > First of all, I would like to introduce the motivation of the idea of > split certification, since I think it is an important point in this > discussion and would help to clarify why I think that virtual clients do > not really allow several users to be connected from the same device. > Also, it could help to clarify if I taking a false premise to support > split certification when I should not. > > As far as I understood, the idea of nodeIDs in RELOAD is to represent > devices, despite usernames and nodeIDs are included in the same > certificate. Draft says: "If a user has more than one device, typically > they would get one certificate for each device. =C2=A0This allows each de= vice > to act as a separate peer." However, it also exist the possibility of > having a single certificate with several nodeIDs. In this case, a user > with two devices ( for example a mobile and a fixed phone ) would have a > certificate with a username and two nodeIDs, one for each device; being > able to be connected to network and contactable in both devices at the > same time. > > Regarding the first alternative, there is something I have not clear: If > a user has a different certificate for each device she has, would these > certificates have the same username and different nodeIDs? and if so, > would the PK be the same in all the certificates or a different PK in > each one?; or would the user have a different username, a different > nodeID and a different PK in each certificate?. Said this, if we want > each device to have its own certificate, why don't make it simpler a > split device's identity from the user's identity? The only requirement is that no two nodes can be trying to use the same nodeid at the same time. Otherwise, it doesn't make any difference to the protocol if two physical devices use the same nodeid at different times. The draft doesn't say much about managing this because outside of this requirement, it's really up to the implementation. > > The second alternative (several nodeIDs in a single cert) works well for > me if the user if using the same devices all the time, for example a > user with one cert with a nodeID for her mobile phone and another nodeID > for her office fixed phone; but has some limitations. What happens if > the user is out for one week in another office and wants to be connected > from there ? The simple answer seems to be "use the nodeID she was using > in the other office". But, is it not weird to bother in the first place > to give a different nodeID to each user's device and now use the same > nodeID for two different ones? Also, won't be useful to have each device > identified by a unique nodeID within the network for security reasons or > to have permanent statistics about its past behavior for network > maintenance or routing purposes? I don't see that it would be that useful. It certainly doesn't give you any additional security, since you can't enforce it at a protocol level. If you're interested in logging information about hardware or software configuration nodes are using, you can certainly do that---and if you do that, you've solved the problem. > > With this in mind, it came to me the idea of a split certification. With > split certification, users would be identified always by the same > certificate independently of the device they are using (something that > does not happen in the first alternative). Also, devices would be always > identified by the same and unique cert (something that does not happen > in the second). Besides, users could be connected to as many devices as > they want without have to been re-certified to get more nodeIDs. I think > this would simplify the certification of the system and improve its > maintenance. Also, extra improvements come with this alternative, like > greater interoperability with SIP ( as I've already commented in > previous mails ) or the easy deployment of more secure networks formed > by hard coded (including a certificate with a nodeID) devices. This can all be done with the existing protocol. And, as I said in my earlier responses, I don't believe there are any interop issues with SIP, I think a reload cert could be 6072 compatible, though I don't claim to be an expert on that or to have tested it. > > The comments to the other improvement I see of this alternative, related > to several users connected to the same device, are inline. > > On Fri, 2011-07-08 at 19:06 -0400, Bruce Lowekamp wrote: >> inline >> >> On Fri, Jul 8, 2011 at 12:53 PM, Diego Suarez wro= te: >> > Hi, >> > >> > I have the impression I am not explaining myself well. I am not saying >> > that clients in RELOAD do not work well, I am just saying that I do no= t >> > see how they can be used to allow several users to be connected to the >> > same the device; at least not with full functionalities. >> > >> > Lets go back to the example: >> > Imagine we have a device, with PKC ( # user =3D device1, nodeID =3D 10= 0 # ) >> > and two users ( # user =3D user1, nodeID =3D 200 # and # user =3D user= 2, >> > nodeID =3D 300 # ) connected to that device acting as virtual clients. >> > >> > As you have said, during registration, users store a destination list >> > that start with the device ( nodeID =3D 100 ) and finishes with the >> > client's nodeID ( nodeID =3D 200 for user1 and nodeID =3D 300 for user= 2). >> > This works well, and allows other peers of the system to reach them. >> > >> > However, the problem is with the access control. Being virtual clients= , >> > users can perform NODE-USER-MATCH accesses related to their client's >> > nodeIDs and usernames: 200-user1 for user1 and 300-user2 for user2. >> > Nevertheless, this is not what we want in this case. In this case, whe= re >> > user1 and user2 are supposed to be connected to the same device (nodeI= D >> > =3D 100), they should be allowed to perform NODE-USER-MATCH accesses >> > related to this device and their usernames: 100-user1 for user1 and >> > 100-user2 for user2. >> >> why? =C2=A0It works as designed when they use their client nodeid. > > Well, I've said before, if the idea of RELOAD is to have each device be > identified by a different nodeID, from my point of view two users > operating from the same device should be using the same nodeID. Two > users connected to the same device, using different nodeIDs, that also > reuse later with another devices are not actually breaking the > certification idea of 1device =3D 1nodeID? The idea is at most one device on the overlay at any given time with the same node id. The ability to act as a particular node id is controlled by the certificate mechanism. No other assumptions. > > >> In >> fact, using the host's nodeid here gives the exact opposite behavior >> of what you would want---if one of the multiple users switches to a >> different device, they may wind up with a stale entry pointing to the >> device they are no longer at, whereas if the user uses their own >> certificate&nodeid, when they register their route to the new host the >> old one is automatically removed because they're using the same client >> nodeid. > > I think this would be a fail of the implementation not of the proposal > and that can also happen with the actual model of RELOAD. Imagine a user > with a cert (including a username and two nodeIDs ) connected to two > different devices. If she disconnects from one of the devices but > forgets to remove that entry point, she may also wind up with a stale > entry pointing to a device she is no longer at. > Exactly. If you use the same nodeid for that person, you don't need to worry about stale entries. > >> >> > Because, if not, we are not really implementing >> > this functionality. >> >> what functionality? >> >> > In order to be fully implemented, several users >> > connected to the same device should have the same functionalities that= a >> > single user connected to this device has, and this is not the case usi= ng >> > virtual clients. >> >> could you clarify what you're referring to here? =C2=A0 I don't know wha= t >> functionality I would expect multiple users signed into the same >> device to have that wouldn't be provided using their own nodeids. >> > > I would try to clarify what I mean with an example that presents three > possible cases that can occur in RELOAD: > > case 1: > > User1 with cert ( user =3D user1, nodeID =3D 100 ) is connected to the > network using a device. Therefore she can perform any access related to > her user( USER-MATCH =3D user1 ), nodeID ( NODE-MATCH =3D 100 ) or the > combination of both (USER-NODE-MATCH =3D user1-100). > > case 2: > > The same User1 with the same cert is connected to the network using the > same device. But now, also User2 ( user =3D user2, nodeID =3D 200 ) and > User3 ( user =3D user3, nodeID =3D 300 ) are connected to that device as > virtual clients. User1 can perform the same kind of accesses than > in case 1. User2 can perform accesses related her user( USER-MATCH =3D > user2 ), virtual nodeID ( NODE-MATCH =3D 200 ) or the combination of both > (USER-NODE-MATCH =3D user2-200). User3 is ( USER-MATCH =3D user3 ), virtu= al > nodeID ( NODE-MATCH =3D 300 ) or the combination of both (USER-NODE-MATCH > =3D user3-300). > > > case 3: > > A "non-user" device ( user =3D lab1, nodeID =3D 100 ) is connected to the > network. Two users, User2 and User3 (with the same credentials that in > the previous case) are connected to that device. So, User2 and User3 can > perform the same accesses than in case 3. > > In this three examples, taking a look a the accesses related to NODE, > the important thing here, we see different cases of users presumably > connected to the same device, that should have the same functionalities > over that device but actually they have not. Precisely, User1 can > perform accesses on behalf of the device, while user2 and user3 cannot. > I would expect for all the cases the same rights for a user, either she > has full control over the device ( to perform accesses like NODE-MATCH = =3D > 100 ) or she does not have any control at all over it. But not these > different possibilities depending on how the user is connected to the > device. This is what I wanted to mean with no having full > functionalities. Furthermore, in case 2 we are forcing User1 to be > connected to the network while User2 and User3 wish to continue using > the device. It would be possible here that User1 entered in an > =E2=80=98invisible mode=E2=80=99 by removing her contact information from= the network. > In such case, User1 seemed to be offline for the other users of the > network (neither they could have the knowledge that she is online or > access to her contact information) but she would be actually online > since she could access to all the resources of the network, like her > voicemail or the contact information of other users to initiate media > calls. I really lost you on this point. Reload is an overlay and key-based storage protocol. The only functionality it gives you are those abilities, there's nothing about "seems to be offline" that would come out of the core protocol. A usage, such as the sip usage, specifies how to use it to deliver functionality to the user. In the sip-usage case, it stores destination lists indexed by AORs---so it doesn't matter whether the users are using the nodeid of a peer or a client. They are reachable via the destination list they specify. I guess you could specify a usage that only stored the peer's nodeid and so didn't support clients, but that would be broken. Any information in reload on how to contact a node needs to be a destination list. Bruce > > > cheers > >> Bruce >> >> >> > >> > cheers >> > >> > >> > >> > On Fri, 2011-07-08 at 09:40 -0400, Bruce Lowekamp wrote: >> >> On Fri, Jul 8, 2011 at 7:15 AM, Diego Suarez w= rote: >> >> > Hi Bruce, >> >> > >> >> > Answers inline. >> >> > >> >> > >> >> > On Thu, 2011-07-07 at 22:24 -0400, Bruce Lowekamp wrote: >> >> >> Diego, >> >> >> >> >> >> Please take some time understanding how real clients work in reloa= d. >> >> >> Then just have the virtual clients use the same messages. =C2=A0Th= e virtual >> >> >> clients use their own nodeids, not the host's nodeid. =C2=A0It all= works >> >> >> fine. >> >> > >> >> > I agree, this works fine for clients, but, from my point of view, i= t >> >> > does not for several users connected to the same device. The fact t= hat >> >> > clients ( or virtual clients ) use their own nodeIDs and not the ho= st's >> >> > nodeIDs is precisely what I see as the problem of using virtual cli= ents >> >> > to allow several users to be connected to the same device. Since vi= rtual >> >> > clients are not using the device's nodeID, they cannot perform >> >> > operations ( like NODE-MATCH or USER-NODE-MATCH accesses) from that >> >> > device like they should if they were actually connected to the syst= em >> >> > from it. As I've said in my previous mail, they only way I see to a= llow >> >> > so is the device adding an extra signature to the message, with the >> >> > already commented problem of two users and two nodeIDs in it. >> >> > >> >> >> >> Since a client is using its own nodeid, NODE-MATCH and USER-NODE-MATC= H >> >> are performed using the client's nodeid. =C2=A0In the case of the sip >> >> usage, it's done using USER-NODE-MATCH. =C2=A0This is the client's >> >> rfc822Name and the client's nodeid. =C2=A0In that registration, it st= ores a >> >> destination list that starts with the peer and finishes with the >> >> client's nodeid (in most cases, would be only these two entries). >> >> This is how clients are supported in reload and for the sip usage. >> >> >> >> > >> >> >> I don't see a real problem with a host node having an >> >> >> "admin@example.com" or "node12345@example.com" name attached to it= . >> >> >> Routers pretty much always have DNS names that are descriptive of >> >> >> where they are to admins, even though routing protocols don't requ= ire >> >> >> it. >> >> > >> >> > Neither do I except for cases, like the presented before, of severa= l >> >> > users in the same device. >> >> > >> >> >> >> >> >> Regarding certs, 6072 has the following text: >> >> >> >> >> >> =C2=A0 =C2=A0If the certificate is signed by a trusted certificati= on authority, >> >> >> =C2=A0 =C2=A0and one of the names in the SubjectAltName matches th= e original URI, >> >> >> =C2=A0 =C2=A0then this certificate MAY be used, but only for exact= ly the original >> >> >> >> >> >> It's been awhile since I've looked at that in detail, but it appea= rs >> >> >> to me that a reload cert could be perfectly valid for use with 607= 2 as >> >> >> long as it has the sip uri in it. =C2=A0Though I'm not immediately >> >> >> convinced that this is that useful, regardless. >> >> > >> >> > The problem is not with RELOAD certs being used in SIP systems, but= with >> >> > SIP certs being used in RELOAD systems. Since SIP certs do not have >> >> > nodeIDs, they are not valid in RELOAD. >> >> > >> >> > cheers >> >> > >> >> >> >> >> >> Bruce >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 4, 2011 at 5:51 AM, Diego Suarez wrote: >> >> >> > Hi, >> >> >> > >> >> >> > Actually, I see this "virtual client" method more complicated an= d >> >> >> > confusing than splitting the identities of users and devices. >> >> >> > >> >> >> > With this model, you are gonna have a device identified by a PKC= that >> >> >> > includes a username and a nodeID acting as a peer, but only usin= g its >> >> >> > nodeID. And several users connected to the device as virtual cli= ents >> >> >> > identified by PKCs including a username and a nodeID, but only u= sing >> >> >> > their usernames. >> >> >> > >> >> >> > One of the more confusing things I see here is the access contro= l. >> >> >> > Imagine we have a device, with PKC ( # user =3D device1, nodeID = =3D 100 # ) >> >> >> > and two users ( # user =3D user1, nodeID =3D 200 # and # user = =3D user2, >> >> >> > nodeID =3D 300 # ) connected to that device acting as virtual cl= ients. >> >> >> > >> >> >> > If user1 wants to perform a USER-NODE-MATCH access control relat= ed to >> >> >> > the peer she is operating from ( actually the nodeID =3D 100 nor= the >> >> >> > virtual one with nodeID =3D 200 ) and her username ( user =3D us= er1 ), she >> >> >> > is gonna have to create a request signed with her PKC and the PK= C of the >> >> >> > device. This request need to be doubled signed ( by the peer to = grant >> >> >> > the nodeID =3D 100 and by the user to grant the user =3D user 1 = ). However, >> >> >> > this double signed request intended for nodeID =3D 100 and user = =3D user1 is >> >> >> > gonna include two users =3D device1 and user1 and two nodeID =3D= 100 and >> >> >> > 200. This is confusing for me. Therefore, from my point of view,= it >> >> >> > makes sense to me to remove the username from the device and the= node >> >> >> > from the users since we are not using them and confuse the acces= s >> >> >> > control. >> >> >> > >> >> >> > Also, splitting identities have another advantages like greater >> >> >> > interoperability with traditional SIP systems. Imagine a company= running >> >> >> > a SIP system, where users are identified by a PKC including a SI= P >> >> >> > username, that wants to extend its coverage interconnecting it w= ith a >> >> >> > P2PSIP system. With the actual certification model, SIP PKCs are= not >> >> >> > valid for the new P2PSIP side of the system. All the users have = to be >> >> >> > re-certificated to have a PKC including the old SIP username and= a >> >> >> > nodeID. However, with the split proposal SIP certificates are st= ill >> >> >> > valid in the P2PSIP side of the system and interoperable within = the two >> >> >> > networks, and only the devices intended to be used in the P2PSIP= side >> >> >> > have to be certified with a nodeID. >> >> >> > >> >> >> > >> >> >> > cheers >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > On Sat, 2011-07-02 at 16:53 -0400, Bruce Lowekamp wrote: >> >> >> >> With the current definition of the protocol, split routing IDs = and >> >> >> >> user IDs can be achieved by having the host node participate as= a peer >> >> >> >> (or as a client, honestly) using its own cert and the attached = users >> >> >> >> represented as virtual clients, i.e. generate messages as if th= ey are >> >> >> >> on separate nodes attached to the host node as a client. >> >> >> >> >> >> >> >> If you wanted to implement it "natively," other than the >> >> >> >> USER-NODE-MATCH, as mentioned before, I can only find two chang= es that >> >> >> >> would need to be made to support split identities. >> >> >> >> >> >> >> >> For processing StoreReq: >> >> >> >> o =C2=A0For original (non-replica) stores, the StoreReq is sign= ed by a >> >> >> >> =C2=A0 =C2=A0 =C2=A0 credential which is authorized to write th= is kind at this >> >> >> >> =C2=A0 =C2=A0 =C2=A0 Resource-Id. =C2=A0If this check fails, th= e request MUST be rejected >> >> >> >> =C2=A0 =C2=A0 =C2=A0 with an Error_Forbidden error. >> >> >> >> >> >> >> >> and the definition of credential in beginning of 10.3. >> >> >> >> >> >> >> >> >> >> >> >> Assuming that there is not something I'm missing with using vir= tual >> >> >> >> clients, I'd rather not make any changes. =C2=A0This is a compl= icated >> >> >> >> enough protocol, and I think adding special cases for something= like >> >> >> >> split identities just makes it more complicated. =C2=A0If any c= hanges were >> >> >> >> made, I would think it should be something to make it possible = for an >> >> >> >> extension to specify the change, but as long as the current pro= tocol >> >> >> >> is capable of handling the functional goals, I'd rather no chan= ges be >> >> >> >> made. >> >> >> >> >> >> >> >> Bruce >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Sat, Jul 2, 2011 at 1:04 PM, Marc Petit-Huguenin wrote: >> >> >> >> > -----BEGIN PGP SIGNED MESSAGE----- >> >> >> >> > Hash: SHA1 >> >> >> >> > >> >> >> >> > On 07/02/2011 09:28 AM, Diego Suarez wrote: >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> >> >>>From my point of view, in this case the user has to both pro= ve she is in >> >> >> >> >> possession of the PKC that includes the required username an= d also prove >> >> >> >> >> she is operating from the required node. However, modifying = the >> >> >> >> >> SignerIdentity to include multiple identities ( the user and= the >> >> >> >> >> device ) would not really prove that since only one signatur= e could be >> >> >> >> >> included (either the user's signature or the device's one). >> >> >> >> >> >> >> >> >> >> Therefore, I'd modify the SecurityBlock instead to allow the= inclusion >> >> >> >> >> of more than only one signature. >> >> >> >> >> >> >> >> >> >> For this case, the securityBlock would include two signature= s. One with >> >> >> >> >> the SignerIdentity of the user and the signature of the user= 's PKC >> >> >> >> >> (including the username ) and another with the SignerIdentit= y of the >> >> >> >> >> device and the signature of the device's PKC ( including the= nodeID). >> >> >> >> > >> >> >> >> > Right, something like this: >> >> >> >> > >> >> >> >> > struct { >> >> >> >> > =C2=A0 GenericCertificate certificates<0..2^16-1>; >> >> >> >> > =C2=A0 Signature =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0signatures= <0..2^16-1>; >> >> >> >> > =C2=A0 } SecurityBlock; >> >> >> >> > >> >> >> >> > Note that StoredData also needs to be modified: >> >> >> >> > >> >> >> >> > struct { >> >> >> >> > =C2=A0 uint32 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0length; >> >> >> >> > =C2=A0 uint64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0storage_time; >> >> >> >> > =C2=A0 uint32 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lifetime; >> >> >> >> > =C2=A0 StoredDataValue value; >> >> >> >> > =C2=A0 Signature =C2=A0 =C2=A0 =C2=A0 signatures<0..2^16-1>; >> >> >> >> > =C2=A0 } StoredData; >> >> >> >> > >> >> >> >> >> >> >> >> >> >> cheers >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, 2011-07-01 at 15:44 -0700, Marc Petit-Huguenin wrote= : >> >> >> >> >> Hi Diego, >> >> >> >> >> >> >> >> >> >> How does this work with an access control policy like USER-N= ODE-MATCH, which >> >> >> >> >> requires both a Node-ID and a username in the SignerIdentity= ? =C2=A0If the Node-ID >> >> >> >> >> and the username are in separate certificates, wouldn't that= require to extend >> >> >> >> >> the SignerIdentity structure to store multiple identities? >> >> >> >> >> >> >> >> >> >> Thanks. >> >> >> >> >> >> >> >> >> >> On 06/09/2011 10:47 AM, Diego Suarez wrote: >> >> >> >> >>>>> I think it would require a (slight) modification in the b= ase document. >> >> >> >> >>>>> Current P2PSIP certification model is based on a single P= KC (including >> >> >> >> >>>>> both usernames and nodeIDs) that uniquely identifies a us= er and her >> >> >> >> >>>>> devices. On the other hand, our model is base on a split = certification. >> >> >> >> >>>>> Devices and users are independent. Each device has its ow= n PKC including >> >> >> >> >>>>> a nodeID and a PK. Similarly, each user has her own PKC i= ncluding her >> >> >> >> >>>>> username and a PK. This approach do not prevent a central= ized entity >> >> >> >> >>>>> (such as an offline CA) to have information related to th= e devices each >> >> >> >> >>>>> user (or company, etc.) has registered, but permits, amon= g other >> >> >> >> >>>>> improvements, a user to be connected to the system throug= h devices she >> >> >> >> >>>>> has not registered herself such as a phone issued by a te= lco or a fixed >> >> >> >> >>>>> phone in a laboratory shared by all the members of a rese= arch group. >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wr= ote: >> >> >> >> >>>>> Does this model really required modifications in the base= document, or can it be >> >> >> >> >>>>> designed as an extension? =C2=A0(Unfortunately the paper = is not freely available, so >> >> >> >> >>>>> it is difficult to know really what is needed for this). >> >> >> >> >>>>> >> >> >> >> >>>>> On 06/09/2011 07:31 AM, Diego Suarez wrote: >> >> >> >> >>>>>>>> Hi, >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> I had in mind writing a draft about this, but since I'= m running out of >> >> >> >> >>>>>>>> time, I would like to summarize a new certification mo= del for P2PSIP I >> >> >> >> >>>>>>>> have been working on, in case it is of interest for th= e group. >> >> >> >> >>>>>>>> Further details can be found in paper: >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, = =C2=A0Advantages of >> >> >> >> >>>>>>>> identity certificate segregation in P2PSIP systems, = =C2=A0Communications, >> >> >> >> >>>>>>>> IET, vol. 5, pp. 879 889, Apr. 2011. >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> The idea is to split the certification of users and de= vices. Devices are >> >> >> >> >>>>>>>> identified by PKCs including a nodeID and the PK of th= e device, while >> >> >> >> >>>>>>>> users are identified by PKCs including a username and = the PK of the >> >> >> >> >>>>>>>> user. Similar models have been used before in other co= mmunications >> >> >> >> >>>>>>>> systems, such as GSM where devices and users are separ= ately represented >> >> >> >> >>>>>>>> by the international mobile equipment identity (IMEI) = stored in the >> >> >> >> >>>>>>>> phones and the international mobile subscriber identit= y (IMSI) stored in >> >> >> >> >>>>>>>> the user subscriber identity module (SIM), respectivel= y. >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> Motivations of this model are: >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> - Users and devices are different entities performing = different >> >> >> >> >>>>>>>> roles within a P2PSIP system. Devices are nodes of the= P2P >> >> >> >> >>>>>>>> overlay network (represented by a nodeID) that offer s= ervices >> >> >> >> >>>>>>>> (to route messages, to store data, . . .) to the syste= m, while >> >> >> >> >>>>>>>> users (represented by an username) utilize these servi= ces, >> >> >> >> >>>>>>>> usually to establish media communications using SIP. >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> - Support for mobility scenarios where a user may be l= ogged at different >> >> >> >> >>>>>>>> devices at the same time using the same PKC. >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> - Support several users to be logged in the same devic= e (like a fixed >> >> >> >> >>>>>>>> phone) at the same time. >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> - Support for user independent hard-coded devices. >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> - Interoperability with SIP. SIP certificates are not = valid in actual >> >> >> >> >>>>>>>> P2PSIP since they don't include a nodeID. >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> cheers >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> Diego Su=C3=A1rez >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrot= e: >> >> >> >> >>>>>>>>> Unless something major comes up, we plan to request t= he newest version >> >> >> >> >>>>>>>>> of the base draft, draft-ietf-p2psip-base-15, be publ= ished. I'll put >> >> >> >> >>>>>>>>> in the request in a week (June 16th or 17th). If ther= e are any further >> >> >> >> >>>>>>>>> comments from the last call a while ago (or further c= omments on the >> >> >> >> >>>>>>>>> comments since then), please send them to the list AS= AP. >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>>> Thanks, >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>>> David (as chair) >> >> >> >> > >> >> >> >> > - -- >> >> >> >> > Marc Petit-Huguenin >> >> >> >> > Personal email: marc@petit-huguenin.org >> >> >> >> > Professional email: petithug@acm.org >> >> >> >> > Blog: http://blog.marc.petit-huguenin.org >> >> >> >> > -----BEGIN PGP SIGNATURE----- >> >> >> >> > Version: GnuPG v1.4.11 (GNU/Linux) >> >> >> >> > >> >> >> >> > iEYEARECAAYFAk4PT4sACgkQ9RoMZyVa61dPvACeITly6/Zqumz4e4ZrAn1yG= I4x >> >> >> >> > ay4AoJ11vmCRDkL8pXuN71qaZXhw5JTZ >> >> >> >> > =3DTp+D >> >> >> >> > -----END PGP SIGNATURE----- >> >> >> >> > _______________________________________________ >> >> >> >> > P2PSIP mailing list >> >> >> >> > P2PSIP@ietf.org >> >> >> >> > https://www.ietf.org/mailman/listinfo/p2psip >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> >> > >> > >> > >> > > > > From bbl@lowekamp.net Sat Jul 16 18:42:00 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16D121F8829 for ; Sat, 16 Jul 2011 18:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqXQXHqqpqIK for ; Sat, 16 Jul 2011 18:41:59 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40E3C21F8828 for ; Sat, 16 Jul 2011 18:41:58 -0700 (PDT) Received: by ewy19 with SMTP id 19so1247551ewy.31 for ; Sat, 16 Jul 2011 18:41:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.43.150 with SMTP id l22mr1757507eeb.190.1310866915342; Sat, 16 Jul 2011 18:41:55 -0700 (PDT) Received: by 10.14.127.1 with HTTP; Sat, 16 Jul 2011 18:41:55 -0700 (PDT) In-Reply-To: References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E0E4DBE.5060302@acm.org> <1309624099.5232.23.camel@santeles> <4E0F4F8D.9080108@acm.org> <1309773089.5716.43.camel@santeles> <1310123712.22737.73.camel@toedo> <1310143982.6132.75.camel@santeles> <1310232343.5262.27.camel@santeles> Date: Sat, 16 Jul 2011 21:41:55 -0400 Message-ID: From: Bruce Lowekamp To: Diego Suarez Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 17 Jul 2011 01:42:01 -0000 Sorry for replying to my own message. I meant to add this to the top... I think there's an interesting philosophical discussion of whether it would have been better to have split identities. My point in the previous reply is not that split identities wouldn't work, I just don't think there is anything they support that can't be done with the existing protocol. So I'm OK having a conversation about how they would work. But when you say you don't believe that clients (virtual or not) provide the same functionality, I have to disagree with that---the protocol was designed to support clients, and there is no problem with the functionality they receive that I am aware of. I have mixed feelings about whether using split identities would be good or bad. So much the security of p2p algorithms depends on the inability of an attacker to chose a location within the overlay. It makes me a bit paranoid to decouple identity in that way---although I'm not sure that in practice managing pure node id certificates would be that much harder---in the end, you still need to identify what certificates are attacking the network. The biggest difference that I can see is that with split identities you would almost double the number of certificates on the wire/being stored. I think there would have to be a significant feature advantage to justify that, and right now I'm not seeing it. Bruce On Sat, Jul 16, 2011 at 9:27 PM, Bruce Lowekamp wrote: > On Sat, Jul 9, 2011 at 1:25 PM, Diego Suarez wrote= : >> First of all, I would like to introduce the motivation of the idea of >> split certification, since I think it is an important point in this >> discussion and would help to clarify why I think that virtual clients do >> not really allow several users to be connected from the same device. >> Also, it could help to clarify if I taking a false premise to support >> split certification when I should not. >> >> As far as I understood, the idea of nodeIDs in RELOAD is to represent >> devices, despite usernames and nodeIDs are included in the same >> certificate. Draft says: "If a user has more than one device, typically >> they would get one certificate for each device. =C2=A0This allows each d= evice >> to act as a separate peer." However, it also exist the possibility of >> having a single certificate with several nodeIDs. In this case, a user >> with two devices ( for example a mobile and a fixed phone ) would have a >> certificate with a username and two nodeIDs, one for each device; being >> able to be connected to network and contactable in both devices at the >> same time. >> >> Regarding the first alternative, there is something I have not clear: If >> a user has a different certificate for each device she has, would these >> certificates have the same username and different nodeIDs? and if so, >> would the PK be the same in all the certificates or a different PK in >> each one?; or would the user have a different username, a different >> nodeID and a different PK in each certificate?. Said this, if we want >> each device to have its own certificate, why don't make it simpler a >> split device's identity from the user's identity? > > The only requirement is that no two nodes can be trying to use the > same nodeid at the same time. =C2=A0Otherwise, it doesn't make any > difference to the protocol if two physical devices use the same nodeid > at different times. =C2=A0The draft doesn't say much about managing this > because outside of this requirement, it's really up to the > implementation. > >> >> The second alternative (several nodeIDs in a single cert) works well for >> me if the user if using the same devices all the time, for example a >> user with one cert with a nodeID for her mobile phone and another nodeID >> for her office fixed phone; but has some limitations. What happens if >> the user is out for one week in another office and wants to be connected >> from there ? The simple answer seems to be "use the nodeID she was using >> in the other office". But, is it not weird to bother in the first place >> to give a different nodeID to each user's device and now use the same >> nodeID for two different ones? Also, won't be useful to have each device >> identified by a unique nodeID within the network for security reasons or >> to have permanent statistics about its past behavior for network >> maintenance or routing purposes? > > I don't see that it would be that useful. =C2=A0It certainly doesn't give > you any additional security, since you can't enforce it at a protocol > level. =C2=A0If you're interested in logging information about hardware o= r > software configuration nodes are using, you can certainly do > that---and if you do that, you've solved the problem. > > >> >> With this in mind, it came to me the idea of a split certification. With >> split certification, users would be identified always by the same >> certificate independently of the device they are using (something that >> does not happen in the first alternative). Also, devices would be always >> identified by the same and unique cert (something that does not happen >> in the second). Besides, users could be connected to as many devices as >> they want without have to been re-certified to get more nodeIDs. I think >> this would simplify the certification of the system and improve its >> maintenance. Also, extra improvements come with this alternative, like >> greater interoperability with SIP ( as I've already commented in >> previous mails ) or the easy deployment of more secure networks formed >> by hard coded (including a certificate with a nodeID) devices. > > This can all be done with the existing protocol. =C2=A0And, as I said in = my > earlier responses, I don't believe there are any interop issues with > SIP, I think a reload cert could be 6072 compatible, though I don't > claim to be an expert on that or to have tested it. > >> >> The comments to the other improvement I see of this alternative, related >> to several users connected to the same device, are inline. >> >> On Fri, 2011-07-08 at 19:06 -0400, Bruce Lowekamp wrote: >>> inline >>> >>> On Fri, Jul 8, 2011 at 12:53 PM, Diego Suarez wr= ote: >>> > Hi, >>> > >>> > I have the impression I am not explaining myself well. I am not sayin= g >>> > that clients in RELOAD do not work well, I am just saying that I do n= ot >>> > see how they can be used to allow several users to be connected to th= e >>> > same the device; at least not with full functionalities. >>> > >>> > Lets go back to the example: >>> > Imagine we have a device, with PKC ( # user =3D device1, nodeID =3D 1= 00 # ) >>> > and two users ( # user =3D user1, nodeID =3D 200 # and # user =3D use= r2, >>> > nodeID =3D 300 # ) connected to that device acting as virtual clients= . >>> > >>> > As you have said, during registration, users store a destination list >>> > that start with the device ( nodeID =3D 100 ) and finishes with the >>> > client's nodeID ( nodeID =3D 200 for user1 and nodeID =3D 300 for use= r2). >>> > This works well, and allows other peers of the system to reach them. >>> > >>> > However, the problem is with the access control. Being virtual client= s, >>> > users can perform NODE-USER-MATCH accesses related to their client's >>> > nodeIDs and usernames: 200-user1 for user1 and 300-user2 for user2. >>> > Nevertheless, this is not what we want in this case. In this case, wh= ere >>> > user1 and user2 are supposed to be connected to the same device (node= ID >>> > =3D 100), they should be allowed to perform NODE-USER-MATCH accesses >>> > related to this device and their usernames: 100-user1 for user1 and >>> > 100-user2 for user2. >>> >>> why? =C2=A0It works as designed when they use their client nodeid. >> >> Well, I've said before, if the idea of RELOAD is to have each device be >> identified by a different nodeID, from my point of view two users >> operating from the same device should be using the same nodeID. Two >> users connected to the same device, using different nodeIDs, that also >> reuse later with another devices are not actually breaking the >> certification idea of 1device =3D 1nodeID? > > The idea is at most one device on the overlay at any given time with > the same node id. =C2=A0The ability to act as a particular node id is > controlled by the certificate mechanism. =C2=A0No other assumptions. > > >> >> >>> In >>> fact, using the host's nodeid here gives the exact opposite behavior >>> of what you would want---if one of the multiple users switches to a >>> different device, they may wind up with a stale entry pointing to the >>> device they are no longer at, whereas if the user uses their own >>> certificate&nodeid, when they register their route to the new host the >>> old one is automatically removed because they're using the same client >>> nodeid. >> >> I think this would be a fail of the implementation not of the proposal >> and that can also happen with the actual model of RELOAD. Imagine a user >> with a cert (including a username and two nodeIDs ) connected to two >> different devices. If she disconnects from one of the devices but >> forgets to remove that entry point, she may also wind up with a stale >> entry pointing to a device she is no longer at. >> > > Exactly. =C2=A0If you use the same nodeid for that person, you don't need > to worry about stale entries. > > > >> >>> >>> > Because, if not, we are not really implementing >>> > this functionality. >>> >>> what functionality? >>> >>> > In order to be fully implemented, several users >>> > connected to the same device should have the same functionalities tha= t a >>> > single user connected to this device has, and this is not the case us= ing >>> > virtual clients. >>> >>> could you clarify what you're referring to here? =C2=A0 I don't know wh= at >>> functionality I would expect multiple users signed into the same >>> device to have that wouldn't be provided using their own nodeids. >>> >> >> I would try to clarify what I mean with an example that presents three >> possible cases that can occur in RELOAD: >> >> case 1: >> >> User1 with cert ( user =3D user1, nodeID =3D 100 ) is connected to the >> network using a device. Therefore she can perform any access related to >> her user( USER-MATCH =3D user1 ), nodeID ( NODE-MATCH =3D 100 ) or the >> combination of both (USER-NODE-MATCH =3D user1-100). >> >> case 2: >> >> The same User1 with the same cert is connected to the network using the >> same device. But now, also User2 ( user =3D user2, nodeID =3D 200 ) and >> User3 ( user =3D user3, nodeID =3D 300 ) are connected to that device as >> virtual clients. User1 can perform the same kind of accesses than >> in case 1. User2 can perform accesses related her user( USER-MATCH =3D >> user2 ), virtual nodeID ( NODE-MATCH =3D 200 ) or the combination of bot= h >> (USER-NODE-MATCH =3D user2-200). User3 is ( USER-MATCH =3D user3 ), virt= ual >> nodeID ( NODE-MATCH =3D 300 ) or the combination of both (USER-NODE-MATC= H >> =3D user3-300). >> >> >> case 3: >> >> A "non-user" device ( user =3D lab1, nodeID =3D 100 ) is connected to th= e >> network. Two users, User2 and User3 (with the same credentials that in >> the previous case) are connected to that device. So, User2 and User3 can >> perform the same accesses than in case 3. >> >> In this three examples, taking a look a the accesses related to NODE, >> the important thing here, we see different cases of users presumably >> connected to the same device, that should have the same functionalities >> over that device but actually they have not. Precisely, User1 can >> perform accesses on behalf of the device, while user2 and user3 cannot. >> I would expect for all the cases the same rights for a user, either she >> has full control over the device ( to perform accesses like NODE-MATCH = =3D >> 100 ) or she does not have any control at all over it. But not these >> different possibilities depending on how the user is connected to the >> device. This is what I wanted to mean with no having full >> functionalities. Furthermore, in case 2 we are forcing User1 to be >> connected to the network while User2 and User3 wish to continue using >> the device. It would be possible here that User1 entered in an >> =E2=80=98invisible mode=E2=80=99 by removing her contact information fro= m the network. >> In such case, User1 seemed to be offline for the other users of the >> network (neither they could have the knowledge that she is online or >> access to her contact information) but she would be actually online >> since she could access to all the resources of the network, like her >> voicemail or the contact information of other users to initiate media >> calls. > > I really lost you on this point. =C2=A0Reload is an overlay and key-based > storage protocol. =C2=A0The only functionality it gives you are those > abilities, there's nothing about "seems to be offline" that would come > out of the core protocol. =C2=A0A usage, such as the sip usage, specifies > how to use it to deliver functionality to the user. =C2=A0In the sip-usag= e > case, it stores destination lists indexed by AORs---so it doesn't > matter whether the users are using the nodeid of a peer or a client. > They are reachable via the destination list they specify. =C2=A0I guess y= ou > could specify a usage that only stored the peer's nodeid and so didn't > support clients, but that would be broken. =C2=A0Any information in reloa= d > on how to contact a node needs to be a destination list. > > > Bruce > > >> >> >> cheers >> >>> Bruce >>> >>> >>> > >>> > cheers >>> > >>> > >>> > >>> > On Fri, 2011-07-08 at 09:40 -0400, Bruce Lowekamp wrote: >>> >> On Fri, Jul 8, 2011 at 7:15 AM, Diego Suarez = wrote: >>> >> > Hi Bruce, >>> >> > >>> >> > Answers inline. >>> >> > >>> >> > >>> >> > On Thu, 2011-07-07 at 22:24 -0400, Bruce Lowekamp wrote: >>> >> >> Diego, >>> >> >> >>> >> >> Please take some time understanding how real clients work in relo= ad. >>> >> >> Then just have the virtual clients use the same messages. =C2=A0T= he virtual >>> >> >> clients use their own nodeids, not the host's nodeid. =C2=A0It al= l works >>> >> >> fine. >>> >> > >>> >> > I agree, this works fine for clients, but, from my point of view, = it >>> >> > does not for several users connected to the same device. The fact = that >>> >> > clients ( or virtual clients ) use their own nodeIDs and not the h= ost's >>> >> > nodeIDs is precisely what I see as the problem of using virtual cl= ients >>> >> > to allow several users to be connected to the same device. Since v= irtual >>> >> > clients are not using the device's nodeID, they cannot perform >>> >> > operations ( like NODE-MATCH or USER-NODE-MATCH accesses) from tha= t >>> >> > device like they should if they were actually connected to the sys= tem >>> >> > from it. As I've said in my previous mail, they only way I see to = allow >>> >> > so is the device adding an extra signature to the message, with th= e >>> >> > already commented problem of two users and two nodeIDs in it. >>> >> > >>> >> >>> >> Since a client is using its own nodeid, NODE-MATCH and USER-NODE-MAT= CH >>> >> are performed using the client's nodeid. =C2=A0In the case of the si= p >>> >> usage, it's done using USER-NODE-MATCH. =C2=A0This is the client's >>> >> rfc822Name and the client's nodeid. =C2=A0In that registration, it s= tores a >>> >> destination list that starts with the peer and finishes with the >>> >> client's nodeid (in most cases, would be only these two entries). >>> >> This is how clients are supported in reload and for the sip usage. >>> >> >>> >> > >>> >> >> I don't see a real problem with a host node having an >>> >> >> "admin@example.com" or "node12345@example.com" name attached to i= t. >>> >> >> Routers pretty much always have DNS names that are descriptive of >>> >> >> where they are to admins, even though routing protocols don't req= uire >>> >> >> it. >>> >> > >>> >> > Neither do I except for cases, like the presented before, of sever= al >>> >> > users in the same device. >>> >> > >>> >> >> >>> >> >> Regarding certs, 6072 has the following text: >>> >> >> >>> >> >> =C2=A0 =C2=A0If the certificate is signed by a trusted certificat= ion authority, >>> >> >> =C2=A0 =C2=A0and one of the names in the SubjectAltName matches t= he original URI, >>> >> >> =C2=A0 =C2=A0then this certificate MAY be used, but only for exac= tly the original >>> >> >> >>> >> >> It's been awhile since I've looked at that in detail, but it appe= ars >>> >> >> to me that a reload cert could be perfectly valid for use with 60= 72 as >>> >> >> long as it has the sip uri in it. =C2=A0Though I'm not immediatel= y >>> >> >> convinced that this is that useful, regardless. >>> >> > >>> >> > The problem is not with RELOAD certs being used in SIP systems, bu= t with >>> >> > SIP certs being used in RELOAD systems. Since SIP certs do not hav= e >>> >> > nodeIDs, they are not valid in RELOAD. >>> >> > >>> >> > cheers >>> >> > >>> >> >> >>> >> >> Bruce >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Mon, Jul 4, 2011 at 5:51 AM, Diego Suarez wrote: >>> >> >> > Hi, >>> >> >> > >>> >> >> > Actually, I see this "virtual client" method more complicated a= nd >>> >> >> > confusing than splitting the identities of users and devices. >>> >> >> > >>> >> >> > With this model, you are gonna have a device identified by a PK= C that >>> >> >> > includes a username and a nodeID acting as a peer, but only usi= ng its >>> >> >> > nodeID. And several users connected to the device as virtual cl= ients >>> >> >> > identified by PKCs including a username and a nodeID, but only = using >>> >> >> > their usernames. >>> >> >> > >>> >> >> > One of the more confusing things I see here is the access contr= ol. >>> >> >> > Imagine we have a device, with PKC ( # user =3D device1, nodeID= =3D 100 # ) >>> >> >> > and two users ( # user =3D user1, nodeID =3D 200 # and # user = =3D user2, >>> >> >> > nodeID =3D 300 # ) connected to that device acting as virtual c= lients. >>> >> >> > >>> >> >> > If user1 wants to perform a USER-NODE-MATCH access control rela= ted to >>> >> >> > the peer she is operating from ( actually the nodeID =3D 100 no= r the >>> >> >> > virtual one with nodeID =3D 200 ) and her username ( user =3D u= ser1 ), she >>> >> >> > is gonna have to create a request signed with her PKC and the P= KC of the >>> >> >> > device. This request need to be doubled signed ( by the peer to= grant >>> >> >> > the nodeID =3D 100 and by the user to grant the user =3D user 1= ). However, >>> >> >> > this double signed request intended for nodeID =3D 100 and user= =3D user1 is >>> >> >> > gonna include two users =3D device1 and user1 and two nodeID = =3D 100 and >>> >> >> > 200. This is confusing for me. Therefore, from my point of view= , it >>> >> >> > makes sense to me to remove the username from the device and th= e node >>> >> >> > from the users since we are not using them and confuse the acce= ss >>> >> >> > control. >>> >> >> > >>> >> >> > Also, splitting identities have another advantages like greater >>> >> >> > interoperability with traditional SIP systems. Imagine a compan= y running >>> >> >> > a SIP system, where users are identified by a PKC including a S= IP >>> >> >> > username, that wants to extend its coverage interconnecting it = with a >>> >> >> > P2PSIP system. With the actual certification model, SIP PKCs ar= e not >>> >> >> > valid for the new P2PSIP side of the system. All the users have= to be >>> >> >> > re-certificated to have a PKC including the old SIP username an= d a >>> >> >> > nodeID. However, with the split proposal SIP certificates are s= till >>> >> >> > valid in the P2PSIP side of the system and interoperable within= the two >>> >> >> > networks, and only the devices intended to be used in the P2PSI= P side >>> >> >> > have to be certified with a nodeID. >>> >> >> > >>> >> >> > >>> >> >> > cheers >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > On Sat, 2011-07-02 at 16:53 -0400, Bruce Lowekamp wrote: >>> >> >> >> With the current definition of the protocol, split routing IDs= and >>> >> >> >> user IDs can be achieved by having the host node participate a= s a peer >>> >> >> >> (or as a client, honestly) using its own cert and the attached= users >>> >> >> >> represented as virtual clients, i.e. generate messages as if t= hey are >>> >> >> >> on separate nodes attached to the host node as a client. >>> >> >> >> >>> >> >> >> If you wanted to implement it "natively," other than the >>> >> >> >> USER-NODE-MATCH, as mentioned before, I can only find two chan= ges that >>> >> >> >> would need to be made to support split identities. >>> >> >> >> >>> >> >> >> For processing StoreReq: >>> >> >> >> o =C2=A0For original (non-replica) stores, the StoreReq is sig= ned by a >>> >> >> >> =C2=A0 =C2=A0 =C2=A0 credential which is authorized to write t= his kind at this >>> >> >> >> =C2=A0 =C2=A0 =C2=A0 Resource-Id. =C2=A0If this check fails, t= he request MUST be rejected >>> >> >> >> =C2=A0 =C2=A0 =C2=A0 with an Error_Forbidden error. >>> >> >> >> >>> >> >> >> and the definition of credential in beginning of 10.3. >>> >> >> >> >>> >> >> >> >>> >> >> >> Assuming that there is not something I'm missing with using vi= rtual >>> >> >> >> clients, I'd rather not make any changes. =C2=A0This is a comp= licated >>> >> >> >> enough protocol, and I think adding special cases for somethin= g like >>> >> >> >> split identities just makes it more complicated. =C2=A0If any = changes were >>> >> >> >> made, I would think it should be something to make it possible= for an >>> >> >> >> extension to specify the change, but as long as the current pr= otocol >>> >> >> >> is capable of handling the functional goals, I'd rather no cha= nges be >>> >> >> >> made. >>> >> >> >> >>> >> >> >> Bruce >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> On Sat, Jul 2, 2011 at 1:04 PM, Marc Petit-Huguenin wrote: >>> >> >> >> > -----BEGIN PGP SIGNED MESSAGE----- >>> >> >> >> > Hash: SHA1 >>> >> >> >> > >>> >> >> >> > On 07/02/2011 09:28 AM, Diego Suarez wrote: >>> >> >> >> >> Hi, >>> >> >> >> >> >>> >> >> >> >>>From my point of view, in this case the user has to both pr= ove she is in >>> >> >> >> >> possession of the PKC that includes the required username a= nd also prove >>> >> >> >> >> she is operating from the required node. However, modifying= the >>> >> >> >> >> SignerIdentity to include multiple identities ( the user an= d the >>> >> >> >> >> device ) would not really prove that since only one signatu= re could be >>> >> >> >> >> included (either the user's signature or the device's one). >>> >> >> >> >> >>> >> >> >> >> Therefore, I'd modify the SecurityBlock instead to allow th= e inclusion >>> >> >> >> >> of more than only one signature. >>> >> >> >> >> >>> >> >> >> >> For this case, the securityBlock would include two signatur= es. One with >>> >> >> >> >> the SignerIdentity of the user and the signature of the use= r's PKC >>> >> >> >> >> (including the username ) and another with the SignerIdenti= ty of the >>> >> >> >> >> device and the signature of the device's PKC ( including th= e nodeID). >>> >> >> >> > >>> >> >> >> > Right, something like this: >>> >> >> >> > >>> >> >> >> > struct { >>> >> >> >> > =C2=A0 GenericCertificate certificates<0..2^16-1>; >>> >> >> >> > =C2=A0 Signature =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0signature= s<0..2^16-1>; >>> >> >> >> > =C2=A0 } SecurityBlock; >>> >> >> >> > >>> >> >> >> > Note that StoredData also needs to be modified: >>> >> >> >> > >>> >> >> >> > struct { >>> >> >> >> > =C2=A0 uint32 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0length; >>> >> >> >> > =C2=A0 uint64 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0storage_time= ; >>> >> >> >> > =C2=A0 uint32 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lifetime; >>> >> >> >> > =C2=A0 StoredDataValue value; >>> >> >> >> > =C2=A0 Signature =C2=A0 =C2=A0 =C2=A0 signatures<0..2^16-1>; >>> >> >> >> > =C2=A0 } StoredData; >>> >> >> >> > >>> >> >> >> >> >>> >> >> >> >> cheers >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> On Fri, 2011-07-01 at 15:44 -0700, Marc Petit-Huguenin wrot= e: >>> >> >> >> >> Hi Diego, >>> >> >> >> >> >>> >> >> >> >> How does this work with an access control policy like USER-= NODE-MATCH, which >>> >> >> >> >> requires both a Node-ID and a username in the SignerIdentit= y? =C2=A0If the Node-ID >>> >> >> >> >> and the username are in separate certificates, wouldn't tha= t require to extend >>> >> >> >> >> the SignerIdentity structure to store multiple identities? >>> >> >> >> >> >>> >> >> >> >> Thanks. >>> >> >> >> >> >>> >> >> >> >> On 06/09/2011 10:47 AM, Diego Suarez wrote: >>> >> >> >> >>>>> I think it would require a (slight) modification in the = base document. >>> >> >> >> >>>>> Current P2PSIP certification model is based on a single = PKC (including >>> >> >> >> >>>>> both usernames and nodeIDs) that uniquely identifies a u= ser and her >>> >> >> >> >>>>> devices. On the other hand, our model is base on a split= certification. >>> >> >> >> >>>>> Devices and users are independent. Each device has its o= wn PKC including >>> >> >> >> >>>>> a nodeID and a PK. Similarly, each user has her own PKC = including her >>> >> >> >> >>>>> username and a PK. This approach do not prevent a centra= lized entity >>> >> >> >> >>>>> (such as an offline CA) to have information related to t= he devices each >>> >> >> >> >>>>> user (or company, etc.) has registered, but permits, amo= ng other >>> >> >> >> >>>>> improvements, a user to be connected to the system throu= gh devices she >>> >> >> >> >>>>> has not registered herself such as a phone issued by a t= elco or a fixed >>> >> >> >> >>>>> phone in a laboratory shared by all the members of a res= earch group. >>> >> >> >> >>>>> >>> >> >> >> >>>>> >>> >> >> >> >>>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin w= rote: >>> >> >> >> >>>>> Does this model really required modifications in the bas= e document, or can it be >>> >> >> >> >>>>> designed as an extension? =C2=A0(Unfortunately the paper= is not freely available, so >>> >> >> >> >>>>> it is difficult to know really what is needed for this). >>> >> >> >> >>>>> >>> >> >> >> >>>>> On 06/09/2011 07:31 AM, Diego Suarez wrote: >>> >> >> >> >>>>>>>> Hi, >>> >> >> >> >>>>>>>> >>> >> >> >> >>>>>>>> I had in mind writing a draft about this, but since I= 'm running out of >>> >> >> >> >>>>>>>> time, I would like to summarize a new certification m= odel for P2PSIP I >>> >> >> >> >>>>>>>> have been working on, in case it is of interest for t= he group. >>> >> >> >> >>>>>>>> Further details can be found in paper: >>> >> >> >> >>>>>>>> >>> >> >> >> >>>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, = =C2=A0Advantages of >>> >> >> >> >>>>>>>> identity certificate segregation in P2PSIP systems, = =C2=A0Communications, >>> >> >> >> >>>>>>>> IET, vol. 5, pp. 879 889, Apr. 2011. >>> >> >> >> >>>>>>>> >>> >> >> >> >>>>>>>> >>> >> >> >> >>>>>>>> The idea is to split the certification of users and d= evices. Devices are >>> >> >> >> >>>>>>>> identified by PKCs including a nodeID and the PK of t= he device, while >>> >> >> >> >>>>>>>> users are identified by PKCs including a username and= the PK of the >>> >> >> >> >>>>>>>> user. Similar models have been used before in other c= ommunications >>> >> >> >> >>>>>>>> systems, such as GSM where devices and users are sepa= rately represented >>> >> >> >> >>>>>>>> by the international mobile equipment identity (IMEI)= stored in the >>> >> >> >> >>>>>>>> phones and the international mobile subscriber identi= ty (IMSI) stored in >>> >> >> >> >>>>>>>> the user subscriber identity module (SIM), respective= ly. >>> >> >> >> >>>>>>>> >>> >> >> >> >>>>>>>> Motivations of this model are: >>> >> >> >> >>>>>>>> >>> >> >> >> >>>>>>>> - Users and devices are different entities performing= different >>> >> >> >> >>>>>>>> roles within a P2PSIP system. Devices are nodes of th= e P2P >>> >> >> >> >>>>>>>> overlay network (represented by a nodeID) that offer = services >>> >> >> >> >>>>>>>> (to route messages, to store data, . . .) to the syst= em, while >>> >> >> >> >>>>>>>> users (represented by an username) utilize these serv= ices, >>> >> >> >> >>>>>>>> usually to establish media communications using SIP. >>> >> >> >> >>>>>>>> >>> >> >> >> >>>>>>>> - Support for mobility scenarios where a user may be = logged at different >>> >> >> >> >>>>>>>> devices at the same time using the same PKC. >>> >> >> >> >>>>>>>> >>> >> >> >> >>>>>>>> - Support several users to be logged in the same devi= ce (like a fixed >>> >> >> >> >>>>>>>> phone) at the same time. >>> >> >> >> >>>>>>>> >>> >> >> >> >>>>>>>> - Support for user independent hard-coded devices. >>> >> >> >> >>>>>>>> >>> >> >> >> >>>>>>>> - Interoperability with SIP. SIP certificates are not= valid in actual >>> >> >> >> >>>>>>>> P2PSIP since they don't include a nodeID. >>> >> >> >> >>>>>>>> >>> >> >> >> >>>>>>>> cheers >>> >> >> >> >>>>>>>> >>> >> >> >> >>>>>>>> Diego Su=C3=A1rez >>> >> >> >> >>>>>>>> >>> >> >> >> >>>>>>>> >>> >> >> >> >>>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wro= te: >>> >> >> >> >>>>>>>>> Unless something major comes up, we plan to request = the newest version >>> >> >> >> >>>>>>>>> of the base draft, draft-ietf-p2psip-base-15, be pub= lished. I'll put >>> >> >> >> >>>>>>>>> in the request in a week (June 16th or 17th). If the= re are any further >>> >> >> >> >>>>>>>>> comments from the last call a while ago (or further = comments on the >>> >> >> >> >>>>>>>>> comments since then), please send them to the list A= SAP. >>> >> >> >> >>>>>>>>> >>> >> >> >> >>>>>>>>> Thanks, >>> >> >> >> >>>>>>>>> >>> >> >> >> >>>>>>>>> David (as chair) >>> >> >> >> > >>> >> >> >> > - -- >>> >> >> >> > Marc Petit-Huguenin >>> >> >> >> > Personal email: marc@petit-huguenin.org >>> >> >> >> > Professional email: petithug@acm.org >>> >> >> >> > Blog: http://blog.marc.petit-huguenin.org >>> >> >> >> > -----BEGIN PGP SIGNATURE----- >>> >> >> >> > Version: GnuPG v1.4.11 (GNU/Linux) >>> >> >> >> > >>> >> >> >> > iEYEARECAAYFAk4PT4sACgkQ9RoMZyVa61dPvACeITly6/Zqumz4e4ZrAn1y= GI4x >>> >> >> >> > ay4AoJ11vmCRDkL8pXuN71qaZXhw5JTZ >>> >> >> >> > =3DTp+D >>> >> >> >> > -----END PGP SIGNATURE----- >>> >> >> >> > _______________________________________________ >>> >> >> >> > P2PSIP mailing list >>> >> >> >> > P2PSIP@ietf.org >>> >> >> >> > https://www.ietf.org/mailman/listinfo/p2psip >>> >> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> > >>> >> > >>> >> > >>> > >>> > >>> > >> >> >> > From bbl@lowekamp.net Sat Jul 16 18:47:33 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5044F21F87C6 for ; Sat, 16 Jul 2011 18:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=1.462, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ql-1ABUh+RV for ; Sat, 16 Jul 2011 18:47:32 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA8C921F8783 for ; Sat, 16 Jul 2011 18:47:31 -0700 (PDT) Received: by ewy19 with SMTP id 19so1248166ewy.31 for ; Sat, 16 Jul 2011 18:47:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.99.198 with SMTP id x46mr1755242eef.126.1310867250930; Sat, 16 Jul 2011 18:47:30 -0700 (PDT) Received: by 10.14.127.1 with HTTP; Sat, 16 Jul 2011 18:47:30 -0700 (PDT) In-Reply-To: <4E21D49F.9000100@acm.org> References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E00F7CE.7080402@acm.org> <4E0DB3EC.1040705@ericsson.com> <4E207F1C.9080500@acm.org> <4E21D49F.9000100@acm.org> Date: Sat, 16 Jul 2011 21:47:30 -0400 Message-ID: From: Bruce Lowekamp To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Breaking RELOAD [was Re: Identity certificate segregation] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 17 Jul 2011 01:47:33 -0000 On Sat, Jul 16, 2011 at 2:12 PM, Marc Petit-Huguenin wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/16/2011 09:41 AM, Cullen Jennings wrote: >> >> I think all the people that implemented early version know that changes = can, >> and will, =C2=A0 break backwards compatibility. I don't recall very many= places >> where I used this as augment for one way or another. I recall some place= s >> where it was 6 of one of half a dozen of the other and it made no fundam= ental >> difference to the protocol so we decided to go which what was already >> implemented. > > Well, I kind of disagree here. =C2=A0The problem is that *future* impleme= nters will > not have access to the whole history of the development of the RELOAD pro= tocol > when trying to decipher the specification. =C2=A0The RELOAD specification= is *not* > developer friendly (but it is not specific to this spec). =C2=A0I am stil= l not saying > that a protocol must be developer-friendly, just that the text describing= it > should be, and that when it makes no fundamental difference to the protoc= ol, > making it easier for future developers should have priority over not brea= king > compatibility. > While I think we're a bit late in the process for a wholesale rewrite (we've done it about twice), if you have specific suggestions on editorial issues that would make it clearer, please make them now while we might be able to adjust some of the text. >> That said some types of changes are very easy to move into a fully >> operational deployed DHT. Others are not. For example, a change that you= can >> detect the version number and then just have the software do the right t= hings >> is pretty easy particularly if both the new code and old code can exist = in >> the ring at the same time. A change where every device in the ring needs= to >> get a new certificate and you can' have a mixed ring with the old and ne= w >> certificates at the same time is not easy to deploy. > > I still do not see this as a good reason to stop fixing stuff in the prot= ocol. > What is the point of having internet *drafts* if they are to be considere= d as > standard track RFCs? There are quite a few people who want to build things on top of it, and it needs to not be a moving target for that to happen. Presumably, if a significant amount of practical experience shows things need to be changed, extensions and/or a v2.0 can be done. But right now the lack of a v1.0 is blocking other people's work. Bruce > >> >> To the point of this specific proposal for change. This fundamentally ch= anges >> the security model and nearly every part of this protocol that has anyth= ing >> to do with security - which is most of it. The suggestions is several ye= ars >> late - it was many years ago that this WG made the decision about what t= he >> general security model was doing to be. If people want this, it seems li= ke a >> fine thing to do in version 2.0 of the protocol. Thought my previous ema= il >> suggested that one could look at doing it in an extension, closer examin= ation >> of that makes me think there would be some real hard problems in trying = to do >> that as it requires all the security component to be re-thought and >> redesigned. > > OK, now we agree. > >> Given the current level of energy in the WG, that would take >> several years to happen. I have pretty much zero interest in doing that,= I'd >> like to actually have an RFC for this in the next year instead of severa= l >> years from now. As practical improvement of the protocol, I have not see= n a >> single use case proposed where this improves things so much we can actua= lly >> do something interesting that we can no do with the current proposal. >> >> >> >> On Jul 15, 2011, at 10:55 , Marc Petit-Huguenin wrote: >> >> On 07/07/2011 03:34 PM, Cullen Jennings wrote: >>>>> >>>>> This would break all the current deployments and implementation and n= ot >>>>> just in a way where some new software would need to be pushed out - a= ll >>>>> new certificates would need to be issues. From my point of view, this >>>>> is too late for this change and instead it could be addressed with an >>>>> extension. >> >> About this "breaking current deployment" thing, it seems to me that anyw= ay >> when RELOAD will be published as an RFC, the version number with be >> incremented to 1.0 (0x0a), so implementations of the RFC will *not* be >> compatible with *any* of the current implementations. =C2=A0And because = of this, I >> really do not understand why the authors of RELOAD are fighting so hard = to >> not break things that will be broken anyway - there was multiple instanc= es of >> things that could have been improved in the document but stayed because = of >> this (the fragment bit is one example of this). =C2=A0Having been there = multiple >> times I really understand the plight of early implementers but I would n= ever >> ever use this as a justification to keep useless stuff in a protocol. = =C2=A0What >> should have been done is simply to increment the version each time a new >> version of the draft would have broken interoperability - and we had the >> possibility to do that 8 times (versions 0.1 to 0.9). >> >>>>> >>>>> On Jul 1, 2011, at 5:47 AM, Gonzalo Camarillo wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> please, let me know whether or not these modifications will be >>>>>> included in the base draft at this point. >>>>>> >> >> [...] >> >>> > >> Cullen Jennings For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk4h1J0ACgkQ9RoMZyVa61cFxQCfTPJuP/YveHmTK4AMZfonQK3m > Q+IAmgJN8sYZMzfygCqnocSYuosMsJT9 > =3Do9Rj > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From petithug@acm.org Sat Jul 16 23:14:01 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B84621F86AD for ; Sat, 16 Jul 2011 23:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sn41rMAvwROV for ; Sat, 16 Jul 2011 23:14:00 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF2B21F869E for ; Sat, 16 Jul 2011 23:14:00 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 9D2E82199E; Sun, 17 Jul 2011 08:12:16 +0200 (CEST) Message-ID: <4E227DA3.8010603@acm.org> Date: Sat, 16 Jul 2011 23:13:55 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: Bruce Lowekamp References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E00F7CE.7080402@acm.org> <4E0DB3EC.1040705@ericsson.com> <4E207F1C.9080500@acm.org> <4E21D49F.9000100@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Breaking RELOAD [was Re: Identity certificate segregation] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 17 Jul 2011 06:14:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This was general remarks about the whole process, which I especially dislike. On 07/16/2011 06:47 PM, Bruce Lowekamp wrote: > On Sat, Jul 16, 2011 at 2:12 PM, Marc Petit-Huguenin wrote: > On 07/16/2011 09:41 AM, Cullen Jennings wrote: >>>> >>>> I think all the people that implemented early version know that changes can, >>>> and will, break backwards compatibility. I don't recall very many places >>>> where I used this as augment for one way or another. I recall some places >>>> where it was 6 of one of half a dozen of the other and it made no fundamental >>>> difference to the protocol so we decided to go which what was already >>>> implemented. > > Well, I kind of disagree here. The problem is that *future* implementers will > not have access to the whole history of the development of the RELOAD protocol > when trying to decipher the specification. The RELOAD specification is *not* > developer friendly (but it is not specific to this spec). I am still not saying > that a protocol must be developer-friendly, just that the text describing it > should be, and that when it makes no fundamental difference to the protocol, > making it easier for future developers should have priority over not breaking > compatibility. > > >> While I think we're a bit late in the process for a wholesale rewrite >> (we've done it about twice), if you have specific suggestions on >> editorial issues that would make it clearer, please make them now >> while we might be able to adjust some of the text. > > >>>> That said some types of changes are very easy to move into a fully >>>> operational deployed DHT. Others are not. For example, a change that you can >>>> detect the version number and then just have the software do the right things >>>> is pretty easy particularly if both the new code and old code can exist in >>>> the ring at the same time. A change where every device in the ring needs to >>>> get a new certificate and you can' have a mixed ring with the old and new >>>> certificates at the same time is not easy to deploy. > > I still do not see this as a good reason to stop fixing stuff in the protocol. > What is the point of having internet *drafts* if they are to be considered as > standard track RFCs? > >> There are quite a few people who want to build things on top of it, >> and it needs to not be a moving target for that to happen. >> Presumably, if a significant amount of practical experience shows >> things need to be changed, extensions and/or a v2.0 can be done. But >> right now the lack of a v1.0 is blocking other people's work. > >> Bruce > > >>>> >>>> To the point of this specific proposal for change. This fundamentally changes >>>> the security model and nearly every part of this protocol that has anything >>>> to do with security - which is most of it. The suggestions is several years >>>> late - it was many years ago that this WG made the decision about what the >>>> general security model was doing to be. If people want this, it seems like a >>>> fine thing to do in version 2.0 of the protocol. Thought my previous email >>>> suggested that one could look at doing it in an extension, closer examination >>>> of that makes me think there would be some real hard problems in trying to do >>>> that as it requires all the security component to be re-thought and >>>> redesigned. > > OK, now we agree. > >>>> Given the current level of energy in the WG, that would take >>>> several years to happen. I have pretty much zero interest in doing that, I'd >>>> like to actually have an RFC for this in the next year instead of several >>>> years from now. As practical improvement of the protocol, I have not seen a >>>> single use case proposed where this improves things so much we can actually >>>> do something interesting that we can no do with the current proposal. >>>> >>>> >>>> >>>> On Jul 15, 2011, at 10:55 , Marc Petit-Huguenin wrote: >>>> >>>> On 07/07/2011 03:34 PM, Cullen Jennings wrote: >>>>>>> >>>>>>> This would break all the current deployments and implementation and not >>>>>>> just in a way where some new software would need to be pushed out - all >>>>>>> new certificates would need to be issues. From my point of view, this >>>>>>> is too late for this change and instead it could be addressed with an >>>>>>> extension. >>>> >>>> About this "breaking current deployment" thing, it seems to me that anyway >>>> when RELOAD will be published as an RFC, the version number with be >>>> incremented to 1.0 (0x0a), so implementations of the RFC will *not* be >>>> compatible with *any* of the current implementations. And because of this, I >>>> really do not understand why the authors of RELOAD are fighting so hard to >>>> not break things that will be broken anyway - there was multiple instances of >>>> things that could have been improved in the document but stayed because of >>>> this (the fragment bit is one example of this). Having been there multiple >>>> times I really understand the plight of early implementers but I would never >>>> ever use this as a justification to keep useless stuff in a protocol. What >>>> should have been done is simply to increment the version each time a new >>>> version of the draft would have broken interoperability - and we had the >>>> possibility to do that 8 times (versions 0.1 to 0.9). >>>> >>>>>>> >>>>>>> On Jul 1, 2011, at 5:47 AM, Gonzalo Camarillo wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> please, let me know whether or not these modifications will be >>>>>>>> included in the base draft at this point. >>>>>>>> >>>> >>>> [...] >>>> >>>>> > >>>> Cullen Jennings For corporate legal information go to: >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4ifaIACgkQ9RoMZyVa61fPIgCfXHENMbCurA48yDa8luqfDruT Ih0AoIgCzBWIRssi3kvGwSMLZLBa8i05 =6UXw -----END PGP SIGNATURE----- From petithug@acm.org Sun Jul 17 10:11:24 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4B121F84BC for ; Sun, 17 Jul 2011 10:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYs5wdvYeNec for ; Sun, 17 Jul 2011 10:11:24 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 1346121F8429 for ; Sun, 17 Jul 2011 10:11:24 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 91B762199E for ; Sun, 17 Jul 2011 19:09:36 +0200 (CEST) Message-ID: <4E2317B6.4090901@acm.org> Date: Sun, 17 Jul 2011 10:11:18 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: P2PSIP WG X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Signature validation for TURN-SERVICE kind X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 17 Jul 2011 17:11:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When storing a TURN-SERVICE kind, the storing peer cannot count on having the certificate used to sign the value available locally, because the CERTIFICATE_BY_NODE and CERTIFICATE_BY_USER kinds will be stored in a different peer. Is the intent that the storing peer remotely fetch the certificate for the validation or should it fail when the certificate is not sent in the certificates field of the SecurityBlock? Note that if the request should fail, then it is a problem with replications as there is very little chance to have the right certificate in the SecurityBlock when the value is replicated. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4jF7QACgkQ9RoMZyVa61d/mQCgnL3vndPpYAJds03IvXnYZprE MmsAoITz6U97WHeyIone4md7hwYFIxNW =BPUG -----END PGP SIGNATURE----- From loopp2psip@gmail.com Mon Jul 18 12:03:18 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D947F11E808B for ; Mon, 18 Jul 2011 12:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.364 X-Spam-Level: X-Spam-Status: No, score=-1.364 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd3A6M2Y8DrX for ; Mon, 18 Jul 2011 12:03:16 -0700 (PDT) Received: from mail-wy0-f194.google.com (mail-wy0-f194.google.com [74.125.82.194]) by ietfa.amsl.com (Postfix) with ESMTP id 58FAD21F8677 for ; Mon, 18 Jul 2011 12:02:28 -0700 (PDT) Received: by wyf22 with SMTP id 22so801626wyf.1 for ; Mon, 18 Jul 2011 12:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=huMU23lea5DWk0TEcpa0mN2sz2shNL/N84h1ofdXprQ=; b=pKQkhSFquJmEG0N5v0V0v+K7BQWveu+9eh6lkQJJe043NLQuYQcQvWlVlSAXnmZf0H eC4kJRH+n6P255dKhgMftKdf8gKtTABDQuphrlm7LSXcni2B577iP3Ova7eZdZr8zy19 10tJpQrpfSV0ZfUJdI6dFi4tUajsq6O5cJKXw= Received: by 10.216.132.214 with SMTP id o64mr5599609wei.75.1311015747319; Mon, 18 Jul 2011 12:02:27 -0700 (PDT) Received: from [192.168.1.3] (96.134.16.95.dynamic.jazztel.es [95.16.134.96]) by mx.google.com with ESMTPS id j54sm1259792wed.47.2011.07.18.12.02.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jul 2011 12:02:23 -0700 (PDT) From: Diego Suarez To: Bruce Lowekamp In-Reply-To: References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E0E4DBE.5060302@acm.org> <1309624099.5232.23.camel@santeles> <4E0F4F8D.9080108@acm.org> <1309773089.5716.43.camel@santeles> <1310123712.22737.73.camel@toedo> <1310143982.6132.75.camel@santeles> <1310232343.5262.27.camel@santeles> Content-Type: text/plain; charset="UTF-8" Date: Mon, 18 Jul 2011 21:02:20 +0200 Message-ID: <1311015740.5190.23.camel@santeles> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2011 19:03:19 -0000 Hi, As I've said, from my point of view the good thing of split certification is that it makes things more simple and clear. Clients work fine for some scenarios, but for the case of several users in the same device are confusing for me. About the compatibility of the certification model, it is not that P2PSIP certificates are not compatible with SIP, but that SIP certificates are not valid with P2PSIP because they do not have a nodeID. However, as I've said in my very first mail, I just wanted to introduce the idea of split certification in case the group thought it was useful for RELOAD. But if you think that it is not or that it makes things more complex or that it is too late to change the cert model; I, of course, accept your decision. I have another proposal for RELOAD related to the authorization (use of ACs instead -or as a complement- of ACLs), but since it does not need any change in the main draft I will take a while to write a draft to properly present it. cheers On Sat, 2011-07-16 at 21:41 -0400, Bruce Lowekamp wrote: > Sorry for replying to my own message. I meant to add this to the top... > > I think there's an interesting philosophical discussion of whether it > would have been better to have split identities. My point in the > previous reply is not that split identities wouldn't work, I just > don't think there is anything they support that can't be done with the > existing protocol. So I'm OK having a conversation about how they > would work. But when you say you don't believe that clients (virtual > or not) provide the same functionality, I have to disagree with > that---the protocol was designed to support clients, and there is no > problem with the functionality they receive that I am aware of. > > I have mixed feelings about whether using split identities would be > good or bad. So much the security of p2p algorithms depends on the > inability of an attacker to chose a location within the overlay. It > makes me a bit paranoid to decouple identity in that way---although > I'm not sure that in practice managing pure node id certificates would > be that much harder---in the end, you still need to identify what > certificates are attacking the network. > > The biggest difference that I can see is that with split identities > you would almost double the number of certificates on the wire/being > stored. I think there would have to be a significant feature > advantage to justify that, and right now I'm not seeing it. > > Bruce > > > On Sat, Jul 16, 2011 at 9:27 PM, Bruce Lowekamp wrote: > > On Sat, Jul 9, 2011 at 1:25 PM, Diego Suarez wrote: > >> First of all, I would like to introduce the motivation of the idea of > >> split certification, since I think it is an important point in this > >> discussion and would help to clarify why I think that virtual clients do > >> not really allow several users to be connected from the same device. > >> Also, it could help to clarify if I taking a false premise to support > >> split certification when I should not. > >> > >> As far as I understood, the idea of nodeIDs in RELOAD is to represent > >> devices, despite usernames and nodeIDs are included in the same > >> certificate. Draft says: "If a user has more than one device, typically > >> they would get one certificate for each device. This allows each device > >> to act as a separate peer." However, it also exist the possibility of > >> having a single certificate with several nodeIDs. In this case, a user > >> with two devices ( for example a mobile and a fixed phone ) would have a > >> certificate with a username and two nodeIDs, one for each device; being > >> able to be connected to network and contactable in both devices at the > >> same time. > >> > >> Regarding the first alternative, there is something I have not clear: If > >> a user has a different certificate for each device she has, would these > >> certificates have the same username and different nodeIDs? and if so, > >> would the PK be the same in all the certificates or a different PK in > >> each one?; or would the user have a different username, a different > >> nodeID and a different PK in each certificate?. Said this, if we want > >> each device to have its own certificate, why don't make it simpler a > >> split device's identity from the user's identity? > > > > The only requirement is that no two nodes can be trying to use the > > same nodeid at the same time. Otherwise, it doesn't make any > > difference to the protocol if two physical devices use the same nodeid > > at different times. The draft doesn't say much about managing this > > because outside of this requirement, it's really up to the > > implementation. > > > >> > >> The second alternative (several nodeIDs in a single cert) works well for > >> me if the user if using the same devices all the time, for example a > >> user with one cert with a nodeID for her mobile phone and another nodeID > >> for her office fixed phone; but has some limitations. What happens if > >> the user is out for one week in another office and wants to be connected > >> from there ? The simple answer seems to be "use the nodeID she was using > >> in the other office". But, is it not weird to bother in the first place > >> to give a different nodeID to each user's device and now use the same > >> nodeID for two different ones? Also, won't be useful to have each device > >> identified by a unique nodeID within the network for security reasons or > >> to have permanent statistics about its past behavior for network > >> maintenance or routing purposes? > > > > I don't see that it would be that useful. It certainly doesn't give > > you any additional security, since you can't enforce it at a protocol > > level. If you're interested in logging information about hardware or > > software configuration nodes are using, you can certainly do > > that---and if you do that, you've solved the problem. > > > > > >> > >> With this in mind, it came to me the idea of a split certification. With > >> split certification, users would be identified always by the same > >> certificate independently of the device they are using (something that > >> does not happen in the first alternative). Also, devices would be always > >> identified by the same and unique cert (something that does not happen > >> in the second). Besides, users could be connected to as many devices as > >> they want without have to been re-certified to get more nodeIDs. I think > >> this would simplify the certification of the system and improve its > >> maintenance. Also, extra improvements come with this alternative, like > >> greater interoperability with SIP ( as I've already commented in > >> previous mails ) or the easy deployment of more secure networks formed > >> by hard coded (including a certificate with a nodeID) devices. > > > > This can all be done with the existing protocol. And, as I said in my > > earlier responses, I don't believe there are any interop issues with > > SIP, I think a reload cert could be 6072 compatible, though I don't > > claim to be an expert on that or to have tested it. > > > >> > >> The comments to the other improvement I see of this alternative, related > >> to several users connected to the same device, are inline. > >> > >> On Fri, 2011-07-08 at 19:06 -0400, Bruce Lowekamp wrote: > >>> inline > >>> > >>> On Fri, Jul 8, 2011 at 12:53 PM, Diego Suarez wrote: > >>> > Hi, > >>> > > >>> > I have the impression I am not explaining myself well. I am not saying > >>> > that clients in RELOAD do not work well, I am just saying that I do not > >>> > see how they can be used to allow several users to be connected to the > >>> > same the device; at least not with full functionalities. > >>> > > >>> > Lets go back to the example: > >>> > Imagine we have a device, with PKC ( # user = device1, nodeID = 100 # ) > >>> > and two users ( # user = user1, nodeID = 200 # and # user = user2, > >>> > nodeID = 300 # ) connected to that device acting as virtual clients. > >>> > > >>> > As you have said, during registration, users store a destination list > >>> > that start with the device ( nodeID = 100 ) and finishes with the > >>> > client's nodeID ( nodeID = 200 for user1 and nodeID = 300 for user2). > >>> > This works well, and allows other peers of the system to reach them. > >>> > > >>> > However, the problem is with the access control. Being virtual clients, > >>> > users can perform NODE-USER-MATCH accesses related to their client's > >>> > nodeIDs and usernames: 200-user1 for user1 and 300-user2 for user2. > >>> > Nevertheless, this is not what we want in this case. In this case, where > >>> > user1 and user2 are supposed to be connected to the same device (nodeID > >>> > = 100), they should be allowed to perform NODE-USER-MATCH accesses > >>> > related to this device and their usernames: 100-user1 for user1 and > >>> > 100-user2 for user2. > >>> > >>> why? It works as designed when they use their client nodeid. > >> > >> Well, I've said before, if the idea of RELOAD is to have each device be > >> identified by a different nodeID, from my point of view two users > >> operating from the same device should be using the same nodeID. Two > >> users connected to the same device, using different nodeIDs, that also > >> reuse later with another devices are not actually breaking the > >> certification idea of 1device = 1nodeID? > > > > The idea is at most one device on the overlay at any given time with > > the same node id. The ability to act as a particular node id is > > controlled by the certificate mechanism. No other assumptions. > > > > > >> > >> > >>> In > >>> fact, using the host's nodeid here gives the exact opposite behavior > >>> of what you would want---if one of the multiple users switches to a > >>> different device, they may wind up with a stale entry pointing to the > >>> device they are no longer at, whereas if the user uses their own > >>> certificate&nodeid, when they register their route to the new host the > >>> old one is automatically removed because they're using the same client > >>> nodeid. > >> > >> I think this would be a fail of the implementation not of the proposal > >> and that can also happen with the actual model of RELOAD. Imagine a user > >> with a cert (including a username and two nodeIDs ) connected to two > >> different devices. If she disconnects from one of the devices but > >> forgets to remove that entry point, she may also wind up with a stale > >> entry pointing to a device she is no longer at. > >> > > > > Exactly. If you use the same nodeid for that person, you don't need > > to worry about stale entries. > > > > > > > >> > >>> > >>> > Because, if not, we are not really implementing > >>> > this functionality. > >>> > >>> what functionality? > >>> > >>> > In order to be fully implemented, several users > >>> > connected to the same device should have the same functionalities that a > >>> > single user connected to this device has, and this is not the case using > >>> > virtual clients. > >>> > >>> could you clarify what you're referring to here? I don't know what > >>> functionality I would expect multiple users signed into the same > >>> device to have that wouldn't be provided using their own nodeids. > >>> > >> > >> I would try to clarify what I mean with an example that presents three > >> possible cases that can occur in RELOAD: > >> > >> case 1: > >> > >> User1 with cert ( user = user1, nodeID = 100 ) is connected to the > >> network using a device. Therefore she can perform any access related to > >> her user( USER-MATCH = user1 ), nodeID ( NODE-MATCH = 100 ) or the > >> combination of both (USER-NODE-MATCH = user1-100). > >> > >> case 2: > >> > >> The same User1 with the same cert is connected to the network using the > >> same device. But now, also User2 ( user = user2, nodeID = 200 ) and > >> User3 ( user = user3, nodeID = 300 ) are connected to that device as > >> virtual clients. User1 can perform the same kind of accesses than > >> in case 1. User2 can perform accesses related her user( USER-MATCH = > >> user2 ), virtual nodeID ( NODE-MATCH = 200 ) or the combination of both > >> (USER-NODE-MATCH = user2-200). User3 is ( USER-MATCH = user3 ), virtual > >> nodeID ( NODE-MATCH = 300 ) or the combination of both (USER-NODE-MATCH > >> = user3-300). > >> > >> > >> case 3: > >> > >> A "non-user" device ( user = lab1, nodeID = 100 ) is connected to the > >> network. Two users, User2 and User3 (with the same credentials that in > >> the previous case) are connected to that device. So, User2 and User3 can > >> perform the same accesses than in case 3. > >> > >> In this three examples, taking a look a the accesses related to NODE, > >> the important thing here, we see different cases of users presumably > >> connected to the same device, that should have the same functionalities > >> over that device but actually they have not. Precisely, User1 can > >> perform accesses on behalf of the device, while user2 and user3 cannot. > >> I would expect for all the cases the same rights for a user, either she > >> has full control over the device ( to perform accesses like NODE-MATCH = > >> 100 ) or she does not have any control at all over it. But not these > >> different possibilities depending on how the user is connected to the > >> device. This is what I wanted to mean with no having full > >> functionalities. Furthermore, in case 2 we are forcing User1 to be > >> connected to the network while User2 and User3 wish to continue using > >> the device. It would be possible here that User1 entered in an > >> ‘invisible mode’ by removing her contact information from the network. > >> In such case, User1 seemed to be offline for the other users of the > >> network (neither they could have the knowledge that she is online or > >> access to her contact information) but she would be actually online > >> since she could access to all the resources of the network, like her > >> voicemail or the contact information of other users to initiate media > >> calls. > > > > I really lost you on this point. Reload is an overlay and key-based > > storage protocol. The only functionality it gives you are those > > abilities, there's nothing about "seems to be offline" that would come > > out of the core protocol. A usage, such as the sip usage, specifies > > how to use it to deliver functionality to the user. In the sip-usage > > case, it stores destination lists indexed by AORs---so it doesn't > > matter whether the users are using the nodeid of a peer or a client. > > They are reachable via the destination list they specify. I guess you > > could specify a usage that only stored the peer's nodeid and so didn't > > support clients, but that would be broken. Any information in reload > > on how to contact a node needs to be a destination list. > > > > > > Bruce > > > > > >> > >> > >> cheers > >> > >>> Bruce > >>> > >>> > >>> > > >>> > cheers > >>> > > >>> > > >>> > > >>> > On Fri, 2011-07-08 at 09:40 -0400, Bruce Lowekamp wrote: > >>> >> On Fri, Jul 8, 2011 at 7:15 AM, Diego Suarez wrote: > >>> >> > Hi Bruce, > >>> >> > > >>> >> > Answers inline. > >>> >> > > >>> >> > > >>> >> > On Thu, 2011-07-07 at 22:24 -0400, Bruce Lowekamp wrote: > >>> >> >> Diego, > >>> >> >> > >>> >> >> Please take some time understanding how real clients work in reload. > >>> >> >> Then just have the virtual clients use the same messages. The virtual > >>> >> >> clients use their own nodeids, not the host's nodeid. It all works > >>> >> >> fine. > >>> >> > > >>> >> > I agree, this works fine for clients, but, from my point of view, it > >>> >> > does not for several users connected to the same device. The fact that > >>> >> > clients ( or virtual clients ) use their own nodeIDs and not the host's > >>> >> > nodeIDs is precisely what I see as the problem of using virtual clients > >>> >> > to allow several users to be connected to the same device. Since virtual > >>> >> > clients are not using the device's nodeID, they cannot perform > >>> >> > operations ( like NODE-MATCH or USER-NODE-MATCH accesses) from that > >>> >> > device like they should if they were actually connected to the system > >>> >> > from it. As I've said in my previous mail, they only way I see to allow > >>> >> > so is the device adding an extra signature to the message, with the > >>> >> > already commented problem of two users and two nodeIDs in it. > >>> >> > > >>> >> > >>> >> Since a client is using its own nodeid, NODE-MATCH and USER-NODE-MATCH > >>> >> are performed using the client's nodeid. In the case of the sip > >>> >> usage, it's done using USER-NODE-MATCH. This is the client's > >>> >> rfc822Name and the client's nodeid. In that registration, it stores a > >>> >> destination list that starts with the peer and finishes with the > >>> >> client's nodeid (in most cases, would be only these two entries). > >>> >> This is how clients are supported in reload and for the sip usage. > >>> >> > >>> >> > > >>> >> >> I don't see a real problem with a host node having an > >>> >> >> "admin@example.com" or "node12345@example.com" name attached to it. > >>> >> >> Routers pretty much always have DNS names that are descriptive of > >>> >> >> where they are to admins, even though routing protocols don't require > >>> >> >> it. > >>> >> > > >>> >> > Neither do I except for cases, like the presented before, of several > >>> >> > users in the same device. > >>> >> > > >>> >> >> > >>> >> >> Regarding certs, 6072 has the following text: > >>> >> >> > >>> >> >> If the certificate is signed by a trusted certification authority, > >>> >> >> and one of the names in the SubjectAltName matches the original URI, > >>> >> >> then this certificate MAY be used, but only for exactly the original > >>> >> >> > >>> >> >> It's been awhile since I've looked at that in detail, but it appears > >>> >> >> to me that a reload cert could be perfectly valid for use with 6072 as > >>> >> >> long as it has the sip uri in it. Though I'm not immediately > >>> >> >> convinced that this is that useful, regardless. > >>> >> > > >>> >> > The problem is not with RELOAD certs being used in SIP systems, but with > >>> >> > SIP certs being used in RELOAD systems. Since SIP certs do not have > >>> >> > nodeIDs, they are not valid in RELOAD. > >>> >> > > >>> >> > cheers > >>> >> > > >>> >> >> > >>> >> >> Bruce > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> On Mon, Jul 4, 2011 at 5:51 AM, Diego Suarez wrote: > >>> >> >> > Hi, > >>> >> >> > > >>> >> >> > Actually, I see this "virtual client" method more complicated and > >>> >> >> > confusing than splitting the identities of users and devices. > >>> >> >> > > >>> >> >> > With this model, you are gonna have a device identified by a PKC that > >>> >> >> > includes a username and a nodeID acting as a peer, but only using its > >>> >> >> > nodeID. And several users connected to the device as virtual clients > >>> >> >> > identified by PKCs including a username and a nodeID, but only using > >>> >> >> > their usernames. > >>> >> >> > > >>> >> >> > One of the more confusing things I see here is the access control. > >>> >> >> > Imagine we have a device, with PKC ( # user = device1, nodeID = 100 # ) > >>> >> >> > and two users ( # user = user1, nodeID = 200 # and # user = user2, > >>> >> >> > nodeID = 300 # ) connected to that device acting as virtual clients. > >>> >> >> > > >>> >> >> > If user1 wants to perform a USER-NODE-MATCH access control related to > >>> >> >> > the peer she is operating from ( actually the nodeID = 100 nor the > >>> >> >> > virtual one with nodeID = 200 ) and her username ( user = user1 ), she > >>> >> >> > is gonna have to create a request signed with her PKC and the PKC of the > >>> >> >> > device. This request need to be doubled signed ( by the peer to grant > >>> >> >> > the nodeID = 100 and by the user to grant the user = user 1 ). However, > >>> >> >> > this double signed request intended for nodeID = 100 and user = user1 is > >>> >> >> > gonna include two users = device1 and user1 and two nodeID = 100 and > >>> >> >> > 200. This is confusing for me. Therefore, from my point of view, it > >>> >> >> > makes sense to me to remove the username from the device and the node > >>> >> >> > from the users since we are not using them and confuse the access > >>> >> >> > control. > >>> >> >> > > >>> >> >> > Also, splitting identities have another advantages like greater > >>> >> >> > interoperability with traditional SIP systems. Imagine a company running > >>> >> >> > a SIP system, where users are identified by a PKC including a SIP > >>> >> >> > username, that wants to extend its coverage interconnecting it with a > >>> >> >> > P2PSIP system. With the actual certification model, SIP PKCs are not > >>> >> >> > valid for the new P2PSIP side of the system. All the users have to be > >>> >> >> > re-certificated to have a PKC including the old SIP username and a > >>> >> >> > nodeID. However, with the split proposal SIP certificates are still > >>> >> >> > valid in the P2PSIP side of the system and interoperable within the two > >>> >> >> > networks, and only the devices intended to be used in the P2PSIP side > >>> >> >> > have to be certified with a nodeID. > >>> >> >> > > >>> >> >> > > >>> >> >> > cheers > >>> >> >> > > >>> >> >> > > >>> >> >> > > >>> >> >> > > >>> >> >> > On Sat, 2011-07-02 at 16:53 -0400, Bruce Lowekamp wrote: > >>> >> >> >> With the current definition of the protocol, split routing IDs and > >>> >> >> >> user IDs can be achieved by having the host node participate as a peer > >>> >> >> >> (or as a client, honestly) using its own cert and the attached users > >>> >> >> >> represented as virtual clients, i.e. generate messages as if they are > >>> >> >> >> on separate nodes attached to the host node as a client. > >>> >> >> >> > >>> >> >> >> If you wanted to implement it "natively," other than the > >>> >> >> >> USER-NODE-MATCH, as mentioned before, I can only find two changes that > >>> >> >> >> would need to be made to support split identities. > >>> >> >> >> > >>> >> >> >> For processing StoreReq: > >>> >> >> >> o For original (non-replica) stores, the StoreReq is signed by a > >>> >> >> >> credential which is authorized to write this kind at this > >>> >> >> >> Resource-Id. If this check fails, the request MUST be rejected > >>> >> >> >> with an Error_Forbidden error. > >>> >> >> >> > >>> >> >> >> and the definition of credential in beginning of 10.3. > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> Assuming that there is not something I'm missing with using virtual > >>> >> >> >> clients, I'd rather not make any changes. This is a complicated > >>> >> >> >> enough protocol, and I think adding special cases for something like > >>> >> >> >> split identities just makes it more complicated. If any changes were > >>> >> >> >> made, I would think it should be something to make it possible for an > >>> >> >> >> extension to specify the change, but as long as the current protocol > >>> >> >> >> is capable of handling the functional goals, I'd rather no changes be > >>> >> >> >> made. > >>> >> >> >> > >>> >> >> >> Bruce > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> On Sat, Jul 2, 2011 at 1:04 PM, Marc Petit-Huguenin wrote: > >>> >> >> >> > -----BEGIN PGP SIGNED MESSAGE----- > >>> >> >> >> > Hash: SHA1 > >>> >> >> >> > > >>> >> >> >> > On 07/02/2011 09:28 AM, Diego Suarez wrote: > >>> >> >> >> >> Hi, > >>> >> >> >> >> > >>> >> >> >> >>>From my point of view, in this case the user has to both prove she is in > >>> >> >> >> >> possession of the PKC that includes the required username and also prove > >>> >> >> >> >> she is operating from the required node. However, modifying the > >>> >> >> >> >> SignerIdentity to include multiple identities ( the user and the > >>> >> >> >> >> device ) would not really prove that since only one signature could be > >>> >> >> >> >> included (either the user's signature or the device's one). > >>> >> >> >> >> > >>> >> >> >> >> Therefore, I'd modify the SecurityBlock instead to allow the inclusion > >>> >> >> >> >> of more than only one signature. > >>> >> >> >> >> > >>> >> >> >> >> For this case, the securityBlock would include two signatures. One with > >>> >> >> >> >> the SignerIdentity of the user and the signature of the user's PKC > >>> >> >> >> >> (including the username ) and another with the SignerIdentity of the > >>> >> >> >> >> device and the signature of the device's PKC ( including the nodeID). > >>> >> >> >> > > >>> >> >> >> > Right, something like this: > >>> >> >> >> > > >>> >> >> >> > struct { > >>> >> >> >> > GenericCertificate certificates<0..2^16-1>; > >>> >> >> >> > Signature signatures<0..2^16-1>; > >>> >> >> >> > } SecurityBlock; > >>> >> >> >> > > >>> >> >> >> > Note that StoredData also needs to be modified: > >>> >> >> >> > > >>> >> >> >> > struct { > >>> >> >> >> > uint32 length; > >>> >> >> >> > uint64 storage_time; > >>> >> >> >> > uint32 lifetime; > >>> >> >> >> > StoredDataValue value; > >>> >> >> >> > Signature signatures<0..2^16-1>; > >>> >> >> >> > } StoredData; > >>> >> >> >> > > >>> >> >> >> >> > >>> >> >> >> >> cheers > >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> On Fri, 2011-07-01 at 15:44 -0700, Marc Petit-Huguenin wrote: > >>> >> >> >> >> Hi Diego, > >>> >> >> >> >> > >>> >> >> >> >> How does this work with an access control policy like USER-NODE-MATCH, which > >>> >> >> >> >> requires both a Node-ID and a username in the SignerIdentity? If the Node-ID > >>> >> >> >> >> and the username are in separate certificates, wouldn't that require to extend > >>> >> >> >> >> the SignerIdentity structure to store multiple identities? > >>> >> >> >> >> > >>> >> >> >> >> Thanks. > >>> >> >> >> >> > >>> >> >> >> >> On 06/09/2011 10:47 AM, Diego Suarez wrote: > >>> >> >> >> >>>>> I think it would require a (slight) modification in the base document. > >>> >> >> >> >>>>> Current P2PSIP certification model is based on a single PKC (including > >>> >> >> >> >>>>> both usernames and nodeIDs) that uniquely identifies a user and her > >>> >> >> >> >>>>> devices. On the other hand, our model is base on a split certification. > >>> >> >> >> >>>>> Devices and users are independent. Each device has its own PKC including > >>> >> >> >> >>>>> a nodeID and a PK. Similarly, each user has her own PKC including her > >>> >> >> >> >>>>> username and a PK. This approach do not prevent a centralized entity > >>> >> >> >> >>>>> (such as an offline CA) to have information related to the devices each > >>> >> >> >> >>>>> user (or company, etc.) has registered, but permits, among other > >>> >> >> >> >>>>> improvements, a user to be connected to the system through devices she > >>> >> >> >> >>>>> has not registered herself such as a phone issued by a telco or a fixed > >>> >> >> >> >>>>> phone in a laboratory shared by all the members of a research group. > >>> >> >> >> >>>>> > >>> >> >> >> >>>>> > >>> >> >> >> >>>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: > >>> >> >> >> >>>>> Does this model really required modifications in the base document, or can it be > >>> >> >> >> >>>>> designed as an extension? (Unfortunately the paper is not freely available, so > >>> >> >> >> >>>>> it is difficult to know really what is needed for this). > >>> >> >> >> >>>>> > >>> >> >> >> >>>>> On 06/09/2011 07:31 AM, Diego Suarez wrote: > >>> >> >> >> >>>>>>>> Hi, > >>> >> >> >> >>>>>>>> > >>> >> >> >> >>>>>>>> I had in mind writing a draft about this, but since I'm running out of > >>> >> >> >> >>>>>>>> time, I would like to summarize a new certification model for P2PSIP I > >>> >> >> >> >>>>>>>> have been working on, in case it is of interest for the group. > >>> >> >> >> >>>>>>>> Further details can be found in paper: > >>> >> >> >> >>>>>>>> > >>> >> >> >> >>>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, Advantages of > >>> >> >> >> >>>>>>>> identity certificate segregation in P2PSIP systems, Communications, > >>> >> >> >> >>>>>>>> IET, vol. 5, pp. 879 889, Apr. 2011. > >>> >> >> >> >>>>>>>> > >>> >> >> >> >>>>>>>> > >>> >> >> >> >>>>>>>> The idea is to split the certification of users and devices. Devices are > >>> >> >> >> >>>>>>>> identified by PKCs including a nodeID and the PK of the device, while > >>> >> >> >> >>>>>>>> users are identified by PKCs including a username and the PK of the > >>> >> >> >> >>>>>>>> user. Similar models have been used before in other communications > >>> >> >> >> >>>>>>>> systems, such as GSM where devices and users are separately represented > >>> >> >> >> >>>>>>>> by the international mobile equipment identity (IMEI) stored in the > >>> >> >> >> >>>>>>>> phones and the international mobile subscriber identity (IMSI) stored in > >>> >> >> >> >>>>>>>> the user subscriber identity module (SIM), respectively. > >>> >> >> >> >>>>>>>> > >>> >> >> >> >>>>>>>> Motivations of this model are: > >>> >> >> >> >>>>>>>> > >>> >> >> >> >>>>>>>> - Users and devices are different entities performing different > >>> >> >> >> >>>>>>>> roles within a P2PSIP system. Devices are nodes of the P2P > >>> >> >> >> >>>>>>>> overlay network (represented by a nodeID) that offer services > >>> >> >> >> >>>>>>>> (to route messages, to store data, . . .) to the system, while > >>> >> >> >> >>>>>>>> users (represented by an username) utilize these services, > >>> >> >> >> >>>>>>>> usually to establish media communications using SIP. > >>> >> >> >> >>>>>>>> > >>> >> >> >> >>>>>>>> - Support for mobility scenarios where a user may be logged at different > >>> >> >> >> >>>>>>>> devices at the same time using the same PKC. > >>> >> >> >> >>>>>>>> > >>> >> >> >> >>>>>>>> - Support several users to be logged in the same device (like a fixed > >>> >> >> >> >>>>>>>> phone) at the same time. > >>> >> >> >> >>>>>>>> > >>> >> >> >> >>>>>>>> - Support for user independent hard-coded devices. > >>> >> >> >> >>>>>>>> > >>> >> >> >> >>>>>>>> - Interoperability with SIP. SIP certificates are not valid in actual > >>> >> >> >> >>>>>>>> P2PSIP since they don't include a nodeID. > >>> >> >> >> >>>>>>>> > >>> >> >> >> >>>>>>>> cheers > >>> >> >> >> >>>>>>>> > >>> >> >> >> >>>>>>>> Diego Suárez > >>> >> >> >> >>>>>>>> > >>> >> >> >> >>>>>>>> > >>> >> >> >> >>>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: > >>> >> >> >> >>>>>>>>> Unless something major comes up, we plan to request the newest version > >>> >> >> >> >>>>>>>>> of the base draft, draft-ietf-p2psip-base-15, be published. I'll put > >>> >> >> >> >>>>>>>>> in the request in a week (June 16th or 17th). If there are any further > >>> >> >> >> >>>>>>>>> comments from the last call a while ago (or further comments on the > >>> >> >> >> >>>>>>>>> comments since then), please send them to the list ASAP. > >>> >> >> >> >>>>>>>>> > >>> >> >> >> >>>>>>>>> Thanks, > >>> >> >> >> >>>>>>>>> > >>> >> >> >> >>>>>>>>> David (as chair) > >>> >> >> >> > > >>> >> >> >> > - -- > >>> >> >> >> > Marc Petit-Huguenin > >>> >> >> >> > Personal email: marc@petit-huguenin.org > >>> >> >> >> > Professional email: petithug@acm.org > >>> >> >> >> > Blog: http://blog.marc.petit-huguenin.org > >>> >> >> >> > -----BEGIN PGP SIGNATURE----- > >>> >> >> >> > Version: GnuPG v1.4.11 (GNU/Linux) > >>> >> >> >> > > >>> >> >> >> > iEYEARECAAYFAk4PT4sACgkQ9RoMZyVa61dPvACeITly6/Zqumz4e4ZrAn1yGI4x > >>> >> >> >> > ay4AoJ11vmCRDkL8pXuN71qaZXhw5JTZ > >>> >> >> >> > =Tp+D > >>> >> >> >> > -----END PGP SIGNATURE----- > >>> >> >> >> > _______________________________________________ > >>> >> >> >> > P2PSIP mailing list > >>> >> >> >> > P2PSIP@ietf.org > >>> >> >> >> > https://www.ietf.org/mailman/listinfo/p2psip > >>> >> >> >> > > >>> >> >> > > >>> >> >> > > >>> >> >> > > >>> >> > > >>> >> > > >>> >> > > >>> > > >>> > > >>> > > >> > >> > >> > > From davidbryan@gmail.com Tue Jul 19 16:46:21 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AC011E8099 for ; Tue, 19 Jul 2011 16:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPEM+P0HClcB for ; Tue, 19 Jul 2011 16:46:20 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD2711E8097 for ; Tue, 19 Jul 2011 16:46:20 -0700 (PDT) Received: by qyk9 with SMTP id 9so3103689qyk.10 for ; Tue, 19 Jul 2011 16:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=qmwkjOyp/dc2f0o7BwfQvsQT5/Ei1LitbfnEXxN54eg=; b=jmTmnYy8q4UdxU/1COWyRjMf28As4blJ5knNVdAEs7lY9CK8mVjTe+0t36tR7HC/Gm 1vH/zQITAmqX0wg0b3PbL6je+zZlBCQg2HPy+GDctM+D9k9oIYWHxLlyBB8oVV9XPpRV E+oWWJd2OJspCPT7t9YLz5hBkO/ceV4hS64RI= MIME-Version: 1.0 Received: by 10.229.62.194 with SMTP id y2mr6589278qch.4.1311119179766; Tue, 19 Jul 2011 16:46:19 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.229.229.135 with HTTP; Tue, 19 Jul 2011 16:46:19 -0700 (PDT) Date: Tue, 19 Jul 2011 16:46:19 -0700 X-Google-Sender-Auth: w-4WucBo1Qzj6f5PTxprt6btkYw Message-ID: From: "David A. Bryan" To: P2PSIP WG Content-Type: multipart/alternative; boundary=001485f33b0ef7db4904a874b8f0 Subject: [P2PSIP] Slides X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2011 23:46:21 -0000 --001485f33b0ef7db4904a874b8f0 Content-Type: text/plain; charset=ISO-8859-1 If you have a presentation scheduled on the agenda ( http://www.ietf.org/proceedings/81/agenda/p2psip.txt), we'd like to request slides by Monday, 7/25. Please send them to both Brian and myself. Thanks, David --001485f33b0ef7db4904a874b8f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you have a presentation scheduled on the agenda (http://www.ietf.org/proceedings/8= 1/agenda/p2psip.txt), we'd like to request slides by Monday, 7/25. = Please send them to both Brian and myself.

Thanks,

David
--001485f33b0ef7db4904a874b8f0-- From stpeter@stpeter.im Wed Jul 20 16:55:06 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1D521F8AD8 for ; Wed, 20 Jul 2011 16:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.876 X-Spam-Level: X-Spam-Status: No, score=-101.876 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85kK5QZWvjsu for ; Wed, 20 Jul 2011 16:55:06 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 44FC121F87D3 for ; Wed, 20 Jul 2011 16:55:06 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 060834005A for ; Wed, 20 Jul 2011 17:55:47 -0600 (MDT) Message-ID: <4E276AD5.3000601@stpeter.im> Date: Wed, 20 Jul 2011 17:55:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: p2psip@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [P2PSIP] partial review of draft-ietf-p2psip-base-17 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jul 2011 23:55:07 -0000 I've been asked to look at the XML aspects of draft-ietf-p2psip-base. Overall it seems fine. Here are some relatively minor comments. 1. element. The text says "Each configuration element has the following attributes..." Unless cardinality is covered by the schema, it would be good to say how many times each attribute may or must be included. 2. The 'expiration' attribute has a datatype of xsd:dateTime but does not define the details of the syntax as used in this protocol. It would be best to reference RFC 3339, making sure to document all the details about various options, such as use of non-UTC time zones and fractional seconds. 3. Is this valid data? YmFkIGNlcnQK 4. For the elements and attributes of type xsd:boolean, please note that the lexical representations in W3C XML Schema Part 2 are "true" or "1" for TRUE and "false" or "0" for FALSE. I always find it useful to make a note about that, specifying whether implementations must support both styles. 5. Is it really true that the only allowable values for the 'digest' attribute are "sha1" and "sha256"? What about hash agility? Peter -- Peter Saint-Andre https://stpeter.im/ From petithug@acm.org Fri Jul 22 08:55:23 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E22321F8B03 for ; Fri, 22 Jul 2011 08:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Kva5zkGnubM for ; Fri, 22 Jul 2011 08:55:22 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE4321F8AFB for ; Fri, 22 Jul 2011 08:55:22 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 7B9E920136; Fri, 22 Jul 2011 17:53:17 +0200 (CEST) Message-ID: <4E299D66.8000400@acm.org> Date: Fri, 22 Jul 2011 08:55:18 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4E0DB1D0.6060703@ericsson.com> In-Reply-To: <4E0DB1D0.6060703@ericsson.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] AD review: draft-ietf-p2psip-base-15 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2011 15:55:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/01/2011 04:38 AM, Gonzalo Camarillo wrote: > Folks, > > the P2PSIP WG chairs are in the process of requesting the publication of > the following draft: > > https://datatracker.ietf.org/doc/draft-ietf-p2psip-base/ > > At this point, they are working with the secretary to fix the state of > the document in the tracker (it should be publication requested) and to > upload the document's PROTO write up. > > While that gets fixed, I have done my AD review (see below) in order to > gain some time. As soon as these comments are addressed, I will start > the IETF LC on this draft. > The IETF LC ends today but Michael Chen and I sent multiple questions to the mailing-list that are still without answer. I find it difficult to decide if this specification is ready to be published until this questions are answered. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4pnWMACgkQ9RoMZyVa61fJPgCfW2yfgvjVlpcOg0j272ma3yQR U8YAoJayxKmy+H9ARjW+G/nf2K+2KLsA =p5U9 -----END PGP SIGNATURE----- From bbl@lowekamp.net Fri Jul 22 13:32:19 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DD621F8ABC for ; Fri, 22 Jul 2011 13:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grUa1Uet-MkP for ; Fri, 22 Jul 2011 13:32:18 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82EB521F8B6A for ; Fri, 22 Jul 2011 13:32:18 -0700 (PDT) Received: by ewy19 with SMTP id 19so2117807ewy.31 for ; Fri, 22 Jul 2011 13:32:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.37.76 with SMTP id x52mr738487eea.222.1311366735827; Fri, 22 Jul 2011 13:32:15 -0700 (PDT) Received: by 10.14.127.13 with HTTP; Fri, 22 Jul 2011 13:32:15 -0700 (PDT) In-Reply-To: <4E2317B6.4090901@acm.org> References: <4E2317B6.4090901@acm.org> Date: Fri, 22 Jul 2011 16:32:15 -0400 Message-ID: From: Bruce Lowekamp To: Marc Petit-Huguenin , Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: P2PSIP WG Subject: Re: [P2PSIP] Signature validation for TURN-SERVICE kind X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2011 20:32:19 -0000 >From 5.3.4: The certificates bucket SHOULD contain all the certificates necessary to verify every signature in both the message and the internal message objects. This is the only location in the message which contains certificates, thus allowing for only a single copy of each certificate to be sent. In systems which have some alternate certificate distribution mechanism, some certificates MAY be omitted. However, implementors should note that this creates the possibility that messages may not be immediately verifiable because certificates must first be retrieved. This implies that a TURN-SERVICE implementation caches the certificates needed for replication. Will add a note to the TURN-SERVICE description for clarification. Bruce On Sun, Jul 17, 2011 at 1:11 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > When storing a TURN-SERVICE kind, the storing peer cannot count on having the > certificate used to sign the value available locally, because the > CERTIFICATE_BY_NODE and CERTIFICATE_BY_USER kinds will be stored in a different > peer. > > Is the intent that the storing peer remotely fetch the certificate for the > validation or should it fail when the certificate is not sent in the > certificates field of the SecurityBlock? > > Note that if the request should fail, then it is a problem with replications as > there is very little chance to have the right certificate in the SecurityBlock > when the value is replicated. > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk4jF7QACgkQ9RoMZyVa61d/mQCgnL3vndPpYAJds03IvXnYZprE > MmsAoITz6U97WHeyIone4md7hwYFIxNW > =BPUG > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From petithug@acm.org Fri Jul 22 13:37:39 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57B021F8B72 for ; Fri, 22 Jul 2011 13:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXmdiSImBnnS for ; Fri, 22 Jul 2011 13:37:39 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEBB21F8B59 for ; Fri, 22 Jul 2011 13:37:37 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 1051420136; Fri, 22 Jul 2011 22:35:31 +0200 (CEST) Message-ID: <4E29DF8E.2050403@acm.org> Date: Fri, 22 Jul 2011 13:37:34 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: Bruce Lowekamp References: <4E2317B6.4090901@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Signature validation for TURN-SERVICE kind X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2011 20:37:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/22/2011 01:32 PM, Bruce Lowekamp wrote: >>From 5.3.4: > > The certificates bucket SHOULD contain all the certificates necessary > to verify every signature in both the message and the internal > message objects. This is the only location in the message which > contains certificates, thus allowing for only a single copy of each > certificate to be sent. In systems which have some alternate > certificate distribution mechanism, some certificates MAY be omitted. > However, implementors should note that this creates the possibility > that messages may not be immediately verifiable because certificates > must first be retrieved. > > > This implies that a TURN-SERVICE implementation caches the > certificates needed for replication. Will add a note to the > TURN-SERVICE description for clarification. OK, but isn't this true also for all other kinds that do not use USER-MATCH or NODE-MATCH? > > Bruce > > > > On Sun, Jul 17, 2011 at 1:11 PM, Marc Petit-Huguenin wrote: > When storing a TURN-SERVICE kind, the storing peer cannot count on having the > certificate used to sign the value available locally, because the > CERTIFICATE_BY_NODE and CERTIFICATE_BY_USER kinds will be stored in a different > peer. > > Is the intent that the storing peer remotely fetch the certificate for the > validation or should it fail when the certificate is not sent in the > certificates field of the SecurityBlock? > > Note that if the request should fail, then it is a problem with replications as > there is very little chance to have the right certificate in the SecurityBlock > when the value is replicated. > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4p34wACgkQ9RoMZyVa61eU4ACdH1DM2DJBEkgd5JltNZDo86qL Mp4AnjMkGXYpPePQ2Vdpeaz/R2Hjb5Zk =5Y7V -----END PGP SIGNATURE----- From bbl@lowekamp.net Fri Jul 22 13:42:05 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8559421F8761 for ; Fri, 22 Jul 2011 13:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=1.169, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zHXqZTG8oQb for ; Fri, 22 Jul 2011 13:42:05 -0700 (PDT) Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id CBBDF21F86DF for ; Fri, 22 Jul 2011 13:42:04 -0700 (PDT) Received: by eya28 with SMTP id 28so3041766eya.21 for ; Fri, 22 Jul 2011 13:42:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.47.195 with SMTP id t43mr729455eeb.62.1311367323666; Fri, 22 Jul 2011 13:42:03 -0700 (PDT) Received: by 10.14.127.13 with HTTP; Fri, 22 Jul 2011 13:42:03 -0700 (PDT) In-Reply-To: <20110707174850.61e8c06078a3b23a733c71e914c0b9df.97c67717b4.wbe@email00.secureserver.net> References: <20110707174850.61e8c06078a3b23a733c71e914c0b9df.97c67717b4.wbe@email00.secureserver.net> Date: Fri, 22 Jul 2011 16:42:03 -0400 Message-ID: From: Bruce Lowekamp To: Michael Chen , Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Configuration sequence number includes 0 or not X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2011 20:42:05 -0000 I believe 10.1 should say 0 to 2^16-2 Bruce On Thu, Jul 7, 2011 at 8:48 PM, Michael Chen wrote: > Hi, > > The base-15 draft definition for the configuration sequence number in > section 10.1 says it is a number between 1 and 65534. This conflicts > with section 5.3.2.1 last sentence, where it describes the wrapping of > sequence number is setting it to 0 when it reaches 65535. > > Was sequence 0 intended for anything? > > Thanks > > --Michael > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From bbl@lowekamp.net Fri Jul 22 13:49:02 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E17A21F8B0A for ; Fri, 22 Jul 2011 13:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=1.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7yihunSGej9 for ; Fri, 22 Jul 2011 13:49:01 -0700 (PDT) Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 23AE721F8B02 for ; Fri, 22 Jul 2011 13:49:00 -0700 (PDT) Received: by eya28 with SMTP id 28so3045402eya.21 for ; Fri, 22 Jul 2011 13:49:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.37.76 with SMTP id x52mr743166eea.222.1311367739790; Fri, 22 Jul 2011 13:48:59 -0700 (PDT) Received: by 10.14.127.13 with HTTP; Fri, 22 Jul 2011 13:48:59 -0700 (PDT) In-Reply-To: <4E29DF8E.2050403@acm.org> References: <4E2317B6.4090901@acm.org> <4E29DF8E.2050403@acm.org> Date: Fri, 22 Jul 2011 16:48:59 -0400 Message-ID: From: Bruce Lowekamp To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Signature validation for TURN-SERVICE kind X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2011 20:49:02 -0000 On Fri, Jul 22, 2011 at 4:37 PM, Marc Petit-Huguenin wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/22/2011 01:32 PM, Bruce Lowekamp wrote: >>>From 5.3.4: >> >> The certificates bucket SHOULD contain all the certificates necessary >> =C2=A0 =C2=A0to verify every signature in both the message and the inter= nal >> =C2=A0 =C2=A0message objects. =C2=A0This is the only location in the mes= sage which >> =C2=A0 =C2=A0contains certificates, thus allowing for only a single copy= of each >> =C2=A0 =C2=A0certificate to be sent. =C2=A0In systems which have some al= ternate >> =C2=A0 =C2=A0certificate distribution mechanism, some certificates MAY b= e omitted. >> =C2=A0 =C2=A0However, implementors should note that this creates the pos= sibility >> =C2=A0 =C2=A0that messages may not be immediately verifiable because cer= tificates >> =C2=A0 =C2=A0must first be retrieved. >> >> >> This implies that a TURN-SERVICE implementation caches the >> certificates needed for replication. =C2=A0Will add a note to the >> TURN-SERVICE description for clarification. > > OK, but isn't this true also for all other kinds that do not use USER-MAT= CH or > NODE-MATCH? > Yes, since 5.3.4 is the definition of the basic SecurityBlock, it applies to anything using the protocol. Though I would expect such usages to be rare. Do you have any suggestions for how/where to clarify this point? If we add a sentence in 5.3.4 and one with TURN-SERVICE, I think that will cover anyone reading the spec thoroughly and anyone just looking at TURN-SERVICE as an example usage while writing another. Bruce >> >> Bruce >> >> >> >> On Sun, Jul 17, 2011 at 1:11 PM, Marc Petit-Huguenin = wrote: >> When storing a TURN-SERVICE kind, the storing peer cannot count on havin= g the >> certificate used to sign the value available locally, because the >> CERTIFICATE_BY_NODE and CERTIFICATE_BY_USER kinds will be stored in a di= fferent >> peer. >> >> Is the intent that the storing peer remotely fetch the certificate for t= he >> validation or should it fail when the certificate is not sent in the >> certificates field of the SecurityBlock? >> >> Note that if the request should fail, then it is a problem with replicat= ions as >> there is very little chance to have the right certificate in the Securit= yBlock >> when the value is replicated. >> > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk4p34wACgkQ9RoMZyVa61eU4ACdH1DM2DJBEkgd5JltNZDo86qL > Mp4AnjMkGXYpPePQ2Vdpeaz/R2Hjb5Zk > =3D5Y7V > -----END PGP SIGNATURE----- > From bbl@lowekamp.net Fri Jul 22 13:54:21 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1993621F893C for ; Fri, 22 Jul 2011 13:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.974, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRl2xwk4pU9Y for ; Fri, 22 Jul 2011 13:54:20 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20E6721F88E5 for ; Fri, 22 Jul 2011 13:54:19 -0700 (PDT) Received: by ewy19 with SMTP id 19so2125209ewy.31 for ; Fri, 22 Jul 2011 13:54:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.99.198 with SMTP id x46mr713410eef.126.1311368058858; Fri, 22 Jul 2011 13:54:18 -0700 (PDT) Received: by 10.14.127.13 with HTTP; Fri, 22 Jul 2011 13:54:18 -0700 (PDT) In-Reply-To: <4E299D66.8000400@acm.org> References: <4E0DB1D0.6060703@ericsson.com> <4E299D66.8000400@acm.org> Date: Fri, 22 Jul 2011 16:54:18 -0400 Message-ID: From: Bruce Lowekamp To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] AD review: draft-ietf-p2psip-base-15 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2011 20:54:21 -0000 On Fri, Jul 22, 2011 at 11:55 AM, Marc Petit-Huguenin wr= ote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/01/2011 04:38 AM, Gonzalo Camarillo wrote: >> Folks, >> >> the P2PSIP WG chairs are in the process of requesting the publication of >> the following draft: >> >> https://datatracker.ietf.org/doc/draft-ietf-p2psip-base/ >> >> At this point, they are working with the secretary to fix the state of >> the document in the tracker (it should be publication requested) and to >> upload the document's PROTO write up. >> >> While that gets fixed, I have done my AD review (see below) in order to >> gain some time. As soon as these comments are addressed, I will start >> the IETF LC on this draft. >> > > The IETF LC ends today but Michael Chen and I sent multiple questions to = the > mailing-list that are still without answer. =C2=A0I find it difficult to = decide if > this specification is ready to be published until this questions are answ= ered. > Marc, The other authors and I greatly appreciate the time you have put into implementing and evaluating the protocol, and into providing comments on the document. However, it's difficult to keep track of them since they are generally in separate emails, so I would appreciate it if you could be specific listing any unanswered questions. I've looked through my email archive and responded to the two questions (one from you and one from Michael Chen) that I found, both of which I think are simple to resolve in the text. If there are any others, please list them so we can be sure to address them. Thanks, Bruce > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk4pnWMACgkQ9RoMZyVa61fJPgCfW2yfgvjVlpcOg0j272ma3yQR > U8YAoJayxKmy+H9ARjW+G/nf2K+2KLsA > =3Dp5U9 > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From petithug@acm.org Fri Jul 22 13:58:46 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EF221F89C1 for ; Fri, 22 Jul 2011 13:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsYtOOHGGazP for ; Fri, 22 Jul 2011 13:58:45 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 54D1B21F888A for ; Fri, 22 Jul 2011 13:58:45 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 85B5B20136; Fri, 22 Jul 2011 22:56:40 +0200 (CEST) Message-ID: <4E29E482.3060506@acm.org> Date: Fri, 22 Jul 2011 13:58:42 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: Bruce Lowekamp References: <4E2317B6.4090901@acm.org> <4E29DF8E.2050403@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Signature validation for TURN-SERVICE kind X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2011 20:58:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/22/2011 01:48 PM, Bruce Lowekamp wrote: > On Fri, Jul 22, 2011 at 4:37 PM, Marc Petit-Huguenin wrote: > On 07/22/2011 01:32 PM, Bruce Lowekamp wrote: >>>> >From 5.3.4: >>>> >>>> The certificates bucket SHOULD contain all the certificates necessary >>>> to verify every signature in both the message and the internal >>>> message objects. This is the only location in the message which >>>> contains certificates, thus allowing for only a single copy of each >>>> certificate to be sent. In systems which have some alternate >>>> certificate distribution mechanism, some certificates MAY be omitted. >>>> However, implementors should note that this creates the possibility >>>> that messages may not be immediately verifiable because certificates >>>> must first be retrieved. >>>> >>>> >>>> This implies that a TURN-SERVICE implementation caches the >>>> certificates needed for replication. Will add a note to the >>>> TURN-SERVICE description for clarification. > > OK, but isn't this true also for all other kinds that do not use USER-MATCH or > NODE-MATCH? > > >> Yes, since 5.3.4 is the definition of the basic SecurityBlock, it >> applies to anything using the protocol. Though I would expect such >> usages to be rare. Well, in addition to the TURN-SERVICE kind, all the kinds defined as Shared resource (draft-knauf-p2psip-share), the VIPR kind and the ReDir kind. That's not rare. > Do you have any suggestions for how/where to >> clarify this point? IMO, it should be required that each peer stores all the certificates needed to verify all the stored values at this peer. When replicating the stored values, the peer must also send the matching certificates in the GenericCertificate field of the SecurityBlock request. > If we add a sentence in 5.3.4 and one with >> TURN-SERVICE, I think that will cover anyone reading the spec >> thoroughly and anyone just looking at TURN-SERVICE as an example usage >> while writing another. > >> Bruce > > > >>>> >>>> Bruce >>>> >>>> >>>> >>>> On Sun, Jul 17, 2011 at 1:11 PM, Marc Petit-Huguenin wrote: >>>> When storing a TURN-SERVICE kind, the storing peer cannot count on having the >>>> certificate used to sign the value available locally, because the >>>> CERTIFICATE_BY_NODE and CERTIFICATE_BY_USER kinds will be stored in a different >>>> peer. >>>> >>>> Is the intent that the storing peer remotely fetch the certificate for the >>>> validation or should it fail when the certificate is not sent in the >>>> certificates field of the SecurityBlock? >>>> >>>> Note that if the request should fail, then it is a problem with replications as >>>> there is very little chance to have the right certificate in the SecurityBlock >>>> when the value is replicated. >>>> > >> - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4p5IAACgkQ9RoMZyVa61fTUACeLnbCTQb/hN4buzKlHl+8j2Am WHYAn31D+2w2hcxEIh921OfiXFrG0SGz =CA38 -----END PGP SIGNATURE----- From petithug@acm.org Fri Jul 22 14:09:59 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920B121F8B1C for ; Fri, 22 Jul 2011 14:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.687 X-Spam-Level: X-Spam-Status: No, score=-101.687 tagged_above=-999 required=5 tests=[AWL=-0.899, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvJZe8btcIm6 for ; Fri, 22 Jul 2011 14:09:58 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0A921F8B2D for ; Fri, 22 Jul 2011 14:09:58 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id EA8E520136; Fri, 22 Jul 2011 23:07:45 +0200 (CEST) Message-ID: <4E29E71C.90804@acm.org> Date: Fri, 22 Jul 2011 14:09:48 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: Bruce Lowekamp References: <4E0DB1D0.6060703@ericsson.com> <4E299D66.8000400@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] AD review: draft-ietf-p2psip-base-15 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2011 21:09:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/22/2011 01:54 PM, Bruce Lowekamp wrote: > On Fri, Jul 22, 2011 at 11:55 AM, Marc Petit-Huguenin wrote: > On 07/01/2011 04:38 AM, Gonzalo Camarillo wrote: >>>> Folks, >>>> >>>> the P2PSIP WG chairs are in the process of requesting the publication of >>>> the following draft: >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-p2psip-base/ >>>> >>>> At this point, they are working with the secretary to fix the state of >>>> the document in the tracker (it should be publication requested) and to >>>> upload the document's PROTO write up. >>>> >>>> While that gets fixed, I have done my AD review (see below) in order to >>>> gain some time. As soon as these comments are addressed, I will start >>>> the IETF LC on this draft. >>>> > > The IETF LC ends today but Michael Chen and I sent multiple questions to the > mailing-list that are still without answer. I find it difficult to decide if > this specification is ready to be published until this questions are answered. > > >> Marc, > >> The other authors and I greatly appreciate the time you have put into >> implementing and evaluating the protocol, and into providing comments >> on the document. However, it's difficult to keep track of them since >> they are generally in separate emails, so I would appreciate it if you >> could be specific listing any unanswered questions. I've looked >> through my email archive and responded to the two questions (one from >> you and one from Michael Chen) that I found, both of which I think are >> simple to resolve in the text. If there are any others, please list >> them so we can be sure to address them. http://www.ietf.org/mail-archive/web/p2psip/current/msg05937.html You may also want to look at my draft containing stuff I plan to publish as extensions or in RELOAD 2.0: http://www.ietf.org/internet-drafts/draft-petithuguenin-p2psip-reload-bis-00.txt Version -01 will contains at least one additional section, here's the current draft (which is related to the TURN-SERVICE question):
An original store is able to verify the signature of the items to store because the signer of the request is the same than the signer of the stored values, but it is not true for replica stores, where the request signer and the stored value signer are different. Even for the Access Control Policies where the certificate is stored at the same peer than the stored value, there is no guarantee that during a replication the certificate will be available for verification of the value. This document adds a rule to the list in section 6.4.1.1 that says that when processing a StoreReq, none of the modifications is visible to the validation process until the whole content of the StoreReq is validated. This means for example that sending a certificate with a CERTIFICATE_BY_NODE kind in the same StoreReq than a a value signed by this certificate will not permit to validate this value. The certificate has to be stored before in a different Store request or has to be sent in the GenericCertificate field of the SecurityBlock of the request. This document also requires that each peer stores all the certificates needed to verify all the stored values. When replicating the stored values, the peer MUST also send the matching certificates in the GenericCertificate field of the SecurityBlock request.
- -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4p5xQACgkQ9RoMZyVa61eHuQCgp4Cinv0NrOcCR7IWF/qcz67l KrgAniXutvo9Tp+k/TTtfbR89hP+3g/U =Aftz -----END PGP SIGNATURE----- From p2p.nve.2011@gmail.com Sat Jul 23 01:06:18 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD6C21F85CE; Sat, 23 Jul 2011 01:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v12zpvX0oBvD; Sat, 23 Jul 2011 01:06:16 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7501F21F84FE; Sat, 23 Jul 2011 01:06:16 -0700 (PDT) Received: by yxp4 with SMTP id 4so1981933yxp.31 for ; Sat, 23 Jul 2011 01:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=8ZKHcX719/YoCAsY1ZUDa4TS3GP0FosW0oY5GRNWUiI=; b=bQERUTDAVmYKhrL8/aOpQ+fGyurbqs6RqF8yW3Z1iaqH+mZXn0ZcR9quRoFyyjpkxT apBe8OC6jRB9bl5pcwxa6ODZ27gOR7KeV0VuqVUju5PRUpeNvq2IsYgxJ01RbBi7jPVU TOMJzgWMsYENu8OlKICDzgRDXGWRhU3cz6p5M= MIME-Version: 1.0 Received: by 10.142.200.2 with SMTP id x2mr589188wff.125.1311408375180; Sat, 23 Jul 2011 01:06:15 -0700 (PDT) Received: by 10.143.82.9 with HTTP; Sat, 23 Jul 2011 01:06:15 -0700 (PDT) Date: Sat, 23 Jul 2011 16:06:15 +0800 Message-ID: From: =?Big5?B?qVCpd71u?= To: ppsp@ietf.org, sam@irtf.org, p2p@ogf.org, p2psip@ietf.org Content-Type: multipart/alternative; boundary=000e0cd2e2465bac8504a8b80e2d Subject: [P2PSIP] [CFP] P2PNVE 2011 (Deadline: Aug. 20, 2011) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2011 08:18:45 -0000 --000e0cd2e2465bac8504a8b80e2d Content-Type: text/plain; charset=ISO-8859-1 CFP ======================================================================== The 5th International Workshop on Peer-to-Peer Networked Virtual Environments (P2P-NVE 2011) in conjunction with The 17th International Conference on Parallel and Distributed Systems (ICPADS 2011) December 7-9, 2011 Tainan, Taiwan http://acnlab.csie.ncu.edu.tw/P2PNVE2011/ ======================================================================== PURPOSE AND SCOPE Peer-to-peer (P2P) is a computing paradigm based on self-organizing network overlays, in which participating entities play symmetric roles as both servers and clients for accomplish common goals. Compared with the traditional client/server (C/S) paradigm, the P2P paradigm is not vulnerable to a single point of failure and has better scalability and lower installation and management cost. It has been successfully applied to many applications, such as data sharing, storage sharing, bandwidth sharing, collaborative computation, and so on. Many research studies have been devoted to developing efficient, flexible, and secure P2P systems. They call for a workshop to provide a forum for researchers to exchange their ideas about state-of-the-art P2P technologies. Recently, some studies try to apply the P2P paradigm to network virtual environments (NVEs), which is also known as distributed virtual environment (DVEs) or collaborative virtual environment (CVEs), to increase NVE scalability and to reduce NVE management and deployment costs. An NVE is a computer-generated virtual world where multiple users can assume virtual representatives (or avatars) to concurrently interact with each other via networked links. Examples of NVEs include early DARPA SIMNET and DIS systems as well as currently booming Massively Multiplayer Online Games (MMOGs). Typical examples of studies on P2P NVEs are P2P voice chatting, P2P 3D streaming, P2P game state management, and so on. In spite of the success of the studies, we need more studies about state consistency control, persistent data storage, multimedia data dissemination, cheat-prevention, topology mismatching, and virtual world interoperability to construct NVEs of better performance. The 1st, 2nd, 3rd and 4th International Workshop on Peer-to-Peer Networked Virtual Environments were held in conjunction with the 13th, 14th, 15th and 16th International Conference on Parallel and Distributed Systems in 2007, 2008, 2009, and 2010 respectively. To adhere to the theme of P2P-NVE workshops, the theme of P2P-NVE 2011 is to solicit original and previously unpublished new ideas on general P2P schemes as well as on the design and realization of P2P NVEs. The workshop aims to facilitate discussions and idea exchanges by both academics and practitioners. Authors are invited to submit an electronic version of original, unpublished manuscripts, not to exceed 8 double-columned, single-spaced pages, to the workshop. Submitted papers should be in accordance with IEEE Computer Society guidelines, and will be refereed by reviewers in terms of relevance, originality, contribution, correctness, and presentation. All Accepted papers will be published by IEEE Press (indexed by EI) and will be included in IEEE Xplore. Topics of interest include, but are not limited to: * P2P systems and infrastructures * Applications of P2P systems * Performance evaluation of P2P systems * Trust and security issues in P2P systems * Network support for P2P systems * Fault tolerance in P2P systems * Data structures for P2P systems * Efficient P2P resource lookup and sharing * Distributed Hash Tables (DHTs) and related issues * Solutions to topology mismatching for P2P overlays * P2P overlays for NVEs * P2P NVE multicast * P2P NVE interoperability * P2P NVE content distribution * P2P NVE 3D streaming * P2P NVE voice communications * P2P NVE architecture designs * P2P NVE prototypes * P2P NVE consistency control * Persistent storage for P2P NVEs * Security and cheat-prevention mechanisms for P2P games * P2P control for mobile NVEs * P2P NVE applications on mobile devices ========================================== IMPORTANT DATES Submission: August 20, 2011 Notification: September 25, 2011 Camera ready: October 7, 2011 =========================================== PAPER SUBMISSION Authors are invited to submit an electronic version of original, unpublished manuscripts, not to exceed 8 double-columned, single-spaced pages, to the workshop. Submitted papers should be in PDF format in accordance with IEEE Computer Society guidelines, and will be refereed by reviewers in terms of originality, contribution, correctness, and presentation. --000e0cd2e2465bac8504a8b80e2d Content-Type: text/html; charset=Big5 Content-Transfer-Encoding: quoted-printable CFP=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The 5th International Workshop on Peer-to-Peer Networked Virtual Environmen= ts (P2P-NVE 2011)

in conjunction with

The 17th International = Conference on Parallel and Distributed Systems (ICPADS 2011)

Decembe= r 7-9, 2011
Tainan, Taiwan

> =C2=A0 > =C2=A0 =C2=A0An original store is able to verify the signature of the ite= ms to store > because the signer of the request is the same than the signer of the stor= ed > values, but it is not true for replica stores, where the request signer a= nd the > stored value signer are different. > =C2=A0 =C2=A0Even for the Access Control Policies where the certificate i= s stored at the > same peer than the stored value, there is no guarantee that during a repl= ication > the certificate will be available for verification of the value. > =C2=A0 > > =C2=A0 > =C2=A0 =C2=A0This document adds a rule to the list in section 6.4.1.1 tha= t says that when > processing a StoreReq, none of the modifications is visible to the valida= tion > process until the whole content of the StoreReq is validated. > =C2=A0 =C2=A0This means for example that sending a certificate with a CER= TIFICATE_BY_NODE > kind in the same StoreReq than a a value signed by this certificate will = not > permit to validate this value. > =C2=A0 =C2=A0The certificate has to be stored before in a different Store= request or has > to be sent in the GenericCertificate field of the SecurityBlock of the re= quest. > =C2=A0 > > =C2=A0 > =C2=A0 =C2=A0This document also requires that each peer stores all the ce= rtificates > needed to verify all the stored values. None of this seems to add anything beyond what's already in 5.3.4, that the certificates necessary to validate a request SHOULD be in the message. Quoting again from that section: In systems which have some alternate certificate distribution mechanism, some certificates MAY be omitted. that's the exception, clearly stated. Otherwise, the certs are included. > =C2=A0 =C2=A0When replicating the stored values, the peer MUST also send = the matching > certificates in the GenericCertificate field of the SecurityBlock request= . The exception was requested by some people with specific scenarios where they had (or could get) certificates quite easily. The exception also applies to the shared-secret security mechanism in the document (12.4). Since that specific case where certs don't need to be included is already in the base document, I would be against changing the current approach by making including certs a MUST. Bruce > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk4p5xQACgkQ9RoMZyVa61eHuQCgp4Cinv0NrOcCR7IWF/qcz67l > KrgAniXutvo9Tp+k/TTtfbR89hP+3g/U > =3DAftz > -----END PGP SIGNATURE----- > From bbl@lowekamp.net Sat Jul 23 12:03:50 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF3921F86BC for ; Sat, 23 Jul 2011 12:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTPbk2XC0zx2 for ; Sat, 23 Jul 2011 12:03:49 -0700 (PDT) Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8654421F853B for ; Sat, 23 Jul 2011 12:03:49 -0700 (PDT) Received: by eya28 with SMTP id 28so3366403eya.21 for ; Sat, 23 Jul 2011 12:03:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.119.136 with SMTP id n8mr985832eeh.30.1311447827349; Sat, 23 Jul 2011 12:03:47 -0700 (PDT) Received: by 10.14.127.13 with HTTP; Sat, 23 Jul 2011 12:03:47 -0700 (PDT) In-Reply-To: <4E2B172E.5020906@acm.org> References: <4E2317B6.4090901@acm.org> <4E29DF8E.2050403@acm.org> <4E29E482.3060506@acm.org> <4E2B172E.5020906@acm.org> Date: Sat, 23 Jul 2011 15:03:47 -0400 Message-ID: From: Bruce Lowekamp To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Signature validation for TURN-SERVICE kind X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2011 19:03:50 -0000 On Sat, Jul 23, 2011 at 2:47 PM, Marc Petit-Huguenin wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/22/2011 10:58 PM, Marc Petit-Huguenin wrote: >> On 07/22/2011 01:48 PM, Bruce Lowekamp wrote: >>> On Fri, Jul 22, 2011 at 4:37 PM, Marc Petit-Huguenin = wrote: >>> On 07/22/2011 01:32 PM, Bruce Lowekamp wrote: >>>>>> >From 5.3.4: >>>>>> >>>>>> The certificates bucket SHOULD contain all the certificates necessar= y >>>>>> =C2=A0 =C2=A0to verify every signature in both the message and the i= nternal >>>>>> =C2=A0 =C2=A0message objects. =C2=A0This is the only location in the= message which >>>>>> =C2=A0 =C2=A0contains certificates, thus allowing for only a single = copy of each >>>>>> =C2=A0 =C2=A0certificate to be sent. =C2=A0In systems which have som= e alternate >>>>>> =C2=A0 =C2=A0certificate distribution mechanism, some certificates M= AY be omitted. >>>>>> =C2=A0 =C2=A0However, implementors should note that this creates the= possibility >>>>>> =C2=A0 =C2=A0that messages may not be immediately verifiable because= certificates >>>>>> =C2=A0 =C2=A0must first be retrieved. >>>>>> >>>>>> >>>>>> This implies that a TURN-SERVICE implementation caches the >>>>>> certificates needed for replication. =C2=A0Will add a note to the >>>>>> TURN-SERVICE description for clarification. >> >>> OK, but isn't this true also for all other kinds that do not use USER-M= ATCH or >>> NODE-MATCH? >> >> >>>> Yes, since 5.3.4 is the definition of the basic SecurityBlock, it >>>> applies to anything using the protocol. =C2=A0Though I would expect su= ch >>>> usages to be rare. >> >> Well, in addition to the TURN-SERVICE kind, all the kinds defined as Sha= red >> resource (draft-knauf-p2psip-share), the VIPR kind and the ReDir kind. = =C2=A0That's >> not rare. >> >>> Do you have any suggestions for how/where to >>>> clarify this point? >> >> IMO, it should be required that each peer stores all the certificates ne= eded to >> verify all the stored values at this peer. =C2=A0When replicating the st= ored values, >> the peer must also send the matching certificates in the GenericCertific= ate >> field of the SecurityBlock request. > > If should be also required that a Fetch returns in the SecurityBlock all = the > certificates for all the StoredValue it will return. =C2=A0With this the > CERTIFICATE_BY_NODE and CERTIFICATE_BY_USER kinds are redundant and can b= e > removed from the spec. > This is already covered by 5.3.4. As agreed earlier, we will clarify it. Since the two certificate usages aren't really intended to be used to validate messages, I don't see a reason to remove them here. Bruce >> >>> If we add a sentence in 5.3.4 and one with >>>> TURN-SERVICE, I think that will cover anyone reading the spec >>>> thoroughly and anyone just looking at TURN-SERVICE as an example usage >>>> while writing another. >> >>>> Bruce >> >> >> >>>>>> >>>>>> Bruce >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Jul 17, 2011 at 1:11 PM, Marc Petit-Huguenin wrote: >>>>>> When storing a TURN-SERVICE kind, the storing peer cannot count on h= aving the >>>>>> certificate used to sign the value available locally, because the >>>>>> CERTIFICATE_BY_NODE and CERTIFICATE_BY_USER kinds will be stored in = a different >>>>>> peer. >>>>>> >>>>>> Is the intent that the storing peer remotely fetch the certificate f= or the >>>>>> validation or should it fail when the certificate is not sent in the >>>>>> certificates field of the SecurityBlock? >>>>>> >>>>>> Note that if the request should fail, then it is a problem with repl= ications as >>>>>> there is very little chance to have the right certificate in the Sec= urityBlock >>>>>> when the value is replicated. >>>>>> > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk4rFysACgkQ9RoMZyVa61cnoACdEqchCvjXnTAFAPSzrWv8Z2TW > 2uAAnAxG+SD6/d7JyUvpGyXIqqVV0SNw > =3D/W+3 > -----END PGP SIGNATURE----- > From petithug@acm.org Sat Jul 23 12:12:39 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9AC21F8A80 for ; Sat, 23 Jul 2011 12:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.659 X-Spam-Level: X-Spam-Status: No, score=-101.659 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YmRMlv9EYmw for ; Sat, 23 Jul 2011 12:12:35 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id BCAE721F856F for ; Sat, 23 Jul 2011 12:12:34 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:ca0a:a9ff:fe2e:a4f6] (tem.shalmaneser.org [IPv6:2001:470:1f05:616:ca0a:a9ff:fe2e:a4f6]) by implementers.org (Postfix) with ESMTPS id 572E720136; Sat, 23 Jul 2011 21:10:26 +0200 (CEST) Message-ID: <4E2B1D1C.2030904@acm.org> Date: Sat, 23 Jul 2011 21:12:28 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Icedove/3.1.11 MIME-Version: 1.0 To: Bruce Lowekamp References: <4E0DB1D0.6060703@ericsson.com> <4E299D66.8000400@acm.org> <4E29E71C.90804@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] AD review: draft-ietf-p2psip-base-15 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2011 19:12:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/23/2011 08:59 PM, Bruce Lowekamp wrote: > On Fri, Jul 22, 2011 at 5:09 PM, Marc Petit-Huguenin wrote: > On 07/22/2011 01:54 PM, Bruce Lowekamp wrote: >>>> On Fri, Jul 22, 2011 at 11:55 AM, Marc Petit-Huguenin wrote: >>>> On 07/01/2011 04:38 AM, Gonzalo Camarillo wrote: >>>>>>> Folks, >>>>>>> >>>>>>> the P2PSIP WG chairs are in the process of requesting the publication of >>>>>>> the following draft: >>>>>>> >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-p2psip-base/ >>>>>>> >>>>>>> At this point, they are working with the secretary to fix the state of >>>>>>> the document in the tracker (it should be publication requested) and to >>>>>>> upload the document's PROTO write up. >>>>>>> >>>>>>> While that gets fixed, I have done my AD review (see below) in order to >>>>>>> gain some time. As soon as these comments are addressed, I will start >>>>>>> the IETF LC on this draft. >>>>>>> >>>> >>>> The IETF LC ends today but Michael Chen and I sent multiple questions to the >>>> mailing-list that are still without answer. I find it difficult to decide if >>>> this specification is ready to be published until this questions are answered. >>>> >>>> >>>>> Marc, >>>> >>>>> The other authors and I greatly appreciate the time you have put into >>>>> implementing and evaluating the protocol, and into providing comments >>>>> on the document. However, it's difficult to keep track of them since >>>>> they are generally in separate emails, so I would appreciate it if you >>>>> could be specific listing any unanswered questions. I've looked >>>>> through my email archive and responded to the two questions (one from >>>>> you and one from Michael Chen) that I found, both of which I think are >>>>> simple to resolve in the text. If there are any others, please list >>>>> them so we can be sure to address them. > > http://www.ietf.org/mail-archive/web/p2psip/current/msg05937.html > > >> Thanks for pointing that out. I didn't go back beyond the beginning >> of last call when I looked yesterday. > > > You may also want to look at my draft containing stuff I plan to publish as > extensions or in RELOAD 2.0: > > >> If you have a comment to make about the current draft, please make it >> clearly on-list. I sure wouldn't expect a 2.0 document anytime soon, >> and if you believe there are issues that somehow need to be resolved, >> you should be making clear technical statements about them. I've read >> that draft, but I'm not going to go through guessing what you think >> you want to do later as extensions and what you think should be >> changed in the current draft. If there was something in it that I thought was necessary to the base draft, I would have send it directly. > > > http://www.ietf.org/internet-drafts/draft-petithuguenin-p2psip-reload-bis-00.txt > > Version -01 will contains at least one additional section, here's the current > draft (which is related to the TURN-SERVICE question): > >
> > An original store is able to verify the signature of the items to store > because the signer of the request is the same than the signer of the stored > values, but it is not true for replica stores, where the request signer and the > stored value signer are different. > Even for the Access Control Policies where the certificate is stored at the > same peer than the stored value, there is no guarantee that during a replication > the certificate will be available for verification of the value. > > > > This document adds a rule to the list in section 6.4.1.1 that says that when > processing a StoreReq, none of the modifications is visible to the validation > process until the whole content of the StoreReq is validated. > This means for example that sending a certificate with a CERTIFICATE_BY_NODE > kind in the same StoreReq than a a value signed by this certificate will not > permit to validate this value. > The certificate has to be stored before in a different Store request or has > to be sent in the GenericCertificate field of the SecurityBlock of the request. > > > > This document also requires that each peer stores all the certificates > needed to verify all the stored values. > >> None of this seems to add anything beyond what's already in 5.3.4, >> that the certificates necessary to validate a request SHOULD be in the >> message. Quoting again from that section: > >> In systems which have some alternate >> certificate distribution mechanism, some certificates MAY be omitted. > >> that's the exception, clearly stated. Otherwise, the certs are included. I can assure you that it is not what implementers understand (and I am not talking about myself). This is the problem when a SHOULD is used instead of a conditional MUST. > > When replicating the stored values, the peer MUST also send the matching > certificates in the GenericCertificate field of the SecurityBlock request. > >> The exception was requested by some people with specific scenarios >> where they had (or could get) certificates quite easily. The >> exception also applies to the shared-secret security mechanism in the >> document (12.4). Since that specific case where certs don't need to >> be included is already in the base document, I would be against >> changing the current approach by making including certs a MUST. OK. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4rHRoACgkQ9RoMZyVa61flsACfb10o/deRx4Q24yV/rE+KIjns thYAnRdr8OeI1CWv1mpzZZM6ablxnpZJ =UFHi -----END PGP SIGNATURE----- From petithug@acm.org Sat Jul 23 12:14:22 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156A621F86AD for ; Sat, 23 Jul 2011 12:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPlkF5AkamCY for ; Sat, 23 Jul 2011 12:14:21 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6756421F856F for ; Sat, 23 Jul 2011 12:14:15 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:ca0a:a9ff:fe2e:a4f6] (tem.shalmaneser.org [IPv6:2001:470:1f05:616:ca0a:a9ff:fe2e:a4f6]) by implementers.org (Postfix) with ESMTPS id 2D76B20136; Sat, 23 Jul 2011 21:12:07 +0200 (CEST) Message-ID: <4E2B1D85.2030908@acm.org> Date: Sat, 23 Jul 2011 21:14:13 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Icedove/3.1.11 MIME-Version: 1.0 To: Bruce Lowekamp References: <4E2317B6.4090901@acm.org> <4E29DF8E.2050403@acm.org> <4E29E482.3060506@acm.org> <4E2B172E.5020906@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Signature validation for TURN-SERVICE kind X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2011 19:14:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/23/2011 09:03 PM, Bruce Lowekamp wrote: > On Sat, Jul 23, 2011 at 2:47 PM, Marc Petit-Huguenin wrote: > On 07/22/2011 10:58 PM, Marc Petit-Huguenin wrote: >>>> On 07/22/2011 01:48 PM, Bruce Lowekamp wrote: >>>>> On Fri, Jul 22, 2011 at 4:37 PM, Marc Petit-Huguenin wrote: >>>>> On 07/22/2011 01:32 PM, Bruce Lowekamp wrote: >>>>>>>> >From 5.3.4: >>>>>>>> >>>>>>>> The certificates bucket SHOULD contain all the certificates necessary >>>>>>>> to verify every signature in both the message and the internal >>>>>>>> message objects. This is the only location in the message which >>>>>>>> contains certificates, thus allowing for only a single copy of each >>>>>>>> certificate to be sent. In systems which have some alternate >>>>>>>> certificate distribution mechanism, some certificates MAY be omitted. >>>>>>>> However, implementors should note that this creates the possibility >>>>>>>> that messages may not be immediately verifiable because certificates >>>>>>>> must first be retrieved. >>>>>>>> >>>>>>>> >>>>>>>> This implies that a TURN-SERVICE implementation caches the >>>>>>>> certificates needed for replication. Will add a note to the >>>>>>>> TURN-SERVICE description for clarification. >>>> >>>>> OK, but isn't this true also for all other kinds that do not use USER-MATCH or >>>>> NODE-MATCH? >>>> >>>> >>>>>> Yes, since 5.3.4 is the definition of the basic SecurityBlock, it >>>>>> applies to anything using the protocol. Though I would expect such >>>>>> usages to be rare. >>>> >>>> Well, in addition to the TURN-SERVICE kind, all the kinds defined as Shared >>>> resource (draft-knauf-p2psip-share), the VIPR kind and the ReDir kind. That's >>>> not rare. >>>> >>>>> Do you have any suggestions for how/where to >>>>>> clarify this point? >>>> >>>> IMO, it should be required that each peer stores all the certificates needed to >>>> verify all the stored values at this peer. When replicating the stored values, >>>> the peer must also send the matching certificates in the GenericCertificate >>>> field of the SecurityBlock request. > > If should be also required that a Fetch returns in the SecurityBlock all the > certificates for all the StoredValue it will return. With this the > CERTIFICATE_BY_NODE and CERTIFICATE_BY_USER kinds are redundant and can be > removed from the spec. > > >> This is already covered by 5.3.4. As agreed earlier, we will clarify >> it. Since the two certificate usages aren't really intended to be >> used to validate messages, I don't see a reason to remove them here. OK. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4rHX8ACgkQ9RoMZyVa61cq9wCfbnQU3aIHl7OeGWJma1oxskxE /lkAn3X6xzxMeqmq7LhDejCvRozcIvGc =mQI0 -----END PGP SIGNATURE----- From buford@samrg.org Fri Jul 29 06:14:29 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EBC21F8BC8 for ; Fri, 29 Jul 2011 06:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.59 X-Spam-Level: X-Spam-Status: No, score=-100.59 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5vcKic6tAig for ; Fri, 29 Jul 2011 06:14:28 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 579A421F8B82 for ; Fri, 29 Jul 2011 06:14:28 -0700 (PDT) Received: (qmail 1737 invoked by uid 0); 29 Jul 2011 13:14:28 -0000 Received: from unknown (HELO host181.hostmonster.com) (74.220.207.181) by cpoproxy3.bluehost.com with SMTP; 29 Jul 2011 13:14:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=samrg.org; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=svgLyBcfydUdpnpLCccJE87H2JmHrSlkZR8l7GY3Bxk=; b=QFusIZ5M9ugzSKDlQ5WifPqC2+zdBmbeYwOXKKnp7vZwPUOSIwiajEkkTp1DqZsbkOX7qDSmp+OFKkc0Xo1ZL+1lpX26z9zF5qu5qNDrwp5jfN89Dd2zxWXe2KIBy7cV; Received: from dhcp-14a1.meeting.ietf.org ([130.129.20.161] helo=AGILON) by host181.hostmonster.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.76) (envelope-from ) id 1QmmtX-0001Ex-MD; Fri, 29 Jul 2011 07:14:27 -0600 From: "John Buford" To: Date: Fri, 29 Jul 2011 09:14:28 -0400 Message-ID: <03ee01cc4df1$73a4a990$5aedfcb0$@org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03EF_01CC4DCF.EC930990" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcxNe0K05u6+4vGkQU+DaROYeYeOwAAdgR5g Content-Language: en-us X-Identified-User: {2055:host181.hostmonster.com:samrgorg:samrg.org} {sentby:smtp auth 130.129.20.161 authed with buford@samrg.org} Cc: 'Lars Eggert' Subject: [P2PSIP] RELOAD code point - request for private message and error codes X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 13:14:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_03EF_01CC4DCF.EC930990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sorry to be raising this issue at this late stage. We are trying to use RELOAD for Application Layer Multicast in the SAM RG in the IRTF, and need to introduce some additional message types for experimenting. However, although Data Kinds and Application-ID have a private range, there is no allocation for private or experimental message codes or error codes in the RELOAD spec. draft-samrg-sam-baseline-protocol-00.txt is the current version of our ALM in RELOAD design. John Buford buford@samrg.org ------=_NextPart_000_03EF_01CC4DCF.EC930990 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry to = be raising this issue at this late stage.  We are trying to use = RELOAD for

Application Layer = Multicast in the SAM RG in the IRTF, and need to = introduce

some additional message = types for experimenting.

 

However, = although Data Kinds and Application-ID have a private range, there is no = allocation

for private or = experimental message codes or error codes in the RELOAD = spec.

 

draft-samrg-sam-baseline-protocol-00.txt is the = current version of our ALM in RELOAD design.

 

John = Buford

buford@samrg.org

 

------=_NextPart_000_03EF_01CC4DCF.EC930990-- From gonzalo.camarillo@ericsson.com Fri Jul 29 06:31:25 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9E921F8B88 for ; Fri, 29 Jul 2011 06:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.604 X-Spam-Level: X-Spam-Status: No, score=-106.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK-WcSCjxnTs for ; Fri, 29 Jul 2011 06:31:24 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6955721F8B21 for ; Fri, 29 Jul 2011 06:31:24 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-24-4e32b625138c Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F9.A5.20773.526B23E4; Fri, 29 Jul 2011 15:31:17 +0200 (CEST) Received: from [131.160.126.141] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Fri, 29 Jul 2011 15:31:16 +0200 Message-ID: <4E32B623.4080503@ericsson.com> Date: Fri, 29 Jul 2011 09:31:15 -0400 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [P2PSIP] draft-ietf-p2psip-base-17 - Reference to an abandoned draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 13:31:25 -0000 Hi, the RELOAD spec has a reference to the following draft, which seems to have been abandoned: [I-D.pascual-p2psip-clients] Pascual, V., Matuszewski, M., Shim, E., Zhang, H., and S. Yongchao, "P2PSIP Clients", draft-pascual-p2psip-clients-01 (work in progress), February 2008. The authors may want to copy/paste whatever text is relevant from this draft to the RELOAD spec to avoid the reference. http://tools.ietf.org/html/draft-pascual-p2psip-clients-01 Cheers, Gonzalo From victor.pascual.avila@gmail.com Fri Jul 29 07:53:51 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7360211E8072 for ; Fri, 29 Jul 2011 07:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzgD4pVEI8HQ for ; Fri, 29 Jul 2011 07:53:51 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE9821F8C53 for ; Fri, 29 Jul 2011 07:53:50 -0700 (PDT) Received: by iye7 with SMTP id 7so4978819iye.31 for ; Fri, 29 Jul 2011 07:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=A4xuJnO+JyJiUZ7JE/2XlBjY/4DHS3Xl18U7Et+km7w=; b=lSIKEogrAyZkrn/5JD0ZMigCiaxVUC5zRiDXvo3H0cIzNvReTckxqapzshbza/e75i u9YOETSKc/xyNWOk6+6+lNPtME46E9/hjwLaBlu2w25WNMmKQ1SFjpbblen6jUVdsyfc KSF4CjBIYVbvvG196D4wMOe2zhA/BK75sd/dA= MIME-Version: 1.0 Received: by 10.231.84.144 with SMTP id j16mr894339ibl.145.1311951230152; Fri, 29 Jul 2011 07:53:50 -0700 (PDT) Received: by 10.231.3.133 with HTTP; Fri, 29 Jul 2011 07:53:50 -0700 (PDT) In-Reply-To: <4E32B623.4080503@ericsson.com> References: <4E32B623.4080503@ericsson.com> Date: Fri, 29 Jul 2011 16:53:50 +0200 Message-ID: From: Victor Pascual Avila To: Gonzalo Camarillo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-17 - Reference to an abandoned draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2011 14:53:51 -0000 Correct-- The authors are not planning to update/maintain this draft -Victor On Fri, Jul 29, 2011 at 3:31 PM, Gonzalo Camarillo wrote: > Hi, > > the RELOAD spec has a reference to the following draft, which seems to > have been abandoned: > > =C2=A0 [I-D.pascual-p2psip-clients] > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pascual, V., Matuszewski,= M., Shim, E., Zhang, H., and S. > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yongchao, "P2PSIP Clients= ", > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-pascual-p2psip-clie= nts-01 (work in progress), > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0February 2008. > > The authors may want to copy/paste whatever text is relevant from this > draft to the RELOAD spec to avoid the reference. > > http://tools.ietf.org/html/draft-pascual-p2psip-clients-01 > > Cheers, > > Gonzalo > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > --=20 Victor Pascual =C3=81vila