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

[Alissa Cooper <[e-mail]>]

Hi Thomas,

Checking in on this and the -share doc. When do you expect to respond?

Thanks,
Alissa

> On Feb 8, 2016, at 2:52 PM, Thomas C. Schmidt <[e-mail]> wrote:
> 
> Yes, I'll catch up on this asap.
> 
> Cheers,
> Thomas
> 
> On 08.02.2016 23:34, Alissa Cooper wrote:
>> Is anyone in the WG able to respond to these comments and questions?
>> 
>> Thanks,
>> Alissa
>> 
>>> On Jan 15, 2016, at 1:58 PM, Alissa Cooper <[e-mail]> 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.
>>> 
>>> 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).
>>> 
>>> 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.
>>> 
>>> = 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?
>>> 
>>> = 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?
>>> 
>>> (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.
>>> 
>>> OLD
>>> A RELOAD overlay can be configured to accept store requests for any AOR, or to apply domain name restrictions.  For the latter, an enumeration of admissible domain names including wildcarded name patterns of the following form MAY be configured.
>>> 
>>> Example of Domain Patterns: dht\.example\.com .*\.my\.name
>>> 
>>> In this example, any AOR will be accepted that is either of the form <user>@dht.example.com, or ends with the domain "my.name".  When restrictions apply and in the absence of domain patterns, the default behavior is to accept only AORs that exactly match the domain name of the overlay.  Otherwise, i.e., when restrictions are not configured (attribute enable not set), the default behavior is to accept any AOR.  In the absence of a <domain-restrictions> element, implementors SHOULD assume this default value.  Encoding of the domain name complies to the restricted ASCII character set without character escaping as defined in Section 19.1 of [RFC3261].
>>> 
>>> The <domain-restrictions> element serves as a container for zero to multiple <pattern> sub-elements.  A <pattern> element MAY be present if the "enable" attribute of its parent element is set to true.  Each <pattern> element defines a pattern for constructing admissible resource names.  It is of type xsd:string and interpreted as a regular expression according to "POSIX Extended Regular Expression" (see the specifications in [IEEE-Posix]).
>>> 
>>> NEW
>>> A RELOAD overlay can be configured to accept store requests for any AOR, or to apply domain name restrictions.  To apply restrictions, the overlay configuration document needs to contain a <domain-restrictions> element. The <domain-restrictions> element serves as a container for zero to multiple <pattern> sub-elements.  A <pattern> element MAY be present if the "enable" attribute of its parent element is set to true.  Each <pattern> element defines a pattern for constructing admissible resource names.  It is of type xsd:string and interpreted as a regular expression according to "POSIX Extended Regular Expression" (see the specifications in [IEEE-Posix]). Encoding of the domain name complies to the restricted ASCII character set without character escaping as defined in Section 19.1 of [RFC3261].
>>> 
>>> Inclusion of a <domain-restrictions> element in an overlay configuration document is OPTIONAL. If the element is not included, the default behavior is to accept any AOR. If the element is included and the “enable” attribute is not set, the overlay MUST only accept AORs that match the domain name of the overlay. If the element is included and the “enable” attribute is set to true, the overlay MUST only accept AORs that match patterns specified in the <domain-restrictions> element.
>>> 
>>> Example of Domain Patterns: dht\.example\.com .*\.my\.name
>>> 
>>> In this example, any AOR will be accepted that is either of the form <user>@dht.example.com, or ends with the domain "my.name".
>>> 
>>> = 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).
>>> 
>>> = Section 8.2.4 =
>>> 
>>> (1)
>>> By "public" you mean "visible to all nodes in the overlay," correct?
>>> 
>>> (2)
>>> "Methods of providing
>>>   location and identity privacy are still being studied."
>>> 
>>> Is this true, specifically for P2PSIP?
>>> 
>>> 
>>> == Nits ==
>>> 
>>> = Section 1 =
>>> 
>>> s/The REsource LOcation And Discovery (RELOAD)/REsource LOcation And Discovery (RELOAD)/
>>> 
>>> 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.
>>> 
>>> = 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.
>>> 
>>> = 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.
>>> 
>>> = Section 5.1 =
>>> 
>>> s/MUST NOT be used and closed/MUST NOT be used and MUST be closed/
>>> 
>>> = Section 6 =
>>> 
>>> I don't think you need the normative MAY here.
>>> 
>>> _______________________________________________
>>> P2PSIP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/p2psip
>> 
>> _______________________________________________
>> P2PSIP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/p2psip
>> 
> 
> -- 
> 
> 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] °
> 
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/p2psip