idnits 2.17.1 draft-yang-dhc-ipv4-dis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2012) is 4306 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2131' on line 87 looks like a reference -- Missing reference section? 'RFC3315' on line 68 looks like a reference -- Missing reference section? 'RFC2119' on line 84 looks like a reference -- Missing reference section? 'RFC2132' on line 192 looks like a reference -- Missing reference section? '2131' on line 245 looks like a reference -- Missing reference section? '2132' on line 247 looks like a reference -- Missing reference section? '3315' on line 249 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Yang 3 Internet-Draft L. Li 4 Intended status: Standards Track Q. Ma 5 Expires: January 13, 2013 China Mobile 6 July 12, 2012 8 Mitigating aggregated traffic of DHCP discover messages 9 draft-yang-dhc-ipv4-dis-01 11 Abstract 13 This document defines a new option DIS_MAX_RT which can mitigate 14 aggregated traffic caused by discover messages the clients send to 15 the server. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 13, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 53 3. Potential Problems . . . . . . . . . . . . . . . . . . . . . . 3 54 4. DIS_MAX_RT and DIS_MAX_RT_OPTION . . . . . . . . . . . . . . . 6 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 57 7. Refrences . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 61 1. Introduction 63 In RFC2131 [RFC2131], there are no specific definitions for client's 64 operation if the server does not respond for the discover messages. 65 In some cases, this will lead to an unacceptably high volum of 66 aggregated traffic at a DHCPv4 server. 68 In RFC3315 [RFC3315], SOL_MAX_RT is defined as an option of DHCPv6 69 message to prevent the frequently requesting of clients, which reduce 70 the aggregated traffic. In DHCPv4, there are no corresponding IPv4 71 options. Although the format of DHCPv4 is different with DHCPv6, it 72 is also necessary to introduce similar option in DHCPv4 to keep the 73 consistency between DHCPv4 and DHCPv6. 75 This document updates RFC 2131 [RFC2131] by defining a new option 76 DIS_MAX_RT which makes the DHCPv4 server mitigating aggregated 77 traffic of client's discover messages. 79 2. Requirements Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 3. Potential Problems 87 RFC2131 [RFC2131] defines the interaction between the DHCP server and 88 clients. There are no specific discription for client's operation 89 when the client does not receive the DHCPOFFER in response to its 90 DHCPDISCOVER message. In normal IPv4 environment, clients will flood 91 DHCPDISCOVER messages only when the server or link is broken. But in 92 Dual-Stack scenarios, the problem becomes more frequent and serious. 93 In IPv6 LAN/WLAN network or intranet, the core router or AC often 94 plays the role of DHCP server, and the clients are serval thousands 95 PC or mobile phones. If the server is configured in IPv6-only, the 96 clients in dual-stack or IPv4-only, they will broadcast DHCPDISCOVER 97 messages endlessly in the LAN or WLAN. The thousands clients will 98 cause a DDOS-like attack to all the servers in the intranet. 100 ________ 101 | |DISCOVER1 102 | PC |----------------- 103 |________|DISCOVER2 | __________ 104 ...... |----->| | 105 | DHCP | 106 ________ |----->| server | 107 | |DISCOVER1 | |-->|__________| 108 | MS |----------------- | 109 |________|DISCOVER2 | 110 ...... | 111 ...... | 112 ________ | 113 | | | 114 | |-------------------- 115 |________| 117 Figure 1: DHCPDISCOVER flood in LAN/WLAN 119 To avoid this problem, most of the terminals creat backoff algorithms 120 which can help them retransmit DHCPDISCOVER message in different 121 frequency according to their state machine in different Operating 122 Systems, because there is no specific defenition in RFCs to restrict 123 the terminals behaviors when the server is down or in a dual-stack 124 scenario as discripted upwards. But the same point of almost all the 125 verious Operating Systems is that they could not stop DHCPDISCOVER 126 requests enven to an IPv6-only server. We test some of the most 127 popular terminals' OS in WLAN, the results are illuminated as below. 129 ------------------------------------------------------------------------ 130 | DHCP Discovery Packages Time Table | 131 |----------------------------------------------------------------------| 132 | | Windows7 |Windows XP | IOS_5.0.1 |Android_2.3.7|Symbian_S60 | 133 |No|Time | Time | Time | Time |Time | Time |Time | Time | Time | Time| 134 | | |offset| |offset| |offset| |offset | |offse| 135 |--|-----|------|------|------|-----|------|-----|-------|-------|-----| 136 |1 |0 | |0 | |0.1 | |7.8 | | 0 | | 137 |2 |3.9 |3.9 |0.1 | 0.1 |1.4 | 1.3 |10.3 | 2.5 | 2 | 2 | 138 |3 |13.3 |9.4 |4.1 | 4 |3.8 | 2.4 |17.9 | 7.6 | 6 | 4 | 139 |4 |30.5 |17.2 |12.1 | 8 |7.9 | 4.1 |33.9 | 16 | 8 | 2 | 140 |5 |62.8 |32.3 |29.1 | 17 |16.3 | 8.4 |36.5 | 2.6 | 12 | 4 | 141 |6 |65.9 |3.1 |64.9 | 35.8 |24.9 | 8.6 | reconnect | 14 | 2 | 142 |7 |74.9 |9 |68.9 | 4 |33.4 | 8.5 |56.6 | 20.1 | 18 | 4 | 143 |8 |92.1 |17.2 |77.9 | 9 |42.2 | 8.8 |60.2 | 3.6 | 20 | 2 | 144 |9 |395.2|303.1 |93.9 | 16 |50.8 | 8.6 |68.4 | 8.2 | 24 | 4 | 145 |10|399.1|3.9 |433.9 | 340 |59.1 | 8.3 |84.8 | 16.4 | 26 | 2 | 146 |11|407.1|8 |438.9 | 5 |127.3| 68.2|86.7 | 1.9 | 30.1 | 4.1| 147 |12|423.4|16.3 |447.9 | 9 |128.9| 1.6 | reconnect | 32.1 | 2 | 148 |13|455.4|32 |464.9 | 17 |131.1| 2.2 |106.7| 20 | 36.1 | 4 | 149 |14|460.4|5 |794.9 | 330 |135.1| 4 |111.4| 4.7 | 38.1 | 2 | 150 |15|467.4|7 |799.9 | 5 |143.4| 8.3 |120.6| 9.2 | 42.1 | 4 | 151 |16|483.4|16 |808.9 | 9 |151.7| 8.3 |134.9| 14.3 | 44.1 | 2 | 152 |17|842.9|359.5 |824.9 | 16 |160.4| 8.7 |136.8| 1.9 | 48.2 | 4.1| 153 |18|846.9|4 |1141.9| 317 |168.8| 8.4 | reconnect | 50.2 | 2 | 154 ------------------------------------------------------------------------ 156 Terminals DHCPDISCOVER requests when 157 Server's DHCP module is down 159 figure 2. Terminals DHCPDISCOVER requests when Server's DHCP module 160 is down For Windows7, it seems to initiate 8 times DHCPDISCOVER 161 requests in about 300s interval. For WindowsXP, firstly it launches 162 9 times DHCPDISCOVER messages, but after that it cannot get any 163 response from the server, then it initiates 5 times requests in one 164 cycle in around 330s intervals, and never stop. For IOS5.0.1, it 165 seems like WindowsXP. There are 10 times attempts in one cycle, and 166 the interval is about 68s. Symbian_S60 uses the simplest backoff 167 method, it launches DISCOVER in every 2 or 4 seconds. Android2.3.7 168 is the only Operating System which can stop DISCOVER request by 169 disconnect its wireless connection. It reboot wireless and dhcp 170 connection every 20 seconds. Obviously, DHCP server needs to weaken 171 the traffic which is like DDoS attack caused by the clients when many 172 DHCPv4 clients send discovery messages incessantly when the DHCPv4 173 server is configured no respond to discover messages or the IPv4 174 address pool is empty. 176 4. DIS_MAX_RT and DIS_MAX_RT_OPTION 178 In our experiments described upwards, some of the most popular OS 179 will send several discover messages every 1 or 5 minutes, and send 180 the message endlessly. So the DHCP server needs a mechanism to 181 weaken the traffic. 183 It is necessary to define an uniform identification named DIS_MAX_RT 184 for client to follow when it needs to retransmit DHCPDISCOVER. 185 Client should retransmits the message in a period refer to the 186 DIS_MAX_RT value. This parameter can be initiated by client and 187 configurated by DHCP server. Client must support this new option, 188 and should deploy some backoff algorithm to avoid launch DISCOVER 189 more frequently. Server must also support this option, and could 190 refill the parameter according to its state. 192 According to the definition of DHCP option in RFC2132 [RFC2132], a 193 new option named DIS_MAX_RT_OPTION is defined. The format of 194 DIS_MAX_RT_OPTION is: 196 +--------+--------+--------+--------+--------+--------+ 197 |Code |Len | T1 | T2 | T3 | T4 | 198 +--------+--------+--------+--------+--------+--------+ 200 Code DIS_MAX_RT_OPTION (TBD). 201 Len 4. 202 T1-T4 4 octets, Overriding value for 203 DIS_MAX_RT in seconds. 205 DIS_MAX_RT_OPTION 207 The DIS_MAX_RT_OPTION option needs IANA to assign a new Code to 208 indicate and its length (Len value) is 4 octets. From T1 to T4, 209 there are 4 octets space to indicate the max retransmition time 210 period. MRT(T1-T4) identifies the interval time client sends two 211 concatenated DISCOVER message. MRT must > 0; When MRT=FFFF, client 212 should not send DISCOVER any more. A DHCPv4 client MUST include the 213 DIS_MAX_RT_OPTION in any message it sends. The DHCPv4 server MAY 214 include the DIS_MAX_RT_OPTION code in any response it sends to a 215 client that has included the DIS_MAX_RT option code in a request 216 message. The process of this option is described below: 1. Client 217 must initial the time parameter by any random algorithm or any 218 others, and set T1-T4 in DIS_MAX_RT_OPTION. IF client receives 219 DIS_MAX_RT_OPTION from server, it should retransmit DISCOVER 220 according the MRT in the option. As a result of receiving this 221 option, the DHCPv4 client MUST NOT send any request messages more 222 frequently that allowed by the retransmission mechanism defined by 223 their OS. Client should delpoy backoff algorithm to retransmit the 224 message if it does not receive any message from server until the 225 backoff time is triggered. 2. When server receives a request 226 including a DIS_MAX_RT_OPTION, it MAY ignore the value of DIS_MAX_RT 227 and assign a new value in the response to make the client refresh its 228 DIS_MAX_RT. It can change MRT longer than the initialized time if 229 the IPv4 address pool is empty or according to the administrator's 230 configuration. Server can also change the value to FFFF if it does 231 not want to support any more IPv4 address request or in a normal 232 address allocation process in DHCPOFFER or any other messages. 234 5. Security Considerations 236 The security problem is under disscussion. 238 6. IANA Considerations 240 IANA is requested to assign an option code from the "DHCP Option 241 Codes" Registry for OPTION_DIS_MAX_RT. 243 7. Refrences 245 (1) RFC[2131] Dynamic Host Configuration Protocol 247 (2) RFC[2132] DHCP Options and BOOTP Vendor Extensions 249 (3) RFC[3315] Dynamic Host Configuration Protocol for IPv6(DHCPv6) 251 (4) "draft-droms-dhc-dhcpv6-solmaxrt-update-02" Modification to 252 Default Value of SOL_MAX_RT 254 8. Acknowledgement 256 Thanks for the authors of "draft-droms-dhc-dhcpv6-solmaxrt-update-02" 257 and the contributions from Lianyuan Li. 259 Authors' Addresses 261 Tianle Yang 262 China Mobile 263 32, Xuanwumenxi Ave. 264 Xicheng District, Beijing 01719 265 China 267 Email: yangtianle@chinamobile.com 269 Li Lianyuan 270 China Mobile 271 32, Xuanwumenxi Ave. 272 Xicheng District, Beijing 01719 273 China 275 Email: lilianyuan@chinamobile.com 277 Qiongfang Ma 278 China Mobile 279 32, Xuanwumenxi Ave. 280 Xicheng District, Beijing 01719 281 China 283 Email: maqiongfang@chinamobile.com