Re: [v6ops] Secdir last call review of draft-ietf-v6ops-cpe-slaac-renum-04

Ted Lemon <mellon@fugue.com> Wed, 09 September 2020 23:32 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA983A082D for <v6ops@ietfa.amsl.com>; Wed, 9 Sep 2020 16:32:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7N4LIKu-mWg for <v6ops@ietfa.amsl.com>; Wed, 9 Sep 2020 16:31:59 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3335F3A0822 for <v6ops@ietf.org>; Wed, 9 Sep 2020 16:31:59 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id g72so4224255qke.8 for <v6ops@ietf.org>; Wed, 09 Sep 2020 16:31:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2wNo5gCisSNSY4DpBonESfuBtu+nKV+NqWJSlcqNP1k=; b=gXPgQb8CQEvDiE3XgZa4/ENGWfBpCdq7cIxq6ezXRA+zCe0ioMLd4Wx2cJWwyDil4f 5Qp7IFW4ExFZH++RwhGlHGBC6Ac6LWtZ+yJUKGeAx0q1m/ok3fRMfmUqjANZZi9uHgy6 SQwrOXgI3nBw5iDyrlDxyw6RcwDj0sHTjYdPG+PlrSevmfr/blwbQJOdvcR0ZIkQrO5M 6xcEr+K3q0vc1Kz1ShiLCeLMeed6fCcdtCGKMlKo+WGW8qZEE3Mj6sekcabHgVind8Rb IJxuUcac1+MDhGIZ2aIYNeebpTkeenur5iK4+cpKkf9RvZ4FIoAX/Xpga5NPZM6IK2+o ndVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2wNo5gCisSNSY4DpBonESfuBtu+nKV+NqWJSlcqNP1k=; b=AFT/4kCDg0XGRpf+/UIOu4ZNR86sf/F0+y8KX2p8EyABJ7JWYZFFe+0lWm+gOa72UE AAABfA7lwMjCWwS+7BAOl5fwjHz26/o+7WqAR4+eqAGq4ZKE93F+AnXO8KRui9QzKl+m rw/PBTEvDNArl4Zcwqo/BYss6RtQqaFyr5Q13vn7gXIy0dDwhVHY6vOl0iQE8Exp2tOP sp5cbTXw5EwiLLfb+d43Fi0PFTGcWSDB0tqnlZ5R9KYKJk87pI4qoH6Uq0UExnpR2E+U qaqLBpShTkfTNz6tRpaWL+7b9w7LXJ6uIKD0dWD+kUV2AUE9oYbVMXkXFI1rLjlRZkKm lgOQ==
X-Gm-Message-State: AOAM533NQsQ8/Souz7ZtSxX3kSYM474hsanDdwfM/Cp6yrpRy9Nb0aJe vr15uRQos138gOy4MLzsqWbETQ==
X-Google-Smtp-Source: ABdhPJz7nFbl740B20WwTHMpq/K4K23JnkAR/8/z4A/ermW2Jt4CmpG2l4kc/K3jqNqzIXOHV/nGYw==
X-Received: by 2002:a37:d91:: with SMTP id 139mr5446106qkn.455.1599694318194; Wed, 09 Sep 2020 16:31:58 -0700 (PDT)
Received: from localhost.localdomain ([2601:18b:300:36ee:8c6:61e3:cd71:8bf3]) by smtp.gmail.com with ESMTPSA id l5sm5059867qtc.28.2020.09.09.16.31.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Sep 2020 16:31:57 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <4FC30E5B-EF9F-4238-A683-CE8235BDD2EF@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_79F0E0F9-1A86-4FE0-9FEE-29E22D7F63DF"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\))
Date: Wed, 09 Sep 2020 19:31:56 -0400
In-Reply-To: <159969337123.15697.6820068156665930267@ietfa.amsl.com>
Cc: secdir@ietf.org, last-call@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-cpe-slaac-renum.all@ietf.org
To: Christopher Wood <caw@heapingbits.net>, Christopher Wood via Datatracker <noreply@ietf.org>
References: <159969337123.15697.6820068156665930267@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3654.0.3.2.26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Bpw10ZzZzT_-mTfid-aBxcidmEc>
Subject: Re: [v6ops] Secdir last call review of draft-ietf-v6ops-cpe-slaac-renum-04
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2020 23:32:01 -0000

On Sep 9, 2020, at 7:16 PM, Christopher Wood via Datatracker <noreply@ietf.org> wrote:
> - Section 3: is it possible for an attacker to send DHCPv6 Prefix Delegations
> with lifetime=0 to CE routers that support LAN-side DHCPv6 and amplify
> Reconfigure messages to supporting clients? (I don't know if this is a concern
> or part of the threat model, but this did seem to be a case of possible
> request/response asymmetry.) - Section 4: rationale for these default values,
> if available, might be worth including. (Why not make them shorter? What are
> the tradeoffs?) - Section 6: it might be worth noting what happens if stable
> storage is unavailable or otherwise compromised when trying to store prefix
> information. What happens if the "A" or "L" bits are modified? (I suspect
> nothing dangerous, but it's not clear to me whether or not integrity is
> important.)

The attacker on the southbound link would have to know the transaction ID of the DHCP request/confirm/renew message, which is only sent on the northbound interface, and would have to know the DUID and IAID used by the client, again never seen on the southbound link, and would have to know the server’s DUID, again only visible northbound. I don’t think this is a feasible attack. It’s hard to see what the benefit of such an attack would be—in order to effect this attack without knowledge of the exchange on the northbound interface, the client would have to be continuously spamming the southbound link with attempts, so that would be a negative amplication factor of perhaps 2^256, perhaps less if the identifiers can be predicted and renewal times can be predicted.

And this assumes that the DHCPv6 PD client on the CPE device will even accept a DHCP Reply on its southbound interface.

:)