Draft: draft-ietf-sip-location-conveyance-07
Reviewer: Richard Barnes
Review Date: 13 Mar 07
Security / Privacy Concerns:
------------------------------------------------------------------------
1. In the first full paragraph of Section says that if an emergency call
using TLS fails to complete, it MUST be retried without TLS. I don't
think it's the place of the spec to mandate UA behavior in this case; it
should be up to the user to define their urgency/privacy trade-off.
2. In general most of section 6 is either out of scope or true in all
contexts (not just emergency services). The only exceptions I note are
the explanatory text at the beginning and the requirement that S/MIME
MUST NOT be used in emergency cases.
3. Saying that S/MIME MUST NOT be used for emergency calls rules out
that security mechanism when UA itself has queried a LoST server and
contacts a PSAP directly. Is this intentional?
4. In Section 6, in the second to the last paragraph, it basically says
for an emergency call certain policy flags "SHOULD" be set to "yes" and
that if those flags are set to "no" or are not present then they may be
ignored. A GEOPRIV "using protocol" shouldn't dictate that certain
policy flags be ignored for "emergency calls" -- especially since
emergency call marking is still poorly specified.
5. On the other hand, if you're going to allow certain policy flags to
be ignored, then shouldn't setting them to "yes" be a "MUST"? When
would an entity legitimately set the policy flags to "no" in a situation
where intermediate entities are allowed to ignore "no" values for these
flags?
6. The draft's stance on multiple locations seems to take an absolutist
stance on multiple locations. In particular, Section 3.4.6 allows for
multiple locations to cause a call to fail (which seems dangerous to
me). This seems dangerous in an emergency context.
General Comments:
------------------------------------------------------------------------
1. The draft says several times that proxies cannot insert LbyV because
they can't modify bodies. That seems like a small reason to remove a
potentially important use case, and it seems to contradict the fact that
the ABNF in section 3.2 allows for the use of "data:" URIs.
2. More generally, the looseness of the criteria for allowable URIs
could also allow for URIs that convey LI outside of a PIDF-LO, either by
reference or by value (e.g., the "geo:" URI defined in
draft-mayrhofer-geo-uri). Perhaps this could be restricted to the usage
"sip:", "sips:", and "pres:" defined by this document, plus any specific
LbyR protocols later defined.
3. Likewise, I don't see anything that says that the body part indicated
by a "cid:" URI or returned by a reference MUST be a PIDF-LO (although
this is said throughout).
4. Several times, the draft says that it's only describing a "push", but
there are at least two places it defines mechanisms for "pull": The
inclusion of the "geolocation" option tag in a Require header, and the
description of the usage of SIP as a dereferencing protocol.
5. The routing-query-allowed element for PIDF-LO is never defined. This
definition would be a better place for a lot of the discussion in
section 5.3 (just in the introduction, not subordinate bullets).
6. Several times, the document assumes that content protected with
S/MIME is encrypted, when it could be signed, but otherwise readable.
In most cases where use of S/MIME for encryption causes problems, use of
S/MIME for signing only doesn't, and these cases should be noted.
7. Several sections start out by talking about how sensitive location
information is. This repetition should be removed.
Localized Comments and Nits:
------------------------------------------------------------------------
Section 1, paragraph starting "The Geolocation header is introduced..."
This paragraph should be broken into multiple sentences.
Section 3.1, paragraph starting "This document creates..."
Missing closing parenthesis after "[RFC2392]".
Section 3.1, paragraph starting "If a SIP message is routed..."
The requirement that header parameters SHOULD NOT be deleted seems like
it should be a MUST NOT. What's the case where a parameter SHOULD be
deleted?
Section 3.2, paragraph with ABNF
Since the Geolocation header can hold multiple values, should messages
be forbidden to have multiple Geolocation headers?
Also, this specification is very permissive about what URIs may be
inserted. Perhaps it should be restricted to SIP, SIPS, PRES, and CID
for now, with a provision for adding more in the future.
Section 3.2, paragraph starting "The cid-url is defined..."
The meaning of the sentence "This URI MUST be present if location is
by-value in a message" needs to be re-worded or deleted. As I read it,
it would imply that if a message has a PIDF-LO body part (for any
reason), and a Geolocation header, than that header must have a CID URI
pointing to that body part.
Section 3.2, paragraph starting "Use of the header..."
Use of the header in BYE is stated to be both allowed and undefined.
Section 3.2, paragraph starting "The Geolocation header MAY be..."
A Geolocation header added by a proxy could specify LbyV, e.g., if it
contained a "data:" URI.
Section 3.3, paragraph starting "The UAC can use whatever means..."
Need an article before "SIP Intermediary".
Section 3.4, paragraph starting "To illustrate this..."
Replace "would be in here" with "is"
Section 3.4.1, paragraph starting "A Warning header ..."
You refer to data-URLs here; it would be useful to have an Informative
reference to RFC 2397.
Section 3.4.6
Allowing this response code would seem to encourage UASs to reject calls
with multiple locations. This is obviously dangerous in an emergency
setting. Also, it seems odd to include this in a 424 message that goes
back to the UAC, since there may not be anything he can do about it
(e.g., if a proxy is adding conflicting location information).
Section 3.5, paragraph starting "A UAC SHOULD NOT include..."
Need to define what the semantic would be when included. Is it
requesting that a proxy insert a Geolocation header?
Section 5, paragraph starting "Because a person's location..."
Location in general is considered sensitive (not just people), and the
protocol is designed to describe more than people.
Section 5, paragraph starting "A PIDF includes identity information..."
I don't really see the value of anonymizing the location in this case,
since it's already contained in a SIP message that has identifying
information.
Section 5, paragraph starting "Self-signed certificates..."
This paragraph is out of scope. It's general PIDF/GEOPRIV concern.
Section 5.3, paragraph starting "Proxies that perform..."
Need some text before the colon at the end of the paragraph, e.g.,
"fields in a PIDF-LO document". With regard to the table, would it be
simpler just to say that the routing-query-allowed attribute supercedes
the retransmission-allowed element?
Section 6, bullet number 2
Remove "s/he", reword.
Section 6, paragraph starting "While many jurisdictions..."
This should say that many jurisdictions "require" a user to reveal a
location. It seems out of scope to mandate the configurability of
positioning mechanisms.
Section 7, paragraph starting "Transmitting location information..."
Remove the word "Transmitting". Remove the word "tracking" from
"eavesdropping, tracking, and alteration". Replace "any protocol
wishing to be considered a GEOPRIV \"using protocol\"" with "a GEOPRIV
using protocol". Changes "transport protocol meetings" to "transport
protocol meets". I would remove the quotes from RFC 3693, and just cite
the requirement numbers.
Section 8, paragraph starting "Conveyance of physical location..."
Insert "the" before "physical location" in the first sentence. In the
second sentence, change "session set-up" to "SIP request" and strike
"initiating the session or SIP MESSAGE". Also in the second sentence,
it should be made clear that only location-based routing is only screwed
up by S/MIME encryption, not other protections. In the third sentence,
I would add "(except by proxies)" after "eavesdropping and modification".
Section 8, paragraph starting "When the UAC is the source ..."
Change the beginning of the first sentence to "When location is inserted
by a UAC". What, exactly is being RECOMMENDED here? Should that clause
be struck?
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
