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

From: Damien Neil <[email-masked]>
Date: Thu, 1 Oct 2009 00:31:14 -0700

On Sep 30, 2009, at 10:10 PM, pavan_kurapati wrote:
> [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.

Okay, I see what you're getting at.

I don't see why this implies different caching requirements than a  
query by client id or MAC, however.

                - Damien

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 6 Oct 2009 12:51:07 -0400

>Now after some time, lets assume, that lease for this IP address is
forcibly removed from the DHCP server.

I think you are making an assumption that I am not making.

I see the lease time (option 51) in a leasequery message to be somewhat
like an implicit contract. If the lease is forcibly removed from the
DHCP server, then the contract is broken.

There isn't a lease time in a DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN
message, so there isn't a contract. If a subnet is subsequently added to
the DHCP server, then again it doesn't change any contract.

This behavior is important because in the real world, you don't want to
make assumptions about the order of activities. If an IP subnet is added
to a relay agent before it is added to a DHCP server, then it is
possible that a DHCPLEASEUNKNOWN message could be generated by a lease
query from the relay agent. It is desirable that when the IP subnet is
added to the DHCP server, that any cached DHCPLEASEUNKNOWN messages are
purged from the relay agent in a timely manner.

In general, it is better not to persist negative cache entries.

-- Rich

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

Dear Rich,

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

> 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.

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

> -- 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
> 
> >>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.
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
**************** 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***
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 7 Oct 2009 21:59:03 +0530

Hi Rich,

> I think you are making an assumption that I am not making.

Possible. The assumption I am making here is that a lease [subnet] can be forcibly added or removed from DHCP server.
 
> DHCP server, then the contract is broken.

But is not adding a lease forcibly in the DHCP server without Relay Agent's knowledge is also not correct?

> the DHCP server, then again it doesn't change any contract.

I think the difference in our point of view is coming from the fact that you are talking about a subnet while I am talking about a lease from an already existing subnet or a new subnet. From your reply, it looks to me that adding/removing a lease forcibly may not be the right way of doing things. Please correct me if my interpretation of this is wrong.

> purged from the relay agent in a timely manner.

I think the caching of DHCPLEASEUNKNOWN will be replaced with caching of DHCPLEASEUNASSIGNED without periodic querying. Right?

> In general, it is better not to persist negative cache entries.

I agree. I think we can not avoid caching some specific information but querying should be as minimized as possible.

Thanks,
Bharat

-----Original Message-----

Dear Rich,

--

even

Thanks,
Bharat

of
6.5
but
attack
broadband

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 8 Oct 2009 18:34:58 -0400

>But is not adding a lease forcibly in the DHCP server without Relay
Agent's knowledge is also not correct?

I am not as sure about whether adding a lease forcibly into the DHCP
server, without the Relay Agent's knowledge, is 'correct' or not, from a
protocol perspective. I'll leave that to the working group.

I do know that some DHCP servers have the ability to 'import' leases,
although its common use case is to transfer management of the imported
leases from one DHCP server to another. There may be other uses for this
function as well.

I will note that adding such a lease does not seem to violate the
'contract' that I mentioned below.

>I agree. I think we can not avoid caching some specific information but
querying should be as minimized as possible.

I agree that querying should be minimized, to maintain performance and
to avoid denial of service attacks. But I would avoid keeping negative
cache entries on a permanent basis.

Some of the downsides of negative caching are captured here:
http://en.wikipedia.org/wiki/Negative_cache.

-- Rich

P.S. This is my last email on this subject. I have to get back to my day
job.

-----Original Message-----
Sent: Wednesday, October 07, 2009 12:29 PM

Hi Rich,

> I think you are making an assumption that I am not making.

Possible. The assumption I am making here is that a lease [subnet] can
be forcibly added or removed from DHCP server.
 
> DHCP server, then the contract is broken.

But is not adding a lease forcibly in the DHCP server without Relay
Agent's knowledge is also not correct?

> the DHCP server, then again it doesn't change any contract.

I think the difference in our point of view is coming from the fact that
you are talking about a subnet while I am talking about a lease from an
already existing subnet or a new subnet. From your reply, it looks to me
that adding/removing a lease forcibly may not be the right way of doing
things. Please correct me if my interpretation of this is wrong.

> purged from the relay agent in a timely manner.

I think the caching of DHCPLEASEUNKNOWN will be replaced with caching of
DHCPLEASEUNASSIGNED without periodic querying. Right?

> In general, it is better not to persist negative cache entries.

I agree. I think we can not avoid caching some specific information but
querying should be as minimized as possible.

Thanks,
Bharat

-----Original Message-----

Dear Rich,

--

even

Thanks,
Bharat

of
6.5
but
attack
broadband

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 08 Oct 2009 15:53:04 +0100

Bharat Joshi wrote:

>  From your reply, it looks to me that adding/removing a lease forcibly 
may not be
 > the right way of doing things.

	That's an understatement.

	Forcibly removing a (server's record of a) lease breaks an
	established "contract" without notifying the other party.
	It's dangerous, as it invites duplicate use of the address,
	which may (or not) be prevented by other safety measures.

	Forcibly adding a lease asserts a "contract" which the
	other party has no knowledge of.  This is unlikely to be
	dangerous, as a conflicting request from a third party,
	received during the validity period of the "stealth"
	contract, will be refused.  It may conceivably be useful
	to do this in order to prime the server in favour of an
	anticipated request.

	Best regards,

	Niall O'Reilly