Hi Mark -
I've looked at draft-ietf-dhc-dhcpv6-bulk-leasequery-05 and believe
that document is ready for publication.
RjS
On Nov 25, 2008, at 11:14 AM, Mark Stapp wrote:
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
