Hi Thomas, Any update?
Thanks, Alissa > On Feb 18, 2016, at 3:40 PM, Alissa Cooper <[email protected]> wrote: > > 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 _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
