Internet DRAFT - draft-wu-sava-framework

draft-wu-sava-framework






Network Working Group                                              J. Wu
Internet-Draft                                                     J. Bi
Intended status: Informational                                    G. Ren
Expires: December 8, 2007                                          X. Li
                                                                  CERNET
                                                             M. Williams
                                                               R. Bonica
                                                        Juniper Networks
                                                            June 6, 2007


        Source Address Validation Architecture (SAVA) Framework
                     draft-wu-sava-framework-01.txt

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 December 8, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document presents the framework for SAVA (Source Address
   Validation Architecture).




Wu, et al.              Expires December 8, 2007                [Page 1]

Internet-Draft               SAVA Framework                    June 2007


Table of Contents

   1.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Mechanism Considerations and Definitions . . . . . . . . . . .  4
     3.1.  Forwarding vs. Control Plane Mechanism Components  . . . .  4
     3.2.  Packet "SAVA Status" . . . . . . . . . . . . . . . . . . .  5
     3.3.  Implicit vs Explicit Communication . . . . . . . . . . . .  6
   4.  SAVA Framework Hierarchy . . . . . . . . . . . . . . . . . . .  6
     4.1.  First-Hop, Local Subnet Source Validation  . . . . . . . .  7
       4.1.1.  Description  . . . . . . . . . . . . . . . . . . . . .  7
       4.1.2.  Discussion of Scenarios  . . . . . . . . . . . . . . .  8
         4.1.2.1.  Enterprise Networks Connecting to Service
                   Provider . . . . . . . . . . . . . . . . . . . . .  8
         4.1.2.2.  Multihomed Enterprise Network  . . . . . . . . . .  8
         4.1.2.3.  Home Broadband Access  . . . . . . . . . . . . . .  9
         4.1.2.4.  Access from a Wireless Mobile Device . . . . . . .  9
         4.1.2.5.  Other Mobility Scenarios . . . . . . . . . . . . .  9
     4.2.  Intra-AS Communication of SAVA Validation  . . . . . . . .  9
       4.2.1.  Mechanism Requirements . . . . . . . . . . . . . . . .  9
     4.3.  Inter-AS Communication of SAVA Validation  . . . . . . . . 11
       4.3.1.  Mechanism Requirements . . . . . . . . . . . . . . . . 11
         4.3.1.1.  Communication Between Adjacent SAVA-compliant
                   Providers  . . . . . . . . . . . . . . . . . . . . 12
         4.3.1.2.  Communication Between Non-Adjacent
                   SAVA-Compliant Providers . . . . . . . . . . . . . 12
         4.3.1.3.  Communication between a SAVA-Compliant
                   Provider and a SAVA-non-Compliant Provider . . . . 13
       4.3.2.  Design Considerations  . . . . . . . . . . . . . . . . 13
     4.4.  End-End  . . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   5.  SAVA Design Goals  . . . . . . . . . . . . . . . . . . . . . . 13
     5.1.  Performance  . . . . . . . . . . . . . . . . . . . . . . . 13
     5.2.  Economically Feasible  . . . . . . . . . . . . . . . . . . 14
     5.3.  Scaling  . . . . . . . . . . . . . . . . . . . . . . . . . 14
     5.4.  Hierarchical Solution  . . . . . . . . . . . . . . . . . . 14
     5.5.  Incrementally Deployable . . . . . . . . . . . . . . . . . 14
     5.6.  Incomplete Deployment Still Beneficial . . . . . . . . . . 14
     5.7.  Loose Component Coupling . . . . . . . . . . . . . . . . . 15
     5.8.  Solution for IPv6 and IPv4 . . . . . . . . . . . . . . . . 15
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 18



Wu, et al.              Expires December 8, 2007                [Page 2]

Internet-Draft               SAVA Framework                    June 2007


1.  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].


2.  Introduction

   The lack of source IP address checking makes it easier than it should
   be for the attackers to spoof source addresses in the Internet.
   [I-D.wu-sava-problem-statement].  A "Source Address Validation
   Architecture" is proposed as a framework within which to specify
   minimum required functionality and, where necessary, specify
   mechanisms and protocols to:

   o  guarantee validity of source addresses in packets accepted for
      transmission;

   o  communicate within and between administrative domains the degree
      of assurance that exists as to the validity of source addresses in
      each packet; and

   o  communicate with authorized entities as to the validation status
      of packets emitted from administrative domains.

   For the purposes of SAVA, a packet is said to contain a valid source
   address if:

   o  it has been injected into the network by an entity authorized to
      use that source address at that point of injection;

   o  the source address has been appropriately allocated;

   o  the route to that source address has been injected into the global
      routing tables by an entity authorized to do so;

   o  except in cases where global uniqueness is specifically excluded,
      the source address is globally unique; and

   o  the packet is traceable to its origin using the source address.
      (That is, information about the address's location and ownership
      is verifiable and correct.)

   This document deals with the requirements for establishing, enforcing
   and communicating the validity of IPv4 and IPv6 packets under the
   SAVA framework from an access connection, through an access network
   to a service provider, optionally across transit service providers



Wu, et al.              Expires December 8, 2007                [Page 3]

Internet-Draft               SAVA Framework                    June 2007


   and ultimately across another access network to the packet's
   destination

   This doecument does not deal with specific mechanisms for the above
   but provides a framework within which mechanisms can be specified,
   developed and deployed.


3.  Mechanism Considerations and Definitions

   This section, while it does not specify or mandate any mechanisms,
   defines some structures and defnitions for the classification and
   evaluation of mechanisms.

3.1.  Forwarding vs. Control Plane Mechanism Components

   SAVA mechanism components can be categorised into forwarding-plane
   components and control-plane components.  Mechanisms may contain one
   or both types of component.  Forwarding components are those
   components which lie in the forwarding path and which are required to
   operate on every packet forwarded.  Control components are this
   components that operate on data structures such as routing tables
   that are not in the forwarding path and are not related to packet-by-
   packet processing.

   Some examples of forwarding plane components:

   o  uRPF - a reverse path forwarding check component.

   o  Packet Filters

   o  Signature Insertion - a network element inserts a signature into a
      departing packet

   o  Signature Verification - another network element verifies a
      signature in an arriving packet.

   Some examples of comtrol plane components:

   o  Generation and Distribution of Validation Rules - A component
      generates validation rules and distributes the rules to other
      control components.  These rules might, for example, define valid
      incoming interfaces for packets with a given source prefix.

   o  Generation and Distribution of Authentication Information - A
      component generates authentication information and distributes the
      information to other control components.  Examples of
      authentication information could be signatures for insertion into



Wu, et al.              Expires December 8, 2007                [Page 4]

Internet-Draft               SAVA Framework                    June 2007


      departing packets, credentials for control components to exchange
      in order to verify identity, etc.

   Control plane components in general have the advantage of being able
   to be implemented in software, either in the control planes of
   existing network forwarding elements or in servers external to
   existing network elements.  As such, it is usually more feasible to
   implement control plane components in existing networks using
   multiple types of hardware.

   Forwarding plane components typically need to be implemented in
   hardware (or at least in microcode) on line cards.  Unless they are
   very simple or only need to be deployed in a small number of places
   in the network, new forwarding plane components are likely only to be
   deployable in the long term.  A number of potentially useful
   forwarding plane components already exist, however.

3.2.  Packet "SAVA Status"

   At any given time, a packet will have one of four possible "SAVA
   statuses".  It should be noted that the "SAVA status" of a packet may
   be explicit (e.g. through marking the packet in some way) or it may
   be implicit (e.g. through being able to infer the status of a packet
   from the fact that it is delivered or the manner of its delivery.)
   This framework document places no constraint on the mechanism of
   communication.

   o  Strict-Validated: A packet is said to be SAVA "strict-validated"
      if it can be proven that the packet was sent with a valid source
      address and has not been altered in transit, and furthermore, the
      packet can be traced back to an individual host that is authorized
      to emit packets with that SA.  A packet retains strict-validated
      status if it is forwarded from one network element to another and
      the upstream element explicitly or implicitly certifies that the
      packet is SAVA "strict-validated".

   o  Loose-Validated: A packet is said to be SAVA "loose-validated" if
      it can be proven that the packet was sent with a valid source
      address and has not been altered in transit.  In the "loose-
      validated" case, however, it can only be proven that the packet
      was emitted by a host under the control of an adminstrative
      authority authorized to emit packets with that source address.
      Whether or not the packet can be traced to an individual host is
      unknown.  A packet retains loose-validated status if it is
      forwarded from one network element to another and the upstream
      element explicitly or implicitly certifies that the packet is SAVA
      "loose-validated".




Wu, et al.              Expires December 8, 2007                [Page 5]

Internet-Draft               SAVA Framework                    June 2007


   o  Unknown: A packet has "unknown" status if it is not explicitly or
      implicitly certified to be "SAVA validated" by the upstream
      network element, but the downstream element cannot or does not
      "prove" that the packet is spoofed.  In the internet today, the
      vast majority of packets have "unknown" status.

   o  Spoofed: A packet has "spoofed" status if a receiving network
      element can ascertain that it is impossible for a packet having
      the source address contained in the received packet to have been
      forwarded by the path it received the packet.  SAVA-compliant
      nodes MUST discard packets with "spoofed" status.

3.3.  Implicit vs Explicit Communication

   As will be seen from the following section, SAVA mechanisms will
   often be concerned with communicating the "SAVA Status" of a packet
   from one part of the network to another.  Explicit communication will
   typically involve altering a packet in some way which will be
   recognised by downstream nodes.  Setting the "evil bit" in packets
   with "unknown" SAVA status would be an example of explicit
   communication.

   Implicit communication will typically involve creating some boundary
   conditions such that a downstream node will be able to infer the SAVA
   status of a packet from the way in which a packet arrived.  For
   example, if node A only passes "strict-validated" packets, and node B
   can establish that a particular packet pased through node A on its
   way to node B, then communication of "stict-validated" status has
   been achieved for that packet.

   In most cases, implicit communication, if feasible, is preferred.


4.  SAVA Framework Hierarchy

   In the Internet at large, it is not to be expected that there will be
   a single mechanism applied at a single "level" (e.g. service provider
   access) that can solve the source address spoofing problem.  Multiple
   mechanisms will need to coexist and interoperate.

   The problem is decomposed hierarchically into levels of granularity.
   At each level in the framework hierarchy, one or more mechanisms will
   be defined to address the problem of source address spoofing at that
   level.

   The following is the framework hierarchy chosen for SAVA.  It is not
   asserted that this is the only hierarchy that could be chosen.  This
   particular hierarchy is chosen as a balance between allowing as much



Wu, et al.              Expires December 8, 2007                [Page 6]

Internet-Draft               SAVA Framework                    June 2007


   choice as possible for impementers and providers and keeping the
   framework as simple as possible.

4.1.  First-Hop, Local Subnet Source Validation

   The goal of this level is to assure that a packet sent from the
   access network originates from a host which is authorized to emit
   packets containing the source address of the packet.  The source
   address may be assigned to the host in a static way or a dynamic way.
   There are existing and proposed solutions at this level, based on
   creating a binding between a switch port and source IP address, or a
   binding between MAC address, source IP address and switch port.

   A Packet that passes First-Hop, Local Subnet Source Validation
   becomes "SAVA validated" and retains that status as long as it is
   passed along a wholly SAVA-compliant path.

4.1.1.  Description

   A number of hosts may access the Internet via the same interface of a
   layer-3 gateway.  The host acquires its IP address in a "legal" way,
   e.g., static assigned by the administrator, or dynamic assigned by a
   DHCP server.  Suppose ingress filtering is deployed at this
   interface.  If there is no special consideration, one host can still
   spoof source address by sending packet with the "legal" IP address of
   another host, or even with the IP address not owned by this access
   network.  The goal of the access network SAVA mechanisms is to solve
   the source address spoofing problem in these two scenarios.

   "Access network" is a very widely used concept, and it has many
   different scenarios.  We just use this phrase here to indicate the
   specific scenario we describe above.

   (preamble)
                     +----+
                     | GW |
                     +----+
                       |
                       | e.g., a.b.c.0/16
           +---------+--------------+
           |         |              |
           |         |              |
        +----+     +----+         +----+
        |Host|     |Host|   ...   |Host|
        +----+     +----+         +----+
   (postamble)

   The possilbe source address spoofing scenarios at access network



Wu, et al.              Expires December 8, 2007                [Page 7]

Internet-Draft               SAVA Framework                    June 2007


   level are as follows:

   1.  A host sends packet with spoofed source address of another host
       in the same access network.  This packet is sent to a destination
       not in the same access network.

   2.  A host sends packet with spoofed source address not valid for the
       access network.  This packet is sent to a destination not in the
       same access network.

   3.  A host sends packet with spoofed source address of another host
       in the same access network.  This packet is sent to a destination
       on the same access network.

   4.  A host sends packet with spoofed source address not valid for the
       access network.  This packet is sent to a destination in the same
       access network.

   If the access network, including the gateway, can be shown to discard
   all packets of type 2, then all packets emitted from the subnet
   aresaid to have SAVA "loose-validated" status.

   If the access network, including the gateway, can be shown to discard
   all spoofed packets of type 1 and type 2, then all packets emitted
   from the subnet aresaid to have SAVA "strict-validated" status.

   SAVA is not concerned with spoofed packets of type 3 and type 4.

4.1.2.  Discussion of Scenarios

4.1.2.1.  Enterprise Networks Connecting to Service Provider

   An enterprise network for purposes of this discussion is a collection
   of access networks and interconnecting gateways under the control of
   a single management entity that has one or more gateways connected to
   one or more service providers.  Within an enterprise network, packets
   may have "strict-validated" or "loose-validated" status.  However,
   unless the service provider accepting traffic from the enterprise can
   be sure that packets emitted from the enterprise are in fact all
   "strict-validated", then packets can at best have "loose validated"
   status on entering the service provider's network.

4.1.2.2.  Multihomed Enterprise Network








Wu, et al.              Expires December 8, 2007                [Page 8]

Internet-Draft               SAVA Framework                    June 2007


4.1.2.3.  Home Broadband Access

   In home broadband access cases, an individual has a contract with a
   provider for Internet services.  The IPv4 address or prefix or IPv6
   prefix is allocated/delegated by the provider from its pool of
   addresses.  In this case, even if the home broadband user is using a
   home gateway to share an IP address, the address or prefix can be
   said to be strictly delegated to that gateway, and all traffic is the
   responsibility of one individual.  Assuming the provider applies
   measures to prevent spoofing, packets entering the provider network
   can be said to be "strict-validated".

4.1.2.4.  Access from a Wireless Mobile Device

4.1.2.5.  Other Mobility Scenarios

4.2.  Intra-AS Communication of SAVA Validation

   Intra-AS communication of SAVA Validation establishes, enforces and
   maintains packets' validation status from entry into a service
   provider's network either from an access network (either a customer
   node or a customer network) or from another service provider (transit
   provider, transit customer or peer network) until it is either
   delivered to an access network or another provider.  In other words,
   Intra-AS Communication of SAVA Status must:

   o  Correctly establish and enforce SAVA status at the access links to
      the network from customer nodes or networks.

   o  Propagate SAVA Validation status for each packet (strict-
      validated, loose-validated, unknown) from one network element to
      the next until the packet either arrives at an inter-AS boundary
      or is delivered to an access network

   o  Detect and discard packets with "spoofed" status

4.2.1.  Mechanism Requirements

   The possible source address spoofing scenarios at the intra-AS level
   are as follows:

   1.  A host sends packet with spoofed source address of another part
       of the same AS.  This packet is sent to a destination not within
       the sending AS.

   2.  A host sends packet with spoofed source address of another part
       of AS.  This packet is sent to a destination within the sending
       AS.



Wu, et al.              Expires December 8, 2007                [Page 9]

Internet-Draft               SAVA Framework                    June 2007


   3.  A host sends packet with spoofed source address from another AS.
       This packet is sent to a destination not within the sending AS.
       While this packet is transmitted inside the sending AS, it is an
       intra-AS problem; when the packet arrives at the border of the
       sending AS, or the packet is transmitted not in the sending AS,
       it is an inter-AS problem.

   4.  A host sends packet with spoofed source address of another AS.
       This packet is sent to a destination within the sending AS.

   In order for an AS to be "SAVA-compliant", an AS must achieve the
   following:

   1.  The AS must not accept for delivery packets sent from an access
       network that have Source Addresses not authorized to be used by
       that access network.

   2.  Where a packet is accepted from an access network, the AS may
       distinguish between "strict-validated" and "loose-validated"
       status for each packet and assign status accordingly.  If no such
       distinction is made, then a packet accepted for delivery will
       have "loose-validated" status.

   3.  A packet accepted for delivery from an access network cannot have
       "unknown" status and packets with "spoofed" status must be
       discarded.

   4.  A packet that accepted for delivery from an access network must
       be delivered to a SAVA-compliant neighbor AS or to another access
       network with the same validation status as it received on entry
       to the network.

   5.  A packet received from a non-SAVA-compliant neighbour AS will
       usually be assigned either "unknown" or "spoofed" SAVA validation
       status.  There may be specific cases where packets may be
       assigned "loose-validated" status.  If status is "spoofed" then
       the packet must be discarded.  This status is established by
       Inter-AS communication of SAVA validation.

   6.  A packet entering a SAVA-compliant AS with "unknown" validation
       status must exit the AS with "unknown" SAVA validation status.

   7.  A packet received from a SAVA-compliant neighbour AS will have
       "unknown", "loose-validated" or "strict validated" status.  This
       status is received through Inter-AS Communication of SAVA
       Validation.





Wu, et al.              Expires December 8, 2007               [Page 10]

Internet-Draft               SAVA Framework                    June 2007


   8.  A packet must exit the AS to a neighbouring SAVA compliant AS
       with the same status with which it was received, except in the
       case where the AS does not support communication of "strict-
       validated" status, in which case both "strict-validated" and
       "loose-validated" packets must exit the AS with "loose-validated"
       status.

   9.  In the case where SAVA status is communicated explicitly (for
       example through packet marking) Intra-AS status communication
       marking may optionally be removed from the packet before it is
       either delivered to an access network or passed to a peer
       network.

4.3.  Inter-AS Communication of SAVA Validation

   At this framework level, the goal is to provide assurance that a
   packet transmitted from one service provider to another was inserted
   into the network through a provider authorized to insert packets with
   that packet's SA prefix into the Internet.  The transmitting service
   provider or AS indicates whether a packet is known to have a
   validated source address or not.  The receiving provider/AS makes a
   policy decision as to the disposition of the packet. (e.g. forward,
   do not forward, forward at a lower/higher priority, etc.)

   If the packet transits the receiving provider/AS, and the packet
   arrives at the receiving provider not certified as having been
   validated, then the receiving provider/AS MUST NOT certify the packet
   as having been validated to its downstream provider.

   For the purposes of this architecture, a provider-provider or inter-
   provider relationship exists between two or more administrative
   domains comprising one or more autonomous systems (AS) and exchanging
   routing information via EBGP either directly or via intermediate EBGP
   speakers.

   There are some proposed methods for this level in the literature.
   SPM[SPM] is designed to work at this level.  SAVE [SAVE]can also be
   modified to work at this level.

4.3.1.  Mechanism Requirements

   Here we list the possible source address spoofing scenario at the
   inter-AS level:

   1.  The host in one AS sends packet with spoofed source address of
       another AS.  This packet is sent to a destination not in the
       sending AS.




Wu, et al.              Expires December 8, 2007               [Page 11]

Internet-Draft               SAVA Framework                    June 2007


   2.  The provider-provider level of the SAVA architecture can, for
       solution purposes, be broken down into three sub-cases:

       1.  the case where the two SAVA-compliant providers exchanging
           traffic are directly connected;

       2.  the case where the two SAVA-compliant providers are separated
           by one or more intervening, SAVA-non-compliant providers; and

       3.  the case where a SAVA-compliant provider is exchanging
           traffic with a SAVA-non-compliant provider.

4.3.1.1.  Communication Between Adjacent SAVA-compliant Providers

   In order for two or more SAVA-Compliant (from an intra-AS
   perspective) to achieve SAVA-Compliant inter-Domain Communication of
   SAVA Validation, the interconnection must have the following
   characteristics:

   1.  The two domains must establish a trust relationship such that
       information can be exchanged between the domains in a secure
       manner; that is, information should be able to be exchanged
       without insertion of spurious information, without information
       being lost, and such that credentials, keys, etc. are not
       revealed to third parties.  Establishment of this trust
       reationship implies that both participants are "SAVA-Compliant"
       at the Intra-AS level.  (This includes the enforcement of at
       least "loose-validated" status for all packets arriving via
       access links.)

   2.  Trust relationship is transitive.  That is, if A trusts B and B
       trusts C, even if A and C do not have a direct trust
       relationship, A must be able to trust the SAVA validation status
       of packets arriving from C via B.

   3.  Only packets with "strict-validated", "loose-validated" or
       "unknown" may be transmitted between SAVA-compliant ASs.

   4.  SAVA validation status is preserved across the inter-provider
       boundary.

4.3.1.2.  Communication Between Non-Adjacent SAVA-Compliant Providers

   The requirements for this case are the same as for the case were the
   SAVA-compliant domains are adjacent, with the added requirement that
   the receiving domain must be able to distinguish between packets that
   arrived via the SAVA-compliant domain and packets (perhaps with the
   same source addresses) that arrived by some other route.



Wu, et al.              Expires December 8, 2007               [Page 12]

Internet-Draft               SAVA Framework                    June 2007


4.3.1.3.  Communication between a SAVA-Compliant Provider and a SAVA-
          non-Compliant Provider

   Since there is no explicit SAVA communication between the domains in
   this case, the assignment of SAVA status must take place solely using
   information available at the receiving boundary through non-SAVA
   mechanisms. (e.g. routing tables, BGP AS-PATH attributes, etc.)

   In general, packets arriving at a SAVA-compliant domain will be
   assigned at best "unknown" SAVA validation status at the boundary.

   In some cases it will be possible (e.g. using uRPF) to prove that the
   packet is spoofed, in which it must be assigned "spoofed" status and
   discarded.

   There may be other cases (e.g. where the SA matches a prefix which is
   wholly contained within the network of the adjacent sending domain)
   where the packet can be assigned "loose-validated" SAVA status.

4.3.2.  Design Considerations

   Several important points should be kept in mind in the design of
   inter-AS SAVA mechanisms:

   1.  Asymmetric routing is not rare for the inter-AS routing, so SAVA
       methods should be robust in the face of assymetric routing.

   2.  Many ASs are created to support site multihoming.  The inter-AS
       SAVA mechanisms must be robust in the presence of site
       multihoming.

4.4.  End-End

4.5.  Summary


5.  SAVA Design Goals

5.1.  Performance

   Any solutions designed under this framework should be no more taxing
   on routing and other infrastructure than the application of BCP038.
   That is, modern routing equipment should be able to maintain full
   line rate.

   It is permissable to propose solutions that are not fully achievable
   with current equipment "as-is" but would be implementable with
   current generation technology, as long as alternative solutions are



Wu, et al.              Expires December 8, 2007               [Page 13]

Internet-Draft               SAVA Framework                    June 2007


   available for current equipment.

5.2.  Economically Feasible

   The solution must provide benefit at least proportionate to its cost,
   both from the perspective of equipment capital cost and operational
   expense.  A solution that doubles the cost of core routing elements,
   for example, is not acceptable.  A solution that is operationally
   more expensive than ingress filtering must supply significantly more
   benefit than ingress filtering.

   The design goal is to create an overall solution that has an
   operational cost of similar magnitude to that of applying ingress
   filtering that does not increase the cost of routing elements, taking
   into account that technology will allow more to be achieved with the
   same or lower hardware cost in the future.

5.3.  Scaling

   Solutions must be capable of scaling to the size of the global
   Internet.

5.4.  Hierarchical Solution

   One of the reasons why BCP has not solved the problem is that it is a
   single granularity solution - it can only be applied in the access
   network, or at the boundary between a stub/access network and a
   transit network.  A provider who applies BCP038 protects itself from
   its own clients, and the rest of the Internet from its clients but it
   does not protect itself from spoofed packets in the rest of the
   Internet in any way.

   A hierarchical solution will allow a network to assign levels of
   trust to the source addresses on packets sent from neighboring
   providers as well as from its own network and attached stub networks.

5.5.  Incrementally Deployable

   The mechanism should show its benefit even if it is deployed only in
   part of the Internet.  It is impossible to deploy some mechanism all
   over the Internet in one night.  If there is no benefit for partial
   deployment, it is hard to start the deployment.

5.6.  Incomplete Deployment Still Beneficial

   The mechanism should have direct benefit to the party who makes
   investment on the deployment of the mechanism.  Otherwise there is
   not enough incentive for someone to spend money to deploy such



Wu, et al.              Expires December 8, 2007               [Page 14]

Internet-Draft               SAVA Framework                    June 2007


   mechanism.

   This implies two things: first, there must be immediate benefit for
   incomplete deployment, and deploying the recommended solutions must
   provide some protection to the entity deploying the solutions.

5.7.  Loose Component Coupling

   A solution that meets the above design goals will have components for
   each level of granularity.  It is desired that a solution under this
   framework may have more than one solution at any given level of
   granularity.  This allows for different providers to use different
   solutions, as well as allowing for evolution of new solutions as the
   capabilities of equipment improve or simply as new solutions are
   developed.

   This requires the coupling of components at different levels of
   granularity to be loose enough to allow component substitution.

5.8.  Solution for IPv6 and IPv4

   Mechanisms are to be developed for both IPv6 and IPv4.  Where
   possible the same mechanisms should be used for both, but it is
   recognised that it will be possible to make more radical changes to
   IPv6 than it will be for IPv4.


6.  IANA Considerations

   This document makes no request of IANA.

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


7.  Security Considerations


8.  Acknowledgements

   The authors would like to acknowledge the contributors who provided
   helpful inputs on earlier versions of this document.  The authors
   would also like to acknowledge the participants in the SAVA meetings
   held in Sunnyvale, CA, USA (March 2006), Beijing, China (June 2006),
   Montreal, Canada (IETF67 July 2006), and San Diego, USA (Nov. 2006).


9.  References



Wu, et al.              Expires December 8, 2007               [Page 15]

Internet-Draft               SAVA Framework                    June 2007


9.1.  Normative References

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

9.2.  Informative References

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

   [SAVE]     Jin, C. and H. Wang, ""Hop-count filtering: an effective
              defense against spoofed DDoS traffic", in Proc. the 10th
              ACM conference on Computer and Communication Security",
              2002.

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


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












Wu, et al.              Expires December 8, 2007               [Page 16]

Internet-Draft               SAVA Framework                    June 2007


   Gang Ren
   CERNET
   Network Center, Tsinghua University
   Beijing  100084
   China

   Email: rg03@mails.tsinghua.edu.cn


   Xing Li
   CERNET
   Network Center, Tsinghua University
   Beijing  100084
   China

   Email: xing@cernet.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


   Ronald P. Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, VA  20171
   USA

   Email: rbonica@juniper.net

















Wu, et al.              Expires December 8, 2007               [Page 17]

Internet-Draft               SAVA Framework                    June 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 December 8, 2007               [Page 18]