From: Henning Schulzrinne <hgs at cs.columbia.edu>
Date: October 28, 2008 5:30:39 PM EDT
To: Hannes Tschofenig <Hannes.Tschofenig at gmx.net>
Cc: Gábor Bajkó <Gabor.Bajko at nokia.com>, Stephen McCann <stephen.mccann at roke.co.uk
>
Subject: Comments on draft-schulzrinne-ecrit-unauthenticated-
access-03 - Section 1
I think the current terminology is really confusing, as it
commingles access authorization and VSP authorization, which have
rather different consequences. Thus, if this is the WiMax
terminology, I think they are just wrong and we shouldn't propagate
their confusing terminology.
I'm not sure about my attempt below, so I'd appreciate comments. In
particular, there might be a better name instead of ZBP.
---
Second paragraph and following:
Roughly speaking, the IETF emergency services architecture [bcp]
divides responsibility for handling emergency calls between the
access network (ISP), the VoIP service provider (VSP) and the
provider of emergency signaling services, the emergency service
network (ESN). The access network may provide location information
to end systems, but does not have to provide any VoIP signaling
functionality. The emergency caller can reach the ESN either
directly or through the VoIP provider's outbound proxy. Any of the
three parties can provide the mapping from location to PSAP URI by
offering LoST [RFC] services.
In general, a set of automated configuration mechanisms allows a
device to function in a variety of architectures, without the user
being aware of the details on who provides location, mapping
services or call routing services. However, if emergency calling is
to be supported when the calling device lacks access network
authorization or does not have a VoIP provider, one or more of the
providers may need to provide additional services and functions.
In all cases, the end device MUST be able to perform a LoST lookup
and otherwise conduct the emergency call in the same manner as when
the three exceptional conditions discussed below do not apply.
We distinguish between three conditions:
(1) No access authorization (NAA): The current access network
requires access authorization and the caller does not have valid
user credentials. (This includes the case where the access network
allows pay-per-use, as is common for wireless hotspots, but there is
insufficient time to pay for access.)
(2) No VoIP provider (NVP): The caller does not have a VoIP service
provider (VSP) at the time of the call.
(3) Zero-balance VoIP provider (ZBP): The caller has valid
credentials with a VSP, but is not allowed to place calls, e.g.,
because the user has a zero balance in a prepaid account.
A user may well suffer from both NAA and NVP or ZBP at the same
time. Depending on local policy and regulations, it may not be
possible to place emergency calls in the NAA case. Unless local
regulations require user identification, it should always be
possible to place calls in the NVP case, with minimal impact on the
ISP. Unless the ESN requires that all calls traverse a known set of
VSPs, a caller should be able to place an emergency call in the ZBP
case. We discuss each case in separate sections below.
----
<section>No Access Authorization (NAA)
In the NAA (No Access Authorization) case, the emergency caller does
not posses valid credentials for the access network. If local
regulations or policy allows or require, the access network may or
needs to cooperate in providing emergency calling services.
Generally, the ISP will want to ensure that devices do not pretend
to place emergency calls, but then abuse the access for obtaining
more general services fraudulently.
In particular, the ISP MUST allow emergency callers to acquire an IP
address and to reach a LoST server, either provided by the ISP or
some third party. It SHOULD also provide location information via
one of the mechanisms specified in [bcp] without requiring
authorization unless it can safely assume that all nodes in the
access network can determine their own location, e.g., via GPS.
The details of how filtering is performed depends on the details of
the ISP architecture and are beyond the scope of this document. We
illustrate a possible model. If the ISP runs its own LoST server, it
would maintain an access control list including all IP addresses
contained in responses returned by the LoST server, as well as the
LoST server itself. (It may need to translate the domain names
returned to IP addresses and hope that the resolution captures all
possible DNS responses.) Since the media destination addresses are
not predictable, the ISP also has to provide a SIP outbound proxy so
that it can determine the media addresses and add those to the
filter list.
<section>No VoIP Service Provider (NVP)
In the second case, the emergency caller has no current VoIP service
provider (VSP). This case poses no particular difficulties unless it
is assumed that only VSPs provide LoST server or that ESNs only
accept calls that reach it through a set of known VSPs. However,
since the calling device cannot obtain configuration information
from its VSP, the ISP MUST provide the address of a LoST server via
DHCP [rfc] if this model is to be supported. The LoST server may be
operated either by the ISP or a third party.
<section>Zero-Balance VoIP Service Provider (ZBP)
In the case of zero-balance VoIP service provider, the VSP can
authenticate the caller, but the caller is not authorized to place
regular VoIP calls, e.g., because the contract has expired or the
prepaid account for the customer has been depleted. Naturally, a VSP
can simply disallow access by such customers, so that all such
customers find themselves in the NVP situation described above. If
VSPs desire or are required by regulation to provide emergency
calling services to such customers, they need to provide LoST
services to such customers and may need to provide outbound SIP
proxy services. As usual, the calling device looks up the LoST
server via SIP configuration.
Unless the emergency call traverses a PSTN gateway or the VSP
charges for IP-to-IP calls, there is little potential for fraud. If
the VSP also operates the LoST server, the outbound proxy MAY
restrict outbound calls to the SIP URIs returned by the LoST server.
It is NOT RECOMMENDED to rely on a fixed list of SIP URIs, as that
list may change.
---
Henning