Subject: [Ecrit] LoST & U-NAPTR Usage

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 18 Mar 2008 22:20:09 +0200

Hi folks,

prior to IETF#71 we received a lot of IESG comments and particular one 
comment from Sam Hartman triggered some discussion. The topic of 
discussion referred to the way how two pieces of information are matched 
against each other, namely:
1) the content of the identity information carried in the certificate 
exchanged as part of a TLS handshake between a LoST client and a LoST server
2) information that is provided as input or obtained as output of the 
U-NAPTR DNS discovery mechanism.

The 2nd mechanism triggered some discussion since the current text in 
the draft uses the output of the U-NAPTR mechanism for comparison 
against (1).

During the ECRIT session at IETF#71 I asked for an opinion of the 
working group whether they would like to go for using the
a) the input to the U-NAPTR process OR
b) the output of the U-NAPTR process
to be matched against (1).

To illustrate the issue please consider Section 4 of the LoST 
specification since it provides an example.
    
The complexity of the issue is hidden in the deployment story. There are 
three deployment cases that need to be considered:

Case 1:  Pre-Configured URI of the LoST server

In this case the LoST client is configured with the LoST server URI and 
hence there is no need for the U-NAPTR mechanism.

Example: https://lostserver.example.com

The usage of the SIP config framework is a possible tool for providing 
this information to the LoST client.

Case 2: VoIP provider runs a LoST server and uses U-NAPTR

In this case the U-NAPTR mechanism is used and the LoST client is only 
configured with the domain of it's VoIP provider, here
example.com. An example of this configuration can be found in the document:

------------------------------------------------------------------------

    example.com.
    
    IN NAPTR 100  10   "u"    "LoST:https"
    "!.*!https://lostserver.example.com/secure!"  ""
    
    IN NAPTR 200  10   "u"    "LoST:http"
    "!.*!http://lostserver.example.com!"  ""

------------------------------------------------------------------------    
    
 In this case matching the output of the U-NAPTR introduces problems 
since the translation step from example.com to 
https://lostserver.example.com/secure is only secure if DNSSEC is used. 
Without DNSSEC an adversary would be able to intercept the response and 
provide a different answer back or make use of DNS cache poisioning.

  Case 3: VoIP provider points to a LoST server and uses U-NAPTR
    
This case is the most likely one based on the current thinking of the 
deployment models. Here, the VoIP provider itself does not run the LoST 
server but just points to it using the U-NAPTR mechanism. This might be, 
for example, the case when enterprises in one state point to a LoST 
server operated by the government.

The following configuration shows this example:

------------------------------------------------------------------------

    enterprise-example.com.
    
    IN NAPTR 100  10   "u"    "LoST:https"
    "!.*!https://lostserver.state-psap.gov/secure!"  ""
    
    IN NAPTR 200  10   "u"    "LoST:http"
    "!.*!http://lostserver.state-psap.gov!"  ""

------------------------------------------------------------------------    
    
In this case the government operating the LoST server provides their 
service for a large number of enterprise networks within a particular 
state. In fact, they might even be unaware of the number of enterprising 
pointing to their LoST server at a given point in time.
 
Using the output of the U-NAPTR process for comparison against (1) makes 
a lot of sense in this deployment case. Using the input would require 
the LoST server operated by the government to have certificates for each 
of the enterprise networks the LoST server is providing services for.

Case 4: DHCP-based Discovery

In the DHCP-based discovery the DHCP client is provided with the domain 
name of the LoST server. Then, the client uses the U-NAPTR mechanism as 
described above. The considerations of Case 2 and Case 4 apply.

The security of the DHCP-based discovery is determined by the level of 
security provided by DHCP and additionally by the security of the 
U-NAPTR procedure.

Ciao
Hannes

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Mar 2008 16:44:33 -0400

Even in an enterprise environment, the VoIP provider is unlikely to know the
best LoST server.  The access network provider is much more likely to be
able to do that.  Consider a telecommuter for example; enterprise =
clueless, access (broadband) supplier=likely to have correct data.

Doesn't really affect your discussion, although the DHCP case is more likely
for that.  When we finish this, we probably need words in phonebcp about
this, and especially what to do when the access network says one thing and
the calling network says another.  In the U.S., we're likely to have well
behaved LoST servers hooked up to a comprehensive forest guide network, so
any LoST server should be able to get you to the right one.  That may not be
true in other places.  The access network is roughly never wrong (because
it's local).  The calling network may well be, because it doesn't know where
you are.

Of course if the calling network and the access network are the same entity,
it probably doesn't matter.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Tuesday, March 18, 2008 4:20 PM
To: [email-masked]
Subject: [Ecrit] LoST & U-NAPTR Usage

Hi folks,

    

    example.com.

    

    

    enterprise-example.com.

    

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 18 Mar 2008 15:47:57 -0500

Actually I think for the enterprise case you will just have a hard-coded
LoST server in your calling client. This does of course assume that LoST
servers are widely deployed and have a good peering relationship going.

Cheers
James

> Brian Rosen
> Sent: Wednesday, 19 March 2008 7:45 AM
> To: 'Hannes Tschofenig'; [email-masked]
> Subject: Re: [Ecrit] LoST & U-NAPTR Usage
> 
> Even in an enterprise environment, the VoIP provider is unlikely to
know
> the
> any LoST server should be able to get you to the right one.  That may
not
> be
> security provided by DHCP and additionally by the security of the

------------------------------------------------------------------------------------------------
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: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Mar 2008 17:08:08 -0400

This is the question I'm raising.

Suppose you have an enterprise client and you take it to Paris (or Sierra
Leone).  Your hardwired LoST server is likely wrong.  You MAY be able to
follow the forest guides to the right server, but maybe not.  If the access
network gave you a LoST server via DHCP, you should probably use that in
preference to your configured server in the client.

Brian

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Tuesday, March 18, 2008 4:48 PM
To: Brian Rosen; Hannes Tschofenig; [email-masked]
Subject: RE: [Ecrit] LoST & U-NAPTR Usage

Cheers
James

know
not
> security provided by DHCP and additionally by the security of the

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2]

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 18 Mar 2008 16:21:57 -0500

Okay you have forced me to go and read LoST.
Good thing too, because in the introduction there is talk about PIDL-LO
profile.

Maybe I have it wrong, but I thought that it was the LoST server that
would talk to the FG, and not the end-device. In this way I could get
some degree of transitive trust across the network between the FGs and
the various LoST servers that contained the service mappings I was
after.

It is definitely true that the a relatively good mesh of FGs to LoST
servers has to exist for this to work. However, if the VSP in Sierra
Leone is going to check that your destination URI is really that of a
PSAP, then this mesh will have to exist anyway. Of course if the VSP is
going to pass the call in any event, then simply providing the PSAP URI
directly over the LCP works just was well.... ;)  (okay bait off now).

Cheers
James

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, 19 March 2008 8:08 AM
> To: Winterbottom, James; 'Hannes Tschofenig'; [email-masked]
> > From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of
> > best LoST server.  The access network provider is much more likely
to
> > Doesn't really affect your discussion, although the DHCP case is
more
> > likely
> > this, and especially what to do when the access network says one
thing
> and
> > it's local).  The calling network may well be, because it doesn't
know
> > where
> > From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of
> > exchanged as part of a TLS handshake between a LoST client and a
LoST
> > server
--
> --
--
> --

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Mar 2008 17:37:31 -0400

Yeah, I assume it's the server that consults the FG.  If the server you are
directed to is well connected, you won't have a problem.

I worry about things going wrong. In theory, if all countries have FGs, and
they are interconnected, no problem.  But, is that a reasonable assumption?

Wouldn't it be better if we advised the access network to provide a local
service, and suggest that the client of the LoST server use that server,
rather than what the VoIP network provides?  I would think that would work
better.

Brian

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Tuesday, March 18, 2008 5:22 PM
To: Brian Rosen; Hannes Tschofenig; [email-masked]
Subject: RE: [Ecrit] LoST & U-NAPTR Usage

Cheers
James

Behalf
to
more
thing
know
Behalf
LoST

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 18 Mar 2008 18:06:22 -0500

I definitely agree. As with the LIS, a reliable and readily
implementable discovery process needs to exist that access networks of
all descriptions can implement consistently.

LoST has to be implemented on a local basis because by definition it
provides a local service. Having decided to implement LoST, local
jurisdictions will have much more control over the reliability of the
service if there is no assumed dependency on some global web of
relationships.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Wednesday, 19 March 2008 8:38 AM
To: Winterbottom, James; 'Hannes Tschofenig'; [email-masked]
Subject: Re: [Ecrit] LoST & U-NAPTR Usage

Yeah, I assume it's the server that consults the FG.  If the server you
are
directed to is well connected, you won't have a problem.

I worry about things going wrong. In theory, if all countries have FGs,
and
they are interconnected, no problem.  But, is that a reasonable
assumption?

Wouldn't it be better if we advised the access network to provide a
local
service, and suggest that the client of the LoST server use that server,
rather than what the VoIP network provides?  I would think that would
work
better.

Brian

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Tuesday, March 18, 2008 5:22 PM
To: Brian Rosen; Hannes Tschofenig; [email-masked]
Subject: RE: [Ecrit] LoST & U-NAPTR Usage

Cheers
James

Behalf
to
more
thing
know
Behalf
LoST

----
----
--------------------
[mf2]

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Mar 2008 23:06:41 -0400

Practically speaking, we need to support a number of options, given  
that not all enterprises or WiFi access networks will support LoST  
servers next year. Many home Linksys boxes will never be upgraded to  
contain DHCP information for LoST servers. VoIP providers are probably  
going to be the earliest adopters, simply because they have an  
incentive and have traditionally been held responsible for emergency  
calls, fairly or not. Thus, you need a reasonable set of alternatives,  
probably starting with DHCP (most likely to be local), followed by SIP  
configuration (also often local and avoids UNAPTR problems, and  
already supports network and provider configuration, but obviously not  
finished yet and somewhat complicated) and last, UNAPTR for the SIP  
domain name (easiest to deploy).

Henning

On Mar 18, 2008, at 4:44 PM, Brian Rosen wrote:

> know the
> to be
> more likely
> thing and
> know where

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 19 Mar 2008 11:32:07 +0200

Hi Brian, James, Martin, Henning,
Hi all,

there are certainly challenging issues about the ability to 
incrementally deploy LoST and whether it is easier to deploy FGs or 
local LoST servers. This is all very interesting (and as Henning says 
there are good reasons for having all these mechanisms) BUT

*** that's not really what the DISCUSS by Sam Hartman and now Pasi 
Eronen is about ***.

Regardless whether you use DHCP (and then U-NAPTR) or U-NAPTR directly 
there is this issue about security. Hence, the most important topic for 
our discussion is what to compare the content of the certificate with. 
There are only two choices: The input or the output of the U-NAPTR mechanism

Currently, we are using the output of the U-NAPTR procedure and compare 
it with the cert. This has the nice property that the entity that 
operates the LoST server does not need to know all the enterprise 
networks, VoIP provider, etc. that point to it. This is case 3 in my 
summary. There are, however, disadvantages with respect to security.

Hence, there is a clear tradeoff between security vulnerability and 
simplicity of deployment. That's what we should come to a conclusion on.

Ciao
Hannes

Brian Rosen wrote:
>> best LoST server.  The access network provider is much more likely to
>>     
> be
>   
>> for that.  When we finish this, we probably need words in phonebcp
>>     
> about
>   
>> this, and especially what to do when the access network says one thing
>>     
> and
>   
>> the calling network says another.  In the U.S., we're likely to have
>>     
> well
>   
>> behaved LoST servers hooked up to a comprehensive forest guide
>>     
> network, so
>   
>> true in other places.  The access network is roughly never wrong
>>     
> (because
>   
>> discussion referred to the way how two pieces of information are
>>     
> matched
>   
>> The complexity of the issue is hidden in the deployment story. There
>>     
> are
>   
>> In this case the LoST client is configured with the LoST server URI
>>     
> and
>   
>> https://lostserver.example.com/secure is only secure if DNSSEC is
>>     
> used.
>   
>> Without DNSSEC an adversary would be able to intercept the response
>>     
> and
>   
>> deployment models. Here, the VoIP provider itself does not run the
>>     
> LoST
>   
>> server but just points to it using the U-NAPTR mechanism. This might
>>     
> be,
>   
>> state. In fact, they might even be unaware of the number of
>>     
> enterprising
>   
>> Using the output of the U-NAPTR process for comparison against (1)
>>     
> makes
>   
>> the LoST server operated by the government to have certificates for
>>     
> each
>   
>> In the DHCP-based discovery the DHCP client is provided with the
>>     
> domain
>   
>> name of the LoST server. Then, the client uses the U-NAPTR mechanism
>>     
> as
>