域间源地址验证方案 SAVA-X实现机制

域间源地址验证方案 SAVA-X实现机制

如图1 信任联盟示意图所示，部署了SAVA-X方案的所有AD（Address Domain，地址域）组成一个信任联盟，联盟内的每个AD成为联盟成员，联盟外的AD成为非联盟成员。每一个联盟成员AD都有一个ACS（AD Control Server，控制服务器）。
SAVA-X采用去中心化的联盟链管理联盟的成员列表，控制联盟成员的加入和离开。
ACS之间通过SM（State Machine，状态机）进行协商和生成标签，进而将这些标签部署到本AD的AER（AD Edge Router，边界路由器）上，标签被源AD的出口路由器加在报文中，被目的AD的入口路由器检验，从而验证报文源地址前缀的正确性。
图1-3567 信任联盟示意图

通过标签的添加和检验，联盟成员可以验证彼此的报文源地址前缀，从而可以建立起相互的信任关系，防止其他AD内的主机伪造成本AD内的主机，并可以在探测到攻击的时候对不可信任的连接进行限速等措施来减少自己的损失。
SMA（State Machine based Anti-spoofing，源地址验证方案）要求组成联盟的成员AS（Autonomous System，自治系统）两两之间维护状态机，如果所有的AS都加入一个信任联盟，将会导致每个AS维护的网络规模以及状态机空间负载过大，方案的可行性受到严重影响。由此SAVA-X方案被提出，该方案对域间方案在如下两方面做了更新：
信任联盟做分层机制，并在层级之间引入标签验证替换机制。
将信任联盟成员的概念扩展为地址域级别。
如图1-3568所示：
图1-3568 信任联盟分层示意图

SAVA-X主体职责介绍
SAVA-X协议共分为两个层面：数据层面和控制层面。
(1) 数据层面包括在源AD的边界路由器上添加标签、在跨层的边界路由器上进行标签校验和替换、在目的AD的边界路由器上对标签进行检查。数据层面的参与主体为AD的边界路由器。

(2) 控制层面包括成员注册信息的提交与分发、状态机的协商、变更与同步，边界路由器的配置等，其参与主体为ACS（AD Control Server，控制服务器）和AER（AD Edge Router，边界路由器）。控制服务器和边界路由器的主要职责如下：
(1) 控制服务器：
通过安全信道与联盟链的其他ACS进行通信，完成职责2～3。
向子信任联盟管理员节点提交本AD的注册信息变更请求。
接收子信任联盟管理员节点发布的变更信息，并进行处理。
通过安全信道与联盟中其他AD的控制服务器进行通信，完成职责5～9。
向其他ACS发送本AD地址前缀信息。
从其他ACS接收相应AD的地址前缀信息。
向其他ACS发送本AD到相应AD的状态机信息。
从其他ACS接收相应AD到本AD的状态机信息。
制定添加标签、检查标签、部署等策略。
通过安全信道与本AD的AER进行通信，完成职责11～13。
将其他AD域的地址前缀信息部署到AER。
通过KeepAlive报文与AER报持连接。
将标签信息部署到AER。
(2) 边界路由器（AER）：
通过安全信道与本AD的ACS进行通信，完成职责2～6。
接收ACS部署的地址前缀信息，并根据地址前缀信息指导数据面报文标签添加和校验。
接收ACS部署的标签信息，并用于数据面报文标签添加和校验。
添加标签：对源自本AD、宿于其他成员AD的IPv6报文添加标签。
检验标签：对源自其他成员AD、宿于本AD的IPv6报文检查标签正确性并进行响应处理。
标签替换：对于跨层发送的IPv6报文，在跨层边界路由器上，根据地址前缀和接口层级信息判断标签校验和替换。

AER功能简介
目前，NetEngine 8800 X, NetEngine 8100 X, NetEngine 8000 X, NetEngine 8000E X支持AER的大部分功能，下面将分为数据层面和控制层面，对NetEngine 8800 X, NetEngine 8100 X, NetEngine 8000 X, NetEngine 8000E X已经实现的功能进行具体的介绍。
数据层面
AER是数据层面的功能主体，其职责如下：
端口分类
为了正确对报文进行分类，以完成标签的添加、检查和报文的转发，需要对AER的端口进行分类。如图1-3569所示，AER的任何一个已连接的端口必须属于且仅属于下面一类端口：
Ingress Port：连接到本AD中非SAVA-X路由器的端口；
Egress Port：连接到其他AD的端口；
Trust Port：连接到本AD中SAVA-X路由器的端口。
图1-3569 Ingress/Egress/Trust端口
   

(1) 源地址检查
在SAVA-X中，AER必须对报文的源地址进行检查，只有通过该检查的报文才进行“报文分类”步骤，将使用了假冒源地址的报文丢弃。
从AD域Egress接口往其他AD域发送报文时，处理规则如下：
    报文目的地址属于本AD域，直接转发。
    源地址属于本AD域， 目的地址属于其他AD域，需要添加标签。
    源地址属于其他AD域，目的地址属于其他AD域，过路场景，直接转发。
    源地址属于其他AD域，目的地址属于其他AD域，跨层场景，校验低层标签，如果校验通过，替换为高层标签后转发，如果校验失败，则丢弃报文。
    源地址属于非信任联盟，直接转发。
    目的地址属于非信任联盟，直接转发。
从AER Egress接口进入本AD域时，处理规则如下：
    报文来自其他AD域，源地址属于本AD域，直接丢弃。
    源地址属于其他AD域，目的地址属于本AD域，需要校验标签。
    源地址属于其他AD域，目的地址属于其他AD域，过路场景，直接转发。
    源地址属于其他AD域，目的地址属于其他AD域，跨层场景，校验高层标签，如果校验通过，替换为低层标签后转发，如果校验失败，则丢弃报文。
    源地址属于非信任联盟，直接转发。
    目的地址属于非信任联盟，直接转发。
本AD所拥有的地址前缀由控制层面的协议获得，并由本AD的ACS部署到AER上。
(2) 标签更新
AER不运行状态转移算法，定时从ACS获得新的标签。
添加标签
SAVA-X的标签作为一个新类型的Option加入IPv6的Destination Option Header中，这种新定义的Option命名为SAVA-X Option。对于应添加标签的报文要分三种情况添加SAVA-X Option。
    原报文中不含有Destination Option Header：按照相关标准加入Destination Option Header，并在其中加入SAVA-X Option。
    原报文中含有Destination Option Header，但不含有SAVA-X Option：按照相关标准在Destination Option Header中加入SAVA-X Option。
    原报文中含有Destination Option Header，同时含有SAVA-X Option：将SAVA-X Option插入到报文中已有Option之前。

(3) 验证标签
    原报文中不含有Destination Option Header，或不含有SAVA-X Option：将该报文丢弃。
    原报文中含有SAVA-X Option，但参数或标签不正确：将该报文丢弃。
    原报文中含有SAVA-X Option，参数和标签均正确：移除SAVA-X Option再将报文转发。

(4) 特殊处理
为了应对ACS异常场景，无法向AER更新标签时，防止造成数据面断流，进行如下特殊处理：

    标签老化后，AER删除对应标签。
    源AD域AER转发报文，无法查到标签时，封装0标签发送。
    目的AD域AER接收报文，无法查到标签时，不对报文进行校验。

控制层面
控制层面的通信包括两个部分：一是ACS与ACS之间的通信，用于地址前缀信息和状态机信息的宣告、查询和应答，以及诊断请求与应答；二是ACS与AER之间的通信，用于对地址前缀信息和标签信息的部署、查询和应答，KeepAlive请求与应答。
这两个部分的控制协议均使用TCP协议通信，并使用SSL进行身份的验证与消息加密。此外ACS与ACS、ACS与AER之间还需要通过NTP协议来保持时间的同步。
    ACS与AER之间的通信
    成员AD可以通过ACS与AER之间的通信来对AER进行地址前缀信息、标签信息的部署等。具体的通信内容包括如下四个部分：
        地址前缀信息的部署、查询与应答，包括：
            ACS向AER部署地址前缀信息。
            AER向ACS查询地址前缀信息。
            ACS向AER应答地址前缀信息的查询请求。
        标签信息的部署包括：
            ACS向AER部署标签信息。
        Keepalive存活性检测与应答，包括：
            ACS向AER发送Keepalive消息。
            AER应答Keepalive消息。

为了保证AER上的信息最新，ACS要将所有的最新信息定时部署给AER，即：每隔一段时间，ACS将所有联盟成员（包括本AD）的全部地址前缀信息、以及与其他AD域更新的标签信息部署给本AD域内所有AER。
协议通过ACS向AER发送ALIVE_INFO-Request报文对AER进行存活性检测。AER收到查询后应回复ACK来应答。如果ACS在60秒内没有收到来自AER的应答，则ACS认为AER出现了故障，并将故障信息通知本AD管理员。同时保持对该故障AER发送存活性信息查询请求。当AER重新对查询给予正确的应答时，ACS认为其从故障中恢复。
术语与缩略语
缩略语