Network Working Group F. Baker Internet-Draft Cisco Systems Intended status: Informational November 5, 2007 Expires: May 8, 2008 Cisco IP Version 4 Source Guard draft-baker-sava-cisco-ip-source-guard-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. This document may not be modified, and derivative works of it may not be created. 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 May 8, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract As requested in the SAVA discussions, this document describes Cisco's IP Source Guard feature. Baker Expires May 8, 2008 [Page 1] Internet-Draft Cisco IP Version 4 Source Guard November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. IP Source Guard . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Intended use of IP Source Guard . . . . . . . . . . . . . . 4 2.2. Pitfalls of IP Source Guard . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Baker Expires May 8, 2008 [Page 2] Internet-Draft Cisco IP Version 4 Source Guard November 2007 1. Introduction As requested in the SAVA discussions, this document describes Cisco's IP Source Guard feature. This is a feature intended to implement BCP 38 [RFC2827] for IPv4 [RFC0791] in a switched LAN environment. It is referred to in [I-D.baker-sava-operational], which describes existing implementations of BCP 38 in real networks. For IPR purposes, this document is coded as "no derivative works", which implies "not to be published as an RFC". The reason is that it describes a specific feature of a specific set of products, not for the purpose of setting a standard, but for the purpose of describing existing practice. This is an input to the process, not an output. Also, the proper place to find documentation of vendor features is the vendor's web site (in this case, [IPSRCGRD]), not an IETF RFC. That said, we are happy to discuss the feature with anyone that is interested. 2. IP Source Guard IP Source Guard provides source IPv4 address filtering on a Layer 2 port to prevent a malicious host from impersonating a legitimate host by assuming the legitimate host's IPv4 address. The feature uses dynamic DHCP snooping and static IPv4 source binding to match IPv4 addresses to hosts on untrusted Layer 2 ports, including both access and trunk ports. Initially, all IPv4 traffic on the protected port is blocked except for DHCP packets. After a client receives an IPv4 address from the DHCP server, or after a static IPv4 source binding is configured by the administrator, all traffic with that IPv4 source address is permitted from that client. Traffic from other hosts is denied. This filtering limits a host's ability to attack the network by claiming a neighbor host's IPv4 address. IPv4 Source Guard is a port-based feature that automatically creates an implicit port access control list (PACL). As described, the feature is clearly one implemented on an IP or Ethernet switch intended for use in a SOHO, corporate, or access network. It is not, at this writing, supported on Cisco routers, nor is it something one would expect to be implemented on a host. Interoperability is not a requirement per se; if the DHCP client and server are interoperable with each other, spoofing is adequately eliminated. Baker Expires May 8, 2008 [Page 3] Internet-Draft Cisco IP Version 4 Source Guard November 2007 2.1. Intended use of IP Source Guard In the IPv4 architecture, it is legal to have more than one IP address on a host, and there are systems (including routers and some hosts) that routinely send datagrams using a source IP address that differs from the interface's primary IP address. However, in the general case, a host has one address for each interface, and in the general case, a host has one interface. It is this case that the IP Source Guard feature addresses. By dropping all IPv4 datagrams from such hosts that use a different address than the one assigned, the feature severely limits a network's ability to introduce spoofed source addresses to the Internet. One could argue that this done not help the local network, but one would be wrong. An attack that happens elsewhere in the Internet can and does happen on the local LAN and in the IP network that a host resides in. Hence, while the degree may not be the same, eliminating address spoofing remains the first step in removing several classes of attacks from one's network, and is therefore a good idea. 2.2. Pitfalls of IP Source Guard IP Source Guard assumes that some ports on a switch - those whose single interface has one address - are "protected" and others are not. "Others" include systems with multiple interfaces, which might as a result receive a datagram through one interface and respond to it ("from" the IP of that interface) on the other, for which this capability is obviously problematic. "Others" also includes routers, prefix-based NATs, and others, which may originate traffic from a variety of addresses that are not within the local prefix. The problem on a router interface should be obvious: a router forwards datagrams sent by other systems, which carry the source address of their originators. If this feature is applied to a router interface, the data it is forwarding will be discarded, nullifying its usefulness without advising either the network or its users of the fact - a clear violation of the End-to-End principle. The problem on other varieties of devices - NATs that use multiple addresses, hosts that have "primary" and "secondary" addresses, and hosts with multiple LAN interfaces - is of the same nature. The system will be prevented from carrying out an intended function when using an address other than the one that the switch is enforcing the use of. Baker Expires May 8, 2008 [Page 4] Internet-Draft Cisco IP Version 4 Source Guard November 2007 3. IANA Considerations This memo adds no new IANA considerations. Note to RFC Editor: This section will have served its purpose if it correctly tells IANA that no new assignments or registries are required, or if those assignments or registries are created during the RFC publication process. From the author's perspective, it may therefore be removed upon publication as an RFC at the RFC Editor's discretion. 4. Security Considerations IP Source Guard is intended to contribute to the security of an IPv4 network by reducing the probability that an end system can inject data into the network that appears to be from a different interface or system. Obvious weaknesses, as discussed in Section 2.1, include any system that might legitimately send datagrams from an address other than that of an interface. 5. Acknowledgements 6. Informative References [I-D.baker-sava-operational] Baker, F. and R. Droms, "IPv4/IPv6 Source Address Verification", draft-baker-sava-operational-00 (work in progress), June 2007. [IPSRCGRD] Cisco Systems, Inc, "Cisco: Configuring IP Source Guard", . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. Baker Expires May 8, 2008 [Page 5] Internet-Draft Cisco IP Version 4 Source Guard November 2007 Author's Address Fred Baker Cisco Systems Santa Barbara, California 93117 USA Phone: +1-408-526-4257 Fax: +1-413-473-2403 Email: fred@cisco.com Baker Expires May 8, 2008 [Page 6] Internet-Draft Cisco IP Version 4 Source Guard November 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). Baker Expires May 8, 2008 [Page 7]