Skip to main content

A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5210.
Authors Jianping Wu , Jun Bi , Xing Li , Gang Ren , Mark Williams , Ke Xu
Last updated 2015-10-14 (Latest revision 2008-05-16)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Experimental
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 5210 (Experimental)
Action Holders
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Jari Arkko
Send notices to
Network Working Group                                              J. Wu
Internet-Draft                                                     J. Bi
Intended status: Experimental                                      X. Li
Expires: November 16, 2008                                        G. Ren
                                                                   K. Xu
                                                     Tsinghua University
                                                             M. Williams
                                                        Juniper Networks
                                                            May 15, 2008

                  SAVA Testbed and Experiences to Date

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 16, 2008.

Wu, et al.              Expires November 16, 2008               [Page 1]
Internet-Draft                SAVA Testbed                      May 2008


   Because the Internet forwards packets according to the IP destination
   address, packet forwarding typically takes place without inspection
   of the source address and malicious attacks have been launched using
   spoofed source addresses.  In an effort to enhance the Internet with
   IP source address validation, a prototype implementation of the IP
   Source Address Validation Architecture (SAVA) was created [Wu07] and
   an evaluation was conducted on an IPv6 network.  This document
   reports on the prototype implementation and the test results, as well
   as the lessons and insights gained from 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

Wu, et al.              Expires November 16, 2008               [Page 2]
Internet-Draft                SAVA Testbed                      May 2008

     10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     10.2. Informative References . . . . . . . . . . . . . . . . . . 29

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
   Intellectual Property and Copyright Statements . . . . . . . . . . 32

Wu, et al.              Expires November 16, 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 would help us achieve the
   following goals:

   o  Since packets which carry spoofed source addresses would not be
      forwarded, it would be impossible to launch network attacks which
      are enabled by using spoofed source addresses and more difficult
      to successfully carry out attacks enhanced or strengthened by the
      use of spoofed source addresses.

   o  Being able to assume that all packet source addresses are correct
      would allow traceback to be accomplishedaccurately and with
      confidence.  This would benefit network diagnosis, management,
      accounting and applications.

   As part of the effort in developing a Source Address Validation
   Architecture (SAVA), we implemented a SAVA prototype and deployed the
   prototype in 12 ASes in an operational network as part of China Next
   Gerneration Internet (CNGI) Project.  We conducted evaluation
   experiments.  In this document we first describe the prototype
   solutions and then report 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
   this 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 16, 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.  That is,
   there are multiple points in the network at which the validity of a
   packet's source address can be checked.  This is because in the
   current single-fence model where source address validity is
   essentially checked only at ingress to the network, deployment has
   been inadequate to the point that there are always sufficient
   opportunity to mount attacks based on spoofed source addresses and it
   seems likely that this condition will continue in the forseeable
   future.  A multiple-fence solution will allow "holes" in deployment
   to be covered and and validity of the source address to be evaluated
   with increased confidence across the whole Internet.  The assumption
   here is that when validity checking is not universal, it is still
   worthwhile to increase the confidence in the validity of source
   addresses and to reduce the opportunities to mount a source address
   spoofing attack.

   Furthermore, the architecture allows for multiple independent and
   loosely-coupled checking mechanisms.  The motivation for this is that
   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
   could potentially render an implementation ineffective.  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 16, 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 networks where hosts are individually directly attached to one
   interface of a router, but this is not the normal case in an access

   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 16, 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

   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 is 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 ensures 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 16, 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, it 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 SAMS history database 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 16, 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

   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 again becomes 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 16, 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 tested both solutions.  The
   switch-based solution has better performance but the switches in the
   access network would need to be upgraded (usually the number of
   switches in an access network is large) .  The signature based
   solution could be deployed between host and the exit router, but it
   has some extra cost in 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 enough 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 16, 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 a router with a set of valid source address blocks, and

Wu, et al.              Expires November 16, 2008              [Page 11]
Internet-Draft                SAVA Testbed                      May 2008

   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

Wu, et al.              Expires November 16, 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 export 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 a 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 described 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, an 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

Wu, et al.              Expires November 16, 2008              [Page 13]
Internet-Draft                SAVA Testbed                      May 2008

   tag can be put in an IPv6 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, it is assured that
   their networks do not send spoofed packets.  However, other networks
   may still do this.  With the above scheme, however, this capability
   is eliminated.  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

   The Registration Server is the "center" of the trust alliance (TA).
   It maintains a member list for the TA.  It performs two major

   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 16, 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 periodically.  Although
   the overhead of maintaining and exchanging authentication tags
   between AS pairs is O(N) rather than O(N^2), the traffic and
   processing overhead do increase as the number of ASes increases.
   Therefore an automatic authentication tag refresh mechanism is
   utilized in this solution.  In this mechanism, each peers run the
   same algorithm to automatically generate an authentication tag
   sequence.  Then the authentication tag in packets can be changed
   automatically with high frequency.  To enhance the security, a seed
   is used for the algorithm to generate an authentication tag sequence
   robust against guessing.  Thus, the peers need only to negotiate and
   change the seed at very low frequency.  This lowers the overhead
   associated with frequently negotiating and changing the
   authentication tag while maintaining acceptable 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.  Neither of the solutions is perfect, but
   they are both 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 field 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 create
   a DoS attack target.

Wu, et al.              Expires November 16, 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 critical issue.  Our work focused
   on two points: tag negotiation and tag refresh.  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 rather than the sender AS.
   With a receiver-driven scheme, the receiver AS can decide the
   policies of tag management.  The packets tagged with an old
   authentication tag should not be allowed indefinitely.  Rather, after
   having negotiated a 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 valid after the new
   tag has been assigned.  In the experiment, we use five seconds.

   The trust alliance is intended to be established dynamically (join
   and quit), but in this testbed we need to confirm offline the initial
   trust among alliance members.

Wu, et al.              Expires November 16, 2008              [Page 16]
Internet-Draft                SAVA Testbed                      May 2008

3.  SAVA Testbed


   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 rather than being a
   mixed IPv4/IPv6 infrastructure.  Only Some CPNs are dual-stacked.
   The CNGI-CERNET2 backbones, CNGI-CERNET2 CPNs, and CNGI-6IX all have
   globally unique AS numbers.  Thus a multi-AS testbed environment is

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 an
   operational backbone, any new protocols and networking techniques
   need to be tested in a non-disruptive way.

Wu, et al.              Expires November 16, 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 architecture.  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-

   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

   Each university deployed one AS.  Six universities deployed all parts
   of the solution and are hence fully-featured, with inter-AS, intra-AS

Wu, et al.              Expires November 16, 2008              [Page 18]
Internet-Draft                SAVA Testbed                      May 2008

   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 were
   installed on a variety of servers.  Two solutions for the access
   network were deployed.

Wu, et al.              Expires November 16, 2008              [Page 19]
Internet-Draft                SAVA Testbed                      May 2008

4.  Test Experience and Results

   The solutions outlined in section 2 were implemented on the testbed
   described in section 3.  Successful testing of all solutions was been
   carried out, as detailed in the following sections.

4.1.  Test Scenarios

   For each of the test scenarios, we 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

   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 the
       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 16, 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 16, 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 can be launcched 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 optimal 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 16, 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

   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 16, 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

   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 positives.  Currently CNGI-CERNET2 is a
   relatively stable network and this method works well in the testbed.
   We will further study the impact of false positives in an unstable

   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

Wu, et al.              Expires November 16, 2008              [Page 24]
Internet-Draft                SAVA Testbed                      May 2008

6.  Conclusion

   Several conclusions can be drawn 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

   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

   o  Trust establishment issue and study of false positives.

   o  Deployability considerations, e.g. modifiability of switches,
      hosts, etc.

Wu, et al.              Expires November 16, 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

Wu, et al.              Expires November 16, 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 16, 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, Lixia Zhang and Pekka
   Savola for their detailed review comments on this draft, and thank
   Paul Ferguson and Ron Bonica for their valuable advice on the
   solution development and the testbed implementation.

Wu, et al.              Expires November 16, 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.


   [Wu07]     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 November 16, 2008              [Page 29]
Internet-Draft                SAVA Testbed                      May 2008

Authors' Addresses

   Jianping Wu
   Tsinghua University
   Computer Science, Tsinghua University
   Beijing  100084


   Jun Bi
   Tsinghua University
   Network Research Center, Tsinghua University
   Beijing  100084


   Xing Li
   Tsinghua University
   Electronic Engineering, Tsinghua University
   Beijing  100084


   Gang Ren
   Tsinghua University
   Computer Science, Tsinghua University
   Beijing  100084


   Ke Xu
   Tsinghua University
   Computer Science, Tsinghua University
   Beijing  100084


Wu, et al.              Expires November 16, 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


Wu, et al.              Expires November 16, 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

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

   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

Wu, et al.              Expires November 16, 2008              [Page 32]