Trustworthy Location
draft-ietf-ecrit-trustworthy-location-14

I have no objection to the publication of this document.

---

I'm interested in two scenarios. The first is whether we would ever
reach a position where an emergency call that did not contain
authenticatable location information would be discarded or treated as
less urgent: "90 year-old widow burns to death because she used an old
telephone". The second is whether there is a risk of false negatives 
that might lead the PSAP to mark a call as containing false information
when it is in fact genuine: "Screw-up at high tech call center leads to                              
death of 3 year-old girl".

Perhaps this is covered by Section 4's
   if automated
   location information is understood to be highly suspect, a call taker
   can put more effort into obtaining location information from the
   caller.

Maybe you could make this statement (adding "or absent") in the
Introduction. 

But note that the thrust of the document is that if the location info is
suspect then the whole call is suspect. So perhaps you need to modify 
this text as...

   if automated
   location information is understood to be highly suspect or is absent,
   a call taker can put more effort into verifying the authenticity of 
   the call and to obtaining location information from the caller.

---

A paragraph in the Introduction gives a false impression:

   EENA [EENA] has attempted to define terminology and describe best
   current practices for dealing with false emergency calls, which in
   certain European countries can constitute as much as 70% of all
   emergency calls.  Reducing the number of prank calls represents a
   challenge, since emergency services authorities in most countries are
   required to answer every call (whenever possible).  Where the caller
   cannot be identified, the ability to prosecute is limited.

This leaves the reader believing that 70% of of all emergency calls are
pranks, where the definition of "false" in the referenced document is
quite different. Since the purpose of this work has two prongs 
(correctly locating a real emergency caller, and helping to identify
prank calls - with the possibility of taking additional action) I 
think that the reference to 70% could be reasonably removed.

---

In the Introduction...

   Ideally, a call taker at a Public Service Answering Point (PSAP)
   should be put in the position to assess, in real-time, the level of
   trust that can be placed on the information provided within a call.
   This includes automated location conveyed along with the call and
   location information communicated by the caller, as well as identity
   information about the caller.  Where real-time assessment is not
   possible, it is important to be able to determine the source of the
   call in a post-mortem, so as to be able to enforce accountability.

Can "identity information about the caller" really be determined? Do
you mean "identity of the calling equipment?

Do you really mean "post-mortem"? That sounds a bit dramatic. Maybe
"after the fact".

--

The term PIDF-LO is used before it is expanded in Section 2.1.

---

LSP
Great. Just what we needed. More meanings for the same old acronyms.
Would you consider including a reference to RFC 5513?

---

Shouldn't "Identity Spoofing" appear in Section 1.1?

---

In Section 3
                                    
   This section presents three mechanisms which can be used to convey
   location securely

Is this exactly what you meant to say? "Convey securely" implies to me
"protect against tampering on wire" and possibly "protect against 
snooping". but you are talking about source-signing which is equally
about making the information authenticatable.

I support Stephen's position

1:

I think the word "prank" is incorrect here. A prank is normally done as a joke or to be mildly mischievous or a nuisance. (See the wikipedia entry for "Prank Call".) Instead, "hoax call" is probably the better term, and the one that is used in the EENA document.

I think the reference to "swatting" makes the intro read as hype rather than a serious piece of technical work. It's not referred to elsewhere in the document. It's fine to refer to the EENA document, and mention the types of attacks, but remove the reference "swatting", and the FBI. They're not appropriate for this document. Leave it to the press releases.

   Ideally, a call taker at a PSAP should be put in the position to
   assess, in real-time, the level of trust that can be placed on the
   information provided within a call.
   
Do you mean that the "call taker at a PSAP should *not* be put in the position to..."? (That is, this shouldn't be the responsibility of a human.) Or do you rather mean that the "call taker at a PSAP should be able to..."? Something's weird in the sentence as written.

2.1: Points 2 and 3 aren't end host attacks.

I have a question about Location swapping: So Trudy gets Malory's location information. Then Malory can contact Trudy's PSAP and report an emergency at Trudy's location. But in this case, when the emergency turns out to be false, Trudy gets blamed *and that's right*, because Trudy colluded. Is the concern simply that somehow Malory won't get any of the blame for participating? What's the spoof here?

2.2: I don't understand how bot-net attacks are relevant here. The lack of doing strong authentication makes the system vulnerable to false identity attacks by the end host, but that's not a bot-net attack. If a bot-net attack is relevant here, you had best explain it.

3.1: I presume the bot-net attack described here (still not defined) is that the bots would be used for a DoS of the PSAP itself. But the damage is done with or without location information, isn't it? Or it could be that you're referring to bots set up to make a particular PSAP think that there was a set of calls from the same location (even though no human was on the other end of the line) and therefore increase the likelihood of an actual emergency. But you don't explain how that attack works. Either way, I'm not clear on what you're talking about here.

Henning thanking himself in the acknowledgements is...creepy.

Stephen and Adrian's comments are well-said. Saved me writing more.

- Thanks for adding text in 1.2.1 which is sufficient to
handle the discuss. However, I think you're maybe missing the
punch line at the end of 1.2.1 so I'd suggest maybe something
like "Given the above, SIP UAs in practice provide no privacy
for location information whenever the UA is able to determine
location. This will likely lead to some proportion of users
taking whatever steps are possible to prevent location
information being available to the UAC.  In the end, the
consequence of not honoring the user's wishes within the
network, will be that location will not be available (or will
be spoofed) for some emergency calls." But, I doubt you'd want
to go that far, so I won't insist:-)

(As an aside, I'd be interested in thinking about whether or
not we think the whole geopriv effort has been a success in
privacy terms. I've no idea if there'd be energy for that, 
but it might be a useful bit of navel gazing for the IETF to
do.)

The comment below is from March. It remains valid I 
believe. I don't recall any response to it.

- The title is misleading. I expected to be told how to
do something or how someone had done something but
instead the draft actually discusses pros and cons of
many ways of providing location information for emergency
calls. And no firm conclusion is reached. So I suggest a
tile such as "Issues with Trusting Location" would be a
more appropriate title.