One document matched: draft-baker-sava-simple-00.txt

Source Address Validation                                       F. Baker
Architecture                                               Cisco Systems
Internet-Draft                                            March 19, 2007
Intended status: Informational
Expires: September 20, 2007


                    Simple Source Address Validation
                       draft-baker-sava-simple-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 September 20, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This note proposes a simple solution to Source Address Validation,
   assuming that the purpose of such validation is to prevent attacks
   from using spoofed addresses.







Baker                  Expires September 20, 2007               [Page 1]

Internet-Draft    Local Unicast Reverse Path Forwarding       March 2007


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Simple proposed solution  . . . . . . . . . . . . . . . . . . . 3
     2.1.  The fundamental requirements: what is it that has to
           be solved?  . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.2.  What to do  . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.3.  How to do it  . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   Intellectual Property and Copyright Statements  . . . . . . . . . . 6



































Baker                  Expires September 20, 2007               [Page 2]

Internet-Draft    Local Unicast Reverse Path Forwarding       March 2007


1.  Introduction

   This note proposes a simple solution to Source Address Validation,
   assuming that the purpose of such validation is to prevent attacks
   from using spoofed addresses.  The Source Address Validation problem
   is proposed in other papers on this topic.  I won't try to replicate
   that discussion.

   That said, it seems to this author that the principal mode of attack
   in which a datagram with a spoofed source address is used is a single
   datagram attack; it is possible to spoof an address for the first
   exchange in a TCP session, but given that nothing is known of how a
   peer replies to a datagram that was sent from a spoofed address, the
   further into such a session one goes the more difficult it is to
   maintain the illusion of coherence.  As such, it seems like the first
   requirement is that the first datagram in a session have its address
   validated.

   It also seems to this author that the network in which a datagram is
   originated is among the targets that a bot might attack; an infected
   host can attack the next host on the same wire or switch.  As such,
   the value of such an architecture is non-zero for the source LAN, and
   only by derivation later.


2.  Simple proposed solution

   So I have a simple proposal.

2.1.  The fundamental requirements: what is it that has to be solved?

   If one buys the arguments that source address validation is of value
   in the network the datagram is originated on and that it must be
   applicable to the first datagram in any exchange, then it follows
   that

   o  the place to implement source address validation is the set of
      hosts and routers that directly connect to a host; e.g., those on
      the same LAN, and

   o  that those devices must learn of that address before it is used or
      as early as possible in its use.

2.2.  What to do

   Any host running IPv4 or IPv6 has one or more IP addresses that it
   uses on any given interface.  It also has some way of identifying
   itself to its neighbors at Link Layer.  On a LAN (fixed or wireless),



Baker                  Expires September 20, 2007               [Page 3]

Internet-Draft    Local Unicast Reverse Path Forwarding       March 2007


   it uses a MAC Address; in a GPRS/3GPP network, it establishes a
   circuit-like relationship with its router and is the only device at
   the end of that circuit, so the circuit identifies the association.
   If it is possible to associate addresses with hosts, it is possible
   to associate them the way host is identified at the link layer.  We
   in fact do that, for the purpose of datagram delivery.

   Implement what amounts to Local Unicast Reverse Path Forwarding.
   Impose a policy that one IP system should accept IP datagrams from a
   directly-connected IP neighbor (host or router) if and only if the
   Source IP Address is among the equivalence class of IP addresses
   known to be associated with the neighboring device.  If traffic is
   not accepted if that fails, this protects the devices each direct
   recipient from the problem.  Since one of those direct recipients is
   the first hop router, by extension this protects the enterprise and
   the Internet.

   There are obvious exceptions to this, including routers and
   multihomed hosts whose addresses are from other LANs.  It seems that
   these are eminently solvable:

   o  a host can identify each router it is a neighbor of, as it sends
      Router Advertisements,

   o  a router can identify a neighboring router by the fact that it
      enters into a routing protocol exchange, and

   o  multihomed hosts can follow a policy of only sending datagrams on
      the LANs on which their source addresses are valid.

   So these cases may be handled as exceptions in the logic.

2.3.  How to do it

   The way to accomplish this depends on the underlying Link Layer and
   the way it associates devices.  The set of valid IP addresses to be
   used by the typical host may be established using ARP, by watching
   DHCP assignments, or by asking for a Neighbor Discovery [RFC2461]
   exchange to be accomplished per address the host will use.


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



Baker                  Expires September 20, 2007               [Page 4]

Internet-Draft    Local Unicast Reverse Path Forwarding       March 2007


   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

   The security issues this document imposes are not worse than existing
   security behavior.  The use of ARP, Neighbor Discovery, and DHCP are
   not currently secured, which may be an open attack vector.  This is
   considered a separate issue that, if real, must be addressed
   separately.


5.  Acknowledgements


6.  References

6.1.  Normative References

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

6.2.  Informative References

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.


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 September 20, 2007               [Page 5]

Internet-Draft    Local Unicast Reverse Path Forwarding       March 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 September 20, 2007               [Page 6]