Re: [dhcwg] Adoption Call for draft-wkumari-dhc-addr-notification-07- Respond by April, 20 2023

>Bernie>But that reopens the can of worms the earlier attempt at this work raised:

>>   This document borrows heavily from a previous document, draft-ietf-
>>   dhc-addr-registration, which defined "a mechanism to register self-
>>   generated and statically configured addresses in DNS through a DHCPv6
>>   server".  That document was written Sheng Jiang, Gang Chen, Suresh
>>   Krishnan, and Rajiv Asati.

The current notification draft only keep the part that the clients notify their own-generated addresses to DHCPv6 server from my original registration draft, and leave it out that the DHCPv6 server registers FQDNs on behalf of clients. So it does not open the issue. The latter part may have more security and privacy considerations, even there are motivations. Therefore, the current draft fairly leave it out of scope. The sentence in current draft, "Clients MAY include other options, such as the Client FQDN Option", only means the client MAY notify more information rather than addresses. Anyway, even the other more information also a minor point to discuss.

Regards,

Sheng Jiang

>This is with WG co-chair hat off.

>

>Good find regarding:

>

>> The Security Considerations relating to the AUTH option are... insufficient.

>> I wish we'd removed it from 8415.

>

>

>   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.  These attacks may be mitigated by

>   using generic DHCPv6 protection such as the AUTH option [RFC8415].

>   The similar attack vector exist today, e.g. an attacker can DoS the

>   server with messages contained spoofed DUIDs.

>

>WE DID remove AUTH effectively in 8415 as it is only used for reconfiguring!! So this text needs to be corrected. Just remove the sentence about AUTH.

>

>Regarding:

>

>> There is some subtle (emotional?) connection to RFC8505, which I'll try to

>> resolve in my mind.

>

>

>8505 is at the link layer. DHCPv6 is designed to be able to operate at higher layer as “registration” at link level is already possible.

>

>Regarding:

>

>> Can a host include RFC4704 (Client FQDN) in the same packet to have the

>> reverse DNS updated?

>

>

>Document does say:

>

>   Clients MAY include other options, such as the Client FQDN Option

>   [RFC4704].

>

>But that reopens the can of worms the earlier attempt at this work raised:

>

>   This document borrows heavily from a previous document, draft-ietf-

>   dhc-addr-registration, which defined "a mechanism to register self-

>   generated and statically configured addresses in DNS through a DHCPv6

>   server".  That document was written Sheng Jiang, Gang Chen, Suresh

>   Krishnan, and Rajiv Asati.

>

>Personally I am not in favor of this new work either (and will comment more later).

>

>- Bernie Volz

>

>> On Apr 7, 2023, at 12:06 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

>> 

>> 

>> Timothy Winters <tim@qacafe.com> wrote:

>>> As discussed during IETF-116, I would like initiating a WG call for

>>> adoption on

>>> https://datatracker.ietf.org/doc/draft-wkumari-dhc-addr-notification/.

>> 

>>> This starts the call for adoption of this document. Please respond by

>>> April 20, 2023.

>> 

>> I read the document a few weeks ago, and I like it.

>> Please adopt it.

>> 

>> } The host MUST only send the ADDR-REG-INFORM message for valid ([RFC4862])

>> } addresses of global scope ([RFC4007]).

>> 

>> Is this intended to exclude ULA?

>> 

>> } address being registered is "appropriate to the link" as defined by

>> 

>> It seems that this will be in conflict with draft-collink-v6ops-ent64pd,

>> should it be adopted.

>> The Security Considerations relating to the AUTH option are... insufficient.

>> I wish we'd removed it from 8415.

>> 

>> Does the packet need to originate from the IP address which is being

>> registered?

>> It would be nice if there was a return reachability challenge (3-way handshake).

>> 

>> Can a host include RFC4704 (Client FQDN) in the same packet to have the

>> reverse DNS updated?

>> 

>> There is some subtle (emotional?) connection to RFC8505, which I'll try to

>> resolve in my mind.

>> 

>> 

>> 

>> 

>> 

>> 

>> 

>> -- 

>> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )

>>           Sandelman Software Works Inc, Ottawa and Worldwide

>> 

>> 

>> 

>> 

>> _______________________________________________

>> dhcwg mailing list

>> dhcwg@ietf.org

>> https://www.ietf.org/mailman/listinfo/dhcwg