Skip to main content

A SAVI solution for WLAN
draft-bi-savi-wlan-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Jun Bi , Jianping Wu , You Wang , Tao Lin
Last updated 2013-02-05
Replaced by draft-bi-intarea-savi-wlan
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-bi-savi-wlan-03
Network Working Group                                            J. Bi 
Internet Draft                                                   J. Wu 
Intended status: Standard Tracks                               Y. Wang 
Expires: August, 2013                              Tsinghua University 
                                                                T. Lin 
                                          Hangzhou H3C Tech. Co., Ltd. 
                                                      February 6, 2013 
                                   
 
                         A SAVI solution for WLAN 

                         draft-bi-savi-wlan-03.txt 

Abstract 

   This document describes a source address validation solution for WLAN 
   enabling 802.11i or other security mechanisms. This mechanism snoops 
   NDP and DHCP to bind IP address with MAC address, and relies on the 
   security of MAC address guaranteed by 802.11i or other mechanisms to 
   filter IP spoofing packets. It can work in the special situations 
   described in the charter of SAVI workgroup, such as multiple MAC 
   addresses on one interface. This document describes three different 
   deployment scenarios, with solutions for migration of binding entries 
   when hosts move from one access point to another. 

Status of this Memo 

   This Internet-Draft is submitted 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 October 5, 2012. 

Copyright Notice 

   Copyright (c) 2011 IETF Trust and the persons identified as the 
   document authors.  All rights reserved. 

 
 
 
Bi, et al.             Expires August 6, 2013                 [Page 1] 
 

Internet-Draft                SAVI wlan                  February 2013 
    

   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. 

   This document may contain material from IETF Documents or IETF 
   Contributions published or made publicly available before November 10
   , 2008.  The person(s) controlling the copyright in some of this 
   material may not have granted the IETF Trust the right to allow 
   modifications of such material outside the IETF Standards Process. 
   Without obtaining an adequate license from the person(s) controlling 
   the copyright in such materials, this document may not be modified 
   outside the IETF Standards Process, and derivative works of it may 
   not be created outside the IETF Standards Process, except to format 
   it for publication as an RFC or to translate it into languages other 
   than English. 

Table of Contents 

    
   1. Introduction ................................................ 3 
   2. Conventions used in this document............................ 3 
   3. IP-MAC Binding .............................................. 3 
      3.1. Data Structures......................................... 4 
         3.1.1. IP-MAC Mapping Table............................... 4 
         3.1.2. MAC-IP Mapping Table............................... 4 
      3.2. Pre-conditions for binding.............................. 4 
      3.3. Binding IP addresses to MAC addresses................... 5 
      3.4. Binding Migration....................................... 5 
      3.5. Binding Clearing........................................ 6 
   4. Source Address Validation.................................... 6 
   5. Deployment Scenarios......................................... 6 
      5.1. Centralized WLAN........................................ 7 
         5.1.1. AP Filtering....................................... 7 
            5.1.1.1. Candidate Binding............................. 7 
            5.1.1.2. CAPWAP Extension.............................. 8 
            5.1.1.3. Mobility Solution............................. 9 
         5.1.2. AC Filtering...................................... 10 
      5.2. Autonomous WLAN........................................ 10 
   6. Security Considerations..................................... 11 
   7. IANA Considerations ........................................ 11 
 
 
Bi, et al.             Expires August 6, 2013                 [Page 2] 
    

Internet-Draft                SAVI wlan                  February 2013 
    

   8. Conclusions ................................................ 11 
   9. Contributors ............................................... 11 
   10. Acknowledgments ........................................... 11 
   11. References ................................................ 11 
      11.1. Normative References.................................. 11 
      11.2. Informative References................................ 13 
    
1. Introduction 

   This document describes a mechanism to perform per packet IP source 
   address validation in WLAN. This mechanism performs ND snooping or 
   DHCP snooping to bind allocated IP address with authenticated MAC 
   address. Static addresses are bound to the MAC addresses of 
   corresponding hosts manually. Then the mechanism can check validity 
   of source IP address in local packets according to the binding 
   association. The security of MAC address is assured by 802.11i or 
   other mechanisms, thus the binding association is secure.  

   The situation that one interfaces with multiple MAC addresses is a 
   special case mentioned in the charter of SAVI. And this situation is 
   the only special case that challenges MAC-IP binding. The mechanism 
   to handle this situation is specified in the document. 

   There are three deployment scenarios specified in this document. The 
   mechanism is deployed on different devices in different scenarios. 
   The deployment detail is described in the document. 

   When hosts move from one access point to another, the migration of 
   binding entries may be triggered according to the specific mobility 
   scenario. The mechanism to handle host mobility is specified in the 
   document according to different deployment scenarios.  

2. Conventions used in this document 

   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 RFC-2119 [RFC2119].  

3. IP-MAC Binding 

   This section specifies the operations for creating and clearing of 
   bindings between IP addresses to MAC addresses.  

 
 
Bi, et al.             Expires August 6, 2013                 [Page 3] 
    

Internet-Draft                SAVI wlan                  February 2013 
    

3.1. Data Structures 

3.1.1. IP-MAC Mapping Table 

   This table maps IP addresses to corresponding MAC addresses. IP 
   address is the index of the table. One IP address can only have one 
   corresponding MAC address, while different IP addresses can be mapped 
   to the same MAC address.  

   This table is used in control process. Before creating new IP-MAC 
   bindings, this table must first be consulted in case of conflict in 
   binding entries. This table must be synchronized with the MAC-IP 
   table specified in Section 3.1.2. 

   Each entry in IP-MAC mapping table must also record the binding state 
   of the IP address. Addresses snooped in DHCP address assignment 
   procedure must record its state as "DHCPv6", and addresses snooped in 
   Duplicate Address Detection procedure must record its state as 
   "SLAAC". 

   Each entry in IP-MAC mapping table has its lifetime. The address 
   allocated by DHCP has a limited lifetime, so the related entry 
   records its lifetime the same as that of the address. According to 
   [RFC4862], stateless address also has a limited lifetime, and the 
   host set this lifetime by itself. Thus the related entry also records 
   its lifetime the same as that of the address. 

3.1.2. MAC-IP Mapping Table 

   This table maps MAC addresses to corresponding IP addresses. MAC 
   address is the index of the table. It is a one-to-many mapping table, 
   which means a MAC address can be mapped to multiple IP addresses. 
   Though multiple MAC addresses may exist on one interface, these MAC 
   addresses must be mapped to different IP addresses. 

   This table is used for filtering. Different from wired network, MAC-
   IP mapping table and IP-MAC mapping table can be maintained 
   separately on different devices. Mechanisms for synchronization 
   between the two tables must be employed for the consistency of the 
   bindings. We will specify the details in Section 5 according to 
   different deployment scenarios. 

3.2. Pre-conditions for binding 

   In the binding based mechanism, the security of IP address is based 
   on the security of the binding anchor. In WLAN, a number of security 

 
 
Bi, et al.             Expires August 6, 2013                 [Page 4] 
    

Internet-Draft                SAVI wlan                  February 2013 
    

   mechanisms on link layer make MAC address a strong enough binding 
   anchor, for instance, 802.11i, WAPI, WEP.  

   If MAC address has no protection, attackers can spoof MAC address to 
   succeed in validation. However, in general cases, if MAC address is 
   not protected, more serious attack can be launched than IP spoofing 
   attack.  

3.3. Binding IP addresses to MAC addresses 

   All the static IP-MAC address pairs are configured into the IP-MAC 
   Mapping Table with the mechanism enabled.  

   An individual procedure handles binding DHCP addresses to MAC 
   addresses. This procedure snoops the DHCP address assignment 
   procedure between attached hosts and DHCP server. DHCP snooping in 
   WLAN is the same as that in wired network. 

   An individual procedure handles binding stateless addresses to MAC 
   addresses. This procedure snoops Duplicate Address Detection 
   procedure. ND snooping in WLAN is the same as that in wired network. 

   Data packets can also trigger the establishment of new IP-MAC binding 
   entries. Data packet with non-bound source IP address with a limited 
   rate is collected to handle DAD message loss in SLAAC procedure, 
   which can be quite frequent in wireless network. We will specify the 
   details in Section 4.  

   In some deployment scenarios, the function of address snooping and 
   IP-MAC table maintaining may also be separated onto different devices. 
   Thus to prevent conflictions in binding entries, the device snoops 
   addresses must have interactions with the device maintains the IP-MAC 
   table. We will specify the details in Section 5.1.1.  

3.4. Binding Migration 

   Different from wired network, SAVI for WLAN must handle migration of 
   binding entries when mobile hosts move from one access point to 
   another. After movement, hosts will not perform another address 
   allocation procedure to obtain new IP addresses, but continue to use 
   the existing IP address. Thus binding entries in the foreign device 
   that the mobile hosts access to cannot be established by snooping. A 
   new mechanism is needed to correctly migrate the binding entry 
   related to the IP address of the mobile host from the home device to 
   the foreign device. We will specify the details in Section 5, 
   according to deferent deployment scenarios. 

 
 
Bi, et al.             Expires August 6, 2013                 [Page 5] 
    

Internet-Draft                SAVI wlan                  February 2013 
    

3.5. Binding Clearing 

   Three kinds of events will trigger binding clearing:  

   1. The lifetime of an IP address in one entry has expired. This IP 
   entry MUST be cleared.  

   2. A host leaves this access point. The entries for all the related 
   MAC addresses MUST be cleared.  

   3. A DHCP RELEASE message is received from the owner of corresponding 
   IP address. This IP entry MUST be cleared. 

4. Source Address Validation 

   This section describes source address validation procedure on packet. 
   In this procedure, all the frames are assumed to have passed the 
   verifications of 802.11i or other security mechanisms.   

   This procedure has the following steps:  

   1. Extract the IP source and MAC source from the frame. Lookup the 
   MAC address in the MAC-IP Mapping Table and check if the MAC-IP pair 
   exists. If yes, forward the packet. Or else go to next step.  

   2. Lookup the IP address in the IP-MAC Mapping Table and check if the 
   IP address exists. If no, insert a new entry into the IP-MAC Mapping 
   Table and forward the packet. If yes, check whether The MAC address 
   in the entry is the same as that in the frame. If yes, forward the 
   packet. Else drop the packet.  

   In step 2, after the packet is judged valid and forwarded, 
   synchronization between the MAC-IP and IP-MAC mapping table should be 
   triggered. The MAC-IP binding of the packet should be synchronized 
   from IP-MAC mapping table to MAC-IP mapping table and thus the 
   following packets with the same MAC-IP pair will be forwarded without 
   going to step 2. 

5. Deployment Scenarios 

   This section specifies three deployment scenarios including two under 
   centralized WLAN and one under autonomous WLAN. The deployment 
   details and solutions for host mobility between access points are 
   described respectively in each scenario. 

 
 
Bi, et al.             Expires August 6, 2013                 [Page 6] 
    

Internet-Draft                SAVI wlan                  February 2013 
    

5.1. Centralized WLAN 

   Centralized WLAN is comprised of FIT Access Points (AP) and Access 
   Controllers (AC). In this scenario, this document proposes the 
   following two deployment solutions. 

5.1.1. AP Filtering 

   In this scenario, AC maintains IP-MAC Mapping Table while AP 
   maintains MAC-IP Mapping Table and perform address snooping. 

5.1.1.1. Candidate Binding 

   AP executes the procedure specified in Section 3.3. Candidate binding 
   is generated after snooping procedure. Candidate binding must be 
   confirmed by AC to be valid. 

   After a candidate binding is generated, AC is notified and checks 
   whether the binding is valid or not. The validity of a candidate 
   binding is determined if the binding does not violate any existing 
   bindings in the IP-MAC Mapping Table. Otherwise if an address is not 
   suitable for a host to use, AC notifies the corresponding AP. If the 
   candidate binding is valid, AC adds an entry into the IP-MAC Mapping 
   Table and notifies AP. Afterwards AP also adds an entry into the 
   local MAC-IP Mapping Table. 

5.1.1.2. Packet Filtering 

   As specified in Section 4, for incoming data packets, AP looks up the 
   MAC address in the local MAC-IP Mapping Table and check if the MAC-IP 
   pair exists. If yes, AP forwards the packet. Or else AP delivers the 
   packet to AC for further processing.  

   When receiving data packets from AP, AC Looks up the IP address in 
   the local IP-MAC Mapping Table and checks if the IP address exists. 
   If no, AC inserts a new entry into the local IP-MAC Mapping Table and 
   forwards the packet. If yes, AC checks whether The MAC address in the 
   entry is the same as that in the frame. If yes, AC forwards the 
   packet. Else AC drops the packet. 

   After AC forwards a valid packet, it synchronizes related MAC-IP 
   binding to the MAC-IP mapping table on the AP from which the packet 
   comes. Following packets with the same MAC-IP pair will be forwarded 
   directly by AP without going to AC. 

 
 
Bi, et al.             Expires August 6, 2013                 [Page 7] 
    

Internet-Draft                SAVI wlan                  February 2013 
    

5.1.1.3. CAPWAP Extension 

   CAPWAP protocol is used for communication between AP and AC. A new 
   CAPWAP protocol message element is introduced, which extends the 
   [CAPWAP]. The host IP message element is used by both AP and AC to 
   exchange the binding information of hosts. 

   The host IP message element can be used in the process of 
   confirmation of candidate binding. When AP generates a candidate 
   binding, it reports the MAC address and related IP addresses to AC 
   using this message, with suggestions of the state and lifetime of 
   each IP address as specified in Section 3.1.1. After AC checks the 
   validation of the candidate binding, it replies using a message of 
   the same format to inform AP the validation of each IP address with 
   suggestions of its state and lifetime. 

   The host IP message element also can be used in the process of 
   binding migration. In mobility scenario, foreign device the mobile 
   hosts accesses to need to request related bindings from home devices, 
   and host IP message element can be used for interactions between  
   them. Details will be specified in the following sections according 
   to different deployment scenarios. 

        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 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |    Radio ID   |                 Total Length                  + 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |   Sender ID   |     Length    |         Description           + 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |    MAC flag   |     Length    |        MAC Address...         + 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                     MAC Address...                            + 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |    IPv4 flag  |     Length    |        IPv4 Address...        + 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                    IPv4 Address...                            + 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |    IPv6 flag  |     Length    |        IPv6 Address...        + 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                    IPv6 Address...                            + 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    

 
 
Bi, et al.             Expires August 6, 2013                 [Page 8] 
    

Internet-Draft                SAVI wlan                  February 2013 
    

   Radio ID: An 8-bit value representing the radio, whose value is 
   between 1 and 31. 

   Total Length: Total length of the following fields.  

   Sender ID: An 8-bit value representing the sender of the message. AP 
   is represented by value 1 and AC is represented by value 2. 

   Length: The length of the Value field. 

   Description: A 16-bit value for descriptions of the sender (AP or AC). 

   MAC flag: An 8-bit value representing that the sub-field's type is 
   MAC address, whose value is 1.  

   Length: The length of the MAC Address field. The formats and lengths 
   specified in [EUI-48] and [EUI-64] are supported.  

   MAC Address: A MAC address of the host.  

   IPv4 flag: An 8-bit value representing that the sub-field's type is 
   IPv4 address, whose value is 2.  

   Length: The length of the IPv4 Address field.  

   IPv4 Address: An IPv4 address of the host. There may exist many 
   entries, and each entry is comprised of an IPv4 address, an 8-bit 
   value for address state (only value 1 is used for now), and a 32-bit 
   value for lifetime.  

   IPv6 flag: An 8-bit value representing that the sub-field's type is 
   IPv6 address, whose value is 3. 

   Length: The length of the IPv6 Address field.  

   IPv6 Address: An IPv6 address of the host. There may exist many 
   entries, and each entry is comprised of an IPv6 address, an 8-bit 
   value of address state (also one value for now), and a 32-bit value 
   lifetime. 

5.1.1.4. Mobility Solution 

   When a host moves from one AP to another, layer-2 association happens 
   before IP packet transfer. Home AP deletes the binding when mobile 
   host is disconnected, and foreign AP immediately requests the bound 
   addresses with the associated MAC from AC using host IP message 
   element specified in Section 5.1.1.2. AC returns the binding with 
 
 
Bi, et al.             Expires August 6, 2013                 [Page 9] 
    

Internet-Draft                SAVI wlan                  February 2013 
    

   suggestions of its state and lifetime also using the new CAPWAP 
   protocol message. After AP get the addresses should be bound, the 
   binding migration is completed.  

   In WLAN, a host can move from an AC to another AC while keeping using 
   the same IP address. To be compatible with such scenario, ACs must 
   communicate to perform the binding migration. CAPWAP extensions 
   specified in Section 5.1.1.2 can also be used for communications 
   between AC. 

5.1.2. AC Filtering 

   In this scenario, AC maintains both MAC-IP and IP-MAC Mapping Table 
   and performs both address snooping and packet filtering. So all the 
   packets must be forwarded to AC firstly.  

   AC executes the procedure specified in Section 3.3 and check the 
   validity of IP-MAC pairs by consulting the local IP-MAC mapping table. 
   No extra procedure is needed to establish the IP-MAC bindings.  

   AC executes the procedure specified in Section 4 for packet filtering 
   and no extra procedure is involved. 

   Mobility within one AC does not trigger any binding migration. 
   Mobility between different ACs triggers binding migration. ACs must 
   communicate to perform the binding migration. CAPWAP extensions 
   specified in Section 5.1.1.2 can be used for communications between 
   AC. 

5.2. Autonomous WLAN 

   Autonomous WLAN is comprised of FAT Access Points. In this scenario, 
   FAT AP maintains both MAC-IP and IP-MAC Mapping Table and performs 
   both address snooping and packet filtering.  

   FAT AP executes the procedure specified in Section 3.3 and check the 
   validity of IP-MAC pairs by consulting the local IP-MAC mapping table. 
   No extra procedure is needed to establish the IP-MAC bindings.  

   FAT AP executes the procedure specified in Section 4 for packet 
   filtering and no extra procedure is involved. 

   Mobility between different FAT APs will trigger binding migration. 
   FAT APs must communicate to perform the binding migration. CAPWAP 
   extensions specified in Section 5.1.1.2 can be used for 
   communications between FAT AP. 

 
 
Bi, et al.             Expires August 6, 2013                [Page 10] 
    

Internet-Draft                SAVI wlan                  February 2013 
    

6. Security Considerations 

   The security of address allocation methods matters the security of 
   this mechanism. Thus it is necessary to improve the security of 
   stateless auto-configuration and DHCP firstly.  

7. IANA Considerations 

   There is no IANA Consideration currently.  

8. Conclusions 

   This solution can satisfy the requirements of SAVI charter in WLAN 
   enabling 802.11i or other security mechanisms. 

9. Contributors 

   Guang Yao 
   Tsinghua University 
   Network Research Center, Tsinghua University 
   Beijing  100084 
   China 
   EMail: yaog@netarchlab.tsinghua.edu.cn 
    
   Yang Shi 
   Hangzhou H3C Tech. Co., Ltd. 
   Beijing 100085 
   China 
   EMail: rishyang@gmail.com  
    
   Hao Wang 
   Hangzhou H3C Tech. Co., Ltd. 
   Beijing 100085 
   China 
   EMail: hwang@h3c.com 
 

10. Acknowledgments 

   This document was prepared using 2-Word-v2.0.template.dot.  

11. References 

11.1. Normative References 

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
         Levels", BCP 14, RFC 2119, March 1997. 
 
 
Bi, et al.             Expires August 6, 2013                [Page 11] 
    

Internet-Draft                SAVI wlan                  February 2013 
    

   [2]  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
         Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
         Demon Internet Ltd., November 1997.  

   [3]  IEEE 802.11i-2004: Amendment 6: Medium Access Control (MAC) 
         Security Enhancements  

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate 
   Requirement Levels", BCP 14, RFC 2119, March 1997.  

   [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless 
   Autoconfiguration", RFC4862, September, 2007.  

   [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, and 
   M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 
   RFC3315, July, 2003.  

   [RFC5415] Control And Provisioning of Wireless Access Points (CAPWAP) 
   Protocol Specification 

 
 
Bi, et al.             Expires August 6, 2013                [Page 12] 
    

Internet-Draft                SAVI wlan                  February 2013 
    

11.2. Informative References 

Authors' Addresses 

   Jun Bi 
   Tsinghua University 
   Network Research Center, Tsinghua University 
   Beijing  100084 
   China 
   EMail: junbi@cernet.edu.cn 
    
   Jianping Wu 
   Tsinghua University 
   Computer Science, Tsinghua University 
   Beijing  100084 
   China 
   EMail: jianping@cernet.edu.cn 
    
   You Wang 
   Tsinghua University 
   Network Research Center, Tsinghua University 
   Beijing  100084 
   China 
   EMail: wangyou10@mails.tsinghua.edu.cn 
    
   Tao Lin 
   Hangzhou H3C Tech. Co., Ltd. 
   Beijing 100085 
   China 
   EMail: lintaog@gmail.com 
    

 
 
Bi, et al.             Expires August 6, 2013                [Page 13]