Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 25 Apr 2007 06:50:28 -0700

But how does my application access it?

DHCP is not something that an application layer program should be allowed to perform. It is a security issue. For good reason performing DHCP operations requires privileges beyond mere network connectivity on Windows.

That is why configuring application programs from DHCP never caught on.  

> -----Original Message-----
> From: John Schnizlein [mailto:[email-masked]] 
> Sent: Sunday, April 22, 2007 6:41 PM
> To: David W. Hankins
> Cc: GEOPRIV WG; [email-masked]
> Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 
> Working Group Hums
> 
> The reason that DHCP is appropriate for information about the 
> location of the host is that the scope of DHCP administration 
> usually does match the local network to which the host is 
> attached.  Location is local information.
> 
> John
> 
> On Apr 20, 2007, at 3:38 PM, David W. Hankins wrote:
> 
> > The point is that the ISO L(x) is not what one considers 
> when judging 
> > wether or not a certain configuration value "would make a good band 
> > name.  I mean DHCP option."
> >
> > What we (strive to) consider instead is the administrative scope of 
> > the configuration information, and wether it matches common and 
> > practical use of DHCP.
> 
> 
> On Apr 19, 2007, at 7:47 PM, David W. Hankins wrote:
> > On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, 
> Phillip wrote:
> >> DHCP is a layer 3 technology that talks directly to layer 2.
> >
> > DHCP is a technology that dynamically configures hosts.
> >
> > If a host has a configuration knob that might reasonably 
> and properly 
> > be set by the systems administrator or the network you are 
> presently 
> > attached to, then it is reasonable and proper to configure it via 
> > DHCP.
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

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

've come 
to consensus on whether this is the perferred approach.]

(B) Remove the routing-query-allowed element and allow a user to mark 
[using some reasonable syntax] a conveyed location as either "intended 
for routing", "intended for the end-point" or "intended for both" (where 
the default behaivor is "intended for both").

[This would add no additional length to the SIP message in the common 
case where the location can be used for either routing or by the 
end-point, but allows the user to explicitly indicate his desires if 
necessary.]

Given my understanding of the discussion, it seems that to move forward 
we need to try reach consensus on whether (A) or (B) is the perferred 
technical choice [which I believe is possible] and postpone theological 
discussions on which there is little hope of reaching consensus.

- Matt Lepinski :->

>
> Henning
>
> On May 9, 2007, at 5:29 PM, Richard Barnes wrote:
>
>> Ok, we're back to this:
>>
>> The difference is in whether the proxy is a Recipient of the LO.   If 
>> it passes the bits along blindly, without interpreting them,  then it 
>> has not, for privacy purposes, received the LO.  This is  why you can 
>> pass an LO with retransmission-allowed=no through a  
>> store-and-forward network (be it SIP, email, whatever).
>>
>> If the proxy reads and acts on the LO, then it becomes a Location  
>> Recipient, and is bound by the privacy rules in the LO (and  
>> possibly, as we've discussed, in the SIP header).  Then, if  
>> retransmission-allowed=no, that indicates that the proxy should not  
>> send the LO -- or the LI within it -- to another party.  And, as  
>> I've discussed before, there's some flexibility in "party", but  
>> there's no sensible definition that allows arbitrary LoST queries.
>>
>> The trouble with -conveyance is that it allows both UASs and  proxies 
>> to be the recipients of the location, even though the UAC  might want 
>> to send different locations with different privacy rules  to these 
>> two different sets of recipients.  I think indicating  destinations 
>> (with header fields or tags) is a simple way to  disambiguate this.
>>
>> --Richard
>
>
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
>

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 25 Apr 2007 06:50:28 -0700

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 25 Apr 2007 11:25:15 -0700

> But how does my application access it?

The "proper" way from my point of view would be to read from your
system's option cache, so whatever DHCP the system does filters
down to applications.

> DHCP is not something that an application layer program should be allowed
> to perform.

Amen, brother!  But, you're preaching to the choir.

Macromedia Flash Proxy whatsimahoosits...sends a DHCPINFORM.
Doesn't set ciaddr, chaddr, htype or hlen.  Let me tell you,
becoming "similarly compatible" to this as other servers
evidently are was not an experience I would like to repeat.  [1]

Microsoft Industry Update Control.  Refuses to stop sending
DHCPINFORMs until any server responds with the WPAD option,
without placing that option on the PRL.  [2]

> It is a security issue. For good reason performing DHCP operations
> requires privileges beyond mere network connectivity on Windows.

I expect it doesn't, actually, as the relevant flash proxy bits
are sufficiently nonpriveleged.  That's via a "dot net" facility,
I've been told.  I see no reason to hold the system's option cache
secret from applications, when taht cache is got by a packet that
anyone can sniff off the wire.  I understand that applications
such as Opera, Firefox, and ID [3], are said to digest at least
one option in this way.

But, I'm not a "Windows guy," so if someone knows how that actually
works it would be helpful.  I just know that it works from the
outside looking in.

> That is why configuring application programs from DHCP never caught on.  

The reason you have made this statement is false.

But that doesn't, on its own, mean that the conclusion is false.  I
would say it certainly is not mainstream, but it is pervasive.

[1] http://marc.info/?l=dhcp-server&m=113466843320099&w=2

[2] http://marc.info/?l=dhcp-server&m=110928450802695&w=2

[3] http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol

[4] http://www.ietf.org/proceedings/99nov/I-D/draft-ietf-wrec-wpad-01.txt

    "The DHCP option code for WPAD is 252 by agreement of the DHC working 
     group chair."

    Possible alternative text:

    "I can't believe it's not IANA!"

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv