Subject: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05

From: Ralph Droms <[email-masked]>
Date: Fri, 16 Jan 2009 15:16:34 -0500

"Discovering the Local Location Information Server (LIS)," http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-05 
, defines DHCPv[46] options to carry the address of a LIS to a host.   
The geopriv WG would like to get dhc WG review and feedback on the  
syntax and use of these options.  Please review the draft and reply to  
the mailing list with comments.  Thanks...

- Ralph

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

---

From: Ralph Droms <[email-masked]>
Date: Tue, 27 Jan 2009 06:41:06 -0500

I have a few comments about the details of the DHCPv4 and DHCPv6  
option syntax in this draft.

Can there be more than one fingerprint and more than one URI carried  
in the LIS-URI option?  I don't think the draft explicitly restricts  
the option.  Because the URI does not include a length field, it would  
seem to limit the option to one URI, and the fingerprint MUST come  
before the URI.  I think the text should be explicit on this point.

If I understand this restriction correctly, it may be possible to  
simplify the option syntax by assuming the order and number of fields  
in the option.  I'll defer to dhc WG members for opinions on whether  
there might be a modification to the syntax that would be more in line  
with existing options and implementations.

The DHCPv6 option doesn't have the 253 byte length restriction.  It  
would be good to mention that difference between the two option  
versions.

- Ralph

On Jan 16, 2009, at 3:16 PM 1/16/09, Ralph Droms wrote:

> , defines DHCPv[46] options to carry the address of a LIS to a  
> host.  The geopriv WG would like to get dhc WG review and feedback  
> on the syntax and use of these options.  Please review the draft and  
> reply to the mailing list with comments.  Thanks...
>
> - Ralph
>

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 27 Jan 2009 11:39:47 -0800

On Tue, Jan 27, 2009 at 06:41:06AM -0500, Ralph Droms wrote:
> Can there be more than one fingerprint and more than one URI carried in the 
> LIS-URI option?  I don't think the draft explicitly restricts the option.  
> Because the URI does not include a length field, it would seem to limit the 
> option to one URI, and the fingerprint MUST come before the URI.  I think 
> the text should be explicit on this point.
> 
> If I understand this restriction correctly, it may be possible to simplify 
> the option syntax by assuming the order and number of fields in the option. 
>  I'll defer to dhc WG members for opinions on whether there might be a 
> modification to the syntax that would be more in line with existing options 
> and implementations.

I presumed the intent was to provide only one URI.

I think that if you squint and turn your head sideways, the 'f-code,
f-length' looks like a suboption (except that the URI's f-code implies
no length octet, evidently a format size optimization).

I want to ask if the idea is to intentionally make a distinction
between 'f-code's and suboptions, such as in order to support multiple
instances of one f-code (and not provoke option concatenation as would
happen with multiple sub-option codes of the same value).

If they can be suboptions, then why not multiple regular options?
I think the answer is that the certificate is useless without the URI,
and vice versa, so if a DHCP server omitted one due to running out of
space it is better to omit both.  Containering them together solves
this neatly.

> The DHCPv6 option doesn't have the 253 byte length restriction.  It would 
> be good to mention that difference between the two option versions.

I was curious what you meant (253, not 255?), so went back to re-read
the draft.  I don't see the number 253 mentioned, nor 255!

It /does/ mention '225'.  This appears to be a typo?

My only suggestion for the mention of the option size is to refer
specifically to the 'length field value', and not to terms like 'URI
length' or 'option length', which can be misinterpreted from different
starting positions.

Otherwise I like this approach of referring to the extension of option
space as a DHCPv4 protocol feature, and not trying to reinvent its
specification.

-- 
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
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Tue, 27 Jan 2009 15:06:28 -0500

David - if, indeed, the idea is for one URI, with an optional  
fingerprint, would the following format be sensible and simpler to  
parse?

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    LIS_URI    |    Length     | Hash-Type-Len | Hash-Type   ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Hash-Type (cont.)                 ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Fprint-Len   |           Fingerprint-Value                 ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           URI                               ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           URI (cont.)                       ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where Hash-Type-Len and Fprint-Len are both either zero (no  
fingerprint) or greater than 0 (fingerprint included).

- Ralph

On Jan 27, 2009, at 2:39 PM 1/27/09, David W. Hankins wrote:

>> simplify
>> would

---

From: Bud Millwood <[email-masked]>
Date: Wed, 28 Jan 2009 09:52:19 +0100

> fingerprint, would the following format be sensible and simpler to

This option would be much better served as a subencoded option IMO. It's going 
through terrible contortions to encode both fixed-field settings and variable 
length settings.

I think a better approach would be to encode everything as suboptions, and 
then to simply dictate which options should be present under the different 
circumstances.

- Bud

-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Damien Neil <[email-masked]>
Date: Wed, 28 Jan 2009 09:52:44 -0800

> then to simply dictate which options should be present under the  

I strongly agree with this.  Suboptions are a much simpler and more  
flexible way of encoding this data.

                 - Damien

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 28 Jan 2009 22:02:05 -0500

I agree with Bud and Damien (and David) ... Defining suboptions would be
far better way to go.

Suboption 1 - URI
Suboption 2 - Fingerprint

(You could start with suboption 0, but as most sub-option users avoid
suboption 0, I would not recommend it.)

Now, if the intent is to allow multiple URI instances ... That should be
OK as I don't recall that option concatentation extends to suboptions.
Therefore, two instances of the same suboption are technically possible.
Though hopefully that is not the case as it complicates servers (and
clients) and is likely not supported by most servers today?

The same should be done for DHCPv6 (though of course the suboptions are
16-bit sub-option code and length fields).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bud Millwood
Sent: Wednesday, January 28, 2009 3:52 AM
To: [email-masked]
Subject: Re: [dhcwg] dhc WG review of
draft-ietf-geopriv-lis-discovery-05

> fingerprint, would the following format be sensible and simpler to

This option would be much better served as a subencoded option IMO. It's
going 
through terrible contortions to encode both fixed-field settings and
variable 
length settings.

I think a better approach would be to encode everything as suboptions,
and 
then to simply dictate which options should be present under the
different 
circumstances.

- Bud

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 28 Jan 2009 21:05:10 -0600

My earlier mail was bounced (forgot to subscribe).  Apologies to the moderators if this is a double-up.

> From: Thomson, Martin
> Sent: Wednesday, 28 January 2009 9:06 AM
> To: 'Ralph Droms'; David W. Hankins
> Cc: DHC WG; Richard Barnes; Winterbottom, James
> Subject: RE: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-
> 05
> 
> Hi Ralph, David,
> 
> Thanks both for your feedback.
> 
> Obviously, I missed a critical piece of text on cardinality.  The
> intent is to convey one URI with one or more fingerprints.  The URI is
> the point of the exercise, and the fingerprints describe a property of
> that URI.  A fingerprint without a URI would be pointless, so I wanted
> a format that would inherently enforce the restriction.  What Ralph
> proposes is almost identical to what is in the current draft with the
> limitation of one (or no) fingerprints.  It would also be possible to
> overload the meaning of hash-type-len so that a zero length means that
> there are no more fingerprints, which would allow for multiple
> fingerprints.
> 
> Allowing for multiple fingerprints ensures that new hash functions can
> be invented and actually used without breaking backward compatibility.
> That's the idea at least--I'm sure that our security expert friends
> would be happy to tell me otherwise if this were a bad or unworkable
> idea.
> 
> For David's benefit, concatenation would only be useful in providing
> for a longer URI.  I'll take the suggestion on restricting the total
> option length to 253 and I'll be clearer on the lack of the same
> restriction in v6.  As an aside, 225 happens to be the length to the
> URI after a SHA-1 fingerprint is included...I think :)  253 - f-
> code(1)x2 - hashlen(1) - 'sha-1'(5) -fprint-len(1) - fprint(20) =
> 224... oh well.
> 
> Cheers,
> Martin
> 
> > From: Ralph Droms [mailto:[email-masked]]
> > Sent: Wednesday, 28 January 2009 7:06 AM
> > To: David W. Hankins
> > Cc: Ralph Droms; DHC WG; Richard Barnes; Winterbottom, James;
> Thomson,
> > Martin
> > Subject: Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-
> discovery-
> > 05
> >
> > >> option to one URI, and the fingerprint MUST come before the URI.
> I
> > >> think
> > >> the option syntax by assuming the order and number of fields in
> the
> > >> option.
> > >> I'll defer to dhc WG members for opinions on whether there might
> be
> > a
> > >> modification to the syntax that would be more in line with
> existing
> > >> options
> > >> and implementations.
> > >

------------------------------------------------------------------------------------------------
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]
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 28 Jan 2009 21:21:07 -0600

The intent is to have one (only) URI, and 0..n fingerprints.

I didn't choose suboptions originally because I didn't want to have to deal with the case that the client receives multiple URIs.  I really don't want to deal with the problem of working out which fingerprint goes with which URI.  If there is a feeling that this can be addressed by the judicious application of the "MUST"-hammer, then I'm more than happy to go with suboptions.

Cheers,
Martin

> Of Bernie Volz (volz)
> Sent: Thursday, 29 January 2009 2:02 PM
> To: Bud Millwood; [email-masked]
> Subject: Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-
> 05
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 28 Jan 2009 22:40:36 -0500

So, perhaps best to have two options ...

One for the URI.

One for the fingerprints. The fingerprints option would be formatted
something like:
  <option><length><f-0-len><f-0-data>[<f-1-len><f-1-data>[...]]

The hash stuff (length and data) is either part of the f-<n>-data or is
before <f-0-len>, I'm presume the reason to have multiple fingerprints
would be to support different hashes.

This does mean a server could return a URI without a fingerprint (or
vice versa), but the client would then ignore the single option (as it
is meaningless).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomson, Martin
Sent: Wednesday, January 28, 2009 10:21 PM
To: Bernie Volz (volz); Bud Millwood; [email-masked]
Subject: Re: [dhcwg] dhc WG review of
draft-ietf-geopriv-lis-discovery-05

I didn't choose suboptions originally because I didn't want to have to
deal with the case that the client receives multiple URIs.  I really
don't want to deal with the problem of working out which fingerprint
goes with which URI.  If there is a feeling that this can be addressed
by the judicious application of the "MUST"-hammer, then I'm more than
happy to go with suboptions.

Cheers,
Martin

> Subject: Re: [dhcwg] dhc WG review of
draft-ietf-geopriv-lis-discovery-
> >     |                           Hash-Type (cont.)
...
> >     |                           URI
...
> >     |                           URI (cont.)
...
> > > space as a DHCPv4 protocol feature, and not trying to reinvent its

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 28 Jan 2009 22:03:18 -0600

Yes, the reason for multiple fingerprints is to allow for multiple hash functions.

I can't see how your suggestion avoids the problem.  It looks no different to multiple suboptions to me.

What about:

<subopt (uri)><length><LIS uri>
<subopt (fp)><length><hash name length><hash name><hash length><hash>
<subopt (fp)><length><hash name length><hash name><hash length><hash>

Or:

<subopt (uri)><length><LIS uri>
<subopt (fp)><length><hash name><0><hash>
<subopt (fp)><length><hash name><0><hash>

Preferences?

The first seems to be the more common method for variable length data.  The second is a little more frugal.  However, the both run into a little size restriction problem...for v4, the URI cannot be longer than 255 characters.  That means that we'd have to allow for concatenation of that particular suboption.  URIs have this ugly tendency to get long quickly - the current solution transparently allows for that.

That means text along the lines of:

  This option MUST have at least one instance of the URI suboption.  Multiple instances of the URI suboption are permitted to allow for URIs longer than 255(v4)/65535(v6!) characters, the value of each is concatenated to determine the final value.  The option MAY have zero or more instances of the fingerprint suboption, each containing a fingerprint that is derived using a different hash function.

Does that work for you?  Or am I being unreasonable?

Cheers,
Martin

> Sent: Thursday, 29 January 2009 2:41 PM
> To: Thomson, Martin; Bud Millwood; [email-masked]
> > > >> LIS-URI option?  I don't think the draft explicitly restricts
> the
> > > >> option.
> > > >> Because the URI does not include a length field, it would seem
> to
> > > >> limit the
> > > > and vice versa, so if a DHCP server omitted one due to running
> out
> > of

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 28 Jan 2009 23:29:48 -0500

There is a significant difference because, as I said, repeating the same
sub option multiple times is not something that has been used to date.
And, it avoids the problem of multiple URIs because per RFC 3396,
multiple instances of the same option are CONCATENATED (RFC 3396 does
not apply to sub options). This also allows you to have potentially have
much longer URIs (>255 bytes).

<option (uri)><length><LIS uri>
<option (fp)><length><hash name 1 length><hash name 1><fingerprint 1
len><fingerprint 1>[<hash name 2 length>...]

Do not put 0's to terminate the hash name. You have a length, no need
for a null byte.

This gives you very long URIs, and you could have fingerprints that are
big too (they can't be more then 255).

Though of course, having options this long will likely cause issues
between clients and servers (and possibly IP fragmentation).

I'd use the same approach for v6. Unless you feel you need hash names or
fingerprints that are longer than 255 bytes, you can probably leave
these as byte fields.

- Bernie

-----Original Message-----
Sent: Wednesday, January 28, 2009 11:03 PM

Yes, the reason for multiple fingerprints is to allow for multiple hash
functions.

I can't see how your suggestion avoids the problem.  It looks no
different to multiple suboptions to me.

What about:

Or:

Preferences?

The first seems to be the more common method for variable length data.
The second is a little more frugal.  However, the both run into a little
size restriction problem...for v4, the URI cannot be longer than 255
characters.  That means that we'd have to allow for concatenation of
that particular suboption.  URIs have this ugly tendency to get long
quickly - the current solution transparently allows for that.

  This option MUST have at least one instance of the URI suboption.
Multiple instances of the URI suboption are permitted to allow for URIs
longer than 255(v4)/65535(v6!) characters, the value of each is
concatenated to determine the final value.  The option MAY have zero or
more instances of the fingerprint suboption, each containing a
fingerprint that is derived using a different hash function.

Cheers,
Martin

> > I agree with Bud and Damien (and David) ... Defining suboptions
would
> > Now, if the intent is to allow multiple URI instances ... That
should
> > > > I think the answer is that the certificate is useless without
the
> > URI,
-----------------------------------------------------------------------
> -
-----------------------------------------------------------------------
> -

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 28 Jan 2009 22:58:23 -0600

Excuse me, I must been having another one of my "thick" moments.

As I understand, RFC 3396 concatenation occurs at a lower layer - a client that supports RFC 3396 can present arbitrarily large values to its users.  If there is indeed no established convention for concatenation of suboptions, then it might be reasonable to assume concatenation.  If you assume concatenation is the method for dealing with repeated sub-options, then your suggestion works for me.  Without that assumption, I missed what you were getting at.  (For my benefit, I'm not aware of a use of sub-options post 3396, is there no use of concatenation with any of these?)

As for size of the length fields within the fingerprint, I might be willing to go out on a limb and suggest that a >2040 bit hash is a little way off and stick with a single byte each.  Given that there are already 512 bit hashes, I think that I will play it safe and use the full 16 bits for v6.  At least with IPv4 it might have gone away by the time we care about really strong hashes, not that there isn't a workaround.

Ta,
Martin

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Thursday, 29 January 2009 3:30 PM
> > > >      0                   1                   2
> 3
> > > >      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
> 0
> > 1
> > > >
> > > > > instances of one f-code (and not provoke option concatenation
> as
> > > would
> > > > >> The DHCPv6 option doesn't have the 253 byte length
> restriction.
> > > It
> > > > >> would

---

From: Damien Neil <[email-masked]>
Date: Thu, 29 Jan 2009 00:10:13 -0800

> different to multiple suboptions to me.

I don't like multiple instances of the same suboption.  From an  
implementation standpoint they don't pose any problems, but presenting  
a sane user interface to them in a generic options handling mechanism  
is problematic.

> <subopt (fp)><length><hash name length><hash name><hash length><hash>

I would vote for making the format of the fingerprint suboption be:

	A list of:
		A tuple of:
			A length-prefixed hash name.
			A length-prefixed hash.

While I don't know of any options with exactly this format, there is  
some precedent for this.  The Policy Filter option (code 21, RFC 2132)  
is defined as a list of tuples, and the User Class option (code 77,  
RFC 3004) is defined as a list of length-prefixed strings.

Also, with option concatenation the example you give above is already  
in this format. :>

A colleague points out to me that it would save space to include the  
hash type as an integral code rather than as a string.  Whether this  
is practical for your purposes, I do not know.

> As for size of the length fields within the fingerprint, I might be  
> willing to go out on a limb and suggest that a >2040 bit hash is a  
> little way off and stick with a single byte each.  Given that there  
> are already 512 bit hashes, I think that I will play it safe and use  
> the full 16 bits for v6.  At least with IPv4 it might have gone away  
> by the time we care about really strong hashes, not that there isn't  
> a workaround.

Given that 2048 bit hashes are likely to enter common use within the  
lifetime of IPv4, I suggest using a 2-byte length prefix for the hash.

                - Damien

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 27 Jan 2009 16:06:01 -0600

Hi Ralph, David,

Obviously, I missed a critical piece of text on cardinality.  The intent is to convey one URI with one or more fingerprints.  The URI is the point of the exercise, and the fingerprints describe a property of that URI.  A fingerprint without a URI would be pointless, so I wanted a format that would inherently enforce the restriction.  What Ralph proposes is almost identical to what is in the current draft with the limitation of one (or no) fingerprints.  It would also be possible to overload the meaning of hash-type-len so that a zero length means that there are no more fingerprints, which would allow for multiple fingerprints.

Allowing for multiple fingerprints ensures that new hash functions can be invented and actually used without breaking backward compatibility.  That's the idea at least--I'm sure that our security expert friends would be happy to tell me otherwise if this were a bad or unworkable idea.

For David's benefit, concatenation would only be useful in providing for a longer URI.  I'll take the suggestion on restricting the total option length to 253 and I'll be clearer on the lack of the same restriction in v6.  As an aside, 225 happens to be the length to the URI after a SHA-1 fingerprint is included...I think :)  253 - f-code(1)x2 - hashlen(1) - 'sha-1'(5) -fprint-len(1) - fprint(20) = 224... oh well.

Cheers,
Martin

> Cc: Ralph Droms; DHC WG; Richard Barnes; Winterbottom, James; Thomson,
> Martin

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 29 Jan 2009 14:37:25 -0800

> Excuse me, I must been having another one of my "thick" moments.

No, DHCPv4 is just that hard.  The sensation you are perceiving is
perfectly normal, and is often accompanied by nausea and in extreme
cases vomiting.  Do not operate any heavy machinery.

I have found it helps sometimes to put it away and come back to it
after the caffeine has reached full potency.

And don't go swimming for at least an hour.

> As I understand, RFC 3396 concatenation occurs at a lower layer - a client
> that supports RFC 3396 can present arbitrarily large values to its users.
> If there is indeed no established convention for concatenation of suboptions,
> then it might be reasonable to assume concatenation.

I think older ISC DHCP software (3.0-) concatenates duplicates in sub
option spaces.  The newer software (3.1+?) that was updated for v6 and
VSIO only does the concat thing on DHCPv4 root options.  All other
'option spaces' (we call them) default to not having the flag enabled
and so do not perform concats (on the basis that the behaviour was not
described in the relevant RFC for those options).

So from my point of view, you can specify which behaviour you want in
the draft.

But I don't actually know what other software does for these spaces.

> If you assume concatenation is the method for dealing with repeated
> sub-options, then your suggestion works for me.  Without that assumption,
> I missed what you were getting at.  (For my benefit, I'm not aware of a
> use of sub-options post 3396, is there no use of concatenation with any of
> these?)

If there is, I need to be educated too!  The only space we currently
support where multiple options concatenate is the root DHCPv4 options.

All other v4 encapsulated and all v6 "spaces" are non-concat.

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 29 Jan 2009 18:11:15 -0600

> No, DHCPv4 is just that hard.
 
...but it LOOKS so easy!

It seems like there is fairly strong support for the following format (in pseudo-ABNF rather than those lovely pictures):

  URI-sub-opt(1) = sub-opt-code len URI
  FPrint-Sub-opt(2) = sub-opt-code len *( FPrint )
  FPrint = hash-type-len hash-type hash-len hash
                   
For v4 all sub-option codes and lengths are one byte.
For v6 all sub-option codes and lengths are two bytes.

Repeated sub-options are concatenated.

Yes, I value consistency over the ability to support arbitrary length hashes.  That means that when a 2048bit hash is (inevitably) developed that people actually want to use with DHCPv4, a new variant of the concatenation rule is minted:

  Hash functions that generate hashes longer than 2040bits can be included by splitting the hash and relying on concatenation.  The value of hashes that have the same hash-type are concatenated, allowing for arbitrary length values.

I considered using a single option code for the hash type, but there are already two IANA registries for hash functions, I am loath to add another.  It would solve a few problems by simply consuming a sub-opt code for each hash code, avoiding that last bit of dodgy concatenation.  Thoughts?

Cheers,
Martin

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 30 Jan 2009 12:53:57 -0500

>Repeated sub-options are concatenated.
 
NO! Again, DHCPv4 options are concatenated. Suboptions are (to date)
NOT. Read RFC 3396! Thus, if you specified this behavior, it would be
specific to this option's suboptions which will mean that you need
additional support that doesn't yet exist in servers or clients (and
there is a greater risk that someone will miss it).

I'm not sure why you're against using two options?

Do you expect to add additional [sub-]options in the future?

>It would solve a few problems by simply consuming a sub-opt code for
each hash code, avoiding that last bit of dodgy concatenation.

This would be one argument to use suboptions, but it also seems to me
that a more efficient mechanism is to just have a hash-type field octet.
And, what's wrong with using something like the PGP Hash Algorithms (see
http://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml).
You could always restrict the values supported in your draft to those
that you need at present. (Or, if this one isn't to your liking, what
about the 'other' registry you found -- not sure what it is, I didn't
search for it either.)

Of course, if you wanted to the client and server to be able to
negotiate which hash was supported, that might require a
hash-type-request suboption. But you could also do that with the option
-- the client could send the option to the server only specifying the
hash-type it supported (something like <hash-type><0-length for
hash><0-length for fingerprint>[repeated for each hash-type supported]).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomson, Martin
Sent: Thursday, January 29, 2009 7:11 PM
To: David W. Hankins
Cc: [email-masked]
Subject: Re: [dhcwg] dhc WG review of
draft-ietf-geopriv-lis-discovery-05

...but it LOOKS so easy!

It seems like there is fairly strong support for the following format
(in pseudo-ABNF rather than those lovely pictures):

Yes, I value consistency over the ability to support arbitrary length
hashes.  That means that when a 2048bit hash is (inevitably) developed
that people actually want to use with DHCPv4, a new variant of the
concatenation rule is minted:

  Hash functions that generate hashes longer than 2040bits can be
included by splitting the hash and relying on concatenation.  The value
of hashes that have the same hash-type are concatenated, allowing for
arbitrary length values.

I considered using a single option code for the hash type, but there are
already two IANA registries for hash functions, I am loath to add
another.  It would solve a few problems by simply consuming a sub-opt
code for each hash code, avoiding that last bit of dodgy concatenation.
Thoughts?

Cheers,
Martin

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Jan 2009 11:11:59 -0700

> I'm not sure why you're against using two options?

This discussion provides evidence for the fairly obvious conclusion  
that in the minds of implementors, there is a certain degree of  
ambiguity about whether suboptions are concatenated, regardless of  
what it says in RFC3396 (I do agree with your reading, but that's not  
the point).   Further, as I think Damien pointed out, no other option  
in DHCPv4 repeats suboptions to provide additional configuration  
(although we've talked about doing this with NTP).   So using two  
options *also* requires additional code.

The key point in the discussion here seems to be about cryptographic  
checksums.   An option spec that assumes these will never be larger  
than 255 bytes is really seriously not future-proof.   So I agree with  
Martin's reasoning--support for concatenation of this option is  
required.

This brings us back full-circle to the assertion that Bud made and  
that Damien and Bernie agreed to, that encoding this option as a  
series of suboptions is easier than encoding it as an encapsulation.    
I think that turns out not to be true here.   In fact, historically  
we've done just fine encoding options like this as straight options.    
It is the precedent for encoding things like this as an encapsulation  
that is new, and problematic.   So I think perhaps we were a bit too  
hasty in going down that path.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 30 Jan 2009 13:43:16 -0500

>So using two options *also* requires additional code. 

I'm not sure I understand this. On the client, yes, but there is
additional code required anyway to decode this option (or options)
regardless?

Perhaps it is clear from a detailed reading the of the draft or from
other geopriv documents referenced, but one question that would help to
clarify this is what level of processing is required in the DHCP server
to support these options?

Are these like many options which are just statically configured (for
some subset or all clients), such as is the DNS server address or DNS
search list? Or does the DHCP server have to have special processing for
each client transactions?

If support on the DHCP server only requires static configuration, then
we need to keep this within the realm of what is potentially reasonable
to be configured in such a manner (if there are new complex
configuration requirements, it just means its adoption may be much
longer in coming).

If the DHCP server must construct the option during processing (much
like the AUTH option - DHCPv6 AUTH (RFC 3315) or DHCPv4 AUTH (RFC
3118)), then a complex form is acceptable.

My understanding is that this is statically configured, in which case we
do want to keep it within the existing configuration types to expedite
its support. Hence, keeping the format of the option(s) and or
sub-option(s) to those in David's
http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-03.
txt is probably best?

---

Note also that:

   The DHCP LIS URI option includes an optional authentication method
   for the LIS.  If an https: URI is provided for the LIS, the option
   can optionally include a fingerprint of the server certificate.  The
   device can use this fingerprint to authenticate the server.

So, this seems to imply that one could have JUST the URI (no
hash/fingerprint information). So, making it very easy to support at
least that minimal capability by configuration a simple STRING formatted
option, seems to me a BIG WIN. Most servers have the capability to
extend the option support to new options - so this is a matter of a few
minutes of work?

For the hash/fingerprint information, it seems to me that it isn't clear
how this would be entered into a server's configuration (assuming it is
static). Just as a series of hexadecimal bytes? Perhaps some discussion
and thought as to how this information is provided to the server is
warranted? 

>From the following in the document:

   The mechanism to generate a fingerprint is to take the hash of the
   DER-encoded certificate using a cryptographically strong algorithm.
   The hash algorithm used for generating the fingerprint is identified
   by a textual name taken from the IANA registry "Hash Function Textual
   Names" defined in [RFC4572].  Implementations MUST support SHA-1 as
   the hash algorithm and use the label "sha-1" to identify the SHA-1
   algorithm.

It seems to me that a "good" technique would be to configure the server
with the desired hash type(s) and the file. The server (at some point)
would then need to generate the hash. This would also mean that it would
have to construct the option using this data. In that case, having a
complex option (or sub-options) may be OK as the server needs special
support for this -- it isn't like one of the simple options.

But, again, separating out the security information into a separate
option from the URI allows (almost) any existing server to provide an
UNAUTHENTICATED URI. Providing authenticated URIs would then require
manually generating the hash and configuring the hexadecimal values into
the server OR special code in the server to read the file and generate
the hash value (perhaps some pre-processor does that for the server so
the server just gets the hexadecimal values).

Perhaps I've misunderstood all this and there's more to the story.

---

One also has to ask whether this is the best way to provide some of this
data? If the hash/fingerprint is 512 bytes, will DHCP really be the best
way to communicate this? This would double (or triple) the size of the
DHCP packet, potentially forcing fragmentation.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Jan 2009 12:26:35 -0700

> additional code required anyway to decode this option (or options)

Damien pointed out to me privately that I may have been responding to  
a proposal that you had not made.   I had understood you to be talking  
about expressing each datum as a separate suboption, when in fact  
Damien said (and it seems you agree) that you were talking about top- 
level options.   So my observations about what you said don't really  
apply.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 30 Jan 2009 15:55:07 -0500

Hi Ted:

Not an issue ... The discussion is evolving and some of my earlier
opinions have changed as I learn more about this. Originally I had
suggested suboptions, but as the potential size of the suboptions and
the semantics of their use has become clear, I'm no longer in favor of
that -- I instead think separate options are more appropriate.

- Bernie