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

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

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