idnits 2.17.1 draft-baker-sava-cisco-ip-source-guard-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.2b on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 216. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 227. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 240. -- The document has an RFC 3978 Section 5.2(b) Derivative Works Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 5, 2007) is 6016 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Informational November 5, 2007 5 Expires: May 8, 2008 7 Cisco IP Version 4 Source Guard 8 draft-baker-sava-cisco-ip-source-guard-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 This document may not be modified, and derivative works of it may not 17 be created. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 8, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 As requested in the SAVA discussions, this document describes Cisco's 44 IP Source Guard feature. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. IP Source Guard . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1. Intended use of IP Source Guard . . . . . . . . . . . . . . 4 51 2.2. Pitfalls of IP Source Guard . . . . . . . . . . . . . . . . 4 52 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 54 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 55 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 Intellectual Property and Copyright Statements . . . . . . . . . . 7 59 1. Introduction 61 As requested in the SAVA discussions, this document describes Cisco's 62 IP Source Guard feature. This is a feature intended to implement BCP 63 38 [RFC2827] for IPv4 [RFC0791] in a switched LAN environment. It is 64 referred to in [I-D.baker-sava-operational], which describes existing 65 implementations of BCP 38 in real networks. 67 For IPR purposes, this document is coded as "no derivative works", 68 which implies "not to be published as an RFC". The reason is that it 69 describes a specific feature of a specific set of products, not for 70 the purpose of setting a standard, but for the purpose of describing 71 existing practice. This is an input to the process, not an output. 72 Also, the proper place to find documentation of vendor features is 73 the vendor's web site (in this case, [IPSRCGRD]), not an IETF RFC. 74 That said, we are happy to discuss the feature with anyone that is 75 interested. 77 2. IP Source Guard 79 IP Source Guard provides source IPv4 address filtering on a Layer 2 80 port to prevent a malicious host from impersonating a legitimate host 81 by assuming the legitimate host's IPv4 address. The feature uses 82 dynamic DHCP snooping and static IPv4 source binding to match IPv4 83 addresses to hosts on untrusted Layer 2 ports, including both access 84 and trunk ports. 86 Initially, all IPv4 traffic on the protected port is blocked except 87 for DHCP packets. After a client receives an IPv4 address from the 88 DHCP server, or after a static IPv4 source binding is configured by 89 the administrator, all traffic with that IPv4 source address is 90 permitted from that client. Traffic from other hosts is denied. 91 This filtering limits a host's ability to attack the network by 92 claiming a neighbor host's IPv4 address. IPv4 Source Guard is a 93 port-based feature that automatically creates an implicit port access 94 control list (PACL). 96 As described, the feature is clearly one implemented on an IP or 97 Ethernet switch intended for use in a SOHO, corporate, or access 98 network. It is not, at this writing, supported on Cisco routers, nor 99 is it something one would expect to be implemented on a host. 100 Interoperability is not a requirement per se; if the DHCP client and 101 server are interoperable with each other, spoofing is adequately 102 eliminated. 104 2.1. Intended use of IP Source Guard 106 In the IPv4 architecture, it is legal to have more than one IP 107 address on a host, and there are systems (including routers and some 108 hosts) that routinely send datagrams using a source IP address that 109 differs from the interface's primary IP address. However, in the 110 general case, a host has one address for each interface, and in the 111 general case, a host has one interface. It is this case that the IP 112 Source Guard feature addresses. By dropping all IPv4 datagrams from 113 such hosts that use a different address than the one assigned, the 114 feature severely limits a network's ability to introduce spoofed 115 source addresses to the Internet. 117 One could argue that this done not help the local network, but one 118 would be wrong. An attack that happens elsewhere in the Internet can 119 and does happen on the local LAN and in the IP network that a host 120 resides in. Hence, while the degree may not be the same, eliminating 121 address spoofing remains the first step in removing several classes 122 of attacks from one's network, and is therefore a good idea. 124 2.2. Pitfalls of IP Source Guard 126 IP Source Guard assumes that some ports on a switch - those whose 127 single interface has one address - are "protected" and others are 128 not. "Others" include systems with multiple interfaces, which might 129 as a result receive a datagram through one interface and respond to 130 it ("from" the IP of that interface) on the other, for which this 131 capability is obviously problematic. "Others" also includes routers, 132 prefix-based NATs, and others, which may originate traffic from a 133 variety of addresses that are not within the local prefix. 135 The problem on a router interface should be obvious: a router 136 forwards datagrams sent by other systems, which carry the source 137 address of their originators. If this feature is applied to a router 138 interface, the data it is forwarding will be discarded, nullifying 139 its usefulness without advising either the network or its users of 140 the fact - a clear violation of the End-to-End principle. 142 The problem on other varieties of devices - NATs that use multiple 143 addresses, hosts that have "primary" and "secondary" addresses, and 144 hosts with multiple LAN interfaces - is of the same nature. The 145 system will be prevented from carrying out an intended function when 146 using an address other than the one that the switch is enforcing the 147 use of. 149 3. IANA Considerations 151 This memo adds no new IANA considerations. 153 Note to RFC Editor: This section will have served its purpose if it 154 correctly tells IANA that no new assignments or registries are 155 required, or if those assignments or registries are created during 156 the RFC publication process. From the author's perspective, it may 157 therefore be removed upon publication as an RFC at the RFC Editor's 158 discretion. 160 4. Security Considerations 162 IP Source Guard is intended to contribute to the security of an IPv4 163 network by reducing the probability that an end system can inject 164 data into the network that appears to be from a different interface 165 or system. Obvious weaknesses, as discussed in Section 2.1, include 166 any system that might legitimately send datagrams from an address 167 other than that of an interface. 169 5. Acknowledgements 171 6. Informative References 173 [I-D.baker-sava-operational] 174 Baker, F. and R. Droms, "IPv4/IPv6 Source Address 175 Verification", draft-baker-sava-operational-00 (work in 176 progress), June 2007. 178 [IPSRCGRD] 179 Cisco Systems, Inc, "Cisco: Configuring IP Source Guard", 180 . 184 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 185 September 1981. 187 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 188 Defeating Denial of Service Attacks which employ IP Source 189 Address Spoofing", BCP 38, RFC 2827, May 2000. 191 Author's Address 193 Fred Baker 194 Cisco Systems 195 Santa Barbara, California 93117 196 USA 198 Phone: +1-408-526-4257 199 Fax: +1-413-473-2403 200 Email: fred@cisco.com 202 Full Copyright Statement 204 Copyright (C) The IETF Trust (2007). 206 This document is subject to the rights, licenses and restrictions 207 contained in BCP 78, and except as set forth therein, the authors 208 retain all their rights. 210 This document and the information contained herein are provided on an 211 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 212 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 213 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 214 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 215 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 216 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 218 Intellectual Property 220 The IETF takes no position regarding the validity or scope of any 221 Intellectual Property Rights or other rights that might be claimed to 222 pertain to the implementation or use of the technology described in 223 this document or the extent to which any license under such rights 224 might or might not be available; nor does it represent that it has 225 made any independent effort to identify any such rights. Information 226 on the procedures with respect to rights in RFC documents can be 227 found in BCP 78 and BCP 79. 229 Copies of IPR disclosures made to the IETF Secretariat and any 230 assurances of licenses to be made available, or the result of an 231 attempt made to obtain a general license or permission for the use of 232 such proprietary rights by implementers or users of this 233 specification can be obtained from the IETF on-line IPR repository at 234 http://www.ietf.org/ipr. 236 The IETF invites any interested party to bring to its attention any 237 copyrights, patents or patent applications, or other proprietary 238 rights that may cover technology that may be required to implement 239 this standard. Please address the information to the IETF at 240 ietf-ipr@ietf.org. 242 Acknowledgment 244 Funding for the RFC Editor function is provided by the IETF 245 Administrative Support Activity (IASA).