Subject: Re: [Gen-art] Gen-art IETF LC review of draft-ietf-dhc-dhcpv6-bulk-leasequery-0

From: Mark Stapp <[email-masked]>
Date: Tue, 25 Nov 2008 12:14:23 -0500

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-masked]
https://www.ietf.org/mailman/listinfo/gen-art