Subject: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 8 Nov 2009 10:23:56 -0500

Begin forwarded message:

> From: Henning Schulzrinne <[email-masked]>
> Date: October 28, 2008 5:30:39 PM EDT
> To: Hannes Tschofenig <[email-masked]>
> Cc: Gábor Bajkó <[email-masked]>, Stephen McCann <[email-masked] 
> >
> 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
>
>
>
>
>
>
>
>
>
>

---

From: [email-masked]
Date: Mon, 9 Nov 2009 11:49:02 +0900

> more general services fraudulently.

As the Network Ops guy in my previous job, I have to admit that I have 
great difficulty understanding the NNA issue.

In the UK it's very likely that access networks will be required (by 
regulation) to assist with emergency calls, but there's _no_ way that this 
regulation will ever apply to users that are unknown to the ISP.

We offered ADSL services and _fixed_ wireless access.  On neither of these 
networks would it have been practical to support unauthenticated users.

Your "pay-per-use" public WiFi (or 802.16e mobile WiMax) example is in 
fact the only technology I can think of where this could usefully apply. 
In particular this is because commonly-used WiFi access control systems 
need full IP connectivity, even if it's just into a walled garden.  Most 
other technologies authenticate at lower layers than that - think PPP, or 
similar.

I believe that more explanation is necessary of exactly what sorts of ISP 
and access network technologies you believe might be covered by this 
requirement.

Ray

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 8 Nov 2009 22:27:28 -0500

I agree that this requires L2 cooperation in many cases. There is a  
separate discussion on the L2 case that will apparently take place in  
ECRIT, with EAP as one main topic of discussion.

Henning

On Nov 8, 2009, at 9:49 PM, [email-masked] wrote:

> As the Network Ops guy in my previous job, I have to admit that I  
> have great difficulty understanding the NNA issue.
>
> regulation) to assist with emergency calls, but there's _no_ way  
> that this regulation will ever apply to users that are unknown to  
> the ISP.
>
> We offered ADSL services and _fixed_ wireless access.  On neither of  
> these networks would it have been practical to support  
> unauthenticated users.
>
> Your "pay-per-use" public WiFi (or 802.16e mobile WiMax) example is  
> in fact the only technology I can think of where this could usefully  
> apply.  In particular this is because commonly-used WiFi access  
> control systems need full IP connectivity, even if it's just into a  
> walled garden.  Most other technologies authenticate at lower layers  
> than that - think PPP, or similar.
>
> I believe that more explanation is necessary of exactly what sorts  
> of ISP and access network technologies you believe might be covered  
> by this requirement.
>
> Ray

---

From: [email-masked]
Date: Mon, 9 Nov 2009 13:10:12 +0900

> ECRIT, with EAP as one main topic of discussion.

I think that misses my point.

Where an access network _already_ uses the full IP stack to authenticate 
customers (using a web portal for example) then unauthenticated access is 
relatively easy.   Such networks already satisfy the requirement to give 
out a Layer 3 IP address to any client regardless of their layer 1 or 2 
connectivity or identifiers.

However if the authentication happens at much lower levels then (IMHO) it 
will be _very_ difficult to support unauthenticated access.

Ray

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 8 Nov 2009 20:46:32 -0800

Ray Bellis said:

"However if the authentication happens at much lower levels then (IMHO) it
will be _very_ difficult to support unauthenticated access. "

Why?   Existing authentication mechanisms (such as EAP-TLS, described in RFC
5216) already support client unauthenticated access.  All that is necessary
is for the client to send an emergency NAI to signal the need for emergency
access.  The server will still send its certificate which the client should
verify.  The server can either not request the client certificate based on
the emergency NAI, or it can ask for it, but the client will not supply it
and the server needs to then conclude the authentication by placing the
client on an emergency VLAN.

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 9 Nov 2009 12:58:49 +0800

And, of course, having granted the device "emergency only access", the only services the network needs to permit the device access to are the LIS, LoST, and the PSAP URI applicable to the point of connect.

Unless of course you're also going to let it go off to some arbitrary third party VSP that has no relationship with the network just so that VSP can proxy the emergency call. Then you've bought yourself a whole world of pain and uncertainty...

Cheers,
Martin

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Monday, 9 November 2009 3:47 PM
To: [email-masked]; 'Henning Schulzrinne'
Cc: 'ECRIT'
Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1

Ray Bellis said:

"However if the authentication happens at much lower levels then (IMHO) it will be _very_ difficult to support unauthenticated access. "

Why?   Existing authentication mechanisms (such as EAP-TLS, described in RFC 5216) already support client unauthenticated access.  All that is necessary is for the client to send an emergency NAI to signal the need for emergency access.  The server will still send its certificate which the client should verify.  The server can either not request the client certificate based on the emergency NAI, or it can ask for it, but the client will not supply it and the server needs to then conclude the authentication by placing the client on an emergency VLAN.

---

From: [email-masked]
Date: Mon, 9 Nov 2009 14:03:00 +0900

> Why?   Existing authentication mechanisms (such as EAP-TLS, 
> described in RFC 5216) already support client unauthenticated 
> access.  All that is necessary is for the client to send an 
> emergency NAI to signal the need for emergency access.  The server 
> will still send its certificate which the client should verify.  The
> server can either not request the client certificate based on the 
> emergency NAI, or it can ask for it, but the client will not supply 
> it and the server needs to then conclude the authentication by 
> placing the client on an emergency VLAN. 

That's fine _if_ your network supports such a mechanism.

None of the network technologies I ever ran did.

All I'm saying is the draft needs to be much clearer (IMHO) about what 
sorts of access network technologies _might_ be able to support this.

Ray

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 9 Nov 2009 06:31:39 +0100

Ray, 
 
what you are saying in your earlier e-mail is true for the UK, but not
for other countries. Currently there is support for 'SIM-less' calls in
cellular networks (enabled based on a per-country policy). You need to
support this in some regions like North-America. I would say that
obvious candidates include wireless access in regulated spectrum.
For fixed-line, this is not a big deal as usually there is no
'unauthenticated' case.
 
Dirk

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext [email-masked]
	Sent: Monday, November 09, 2009 6:03 AM
	To: Bernard Aboba
	Cc: 'ECRIT'
	Subject: Re: [Ecrit] Fwd: Comments on
draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1

	

	All I'm saying is the draft needs to be much clearer (IMHO)
about what sorts of access network technologies _might_ be able to
support this. 
	
	Ray

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 9 Nov 2009 06:40:12 +0100

right, this is described as one of the possible options in the new
section 6 in the unauthenticated draft. It probably needs some
refinement, so please take a look and let us know what should be added
or modified.
 
Dirk

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Bernard Aboba
	Sent: Monday, November 09, 2009 5:47 AM
	To: [email-masked]; 'Henning Schulzrinne'
	Cc: 'ECRIT'
	Subject: Re: [Ecrit] Fwd: Commentson
draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1

	Ray Bellis said:

	"However if the authentication happens at much lower levels then
(IMHO) it will be _very_ difficult to support unauthenticated access. "

	Why?   Existing authentication mechanisms (such as EAP-TLS,
described in RFC 5216) already support client unauthenticated access.
All that is necessary is for the client to send an emergency NAI to
signal the need for emergency access.  The server will still send its
certificate which the client should verify.  The server can either not
request the client certificate based on the emergency NAI, or it can ask
for it, but the client will not supply it and the server needs to then
conclude the authentication by placing the client on an emergency VLAN.

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 9 Nov 2009 13:52:38 +0800

Just to be clear, we are talking about unauthenticated to the access network. Right?

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kroeselberg, Dirk (NSN - DE/Munich)
Sent: Monday, 9 November 2009 4:32 PM
To: [email-masked]; Bernard Aboba
Cc: ECRIT
Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1

Ray,

what you are saying in your earlier e-mail is true for the UK, but not for other countries. Currently there is support for 'SIM-less' calls in cellular networks (enabled based on a per-country policy). You need to support this in some regions like North-America. I would say that obvious candidates include wireless access in regulated spectrum.
For fixed-line, this is not a big deal as usually there is no 'unauthenticated' case.

Dirk

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Monday, November 09, 2009 6:03 AM
To: Bernard Aboba
Cc: 'ECRIT'
Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1

All I'm saying is the draft needs to be much clearer (IMHO) about what sorts of access network technologies _might_ be able to support this.

Ray

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 9 Nov 2009 07:47:43 +0100

yes (at least for my part).
 
Dirk

	From: ext Winterbottom, James
[mailto:[email-masked]] 
	Sent: Monday, November 09, 2009 6:53 AM
	To: Kroeselberg, Dirk (NSN - DE/Munich);
[email-masked]; Bernard Aboba
	Cc: ECRIT
	Subject: RE: [Ecrit] Fwd: Comments
ondraft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1

	Just to be clear, we are talking about unauthenticated to the
access network. Right?

Behalf Of Kroeselberg, Dirk (NSN - DE/Munich)

	Ray, 

	what you are saying in your earlier e-mail is true for the UK,
but not for other countries. Currently there is support for 'SIM-less'
calls in cellular networks (enabled based on a per-country policy). You
need to support this in some regions like North-America. I would say
that obvious candidates include wireless access in regulated spectrum.

	Dirk

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext
[email-masked]
		Sent: Monday, November 09, 2009 6:03 AM
		To: Bernard Aboba
		Cc: 'ECRIT'
		Subject: Re: [Ecrit] Fwd: Comments on
draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1

		
		All I'm saying is the draft needs to be much clearer
(IMHO) about what sorts of access network technologies _might_ be able
to support this. 
		
		Ray

---

From: Marc Linsner <[email-masked]>
Date: Mon, 09 Nov 2009 08:15:35 -0500

Dirk,

Are there regulations that call for unauthenticated clients to have
emergency access in the Internet realm?  Or is this an assumption of
something in the future?

-Marc-

On 11/9/09 12:31 AM, "Kroeselberg, Dirk (NSN - DE/Munich)"
<[email-masked]> wrote:

> Ray, 
>  
> what you are saying in your earlier e-mail is true for the UK, but not for
> other countries. Currently there is support for 'SIM-less' calls in cellular
> networks (enabled based on a per-country policy). You need to support this in
> some regions like North-America. I would say that obvious candidates include
> wireless access in regulated spectrum.
>> All  I'm saying is the draft needs to be much clearer (IMHO) about what sorts
>> of  access network technologies _might_ be able to support this.
>> 
>> Ray 
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 9 Nov 2009 08:27:18 -0500

Given that there are currently likely no regulations for Internet  
emergency calling (beyond the "must provide equivalent service ones"),  
I suspect that asking this question is not too helpful. I would  
consider this anticipating and exploring the issue - namely, whether  
it is feasible to do this if so desired. We have the moral equivalent,  
such as US landlines that have been shut off for non-payment, but can  
still be used to place emergency calls, in addition to payphones that  
provide free emergency calls.

If I were a hotel or airport operator, I'd want to provide such  
functionality - after all, I'd kind of like the local fire and police  
department to know about the smoke or suspicious package that a  
visitor is seeing.

Henning

On Nov 9, 2009, at 8:15 AM, Marc Linsner wrote:

> On 11/9/09 12:31 AM, "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked] 
> > wrote:
>
>> Ray,
>>
>> what you are saying in your earlier e-mail is true for the UK, but  
>> not for other countries. Currently there is support for 'SIM-less'  
>> calls in cellular networks (enabled based on a per-country policy).  
>> You need to support this in some regions like North-America. I  
>> would say that obvious candidates include wireless access in  
>> regulated spectrum.
>>> All  I'm saying is the draft needs to be much clearer (IMHO) about  
>>> what sorts of  access network technologies _might_ be able to  
>>> support this.
>>>
>>> Ray
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 9 Nov 2009 08:28:08 -0500

> Just to be clear, we are talking about unauthenticated to the access  

Yes, although the document, predating "direct", also mentions the  
other cases.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 09 Nov 2009 08:33:50 -0400

Although I would note that it¹s not yet clear how the U.S. Regulator will
treat these arrangements.   There is significant pressure from the emergency
call authorities to NOT support unauthenticated access from broadband
networks.

However, there are some jurisdictions that I expect will require it, and
thus there needs to be some documentation of how to do that in such
jurisdictions.  As long as the device can tell if it is required or not,
we¹ll be okay.  As with direct, I don¹t want to encourage such use, but if
the local jurisdiction requires it, then we have to do something.  I prefer
this document over direct.

Brian

---

From: Marc Linsner <[email-masked]>
Date: Mon, 09 Nov 2009 08:34:59 -0500

Hence, I want the motivation for the work to NOT include 'regulation'.  As
you describe, the functionality should stand on it's own merits.

-Marc-

On 11/9/09 8:27 AM, "Henning Schulzrinne" <[email-masked]> wrote:

>> <[email-masked]
>>> wrote:
>> 
>>> Ray,
>>>

---

From: [email-masked]
Date: Mon, 9 Nov 2009 23:10:17 +0900

> Although I would note that it’s not yet clear how the U.S. Regulator
> will treat these arrangements.   There is significant pressure from 
> the emergency call authorities to NOT support unauthenticated access
> from broadband networks.

Given the objections to ECRIT-direct and the comparison with SIMless 
phones, that does not surprise me.
 
> However, there are some jurisdictions that I expect will require it,
> and thus there needs to be some documentation of how to do that in 
> such jurisdictions. 

I'd ask the same as I asked Henning - what sort of broadband networks do 
you mean?

Per my previous message, this may make sense for wireless, but it doesn't 
seem to make any sense for wired access, at least not for the NAA case.

Ray

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 9 Nov 2009 14:34:34 +0100

Marc, 
 
my understanding is that today this is mainly in place for the existing
cellular networks, and the "I would say that obvous candidates include
wireless access in regulated spectrum" part below is an assumption. But
I may not be fully up-to-date regarding the latest status e.g. in the
U.S. or Canda...
 
Thanks,
Dirk

	From: ext Marc Linsner [mailto:[email-masked]] 
	Sent: Monday, November 09, 2009 2:16 PM
	To: Kroeselberg, Dirk (NSN - DE/Munich);
[email-masked]; Bernard Aboba
	Cc: ECRIT
	Subject: Re: [Ecrit] Fwd: Comments on
draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1

	Dirk,
	
	Are there regulations that call for unauthenticated clients to
have emergency access in the Internet realm?  Or is this an assumption
of something in the future?
	
	-Marc-

		Ray, 
		
		what you are saying in your earlier e-mail is true for
the UK, but not for other countries. Currently there is support for
'SIM-less' calls in cellular networks (enabled based on a per-country
policy). You need to support this in some regions like North-America. I
would say that obvious candidates include wireless access in regulated
spectrum.
		For fixed-line, this is not a big deal as usually there
is no 'unauthenticated' case.
		
		Dirk

			> placing the client on an emergency  VLAN. 
			
			That's fine _if_ your network  supports such a
mechanism. 
			
			None of the  network technologies I ever ran
did. 
			
			All  I'm saying is the draft needs to be much
clearer (IMHO) about what sorts of  access network technologies _might_
be able to support this.  
			
			Ray

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 9 Nov 2009 14:50:18 +0100

Marc, 

I think I agree with this in so far that it is not the job of any
standards organization to decide or figure out where to use such
feature. A standard in this area can only offer building blocks or
capture some recommendations. Where these will actually be used later on
is a different story. But at least it does not look like we can safely
assume that noone will require such functionality.

Dirk 

> -----Original Message-----
> Sent: Monday, November 09, 2009 2:35 PM
> To: Henning Schulzrinne
> Cc: Kroeselberg, Dirk (NSN - DE/Munich); 
> [email-masked]; Bernard Aboba; ECRIT
> (IMHO) about

---

From: Brian Rosen <[email-masked]>
Date: Mon, 09 Nov 2009 09:46:24 -0400

Frankly, I don¹t really know how this will work, but I¹ve had someone
explain to me that they believe their regulator will require ALL broadband
networks to support access to make emergency calls.  If there is an L2 path,
then access is allowed for emergency calls, similar to if there is a radio
connection, access is allowed for emergency calls.  I don¹t think the choice
of access control mechanism has any bearing on what the regulator requires.

Brian

On 11/9/09 10:10 AM, "[email-masked]" <[email-masked]>
wrote:

> 
>> > Although I would note that it¹s not yet clear how the U.S. Regulator
> Given the objections to ECRIT-direct and the comparison with SIMless phones,
> that does not surprise me.
>  
> I'd ask the same as I asked Henning - what sort of broadband networks do you
> mean? 
> 
> Per my previous message, this may make sense for wireless, but it doesn't seem
> to make any sense for wired access, at least not for the NAA case.
> 
> Ray 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 9 Nov 2009 09:46:49 -0500

>
> Per my previous message, this may make sense for wireless, but it  
> doesn't seem to make any sense for wired access, at least not for  
> the NAA case.

In some cases, this may make sense for wired (Ethernet) networks. My  
understanding is that it is becoming more common that corporate  
networks require network access authentication for their wired  
networks, to avoid the obvious security problem that a visitor can  
just leave behind a little box that plugs into the nearest unused  
Ethernet jack. On a college campus I visited recently, both the wired  
and wireless network required the same (web-based) access  
authentication for students and visitors. (To my disappointment - I  
had hoped that my retractable Ethernet cable would help me out to get  
Internet access...)

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 10 Nov 2009 00:04:50 +0800

Hi Brian,

Your last comment indicates some actual or affected confusion about direct... which was also indicated in previous sensational comparisons to "SIMless" scenarios.

The question of whether the call goes directly from UA to ESRP is orthogonal to the question of (un)authenticated network access. The access can prevent an emergency call for an unauthenticated device regardless of whether the call is being made via a VSP or whether it goes directly. It is non sensible to compare the two documents in this way.

Having said that, where some jurisdiction demands that networks permit emergency calls regardless of "authentication" then the direct model certainly makes it easier for the network to apply appropriate controls - i.e. the network doesn't have to somehow take the device's word for it that it really is using that foreign VSP to make an emergency call... "honest guv'"

On the topic of the thread:

There are two main reasons networks do authentication - security, particularly for enterprise networks - and commercial; i.e. for billing purposes. The nature of authentication, and in particular whether it occurs at layer two or not, will govern how difficult it is to support "unauthenticated" emergency calling. If authentication occurs on layer 3, then unauthenticated emergency access is more straightforward:

Consider the typical hot spot. Access is uncontrolled right up to layer 3; the access points are unsecured, an IP address is issued. At that point the user is typically portal locked, HTTP only, to the access point web site. Some portals allow limited web browsing to specific destinations. It is reasonably straightforward to add access to the LIS, LoST, and SIP to the PSAP URI to the portal white list. Then users can tunnel the emergency procedures through that access without completing authentication. No other general Internet access is granted or required.

Where an emergency context has to be established at layer 2, then I don't really see any alternative to the layer two technology supporting specific signalling to establish that context in order that the device can be bootstrapped up to layer 3. Once that is done, the same limited access is possible as in the hot spot scenario above. 3GPP has described how UE establish an emergency context in their RANs; I believe there is movement in the IEEE to do something like this for 802. No idea what the DSL or cable forums are thinking.

As discussed, the imperative for any form of access network to do this must ultimately be the subject of local regulation. It's definitely worthwhile documenting what we can to help those jurisdictions decide whether it's worthwhile. I'm not sure that the IETF can say anything other than what happens from IP up however. Again - it's a different topic to the one covered in the ECRIT direct draft.

Cheers,
Martin

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Monday, 9 November 2009 11:34 PM
To: Kroeselberg, Dirk (NSN - DE/Munich); [email-masked]; Bernard Aboba
Cc: ECRIT
Subject: Re: [Ecrit] Fwd: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1

Although I would note that it's not yet clear how the U.S. Regulator will treat these arrangements.   There is significant pressure from the emergency call authorities to NOT support unauthenticated access from broadband networks.

However, there are some jurisdictions that I expect will require it, and thus there needs to be some documentation of how to do that in such jurisdictions.  As long as the device can tell if it is required or not, we'll be okay.  As with -direct, I don't want to encourage such use, but if the local jurisdiction requires it, then we have to do something.  I prefer this document over -direct.

Brian

On 11/9/09 1:31 AM, "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]> wrote:
Ray,

Dirk

Ray

---

From: Byron Smith <[email-masked]>
Date: Mon, 09 Nov 2009 11:14:59 -0500

It should be noted that NAA access may not provide the same level of 
functionality as credentialed access.

With respect to US landlines that are shut off for non-payment:  At 
least here in the state of Indiana there is no regulatory requirement of 
which I am aware.  It is a telco "service" that varies with company, 
policy, and equipment.

However, this PSTN "NAA" service, where implemented, may be problematic 
for several reasons:

a)  Incorrect routing, as the caller may not have an assigned number in 
the Class 5 switch, so the call must be "exchange" (trunk) routed
b)  No ALI data, or ALI data may be "generic" without location information
c)  The PSAP cannot call back the caller
d)  Potential for annoynomous / annoyance calls

Due to these issues such PSTN calls create special problems for the PSAP 
(lack of identification/location data)/annoyance 
calls/out-of-jurisdiction calls), for the service provider (trouble 
tickets for "misroutes," no ALI, annoyance call tracing, exposure to 
legal actions) and to the caller (lower quality of emergency service).  
So some local telcos have ceased to implement this type of service 
rather than deal with the issues.

Never-the-less, for the telcos that do provide this service, a person 
can still call for help from a "disconnected" phone even though the 
quality of service is substantially reduced.

I do agree this is an interesting issue to consider.   Presumably the 
feasibility of providing NAA service in the Internet world will be 
greater than in the PSTN world.  I just wanted to make the point that 
this type of service is not universally available in the PSTN network, 
and that it is problematic in serveral ways.

Byron

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 9 Nov 2009 08:55:31 -0800

Henning said: 

"In some cases, this may make sense for wired (Ethernet) networks. My  
Internet access...)"

There are a number of challenges for providing emergency calling on
authenticated Ethernet networks. 

Today these networks are not built to enable rapid logon.  If clients are
set to expect 802.1X support, then they will send EAPoL-Start packets in an
effort to wake up the authenticator.  If they don't get an answer, they will
not allow network access unless they are set up for "failback", in which
case they will then start DHCP and get an address.  At that point they may
encounter the web portal/DNS spoofing facility which typically returns the
A/AAAA RR of the portal in response to all A/AAAA RR queries.  Since we are
talking about a DNS proxy, it is likely to be non-compliant in a variety of
ways (see RFC 5625).  Many applications (including some SIP UAs) do not deal
well with portal behavior, and will throw up various error messages as
certificates fail to verify, registration attempts timeout or fail, etc. 

Assuming that the user is not too distracted by all the error messages being
thrown up, they will need to bring up the browser and attempt to satisfy the
demands of the portal on their handset screens.  Since the portals are
non-standard in their designs, they may need to create login IDs, agree to
the terms of use, select roaming partners, etc. before they are allowed
enough access to actually attempt an emergency call. 

Just getting on to an authenticated Ethernet network is a annoying at best
in a non-stressful situation.  In an emergency, the exercise would be a form
of torture.