Subject: Re: [dhcwg] Comments ondraft-ietf-dhc-leasequery-by-remote-id-02.txt

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 21 Sep 2009 18:11:10 -0400

>>I would be interested to learn why the language regarding cacheing of
DHCPLEASEUNKNOWN responses was originally included in RFC 4388.

>I would also like to know that. :)

I assume you are talking about this text concerning the from section 6.5
of RFC 4388: "The access concentrator SHOULD cache this information, but
only for a relatively short lifetime, approximately 5 minutes."

This 'negative caching' was added to prevent a denial of service attack
on the DHCP server itself. From section 7:

   Access concentrators SHOULD minimize potential denial of service
   attacks on the DHCP servers by minimizing the generation of
   DHCPLEASEQUERY messages.  In particular, the access concentrator
   SHOULD employ negative caching (i.e., cache DHCPLEASEUNASSIGNED,
   DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY
   messages) and ciaddr restriction (i.e., don't send a DHCPLEASEQUERY
   message with a ciaddr outside of the range of the attached broadband
   access networks).  Together, these mechanisms limit the access
   concentrator to transmitting one DHCPLEASEQUERY message (excluding
   message retries) per legitimate broadband access network IP address
   after a reboot event.

-- Rich

P.S. Expect a slow response from me, as I'm working on other projects
lately.

---

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 21 Sep 2009 18:42:22 -0400

And the reason that the DHCPLEASEUNKNOWN negative response is cached --
not permanently stored -- is that the state of the DHCP server might
change in the future, which may not be detectable through DHCP message
gleaning.

For example, someone could add an IP subnet to the DHCP server, or even
possibly forcibly add an IP lease to the DHCP server.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Woundy, Richard
Sent: Monday, September 21, 2009 6:11 PM
To: Stephen Jacob; Damien Neil
Cc: DHC-WG WG
Subject: Re: [dhcwg] Comments
ondraft-ietf-dhc-leasequery-by-remote-id-02.txt

-- Rich

P.S. Expect a slow response from me, as I'm working on other projects
lately.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Kim Kinnear <[email-masked]>
Date: Tue, 22 Sep 2009 11:48:41 -0400

I've been trying to sort out what we meant by DHCPLEASEUNKNOWN
and DHCPLEASEUNASSIGNED when we wrote RFC 4388, and the
implications for their use in the leasequery-by-remote-id draft.

As nearly as I can recall, DHCPLEASEUNKNOWN was meant to convey
that we didn't know anything about the query in question.  That
could change, of course, but at present we simply had no current
information *and* no easily accessible historical information
about this object of this query.

DHCPLEASEUNASSIGNED, on the other hand, was meant to convey that
we *did* know something about the object of this query and,
indeed, that we had an IP address associated with the object of
this query.  Because either the object of the query *was* already
an IP address, or the object of this query was a MAC or client-id
which was associated with an IP address.  The idea was that we
got all the way to the end of the processing and had an IP
address (either directly or from a MAC or client-id association),
but the IP address was not leased (active).  If it had been
active, we'd do DHCPLEASACTIVE, but it wasn't.

Now, this isn't exactly what RFC 4388 says, as it largely
restricts the use of the DHCPLEASEUNASSIGNED message to queries
by IP address.  But the original intent does come through in a
number of places, since there was no real reason why you couldn't
return a DHCPLEASEUNASSIGNED message for a MAC or client-id based
query, if such a query turned up an IP address.  Obviously someone
objected to that, so we put words in to restrict it, but equally
obviously some of the original intent got left in, unfortunately.

I think a better resolution for RFC 4388 would have been to
restrict the DHCPLEASEUNASSIGNED message to a situation where
there is an IP address associated with the results of the query.
This would be obvious for an IP based query, and would require
work but would frequently be the case for a MAC or client-id
based query.

But that isn't strictly what RFC 4388 says.  However, there isn't
any reason, in my view, to prevent the remote-id draft from doing
something along those lines.  If the remote-id yields an
associated IP address and that IP address isn't active, then a
DHCPLEASEUNASSIGNED message would be quite appropriate in my
view.  Now, that doesn't give you the ability to return
DHCPLEASEUNASSIGNED if you "know" the remote-id but don't have an
IP address associated with it.  Which I'd be all right with too,
actually, though I think it is less interesting somehow.

Note that DHCPLEASEUNASSIGNED was to allow a DHCP server to say
that "I know something about this query, but I don't have a
leased IP address to return".  It was *not* designed to say "I
know everything about this query and you don't have to ask anyone
else".  It is too bad we weren't clearer about that.

---------------------

I could see that we might specify that in the remote-id draft the
DHCPLEASEUNASSIGNED message would mean "I know about an IP
address associated with this query but it isn't assigned/leased".
Alternatively it could be "I know about the object of this query,
but no leased IP address is associated with this object.".  I
rather like the former but the later would be ok with me too.  I
see no reason to remove the message.

In either case, I would suggest that the DHCPLEASEUNASSIGNED
message *not* be interpreted as "you can stop now, I know
everything there is to know about this IP address".  That isn't
what it was meant to say in RFC4388 nor should that approach be
used in the leasequery-by-remote-id draft.

Regards -- Kim

At 02:53 PM 8/10/2009, Stephen Jacob wrote:
>On Mon, Aug 10, 2009 at 11:37:34AM +0200, Bud Millwood wrote:
>> There is no guarantee that the server has a list of remote ids, but it's 
>> certainly possible. DHCPLEASEUNKNOWN seems like a reasonable response from a 
>> server that is explicitly configured to authenticate by remote ID.
>> 
>> If the server is *not* explicitly authenticating remote IDs, but instead is 
>> just recording those it has seen in the past, is a DHCPLEASEUNKNOWN response 
>> useful for the access concentrator?
>
>It is entirely possible for a server to use an external source of
>authentication by remote ID and thus to authenticate based on it
>but not inherently know about remote IDs that are considered valid.
>
>That said, I suppose such a server could probably consult the
>external authentication source regarding a remote ID in response
>to the DHCPLEASEQUERY.
>
>On the topic of whether DHCPLEASEUNASSIGNED even makes sense, I
>to side with Damien on this.
>
>When queried by IP address, you can say that a /lease/ is
>definitively unassigned or unknown depending on whether it is
>balanced to you and known to be unassigned or may have been
>assigned by a peer (or cooperating server!) -- i.e. unknown.
>
>In any sane DHCP installation you really /can/ know that an address
>is unassigned if either you are authoritative for the address
>and no failover is involved or if failover is involved and it is
>balanced to you. Any configuration in which that that is not true
>is broken.
>
>On the other hand, though, if you query by remote ID you will
>never, ever, definitively be able to say that nobody else has
>given a lease to that remote ID unless you have some extra-
>protocular knowledge. Since remote IDs don't balance to one
>server or another like leases (with failover), and since they
>are not segregated to only be answered by either "me or not-me"
>(cooperating DHCP servers), there is absolutely no way to ever
>say for sure that neither a failover peer nor some cooperating
>DHCP server has given a lease to a given remote ID.
>
>That is ... unless the server has been administratively
>configured in some way to promise it that it knows more than it
>can otherwise guess (sort of like you can administratively
>promise to one failover peer that its peer is dead to put it in
>PARTNER-DOWN versus COMMUNICATIONS-INTERRUPTED).
>
>I'm not sure that it's wise for the WG to publish a draft
>suggesting that servers should try to tell the difference. It
>seems like something very hard to determine in a DHCP server
>without customer-specific code to ensure that UNASSIGNED really
>is UNASSIGNED.
>
>That said, though ... it seems to me that there's the very same
>issue with query by client ID or query by MAC address, so perhaps
>we've already committed the faux pas.
>
>Does anybody actually have an implementation which differentiates
>and chooses whether to send DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN
>depending on ... something for query by Client ID or MAC address?
>
>Regards,
>Stephen
>-- 
> Stephen Jacob | [email-masked] | +1 650 381 6051
> Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000

---

From: Damien Neil <[email-masked]>
Date: Tue, 29 Sep 2009 21:40:44 -0700

Apologies for the delay in responding.

I'm going to try to summarize the current state of discussion.  I'm  
certain I don't need to ask to be corrected if I get something wrong. :>

RFC 4388 specifies:

- There are three types of leasequery: by-IP, by-MAC, and by-client-id.
- There are three possible responses to a query: DHCPLEASEUNKNOWN,
   DHCPLEASEUNASSIGNED, and DHCPLEASEACTIVE.
- DHCPLEASEUNASSIGNED may only be sent in response to a by-IP query.
- DHCPLEASEUNKNOWN or DHCPLEASEACTIVE may be sent in response to any  
query.

Section 6.5 of RFC 4388 is the only place that specifies how access  
concentrators should handle a DHCPLEASEUNASSIGNED response as opposed  
to  DHCPLEASEUNKNOWN: A DHCPLEASEUNKNOWN SHOULD be cached for "a  
relatively short lifespan", while a DHCPLEASEUNASSIGNED SHOULD be  
cached for an unspecified (and presumably indefinite) duration.

There are two questions that directly apply to the draft under  
discussion:

- Should a DHCPLEASEUNASSIGNED response be specified for a query by  
remote-id?
- What caching behavior should be specified for queries by remote-id?

Continuing on with my current thoughts:

I don't think it makes sense for the possible responses to a query by  
remote-id to differ from the possible responses to a query by client- 
id or MAC.  There isn't any meaningful difference between these query  
types that would call for them to be treated differently.

Either it is unnecessary to specify DHCPLEASEUNASSIGNED as a possible  
response to a query by remote-id, or RFC 4388 got it wrong and should  
have permitted DHCPLEASEUNASSIGNED responses to queries by client-id  
and MAC.

I don't really have a strong opinion on which case holds.  I would,  
however, like to avoid having every new query type come with its own  
unique set of behavior.  I don't have any good ideas at the moment on  
how to accomplish this; I just don't want to look back ten years from  
now on a plethora of different leasequery RFCs, each subtly  
incompatible with the rest.

                - Damien

---

From: pavan_kurapati <[email-masked]>
Date: Wed, 30 Sep 2009 11:53:42 +0530

Hello Damien,

I agree with your summary, except that query by remote-id is not exactly in the same group as client-id or mac. Because a query by remote-id gives "complete" information of a given i/f, a need of having limited time caching and retry doesn't arise. This was the reason we were not suggesting a DHCPLEASEUNKNOWN since it demands a lesser caching time compared to a DHCPLEASEUNASSIGNED. We seem to have different opinions in the group so I feel we need to arrive at a quick consensus on your below 2 points to move forward

Thanks,
Pavan

> Of Damien Neil
> Sent: Wednesday, September 30, 2009 10:11 AM
> To: DHC-WG WG
> Subject: Re: [dhcwg] Comments on draft-ietf-dhc-leasequery-by-remote-
> id-02.txt
>

---

From: Damien Neil <[email-masked]>
Date: Wed, 30 Sep 2009 11:10:34 -0700

On Sep 29, 2009, at 11:23 PM, pavan_kurapati wrote:
> I agree with your summary, except that query by remote-id is not  
> exactly in the same group as client-id or mac. Because a query by  
> remote-id gives "complete" information of a given i/f, a need of  
> having limited time caching and retry doesn't arise. This was the  
> reason we were not suggesting a DHCPLEASEUNKNOWN since it demands a  
> lesser caching time compared to a DHCPLEASEUNASSIGNED. We seem to  
> have different opinions in the group so I feel we need to arrive at  
> a quick consensus on your below 2 points to move forward

I'm not clear on how a query by remote-id gives more or less complete  
information than a query by client-id.  Could you clarify that point  
for me?

Thanks,

                  - Damien

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 1 Oct 2009 08:54:35 +0530

Dear Rich,

       Sorry for a very delayed reply. Please see my response in line.

> possibly forcibly add an IP lease to the DHCP server.

Ok. We had thought of this and had discussed it among ourselves [co-authors]. But there are issues with this assumption.

What we think is that a Relay Agent [Access Concentrator] should not worry about what it can not detect by gleaning DHCP messages. If it worries about things happening in DHCP server also, a Relay Agent [AC] would need to keep querying DHCP server even for Active leases. 

Taking cue from your above example, lets assume, an IP lease is first forcibly added and because of the caching and querying, we later received a LEASEACTIVE for this IP address. Now after some time, lets assume, that lease for this IP address is forcibly removed from the DHCP server. Now as mentioned above, Relay Agent can not detect this by gleaning DHCP messages as there is no DHCP release for this IP address. So how will Relay Agent find the new state for this IP address. Only by periodically checking the state of this IP address. That means it has to keep querying for all IP addresses for which LEASE is ACTIVE. This will result in too many unnecessary messages being exchanged between DHCP server and Relay Agents.

So this is one of the reasons, we decided against the use of periodic query if a DHCPLEASEUNKNOWN or DHCPLEASEUNASSIGNED is received for a specific 'Query-by-remote-id'.

Thanks,
Bharat

> P.S. Expect a slow response from me, as I'm working on other projects
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: pavan_kurapati <[email-masked]>
Date: Thu, 1 Oct 2009 10:40:46 +0530

Hello Damien,
Reply inline

Thanks,
Pavan

> From: Damien Neil [mailto:[email-masked]]
> Sent: Wednesday, September 30, 2009 11:41 PM
> To: pavan_kurapati
> Cc: Damien Neil; DHC-WG WG
[Pavan] We had explained it in detail in our draft. If the query is based on MAC, an access concentrator can never determine how many hosts are behind an interface at any given time. It needs to query based on data that comes and needs to repeat it until a max limit of an i/f is reached. A query by remote-id on other hand gives complete information because a remote-id can be made common for all hosts of a given circuit/interface. A reply to the query based on remote-id can precisely give all leases allocated for a given i/f.