Subject: [Ecrit] RE: review of phone-bcp (was: Reviewers of Phone BCP & Framework)

From: "Brian Rosen" <[email-masked]>
Date: Wed, 19 Sep 2007 17:06:03 -0400

Alexander

I'm finishing an update to -framework and -phonebcp today and I resolved
most of the comments you provided except as noted below:

> - Section 5: The "one-button" thing: How broad is that opinion of PSAPs?
> I'm just curious whether that is the opinion of a few, or the vast
> majority of PSAP operators agrees on that...
This is a very widely held view.  It used to be common to have a one button
emergency call on early mobiles.  The incidence of false calls was very
high, and the emergency authorities prevailed on the mobile operators to get
rid of that feature.  If it takes a sequence, it's okay, but one button is
very bad.  I don't know any PSAP person who is in favor of one button
emergency call features.

> 
> - Section 5: "Home dialstring": I think keeping the home dial string
> poses quite some problems, because they are merged into the local dial
> plan of the country/region visited. For example, Vienna has a full
> 7-digit number block under "911xxxx". From a phone visiting from the US,
> any call to any of those 10000 actual numbers would make the user
> unwittingly place an emergency call, given that the phone also imports
> the local dial plan... (and i suppose it would be much worse with
> numbers starting with "112" in the US?) People are used from mobile
> networks that their "home" dialstring for emergency calls is
> unavailable, so i don't think it's worth to invent new behaviour for IP
> phones...
The document says home dial string is a MAY, local is a MUST.  It's usually
easier to integrate the home number in a dial plan, because the plan is
usually determined from the home calling system.  The counter argument to
the one you are making is that the visitor is much more likely to know his
home emergency dial string than he is to know the local one, and when people
are stressed, they often do the "wrong" thing.

> 
> - Section 6.1: bullet 1) This essentially puts an requirement for
> support of TLS and sips on every device able to place emergency calls.
> Is that intended, and if yes, is that even possible in a BCP?
Yes, it is intended.  It's because the call carries location.  The BCP does
say "Try TLS, but if it fails, retry without it".

> 
> - Section 6.3: Are there any requirements on a proxy if it detects a
> "direct" PSAP call (PSAP URI in the Request line), with the service URN
> only in the Route: header?
No, it would be treated as a normal call.  It may route correctly, but we
can't guarantee that.  I don't understand how you could get the service URN
in a Route header unless you had a bad implementation.

> 
> - Section 6.5: I'm really unsure about the requirement of not allowing
> the user to send a BYE. Wouldn't that violate the SIP specs? Especially
> the "PSAP gets called again" part really should be coordinated with
> PSAPs on a broad basis - that sounds really scary to me... The user who
> has placed an emergency call by accident will try to hangup again, then
> the phone rings again, the user tries to hang up again, and so on... In
> the end, he has probably put a nice DoS attack on the PSAP, because 12
> agents are trying to figure why this guy repeatedly calls the PSAP....
> in almost none of the cases, he will reach the same agent...
PSAPs have big problems with "abandoned calls".  They really would prefer
that you tell them you made a mistake.  In most jurisdictions, the PSAP will
call back when it receives an abandoned call, and in some, it will dispatch
a police officer if it can't talk to the caller.

In the example you raised, there is only one call, and one call taker.  The
call stays up through the repeated hang up, pick up cycles.

The only time there would be multiple calls would be if he calls, the PSAP
releases the call, and he calls again.  This would not invoke the mechanism
discussed.  The mechanism says: don't send a BYE, keep the session active.
Signal an alert to the user, and when he picks up, he is still on the
original call.

> 
> - Section 6.6 should say that those features are to be disabled only
> while a emergency call is in progress... Disabling features on inbound
> call poses an interesting challenge: How does the UA identify such
> calls? It would be very tempting for SPITters to fake being a PSAP, and
> disable all kind of anti-spit measures on the phone, probably even the
> option to hang up the SPIT call...
I fixed the wording to clarify.  There is also text on how to determine
which call is a PSAP call.  Basically its only detected after a successfully
outbound emergency call, it has to be from the domain that answered the
call, and it has to occur within some short time period after the original
call was completed.  There is text that warns about it being a problem.
> 
> Returning a dereferenced location in such test calls could provide a
> nice way to use the PSAP as a man-in-the-middle for inappropriate access
> to location information - simply put the location URI of another user in
> the Request, and use that test mechanism to let the PSAP dereference the
> location URI on behalf of the attacker? Smells like a BIG security hole
> to me, especially since the PSAP probably has no way to identify which
> location URI belongs to which user (only the service provider would be
> able to do that). I think that should definitely be addressed in the
> Security Considerations section...
The security of the reference is the same as the security of the value.
Having the reference has to be assumed to be the same as having the value.
You don't know for whom the LIS will dereference.  There is new text about
location hiding for the test.

Brian

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 19 Sep 2007 17:06:23 -0400

Thank you for your review.  There is an update of both -framework and
-phonebcp coming out today.  

> Section 5.3, 3rd paragraph: The sentence "All location objects MUST be
> delivered to the PSAP" suggests that a device needs to send all LO's
> that it has, even the manual one(s), which doesn't seem consistent with
> LoST section 11.1 items 3 ("a client SHOULD NOT send multiple <location>
> profiles derived from different baseline profiles")and 6 ("A server uses
> the first-listed location profile that it understands and ignores the
> others"). Or is the sentence trying to say that "All location objects
> that a device and other intermediate proxies include in a message MUST
> be delivered to the PSAP"? That would be ok. But I really want to make
> sure the device is allowed to decide which one location to send, if it
> has several.
Please have a look at the text now.  There is even a section called
"Multiple locations".  I think it's now clear that:
1. If you get multiple locations, you pass all of them on
2. If you get one or more locations from the UA, you can add one or more
than one, but you route on one of the ones you got from the UA.
3. No matter who routes, they pick one to route on, and mark it.

> 
> Section 5.5, DHCP: After reading this, I'm confused as to whether a
> device should use REQUEST or INFORM when it uses means other than DHCP
> for getting its IP address. RFC2131 says DHCPINFORM is for "asking only
> for local configuration parameters" where the "client already has
> externally configured network address". The DHCPREQUEST message seems to
> require the server to do all sorts of checking of IP addresses and
> leases and such, so that it doesn't really seem appropriate when the
> device got its address through other means. I'm happy to be better
> educated on this topic, though.
Probably needs some more investigation and work.  Anyone else care to
comment?

> 
> Section 5.5, 3rd from last paragraph: It is not necessary for a device
> to support a phonebcp-list protocol towards the WAN if it does a
> proprietary protocol to its LAN. The location could be manually
> configured. I would expect such manual configuration in corporate campus
> environments like the one I'm in. The buildings in this corporate campus
> are served by a private intranet. Although I'm in Atlanta, the
> Internet-facing server is in Birmingham. Therefore, it would be the
> corporation's responsibility to manually configure locations in
> routers/servers, as appropriate. I would recommend deleting the sentence
> "However, unless another element ... won't be able to acquire its
> location."
I deleted all of the text that talks about private mechanisms.  It now just
has the list and devices do all, networks do one.  I think you can't get
away with static configuring.  The number of situations where you have
things like laptops with softclients or IM clients roaming into these
networks is way too high.  You need an LCP.  May I recommend DHCP or LLDP
for your campus?

> 
> Section 6, Type of Emergency Service: "We support this mechanism by
> optionally labeling calls with a service identifier" -- I thought that
> labeling with a service identifier was mandatory, but that the use of
> more specific (than just "sos") was optional. Am I wrong?
I think you are right.  There are a bunch of changes in the text now.  Let
me know if I have made it clear now or not.

> 
> Section 10, disabling of call features: Since I have comments against
> some of this text in phonebcp, I would prefer if this list of what must
> and should be disabled is in one place only. So, I'd prefer if this said
> simply  "While in a call, a number of other call features need to be
> disabled. This is discussed in [phonebcp]."
I fixed this.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 19 Sep 2007 17:06:29 -0400

I fixed all of these but:

> 10. Section 9, first sentence "The call-taker must be able..." . Since
> some jurisdictions allow calls from uninitialized devices, I don't think
> it can be said that this is truly "must". Perhaps "It is highly
> desirable for the call-taker to be able to reach..."
I did a lot of rework on this text.  Take a look at both framework and
phonebcp updates coming today and let me know if I have satisfied you on
this item.

Brian

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 19 Sep 2007 23:31:47 +0200

Brian, Alexander,
 
>are stressed, they often do the "wrong" thing.

I know about the requirements about the local dial string, but
I see serious problem here coming up (and not only for
emegency numbers, but for all local non-E.164 numbers)
 
In existing mobile systems all UE use the dial plan
of the visited network. Home numbers may be accessed
in some cases with CAMEL.
 
In SIP and especially in IMS the
UE is always talking directly to the home network, so it
always uses the home dialing plan. The only way to access
local non-E.164 numbers would be a P-CSCF in the visited
network (in release 8 and beyond), which may filter out certain
numbers, but these would then be not available for dialing
in the home dialing plan e.g if you are in the US you may not be 
able to dial 911xxx. One may use prefixes for this, but none
are defined yet.
 
IMO this problem is not resolved yet
 
Richard