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

["Bernie Volz (volz)" <[e-mail]>]

Just to be clear these are my personal comments and not as WG co-chair.


> If client maintains the state across reboots ... client MUST reestablish the binding on every power-on ...

There are cases where a reboot is not even necessary. Think of a Cable Modem with a CPE with some kind of bridge between them that does not provide any signaling when the CM link is dropped. In this case, the CPE will happily continue to try to use its lease(s) until they expire. There is no reboot of the CPE (or CM) involved.

This may be what your 2nd paragraph is trying to say? But I'm not sure what "client is not directly connected to the relay" means.


The applicability statement is difficult for this work because it is fairly complex - the kind of places this will work when there are multiple devices (such as CM + CPE) involved is pretty tricky. For a device that has a virtual circuit to the relay, it is pretty straight forward - if the virtual circuit goes down, the device will have to reestablish the circuit and also do DHCP. But for other devices 'behind' this device, it is less clear as you do not know if they are keeping state or not.

Also, in cases where a circuit may be bouncing up and down, there could be interesting timing issues - especially if the relay to server network connection itself is multi-path or bouncing ... think what would happen if a (early generated) release is delayed in the network and the DHCP client has in the meantime done a Solicit/A/R/R (which renewed the existing lease) ... the delayed packet will result in the lease being released when it should not have been since the client just reestablished it. You would have to deal with this issue on out-of-order packets between relay and server.


Anyway, I am really skeptical whether the complexity of doing this is worth it. And even more so in v6 as there at least for addresses, we have no shortage (and hopefully the same can be said for prefix delegation, but clearly the space available there is less than for addresses).


-          Bernie


From: Sunil Gandhewar [mailto:[e-mail]]
Sent: Tuesday, August 04, 2015 10:52 AM
To: Bernie Volz (volz); [e-mail]
Cc: Sunil Gandhewar
Subject: RE: Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

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]<mailto:[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]>