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