One document matched: draft-baker-sava-cisco-ip-source-guard-00.txt

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",
              <http://www.cisco.com/en/US/docs/switches/lan/
              catalyst6500/ios/12.2SX/configuration/guide/
              ipsrcgrd.html>.

   [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]