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

["Thomson, Martin" <[e-mail]>]

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

> -----Original Message-----
> From: Ralph Droms [mailto:[e-mail]]
> 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
> 
> 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:
> 
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dhcwg
> 

------------------------------------------------------------------------------------------------
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
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg