Thanks for the review comments; please see my replies inline below.
Robert Sparks wrote:
Comments:
Apologies in advance if I'm tripping over things that are obvious to
folks that are deeply involved in the current dhcpv6 work. I have a
few high-level questions/observations:
1) The last paragraph of section 4 requires a dhcpv6 server that's
listening on UDP or other types of queries to reject a bulk-leasequery
with NotAllowed. This assumes the bulk-leasequery message was
constructed the way other UDP based dhcp messages are built
(specifically, not framed for TCP as defined in this document) and
then sent over UDP. This assumption should be explicitly stated in the
text.
That paragraph tries to make it clear that even though the TCP version
of the protocol shares the common query-type numbering space, there are
some query-types that are not valid with the UDP, one-lease-at-a-time
protocol. That issue was raised during WG discussion because some/many
implementations will support both query modes, so there was a need for
clarifying text in a couple of places about the behavior of those
implementations.
The text I've got is: "MUST NOT accept Bulk Leasequery query-types in
UDP Leasequery messages." I guess I do read that as "UDP format messages
that contain one of the new query-types defined here." Can you suggest
text that you'd find clearer?
There should also be some discussion of what happens if an
implementation frames the request for TCP and then sends it over UDP.
This is a common programming mistake in other protocols that can use
both transports. Did the working group discuss the tradeoffs of
putting this message-size at the front of the request instead of
inside the message-type specific space (allowing unmodified servers to
reject the request)?
We hadn't considered that too much of a _protocol_ problem, though of
course it would be a bug. A requestor who wanted to use the TCP protocol
would need to set up a TCP connection, for example. Certainly, someone
could always send a frame down the wrong socket, but that's really an
implementation issue, isn't it? I mean, someone could always send a
query to the wrong destination address, or supply byte-swapped query
data, but those are really implementation bugs. I've added a new brief
paragraph at the end of that section, just making it explicit that the
TCP framing would produce invalid UDP messages.
We did talk within the working group about the framing, and the
conclusion was that the length prefix was the preferred solution. That's
been widely used in other familiar protocols that have both UDP and TCP
flavors (like DNS), so it seemed a natural choice for us too.
2) There are places in the draft where its unclear if you intending to
just use TCP (which I think is the case) or if you are expecting to
influence the behavior of TCP. The last sentence of 7.4 is
particularly confusing: "If the server detects that the client end has
been closed, the server MUST close its end of the connection after it
has finished processing any outstanding requests from the client."
(Its also not clear why the server would finish processing the
outstanding requests that arrived on this connection).
I think that came from working-group discussion actually. There is a
valid TCP pattern, I was told, in which a client does a half-close of
just the 'write' half of its end of the connection. In that case, the
server would get a zero-length read on the connection. But in a
multi-threaded server, for example, background processing that's
delivering results to the client's 'read' half of the connection will
not see an error while sending, and that background processing is
allowed to continue. Personally, I don't expect that to be widely used,
but ... as I say, the question came up and I've tried to make the spec
explicit about what should happen.
3) The second paragraph of 7.1 talks about restricting connections to
"certain clients" but is not explicit about how those clients are
identified. Was this discussed?
Yes. The working group has typically tried to avoid specifying "policy"
- though it's sometimes tempting. The group has generally accepted text
that described _where_ a policy might be applied, but has generally not
accepted text that specifies the policy. So in this case we discussed
some of the ways that an implementation might be configured with info
about leasequery clients, but there didn't seem to be interest in text
that specified required configuration parameters.
4) I'd expect the implementer community in this space to be really
sharp on UDP security issues. Are these folks as up to speed on such
considerations when using TCP (this appears to be the first use of TCP
in this protocol suite)? If not, I wonder if there's a richer set of
considerations already captured somewhere that this document can point
to?
There's a lot of security-related text in the omnibus RFC 4614, and I
didn't really want to try to cut-and-paste that into this spec. I did
include some specific comments on a couple of points that seemed "new"
to us - about resource exhaustion, for example - but I do think that
4614 is the "richer" place you're thinking about.
Nits:
It might help to leave explicit notes the RFCeditor on how to replace
the TBDs in 5.2.1/2 based on the IANA actions.
Yes, I've removed the "TBDs" and clarified some other IANA-related text.
I'd gotten a couple of last-call comments in that area. I've actually
already heard from IANA with a draft of their updates, so things seem ok
there now.
Thanks,
Mark
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
