Subject: Re: [P2PSIP] Isssues not fixed in draft-ietf-p2psip-base-13

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Apr 2011 19:44:59 -0700

Thanks michael. We will get these

But really don't you think it's cooler to have an x in your name?

Ekr

On Mar 30, 2011, at 20:05, Michael Chen <[email-masked]> wrote:

> Hi,
> 
> While looking at the diff between base-12 and 13, I spotted couple simple problems:
> 
> 1) Section 5.5.1.2, the following sentence should get its own "o" bullet. There should be altogether 4 bullets:
> 
>  o  If the peer is overloaded or detects some other kind of error, it
>      MAY generate an error instead of an AttachReqAns.
> 
> Also, in my proposed language for this section, I have one sentence right before the "*" bullets that is not included in base-13:
> 
> +     The tie-breaker heuristic is to compare the Node-IDs of both
> +     peers as unsigned integers, and
> 
> 
> No where in this draft talks about one Node-ID "smaller" or "larger" than another Node-ID. I thought this language or something similar can help implementors understand the heuristic better. Wrong implementation of this comparison defeats the heuristic completely.
> 
> 2) Please remove the extra "x" letter in my name in paragraph right above Section 15.
> 
> Thanks
> 
> Michael Chen
> 
> 
> On 3/14/2011 4:43 PM, Cullen Jennings wrote:
>> There are a few things that did not get fixed in the -13 draft. Some due to just not sure how to fix them yet and some due to lack of time. The remanning open items are
>> 
>> 
>> We need to update a few things to clarify usage when certificates have multiple node-id. Proposal is to say that, in cases other than when signaling a bootstrap peer, the first message is an Attach. The node-id used in the SignerIdentity of the Attach would indicate the node-id that this connection represented. The SignerIdentity still has to be one of the node-is in the certificate or the message is rejected. The same approach works for the non certificate based security modes. I realize this paragraph is clear as mud - we will work on better text. I may have misunderstood some of the email on this but I think this is the proposal from Marc, Bruce, and EKR.
>> 
>> 
>> In section 6.3.4, it is not specified how to encode i into the hash. I'm proposing treating it as a uint32 and hashing that.
>> 
>> 
>> 
>>> A.39. Section 6.2.2
>>> 
>>> I am not really sure to understand how the "exists=False" are synthesized when
>>> doing a Fetch on an array.  For example if a Store was made for an object with
>>> an index of 0xfffffffe, and the Fetch requests the whole array, will the answer
>>> contains 4294967294 "exists=False" objects?
>> Proposal: Yes
>> 
>>> Also how are this synthesized elements signed?
>> Proposal:
>> The "opaque value<0..2^32-1>;" would just indicate a 0 byte long binary blog and be encoded per normal.
>> 
>> 
>>> A.40. Section 6.4.3.2
>>> 
>>> If exist is False, should the hash_value be the hash value of an empty byte
>>> array (i.e. da39a3ee5e6b4b0d3255bfef95601890afd80709 for SHA-1) or be omitted?
>> Proposal:
>> empty byte array ... keep the code path all the same with no special rules for exists == False. Keep in mind that you need to "sign" a delete of an entry and have that interact properly when a partitioned overlay merges"
>> 
>> 
>>> A.43. Section 10.1 Element signature
>>> 
>>> What certificate should be used to compute (and verify) the signature for the
>>> whole configuration file?
>> 
>> Proposal:
>> Add a<config-signer>  to the configuration that is much like the<kind-signer>  but says who can sing the configuration file. IN the case of the first time you get a configuration file, that could come at same time as enrollment and be secured that way.
>> 
>>> A.47. Section 6.3
>>> 
>>> The four policies defined in p2psip-base consistently says that "[a] given value
>>> MUST be written (or overwritten) if and only if the request is signed ..."
>>> Additional access control policies defined elsewhere use similar wording.
>>> 
>>> But should not the StoredData signature be used instead of the request
>>> signature?  When replicating the data, the signer of the StoreRequest will be
>>> different from the signer of the original request and so the test will no longer
>>> work.  Section 6.4.1.1 says that "[a] peer MUST [check that] [e]ach element is
>>> signed by a credential which is authorized to write this kind at this
>>> Resource-ID.", which seems to confirm that this is the element's signature that
>>> must be checked, not the request's.
>> So the elements sig need to be checked for sure. The questions is should the request sig also be checked before that. Unless we can say how to check it, seems like bad idea. Proposal: remove this or clarify.
>> 
>>> A.38. Section 5.5.1.1. 'rel_addr_port corresponds to the rel-addr and rel-port
>>> productions.  Only present for type "relay".'
>>> 
>>> In ICE, the rel address and port are also present for srflx and prflx candidates.
>> my brain hurts. Proposal: go for beer
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> P2PSIP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/p2psip
>> 
>> 
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 26 Apr 2011 14:33:25 -0600

On Mar 15, 2011, at 11:23 AM, Marc Petit-Huguenin wrote:

> 
> A.24. Section 10.1.1. "| attribute id { xsd:int }),"
> 
> Does not match 13.6, that is saying that this is an unsigned integer.  Should
> probably use xsd:unsignedInt instead.
> 
> (the private kind ids, 4026531844 and up, cannot be used with this definition).

Fixed.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 26 Apr 2011 14:36:39 -0600

On Mar 15, 2011, at 6:41 PM, Marc Petit-Huguenin wrote:

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

Fixed in next version.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 26 Apr 2011 14:38:28 -0600

On Mar 15, 2011, at 6:41 PM, Marc Petit-Huguenin wrote:

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

Covered in section 6.4.1.1.

Search for para starting with 
"When a peer stores data previously stored by another node"

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 26 Apr 2011 14:50:29 -0600

>      MAY generate an error instead of an AttachReqAns.

Fixed

> No where in this draft talks about one Node-ID "smaller" or "larger" than another Node-ID. I thought this language or something similar can help implementors understand the heuristic better. Wrong…

fixed 

> 2) Please remove the extra "x" letter in my name in paragraph right above Section 15.

fixed