[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                                              J. Wu
Internet-Draft                                                    G. Ren
Intended status: Experimental                                      J. Bi
Expires: January 14, 2009                                          X. Li
                                                                  CERNET
                                                             M. Williams
                                                        Juniper Networks
                                                           July 13, 2008


  A Solution For Source Address Validation in Local Subnet Environment
                 draft-wu-sava-solution-firsthop-eap-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 14, 2009.

Abstract

   This document describes a solution for preventing source address
   spoofing in the local subnet of the Internet.  The main idea of the
   solution is to get a dynamic binding between IP address and access
   switch port.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",



Wu, et al.              Expires January 14, 2009                [Page 1]


Internet-Draft              Abbreviated-Title                  July 2008


   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Local Subnet Source Address Validation  . . . . . . . . . . . . 3
     2.1.  Problem Description . . . . . . . . . . . . . . . . . . . . 3
     2.2.  Focus of the Solution . . . . . . . . . . . . . . . . . . . 4
   3.  An IP Address-Switch Port Binding Solution  . . . . . . . . . . 4
     3.1.  System Architecture . . . . . . . . . . . . . . . . . . . . 4
     3.2.  Key Mechanisms  . . . . . . . . . . . . . . . . . . . . . . 6
     3.3.  Discussion of Control Protocol  . . . . . . . . . . . . . . 6
   4.  CNGI-CERNET2 Test Experience  . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9




























Wu, et al.              Expires January 14, 2009                [Page 2]


Internet-Draft              Abbreviated-Title                  July 2008


1.  Introduction

   The problem of source address validation is decomposed hierarchically
   into three levels of granularity in [I-D.wu-sava-framework] for
   discussion: local subnet source validation, intra-AS source
   validation, and inter-AS source validation.

   The local subnet source validation is the crucial level in the
   hierarchy when it comes to achieving "strict-validated"SAVA status,
   which means the packet can be traced back to an individual host that
   is authorized to emit packets with that source address.  An IP
   address-switch port binding solution is proposed in this document.

   There have been many efforts in the research and engineering
   community to design mechanisms related to source address validation
   in local subnet environment.  IP Source Guard and DHCP Lease Query
   are related solution examples.

   It should be stressed that at this early stage, the solutions
   proposed in this solution document are not intended to pre-empt other
   work carried out by the IETF in the solution space.  Furthermore, it
   is envisaged that more than one solution could be devised and
   deployed for each of the proposed solution elements required under
   the framework, in keeping with the requirement for a loosely-coupled
   architecture and, as far as possible, a plug-and-play framework.

   The intention of this document is to provide some potential solution
   ideas which have been implemented on the testbed described
   in[I-D.wu-sava-testbed-experience].  Some other procedures that could
   be used as solution elements in the local subnet source validation
   have been devised and one is introduced and discussed in
   [I-D.baker-sava-cisco-ip-source-guard].


2.  Local Subnet Source Address Validation

2.1.  Problem Description

   The deployment of BCP38 typically requires that the source address of
   a packet entering the provider network belong to a prefix that is
   allocated to or has transit through the attached access network.  If
   there is no special consideration, one host can still spoof source
   address by sending packet with the "legal" IP address of another host
   with same IP prefix.  The goal of the Local Subnet source address
   validation is to solve the source address spoofing problem in these
   scenarios.  That is, to achieve "strict-validated" SAVA validation
   status, which means the packet can be traced back to an individual
   host that is authorized to emit packets with that source address.



Wu, et al.              Expires January 14, 2009                [Page 3]


Internet-Draft              Abbreviated-Title                  July 2008


   See detail in [I-D.wu-sava-framework].

2.2.  Focus of the Solution

   There are several different local subnet scenarios: enterprise
   networks with switches, home broadband access, access from a wireless
   mobile device etc.  The focus of the solution described in this
   document is enterprise networks with switches.The source address may
   be assigned to the host in a static way or a dynamic way.

   The solution tested in the SAVA testbed takes the strongest
   requirement for validation in the local subnet.  That is, any IPv6
   address should have a unique association with an entity that is
   specifically authorised to use that IPv6 address.  The SAVA testbed
   has implemented a solution for IPv6 only.  The principles can be
   extended to IPv4 without difficulty.


3.  An IP Address-Switch Port Binding Solution

3.1.  System Architecture

   The main idea of the solution described in this document is based on
   creating a dynamic binding between a switch port and valid source IP
   address, or a binding between MAC address, source IP address and
   switch port.

   There are four main modules of the system: Source Address Request
   Client (SARC) on the host, Source Address Validation Proxy (SAVP) on
   the switch, Source Address Management Server (SAMS) and Interface to
   the Authentication Server (IAS).  The system architecture is shown in
   Figure 1.



















Wu, et al.              Expires January 14, 2009                [Page 4]


Internet-Draft              Abbreviated-Title                  July 2008


                                    ---------
                                    | IAS   |
                                    ------|-
                                          |
                                ----------------
                                | SERVER        |
                                |    -------    |
                                |    | SAMS |   |
                                |    --------   |
                                -----------------
                                        |
                                        |
                                ----------------
                                | SWITCH        |
                                |    -------    |
                                |    | SAVP |   |
                                |    --------   |
                                -----------------
                                        |
                                        |
                                ----------------
                                | END HOST      |
                                |    -------    |
                                |    | SARC |   |
                                |    --------   |
                                -----------------
   Key: SARC == Source Address Request Client , SAVP == Source Address
   Validation Proxy, SAMS== Source Address Management Server, IAS==
   Interface to the Authentication Server

                       Figure 1: System Architecture

   o  SARC sends an IP address request to the SAMS.

   o  SAVP relays the IP address request from SARC to SAMS and the IP
      addess response from SAMS to SARC.  It maintain a binding table
      between switch port and source IP address.

   o  SAMS receives the request from SARC and generates an address
      response to SARC based on the address allocation and management
      policy of the local subnet.  It can contact to the authentication
      server for identification and access control via IAS.  The
      allocation history of the address is stored in SAMS for future
      traceback.

   o  IAS is the interface between the SAMS and authentication server.
      In many cases, the allocation and binding of IP addresses is
      performed after a process of identity discovery and application of



Wu, et al.              Expires January 14, 2009                [Page 5]


Internet-Draft              Abbreviated-Title                  July 2008


      access control policy.

3.2.  Key Mechanisms

   The solution's principle steps are as follows:

   1.  The SARC on the end host sends an IP address request.  The SAVP
       on the switch relays this request to the SAMS.  If the address
       has been predetermined by the end host, it still needs to put it
       in the request datagram for acceptance from SAMS.

   2.  SAMS receives the IP address request, and generates an address
       response to SARC based on the address allocation and management
       policy of the local subnet.  The allocation of the IP address is
       stored in the history database of SAMS for traceback.  If the
       allocation and binding of IP address is performed process of
       identity discovery and application of access control policy, do
       the identification via IAS.  If authorization is successful, send
       the IP address response to the SARC.

   3.  The SAVP on the access switch receives the response, and binds
       the IP address with the switch port on the binding table.  In
       addition, it forwards the issued address to SARC on the end host.

   4.  The access switch begins to filter packets sent from the end
       host.  Packets which do not conform to the tuple (IP address,
       Switch Port) are discarded.

3.3.  Discussion of Control Protocol

   The control protocol for generating binding rules of IP address and
   switch port can be an extension of DHCP, or a new protocol.  The
   allocation and binding of IP address can also performed after a
   process of access control and identification.  For the implementation
   in CNGI-CERNET2 testbed, The communication between SARC and SAVP is
   an extension of EAP, and the communication between SAVP and SAMS is
   an extension of Radius.


4.  CNGI-CERNET2 Test Experience

   The solutions outlined above have been implemented on the testbed of
   CNGI-CERNET2.  An extension of EAP is used for the communication
   between SARC and SAVP, and an extension of Radius is used for the
   communication between SAVP and SAMS.  Successful testing of the
   solution has been carried out.  A more detailed discussion is
   described in [I-D.wu-sava-testbed-experience].




Wu, et al.              Expires January 14, 2009                [Page 6]


Internet-Draft              Abbreviated-Title                  July 2008


5.  IANA Considerations

   This document makes no request of IANA.


6.  Security Considerations


7.  Acknowledgements


8.  References

8.1.  Normative References

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

8.2.  Informative References

   [I-D.baker-sava-cisco-ip-source-guard]
              Baker, F., "Cisco IP Version 4 Source Guard",
              draft-baker-sava-cisco-ip-source-guard-00 (work in
              progress), November 2007.

   [I-D.wu-sava-framework]
              Wu, J., "Source Address Validation Architecture (SAVA)
              Framework", draft-wu-sava-framework-01 (work in progress),
              July 2007.

   [I-D.wu-sava-problem-statement]
              Wu, J., Bonica, R., Bi, J., Li, X., Ren, G., and M.
              Williams, ""Source Address Validation Architecture (SAVA)
              Problem Statement", draft-wu-sava-problem-statement-00
              (Work in Progress)", February 2007.

   [I-D.wu-sava-testbed-experience]
              Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams,
              "SAVA Testbed and Experiences to Date",
              draft-wu-sava-testbed-experience-06 (work in progress),
              May 2008.










Wu, et al.              Expires January 14, 2009                [Page 7]


Internet-Draft              Abbreviated-Title                  July 2008


Authors' Addresses

   Jianping Wu
   CERNET
   Network Center, Tsinghua University
   Beijing  100084
   China

   Email: jianping@cernet.edu.cn


   Gang Ren
   CERNET
   Network Center, Tsinghua University
   Beijing  100084
   China

   Email: rg03@mails.tsinghua.edu.cn


   Jun Bi
   CERNET
   Network Center, Tsinghua University
   Beijing  100084
   China

   Email: junbi@cernet.edu.cn


   Xing Li
   CERNET
   Network Center, Tsinghua University
   Beijing  100084
   China

   Email: xing@cernet.edu.cn


   Mark I. Williams
   Juniper Networks
   Suite 1508, W3 Tower, Oriental Plaza, 1 East Chang'An Ave
   Dong Cheng District, Beijing  100738
   China

   Email: miw@juniper.net






Wu, et al.              Expires January 14, 2009                [Page 8]


Internet-Draft              Abbreviated-Title                  July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Wu, et al.              Expires January 14, 2009                [Page 9]