GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5210

Network Working Group J. Wu Request for Comments: 5210 J. Bi Category: Experimental X. Li

                                                                G. Ren
                                                                 K. Xu
                                                   Tsinghua University
                                                           M. Williams
                                                      Juniper Networks
                                                             June 2008
      A Source Address Validation Architecture (SAVA) Testbed
                     and Deployment Experience

Status of This Memo

 This memo defines an Experimental Protocol for the Internet
 community.  It does not specify an Internet standard of any kind.
 Discussion and suggestions for improvement are requested.
 Distribution of this memo is unlimited.

Abstract

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

Wu, et al. Experimental [Page 1] RFC 5210 SAVA Testbed June 2008

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
 2.  A Prototype SAVA Implementation  . . . . . . . . . . . . . . .  4
   2.1.  Solution Overview  . . . . . . . . . . . . . . . . . . . .  4
   2.2.  IP Source Address Validation in the Access Network . . . .  6
   2.3.  IP Source Address Validation at Intra-AS/Ingress Point . .  9
   2.4.  IP Source Address Validation in the Inter-AS Case
         (Neighboring AS) . . . . . . . . . . . . . . . . . . . . .  9
   2.5.  IP Source Address Validation in the Inter-AS Case
         (Non-Neighboring AS) . . . . . . . . . . . . . . . . . . . 12
 3.  SAVA Testbed . . . . . . . . . . . . . . . . . . . . . . . . . 15
   3.1.  CNGI-CERNET2 . . . . . . . . . . . . . . . . . . . . . . . 15
   3.2.  SAVA Testbed on CNGI-CERNET2 Infrastructure  . . . . . . . 16
 4.  Test Experience and Results  . . . . . . . . . . . . . . . . . 17
   4.1.  Test Scenarios . . . . . . . . . . . . . . . . . . . . . . 17
   4.2.  Test Results . . . . . . . . . . . . . . . . . . . . . . . 18
 5.  Limitations and Issues . . . . . . . . . . . . . . . . . . . . 18
   5.1.  General Issues . . . . . . . . . . . . . . . . . . . . . . 18
   5.2.  Security Issues  . . . . . . . . . . . . . . . . . . . . . 20
   5.3.  Protocol Details . . . . . . . . . . . . . . . . . . . . . 20
 6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21
 7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
 8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
 9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
   9.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
   9.2.  Informative References . . . . . . . . . . . . . . . . . . 23

Wu, et al. Experimental [Page 2] RFC 5210 SAVA Testbed June 2008

1. Introduction

 By design, the Internet forwards data packets solely based on the
 destination IP address.  The source IP address is not checked during
 the forwarding process in most cases.  This makes it easy for
 malicious hosts to spoof the source address of the IP packet.  We
 believe that it would be useful to enforce the validity of the source
 IP address for all the packets being forwarded.
 Enforcing the source IP address validity would help us achieve the
 following goals:
 o  Since packets which carry spoofed source addresses would not be
    forwarded, it would be impossible to launch network attacks that
    are enabled by using spoofed source addresses and more difficult
    to successfully carry out attacks enhanced or strengthened by the
    use of spoofed source addresses.
 o  Being able to assume that all packet source addresses are correct
    would allow traceback to be accomplished accurately and with
    confidence.  This would benefit network diagnosis, management,
    accounting, and applications.
 As part of the effort in developing a Source Address Validation
 Architecture (SAVA), we implemented a SAVA prototype and deployed the
 prototype in 12 ASes in an operational network as part of China Next
 Generation Internet (CNGI) Project [Wu07].  We conducted evaluation
 experiments.  In this document, we first describe the prototype
 solutions and then report experimental results.  We hope that this
 document can provide useful insights to those interested in the
 subject, and can serve as an initial input to future IETF effort in
 this area.
 In recent years, there have been a number of research and engineering
 efforts to design IP source address validation mechanisms, such as
 [RFC2827], [Park01], [Li02], [Brem05], and [Snoe01].  Our SAVA
 prototype implementation was inspired by some of the schemes from the
 proposed or existing solutions.
 The prototype implementation and experimental results presented in
 this report serve only as an input, and by no means preempt any
 solution development that may be carried out by future IETF effort.
 Indeed, the presented solutions are experimental approaches and have
 a number of limitations as discussed in Sections 5 and 6.

Wu, et al. Experimental [Page 3] RFC 5210 SAVA Testbed June 2008

2. A Prototype SAVA Implementation

2.1. Solution Overview

 A multiple-fence solution is proposed in this document.  That is,
 there are multiple points in the network at which the validity of a
 packet's source address can be checked.  This is because in the
 current single-fence model where source address validity is
 essentially checked only at ingress to the network, deployment has
 been inadequate to the point that there is always sufficient
 opportunity to mount attacks based on spoofed source addresses, and
 it seems likely that this condition will continue in the foreseeable
 future.  A multiple-fence solution will allow "holes" in deployment
 to be covered and validity of the source address to be evaluated with
 increased confidence across the whole Internet.  The assumption here
 is that when validity checking is not universal, it is still
 worthwhile to increase the confidence in the validity of source
 addresses and to reduce the opportunities to mount a source address
 spoofing attack.
 Furthermore, the architecture allows for multiple independent and
 loosely-coupled checking mechanisms.  The motivation for this is that
 in the Internet at large, it is unrealistic to expect any single IP
 source address validation mechanism to be universally supported.
 Different operators and vendors may choose to deploy/develop
 different mechanisms to achieve the same end, and there need to be
 different mechanisms to solve the problem at different places in the
 network.  Furthermore, implementation bugs or configuration errors
 could potentially render an implementation ineffective.  Therefore,
 our prototype SAVA implementation is a combination of multiple
 coexisting and cooperating mechanisms.  More specifically, we
 implement source IP address validation at three levels: access
 network source address validation; intra-AS source address
 validation; and inter-AS source address validation, as shown in
 Figure 1.  The system details can be found in [Wu07].

Wu, et al. Experimental [Page 4] RFC 5210 SAVA Testbed June 2008

                   __ ____                          __ ____
               .-''       `':                   .-''       `':
               |             |                  |             |
               |   +-+----+  |   Inter-AS SAV   |   +-+----+  |
               |   |Router+--+------------------+---|Router+  +
               |   +--.---+  |                  |   +--.---+  |
    Intra-AS   |      |       \      Intra-AS   |      |      |
       SAV     |   +--+---+    \        SAV     |   +--+---+  |
               |   |Router|     \               |   |Router|  |
               |   +--.---+      \               '_  +-----+  _
               |      |           \               `'-------'''
              /       |            \
             /        |             \
            | +---------------------+\
        ----+---------. Router      | \
            | ++-------\------------+  \
            |  |     |  \    |     |    |
            |  | +------+|+------++----+|Intra-AS
            |  | |Switch|||Switch||Host||SAV
            |  | +------+|+------++----+|
            |  |     |   |  |    \      |
            |+-+--++----+|+----++----+  |
            ||Host||Host|||Host||Host|  |
            `+----++----+|+----++----+ /
              `--.       |         _.-'
                  `------|------+''
               Access    |
               Network   |
                SAV
     Key:  SAV - Source Address Validation
                      Figure 1: Solution Overview
 This document divides source address validation into three different
 classes of solutions:
 1.  Access network.  This prevents a host in a network from spoofing
     the address of another host in the same network segment.  This
     enables host-granularity of protection compared to Intra-AS
     prevention.  See Section 2.2 for details.

Wu, et al. Experimental [Page 5] RFC 5210 SAVA Testbed June 2008

 2.  Intra-AS.  When the edge router of an access network performs
     source address validation (e.g., using [RFC2827] and [RFC3704]),
     hosts are prevented from spoofing an arbitrary address, but
     unless access network SAV is employed, they may be able to spoof
     an address of a host in the same network segment.  In a
     degenerate case, when a router connects a single host, the host
     can't spoof any address.
 3.  Inter-AS.  Mechanisms that enforce packet source address
     correctness at AS boundaries.  Because the global Internet has a
     mesh topology, and because different networks belong to different
     administrative authorities, IP source address validation at the
     Inter-AS level is more challenging.  Nevertheless, we believe
     this third level of protection is necessary to detect packets
     with spoofed source addresses, when the first two levels of
     source address validation are missing or ineffective.
 In the following sections, we describe the specific mechanisms
 implemented at each of the three levels in detail.

2.2. IP Source Address Validation in the Access Network

 At the access network level, the solution ensures the host inside the
 access network cannot use the source address of another host.  The
 host address should be a valid address assigned to the host
 statically or dynamically.  The solution implemented in the
 experiment provides such a function for Ethernet networks.  A layer-3
 source address validation architecture device (SAVA Device) for the
 access network (the device can be a function inside the Customer
 Premises Equipment (CPE) router or a separate device) is deployed at
 the exit of the access network.  Source address validation
 architecture agents (SAVA Agents) are deployed inside the access
 network.  (In fact, these agents could be a function inside the first
 hop router/switch connected to the hosts.)  A set of protocols was
 designed for communication between the host, SAVA Agent, and SAVA
 Device.  Only a packet originating from the host that was assigned
 that particular source address may pass through the SAVA Agent and
 SAVA Device.
 Two possible deployment variants exist; we will call them Variant A
 and Variant B.  In Variant A, an agent is mandatory and each host is
 attached to the agent on a dedicated physical port.  In Variant B,
 hosts are required to perform network access authentication and
 generate key material needed to protect each packet.  In this
 variant, the agent is optional.

Wu, et al. Experimental [Page 6] RFC 5210 SAVA Testbed June 2008

 The key function of Variant A is to create a dynamic binding between
 a switch port and valid source IP address, or a binding between Media
 Access Control (MAC) address, source IP address, and switch port.  In
 the prototype, this is established by having hosts employ a new
 address configuration protocol that the switch is capable of
 tracking.
 Note:  In a production environment, the approach in the prototype
    would not be sufficient due to reasons discussed in Section 5.
 In Variant A, there are three main participants: Source Address
 Request Client (SARC) on the host, Source Address Validation Proxy
 (SAVP) on the switch, and Source Address Management Server (SAMS). as
 shown in Figure 2.  The solution follows the basic steps below:
 1.  The SARC on the end host sends an IP address request.  The SAVP
     on the switch relays this request to the SAMS and records the MAC
     address and incoming port.  If the address has already been
     predetermined by the end host, the end host still needs to put
     that address in the request message for verification by SAMS.
 2.  After the SAMS receives the IP address request, it then allocates
     a source address for that SARC based on the address allocation
     and management policy of the access network, it stores the
     allocation of the IP address in the SAMS history database for
     traceback, then sends response message containing the allocated
     address to the SARC.
 3.  After the SAVP on the access switch receives the response, it
     binds the IP address and the former stored MAC address of the
     request message with the switch port on the binding table.  Then,
     it forwards the issued address to SARC on the end host.
 4.  The access switch begins to filter packets sent from the end
     host.  Packets which do not conform to the tuple (IP address,
     Switch Port) are discarded.

Wu, et al. Experimental [Page 7] RFC 5210 SAVA Testbed June 2008

  1. —————

| SERVER |

                       |    -------    |
                       |    | SAMS |   |
                       |    --------   |
                       -----------------
                               |
                               |
                       ----------------
                       | SWITCH        |
                       |    -------    |
                       |    | SAVP |   |
                       |    --------   |
                       -----------------
                               |
                               |
                       ----------------
                       | END HOST      |
                       |    -------    |
                       |    | SARC |   |
                       |    --------   |
                       -----------------
       Key:     SARC - Source Address Request Client
                SAVP - Source Address Validation Proxy
                SAMS - Source Address Management Sever
         Figure 2: Binding-Based IP Source Address Validation
                         in the Access Network
 The main idea of Variant B is to employ key material from network
 access authentication for some additional validation process.  A
 session key is derived for each host connecting to the network, and
 each packet sent by the host has cryptographic protection that
 employs this session key.  After establishing which host the packet
 comes from, it again becomes possible to track whether the addresses
 allocated to the host match those used by the host.  The mechanism
 details can be found in [XBW07], but the process follows these basic
 steps:
 1.  When a host wants to establish connectivity, it needs to perform
     network access authentication.
 2.  The network access devices provide the SAVA Agent (often co-
     located) a session key S.  This key is further distributed to the
     SAVA Device.  The SAVA Device binds the session key and the
     host's IP address.

Wu, et al. Experimental [Page 8] RFC 5210 SAVA Testbed June 2008

 3.  When the host sends packet M to somewhere outside the access
     network, either the host or the SAVA Agent needs to generate a
     message authentication code for each using key S and packet M.
      In the prototype, the message authentication code is carried in
     an experimental IPv6 extension header.
 4.  The SAVA Device uses the session key to authenticate the
     signature carried in the packet so that it can validate the
     source address.
 In our testbed, we implemented and tested both solutions.  The
 switch-based solution has better performance, but the switches in the
 access network would need to be upgraded (usually the number of
 switches in an access network is large).  The signature-based
 solution could be deployed between the host and the exit router, but
 it has some extra cost in inserting and validating the signature.

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

 We adopted the solution of the source address validation of IP
 packets at ingress points described in [RFC2827] and [RFC3704]; the
 latter describes source address validation at the ingress points of
 multi-homed access networks.

2.4. IP Source Address Validation in the Inter-AS Case (Neighboring AS)

 Our design for the Inter-AS Source Address Validation included the
 following characteristics: It should cooperate among different ASes
 with different administrative authorities and different interests.
 It should be lightweight enough to support high throughput and not to
 influence forwarding efficiency.
 The inter-AS level of SAVA can be classified into two sub-cases:
 o  Two SAVA-compliant ASes exchanging traffic are directly connected;
 o  Two SAVA-compliant ASes are separated by one or more intervening,
    non-SAVA-compliant providers.

Wu, et al. Experimental [Page 9] RFC 5210 SAVA Testbed June 2008

  1. ——–

| AIMS |

  1. —–|-

|

  1. ————- ———–|—–

| AS-4 |——– ——–| AS-1 | |——- Global

 | ------      |ASBR,VE|->|ASBR,VE|    ------|-   |ASBR,VE|--->IPv6
 | |VRGE|      |--------  --------|    | VRGE |   |-------     Network
 | ------      |                  |    --------   |
 ---------------            ----- -----------------
                            |ASBR,VE|    |ASBR,VE|
                            ---------    ---------
                             /             |
                            /              |
                           /               |
                          /                |
                      ----------        --------
                      |ASBR, VE|        |ASBR,VE|
                 ---------------      -------------
                 |   AS-2      |      |  AS-3     |
                 |  -----      |      |   -----   |
                 |  |VRGE|     |      |  |VRGE|   |
                 |  -----      |      |  ------   |
                 ---------------      -------------
        Key:     AIMS - AS-IPv6 prefix Mapping Server
                 ASBR - AS Border Router
                 VE   - Validating Engine
                 VR   - Validation Rule
                 VRGE - Validation Rule Generating Engine
             Figure 3: Inter-ISP (Neighboring AS) Solution
 Two ASes that exchange traffic have a customer-to-provider, provider-
 to-customer, peer-to-peer, or sibling-to-sibling relationship.  In a
 customer-to-provider or provider-to-customer relationship, the
 customer typically belongs to a smaller administrative domain that
 pays a larger administrative domain for access to the rest of
 Internet.  The provider is an AS that belongs to the larger
 administrative domain.  In a peer-to-peer relationship, the two peers
 typically belong to administrative domains of comparable size and
 find it mutually advantageous to exchange traffic between their
 respective customers.  Two ASes have a sibling-to-sibling
 relationship if they belong to the same administrative domain or to
 administrative domains that have a mutual-transit agreement.

Wu, et al. Experimental [Page 10] RFC 5210 SAVA Testbed June 2008

 An AS-relation-based mechanism is used for neighboring SAVA-compliant
 ASes.  The basic ideas of this AS-relation-based mechanism are as
 follows.  It builds a VR table that associates each incoming
 interface of a router with a set of valid source address blocks, and
 then uses it to filter spoofed packets.
 In the solution implemented on the testbed, the solution for the
 validation of IPv6 prefixes is separated into three functional
 modules: The Validation Rule Generating Engine (VRGE), the Validation
 Engine (VE), and the AS-IPv6 prefix Mapping Server (AIMS).
 Validation rules that are generated by the VRGE are expressed as IPv6
 address prefixes.
 The VRGE generates validation rules that are derived according to
 Table 1, and each AS has a VRGE.  The VE loads validation rules
 generated by VRGE to filter packets passed between ASes (in the case
 of Figure 3, from neighboring ASes into AS-1).  In the SAVA testbed,
 the VE is implemented as a simulated layer-2 device on a Linux-based
 machine inserted into the data path just outside each ASBR interface
 that faces a neighboring AS.  In a real-world implementation, it
 would probably be implemented as a packet-filtering set on the ASBR.
 The AS-IPv6 prefix mapping server is also implemented on a Linux
 machine and derives a mapping between an IPv6 prefix and the AS
 number of that prefix.
----------------------------------------------------------------------
|   \Export| Own     | Customer's| Sibling's | Provider's | Peer's   |
|To  \     | Address | Address   | Address   | Address    | Address  |
|-----\--------------------------------------------------------------|
| Provider |    Y    |     Y     |     Y     |            |          |
|--------------------------------------------------------------------|
| Customer |    Y    |     Y     |     Y     |     Y      |    Y     |
|--------------------------------------------------------------------|
| Peer     |    Y    |     Y     |     Y     |            |          |
|--------------------------------------------------------------------|
| Sibling  |    Y    |     Y     |     Y     |     Y      |    Y     |
----------------------------------------------------------------------
         Table 1: AS-Relation-Based Inter-AS Filtering
 Different ASes exchange and transmit VR information using the AS-
 Relation-Based Export Rules in the VRGE.  As per Table 1, an AS
 exports the address prefixes of itself, its customers, its providers,
 its siblings, and its peers to its customers and siblings as valid
 prefixes, while it only exports the address prefixes of itself, its
 customers, and its siblings to its providers and peers as valid
 prefixes.  With the support of the AS-IPv6 prefix mapping server,
 only AS numbers of valid address prefixes are transferred between
 ASes, and the AS number is mapped to address prefixes at the VRGE.

Wu, et al. Experimental [Page 11] RFC 5210 SAVA Testbed June 2008

 Only changes of AS relation and changes of IP address prefixes
 belonging to an AS require the generation of VR updates.
 The procedure's principal steps are as follows (starting from AS-1 in
 Figure 3):
 1.  When the VRGE has initialized, it reads its neighboring SAVA-
     compliant AS table and establishes connections to all the VEs in
     its own AS.
 2.  The VRGE initiates a VR renewal.  According to its export table,
     it sends its own originated VR to VRGEs of neighboring ASes.  In
     this process, VRs are expressed as AS numbers.
 3.  When a VRGE receives a new VR from its neighbor, it uses its own
     export table to decide whether it should accept the VR and, if it
     accepts a VR, whether or not it should re-export the VR to other
     neighboring ASes.
 4.  If the VRGE accepts a VR, it uses the AIMS to transform the AS-
     expressed VR into an IPv6 prefix-expressed VR.
 5.  The VRGE pushes the VR to all the VEs in its AS.
 The VEs use these prefix-based VRs to validate the source IP
 addresses of incoming packets.

2.5. IP Source Address Validation in the Inter-AS Case

    (Non-Neighboring AS)
 In the case where two ASes do not exchange packets directly, it is
 not possible to deploy a solution like that described in the previous
 section.  However, it is highly desirable for non-neighboring ISPs to
 be able to form a trust alliance such that packets leaving one AS
 will be recognized by the other and inherit the validation status
 they possessed on leaving the first AS.  There is more than one way
 to do this.  For the SAVA experiments to date, an authentication tag
 method has been used.  This solution is inspired by the work of
 [Brem05].
 The key elements of this lightweight authentication tag based
 mechanism are as follows: For each pair of SAVA-compliant ASes, there
 is a pair of unique temporary authentication tags.  All SAVA-
 compliant ASes together form a SAVA AS Alliance.  When a packet is
 leaving its own AS, if the destination IP address belongs to an AS in
 the SAVA AS Alliance, the edge router of this AS looks up the
 authentication tag using the destination AS number as the key, and
 adds an authentication tag to the packet.  When a packet arrives at

Wu, et al. Experimental [Page 12] RFC 5210 SAVA Testbed June 2008

 the destination AS, if the source address of the packet belongs to an
 AS in the SAVA AS Alliance, the edge router of the destination AS
 searches its table for the authentication tag using the source AS
 number as the key, and the authentication tag carried in the packet
 is verified and removed.  As suggested by its name, this particular
 method uses a lightweight authentication tag.  For every packet
 forwarded, the authentication tag can be put in an IPv6 hop-by-hop
 extension header.  It is reasonable to use a 128-bit shared random
 number as the authentication tag to save the processing overhead
 brought by using a cryptographic method to generate the
 authentication tag.
 The benefit of this scheme compared to merely turning on local
 address validation (such as RFC 2827) is as follows: when local
 address validation is employed within a group of networks, it is
 assured that their networks do not send spoofed packets.  But other
 networks may still do this.  With the above scheme, however, this
 capability is eliminated.  If someone outside the alliance spoofs a
 packet using a source address from someone within the alliance, the
 members of the alliance refuse to accept such a packet.
                              +-----+
            .-----------------+ REG |-----------------.
            |                 +-----+                 |
            |                                         |
      ,-----+--------                          ,------+-------
    ,'     `|        `.                      ,'     ` |       `.
   /        |         \                     /         |         \
  /         |          \                   /          |          \
 ;       +--'--+      +----+             +----+     +-----+       ;
 |       | ASC +------+ASBR|             |ASBR+-----+ ASC |       |
 :       +--.--+      +----+`            +----+     +--+--+       :
  \         |__________________________________________|         /
   \                   /                    \                   /
    `.               ,'                      `.               ,'
      '-------------'                          '-------------'
           AS-1                                     AS-2
               Key:   REG  - Registration Server
                      ASC  - AS Control Server
                      ASBR - AS Border Router
           Figure 4: Inter-AS (Non-Neighboring AS) Solution
 There are three major components in the system: the Registration
 Server (REG), the AS Control Server (ASC), and the AS Border Router
 (ASBR).

Wu, et al. Experimental [Page 13] RFC 5210 SAVA Testbed June 2008

 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  Notifies each AS Control Server when the member list is changed.
 Each AS deploying the method has an AS Control Server.  The AS
 Control Server has three major functions:
 o  Communicates with the Registration Server, to get the up-to-date
    member list of TA.
 o  Communicates with the AS Control Server in other member ASes in
    the TA, to exchange updates of prefix ownership information and to
    exchange authentication tags.
 o  Communicates with all AS Border Routers of the local AS, to
    configure the processing component on the AS Border Routers.
 The AS Border Router does the work of adding the authentication tag
 to the packet at the sending AS, and the work of verifying and
 removing the authentication tag at the destination AS.
 In the design of this system, in order to decrease the burden on the
 REG, most of the control traffic happens between ASCs.
 The authentication tag needs to be changed periodically.  Although
 the overhead of maintaining and exchanging authentication tags
 between AS pairs is O(N) from the point of view of one AS, rather
 than O(N^2), the traffic and processing overhead do increase as the
 number of ASes increases.  Therefore, an automatic authentication tag
 refresh mechanism is utilized in this solution.  In this mechanism,
 each peer runs the same algorithm to automatically generate an
 authentication tag sequence.  Then the authentication tag in packets
 can be changed automatically with high frequency.  To enhance the
 security, a seed is used for the algorithm to generate an
 authentication tag sequence robust against guessing.  Thus, the peers
 need only to negotiate and change the seed at very low frequency.
 This lowers the overhead associated with frequently negotiating and
 changing the authentication tag while maintaining acceptable
 security.
 Since the authentication tag is put in an IPv6 hop-by-hop extension
 header, the MTU issues should be considered.  Currently we have two
 solutions to this problem.  Neither of the solutions is perfect, but

Wu, et al. Experimental [Page 14] RFC 5210 SAVA Testbed June 2008

 they are both feasible.  One possible way is to set the MTU at the
 ASBR to be 1280 bytes, which is the minimum MTU for the IPv6.  Thus,
 there should be no ICMP "Packet Too Big" message received from the
 downstream gateways.  The disadvantage of this solution is that it
 doesn't make good use of the available MTU.  The other possible way
 is to let the ASBR catch all incoming ICMP "Packet Too Big" messages,
 and decrease the value in the MTU field before forwarding it into the
 AS.  The advantage of this solution is that it can make good use of
 the available MTU.  But such processing of ICMP packets at the ASBR
 may create a target for a denial-of-service (DoS) attack.
 Because the authentication tag is validated at the border router of
 the destination AS, not the destination host, the destination options
 header is not chosen to carry the authentication tag.
 Authentication tag management is a critical issue.  Our work focused
 on two points: tag negotiation and tag refresh.  The tag negotiation
 happens between the ASCs of a pair of ASes in the SAVA AS Alliance.
 Considering the issue of synchronization and the incentive of
 enabling SAVA, receiver-driven tag negotiation is suggested.  It
 gives more decision power to the receiver AS rather than the sender
 AS.  With a receiver-driven scheme, the receiver AS can decide the
 policies of tag management.  The packets tagged with old
 authentication tags should not be allowed indefinitely.  Rather,
 after having negotiated a new tag, the old tag should be set to be
 invalid after a period of time.  The length of this period is a
 parameter that will control how long the old tag will be valid after
 the new tag has been assigned.  In the experiment, we used five
 seconds.
 The trust alliance is intended to be established dynamically (join
 and quit), but in this testbed we needed to confirm off-line the
 initial trust among alliance members.

3. SAVA Testbed

3.1. CNGI-CERNET2

 The prototypes of our solutions for SAVA are implemented and tested
 on CNGI-CERNET2.  CNGI-CERNET2 is one of the China Next Generation
 Internet (CNGI) backbones, operated by the China Education and
 Research Network (CERNET).  CNGI-CERNET2 connects 25 core nodes
 distributed in 20 cities in China at speeds of 2.5-10 Gb/s.  The
 CNGI-CERNET2 backbones are IPv6-only networks rather than being a
 mixed IPv4/IPv6 infrastructure.  Only some Customer Premises Networks
 (CPNs) are dual-stacked.  The CNGI-CERNET2 backbones, CNGI-CERNET2
 CPNs, and CNGI-6IX all have globally unique AS numbers.  Thus a
 multi-AS testbed environment is provided.

Wu, et al. Experimental [Page 15] RFC 5210 SAVA Testbed June 2008

3.2. SAVA Testbed on CNGI-CERNET2 Infrastructure

 It is intended that eventually the SAVA testbed will be implemented
 directly on the CNGI-CERNET2 backbone, but in the early stages the
 testbed has been implemented across 12 universities connected to
 CNGI-CERNET2.  First, this is because some of the algorithms need to
 be implemented in the testbed routers themselves, and to date they
 have not been implemented on any of the commercial routers forming
 the CNGI-CERNET2 backbone.  Second, since CNGI-CERNET2 is an
 operational backbone, any new protocols and networking techniques
 need to be tested in a non-disruptive way.
                             __
                           ,'  \                            _,...._
                          ,'    \____---------------+     ,'Beijing`.
                          /      \  | Inter-AS SAV  |-----| Univ    |
  +---------------+     |         | +---------------+     `-._____,'
  | Inter-AS SAV  +-----|         |
  +------.--------+     |  CNGI-  |                         _,...._
         |              | CERNET2 |__---------------+     ,Northeast`.
         |              |         | |Inter-AS SAV   |-----| Univ    |
 Tsinghua|University    | Backbone| +---------------+     `-._____,'
      ,,-|-._           |         |
    ,'   |   `.         |         |
  ,'+---------+\        |         |
 |  |Intra-AS | |       |         |      ...
 |  |   SAV   | |       |         |
 |  +---------+ |       |         |
 |       |      |       |         |                         _,...._
 |  +---------+ |       |         |__---------------+     ,Chongqing`.
 |  | Access  | |       |         | |Inter-AS SAV   |-----|Univ     |
 |  | Network | |       |         | +---------------+     `-._____,'
 |  |  SAV    | |       |         |
  \ +---------+.'        \       .'
   \          ,'          \      |
    `.      ,'             \    /
      ``---'                -_,'
                Key:  SAV - Source Address Validation
                  Figure 5: CNGI-CERNET2 SAVA Testbed
 In any case, the testbed is fully capable of functional testing of
 solutions for all parts of SAVA.  This includes testing procedures
 for ensuring the validity of IPv6 source addresses in the access
 network, in packets sent from the access network to an IPv6 service
 provider, in packets sent within one service provider's network, in

Wu, et al. Experimental [Page 16] RFC 5210 SAVA Testbed June 2008

 packets sent between neighboring service providers, and in packets
 sent between service providers separated by an intervening transit
 network.
 The testbed is distributed across 12 universities connected to CNGI-
 CERNET2.
 Each of the university installations is connected to the CNGI-CERNET2
 backbone through a set of inter-AS Source Address Validation
 prototype equipment and traffic monitoring equipment for test result
 display.
 Each university deployed one AS.  Six universities deployed all parts
 of the solution and are hence fully-featured, with validation at the
 inter-AS, intra-AS, and access network levels all able to be tested.
 In addition, a suite of applications that could be subject to
 spoofing attacks or that can be subverted to carry out spoofing
 attacks were installed on a variety of servers.  Two solutions for
 the access network were deployed.

4. Test Experience and Results

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

4.1. Test Scenarios

 For each of the test scenarios, we tested many cases.  Taking the
 Inter-AS (non-neighboring AS) SAVA solution test as an example, we
 classified the test cases into three classes: normal class, dynamic
 class, and anti-spoofing class.
 1.  For normal class, there are three cases: Adding authentication
     tag Test, Removing authentication tag Test, and Forwarding
     packets with valid source address.
 2.  For dynamic class, there are four cases: Updating the
     authentication tag between ASes, The protection for a newly
     joined member AS, Adding address space, and Deleting address
     space.
 3.  For anti-spoofing class, there is one case: Filtering of packets
     with forged IP addresses.
 As is shown in Figure 5, we have "multiple-fence" design for our SAVA
 testbed.  If source address validation is deployed in the access
 network, we can get a host granularity validation.  If source address

Wu, et al. Experimental [Page 17] RFC 5210 SAVA Testbed June 2008

 validation is deployed at the intra-AS level, we can guarantee that
 the packets sent from this point have a correct IP prefix.  If source
 address validation is deployed at the inter-AS level, we can
 guarantee that the packets sent from this point are from the correct
 AS.

4.2. Test Results

 1.  The test results are consistent with the expected ones.  For an
     AS that has fully-featured SAVA deployment with validation at the
     inter-AS, intra-AS, and access network levels, packets that do
     not hold an authenticated source address will not be forwarded in
     the network.  As a result, it is not possible to launch network
     attacks with spoofed source addresses.  Moreover, the traffic in
     the network can be traced back accurately.
 2.  For the Inter-AS (non-neighboring AS) SAVA solution, during the
     period of authentication tag update, the old and the new
     authentication tags are both valid for source address validation;
     thus, there is no packet loss.
 3.  For the Inter-AS (non-neighboring AS) SAVA solution, the
     validation function is implemented in software on a device
     running Linux, which simulates the source address validation
     functions of a router interface.  It is a layer-2 device because
     it needs to be transparent to the router interface.  During the
     test, when the devices were connected directly, normal line-rate
     forwarding was achieved.  When the devices were connected with
     routers from another vendor, only a very limited forwarding speed
     was achieved.  The reason is that the authentication tags are
     added on the IPv6 hop-by-hop option header, and many current
     routers can handle the hop-by-hop options only at a limited rate.

5. Limitations and Issues

 There are several issues both within this overall problem area and
 with the particular approach taken in the experiment.

5.1. General Issues

 There is a long-standing debate about whether the lack of universal
 deployment of source address validation is a technical issue that
 needs a technical solution, or if mere further deployment of existing
 tools (such as RFC 2827) would be a more cost effective way to
 improve the situation.  Further deployment efforts of this tool have
 proved to be slow, however.  Some of the solutions prototyped in this
 experiment allow a group of network operators to have additional
 protection for their networks while waiting for universal deployment

Wu, et al. Experimental [Page 18] RFC 5210 SAVA Testbed June 2008

 of simpler tools in the rest of the Internet.  This allows them to
 prevent spoofing attacks that the simple tools alone would not be
 able to prevent, even if already deployed within the group.
 Similarly, since a large fraction of current denial-of-service
 attacks can be launched by employing legitimate IP addresses
 belonging to botnet clients, even universal deployment of better
 source address validation techniques would be unable to prevent these
 attacks.  However, tracing these attacks would be easier given that
 there would be more reliance on the validity of source address.
 There is also a question about the optimal placement of the source
 address validation checks.  The simplest model is placing the checks
 on the border of a network.  Such RFC 2827-style checks are more
 widely deployed than full checks ensuring that all addresses within
 the network are correct.  It can be argued that it is sufficient to
 provide such coarse granularity checks, because this makes it at
 least possible to find the responsible network administrators.
 However, depending on the type of network in question, those
 administrators may or may not find it easy to track the specific
 offending machines or users.  It is obviously required that the
 administrators have a way to trace offending equipment or users --
 even if the network does not block spoofed packets in real-time.
 New technology for address validation would also face a number of
 deployment barriers.  For instance, all current technology can be
 locally and independently applied.  A system that requires global
 operation (such as the Inter-AS validation mechanism) would require
 significant coordination, deployment synchronization, configuration,
 key setup, and other issues, given the number of ASes.
 Similarly, deploying host-based access network address validation
 mechanisms requires host changes, and can generally be done only when
 the network owners are in control of all hosts.  Even then, the
 changing availability of the host for all types of products and
 platforms would likely prevent universal deployment even within a
 single network.
 There may be also be significant costs involved in some of these
 solutions.  For instance, in an environment where access network
 authentication is normally not required, employing an authentication-
 based access network address validation would require deployment of
 equipment capable of this authentication as well as credentials
 distribution for all devices.  Such undertaking is typically only
 initiated after careful evaluation of the costs and benefits
 involved.

Wu, et al. Experimental [Page 19] RFC 5210 SAVA Testbed June 2008

 Finally, all the presented solutions have issues in situations that
 go beyond a simple model of a host connecting to a network via the
 same single interface at all times.  Multihoming, failover, and some
 forms of mobility or wireless solutions may collide with the
 requirements of source address validation.  In general, dynamic
 changes to the attachment of hosts and topology of the routing
 infrastructure are something that would have to be handled in a
 production environment.

5.2. Security Issues

 The security vs. scalability of the authentication tags in the
 Inter-AS (non-neighboring AS) SAVA solution presents a difficult
 tradeoff.  Some analysis about the difficulty of guessing the
 authentication tag between two AS members was discussed in [Brem05].
 It is relatively difficult, even with using a random number as an
 "authentication tag".  The difficulty of guessing can be increased by
 increasing the length of the authentication tag.
 In any case, the random number approach is definitely vulnerable to
 attackers who are on the path between the two ASes.
 On the other hand, using an actual cryptographic hash in the packets
 will cause a significant increase in the amount of effort needed to
 forward a packet.  In general, addition of the option and the
 calculation of the authentication tag consume valuable resources on
 the forwarding path.  This resource usage comes on top of everything
 else that modern routers need to do at ever increasing line speeds.
 It is far from clear that the costs are worth the benefits.

5.3. Protocol Details

 In the current CNGI-CERNET2 SAVA testbed, a 128-bit authentication
 tag is placed in an IPv6 hop-by-hop option header.  The size of the
 packets increases with the authentication tags.  This by itself is
 expected to be acceptable, if the network administrator feels that
 the additional protection is needed.  The size increases may result
 in an MTU issue, and we found a way to resolve it in the testbed.
 Since an IPv6 hop-by-hop option header was chosen, the option header
 has to be examined by all intervening routers.  While in theory this
 should pose no concern, the test results show that many current
 routers handle hop-by-hop options with a much reduced throughput
 compared to normal traffic.
 The Inter-AS (neighboring AS) SAVA solution is based on the AS
 relation; thus, it may not synchronize with the dynamics of route
 changes very quickly and it may cause false positives.  Currently,

Wu, et al. Experimental [Page 20] RFC 5210 SAVA Testbed June 2008

 CNGI-CERNET2 is a relatively stable network, and this method works
 well in the testbed.  We will further study the impact of false
 positives in an unstable network.
 The access network address validation solution is merely one option
 among many.  Solutions appear to depend highly on the chosen link
 technology and network architecture.  For instance, source address
 validation on point-to-point links is easy and has generally been
 supported by implementations for years.  Validation in shared
 networks has been more problematic, but is increasing in importance
 given the use of Ethernet technology across administrative boundaries
 (such as in DSL).  In any case, the prototyped solution has a number
 of limitations, including the decision to use a new address
 configuration protocol.  In a production environment, a solution that
 is suitable for all IPv6 address assignment mechanisms would be
 needed.

6. Conclusion

 Several conclusions can be drawn from the experiment.
 First, the experiment is a proof that a prototype can be built that
 is deployable on loosely-coupled domains of test networks in a
 limited scale and "multiple-fence" design for source address
 validation.  The solution allows different validation granularities,
 and also allows different providers to use different solutions.  The
 coupling of components at different levels of granularity can be
 loose enough to allow component substitution.
 Incremental deployment is another design principle that was used in
 the experiment.  The tests have demonstrated that benefit is derived
 even when deployment is incomplete, thus giving providers an
 incentive to be early adopters.
 The experiment also provided a proof of concept for the switch-based
 local subnet validation, network authentication based validation,
 filter-based Inter-AS validation, and authentication tag-based
 Inter-AS validation mechanisms.  The client host and network
 equipment need to be modified and some new servers should be
 deployed.
 Nevertheless, as discussed in the previous section, there are a
 number of limitations, issues, and questions in the prototype designs
 and the overall source address validation space.

Wu, et al. Experimental [Page 21] RFC 5210 SAVA Testbed June 2008

 It is our hope that some of the experiences will help vendors and the
 Internet standards community in these efforts.  Future work in this
 space should attempt to answer some of the issues raised in
 Section 5.  Some of the key issues going forward include:
 o  Scalability questions and per-packet operations.
 o  Protocol design issues, such as integration to existing address
    allocation mechanisms, use of hop-by-hop headers, etc.
 o  Cost vs. benefit questions.  These may be ultimately answered only
    by actually employing some of these technologies in production
    networks.
 o  Trust establishment issue and study of false positives.
 o  Deployability considerations, e.g. modifiability of switches,
    hosts, etc.

7. Security Considerations

 The purpose of the document is to report experimental results.  Some
 security considerations of the solution mechanisms of the testbed are
 mentioned in the document, but are not the main problem to be
 described in this document.

8. Acknowledgements

 This experiment was conducted among 12 universities -- namely,
 Tsinghua University, Beijing University, Beijing University of Post
 and Telecommunications, Shanghai Jiaotong University, Huazhong
 University of Science and Technology in Wuhan, Southeast University
 in Nanjing, South China University of Technology in Guangzhou,
 Northeast University in Shenyang, Xi'an Jiaotong University, Shandong
 University in Jinan, University of Electronic Science and Technology
 of China in Chengdu, and Chongqing University.  The authors would
 like to thank everyone involved in this effort in these universities.
 The authors would like to thank Jari Arkko, Lixia Zhang, and Pekka
 Savola for their detailed review comments on this document, and thank
 Paul Ferguson and Ron Bonica for their valuable advice on the
 solution development and the testbed implementation.

Wu, et al. Experimental [Page 22] RFC 5210 SAVA Testbed June 2008

9. References

9.1. Normative References

 [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
            Defeating Denial of Service Attacks which employ IP Source
            Address Spoofing", BCP 38, RFC 2827, May 2000.
 [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
            Networks", BCP 84, RFC 3704, March 2004.

9.2. Informative References

 [Brem05]   Bremler-Barr, A. and H. Levy, "Spoofing Prevention
            Method", INFOCOM 2005.
 [Li02]     Li,, J., Mirkovic, J., Wang, M., Reiher, P., and L.
            Zhang, "SAVE: Source Address Validity Enforcement
            Protocol", INFOCOM  2002.
 [Park01]   Park, K. and H. Lee, "On the effectiveness of route-based
            packet filtering for distributed DoS attack prevention in
            power-law internets", SIGCOMM 2001.
 [Snoe01]   Snoeren, A., Partridge, C., Sanchez, L., and C. Jones, "A
            Hash-based IP traceback", SIGCOMM 2001.
 [Wu07]     Wu, J., Ren, G., and X. Li, "Source Address Validation:
            Architecture and Protocol Design", ICNP 2007.
 [XBW07]    Xie, L., Bi, J., and J. Wu, "An Authentication based
            Source Address Spoofing Prevention Method Deployed in IPv6
            Edge Network", ICCS 2007.

Wu, et al. Experimental [Page 23] RFC 5210 SAVA Testbed June 2008

Authors' Addresses

 Jianping Wu
 Tsinghua University
 Computer Science, Tsinghua University
 Beijing  100084
 China
 EMail: jianping@cernet.edu.cn
 Jun Bi
 Tsinghua University
 Network Research Center, Tsinghua University
 Beijing  100084
 China
 EMail: junbi@cernet.edu.cn
 Xing Li
 Tsinghua University
 Electronic Engineering, Tsinghua University
 Beijing  100084
 China
 EMail: xing@cernet.edu.cn
 Gang Ren
 Tsinghua University
 Computer Science, Tsinghua University
 Beijing  100084
 China
 EMail: rg03@mails.tsinghua.edu.cn
 Ke Xu
 Tsinghua University
 Computer Science, Tsinghua University
 Beijing  100084
 China
 EMail: xuke@csnet1.cs.tsinghua.edu.cn
 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. Experimental [Page 24] RFC 5210 SAVA Testbed June 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Wu, et al. Experimental [Page 25]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5210.txt · Last modified: 2008/06/25 01:19 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki