[dhcwg] Eric Rescorla's Discuss on draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with DISCUSS and COMMENT)

Eric Rescorla <ekr@rtfm.com> Thu, 11 October 2018 02:12 UTC

Return-Path: <ekr@rtfm.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 B3A31130E08; Wed, 10 Oct 2018 19:12:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dhc-dhcp4o6-saddr-opt@ietf.org, Bernie Volz <volz@cisco.com>, volz@cisco.com, dhcwg@ietf.org, dhc-chairs@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.86.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153922397672.5804.489295934152877724.idtracker@ietfa.amsl.com>
Date: Wed, 10 Oct 2018 19:12:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/BjaXuvtJabXwpoPBEDZPN_ZUAAA>
Subject: [dhcwg] Eric Rescorla's Discuss on draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with DISCUSS and 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 02:12:57 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-dhc-dhcp4o6-saddr-opt-06: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5110


I believe there are security issues as detailed in this review.

DETAIL
S 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).

This doesn't seem like a very strong defense. At minimum you need an
analysis of the level of entropy.

I note that an on-path attacker (as RFC 3552 requires us to consider)
will have no real problem with this attack. This seems fairly serious.


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

S 1.
>      A dynamic provisioning model, such as using DHCPv4 over DHCPv6
>      [RFC7341] (DHCP 4o6) allows much more flexibility in the location of
>      the IPv4-over-IPv6 softwire source address.  In this model, the IPv6
>      address is dynamically communicated back to the service provider
>      allowing the corresponding softwire configuration to be created in
>      the border router (BR).

I'm sure this is obvious to the informed, but it would have helped me
to have explained that the setting here is that the client has v6-only
service and is going to get a v4 address and tunnel that over v6.


S 5.
>              OPTION_DHCP4O6_S46_SADDR (TBD2) with the IPv6 address which
>              the client will use as its softwire source address.
>   
>      Step 4  The server sends a DHCPv6 'DHCPV4-RESPONSE (21)' message.
>              OPTION_DHCPV4_MSG contains a DHCPv4 DHCPACK message.
>              OPTION_DHCP4O6_S46_SADDR with the client's softwire source

Which of these messages contains the client's assigned IPv4 address?
It's the DHCPOFFER, right?