Subject: [Sip] Review of draft-ietf-sip-location-conveyance

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Apr 2007 11:55:28 -0400

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 15 Apr 2007 19:27:16 -0500

Much of what Richard says I think is okay.

But please, please, please don't re-open the can of worms concerning the
reference restriction in the ABNF. This issue has been battled to death
and I think that the document clearly describes the outcome on which
consensus was reached. The text will provide restrictions but the ABNF
will not.

Cheers
James

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Saturday, 14 April 2007 1:55 AM
> To: [email-masked]
> Subject: [Sip] Review of draft-ietf-sip-location-conveyance
> 
> by a UAC".  What, exactly is being RECOMMENDED here?  Should that
clause

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]