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

Uri Blumenthal <uri@mit.edu> Thu, 10 September 2020 02:17 UTC

Return-Path: <uri@mit.edu>
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 DFFE23A0A83; Wed, 9 Sep 2020 19:17:42 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Z5xtf1NCJ5qT; Wed, 9 Sep 2020 19:17:41 -0700 (PDT)
Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6D63A0A82; Wed, 9 Sep 2020 19:17:40 -0700 (PDT)
Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 08A2HWBS031219; Wed, 9 Sep 2020 22:17:33 -0400
Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 9 Sep 2020 22:17:32 -0400
Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by oc11expo31.exchange.mit.edu (18.9.4.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 9 Sep 2020 22:17:33 -0400
Received: from oc11expo31.exchange.mit.edu ([18.9.4.104]) by oc11expo31.exchange.mit.edu ([18.9.4.104]) with mapi id 15.00.1365.000; Wed, 9 Sep 2020 22:17:33 -0400
From: Uri Blumenthal <uri@mit.edu>
To: Ted Lemon <mellon@fugue.com>
CC: Christopher Wood <caw@heapingbits.net>, Christopher Wood via Datatracker <noreply@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, "draft-ietf-v6ops-cpe-slaac-renum.all@ietf.org" <draft-ietf-v6ops-cpe-slaac-renum.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: [secdir] [v6ops] Secdir last call review of draft-ietf-v6ops-cpe-slaac-renum-04
Thread-Index: AQHWhwF7e7SlyDtnvU2s/txTJbnRbalhZh8A
Date: Thu, 10 Sep 2020 02:17:33 +0000
Message-ID: <54DA4651-1C55-4DF9-BF3D-7E851B6692F4@mit.edu>
References: <4FC30E5B-EF9F-4238-A683-CE8235BDD2EF@fugue.com>
In-Reply-To: <4FC30E5B-EF9F-4238-A683-CE8235BDD2EF@fugue.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/signed; boundary="Apple-Mail-20FE2E7B-F5C2-485D-A9F8-CE4E520C868A"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/V6RJ6DN0MHBTgSk8GzqmPQsropM>
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 02:17:43 -0000

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