Subject: RE: [dhcwg] Re: I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 21 Nov 2005 09:12:53 -0500

Henning:

See below.

- Bernie 

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Saturday, November 19, 2005 6:07 PM
> To: Bernie Volz (volz)
> Cc: Ted Hardie; Ralph Droms (rdroms); DHCP discussion list; 
> [email-masked]
> Subject: Re: [dhcwg] Re: I-D 
> ACTION:draft-ietf-geopriv-dhcp-civil-07.txt
> 
> 
> > I'm fine with the above, but I think this potentially 
> crosses the line
> > with what Ted was saying: "((Server here does not mean box; 
> it means any
> > other function, even if it is within the same 
> administrative domain or
> > resident in the same box)". I think Ted's definition is a 
> bit extreme
> > and agree with your wording. I think there are valid uses of this
> > information by other "components" in special/restricted 
> circumstances
> > (such as what you specify since DHCP has nothing to do with 
> emergency
> > calling itself). And, if a client really doesn't want the 
> information to
> > be used for anything, it just doesn't supply it!
> > 
> > Perhaps that's a better way to view this ... While the information
> > should not be distributed by the receiving server, it may 
> be used for
> > functions within the server's administrative domain. A client that
> > doesn't agree to those rules of use by the server is always 
> free NOT to
> > provide the information. Therefore, clients SHOULD NOT send this by
> > default.
> 
> I agree that 'single server' is too narrow and pretty 
> useless, plus it 
> gets into trouble even with standard setups consisting of 
> relay agents 
> or a separate database backend server. 'Administrative 
> domain' works for 
> me, as it seems pretty well defined by common usage in lots 
> of protocol 
> documents.
> 
> 
> > 
> >>The DHCP client would use the [???] messages for this purpose.
> 
> Addendum: I believe this should only be permissible in unicast 
> DHCPINFORM, not in any broadcast requests, for obvious 
> privacy reasons. 
> (DHCPREQUEST seems to be commonly used in broadcast mode. If we allow 
> DHCPREQUEST, it seems too likely that lazy implementors will 
> include the 
> information in broadcast requests.)
> 
> Text:
> 
> The DHCP MUST use the unicast DHCPINFORM request for this
> purpose.  In general, the client MUST NOT broadcast or multicast
> location information.

There's also unicast DHCPREQUEST (renewals). BUT, in any case I
respectfully disagree that this provides any privacy/security. It is
trivial to enter promiscous mode on most network adapters and receive
unicasts. I just can't see any value in this. We're just fooling
ourselves into believing this adds any security. (That's also why the
server to client direction is just as suspect.)

If you want to keep this information private, DON'T SEND IT via DHCP.
Period. End of story! That's why clients shouldn't be sending this
unless configured to.

> 
> > Old location information should/must be discarded when updated by a
> > client in a subsequent transaction, when the lease is 
> released by the
> > client, or the lease expires.
> 
> Works for me.

Actually, thinking about this further, it would best be left unsaid. I
don't really see an issue in a server keeping this information for as
long as it keeps information about the client (which often extends
beyond the end of the lease, since if the client returns it is generally
believed best to give it the same address it previously had) or perhaps
about the physical locaton of the port (such as when using relay agent
information option data).

The earlier prohibition on the distribution of the information should be
sufficient. I don't think we need to require (either should or must) for
this information to be explicitly deleted when a lease expires or is
released.

> 
> As I said, I'd like to close this issue and move on. Please speak up 
> soon if you disagree with this resolution or have text suggestions.

Other than the above comments, I'm comfortable with what you propose.

> Henning

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Nov 2005 11:49:29 -0800

>Period. End of story! That's why clients shouldn't be sending this

This suggests that we might get past this by reversing Henning's original
proposal.  Do not make this a protocol error, but state in the document
that sending it from client to server is equivalent to sending a pidf-lo
with unlimited distribution and retention permitted.   Make it a SHOULD NOT,
obviously, but note that if you do send it that is the effect.

My reasoning here is that it is nigh impossible to determine what
administrative domain means in many deployments, and the agreement
to share among servers in a single administrative domains translates
into "you don't know where this is going".  If we state in the document
that it is SHOULD NOT unless the client is willing to set the ravish-me bits,
that is at least clear on what the consequences are.

How would that work for folks?
				Ted

---

From: Randall Gellens <[email-masked]>
Date: Mon, 21 Nov 2005 14:11:29 -0800

>  How would that work for folks?

This does mean that a client has to make a possibly unpleasant choice 
between not sending the information, and thus possibly making it 
harder be located in an emergency or possibly having poorer service 
in some other area, and sending it with no redistribution/retention 
limits.

I'd rather have the implied policy be do not distribute / do not 
retain, even though that raises the issue of what counts as 
distribution.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
History is strewn thick with evidence that truth is not hard to kill,
but a lie, well told, is immortal.
--Mark Twain

---

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Nov 2005 16:10:30 -0800

At 2:11 PM -0800 11/21/05, Randall Gellens wrote:
>
>This does mean that a client has to make a possibly unpleasant choice between not sending the information, and thus possibly making it harder be located in an emergency or possibly having poorer service in some other area, and sending it with no redistribution/retention limits.
>
>I'd rather have the implied policy be do not distribute / do not retain, even though that raises the issue of what counts as distribution.
>

I don't think the "poorer service in some other area" is a hard choice to make; if
they are willing to trade unknown distribution for (unknown?) optimization, they can.

I think the use of this in an emergency case is a really weak possibility, for reasons
others have already stated.
			regards,
				Ted Hardie

---

From: Randall Gellens <[email-masked]>
Date: Mon, 21 Nov 2005 16:30:30 -0800

>  they are willing to trade unknown distribution for (unknown?) 

If the use cases for client-to-server transmission are very limited, 
then we can argue that they are so marginal that a client isn't 
making a hard choice at all.  But one could also argue that if that 
is true, why include it?

I agree that client-to-server transmission needs to have a very 
clearly stated default policy for the (as Ted so charmingly puts it) 
"ravish me" bits.  I also agree that making this default 
"do-not-retain , do-not-distribute" raises the issue of what counts 
as distributing.  But that problem exists anyway, doesn't it?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Flappity, Floppity, Flip!
The Mouse on the Möbius Strip.
  The Strip revolved,
  The Mouse dissolved
In a chronodimensional skip.
--Frederick Winsor, "The Space Child's Mother Goose"
              [Simon & Schuster 1966], paperback

---

From: Randall Gellens <[email-masked]>
Date: Mon, 21 Nov 2005 21:48:29 -0800

In thinking about this some more, I realize that since we are talking 
about a SHOULD NOT behavior, it is fine to say "and if you do this, 
realize that there is no privacy associated with it."
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
f u cn rd ths, itn tyg h myxbl cd.