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
