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 <[email protected]> > 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 <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/p2psip >> >> _______________________________________________ >> P2PSIP mailing list >> [email protected] >> 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: +49-40-42875-8452 ° > ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
