Network Working Group J. Wu
Internet-Draft J. Bi
Intended status: Informational G. Ren
Expires: August 11, 2007 X. Li
CERNET
R. Bonica
M. Williams
Juniper Networks
February 7, 2007
Source Address Validation Architecture (SAVA) Framework
draft-wu-sava-framework-00.txt
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 11, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document presents the framework for SAVA (Source Address
Validation Architecture).
Wu, et al. Expires August 11, 2007 [Page 1]
Internet-Draft SAVA Framework February 2007
Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Forwarding Component . . . . . . . . . . . . . . . . . . . . . 3
4.1. uRPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Signature . . . . . . . . . . . . . . . . . . . . . . . . 3
4.3. Verification . . . . . . . . . . . . . . . . . . . . . . . 3
5. Control Component . . . . . . . . . . . . . . . . . . . . . . 3
5.1. Generation and Distribution of Validation Rules . . . . . 3
5.2. Generation and Distribution of Authentication
Information . . . . . . . . . . . . . . . . . . . . . . . 4
6. Framework Granularity . . . . . . . . . . . . . . . . . . . . 4
6.1. Provider-Provider . . . . . . . . . . . . . . . . . . . . 4
6.1.1. Description . . . . . . . . . . . . . . . . . . . . . 4
6.1.2. Presentation of Prefix Ownership . . . . . . . . . . . 5
6.1.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 5
6.2. Sub-Provider-Sub-Provider . . . . . . . . . . . . . . . . 6
6.2.1. Description . . . . . . . . . . . . . . . . . . . . . 6
6.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Inside Access Network . . . . . . . . . . . . . . . . . . 9
6.3.1. Description . . . . . . . . . . . . . . . . . . . . . 9
6.3.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Access Network - Provider . . . . . . . . . . . . . . . . 11
6.5. End-End . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Solution Focussed on IPv6 . . . . . . . . . . . . . . . . 12
7.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 12
7.3. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.4. Multi-granularity ("Multi-Fence") solution . . . . . . . . 12
7.5. Incrementally Deployable . . . . . . . . . . . . . . . . . 13
7.6. Incomplete Deployment Still Beneficial . . . . . . . . . . 13
7.7. Loose Component Coupling . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Wu, et al. Expires August 11, 2007 [Page 2]
Internet-Draft SAVA Framework February 2007
1. 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].
2. Introduction
The lack of source IP address checking makes the Internet easy for
the attackers to spoof the source address
[I-D.sava-problem-statement]. The proposed "Source Address
Validation Architecture" is chartered to specify standardization of
methods for building effective source-address validation to ensure
that packets forwarded hold authentic source addresses.
3. Overview
The SAVA framework consists of forwording components and control
components.
4. Forwarding Component
4.1. uRPF
A reverse path forwarding check component.
4.2. Signature
A component inserts signature into the departing packet.
4.3. Verification
A component checks the signature in the received packet
5. Control Component
5.1. Generation and Distribution of Validation Rules
A component generates validation rules and distributes the rules to
other control components.
Wu, et al. Expires August 11, 2007 [Page 3]
Internet-Draft SAVA Framework February 2007
5.2. Generation and Distribution of Authentication Information
A component generates authentication information and distributes the
information to other control components.
6. Framework Granularity
We can't expect that single mechanism can solve the source address
spoofing problem in the Internet. Multiple mechanisms should coexist
and cooperate. Since the Internet is organized as a hierarchical
architecture, it is natural to consider organizing the SAVA
mechanisms in a hierarchical way, too. We suggest to organize the
SAVA mechanisms in the following three levels:
6.1. Provider-Provider
The goal of this level is to achieve that the packet transmitted in
the Internet originates from the right AS that owns the source
address of the packet. The granularity to check at this level is
address prefix.
SPM is designed to work at this level. SAVE can also be modified to
work at this level.
The inter-AS level is the most important for the SAVA architecture.
The inter-AS source address spoofing is the most difficult to handle.
6.1.1. Description
The Internet is a conglomeration of autonomous systems (AS) that
define the administrative authority and the routing policies of
different organizations[11]. From this viewpoint, Internet is a
hierarchical architecture with two levels: the first level is the
relationship between AS; the second level is the relationship inside
one AS.
For a given address prefix assigned already, there should be an AS
that owns this prefix and be responsible for this prefix.
At the inter-AS level, only the packet transmitted between different
AS is considered. The packet only transmitted inside one AS is not
considered.
Here we list the possible source address spoofing scenario at the
inter-AS level:
Wu, et al. Expires August 11, 2007 [Page 4]
Internet-Draft SAVA Framework February 2007
1. The host in one AS sends packet with spoofed source address of
another AS. This packet is sent to a destination not in the
sending AS.
The goal of the inter-AS SAVA mechanisms is to achieve:
1. The packet transmitted in the Internet should originate from the
right AS that owns the source address of the packet.
2. A packet should not originates from an AS that does not own the
source address of the packet.
3. For a packet transmitted in the Internet, it should be able to
find which AS is responsible for the packet from the source
address of the packet.
6.1.2. Presentation of Prefix Ownership
Here we discuss how to present the ownership of prefix for an AS.
Since Longest Prefix Match is applied in the current forwarding
lookup method, in the presentation of the prefix ownership we should
also notice this property. For An AS (e.g., AS-1) that owns a large
address block (e.g., a.b.0.0/16), it may assign part of its address
(e.g., a.b.c.0/24) to another AS (e.g., AS-2). Both AS-1 and AS-2
have global AS number. In this case, this small address block (i.e.,
a.b.c.0/24) is not owned by AS-1, but owned by AS-2. So for an AS to
express its own prefix, it should present not only the prefix
blocksthat owned by this AS, but also those small prefix blocks that
are not owned by this AS.
The prefix ownership of an AS can be expressed in a table. The entry
in the table can be organized as:
o Prefix: prefix address.
o Prefix length: length of the prefix.
o Flag: whether the prefix is owned by this AS. If the prefix is
owned by the AS, the flag is YES; if the prefix is not owned by
the AS, the flag is NO.
6.1.3. Discussion
Several important points should be kept in mind in the design of
inter-AS SAVA mechanisms:
1. Asymmetric routing. Asymmetric routing is not rare for the
inter-AS routing. So some methods (e.g., uRPF) by simply
Wu, et al. Expires August 11, 2007 [Page 5]
Internet-Draft SAVA Framework February 2007
reversing the forwarding table are not suitable.
2. Support for site multihoming. Many AS are created to support
site multihoming. The inter-AS SAVA mechanisms should not break
the usage of site multihoming.
3. High bandwidth. Usually the inter-AS bandwidth is high. The
inter-AS SAVA mechanisms should be high performance.
4. Incremental deployment. It's hard to ask all ASes in the
Internet to deploy some mechanism over one night, the inter-AS
SAVA mechanisms should be effective even with partial deployment.
5. Deployemnt incentive. Since organizations behind each AS have
their own different interest, the inter-AS SAVA mechanisms should
provide enough incentive for the deployment.
6. By-passing traffic. Inside a transit AS, there are by- passing
traffic and its own originated traffic. These two types of
traffic should be discriminated.
6.2. Sub-Provider-Sub-Provider
The goal of this level is to achieve that the packet in its sending
AS originates from the right sub-part of this AS which owns the
source address of the packet. The granularity to check at this level
is address prefix. Ingress filtering and uRPF can be applied at this
level.
6.2.1. Description
At the Intra-AS, we only consider how to support SAVA in the sending
AS of the packet. The packet may be sent to a destination in the
sending AS, or to a destination out of the sending AS.
To better manage the network, it is possible to further divide one AS
to some parts in a sub level. Each sub part owns part of the AS
address prefix, and be responsible for its own prefix.
The possilbe source address spoofing scenarios at intra-AS level are
as follows:
1. A host sends packet with spoofed source address of other part of
AS. This packet is sent to a destination not in the sending AS.
2. A host sends packet with spoofed source address of other part of
AS. This packet is sent to a destination in the sending AS.
Wu, et al. Expires August 11, 2007 [Page 6]
Internet-Draft SAVA Framework February 2007
3. A host sends packet with spoofed source address of other AS.
This packet is sent to a destination not in the sending AS.
While this packet is transmitted inside the sending AS, it is an
intra-AS problem; when the packet arrives at the border of the
sending AS, or the packet is transmitted not in the sending AS,
it is an inter-AS problem.
4. A host sends packet with spoofed source address of other AS.
This packet is sent to a destination in the sending AS.
The goal of the intra-AS SAVA mechanisms is to achieve:
1. In the sending AS of a packet, the packet should not have the
source address that does not belong to the sending AS.
2. In the sending AS of a packet, if the source address of the
packet belongs to the sending AS, the packet should originate
from the right sub-part of this AS which owns the source address
of the packet.
3. In the sending AS of a packet, if the source address of the
packet belongs to the sending AS, a packet should not originates
from the sub-part that does not own the source address of the
packet.
4. In the sending AS of a packet, if the source address of the
packet belongs to the sending AS, it should be able to find which
sub-part of the AS is responsible for the packet from the source
address of the packet.
The by-passing traffic in the transit AS is not considered in the
design of intra-AS SAVA mechanism.
6.2.2. Discussion
There are several good points for designing the intra-AS SAVA
mechanisms:
1. The unified control. Usually an AS is controlld by one
organization. It is easy to make a unified consideration for the
deployment of the intra-AS SAVA mechanism.
2. In the intra-AS level, SAVA mechanisms only check the source
address in the granularity of address prefix. Checking in
smaller granularity is left to do in the access network level.
3. Usually the provider assigns an address block to the customer
network and provides a link to it. In this case, it is a very
Wu, et al. Expires August 11, 2007 [Page 7]
Internet-Draft SAVA Framework February 2007
effective way for the provider to apply ingress filtering at the
provider side interface.
(preamble)
----------
| Provider |
| AS |
|a.b.0.0/16|
----------
/ | \
/ | \
/ | \
/ | \
/ | \
---------- / ---------- \ ----------
| Customer | / | Customer | \ | Customer |
| Network |--/ | Network | \--| Network |
|a.b.c.0/24| |a.b.d.0/24| |a.b.e.0/24|
---------- ---------- ----------
(postamble)
In some cases, a customer network may have more than one link to the
provider to support site multihoming. Since the address block used
by the customer network is only owner by one provider, it is still
feasible to use ingress filtering here.
(preamble)
----------
| Provider |
| AS |
|a.b.0.0/16|
----------
| |
| |
| |
| |
| |
----------
| Customer |
| Network |
|a.b.c.0/24|
----------
(postamble)If the customer network has links to more than one
providers to support site multihoming, the customer network should
have a global AS number. In this case, it is no longer an intra-AS
SAVA problem, but an inter-AS SAVA problem.
Wu, et al. Expires August 11, 2007 [Page 8]
Internet-Draft SAVA Framework February 2007
(preamble)
---------- ----------
|Provider-1| |Provider-2|
| AS | | AS |
|a.b.0.0/16| |a.d.0.0/16|
---------- ----------
\ /
\ /
\ /
\ /
\ /
----------
| Customer |
| Network |
|a.b.c.0/24|
----------
(postamble)
6.3. Inside Access Network
The goal of this level is to achieve that the packet sent from the
access network originates from the right host which owns the source
address of the packet. The source address may be assigned to the
host in a static way or a dynamic way, in a "legal" way. Some
products have provides solutions at this level, based on binding
between port and source IP address, or binding between MAC address
and source IP address.
6.3.1. Description
A number of hosts may access the Internet via the same interface of a
layer-3 gateway. The host acquires its IP address in a "legal" way,
e.g., static assigned by the administrator, or dynamic assigned by a
DHCP server. Suppose ingress filtering is deployed at this
interface. If there is no special consideration, one host can still
spoof source address by sending packet with the "legal" IP address of
other host, or even with the IP address not owned by this access
network. The goal of the access network SAVA mechanisms is to solve
the source address spoofing problem in these two scenarios.
"Access network" is a very widely used concept, and it has many
different scenarios. We just use this phrase here to indicate the
specific scenario we describe above.
Wu, et al. Expires August 11, 2007 [Page 9]
Internet-Draft SAVA Framework February 2007
(preamble)
+----+
| GW |
+----+
|
| e.g., a.b.c.0/16
+---------+--------------+
| | |
| | |
+----+ +----+ +----+
|Host| |Host| ... |Host|
+----+ +----+ +----+
(postamble)The possilbe source address spoofing scenarios at access
network level are as follows:
1. A host sends packet with spoofed source address of other host in
the same access network. This packet is sent to a destination
not in the same access network.
2. A host sends packet with spoofed source address not owned by the
access network. This packet is sent to a destination not in the
same access network. Before the packet passes through the
interface of layer-3 gateway, it is a access network level
problem.
3. A host sends packet with spoofed source address of other host in
the same access network. This packet is sent to a destination in
the same access network.
4. A host sends packet with spoofed source address not owned by the
access network. This packet is sent to a destination in the same
access network.
We classify the goal of SAVA mechanisms at access network level into
types: Loose Check scenario, and Strict Check scenario.
In the Loose Check scenario, the SAVA mechanism should support:
o The packet originating from the access network that can pass
through the layer-3 gateway should originate from the right host
that owns the source address of the packet.
In the Strict Check scenario, in additional to the requirement in the
Loose Check scenario, the SAVA mechanism should also support:
o The packet originating from the access network that can be receive
by other hosts in the same access network should originate from
the right host that owns the source address of the packet.
Wu, et al. Expires August 11, 2007 [Page 10]
Internet-Draft SAVA Framework February 2007
6.3.2. Discussion
Currently, a common way to support access network level SAVA is to
allocate each host with seperate port at a layer-2 or layer-3 switch.
(preamble)
+----+
| GW |
+----+
|
| e.g., a.b.c.0/16
+--------+
+-------| L2/L3 | ---------+
| | switch | |
| +--------+ |
| | |
+----+ +----+ +----+
|Host| |Host| ... |Host|
+----+ +----+ +----+
(postamble)With layer-3 switch, the assigned IP address is binded
with some specific port of the switch. Only the packet with the
assigned source address can be sent through the port. It can meet
the requirement of Strict Check scenario.
With layer-2 switch, the assigned IP address is binded with the MAC
address of the host, and this binding is checked by the layer-3
gateway. The layer-2 switch should support the binding between MAC
address and the port of the layer-2 switch. Thus, it is achieved the
binding between the assigned IP address and the port of the layer-2
switch. But it can only meet the requirement of Loose Check
scenario.
6.4. Access Network - Provider
6.5. End-End
6.6. Summary
Wu, et al. Expires August 11, 2007 [Page 11]
Internet-Draft SAVA Framework February 2007
(preamble)
+-------------------------------------------------------------------+
| |Scope |Granule |Possible Mechanisms |
+-------------------------------------------------------------------+
|inter-AS |between ASes |prefix |SPM, SAVE-like |
+-------------------------------------------------------------------+
|intra-AS |inside AS |prefix |ingress filtering, uRPF |
+-------------------------------------------------------------------+
|access network |access network |host addr |port/mac - addr binding |
+-------------------------------------------------------------------+
(postamble)
7. Design Goals
7.1. Solution Focussed on IPv6
Much if not all of the problem statement applies equally to IPv4 as
to IPv6. However, the decision has been taken in this effort to
focus on IPv6 only. This is because there are many changes that can
still be made to IPv6 that cannot be made to IPv4. If a solution
designed under this framework is also applicable to IPv4, or can be
modified to work with IPv4, then that is considered to be good, but
it is not a design goal.
7.2. Performance
Any solutions designed under this framework should be no more taxing
on routing and other infrastructure than the application of BCP038.
That is, modern routing equipment should be able to maintain full
line rate.
It is permissable to propose solutions that are not fully achievable
with current equipment "as-is" but would be implementable with
current generation technology, as long as alternative solutions are
available for current equipment. (See Section 6.7).
7.3. Scaling
Solutions must be capable of scaling to the size of the global
Internet.
7.4. Multi-granularity ("Multi-Fence") solution
One of the reasons why BCP has not solved the problem is that it is a
single granularity solution - it can only be applied in the access
network, or at the boundary between a stub/access network and a
Wu, et al. Expires August 11, 2007 [Page 12]
Internet-Draft SAVA Framework February 2007
transit network. A provider who applies BCP038 protects itself from
its own clients, and the rest of the Internet from its clients but it
does not protect itself from spoofed packets in the rest of the
Internet in any way.
A multi-granularity solution will allow a network to assign levels of
trust to the source addresses on packets sent from neighboring
providers as well as from its own network and attached stub networks.
7.5. Incrementally Deployable
The mechanism should show its benefit even if it is deployed only in
part of the Internet. It is impossible to deploy some mechanism all
over the Internet in one night. If there is no benefit for partial
deployment, it is hard to start the deployment.
7.6. Incomplete Deployment Still Beneficial
The mechanism should have direct benefit to the party who makes
investment on the deployment of the mechanism. Otherwise there is
not enough incentive for someone to spend money to deploy such
mechanism.
This implies two things: first, there must be immediate benefit for
incomplete deployment, and deploying the recommended solutions must
provide some protection to the entity deploying the solutions.
7.7. Loose Component Coupling
A solution that meets the above design goals will have components for
each level of granularity. It is desired that a solution under this
framework may have more than one solution at any given level of
granularity. This allows for different providers to use different
solutions, as well as allowing for evolution of new solutions as the
capabilities of equipment improve or simply as new solutions are
developed.
This requires the coupling of components at different levels of
granularity to be loose enough to allow component substitution.
8. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Wu, et al. Expires August 11, 2007 [Page 13]
Internet-Draft SAVA Framework February 2007
9. Security Considerations
10. Acknowledgements
The authors would like to acknowledge the contributors who provided
helpful inputs on earlier versions of this document. The authors
would also like to acknowledge the participants in the SAVA meetings
held in Sunnyvale, CA, USA (March 2006), Beijing, China (June 2006),
Montreal, Canada (IETF67 July 2006), and San Diego, USA (Nov. 2006).
11. References
[I-D.sava-problem-statement]
Wu, J., Bonica, R., Bi, J., Li, X., Ren, G., and M I.
Williams, "Source Address Validation Architecture (SAVA)
Problem Statemene", February 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Jianping Wu
CERNET
Network Center, Tsinghua University
Beijing 100084
China
Email: jianping@cernet.edu.cn
Jun Bi
CERNET
Network Center, Tsinghua University
Beijing 100084
China
Email: junbi@cernet.edu.cn
Wu, et al. Expires August 11, 2007 [Page 14]
Internet-Draft SAVA Framework February 2007
Gang Ren
CERNET
Network Center, Tsinghua University
Beijing 100084
China
Email: rg03@mails.tsinghua.edu.cn
Xing Li
CERNET
Network Center, Tsinghua University
Beijing 100084
China
Email: xing@cernet.edu.cn
Ronald P. Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
USA
Email: rbonica@juniper.net
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 11, 2007 [Page 15]
Internet-Draft SAVA Framework 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 11, 2007 [Page 16]