[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 5210

Network Working Group                                              J. Wu
Internet-Draft                                                     J. Bi
Intended status: Experimental                                      X. Li
Expires: March 23, 2008                                           G. Ren
                                                                   K. Xu
                                                     Tsinghua University
                                                             M. Williams
                                                        Juniper Networks
                                                            Sep 20, 2007


                  SAVA Testbed and Experiences to Date
                  draft-wu-sava-testbed-experience-02

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 March 23, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).









Wu, et al.               Expires March 23, 2008                 [Page 1]

Internet-Draft                SAVA Testbed                      Sep 2007


Abstract

   Since the Internet uses destination-based packet forwarding,
   malicious attacks have been launched using spoofed source addresses.
   In an effort to enhance the Internet with IP source address
   validation, we prototyped an implementation of the IP Source Address
   Validation Architecture (SAVA) and conducted the evaluation on an
   IPv6 network.  This document reports our prototype implementation and
   the test results, as well as the lessons and insights gained from our
   experimentation.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  A Prototype SAVA Implementation  . . . . . . . . . . . . . . .  5
     2.1.  Solution Overview  . . . . . . . . . . . . . . . . . . . .  5
     2.2.  IP Source Address Validation at Access Network . . . . . .  6
     2.3.  IP Source Address Validation at Intra-AS/Ingress Point . .  7
     2.4.  IP Source Address Validation in Inter-AS Case
           (Neighboring AS) . . . . . . . . . . . . . . . . . . . . .  7
     2.5.  IP Source Address Validation in Inter-AS Case
           (Non-Neighboring AS) . . . . . . . . . . . . . . . . . . . 10

   3.  SAVA Testbed . . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.1.  CNGI-CERNET2 . . . . . . . . . . . . . . . . . . . . . . . 12
     3.2.  SAVA Testbed on CNGI-CERNET2 Infrastructure  . . . . . . . 12

   4.  Test Experience and Results  . . . . . . . . . . . . . . . . . 15
     4.1.  Test Experience  . . . . . . . . . . . . . . . . . . . . . 15
     4.2.  Test Results . . . . . . . . . . . . . . . . . . . . . . . 15

   5.  Design Limitation  . . . . . . . . . . . . . . . . . . . . . . 17

   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 18

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19

   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21

   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     10.2. Informative References . . . . . . . . . . . . . . . . . . 22

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23



Wu, et al.               Expires March 23, 2008                 [Page 2]

Internet-Draft                SAVA Testbed                      Sep 2007


   Intellectual Property and Copyright Statements . . . . . . . . . . 25


















































Wu, et al.               Expires March 23, 2008                 [Page 3]

Internet-Draft                SAVA Testbed                      Sep 2007


1.  Introduction

   By design the Internet forwards data packets solely based on the
   destination IP address.  The source IP address is not checked during
   the forwarding process in most cases.  This makes it easy for
   malicious hosts to spoof the source address of the IP packet.  We
   believe that it would be useful to enable the Internet security to
   enforce the validity of the source IP address for all the packets
   being forwarded. .

   Enforcing the source IP address validity can help us achieve the
   following goals:

   o The packets which carry spoofed source addresses will not be
   forwarded, making it impossible to launch network attacks with
   spoofed source addresses.

   o The packets which hold a correct source address can be traced back
   accurately.  This can benefit network diagnosis, management,
   accounting and applications.

   As part of the effort in developing a Source Address Validation
   Architecture (SAVA), we have implemented a SAVA prototype on an
   operational network, a native IPv6 backbone network of the China Next
   Generation Internet project, and conducted evaluation experiments.
   In this documents we first describes our prototype solution 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[RFC2827][Park01][Li02][Brem05][Snoe01] Our SAVA prototype
   implementation has borrowed some of the schemes from the proposed or
   existing solutions.  It should also be stressed that we are still in
   an early stage in developing IP source address validation solutions.
   Thus the prototype implementation and experimental results presented
   in this report serve only as an input, and by no means pre-empt any
   solution development that may be carried out by future IETF effort.












Wu, et al.               Expires March 23, 2008                 [Page 4]

Internet-Draft                SAVA Testbed                      Sep 2007


2.  A Prototype SAVA Implementation

2.1.  Solution Overview

   In the Internet at large, it is unrealistic to expect any single IP
   source address validation mechanism to be universally supported
   everywhere to eliminate the IP source address spoofing problem.
   Furthermore, implementation bugs or configuration errors can also
   render the intended implementation effectiveness.  Therefore our
   prototype SAVA implementation is a combination of multiple coexisting
   and cooperate mechanisms.  More specifically,we implement source IP
   address checking at three levels: first-hop, local subnet source
   address validation; intra-AS source address validation; and remote,
   inter-AS source address validation, as shown in Figure 1.
                  __ ____                        __ ____
              .-''       `':                 .-''       `':
              |             |   Inter-AS SAV |             |
              |   +-+----+  |                |   +-+----+  |
              |   |Router+--+----------------+---+Router|  |
              |   +--.---+  |                |   +--.---+  |
     Intra-AS |      |      |       Intra-AS |      |      |
        SAV   |   +--+---+  |          SAV   |   +--+---+  |
              |   |Router|  |                |   |Router|  |
              '_  +--.---+  _                '_  +--.---+  _
                `'---+---'''                   `'---+---'''
              __..---+---..._                __..---+---..._
              |      |       `|              |      |       `|
              |+-----+-------+|              |+-----+-------+|
              ||Router/Switch||              ||Router/Switch||
              |+-----.-------+|              |+-----.-------+|
     First Hop|      |        |     First Hop|      |        |
        SAV   |    +-'--+     |        SAV   |    +-'--+     |
              |    |Host|     |              |    |Host|     |
              '_   +----+   _,;'             '_   +----+   _,;'
                `'-------'''                   `'-------''
   Key: SAV== Source Address Validation

                        Figure 1: Solution Overview

   It is important to enforce IP source address validity at the first-
   Hop and the local subnet level.  That is, when an IP packet is sent
   from a host, the first physical multiplexing box should check to make
   sure that the packet carries a correct source IP address.  If this
   first hop source address checking is missing, then a host may be able
   to spoof the source IP address which belongs to another local host.

   We use the term "intra-AS source address validation" to mean the IP
   source address checking at the attachment point of a customer network



Wu, et al.               Expires March 23, 2008                 [Page 5]

Internet-Draft                SAVA Testbed                      Sep 2007


   to its provider network, also called the ingress point.  IP source
   address checking at ingress points can enforce the source IP address
   correctness at the IP prefix level, assuming the customer network
   owns one or more IP address blocks.  This practice has been adopted
   as the Internet Best-Current-Practice [RFC2827][RFC3704].  Even in
   the absence of the first-hop source address checking, this ingress
   checking can still prevent the hosts within one customer network from
   spoofing IP addresses belonging to other networks.

   Inter-AS IP source address validation refers to mechanisms that
   enforcement of the correctness of the source address of the packet at
   AS boundaries is ensured, after a packet is injected into the
   Internet backbone.  The first two steps of source address checking
   utilize the network physical connectivity of the first-hop and the
   ingress points.  Because the Internet backbone 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 checking is
   missing or non-effective.

   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 at Access Network

   The main idea of the solution is based on creating a dynamic binding
   between a switch port and valid source IP address, or a binding
   between MAC address, source IP address and switch port.

   Our design has three main modules: Source Address Request Client
   (SARC) on the host, Source Address Validation Proxy (SAVP) on the
   switch, and Source Address Management Server (SAMS).

   Our solution has the following basic steps:

   1.  The SARC on the end host sends an IP address request.  The SAVP
       on the switch relays this request to the SAMS.  If the address
       has been predetermined by the end host, it still needs to put it
       in the request message for verification by SAMS.

   2.  SAMS receives the IP address request, and generates an address
       response to SARC based on the address allocation and management
       policy of the local subnet.  The allocation of the IP address is
       stored in the history database of SAMS for traceback.





Wu, et al.               Expires March 23, 2008                 [Page 6]

Internet-Draft                SAVA Testbed                      Sep 2007


   3.  The SAVP on the access switch receives the response, and binds
       the IP address with the switch port on the binding table.  In
       addition, 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.

2.3.  IP Source Address Validation at Intra-AS/Ingress Point

   We adopted the solution of the source address filtering of IP packets
   at ingress points described in [RFC2827]and[RFC3704]; the latter
   describes source address filtering at the ingress points of multi-
   homed customer 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 ASs
   with different administrative authorities and different interests.
   It should be light weight to support high throughput and not to
   influence forwarding efficiency.





























Wu, et al.               Expires March 23, 2008                 [Page 7]

Internet-Draft                SAVA Testbed                      Sep 2007


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

               Figure 2: Inter-ISP (Neighboring AS) Solution

   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, and each AS has one.  The VE
   loads validation rules generated by VRGE to filter packets passed
   between ASs (In the case of Figure 2, from neighboring ASs 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 filter
   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 of that prefix's "entry" into the region of
   validated IPv6 prefixed by processing AS-Path information.  The rules



Wu, et al.               Expires March 23, 2008                 [Page 8]

Internet-Draft                SAVA Testbed                      Sep 2007


   are derived according to the table below.
---------------------------------------------------------------------------
|   \Export| Own        | Customer's| Sibling's | Provider's | Peer's     |
|To  \     | Address    | Address   | Address   | Address    | Address    |
|-----\-------------------------------------------------------------------|
| Provider |      Y     |    Y      |     Y     |            |            |
|-------------------------------------------------------------------------|
| Customer |      Y     |    Y      |     Y     |     Y      |     Y      |
|-------------------------------------------------------------------------|
| Peer     |      Y     |    Y      |     Y     |            |            |
|-------------------------------------------------------------------------|
| Sibling  |      Y     |    Y      |     Y     |     Y      |     Y      |
---------------------------------------------------------------------------

              Figure 3: AS-Relation Based Inter-AS Filtering

   Different ASes exchange and transmit VR information using the AS-
   relation-based export rules in the VR generation server.  As per
   Figure 3, an AS exports the address prefixes of its own, its
   customers, its providers, it siblings and its peers to its customers
   and siblings as valid prefixes, while it only exports the address
   prefixes of its own, its customers and its siblings to its providers
   and peers as valid prefixes.  With the support of AS Number to IPv6
   Address Mapping service, only AS numbers of valid address prefixes
   are transferred between ASes and the AS number is mapped to address
   prefixes at the VRGE.  Only changes of AS relation and changes of IP
   address prefixes belonging to an AS require the generation of VR
   updates.

   The procedure's principle steps are as follows (Seeing from AS-1 in
   Figure 2):

   1.  When the VRGE has initialized, it reads its neighboring SAVA-
       compliant AS table and establishes connections to all the VEs in
       its own AS.

   2.  The VRGE initiates a VR renewal.  According to its exporting
       table, it sends its own originated VR to VRGEs of neighboring
       ASs.  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 ASs.

   4.  If the VRGE accepts a VR, it uses the AIMS to transform AS-
       expressed VR into IPv6 prefix-expressed VR.




Wu, et al.               Expires March 23, 2008                 [Page 9]

Internet-Draft                SAVA Testbed                      Sep 2007


   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 ASs do not exchange packets directly, it s not
   possible to deploy a solution like that in the previous section.
   However, it is highly desirable for non-neighboring ISPs to be able
   to form a trust alliance such that packets leaving one AS will be
   recognized by the other and inherit the validation status they
   possessed on leaving the first AS.  There is more than one way to do
   this.  For the SAVA experiments to date, A signature method has been
   used.  This solution is inspired by the work [Brem05].  This
   particular method uses a light-weight signature.
                                +-----+
              .-----------------+.REG |-----------------.
              |                 +-----+                 |
              |                                         |
        ,-----+--------                          ,------+-------
      ,'     `|        `.                      ,'     ` |       `.
     /        |         \                     /         |         \
    /         |          \                   /          |          \
   ;       +--'--+      +----+             +----+     +-----+       ;
   |       | ASC +------+AER |             |AER +-----+ ASC |       |
   :       +--.--+      +----+`            +----+     +--+--+       :
    \         |__________________________________________|         /
     \                   /                    \                   /
      `.               ,'                      `.               ,'
        '-------------'                          '-------------'
             AS-1                                     AS-2
   KEY: REG == Registration Server, ASC == AS Control Server, AER == AS
   Edge Router.

             Figure 4: Inter-AS (Non-neighboring AS) Solution

   There are three major components in the system: the Registration
   Server (REG), the AS Control Server (ASC), and the AS Edge Router
   (AER).

   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.




Wu, et al.               Expires March 23, 2008                [Page 10]

Internet-Draft                SAVA Testbed                      Sep 2007


   o When the member list is changed, notify each AS Control Server.

   Each AS deploying the method should have an AS Control Server.  The
   AS Control Server has three major functions:

   o Communicate with the Registration Server, to get the up-to-date
   member list of TA.

   o Communicate with the AS Control Server in other member AS in the
   TA, to exchange updates of prefix ownership information, and to
   exchange signatures.

   o Communicate with all edge routers of the local AS, to configure the
   processing component on the edge routers.

   The AS Edge Router does the work of adding signature to the packet at
   the sending AS, and the work of verifying and removing the signature
   at the destination AS.

   In the design of this system, in order to decrease the burden on the
   REG, most of the control traffic happens between ASCs.






























Wu, et al.               Expires March 23, 2008                [Page 11]

Internet-Draft                SAVA Testbed                      Sep 2007


3.  SAVA Testbed

3.1.  CNGI-CERNET2

   The prototypes of our solutions for SAVA are implemented and tested
   on CNGI-CERNET2.  CNGI-CERNET2 is one of the China Next Generation
   Internet (CNGI) backbones.  CNGI-CERNET2 connects 25 core nodes
   distributed in 20 cities in China at speeds of 2.5-10 Gb/s.  The
   CNGI-CERNET2 backbones are IPv6-only networks (the biggest in the
   world), not the mixed IPv4/IPv6 infrastructure.  The CNGI-CERNET2
   backbones, CNGI-CERNET2 CPNs, and CNGI-6IX all have globally unique
   AS numbers.  Thus a multi-AS 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 7 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 CERNET2 is a production
   backbone, any new protocols and networking techniques need to be
   tested in a non- disruptive way.



























Wu, et al.               Expires March 23, 2008                [Page 12]

Internet-Draft                SAVA Testbed                      Sep 2007


                                __
                              ,'  \                            _,...._
                             ,'    \____---------------+     ,'Beijing`.
                             /      \  |Inter-AS SAV(D)|-----| Uni     |
     +---------------+     |         | +---------------+     `-._____,'
     |Inter-AS SAV(D)+-----|         |
     +------.--------+     |         |                         _,...._
            |              | CERNET2 |__---------------+     , SE     `.
            |              |         | |Inter-AS SAV(D)|-----| Uni     |
    Tsinghua|University    | Backbone| +---------------+     `-._____,'
         ,,-|-._           |         |
       ,'   |   `.         |         |
     ,'+---------+\        |         |
    |  |Router(C)| |       |         |      ...
    |  +---------+ |       |         |
    |       |      |       |         |
    |  +---------+ |       |         |                         _,...._
    |  |Switch(B)| |       |         |__---------------+     ,        `.
    |  +---------+ |       |         | |Inter-AS SAV(D)|-----|  BUPT   |
    |       |      |       |         | +---------------+     `-._____,'
    |   +-------+  |       |         |
     \  |Host(A)| .'        \       .'
      \ +-------+,'          \      |
       `.      ,'             \    /
         ``---'                -_,'
   KEY: SAV=Source Address Validation
   Rectangle(A) (B) (C) (D) are deployment point of source address
   validation mechenism.

                  Figure 5: CERNET2 SAVA Test Environment

   Notwithstanding the aforementioned restrictions on the early testbed,
   the testbed is fully capable of functional testing of solutions for
   all parts of the SAVA solutions.  Namely, it is possible to test
   procedures for ensuring the validity of IPv6 source addresses in the
   access network and in packets sent from the access network to an IPv6
   service provider, packets sent within one service provider's network,
   packets sent between neighboring service providers and packets sent
   between service providers separated by an intervening transit
   network.

   The testbed is distributed across 7 universities connected to CNGI-
   CERNET2, namely Tsinghua University, Beijing University, Beijing
   University of Post and Telecommunications, Shanghai Jiaotong
   University, Wuhan Polytechnic University, Southeast University in
   Nanjing, and South China Polytechnic University in Guangzhou.

   Each of the university installations is connected to the CNGI-CERNET2
   backbone through a set of inter-AS filtering and monitoring



Wu, et al.               Expires March 23, 2008                [Page 13]

Internet-Draft                SAVA Testbed                      Sep 2007


   equipment.  (Inter-AS Layer).

   o When the member list is changed, notifiy each AS Control Server.

   Each AS deploying the method should have an AS Control Server.  The
   AS Control Server has three major functions:

   Of the installations, the installation at Tsinghua University is the
   most fully-featured, with inter-AS, Intra-AS and first-hop layer
   validation all able to be tested.  In addition, a suite of
   applications that could be subject to spoofing attacks or which can
   be subverted to carry out spoofing attacks are installed on a variety
   of servers.






































Wu, et al.               Expires March 23, 2008                [Page 14]

Internet-Draft                SAVA Testbed                      Sep 2007


4.  Test Experience and Results

   The solutions outlined above have been implemented on the testbed
   described above.  Successful testing of all solutions has been
   carried out, as detailed in the following sections.

4.1.  Test Experience

   We have test in Tsinghua University and tests between Tsinghua
   University and other universities.  We have Inter-AS (non-neighboring
   AS) SAVA solution test, Inter-AS (neighboring AS) SAVA solution test,
   Intra-AS SAVA solution test, and Access Network SAVA solution test.

   For each one of the test scenarios, we have tested many cases.
   Taking Inter-AS (non-neighboring AS) SAVA solution test as an
   example, we classified the test cases into three classes: normal
   class, dynamic class and anti-spoofing class.

   1.  For normal class, there are three cases: Adding Signature Test,
       Removing Signature Test and Forwarding packets with valid source
       address.

   2.  For dynamic class, there are four cases: Updating the signature
       between ASes, The protection for newly joined member AS, Adding
       address space and Deleting address space.

   3.  For anti-spoofing class, there is one case: Filtering of packets
       with forged IP address.

   As is shown in Fig.5, We have "multiple-fence" design for our SAVA
   testbed.  A is an attacker's host sending spoofing packets.  B is the
   first-hop source address validation point.  C is the Intra-AS source
   address validation point.  D is Inter-AS source address validation
   point.  If source address validation is deployed at B, we can get a
   host granularity validation.  If source address validation is
   deployed at C, we can guarantee that the packets sent from this point
   have a correct IP prefix.  If source address validation is deployed
   at D, we can guarantee that the packets sent from this point are from
   a correct AS.

4.2.  Test Results

   1.  The test results are consistent with the expected ones.  For an
       AS which has fully-featured SAVA deployment with inter-AS,
       Intra-AS and First-Hop layer 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



Wu, et al.               Expires March 23, 2008                [Page 15]

Internet-Draft                SAVA Testbed                      Sep 2007


       can be traced back accurately.

   2.  For the Inter-AS (non-neighboring AS) SAVA solution, during the
       period of signature update, the old and the new signature are
       both valid, thus there are no packet loss.

   3.  For the Inter-AS (non-neighboring AS) SAVA solution, the
       validation function is implemented by software in a layer-two box
       running Linux.  During the test, If the box connected directly,
       it can achieve a normal forwarding line speed.  If the box is
       connected with devices from other vendor, it can only achieve a
       very limited line speed.  The reason is that the signatures are
       added on the IPv6 hop-by-hop option header and the network device
       from vendors handled the hop-by-hop options just by software.





































Wu, et al.               Expires March 23, 2008                [Page 16]

Internet-Draft                SAVA Testbed                      Sep 2007


5.  Design Limitation

   There are several design limitations for the solutions deployed in
   CNGI-CERNET2 testbed.

   1.  For Inter-AS (non-neighboring AS) SAVA solution, the difficulty
       for guessing the signature between two AS members was discussed
       in [Brem05].  It is relatively difficult and we can increase the
       difficulty of guess by increasing the length of the signature.
       In current CERNET2 SAVA testbed, a 128-bit signature is designed
       in IPv6 hop-by-hop option header.

   2.  Inter-AS (neighboring AS) SAVA solution is based on AS relation,
       thus it can not synchronized with the dynamics of route changes
       very quickly.

   3.  The First-hop SAVA solution needs to be widely deployed in the
       access network switches.  For the environment where source
       address validation is not deployed in the access network, because
       we have a "multiple-fence" design for SAVA, we can still get a
       source address validation of IP prefix granularity if Intra-AS
       source address validation is deployed.





























Wu, et al.               Expires March 23, 2008                [Page 17]

Internet-Draft                SAVA Testbed                      Sep 2007


6.  Conclusion

   Several conclusions can be made from the test experience and results.

   It is possible to devise a loosely-coupled, and "multiple-fence"
   design for SAVA.  This provides for different granularities of
   authenticity of source IP addresses.  It also allows for different
   providers to use different solutions, and the coupling of components
   at different levels of granularity of authenticity can be loose
   enough to allow component substitution.

   The scalability of SAVA still need further consideration.  CNGI-
   CERNET2 testbed just provides an initial test environment for SAVA.
   Although the overhead of maintain and exchanging signatures between
   AS pairs is not O(N^2), but O(N), the traffic and processing overhead
   are increased when the AS numbers are increased.  SAVA must be
   capable of scaling to the size of the global Internet.

   Incrementally deployment should be another design principle for SAVA.
   The tests have demonstrated that benefit is derived even when
   deployment is incomplete, which gives providers an incentive to be
   early adopters of the framework.  Some DiffServe mechanism can also
   be taken into consideration.  Traffics from SAVA-compliant AS should
   get a high priority service.

   First-Hop, local subnet source address validation is an important
   part of SAVA to achieve an authenticity of host IP granularity.
   There are multiple access cases: Local subnet in Enterprise networks,
   residential broadband, and wireless mobile, etc.  For Enterprise
   networks, there are multiple solutions from the research and
   engineering community.  Focusing on the appropriate framework and
   solutions for first-hop source address validation could be a valuable
   initial step for solving the source address spoofing problem in IETF.


















Wu, et al.               Expires March 23, 2008                [Page 18]

Internet-Draft                SAVA Testbed                      Sep 2007


7.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.













































Wu, et al.               Expires March 23, 2008                [Page 19]

Internet-Draft                SAVA Testbed                      Sep 2007


8.  Security Considerations

   The purpose of the draft is to report experimental results.  The
   security considerations of the solution mechanisms of testbed are not
   mentioned in this document.














































Wu, et al.               Expires March 23, 2008                [Page 20]

Internet-Draft                SAVA Testbed                      Sep 2007


9.  Acknowledgements

   The authors would like to thank Jari Arkko and Lixia Zhang for their
   detailed review comments on this draft, and thank Paul Ferguson and
   Ron Bonica for their valuable advices on the solution development and
   the testbed implementation.













































Wu, et al.               Expires March 23, 2008                [Page 21]

Internet-Draft                SAVA Testbed                      Sep 2007


10.  References

10.1.  Normative References

   [RFC2827]  Paul, F. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, 2004.

10.2.  Informative References

   [Brem05]   Bremler-Barr, A. and H. Levy, "Spoofing Prevention
              Method", INFOCOM 2005.

   [Li02]     Li,, J., Mirkovic, J., Wang, M., Reiher, P., and L.
              Zhang, "SAVE: Source Address Validity Enforcement
              Protocol", INFOCOM  2002.

   [Park01]   Park, K. and H. Lee, "On the effectiveness of route-based
              packet filtering for distributed DoS attack prevention in
              power-law internets", SIGCOMM 2001.

   [Snoe01]   Snoeren, A., Partridge, C., Sanchez, L., and C.
              Jones......, "A Hash-based IP traceback", SIGCOMM 2001.

























Wu, et al.               Expires March 23, 2008                [Page 22]

Internet-Draft                SAVA Testbed                      Sep 2007


Authors' Addresses

   Jianping Wu
   Tsinghua University
   Computer Science, Tsinghua University
   Beijing  100084
   China

   Email: jianping@cernet.edu.cn


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

   Email: junbi@cernet.edu.cn


   Xing Li
   Tsinghua University
   Electronic Engineering, Tsinghua University
   Beijing  100084
   China

   Email: xing@cernet.edu.cn


   Gang Ren
   Tsinghua University
   Computer Science, Tsinghua University
   Beijing  100084
   China

   Email: rg03@mails.tsinghua.edu.cn


   Ke Xu
   Tsinghua University
   Computer Science, Tsinghua University
   Beijing  100084
   China

   Email: xuke@csnet1.cs.tsinghua.edu.cn






Wu, et al.               Expires March 23, 2008                [Page 23]

Internet-Draft                SAVA Testbed                      Sep 2007


   Mark I. Williams
   Juniper Networks
   Suite 1508, W3 Tower, Oriental Plaza, 1 East Chang'An Ave
   Dong Cheng District, Beijing  100738
   China

   Email: miw@juniper.net












































Wu, et al.               Expires March 23, 2008                [Page 24]

Internet-Draft                SAVA Testbed                      Sep 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Wu, et al.               Expires March 23, 2008                [Page 25]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/