Re: [dhcwg] Alissa Cooper's No Objection on draft-ietf-dhc-dhcpv4-active-leasequery-06: (with COMMENT)

[Kathleen Moriarty <[e-mail]>]

On Wed, Sep 30, 2015 at 7:29 PM, Kathleen Moriarty
<[e-mail]> wrote:
>
>
> Sent from my iPhone
>
>> On Sep 30, 2015, at 6:56 PM, Alissa Cooper <[e-mail]> wrote:
>>
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-dhc-dhcpv4-active-leasequery-06: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-active-leasequery/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I think it would help to explain the rationale for having both secure and
>> insecure modes supported.
>>
>> In sections 7.2, 8.1, and 9, this is a bit of a strange layering of
>> normative requirements:
>>
>> The recommendations in [RFC7525] SHOULD be followed when negotiating
>>   this connection.
>>
>> If you were going to use normative language here I think this would more
>> appropriately be a MUST, but I would actually recommend something along
>> the lines of "The recommendations in [RFC7525] apply" since the
>> recommendations contained therein vary in their normative strength.
>> Perhaps the security ADs have a preferred formulation, I'm not sure.
>
> In my opinion, RFC7525 only applies in some situations.

I probably should have said that I am okay with the SHOULD here,
rather than the statement I left before... I was thinking more about
use of DHCP on internal networks prior to NAT translation or with
multiple levels of security including access controls and
firewalls/gateways/IPS (which will translate and possibly record the
addresses assigned anyway).  Looking at the full picture is important.
Ideally, these sessions would be encrypted, but as Brian pointed out,
the database is accessible (protected with controls) on the same
network.  The infrastructure typically via a switch (not shared
Ethernet), so traffic is directly between the server and DHCP client.
I'm okay with the SHOULD and would rather have the secure mode when
confidentiality is needed (my preference in that case is more than
OS).

> If DHCP is being used in a local network, there are other security controls in place.  As such, a risk assessment of the actual threat to determine if secure mode is needed would be fine.  Having made this operational decision on highly secure networks, I think it's okay to allow for flexibility to look at the bigger picture and determine the appropriate set of controls.  Since the draft provides a secure option, I think that's enough.
>
> Thanks,
> Kathleen
>
>>
>>



-- 

Best regards,
Kathleen