Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-leasequery-by-remote-id-05.txt

From: Stephen Jacob <[email-masked]>
Date: Tue, 20 Jul 2010 11:13:34 -0700

I have read the updated draft.

My apologies for not being able to look at this sooner.  At the
point where I was made aware of the new draft, I was unable to get
any time to read it or comment upon it.  I hope this review is
useful in spite of the fact that it may be past the end of a last
call.

The new version of the draft addresses some of my concerns with the
previous version of the draft (notably, elimination of the
DHCPLEASEUNASSIGNED response to this type of query) ... but I am
still not convinced by the suggestion that a DHCPLEASEUNKNOWN
response can be "definitive" or that it can be cached indefinitely.

It is possible that I am missing something subtle, but it seems to
me that either with cooperating servers or with failover if there
is network partition or (more simply) if the DHCPLEASEQUERY message
does not reach one or more servers (or their responses do not reach
the client [relay agent]) then a DHCPLEASEUNKNOWN response from one
or more servers cannot, in fact, be considered definitive at all,
unless the router/relay agent performing the DHCPLEASEQUERY knows
that all of the servers have responded or there is some a priori
shared knowledge outside the DHC protocol about servers knowing
definitive information (like if the router knows that all the
DHCP servers will consult a common database or authorization
system before responding to DHCPLEASEQUERY--which is not something
that can be considered to be generally true).

It seems to me this is exactly why RFC 4388 says such responses
should be cached only short-term (e.g. 5m).

I do not think section 4.6 of the draft should be suggesting
changed caching semantics for DHCPLEASEUNKNOWN (after all, it
seems to me that the caching semantics are really the whole reason
to use DHCPLEASEUNKNOWN and not DHCPLEASEUNASSIGNED).  Periodic
retries seem to me to be necessary, as specified in RFC 4388.

Other than the above, I only have copy edit style comments, which
I will include in-line:

| DHC Working Group                                            P. Kurapati
| Internet-Draft                                     Juniper Networks Ltd.
| Expires: December 9, 2010                                     R. Desetti
|                                                                 B. Joshi
|                                                Infosys Technologies Ltd.
|                                                             June 7, 2010
| 
| 
|                DHCPv4 Leasequery by relay agent remote ID
|              draft-ietf-dhc-leasequery-by-remote-id-05.txt
| 
<snip>
| Table of Contents
| 
|    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
|    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
|    3.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  7
|    4.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . .  8
|      4.1.  Sending the DHCPLEASEQUERY Message . . . . . . . . . . . .  8
|      4.2.  Responding to the DHCPLEASEQUERY Message . . . . . . . . .  9
|      4.3.  Determining the IP address to be used in response  . . . .  9
|      4.4.  Building a DHCPLEASEUNKNOWN or DHCPLEASEACTIVE message . . 10
|      4.5.  Sending a DHCPLEASEACTIVE or DHCPLEASEUNKNOWN Message  . . 10
|      4.6.  Receiving a  DHCPLEASEACTIVE or DHCPLEASEUNKNOWN
|            Message  . . . . . . . . . . . . . . . . . . . . . . . . . 10

This may be waaaaaay too nick-picky, but it stood out to my brain
when scanning this that the ordering of the message names in the
titles of 4.4, 4.5 and 4.6 was arbitrarily different (perhaps 4.4
should be re-ordered?).

|      4.7.  Receiving No Response to the DHCPLEASEQUERY Message  . . . 11
|      4.8.  Lease Binding Data Storage Requirements  . . . . . . . . . 11
|      4.9.  Using the DHCPLEASEQUERY Message with Multiple DHCP
|            Servers  . . . . . . . . . . . . . . . . . . . . . . . . . 11
|    5.  RFC 4388 Considerations  . . . . . . . . . . . . . . . . . . . 12
|    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
|    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
|    8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
|    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
|      9.1.  Normative Reference  . . . . . . . . . . . . . . . . . . . 16
|      9.2.  Informative Reference  . . . . . . . . . . . . . . . . . . 16
|    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
<snip>
| 4.1.  Sending the DHCPLEASEQUERY Message
| 
|    The DHCPLEASEQUERY message is typically sent by an access
|    concentrator.  The DHCPLEASEQUERY message uses the DHCP message
|    format as described in RFC 2131 [RFC2131], and uses message number 10
|    in the DHCP Message Type option (option 53).  The DHCPLEASEQUERY
|    message has the following pertinent message contents:
| 
|    o  The giaddr and Parameter Request List option" are set as explained
|       in section 6.2 of RFC 4388 [RFC4388].

Excess " after "option".

|    o  There MUST be a Relay Agent Information option (option 82) with
|       only Agent Remote ID sub-option (sub-option 2) in the
|       DHCPLEASEQUERY message.
| 
|    o  The "ciaddr" field MUST be set to zero.

Should "ciaddr" appear in quotes?

giaddr doesn't, above, and nor do htype, hlen and chaddr below.

|    o  The values of htype, hlen, and chaddr MUST be set to zero.
| 
|    o  The Client-identifier option (option 61) MUST NOT appear in the
|       packet.

Should this not be either "Client Identifier" or "client-identifier"?
The capitalization seems inconsistent.

<snip>
|    o  DHCPLEASEUNKNOWN
| 
|    The DHCPLEASEUNKNOWN message indicates that the client associated
|    with the agent remote-ID suboption of the DHCPLEASEQUERY message is
|    not allocated any lease or it is not managed by the server.

I think this should be "Remote ID" to match below (section 4.3) or
at least the usage should be made consistent throughout.  Other
possible options: "Remote-ID", "remote-id".

RFC 3046 uses "Agent Remote ID" and "Remote ID", occasionally
lowercasing the 'R' but never using a dash (-), so I would vote for
"Remote ID" or "Agent Remote ID" and making it consistent throughout
the document.

<snip>
| 4.6.  Receiving a  DHCPLEASEACTIVE or DHCPLEASEUNKNOWN Message
<snip>
|    When a DHCPLEASEUNKNOWN message is received by an access concentrator
|    that had sent out a DHCPLEASEQUERY message, it means that the DHCP
|    server does not have definitive information concerning the DHCP
|    client specified in the Agent Remote ID sub-option of the
|    DHCPLEASEQUERY message.  The Access Concentrator MAY store this
|    information for future use.  However, a DHCPLEASEQUERY SHOULD NOT be
|    attempted with the same Remote ID sub-option.
| 
|    For leasequery by remote-id, the impact of negative caching is
|    greatly reduced as the response leads to "definitive" information on
| 
|    all the hosts connected behind the connection.  Note that in the case
|    of data-driven approach [RFC4388], a host spoofing several IP
|    addresses can lead to negative caching of greater magnitude.  Another
|    important change this draft brings is the removal of "periodic"
|    leasequeries generated from negative caching caused by
|    DHCPLEASEUNKNOWN.  Since the information obtained through query by
|    remote-id is complete, there is no need of attempting leasequery
|    again for the same connection.

See top of e-mail for my disagreement with this section.

<snip>
| 5.  RFC 4388 Considerations
<snip>
|    o  RFC 4388 [RFC4388] suggests that a DHCPLEASEUNASSIGNED is returned
|       only in the case of 'query by IP address'.  All other query types
|       will have a return message of either DHCPLEASEACTIVE or
|       DHCPLEASEUNKNOWN.  Although it would be possible to return
|       DHCPLEASEUNASSIGNED in case of a query by remote-id, in order to
|       maintain compatibility with other similar query types (MAC and
|       Client-id) a query by remote-id does not support a
|       DHCPLEASEUNASSIGNED response.

I disagree with this statement.  For reasons I stated at the top of
this e-mail, I think DHCPLEASEUNASSIGNED would be invalid.  Thus, I
don't think the draft should be on the one hand not using it but on
the other hand asserting that we could have chosen to use it.

<snip>
| 8.  Acknowledgments
| 
|    Copious amounts of text in this document are derived from RFC 4388
|    [RFC4388].  Kim kinnear, Damien Neil, Stephen Jacob and Alfred Hoenes
|    provided valuable feedback on this document

Capitalize "Kinnear". :)

That's it!

Regards,
Stephen
-- 
 Stephen Jacob | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000

---

From: Pavan Kurapati <[email-masked]>
Date: Wed, 21 Jul 2010 08:55:16 +0530

Hello Stephen,

Thanks for the detailed review. I will take care of the editorial changes
that you suggested in the next version. Regarding your suggestion on
UNKNOWN, the reason we thought it as definitive is because for a data-driven
query type, we dont know how many hosts are connected behind a "connection"
whereas in the Remote ID query we get definitive response for all the hosts.
I understand that if all servers do not reply or if host do not get all the
replies we cannot be certain. However, the same is true even for
LEASEACTIVE. We may have a case where not all LEASEACTIVEs are sent or
client has not received all. Then why should there be a difference in
behavior for LEASEACTIVE and UNKNOWN? Can you please clarify this.

Thanks,
Pavan

On Tue, Jul 20, 2010 at 11:43 PM, Stephen Jacob
<[email-masked]>wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Stephen Jacob <[email-masked]>
Date: Tue, 20 Jul 2010 22:10:47 -0700

On Wed, Jul 21, 2010 at 08:55:16AM +0530, Pavan Kurapati wrote:
> that you suggested in the next version.

No problem. Thanks!

> Regarding your suggestion on

Hm. That is actually a really good point.
 
I'm not sure I can justify why a set of DHCPLEASEUNKNOWN responses
(or a combination of DHCPUNKNOWN and DHCPLEASEACTIVE responses)
should be considered less definitive than a set of DHCPLEASEACTIVE
responses. You are indeed correct that in either case there could
be missing DHCPLEASEACTIVE responses.

I guess in light of that I cannot really object.

Regards,
Stephen

---

From: Pavan Kurapati <[email-masked]>
Date: Wed, 21 Jul 2010 16:39:10 +0530

Thanks Stephen