Network Working Group J. Wu Internet-Draft G. Ren Intended status: Experimental J. Bi Expires: December 10, 2007 X. Li CERNET M. Williams Juniper Networks June 8, 2007 A First-Hop Source Address Validation Solution for SAVA draft-wu-sava-solution-firsthop-eap-00 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 December 10, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes a solution for preventing source address spoofing in the first hop, local subnet of the Internet. The main idea of the solution is to get a dynamic binding between IP address and access switch port. Wu, et al. Expires December 10, 2007 [Page 1] Internet-Draft SAVA First-Hop Validation June 2007 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 RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. First-Hop, 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 December 10, 2007 [Page 2] Internet-Draft SAVA First-Hop Validation June 2007 1. Introduction The problem of source address validation is decomposed hierarchically into three levels of granularity in [I-D.wu-sava-framework] for discussion: first-hop, local subnet source validation, intra-AS source validation, and inter-AS source validation. The first-hop, 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. It should be stressed that at this early stage, the solutions proposed in the solution document are not intended to pre-empt other work carried out by the IETF in the solution space. Indeed, consensus must be reached on a framework before solution work can be fully undertaken. 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 first-hop, local subnet source validation have been devised and one is introduced and discussed in [I-D.baker-sava-simple]. 2. First-Hop, 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 First-Hop, 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. See detail in [I-D.wu-sava-framework]. Wu, et al. Expires December 10, 2007 [Page 3] Internet-Draft SAVA First-Hop Validation June 2007 2.2. Focus of the Solution There are several different first-hop, 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 first-hop, 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 December 10, 2007 [Page 4] Internet-Draft SAVA First-Hop Validation June 2007 --------- | 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 December 10, 2007 [Page 5] Internet-Draft SAVA First-Hop Validation June 2007 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 December 10, 2007 [Page 6] Internet-Draft SAVA First-Hop Validation June 2007 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations 7. Acknowledgements I-D.wu-sava-problem-statement 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-simple] Baker, F., "Simple Source Address Validation", draft-baker-sava-simple-00 (work in progress), March 2007. [I-D.wu-sava-framework] Wu, J., "Source Address Validation Architecture (SAVA) Framework", draft-wu-sava-framework-00 (work in progress), February 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., "SAVA Testbed and Experiences to Date", draft-wu-sava-testbed-experience-00 (work in progress), February 2007. Wu, et al. Expires December 10, 2007 [Page 7] Internet-Draft SAVA First-Hop Validation June 2007 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 December 10, 2007 [Page 8] Internet-Draft SAVA First-Hop Validation June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Wu, et al. Expires December 10, 2007 [Page 9]