Internet Engineering Task Force T. Yang Internet-Draft L. Li Intended status: Standards Track Q. Ma Expires: January 13, 2013 China Mobile July 12, 2012 Mitigating aggregated traffic of DHCP discover messages draft-yang-dhc-ipv4-dis-01 Abstract This document defines a new option DIS_MAX_RT which can mitigate aggregated traffic caused by discover messages the clients send to the server. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 13, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Yang, et al. Expires January 13, 2013 [Page 1] Internet-Draft DHC-DIS July 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 3. Potential Problems . . . . . . . . . . . . . . . . . . . . . . 3 4. DIS_MAX_RT and DIS_MAX_RT_OPTION . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Refrences . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Yang, et al. Expires January 13, 2013 [Page 2] Internet-Draft DHC-DIS July 2012 1. Introduction In RFC2131 [RFC2131], there are no specific definitions for client's operation if the server does not respond for the discover messages. In some cases, this will lead to an unacceptably high volum of aggregated traffic at a DHCPv4 server. In RFC3315 [RFC3315], SOL_MAX_RT is defined as an option of DHCPv6 message to prevent the frequently requesting of clients, which reduce the aggregated traffic. In DHCPv4, there are no corresponding IPv4 options. Although the format of DHCPv4 is different with DHCPv6, it is also necessary to introduce similar option in DHCPv4 to keep the consistency between DHCPv4 and DHCPv6. This document updates RFC 2131 [RFC2131] by defining a new option DIS_MAX_RT which makes the DHCPv4 server mitigating aggregated traffic of client's discover messages. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Potential Problems RFC2131 [RFC2131] defines the interaction between the DHCP server and clients. There are no specific discription for client's operation when the client does not receive the DHCPOFFER in response to its DHCPDISCOVER message. In normal IPv4 environment, clients will flood DHCPDISCOVER messages only when the server or link is broken. But in Dual-Stack scenarios, the problem becomes more frequent and serious. In IPv6 LAN/WLAN network or intranet, the core router or AC often plays the role of DHCP server, and the clients are serval thousands PC or mobile phones. If the server is configured in IPv6-only, the clients in dual-stack or IPv4-only, they will broadcast DHCPDISCOVER messages endlessly in the LAN or WLAN. The thousands clients will cause a DDOS-like attack to all the servers in the intranet. Yang, et al. Expires January 13, 2013 [Page 3] Internet-Draft DHC-DIS July 2012 ________ | |DISCOVER1 | PC |----------------- |________|DISCOVER2 | __________ ...... |----->| | | DHCP | ________ |----->| server | | |DISCOVER1 | |-->|__________| | MS |----------------- | |________|DISCOVER2 | ...... | ...... | ________ | | | | | |-------------------- |________| Figure 1: DHCPDISCOVER flood in LAN/WLAN To avoid this problem, most of the terminals creat backoff algorithms which can help them retransmit DHCPDISCOVER message in different frequency according to their state machine in different Operating Systems, because there is no specific defenition in RFCs to restrict the terminals behaviors when the server is down or in a dual-stack scenario as discripted upwards. But the same point of almost all the verious Operating Systems is that they could not stop DHCPDISCOVER requests enven to an IPv6-only server. We test some of the most popular terminals' OS in WLAN, the results are illuminated as below. Yang, et al. Expires January 13, 2013 [Page 4] Internet-Draft DHC-DIS July 2012 ------------------------------------------------------------------------ | DHCP Discovery Packages Time Table | |----------------------------------------------------------------------| | | Windows7 |Windows XP | IOS_5.0.1 |Android_2.3.7|Symbian_S60 | |No|Time | Time | Time | Time |Time | Time |Time | Time | Time | Time| | | |offset| |offset| |offset| |offset | |offse| |--|-----|------|------|------|-----|------|-----|-------|-------|-----| |1 |0 | |0 | |0.1 | |7.8 | | 0 | | |2 |3.9 |3.9 |0.1 | 0.1 |1.4 | 1.3 |10.3 | 2.5 | 2 | 2 | |3 |13.3 |9.4 |4.1 | 4 |3.8 | 2.4 |17.9 | 7.6 | 6 | 4 | |4 |30.5 |17.2 |12.1 | 8 |7.9 | 4.1 |33.9 | 16 | 8 | 2 | |5 |62.8 |32.3 |29.1 | 17 |16.3 | 8.4 |36.5 | 2.6 | 12 | 4 | |6 |65.9 |3.1 |64.9 | 35.8 |24.9 | 8.6 | reconnect | 14 | 2 | |7 |74.9 |9 |68.9 | 4 |33.4 | 8.5 |56.6 | 20.1 | 18 | 4 | |8 |92.1 |17.2 |77.9 | 9 |42.2 | 8.8 |60.2 | 3.6 | 20 | 2 | |9 |395.2|303.1 |93.9 | 16 |50.8 | 8.6 |68.4 | 8.2 | 24 | 4 | |10|399.1|3.9 |433.9 | 340 |59.1 | 8.3 |84.8 | 16.4 | 26 | 2 | |11|407.1|8 |438.9 | 5 |127.3| 68.2|86.7 | 1.9 | 30.1 | 4.1| |12|423.4|16.3 |447.9 | 9 |128.9| 1.6 | reconnect | 32.1 | 2 | |13|455.4|32 |464.9 | 17 |131.1| 2.2 |106.7| 20 | 36.1 | 4 | |14|460.4|5 |794.9 | 330 |135.1| 4 |111.4| 4.7 | 38.1 | 2 | |15|467.4|7 |799.9 | 5 |143.4| 8.3 |120.6| 9.2 | 42.1 | 4 | |16|483.4|16 |808.9 | 9 |151.7| 8.3 |134.9| 14.3 | 44.1 | 2 | |17|842.9|359.5 |824.9 | 16 |160.4| 8.7 |136.8| 1.9 | 48.2 | 4.1| |18|846.9|4 |1141.9| 317 |168.8| 8.4 | reconnect | 50.2 | 2 | ------------------------------------------------------------------------ Terminals DHCPDISCOVER requests when Server's DHCP module is down figure 2. Terminals DHCPDISCOVER requests when Server's DHCP module is down For Windows7, it seems to initiate 8 times DHCPDISCOVER requests in about 300s interval. For WindowsXP, firstly it launches 9 times DHCPDISCOVER messages, but after that it cannot get any response from the server, then it initiates 5 times requests in one cycle in around 330s intervals, and never stop. For IOS5.0.1, it seems like WindowsXP. There are 10 times attempts in one cycle, and the interval is about 68s. Symbian_S60 uses the simplest backoff method, it launches DISCOVER in every 2 or 4 seconds. Android2.3.7 is the only Operating System which can stop DISCOVER request by disconnect its wireless connection. It reboot wireless and dhcp connection every 20 seconds. Obviously, DHCP server needs to weaken the traffic which is like DDoS attack caused by the clients when many DHCPv4 clients send discovery messages incessantly when the DHCPv4 server is configured no respond to discover messages or the IPv4 address pool is empty. Yang, et al. Expires January 13, 2013 [Page 5] Internet-Draft DHC-DIS July 2012 4. DIS_MAX_RT and DIS_MAX_RT_OPTION In our experiments described upwards, some of the most popular OS will send several discover messages every 1 or 5 minutes, and send the message endlessly. So the DHCP server needs a mechanism to weaken the traffic. It is necessary to define an uniform identification named DIS_MAX_RT for client to follow when it needs to retransmit DHCPDISCOVER. Client should retransmits the message in a period refer to the DIS_MAX_RT value. This parameter can be initiated by client and configurated by DHCP server. Client must support this new option, and should deploy some backoff algorithm to avoid launch DISCOVER more frequently. Server must also support this option, and could refill the parameter according to its state. According to the definition of DHCP option in RFC2132 [RFC2132], a new option named DIS_MAX_RT_OPTION is defined. The format of DIS_MAX_RT_OPTION is: +--------+--------+--------+--------+--------+--------+ |Code |Len | T1 | T2 | T3 | T4 | +--------+--------+--------+--------+--------+--------+ Code DIS_MAX_RT_OPTION (TBD). Len 4. T1-T4 4 octets, Overriding value for DIS_MAX_RT in seconds. DIS_MAX_RT_OPTION The DIS_MAX_RT_OPTION option needs IANA to assign a new Code to indicate and its length (Len value) is 4 octets. From T1 to T4, there are 4 octets space to indicate the max retransmition time period. MRT(T1-T4) identifies the interval time client sends two concatenated DISCOVER message. MRT must > 0; When MRT=FFFF, client should not send DISCOVER any more. A DHCPv4 client MUST include the DIS_MAX_RT_OPTION in any message it sends. The DHCPv4 server MAY include the DIS_MAX_RT_OPTION code in any response it sends to a client that has included the DIS_MAX_RT option code in a request message. The process of this option is described below: 1. Client must initial the time parameter by any random algorithm or any others, and set T1-T4 in DIS_MAX_RT_OPTION. IF client receives DIS_MAX_RT_OPTION from server, it should retransmit DISCOVER according the MRT in the option. As a result of receiving this Yang, et al. Expires January 13, 2013 [Page 6] Internet-Draft DHC-DIS July 2012 option, the DHCPv4 client MUST NOT send any request messages more frequently that allowed by the retransmission mechanism defined by their OS. Client should delpoy backoff algorithm to retransmit the message if it does not receive any message from server until the backoff time is triggered. 2. When server receives a request including a DIS_MAX_RT_OPTION, it MAY ignore the value of DIS_MAX_RT and assign a new value in the response to make the client refresh its DIS_MAX_RT. It can change MRT longer than the initialized time if the IPv4 address pool is empty or according to the administrator's configuration. Server can also change the value to FFFF if it does not want to support any more IPv4 address request or in a normal address allocation process in DHCPOFFER or any other messages. 5. Security Considerations The security problem is under disscussion. 6. IANA Considerations IANA is requested to assign an option code from the "DHCP Option Codes" Registry for OPTION_DIS_MAX_RT. 7. Refrences (1) RFC[2131] Dynamic Host Configuration Protocol (2) RFC[2132] DHCP Options and BOOTP Vendor Extensions (3) RFC[3315] Dynamic Host Configuration Protocol for IPv6(DHCPv6) (4) "draft-droms-dhc-dhcpv6-solmaxrt-update-02" Modification to Default Value of SOL_MAX_RT 8. Acknowledgement Thanks for the authors of "draft-droms-dhc-dhcpv6-solmaxrt-update-02" and the contributions from Lianyuan Li. Yang, et al. Expires January 13, 2013 [Page 7] Internet-Draft DHC-DIS July 2012 Authors' Addresses Tianle Yang China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 01719 China Email: yangtianle@chinamobile.com Li Lianyuan China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 01719 China Email: lilianyuan@chinamobile.com Qiongfang Ma China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 01719 China Email: maqiongfang@chinamobile.com Yang, et al. Expires January 13, 2013 [Page 8]