Re: [dhcwg] My WGLC comment on draft-ietf-dhc-rfc3315bis-05 - part 2

[Tomek Mrugalski <[e-mail]>]

Here is the second part that concludes my review. Apologies for sending
them so late after the deadline.

Missed comment for 17.1.1.
The text says "The first Solicit message from the client on the
interface MUST be delayed by a random amount of time between 0 and
SOL_MAX_DELAY." This mechanism was defined to avoid packet storm after a
network recovers from blackout, but it makes no sense when booting
wireless device. We should make an exception for wireless devices here.

Section 17.1.10.1
in order avoid => in order to avoid

Section 17.1.10.3
The references look odd "the client performs DHCP server solicitation,
as described in Section 17, and client-initiated configuration, as
described in Section 17." More specific sections should be referenced.

Section 17.1.6
"The client SHOULD include a Client Identifier option to identify
itself to the server.  If the client does not include a Client
Identifier option, the server will not be able to return any client-
specific options to the client, or the server may choose not to
respond to the message at all." It would be better to use MAY.
I'm also not fond of the text that says the server may not respond
at all. This is especially important from the privacy context.
THere may be clients that protect their privacy, don't want to
reveal their client-id and expect to get only basic configuration
options, like DNS servers information.

This is also in conflict with text in 17.2.6 ("the server SHOULD respond").

Note that draft-ietf-dhc-sedhcpv6 draft relies on anonymous
information-requests when bootstrapping encryption.

As such, I think the text about server dropping the message should
be removed.


Section 17.2, third paragraph
"In most instances, the server will send a Reply in response to a
Request, Confirm, Renew, Rebind, Decline and Information-request
messages sent by a client." Add Release here.

Section 17.2.1
What should the server do when it receives a unicasted Solicit? There's
no text for sending back UseMulticast status for Solicit, but there
are for other message types.

"...send a Request message for those addresses." Add "or prefixes".

"may useful using server selection process." => "may be useful during
the server selection process."

The last paragraph in 17.2.1 is confusing. The text needs to emphasize
somehow that the paragraph only applies to case when rapid-commit was
sent. Maybe we could move the rapid-commit response paragraphs to a
separate sub-section?

Section 17.2.2
"...and a Status Code option containing status code NoAddrsAvail.". The
text should be clarified as to whether send this status option within
IA or as top level option.

Section 17.2.5
There's no text for unicast Rebind and sending UseMulticast. Sending
unicasted rebind is wrong on so many levels BTW.

"Therefore, the server SHOULD only create new bindings during processing
of a Rebind message if the server is configured to respond with a Reply
message to a Solicit message containing the Rapid Commit option."
I disagree with this text. Responding to Solicit with rapid-commit and
creating leases when responding to Rebind are two similar scenarios,
but they're not the same. I can certainly see deployments that would
want to deploy only one or the other, but not both. For specific
example, there's one server that does not support rapid commit. The
server crashed and lost its database. The server is restarted with empty
database, but it knows there are clients in various Renew/Rebind stages
and it know it's the only server in the network. There should be a way
to recreate the leases (at least those that clients still attempt to
rebind) without enforcing clients go get new ones.

To conclude, I think the sentence should be removed completely.

Section 17.2.6
There's no text for unicast Information-request and sending back
UseMulticast. I can some reasons why we may allow that behavior,
so I don't insist strongly on adding such text, but maybe we need
to have some explanatory text when unicasted Information-request
is ok and when it's not.

Section 17.2.9
I have a problem with this text "If the Solicit message from the client
included one or more IA options, the server MUST include...", especially
with the "if". The conditional nature of that expression may be
suggest that it's ok to send Solicit without any Ia options. That's
definitely not the case. If the Solicit didn't include any IAs,
it's a valid Solicit and should be dropped, and the implementer should
not be following the section about creation and transmission of
Advertise messages.

(IA_NA or IA_IA) => (IA_NA or IA_TA)

Possible additional text at the end of 17.2.9 and 17.2.10
"The server MAY include additional options if configured to do so or
when supporting additional mechanisms, e.g. Relay Supplied Options
(RFC6422) or Echo Request Option (RFC4994)."

I like the idea of mentioning other existing mechanisms to get better
exposure to what is currently defined in other RFCs.

Section 18.1.1
RFC3879 deprecated site scope unicast addresses. Do we still want to
mention them in the first sentence? The second sentence needs
improvement: "If not addresses of other scopes are available the relay
agent..." => "If no such addresses are available, the relay agent..." =>

"as described in the previous paragraph" =>
"as described in the earlier paragraphs"

Section 20.1
"DHCP options are scoped by using encapsulation.  Some options apply
generally to the client, some are specific to an IA, and some are
specific to the addresses within an IA." This text, while true, it does
not cover all cases. We have other encapsulated options that have
nothing to do with addresses, e.g. MAP options defined in RFC7598.

Sections 20.4 and 20.5.
"This option MAY appear in a Confirm message if the lifetimes on the
non-temporary addresses in the associated IA have not expired." This
sentence appears out of place. We should either mention all other
messages it may appear in or not mention Confirm at all.

Section 20.7
I saw quite a few client messages that request Preference and
Rapid-Commit options in their Solicit messages. I suspect that by saying
that the client MUST NOT request it will make many clients non-conformant.

"the container MUST NOT by in the Option Request" =>
"the container MUST NOT be in the Option Request"

Section 20.13

There are more status codes defined than listed in this section. A text
similar to "Additional status codes have been defined in other
documents. Additional status codes may be defined in the future." and a
link to IANA page listing currently defined status codes would be useful
here.

Somewhere after 20.25 we must put a text similar to "Other options
are defined in other documents. Additional options will be defined in
the future. For the complete up to date list of currently defined
option, see IANA page [link].". This is important, especially due to the
remark made in 20.25: "This [Information Refresh Time Option] is listed
here for completeness." can be misinterpreted as "these are all the
DHCPv6 options that are currently defined".

General comment:
The header appearing on each page is "RFC 3315 bis". It's ok for the
time this draft is discussed in WG phase, but we should change this to
"DHCP for IPv6" before sending it to the IESG.

Section 21
I don't understand this paragraph: "In the case where relay agents add
additional options to Relay Forward messages, the messages exchanged
between relay agents and servers may be used to mount a "man in the
middle" or denial of service attack."

It doesn't make sense to me. If a relay agent is compromised (or
attackers manages to introduce a node he controls into the path, both
DOS and MITM attacks are possible, regardless of the original relay
agent inserted any options or not.

"in which the DHCP server sends the key to the client." =>
"in which the DHCP server sends the key in plain text to the client."

"A malicious requesting router may be able to mount a denial of
service attack by repeated requests for delegated prefixes that
exhaust the delegating router's available prefixes.". We should add
something similar to: "Some forms of this exhaustion attack can be
mitigated by appropriate server policy, e.g. limiting maximum number of
leases one client can get.".

Unless I missed something, we can probably remove this sentence:
"The details of using IPsec for DHCP are under development.". Or replace
it with a link to draft-ietf-dhc-sedhcpv6.

Section 22
"Section 3 of said document discuss..." =>
"Section 3 of said document discusses...".

Section 23
Do we want a separate column in IANA registry that explains which
options are singletons?

Section 24
"The following mechanism are..." =>
"The following mechanisms are..."

Section 26
I think we have way too many normative references. It's a bit of a
judgement call, but in my opinion, the following should be informative
rather than normative: 826, 2131, 2132, 2136, 2464, 3646, 4075, 4291,
4301, 4941, 5905, 6724, 7227.

Appendix A
I'm not sure if removing this is a good idea. There will be lots of
implementers and operators that don't participate in IETF at all. Once
the RFC is published, they'll be wondering what has changed and having
such a list may be of use for them. If we keep that list, we should add
a link to the dhcpv6bis tracker, so the ticket numbers would remain to
be useful.

Possible Appendix E
We could add a list of options with explicit specification which options
are singletons and which are not. This information could be also added
to the IANA registry. If anyone objects, I won't insist on that, though.

Ok, that's it. I have not further comments.

Tomek