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

From: John Schnizlein <[email-masked]>
Date: Mon, 12 Sep 2005 16:44:26 -0400

Begin forwarded message:

> From: [email-masked]
> Date: September 12, 2005 3:50:02 PM EDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Geopriv] I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Geographic Location/Privacy Working  
> Group of the IETF.
>
> 	Title		: Dynamic Host Configuration Protocol (DHCPv4
>                           and DHCPv6) Option for Civic Addresses
>                           Configuration Information
> 	Author(s)	: H. Schulzrinne
> 	Filename	: draft-ietf-geopriv-dhcp-civil-07.txt
> 	Pages		: 22
> 	Date		: 2005-9-12
> 	
> This document specifies a Dynamic Host Configuration Protocol (DHCPv4
>    and DHCPv6) option containing the civic location of the client or  
> the
>    DHCP server.  The Location Configuration Information (LCI) includes
>    information about the country, administrative units such as states,
>    provinces and cities, as well as street addresses, postal community
>    names and building information.  The option allows multiple
>    renditions of the same address in different scripts and languages.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil 
> -07.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of  
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the  
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-geopriv-dhcp-civil-07.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-geopriv-dhcp-civil-07.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Nguyen Dinh Nam <[email-masked]>
Date: Tue, 13 Sep 2005 10:31:15 +0700

* This draft defines a set of CAtypes. I think that using (Relative)
Object Identifier to identify CAtypes may be a good alternative to the
IANA registry.

* Using ASN.1 to define this protocol make it much clearer, and it's
easy to define formats of CAvalues when necessary. For example, the
value of CAtype 27 (floor) should be numerical instead of an arbitrary
value. And ANS.1 is extremely helpful when implementing the protocol.

* The author mentioned a security consideration: "Where critical
decisions might be based on the value of this GEOCONF_CIVIC option".
If the DHCP server is authenticated separatedly from the
GEOCONF_CIVIC, it can fake random GEOCONF_CIVIC options because no
binding between the DHCP server's identity and GEOCONF_CIVIC options
which the DHCP server can provide. If GEOCONF_CIVIC options are
authentic, it'll help separate good DHCP server from rogue ones. For
example, in the dorm, the authentic GEOCONF_CIVIC options don't allow
a famous cafe shop next to the dorm (where many students visit
regularly, and they let the DHCP server there assigns configurations
automatically) to advertise itself as the dorm's DHCP server.

This draft is closely related to what I've been working on -
authenticating ARP and DHCP so I would like to help - if the author
agrees.

Regards,
Nam

---

From: Nguyen Dinh Nam <[email-masked]>
Date: Tue, 13 Sep 2005 17:36:37 +0700

This email didn't seem to reach the mailing list so I resend it, sorry
if it's duplicated
-----

* Using ASN.1 to define this option will make it clearer, and it's
easy to define formats of CAvalues when necessary. For example, the
value of CAtype 27 (floor) should be numerical instead of an arbitrary
value. And ANS.1 is extremely helpful when implementing the protocol.
However, ASN.1 may be overkill.

Regards,
Nam

---

From: Nguyen Dinh Nam <[email-masked]>
Date: Tue, 13 Sep 2005 22:09:25 +0700

On 9/13/05, Henning Schulzrinne <[email-masked]> wrote:
> Thanks for your comments. I will point out that this draft has been in
> working group and IETF last call already. It has been available for
> review since December 2002, i.e., almost three years ago. Thus,
> unrolling many of the agreements that two working groups (GEOPRIV and
> DHCP) have arrived at since one could do things differently seems less
> attractive if the IETF attaches any value to ever completing an effort.
>
> IANA has to register these mapping in either event. We could make the
> same argument for any numeric constant in any protocol. As far as I
> know, no other DHCP option has chosen this approach.
>
> Again, I'm sorry to say that I fail to see the advantage. ASN.1 would
> likely mean a variable-length identifier, and one that is significantly
> longer than one byte. During the design, space efficiency was a prime
> consideration.
>
> As you point out, this is a generic DHCP problem which, I believe,
> should be solved generically rather than for one particular DHCP option.
> If the DHCP working group can agree on such a mechanism, this option,
> as well as many others, benefit, but it seems unhelpful to delay
> completion of this effort by waiting for a much more ambitious undertaking.

Sorry, I was brand new to the DHCWG so I was too eager to give comments :)

Currently, the DHCP authentication option is available (although not
yet implemented). A shared secret schema is defined and I think that a
public key authentication (PKA) schema will be available, sooner or
later. It's important because only the PKA schema can help people
authenticate unknown DHCP servers, just like the case of HTTPS
websites.

So I assume that we will have the Certification Authority to sign the
DHCP server's X.509 certificate. This certificate SHALL limit the DHCP
server from providing random options to clients. Certainly, the CA
SHOULD not sign all options, so it's *not a generic problem*, each
option has to get its own consideration! And I think that your
GEOCONF_CIVIC will get top priority because it may be the most
important (if not the only one) to recognize rogue DHCP servers.

If you agree with my arguments, then the cooperation between
GEOCONF_CIVIC and X.509 is important. So using OID to identify CAtypes
may have a benefit: we don't have to invent some identifiers that
existed, then create the mapping between them (OID and the IANA
registry), such as
2.5.4.6 countryName <--> CAtype=0
2.5.4.8 stateOrProvinceName <--> CAtype=1
...
Almost everything has trade-offs, surely, the disadvantage is that OID
is that it's bigger.
Just my 2 cents.
Nam
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Nguyen Dinh Nam <[email-masked]>
Date: Wed, 14 Sep 2005 01:46:35 +0700

I found that I got it wrong. Initially, I thought that the public key
authentication mechanism SHALL rely on your option to detect rogue
servers, but for now, I think that it's the bad practice.

Certainly, a certificate can be crafted to contain everything
GEOCONF_CIVIC does - in the subject (RDNSequence - RFC 2459) -
providing the superset of features plus everything is authentic, but
it's out of the scope of the comments of your proposal.

Sorry for wasting your time,
Nam

> Since there doesn't seem to be a DHCP WG Internet draft on your
> proposal, I think I will refrain from further comments as I'm likely to
> miss the point of your propoal.

---

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

Nguyen Dinh Nam wrote:
> This email didn't seem to reach the mailing list so I resend it,

> sorryif it's duplicated----- * This draft defines a set of CAtypes. I
> think that using (Relative)Object Identifier to identify CAtypes may
> be a good alternative to theIANA registry.

Why would this help?

> * Using ASN.1 to define this option will make it clearer, and
> it'seasy to define formats of CAvalues when necessary. For example,
> thevalue of CAtype 27 (floor) should be numerical instead of an
> arbitraryvalue. And ANS.1 is extremely helpful when implementing the
> protocol.However, ASN.1 may be overkill.

> * The author mentioned a security consideration: "Where
> criticaldecisions might be based on the value of this GEOCONF_CIVIC
> option".If the DHCP server is authenticated separatedly from
> theGEOCONF_CIVIC, it can fake random GEOCONF_CIVIC options because
> nobinding between the DHCP server's identity and GEOCONF_CIVIC
> optionswhich the DHCP server can provide. If GEOCONF_CIVIC options
> areauthentic, it'll help separate good DHCP server from rogue ones.
> Forexample, in the dorm, the authentic GEOCONF_CIVIC options don't
> allowa famous cafe shop next to the dorm (where many students
> visitregularly, and they let the DHCP server there assigns
> configurationsautomatically) to advertise itself as the dorm's DHCP
> server. This draft is closely related to what I've been working on
> -authenticating ARP and DHCP so I would like to help - if the
> authoragrees.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 13 Sep 2005 14:01:37 -0400

> Sorry, I was brand new to the DHCWG so I was too eager to give

Comments are always helpful, but there is a danger of delaying any draft 
forever - we could go about re-visiting design decisions forever, 
particularly those involving codin.

> Currently, the DHCP authentication option is available (although
> notyet implemented). A shared secret schema is defined and I think
> that apublic key authentication (PKA) schema will be available,
> sooner orlater. It's important because only the PKA schema can help
> peopleauthenticate unknown DHCP servers, just like the case of
> HTTPSwebsites.

Since I don't track all the work items within the DHCP working group, I 
don't know what status this work has within the WG.

> So I assume that we will have the Certification Authority to sign
> theDHCP server's X.509 certificate. This certificate SHALL limit the
> DHCPserver from providing random options to clients. Certainly, the
> CASHOULD not sign all options, so it's *not a generic problem*,
> eachoption has to get its own consideration! And I think that
> yourGEOCONF_CIVIC will get top priority because it may be the
> mostimportant (if not the only one) to recognize rogue DHCP servers.

I'm sorry to say that if each option has its own signing issues, then 
the mechanism may not be particularly suitable for DHCP.

> If you agree with my arguments, then the cooperation
> betweenGEOCONF_CIVIC and X.509 is important. So using OID to identify
> CAtypesmay have a benefit: we don't have to invent some identifiers
> thatexisted, then create the mapping between them (OID and the
> IANAregistry), such as2.5.4.6 countryName <--> CAtype=02.5.4.8
> stateOrProvinceName <--> CAtype=1...Almost everything has trade-offs,
> surely, the disadvantage is that OIDis that it's bigger.Just my 2
> cents.Nam

I fail to see the helpfulness of such a mapping.

Regards,

Henning

---

From: Ralph Droms <[email-masked]>
Date: Mon, 19 Sep 2005 13:15:27 -0400

Following up on the announcement of the publication of draft-ietf-
geopriv-dhcp-civil-07.txt, which John Schnizlein forwarded to the
mailing list, the -04 revision of this draft was reviewed by the dhc WG
several months ago, in a joint last call with the geopriv WG.  The draft
was then submitted to the IESG.  draft-ietf-geopriv-dhcp-civil-07.txt
includes changes in response to comments received during the IESG
review.  Because this specification involves DHCP, the dhc WG has an
opportunity for a final review of the draft.  Accordingly, if you have
any comments about the draft, please respond by 1700EDT on Thu, 9/22.  I
will forward any responses to the IESG and the geopriv WG chairs.

I prepared a diff of the -04 and -07 versions, but haven't sent it with
this announcement because it's about 200KB (using side-by-side rfcdiff
tool).  Let me know if you'd like me to send you an individual copy.

- Ralph

---

From: Ted Hardie <[email-masked]>
Date: Mon, 19 Sep 2005 10:16:39 -0700

Thanks to Ralph for forwarding this to the group.  There may be a further revision,
however, as David Kessens still has an outstanding discuss which is not yet
resolved.  David has agreed to update the discuss text to indicate more clearly
the points of discussion but has not yet done so.  Until that is complete, it is
not clear whether further changes to this aspect of the document will be requested.
Your review of this draft is, of course, appreciated, but please be aware that there may
be a second request.
			regards,
				Ted Hardie

At 1:12 PM -0400 9/19/05, Ralph Droms wrote:
>Attachment converted: Macintosh HD:geopriv-dhcp-diff 1.html (TEXT/«IC») (0033FA45)