Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt

[Martin Huněk <[e-mail]>]

On 01. 01. 23 19:59, Brian E Carpenter wrote:
> On 02-Jan-23 01:50, Martin Huněk wrote:
>> Hello Fernando,
>>
>> Dne sobota 31. prosince 2022 1:01:23 CET, Fernando Gont napsal(a):
>>> Hello, Martin,
>>>
>>> On 22/12/22 18:40, Martin Huněk wrote:
>>> [...]
>>>>>>>
>>>>>>> Completely understood. But the bad old days of using the MAC
>>>>>>> address to create the IID are gone, and numbering hosts from 1
>>>>>>> upwards would be extremely helpful for some kinds of attack.
>>>>>>
>>>>>> Again, I do not suggest that it should, by default, number
>>>>>> hosts/services from 1 upwards. I'm saying that when (and only
>>>>>> when) the device is providing service to the Internet, the IID on
>>>>>> which the service is listening should be predictable.
>>>>>
>>>>> No. It does not need to be predictable -- that's one of the reasons
>>>>> for which you have the DNS. If anything, it needs to be stable, to
>>>>> avoid the hassle (and glitches) to perform DNS updates regularly.
>>>>
>>>> That's precisely why it must be predictable, so the admin is actually
>>>> able to put it into the DNS. Or at least it needs to be predictable
>>>> to the admin.
>>>
>>> It doesn't need to be predictable, If anything, it has to be stable
>>> (indeed, these two characteristics are design goals of RFC7217).
>>>
>> There is not even a stability requirement in this document. It seems that it is strictly up to the host implementation. If this should be the SLAAC replacement, then it is not worse than the SLAAC in this aspect. However, if this should be something balancing the lack of DHCPv6 support on some platform/vendor, stable IID is not enough - it has to be predictable.
> 
> Martin, that is *your* requirement, it seems, but from a privacy point of view, unpredicatability is a requirement. That is a conflict of requirements, and that's
> why we have alternative solutions.
> 
> In such cases a detailed secenario analysis is needed, so that the conflict
> can be stated very precisely.

I don't think I'm the only one who would appreciate (admin) predictable IID. Also, if it would not be used for unsolicited outbound connections and it would be used only for inbound and related outbound connections, then the privacy impact is IMHO just marginal. In such a case, you would not give away the predictable IID by user activity. It would either have to be guessed or given away by a DNS, and then it doesn't matter how it has been constructed. So, I don't see it as a big conflict of requirements.

The main problem with privacy in the EUI-64 case was in outbound connections, so that device was constantly giving away its stable IID. If it is not using predictable IID for outbound connections, there is no privacy problem induced by it.
> 
>>>
>>>> As a network admin, I know the following: - Client's DUID - Client's
>>>> Link-local address - Delegated prefix - Maybe the MAC address
>>>>
>>>> I do not know the IID, so I cannot know the IPv6 address needed to
>>>> make an AAAA record. This I know with DHCPv6, and I knew that back in
>>>> the days when only EUI-64 was used with SLAAC. Also, in the draft,
>>>> there is no stability requirement.
>>>
>>> If you use DHCPv6, then you know the addresses, because you're leasing them.
>>>
>> Yes, when using DHCPv6, you can do that. However, not the case for the DHCPv6-PD discussed in the referenced document. You would not know the IID used by the host inside the delegated prefix - that is the problem.
> 
> It actually isn't a human operator who needs to know the address. It's whatever software creates the AAAA record. That can certainly be automated, but the authorization and authentication mechanisms must be defined. This is necessary as part of an overall
> delegation mechanism, and I don't mean to say that it's trivial> 
>      Brian

Ideally, it has to allow the same managing method as it is used in the IPv4 world so it can easily integrate with current solutions already deployed. So, If I'm using a manual configuration with static binding in DHCP, then I should be able to use the same method in IPv6. I may use RADIUS to hint the DHCP address or fully open Dynamic DNS. The point is we cannot presume that enterprises (targets of this draft) would change their internal processes/policies to accommodate new autoconfiguration methods.

I agree that new mechanisms should be defined as they can also help solve these issues in SLAAC. However, an admin-predictable server-only IID would be the easiest, fastest option to achieve such a goal - at least for DHCPv6-PD.

Martin
> 
>>
>>> OTOH, if you use SLAAC, you're somehow advocating for hosts to do their
>>> own thing -- so it shouldn't be you registering addresses in the DNS,
>>> but the hosts tehmselves should do it with Dynamic DNS updates.
>>>
>> Allowing the unrestricted Dynamic DNS would be a security issue, and from what I know, there is no way how to indicate to the device what domain name it is allowed to modify/register when using SLAAC. It is sort of open access to the network with no trust established. So only viable solution to allow Dynamic DNS would be a separate sub-domain per network segment. But even this way, there are risks for the domain. That is why you want to keep the domain under manual control - but this way, you cannot use SLAAC (nor DHCPv6-PD in its current state).
>>>
>>>
>>>> Long story short, if we keep overlooking the need for
>>>> autoconfiguration predictability in the name of privacy, we will end
>>>> up with hosts with privately generated addresses that will use IPv4
>>>> only, as there would be no IPv6 autoconfigured services in the DNS.
>>>
>>> If you want managed configuration, you do DHCPv6, not SLAAC -- slaac is,
>>> in a way, configuaration anarchy.
>>>
>> I agree. The DHCPv6 is now the only way. No DHCPv6-PD as it is written in this document and no SLAAC after EUI-64 has been replaced.
>>>
>>>
>>>> Even with stable privacy addresses, I cannot know the IID generated
>>>> by the host with SLAAC (it uses internal values for generating IID).
>>>> Currently, I have got just three options: 1) Force clients to use
>>>> EUI-64. 2) Use DHCPv6 and force users to report DUID manually. 3) Use
>>>> static configuration, losing all benefits autoconfiguration has.
>>>
>>> #1 has been known to be bad for a long time, so I hope you don't even
>>> consider it. ;-)
>>
>> Actually, I do. Not for mobile clients - it is too bad for them. But I have no issue with EUI-64 for fixed clients, especially for those without human users sitting behind them (servers, printers etc.), as they have no use for privacy ... :-)
>>>
>>> With SLAAC, hosts do their own thing, such as generating addresses. If
>>> you don't like SLAAC because you cannot predict addresses, then... don't
>>> use SLAAC. ;-)
>>>
>> I don't like that we have been forced to use SLAAC when implementing IPv6 in our network, as the SLAAC is the only required autoconfiguration option (the DHCPv6 is not mandatory). Back then, the EUI-64 was the only IID option - so we could use it for AAAA records. Then privacy extensions came along, followed by RFC7217 - which rendered EUI-64 AAAA-generated records useless and broken. So it seems that the only option left is the non-mandatory DHCPv6. If there is not and should not be any other way, then it is vital for IPv6 deployment, so DHCPv6 MUST be mandatory for every client device.
>>
>> If the suggested DHCPv6-PD for a client should be an alternative for DHCPv6, then it must allow either to predict IID or there has to be a way how to secure Dynamic DNS updates. The securing of the DDNS would need to consist of indicating to a client what names it is allowed to modify/register and some way how to negotiate TSIG for it. Most importantly, it had to be administratively effortless and automated.
>>>
>>>
>>>> What happened at our university (fully dual-stack) was that when the
>>>> IPv6 was deployed, there was only EUI-64 we had made, for every
>>>> registered device in the network, both A and AAAA records. When the
>>>> privacy extension came, we had to abandon the idea of making
>>>> automated EUI-64-based AAAA records.
>>>
>>> If you wanted, you could map MAC <--> IPv6 address, and create DNS names
>>> from there.
>>>
>> Yes, it was possible when the EUI-64 was the only option for SLAAC, or with DHCPv6 when the relay/server provides information about client MAC (not always the case) or when a client is using DUID-LL or DUID-LLT (not recommended now) or collect it from the neighbor table (resource heavy). It is not an easy task nowadays.
>>>
>>>> I'm not saying that IID has to be a fixed value known to everybody.
>>>> It can be, for example (just to illustrate an idea): SHA256(Client
>>>> DUID + Delegated prefix) and use first n bits where n is length of
>>>> IID.
>>>
>>> I think we have had enough lessons suggesting: do not employ predictable
>>> IDs.
>>
>> For client privacy, yes. However, unpredictable IIDs caused other problems - a headache for (IPv6) network administrators being one of them. :-)
>>
>> Best Regards,
>> Martin
>>