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

["Woundy, Richard" <[e-mail]>]

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

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

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-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Bharat Joshi
Sent: Wednesday, October 07, 2009 12:29 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

Hi Rich,

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

Possible. The assumption I am making here is that a lease [subnet] can
be forcibly added or removed from DHCP server.
 
> 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.
> 

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

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

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.

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

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

> -- Rich




-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg