Subject: [Ecrit] Reviewers of Phone BCP & Framework

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 01 Aug 2007 10:47:45 +0200

I would like to thank

* James Winterbottom
* Richard Barnes
* Alexander Mayrhofer
* Steve Norreys
* Barbara Stark

for their willingness to review the Phone BCP & Framework within the 
next 2 weeks.

Ciao
Hannes

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

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 7 Aug 2007 15:53:41 -0400

For the current draft of phonebcp, my comments were sent to the list on
17 April 2007. I believe these comments are all still relevant, and I
look forward to seeing the proposed changes for making it easier to
determine which requirements apply to which device or entity.

Here are Framework comments that deal with readability, consistency, or
that are editorial. I'll put substantive comments in a separate email.

1. Section 3, initial paragraph: There are many references with extra
parentheses around them. This use of extra parentheses isn't repeated
elsewhere in the doc, and seems unnecessary.

2. Figures 1 and 2, and everything in between. Figure 1 isn't referenced
at all and never described; Figure 2 doesn't appear until 3 pages after
it's referenced, which is confusing. I recommend the following changes:
 - In Figure 1, change "[1]" through "[8]" to be "[M1]" through "[M8]"
to match the message numbering of Figure 2. Delete "[9]".
 - Move Figure 2 to be directly beneath Figure 1.
 - Change first 2 sentences beneath Figure(s) to "Figure 1 shows a
generic ECRIT component topology and Figure 2 shows a generic call
establishment. These include the following:"

3. Section 3, last bullet on p.9: recommend deleting "for in times of
emergencies" because it's bad redundant grammar

4. Section 5.2 Types of Location Information: "jurisdictional" is listed
as a type distinct from "civic" in the initial sentence, but then is
described as a sub-type in the subsequent description. Recommend the
following changes:
 - "There are three primary types of location information: civic
(jurisdictional and postal), geospatial, and ..."
 - In the postal description, replace "to mail a letter to" with "for
mail delivery".
 - In Geospatial description, since "geo" is frequently used after
geospatial is introduced, recommend "Geospatial (geo):" to make it clear
that this is just an abbreviated form.

5. Section 5.5, p. 18, 3rd from last paragraph: The sentence "However,
unless another element ... won't be able to acquire location." is really
hard to read because of its run-on nature. Once I figured it out, I
decided I had a substantive comment, so recommended change is in next
email.

6. Section 5.5, p. 18, 2nd from last paragraph: referenced doc should be
phonebcp and not lost

7. Section 5.5, last sentence of last paragraph: It's not clear why
someone would want to see Section 5.7. Recommend rewording "routing, but
see Section 5.7" to "routing. See Section 5.7 for further discussion on
location updates."

8. Section 5.10: "In some jurisdictions ... Support calls to 9-1-1." is
hard to read and run-on. Recommend "In some jurisdictions, for some
services, support of emergency calls from so-called "uninitialized"
devices is required. For example, cellular providers in the United
States must support calls to 9-1-1 from a mobile phone that does not
have an active service contract."

9. change "may used" to "may be used"

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..."

11. Section 16.3: This section should be titled "LoST Security and
Impersonation" instead of "PSAP Impersonation". Then that immediate
reference to "See Section 16.4" (if you're really after PSAP
impersonation) can be removed. 

Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 7 Aug 2007 16:52:56 -0400

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.

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. 

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."

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? 

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]."

Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Thu, 9 Aug 2007 14:57:55 +0200

Hi,

my comments on the Phone BCP are as follows (Disclaimer: I didn't
re-read the framework document yet, still to do).

- NIT: The "intended status" of the document says "Standards Track",
although is suppose it should become a BCP.

- Terminology: There are a _lot_ of unexplained acronyms in the
document, it would probably be good to add those to the terminology
section. I spotted: SIP, DHCP, LLDP, PSTN, NAT, VPN, LCP (see below),
LLDP-MED, HELD, RELO, URN, SDP, AoR, GRUU, UA, UAC, B2BUA, AP, SRV,
NAPTR, FQDN, RTP, BAUDOT, PKI, ESRP.

- Abstract: Personally, i'd move the first few sentences from the
Abstract to the Introduction, and just keep the "The IETF has several
efforts..." part

- Introduction: The second list (ethernet connected phone): I thought
the phone would aquire initial LoST information right after it boots,
and cache that? I don't find that in the list. Also there (NIT): suggest
to replace "It would determine" by "It determines" - same for the next
bullet (is a bit mixed in the list). Small editorialnit in the last
sentence: missing blank in "[RFC4130]media". I'm missing in the second
list the option that the phone could contact the PSAP directly (but
actually then the PSAP itself would be the next hop, which is covered by
the text). Also in the second list: "Location header" should probably be
"Geolocation header".

- Section 3, small editorial nit: Double full stop at the end of second
sentence.

- Section 4: In some papers from the European commission, they have the
terminology "most appropriate PSAP", which covers the case in which a
endpoint needs to contact a PSAP cabable of TTY service, which might be
different from the "common" PSAP for voice services. So, that
terminology would allow routing based on the desired service, and
actually i think it's a good way to get around the definition what the
"serving PSAP" is. Any comments on this?

- Section 4: In many cases, the location of the caller is not
neccessarily the location of the person in need for help. A lot of PSAPs
here receive calls of the kind "my friend said she's gonna kill
herself", which renders the location of the caller useless for sending
out the responders. This case can obviously not be covered technically,
but i think it deserves a note that the location to send the responder
to can be substantially different from the location of the caller.

- Section 4.1, 2nd paragraph: The first sentence is confusing to me ("..
where it is the access network that..."). Adding "LCP" to the full
"Location Configuration Protocol" would make sense here. 

- The various "placeholders for L7 LCP" could be replaced with HELD, or?
<ducks under table>

- Section 4.2: The requirement on devices to support ALL of DHCP, LLDP,
L7 is rather challenging, i think. There could well be scenarios where
phones would need to support only one of the methods (like, only LLDP
for phones which are only installed together with a matching switch in
enterprise scenarios...). I might have missed most of the discussion
here, but i think that puts quite a burden on the development of smaller
(mobile) devices... Any insight on what led to the conclusion that the
requirement is upon the devices, and not upon the access networks?

The last paragraph is quite confusing to me. I'm especially confused by
the "network attachment". Actually, i don't get that paragraph :-/

- Section 4.3: Saying that a self reported location is "generally
unacceptable" is probably too strong. Its an contradiction to the next
few sentences which say that self reported location might be used to
override the automatic configuration, and also, most of today's mobile
emergency calls in Europe work with that "unacceptable" self reported
location - it's usually the first question a PSAP poses to the caller,
because automatic location delivery is quite uncommon yet. Also, self
reported location (like upon installation of a WLAN AP) will probably be
the only source of location for quite a bit of time (until access
networks are obliged to provide location). And i think that users have
an interest to provide their true location, if they understand that it's
critical in emergency situations...

- 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...

- Section 5: nit: A reference to the section about where to put the
service URN would be good after "Devices MUST use...". Small nit in the
next sentence "is SHOULD performed" -> "SHOULD be performed"?

- 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...

- 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?

- Section 6.1 (and in other places as well): Header names are sometimes
listed with a colon, sometimes without. Would be good to unify this.

- Section 6.2, last bullet: "message is routing is now" is unclear to
me, probably typo.

- Section 6.3: The paragraph about the constraints of simple polygons
could refer to the PDIF-LO-profile draft. 

- 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? 

- Section 6.4: I think that should refer to the respective RFC (3263?)

- 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...

- 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...

- Section 7: Likewise: I think the "location-on-reINVITE" should be
mentioned in the security considerations section - that could be a nice
option for eavesdropper, too, if the implementation does not constrain
this option to PSAPs (which, again, takes me back to the identification
problem)

- Section 9.1: Where should that service URN go? Request URI? Route
Header, with direct PSAP URI? Or whereever it applies according to the
definitions above? 

Security Hole?:

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...

That's all - hope that was useful!

cheers

alex
--
Alexander Mayrhofer 

nic.at Internet Verwaltungs- und BetriebsGmbH
Jakob-Haringer-Strasse 8, A-5020 Salzburg
LG Salzburg, FN 172568b

E: <[email-masked]> W: http://www.nic.at/
T: +43 1 5056416 34, F: +43 1 5056416 934

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Wednesday, August 01, 2007 10:48 AM
> To: ECRIT
> Cc: Winterbottom, James; Richard L. Barnes; Alexander 
> Mayrhofer; [email-masked]; Stark, Barbara
> Subject: Reviewers of Phone BCP & Framework
> 
> I would like to thank
> 
> * James Winterbottom
> * Richard Barnes
> * Alexander Mayrhofer
> * Steve Norreys
> * Barbara Stark
>

---

From: <[email-masked]>
Date: Sun, 12 Aug 2007 14:42:42 -0500

http://www.wi-fiplanet.com/news/article.php/3693221

---

From: "Marc Linsner" <[email-masked]>
Date: Sun, 12 Aug 2007 17:58:57 -0400

Gabor,

Please describe what in this case would become a requirement for 802?  It
obviously worked as is (no additional protocol required) under control of
the network operator.

I'm trying to connect the dots .....

Thanks,

-Marc-

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Sunday, August 12, 2007 3:43 PM
> To: [email-masked]
> Subject: [Ecrit] real life use case for wi-fi unauthenticated access
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 12 Aug 2007 20:14:01 -0500

I interpreted Gabor's (very terse :) ) point as being that this is a
real life example of an Internet access network which has
unauthenticated access but which is able to be used to originate
emergency calls.

I always find discussions about "unauthenticated access" a bit
frustrating because two aspects never seem to be clearly defined and
I've listened to many exchanges going hammer and tongs at apparently
cross-purposes.

1. For Internet telephony, there is a distinction between "access" and
"voice service". One can have (un)authenticated Internet access (per
this muni-WiFi example versus a subscription hotspot) and one can have
(un)authenticated access to the VoIP service (e.g. Vonage, versus direct
routing to the emergency service). In fact all four combinations are
valid use cases. In traditional telephony, authentication for the access
and voice service occurs concurrently as the same function. In fact the
idea of distinguishing between them never really arose for the PSTN
(including cellular).

2. What is important about "unauthenticated access" anyway? Is the
question about *forbidding* unauthenticated access or is it about
*requiring* unauthenticated access? That is - using this example - is
the question about whether a free Muni-WiFi network should be allowed to
be used for emergency calls or is the question really about whether a
commercial Internet access service (e.g. subscription HotSpot) must be
able to be used for free if it's for an emergency call?

Putting it in a 2x2 matrix

               | Auth  |   UnAuth
---------------+-------+----------
Access Service |   ?   |     ?
---------------+-------+----------
Voice Service  |   ?   |     ?

The question marks can be replaced by one of three values - Required,
Forbidden, or Don't Care (R, F, X)

Personally, I would prefer to see X in UnAuth column. "Don't Care"
really means that folk have whatever mechanism available to them that
normal circumstances dictate. That is, unauthenticated access should be
neither required nor forbidden. That is:

               | Auth  |   UnAuth
---------------+-------+----------
Access Service |   R   |     X
---------------+-------+----------
Voice Service  |   R   |     X

If I'm attached to a free WiFi access, then *yes* I can make an
emergency call. If all that's available is a commercial WiFi hotspot,
then they should not be required to provide unauthenticated access for
emergency calls. If I'm able to use the ECRIT model for directly routing
to the PSAP based on the information provided to me by LoST, then *yes*
I should be able make that call. If I need to authenticate with a VoIP
provider before I can use their service, then that provider should still
be allowed to require authentication before I can use them for an
emergency call. The providers of authenticated access and voice services
could choose to provide unauthenticated access for emergency services if
they so desired. I think the complexity of achieving this is what is
causing so much grief in the standards forums - especially for the
access side.

The preceding paragraph is just my opinion. However, per the rest of the
text, I'd still prefer to see some more rigour in the definition about
what the "unauthenticated" discussion actually means. Currently I see
the emergency services constituency coming at this question from a quite
different perspective to the network standards forums (e.g. 3G and IEEE
802) - with the former focussed on the "forbid" and the latter focussed
on the "require" aspect.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Monday, 13 August 2007 7:59 AM
To: [email-masked]; [email-masked]
Subject: RE: [Ecrit] real life use case for wi-fi unauthenticated access

Gabor,

Please describe what in this case would become a requirement for 802?
It
obviously worked as is (no additional protocol required) under control
of
the network operator.

Thanks,

-Marc-

------------------------------------------------------------------------------------------------
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]

---

From: <[email-masked]>
Date: Mon, 13 Aug 2007 00:58:27 -0500

This shows that wi-fi is a good backup/alternative for cellular, when
that is congested or there is no adequate coverage.  Of course, network
access may not be enough to place an ecall, but it is necessary. If
there was a standard for unauthenticated access (for ecall purposes),
then network operator(s) interventions would not be required in these
cases.

- gabor

-----Original Message-----
From: ext Marc Linsner [mailto:[email-masked]] 
Sent: Sunday, August 12, 2007 2:59 PM
To: Bajko Gabor (Nokia-SIR/MtView); [email-masked]
Subject: RE: [Ecrit] real life use case for wi-fi unauthenticated access

Gabor,

Please describe what in this case would become a requirement for 802?
It obviously worked as is (no additional protocol required) under
control of the network operator.

Thanks,

-Marc-