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
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
源地址验证体系结构（SAVA）测试平台和部署经验
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.
由于Internet根据IP目标地址转发数据包，数据包转发通常在不检查源地址的情况下进行，并且使用伪造的源地址发起恶意攻击。为了通过IP源地址验证增强Internet，创建了IP源地址验证体系结构（SAVA）的原型实现，并在IPv6网络上进行了评估。本文档报告了原型实现和测试结果，以及从实验中获得的经验和见解。
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
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
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.
根据设计，互联网仅根据目的地IP地址转发数据包。在大多数情况下，在转发过程中不会检查源IP地址。这使得恶意主机很容易欺骗IP数据包的源地址。我们认为，对于所有转发的数据包，强制执行源IP地址的有效性是有用的。
Enforcing the source IP address validity would help us achieve the following goals:
实施源IP地址有效性将有助于我们实现以下目标：
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 由于携带伪造源地址的数据包不会被转发，因此不可能发起通过使用伪造源地址启用的网络攻击，并且更难成功执行通过使用伪造源地址增强或加强的攻击。
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.
o 如果能够假设所有数据包源地址都是正确的，那么就可以准确、自信地完成回溯。这将有利于网络诊断、管理、记帐和应用程序。
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.
作为开发源地址验证体系结构（SAVA）工作的一部分，我们实现了一个SAVA原型，并作为中国下一代互联网（CNGI）项目[Wu07]的一部分，将该原型部署在运营网络中的12个ASE中。我们进行了评估实验。在本文中，我们首先描述原型解决方案，然后报告实验结果。我们希望本文件能为对该主题感兴趣的人提供有用的见解，并能作为未来IETF在该领域工作的初步投入。
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.
近年来，已经有许多研究和工程努力来设计IP源地址验证机制，例如[RFC2827]、[Park01]、[Li02]、[Brem05]和[Snoe01]。我们的SAVA原型实现受到了来自提议的或现有解决方案的一些方案的启发。
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.
本报告中给出的原型实现和实验结果仅作为输入，决不能抢占未来IETF可能进行的任何解决方案开发。事实上，所提出的解决方案是实验性的方法，如第5节和第6节所讨论的，有许多局限性。
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].
此外，该体系结构允许多种独立且松散耦合的检查机制。这样做的动机是，在整个互联网上，期望任何单一的IP源地址验证机制都得到普遍支持是不现实的。不同的运营商和供应商可能会选择部署/开发不同的机制来实现相同的目的，并且需要不同的机制来解决网络中不同位置的问题。此外，实现错误或配置错误可能导致实现无效。因此，我们的原型SAVA实现是多种共存和协作机制的组合。更具体地说，我们在三个级别实现源IP地址验证：访问网络源地址验证；内部AS源地址验证；和内部AS源地址验证，如图1所示。可在[Wu07]中找到系统详细信息。
__ ____ __ ____
.-'' `': .-'' `':
| | | |
| +-+----+ | Inter-AS SAV | +-+----+ |
| |Router+--+------------------+---|Router+ +
| +--.---+ | | +--.---+ |
Intra-AS | | \ Intra-AS | | |
SAV | +--+---+ \ SAV | +--+---+ |
| |Router| \ | |Router| |
| +--.---+ \ '_ +-----+ _
| | \ `'-------'''
/ | \
/ | \
| +---------------------+\
----+---------. Router | \
| ++-------\------------+ \
| | | \ | | |
__ ____ __ ____
.-'' `': .-'' `':
| | | |
| +-+----+ | Inter-AS SAV | +-+----+ |
| |Router+--+------------------+---|Router+ +
| +--.---+ | | +--.---+ |
Intra-AS | | \ Intra-AS | | |
SAV | +--+---+ \ SAV | +--+---+ |
| |Router| \ | |Router| |
| +--.---+ \ '_ +-----+ _
| | \ `'-------'''
/ | \
/ | \
| +---------------------+\
----+---------. Router | \
| ++-------\------------+ \
| | | \ | | |
| | +------+|+------++----+|Intra-AS
| | |Switch|||Switch||Host||SAV
| | +------+|+------++----+|Intra-AS
| | |Switch|||Switch||Host||SAV
| | +------+|+------++----+|
| | +------+|+------++----+|
| | | | | \ |
| | | | | \ |
|+-+--++----+|+----++----+ |
|+-+--++----+|+----++----+ |
||Host||Host|||Host||Host| |
`+----++----+|+----++----+ /
||Host||Host|||Host||Host| |
`+----++----+|+----++----+ /
`--. | _.-'
`------|------+''
Access |
Network |
SAV
`--. | _.-'
`------|------+''
Access |
Network |
SAV
Key: SAV - Source Address Validation
关键字：SAV-源地址验证
Figure 1: Solution Overview
图1：解决方案概述
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.
1. 接入网络。这可防止网络中的主机欺骗同一网段中另一主机的地址。与内部AS预防相比，这支持主机粒度的保护。详见第2.2节。
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.
2. 内部AS。当接入网络的边缘路由器执行源地址验证（例如，使用[RFC2827]和[RFC3704]）时，防止主机欺骗任意地址，但除非使用接入网络SAV，否则它们可能能够欺骗同一网段中主机的地址。在退化情况下，当路由器连接单个主机时，主机不能伪造任何地址。
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.
3. 国际米兰。在AS边界强制执行数据包源地址正确性的机制。由于全球互联网具有网状拓扑结构，并且不同的网络属于不同的管理机构，因此AS间级别的IP源地址验证更具挑战性。然而，我们认为，当前两级源地址验证丢失或无效时，第三级保护对于检测具有伪造源地址的数据包是必要的。
In the following sections, we describe the specific mechanisms implemented at each of the three levels in detail.
在以下各节中，我们将详细描述在三个级别中的每一个级别上实现的具体机制。
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.
在接入网级别，该解决方案确保接入网内的主机不能使用另一台主机的源地址。主机地址应该是静态或动态分配给主机的有效地址。实验中实现的解决方案为以太网网络提供了这样的功能。接入网络的第3层源地址验证体系结构设备（SAVA设备）（该设备可以是客户场所设备（CPE）路由器内的功能或单独的设备）部署在接入网络的出口处。源地址验证体系结构代理（SAVA代理）部署在访问网络内部。（事实上，这些代理可以是连接到主机的第一跳路由器/交换机内的一个功能。）为主机、SAVA代理和SAVA设备之间的通信设计了一组协议。只有从分配了特定源地址的主机发出的数据包才能通过SAVA代理和SAVA设备。
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.
存在两种可能的部署变体；我们将它们称为变体A和变体B。在变体A中，代理是必需的，每个主机都连接到专用物理端口上的代理。在变体B中，主机需要执行网络访问身份验证并生成保护每个数据包所需的密钥材料。在此变体中，代理是可选的。
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.
变体A的关键功能是在交换机端口和有效源IP地址之间创建动态绑定，或者在媒体访问控制（MAC）地址、源IP地址和交换机端口之间创建绑定。在原型中，这是通过让主机采用交换机能够跟踪的新地址配置协议来实现的。
Note: In a production environment, the approach in the prototype would not be sufficient due to reasons discussed in Section 5.
注：在生产环境中，由于第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:
在变体A中，有三个主要参与者：主机上的源地址请求客户端（SARC）、交换机上的源地址验证代理（SAVP）和源地址管理服务器（SAMS）。如图2所示。解决方案遵循以下基本步骤：
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.
1. 终端主机上的SARC发送一个IP地址请求。交换机上的SAVP将此请求中继到SAMS，并记录MAC地址和传入端口。如果终端主机已经预先确定了地址，则终端主机仍需要将该地址放入请求消息中，以供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.
2. SAMS接收到IP地址请求后，根据接入网的地址分配和管理策略为该SARC分配源地址，并将IP地址的分配存储在SAMS历史数据库中进行回溯，然后向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.
3. 在接入交换机上的SAVP接收到响应后，它将请求消息的IP地址和先前存储的MAC地址与绑定表上的交换机端口绑定。然后，它将发出的地址转发给终端主机上的SARC。
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.
4. 接入交换机开始过滤从终端主机发送的数据包。不符合元组（IP地址、交换机端口）的数据包将被丢弃。
----------------
| SERVER |
| ------- |
| | SAMS | |
| -------- |
-----------------
|
|
----------------
| SWITCH |
| ------- |
| | SAVP | |
| -------- |
-----------------
|
|
----------------
| END HOST |
| ------- |
| | SARC | |
| -------- |
-----------------
----------------
| SERVER |
| ------- |
| | SAMS | |
| -------- |
-----------------
|
|
----------------
| SWITCH |
| ------- |
| | SAVP | |
| -------- |
-----------------
|
|
----------------
| END HOST |
| ------- |
| | SARC | |
| -------- |
-----------------
Key: SARC - Source Address Request Client SAVP - Source Address Validation Proxy SAMS - Source Address Management Sever
关键字：SARC-源地址请求客户端SAVP-源地址验证代理SAMS-源地址管理服务器
Figure 2: Binding-Based IP Source Address Validation in the Access Network
图2：接入网中基于绑定的IP源地址验证
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:
变体B的主要思想是使用来自网络访问认证的关键材料进行一些额外的验证过程。为连接到网络的每个主机派生会话密钥，并且主机发送的每个数据包都具有使用该会话密钥的加密保护。在确定数据包来自哪个主机之后，可以再次跟踪分配给该主机的地址是否与该主机使用的地址匹配。机制详情见[XBW07]，但流程遵循以下基本步骤：
1. When a host wants to establish connectivity, it needs to perform network access authentication.
1. 当主机想要建立连接时，它需要执行网络访问身份验证。
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.
2. 网络接入设备向SAVA代理（通常位于同一位置）提供会话密钥。该密钥进一步分发到SAVA设备。SAVA设备绑定会话密钥和主机的IP地址。
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.
3. 当主机将数据包M发送到接入网络之外的某个地方时，主机或SAVA代理需要使用密钥S和数据包M为每个数据包生成消息身份验证码。在原型中，消息身份验证码携带在实验性IPv6扩展头中。
4. The SAVA Device uses the session key to authenticate the signature carried in the packet so that it can validate the source address.
4. SAVA设备使用会话密钥对数据包中携带的签名进行身份验证，以便验证源地址。
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.
在我们的测试床上，我们实现并测试了这两种解决方案。基于交换机的解决方案具有更好的性能，但接入网络中的交换机需要升级（通常接入网络中的交换机数量很大）。基于签名的解决方案可以部署在主机和出口路由器之间，但在插入和验证签名时会有一些额外的成本。
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.
我们采用了[RFC2827]和[RFC3704]中描述的入口点IP数据包的源地址验证解决方案；后者描述了多宿接入网络入口点的源地址验证。
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.
我们的内部AS源地址验证设计包括以下特点：它应该在具有不同管理权限和不同利益的不同ASE之间进行合作。它应该足够轻，以支持高吞吐量，而不影响转发效率。
The inter-AS level of SAVA can be classified into two sub-cases:
SAVA的内部AS级别可分为两个子情况：
o Two SAVA-compliant ASes exchanging traffic are directly connected;
o 两个SAVA兼容ASE交换流量直接连接；
o Two SAVA-compliant ASes are separated by one or more intervening, non-SAVA-compliant providers.
o 两个符合SAVA的ASE由一个或多个不符合SAVA的介入提供商分隔。
---------
| 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| |
| ----- | | ------ |
--------------- -------------
---------
| 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
关键字：AIMS-AS-IPv6前缀映射服务器ASBR-AS边界路由器VE-验证引擎VR-验证规则VRGE-验证规则生成引擎
Figure 3: Inter-ISP (Neighboring AS) Solution
图3：ISP间（相邻AS）解决方案
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.
交换流量的两个ASE具有客户到提供商、提供商到客户、对等或兄弟姐妹关系。在客户对提供商或提供商对客户的关系中，客户通常属于较小的管理域，该管理域为访问Internet的其余部分而向较大的管理域付费。提供程序是属于较大管理域的AS。在对等关系中，两个对等点通常属于规模相当的管理域，并且发现在各自的客户之间交换流量对双方都有利。如果两个ASE属于同一管理域或具有相互传输协议的管理域，则它们具有兄弟姐妹关系。
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.
基于AS关系的机制用于相邻SAVA兼容ASE。这种基于关系的机制的基本思想如下。它构建一个VR表，将路由器的每个传入接口与一组有效的源地址块相关联，然后使用它过滤伪造的数据包。
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.
在测试平台上实现的解决方案中，IPv6前缀验证解决方案分为三个功能模块：验证规则生成引擎（VRGE）、验证引擎（VE）和AS-IPv6前缀映射服务器（AIMS）。VRGE生成的验证规则表示为IPv6地址前缀。
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 |
----------------------------------------------------------------------
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
表1：基于AS关系的AS间过滤
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.
不同的ASE使用VRGE中基于AS关系的导出规则交换和传输VR信息。根据表1，As将自身、客户、提供商、同级和同级的地址前缀作为有效前缀导出到客户和同级，而仅将自身、客户和同级的地址前缀作为有效前缀导出到提供商和同级。在AS-IPv6前缀映射服务器的支持下，只有AS编号的有效地址前缀在ASE之间传输，并且AS编号映射到VRGE的地址前缀。
Only changes of AS relation and changes of IP address prefixes belonging to an AS require the generation of VR updates.
只有AS关系的更改和属于AS的IP地址前缀的更改需要生成VR更新。
The procedure's principal steps are as follows (starting from AS-1 in Figure 3):
该程序的主要步骤如下（从图3中的as-1开始）：
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.
1. 当VRGE初始化后，它读取其相邻的SAVA兼容AS表，并在其自己的AS中建立与所有VE的连接。
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.
2. VRGE启动虚拟现实更新。根据其导出表，它向相邻ASE的VRGE发送自己的原始VR。在此过程中，VRs表示为数字。
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.
3. 当VRGE从其邻居接收到新的VR时，它使用自己的导出表来决定是否应该接受VR，如果它接受VR，它是否应该将VR重新导出到其他相邻的ASE。
4. If the VRGE accepts a VR, it uses the AIMS to transform the AS-expressed VR into an IPv6 prefix-expressed VR.
4. 如果VRGE接受VR，它将使用AIMS将表示的VR转换为IPv6前缀表示的VR。
5. The VRGE pushes the VR to all the VEs in its AS.
5. VRGE将VR推送到其AS中的所有VE。
The VEs use these prefix-based VRs to validate the source IP addresses of incoming packets.
VEs使用这些基于前缀的VRs来验证传入数据包的源IP地址。
2.5. IP Source Address Validation in the Inter-AS Case (Non-Neighboring AS)
2.5. 内部AS情况下的IP源地址验证（非相邻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].
在两个ASE不直接交换数据包的情况下，不可能部署如前一节所述的解决方案。然而，非常希望非相邻ISP能够形成信任联盟，使得离开一个AS的数据包将被另一个AS识别，并在离开第一个AS时继承其拥有的验证状态。实现这一点的方法不止一种。对于迄今为止的SAVA实验，使用了身份验证标签方法。此解决方案受[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
这种基于轻量级身份验证标签的机制的关键元素如下：对于每对SAVA兼容ASE，都有一对唯一的临时身份验证标签。所有符合SAVA的ASE共同组成了SAVA AS联盟。当数据包离开自己的AS时，如果目标IP地址属于SAVA AS联盟中的AS，则该AS的边缘路由器使用目标AS号作为密钥查找身份验证标签，并向数据包添加身份验证标签。当包裹到达
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.
目的地AS，如果分组的源地址属于SAVA AS联盟中的AS，则目的地AS的边缘路由器使用源AS号码作为密钥搜索其表中的认证标签，并且验证并移除分组中携带的认证标签。正如其名称所示，此特定方法使用轻量级身份验证标记。对于转发的每个数据包，可以将身份验证标签放入IPv6逐跳扩展标头中。使用128位共享随机数作为身份验证标签是合理的，以节省使用加密方法生成身份验证标签所带来的处理开销。
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.
与仅打开本地地址验证（如RFC 2827）相比，此方案的好处如下：当在一组网络中使用本地地址验证时，可以确保其网络不会发送伪造的数据包。但其他网络可能仍会这样做。然而，通过上述方案，这种能力被消除。如果联盟外的人使用来自联盟内的人的源地址欺骗数据包，联盟成员将拒绝接受此类数据包。
+-----+
.-----------------+ REG |-----------------.
| +-----+ |
| |
,-----+-------- ,------+-------
,' `| `. ,' ` | `.
/ | \ / | \
/ | \ / | \
; +--'--+ +----+ +----+ +-----+ ;
| | ASC +------+ASBR| |ASBR+-----+ ASC | |
: +--.--+ +----+` +----+ +--+--+ :
\ |__________________________________________| /
\ / \ /
`. ,' `. ,'
'-------------' '-------------'
AS-1 AS-2
+-----+
.-----------------+ REG |-----------------.
| +-----+ |
| |
,-----+-------- ,------+-------
,' `| `. ,' ` | `.
/ | \ / | \
/ | \ / | \
; +--'--+ +----+ +----+ +-----+ ;
| | ASC +------+ASBR| |ASBR+-----+ ASC | |
: +--.--+ +----+` +----+ +--+--+ :
\ |__________________________________________| /
\ / \ /
`. ,' `. ,'
'-------------' '-------------'
AS-1 AS-2
Key: REG - Registration Server ASC - AS Control Server ASBR - AS Border Router
注册表-注册服务器ASC-AS控制服务器ASBR-AS边界路由器
Figure 4: Inter-AS (Non-Neighboring AS) Solution
图4：内部AS（非相邻AS）解决方案
There are three major components in the system: the Registration Server (REG), the AS Control Server (ASC), and the AS Border Router (ASBR).
系统中有三个主要组件：注册服务器（REG）、AS控制服务器（ASC）和AS边界路由器（ASBR）。
The Registration Server is the "center" of the trust alliance (TA). It maintains a member list for the TA. It performs two major functions:
注册服务器是信任联盟（TA）的“中心”。它为TA保留了一份成员名单。它执行两个主要功能：
o Processes requests from the AS Control Server, to get the member list for the TA.
o 处理来自AS控制服务器的请求，以获取TA的成员列表。
o Notifies each AS Control Server when the member list is changed.
o 成员列表更改时通知每个AS控制服务器。
Each AS deploying the method has an AS Control Server. The AS Control Server has three major functions:
部署该方法的每个AS都有一个AS控制服务器。AS控制服务器有三个主要功能：
o Communicates with the Registration Server, to get the up-to-date member list of TA.
o 与注册服务器通信，以获取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 与TA中其他成员ASE中的AS控制服务器通信，以交换前缀所有权信息的更新和交换身份验证标签。
o Communicates with all AS Border Routers of the local AS, to configure the processing component on the AS Border Routers.
o 与本地AS的所有AS边界路由器通信，以在AS边界路由器上配置处理组件。
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.
AS边界路由器执行在发送AS处向分组添加认证标签的工作，以及在目的AS处验证和移除认证标签的工作。
In the design of this system, in order to decrease the burden on the REG, most of the control traffic happens between ASCs.
在本系统的设计中，为了减少REG的负担，大部分控制流量发生在ASC之间。
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.
身份验证标签需要定期更改。尽管从一个AS的角度来看，AS对之间维护和交换身份验证标签的开销是O（N），而不是O（N^2），但流量和处理开销确实会随着AS数量的增加而增加。因此，在该解决方案中使用了自动认证标签刷新机制。在这种机制中，每个对等方运行相同的算法来自动生成身份验证标记序列。然后，数据包中的身份验证标签可以自动进行高频更改。为了提高安全性，该算法使用一个种子来生成一个抗猜测的认证标签序列。因此，对等方只需以非常低的频率协商和更改种子。这降低了与频繁协商和更改身份验证标记相关的开销，同时保持了可接受的安全性。
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
由于身份验证标记放在IPv6逐跳扩展标头中，因此应考虑MTU问题。目前我们有两种解决这个问题的方法。这两种解决方案都不是完美的，但是
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.
它们都是可行的。一种可能的方法是将ASBR处的MTU设置为1280字节，这是IPv6的最小MTU。因此，不应从下游网关接收ICMP“数据包太大”消息。这种解决方案的缺点是没有充分利用可用的MTU。另一种可能的方法是让ASBR捕获所有传入的ICMP“Packet Too Big”消息，并在将其转发到AS之前减小MTU字段中的值。此解决方案的优点是可以充分利用可用的MTU。但ASBR对ICMP数据包的这种处理可能会造成拒绝服务（DoS）攻击的目标。
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.
身份验证标签管理是一个关键问题。我们的工作集中在两点：标签协商和标签刷新。标签协商发生在SAVA AS联盟中一对ASE的ASC之间。考虑到同步问题和启用SAVA的激励，提出了接收器驱动的标签协商。它给予接收者更多的决策权，而不是发送者。在接收方驱动的方案中，接收方AS可以决定标签管理的策略。不应无限期地允许使用旧身份验证标记标记的数据包。相反，在协商新标记之后，旧标记应该在一段时间后设置为无效。此期间的长度是一个参数，用于控制分配新标记后旧标记的有效时间。在实验中，我们用了五秒钟。
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.
信任联盟旨在动态建立（加入和退出），但在这个测试平台中，我们需要离线确认联盟成员之间的初始信任。
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.
我们的SAVA解决方案原型已在CNGI-CERNET2上实现和测试。CNGI-CERNET2是由中国教育和研究网络（CERNET）运营的中国下一代互联网（CNGI）主干网之一。CNGI-CERNET2以2.5-10 Gb/s的速度连接分布在中国20个城市的25个核心节点。CNGI-CERNET2主干网是纯IPv6网络，而不是IPv4/IPv6混合基础设施。只有一些客户场所网络（CPN）是双重堆叠的。CNGI-CERNET2主干、CNGI-CERNET2 CPN和CNGI-6IX都具有全球唯一的AS编号。因此，提供了一个多AS测试平台环境。
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 | | | |
\ +---------+.' \ .'
\ ,' \ |
`. ,' \ /
``---' -_,'
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
关键字：SAV-源地址验证
Figure 5: CNGI-CERNET2 SAVA Testbed
图5:CNGI-CERNET2 SAVA试验台
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
在任何情况下，测试台都完全能够对SAVA的所有部分的解决方案进行功能测试。这包括用于确保接入网络中的IPv6源地址、从接入网络发送到IPv6服务提供商的数据包、在一个服务提供商的网络中发送的数据包、以及
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.
该试验台分布在连接CNGI-CERNET2的12所大学。
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.
每个大学装置都通过一套AS源地址验证原型设备和流量监测设备连接到CNGI-CERNET2主干网，以显示测试结果。
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.
每所大学都部署了一所作为研究对象。六所大学部署了解决方案的所有部分，因此功能齐全，在AS间、AS内和接入网络级别都可以进行验证。此外，在各种服务器上安装了一套应用程序，这些应用程序可能会受到欺骗攻击，也可能会被颠覆以执行欺骗攻击。为接入网络部署了两个解决方案。
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.
第2节中概述的解决方案是在第3节中描述的测试床上实现的。所有解决方案均已成功测试，详见以下章节。
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.
对于每个测试场景，我们测试了许多案例。以Inter-AS（non-neighting-AS）SAVA解决方案测试为例，我们将测试用例分为三类：正常类、动态类和反欺骗类。
1. For normal class, there are three cases: Adding authentication tag Test, Removing authentication tag Test, and Forwarding packets with valid source address.
1. 对于普通类，有三种情况：添加身份验证标记测试、删除身份验证标记测试和转发具有有效源地址的数据包。
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.
2. 对于动态类，有四种情况：更新ASE之间的身份验证标记、保护新加入的成员AS、添加地址空间和删除地址空间。
3. For anti-spoofing class, there is one case: Filtering of packets with forged IP addresses.
3. 对于反欺骗类，有一种情况：过滤具有伪造IP地址的数据包。
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
如图5所示，我们为SAVA试验台设计了“多重围栏”。如果在访问网络中部署源地址验证，则可以获得主机粒度验证。中频源地址
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.
验证部署在内部AS级别，我们可以保证从该点发送的数据包具有正确的IP前缀。如果源地址验证部署在内部AS级别，我们可以保证从该点发送的数据包来自正确的AS。
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.
1. 试验结果与预期一致。对于具有在AS间、AS内和接入网络级别进行验证的全功能SAVA部署的AS，不包含经过身份验证的源地址的数据包将不会在网络中转发。因此，不可能使用伪造的源地址发起网络攻击。此外，网络中的流量可以准确地追溯。
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.
2. 对于Inter-AS（non-neighting-AS）SAVA解决方案，在认证标签更新期间，新旧认证标签对源地址验证都有效；因此，不存在分组丢失。
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.
3. 对于Inter-AS（非相邻AS）SAVA解决方案，验证功能在运行Linux的设备上的软件中实现，该设备模拟路由器接口的源地址验证功能。它是第二层设备，因为它需要对路由器接口透明。在测试期间，当设备直接连接时，实现了正常的线路速率转发。当这些设备与另一家供应商的路由器连接时，只能获得非常有限的转发速度。原因是身份验证标签添加在IPv6逐跳选项标头上，并且许多当前路由器只能以有限的速率处理逐跳选项。
There are several issues both within this overall problem area and with the particular approach taken in the experiment.
在整个问题区域内以及在实验中采用的特定方法中都存在一些问题。
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
关于缺乏源地址验证的普遍部署是否是一个需要技术解决方案的技术问题，或者仅仅进一步部署现有工具（如RFC 2827）是否是改善这种情况的更具成本效益的方法，存在着长期的争论。然而，事实证明，该工具的进一步部署工作进展缓慢。本实验中的一些原型解决方案允许一组网络运营商在等待通用部署时为其网络提供额外的保护
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.
类似地，由于当前的拒绝服务攻击中有很大一部分可以通过使用属于僵尸网络客户端的合法IP地址来发起，因此即使普遍部署更好的源地址验证技术也无法防止这些攻击。然而，由于更多地依赖于源地址的有效性，因此跟踪这些攻击会更容易。
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.
还有一个关于源地址验证检查的最佳位置的问题。最简单的模型是将支票放在网络的边界上。这种RFC 2827样式的检查比完全检查更广泛地部署，以确保网络中的所有地址都是正确的。可以说，提供这样的粗粒度检查就足够了，因为这样至少可以找到负责的网络管理员。但是，根据所讨论的网络类型，这些管理员可能会发现跟踪特定的违规机器或用户很容易，也可能不容易。很明显，管理员需要有一种跟踪违规设备或用户的方法——即使网络没有实时阻止伪造的数据包。
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.
用于地址验证的新技术也将面临许多部署障碍。例如，所有当前技术都可以在本地独立应用。考虑到ASE的数量，需要全局操作（如as间验证机制）的系统将需要大量的协调、部署同步、配置、密钥设置和其他问题。
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.
其中一些解决方案也可能会涉及大量成本。例如，在通常不需要接入网认证的环境中，采用基于认证的接入网地址验证将需要部署能够进行该认证的设备以及为所有设备分发凭据。通常，只有在仔细评估所涉及的成本和收益后，才会启动此类承诺。
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.
最后，所有提出的解决方案都存在一些问题，这些问题超出了主机始终通过同一单一接口连接到网络的简单模型。多宿、故障切换和某些形式的移动或无线解决方案可能会与源地址验证的要求相冲突。通常，对主机附件和路由基础结构拓扑的动态更改必须在生产环境中处理。
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.
在Inter-AS（非相邻AS）SAVA解决方案中，身份验证标签的安全性与可伸缩性是一个困难的权衡。[Brem05]中讨论了猜测两个AS成员之间身份验证标签的难度的一些分析。这是相对困难的，即使使用随机数作为“身份验证标签”。通过增加身份验证标记的长度，可以增加猜测的难度。
In any case, the random number approach is definitely vulnerable to attackers who are on the path between the two ASes.
在任何情况下，随机数方法肯定容易受到位于两个ASE之间路径上的攻击者的攻击。
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.
另一方面，在分组中使用实际的加密散列将导致转发分组所需的工作量显著增加。通常，添加选项和计算身份验证标记会消耗转发路径上的宝贵资源。在不断提高的线路速度下，这种资源的使用是现代路由器需要做的最重要的事情。目前还不清楚成本是否值得收益。
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.
在当前的CNGI-CERNET2 SAVA试验台中，一个128位身份验证标签被放置在IPv6逐跳选项标头中。数据包的大小随着身份验证标签的增加而增加。如果网络管理员认为需要额外的保护，则这本身是可以接受的。尺寸的增加可能会导致MTU问题，我们在测试床上找到了解决这个问题的方法。由于选择了IPv6逐跳选项标头，因此所有介入路由器都必须检查该选项标头。虽然理论上这不应该引起关注，但测试结果表明，与正常流量相比，许多当前路由器处理逐跳选项的吞吐量大大降低。
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,
内部AS（相邻AS）SAVA解决方案基于AS关系；因此，它可能不会很快与路由更改的动态同步，并且可能会导致误报。目前，
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.
CNGI-CERNET2是一个相对稳定的网络，该方法在试验台上运行良好。我们将进一步研究不稳定网络中误报的影响。
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.
接入网地址验证解决方案只是众多方案中的一种。解决方案似乎高度依赖于所选择的链路技术和网络体系结构。例如，点到点链接上的源地址验证很容易，并且多年来一直受到实现的支持。共享网络中的验证问题更大，但考虑到跨管理边界（如DSL）使用以太网技术，验证的重要性正在增加。在任何情况下，原型解决方案都有一些限制，包括决定使用新的地址配置协议。在生产环境中，需要一种适用于所有IPv6地址分配机制的解决方案。
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.
该实验还为基于交换机的本地子网验证、基于网络身份验证、基于过滤器的内部AS验证和基于身份验证标签的内部AS验证机制提供了概念证明。需要修改客户端主机和网络设备，并部署一些新服务器。
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.
然而，正如前一节所讨论的，原型设计和整个源地址验证空间中存在许多限制、问题和问题。
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:
我们希望，其中一些经验将有助于供应商和互联网标准社区的这些努力。今后在这方面的工作应尝试回答第5节中提出的一些问题。未来的一些关键问题包括：
o Scalability questions and per-packet operations.
o 可伸缩性问题和每包操作。
o Protocol design issues, such as integration to existing address allocation mechanisms, use of hop-by-hop headers, etc.
o 协议设计问题，如与现有地址分配机制的集成、逐跳标头的使用等。
o Cost vs. benefit questions. These may be ultimately answered only by actually employing some of these technologies in production networks.
o 成本与效益问题。只有在生产网络中实际应用其中一些技术，才能最终解决这些问题。
o Trust establishment issue and study of false positives.
o 信任建立问题和误报研究。
o Deployability considerations, e.g. modifiability of switches, hosts, etc.
o 可部署性注意事项，例如交换机、主机等的可修改性。
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.
本文件的目的是报告实验结果。本文档中提到了测试床解决方案机制的一些安全注意事项，但不是本文档中要描述的主要问题。
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.
本实验在清华大学、北京大学、邮电通信学院、上海交通大学、武汉华中科技大学、南京、广州等12所高校进行。东北大学在沈阳，西安交通大学，山东大学在济南，成都电子科技大学在中国，重庆大学。作者要感谢在这些大学里参与这项工作的每一个人。
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.
作者要感谢Jari Arkko、Lixia Zhang和Pekka Savola对本文档的详细评论，并感谢Paul Ferguson和Ron Bonica对解决方案开发和测试床实施的宝贵建议。
[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.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[Brem05] Bremler-Barr, A. and H. Levy, "Spoofing Prevention Method", INFOCOM 2005.
[Brem05]Bremler Barr，A.和H.Levy，“欺骗预防方法”，INFOCOM 2005。
[Li02] Li,, J., Mirkovic, J., Wang, M., Reiher, P., and L. Zhang, "SAVE: Source Address Validity Enforcement Protocol", INFOCOM 2002.
[Li02]李，J.，米尔科维奇，J.，王，M.，赖尔，P.，和L.张，“保存：源地址有效性实施协议”，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.
[Park01]Park，K.和H.Lee，“基于路由的包过滤在幂律互联网中预防分布式拒绝服务攻击的有效性”，SIGCOMM 2001。
[Snoe01] Snoeren, A., Partridge, C., Sanchez, L., and C. Jones, "A Hash-based IP traceback", SIGCOMM 2001.
[Snoe01]Snoren，A.，Partridge，C.，Sanchez，L.，和C.Jones，“基于哈希的IP回溯”，SIGCOM2001。
[Wu07] Wu, J., Ren, G., and X. Li, "Source Address Validation: Architecture and Protocol Design", ICNP 2007.
[Wu07]Wu，J.，Ren，G.，和X.Li，“源地址验证：架构和协议设计”，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.
[XBW07]Xie，L.，Bi，J.，和J.Wu，“部署在IPv6边缘网络中的基于身份验证的源地址欺骗预防方法”，ICCS 2007。
Authors' Addresses
作者地址
Jianping Wu Tsinghua University Computer Science, Tsinghua University Beijing 100084 China EMail: jianping@cernet.edu.cn
吴建平清华大学计算机科学，清华大学北京100084中国电子邮件：jianping@cernet.edu.cn
Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China EMail: junbi@cernet.edu.cn
毕军清华大学网络研究中心，清华大学北京100084中国电子邮件：junbi@cernet.edu.cn
Xing Li Tsinghua University Electronic Engineering, Tsinghua University Beijing 100084 China EMail: xing@cernet.edu.cn
邢莉清华大学电子工程，清华大学北京100084中国电子邮件：xing@cernet.edu.cn
Gang Ren Tsinghua University Computer Science, Tsinghua University Beijing 100084 China EMail: rg03@mails.tsinghua.edu.cn
任刚清华大学计算机科学，清华大学北京100084中国电子邮件：rg03@mails.tsinghua.edu.cn
Ke Xu Tsinghua University Computer Science, Tsinghua University Beijing 100084 China EMail: xuke@csnet1.cs.tsinghua.edu.cn
徐克清华大学计算机科学，清华大学北京100084中国电子邮件：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
Mark I.Williams Juniper Networks北京市东城区东长安街1号东方广场W3大厦1508室邮编：100738中国电子邮件：miw@juniper.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.