Network Working Group J. Wu
Internet-Draft J. Bi
Intended status: Experimental X. Li
Expires: November 14, 2008 G. Ren
K. Xu
Tsinghua University
M. Williams
Juniper Networks
May 13, 2008
SAVA Testbed and Experiences to Date
draft-wu-sava-testbed-experience-05
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 November 14, 2008.
Wu, et al. Expires November 14, 2008 [Page 1]
Internet-Draft SAVA Testbed May 2008
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) [WRL2007]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 . . . . 7
2.3. IP Source Address Validation at Intra-AS/Ingress Point . . 10
2.4. IP Source Address Validation in Inter-AS Case
(Neighboring AS) . . . . . . . . . . . . . . . . . . . . . 10
2.5. IP Source Address Validation in Inter-AS Case
(Non-Neighboring AS) . . . . . . . . . . . . . . . . . . . 13
3. SAVA Testbed . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. CNGI-CERNET2 . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. SAVA Testbed on CNGI-CERNET2 Infrastructure . . . . . . . 17
4. Test Experience and Results . . . . . . . . . . . . . . . . . 20
4.1. Test Scenarios . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Test Results . . . . . . . . . . . . . . . . . . . . . . . 20
5. Limitations and Issues . . . . . . . . . . . . . . . . . . . . 22
5.1. General Issues . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Security Issues . . . . . . . . . . . . . . . . . . . . . 23
5.3. Protocol Details . . . . . . . . . . . . . . . . . . . . . 23
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
Wu, et al. Expires November 14, 2008 [Page 2]
Internet-Draft SAVA Testbed May 2008
10.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 32
Wu, et al. Expires November 14, 2008 [Page 3]
Internet-Draft SAVA Testbed May 2008
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 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 and
deployed the prototype in 12 ASes in an operational network, as part
of China Next Gerneration Internet Project. We 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.
Indeed, the presented solutions are experimental approaches and have
a number of limitations as discussed in sections 5 and 6.
Wu, et al. Expires November 14, 2008 [Page 4]
Internet-Draft SAVA Testbed May 2008
2. A Prototype SAVA Implementation
2.1. Solution Overview
A multiple-fence solution is proposed in this document. The reasons
are mentioned as follow. 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].
Wu, et al. Expires November 14, 2008 [Page 5]
Internet-Draft SAVA Testbed May 2008
__ ____ __ ____
.-'' `': .-'' `':
| | | |
| +-+----+ | 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
network. That is, when an IP packet is sent from a host, the
routers, switches or other devices should check to make sure that the
packet carries a valid 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. The
Internet Best-Current-Practice [RFC2827] and [RFC3704] can be used in
access network when only one host is directly attached to one
interface of the router, but which is not the normal case in an
access network.
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] and
Wu, et al. Expires November 14, 2008 [Page 6]
Internet-Draft SAVA Testbed May 2008
[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 at 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
different levels provide additional layers of defense.
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 cannot use the source address of another
host. The host address should be a valid address assigned to the
host statically or dynamically. The solution implemented in the
experiment provides such a function for Ethernet networks. A layer-3
source address validation device (SAVA Device) for the access network
(the device can be a function inside the CPE router or a separate
device) is deployed at the exit of the access network. Source
address validation agents (SAVA Agents) are deployed inside the
access network. (In fact these agents could be a function inside the
first hop router/switch connected to the hosts.) A set of protocols
was designed for communication between the host, SAVA Agent and SAVA
Device. Only a packet originating from the host that was assigned
that particular source address may pass through the SAVA Agent and
SAVA Device.
Two possible deployment variants exist. In one variant an agent is
mandatory and each host is attached to the agent on a dedicated
physical port. In another variant hosts are required to perform
network access authentication and generate key material needed to
protect each packet. In this second variant the agent is optional.
Wu, et al. Expires November 14, 2008 [Page 7]
Internet-Draft SAVA Testbed May 2008
The key function of the first variant 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. In the
prototype, this is established by having hosts employ a new address
configuration protocol that the switch is capable of tracking.
Note: In a production environment the approach in the prototype would
not be sufficient due to reasons discussed in Section 5.
In this variant, there are three main participants: Source Address
Request Client (SARC) on the host, Source Address Validation Proxy
(SAVP) on the switch, and Source Address Management Server (SAMS). as
shown inFigure 2.The solution follows the basic steps below:
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.
Wu, et al. Expires November 14, 2008 [Page 8]
Internet-Draft SAVA Testbed May 2008
----------------
| SERVER |
| ------- |
| | SAMS | |
| -------- |
-----------------
|
|
----------------
| SWITCH |
| ------- |
| | SAVP | |
| -------- |
-----------------
|
|
----------------
| END HOST |
| ------- |
| | SARC | |
| -------- |
-----------------
Key: SARC == Source Address Request Client , SAVP == Source Address
Validation Proxy, SAMS== Source Address Management Server
Figure 2: Binding Based IP Source Address Validation in the Access
Network
The main idea of the second variant is to employ key material from
network access authentication for some additional validation process.
A session key is derived for each host connecting to the network, and
each packet sent by the host has cryptographic protection that
employs this session key. Having established which host the packet
comes from, it becomes again possible to track that the addresses
allocated to the host and used by the host match. The mechanism
details can be found in [XBW07], but the the process follows these
basic steps:
1. When a host wants to establish connectivity, it first needs to
perform network access authentication.
2. The network access devices provide the SAVA Agent (often co-
located) a session key S. This key is further distributed to the
SAVA Device. 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, either the host or the SAVA Agent needs to generate a
Wu, et al. Expires November 14, 2008 [Page 9]
Internet-Draft SAVA Testbed May 2008
message authentication code for each using key S and packet M. In
the prototype, the message authentication code is carried in an
experimental IPv6 extension 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.
In our testbed, we implemented and test both solutions. The switches
based solution has better performance but the old switches in the
access network need to be upgraded (usually the number of switches in
an access network is a large amount) . The signature based solution
can be deployed between host and the exit router, but it has some
extra cost to inserting and validating the signature.
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;
o Two SAVA-compliant ASes are separated by one or more intervening,
SAVA-non-compliant providers.
Wu, et al. Expires November 14, 2008 [Page 10]
Internet-Draft SAVA Testbed May 2008
---------
| 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 3: Inter-ISP (Neighboring AS) Solution
Two ASes that exchange traffic have a customer-to-provider, provider-
to-customer,peer-to-peer, or sibling-to-sibling relationship. In a
customer-to-provider or provider-to-customer relationship, the
customer typically belongs to a smaller administrative domain that
pays a larger administrative domain for access to the rest of
Internet. The provider is an AS that belongs to the larger
administrative domain. In a peer-to-peer relationship, the two peers
typically belong to administrative domains of comparable size and
find it mutually advantageous to exchange traffic between their
respective customers. Two ASes have a sibling-to-sibling
relationship if they belong to the same administrative domain or to
the administrative domains that have a mutual-transit agreement.
An AS relation based mechanism is used 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,
Wu, et al. Expires November 14, 2008 [Page 11]
Internet-Draft SAVA Testbed May 2008
and then uses it to filter spoofed packets.
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
the table shown in figure 4, 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 3, 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 4: 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 4, 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.
Wu, et al. Expires November 14, 2008 [Page 12]
Internet-Draft SAVA Testbed May 2008
The procedure's principle steps are as follows (Seeing from AS-1 in
Figure 3):
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.
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 authentication tag method
has been used. This solution is inspired by the work [Brem05]. The
key elements of this light-weight authentication tag based mechanism
are as follows: For each pair of SAVA-compliant ASes, there is a pair
of unique temporary authentication tags. All SAVA-compliant ASes
together form a 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 authentication
tag based on the destination AS number, and tags a authentication tag
to the packet. When a packet arrives at the destination AS, if the
source address of the packet belongs to an AS in the SAVA AS
Alliance, so the edge router of the destination AS searches its table
for the authentication tag using the source AS number as the key and
the authentication tag carried in the packet is verified and removed.
This particular method uses a light-weight authentication tag. For
every packet forwarded, the authentication tag can be put in an IPv6
Wu, et al. Expires November 14, 2008 [Page 13]
Internet-Draft SAVA Testbed May 2008
hop-by-hop extension header. It is reasonable to use a 128-bit
shared random number as the authentication tag to save the processing
overhead of using a cryptographic method to generate the
authentication tag.
The benefit of this scheme compared to merely turning on local
address validation such as RFC 2827 is as follows. When local
address validation is employed within a group of networks, they can
be assured that their networks do not send spoofed packets. However,
other networks may still do this. With the above scheme, however,
this capability is reduced. If someone outside the alliance spoofs a
packet using a source address from someone within the alliance, the
members of the alliance refuse to accept such a packet.
+-----+
.-----------------+.REG |-----------------.
| +-----+ |
| |
,-----+-------- ,------+-------
,' `| `. ,' ` | `.
/ | \ / | \
/ | \ / | \
; +--'--+ +----+ +----+ +-----+ ;
| | ASC +------+ASBR| |ASBR+-----+ ASC | |
: +--.--+ +----+` +----+ +--+--+ :
\ |__________________________________________| /
\ / \ /
`. ,' `. ,'
'-------------' '-------------'
AS-1 AS-2
KEY: REG == Registration Server, ASC == AS Control Server, ASBR == AS
Border Router.
Figure 5: 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). As shown in Figure 5.
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
Wu, et al. Expires November 14, 2008 [Page 14]
Internet-Draft SAVA Testbed May 2008
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 authentication tags.
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 authentication tag to
the packet at the sending AS, and the work of verifying and removing
the authentication tag 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 authentication tag needs to be changed frequently, Although the
overhead of maintaining and exchanging authentication tags 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
authentication tag changing method is utilized in this solution.In
this method, each peers run the same algorithm to automatically
generate an authentication tag sequence. Then the authentication tag
in packets can be changed automatically in a high frequency. To
enhance the security, a seed is used for the algorithm to generate
different authentication tag sequence against guessing. Then the
peers only need to negotiate and change the seed in a very low
frequency. Therefore, it lowered the overhead of frequently
negotiating and changing authentication tag and somehow enhanced
security.
Since the authentication tag is put in an IPv6 hop-by-hop extension
header, the MTU issues should be considered. Currently we have two
solutions to this problem. Both of the solutions are not so perfect,
but they are feasible. One possible way is to set the MTU at the AER
to be 1280, which is the minimum MTU for the IPv6. Thus there should
be no ICMP "Packet Too Big" message received from the down-stream
gateways. The disadvantage of this solution is that it doesn't make
good use of the available MTU. The other possible way is to let AER
catch all coming ICMP "Packet Too Big" message", and decrease the
value in the MTU area before forwarding it into the AS. The
advantage of this solution is that it can make good use of the
available MTU. But such processing of ICMP packet at AER may become
a destination of DoS attack.
Wu, et al. Expires November 14, 2008 [Page 15]
Internet-Draft SAVA Testbed May 2008
Because the authentication tag is validated at the border router of
destination AS, not destination host, the destination options header
is not chosen to carry the authentication tag.
Authentication tag management is a very important issue. Our work
focused on two points: tag negotiation and tag switching. The tag
negotiation happens between the ACS of a pair of ASes in the SAVA AS
Alliance. Considering the issue of synchronization and the incentive
of enabling SAVA, receiver-driven tag negotiation is suggested. It
gives more decision power to receiver AS instead of sender AS. With
receiver-driven scheme, the receiver AS can decide the policies of
tag management. The packets tagged with old authentication tag
should not be allowed infinitely. After having negotiated the new
tag, the old tag should be set to be invalid after a period of time.
The length of this period is a parameter which will control how long
the old tag will be invalid after the new tag has been used.
Currently we use five seconds.
The trust alliance is established dynamically (join and quit), but in
this testbed we need to offline confirm the initial trust among
alliance members.
Wu, et al. Expires November 14, 2008 [Page 16]
Internet-Draft SAVA Testbed May 2008
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. Only Some CPNs are dual stacks. 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 November 14, 2008 [Page 17]
Internet-Draft SAVA Testbed May 2008
__
,' \ _,...._
,' \____---------------+ ,'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 6: CNGI-CERNET2 SAVA Testbed
In any case, the testbed is fully capable of functional testing of
solutions for all parts of the SAVA solution. This includes testing
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. As shown in Figure 6.
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.
Each university deployed one AS. Six universities deployed all
parts, and are most fully-featured, with inter-AS, intra-AS and
Wu, et al. Expires November 14, 2008 [Page 18]
Internet-Draft SAVA Testbed May 2008
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. Two solutions for access network deployed.
Wu, et al. Expires November 14, 2008 [Page 19]
Internet-Draft SAVA Testbed May 2008
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 Scenarios
For each 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 authentication
tag Test, Removing authentication tag Test and Forwarding packets
with valid source address.
2. For dynamic class, there are four cases: Updating the
authentication tag between ASes, The protection for a 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.6, 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 the 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.
2. For the Inter-AS (non-neighboring AS) SAVA solution, during the
period of authentication tag update, the old and the new
authentication tag are both valid for source address validation,
thus there is no packet loss.
Wu, et al. Expires November 14, 2008 [Page 20]
Internet-Draft SAVA Testbed May 2008
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 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 authentication tags are added
on the IPv6 hop-by-hop option header and many current routers can
handle the hop-by-hop options only at a limited rate.
Wu, et al. Expires November 14, 2008 [Page 21]
Internet-Draft SAVA Testbed May 2008
5. Limitations and Issues
There are several issues both within this overall problem area and
with the particular approach taken in the experiment.
5.1. General Issues
There is a long standing debate about whether the lack of universal
deployment of source address validation is a technical issue that
needs a technical solution, or if mere further deployment of existing
tools (such as RFC 2827) would be a more cost effective way to
improve the situation. Further deployment efforts of this tool have
proved to be slow, however. Some of solutions prototyped in this
experiment allow a group of network operators to have additional
protection for their networks while waiting for universal deployment
of simpler tools in the rest of the Internet. This allows them to
prevent spoofing attacks that the simple tools alone would not be
able to prevent, even if already deployed within the group.
Similarly, since 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.
There is also a question about the right placement of the source
address validation checks. The simplest model is placing the checks
on the border of a network. Such RFC 2827-style checks are more
widely deployed than full checks ensuring that all addresses within
the network are correct. It can be argued that it is sufficient to
provide such a coarse granularity checks, because this makes it at
least possible to find the responsible network administrators.
However, depending on the type of a network in question, those
administrators may or may not find it easy to track the specific
offending machines or users. It is obviously required that the
administrators have a way to trace offending equipment or users --
even if the network does not block spoofed packets in real-time.
New technology for address validation would also face a number of
deployment barriers. For instance, all current technology can be
locally and independently applied. A system that requires global
operation (such as the Inter-AS validation mechanism) would require
significant coordination, deployment synchronization, configuration,
key setup, and other issues, given the number of ASes.
Similarly, deploying host-based access network address validation
mechanisms requires host changes, and can generally be done only when
Wu, et al. Expires November 14, 2008 [Page 22]
Internet-Draft SAVA Testbed May 2008
the network owners are in control of all hosts. Even then,
availability of the host changes for all types of products and
platforms would likely prevent universal deployment even within a
single network.
There may be also be significant costs involved in some of these
solutions. For instance, in an environment where access network
authentication is normally not required, employing an authentication-
based access network address validation would require deployment of
equipment capable of this authentication as well as credentials
distribution for all devices. Such undertaking is typically only
initiated after careful evaluation of the costs and benefits
involved.
Finally, all the presented solutions have issues in situations that
go beyond a simple model of a host connecting to a network via the
same single interface at all times. Multihoming, failover and some
forms of mobility or wireless solutions may collide with the
requirements of source address validation. In general, dynamic
changes to the attachment of hosts and topology of the routing
infrastructure is something that would have to be handled in
production environment.
5.2. Security Issues
The security vs. scalability of the authentication tags in the
Inter-AS (non-neighboring AS) SAVA solution presents a difficult
tradeoff. Some analysis about the difficulty of guessing the
authentication tag between two AS members was discussed in [Brem05].
It is relatively difficult, even with using a random number as a
"authentication tag". The difficulty of guessing can be increased by
increasing the length of the authentication tag.
In any case, the random number approach is definitely vulnerable to
attackers who are on the path between the two ASes.
On the other hand, using an actual cryptographic hash in the packets
will cause a significant increase in the amount of effort needed to
forward a packet. In general, addition of the option and the
calculation of the authentication tag consumes valuable resources on
the forwarding path. This resource usage comes on top of everything
else that modern routers need to do at ever increasing line speeds.
It is far from clear that costs are worth the benefits.
5.3. Protocol Details
In current CNGI-CERNET2 SAVA testbed, a 128-bit authentication tag is
placed in IPv6 a new hop-by-hop option header. The size of the
Wu, et al. Expires November 14, 2008 [Page 23]
Internet-Draft SAVA Testbed May 2008
packets increases with the authentication tags. This by itself is
expected to be acceptable, if the network administrator feels that
the additional protection is needed. The size increases may result
in MTU issue and we found a way to resolve it in the testbed. Given
the choice to use an IPv6 hop-by-hop option has to be looked at by
all intervening routers. While in theory this should pose no
concern, the test results show that many current routers handle hop-
by-hop options with a much reduced throughput compared to normal
traffic.
The Inter-AS (neighboring AS) SAVA solution is based on AS relation,
thus it may not synchronize with the dynamics of route changes very
quickly and cause false positive. Currently CNGI-CERNET2 is a
relatively stable network and this method just works well in the
testbed. We will furtherly study the impact on false positive in an
unstable network.
The access network address validation solution is merely one option
among many. Solutions appear to depend highly on the chosen link
technology and network architecture. For instance, source address
validation on point-to-point links is easy and has generally been
supported by implementations for years. Validation in a shared
networks has been more problematic, but is increasing in importance
given the use Ethernet technology across administrative boundaries
(such as in DSL). In any case, the prototyped solution has a number
of limitations, including the decision to use a new address
configuration protocol. In a production environment a solution which
is suitable for all IPv6 address assignment mechanisms would be
needed..
Wu, et al. Expires November 14, 2008 [Page 24]
Internet-Draft SAVA Testbed May 2008
6. Conclusion
Several conclusions can be made from the experiment.
First, the experiment is a proof that a prototype can be built that
is deployable on loosely-coupled domains of test networks in a
limited scale and "multiple-fence" design for source address
validation. The solution allows different validation granularities,
and also allows different providers to use different solutions. The
coupling of components at different levels of granularity can be
loose enough to allow component substitution.
Incremental deployment is another design principle that was used in
the experiment. The tests have demonstrated that benefit is derived
even when deployment is incomplete, which gives providers an
incentive to be early adopters.
The experiment also provided a proof of concept for the switch-based
local subnet validation, network authentication based validation,
filter-based Inter-AS validation, and authentication tag-based
Inter-AS validation mechanisms. The client host and network
equipment need to be modified and some new servers should be
deployed.
Nevertheless, as discussed in the previous section, there are a
number of limitations, issues, and question marks in the prototype
designs and the overall source address validation space.
It is our hope that some of the experiences will help vendors and the
Internet standards community in these efforts. Future work in this
space should attempt to answer some of the issues raised in Section
5. Some of the key issues going forward include:
o Scalability questions and per-packet operations.
o Protocol design issues, such as integration to existing address
allocation mechanisms, use of hop-by-hop headers, etc.
o Cost vs. benefit questions. These may be ultimately answered only
by actually employing some of these technologies in production
networks.T
o Trust establishment issue and study of false positive.
o Deployability considerations, e.g. modifiability of switches,
hosts, etc.
Wu, et al. Expires November 14, 2008 [Page 25]
Internet-Draft SAVA Testbed May 2008
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 November 14, 2008 [Page 26]
Internet-Draft SAVA Testbed May 2008
8. Security Considerations
The purpose of the draft is to report experimental results. Some
security considerations of the solution mechanisms of testbed are
mentioned in the document, but not the main problem to be described
in this document.
Wu, et al. Expires November 14, 2008 [Page 27]
Internet-Draft SAVA Testbed May 2008
9. Acknowledgements
This experiment was conducted among 12 universities, 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. The authors would like
to thank everyone involved in this effort in these universities.
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 November 14, 2008 [Page 28]
Internet-Draft SAVA Testbed May 2008
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.
http://www.icnp2007.edu.cn/files/ICNP_papers/
28_wuj-sava.pdf
[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 November 14, 2008 [Page 29]
Internet-Draft SAVA Testbed May 2008
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 November 14, 2008 [Page 30]
Internet-Draft SAVA Testbed May 2008
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 November 14, 2008 [Page 31]
Internet-Draft SAVA Testbed May 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Wu, et al. Expires November 14, 2008 [Page 32]
