doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc5210.txt b/doc/rfc/rfc5210.txt
new file mode 100644
index 0000000..b4f09dc
--- /dev/null
+++ b/doc/rfc/rfc5210.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+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
+
+
+                         ----------------
+                         | 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
+
+
+                                        ---------
+                                        | AIMS   |
+                                         ------|-
+                                               |
+   --------------                   -----------|-----
+   |  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]
+