Hi Alissa, all,
many thanks for the review and sorry for my late reply. Please see inline
On 15.01.2016 22:58, Alissa Cooper 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.
Regarding the security concerns, please see below.
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).
Previous version had been the state of discussion from a long time ago.
We've updated to follow RFC 3840, which was indeed 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.
This is only a highlighting following a previous discussion on the list,
where clarity was requested on how to distinguish SIP/SIPs. We've made
this more explicit by the following text:
In particular, a callee can indicate that it prefers contact via a
particular SIP scheme - SIP or SIPS - by using one of the following
contact_prefs attribute:
(sip.schemes=SIP)
(sip.schemes=SIPS)
= 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?
This only concerns the issuer of a request and the rationale behind
being liberal is that there might be reasons why an issuer cannot
validate the Resource Name (e.g., does not have resources, or no access
to a current/consistent overlay configuration etc.). The storing node
does have the obligation ("MUST") to verify the AOR.
This could be changed, though, but from the perspective of consistency,
the storing node is the one to take the final responsibility.
= 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?
This I could not figure. I had several colleagues looking at the case,
but all see identical Posix refs???
(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.
Thanks for the improvement, we replaced the text. Also, there is now a
definition for the "enable" attribute is set to false:
If the element is
included and the "enable" attribute is not set or set to false, the
overlay MUST only accept AORs that match the domain name of the
overlay.
= 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).
This security issue only arises, if the overlay *and* the enrollment
service both do not impose restrictions. Normally, at least the
enrollment server does not issue certificates for any username/AOR. We
have clarified by referring to authorization at this point.
Actually, this issue comes at no surprise: If we allow anybody to store
any name, then the system is open to name hijacking. The concept of name
restrictions and implications was discussed at a WG meeting and was
considered deployment-dependent. There may be use cases that provide
protection by other means. However, the default case of this spec is to
restrict AORs to the current domain name *and* have the enrollment
server authorize individual names.
Still it is IMO good to be clear to the reader: If you open up the name
registration, then you may face name hijacking.
= Section 8.2.4 =
(1)
By "public" you mean "visible to all nodes in the overlay," correct?
Yes - reworded now.
(2)
"Methods of providing
location and identity privacy are still being studied."
Is this true, specifically for P2PSIP?
For P2P overlays, I guess privacy is an active field. This would apply
to P2PSIP, even if work is not explicitly dedicated to it.
== Nits ==
= Section 1 =
s/The REsource LOcation And Discovery (RELOAD)/REsource LOcation And Discovery
(RELOAD)/
Thanks, corrected.
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.
Thanks, replaced.
= 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.
Thanks, fixed.
= 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.
Thanks, fixed.
= Section 5.1 =
s/MUST NOT be used and closed/MUST NOT be used and MUST be closed/
Fixed, thanks.
= Section 6 =
I don't think you need the normative MAY here.
Also cleared.
Cheers,
Thomas
--
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
