Subject: [Geopriv] lis-discovery proposed changes

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 24 Jun 2008 01:21:39 -0500

In my off-lists discussions on discovery with Dean I've come to the realization that there are still a few minor textual changes that could improve the draft.

Here are my proposed changes.  The first proposal has a potential impact on HELD that probably needs further discussion.

***1. Add (to Section 5) text to the effect of:

  "A LIS that is discovered through this process might not be able to provide location.  Section 4.3.2 of [held] mandates that a LIS fail requests for location information where it is unable.  The host SHOULD make a query to the LIS to ensure that the LIS is able to provide location information.  If the response from the LIS indicates an error code of "notLocatable", this indicates that the LIS cannot provide location information and the host SHOULD continue the discovery process."

 The point for discussion on the HELD draft is thus:  The error codes currently available indicate situations that could be temporary.  The situation highlighted in Section 4.3.2 is one that is permanent.  Indicating to the host that this is a permanent situation lets the device continue searching for a valid LIS, rather than leaving it in the ambiguous state where the LIS *might* be the right one.  To address this, we need a new error code for this situation.  I can add this to the lis-discovery draft, but would actually prefer that it be put in the HELD draft and referenced in Section 4.3.2.

***2. Dean brought up an interesting use case for STUN that probably needs highlighting in the operational considerations section.  The (simplified) deployment scenario looks like:

  Target --- Home Router --- (Internet) --- NAT* --- STUN Server
                NAT                               `- SIP Server

In this case, the results from the STUN server aren't of much use.  The IP address it produces is in the private address range of the SIP provider.  I am assuming that the mapping between this address and the public IP address of the home router is fairly simple so that the NAT* can correctly route return packets.  However, this case doesn’t provide much hope for discovering the public/external address of the home router.  If this address is used in discovery, it wont work, or it will turn up the LIS in the SIP provider's network.  

I propose to add a diagram that illustrates this scenario (as above) and add a suggestion to the effect that only properly public STUN servers are useful.

***3. I have been reminded of NAT-PMP, which is a simpler alternative to UPnP.  I'd like to add an informative reference:

  <http://tools.ietf.org/html/draft-cheshire-nat-pmp>

***4. More text in the Access Network Guidance section:

 - Any access network that uses a private address range and a NAT should provide reverse DNS for the private address range AND the public address range so that addresses from either range can be used to discover the LIS.
 - Any access network that provides reverse DNS records should also provide U-NAPTR records that indicate the LIS that serves the given address range.  

In particular, the LIS that serves the private address range should be discoverable externally (even if it is not necessarily accessible from the public internet).  This enables the use of public STUN servers.

These use "should" strength text because they are not strictly required to get discovery working.
------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 24 Jun 2008 11:40:22 +0300

Only a quick comment: 

It does not help to list all possible ways for an end host to obtain
it's public IP address. You only need to mandate one mechanism -- and
that one always needs to work 

Otherwise you create a system where there is some chance that nothing
will work. 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Thomson, Martin
>Sent: 24 June, 2008 09:22
>To: GEOPRIV
>Subject: [Geopriv] lis-discovery proposed changes
>
>In my off-lists discussions on discovery with Dean I've come 
>to the realization that there are still a few minor textual 
>changes that could improve the draft.
>
>Here are my proposed changes.  The first proposal has a 
>potential impact on HELD that probably needs further discussion.
>
>  "A LIS that is discovered through this process might not be 
>able to provide location.  Section 4.3.2 of [held] mandates 
>that a LIS fail requests for location information where it is 
>unable.  The host SHOULD make a query to the LIS to ensure 
>that the LIS is able to provide location information.  If the 
>response from the LIS indicates an error code of 
>"notLocatable", this indicates that the LIS cannot provide 
>location information and the host SHOULD continue the 
>discovery process."
>
> The point for discussion on the HELD draft is thus:  The 
>error codes currently available indicate situations that could 
>be temporary.  The situation highlighted in Section 4.3.2 is 
>one that is permanent.  Indicating to the host that this is a 
>permanent situation lets the device continue searching for a 
>valid LIS, rather than leaving it in the ambiguous state where 
>the LIS *might* be the right one.  To address this, we need a 
>new error code for this situation.  I can add this to the 
>lis-discovery draft, but would actually prefer that it be put 
>in the HELD draft and referenced in Section 4.3.2.
>
>***2. Dean brought up an interesting use case for STUN that 
>probably needs highlighting in the operational considerations 
>section.  The (simplified) deployment scenario looks like:
>
>In this case, the results from the STUN server aren't of much 
>use.  The IP address it produces is in the private address 
>range of the SIP provider.  I am assuming that the mapping 
>between this address and the public IP address of the home 
>router is fairly simple so that the NAT* can correctly route 
>return packets.  However, this case doesn't provide much hope 
>for discovering the public/external address of the home 
>router.  If this address is used in discovery, it wont work, 
>or it will turn up the LIS in the SIP provider's network.  
>
>I propose to add a diagram that illustrates this scenario (as 
>above) and add a suggestion to the effect that only properly 
>public STUN servers are useful.
>
>***3. I have been reminded of NAT-PMP, which is a simpler 
>alternative to UPnP.  I'd like to add an informative reference:
>
> - Any access network that uses a private address range and a 
>NAT should provide reverse DNS for the private address range 
>AND the public address range so that addresses from either 
>range can be used to discover the LIS.
> - Any access network that provides reverse DNS records should 
>also provide U-NAPTR records that indicate the LIS that serves 
>the given address range.  
>
>In particular, the LIS that serves the private address range 
>should be discoverable externally (even if it is not 
>necessarily accessible from the public internet).  This 
>enables the use of public STUN servers.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 28 Jun 2008 18:40:43 +0300

Hi Martin,

>  The point for discussion on the HELD draft is thus:  The error codes currently available indicate situations that could be temporary.  The situation highlighted in Section 4.3.2 is one that is per…

Definitely a useful thing.

> I propose to add a diagram that illustrates this scenario (as above) and add a suggestion to the effect that only properly public STUN servers are useful.

I heard that this is a fairly common scenario these days with DSL 
providers.

During the meeting I heard a strong prefer for investing an anycast 
solution as well. That would deal with this scenario quite nicely.

>   <http://tools.ietf.org/html/draft-cheshire-nat-pmp>
I commented this one already

>  - Any access network that uses a private address range and a NAT should provide reverse DNS for the private address range AND the public address range so that addresses from either range can be us…
How is this supposed to work with private IP addresses?

>  - Any access network that provides reverse DNS records should also provide U-NAPTR records that indicate the LIS that serves the given address range.  
I don't think that it is new that U-NAPTR records also need to be 
provided in addition the the reverse DNS records.

> These use "should" strength text because they are not strictly required to get discovery working.
I thought that the U-NAPTR usage is mandatorily used. Even with the 
DHCP-based discovery procedure don't you make use of U-NAPTR?

Ciao
Hannes

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 30 Jun 2008 00:32:00 -0500

Thanks for the feedback Hannes.  More inline below.

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Sunday, 29 June 2008 1:41 AM
> To: Thomson, Martin
> Cc: GEOPRIV
> Subject: Re: [Geopriv] lis-discovery proposed changes
> 
> Hi Martin,
> 
> Thomson, Martin wrote:
> > In my off-lists discussions on discovery with Dean I've come to the
> realization that there are still a few minor textual changes that could
> improve the draft.
> >
> > Here are my proposed changes.  The first proposal has a potential
> impact on HELD that probably needs further discussion.
> >
> >   "A LIS that is discovered through this process might not be able to
> provide location.  Section 4.3.2 of [held] mandates that a LIS fail
> requests for location information where it is unable.  The host SHOULD
> make a query to the LIS to ensure that the LIS is able to provide
> location information.  If the response from the LIS indicates an error
> code of "notLocatable", this indicates that the LIS cannot provide
> location information and the host SHOULD continue the discovery
> process."
> >
> >  The point for discussion on the HELD draft is thus:  The error codes
> currently available indicate situations that could be temporary.  The
> situation highlighted in Section 4.3.2 is one that is permanent.
> Indicating to the host that this is a permanent situation lets the
> device continue searching for a valid LIS, rather than leaving it in
> the ambiguous state where the LIS *might* be the right one.  To address
> this, we need a new error code for this situation.  I can add this to
> the lis-discovery draft, but would actually prefer that it be put in
> the HELD draft and referenced in Section 4.3.2.
> >
> 

Would you prefer this to be added to HELD, or LIS-discovery?  I can manage with either, but prefer HELD.

> > ***2. Dean brought up an interesting use case for STUN that probably
> needs highlighting in the operational considerations section.  The
> (simplified) deployment scenario looks like:
> >
> > In this case, the results from the STUN server aren't of much use.
> The IP address it produces is in the private address range of the SIP
> provider.  I am assuming that the mapping between this address and the
> public IP address of the home router is fairly simple so that the NAT*
> can correctly route return packets.  However, this case doesn’t provide
> much hope for discovering the public/external address of the home
> router.  If this address is used in discovery, it wont work, or it will
> turn up the LIS in the SIP provider's network.
> >
> > I propose to add a diagram that illustrates this scenario (as above)
> and add a suggestion to the effect that only properly public STUN
> servers are useful.
> >
> 

This is less about the DSL providers and more to do with how people deploy STUN services.  Drawing this picture would show one of the potential pitfalls that comes with relying on STUN.

What would be more interesting from a DSL provider perspective is the following diagram:

  Target --- Home Router ---  ISP NW  --- ISP NAT --- (Internet) --- 
                 NAT         (private)                       

With ipv4 addressing limitations, this is becoming more and more common.  Describing where to look for a LIS in this scenario is what motivates some of the points below (in ***4). 

> solution as well. That would deal with this scenario quite nicely.

I'd like to explore the anycast solutions separately.  My view is that any attempt to add anycast would unnecessarily delay publication of this document, and those that depend on it (namely HELD, which is already a long way towards publication).  Anycast is most likely more robust, but there are still a number of unanswered questions and a long road to specification.  We make do with the tools that are available at the time.

> > ***3. I have been reminded of NAT-PMP, which is a simpler alternative
> to UPnP.  I'd like to add an informative reference:
> >

And your comments were duly noted.  In theory.  A single method that always works is what is commonly referred to as a "silver bullet".  We make do with the tools that are available at the time.

> >  - Any access network that uses a private address range and a NAT
> should provide reverse DNS for the private address range AND the public
> address range so that addresses from either range can be used to
> discover the LIS.
> >

If I discover an address that refers to my host, I can use that address to discover the LIS.  It doesn't matter if that address is private.  The best example is from above:

  Target --- Home Router ---  ISP NW  --- ISP NAT --- (Internet) --- ?
                 NAT          (w/ LIS)                       

The LIS exists in the private address space operated by the ISP.  If a client on the Target host were able to discover the external address of the home router using UPnP/NAT-PMP it could use that address (say 10.1.2.3) to discover the LIS if there were appropriate PTR and NAPTR records for the private address range.  Operating DNS for large private address ranges is common practice (I'm using one right now), so I don't see this as particularly revolutionary or surprising.
 
> >  - Any access network that provides reverse DNS records should also
> provide U-NAPTR records that indicate the LIS that serves the given
> address range.

No, but this is about being extra-super-specific.  I don't think that the extra text hurts.

> > In particular, the LIS that serves the private address range should
> be discoverable externally (even if it is not necessarily accessible
> from the public internet).  This enables the use of public STUN
> servers.
> >
 
When providing guidance on network configuration, the rules are slightly different.  Basically, most of the requirements on network configuration are an extension of the documented discovery procedure with judicious application of common-sense.  If a network implements DHCP and all hosts are necessarily configured by DHCP, then providing U-NAPTR records isn't necessary.

> Hannes

Ta,
Martin

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 30 Jun 2008 12:00:50 +0300

Hi Martin, 

>Sent: 30 June, 2008 08:32
>To: Hannes Tschofenig
>Cc: GEOPRIV
>> realization that there are still a few minor textual changes that 
>> could improve the draft.
>> >
>> the ambiguous state where the LIS *might* be the right one.  To 
>> address this, we need a new error code for this situation.  
>I can add 
>> this to the lis-discovery draft, but would actually prefer 
>that it be 
>> put in the HELD draft and referenced in Section 4.3.2.
>> >
>> 
>Would you prefer this to be added to HELD, or LIS-discovery?  
>I can manage with either, but prefer HELD.

I prefer HELD

>> can correctly route return packets.  However, this case doesn't 
>> provide much hope for discovering the public/external address of the 
>> home router.  If this address is used in discovery, it wont work, or 
>> it will turn up the LIS in the SIP provider's network.
>> >
>This is less about the DSL providers and more to do with how 
>people deploy STUN services.  Drawing this picture would show 
>one of the potential pitfalls that comes with relying on STUN.
>
>With ipv4 addressing limitations, this is becoming more and 
>more common.  Describing where to look for a LIS in this 
>scenario is what motivates some of the points below (in ***4).

I don't think that this is about deployment of STUN servers. STUN
servers in the way how they are supposed to be used for VoIP are
actually sitting somewhere on the Internet and have to learn the
outermost public IP address. 

>I'd like to explore the anycast solutions separately.  My view 
>is that any attempt to add anycast would unnecessarily delay 
>publication of this document, and those that depend on it 
>(namely HELD, which is already a long way towards 
>publication).  Anycast is most likely more robust, but there 
>are still a number of unanswered questions and a long road to 
>specification.  We make do with the tools that are available 
>at the time.
>
>> > alternative
>And your comments were duly noted.  In theory.  A single 
>method that always works is what is commonly referred to as a 
>"silver bullet".  We make do with the tools that are available 
>at the time.

The problem is similar to the one of using certain location
configuration protocols. In order to produce a robust solution someone,
either the network or the end host, has to support everything to make
sure that it works.

Hence, I am not sure whether adding more mechanisms is going to be so
useful.

>> should provide reverse DNS for the private address range AND the 
>> public address range so that addresses from either range can be used 
>> to discover the LIS.
>> >
>If I discover an address that refers to my host, I can use 
>that address to discover the LIS.  It doesn't matter if that 
>address is private.  The best example is from above:
>
>The LIS exists in the private address space operated by the 
>ISP.  If a client on the Target host were able to discover the 
>external address of the home router using UPnP/NAT-PMP it 
>could use that address (say 10.1.2.3) to discover the LIS if 
>there were appropriate PTR and NAPTR records for the private 
>address range.  Operating DNS for large private address ranges 
>is common practice (I'm using one right now), so I don't see 
>this as particularly revolutionary or surprising.

The problem is that this only works if the end host uses the DNS server
of the ISP and not any other DNS server (which they always can do) since
then they are essentially looking up a private IP address someone on the
Internet and that's not going to work super great either. 

>think that the extra text hurts.
OK

>When providing guidance on network configuration, the rules 
>are slightly different.  Basically, most of the requirements 
>on network configuration are an extension of the documented 
>discovery procedure with judicious application of 
>common-sense.  If a network implements DHCP and all hosts are 
>necessarily configured by DHCP, then providing U-NAPTR records 
>isn't necessary.

But I understood that the current version of the document always returns
HELD URIs and these have to go through the U-NAPTR resolution procedure.

I am wrong with this assumption? 

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 30 Jun 2008 14:47:29 +0300

I think it would help to add the following text to Section 5 "Discovery
Order" following
"

   1.  DHCP LIS URI Option

If the DHCP provides the LIS URI to the end host then this held URI can
be used by the HELD client without going through a U-NAPTR lookup
procedure to contact the LIS. 
"

Ciao
Hannes

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 1 Jul 2008 00:00:34 -0500

Hi Hannes,

I'll send another email on the topic of the HELD error code, so I'll snip that discussion.

<snip>

> outermost public IP address.

Here are the two scenarios, with an expected location for the LIS in each:

An ISP that employs NAT:

                       {U}     (LIS)            {S}
  Target --- Home Router ---  ISP NW  --- ISP NAT --- (Internet) --- STUN server
                NAT        (private IP)

A VSP that employs NAT:

                       {U}     (LIS)                       {S}	
  Target --- Home Router ---  ISP NW --- (Internet) --- NAT* --- SIP/STUN server
                NAT         (public IP)

(I'll omit the scenario where both ISP and VSP use a NAT, it doesn't add significant value.)

These scenarios both demonstrate the limitations of STUN for this use case.  The point marked with {S} indicates the address that is provided by STUN.  Which in either case can be the wrong address.  At least in the first case, the ISP can provide PTR and NAPTR records for their public address range to ensure that the LIS can still be discovered.  In the second case, nothing can be done - STUN is useless.

>From this, I make two conclusions: STUN servers must be properly public to be useful; STUN is only useful as a last resort. 

You'll note that in both cases the address returned by UPnP {U} is useful.  As long as the ISP provides the necessary DNS records to enable the use of that address in discovery, everything is peachy.

<more snip>

> Hence, I am not sure whether adding more mechanisms is going to be so

It was only a suggestion - consider it retracted.  I'm against making discovery more complicated.

> Internet and that's not going to work super great either.

Indeed.  And I don't have an easy reply for that.  The process behind deciding to use an external DNS is fascinating, but not really relevant.  People do it and we can't say otherwise.

Choosing not to use the DNS provided by your ISP effectively makes the services that are provided on the private network invisible.  Making the LIS discoverable based on the public IP address range of the ISP is a possibility.  This works as long as your STUN server isn't hidden somehow, see earlier discussion.

And here I risk ridicule for suggesting other ways to address the problem:  An ISP could take a bloody-minded approach and let people break this service if they so choose.  Or, the ISP could decide to make a hugely unpopular choice and redirect UDP on port 53.  (Interestingly enough, I'd have thought that the choice of using NAT in the first place would be more unpopular, but it doesn't seem to be.)

<snippy>
> should
	
The URI can be acquired from DHCP alone.  If DHCP provides the URI, then nothing more is necessary.  U-NAPTR is a backup, for those cases where DHCP isn't available.  I've already been asked to be extra-super-specially explicit on this point, so you should see improvements in the next revision.

I can see how reading the abstract could lead to wrong impressions.  I'll make some tweaks in the next revision.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 01 Jul 2008 11:17:47 +0300

Hi Martin,

>   Target --- Home Router ---  ISP NW --- (Internet) --- NAT* --- SIP/STUN server

To my understanding the 2nd scenario isn't so useful since the STUN 
server's are supposed to be on the public Internet in order to work. As 
such, they are not behind NATs unless you are talking about ICE where 
the end hosts themself run STUN servers for connectivity checks.

> You'll note that in both cases the address returned by UPnP {U} is useful.  As long as the ISP provides the necessary DNS records to enable the use of that address in discovery, everything is peach…

For the UPnP case it really depends on the way how the end host is 
provisioned. You can easily create a scenario where it would fail.

> And here I risk ridicule for suggesting other ways to address the problem:  An ISP could take a bloody-minded approach and let people break this service if they so choose.  Or, the ISP could decide…
I just wanted to point out this limitation. I don't have data on how 
often that actually happens.

>>>>> These use "should" strength text because they are not strictly
>>>>>           
>>>> required to get discovery working.
>>>>         
Good.

Ciao
Hannes