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

Suresh Krishnan <> Wed, 20 November 2019 06:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D4BF1202DD; Tue, 19 Nov 2019 22:06:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7OJnRAXXBp1H; Tue, 19 Nov 2019 22:06:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9BA14120274; Tue, 19 Nov 2019 22:06:28 -0800 (PST)
Received: by with SMTP id q18so9606978pls.5; Tue, 19 Nov 2019 22:06:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sqry/mGqDkAikAu+9TAJnraoldZPnOEaBmds6Hy1jeA=; b=qD4qPRko1tH3RNR3wRzS8nJ/UOBuJCgNvJaN73ecyeknSyJSs0lXdvqgK2YOct4hre 45dIV+lUfJPd4w8Rs5dTaJLMtcHeyaiWc7LLnQfDdsVkHg38XMAfWS4gVJLhCE6m7I9i wYwLnrif6pkt5Sa81WKTgbbSHqY3sjdmjjgOZkiYVBv4FjnI/nteTbsZzmN+bk+MqKHg P5h68Rk7o6qnrpNHd9N3QKP/uEXb4HOhTElJderzJULwl1YaQkzfl123O6Jm3OCGVs3T z4g7rPn8WCNUrAdhchp7bdHKrV1k6t1pU8dFTKibMZ3fj0AGmLk1V/PO58LWG72sKwgs VeWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=sqry/mGqDkAikAu+9TAJnraoldZPnOEaBmds6Hy1jeA=; b=Gn8SBV/ymvXOukJWcmqYfcgBxdBq/J8Tdb+wSisvPfV/32hMWl8af+5ss7Hwotx5yH ZZUBUG/vmZmZ+qpddI0WKy7JTTsu40OoCfWQaT/GzbvGN+oeuc1uEHRkwkEks/jUTNB5 i3SlIfafmrvymiS+SL18bkWPPcPW7yPueYvf6Flgm/+vZsJlCzsoYquyDSRjknKQZcmw dCqTfcqZu4BDq8ZZAMwwee/UP8gVguMaQfwdSikfuPlYixdoG66dRn8tmANl7xBUXnOU DqyKQumd4D7+zFKQyEJZg2km578cX6HVYSBiPse6HVmYpsVpoMqEZFm7Qp3QXHCyj3ne ZoRg==
X-Gm-Message-State: APjAAAXc6rB4UgsdZc3ACIhM0Mj7M2lx1vgUpCM3leqCDv8WNIlTciOg CbZfivqxiEFvfLlkGiGTC78=
X-Google-Smtp-Source: APXvYqwBSACIDZh/oPT1W8tN/AWxqHszsY5O/XRQZ8pxGMy0fRczW7I10/rf6Fae6js59bocJW3JDQ==
X-Received: by 2002:a17:90a:24b:: with SMTP id t11mr1902366pje.77.1574229988094; Tue, 19 Nov 2019 22:06:28 -0800 (PST)
Received: from ( []) by with ESMTPSA id 16sm28848768pfc.21.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Nov 2019 22:06:27 -0800 (PST)
From: Suresh Krishnan <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8EF99687-DA7D-4ADC-9B8D-46C2F7A856D4"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 20 Nov 2019 14:06:24 +0800
In-Reply-To: <>
Cc: Ted Lemon <>,,,
To: Gyan Mishra <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [OPSEC] [IoT-DIR] Iotdir early review of draft-ietf-opsec-v6-21
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Nov 2019 06:06:30 -0000

Hi Gyan/Ted,

> On Nov 20, 2019, at 9:12 AM, Gyan Mishra <> wrote:
> On Nov 19, 2019, at 2:30 AM, Ted Lemon < <>> wrote:
>> On Nov 18, 2019, at 1:50 AM, Gyan Mishra < <>> 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.
> Agreed.
>>> 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.
> See RFC 6853.
> <>
> With DHCPV6 all servers are active and that is why there is not any state sharing since the pool has to be different and there a a preference option as to which server is preferred.  This does go deeper into host configuration which is out of scope for this document so will leave out.
>> 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.
> DUID-LLT which is most commonly used still uses an embedded Mac but now along with time source to generate the DUID versus DUID-LL.

There are specific recommendations for this (generation of DUIDs) in Section 4.3 of RFC7844, essentially describing randomizing contents (and usage of “old” random timestamps for DUID-LLT).