Internet Engineering Task Force T. Yang Internet-Draft L. Li Intended status: Standards Track Q. Ma Expires: April 15, 2013 China Mobile Oct 12, 2012 Weakening Aggregated Traffic of DHCP Discover Messages draft-yang-sunset4-weaken-dhcp-00 Abstract This document proposes two methods to mitigate aggregated traffic caused by discover messages the dual stack host 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 April 15, 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 April 15, 2013 [Page 1] Internet-Draft weaken-dhcp Oct 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 3. Potential Problems . . . . . . . . . . . . . . . . . . . . . . 3 4. DHCPv6 solution . . . . . . . . . . . . . . . . . . . . . . . . 6 5. RA solution . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 8. Refrences . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Yang, et al. Expires April 15, 2013 [Page 2] Internet-Draft weaken-dhcp Oct 2012 1. Introduction In RFC3315 [RFC3315, DHCPv6], SOL_MAX_RT is defined in DHCPv6 to prevent the frequently requesting of clients, which reduce the aggregated traffic. But in RFC2131 [RFC2131, DHCPv4], there are not corresponding IPv4 definitions or options for client's behavior 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 DHCP server, especially in the "Dual-Stack host/network + IPv6-Only DHCP server" scenario: As everyone knows, our network is changing from IPv4-Only to Dual- Stack, and even IPv6-Only in the near future. We may turn off some IPv4 services gradually, such as DHCP. If a Dual-Stack host initials DHCP Discover messages through the link to a DHCPv6-Only server, it cannot get any response. Then the host will re-broadcast the messages endlessly, that may cause the aggregated traffic. In this document, we propsed two methods to solve this problem, creating a new option in DHCPv6 or in RS/RA, described as below. 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 Dual-Stack 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 dual-stack or IPv4-only clients 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 network. This situation may occur when the networks or serveices gradually updated to IPv6-Only. Yang, et al. Expires April 15, 2013 [Page 3] Internet-Draft weaken-dhcp Oct 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 April 15, 2013 [Page 4] Internet-Draft weaken-dhcp Oct 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 | ------------------------------------------------------------------------ Figure2:Terminals DHCPDISCOVER requests when Server's DHCP module is down In figure 2: 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 Yang, et al. Expires April 15, 2013 [Page 5] Internet-Draft weaken-dhcp Oct 2012 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. 4. DHCPv6 solution According to the definition of DHCPv6 option in RFC3315 [RFC3315], a new option named OPTION_Dis_Max_RT is defined to affect the retransmission of DHCPv4 DISCOVER message of the host. The format of OPTION_Dis_Max_RT is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dis_Max_RT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_Sol/Dis_Max_RT (TBD). option-len 4. Dis_Max_RT DHCPv4 Discover retransmission time in seconds. OPTION_Dis_Max_RT The OPTION_Dis_Max_RT option needs IANA to assign a new Code to indicate. Its length (Len value) is 4 octets. Dis_Max_RT is the value of DHCPv4 Discover message retransmission time in the unit of second. If Dis_Max_RT=0, server will respond Offer or other DHCP messages in normal; If Dis_Max_RT>0, server won't respond to Discover immediately, cliet should wait for resending Discover message later; If Dis_Max_RT=FFFF, cliet should not send Discover message any more. A DHCPv6 client MUST include the OPTION_Dis_Max_RT code in Option Request Option [RFC3115, section 22.7]. The DHCPv6 server MAY Yang, et al. Expires April 15, 2013 [Page 6] Internet-Draft weaken-dhcp Oct 2012 include the OPTION_Dis_Max_RT in any response it sends to a client. The process of this option is described below: 1. Client must initial the request code in the Option Request Option in the Discover messages. 2. When server receives a request, it MUST assign an appropriate value in the response to the client. It can set FFFF in the Dis_Max_RT field when the dhcp module is turned off or according to the administrator's configuration. 5. RA solution Neighbor Discovery for IPv6 defined in RFC4861[RFC4861] is a basic protocol of IPv6. It is used more widely than DHCPv6. When the value of M in Router Advertisment(RA) message is set, DHCPv6 can only be set to active. If M and O are not set, RA will be used to deliver the IPv6 prefix instead of DHCPv6. A new option is defined in Router Advertisment(RA) messages to be used to avoid frequent retransmission. According to the definition of RA option in RFC4861 [RFC4861], a new option named Option_Dis_Max_RT is defined to affect the retransmission of DHCPv4 DISCOVER message. The format of OPTION_Dis_Max_RT is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dis_Max_RT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type OPTION_Sol/Dis_Max_RT (TBD). Length 8. Reserved Reserved. Dis_Max_RT DHCPv4 Discover retransmission time in seconds. OPTION_Dis_Max_RT The OPTION_Dis_Max_RT option needs IANA to assign a new Code to Yang, et al. Expires April 15, 2013 [Page 7] Internet-Draft weaken-dhcp Oct 2012 indicate and its length (Len value) is 8 octets. Dis_Max_RT is the value of DHCPv4 Discover message retransmission time in the unit of second. If Dis_Max_RT=0, server will respond Offer or other DHCP messages in normal; If Dis_Max_RT>0, server won't respond to Discover immediately, cliet should wait for resending Discover message later; If Dis_Max_RT=FFFF, cliet should not send Discover message any more. The process is a little simpler than DHCPv6: 1. Server send RA with this option to cliet to tell it the intervals to resend Discover messages. 6. Security Considerations The security problem is under disscussion. 7. IANA Considerations IANA is requested to assign an option code from the "DHCP Option Codes" Registry for OPTION_DIS_MAX_RT. 8. Refrences (1) RFC[2131] Dynamic Host Configuration Protocol (2) RFC[3315] Dynamic Host Configuration Protocol for IPv6(DHCPv6) (3) RFC[4861] Neighbor Discovery for IP version 6 Authors' Addresses Tianle Yang China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 100053 China Email: yangtianle@chinamobile.com Yang, et al. Expires April 15, 2013 [Page 8] Internet-Draft weaken-dhcp Oct 2012 Li Lianyuan China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 100053 China Email: lilianyuan@chinamobile.com Qiongfang Ma China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 100053 China Email: maqiongfang@chinamobile.com Yang, et al. Expires April 15, 2013 [Page 9]