One document matched: draft-wu-sava-framework-01.txt
Differences from draft-wu-sava-framework-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 19:42:27 |