Re: WGLC for draft-ietf-dhc-addr-notification - Respond by December 11, 2023

> The intent was that the client is not required to do so, but it could
choose to do so. For example, consider the deployment model in
draft-ietf-v6ops-dhcp-pd-per-device. The client would get a prefix from the
network and could form addresses from it. But the network wouldn't
necessarily know which addresses the client is using. So it cannot reach
the client, add a DNS record for it, etc. The client could inform the
server of these addresses using the address notification mechanism defined
in this document.

Ah okay, that does make perfect sense. Perhaps, in the draft it may be
beneficial (for future revision), to clarify on that particular line, with
the explanation you provided above, I feel the original line is a bit
ambiguous and could potentially lead to "open for interpretation"
issue with vendors if
they try to implement this document in the future.

Another query:
> If a network is using FCFS SAVI [RFC6620], then the DHCPv6 server can
trust that the ADDR-REG-INFORM message was sent by the legitimate holder of
the address. This prevents a host from registering an address owned by
another host.

>From what I can gather, it appears there's not a lot of vendor support
for RFC6620, currently. Is there anything that can be done through
the addr-notification document to mitigate (to a small extent) the
described potential attack vector?

>  An attacker may attempt to register a large number of addresses in quick
succession in order to overwhelm the address registration server and / or
fill up log files.

Perhaps, we can allow a configurable rate-limit variable for the DHCPv6
server to limit the number of "accepted" ADDR-REG-INFORM on a per-MAC
basis? For example, if we had an ADDR-REG-INFORM-LIMIT variable, and we set
it to 20, then this would mean a client (from a specific MAC address)
sending more than 20 ADDR-REG-INFORM messages (containing more than 20
addresses) will be deemed invalid exceeding the first initial 20 addresses,
so any "addresses" past the configured limit will be rejected. At least for
the purpose of non-PD (I can see such a variable, may potentially become a
problem in the case of PD).

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://mailtrack.io/link/f4c2d00a5afe436cbbe2efb2e4079e0c912339d4?url=https%3A%2F%2Fwww.daryllswer.com&userId=2153471&signature=89f0d2b7992a71b9>


On Sun, 24 Dec 2023 at 12:52, Lorenzo Colitti <lorenzo=
[email protected]> wrote:

> On Sun, Dec 24, 2023 at 2:28 PM Daryll Swer <contact=
> [email protected]> wrote:
>
>> Does this imply that, if for example, I have a DHCPv6 server running on a
>> VLAN, and on this particular VLAN, I delegate via ia_pd to my client, a
>> /56, the client needs to inform back to my DHCPv6 server
>> through ADDR-REG-INFORM, whenever the client uses some addresses out of the
>> delegated /56? If the implication is yes, then would this not make it a
>> redundant functionality? As the DHCPv6 server will, anyway, already have
>> knowledge of which client received which ia_pd prefix, therefore if we do
>> need to identify a particular /128 IPv6 address client origin, we can do so
>> by looking at the ia_pd pools.
>>
>
> The intent was that the client is not required to do so, but it could
> choose to do so. For example, consider the deployment model in
> draft-ietf-v6ops-dhcp-pd-per-device
> <https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcp-pd-per-device/>.
> The client would get a prefix from the network and could form addresses
> from it. But the network wouldn't necessarily know which addresses the
> client is using. So it cannot reach the client, add a DNS record for it,
> etc. The client could inform the server of these addresses using the
> address notification mechanism defined in this document.
>
> Does that match your reading of the doc?
> _______________________________________________
> dhcwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg