[dhcwg] Adam Roach's No Objection on draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with COMMENT)

Adam Roach <adam@nostrum.com> Thu, 11 October 2018 00:01 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E14B312D7F8; Wed, 10 Oct 2018 17:01:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dhc-dhcp4o6-saddr-opt@ietf.org, Bernie Volz <volz@cisco.com>, dhc-chairs@ietf.org, volz@cisco.com, dhcwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.86.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153921610191.5820.17903104275311003818.idtracker@ietfa.amsl.com>
Date: Wed, 10 Oct 2018 17:01:41 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/byGpvqZiHV4olpdJL62sKXusl_Q>
Subject: [dhcwg] Adam Roach's No Objection on draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Oct 2018 00:01:42 -0000

Adam Roach has entered the following ballot position for
draft-ietf-dhc-dhcp4o6-saddr-opt-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-dhcp4o6-saddr-opt/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thanks to everyone involved for the work they did on this document.

I agree with Alissa's request for the addition of privacy considerations.

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

§7.2.1:

>  the client's IPv6 will change.  E.g., if there is an IPv6 re-

Nit: "...the client's IPv6 address will change."

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

§9:

>  For such an attack to be effective, the attacker would need to know
>  both the client identifier and active IPv4 address lease currently in
>  use by another client.  The risk of this can be reduced by using a
>  client identifier format which is not easily guessable, e.g., by
>  including a time component for when the client identifier was
>  generated (see [I-D.ietf-dhc-rfc3315bis] Section 11.2).

I might be missing something here, but my understanding is that DHCP isn't
confidential, and so attackers on the same segment might be able to observe
another client's identifier and IPv4 address in the DHCP traffic itself
(depending on the nature of the networking equipment). Even if
this cannot be easily mitigated, I think it's worth mentioning.

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

§10:

>  IANA is requested to update the entry for DHCPv6 Option S46_BR (90)
>  in the Option Codes table at https://www.iana.org/assignments/
>  dhcpv6-parameters as follows:
>
>  Old entry:
>
>  |    90 | S46_BR                  | No                  | No        |
>
>  New entry:
>
>  |    90 | S46_BR                  | Yes                 | No        |

This is a somewhat unconventional way to represent IANA actions. This format
does not make sense in a vacuum; and, more importantly, and will lose meaning
in the case that the corresponding registry table is ever expanded. I also
note that the name is incorrect (S46_BR instead of OPTION_S46_BR), and that
the Reference column is omitted (which is relevant, as I believe the intenion
is to instruct IANA to add this document to the list of references).  Please
consider reformatting as:

  Old Entry:

    Value:             90
    Description:       OPTION_S46_BR
    Client ORO:        No
    Singleton Option:  No
    Reference:         [RFC7598]

  New Entry:

    Value:             90
    Description:       OPTION_S46_BR
    Client ORO:        Yes
    Singleton Option:  No
    Reference:         [RFC7598] [RFCxxxx]


>  IANA is also requested to make a new entry for
>  OPTION_S46_BIND_IPV6_PREFIX (TBD1) in the Option Codes table at
>  https://www.iana.org/assignments/dhcpv6-parameters:
>
>  |  TBD1 |OPTION_S46_BIND_IPV6_PREFIX| Yes               | Yes       |

Similarly:

    Value:             TBD1
    Description:       OPTION_S64_BIND_IPV6_PREFIX
    Client ORO:        Yes
    Singleton Option:  Yes
    Reference:         [RFCxxxx]