Subject: [P2PSIP] Fwd: New Version Notification for draft-knauf-p2psip-share-01.txt

From: Alexander Knauf <[email-masked]>
Date: Mon, 11 Jul 2011 22:01:28 +0200

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: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 13 Jul 2011 09:35:00 -0700

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
> 
> 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.
> 

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Alexander Knauf <[email-masked]>
Date: Thu, 14 Jul 2011 10:46:44 +0200

Hi Marc,

Am 13.07.2011 18:35, schrieb Marc Petit-Huguenin:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Alexander,
>
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
> -----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: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 14 Jul 2011 07:36:06 -0700

On 07/14/2011 01:46 AM, Alexander Knauf wrote:
>> 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:

<kind-block>
  <kind id=\"4026531841\"
xmlns:share=\"urn:ietf:params:xml:ns:p2p:config-base:share\">
    <data-model>ARRAY</data-model>
    <access-control>USER-PATTERN-MATCH</access-control>
    <max-count>100</max-count>
    <max-size>100</max-size>
    <share:pattern>.*-conf-$USER@$DOMAIN</share:pattern>
    <share:offset>2</share:offset>
  </kind>
</kind-block>

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