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

Versions: 00 01 02 03 04 05 06 RFC 5210

Network Working Group                                              J. Wu
Internet-Draft                                                     J. Bi
Intended status: Experimental                        Tsinghua University
Expires: August 29, 2007                                     M. Williams
                                                        Juniper Networks
                                                            Feb 25, 2007


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

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 August 29, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (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 August 29, 2007                [Page 1]

Internet-Draft                SAVA Testbed                      Feb 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 in RFC 2119 [RFC2119].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  SAVA Testbed . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  CERNET2  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  SAVA Testbed on CERNET2 Infrastructure . . . . . . . . . .  3
   3.  SAVA Solutions Tested and Experiences  . . . . . . . . . . . .  5
     3.1.  Inter-ISP Case (Neighbouring AS) . . . . . . . . . . . . .  5
     3.2.  Inter-ISP Case (Intervening AS)  . . . . . . . . . . . . .  8
     3.3.  Intra-ISP (Access Network) Case  . . . . . . . . . . . . .  9
   4.  Test Experience  . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 13

























Wu, et al.               Expires August 29, 2007                [Page 2]

Internet-Draft                SAVA Testbed                      Feb 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.


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 August 29, 2007                [Page 3]

Internet-Draft                SAVA Testbed                      Feb 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 August 29, 2007                [Page 4]

Internet-Draft                SAVA Testbed                      Feb 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.

   to be added

              Figure 2: CERNET2 Overlay SAVA Test Environment

   to be added

       Figure 3: Tsinghua University Trustable Internet Test Network

   to be added

            Figure 4: Tsinghua University Network AS100 detail

   to be added

          Figure 5: Tsinghua University Test Network AS200 Detail

   to be added

          Figure 6: Tsinghua University Test Network AS300 Detail


3.  SAVA Solutions Tested and Experiences

3.1.  Inter-ISP Case (Neighbouring AS)










Wu, et al.               Expires August 29, 2007                [Page 5]

Internet-Draft                SAVA Testbed                      Feb 2007


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



Wu, et al.               Expires August 29, 2007                [Page 6]

Internet-Draft                SAVA Testbed                      Feb 2007


   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.

   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.





Wu, et al.               Expires August 29, 2007                [Page 7]

Internet-Draft                SAVA Testbed                      Feb 2007


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

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




Wu, et al.               Expires August 29, 2007                [Page 8]

Internet-Draft                SAVA Testbed                      Feb 2007


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



Wu, et al.               Expires August 29, 2007                [Page 9]

Internet-Draft                SAVA Testbed                      Feb 2007


   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.


4.  Test Experience

   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.


5.  IANA Considerations

   This document makes no request of IANA.

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


6.  Security Considerations


7.  Acknowledgements


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.



Wu, et al.               Expires August 29, 2007               [Page 10]

Internet-Draft                SAVA Testbed                      Feb 2007


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.


Authors' Addresses

   Jianping Wu
   Tsinghua University


   Phone:
   Fax:
   Email: jianping@cernet.edu.cn
   URI:


   Jun Bi
   Tsinghua University


   Phone:
   Fax:
   Email: junbi@tsinghua.edu.cn
   URI:










Wu, et al.               Expires August 29, 2007               [Page 11]

Internet-Draft                SAVA Testbed                      Feb 2007


   Mark Williams
   Juniper Networks


   Phone:
   Fax:
   Email: miw@juniper.net
   URI:











































Wu, et al.               Expires August 29, 2007               [Page 12]

Internet-Draft                SAVA Testbed                      Feb 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 August 29, 2007               [Page 13]


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