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

>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: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 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: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 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
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> 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
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg