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