Subject: [Ecrit] New ID for downloading URIs via DHCP

From: "James M. Polk" <[email-masked]>
Date: Mon, 12 Sep 2005 18:12:05 -0500

ECRIT WG

To let folks know

One reference that is in the new Emergency Architecture Considerations ID 
regarding URIs being able to be downloaded (or requested for, then 
downloaded) to a DHC client is in the following ID just announced (which 
was delayed in its announcement for some reason I am not aware of):

http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-00.txt

with this abstract

    This document defines a new Dynamic Host Configuration Protocol
    (DHC) Option to allow one or more URIs to be transmitted from a
    server to a client within one or more messages, and for one or more
    URIs, each with a unique purpose, to be specifically requested by a
    client of a server.  Included in this Option is a purpose field to
    identify the type of URI being requested by the client, or the type
    of URI in the DHCP message from the server.

There are 11 URIs currectly defined in this ID:

    Purpose = 1  (Primary PSAP URI)
    Purpose = 2  (Secondary PSAP URI)
    Purpose = 3  (Location By-Reference of Client)
    Purpose = 4  (ESGW URI of Client)
    Purpose = 5  (ESRP URI of Client)
    Purpose = 6  (Organization Providing Location for Client)
    Purpose = 7  (URI of Geocoding/Reverse Geocoding)
    Purpose = 8  (Primary URI of Geo Mapping Service)
    Purpose = 9  (Secondary URI of Geo Mapping Service)
    Purpose = 10 (Primary URI of Civic Mapping Service)
    Purpose = 11 (Secondary URI of Civic Mapping Service)

Others can be added based on consensus discussion of this document

I just spoke with the DHC Chair, and open discussion of this ID on the 
ECRIT list is fine with him.  The formal syntax and encoding of the option 
proposal will be discussed on the DHC list for those interested there, but 
the general topic doesn't need to be limiting any of us discussing the ID 
there where they don't care about emergency calling, as ECRIT is the 
primary WG of interest for this effort initially.

Review and comments are appreciated

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 13 Sep 2005 09:15:13 -0400

Maybe it would be helpful to discuss how this work intersects with the 
(SIP) configuration work in SIPPING.

I believe almost all of this information can (and probably should) be 
part of the configuration package, rather than DHCP. In particular, the 
SIP configuration package has three major advantages:

- a much better security model (mutual authentication, encryption, etc.)
- automatic notification of changes
- the ability to use the same mechanism to retrieve this information for 
the local network and the service provider

Henning

James M. Polk wrote:
> ECRIT WG
> 
> To let folks know
> 
> One reference that is in the new Emergency Architecture Considerations 
> ID regarding URIs being able to be downloaded (or requested for, then 
> ECRIT list is fine with him.  The formal syntax and encoding of the 
> option proposal will be discussed on the DHC list for those interested 
> there, but the general topic doesn't need to be limiting any of us 
> discussing the ID there where they don't care about emergency calling, 
> as ECRIT is the primary WG of interest for this effort initially.
>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 13 Sep 2005 11:24:40 -0500

>(SIP) configuration work in SIPPING.

Jonathan and I have already been discussing this, and we see the two as 
complementary.

If DHCP solves this function for the UA, it doesn't need to request the 
URIs within SIP messaging. If the UA doesn't get this from DHCP, the UA 
knows to request this within SIP messaging.

I have another ID coming very soon about this using SIP, to focus the 
discussion for the config work in SIPPING, or to have it separate in ECRIT.

I am not professing DHCP as the only solution to this problem space, just 
the best one at Layer 2/3.

>I believe almost all of this information can (and probably should) be part 
>of the configuration package, rather than DHCP.

"rather"? How about "in addition to"?

OK, so how exactly is a Vonage-type organization to know where my UA is to 
give my UA its URI(s), and will a Vonage-type organization know or have the 
means to know each URI that can be learned via DHCP wherever a UA can be?

The access provider will know this, and if this DHCP Option is supported 
just like the Location Option(s) need(s) to be, this knowledge *can* be 
learned at boot time.

In the cases of a network that owns all 7 layers, DHCP is as good a 
delivery means as any - and arguably better in the wired/802.11 case of a 
home or enterprise/business.

>In particular, the SIP configuration package has three major advantages:
>

SIP travels much farther in the network, so increased security is necessary 
at this layer.

But I am right now on a wired connection directly to my DHCP server in my 
house. I'm not worried about authentication or encryption.  Enterprises are 
also in much tighter controlled network infrastructures, so DHCP messaging 
is much more limited in distances and exposure.

>- automatic notification of changes

DHCP needs to be refreshed at set, configurable intervals already - 
location and URIs can be refreshed at the same time, or more often.

>the local network and the service provider

My SP provides DHCP to my home router/NAT/firewall/DHCP server/client, 
which all my home devices then talk to

This document isn't saying DHCP is better than SIP, just saying this 
function can be accomplished at one of multiple layers up a stack in a 
device, and if DHCP addresses this, then SIP isn't needed for this UA (to 
learn the URIs). If DHCP doesn't address this, the UA seeks this info via SIP.

>>discussing the ID there where they don't care about emergency calling, as 
>>ECRIT is the primary WG of interest for this effort initially.

cheers,
James

                                 *******************

---

From: Andrew Newton <[email-masked]>
Date: Tue, 13 Sep 2005 19:35:57 -0400

On Sep 13, 2005, at 12:24 PM, James M. Polk wrote:

>> - the ability to use the same mechanism to retrieve this  
>> information for the local network and the service provider
>>
>
> My SP provides DHCP to my home router/NAT/firewall/DHCP server/ 
> client, which all my home devices then talk to
>
> This document isn't saying DHCP is better than SIP, just saying  
> this function can be accomplished at one of multiple layers up a  
> stack in a device, and if DHCP addresses this, then SIP isn't  
> needed for this UA (to learn the URIs). If DHCP doesn't address  
> this, the UA seeks this info via SIP.

I believe that providing this information in DHCP has the same  
utility as providing location information in DHCP.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 13 Sep 2005 20:32:07 -0400

> knows to request this within SIP messaging.

In general, having several ways to do roughly the same thing doesn't 
seem too helpful. In particular, it isn't always clear what information 
takes precedence if they contradict each other.

I agree that this is a borderline case, but it can also be seen as 
slippery slope.

> OK, so how exactly is a Vonage-type organization to know where my UA is 
> to give my UA its URI(s), and will a Vonage-type organization know or 
> have the means to know each URI that can be learned via DHCP wherever a 
> UA can be?

As far as I can tell, all the URIs are (or should be) 
location-independent. Thus, Vonage can provide those without having to 
know where the device is located.

> delivery means as any - and arguably better in the wired/802.11 case of 
> a home or enterprise/business.

In light of Christian Huitema's presentation in the APP area 
(http://www3.ietf.org/proceedings/05aug/slides/apparea-4/sld1.htm), 
802.11 strikes me as particularly bad example.

The risk exists for all information conveyed by DHCP, but some 
information seems particularly vulnerable.

Some information pretty much has to be provided locally and, in some 
cases, can be verified by the user. For example, I would likely get 
suspicious if my address gets reported as another city, but I have no 
way of verifying the usefulness of any of the URLs provided by that DHCP 
server. Even with encrypted information, it then becomes trivial to 
forge location provisioning servers, mapping servers and the rest.

There are clear trade-offs here. DHCP has well-known virtues, but also 
severe limitations. Burdening it further would seem to require a bit 
more discussion of the trade-offs and whether, in this case, this is a 
good one.

> But I am right now on a wired connection directly to my DHCP server in 
> my house. I'm not worried about authentication or encryption.  
> Enterprises are also in much tighter controlled network infrastructures, 
> so DHCP messaging is much more limited in distances and exposure.

You, as a network expert, can judge your local configuration, but your 
device is likely to travel (otherwise, the problem isn't too 
interesting). Do we expect non-expert users to make judgement calls 
about whether the rogue 802.11 AP and its attached DHCP server in your 
local Starbucks is trustworthy and flip some kind of switch to disable 
the DHCP-provided URLs?

> device, and if DHCP addresses this, then SIP isn't needed for this UA 
> (to learn the URIs). If DHCP doesn't address this, the UA seeks this 
> info via SIP.

Among other things, I'm concerned that this ordering is not always 
appropriate.

Another question is whether DHCP, as opposed to some of the 
zeroconf-style services, wouldn't be more appropriate for higher-level 
information.

Thus, stepping back, this seems to be providing a solution without 
having fully specified the assumptions and requirements. DHCP may well 
have a role to play, but this seems like a pretty quick jump.

Henning