Re: [dhcwg] Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

[Sunil Gandhewar <[e-mail]>]

Hi Bernie,

I think since multiple client data can be combined into one packet, it improves on packet-flooding DoS attacks.

I understood now the case where device is behind the CPE. I am wondering what might be better way to document this. I am trying to cover both the caases below, the one Ian pointed out and the one you explained below. Do you think more explainatory examples are needed here? Does this description below would be enough to exclude the cases due to the network? Please suggest. Thanks a lot Bernie.

Applicability Statement (section 1.1 under Introduction):
With the Relay Initiated Release, the DHCP client's binding gets cleared from Relay towards the Server. There is no way to inform this to the client. If client maintains the state across reboots (e.g. client does not send release on power down and remembers the address and lease period on it's reboot/wakeup), it may start using the address for the remaining lease period. This will cause network issues as Relay and Server had cleared the binding whereas client is still using it's old state. This document is not applicable where client remembers states across it's reboot. For Relay Initiated Release to function properly, client MUST reestablish the binding on every power-on. The binding MUST come back with the normal mechanism on every power on.

In the network topology where DHCP client is not directly connected to the relay, when the network connection goes down relay would initiate the release and clear the binding for the client in the network. When the network connection comes back up, client has not actually powered off/on, and so client will continue to use the address it was using. Relay Initiated Release should not be used in such cases where there is no clear way to distinguish between network issue and client actually went off.

Relay Initiated Release is useful in the cases where there is a way to clearly know that the client actually went down, replaced or moved and will re-establish the binding when comes back.

Regards,
Sunil Gandhewar
Juniper Networks, Inc.
[e-mail]<mailto:[e-mail]>


From: Bernie Volz (volz) [mailto:[e-mail]]
Sent: Monday, August 03, 2015 11:31 PM
To: Sunil Gandhewar; [e-mail]
Subject: RE: Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

> Regarding security considerations, multiple client data can be combined into one message under Client_Data_option. Thus it can avoid too many messages i.e. need not be one message per client.

I understand that combining. But your security considerations doesn't really mean anything with this respect. This does nothing related to Denial of Service.


I am thinking about the DOCSIS case where there is a CPE in the home connect to a cable modem. In this case, the CPE gets a lease just as the CM does. And while your document doesn't explicitly mention this case, I think it can easily be seen to extend to it - i.e., a Relay Agent (CMTS in DOCSIS) that determines the modem is no longer 'on-line', might decide it can discard BOTH the modem and CPE leases (since the CPE lease is associated with that modem) and that could be a mistake when the CPE may have no knowledge that the modem went offline and therefore the relay 'released' its lease. When the modem goes back online, it will get a new lease; but the CPE never knew this happened and therefore does not obtain a new lease or take steps to 'confirm' its existing lease.

You might not be directly considering that case, but without proper language in the document, there is nothing to preclude using these capabilities in that case.


-          Bernie

From: dhcwg [mailto:[e-mail]] On Behalf Of Sunil Gandhewar
Sent: Monday, August 03, 2015 1:48 PM
To: Bernie Volz (volz); [e-mail]<mailto:[e-mail]>
Subject: Re: [dhcwg] Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

Hi Bernie,
Thanks for the quick reply.

There can be network issues and protocol issues, although one leads to other. The issue is due to the client not sending Release when it's done.
In the scenario you described, devices may be having private network address from the server running on the modem, right? Whereas the modem will actually get the public address from the network.
I agree that in some network topology there is no way of knowing this to the device. Hence I added the applicability statement as per your suggestion.
When I and Ole Troan were discussing, he told the network case he worked with where end device runs BFD and sends BFD packets on the interface towards the BNG with destination address of it's own. So BNG kind of loops-back the BFD packets. That way end device detects network connectivity.
What do you suggest, does the applicability statement I added is enough? Or shall I describe these network cases in that section?

I accept the comment regarding the interface-id.

>>> I think the text needs to be more clear what this should contain. Should it include the IA_NA, IA_TA, IA_PD options or just IAADDR and IAPREFIX? (The fact that one of the status codes is NoBinding might imply IA_NA/IA_TA/IA_PD, but not sure.)
Yes it means all the tyoes of IAs i.e. IA_NA, IA_TA and IA_PD. Should I mention that more specifically?

Regarding security considerations, multiple client data can be combined into one message under Client_Data_option. Thus it can avoid too many messages i.e. need not be one message per client.

Regards,
Sunil Gandhewar
Juniper Networks, Inc.
[e-mail]<mailto:[e-mail]>