Re: [secdir] secdir review of draft-raj-dhc-tftp-addr-option-04

--On Tuesday, December 02, 2008 03:53:58 PM -0500 John C Klensin 
<john-ietf@jck.com> wrote:

>
>
> --On Tuesday, 02 December, 2008 15:23 -0500 Ralph Droms
> <rdroms@cisco.com> wrote:
>
>> Sam - I think most of the issues in your review of
>> draft-raj-dhc-tftp-addr-option-04 can be resolved by reviewing
>> the purposes of RFC 3942 and publishing Informational RFCs
>> describing DHCP option codes.  Fundamentally, the reason to
>> publish RFCs under the process described in RFC 3942 is to
>> document existing uses of option codes in the range of option
>> codes reclaimed for assignment to new DHCP options.  The
>> concern is to avoid conflicts between new options and those
>> grandfathered ("hijacked") option codes.  As such, these RFCs
>> (usually Informational) simply document the already
>> ...
>> Responding to some of your specific points:
>>
>>>> At the very least, I suggest mandating the use of DHCP Auth
>>>> and   removing the suggestion to use option 66 to enhance
>>>> security.  And,   in the absence of a more data about how
>>>> widely used this option is,   I suggest not publishing this
>>>> document at all.
>>
>> The consensus of the dhc WG, to which I concur, is to publish
>> the document as Informational. The text in the Security
>> Considerations section about option 66 might be removed.
>> ...
>> To reiterate, it's not so much a question of whether a new
>> code point is needed; rather, according to the procedures
>> described in RFC 3942, this document gives a description of an
>> existing use of option code 150.  That option code is in use
>> ...
>
> Ralph,
>
> It seems to me that there is a middle ground here.   One can
> stick with Informational publication as the WG intends, but
> still modify the Security Considerations section, not only to
> remove the reference to option 66 (if there is consensus that is
> appropriate) but to add some explanation about why the use of
> this option without authentication might be problematic.
>
> Put differently, your objection to Sam's suggestion seems to
> hinge on "just describe the existing practice, don't try to
> change it in this document". Given RFC 3492, that is entirely
> reasonable.  But, if there are relatively obvious difficulties
> with that practice, it seems to me that documenting them would
> be helpful (indeed that not doing so borders on irresponsible).

I'm inclined to agree with John here.
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf