Network Working Group J. Wu
Internet-Draft J. Bi
Intended status: Experimental X. Li
Expires: April 14, 2008 G. Ren
K. Xu
Tsinghua University
M. Williams
Juniper Networks
Oct 12, 2007
SAVA Testbed and Experiences to Date
draft-wu-sava-testbed-experience-03
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 April 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Wu, et al. Expires April 14, 2008 [Page 1]
Internet-Draft SAVA Testbed Oct 2007
Abstract
Since the Internet uses destination-based packet forwarding,
malicious attacks have been launched using spoofed source addresses.
In an effort to enhance the Internet with IP source address
validation, we prototyped an implementation of the IP Source Address
Validation Architecture (SAVA) and conducted the evaluation on an
IPv6 network. This document reports our prototype implementation and
the test results, as well as the lessons and insights gained from our
experimentation.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. A Prototype SAVA Implementation . . . . . . . . . . . . . . . 5
2.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5
2.2. IP Source Address Validation in the Access Network . . . . 6
2.3. IP Source Address Validation at Intra-AS/Ingress Point . . 8
2.4. IP Source Address Validation in Inter-AS Case
(Neighboring AS) . . . . . . . . . . . . . . . . . . . . . 8
2.5. IP Source Address Validation in Inter-AS Case
(Non-Neighboring AS) . . . . . . . . . . . . . . . . . . . 11
3. SAVA Testbed . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. CNGI-CERNET2 . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. SAVA Testbed on CNGI-CERNET2 Infrastructure . . . . . . . 14
4. Test Experience and Results . . . . . . . . . . . . . . . . . 17
4.1. Test Experience . . . . . . . . . . . . . . . . . . . . . 17
4.2. Test Results . . . . . . . . . . . . . . . . . . . . . . . 17
5. Design Limitation . . . . . . . . . . . . . . . . . . . . . . 19
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Wu, et al. Expires April 14, 2008 [Page 2]
Internet-Draft SAVA Testbed Oct 2007
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Wu, et al. Expires April 14, 2008 [Page 3]
Internet-Draft SAVA Testbed Oct 2007
1. Introduction
By design the Internet forwards data packets solely based on the
destination IP address. The source IP address is not checked during
the forwarding process in most cases. This makes it easy for
malicious hosts to spoof the source address of the IP packet. We
believe that it would be useful to enable the Internet security to
enforce the validity of the source IP address for all the packets
being forwarded. .
Enforcing the source IP address validity can help us achieve the
following goals:
o The packets which carry spoofed source addresses will not be
forwarded, making it impossible to launch network attacks with
spoofed source addresses.
o The packets which hold a correct source address can be traced back
accurately. This can benefit network diagnosis, management,
accounting and applications.
As part of the effort in developing a Source Address Validation
Architecture (SAVA), we have implemented a SAVA prototype on an
operational network, a native IPv6 backbone network of the China Next
Generation Internet project, and conducted evaluation experiments.
In this document we first describe our prototype solutions and then
report our experimental results. We hope that this document can
provide useful insights to those interested in the subject, and can
serve as an initial input to future IETF effort in the same area.
In recent years there have been a number of research and engineering
efforts to design IP source address validation mechanisms, such
as[RFC2827][Park01][Li02][Brem05][Snoe01]. Our SAVA prototype
implementation was inspired by some of the schemes from the proposed
or existing solutions. The prototype implementation and experimental
results presented in this report serve only as an input, and by no
means pre-empt any solution development that may be carried out by
future IETF effort.
Wu, et al. Expires April 14, 2008 [Page 4]
Internet-Draft SAVA Testbed Oct 2007
2. A Prototype SAVA Implementation
2.1. Solution Overview
In the Internet at large, it is unrealistic to expect any single IP
source address validation mechanism to be universally supported.
Different operators and vendors may choose to deploy/develop
different mechanisms to achieve the same end, and there need to be
different mechanisms to solve the problem at different places in the
network. Furthermore, implementation bugs or configuration errors
can also render the intended implementation in-effective. Therefore
our prototype SAVA implementation is a combination of multiple
coexisting and cooperating mechanisms. More specifically, we
implement source IP address validation at three levels: access
network source address validation; intra-AS source address
validation; and inter-AS source address validation, as shown in
Figure 1.The system details can be found in[WRL2007].
__ ____ __ ____
.-'' `': .-'' `':
| | | |
| +-+----+ | Inter-AS SAV | +-+----+ |
| |Router+--+------------------+---|Router+ +
| +--.---+ | | +--.---+ |
Intra-AS | | | Intra-AS | | |
SAV | +--+---+ | SAV | +--+---+ |
| |Router| | | |Router| |
'_ +--.---+ _ '_ +--.---+ _
`'---|---''' `'---|---'''
_.--|-----. _.--|-----.
,-'' | `--. ,-'' | `--.
|'+-----------------+`| |'+-----------------+`|
| | Router | | | | Router | |
| ++----------------+ | | ++----------------+ |
Access | | | | | Access | | | | |
Network| | +------++------+ | Network| | +------++------+ |
SAV | | |Switch||Router| | SAV | | |Switch||Router| |
| | +------++------+ | | | +------++------+ |
| | | | | | | | | |
|+-+--+ +----+ +----+ | |+-+--+ +----+ +----+ |
||Host| |Host| |Host| | ||Host| |Host| |Host| |
`.----+ +----+ +----+,' `.----+ +----+ +----+,'
`--. _.-' `--. _.-'
`--------'' `--------''
Key: SAV== Source Address Validation
Figure 1: Solution Overview
It is important to enforce IP source address validity at the access
Wu, et al. Expires April 14, 2008 [Page 5]
Internet-Draft SAVA Testbed Oct 2007
network. That is, when an IP packet is sent from a host, the
routers, switches or other devices ( if you implement the functions
in a special device ) should check to make sure that the packet
carries a legally assigned source IP address. If this access network
source address validation is missing, then a host may be able to
spoof the source IP address which belongs to another local host.
We use the term "intra-AS source address validation" to mean the IP
source address validation at the attachment point of an access
network to its provider network, also called the ingress point. IP
source address validation at ingress points can enforce the source IP
address correctness at the IP prefix level, assuming the access
network owns one or more IP address blocks. This practice has been
adopted as the Internet Best-Current-Practice [RFC2827][RFC3704].
Even in the absence of the access network source address checking,
this ingress checking can still prevent the hosts within one access
network from spoofing IP addresses belonging to other networks.
In theory, everyone would do validation in the access network level
and again at the intra-AS level. In reality, some packets will get
validated and some will not get validated. As a result, the Intra-AS
validation level will also need to be able to preserve validation
status learnt from the Inter-AS validation level (see below) from
ingress to egress for transit traffic. This is a topic for further
study.
Inter-AS IP source address validation refers to mechanisms that
enforce packet source address correctness at AS boundaries . The
first two steps of source address validation utilize the network
physical connectivity of the access network and the ingress points.
Because the global Internet has a mesh topology, and because
different networks belong to different administrative authorities, IP
source address validation at Inter-AS level becomes more challenging.
Nevertheless we believe this third level of protection is necessary
to detect packets with spoofed source addresses, when the first two
levels of source address validation are missing or ineffective .
In the rest of this section we describe the specific mechanisms
implemented at each of the three levels in detail.
2.2. IP Source Address Validation in the Access Network
At the access network level, the solution will make sure the host
inside the access network could not use the source address of other
host. The host address should be legally assigned to the host in a
static way or a dynamic way. A layer-3 source address validation
device (SAVA Device) for access network (the device can be a function
inside the CPE router or a separate device) is deployed at the exit
Wu, et al. Expires April 14, 2008 [Page 6]
Internet-Draft SAVA Testbed Oct 2007
of the access network. Some source address validation agents (SAVA
Agent) are deployed inside the access network, these agents can be a
function inside the first hop router/switch that connected to hosts.
Some layer-3 protocols are designed between the host, SAVA Agent and
SAVA Device. Only a packet originating from the host that owns the
valid source address can finally pass through the SAVA Agent and SAVA
Device. Therefore, there are two parts: host-to-agent and agent-to-
device (in case that there is no agent can be deployed, the protocol
is between the host and SAVA device directly, so we denote it as
"host/agent-device part" in the following sections).
The main idea of the first-hop part (host-to-agent) is to create a
dynamic binding between a switch port and valid source IP address, or
a binding between MAC address, source IP address and switch port.
For host/agent-device part, we develop a method using source address
authentication using session key and hash digest algorithms, and
prevent replay attack by combining a sequence number method with a
timestamp method.
The host-to-agent part has three main modules: Source Address Request
Client (SARC) on the host, Source Address Validation Proxy (SAVP) on
the switch, and Source Address Management Server (SAMS). The
solution has the following basic steps:
1. The SARC on the end host sends an IP address request. The SAVP
on the switch relays this request to the SAMS and records the MAC
address and incoming port. If the address has already been
predetermined by the end host, the end host still needs to put
that address in the request message for verification by SAMS.
2. After the SAMS receives the IP address request then allocates a
source address for that SARC based on the address allocation and
management policy of the access network, it stores the allocation
of the IP address in the history database of SAMS for traceback,
then sends response message containing the allocated address to
the SARC.
3. After the SAVP on the access switch receives the response, it
binds the IP address and the former stored MAC address of the
request message with the switch port on the binding table. Then,
it forwards the issued address to SARC on the end host.
4. The access switch begins to filter packets sent from the end
host. Packets which do not conform to the tuple (IP address,
Switch Port) are discarded.
For the case that IP address was staticly assigned to the host, if
the address has been predetermined by the end host, it still needs to
Wu, et al. Expires April 14, 2008 [Page 7]
Internet-Draft SAVA Testbed Oct 2007
put it in the request datagram for acceptance from SAMS.
The host/agent-to-device part includes the following steps (the
mechanism details can be found in [XBW07]):
1. When a host wants to access the Internet, it should firstly carry
out the access authentication.
2. Then the SAVA Agent generates a session key S and sends it to the
SAVA Device via a key exchange mechanisms. The SAVA Device binds
the session key and the host's IP address.
3. When the host sends packet M to somewhere outside the access
network, the SAVA Agent needs to generate one signature for each
packet using the hash digest algorithm (e.g. MD5). Then the
signature H[M||S] is carried in a new IPv6 extension header,
named 'source address validation header'.
4. The SAVA Device uses the session key to authenticate the
signature carried in the packet so that it can validate the
source address.
5. The SAVA Device identifies the replay packets by checking whether
the sequence number of the packet is increasing within the
admission time window T (T is set up by timestamp mechanism).
6. In case there is no SAVA Agent deployed, the host is installed a
software to do the above work (exchanging session key and
inserting the signature into the packets) by the host itself.
2.3. IP Source Address Validation at Intra-AS/Ingress Point
We adopted the solution of the source address validation of IP
packets at ingress points described in [RFC2827]and[RFC3704]; the
latter describes source address validation at the ingress points of
multi-homed access networks.
2.4. IP Source Address Validation in Inter-AS Case (Neighboring AS)
Our design for the Inter-AS Source Address Validation aimed at the
following characteristics: It should cooperate among different ASes
with different administrative authorities and different interests.
It should be light-weight to support high throughput and not to
influence forwarding efficiency.
The inter-AS level of SAVA can be classified into two sub-cases:
o Two SAVA-compliant ASes exchanging traffic are directly connected;
Wu, et al. Expires April 14, 2008 [Page 8]
Internet-Draft SAVA Testbed Oct 2007
o Two SAVA-compliant ASes are separated by one or more intervening,
SAVA-non-compliant providers.
---------
| AIMS |
------|-
|
-------------- -----------|-----
| AS-4 |-------- --------| AS-1 | |------- Global
| ------ |ASBR,VE|->|ASBR,VE| ------|- |ASBR,VE|--->IPv6
| |VRGE| |-------- --------| | VRGE | |------- Network
| ------ | | -------- |
--------------- ----- -----------------
|ASBR,VE| |ASBR,VE|
--------- ---------
/ |
/ |
/ |
/ |
---------- --------
|ASBR, VE| |ASBR,VE|
--------------- -------------
| AS-2 | | AS-3 |
| ----- | | ----- |
| |VRGE| | | |VRGE| |
| ----- | | ------ |
--------------- -------------
Key: AIMS == AS-IPv6 prefix Mapping Server, VRGE == Validation Rule
Generating Engine, VE == Validating Engine, ASBR = AS Border Router,
VR==Validation Rule
Figure 2: Inter-ISP (Neighboring AS) Solution
An AS relation based mechanism is proposed for neighboring SAVA-
compliant ASes. The basic ideas of this AS-relation based mechanism
are as follows. It builds a VR table that associates each incoming
interface of the router with a set of valid source address blocks,
and then uses it to filter spoofed packets. The VR is generated from
the AS relation of neighboring SAVA-compliant ASes.
In the solution implemented on the testbed, the solution for the
validation of IPv6 prefixes is separated into three functional
modules: The Validation Rule Generating Engine (VRGE), the Validation
Engine (VE) and the the AS-IPv6 prefix Mapping Server(AIMS).
Validation rules (VR) that are generated by the VRGE are expressed as
IPv6 address prefixes.
The VRGE generates validation rules which are derived according to
Wu, et al. Expires April 14, 2008 [Page 9]
Internet-Draft SAVA Testbed Oct 2007
the table shown in figure 3, and each AS has a VRGE. The VE loads
validation rules generated by VRGE to filter packets passed between
ASes (in the case of Figure 2, from neighboring ASes into AS-1). In
the SAVA testbed, the VE is implemented as a simulated L2 device on a
Linux-based machine inserted into the data path just outside each
ASBR interface that faces a neighboring AS, but in a real-world
implementation, it would probably be implemented as a packet
filtering set on the ASBR. The AS-IPv6 prefix mapping server is also
implemented on a Linux machine and derives a mapping between IPv6
prefix and the AS number of that prefix.
---------------------------------------------------------------------------
| \Export| Own | Customer's| Sibling's | Provider's | Peer's |
|To \ | Address | Address | Address | Address | Address |
|-----\-------------------------------------------------------------------|
| Provider | Y | Y | Y | | |
|-------------------------------------------------------------------------|
| Customer | Y | Y | Y | Y | Y |
|-------------------------------------------------------------------------|
| Peer | Y | Y | Y | | |
|-------------------------------------------------------------------------|
| Sibling | Y | Y | Y | Y | Y |
---------------------------------------------------------------------------
Figure 3: AS-Relation Based Inter-AS Filtering
Different ASes exchange and transmit VR information using the AS-
Relation Based Export Rules in the VRGE. As per Figure 3, an AS
exports the address prefixes of its own, its customers, its
providers, its siblings and its peers to its customers and siblings
as valid prefixes, while it only exports the address prefixes of its
own, its customers and its siblings to its providers and peers as
valid prefixes. With the support of AS Number to IPv6 Address
Mapping service, only AS numbers of valid address prefixes are
transferred between ASes and the AS number is mapped to address
prefixes at the VRGE. Only changes of AS relation and changes of IP
address prefixes belonging to an AS require the generation of VR
updates.
The procedure's principle steps are as follows (Seeing from AS-1 in
Figure 2):
1. When the VRGE has initialized, it reads its neighboring SAVA-
compliant AS table and establishes connections to all the VEs in
its own AS.
2. The VRGE initiates a VR renewal. According to its exporting
table, it sends its own originated VR to VRGEs of neighboring
ASes. In this process, VR are expressed as AS numbers.
Wu, et al. Expires April 14, 2008 [Page 10]
Internet-Draft SAVA Testbed Oct 2007
3. When a VRGE receives the new VR from its neighbor, it uses its
own export table to decide whether it should accept the VR and,
if it accepts a VR, whether or not it should re-export the VR to
other neighboring ASes.
4. If the VRGE accepts a VR, it uses the AIMS to transform AS-
expressed VR into IPv6 prefix-expressed VR.
5. The VRGE pushes the VR to all the VEs in its AS.
The VEs use these prefix-based VRs to validate the source IP
addresses of incoming packets.
2.5. IP Source Address Validation in Inter-AS Case (Non-Neighboring AS)
In the case where two ASes do not exchange packets directly, it is
not possible to deploy a solution like that in the previous section.
However, it is highly desirable for non-neighboring ISPs to be able
to form a trust alliance such that packets leaving one AS will be
recognized by the other and inherit the validation status they
possessed on leaving the first AS. There is more than one way to do
this. For the SAVA experiments to date, a signature method has been
used. This solution is inspired by the work [Brem05]. The basic
ideas of this light-weight signature based mechanism are as follows.
For every two SAVA-compliant ASes, there is a pair of unique
temporary signatures. All SAVA-compliant ASes form SAVA AS Alliance.
When a packet is leaving its own AS, if the destination IP address
belongs to an AS in the SAVA AS Alliance, the edge router of this AS
looks up for the signature based on the destination AS number, and
tags a signature to the packet. When a packet is arriving at the
destination AS, if the source address of the packet belongs to an AS
in the SAVA AS Alliance, the edge router of the destination AS looks
up for the signature based on the source AS number, and the signature
carried in the packet is verified and removed. This particular
method uses a light-weight signature. For every packet forwarded,
the signature can be put in an IPv6 hop-by-hop extension header. We
can use a 128-bit shared random number as the signature, instead of
using cryptographic method to generate the signature.
Wu, et al. Expires April 14, 2008 [Page 11]
Internet-Draft SAVA Testbed Oct 2007
+-----+
.-----------------+.REG |-----------------.
| +-----+ |
| |
,-----+-------- ,------+-------
,' `| `. ,' ` | `.
/ | \ / | \
/ | \ / | \
; +--'--+ +----+ +----+ +-----+ ;
| | ASC +------+ASBR| |ASBR+-----+ ASC | |
: +--.--+ +----+` +----+ +--+--+ :
\ |__________________________________________| /
\ / \ /
`. ,' `. ,'
'-------------' '-------------'
AS-1 AS-2
KEY: REG == Registration Server, ASC == AS Control Server, ASBR == AS
Border Router.
Figure 4: Inter-AS (Non-neighboring AS) Solution
There are three major components in the system: the Registration
Server (REG), the AS Control Server (ASC), and the AS Border Router
(ASBR).
The Registration Server is the "center" of the trust alliance (TA) .
It maintains a member list for the TA. It performs two major
functions:
o Processes requests from the AS Control Server, to get the member
list for the TA.
o When the member list is changed, notifies each AS Control Server.
Each AS deploying the method has an AS Control Server. The AS
Control Server has three major functions:
o Communicates with the Registration Server, to get the up-to-date
member list of TA.
o Communicates with the AS Control Server in other member AS in the
TA, to exchange updates of prefix ownership information, and to
exchange signatures.
o Communicates with all AS Border routers of the local AS, to
configure the processing component on the AS Border routers.
The AS Border Router does the work of adding signature to the packet
Wu, et al. Expires April 14, 2008 [Page 12]
Internet-Draft SAVA Testbed Oct 2007
at the sending AS, and the work of verifying and removing the
signature at the destination AS.
In the design of this system, in order to decrease the burden on the
REG, most of the control traffic happens between ASCs.
The signature needs to be changed frequently, Although the overhead
of maintaining and exchanging signatures between AS pairs is not
O(N^2), but O(N), the traffic and processing overhead increase as the
number of ASes increases. Therefore an automatic signature changing
method is utilized in this solution.
Wu, et al. Expires April 14, 2008 [Page 13]
Internet-Draft SAVA Testbed Oct 2007
3. SAVA Testbed
3.1. CNGI-CERNET2
The prototypes of our solutions for SAVA are implemented and tested
on CNGI-CERNET2. CNGI-CERNET2 is one of the China Next Generation
Internet (CNGI) backbones. CNGI-CERNET2 connects 25 core nodes
distributed in 20 cities in China at speeds of 2.5-10 Gb/s. The
CNGI-CERNET2 backbones are IPv6-only networks, not a mixed IPv4/IPv6
infrastructure. The CNGI-CERNET2 backbones, CNGI-CERNET2 CPNs, and
CNGI-6IX all have globally unique AS numbers. Thus a multi-AS
testbed environment is provided.
3.2. SAVA Testbed on CNGI-CERNET2 Infrastructure
It is intended that eventually the SAVA testbed will be implemented
directly on the CNGI-CERNET2 backbone, but in the early stages the
testbed has been implemented across 12 universities connected to
CNGI-CERNET2. This is because first, some of the algorithms need to
be implemented in the testbed routers themselves and to date they
have not been implemented on any of the commercial routers forming
the CNGI-CERNET2 backbone. Second, since CNGI-CERNET2 is a
operational backbone, any new protocols and networking techniques
need to be tested in a non- disruptive way.
Wu, et al. Expires April 14, 2008 [Page 14]
Internet-Draft SAVA Testbed Oct 2007
__
,' \ _,...._
,' \____---------------+ ,'Beijing`.
/ \ | Inter-AS SAV |-----| Univ |
+---------------+ | | +---------------+ `-._____,'
| Inter-AS SAV +-----| |
+------.--------+ | CNGI- | _,...._
| | CERNET2 |__---------------+ ,Northeast`.
| | | |Inter-AS SAV |-----| Univ |
Tsinghua|University | Backbone| +---------------+ `-._____,'
,,-|-._ | |
,' | `. | |
,'+---------+\ | |
| |Intra-AS | | | | ...
| | SAV | | | |
| +---------+ | | |
| | | | | _,...._
| +---------+ | | |__---------------+ ,Chongqing`.
| | Access | | | | |Inter-AS SAV |-----|Univ |
| | Network | | | | +---------------+ `-._____,'
| | SAV | | | |
\ +---------+.' \ .'
\ ,' \ |
`. ,' \ /
``---' -_,'
KEY: SAV=Source Address Validation
Figure 5: CNGI-CERNET2 SAVA Testbed
Notwithstanding the aforementioned restrictions on the early testbed,
the testbed is fully capable of functional testing of solutions for
all parts of the SAVA solutions. Namely, it is possible to test
procedures for ensuring the validity of IPv6 source addresses in the
access network and in packets sent from the access network to an IPv6
service provider, packets sent within one service provider's network,
packets sent between neighboring service providers and packets sent
between service providers separated by an intervening transit
network.
The testbed is distributed across 12 universities connected to CNGI-
CERNET2, namely Tsinghua University, Beijing University, Beijing
University of Post and Telecommunications, Shanghai Jiaotong
University, Huazhong University of Science and Technology in Wuhan,
Southeast University in Nanjing, and South China University of
Technology in Guangzhou, Northeast University in Shenyang, Xi'an
Jiaotong University, Shandong University in Jinan, University of
Electronic Science and Technology of China in Chengdu and Chongqing
University.
Wu, et al. Expires April 14, 2008 [Page 15]
Internet-Draft SAVA Testbed Oct 2007
Each of the university installations is connected to the CNGI-CERNET2
backbone through a set of inter-AS Source Address Validation
prototype equipment and traffic monitoring equipment for test result
display.
Of the installations, the installation at Tsinghua University is the
most fully-featured, with inter-AS, intra-AS and access network level
validation all able to be tested. In addition, a suite of
applications that could be subject to spoofing attacks or which can
be subverted to carry out spoofing attacks are installed on a variety
of servers.
Wu, et al. Expires April 14, 2008 [Page 16]
Internet-Draft SAVA Testbed Oct 2007
4. Test Experience and Results
The solutions outlined in section 2 have been implemented on the
testbed described in section 3. Successful testing of all solutions
has been carried out, as detailed in the following sections.
4.1. Test Experience
We have test in Tsinghua University and tests between Tsinghua
University and other universities. We have Inter-AS (non-neighboring
AS) SAVA solution test, Inter-AS (neighboring AS) SAVA solution test,
Intra-AS SAVA solution test, and Access Network SAVA solution test.
For each one of the test scenarios, we have tested many cases.
Taking Inter-AS (non-neighboring AS) SAVA solution test as an
example, we classified the test cases into three classes: normal
class, dynamic class and anti-spoofing class.
1. For normal class, there are three cases: Adding Signature Test,
Removing Signature Test and Forwarding packets with valid source
address.
2. For dynamic class, there are four cases: Updating the signature
between ASes, The protection for newly joined member AS, Adding
address space and Deleting address space.
3. For anti-spoofing class, there is one case: Filtering of packets
with forged IP address.
As is shown in Fig.5, we have "multiple-fence" design for our SAVA
testbed. If source address validation is deployed in the access
network, we can get a host granularity validation. If source address
validation is deployed at intra-AS level, we can guarantee that the
packets sent from this point have a correct IP prefix. If source
address validation is deployed at inter-AS level, we can guarantee
that the packets sent from this point are from a correct AS.
4.2. Test Results
1. The test results are consistent with the expected ones. For an
AS which has fully-featured SAVA deployment with inter-AS,
intra-AS and access network level validation, packets that do not
hold an authenticated source address will not be forwarded in
network. As a result, it is not possible to launch network
attacks with spoofed source addresses. Moreover, the traffic in
the network can be traced back accurately.
Wu, et al. Expires April 14, 2008 [Page 17]
Internet-Draft SAVA Testbed Oct 2007
2. For the Inter-AS (non-neighboring AS) SAVA solution, during the
period of signature update, the old and the new signature are
both valid for source address validation, thus there are no
packet loss.
3. For the Inter-AS (non-neighboring AS) SAVA solution, the
validation function is implemented in software on a device
running Linux, which simulates the source address validation
functions of a router line card interface. It is a layer-two
device because it has to be transparent to router interface,
During the test, If the devices were connected directly, it could
achieve a normal line rate forwarding. If the devices were
connected with routers from another vendor, it could only achieve
a very limited line speed. The reason is that the signatures are
added on the IPv6 hop-by-hop option header and the network
devices from other vendors handled the hop-by-hop options just by
software.
Wu, et al. Expires April 14, 2008 [Page 18]
Internet-Draft SAVA Testbed Oct 2007
5. Design Limitation
There are several design limitations for the solutions deployed in
CNGI-CERNET2 testbed.
1. For the Inter-AS (non-neighboring AS) SAVA solution, the
difficulty for guessing the signature between two AS members was
discussed in [Brem05]. It is relatively difficult and we can
increase the difficulty of guess by increasing the length of the
signature. In current CNGI-CERNET2 SAVA testbed, a 128-bit
signature is designed in IPv6 hop-by-hop option header. The size
of the packets increases with the signatures. Because this IPv6
hop-by-hop option has to be looked at by all intervening routers,
it still needs further discussion whether the IPv6 hop-by-hop
option is the right tool for the task. Although the overhead is
relatively low, the addition of the option and the calculation of
the signature can consume valuable resources on the forwarding
path.
2. The Inter-AS (neighboring AS) SAVA solution is based on AS
relation, thus it can not synchronized with the dynamics of route
changes very quickly.
3. The first hop solution in access network needs to be widely
deployed in the access network switches. For the environment
where source address validation is not deployed in the access
network, because we have a "multiple-fence" design for SAVA, we
can still get a source address validation by the SAVA Device at
the exit of the access network. Currently we use an
authentication based method for host/agent-to-device part. The
performance of current solution also needs to be further studied.
4. Given that a large fraction of current denial-of-service attacks
are employing legitimate IP addresses belonging to botnet
clients, even universal deployment of better source address
validation techniques would be unable to prevent these attacks.
However, tracing these attacks would be easier given that there
would be more reliance on the validity of source address.
Wu, et al. Expires April 14, 2008 [Page 19]
Internet-Draft SAVA Testbed Oct 2007
6. Conclusion
Several conclusions can be made from the test experience and results.
It is possible to devise a loosely-coupled, and "multiple-fence"
design for SAVA. This provides for different granularities of
authenticity of source IP addresses. It also allows for different
providers to use different solutions, and the coupling of components
at different levels of granularity of authenticity can be loose
enough to allow component substitution.
Incremental deployment is another design principle for SAVA. The
tests have demonstrated that benefit is derived even when deployment
is incomplete, which gives providers an incentive to be early
adopters of the framework. Some DiffServ mechanism could also be
considered. That is, traffic from SAVA-compliant ASes could be given
a higher priority, especially when attacks happening.
Access network source address validation is an important part of SAVA
to achieve an authenticity of host IP granularity. There are
multiple access cases: local subnet in enterprise networks,
residential broadband, and wireless mobile, etc. For enterprise
networks, there are multiple solutions from the research and
engineering community. Focusing on the appropriate framework and
solutions for access network source address validation could be a
valuable initial step for solving the source address spoofing problem
in IETF.
SAVA must be capable of scaling to the size of the global Internet.
The scalability of SAVA still needs further consideration. CNGI-
CERNET2 testbed merely provides an initial testbed for SAVA. To
study the scalabity of the current solutions, we need to extend the
scale of the testbed.
Wu, et al. Expires April 14, 2008 [Page 20]
Internet-Draft SAVA Testbed Oct 2007
7. 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 April 14, 2008 [Page 21]
Internet-Draft SAVA Testbed Oct 2007
8. Security Considerations
The purpose of the draft is to report experimental results. The
security considerations of the solution mechanisms of testbed are not
mentioned in this document.
Wu, et al. Expires April 14, 2008 [Page 22]
Internet-Draft SAVA Testbed Oct 2007
9. Acknowledgements
The authors would like to thank Jari Arkko and Lixia Zhang for their
detailed review comments on this draft, and thank Paul Ferguson and
Ron Bonica for their valuable advices on the solution development and
the testbed implementation.
Wu, et al. Expires April 14, 2008 [Page 23]
Internet-Draft SAVA Testbed Oct 2007
10. References
10.1. Normative References
[RFC2827] Paul, F. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, 2004.
10.2. Informative References
[Brem05] Bremler-Barr, A. and H. Levy, "Spoofing Prevention
Method", INFOCOM 2005.
[Li02] Li,, J., Mirkovic, J., Wang, M., Reiher, P., and L.
Zhang, "SAVE: Source Address Validity Enforcement
Protocol", INFOCOM 2002.
[Park01] Park, K. and H. Lee, "On the effectiveness of route-based
packet filtering for distributed DoS attack prevention in
power-law internets", SIGCOMM 2001.
[Snoe01] Snoeren, A., Partridge, C., Sanchez, L., and C.
Jones......, "A Hash-based IP traceback", SIGCOMM 2001.
[WRL2007] Wu, J., Ren, G., and X. Li, "Source Address Validation:
Architecture and Protocol Design", ICNP 2007.
[XBW07] Xie, L., Bi, J., and J. Wu, "An Authentication based
Source Address Spoofing Prevention Method Deployed in IPv6
Edge Network", ICCS 2007.
Wu, et al. Expires April 14, 2008 [Page 24]
Internet-Draft SAVA Testbed Oct 2007
Authors' Addresses
Jianping Wu
Tsinghua University
Computer Science, Tsinghua University
Beijing 100084
China
Email: jianping@cernet.edu.cn
Jun Bi
Tsinghua University
Network Research Center, Tsinghua University
Beijing 100084
China
Email: junbi@cernet.edu.cn
Xing Li
Tsinghua University
Electronic Engineering, Tsinghua University
Beijing 100084
China
Email: xing@cernet.edu.cn
Gang Ren
Tsinghua University
Computer Science, Tsinghua University
Beijing 100084
China
Email: rg03@mails.tsinghua.edu.cn
Ke Xu
Tsinghua University
Computer Science, Tsinghua University
Beijing 100084
China
Email: xuke@csnet1.cs.tsinghua.edu.cn
Wu, et al. Expires April 14, 2008 [Page 25]
Internet-Draft SAVA Testbed Oct 2007
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 April 14, 2008 [Page 26]
Internet-Draft SAVA Testbed Oct 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 April 14, 2008 [Page 27]
