[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.129c, available from
https://tools.ietf.org/tools/rfcmarkup/