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

From: Robert Sparks <[email-masked]>
Date: Mon, 8 Dec 2008 09:35:57 -0600

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