Hi Gyan/Ted, > On Nov 20, 2019, at 9:12 AM, Gyan Mishra <[email protected]> wrote: > > > > On Nov 19, 2019, at 2:30 AM, Ted Lemon <[email protected] > <mailto:[email protected]>> wrote: > >> On Nov 18, 2019, at 1:50 AM, Gyan Mishra <[email protected] >> <mailto:[email protected]>> 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 > <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.
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). Regards Suresh
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
