Subject: [dhcwg] IESG feedback on draft-ietf-dhc-concat-01.txt

From: Thomas Narten <[email-masked]>
Date: Fri, 01 Feb 2002 11:42:48 -0500

The authors have seen most of these already, but there is one question
in particular I think the WG should have a chance to comment on.

Once these issues are addressed, I expect the IESG will approve the
document in short order. (The next IESG telechat is next Thursday, so
it would be nice to have a new ID in place by then!)

1) General question. Does this document update RFC 2131? If so, the
introduction should have a sentence that says this explicitely.  More
background:

> The applicability section seems to say that an encoding agent can
> use the Option Overload option and the concat at any time.
> 
> Isn't this likely to cause interoperability problems until all DHCP decoding
> agents support the concat specification?
> It would seem more conservative to only allow concat for specific option
> codes (such as the classless route one and others that explicitly say they
> will use concat).

2) A minor complaint about the abstract:

     This draft specifies how DHCP options in a DHCP packet can be
     aggregated so that DHCP protocol agents can send options that are
     more than 255 bytes in length.

  I'd rather see "split and combined" (or similar) rather than "aggregated".
  The document also talks about using this feature in order to split
  options across packet fields, but that's not mentioned in the abstract.
  I'm not as worried about that.

  The technical summary in the draft announcement might actually be a
  much better abstract than what's there now. It is:

  This document specifies the processing rules for DHCP options that
  appear multiple times in the same message. The need to send multiple
  instances of the same option occurs when an option exceeds 255
  octets in size (the maximum size of a single option) or when an
  option needs to be broken up into smaller pieces in order that the
  pieces can be placed in the DHC packet in non-contiguous locations
  (e.g., within the "file" or "sname" field). When multiple instances
  of the same option appear in a packet, the contents of the option
  are concatenated together prior to processing.

3) Should the security considerations section refer to RFC 3118?
 
Thomas

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Feb 2002 11:07:38 -0600

I would like to avoid having these two drafts require the implementation of 
RFC3118, since RFC3118 by itself isn't very deployable.   But you're right 
that RFC3118 does address the security issue, and ought to be mentioned.  
  :'}

---

From: Thomas Narten <[email-masked]>
Date: Fri, 01 Feb 2002 12:32:14 -0500

> RFC3118, since RFC3118 by itself isn't very deployable.

Plus, has anyone even implemented it yet? Please?

On the point of 3118 deployability, there has been some private
discussion that what would be useful to have is a DHC authentication
mechanism that can use certificates, and that only authenticates the
server to the client. This would seem to be a useful deployment
scenario. Thoughts?

Also, note that the final wording in draft-aboba-dhc-domsearch-09.txt
on this point didn't require the use of 3118, but did point out its
existance. That made it through the IESG (but it also prompted the
above discussion about the desirability of a more useful/deployable
authentication mechanism).

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Mon, 04 Feb 2002 11:47:45 -0500

Mentioning 3118 (rather than requiring its use) seems right to me.  As 
Thomas points out, the text from Security Considerations of 
draft-aboba-dhc-domsearch-09.txt would provide a starting point.

Bill Arbaugh may know of an experimental implementation.  I don't know of 
any commercial implementations.

A new protocol that only authenticates servers to clients would likely be 
useful - I'd like to get feedback from anyone on the list who would deploy 
such a system if it were available.

- Ralph

---

From: Richard Barr Hibbs <[email-masked]>
Date: Mon, 04 Feb 2002 16:57:34 -0800

> -----Original Message-----
> From: Ralph Droms
> Sent: Monday, February 04, 2002 08:48
>

Ralph--

see the earlier message from Hai Ku about security issues and my reply:  he
seems to be seeking a way to authenticate servers to clients.

--Barr