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
