Re: [P2PSIP] Review of draft-ietf-p2psip-sip-06

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/15/2011 02:11 AM, Marc Petit-Huguenin wrote:
> No response to this review, but I have an additional comment on this draft:
> 
> 11. Section 3
> 
> "Note that these rules permit Alice to forward calls to Bob without
>  his permission.  However, they do not permit Alice to forward Bob's
>  calls to her."
> 
> One way to allow Alice to forward Bob's calls to her (or someone else) in a
> secure way is to use the access control policy defined in
> draft-knauf-p2psip-share.  With -sip-06, only the owner of the certificate can
> store a SIP-REGISTRATION, that we can represent like this:
> 
> Resource     Kind   Node-ID       URI              signer
> [e-mail]------1--->0x12345678--->sip:[e-mail]    [e-mail]
> 
> What Share can bring here is the possibility to have an authorized third-party
> modifying the SIP registration:
> 
> Resource     Kind   Node-ID       URI              signer
> [e-mail]----1001-->0x12345678--->sip:[e-mail]    [e-mail]
> 
> Resource     Kind   Index        ACL                     signer
> [e-mail]-----18--->0x56780001-->[e-mail]   1001 true   [e-mail]
> [e-mail]-----18--->0x56780002-->[e-mail] 1001 false  [e-mail]
> 
> Here Bob (the boss) delegates to Alice (his assistant[1]) the right to modify
> its registration, so Alice can now change it:
> 
> Resource     Kind   Node-ID       URI              signer
> [e-mail]----1001-->0x12345678--->sip:[e-mail]  [e-mail]
> 
> One problem is that we cannot reuse the Kind 1 (SIP), because it is already
> bound to USER-NODE-MATCH, so we have to create a new kind (1001) that is bound
> to USER-CHAIN-ACL.  Unfortunately I do not see an easy solution to use the
> original Kind (1) with USER-CHAIN-ACL.
> 
> I would suggest to add an informative reference to draft-p2psip-knauf-share, and

I meant "add an informative reference in draft-ietf-p2psip-sip to
draft-knauf-p2psip-share".

> to add a similar example in an appendix.
> 
> 
> [1] For the record, the example I sent to the Share authors had Alice as the
> boss, and Bob as her assistant, but I had to invert the example to match the
> text in -sip.
> 
> On 08/16/2011 08:23 AM, Marc Petit-Huguenin wrote:
>> 1. Section 3: SipRegistration structure
>>
>> I would suggest to use "SipRegistration Resource Record" instead, to match the
>> terminology in -concepts.
>>
>> Same thing for SipRegistration PDU in the same section.
>>
>>
>> 2. Section 3: 1st paragraph
>>
>> s/This uses the SIP-REGISTRATION Kind-ID/This uses the SIP-REGISTRATION Kind/
>>
>>
>> 3. Section 3: opaque contact_prefs<0..2^16-1>;
>>
>> The format of the contact_prefs field is not described.  Is it RFC 3840 or RFC
>> 2533 (better in my opinion) or something else?
>>
>>
>> 4. Section 3: Destination destination_list<0..2^16-1>;
>>
>> I think it would be better to have a list of destination_list instead, to be
>> able to register different paths to the destination.  This could be useful if a
>> node decides to register as a client to multiple peers, using the procedure in
>> the second bullet of section 3.2.1 of -base.
>>
>>
>> 5. Section 3, second bullet of last list.
>>
>> It says that the storing peer must check that "[t]he certificate contains a
>> Node-ID that is the same as the dictionary key it is being stored at.", which is
>> not exactly true when the certificate contains multiple Node-ID.  It would be
>> better to say:
>>
>> "The Node-ID of the signer is the same as the dictionary key it is being stored at."
>>
>>
>> 6. Section 4, first item in list
>>
>> "Check to see if the domain part of the AOR matches the domain name of an
>> overlay of which he is a member."
>>
>> The way I understand this sentence, the "sip:[e-mail]" AOR
>> matches an overlay named "overlay.implementers.org".  Was that the intent of
>> this rule, or was the intent that the "sip:[e-mail]" AOR only
>> matches the "implementers.org" overlay?
>>
>>
>> 7. Section 5.
>>
>> "If certificate-based authentication is in use, the responding peer MUST present
>> a certificate with a Node-ID matching the terminal entry in the route list."
>>
>> If this sentence is about the AppAttach itself (and not about the connection
>> created by the AppAttach), isn't that rule already part of -base?
>>
>>
>> 8. Section 6. Second sentence.
>>
>> I do not understand what this sentence means.
>>
>>
>> 9. Section 8.1. "In this section we discuss security issues that are likely to
>> be relevant to any usage of RELOAD."
>>
>> There is no security issues discussed in section 8.1.
>>
>>
>> 10. Section 9
>>
>> Please change "TBD" by the code point that was already assigned (1, I think), so
>> early implementations can do interoperability testing.
>>
>>
>> Nits
>> ====
>>
>> - Abstract
>>
>> s/(RELOAD),/(RELOAD)./
>>
>> - Section 2
>>
>> s/consiered/considered/
>>
> 


- -- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk7Br/gACgkQ9RoMZyVa61fCTgCfQqApyrWerSBJV55zmG/svCRi
zi0An33Zv3DsWywaChy+fWXNQz7aWi68
=L0Lf
-----END PGP SIGNATURE-----