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

Ted Lemon <mellon@fugue.com> Thu, 10 September 2020 03:42 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 389763A07F2 for <v6ops@ietfa.amsl.com>; Wed, 9 Sep 2020 20:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Qj6Tj67AYWZV for <v6ops@ietfa.amsl.com>; Wed, 9 Sep 2020 20:42:45 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 BC81D3A0BBE for <v6ops@ietf.org>; Wed, 9 Sep 2020 20:42:45 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id w16so4707738qkj.7 for <v6ops@ietf.org>; Wed, 09 Sep 2020 20:42:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=SOtFKDnRQQXFxFswILV9a5wbEVrA1Q5vb3lCY9H6hTo=; b=PPEPL1v5fSTP2CGom2PVY9zKpP1eT+nPfHDbzkkFYOOK8lcuM+AvIWjScQP396MaUQ gW//CFWtmWfbpL3+fBBNi4F000ACDxfZoPwipDJigcRZ6/Ph6N2B1CE6sbL2fY3ILzQK OU5Fp1sbNCVjQLLRazMIgJx80+Zx3fwJBXbI2zpJyibE9K9jZjo4ByaZ98uUbd0eHudd WnVMLYvLW8luODHyG4hScGSJXSmlkTDW/rKxsER7Ohdq9f5yNg6qcItPQ7TlXQbft3Dy 9Qtz3ZDv4ihYcUWljcNjLzcNV0o2TGpD6fNnYBhyHAOE7oj7B1QnINaaF/p901TxkN1g hMtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=SOtFKDnRQQXFxFswILV9a5wbEVrA1Q5vb3lCY9H6hTo=; b=mva4XmSE43rbNr6Qk6MaMRS57K95+vyWydkn31bvBBWz2D8PBtBSF831vM5ACey1ME hfdf4rRkhZUCz6JXW/8wIz/Ka7GwYUPAdW5YyJUik5BvAjM4dlvBU4g3J9QPl5TyUMSa gnxuUxSydr3b716ehI5KoaDJqtWxIiUt5krpIVebMxwu7jFHyZ6+9p0msVWBN5K1bZGX flqOY3peGc/zLtpn1vPeJkr7dQ6bC6XHc5qipql7WiBMxjagupWJXGyyh5CiyQQCX80g R4gd5on/h0usDhGF8AWi0uK98vXVOkNfj+HBR5/zOYpw+eRH7OxpG6A2RUiGAdKcD96E bJkQ==
X-Gm-Message-State: AOAM531Z2nzkkjr1QVenhk8F9JbOoCh66giuNPSPlypa6Y4BuoSLwEE5 C0lisOceQHEHNiiY85UDqZdtNu1+CedQvw==
X-Google-Smtp-Source: ABdhPJxaM1vF5XtApbo8JppbaFjOkRroCCcb0+9AZQ6SoGcmrUWEZpbyABZlIg/kJAW21b72F6npDQ==
X-Received: by 2002:a37:9d84:: with SMTP id g126mr6266756qke.473.1599709364654; Wed, 09 Sep 2020 20:42:44 -0700 (PDT)
Received: from localhost.localdomain ([2601:18b:300:36ee:4ddf:4132:f1df:3766]) by smtp.gmail.com with ESMTPSA id e7sm5521781qtk.17.2020.09.09.20.42.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2020 20:42:44 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-359C6358-7A0C-456E-8A8D-679DDF3674C9"
Content-Transfer-Encoding: 7bit
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 09 Sep 2020 23:42:43 -0400
Message-Id: <90FF05E0-CA1A-4EA1-80D0-351D94C0EC5C@fugue.com>
References: <54DA4651-1C55-4DF9-BF3D-7E851B6692F4@mit.edu>
Cc: Christopher Wood <caw@heapingbits.net>, Christopher Wood via Datatracker <noreply@ietf.org>, last-call@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-cpe-slaac-renum.all@ietf.org, secdir@ietf.org
In-Reply-To: <54DA4651-1C55-4DF9-BF3D-7E851B6692F4@mit.edu>
To: Uri Blumenthal <uri@mit.edu>
X-Mailer: iPhone Mail (18A366)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/5uAcnfkPpfGbwgmy_btz3rK22PA>
Subject: Re: [v6ops] [secdir] 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: Thu, 10 Sep 2020 03:42:48 -0000

There is roughly zero chance of an attacker that is willing to reveal its presence listening on the northbound link. This is a CPE router. The northbound link is a point to point link to the ISP. State actors do not do DoS attacks on home networks. They snoop, or censor, the uplink. 

> On Sep 9, 2020, at 22:17, Uri Blumenthal <uri@mit.edu> wrote:
> 
> Capability-wise, what's the likelihood that the attacker would be present on the southbound interface, but *not* on the northbound one?
> 
> Sent from my test iPhone
> 
>>> On Sep 9, 2020, at 19:32, Ted Lemon <mellon@fugue.com> wrote:
>>> 
>>  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.
>> 
>> :)
>> 
>> _______________________________________________
>> secdir mailing list
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview