[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                              J. Wu
Internet-Draft                                       Tsinghua University
Intended status: Experimental                                  R. Bonica
Expires: August 9, 2007                                 Juniper Networks
                                                                   J. Bi
                                                                   X. Li
                                                                  G. Ren
                                                     Tsinghua University
                                                           M I. Williams
                                                        Juniper Networks
                                                        February 5, 2007


       Source Address Verification Architecture Problem Statement
                    draft-sava-problem-statement-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 August 9, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document outlines the problems for the Source Address



Wu, et al.               Expires August 9, 2007                 [Page 1]


Internet-Draft           SAVA Problem Statement            February 2007


   Verification Architecture (SAVA) initiative to solve.  It examines
   the current state in the internet, looks at current best practices
   and discusses why the current approach is 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.  Best Current Practices  . . . . . . . . . . . . . . . . . . . . 4
   4.  Deficiencies of Ingress-Filter (BCP0038) and uRPF Approach  . . 4
   5.  Why IPSEC is not the Solution to This Problem . . . . . . . . . 5
   6.  Framework Requirements  . . . . . . . . . . . . . . . . . . . . 5
     6.1.  Direct Benefit to Deployers . . . . . . . . . . . . . . . . 5
     6.2.  Solution Focus on IPv6  . . . . . . . . . . . . . . . . . . 5
     6.3.  Performance . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.4.  Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     6.5.  Multiple-Fence Solution . . . . . . . . . . . . . . . . . . 6
     6.6.  Incrementally Deployable  . . . . . . . . . . . . . . . . . 6
     6.7.  Loose Coupling  . . . . . . . . . . . . . . . . . . . . . . 6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9















Wu, et al.               Expires August 9, 2007                 [Page 2]


Internet-Draft           SAVA Problem Statement            February 2007


1.  Introduction

   The Internet is a decentralized system which basically provides best
   effort, packet-based data forwarding service.  In the forwarding
   process, the device (router, switch, gateway, etc.) forwards IP
   packets based on the destination IP address.  In most cases, the
   source IP address is not checked.  The lack of source IP address
   checking makes it easy for the attackers to spoof the source address.
   And it has facilitated many existing attacks in the Internet.

   In recent years, there have been some efforts in the research
   community to design mechanisms on fighting against source address
   spoofing.  We think it is now a suitable time to summarize the
   progress and to standardize some results of research efforts to
   protocols, to enhance the authenticity of the source address.
   Providing authentic IP address is not only helpful to network
   security, but also helpful to some other aspects, e.g., network
   application, network management and accounting, etc.

   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 "inter-AS AIAA problem", "intra-AS
   SAVA problem" and "access network SAVA problem".  The primary
   difference between these three problems is the different level and
   scope in network topology.  The "inter-AS SAVA problem" considers the
   source address spoofing involved with more than one ASes.  The
   "inter-AS SAVA problem" considers the source address spoofing inside
   one AS.  The "access network SAVA problem" considers the source
   address spoofing inside one access network.  There may be multiple
   candidate solutions for each sub-problem.

   Because the current Internet addressing architecture does not verify
   the source address of the packets received and forwarded, has been
   formed for many years, it is difficult and not cost-effective to
   change from the current Internet infrastructure.  The development of
   the IPv6 based next generation Internet will give us the opportunity
   to implement an authentic addressing architecture.  In this memo,
   only the issues in IPv6 network are discussed.


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
   suggested that a large portion of the Internet is vulnerable to
   spoofing and concerted attacks employing spoofing remain a serious



Wu, et al.               Expires August 9, 2007                 [Page 3]


Internet-Draft           SAVA Problem Statement            February 2007


   concern.


3.  Best Current Practices

   The current method of avoiding packets with spoofed source addresses
   entering and being propagated on the Internet relies on two methods:

   1.  Ingress Filtering as per BCP0038 [RFC2827].  This method requires
       ISPs and organisations at the edge to apply filters limiting the
       source addresses allowed on incoming packets to those
       specifically allowed in the stub networks.  If BCP0038 were
       followed at all ingress points to the Internet, then there would
       be no spoofed packets on the Internet.

   2.  Unicast Reverse Path Forwarding (uRPF) filtering.  This is a
       feature available on routers that can be used to block incoming
       packets if, in the case a packet were constructed with the
       incoming packet's source address as its destination address, the
       constructed packet would NOT be routed back along the ingress
       link for the incoming packet.  Assuming random incidence of
       spoofed packets and symmetric routing, a router with n links and
       with uRPF configured would drop (n-1)/n of all incoming spoofed
       packets, greatly mitigating DoS attacks using spoofed packets,
       for example.  (See [RFC3871])


4.  Deficiencies of Ingress-Filter (BCP0038) and uRPF Approach

   Ingress filtering is definitely to be recommended, and uRPF filtering
   certainly does have its uses, but, at least in the current state of
   the Internet, they are insufficient as a protection of the routing
   infrastructure.

   1.  Ingress filtering works, but it only works if all, or at least
       the vast majority of ingress points apply ingress filtering.  As
       can be seen in the Internet today, even when 25% of the Internet
       is unsecured, those elements that want access to "spoofable"
       connections simply move their connection to unsecured attachment
       points.

   2.  uRPF does not work well in places where assymetric routing
       happens.  This constitutes a large part of the Internet








Wu, et al.               Expires August 9, 2007                 [Page 4]


Internet-Draft           SAVA Problem Statement            February 2007


5.  Why IPSEC is not the Solution to This Problem

   IPSEC is a solution to many problems, and it is not the intention of
   the authors to suggest that it should not be deployed.  It is just
   not the solution to this particular problem.

   Whereas IPSEC solves end-end security problems and allows endpoints
   in a connection to verify the identity of connected endpoints, there
   is also a need for the infrastructure of the Internet to be able to
   protect itself.  Many attacks employ spoofed IP addresses to either
   conceal the source of an infrastructure attack or to cause the
   network infrastructure to, in effect, attack itself.

   The network must be able to secure itself from poorly-secured
   endpoints.  The goal of the solution to the problem must be to
   discard spoofed traffic as close to the source of the attack as
   possible. (i.e. within the infrastructure rather than at the other
   endpoint(s).


6.  Framework Requirements

   Following is a list of key requirements for any solution/s to the
   problem described above.  They will be more completely delineated in
   the proposed workgroup charter and the framework document.

6.1.  Direct Benefit to Deployers

   One of the reasons for the less-than-adequate deployment of ingress
   filters is that, in deploying the filters, a network operator or
   attached private network is mostly protecting the rest of the
   Internet rather than itself.  It should be a design goal for any
   solution to give those that deploy the solution some increased level
   of protection from spoofed attacks from outside of their own
   adminitrative domain.

6.2.  Solution Focus on IPv6

   While it is not the intent to develop solutions that cannot be
   deployed on an IPv4 network, the focus of the work should be on
   solutions for IPv6 networks.  In other words, if a solution is
   feasible for IPv6 deployment, but infeasible for IPv4 deployment,
   that shall not be construed as a disadvantage for the solution.

6.3.  Performance

   Deployment of SAVA solutions should not place unreasonable stress on
   network infrastructure components.



Wu, et al.               Expires August 9, 2007                 [Page 5]


Internet-Draft           SAVA Problem Statement            February 2007


6.4.  Scaling

   SAVA solutions should be feasible for network sizes and no-default
   prefix tables many times the size experienced today.  SAVA solutions
   should scale in a way that is at worst linear with the size of the
   Internet.

6.5.  Multiple-Fence Solution

   Ingress filtering is a single fence solution, in that it is only
   applicable only at the access network or at the boundary between an
   attached private network and a network provider.  Where the attached
   network is not a stub, it cannot be deployed effectively.  It should
   be the goal of the SAVA working group to provide solutions that can
   be deployed at the boundaries between ISPs or on intra-ISP links as
   well.

6.6.  Incrementally Deployable

   It must be possible to deploy SAVA solutions incrementally across the
   network.  In other words, there can be no "flag day".

6.7.  Loose Coupling

   Components of the overall solution should be able to be deployed in a
   "mix and match" fashion. this allows for multiple solutions for a
   given component of the overall solution.


7.  IANA Considerations

   This document makes no request of IANA.

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


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


9.  Acknowledgements


10.  References



Wu, et al.               Expires August 9, 2007                 [Page 6]


Internet-Draft           SAVA Problem Statement            February 2007


10.1.  Normative References

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

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

   Jianping Wu
   Tsinghua University


   Phone:
   Email: jianping@cernet.edu.cn
   URI:


   Ronald P. Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, VA  20171
   USA


   Jun Bi
   Tsinghua University


   Phone:
   Fax:
   Email:
   URI:





Wu, et al.               Expires August 9, 2007                 [Page 7]


Internet-Draft           SAVA Problem Statement            February 2007


   Xing Li
   Tsinghua University


   Email: xing@cernet.edu.cn


   Gang Ren
   Tsinghua University

   Email: rengang@csnet1.cs.tsinghua.edu.cn
   URI:


   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






























Wu, et al.               Expires August 9, 2007                 [Page 8]


Internet-Draft           SAVA Problem Statement            February 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).





Wu, et al.               Expires August 9, 2007                 [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/