Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-sip-16

["Thomas C. Schmidt" <[e-mail]>]

Hi Alissa, all,

many thanks for the review and sorry for my late reply. Please see inline

On 15.01.2016 22:58, Alissa Cooper wrote:
> I have reviewed this document in preparation for IETF last call. I have a number of comments and questions that need to be resolved before last call can be initiated. In particular, I have some security concerns about using this in an overlay that allows registrations for any domain.
>

Regarding the security concerns, please see below.

> I’ve also included some nits below that should be resolved together with last call comments.
>
>
> == Substantive comments and questions ==
>
> = Section 3.2 =
>
> This section is underspecified and I’m not sure the references to RFC 2533 and RFC 2738 are the appropriate ones. I think what you need to specify here is that the contact_prefs will encode a media feature set comprised of SIP User Agent capabilities, as defined in RFC 3840 and registered in the SIP media feature tag registration tree (assuming that is what is intended).
>

Previous version had been the state of discussion from a long time ago. 
We've updated to follow RFC 3840, which was indeed intended.

> It’s also confusing that you only mention whether sip.schemes is required or not without mentioning whether specifying any other capabilities is required or optional.
>

This is only a highlighting following a previous discussion on the list, 
where clarity was requested on how to distinguish SIP/SIPs. We've made 
this more explicit by the following text:

    In particular, a callee can indicate that it prefers contact via a
    particular SIP scheme - SIP or SIPS - by using one of the following
    contact_prefs attribute:

          (sip.schemes=SIP)
          (sip.schemes=SIPS)



> = Section 3.3 =
>
> "Before issuing a Store request to the overlay, any peer SHOULD verify that the AOR of the request is a valid Resource Name with respect to its domain name and the namespaces defined in the overlay configuration document (see Section 3.4)."
>
> Why is this SHOULD rather than MUST?
>

This only concerns the issuer of a request and the rationale behind 
being liberal is that there might be reasons why an issuer cannot 
validate the Resource Name (e.g., does not have resources, or no access 
to a current/consistent overlay configuration etc.). The storing node 
does have the obligation ("MUST") to verify the AOR.

This could be changed, though, but from the perspective of consistency, 
the storing node is the one to take the final responsibility.

> = Section 3.4 =
>
> (1) I note that this documents refers to a different version of the IEEE Posix spec than draft-ietf-p2psip-share. What’s the reason for the difference?
>

This I could not figure. I had several colleagues looking at the case, 
but all see identical Posix refs???

> (2)
> I find the explanation of the expected behavior here hard to follow. I've suggested a re-write below. There also seems to be one case that is not specified, which is when the "enable" attribute is set to false. Text describing what should happen in that case needs to be added.
>

Thanks for the improvement, we replaced the text. Also, there is now a 
definition for the "enable" attribute is set to false:

    If the element is
    included and the "enable" attribute is not set or set to false, the
    overlay MUST only accept AORs that match the domain name of the
    overlay.


> = Section 8.2.3 =
>
> The attack described here seems trivial, and therefore it seems to me that the way SIP usage of RELOAD has been specified here has a gaping hole in it. Basically in any overlay that wants to allow registrations from any domain, the only defense against calls being directed to the wrong recipient is for users to bypass the overlay and do what they would normally do when making a SIP call. Thus in this use case the only thing achieved by using RELOAD is to create a giant vulnerability.
>
> Did the WG consider this? What is the value of standardizing this in this way, given this security issue? If the way that SIP usage was specified was limited to overlays with domain restrictions, at least this attack would be limited to bogus registrations of users within the overlay domain(s).
>

This security issue only arises, if the overlay *and* the enrollment 
service both do not impose restrictions. Normally, at least the 
enrollment server does not issue certificates for any username/AOR. We 
have clarified by referring to authorization at this point.

Actually, this issue comes at no surprise: If we allow anybody to store 
any name, then the system is open to name hijacking. The concept of name 
restrictions and implications was discussed at a WG meeting and was 
considered deployment-dependent. There may be use cases that provide 
protection by other means. However, the default case of this spec is to 
restrict AORs to the current domain name *and* have the enrollment 
server authorize individual names.

Still it is IMO good to be clear to the reader: If you open up the name 
registration, then you may face name hijacking.


> = Section 8.2.4 =
>
> (1)
> By "public" you mean "visible to all nodes in the overlay," correct?
>

Yes - reworded now.

> (2)
> "Methods of providing
>     location and identity privacy are still being studied."
>
> Is this true, specifically for P2PSIP?
>

For P2P overlays, I guess privacy is an active field. This would apply 
to P2PSIP, even if work is not explicitly dedicated to it.

>
> == Nits ==
>
> = Section 1 =
>
> s/The REsource LOcation And Discovery (RELOAD)/REsource LOcation And Discovery (RELOAD)/
>
Thanks, corrected.

> OLD
> Two opposite scenarios of deploying P2P SIP services are in the focus of this document: A highly regulated environment of a "single provider" that admits parties using AORs with domains from controlled namespace(s), only, and an open, multi-party infrastructure that liberally allows a registration and rendezvous for various or any domain namespace.
>
> NEW
> This RELOAD usage may be relevant in a variety of environments, including a highly regulated environment of a "single provider" that admits parties using AORs with domains from controlled namespace(s) only, or an open, multi-party infrastructure that liberally allows a registration and rendezvous for various or any domain namespace.
>

Thanks, replaced.

> = Section 3.1 =
>
> "RELOAD peers MAY store two kinds of SIP mappings”
>
> I don’t think you need the normative MAY there, “can” would work.
>

Thanks, fixed.

> = Section 3.4 =
>
> The second line of the example here needs to use .example as the TLD, not .name. Please make the corresponding changes in the text.
>

Thanks, fixed.

> = Section 5.1 =
>
> s/MUST NOT be used and closed/MUST NOT be used and MUST be closed/
>

Fixed, thanks.

> = Section 6 =
>
> I don't think you need the normative MAY here.
>

Also cleared.

Cheers,
  Thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °