Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21

Ted Lemon <mellon@fugue.com> Tue, 19 November 2019 07:31 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2CE120089 for <opsec@ietfa.amsl.com>; Mon, 18 Nov 2019 23:31:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 FwXxA947ZOro for <opsec@ietfa.amsl.com>; Mon, 18 Nov 2019 23:30:58 -0800 (PST)
Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (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 40A1B120878 for <opsec@ietf.org>; Mon, 18 Nov 2019 23:30:58 -0800 (PST)
Received: by mail-qk1-x741.google.com with SMTP id z23so16914925qkj.10 for <opsec@ietf.org>; Mon, 18 Nov 2019 23:30:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gJG+7oBQCzlah4n/lzJCJn6BneYcIy2Lo0ly54mtpNs=; b=QBBFj7bjC3VKMTiSgLZ40oa/yLspQL4N7eU0oeknYbbqMh7ow9a6d3zThQbKHV0EhQ 9IHRKD9iY4DZ+ewGmYGzRWve/2gCPOhlQgL6c/xc93WZk6OCF1OIp/XegM5XcdOZMDDw r/gSgK+YWawLtNIi2ubsbUhWdEmEJwlEUFvcImNdnps+Nf74nIPueZT522OK/pUA4PZA Jx8Ymq0YPlNqTvcIzy7Y/a3IOP2QoExogigrsEQa1jVWLQnfFyZMnmhnYCME2VIsdHz2 4LogGpjHM5C9UkHP1ysdE3SayN2SKa46TOgbNoq6JNxEie+ucUXr270288nYKgMmYnFp I1BA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gJG+7oBQCzlah4n/lzJCJn6BneYcIy2Lo0ly54mtpNs=; b=jiqev3JLkB/ywZRDqnLynvTuqABLkj8WrNerJoEfU3wgLcaIAXx9kB27AdptSexYMe t2F45Le7j0Z6nUMrFmhcBj0z74ihLGWs4jEhwZdtWqbOc7HGr7ofp8YCmRvMn/5utDE7 hKKprtR69m5f0bzs85lzJoBMmwo2CyoluTOA5+4eqy+zXExbE7kdzRHMb53U2TFFO2di aB/P9Qfhhk6HeMboEwBj8zgcoxGcxQMyBJWN5NDTRvvkJwInHKlM8YE0GdhsqakR6FBB RbzzCY0JgM1esJN1Yv4LV58k357kdtjfksy8+b7JerOyXsjMTMmg2U39iF4oJExGjPXg r2BA==
X-Gm-Message-State: APjAAAUy4ElU4YSSp+quFsR1zrKcEKiORV0jTrEQ6LTzgCtWnwGd35s8 hswgJ9i5WrvqvkE70W+PFDci8g==
X-Google-Smtp-Source: APXvYqz6rOVGZwlLaeF/9tO5/A1GtrLSqcARqMoGvK6oXgLpjSrLVB96/tkfpM181M/TFlwpcJ500Q==
X-Received: by 2002:ae9:f217:: with SMTP id m23mr27977006qkg.151.1574148657130; Mon, 18 Nov 2019 23:30:57 -0800 (PST)
Received: from ?IPv6:2601:18b:300:36ee:6101:8b1:d9fd:1e9a? ([2601:18b:300:36ee:6101:8b1:d9fd:1e9a]) by smtp.gmail.com with ESMTPSA id k129sm9891907qke.128.2019.11.18.23.30.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Nov 2019 23:30:56 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.1\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <A9940795-4D4C-45C3-910E-E57EBAF850A3@gmail.com>
Date: Tue, 19 Nov 2019 02:30:54 -0500
Cc: Iot-dir@ietf.org, opsec@ietf.org, draft-ietf-opsec-v6.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDB76F51-CDF0-4079-ABA7-FCD7DF65DB9D@fugue.com>
References: <157394737956.25908.2003745932020934234@ietfa.amsl.com> <A9940795-4D4C-45C3-910E-E57EBAF850A3@gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
X-Mailer: Apple Mail (2.3608.40.2.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/rYOmBvk9ScVHYo2wp1S5EodiMqQ>
Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Nov 2019 07:31:01 -0000

On Nov 18, 2019, at 1:50 AM, Gyan Mishra <hayabusagsm@gmail.com> wrote:
> ULA mentioned in section 2.1 mentions use case described in RFC 4864 but should mention section 3.2 of that document.  I think we could add some verbiage that ULA is used for local scope communications only. Also maybe a case of SHIM6 multi homing or where 6to6  nat - nat64 is used where ULA is inside local Nat to outside global address use case. Maybe also mention default address selection RFC 6724 where a host is configured with both ULA and Global and how ULA is used for internal local communications and how the global address is used for external internet communications.

I don’t think you should mention anything that’s not ready to deploy.  SHIM6 is a neat idea that nobody has deployed, as far as I know, and it’s not clear that it can be deployed.  I may be wrong about that—that’s just my impression—but the point is that if you’re going to suggest something, it should be readily actionable.

> 2.1.4 static does mention obfuscation of static address but 2.1.6 does not since DHCPv6 ISC or other DHCPV6 server implementations the pool address picked let’s say within the scope is randomly picked each time the server doles ourt an IPv6 lease by default and not picked sequentially by the server which is why obfuscation is not mentioned.   We could mention that is how the DHCPv6 sever picks the address so that is not confused.  We don’t mention split scope is required for redundancy which should be mentioned and how that works in comparison to IPv4 where state sharing is done between active and backup server where with DHCPV6 no active leases state sharing.  We will get that added as well.  Also a caveat with DHCPv6 that when the primary server goes down and the lease has to be renewed rebind time that the IPv6 address has to change at which time any active session will have to reset.  I have actually deployed this with BT Diamond which used ISC and to get around this issue we ended up setting a long 7 day lease time with larger block size for the scope being a /112 versus our initial /116 scope.  Also good to mention that since the 128 bits is managed to use smaller scope size for split scope then 2 /65 since their is not any privacy extension which stateful that for security it’s better to have a smaller DHCPv6 scope for managed address.  In section 2.1.6 the DUID has the mac embedded in the address embedded in the DUID as the 48 LSB bits.  Can you provide the use case where the DUID does not have embedded mac.  I agree  that 2.1.7 needs to some extra verbiage as to the use case of when and why addressing would be done as /64 per host and refer back to 2.1.4 static addressing use case.

Why do you need a split scope?  If the prefix is managed, just give out random addresses.   Use a good random number generator.  Use failover to keep the servers in sync.

DUID is opaque.  We recommended generating it using the MAC address because we hadn’t thought about privacy.   RFC7824 makes it clear that this is a problem.  Any DHCP implementation on a device where privacy is a likely issue should already be randomizing the DUID.  DUID-LLT with a random MAC address should be safe to use and unique.  It can be regenerated as frequently as the client decides.

But this isn’t really your problem.  You’re talking about network operational security, not about host operational security.   From the network perspective, you should just assume that this problem either is solved, or will be solved, because the network operator’s behavior is the same in either case.  In fact, given that we are talking about firewalls and filtering here, the fact that any client already can just fabricate a DUID means that you have to account for that when talking about the policy implications of this.