[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: January 4, 2008                                          G. Ren
                                                                  CERNET
                                                             M. Williams
                                                        Juniper Networks
                                                             Jul 3, 2007


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

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 January 4, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).










Wu, et al.               Expires January 4, 2008                [Page 1]

Internet-Draft                SAVA Testbed                      Jul 2007


Abstract

   This draft describes the testbed installed at Tsinghua University and
   other Universities in China attached to the CERNET-II IPv6 backbone,
   some SAVA testing that has been carried out on that network and some
   preliminary results of that testing.













































Wu, et al.               Expires January 4, 2008                [Page 2]

Internet-Draft                SAVA Testbed                      Jul 2007


Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described RFC 2119 [RFC2119].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6

   2.  SAVA Testbed . . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.1.  CERNET2  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.2.  SAVA Testbed on CERNET2 Infrastructure . . . . . . . . . .  7

   3.  SAVA Solutions Tested and Experiences  . . . . . . . . . . . . 15
     3.1.  Inter-ISP Case (Neighbouring AS) . . . . . . . . . . . . . 15
     3.2.  Inter-ISP Case (Intervening AS)  . . . . . . . . . . . . . 17
     3.3.  Intra-ISP (Access Network) Case  . . . . . . . . . . . . . 18

   4.  Test Experience and Results  . . . . . . . . . . . . . . . . . 20
     4.1.  Inter-AS (intervening) SAVA Solution Test  . . . . . . . . 20
       4.1.1.  TsingHua University Inner Test . . . . . . . . . . . . 20
         4.1.1.1.  Tag Signature Test . . . . . . . . . . . . . . . . 20
           4.1.1.1.1.  Test Content . . . . . . . . . . . . . . . . . 20
           4.1.1.1.2.  Expected Results . . . . . . . . . . . . . . . 20
           4.1.1.1.3.  Results  . . . . . . . . . . . . . . . . . . . 21
           4.1.1.1.4.  new section  . . . . . . . . . . . . . . . . . 21
         4.1.1.2.  Remove Signature Test  . . . . . . . . . . . . . . 21
           4.1.1.2.1.  Test Content . . . . . . . . . . . . . . . . . 21
           4.1.1.2.2.  Expected Result  . . . . . . . . . . . . . . . 21
           4.1.1.2.3.  Result . . . . . . . . . . . . . . . . . . . . 22
         4.1.1.3.  Filtering of packets with forged IP address  . . . 22
           4.1.1.3.1.  Test Content . . . . . . . . . . . . . . . . . 22
           4.1.1.3.2.  Expected Resut . . . . . . . . . . . . . . . . 22
           4.1.1.3.3.  Result . . . . . . . . . . . . . . . . . . . . 22
         4.1.1.4.  Update the flag(signature) between ASes  . . . . . 23
           4.1.1.4.1.  Test Content . . . . . . . . . . . . . . . . . 23
           4.1.1.4.2.  Expected Result  . . . . . . . . . . . . . . . 23
           4.1.1.4.3.  Result . . . . . . . . . . . . . . . . . . . . 23
         4.1.1.5.  The protection to newly deployed AS  . . . . . . . 23
           4.1.1.5.1.  Test Content . . . . . . . . . . . . . . . . . 24
           4.1.1.5.2.  Expected Result  . . . . . . . . . . . . . . . 24
           4.1.1.5.3.  Result . . . . . . . . . . . . . . . . . . . . 24
         4.1.1.6.  Add address space  . . . . . . . . . . . . . . . . 25
           4.1.1.6.1.  Test Content . . . . . . . . . . . . . . . . . 25
           4.1.1.6.2.  Expected Result  . . . . . . . . . . . . . . . 25
           4.1.1.6.3.  Result . . . . . . . . . . . . . . . . . . . . 26



Wu, et al.               Expires January 4, 2008                [Page 3]

Internet-Draft                SAVA Testbed                      Jul 2007


         4.1.1.7.  Delete address space . . . . . . . . . . . . . . . 26
           4.1.1.7.1.  Test Content . . . . . . . . . . . . . . . . . 26
           4.1.1.7.2.  Expected result  . . . . . . . . . . . . . . . 26
           4.1.1.7.3.  Result . . . . . . . . . . . . . . . . . . . . 27
       4.1.2.  TsingHua (Beijing) <--> GZU (GuangZhou) Test . . . . . 27
         4.1.2.1.  Tag Signature(flag) Test . . . . . . . . . . . . . 27
           4.1.2.1.1.  Test Content . . . . . . . . . . . . . . . . . 27
           4.1.2.1.2.  Expected Result  . . . . . . . . . . . . . . . 27
           4.1.2.1.3.  Result . . . . . . . . . . . . . . . . . . . . 28
         4.1.2.2.  Remove the Signature . . . . . . . . . . . . . . . 28
           4.1.2.2.1.  Test Content . . . . . . . . . . . . . . . . . 28
           4.1.2.2.2.  Expected Result  . . . . . . . . . . . . . . . 28
           4.1.2.2.3.  Result . . . . . . . . . . . . . . . . . . . . 29
         4.1.2.3.  Filtering of Forged Packets  . . . . . . . . . . . 29
           4.1.2.3.1.  Test Content . . . . . . . . . . . . . . . . . 29
           4.1.2.3.2.  Expected Result  . . . . . . . . . . . . . . . 29
           4.1.2.3.3.  Result . . . . . . . . . . . . . . . . . . . . 30
         4.1.2.4.  Update Signature . . . . . . . . . . . . . . . . . 30
           4.1.2.4.1.  Test Content . . . . . . . . . . . . . . . . . 30
           4.1.2.4.2.  Expected Result  . . . . . . . . . . . . . . . 30
           4.1.2.4.3.  Result . . . . . . . . . . . . . . . . . . . . 30
         4.1.2.5.  The protection for newly joined member AS  . . . . 31
           4.1.2.5.1.  Test Content . . . . . . . . . . . . . . . . . 31
           4.1.2.5.2.  Expected Result  . . . . . . . . . . . . . . . 32
           4.1.2.5.3.  Result . . . . . . . . . . . . . . . . . . . . 32
         4.1.2.6.  Add new address space  . . . . . . . . . . . . . . 32
           4.1.2.6.1.  Test Content . . . . . . . . . . . . . . . . . 32
           4.1.2.6.2.  Expected Result  . . . . . . . . . . . . . . . 33
           4.1.2.6.3.  Result . . . . . . . . . . . . . . . . . . . . 33
         4.1.2.7.  Delete address space . . . . . . . . . . . . . . . 33
           4.1.2.7.1.  Test Content . . . . . . . . . . . . . . . . . 33
           4.1.2.7.2.  Expected result  . . . . . . . . . . . . . . . 34
           4.1.2.7.3.  Result . . . . . . . . . . . . . . . . . . . . 34
     4.2.  Inter-AS (neighbouring) SAVA Solution Test . . . . . . . . 34
       4.2.1.  Initialization of deployment . . . . . . . . . . . . . 34
         4.2.1.1.  Test Content . . . . . . . . . . . . . . . . . . . 34
         4.2.1.2.  Expected Result  . . . . . . . . . . . . . . . . . 35
         4.2.1.3.  Result . . . . . . . . . . . . . . . . . . . . . . 35
       4.2.2.  Filtering of spoofed packets . . . . . . . . . . . . . 35
         4.2.2.1.  Test Content . . . . . . . . . . . . . . . . . . . 35
         4.2.2.2.  Expected Result  . . . . . . . . . . . . . . . . . 35
         4.2.2.3.  Result . . . . . . . . . . . . . . . . . . . . . . 36
     4.3.  Intra-domain SAVA Solution Test  . . . . . . . . . . . . . 36
       4.3.1.  Testing the validity of intra-domain filtering . . . . 36
         4.3.1.1.  Test Content . . . . . . . . . . . . . . . . . . . 36
         4.3.1.2.  Expected Result  . . . . . . . . . . . . . . . . . 36
         4.3.1.3.  Result . . . . . . . . . . . . . . . . . . . . . . 37
     4.4.  Access Network SAVA Solution Test  . . . . . . . . . . . . 37



Wu, et al.               Expires January 4, 2008                [Page 4]

Internet-Draft                SAVA Testbed                      Jul 2007


       4.4.1.  Testing of authentication capability for access
               network  . . . . . . . . . . . . . . . . . . . . . . . 37
         4.4.1.1.  Test Content . . . . . . . . . . . . . . . . . . . 37
         4.4.1.2.  Expected result  . . . . . . . . . . . . . . . . . 37
         4.4.1.3.  Result . . . . . . . . . . . . . . . . . . . . . . 37
       4.4.2.  The authenticated network access . . . . . . . . . . . 37
         4.4.2.1.  Test Content . . . . . . . . . . . . . . . . . . . 37
         4.4.2.2.  Expected Result  . . . . . . . . . . . . . . . . . 37
         4.4.2.3.  Result . . . . . . . . . . . . . . . . . . . . . . 38
       4.4.3.  The filtering of forged packets  . . . . . . . . . . . 38
         4.4.3.1.  Test Content . . . . . . . . . . . . . . . . . . . 38
         4.4.3.2.  Expected Result  . . . . . . . . . . . . . . . . . 38
         4.4.3.3.  Result . . . . . . . . . . . . . . . . . . . . . . 38
     4.5.  Stability Test of Filtering Device . . . . . . . . . . . . 38
       4.5.1.  Testing in the THU Trusty Internet Lab . . . . . . . . 39
         4.5.1.1.  Stability for intervening ASes solution. . . . . . 39
           4.5.1.1.1.  Test Content . . . . . . . . . . . . . . . . . 39
           4.5.1.1.2.  Expected Result  . . . . . . . . . . . . . . . 39
           4.5.1.1.3.  Result . . . . . . . . . . . . . . . . . . . . 39
         4.5.1.2.  Stability for neighboring ASes solution. . . . . . 39
           4.5.1.2.1.  Test Content . . . . . . . . . . . . . . . . . 39
           4.5.1.2.2.  Expected Result  . . . . . . . . . . . . . . . 39
           4.5.1.2.3.  Result . . . . . . . . . . . . . . . . . . . . 40
       4.5.2.  Deployment test between Tsinghua
               University(Beijing) and GZU(Guangzhou) . . . . . . . . 40
         4.5.2.1.  Stability for intervening ASes solution  . . . . . 40
           4.5.2.1.1.  Test Content . . . . . . . . . . . . . . . . . 40
           4.5.2.1.2.  Expected Result  . . . . . . . . . . . . . . . 40
           4.5.2.1.3.  new section  . . . . . . . . . . . . . . . . . 40

   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 41

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 42

   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 44
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 44

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
   Intellectual Property and Copyright Statements . . . . . . . . . . 46









Wu, et al.               Expires January 4, 2008                [Page 5]

Internet-Draft                SAVA Testbed                      Jul 2007


1.  Introduction

   The problem addressed in the Source Address Validation Architecture
   activity is outlined in [I-D.wu-sava-problem-statement] and a
   proposed solution framework for discussion is outlined in
   [I-D.wu-sava-framework].

   Some potential procedures that could be used as solution elements in
   the framework have been devised and one is introduced and discussed
   in [I-D.wu-sava-solution-e2e-ipv6].  It should be stressed that at
   this early stage, the solutions proposed in the solution document are
   not intended to pre-empt work carried out by the IETF in the solution
   space.  Indeed, consensus must be reached on a framework before
   solution work can be fully undertaken.  The shape of the "holes"
   needs to be established before the "pegs" can be carved.
   Furthermore, it is envisaged that more than one solution could be
   devised and deployed for each of the proposed solution elements
   required under the framework, in keeping with the requirement for a
   loosely-coupled architecture and, as far as possible, a plug-and-play
   framework.  The intention of the solutions documents is to provide
   some solution ideas which can be implemented on the testbed described
   in this document.

   This document describes the testbed and the solutions implemented and
   tested on it to date.


























Wu, et al.               Expires January 4, 2008                [Page 6]

Internet-Draft                SAVA Testbed                      Jul 2007


2.  SAVA Testbed

2.1.  CERNET2

   CERNET2 is one of the China Next Generation Internet (CNGI)
   backbones.  CERNET2 connects 25 core nodes distributed in 20 cities
   in China at speeds of 2.5-10 Gb/s.  The CERNET2 backbone is an IPv6-
   only network.

2.2.  SAVA Testbed on CERNET2 Infrastructure

   It is intended that eventually the SAVA testbed will be implemented
   directly on the CERNET2 backbone, but in the early stages the testbed
   has been implemented as an overlay structure on top of 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 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 January 4, 2008                [Page 7]

Internet-Draft                SAVA Testbed                      Jul 2007


                          ---------------
                          | Transit AS  |
                          ---------------
                           |           |
                         ------      ------
                         |ASBR|      |ASBR|
                         ------      ------
                           |           |
                           |           |    Inter-ISP
                           |           |      layer
                   ........|...........|.................
                         ------      ------
                         |ASBR|      |ASBR|
                         ------      ------
                           |           |
                         -----       -----
                         |AS1|       |AS2|
                         -----       -----
                           |           |    Intra-ISP
                           |           |     layer
                   ........|...........|.................
                           |           |
                         -----       -----
                         |ASw|       |ASw|   Access
                         -----       -----   layer
                           |           |
                       ----------  ----------
                       | access |  | access |
                       |  net   |  |  net   |
                       ----------  ----------
                           |           |
                         -----       -----
                         | H1|       |H2 |
                         -----       -----

                      Figure 1: SAVA Framework Layers

   Notwithstanding the aforementioned restrictions on the early testbed,
   the testbed is fully capable of functional testing of solutions for
   all parts of the SAVA solution framework.  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



Wu, et al.               Expires January 4, 2008                [Page 8]

Internet-Draft                SAVA Testbed                      Jul 2007


   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 CERNET2
   backbone through a set of inter-ISP filtering and monitoring
   equipment.  (Inter-ISP Layer).

   Of the installations, the installation at Tsinghua University is the
   most fully-featured, with inter-ISP, Intra-ISP and access 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.  The Tsingua testbed consists of three separate
   Autonomous systems joined by MBGP speakers.



































Wu, et al.               Expires January 4, 2008                [Page 9]

Internet-Draft                SAVA Testbed                      Jul 2007


               ,.-.,,                ,.-.,,                  ,.-.,,
             -`      '             -`      '               -`      '
            |Beijing  |           |  BUPT   |             | WuHan TU|
             .  Uni  .             .       .               .       .
              `''-''\               `''/''`                 .''-''`
                     \                 |                 ,-`
                  +---'----+      +----\---+     +------`-+
     ,.-.,,       |Filters |      |Filters |     |Filters |            ,.-.,,
   -`      '      +--------+      +----/---+     +--.-----+          -`      '
  |Tsinghua|            \              |          .`                | SE Uni |
   .       -              `.           |        .`                  ,.       .
    `'.-''` `.              .          |      .`               _.-``  `''-''`
      |       ',             \  ,,.--..\_   .`           +---'`---+
      |    +----'---+        -'`         `-`           ,,-Filters |
      |    |Filters |      ,'               \    ,,-'``  +--------+
      |    +--------,     /                  -'``
      |              `.  |   CERNET2 Backbone |
      |                `.|                .-.,|                    inter-area filter system
      |                  '\             / ip1 \   inter-area filter       /---\
    /----\                 \            \ mac1-`.   module                |   |
    |    | application      `',_         `'-'`   '--------+               |ip3|
    |    | access               .''--''``        | ip2,ip5|------/        |ip6|
    \____/                      |                +-----,---      |       ,.   |
    / \`.`.,                    |                       `.,      |    ,-` \---/
    /  , ', '.,               +-\------+                   ', /----\ control server
   /   \   .   '.             |Filters |                     `|    | monitoring server
   '    \   `,   `',          +--------+                      \-.--/
 +/-+  +-'+  +'-+  +`'+          |                            .`
 |  |  |  |  |  |  |  |          |                          .`
 +--+  +--+  +--+  +--+       ,.-\,,                   .-.-`zebra Access Router
 DNS,SIP,AAA,E-mail,Media,  '`       '                / ip4 \------..,,,,
     Web Server            |SC TU    |             /``\ mac2'            \
                            .       .              \   `'-'`             /
                             `''-''`                 ```'''''------''''``
                                                   Shanghai Jiaotong Uni SAVA Lab

              Figure 2: CERNET2 Overlay SAVA Test Environment

          ,,.-..,                                                   * /----\
        -`       `',                                                  |Cont |
      ,'            \                                                 |Serv.|
     /    CERNET2    ,         AS300                                 _.     |
     |               -,,                                          _-` |ASC3 |
     \               '  `'    ,..,          ,..,               _-`    \----/ /----\
      \             /        '    `        '    `        /----`--\           |Reg. |
       `-,       _-`       -| 300-4-------|300-3 -.,,    |       |           |Serv.|
          `''--'`            .    /        .    /    ``''- SW31  -------------     |
                              `'-`        ,.`'-`|        |       |-,         |RegS |



Wu, et al.               Expires January 4, 2008               [Page 10]

Internet-Draft                SAVA Testbed                      Jul 2007


                                      ,-'`      |        \-------/  `',      \----/
                                ,..,-'`     ,.., \              -       `'.,
                              '    `      '    `                `.         +-------+
                             |300-2 |----| 300-1|                 \        |       |
                              .    /      .    -                   `.      | client|
                               `'/`        `'-` `,                   ',    |       |
                                /                 .                    \   +-------+
                         +---------+          +----'----+               `,
                         | box300-1|          | box300-2|             +---'---+
                         +----/----+          +-----,---+             | Attack|
                            B |                      ',               | A3    |
                            G |                        `.  BGP        |       |
                            P |                          ``.          +-------+
                              |                             ',
                       +------\--+                            `.
                       | box100-1|                          +---`'----+
                       +-----/---+                          | box200-2|
                            /                               +---------+
                       ,..--,                                       |
                      '      `                                      '..,
       AS100          |100-1 | +---------+           +---------+    '    `
                       .    /--| box100-2|-----------| box200-1|---| 200-1) AS200
                       _.'-`   +---------+   BGP     +---------+    .    /
                     _-`                                             `'-`
/-------\      ,..,-`                                                  |     /----\
|       |     '    `          ,..,                                   ,..,    |Cont |
| SW11  -----| 100-2-.,,     '    `                   ,..,          '    `   |Serv.|
|       |     .    /    ``'-| 100-3|                 '    `--------|-200-2|--|     |
\--/----/      `'-`          .    /                 . 200-3|        .    /   |ASC2 |
   |                          `'-`                ,` .    /-,         '-`    \----/
   |                                            ,'    `'-`   '.
   |                                           /            /--`'---\
   |                                     /----`--\          |       |
/-\--\                                   |       |          | SW23  |
|Cont.|                                  | SW22  |          |       |
|Serv.|                                  |       |          \---/----,   Validated
|     |                                  \---/---/              |     '.  Access
|ASC1 |                                      |                  |       `',
\----/                      Unvalidated      |                  |          '.
                            Acess            |               /--\-\       +--`'---+
                                         +---\---+           |Web/ |      | Attack|
                                         | Attack|           |Media|      | A1    |
                                         | A2    |           |Serv.|      |       |
                                         |       |           |     |      +-------+
                                         +-------+           \----/

       Figure 3: Tsinghua University Trustable Internet Test Network




Wu, et al.               Expires January 4, 2008               [Page 11]

Internet-Draft                SAVA Testbed                      Jul 2007


       AS100                                                     .
                                                                `
    OSPF Areas={100-1,100-3,100-4}                      +------1-+
                                 MAC=0005:64FF:F988     |Box100-1|
                                        @:4::1:1   _,,.-0---2----+
              _,.-.,,                    .,.--,'```         |@:3::1:2
            ,'       `.@:1::1:2        ,'       ''          \192.168.1.2
           |   100-3   1--------------|   100-1  |           |
           |          |       @:1::1:1|_         |-,         |
            ',       3-                ',       ,'  `'.,     |                 .
              `2'--'` \@:1::3:1          `''''''@:4::2:1`',  |               ,'
       @:1::2:1|       \                MAC=0005:64FF:F989 `'.,             -
               |        \                                     |`'., +------1-+
               |         \                                    |    `0Box100-2|
               |          \                                   |     +------2-+
               |           \                                  |       @:3::1:3
               |            `.                                \     192.168.1.3
               |              ,                                |          |
       @:1::2:2|               .                               |          |
           _,.-1,,              \                              |         /
         ,'       `.             \                             |         |
        |   100-4  |              \                            \         |
        |          |               \@:1::3:2                    |       /
         ',       ,-                \                           |       |
           `''2-'`                   0/-----\                   |       |
              |                       |     |                   |      /
              |                       |  A  |                   \/-----\-\
              |                       |  S  |                    |       |
              |                       |  C  |@:3::1:1            | SW2-C |
              \                       |  1  1--------------------\       |
          Application                 |     |192.168.1.1         |       |
          Access                      |     |                    \-------/
                                      \-----/

            Figure 4: Tsinghua University Network AS100 detail
















Wu, et al.               Expires January 4, 2008               [Page 12]

Internet-Draft                SAVA Testbed                      Jul 2007


  /-----\-------------------------------------------------------------------/
  |     |                                             AS200                 |
  |SW2-C-.,,,_     +--------+  _,.      OSPF Areas={200-1,200-3,200-4}      |
  |     |     ``''2|Box200-2|1`                                             |
  \-.---/  @:5::2:2+-----0--+                                       @:5::2:1|
     ,     192.168.2.2    \                             ,.-.,    192.168.2.1|
     |                    \                 @:2::1:2_,1`     `           /--1-\
      ,                    |                   _,-'`  | 200-3|3          | AA |
      |                    |              ,.-'`        .     /@:2::3:1   | SS |
       ,           MAC=0004:9312:00FC,.-``              `2-'`      `'.,  | CA |
       |@:5::2:3     @:4::3:2'.-.-'``                @:2::2:1          `-| || |
    192.168.2.3            .`     `.@:2::1:1          -          @:2::3:2| 22 |
        \                  | 200-1 |                ,'                   | /  |
        +2-------+     _,,.-.      `              ,`                     \----/
       1.Box200-1-0'``@:4::2:2'-'`              ,'
      .`+--------+    MAC=0004:9312:00FD       /
    -`                                       .`                        SAVA
                                           ,'                    Access client
                                 ,.-.,  @:2::2:2                  @:2::4:7+---+
                                `     `1-`                              _,|   |
                               | 200-4 |                           ,.-'`  |   |
                      @:2::5:1,2.     .3,                    _,-'``       +---+
                          _.-`   `'-'`   ''.,13         ,.-'`
              /-----\  ,-`         @:2::4:1  `-------'``
              |     -'`                       |     |--22-----------------/
              |SW22 |                         |SW23 |                     |
              |     |                         |     -21    /----\      /--\-\
             .\-----/                         \--.--/ `'., |    |      |    |
           .`                                 .23         `-    |      |    |
   +---+ .`                                ,-`             | MS |      | WS |
   |A2 -`                         +---+  ,'                |    |      |    |
   |   |                          |A1 |-`                  |    |      |    |
   +---+                          |   |                    |    |      |    |
 @:2::5:9                         +---+                    \----/      \----/
                                @:2::4:9                  @:2::4:2    @:2::4:3


          Figure 5: Tsinghua University Test Network AS200 Detail













Wu, et al.               Expires January 4, 2008               [Page 13]

Internet-Draft                SAVA Testbed                      Jul 2007


   AS300                               client                     @:3::7:ffff
                                        +--+                         /---\
     OSPF Areas={300-1,300-2,           |  |@:3::7:4                ,. R |
                 300-3,300-4}           +--+ `.,                _.-` | e |
                                                ',           ,-`     | g |
      ,.-.,,                ,.-.,,                `'-----\-'`        | S |
    -`      '     @:3::4:1-`      '@:3::7:1        |     |           \---/
   |  300-4 |-------------3 300-3 4----------------- SW31|
    .      @:3::4:2       .       .                |     -,          /---\
     /''-''`               `2'-.1`                 \--.--/ `'-,      | A |
    /              @:3::2:2`    ,@:3::1:2             |        `'-,  | S |
   / Application         ,`     |            @:3::7:9 |     @:3::7:2'0 C |
  /  Access             -        \                  +-\+             | 3 |
 -                    ,'         |                  |A3|             \1--/
                     /            |                 +--+           ,-` @:5::3:1
                   ,'             \                              .` 192.168.3.1
                  /                |                          ,-`
        ,.-.,,  @:3::2:1           |@:3::1:1                .`
      -`      2`                 ,.\.,,.                ,-`
     |  300-2  3..,,,,_         -`      2001:250:c000:128::2/112
      .      @:3::3:2   ```'''--| 300-1 |-.,,,      ,-`
       1''-''`           @:3::3:1      ..     ```''-.,,,_
       |@:4::1:2                 `''-''_       _-`       ``'2001:250:c000:128::1
 MAC=0005:64FF:FD00             @:4::3:1\    .'                    ```'--.,,
       |              MAC=0005:64FF:F9C8 \_,'                       -`      '
       |                                ,'.                        |         |
       |                             _.`  \                         .       .
       |                           ,'      \                         `''-''`
       |                         .`         \                       CERNET 2
       |                      ,-`            \
    +--0-----+           /---`-\          +---0----+
    |Box300-1|2-----------     ----------2|Box300-2|
    1--------+@:5::3:3   |SW3-C|  @:5::3:2+--------1,
   /       192.168.3.3   |     |  192.168.3.2        '.
  -                      \-----/                       `'



          Figure 6: Tsinghua University Test Network AS300 Detail












Wu, et al.               Expires January 4, 2008               [Page 14]

Internet-Draft                SAVA Testbed                      Jul 2007


3.  SAVA Solutions Tested and Experiences

3.1.  Inter-ISP Case (Neighbouring AS)


                                        ---------
                                        | AIMS   |
                                         ------|-
                                               |
   --------------                   -----------|-----
   |  AS-4       |-----       ------|    AS-1  |    |-----
   |             |ASBR |----->|ASBR |    ------|-   |ASBR |---> Global IPv6
   |             |-----       ------|    | VRGE |   |-----       Network
   ---------------                  |    --------   |
                              ----- -----------------
                              |ASBR|       |ASBR|
                              ------       ------
                               /             |
                              /              |
                             /               |
                            /                |
                        ----------        -----
                        |ASBR, VE|        |ASBR|
                   ---------------      -------------
                   |   AS-2      |      |  AS-3     |
                   |             |      |           |
                   |             |      |           |
                   |             |      |           |
                   ---------------      -------------


   Key: AIMS == AS-IPv6 prefix Mapping Server, VRGE == Validation Rule
   Generating Engine, VE == Validating Engine

                Figure 7: Inter-ISP (Neighboring AS) Setup

   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.  In the
   testbed, these are implemented on a LINUX server.  The VE loads
   validation rules generated by VRGE to filter packets passed between
   ASs (In the case of Figure 7, from neighbouring ASs into AS-1.  In
   the SAVA testbed, the VE is implemented as a simulated L2 device on a



Wu, et al.               Expires January 4, 2008               [Page 15]

Internet-Draft                SAVA Testbed                      Jul 2007


   Linux-based machine inserted into the data path just outside each
   ASBR interface that faces a neigbouring 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
   are derived according to the table below, as described in [Gao].

---------------------------------------------------------------------------
|   \Export| Own        | Customer's| Sibling's | Providor's | Peer's     |
|To  \     | Address    | Address   | Address   | Address    | Address    |
|-----\-------------------------------------------------------------------|
| Providor |      Y     |    Y      |     Y     |            |            |
|-------------------------------------------------------------------------|
| Customer |      Y     |    Y      |     Y     |     Y      |     Y      |
|-------------------------------------------------------------------------|
| Peer     |      Y     |    Y      |     Y     |            |            |
|-------------------------------------------------------------------------|
| Sibling  |      Y     |    Y      |     Y     |     Y      |     Y      |
---------------------------------------------------------------------------

              Figure 8: 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 8, 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 folows (as seen by AS-1 in
   Figure 7):

   1.  When the VRG has initialised, it reads the AS neighbour table and
       establishes TCP 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 IPv6 prefixes to neighbouring ASs
       VRGEs.  Rules are expressed as AS numbers.





Wu, et al.               Expires January 4, 2008               [Page 16]

Internet-Draft                SAVA Testbed                      Jul 2007


   3.  When a VRGE receives the new rules from its neighbour, it then
       uses its own export table to decide whether it should accept the
       rules and, if it accepts a rule, whether or not it should re-
       export the rule to other neighbouring ASs.

   4.  If the VRGE accepts a rule, it used the AIMS to transform AS-
       expressed rules into IPv6 refix-expressed rules.

   5.  The VRGE then pushes the thus-generated rules to all the VEs in
       its AS.  The VEs then use these prefix-based rules to filter
       incoming packets.

3.2.  Inter-ISP Case (Intervening AS)

   In the case where two ASs do not exchange packets directly, it s not
   possibe to deploy a solution like that in the previous section.
   However, it is highly desirable for non-neighbouring ISPs to be able
   to form a trust alliance such that packets leaving one AS will be
   recognised 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, the signature method
   detailed in [I-D.wu-sava-solution-e2e-ipv6] has been used.  This
   particular method uses a weak signature.

                                   +-----+
                                   | REG |
                                   +-----+

           ,--------------                          ,--------------
         ,'     `         `.                      ,'     `         `.
        /                  \                     /                   \
       /                    \                   /                     \
      ;       +-----+      +----+             +----+     +-----+       ;
      |       | ASC |      |AER |             |AER |     | ASC |       |
      :       +-----+      +----+`            +----+     +-----+       :
       \                     /                  \                     /
        \                   /                    \                   /
         `.               ,'                      `.               ,'
           '-------------'                          '-------------'
                AS-1                                     AS-2

   KEY: REG == Registration Server, ASC == AS Control Server, AER == AS
   Edge Router.

          Figure 9: Validation Setup Between non-Neighbouring ASs

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



Wu, et al.               Expires January 4, 2008               [Page 17]

Internet-Draft                SAVA Testbed                      Jul 2007


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

   o Processes requests from the AS Control Server, to get the member
   list for the TA.

   o When the member list is changed, notifiy 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.

3.3.  Intra-ISP (Access Network) Case

   Assuming an ISP has implemented source address validation on its
   connection to peers and transit providers, the intra-ISP case reverts
   to access validation.  There are many options for access validation,
   including BCP38 filtering, depending on the strength of validation
   required.  The solution tested in the SAVA testbed takes the
   strongest requirement for validation in the access network.  That is,
   any IPv6 address should have a unique association with an entity that
   is specifically authorised to use that IPv6 address.  (BCP38
   filtering, on the other hand typically only requires that the source
   address of a packet entering the provider network belong to a prefix
   that is allocated to or has transit through the attached access
   network.)

   An Extended Access Control Protocol is used in order to distribute
   authorised IPv6 addreses to end-users and to ensure a record of the
   authorised user and the corresponding IPv6 address and MAC address
   for each port of the access switch.  As a result it is possible for



Wu, et al.               Expires January 4, 2008               [Page 18]

Internet-Draft                SAVA Testbed                      Jul 2007


   the access switch to filter any packets sent by the user (or sokmeone
   pretending to be the user) that do not carry the authorised IPv6
   source address and the corresponding MAC address.  The SAVA extendes
   access control used for this proof of concept follows the following 4
   steps:

   1.  End user sends an identity verification supplication, and the
       access switch sends a RADIUS request to the SAVA access
       validation server.

   2.  On successful establishment of identity, the SAVA access
       validation server issues an authorised IPv6 address for the user.

   3.  The access switch, on receiving the RADIUS authentication success
       message combines the embedded IPv6 address, the end-user
       identity, end-user MAC address and the switch port number into a
       binding relationship.  In addition, it sends the issued address
       to the end-user host.

   4.  The access switch begins to filter packets sent from the end-user
       host.  Packets which do not conform to an authorised (MAC SA,
       IPv6 SA, Switch Port) tuple are discarded.





























Wu, et al.               Expires January 4, 2008               [Page 19]

Internet-Draft                SAVA Testbed                      Jul 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.  A more detailed discussion will be forthcoming in the
   next version of this draft.

4.1.  Inter-AS (intervening) SAVA Solution Test

4.1.1.  TsingHua University Inner Test

4.1.1.1.  Tag Signature Test

4.1.1.1.1.  Test Content

   200-2 and 300-2 are SAVA filtering devices between AS200 and AS300.
   First, start filtering solution

   1.  telnet 200-2 and 300-2, start /home/spm/as-union/box/output/box.

   2.  Input '5' and enter to start filtering.

   3.  telnet ASC2 and ASC3, start /home/spm/as-union/control/output/
       control

   4.  telnet login server RegS, start /home /spm/as-union/register/
       output/register

   Then, A3 in AS300 sends ICMPv6 packets to the media server in AS200
   with its real source IP address.

   Last, telnet 300-2, watch the content of inbound packets at eth0 of
   300-2 and outbound packets at eth1 of 300-2 with tcpdump.

4.1.1.1.2.  Expected Results

   When AS300starts filtering, 300-2 should tag a flag into the received
   IPv6 packets which come from AS300.  The flag is type 0x21 in HOP-by-
   HOP option, including a 6 bytes label and 6 bytes PAD.  The expected
   result is: the packet gets into eth0 have a ICMPv6 expand head after
   first 40 bytes head, and the packet with the same seq number, which
   comes from eth1, should have a type 0x21 HOP-BY-HOP option after the
   first 40 bytes head, then is the ICMPv6 expand head.  The upper
   result will prove that the signature is tagged correctly.







Wu, et al.               Expires January 4, 2008               [Page 20]

Internet-Draft                SAVA Testbed                      Jul 2007


4.1.1.1.3.  Results

--------------------------------------------------------------------------------------
|            | Source IP               | Hop-By-Hop Type  | Hop-By-Hop Flag | Result |
|------------------------------------------------------------------------------------|
|Packets     | 2001:250:cccc:3::7:f    |  NULL            |  NULL           |  pass  |
| Received   |                         |                  |                 |        |
|------------------------------------------------------------------------------------|
|Packets     | 2001:250:cccc:3::7:f    |  0x21            | F241 B12E FB1E  | pass   |
|Sent        |                         |                  |                 |        |
--------------------------------------------------------------------------------------

4.1.1.1.4.  new section

4.1.1.2.  Remove Signature Test

4.1.1.2.1.  Test Content

   At first, start Inter-AS (intervening) filtering solution.

   1.  telnet 200-2 and 300-2, start /home/spm/as-union/box/output/box

   2.  input '5' and enter to start filtering.

   3.  telnet ASC2 and ASC3, start /home/spm/as-union/control/output/
       control

   4.  telnet login server RegS, start /home/spm/as-union/register/
       output/register

   Then A3 in AS300 sends ICMPv6 packets to the media server in AS200
   with its real source IP address.

   Last, telnet 200-2, watch the content of inbound packets at eth1 of
   200-2 and outbound packets at eth0 of 200-2 with tcpdump.

4.1.1.2.2.  Expected Result

   When AS300 starts filtering, 200-2 should receive packets with a flag
   from AS300.  The flag is type 0x21 in HOP-by-HOP option, including a
   6 bytes label and 6 bytes PAD.  The expected result is: the packet
   gets into eth1 have a type 0x21 HOP-BY-HOP option after the first 40
   bytes head, then is the ICMPv6 expand head, and the packet with the
   same seq number, which goes out of eth0, should have the ICMPv6
   expand head directly after first 40 bytes head.  The upper result
   will prove that the signature is removed correctly.





Wu, et al.               Expires January 4, 2008               [Page 21]

Internet-Draft                SAVA Testbed                      Jul 2007


4.1.1.2.3.  Result

   ------------------------------------------------------------
   |            | Hop-By-Hop Type  | Hop-By-Hop Flag | Result |
   |----------------------------------------------------------|
   |Packets     |  0x21            | 66FB 6A4E 325D  |  pass  |
   | Received   |                  |                 |        |
   |----------------------------------------------------------|
   |Packets     |  NULL            | NULL            | pass   |
   |Sent        |                  |                 |        |
   ------------------------------------------------------------

4.1.1.3.  Filtering of packets with forged IP address

4.1.1.3.1.  Test Content

   AS100, AS200 and AS300 are neighbor ASes and 100-1, 100-2, 200-1,
   200-2, 300-1 ,300-2 are filtering devices.  At first, start Inter-AS
   (intervening) filtering solution.

   1.  telnet all, run /home/spm/as-union/box/output/box

   2.  Input '5' and enter to start filtering.

   3.  telnet ASC1, ASC2 and ASC3, run /home/spm/as-union/control/
       output/control

   4.  telnet login server RegS, start /home/spm/as-union/register/
       output/register.

   Then, A3 in AS300 uses(forges) IP address from AS100 to send forged
   packets to MS(media server) in AS200.

   At last, watch the received packets at MS with tcpdump.

4.1.1.3.2.  Expected Resut

   A3 in AS300 sends packets with forged source IP address(IP address in
   AS100) to AS200.  The packets won't contain the right flag, so the
   filtering devices of AS200 would filter the forged packets.  And MS
   (the destination media sever) would not receive the forged packets.

4.1.1.3.3.  Result








Wu, et al.               Expires January 4, 2008               [Page 22]

Internet-Draft                SAVA Testbed                      Jul 2007


   --------------------------------------------------------------------|
   | SRC IP of Forged Pkt  | DST IP of Forged Packet | Filter | Result |
   |-------------------------------------------------|--------|--------|
   |2001:250:cccc:1:7:f    | 2001:250:cccc:2::4:2    |  Yes   | pass   |
   |-------------------------------------------------------------------|

4.1.1.4.  Update the flag(signature) between ASes

4.1.1.4.1.  Test Content

   AS200 and AS300 are neighbor ASes and 200-2, 300-2 are filtering
   devices.  At first, start Inter-AS (intervening) filtering solution.

   1.  telnet 200-2 and 300-2, start /home/spm/as-union/box/output/box

   2.  Input '5' and enter to start filtering.

   3.  telnet ASC2 and ASC3, start /home/spm/as-union/control/output/
       control

   4.  telnet login server RegS, start /home /spm/as-union/register/
       output/register

   Then A3 in AS300 sends ICMPv6 packets to the media server in AS200
   with its real source IP address.

   At last, telnet 300-2, track record of packets coming from eth1 of
   300-2, last for 2T, where T is the period of flag update.

4.1.1.4.2.  Expected Result

   300-2 would tag a flag into every out-going packet.  Find out the
   time between flag changes, and this time should be around the period
   T.

4.1.1.4.3.  Result

-------------------------------------------------------------------------------------------------
|T   | first change time | 1st flag       | Second change time | 2nd flag       | Change period |
------------------------------------------------------------------------------------------------|
|60s | 10:27:55          | 8fd7 0b58 38a4 | 10:29:03           | ec42 236a b074 | 68s           |
-------------------------------------------------------------------------------------------------

4.1.1.5.  The protection to newly deployed AS







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

Internet-Draft                SAVA Testbed                      Jul 2007


4.1.1.5.1.  Test Content

   AS200 and AS300 have filtering devices 200-2 and 300-2 between them.
   But there are no filtering devices between AS100 and AS200 or AS100
   and AS300.

   At first, start Inter-AS filtering solution.

   1.  telnet login server, run /home/spm/as-union/registration/output/
       register to start the server.

   2.  telnet 200-2 and 300-2, run /home/spm/as-union/box/output/box,
       but don't start Inter-AS solutions between them.

   3.  telnet ASC2 and ASC3, run /home/spm/as-union/control/outbox/
       control.

   4.  telnet login server RegS, run /home/spm/as-union/register/output/
       register

   Then, a testing machine in AS100 sends forged packets (IP address in
   AS 300 is forged) to the MS(media server) in AS200.

   Telnet MS in AS200, watch if it receives the forged packets with
   tcpdump.

   At last, start filtering at 200-2 and 300-2.  Telnet MS in AS200,
   watch if MS still receives the forged packets.

4.1.1.5.2.   Expected Result

   The SAVA solution supports incremental deployment.  This experiment
   is to verity the newly deployed AS is protected from source IP forge
   attack and being forged as the source.  At first, filtering is not
   started and forged packets are found at MS.  When the filtering is
   started, forged packets are blocked.  Even if AS100 doesn't belong to
   the solution union, it can't forge the source addresses in the ally
   (AS300).

4.1.1.5.3.  Result











Wu, et al.               Expires January 4, 2008               [Page 24]

Internet-Draft                SAVA Testbed                      Jul 2007


------------------------------------------------------------------------------
| SRC IP of Forged Pkt  | DST IP of Forged Packet | Filter | Filter | Result |
|                       |                         | Before?| After? |        |
|-------------------------------------------------|--------|--------|--------|
|2001:250:cccc:3::7:f   | 2001:250:cccc:2::4:2    |  No    | Yes    | Pass   |
|-----------------------------------------------------------------------------

4.1.1.6.  Add address space

4.1.1.6.1.  Test Content

   200-1 and 300-1 are filtering devices between AS200 and AS300.  There
   are no filtering devices between AS200 and AS100, AS300 and AS100.&#
   65306;

   At first, start Inter-AS filtering solution.

   1.  telnet registration server, run /home/spm/as-union/registration/
       output/register to start.

   2.  telnet 200-1 and 300-1, run /home/spm/as-union/box/output/box,
       start filtering.

   3.  telnet ASC2 and ASC3, run /home/spm/as-union/control/outbox/
       control.

   4.  telnet RegS, run /home/spm/as-union/register/output/register

   The a testing machine in AS100 sends forged packets to MS(media
   server) in AS200 with a new forged source IP address (3ffe:5555::7:f)
   which doesn't belong to AS100, AS200 or AS300.

   Telnet MS in AS200, watch if it receives the forged packet with
   tcpdump.

   Then telnet ASC3 and input 'add' to add a new address space (e.g,
   3ffe:5555: ).

   At last, telnet MS in AS200 to watch if the forged packet is
   received.

4.1.1.6.2.  Expected Result

   The Source IP Authentication Union supports management of the address
   space.  The member AS may gets new address space, it could request
   the registration server to add the new address space.  This
   experiment tests this situation.  Before the new address space is
   added, the forged packet could be found at MS.  After added, the



Wu, et al.               Expires January 4, 2008               [Page 25]

Internet-Draft                SAVA Testbed                      Jul 2007


   forged packet can't be found.  This proves that address space can be
   added correctly.

4.1.1.6.3.  Result

------------------------------------------------------------------------------
| SRC IP                | DST IP                  | Filter | Filter | Result |
|                       |                         | Before?| After? |        |
|-------------------------------------------------|--------|--------|--------|
| 3fffe:5555::7:f       | 2001:250:cccc:2::4:2    |  No    | Yes    | Pass   |
|-----------------------------------------------------------------------------

4.1.1.7.  Delete address space

4.1.1.7.1.  Test Content

   200-1 and 300-1 are filtering devices between AS00 and AS300.  There
   are no filtering devices between AS200 and AS100, AS300 and AS100.

   At first, start Inter-AS filtering solution.

   1.  telnet registration server, run /home/spm/as-union/registration/
       output/register to start.

   2.  telnet 200-1 and 300-1, run /home/spm/as-union/box/output/ box,
       start filtering.

   3.  telnet ASC2 and ASC3, run /home/spm/as-union/control/outbox/
       control.

   4.  telnet RegS, run /home/spm/as-union/register/output/register

   Then A3 in AS300 send packets with its real address to MS in AS200.

   Telnet 200-2, watch the packet content at eth0 with tcpdump.

   Telnet ASC and input 'del' to delete the address space of A3.

   At last, telnet 200-2, use tcpdump to watch the packets from eth0 of
   200-2.

4.1.1.7.2.  Expected result

   The Source IP Authentication Union supports management of the address
   space.  The member AS may omit a used address space, it could request
   the registration server to delete the old address space.  This
   experiment tests this situation.  Before ASC3 deletes the address
   space, packet arriving 200-2 has a signature (flag).  After the



Wu, et al.               Expires January 4, 2008               [Page 26]

Internet-Draft                SAVA Testbed                      Jul 2007


   address space is deleted, packet arriving 200-2 has no signature any
   more.  This proves that address space can be deleted correctly.

4.1.1.7.3.  Result

-----------------------------------------------------------------------------------------------
| SRC IP                | DST IP                  | Flag exist      | Flag exist     | Result |
|                       |                         | before deleted? | after deleted? |        |
|-------------------------------------------------|-----------------|----------------|--------|
| 3fffe:5555::7:f       | 2001:250:cccc:2::4:2    |  Yes            | No             | Pass   |
|----------------------------------------------------------------------------------------------

4.1.2.  TsingHua (Beijing) <--> GZU (GuangZhou) Test

4.1.2.1.  Tag Signature(flag) Test

4.1.2.1.1.  Test Content

   AS65001 and AS65002 deploy filtering devices THU-BOX and GZ-BOX.
   First, start the filtering solution.

   1.  ssh THU-BOX and GZ-BOX, run /home/spm/as-union/box/output/box

   2.  Input '5' and 'Enter', start filtering.

   3.  ssh control server THU-CTRL and GZ-CTRL, run /home/spm/as-union/
       control/output/control

   4.  ssh registration sever REG, run /home/spm/as-union/register/
       output/register

   Then telnet THU-CTRL, execute: ping6 2001:da8:e2::3

   At last, telnet THU-BOX, execute

   tcpdump -X -vvv host 2001:da8:e1::3 i eth0

   tcpdump -X -vvv host 2001:da8:e1::3 i eth1

   and watch packets getting into eth0 of THU-BOX and coming out of eth1
   of THU-BOX.

4.1.2.1.2.  Expected Result

   After AS65001 starts filtering, THU-BOX would tag a signature(type
   0x21, HOP-by-HOP) into each packet from AS65001.  The expected result
   is: the packet gets into eth0 have a ICMPv6 expand head after first
   40 bytes head, and the packet with the same seq number, which comes



Wu, et al.               Expires January 4, 2008               [Page 27]

Internet-Draft                SAVA Testbed                      Jul 2007


   out of eth1, should have a type 0x21 HOP-BY-HOP option after the
   first 40 bytes head, then is the ICMPv6 expand head.  This proves
   that the signature is tagged correctly.

4.1.2.1.3.  Result

--------------------------------------------------------------------------------------
|            | Source IP               | Hop-By-Hop Type  | Hop-By-Hop Flag | Result |
|------------------------------------------------------------------------------------|
|Packets     | 2001:da8:e1::4          |  NULL            |  NULL           |        |
| Received   |                         |                  |                 |        |
|---------------------------------------------------------------------------| PASS   |
|Packets     | 2001:da8:e1::4          |  0x21            | 51DC B074 FF5C  |        |
|Sent        |                         |                  |                 |        |
--------------------------------------------------------------------------------------

4.1.2.2.  Remove the Signature

4.1.2.2.1.  Test Content

   THU-BOX and GZ-BOX are filtering devices between AS65001 and AS65002.
   At first, start Inter-AS (intervening) filtering solution.

   1.  telnet THU-BOX and GZ-BOX, start /home/spm/as-union/box/output/
       box

   2.  Input '5' and enter to start filtering.

   3.  telnet THU-CTRL and GZ-CTRL, start /home/spm/as-union/control/
       output/control

   4.  telnet login server RegS, start /home/spm/as-union/register/
       output/register

   Telnet THU-CTRL, execute: ping6 2001:da8:e2::3

   Telnet GZ-BOX, excute:

   tcpdump -X -vvv host 2001:da8:e1::3 i eth0

   tcpdump -X -vvv host 2001:da8:e1::3 i eth1

   Watch packets getting into eth1 and coming out of eth0 of GZ-BOX.

4.1.2.2.2.  Expected Result

   When AS65001 and AS65002 starts filtering, GZ-BOX should receive
   packets with a flag from AS65001.  The flag is type 0x21 in HOP-by-



Wu, et al.               Expires January 4, 2008               [Page 28]

Internet-Draft                SAVA Testbed                      Jul 2007


   HOP option, including a 6 bytes label and 6 bytes PAD.  The expected
   result is: the packet gets into eth1 have a type 0x21 HOP-BY-HOP
   option after the first 40 bytes head, then is the ICMPv6 expand head.
   And the packet with the same seq number, which goes out of eth0,
   should have ICMPv6 expand head directly after the first 40 bytes
   head, this will prove that GZ-BOX removes this signature correctly.

4.1.2.2.3.  Result

   ------------------------------------------------------------
   |            | Hop-By-Hop Type  | Hop-By-Hop Flag | Result |
   |----------------------------------------------------------|
   |Packets     |  0x21            | 51DC B074 FF5C  |        |
   | Received   |                  |                 |        |
   |------------------------------------------------ | PASS   |
   |Packets     |  NULL            | NULL            |        |
   |Sent        |                  |                 |        |
   ------------------------------------------------------------

4.1.2.3.  Filtering of Forged Packets

4.1.2.3.1.  Test Content

   THU-BOX, GZ-BOX and PKU-BOX are filtering devices among
   AS65001,AS65002 and AS65005.  At first, start filtering devices:

   1.  ssh THU-BOX, GZ-BOX, PKU-BOX, run /home/spm/as-union/box/output/
       box

   2.  Input 5 and press 'enter', start filtering.

   3.  ssh THU-CRTL, PKU-CTRL, GZ-CTRL, run /home/spm/as-union/control/
       output/control

   4.  ssh Registration server REG, run /home/spm/as-union/register/
       output/register.

   Then connect SmartBits test device to AS65001 and configure the
   gateway as 2001:da8:e1::1.  SmartBits sends packets to
   2001:da8:e2::3, using forged source IP 2001:da8:e5:3::7:f.

   At last, ssh GZ-CTRL, execute tcpdump -X -vvv 2001:da8:e5:3::7:f.

4.1.2.3.2.  Expected Result

   AS65005 has joined the Source IP Authentication Union.  SmartBits
   device of AS65001 sends packets with forged source IP, which belongs
   to AS6005.  The packets won't contain the right signatures, hence



Wu, et al.               Expires January 4, 2008               [Page 29]

Internet-Draft                SAVA Testbed                      Jul 2007


   they would be filtered by GZ-BOX of AS65002

4.1.2.3.3.  Result

-----------------------------------------------------------------------|
| SRC IP of Packet      | DST IP of Packet        | Filtered? | Result |
|-------------------------------------------------|-----------|--------|
| 2001:da8:e5:0:0:0:7:f | 2001:da8:e2:0:0:0:0:3   |  Yes      | pass   |
|----------------------------------------------------------------------|

4.1.2.4.  Update Signature

4.1.2.4.1.  Test Content

   THU-BOX and GZ-BOX are filtering devices between AS65001 and AS65002.
   At first, start Inter-AS filtering solution.

   1.  ssh THU-BOX and GZ-BOX, start /home/spm/as-union/box/output/box

   2.  Input '5' and enter to start filtering.

   3.  ssh THU-CTRL and GZ-CTRL, start /home/spm/as-union/control/
       output/control

   4.  ssh registration server RegS, start /home/spm/as-union/register/
       output/register.

   Login THU-CTRL, execute: ping6 2001:da8:e2::3

   At last, login THU-BOX, execute: tcpdump -X -vvv host 2001:da8:e1::3
   > tmp.txt

   Last for 2T(time), T is the signature update period.

4.1.2.4.2.  Expected Result

   THU-BOX would tag signature to each outbound packet.  Find out the
   time of the first change of the signature t1 and the second change
   time t2, t2-t1 is close to signature period T.

4.1.2.4.3.  Result










Wu, et al.               Expires January 4, 2008               [Page 30]

Internet-Draft                SAVA Testbed                      Jul 2007


-------------------------------------------------------------------------------------------------
|T   | first change time | 1st Signature  | Second change time | 2nd flag       | Change period |
------------------------------------------------------------------------------------------------|
|60s | 18:46:19          | 51dc b074 ff5c | 18:47:27           | 4a94 e82a ec58 | 68s           |
-------------------------------------------------------------------------------------------------

4.1.2.5.  The protection for newly joined member AS

4.1.2.5.1.  Test Content

   THU-BOX and GZ-BOX are deployed between AS65001 and AS65002.
   Firstly, start the inter-AS filtering solution.

   1.  SSH the Register, and run /home/spm/as-union/register/output/
       register

   2.  SSH THU-BOX and GZ-BOX, and run /home/spm/as-union/box/output/box
       and enter '5' to begin filtering.

   3.  SSH THU-CTRL and GZ-CTRL, and run /home/spm/as-union/control/
       output/control

   Then, connect the testing apparatus SmartBits to the Switch in
   AS65001, and use it to send forged packets to GZ-CTRL in AS65002.
   The address of forged packets is set to 2001:da8:e5:3::7:f.

   Then, SSH to the GZ-CTRL, and execute: tcpdump -X -vvv host 2001:da8:
   e5:3::7:f

   Observe the captured packets to see whether the forged packets can
   reach the GZ-CTRL.

   After that, telnet PKU-BOX in AS65005, and run /home/spm/as-union/
   box/output/box

   Enter '5' to begin filtering.

   Then telnet PKU-CTRL in AS65005, run /home/spm/as-union/control/
   output/control

   Lastly, SSH to the GZ-CTRL, run tcpdump -X -vvv host
   2001:da8:e5:3::7:f

   Observe the captured packets to see whether the forged packets can
   reach the GZ-CTRL.






Wu, et al.               Expires January 4, 2008               [Page 31]

Internet-Draft                SAVA Testbed                      Jul 2007


4.1.2.5.2.  Expected Result

   The inter-AS filtering solution for intervening ASes supports the
   increment of AS members.  New AS can participate in the union when
   the policy is deployed.  The intention of this testing is to prove
   that the address of the participant AS can not be used to attack
   other ASes in the union.  We expect that before the PKU-BOX is
   started, forged packets can reach the PKU-CTRL, and after that, they
   can not.

4.1.2.5.3.  Result

------------------------------------------------------------------------------
| SRC IP                | DST IP                  | Filter | Filter | Result |
|                       |                         | Before?| After? |        |
|-------------------------------------------------|--------|--------|--------|
|2001:da8:e5::7:f       | 2001:da8:e2::3          |  No    | Yes    | Pass   |
|-----------------------------------------------------------------------------

4.1.2.6.  Add new address space

4.1.2.6.1.  Test Content

   THU-BOX, GZ-BOX and PKU-BOX are deployed among AS65001, AS65002 and
   AS65005.

   Firstly, start up the inter-AS filtering solution.

   1.  SSH Register REG, and run /home/spm/as-union/register/output/
       register

   2.  SSH THU-BOX, GZ-BOX and PKU-BOX, and run /home/spm/as-union/box/
       output/box And enter '5' to begin filtering.

   3.  SSH THU-CTRL ,GZ-CTRL and PKU-CTRL, and run /home/spm/as-union/
       control/output/control

   Then, connect the testing apparatus SmartBits to the Switch in
   AS65001, and use it to send forged packets to GZ-CTRL in AS65002.
   The source address of packets doesn't belong to any of the three ASes
   above.

   Then, SSH to the GZ-CTRL, and execute: tcpdump -X -vvv host 3ffe:
   5555::7:f

   Observe the captured packets to see whether the forged packets can
   reach the GZ-CTRL.




Wu, et al.               Expires January 4, 2008               [Page 32]

Internet-Draft                SAVA Testbed                      Jul 2007


   Then telnet PKU-CTRL in AS65005 and add the address space of the
   forged packets to its address space.

   Lastly, SSH to the GZ-CTRL, run tcpdump -X -vvv host 3ffe:5555::7:f

   Observe the captured packets to see whether the packets can reach the
   GZ-CTRL.

4.1.2.6.2.  Expected Result

   The inter-domain filtering policy for non-neighboring ASes supports
   the management of addresses.  The member AS can apply for protection
   of the newly applied address space.  The intention of this testing is
   to check whether the participant AS can add new address space.
   Before adding the new prefix into PKU-CTRL, spoofing packets can
   arrive at GZ-CTRL.  After the new prefix is added, spoofing packets
   disappear.  Then the support of this policy for address increment is
   proved.

4.1.2.6.3.  Result

------------------------------------------------------------------------------
| SRC IP                | DST IP                  | Filter | Filter | Result |
|                       |                         | Before?| After? |        |
|-------------------------------------------------|--------|--------|--------|
|3fffe:5555::7:f        | 2001:da8:e2::3          |  No    | Yes    | Pass   |
|-----------------------------------------------------------------------------

4.1.2.7.  Delete address space

4.1.2.7.1.  Test Content

   THU-BOX, GZ-BOX and PKU-BOX are deployed among AS65001, AS65002 and
   AS65005

   Firstly, start up the inter-AS filtering solution.

   1.  SSH Register REG, and run /home/spm/as-union/register/output/
       register

   2.  SSH THU-BOX, GZ-BOX and PKU-BOX, and run /home/spm/as-union/box/
       output/box And enter '5' to begin filtering.

   3.  SSH THU-CTRL ,GZ-CTRL and PKU-CTRL, and run /home/spm/as-union/
       control/output/control

   Then, connect the testing apparatus SmartBits to the Switch in
   AS65001, and use it to send packets to GZ-CTRL in AS65002.  The



Wu, et al.               Expires January 4, 2008               [Page 33]

Internet-Draft                SAVA Testbed                      Jul 2007


   address of packets is set to 3ffe:5555::7:f.

   Then, SSH to the GZ-CTRL, and run command: tcpdump -X -vvv host 3ffe:
   5555::7:f -I inet0

   Observe the captured packets to see the content of the packets.

   Then telnet THU-CTRL in AS65001,and delete the address space 3ffe:
   5555::0/64.

   Lastly, SSH to the GZ-CTRL, run tcpdump -X -vvv host 3ffe:5555::7:f
   -I inet0

   Observe the captured packets to see the content of packets.

4.1.2.7.2.  Expected result

   The inter-domain filtering policy for non-neighboring ASes supports
   the management of addresses.  An AS may partition its address space
   for some reason.  The intention of this testing is to check whether
   the participant AS can delete address space.  Before deleting the
   prefix in THU-CTRL, arriving packets have a label.  After the prefix
   is deleted, the label disappears.

4.1.2.7.3.  Result

-----------------------------------------------------------------------------------------------
| SRC IP                | DST IP                  | Flag exist      | Flag exist     | Result |
|                       |                         | before deleted? | after deleted? |        |
|-------------------------------------------------|-----------------|----------------|--------|
| 3fffe:5555::7:f       | 2001:da8:e2::3          |  Yes            | No             | Pass   |
|----------------------------------------------------------------------------------------------

4.2.  Inter-AS (neighbouring) SAVA Solution Test

4.2.1.  Initialization of deployment

4.2.1.1.  Test Content

   Filtering devices 100-1, 100-2, 200-1, 200-2, 300-1 and 300-2 are
   deployed on the links among AS100, AS200 and AS300.

   Start up VRGE.

   1.  telnet all the filtering devices, run /home/spm/as-union/box/
       output/box





Wu, et al.               Expires January 4, 2008               [Page 34]

Internet-Draft                SAVA Testbed                      Jul 2007


   2.  Enter '6' to begin filtering.

   3.  Telnet controller ASC1, ASC2 and ASC3, run /home/vrge/src/output/
       vrge

4.2.1.2.  Expected Result

   Every filtering device will receive the address prefix of the
   neighboring ASes.  E.g. the filtering table of 100-1 will contain the
   prefix of AS300.  (Enter '4' to check.)  The VRGE of every AS will
   send their prefixes to the neighboring ASes.  Enter 'rtShow' on VRGE
   console to check whether the prefixes are received.

4.2.1.3.  Result

   Prefix of AS100: 2001:250:cccc:1::1/64 Prefix of AS200: 2001:250:
   cccc:2::1/64 Prefix of AS300: 2001:250:cccc:3::1/64 Every filtering
   device only receives the prefix of neighboring AS. 100-1 receives
   prefix from AS300, and can not receive prefix from AS200.  Result:
   PASS

4.2.2.  Filtering of spoofed packets

4.2.2.1.  Test Content

   Filtering devices 100-1, 100-2, 200-1, 200-2, 300-1 and 300-2 are
   deployed on the links among AS100, AS200 and AS300.

   Firstly, start up filtering policy:

   1.  Telnet filtering devices, run /home/spm/as-union/box/output/box

   2.  Enter '6' to begin filtering.

   3.  Telnet ASC1, ASC2 and ASC3, run /home/vrge/src/output/vrge

   Then send forged packets to the media server MS from A3 in AS300,
   using a IP address not belonging to the address space of AS100, AS
   200 and AS300.

   Lastly, using tcpdump at MS to observe the receiving packets.

4.2.2.2.  Expected Result

   The filtering device drops the packets that are not in accord with
   the filtering rules.  MS in AS200 will not receive the forged
   packets.




Wu, et al.               Expires January 4, 2008               [Page 35]

Internet-Draft                SAVA Testbed                      Jul 2007


4.2.2.3.  Result

--------------------------------------------------------------------------|
| Spoofed SRC IP of Packet| DST IP of Spoofed Packet | Filtered? | Result |
|-------------------------|--------------------------|-----------|--------|
| 2001:250:cccc:10::7:f   | 2001:250:cccc:2::4:2     |  Yes      | pass   |
|-------------------------------------------------------------------------|

4.3.  Intra-domain SAVA Solution Test

4.3.1.  Testing the validity of intra-domain filtering

4.3.1.1.  Test Content

   200-4 is the router with intra-domain policy deployed.  A testing
   apparatus is connected to sub-Switch SW22, and its IP address is set
   to 2001:250:cccc:2::5:9.

   Firstly, send forged packets to MS with the address
   2001:250:cccc:2::4:2.  The source address of forged packets does not
   belong to 2001:250:cccc:2::5/112.  Use tcpdump at MS to observe the
   received packets.

   Then, stop sending packets.  Log on router 200-4 using serial port.
   Configure the router:

   o  200-4>enable

   o  200-4#configure t

   o  200-4#ipv6 access-list standard 2

   o  200-4#ipv6 host 2001:250:cccc:2::5::/112

   o  200-4#deny ipv6 any

   o  200-4# interface vlan 2

   o  200-4# ipv6 access-group 2 in

   Then restart sending forged packets, and observe packets arriving at
   MS using tcpdump.

4.3.1.2.  Expected Result

   Before router 200-4 starts intra-domain filtering, spoofing packets
   can pass 200-4, and reach MS.  After the filtering starts, MS can not
   receive spoofing packets.



Wu, et al.               Expires January 4, 2008               [Page 36]

Internet-Draft                SAVA Testbed                      Jul 2007


4.3.1.3.  Result

-------------------------------------------------------------------------------------
| Spoofed SRC IP of Packet| DST IP of Spoofed Packet | Filtered  | Filtered |Result |
|                         |                          | before?   | after?   |       |
|-------------------------|--------------------------|-----------|----------|-------|
| 2001:250:cccc:2::7:2    | 2001:250:cccc:2::4:2     |  No       | Yes      | Pass  |
|-----------------------------------------------------------------------------------|

4.4.  Access Network SAVA Solution Test

4.4.1.  Testing of authentication capability for access network

4.4.1.1.  Test Content

   Before applying for authentication, SmartBits sends packets with
   random source address.  After the failure of applying, SmartBits
   sends packets with random source address.

4.4.1.2.  Expected result

   Under the conditions described above, no packet can pass the Switch

4.4.1.3.  Result

----------------------------------------------------------------------------
|                       | SRC IP                 | Filtered?      | Result |
|-----------------------|------------------------|----------------|--------|
| Before Authentication | 2001:250:cccc:2::4:98f | Yes            |        |
------------------------------------------------------------------| Pass   |
| Authentication Fails  | 2001:250:cccc:2::4:98f | Yes            |        |
----------------------------------------------------------------------------

4.4.2.  The authenticated network access

4.4.2.1.  Test Content

   After the success of authentication, SmartBits sends packets with
   source IP address set to ADDRESS1, and source MAC address set to
   MAC1.  ADDRESS1 and MAC1 are both legal.

4.4.2.2.  Expected Result

   The packets can pass Switch.







Wu, et al.               Expires January 4, 2008               [Page 37]

Internet-Draft                SAVA Testbed                      Jul 2007


4.4.2.3.  Result

------------------------------------------------------------------------
| SRC IP Address          | SRC MAC Address   | Filtered?   | Result   |
|-------------------------|-------------------|-------------|----------|
| 2001:250:cccc:2::4:2315 | 00-15-c5-37-e1-eb | No          | Pass     |
------------------------------------------------------------------------

4.4.3.  The filtering of forged packets

4.4.3.1.  Test Content

   After the success of authentication, SmartBits sends these kinds of
   packets:

   o  Source IP Address = ADDRESS2, Source MAC Address = MAC1;

   o  Source IP Address = ADDRESS1, Source MAC Address = MAC2;

   o  Source IP Address = ADDRESS2, Source MAC Address = MAC2;

   (ADDRESS2!=ADDRESS1 && MAC2!=MAC1).

   ADDRESS1 and MAC1 are legal, but ADDRESS2 and MAC2 are forged.

4.4.3.2.  Expected Result

   None of the packets can pass Switch

4.4.3.3.  Result

   ADDRESS1: 2001:250:cccc:2::4:2315; MAC1: 00-15-c5-37-e1-eb; ADDRESS2:
   2001:250:cccc:2::4:98f; MAC2: 00-15-c5-37-e1-ec;
---------------------------------------------------------------------------------------
|                  | SRC IP                  | SRC MAC           | Filtered? | Result |
|------------------|-------------------------|-------------------|-----------|--------|
| ADDRESS2 - MAC1  | 2001:250:cccc:2::4:98f  | 00-15-c5-37-e1-eb | Yes       | Pass   |
|------------------|-------------------------|-------------------|-----------|--------|
| ADDRESS1 - MAC2  | 2001:250:cccc:2::4:2315 | 00-15-c5-37-e1-ec | Yes       | Pass   |
|------------------|-------------------------|-------------------|-----------|--------|
| ADDRESS2 - MAC2  | 2001:250:cccc:2::4:98f  | 00-15-c5-37-e1-ec | Yes       | Pass   |
---------------------------------------------------------------------------------------

4.5.  Stability Test of Filtering Device







Wu, et al.               Expires January 4, 2008               [Page 38]

Internet-Draft                SAVA Testbed                      Jul 2007


4.5.1.  Testing in the THU Trusty Internet Lab

4.5.1.1.  Stability for intervening ASes solution.

4.5.1.1.1.  Test Content

   Start up 200-2 to begin filtering using intervening policy.  Connect
   the interface 1 of SmartBits to SW31 in AS300, and connect interface
   2 to SW23.  The respective addresses are 2001:250:cccc:3::7:f and
   2001:250:cccc:2::4:f.  Start up a flow at interface 1, with
   destination set to 2001:250:cccc:2::4:f, and bit rate set to 20Mbps.
   The flow should last for 3 hours.  Check the flow received at
   interface 2.

4.5.1.1.2.  Expected Result

   The flow received at interface 2 should have a constant bit rate of
   about 20Mbps.  This proves the filtering device can process packets
   at the rate of 20Mbps.

4.5.1.1.3.  Result

-----------------------------------------------------------------------------
|              | Duration | Bitrate | Bytes   Sent | Bytes Received | Result |
|--------------|----------|---------|--------------|----------------|--------|
| Spoofed Flow | 3 hours  | 20 Mbps | 27435920000  | 0              | Pass   |
|--------------|----------|---------|--------------|----------------|--------|
| Legal Flow   | 3 hours  | 20 Mbps | 27435920000  | 27282710068    | Pass   |
------------------------------------------------------------------------------

4.5.1.2.  Stability for neighboring ASes solution.

4.5.1.2.1.  Test Content

   Start up 200-2 to begin filtering using neighboring policy.  Connect
   the interface 1 of SmartBits to SW31 in AS300, and connect interface
   2 to SW23.  The respective addresses are 2001:250:cccc:3::7:f and
   2001:250:cccc:2::4:f.  Start up a flow at interface 1, with
   destination set to 2001:250:cccc:2::4:f, source address set to 2001:
   250:cccc:3::7:f/120,and bit rate set to 20Mbps.  The flow should last
   for 3 hours.  Check the flow received at interface 2.

4.5.1.2.2.  Expected Result

   The flow received at interface 2 should have a constant bit rate of
   about 20Mbps.  This proves the filtering device can process packets
   at the rate of 20Mbps.




Wu, et al.               Expires January 4, 2008               [Page 39]

Internet-Draft                SAVA Testbed                      Jul 2007


4.5.1.2.3.  Result

-----------------------------------------------------------------------------
|              | Duration | Bitrate | Bytes   Sent | Bytes Received | Result |
|--------------|----------|---------|--------------|----------------|--------|
| Spoofed Flow | 3 hours  | 20 Mbps | 27282024704  | 0              | Pass   |
|--------------|----------|---------|--------------|----------------|--------|
| Legal Flow   | 3 hours  | 20 Mbps | 27282024704  | 27282024704    | Pass   |
------------------------------------------------------------------------------

4.5.2.  Deployment test between Tsinghua University(Beijing) and
        GZU(Guangzhou)

4.5.2.1.  Stability for intervening ASes solution

4.5.2.1.1.  Test Content

   Start up the GZ-BOX to begin filtering.  Connect the interface 1 of
   SmartBits to THU-SWITCH of AS65001, interface 2 to GZ-SWITCH of
   AS65002.  The addresses of these interfaces are 2001:da8:e1::f and
   2001:da8:e2::f.  Start up a stream to 2001:da9:e2::f at interface 1,
   with a bit rate of 20Mbps.  The stream should last for 3 hours.
   Check the flow at interface 2.

4.5.2.1.2.  Expected Result

   The bit rate of the receiving flow at interface 2 is always about
   20Mbps.  This proves that the filtering devices can process packets
   at a rate of 20Mbps stably.

4.5.2.1.3.  new section

   After the filtering is started, the flow between AS65001 and AS65002
   is limited to a rate of 1Mbps.  The flow rate can be 20Mbps if the
   filtering is shut down.  Most of the packets are dropped in the
   CERNET2 backbone.















Wu, et al.               Expires January 4, 2008               [Page 40]

Internet-Draft                SAVA Testbed                      Jul 2007


5.  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 January 4, 2008               [Page 41]

Internet-Draft                SAVA Testbed                      Jul 2007


6.  Security Considerations


















































Wu, et al.               Expires January 4, 2008               [Page 42]

Internet-Draft                SAVA Testbed                      Jul 2007


7.  Acknowledgements


















































Wu, et al.               Expires January 4, 2008               [Page 43]

Internet-Draft                SAVA Testbed                      Jul 2007


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

   [Gao]      Gao, L., "On Inferring Autonomous System Relationships in
              the Internet", Infocom 2001, December 2001.

   [I-D.wu-sava-framework]
              Wu, J., "Source Address Validation Architecture (SAVA)
              Framework", draft-wu-sava-framework-00 (work in progress),
              February 2007.

   [I-D.wu-sava-problem-statement]
              Wu, J., Bonica, R., Bi, J., Li, X., Ren, G., and M I.
              Williams, "Source Address Validation Architecture (SAVA)
              Problem Statement", February 2007.

   [I-D.wu-sava-solution-e2e-ipv6]
              Wu, J., "An End-to-end Source Address Validation Solution
              for IPv6", draft-wu-sava-solution-e2e-ipv6-00 (work in
              progress), February 2007.

























Wu, et al.               Expires January 4, 2008               [Page 44]

Internet-Draft                SAVA Testbed                      Jul 2007


Authors' Addresses

   Jianping Wu
   CERNET
   Network Center, Tsinghua University
   Beijing  100084
   China

   Email: jianping@cernet.edu.cn


   Jun Bi
   CERNET
   Network Center, Tsinghua University
   Beijing  100084
   China

   Email: junbi@cernet.edu.cn


   Xing Li
   CERNET
   Network Center, Tsinghua University
   Beijing  100084
   China

   Email: xing@cernet.edu.cn


   Gang Ren
   CERNET
   Network Center, Tsinghua University
   Beijing  100084
   China

   Email: rg03@mails.tsinghua.edu.cn


   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 January 4, 2008               [Page 45]

Internet-Draft                SAVA Testbed                      Jul 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 January 4, 2008               [Page 46]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/