Internet DRAFT - draft-yang-sunset4-weaken-dhcp

draft-yang-sunset4-weaken-dhcp






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]