Subject: RE: [dhcwg] Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sun, 27 Nov 2005 21:43:50 -0500

A few comments below. Prefixed by BV>.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Pekka Savola
> Sent: Saturday, November 26, 2005 9:36 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [dhcwg] Re: Last Call: 'Resolution of FQDN Conflicts 
> among DHCP Clients' to Proposed Standard 
> 
> On Mon, 14 Nov 2005, The IESG wrote:
> > The IESG has received a request from the Dynamic Host 
> Configuration WG to
> > consider the following documents:
> >
> > - 'A DNS RR for Encoding DHCP Information (DHCID RR) '
> >   <draft-ietf-dnsext-dhcid-rr-10.txt> as a Proposed Standard
> > - 'Resolution of FQDN Conflicts among DHCP Clients '
> >   <draft-ietf-dhc-ddns-resolution-10.txt> as a Proposed Standard
> > - 'The DHCP Client FQDN Option '
> >   <draft-ietf-dhc-fqdn-option-11.txt> as a Proposed Standard
> > - 'The DHCPv6 Client FQDN Option '
> >   <draft-ietf-dhc-dhcpv6-fqdn-03.txt> as a Proposed Standard
> 
> I read draft-ietf-dhc-dhcpv6-fqdn-03.txt.  I believe most of the 
> comments also apply to the DHCPv4 option.  I think the document set 
> was overall well written, though there seemed to be a couple 
> of issues 
> which need to be resolved.
> 
> substantial
> -----------
> 
>     The Client FQDN option MUST only appear in a message's 
> options field
>     and applies to all addresses for all IA_NA bindings in the
>     transaction.
> 
> ==> shouldn't this be rather specified the other way around, i.e., in 
> which cases the receivers MUST discard Client FQDN options?  
> Sooner or 
> later someone will send the option in a wrong place, and it makes 
> sense to guard against this in the receiver's implementation.
> 
>     o  Otherwise, if the client's "S" bit is 1 and the servers's
>        configuration allows it to honor the client's request for the
>        server to initiate AAAA RR DNS updates and if it has 
> the necessary
>        credentials, the server sets the "S" to 1.  If the server's "S"
>        bit does not match the client's "S" bit, the server 
> sets the "O"
>        bit to 1.
> 
> ==> the server cannot know, before it has tried DNS update, 
> whether it has
> "the necessary credentials", right?

BV> Well, the server generally assumes it has the right credentials if
it is configured with them. If the DHCP server is told to do updates and
provided credentials, they better be valid or no updates will get done
and this would generally be viewed as a configuration error. Perhaps it
is unnecessary to add this level of detail and we just drop "and if it
has the necssary credentials".

> 
>     The server MAY perform these updates even if the client's 
> message did
>     not carry the Client FQDN option.  The server MUST NOT 
> initiate DNS
>     updates when responding with an ADVERTISE message to the client.
> 
>     The server MAY complete its DNS updates (PTR RR or PTR 
> and AAAA RR)
>     before the server sends the REPLY message to the client.
>     Alternatively, the server MAY send the REPLY message to the client
>     without waiting for the update to be completed.  Whether the DNS
>     update occurs before or after the REPLY is sent is 
> entirely up to the
>     DHCPv6 server's configuration.
> 
>     If the server's AAAA RR DNS update does not complete 
> until after the
>     server has replied to the DHCPv6 client, the server's interaction
>     with the DNS server MAY cause the DHCPv6 server to change 
> the domain
>     name that it associates with the client.  This can occur, for
>     example, if the server detects and resolves a domain-name conflict
>     [8].  In such cases, the domain name that the server 
> returns to the
>     DHCPv6 client would change between two DHCPv6 exchanges.
> 
> ==> does the first paragraph work with Rapid Commit, as there are no
> messages beyond Advertise?

BV> The text is correct. A REPLY is sent in response to a SOLICITI
w/RAPID COMMIT if the server is honoring the RAPID COMMIT. ADVERTISE is
only sent if the 4-message exchange is used.

> 
> ==> actually, the 2nd sentence of 1st paragraph should maybe 
> be placed at
> the end of the second paragraph -- it'd seem more logical there.
> 
> ==> how does the resolution process described in 3rd 
> paragraph work with
> Rapid Commit?  If DNS update is done after the last 
> communication with the
> client, it's not clear how you signal the changed FQDN to the client?

BV> Rapid Commit has no bearing on this as the FQDN may not be updated
until after the REPLY (either for SOLICIT W/Rapid Commit / REPLY or
SOLICIT / ADVERTISE / REQUEST / REPLY). The updated FQDN would not be
communicated until some follow on client operation, such as a renewal.

> 
> 9.  Security Considerations
> 
> ==> this section should provide a pointer to ddns-resolution's 
> security considerations section, highlighting the necessity of 
> implementing conflict resolution properly.  For example, something 
> like,
> 
>     It is critical to implement proper conflict resolution, and the
>     security properties of conflict resolution apply [8].  
> For example,
>     a DHCP-client from example.com should not be able to override,
>     e.g., www.example.com.
> 
> editorial
> ---------
> 
>     Depending on the prescence of or type of authentication 
> used with the
> 
> ==> s/prescence/presence/
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Nov 2005 08:11:57 +0200 (EET)

> has the necssary credentials".

The server may not even be configured with *any* credentials (if DNS 
updates aren't done with DNSSEC). The statement could probably be 
removed and it'd be OK.

> only sent if the 4-message exchange is used.

OK, you know DHCP exchanges better than I do :).  I hope this isn't an 
issue in DHCPv4 spec either.