Subject: [dhcwg] Regarding Extension of Leasequery draft

From: "pavan_kurapati" <[email-masked]>
Date: Wed, 6 Dec 2006 16:43:38 +0530

Hi,

There were some issues raised during the last WG meet regarding this draft(www.ietf.org/internet-drafts/draft-joshi-dhcp-lease-query-ext-02.txt) and it was decided to take it to the mailing list. We have discussed some of these issues offline with those who have raised these during WG meeting. I am listing the discussions with clarifications.

1. Is this draft related to only DSL technology?

No. Our draft applies to any Layer 2 Access Networks for example, xPON, Wimax, EFM etc.

2. DSL Forum has suggested an alternate method (BFD) which obviates the need of Leasequery

The proposal is just a draft method. BFD itself doesnt solve the problem completely.
BFD defines a mechanism to check the status of IP session between IP edge router and CPE. When L2RA goes down, CPE would tear down the IP session and restarts the DHCP. So, L2RA would rebuild the lease information from scratch and so leasequery may not be required. But there are many deployments where DHCP Clients reside outside RG/Modems and RG does plain bridging. In this case BFD would not work because we cant have all user equipments running BFD. Also, it will not work when L2RA comes back up before the BFD keepalive timer expires.

3. Modem would know DSL line going down and initiate DHCP again
We have seen deployments where even if modem is acting as a DHCP client, modem does not restart the DHCP re-configuration when the line goes down. Also as mentioned above, there are many deployments where DHCP is initiated by an entity residing outside the modem.

4. What will happen when L3RA also removes the state when L2RA goes down? How to bring the state in L3RA up?

L3RA generally doesnt keep state. In cases where it keeps the state and removes the routes after detecting that it is no longer valid (either by BFD or by any other means) there has to be a mechanism to bring the state up in L3RA. To address this we plan to propose the following

In the below scenario, L3RA has removed IP session and does not have the state anymore. L2RA has also lost its state because of reboot.

Client sends a packet upstream. L2RA generates leasequery. L3RA updates 'giaddr' with incoming i/f IP address. If LEASEACTIVE is received, L3RA would update its state and bring up the IP session. L3RA would forward the LEASEACTIVE to L2RA. L2RA would update its state in its own table. L3RA might contact AAA/policy server to trigger the authorisation again after seeing LEASEACTIVE. This is out of scope of the document.

For downstream packets, L3RA should have a mechanism to re-create the IP session if required. To re-create the IP session L3RA might use same  mechanism mentioned in RFC 4388.

Please let us know if there are any more suggestions/concerns regarding this draft.

Thanks,
Pavan

Pavan Kumar Kurapati
Infosys Technologies Ltd,
Bangalore

**************** 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://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Richard Pruss <[email-masked]>
Date: Tue, 12 Dec 2006 14:18:58 +1000

Hi Pavan,

Cisco now has a ton of features both in enterprise and in SP markets 
layer 2 devices that are gleaning feature state by watching DHCP events. 
These features are the cornerstones of current layer to protection for 
the ARP table, IP spoofing and control path attacks.

What I was trying to say was not that we do not need something like your 
leasequery draft. I feel there is a need to acknowledge that a ton of L2 
devices snoop DHCP because it is there best indication of what is 
happening but this approach has problems in the long term if we do not 
start to engineer for this. The DSL forum BFD is a good example of the 
types of problems that can occur.

e.g.  If BFD times a session out.  The BRAS will clean up it's state but 
the non-directly L1 connected L2 devices will have no indication that 
the session has gone away.  If we are using the DHCP snooping to close 
holes, those holes will now be open and nothing will close them before 
the L2 device times out, probably at the end of the lease period.

There needs to be some framework for the state in these devices to be 
coupled to other parts of the system, and while leasequery addresses how 
to recover from stateloss in the L2 device it does not address how to 
keep the L2 device coupled for the other changes in the system.

Some comments inline:

> BFD defines a mechanism to check the status of IP session between IP edge router and CPE. When L2RA goes down, CPE would tear down the IP session and restarts the DHCP. So, L2RA would rebuild the l…
Actually I feel both these point are wrong:
a)  The whole point of this is to replace PPPoE and so just like 
Microsoft supports PPPoE today, BFD is a perfectly reasonable thing to 
run on all clients.  In fact many Cisco clients ran ICMP for this until 
Microsoft Service Pack 3 shut down echo response by default.
b) BFD timers can easily be aggressive enough (say 3x5seconds) to 
recover before users start to take action.  As a rule of thumb one can 
say 8 seconds before they notice and around 30 seconds before they take 
action.

> We have seen deployments where even if modem is acting as a DHCP client, modem does not restart the DHCP re-configuration when the line goes down. Also as mentioned above, there are many deployment…
We can make it a requirement of "modem" behaviour

Cheers,
Ric

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 19 Dec 2006 16:58:55 +0530

Hi Richard,

    Thanks for your response and sorry for a delayed reply.

    We think we all [you, Woj and others in DHC WG] agree that our draft
'Extension of Lease Query to switching and bridging networks' solve
certain problems associated with Layer 2 Relay Agents.

    We understand that if an Access Network does not implement BFD, our
solution would be best suitable to the problem we solve.

> the ARP table, IP spoofing and control path attacks.

This is the kind of problem we are trying to solve here. Thanks for
pointing out that there are certain layer 2 devices Cisco has which
might require this.

> keep the L2 device coupled for the other changes in the system.

    Please correct us if we are wrong, its our understanding that BFD is
being developed to solve an entirely different problem [keeping alive
the IP session between BRAS and modem/clients]. But because of BFD,
either our solution may not be required in certain network
configurations or layer 2 relay agent may be out of sync when it brings
down the IP session.

    We think that with BFD, we not only have to sync Layer 2 Relay Agent
[i.e. releasing lease information and other details it maintains] but
DHCP server as well. DHCP server would still hold on to a lease until
the lease expires or DHCP client sends a DHCP RELEASE. So even if we
somehow flush the lease information in Layer 2 Relay Agent, we still
have a problem.

    Now why we think it should work as it is that Layer 2 Relay Agent
MUST flush the lease information only in two cases. One is when it sees
a DHCP RELEASE from the client or when the lease timer expires. If BFD
brings an IP session down and modem/CPE/Gateway triggers the DHCP
DISCOVER, layer 2 relay agent should behave similar to the DHCP server
which still has a Lease-Active for this client. So we think everything
will work as expected if states in Layer 2 Relay agent is in sync with
DHCP server and thats exactly what would happen here.

    Please let me know if you have any questions.

Thanks & Regards,
Bharat