Subject: [dhcwg] Lease query by remote-id

From: Bharat Joshi <[email-masked]>
Date: Wed, 29 Oct 2008 09:38:37 +0530

Hi All,

     We have submitted a 0th version of 'Lease query by remote-id' draft. This was accepted as DHC Working Group item in last IETF.

     Please review the same and let us know your comments. Draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-by-remote-id-00.txt

Thanks,
Bharat

**************** 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: Fri, 31 Oct 2008 16:53:11 +0530

Hi Andre,

     Thanks for reading it up. Please see my response in line.

     I can spin another revision if you have any comments or if I get any more comments on mailing list on this draft.

Regards,
Bharat

>Upon first reading, one part that jumped out at me is where this draft
> explicitly changes what DHCPLEASEUNASSIGNED means, but only in the
> context of this particular query type.   Theoretically a DHCP server
> could make the same sort of determination that it is responsible for IP
> allocation for a CHADDR or ClientID, but it is still required to answer
> with a DHCPLEASEUNKNOWN.  I think that if the DHCP server doesn't have a
> lease for a RemoteID, it should similarly respond with a
> DHCPLEASEUNKNOWN, not a DHCPLEASEUNASSIGNED, to be consistent with the
> established behaviour of the two existing query types.

We assumed that a DHCP server would be able to figure out if it is serving a given remote-id or not. So it should be able to reply with DHCPLEASEUNASSIGNED for those which it may be serving but does not have any active lease associated with it.

With query-by-remote-id, we remove the requirement of negative caching as well as querying for a remote-id if DHCP server returns either DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN. [Actually this is one of the motivation point of coming out with this draft]

Do you see any specific issue with this approach?

> Another thought, wouldn't the suggested deployment scenario basically
> ensure that a DoS attack is launched at the DHCP server when the DSLAM
> is rebooted?  The draft talks about "should query the server for the
> lease information for all the connections/circuits".  If the DSLAM has
> very many of these, wouldn't that cause a flood to the DHCP server?

Yes. Draft do mention that a relay agent can query for all the connections. However draft clearly avoids to make any recommendation on when this should be done.

I think this depends upon the implementation as well as how this will be deployed? There are multiple cases when a relay agent may start querying, for example:

* It can start queryiny for all remote-ids as soon as it start coming up.
* It can start querying for remote-ids corresponding to a line card that has just come up.
* It can start querying for remote-ids corresponding to connections which has just come up.

So if a DSLAM does it based on second and third approach, there may not be much traffic coming to DHCP server. But I agree that there may be huge traffic when it does things based on the first approach. This will be worst if multiple relay agent does this at the same time or nearly same time.

Do you think it make sense to add these details in the draft? I can add some text in the Security Consideration as well.

> Another deployment scenario where I think this may be useful is in the
> cable environment where the CMTS is the one playing Relay Agent and the
> source of LeaseQueries.  Theoretically as the cable modems reconnect to
> the CMTS after a reboot, this could cause the appropriate LeaseQuery by
> RemoteID to be emitted by the CMTS, which would preemptively repopulate
> the tables in the CMTS (the further downstream clients couldn't pass
> traffic before this time anyway since the CM wasn't talking the CMTS
> yet).
>

Yes. I agree. In fact, I talked to couple of my colleagues who actively work in this area and they had mentioned something similar.