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

[Gyan Mishra <[e-mail]>]

>> On Nov 19, 2019, at 2:30 AM, Ted Lemon <[e-mail]> wrote:
>> 
>> On Nov 18, 2019, at 1:50 AM, Gyan Mishra <[e-mail]> 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.

https://tools.ietf.org/html/rfc6853#section-6.1

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.

> 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.
> 
Agreed. I think staying on point with network operational security which is the goal of this draft and not drift into the weeds on host security.  That in itself could be a separate host operational security draft.