Subject: [dhcwg] Comments on draft-wing-dhc-dns-reconfigure-01

From: Tomek Mrugalski <[email-masked]>
Date: Sat, 27 Jul 2013 18:03:59 +0200

I had some time to review draft-wing-dhc-dns-reconfigure-01. This is a
reasonable draft and I believe it tries to solve a real problem. If
authors are going to request adoption in DHC, we'll need to either
update our charter to include it or get AD permission to adopt it.
Since we're in the process of updating our charter, it will be quite
easy to add that draft to our charter.

Please note the the new charter says that if a new proposal defines
simple option that follows standard behavior, it should be adopted in
the respective WG, not in DHC. That draft defines a simple option, but
it does introduce behavior change, hence it should be adopted in DHC in
my opinion.

However, I have some comments:

Section 3, bullets 2 and 3 mention "regular DNS server", but the
terminology section defines only "DNS server".

Section 3, bullet 3: "regualr" => "regular"

Section 4: Please remove the formatting lines after info-flags. The
format as it is presented now suggested 3 octets of padding. This is
probably not what you want.

Option-length field should be defined explicitly as 1.

Although you only define values 0x01 and 0x02, you should add a text
that the server MUST ignore the option if it doesn't recognize
configured flag.

Also, naming of the field a 'flag' is not fortunate. This is more of an
enumaration value. Flag somewhat implies that this is a bit field and
some people may get idea to set both flags and send 0x03. Obviously that
combination does not make sense.

Section 5 should start with "DHCPv6 relay agents that implement
this functionality MUST support RFC6977."

Section 5, first paragraph "IPV6_HIG_PROI_NORM_SERV": H missing after
HIG.

Section 5 repeats some normative language from RFC6977 using slightly
different wording. It would be better to say that relay sends
RECONFIGURE-REQUEST as defined in RFC6977.

Section 6, first and second bullet: Most of the text about sending
reconfigure is duplicated. It would be easier to read if it had
been written once and apply to both cases.

Section 6 says "The server will remember this configuration for the life
of the lease." That is not sufficient. DHCPv6 clients may have more
than one lease. What about stateless clients? They do
information-request only and there are no leases for them.

It should be specified somewhere (perhaps in section 7) in the text that
only the relay closest to the client is able to do host tracking.
Keep in mind that DHCPv6 allows up to 32 relays. I never heard of
any network that has more than 2 cascade relays, though.

There's also redundancy in the section 6. What if the relay starts
sending reconfigure-request with flag set to 0x01 for a given client?
Server should trigger reconfigure for the first time, but later only
check that the flag matches current configuration and do not trigger
another reconfigure. Sure, such behavior would likely mean bad relay
implementation, but I personally would consider it protocol resiliency.

Section 7 can possibly also mention if the information about clients
is affected by relay reboots, e.g. if the information should be kept
in some form of persistent storage or if the relay should retrieve
its lost information using leasequery. If you do not want to be too
specific, please add an information that specific retention policy is
implementation dependent.

There's one flaw in the whole concept or at least an omission in the way
the mechanism is described. Section 7 mentions information about relay
gathering IPv4/IPv6 - MAC mapping, but the reconfigure-request (and
almost any other operation in DHCPv6) references clients by their
DUIDs. So it should be a triplet of IP/MAC/DUID. Do not assume any
relation between MAC and DUID. There are DUID types that are not based
on MAC. Also, even when the client uses MAC-based DUID, it is perfectly
valid case to use different interface's MAC to generate DUID or keep
using DUID after changing NIC.

Security considerations may also mention that if a relay is compromised,
it may be used to force the uncompromised server to abuse clients by
triggering repetitive reconfigurations. That's not a big issue as in
case of the relay being compromised there are more serious ways intruder
could wreak havoc.

References need updating: I-D.ietf-dhc-triggered-reconfigure
was published as RFC6977.

Section 9: nit-pick: There is no "DHCPv6 Options" section in RFC3315.
It is better to say that IANA is requested to add option-code to the
"DHCP Option Codes" maintained at
www.iana.org/assignments/dhcpv6-parameters (note: the registry that
keeps DHCPv6 options is called "DHCP
option codes", not "DHCPv6 Option codes". It is a bit odd, but that's
how the registry was named).

Section 10.1: Are you sure that all those references are normative?
RFC6052, RFC6147, RFC6384 and RFC6724 seems like informative.

None of the informative references are used in the text. Please either
reference or remove them.

Finally, let me repeat my previous opinion (with my chair hat off): I
consider this draft useful and would like to see it adopted in DHC.

Hope that helps,
Tomek

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Sun, 28 Jul 2013 09:01:41 +0000

Hi Tomek,
Thanks for the detailed review. Inline..

>Section 3, bullet 3: "regualr" => "regular"

Accept, will correct.

>Option-length field should be defined explicitly as 1.

Accept.

>that the server MUST ignore the option if it doesn't recognize

Accept.

>combination does not make sense.

Agreed. 'Flag' is not appropriate, it is a mutually exclusive enum.

>Section 5, first paragraph "IPV6_HIG_PROI_NORM_SERV": H missing after

In some of the earlier threads, there was discussion on whether info sent
to the server be more generic and not specific to the DNS problem. There
could be other potential actions that a server MAY want to take, either by
built-in design or configuration, based on end point mode i.e IPv4 only,
IPv6 only, Dual-Stack, transitions from Ipv4/6 to Dual-stack and vice
versa. The idea is to now dynamically indicate generic host mode in
RELAY-FORW and RECONFIGURE_REQUEST to the server and the server then
chooses to (RE)CONFIGURE accordingly, the draft defines server behavior
for DNS reconfiguration to start off with.

>information-request only and there are no leases for them.

Agreed, stateless clients have to be taken into account.

>any network that has more than 2 cascade relays, though.

Yes, it has to be the one closest to the client. Will specify this.

>implementation, but I personally would consider it protocol resiliency.

Right, ideally a relay shouldn¹t be sending redundant
reconfigure-requests. Needs text to specify behavior on both relay and
server for this.

>implementation dependent.

Sure.

>using DUID after changing NIC.

Accept.

>case of the relay being compromised there are more serious ways intruder

Sure, will mention this risk.

>how the registry was named).

Thanks, will do.

>reference or remove them.

Accept.

>consider this draft useful and would like to see it adopted in DHC.

Thanks,
Prashanth

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