One document matched: draft-wu-sava-problem-statement-01.txt

Differences from draft-wu-sava-problem-statement-00.txt

Network Working Group                                    Paul Ferguson   
Internet-Draft                                       Trend Micro, Inc.
Intended status: Experimental                                    J. Wu
Expires: December 31, 2007                                       J. Bi
                                                                 X. Li
                                                                G. Ren
                                                   Tsinghua University
                                                         M I. Williams
                                                      Juniper Networks    
                                                 
                                                          31 June 2007
                                                   

    
                                                      


       Source Address Verification Architecture Problem Statement
                    draft-sava-problem-statement-01

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 31, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document outlines the problems that the Source Address
   Verification Architecture (SAVA) initiative plans to solve.  It
   examines the current state in the internet, looks at current best
   practices, and discusses why the current approaches are unlikely to
   ever solve the problem of IP address spoofing.  It also discusses
   some of the  problems that SAVA should NOT attempt to solve.

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.  Current State of Affairs  . . . . . . . . . . . . . . . . . . . 3
   3.  Shortcomings of Best Current Practices  . . . . . . . . . . . . 4
   4.  Framework Requiremenmts/Discussion  . . . . . . . . . . . . . . 4
   5.  Scaling & Methodlogy . . . . . . . . . . . .  . . . . . . . . . 5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9




1.  Introduction

   As we all know, the Internet is a decentralized system which basically
   provides best effort, packet-based data forwarding service.  In the
   forwarding process, intermediate devices (routers, switches, other
   gateway devices, etc.) forwards IP packets based on the destination
   IP address.

   This is how the Internet was designed to operate, and these are the
   principle contraints that we must acknowledge in the approach that SAVA
   attempts to address.

   In virtaully all cases of processing traffic in the Internet, the source
   IP address is generally not validated as being genuine. It is accepted
as
   being som simply because that it is written into the IP header datagram.

   This is no longer acceptable as method of assuring the validity of the
   geneuine source of traffic, since it is trivial for any host in the
   Internet to re-write this value, or simply misrepresent itself as the
   originator of traffic.

   This lack of source IP address validation makes it easy for anyone to
   spoof the originating IP host address, and has facilitated many existing
   historical (and current) instances of maliciousness (e.g. hiding behind
   spoofed IP source addresses, et al.).

   In recent years, there have been some efforts in the research
   community to design mechanisms to expose efforts to which employ
   IP source address spoofing -- plenty of instances of this are readily
   available.

   The motivation of this document is to clarify the problem in solving
   the spoofing of source address.

   The general problem of supporting authenticity of source address in
   the Internet is divided into three seperated sub-problems, refered
   as "First-hop, local subnet source validation", "Intra-AS Communication
   of SAVA validation", and "Inter-AS Communication of SAVA validation."

   The primary difference between these three topological applications
   details each issue and implementation is unique to the place where it
   is actually enabled.

   This problem statement attempts to illustrate why these problems are
   uniquely different, and why the SAVA framework, and subsequent soutions,
   must be implemented in such a fashion as to take into account the
   placement of each function into the heierachy of the Internet itself.



2.  Current State of Affairs

   In the MIT Spoofer Project [Bev05], the authors found that
   approximately one-quarter of the observed addresses, netblocks and
   autonomous systems (AS) permit full or partial spoofing.  And they
   also suggested that a large portion of the Internet is vulnerable to
   spoofing and concerted attacks employing spoofing remain a serious
   concern.

   While this is by no means an authoritative measurement of the scope
   of the problem, it does, however, illustrate the difficulty in
   measuring how deep this rabbit-hole actually goes -- and how the
   ability to spoof the source address of a packet can contribute to
   malicious activity or attacks in The Internet.

   Commentary: There is much heated discussion, in various forums, on
   the relative threat of spoofed IP host source addresses. Some of it
   is valid, some invalid. The purpose of this draft is to illustrate
   the ability to spoof IP source addresses, and some of the
   corresponding and resulting problems in allowing it to occur, not
   to debate the trends in this regard.

   One thing is for sure, however, and is still held true -- spoofed
   IP host source address traffic still exists, for one reason or
   another, and still poses a conundrum insofar as validating the
   source of maliciousness.


3.  Shortcomings of Best Current Practices

   While there are several BCPs in this area, the wide-spead adoption
   of them remains elusive.

   There is one Best Current Practice (BCP) published in the IETF that
   specifically deals with this issue, and there can be any number of
   discussions on why it is not widely delpoyed (but that is a topic
   for any number of other discussions):

   Ingress Filtering, as described in BCP38 [RFC2827], descibes
   a simple methodology for ISPs and any other Internet-facing
   organisation to apply filters (or other mechanisms) which limit
   to a specific parameter, the source addresses that can be allowed
   to be "source" packets into the Internet from a select and
   predetermined set of prefixes.

   If BCP38 were followed at all ingress points to the Internet, then
   there would be no spoofed packets on the Internet. This particular
   issue is not further discussed in this draft, however, the resulting
   work items that can formulated with a SAVA framework buikds on the
   initial purpose of BCP38 -- to prohibit traffic with spoofed source
   addresses to be sent into The Internet.

   One of the problem with BCP38 is that there is no measuareable or
   incremental method to determine it's success -- either it is deployed
   globally, or else there is no way to determine it's effectiveness.

   What we attempt to do with a SAVA framework, is to bring incremental
   benefit to incremetal deployment of BCP38 implementation, as well as
   a way to meaure it's global deployment and benefit.



4.  Framework Requirements

   SAVA Architecural and WG framework disucssions will be more
   completely defined and addressed in the proposed workgroup
   charter and the framework document.



5.  Scaling & Methodology

   SAVA functionality solutions will be feasible for all network sizes
   due to the manner in which we plan to dissect the framework -- each of
   the desired SAVA functionalities will be defined in individual documents
   that approximate their ability to perfoerm a specific function relative
   to their placement and function in the network heiracrhy:

   - First-hop, local-subnet source-address validation (and enforcement);
   - Intra-AS communication of SAVA validation;
   - Inter-AS communication of SAVA validation.


   Additionally, within the SAVA framework documentation process, we
   would like to define methods to determine how to measure and observe
   "SAVA validation" -- or rather, define ways in which it can be
   definitively determined that source address validation has been
   performed on traffic -- at each point in the Internet heirarchy (e.g.
   first-hop/local subnet, at each hop in the same AS, and at any
   arbitrary point in the end-to-end AS path from source to destination.)

6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


7.  Security Considerations

   For this document, no specific security considerations.  Many of the
   solution elements will need to be examined carefully for robustness
   and to see if they do not in themselves introduce security problems.


8.  Acknowledgements

    [blah]


9.  References


9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [Bev05]    Beverley, S. and S. Bauer, ""The spoofer project:
              inferring the extent of source address filtering on the
              Internet", USENIX SRUTI 2005", 2005.

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

   [RFC3871]  Jones, G., "Operational Security Requirements for Large
              Internet Service Provider (ISP) IP Network
              Infrastructure", RFC 3871, September 2004.


Authors' Addresses


Paul Ferguson
Trend Micro, Inc.
San Jose, California  USA
Email: Paul_Ferguson@trendmicro.com
+1.408.625.1068

Jianping Wu
Tsinghua University
Email: jianping@cernet.edu.cn

Jun Bi
Tsinghua University
Email: junbi@cernet.edu.cn

Xing Li
Tsinghua University
Email: xing@cernet.edu.cn

Gang Ren
Tsinghua University
Email: rengang@csnet1.cs.tsinghua.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







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).