YD T 3900-2021 IP源地址验证技术要求 框架.pdf

《YD T 3900-2021 IP源地址验证技术要求 框架.pdf》由会员分享，可在线阅读，更多相关《YD T 3900-2021 IP源地址验证技术要求 框架.pdf（19页珍藏版）》请在麦多课文档分享上搜索。

1、 ICS 33.040.40 M32 中 华 人 民 共 和 国 通 信 行 业 标 准 YD YD/T IP 源地址验证技术要求 框架 Technical requirement framework for IP source address validation （报批稿） -发布 - 实施中 华 人 民 共 和 国 工 业 和 信 息 化 部 发布 YD/T i 目 次 前 言 .II 1 范围 .1 2 规范性引用文件 .1 3 术语、定义和缩略语 .1 3.1 术语和定义 .1 3.2 缩略语 .2 4 概述 .3 5 IP 源地址验证体系结构 .4 5.1 SAVA 体系结构 .4

2、 5.2 SAVA 体系结构的优点 .6 5.3 接入网 IP 源地址验证 .6 5.4 自治系统内 IP 源地址验证 .8 5.5 自治系统间 IP 源地址验证 .9 6 总结 .14 YD/T ii 前 言 本标准是以太网接入方式下源地址验证技术要求系列标准之一，本系列标准的名称和结构 预计如下： -IP 源地址验证技术要求框架 -以太网接入方式下源地址验证技术要求 框架 -以太网接入方式下源地址验证技术要求 DHCPv4 场景 -以太网接入方式下源地址验证技术要求 DHCPv6 场景 -以太网接入方式下源地址验证技术要求 SLAAC 场景 -以太网接入方式下源地址验证技术要求 多种地址分

3、配方式共存场景 -公众无线局域网接入方式下源地址验证技术要求 -以太网接入方式下源地址验证技术要求 管理信息库 本标准 按照 GB/T 1.1-2009 给出的规则起草。 请注意本文件的某些内容可能涉及专利。 本文件的发布机构不承担识别这些专利的责任。 本标准由中国通信标准化协会提出并归口。 本标准参加单位： 清华大学 、 中国电信集团公司、中国移动通信集团公司、华为技术有限公 司、中兴通讯股份有限公司、新华三技术有限公司、福建星网锐捷网络有限公司、烽火科技集团 有限公司、中国互联网络信息中心、迈普通信技术股份有限公司。 本标准主要起草人 ： 吴建平、毕军、李星、任罡、徐恪、胡虹雨、王之梁、李

4、崇荣、刘莹、徐 明伟。 YD/T 1 IP 源地址验证技术要求 框架 1 范围 本标准规定了 互联网 IP 报文源地址有效性验证的层次化解决架构，并规定了各层次需实现的源地 址验证的效果及目标， 以系统地解决互联网 IP 源地址有效性验证问题。同时对各层次的源地址验证方 案给出了可能的方案设计示例。 本标准适用于互联网一般路由寻址场景下的报文源地址验证。 2 规范性引用 文件 下列文件对于本文件的应用是必不可少的 。 凡是注日期的引用文件 ， 仅所注日期的版本适用于本文 件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 IETF RFC2827 网络入口过滤 协议 （

5、Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing） IETF RFC3704 多宿主网络入 口过滤 （ Ingress Filtering for Multihomed Networks） 3 术语 、 定义和缩略语 3.1 术语和定义 下列术语和定义适用于本文件。 3.1.1 源地址验证 Source address validation 在 IP报文路由寻址过程中，对其携带的源地址的有效性进行验证。 3.1.2 源地址验证架构 Sour

6、ce address validation architecture YD/T 2 在互联网范围对 IP报文进行源地址验证的层次化解决架构 ， 与互联网目前路由寻址的层次化结构相 对应。 3.1.3 接入网源地址验证 /源地址验证增强 Source address validation improvement 在主机所在接入网执行的源地址验证技术 ， 将不允许主机假冒任意非合法分配或配置的地址 。 是源 地址验证的第一步关卡，因此谓之源地址验证增强。 3.1.3 自治系统内 IP源地址验证 Intra-AS source address validation 在自治域 AS内执行的源地址验证技

7、术，将不允许主机假冒该自治域其他子网的 IP地址。 3.1.4 自治系统间 IP源地址验证 Inter-AS source address validation 在自治域 AS间执行的源地址验证技术，将不允许主机假冒其他自治域网络的 IP地址。 3.2 缩略语 下列缩略语适用于本标准。 AIMS AS-IPv6前缀映射服务器 AS-IPv6 prefix Mapping Server AS 自治系统 Autonomous System ASBR AS边界路由器 AS Border Router ASC AS控制服务器 AS Control Server DHCP 动态主机配置协议 Dynami

8、c Host Configuration Protocol NAT 网络地址转换 Network Address Translation REG 注册服务器 Registration Server SAMS 源地址管理服务器 Source Address Management Sever SARC 源地址请求客户端 Source Address Request Client YD/T 3 SAVP 源地址验证代理 Source Address Validation Proxy SEND 安全邻居发现协议 Security Neighbor Discovery SLAAC 无状态地址自动配置 S

9、tateless Address Autoconfiguration VE 验证引擎 Validating Engine VR 验证规则 Validation Rule VRGE 验证规则生成器 Validation Rule Generating Engine 4 概述 现有互联网的 IP分组转发 ， 主要基于目的 IP地址 ， 很少对分组的 IP源地址的有效性进行检查 ， 这使 得分组的 IP源地址容易被伪造 。 网络攻击者常常通过伪造分组的 IP源地址逃避承担责任 。 对 IP源地址的 有效性进行验证已经成为互联网面临的一个挑战性的问题。 “IP源地址的有效性”包含以下三重含义： a)

10、合法的。 IP源地址必须是经互联网 IP地址管理机构分配 /授权的合法地址，不能伪造； b) 唯一的 。 公网 IP地址在公网内全局唯一 ， 同一时间不可复用 ； 私网 IP地址在其私网内全局唯一 ， 同一时间不可复用； c) 可追溯的。网络中转发的 IP分组，可以根据其 IP源地址找到其所有者和位置。 互联网中实施 IP源地址验证后有助于实现如下目标： a) 由于携带假冒源地址的报文不能再被转发 ， 则使用假冒源地址发动网络攻击将变得不可能 ， 或 者通过使用假冒源地址成功实施网络攻击的难度将加大； b) 如果所有报文的源地址都是正确的 ， 则网络追溯将可以准确实现并具有可信性 。 这将使网

11、络诊 断、网络管理、网络统计以及上层应用得到受益。 要实现全网的 IP源地址验证 ， 期望任何一个单一源地址验证技术或方案在互联网单一层面完全部署 是不切实际的 。 考虑到 IP分组在互联网的路由和寻址是一个层次化的结构 ， 本标准规定了一种多层次的 源地址验证的解决架构，即“ IP源地址验证体系结构”（ SAVA： Source Address Validation YD/T 4 Architecture）。具体来说， SAVA体系结构划分为 3个层次：接入网 IP源地址验证、自治系统内 IP源地 址验证和自治系统间 IP源地址验证。本标准同时针对各层次可能的源地址验证方案给出了示例。 5

12、IP 源地址验证体系结构 5.1 SAVA 体系结构 本标准提出了一种多层次防御的源地址验证解决方案 ， 即在网络中设计有多个 “点 ”对数据包源地 址的有效性进行检查 。 这是因为在当前单一 （ single-fence） 模型下 ， 基本上只在报文进入网络时进行 了源地址有效性检查 RFC2827。但目前这种接入检查的部署是显著不足的（在未来仍将继续持续）， 因此基于伪造源地址的网络攻击总还是有机可乘。一种多层次的验证方案将弥补这种部署中的“漏 洞 ”， 整个互联网源地址有效性的可信度也将得到提升 。 即使源地址有效性检查没有全面部署 ， 一定程 度增加源地址有效性可信度以及减少假冒源地址

13、攻击的几率，仍然是有意义和价值的。 同时 ， SAVA体系结构允许多个独立的 、 松耦合的验证方案 （或机制 ） 同时存在 。 这样设计的出发点 是 ， 在 Internet上 ， 期望任何单一的 IP源地址验证机制得到普遍支持是不现实的 。 不同的运营商和供应 商可以选择部署或开发不同的方案（或机制）来实现源地址验证，同时需要设计不同的方案（或机制 ） 来解决网络中不同地方的问题。此外，局部方案（或机制）实施过程中的 bug或者配置的错误都可能会 导致局部验证失效 。 因此 ， 本标准中的 SAVA体系结构在具体实现时实际上 是多个方案 （或机制 ） 同时共 存 、 互相协作的方式 。 考虑

14、到 IP分组在互联网的路由和寻址是一个层次化的结构 ， 本标准设计了与之对 应的多层次的 IP源地址验证体系结构 -SAVA。 具体来说 ， SAVA体系结构划分为 3 个层次 ： 接入网 （ Access Network） IP源地址验证、自治系统内（ Intra-AS） IP源地址验证和自治系统间（ Inter-AS） IP源地址 验证，如图 1所示。 YD/T 5 图 1 IP源地址验证体系结构 本标准将源地址验证解决方案按三个不同层次进行分类： a) 接入网源地址验证 。 该验证可以防止网络中的主机假冒同一网段中其他主机的地址 。 与域内源 地址验证相比，接入网源地址验证可以实现主机粒

15、度的保护。具体见第 5.3节； b) 域内源地址验证 。 在接入网的边缘路由器的接口上执行 “入口过滤 ”源地址验证方案时 （ 例如 ： 使用 RFC2827和 RFC3704） ， 可以防止主机假冒其他网段地址 ， 实现子网粒度的保护 。 但如 果该接口下子网没有部署接入网源地址验证时 ， 仅 实施 “入口过滤 ”， 主机仍可以假冒同一网 段中其他主机的地址 ， 除非该路由器下只接有一台主机 （一种极端情况） 。 （因此接入网源地 址验证是对“入口过滤”方案的一种补充和增强，因此接入网源地址验证又称为 Source Address Validation Improvement， SAVI）。

16、具体见第 5.4节； c) 域间源地址验证 。 在自治域间执行的数据包源地址有效性的验证机制 。 由于全球互联网为网状 拓扑结构 ， 并且不同的网络属于不同的管理机构 ， 因此域间 IP源地址验证更具挑战性 。 尽管如 此 ， 当前面两层 （接入网和域内 ） 源地址验证缺失或失效时 ， 这第三层保护对于检测报文是否 使用假冒源地址仍是十分必要的。具体见第 5.5节； 不同的层次实现不同粒度的 IP源地址有效性验证。在每一个层次，允许不同的运营商采用不同的 方法。这一体系结构设计是一个整体结构的简单性和各部组成的灵活性的平衡。 YD/T 6 5.2 SAVA 体系结构的优点 SAVA 体系结构的

17、优点如下： a) 多重防御：对于一个伪造源地址的分组，设置接入网、自治系统内和自治系统间 3道防线以实 现真实源地址验证； b) 不影响现有性能 ： 设计各层次简单且轻量级源地址验证方案，将不影响现有路由和交换设备的 分组转发性能； c) 松耦合：该体系结构划分为自治系统内、自治系统间和接入网 3个部分，各个部分相互独立， 每个部分可以实现不同粒度的真实地址检查，每个部分的功能实现不依赖于其他部分； d) 支持增量部署 ： 该体系结构支持在全网渐进的、增量的部署，部分部署时仍可获得一定程度的 真实源地址验证效果； e) 可扩展：该体系结构划支持在整个互联网的大规模部署； f) 为上层安全服务和

18、应用提供支持 ： 以真实源地址体系结构为基础，网络追溯、网络诊断、网络 管理、网络统计等上层安全服务和应用都将收益； g) 激励运营商部署 ： 该体系结构的设计体现了“谁部署，谁受益 ”的原则，部署了真实地址验证 机制的网络可以更加容易地发现和追踪网络中伪造源地址的分组，保护自身网络利益。 5.3 接入网 IP 源地址验证 该层次的方案 ， 将不允许主机 （ host） 假冒同一网段上的其他主机的 IP地址 ， 主机地址应该是由静 态或动态分配给主机的合法地址，实现端系统 IP地址一级的细粒度的 IP源地址验证。 接入网 IP源地址验证具有以下特点： a) 所有相关网络设备在同一个网络管理机构

19、管理控制下； b) 解决方案与接入网的地址管理分配和控制策略密切相关； c) 解决方案与端系统的接入方式密切相关。 可以针对接入网的各种主机地址分配方式 ， 如 DHCP、 DHCPv6、 SLAAC、 SEND、 静态地址分配方式等 ， 甚至是混合地址分配场景，设计其特定的接入网源地址验证方案。 YD/T 7 针对目前网络中大量端系统通过交换机接入网络的情形， 可以采用的解决方案包括 ： 在交换机的端 口和真实合法的 IP地址之间建立动态绑定，并对非法源地址报文进行过滤。 接入网 IP源地址验证方案示例： 本标准以以太网网络为例设计了一种 接入网 IP 源地址验证方案 A。 方案 A 的关键

20、步骤是在交 换机端口和合法的 IP 源地址之间建立一个动态绑定 ， 即在 MAC 地址 、 IP 源地址和交换机物理端口 之间建立一个绑定 。 在具体原型实现中 ， 该绑定是通过主机使用一种新的交换机可跟踪的地址分配 协议来建立的。 在方案 A 中， 主要由 3 部分组成 ： 主机上的源地址请求客户端（ SARC） ，交换机上源地址验证 代理（ SAVP），以及源地址管理服务器（ SAMS）。 如图 2 所示。解决方案分为以下基本步骤： a) 终端主机上的 SARC 发送一个 IP 地址请求 。 交换机上的 SAVP 将此请求转发给 SAMS， 并记 录 MAC 地址和传入端口 。 如果终端主

21、机已经预先确定了某地址 ， 终端主机需将该地址放入 请求消息中以便 SAMS 进行验证； b) SAMS 收到 IP 地址请求后，它将基于本子网的地址分配和管理策略， 来为该 SARC 分配一 个源地址 ， 同时它将在 SAMS 历史数据库中记录 该分配的 IP 地址 ， 以方便跟踪和回溯 ， 然 后发送包含该分配地址的响应消息给 SARC； c) 交换机上的 SAVP 收到响应消息后 ， 它将在绑定表中建立 IP 地址 、 请求消息中的 MAC 地址 、 交换机端口的一个绑定表项。然后， 将分配的地址转发到终端主机上的 SARC； d) 接入交换机开始过滤从终端主机发送的数据包 。 不符合绑

22、定表 （ IP 地址 ， MAC 地址 ， 交换 机端口）的数据包将被丢弃。 YD/T 8 图 2 接入网 基于绑定的 IP 源地址验证 本标准在测试环境中 ， 实现并试验了这种解决方案 。 该方案 （基于交换机的解决方案 ） 具有较 好的性能 ， 但是接入网络中的交换机需要升级 ， 而通常接入网络中交换机的数量是非常巨大的 ， 交 换机升级任务较重。 5.4 自治系统内 IP 源地址验证 该层次的方案，将不允许主机（ host） 假冒其他网段的地址，实现前缀（子网 ） 粒度的 IP源地 址验证。 由于自治系统内的网络设备都在同一个管理机构管理之下 ， 该层次的源地址验证技术或方案可 以在运营

23、商网络和接入网络的边界部署。 可以采用的解决方案包括 ： 在接入网的边缘路由器上部署“入口过滤 ”验证规则，这些规则把 每一个路由器的接口和一组真实有效的 IP 地址前缀关联起来。本标准采用了 RFC2827和 RFC3704中描述的“入口过滤 ”IP 数据包源地址验证解决方案； 后者描述了 multi-homed 接入网 络的入接口上的源地址验证。 YD/T 9 RFC2827简介：在接入网的边缘路由器上，对配置了网络地址的三层接口同时是非上行口进 行 ”入口过滤 ”配置，过滤配置将丢弃所有与此网络接口地址前缀不符合的输入报文。该过滤配置 最终是 以 ACL 的形式实现。 实施 “入口过滤

24、”后 ， 非本网络有效地址前缀的报文都将无法进入自治域内 ， 实现了 IP地址前缀粒 度的 IP源地址验证 。 但如果该接口没有部署接入网源地址验证 ， 仅部署 了 “入口过滤 ”， 攻击者仍可以 假冒同一网段中其他主机的地址，除非该路由器下只接有一台主机（一种极端情况）。 5.5 自治系统间 IP 源地址验证 该层次的方案 ， 将不允许主机 （ host） 假冒其他自治域网络的 IP地址 ， 实现自治系统粒度的 IP源地 址验证。 该层次相关技术或方案将在 AS的边界执行相关源地址验证检查 ， 以确保报文源地址的正确性 。 由于 整个 Internet是一种由 AS组成的网状拓扑 ， 且不同

25、的 AS属于不同的管理者 ， AS级的源地址验证是极为复 杂和极具挑战性的。然而当前面两层（接入网和域内）源地址验证没有部署或者失效的时候，第 3层次 的保护，即在 AS边界检查假冒源地址的报文，是十分必要的。 设计域间源地址验证方案时要考虑以下要素： a) 需要属于不同管理权以及不同利益的 AS之间进行协同合作； b) 需要足够轻量级，以维持 AS间高吞吐率，不影响现有转发效率。 域间源地址验证可以分为以下两类： a) 相邻 AS 间（即， 两个支持 SAVA 机制的 AS 是直接相邻交换流量的）； b) 非 相邻 AS 间（即， 两个支持 SAVA 机制的 AS 被一个或多个不支持 SAV

26、A 机制的 Provider 隔开）。 自治系统间（相邻 AS间） IP源地址验证方案示例，以 IPv6网络为例： YD/T 10 图 3 域间（相邻 AS）源地址验证方案 两 个 交 换 流 量 的 AS 之 间 可 能 是 customer-to-provider 、 provider-to-customer ， peer-to-peer ， or sibling-to-sibling 其 中 的 一 种 关 系 。 在 customer-to-provider 或 provider-to-customer 的关系中 ， customer 通常属于一个较小的管理域 ， 它 为访问 Inte

27、rnet 的其 他部分而向一个较大的管理域进行付费 。 provider 是属于更大的管理域的 。 在 peer-to-peer 关系 中 ， 这两个 互为 Peer 关系的 AS 通常都属于具有一定规模的管理域 ， 并发现在它们各自的客户之间 交换流量对它们彼此是有利的。 当两个 AS 它们属于同一个管理域，或者所属管理域间存在交换流 量的合作协议的话，那么这 两个 AS 就属于 sibling-to-sibling 的关系。 本标准为 支持 SAVA 机制且相 邻的 AS 间设计了一种基于 AS 关系的解决方案 （机制） 。 基于 AS 关系的解决方案的基本思想如下 。 它构建了一个验证

28、规则过滤表 （ VR） ， 它将路由器的每个入接口 与一系列合法的源地址前缀关联起来， 然后使用 VR 表过滤假冒数据包。 在具体解决方案中， 验证 IPv6 地址前缀的解决方案分为三个功能模块：验证规则生成引擎 （ VRGE）、验证引擎（ VE）、 AS 和 IPv6 前缀关系映射服务器（ AIMS）。 由 VRGE 生成的验证规则 表示为 IPv6 地址前缀形式。 每个 AS 都有一个 VRGE， VRGE 生成根据表 1 生成验证规则 VR。 VE 加载 VRGE 生成的验证规则 VR， 来过滤在 AS 之间传递的包 （ 在图 3 中 ， 从相邻 AS 发送 给 AS-1 的报文） 。

29、在本标准的具体实现中 ， VE 实现为一个基于 Linux 系统机器的仿真 2 层设备， 它串联在 ASBR 每个面向 邻接 AS 接口外的直 YD/T 11 连数据路径上。在真实实现时，它可以实现为一个数据包过滤设备串联 在 ASBR 上。 AS-IPv6 前缀 映射服务器也是 以 Linux 系统形式实现 ， 它生成 IPv6 前缀和该前缀对应的 AS 号之间的映射关系表 。 表 1 基于 AS 关系的 域间 AS 过滤表 Own Customers Siblings Providers Peers Export To Address Address Address Address Add

30、ress Provider Y Y Y Customer Y Y Y Y Y Peer Y Y Y Sibling Y Y Y Y Y 不同 的 AS 根据 VRGE 上 的基于 AS 关系的输出规则来交换和输出各自 的 VR 信息。 如表 1 所示 ， AS 将它自己的、 其 customers 的、 其 providers 的、 其 siblings 的以及其 peers 的 IPv6 地址前 缀 ， 输出 给它的 customers 和 siblings， 作为 其 customers 和 Siblings 可接收的合法地址前缀 集 ； AS 将它自己的、 其 customers 的、

31、以及其 siblings 的 IPv6 地址前缀输出 给它的 providers 和 peers， 作为 其 providers 和 peers 可接收的合法地址前缀 。 在 AS-IPv6 前缀映射服务器支持下 ， AS 间仅需传递合法地址前缀 的 AS 号， AS 号可 在 VRGE 中转换为 该 AS 号对应 的 IPv6 地址前缀。 当 AS 关系发生 改变或者一个 AS 所包含 的 IP 地址前缀发生变化时，需要 重新生成 VR 并更新 。 基于 AS 关系的域间源地址验证方案的认证过程主要步骤如下（ 图 3 中 从 AS-1 域开始）： a) 当一个 AS 的 VRGE 初始化时，

32、将读取其 相邻的支持 SAVA 的 AS 列表，并和本域内 的所有 VE 建立连接； b) VRGE 初始化一个 VR 更新消息。 VRGE 根据其输出表（ 表 1），把 自己原始的 VR 发 送 给邻接 AS 的 VRGE。在此过程中， VR 以 AS 数量级进行扩散； YD/T 12 c) 当一个 VRGE 从其邻居接收到一个新的 VR， 它将通过自己的输出表来判断它是否应 该接受 该 VR，如果接受，它是否应该 将该 VR 再输出给 其他相邻的 AS； d) 如果 VRGE 接受了一个 VR， 它将使用 AIMS 将 用 AS 表述的 VR 转换为 用 IPv6 前缀表 述 的 VR；

33、e) VRGE 将 该 VR 推送给本域内的 所有 VE； f) VE 使用合法前缀形式 的 VR 来验证每个入报文的源 IP 地址是否合法有效。 自治系统间（非相邻 AS间） IP源地址验证方案示例，以 IPv6网络为例： 当 两个 AS 不是直接交换报文的情况下，上节描述的解决方案将无法实施。然而，对于非相邻 的 ISP 来说 ， 如果能够形成一个信任联盟 ， 这样 ， 一个 AS 发送的报文 ， 将会被联盟中 其他 AS 所识 别 ， 因为报文 离开第一个 AS 时携带了验证信息 。 可以通过很多种方法来实现这一目标 。 在 SAVA 实 验环境中，目前设计了一种身份验证标签方法。该解决

34、方案受到参考文献 1的启发。 该机制（基于轻量级身份验证标签的域间源地址验证方案 ） 的关键要素如下 ： 在每对支持 SAVA 的 AS 间 ， 分配有一对唯一的临时身份验证标签 。 所有支持 SAVA 的 AS 共同组成一个 SAVA 联盟 。 当 一个数据包离开其 AS 时， 如果目标 IP 地址属于某 SAVA AS 联盟中的某个 AS， 那么源 AS 的边缘路 由器将使用目的 AS 号 作为 Key 来查找与 目的 AS 对应的身份验证标签 ， 并且在数据包中加入该身份 验证标签。 当数据包到达目的 AS 时， 如果数据包的源地址属于 SAVA AS 联盟中的某个 AS， 则目的 AS

35、 的边缘路由器在它的表中使用源 AS 号作为 Key 来查找与 源 AS 对应的身份认证标签，并将该标 签与报文中的标签进行验证 ， 验证完成后 ， 身份认证标签将从报文中删除 。 正如其名字所示 ， 该特 殊方案使用了轻量级的身份验证标签。对于转发的每一个数据包，身份验证标签被 放在一个 IPv6 的 hop-by-hop 扩展头中。身份验证标签 为 128 位的共享随机数，这比通过加密方法生成身份验证 标签在处理方面的开销要更合理。 与仅部署网络本地源地址验证相比，该方案的 好处在于 ： 当一组网络仅部署了本地源地址验证 时，只能保证他们自己的网络不向外发送假冒报文，而不能保证其他网络不向

36、它们发送假冒报文 。 而该域间源地址方案在一定程度上消除了这种情况 ， 如果联盟外的主机使用联盟内某主机的地址来 发送假冒数据包， 则联盟成员 AS 将发现并拒绝接受这样的数据包。 YD/T 13 图 4: 域间（ 非相邻 AS） 源地址验证解决方案 在该系统中主要有 3 个组成部分：注册服务器（ Registration Server， REG）， AS 控制服务 器（ AS Control Server， ASC）， 以及 AS 边界路由器（ AS Border Router， ASBR）。 注册服务器 REG 是整个信任联盟（ trust alliance， TA）的“中心”。 它维护一

37、个 TA 的成员 列表。它执行两个主要功能： a) 处理来自 AS 控制服务器的获取 TA 成员列表的请求； b) 当 TA 成员列表变更时， 通知每个 AS 控制服务器。 每个部署了该方案的 AS 都有一个 AS 控制服务器 ASC。 该 ASC 有三个主要功能： a) 与注册服务器沟通， 获取最新的 TA 成员名单； b) 与其他联盟成员 AS 的控制服务器通信，更新的有效前缀信息以及交换身份认证标签； c) 与本 AS 的所有边界路由器通信，以配置边界路由器的处理功能。 AS 边界路由器 ASBR， 在源 AS 端负责向数据包中添加身份认证标签， 在目的 AS 端负责验证和 删除报文中的

38、身份认证标签。 在该系统的设计中， 为了减轻 REG 的负担， 大部分控制管理流量发生在 ASC 之间。 YD/T 14 身份认证标签需要定期更新 。 尽管每对 AS 之间维护和交换身份验证标签的开销 ， 从一个 AS 的 角度来看， 是 O（ N）， 而不是 O（ N 2）， 但通讯和处理的开销仍随着 AS 数量的增加而增加。因 此，在解决方案中使用了一个认证标签自动刷新的机制。在该机制中， 每个对等的 AS 运行相同的 算法 ， 以自动生成身份验证标签序列 。 这样 ， 数据包中的身份验证标签可以较高频率自动更新 。 为 了增强安全性 ， 该算法使用一个种子来生成身份认证标签序列 ， 以防

39、止标签猜测 。 因此 ， 联盟成员 只需要以非常低的频率协商和更新种子即可。这不仅降低了频繁协商和更新身份验证标签的开销 ， 同时保证了身份验证标签的一定的安全性。 由于身份验证标签是放在 IPv6 的 hop-by-hop 扩展头中 ， 因此需要考虑 MTU 问题 。 目前本标准 有两种解决方法。两种解决方案都不完美，但都是可行的。 一种可能的方法是在 ASBR 中设置 MTU 为 1280 字节， 这是 IPv6 的最低的 MTU。这样， 将不会收到从下游网关发来的 ICMP“数据包太大 ” 消息。 这种解决方案的缺点是不能很好地利用可用的 MTU。 另一种可能的方法是让 ASBR 捕获所

40、有 传入的 ICMP“数据包太大 ”消息， 然后在报文送入 AS 之前减小路由器 MTU 值。这种解决方案的优 点是它可以很好地利用可用的 MTU。但是， ASBR 在处理 ICMP 包时可能会成为拒绝服务攻击（ DoS） 的一个目标。 因为身份验证标签是在目的边界路由器上进行验证的 ， 而不是目标主机 ， 因此本标准没有使用 目的地选项扩展头来携带身份验证标签。 身份验证标签管理是一个关键问题。本标准 的工作主要集中在两点 ： 标签协商和标签更新。标 签协商发生在 SAVA 联盟的每对 AS 的 ASC 之间。 考虑到同步化的问题和使用 SAVA 的动机，本标准 提出了基于接收者的标签协商

41、。 它赋予接收方更多的决策权 ， 而不是发送方 。 在基于接收者的方案 下，接收方可以决定标签管理的策略。不允许无限期地接受携带旧身份验证标签的数据包。相反 ， 在新的标签协商出来后 ， 旧标签不是马上作废无效而是保留一段时间 。 该时间长度是可配置的参数 ， 它将控制旧标签在新标签生成之后仍然有效的时间长度 。 在具体实验中 ， 本标准设置该参数 为 5 秒 。 信任联盟是可以动态建立的 （加入和退出 ） ， 但是在本标准的具体实验床中 ， 信任联盟的最初成员 是在线下确认。 6 总结 YD/T 15 本标准设计并提出了“多层防御”的源地址验证体系 结构 SAVA，并在一些松耦合的自治域上

42、（ 12 个校园网）对其原型系统进行了较大规模的部署和验证。该体系结构允许不同粒度的源地址 验证 ， 并且允许不同的提供者提供不同的解决方案 。 不同粒度级别的解决方案之间是松耦合的 ， 同 时允许解决方案更新、替换。 允许增量部署是本体系结构的设计原则之一 。 测试表明 ， 即使在部署不完整的情况下 ， 部署者 也可以通过部署获得好处， 从而使 provider AS 有动机成为早期使用者。 SAVA 体系结构的各层次的示例解决方案：基于交换机的本地子网验证机制、基于网络认证的 域内验证机制、基于过滤的域间（ Inter-AS） 验证机制、基于认证标签的域间（ Inter-AS） 验证机 制等 ， 都得到了概念验证 。 其中有的客户端主机和网络设备需要修改 ， 有的还需要部署一些新的服 务器。 YD/T 16 参考文献 1 Bremler-Barr, A. and H. Levy, Spoofing P