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

Benjamin Kaduk <kaduk@mit.edu> Wed, 10 October 2018 14:59 UTC

Return-Path: <kaduk@mit.edu>
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 EC6B1130E96; Wed, 10 Oct 2018 07:59:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
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: <153918359096.5791.17237672018576211772.idtracker@ietfa.amsl.com>
Date: Wed, 10 Oct 2018 07:59:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/ppXMmqjWPxtY26QTCTUKYv99tDY>
Subject: [dhcwg] Benjamin Kaduk'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: Wed, 10 Oct 2018 14:59:51 -0000

Benjamin Kaduk 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:
----------------------------------------------------------------------

Section 7

   It is also a prerequisite that the client has already learned a
   suitable IPv6 prefix to use for its local softwire endpoint using
   DHCPv6, RA/PIO or another mechanism.

I think I'm confused.  Is the OPTION_S46_BIND_IPV6_PREFIX option a way to
obtain the "suitable IPv6 prefix" above?  If so, then "prerequisite" may
not be the best word to use here.

Section 7.2.1

   Across the lifetime of the leased IPv4 address, it is possible that
   the client's IPv6 will change.  E.g., if there is an IPv6 re-
   numbering event.

nit: The last sentence is a sentence fragment.

Section 9

With address-binding mechanisms such as these we also try to consider the
possibility of binding an unexpected address to an unsuspecting recipient,
e.g., to direct a large flow of traffic to a victim unable to process it
all.  I did not see an immediate way for an attacker to do this, since it
would seem like it would either require DHCPv4 to assign the same address
twice or allow a duplicate v6/v4 softwire binding, but I am not sure I have
the full picture in my head yet.  It would be good to include some text on
this class of attacks, even if it is just "redirecting existing flows to an
unsuspecting victim is not possible because <reason>".