动态主机配置和网络访问验证的制作方法

专利名称：动态主机配置和网络访问验证的制作方法
技术领域：
本申请涉及计算机网络，尤其涉及动态主机配置、组播安全和网 络访问验证。
背景技术：
网络和因特网协i义
存在多种类型的计算机网络，其中因特网最具声名。因特网是计 算机网络的全球网络。如今，因特网是数百万计用户可以使用的公共
的并且自给的网络。因特网使用被称为TCP/IP (即传输控制协议/因 特网协议)的一组通信协议来连接主机。因特网具有被称为因特网骨 干网的通信基础结构。对因特网骨干网的访问很大程度上由将访问权 转让给公司和个人的因特网服务提供商(ISPs)来控制。
对于IP(因特网协议)，这是一种协议，借助该协议，数据可以 在网络上从一个设备(例如电话，PDA个人数字助理，计算机等 等)传送到另一设备。现在存在IP的多个版本，包括例如Ipv4、 Ipv6 等。网络上每个主机设备具有至少一个作为其自己的唯一标识符的IP 地址。
IP是无连接协议。通信过程中端点之间的连接不是连续的。当用 户发送或者接收数据或者消息时，数据或消息被划分为被称为分组的 部分。每个分组作为数据的独立单元加以处理。
为了使因特网或类似网络上点之间的传送标准化，建立了 OSI(开 放系统互连)模型。OSI模型将网络中两点之间的通信过程分为七个 堆叠的层，其中每层添加其自己的功能集。每个设备处理消息，使得 在发送端点存在通过每个层的向下的流，并且在接收端点存在通过这 些层的向上的流。典型地，提供七层功能的程序和/或硬件是设备操作系统、应用程序软件、TCP/IP和/或其他传输和网络协议和其他软件 和石更件的组合。
典型地，当消息从用户传来或者传送到用户时，^使用上面四层， 当消息传送通过设备(例如IP主机设备)时，使用底部三个层。IP 主机是网络上任何能够发送和接收IP分组的设备，诸如服务器、路由 器或工作站。目的地为一些其他主机的消息不被传送到上面的层，而 是被转发到其他主机。下面列出OSI模型的层。第7层(即应用层) 是这样的层，即在该层中，例如识别通信伙伴，识别服务质量，考虑 用户验证和保密，识别对数据语法的约束等等。第6层(即表现层) 是这样的层，即该层例如将输入和输出的数据从一种表现格式变换为 另一种表现格式等等。第5层(即会话层)是这样的层，即该层例如 建立、协同和结束应用程序之间的会话、交换和对话等等。第4层(即 传送层)是这样的层，即该层例如管理端到端控制和错误检查等等。 第3层(即网络层)是这样的层，即该层例如处理路由和转发等等。 第2层(即数据链路层)是这样的层，即该层例如提供物理级的同步、 进行位填充和提供传送协议知识和管理等等。电气和电子工程师协会 (IEEE )将数据链路层细分为两个进一步的子层，控制到和来自物理 层的数据传送的MAC (媒体访问控制)层以及与网络层连接并且解 释命令和执行错误恢复的LLC (逻辑链路控制)层。第1层(即物理 层)是这样的层，即该层例如在物理级通过网络传送位流。IEEE将 物理层细分为PLCP (物理层汇聚规程)子层和PMD (物理媒体相关) 子层。
无线网络
无线网络可以包含多种类型的移动设备，诸如例如手机和无线电 话、PC(个人计算机)、膝上型计算机、可携带式计算机、无绳电话、 寻呼机、耳机、打印机、PDA等等。举例而言，移动设备可以包括数 字系统以保证语音和/或数据的快速无线传送。典型的移动设备包括一 些或全部下述元件收发器(即接收器和发送器，包括例如具有集成 的发送器、接收器、并且如果期望还具有其他功能的单片收发器)、天线、处理器、 一个或者多个音频转换器(例如用于音频通信的设备
中的扬声器或者麦克风)、电磁数据存储器(诸如例如ROM、 RAM、 数字数据存储器等，诸如在提供数据处理的设备中)、存储器、快速 存储器、全芯片组(full chip set)或集成电路、接口 (诸如例如USB、 CODEC、 UART、 PCM等)等等。
无线LAN ( WLAN)可以;帔用于无线通信，其中在无线LAN中， 移动用户可以通过无线连接连接到局域网(LAN)。无线通信可以包 括例如经由电磁波-诸如光、红外线、无线电、微波-传播的通信。 存在多种目前存在的WLAN标准，诸如例如蓝牙、IEEE 802.11和 HomeRF。
作为示例，蓝牙产品可以被用于在移动计算机、移动电话、便携 式手持设备、个人数字助理(PDA)和其他移动设备之间提供连接， 并且提供与因特网的连接。蓝牙是一种计算和电信工业标准，其详细 说明了移动设备可以如何利用短距离无线连接来简便地相互连接和与 非移动设备连接。蓝牙创建了数字无线协议，以解决由于各种需要在 不同设备之间保证数据同步和一致的移动设备剧增而产生的最终用户 问题，从而允许来自不同厂商的设备无缝地共用工作。蓝牙设备可以 根据通用命名概念而被命名。例如，蓝牙设备可以处理蓝牙设备名称 (BDN)或与唯一的蓝牙设备地址(BDA)相关联的名称。蓝牙设备 也可以加入到因特网协议(IP)网络中。如果蓝牙设备在IP网络上工 作，则可以为其提供IP地址和IP (网络)名称。因此，被配置加入 IP网络的蓝牙设备可以包括例如BDN、 BDA、 IP地址和IP名称。术 语"IP名称"指与接口的IP地址对应的名称。
IEEE标准IEEE 802.11详细说明了无线LAN和设备的技术。利 用802.11，无线组网可以由支持多个设备的每个单基站实现。在一些 示例中，设备可以预装有无线硬件或者用户可以安装可以包括天线的 单独的硬件，诸如卡。以示例的方式，用于802.11的设备通常包括三 个主要元件，无论设备是否是接入点(AP)、移动台(STA)、网桥、 PCMCIA卡、或者其他设备无线电收发机、天线和控制网络中点之间分组流的MAC (媒体访问控制)层。
另外，多接口设备(MID: Multiple Interface Device)可以被用 于一些无线网络中。MID可以包括两个独立的网络接口，诸如蓝牙接 口和802.11接口，从而允许MID参与两个独立的网络，并且允许MID 与蓝牙设备连接。MID可以具有IP地址和与IP地址相关联的通用IP (网络)名称。
无线网络设备可以包括但不限于蓝牙设备、多接口设备(MID)、 802.11x设备(包括例如802，lla、 802.11b和802.11g设备的IEEE 802.11设备)、HomeRF (家用射频)设备。Wi-Fi (无线保真)设 备、GPRS(通用分组无线业务)设备、3G蜂窝设备、2.5G蜂窝设备、 GSM (全球移动电话系统)设备、EDGE ( GSM演化增强数据)设备、 TDMA类型(时分多址)设备或包括CDMA2000的CDMA类型(码 分多址)设备。每个网络设备可以包括变化类型的地址，包括但不限 于IP地址、蓝牙设备地址、蓝牙通用名称、蓝牙IP地址、蓝牙IP 通用名称、802.11 IP地址、802.11 IP通用名称或IEEE MAC地址。
无线网络还可以包括在例如移动IP(因特网协议)系统中、在PCS 系统中和在其他移动网络系统中发现的方法和协议。至于移动IP，其 涉及由因特网工程任务组(IETF)所创建的标准通信协议。对于移动 IP而言，移动设备用户可以在维持其以前被分配的IP地址的同时移 动穿过网络。参见Request for Comments (RFC) 3344。注RFC是 因特网工程任务组(IETF )的正式文档。当在其本地网络之外连接时， 移动IP增强因特网协议(IP )并且增加向移动设备转发因特网业务量 的装置。移动IP为每个移动节点分配在其本地网络上的本地地址和识 别设备在网络和其子网中的当前位置的转交地址(CoA)。当设备移 动到不同网络时，其获得新的转交地址。本地网络上的移动代理可以 将每个本地地址与其转交地址相关联。移动节点可以在每次利用例如 因特网控制消息协议(ICMP)改变其转交地址时向本地代理传送绑 定更新。
在基本IP路由(即移动IP外)中，路由机制基于下述假设，即每个网络节点总是具有到例如因特网的恒定附接点，并且每个节点的 IP地址标识其附接到的网络链接。在本文中，术语"节点，，包括连接点， 其可以包括例如数据传送的重新分配点或端点，并且可以识别、处理 通信和/或将通信转发到其他节点。例如，因特网络由器可以查看例如 标识设备网络的IP地址前缀等。然后，在网络级，路由器可以查看例 如一组标识特定子网的位。然后，在子网级，路由器可以查看例如一 组标识特定设备的位。至于典型的移动IP通信，如果用户将移动设备 与例如因特网断开，并且试图将其重新连接到新的子网，则设备必须
被重新配置以新的IP地址、适当的网络掩码(netmask)和默认路由 器。否则，路由协议将不能够正确地传送分组。 动态主才几配置协议
动态主机配置协议(DHCP)是这样一种通信协议，其使管理员 能够管理和/或自动操作网络中的IP地址分配。通过因特网协议(IP )， 连接到因特网的每个设备需要唯一的IP地址。当ISP或组织将用户的 计算机连接到因特网时，IP地址需要被分配给该设备。DHCP使管理 员能够分配IP地址并在计算机被接入网络中不同位置时发送新的IP 地址。DHCP还支持包含需要恒定IP地址的网络服务器的计算机的静 态地址。DHCP是早期网络IP管理协议、引导协议(BOOTP)的扩 展。
如R. Droms于 1997年3 月在名称为 Dynamic Host ConfigurationProtocol的RFC2131中所详细描述的，DHCP提供对 因特网主机的配置参数。DHCP包括两个组成部分用于从DHCP 服务器向主机传送主机特定的配置参数的协议和用于将网络地址分 配给主机的机制。参见RFC2131。 "DHCP基于客户机-服务器模型 建立，其中指定的DHCP服务主机分配网络地址并将配置参数传送 到动态配置的主才几。"Id。
正如RFC2131中所描述的，DHCP服务器指通过DHCP提供初 始化参数的主机，DHCP客户端指从DHCP服务器请求初始化参数的 主机。主机不作为DHCP服务器，除非由系统管理员适当配置。DHCP支持IP地址分配的三种机制l)"自动分配"，在该机制下，DHCP 向客户端分配恒定的IP地址；2)"动态分配"，在该机制下，DHCP 向客户端分配IP地址用于受限的时间期间(或者直到客户端明确放弃 该地址)；3)"手动分配"，在该机制下，客户端的IP地址由网络管 理员分配，并且DHCP被用于将所分配的地址传送给客户端。其中， 动态分配允许自动重用客户端不再需要的曾分配的地址。因此，动态 分配对于向仅仅暂时连接到网络的客户端分配地址是有用的，或者对 于在不需要恒定IP地址的一组客户端之间共享有限的IP地址池是有 用的。参见Id。另外，"动态分配也可以是用于为恒定地连接到网络 的新的客户端分配IP地址的好的选择，其中在该网络中，IP地址十
分稀缺，从而当老的客户端停用时回收它们是非常重要的。"Id。
尽管已知大量系统和方法，但是仍然存在对改进的系统和方法的 需求。

发明内容
地改善。
根据一些实施例，提供用于绑定动态主机配置和网络访问验证的 系统和方法，其中其涉及验证代理(例如PAA)和DHCP服务器之 间的相互作用，诸如例如用于验证SA状态(例如PANA SA状态)和 DHCP SA状态之间的同步，诸如例如用于在连接丟失时维持同步。
根据一些实施例，提供了用于绑定网桥和网络访问验证的系统和 方法，其中其涉及验证代理(例如PAA)和第二层交换机之间的相互 作用，诸如例如用于在例如以上情况下避免业务窃取( service theft) 等(诸如例如MAC地址和/或IP地址欺骗(address spoofing ))。
根据 一 些实施例，提供用于从网络访问验证协议f 1导組播安全的 系统和方法，其中其涉及用于被保护IP组播流的密钥管理，诸如例如 以在例如以上情形下避免IP组播流被与被验证的接收者连接到相同 第二层部分的未验证的接收者不必要地接收和/或处理。


本发明的优选实施例以示例而不是限制的形式显示在附图中，其
中
附图l-12是说明性原理图，其示出了根据本发明一些优选实施 例的特征，其中其涉及绑定动态主机配置和网络访问验证，涉及优选 实施例的详细描述的第I部分，更具体地 附图l是一般结构模型的示意图； 附图2是演示网络访问验证和DHCP的示意图； 附图3是演示在验证会话进行的情况下服务器的行为的示意图； 附图4是演示在验证会话进行的情况下客户端的行为的示意图； 附图5是示意图，其中其演示了 AAA密钥更新方法1: DHCP密 钥保持不变；
附图6是示意图，其中其演示了 AAA密钥更新方法2:延迟的 DHCP密钥更新；
附图7是示意图，其中其演示了 AAA密钥更新方法3:即时的 DHCP密钥更新；
附图8是示意图，其演示了 DHCP服务器重启方法1:非易失性 存储器；
附图9是原理图，其演示了 DHCP服务器重启方法2:从暂存区 中再引导；
附图IO是原理图，其演示了 DHCP服务器重启方法3:向验证器 请求密钥；
附图ll是原理图，其演示了 DHCP使用期限过期方法1:保持当 前的DHCP密钥；和
附图12是原理图，其演示了 DHCP使用周期过期方法2:请求重
附图13 - 39是说明性原理图，其演示了根据本发明 一 些优选实施 例的特征，其涉及绑定网桥和网络访问验证，涉及优选实施例的详细描述的第n部分，并且更为具体地
附图13是原理图，其演示了可能的业务窃取MAC和IP地址欺
骗；
附图14是原理图，其演示了示例性网络的概要；
附图14 (A)是原理图，其演示了记录增加/删除的通知；
附图14 (B)是原理图，其演示了 UFD记录的查询/应答；
附图15是原理图，其演示了示例性分组过滤功能；
附图16是原理图，其演示了具有端口标识符标签(Port Identifier
Tag) (PIT)功能的转发；
附图17是原理图，其演示了带有PIT的会话标识； 附图18是原理图，其演示了 PIT消息格式的示例； 附图19-23是原理图，其分别演示了说明性示例1:步骤1-A
到步骤5-A;
附图24-25是原理图，其分别演示了说明性示例1:步骤4-B 到步骤5-B;
附图26是原理图，其演示了说明性示例l:威胁l;
附图27是原理图，其演示了说明性示例1:威胁2(步骤1-A 到3 - A和4 - B );
附图28是原理图，其演示了说明性示例1:威胁2(步骤5-B);
附图29是原理图，其演示了说明性示例l:威胁2:同时攻击；
附图30是原理图，其演示了说明性示例l:威胁3;
附图31-37是原理图，其分别演示了说明性示例2:步骤1-A 到7-A;
附图38是原理图，其演示了说明性示例2:威胁1&2:步骤5-A处的多会话；和
附图39是原理图，其演示了说明性示例2:威胁1&2:步骤7-A的多会话。
附图40-47是说明性原理图，其演示了根据本发明一些优选实施 例的特征，其涉及从网络访问验证协议引导组播安全，涉及优选实施例的详细描述的第ni部分，并且更为具体地
附图40是说明性IP组播网络的示意性架构附图41是用于(S1， G)的示例性分组转发路径的示意性架构图;
附图42是用于(S2， G)的示例性分组转发路径的示意性架构附图43是具有共享链路的示例性IP组播网络的示意性架构附图44是(Sl， G)的示例性分组转发路径的示意性架构附图45是组播接听者发现(查询)的示意性架构附图46是组播接听者发现(报告)的示意性架构附图47是显示没有MLD探听的组播数据分组转发的示意性架构
附图48是显示具有MLD探听的组播数据分组转发的示意性架构
附图49是显示MLDA密钥分层结构的示意性架构附图50是显示组播IPsec密钥分层结构的示意性架构附图51是显示第一种方法中SRTP密钥分层结构的示意性架构
附图52是显示第二种方法中SRTP密钥分层结构的示意性架构
附图53是显示第一种方法中用于引导MLDA的功能模块的示意 性架构附图54是显示第二种方法中用于引导MLDA的功能模块的示意 性架构附图55是显示用于引导组播IPsec的功能模块的示意性架构图； 附图56是显示第一种方法中用于引导安全组播应用的功能模块
的示意性架构附图57是显示第二种方法中用于引导安全组播应用的功能模块
的示意性架构图。
具体实施方式
尽管本发明可以以多种不同的形式实现，但是这里介绍一些示例 性实施例，应该理解，此处公开的内容应该被认为是提供本发明的原 理的示例，并且这些示例并非意味着将本发明限制到此处所描述和/ 或阐释的优选实施例。
在下面的详细描述中，本发明的优选实施例分三个部分描述。标
题为"绑定动态主机配置和网络访问验证"的第I部分涉及PAA (PANA验证代理)和DHCP服务器之间的相互作用。其中，第I部 分描述了用于PANA SA状态和DHCP SA状态之间同步的方法，诸 如例如在连接失去时维持同步。另一方面，标题为"绑定网桥和网络访 问验证"的第II部分涉及PAA和第二层交换机之间的相互作用。其中， 第II部分描述了在第I部分的情形下避免业务窃取等(诸如例如MAC 地址和/或IP地址欺骗)的方法。在另一方面，标题为"从网络访问验
证协议引导组播安全，，的第m部分涉及用于被保护IP组播流的密钥管 理。其中，第m部分描述了在第i部分的情形下避免ip组播流不必要
地被与被授权的接收者连接到相同第2层部分的非授权的接收者接收
和/或处理。
第I部分绑定动态主机配置和网络访问验证 1、 现有协议
上面讨论并且被整体引入此作为参考的因特网工程任务组(IETF ) 的RFC2131定义动态主机配置协议(DHCP)。如上所述，DHCP提 供TCP/IP网络上用于将配置信息传送到主机的框架。DHCP能够自 动分配可重用的网络地址和附加的配置选项。
被整体引入此处用作参考的IETF的RFC3118描述了用于DHCP 消息的验证，其定义DHCP选项，通过该选项，可以很容易地生成验 证标签(authorization tickets)，并且具有正确验证的新附接的主机 可以从被验证的DHCP服务器被自动配置。
被整体引入在此用作参考的IETF的RFC3315定义用于IPv6的 动态主机配置协议(DHCPv6) 。 DHCPv6使得DHCP服务器可以将 配置参数、诸如IPv6网络地址传送到IPv6节点。其提供可重用网络地址的自动分配的能力，并且提供附加的配置灵活性。RFC3315还包 括用于DHCPv6的延迟验证协议(Delayed Authentication Protocol)。 在
^ http:〃www.ietf.org/internet-drafts/Yegin-Eap-Boot-RFC3118画00.t S』处找到并被整体引入在此用作参考的由A. Yegin等人在2004年 9月2日提出的标题为"Bootstrapping RFC3118 Delayed Dhcp Authentication UsingEAP-based Newtork Access Authenticaiton，，的 因特网草案文档介绍了利用基于EAP的网络访问验证引导RFC3118 延迟DHCP验证。其概述了基于EAP的网络访问验证机制可以如何 被用于建立本地信任关系并生成可以被用于与RFC3118结合的密 钥。
2. —些当前局限性
RFC3118和RFC3115描述了可以如何利用延迟验证协议来验证 DHCP/DHCPv6信息，但是其没有描述任何有关配置初始化延迟验证 协i义所需的共享密钥的内容。另一个方面，Draft-Yegin-EAP-Boot -rfc3118 - 00.txt描述了如何利用基于EAP的网络访问验证机制生成 密钥，因此其支持在DHCP客户端主机连接到网络的第 一时间初始化 延迟验证协议。
然而，Draft - Yegin - EAP - Boot - rfc3118 - 00.txt既没有设想也 没有描述在DHCP的第一次引导之后基于EAP的验证会话和DHCP 会话如何能够最有效地相互作用。
本发明人提出了网络访问验证机制和主机配置机制之间的新的架 构和关系，其相对于现有技术具有突出的优点。另外，根据本发明的 一些优选实施例，提供了在下述情况下任何处理DHCP和验证会话的 系统和方法，这些是
终止例如验证会话被终止的情况；
*更新例如验证会话密钥被更新的情况；
重启例如DHCP服务器需要重新启动的情况；
*过期例如DHCP绑定的使用期限过期的情况；和/或*新会话建立例如建立新验证会话的情况。 3.提出的方法
标记为"一般模型，，的附图1显示了在其中可以实现一些优选实施 例的基本环境。在该示例性环境中，优选地，验证器是能够验证客户 端并授权其通过访问网络访问网络的功能实体。另外，优选地，EAP 服务器是执行EAP验证方法以验证EAP客户端的实体。此外，优选 地，PANA服务器是利用EAP验证PANA客户端的实体。
尽管出于示例的目，附图l显示了验证器、DHCP服务器和客户 端，但是本领域技术人员可以基于公开的内容知道可以根据需要改变 其他实施例。例如，其他实施例可以使用多个验证器，多个DHCP月良 务器和/或多个客户端。
标记为"网络访问验证和DHCP"的附图2有助于演示用于一些优 选实施例的一些原理。
尽管在这样的情形下介绍了一些示例性实施例，即其中PANA被 用作传送用于网络访问的验证信息的协议，并且EAP被用作由传送网 络访问验证信息的协议所传送的实际验证协议，但是其仅仅是一些示
于任何提供与PANA和EAP类似功能的协议或协议集，例如作为成 功验证和授权的结果，在客户端和验证器之间建立验证会话密钥的功 能。作为一些示例，优选实施例的系统和方法可以被用于其中IEEE 802.1X被用作传送EAP的协议的访问网络中。
另外，尽管附图演示了 EAP服务器和PANA服务器共处于一个节 点中的情况，但是这两个实体可以实现在分离的节点中，诸如例如使 用AAA协议来在二者之间传送EAP消息。另外，在这样的示例中， 验证会话密钥可以被表述为AAA密钥。
3.1验证会话终止时的服务器行为
这部分描述了在一些优选实施例中，当验证会话被故意或偶然地 终止时验证器和DHCP服务器的行为。在这方面，标记为"在验证会 话结束的情况下的服务器行为"的附图3被用以参考。(1) 典型地，验证器注意到验证会话已经终止。验证器能够注意
到验证会话终止的情况包括 *验证会话的生命周期结束； 客户端重新验证期间的故障； *从客户端接收到终止请求。
在这些情况中，如果终止被认为是偶然的，则验证器可以发送或 可以不发送验证请求消息以试图重新开始新的验证会话。
(2) 根据本发明的一些优选实施例，验证器可以向DHCP服务器 通知从刚终止的验证会话中所导出的DHCP密钥不再有效。因为 DHCP服务器通常即使在会话已经终止时也存储旧的配置文件，所以 这可以是有利的。优选地，验证器一识别到验证会话终止就通知DHCP 服务器。在多个实施例中，存在验证器向KHCP服务器通知DHCP 密钥的有效性和状态变化的很多可能实现方案。
*在第一示例中，配置文件可以被重写或重新加载。例如，验证 器可以修改DHCP服务器的配置文件。然后，其可以使DHCP 服务器重新启动或者其可以发送信号以请求DHCP服务器再 次读取配置文件。
*在第二个示例中，可以发送请求到DHCP服务器以删除客户端 配置。例如，验证器可以通过通信协议-诸如IP或UNIX域 套接字-发送请求消息。
(3) 在一些系统中，可选特征可以包括如果DHCP服务器接收 到DHCP密钥撤消的消息，并且如果主机配置协议允许，贝'J DHCP 服务器请求DHCP客户端释放在先前的DHCP消息中分配给客户端 的绑定。以示例的方式，DHCPv6服务器可以通过下述步骤请求客户 端更新其绑定
1. DHCPv6服务器利用先前的DHCP密钥发送重新配置消息。
2. DHCPv6客户端向DHCP服务器发送更新消息或信息请求消息。
3. DHCPv6服务器利用先前的DHCP密钥检查DHCP验证选项， 并发送包括生命周期为零的绑定的应答消息。4. DHCPv6客户端停止使用旧的绑定，并且可以开始请求新的绑定。
5. DHCPv6服务器丢弃具有先前DHCP密钥的消息。 在一些情况下，如果客户端注意到验证会话终止，则客户端将自
动地丢弃先前的密钥。相应地，在这种情况下，上述步骤2和后续步 骤可以不发生。
(4)在一些系统中，DHCP服务器删除DHCP密钥，并且使绑 定停用。下述使绑定实体停用的可能实现方案存在 *从绑定表中删除这些实体；
使这些实体的生命周期为零，如同它们过期一样。 应当注意，从绑定表中删除实体并不意味着用于它们的资源被释 放。例如，客户端可能继续偶尔使用该资源。DHCP服务器可以检查 与该绑定相关的资源是否仍由网络中的任何实体使用。例如，RFC2131 描述了分配(DHCPv4)服务器应该在诸如例如以ICMP回送请求分 配地址之前探查被重用的地址。DHCPv6服务器可以以类似方式检查 网络资源的一致性。
3.1.1在验证会话终止时的客户端行为
本部分从客户端的角度描述了客户端如何处理验证会话的终止。 在该方面，标记为"在验证会话终止的情况下的客户端行为"的附图4 演示了与其相关的特征。参考附图4，系统执行如下步骤。
(1) 首先，如附图中的(1)所示，客户端注意到验证会话终 止。在这方面，客户端能够注意到验证会话终止的情况包括
*验证会话生命周期的到期； *重新验证的失败； *终止请求。
(2) 其次，客户端停止使用由DHCP服务器所分配的资源。 客户端可以利用先前的DHCP密钥发送或可以不发送释放消息，
以释放绑定。
(3) 第三，如附图中的(3)所示，如果必要，客户端重新启动新的验证会话，并且得到新的密钥。
3.2验证会话密钥被更新的情况
根据一些优选实施例，在验证会话密钥被更新时，DHCP密钥被 特别处理。在这些优选实施例中，三种可能的方法是可行的。
在一些实施例中，客户端和验证器和/或动态主机配置服务器可以 协商将使用哪些方法。例如，在一些实施例中，客户端可以发送表明 其支持哪些方法的信号。例如，在一些实施例中，在验证会话密钥被 更新时在用于绑定动态主机配置和网络访问验证的系统中使用的客户 端设备所执行的方法可以包括在所述验证会话或所述动态主机配置 会话终止后或在这样的会话开始后，所述客户端设备发送消息，以标 识客户端设备支持哪些动态主机配置密钥处理方法来处理这样的终止 或开始。在一些实施例中，所述客户端设备将所述消息发送到验证器。 在一些实施例中，所述客户端设备将所述消息发送到动态主机配置服 务器。
3.2.1 DHCP密钥保持不变(方法1)
根据第一个实施例，第一方法包括DHCP密钥保持不变，同时验 证密钥被改变。标记为"AAA密钥更新方法1: DHCP密钥保持不 变"的附图5有助于演示根据本实施例的优选实现方案的特征。参考附 图5，系统优选地执行如下步骤
(1) 首先，如附图中(1)所示，验证会话密钥在验证会话中被 改变。
(2) 其次，如附图中(2)所示，客户端更新验证会话密钥，同 时保持DHCP不变化。验证器不将有关DHCP密钥的任何信息发送 到DHCP月艮务器。
(3) 第三，如附图中(3)所示，在客户端或者DHCP服务器要 求DHCP消息交换时，其保持使用相同的DHCP密钥。
3.2.2延迟的DHCP密钥更新(方法2 )
根据第二实施例，第二种方法包括DHCP密钥在稍晚的时间被更 新。特别地，验证会话密钥的改变不导致即刻的DHCP消息交换。因此，在一些优选实施例中，DHCP服务器和客户端将在他们在改变密 钥之后第一次需要DHCP消息交换时更新DHCP密钥。在这一点上， 标记为"AAA密钥更新方法2:延迟的DHCP密钥更新"的附图6显 示了根据本实施例的优选特征。参考附图6,优选地，系统执行下述 步骤
(1) 首先，如附图中(1)所示，验证会话密钥更新由事件触发；
(2) 第二，如附图中(2)所示，验证器将新的DHCP密钥发送 到DHCP服务器；
(3) 第三，如附图中(3)所示，在验证器和客户端之间建立新 的验证会话密钥；
(4) 第四，如附图中(4)所示，在该步骤中，客户端还存储新 的DHCP密钥作为替换密钥；
(5) 第五，如附图中(5)所示，如果可用，在获得新的验证密 钥之后，DHCP服务器和客户端将使用新的DHCP密钥用于消息交换。 一旦DHCP服务器和客户端使用新的DHCP密钥，DHCP服务器和 客户端就将删除旧的DHCP密钥。
3.2.3即时DHCP密钥更新(方法3 )
根据第三个实施例，第三种方法包括在密钥改变之后立即使用新 的DHCP密钥来重新开始DHCP会话。
标记为"AAA密钥更新方法3:即时DHCP密钥更新"的附图7 显示了根据本实施例的特征。参考附图7，优选地，系统执行下述步
(1) 第一，如附图中(1)所示，验证会话密钥在验证会话中被 改变。
(2) 第二，如附图中(2)所示，在验证器和客户端之间建立新 的验证会话密钥。根据本发明的优选实施例，优选地，在该步骤末， 验证器将新的DHCP密钥发送到DHCP服务器。
(3) 第三，如附图中(3)所示，优选地，客户端利用新的DHCP 密钥来启动新的DHCP会话。3.3 DHCP服务器需要被重启的情况
根据一些优选实施例，DHCP服务器在重新引导后或者出于其他 原因以特定方式被重启。在优选实施例中，存在三种可以采用的可能 方法。
在一些实施例中，客户端和验证器和/或动态主机配置服务器可以 协商使用哪些方法。例如，在一些实施例中，客户端可以发送表明其 支持什么方法的信号。例如，在一些示例中，在动态主机配置绑定的 使用期限过期时在用于绑定动态主机配置和网络访问验证的系统中的 客户端设备所执行的方法可以包括在动态主机配置绑定过期后(或 者类似地在动态主机配置会话开始后)，客户端设备可以发送消息， 以标识客户端设备支持什么动态主机配置密钥处理方法来处理这样的 终止或开始。在一些实施例中，所述客户端设备将所述消息传送到验 证器。在一些实施例中，所述客户端设备将所述消息传送给动态主机 配置服务器。
3.3.1从非易失性存储器中恢复整个状态(方法l) 根据本发明的第 一个实施例，第 一种方法包括使用非易失性存储 器来恢复状态。在该点上，标记为"DHCP服务器重启方法l:非易 失性存储器"的附图8显示了根据本实施例的阐释性特征。参考附图8， 优选地，系统执行下述步骤
(1) 第一，如附图中(1)所示，优选地，DHCP服务器将DHCP 密钥表和绑定表保存到非易失性存储器中。DHCP服务器可以在表被 更新的任何时候更新非易失性存储器，和/或周期性地更新非易失性存 储器。非易失性存储器可以利用任何合适的数据存储器或储存器实现， 诸如例如硬盘驱动器、磁盘、快速存储器等。
(2) 第二，优选地，处于某种理由重启DHCP服务器。
(3) 第三，如附图中(3)所示，优选地，DHCP服务器从非易 失性存储器中重新存储密钥表和绑定表。优选地，DHCP服务器删除 使用期限已经过期的实体。
(4) 第四，如附图中(4)所示，优选地，DHCP服务器和客户端使用相同的密钥，直到该密钥的使用期限过期。
3.3.2由验证器重新引导来自DHCP服务器的通知或重新引导探测 (方法2)
根据另 一实施例，第二种方法可以包括DHCP从暂存区重新启动。 在该点上，先前的密钥表和绑定表被丢弃。并且，每个客户端需要重 新启动验证会话。标记为"DHCP服务器重新启动方法2:从暂存区 重新引导"的附图9显示了根据本实施例的一些阐释性的特征。参考附 图9，优选地，系统执行下述步骤
(1) 处于某种原因，DHCP服务器重新启动；
(2) 从验证器动态获得的所有DHCP密钥和绑定表中的相应实 体被丟失。DHCP服务器可以检查也可以不检查可能被分配给先前绑 定的资源，以防止多次分配。实现方案完成上述操作的一些方法包括
DHCP服务器可以向每个客户端发送重新配置，以重新存储 并更新绑定表，
如果可能，
* DHCP服务器可以使用非易失性存储器来再次存储绑定表。
(3) 根据一些优选实施例，可选地可以使用这样的步骤，其中a) DHCP服务器向验证器通知DHCP密钥已被擦除，或b )验证器能够 在没有来自DHCP服务器的通知的情况下得知DHCP服务器的重新 引导。在这些情况下，优选地，验证器为每个客户端更新DHCP密钥， 并将其发送到DHCP服务器。
(4) 在验证器如此要求时，或在客户端注意到DHCP会话终止 时，客户端重新启动验证会话和DHCP会话。
3.3.3向验证器请求密钥(方法3)
根据本发明的另一实施例，第三种方法包括DHCP服务器请求 验证器重新发送密钥信息，并重新存储DHCP密钥表。标记为"DHCP 服务器重新启动方法3:向验证器请求密钥"的附图10显示了根据 本实施例的阐释性特征。参考附图10，优选地，系统执行下述步骤 (1)第一，如附图中(1)所示，在DHCP服务器启动时，DHCP服务器请求验证器重新发送DHCP密钥。
(2) 第二，如附图中(2)所示，验证器将所有有效的DHCP密 钥发送到DHCP服务器。
(3) 第三，如附图中(3)所示，DHCP服务器重新存储DHCP 密钥表。在该点上，绑定表实体可以被重新存储或可以不被重新存储。
*在一些实施例中，如果可能，DHCP服务器可以向每个客户端 发送重新配置消息，以重新存储和更新绑定表。
*在一些实施例中，DHCP服务器可以使用非易失性存储器来重 新存储绑定表。
3.4 DHCP绑定的生命周期到期的情况
本部分描述在DHCP绑定的生命周期到期时DHCP客户端的行 为。存在大量可以被实现的可能方法。 3.4.1保持当前DHCP密钥
现有方法包括DHCP客户端和服务器使用当前密钥以生命周期。 在该点上，标记为"DHCP使用期限过期方法1:保持当前DHCP 密钥"的图11显示了该现有方法的特征。参考附图ll，优选地，系统 执行下述步骤
(1) 第一，如附图中(1)所示，DHCP绑定更新的定时器到期。
(2) 第二，如附图中(2)所示，DHCP服务器或客户端利用当 前DHCP密钥启动DHCP消息交换，以延长生命周期。
3.4.2请求重新验证
根据本发明的优选实施例，可以使用另一方法，其包括DHCP 客户端在DHCP消息交换之前请求更新验证会话。在该点上，标记为 "DHCP使用周期过期方法2:请求重新验证"的附图12显示了根据 本实施例的阐释性特征。参考附图11，优选地，系统执行下述步骤
(1) 第一，DHCP绑定更新的定时器到期。
(2) 第二，如附图中(2)所示，客户端请求验证器重新验证并 更新DHCP密钥。在一些实施例中，DHCP服务器可以请求验证器重 新验证并更新DHCP密钥。(3) 第三，如附图中(3)所示，验证器将新的DHCP密钥发送 到DHCP服务器。优选地，PANA客户端将新的DHCP密钥通知给 DHCP客户端。
(4) 第四，如附图中(4)所示，客户端使用新的DHCP密钥开 始新的DHCP会话。
3.5在建立新的验证会话时的服务器行为
根据优选实施例，在交换验证消息以在验证器和客户端之间创建 新的DHCP密钥期间，优选地，验证器不返回表明已经成功建立新的 验证会话的消息，直到DHCP密钥被成功地安装在DHCP服务器上。 以这种方式，客户端可以在成功的验证会话建立之后迅速地开始具有 新密钥的新DHCP会话，同时避免了竟争状态(race condition )。第II部分绑定网桥和网络访问验证 1.现有方法
被整体引入此用作参考的因特网Draft - IETF - EAP -RFC2284bis-09定义了可扩展认证协议(EAP)， 一种支持多个验证 方法的验证框架。
被整体引入此用作参考的因特网Draft - IETF - PANA - PANA-04定义了用于承载网络接入验证的协议(PANA)， 一种用于可扩展 认证协议(EAP)以支持客户端和访问网络之间网络访问验证的链路 层不可知传输(link - layer agnostic transport)。
如上所述，RFC3118描述了 DHCP消息的验证，其定义了通过其 可以生成授权凭证(authorization ticket)并且重新附接的具有合适授 权的主才几可以从4皮驺、证DHCP月l务器自动配置的DHCP选项。
同样如上所述，RFC3315定义了用于IPv6的动态主机配置协议 (DHCPv6) 。 DHCPv6使DHCP服务器能够向IPv6节点传递配置 参数，诸如IPv6网络地址。其提供了自动分配可重用网络地址的能力， 并提供了附加的配置灵活性。RFC3315还包括用于DHCPv6的延迟 认证协议。
同样如上所述，Draft - Yegin - EAP - Boot - RFC3118 - 00.txt描
其描述了基于EAP的网络访问验证机制可以如何被用于建立本地信 任关系和生成可以与RFC3118结合使用的密钥。
另外，被整体引入此用作参考的标题为"Draft Stands for Local and Metropolitan Area Network: Standard for Port based Network Access Control"的IEEE DRAFT P802.1X描述了这样的架构框架，在 该框架中进行验证和随后的行为。然而，其没有描述交换机的不同物 理端口之间的相互作用。
被整体引入此用作参考的、Rich Seifert所著的JOHN WILEY&SONS公司出版的ISBN 0 - 471034586 - 5的Switch Book解 释了现有的交换机和网桥如何工作。2. 现有方法的局限性
EAP和PANA提供了用于网络访问验证的框架。另夕卜，延迟DHCP 验证可以被用于验证DHCP分组。 一旦这些过程完成，客户端就可以 开始发送和接收分組，诸如例如应用数据。在这一点上，EAP/PANA 和DHCP验证不再为这样的分组提供每个分组保护，并且可能存在业 务窃取的可能性。
标记为"可能的业务窃取"的附图13显示了可以发生的业务窃取的 一些示例。附图的(a)部分显示了简单的访问网络，其中PAA、 DHCP 服务器、路由器和一些客户端(例如，参见客户端1和攻击者)通过 广播LAN -诸如例如广播集线器或同轴电缆以太网-连接到该访问 网络。当客户端l正使用被显示为应用服务器(App)的网络服务时， 从App服务器发送到客户端1的分组被广播到直接连接到LAN的所 有节点。因此，攻击者潜在地可以从App服务器接收分组。另外，攻 击者也可能能够通过欺骗源IP地址而将分组发送到App服务器，就 好像这些分组被从客户端l发送。这被认为是示例性的"业务窃取"。
另一个方面，(b)部分显示了使用L2网桥作为LAN而代替广播 介质的网络。网桥通常不将寻址到客户端1的单播分组发送到除客户 端1之外的任何节点。但是， 一旦攻击者发送欺骗客户端1的MAC 地址的分组，网桥就根据恶意信息更新其转发数据库，并且将随后的 寻址到客户端1的分组发送到攻击者，而不是合法的客户端l。因此， 业务窃取仍然是可能的。通过使用这些攻击方法，攻击者可以在没有 验证的情况下获得网络访问。
因此，需要新的方法来防止恶意攻击者在这些环境中获得非授权 的网络^方问。
3. 提出的模型
3.1示例网络的概要
标记为"示例网络的概要"的附图14显示了示例性网络。在该阐释 性的示例中，网络访问提供者具有作为验证器的PAA、DHCP服务器、 路由器和第2层网桥。网桥具有连接到用于验证器和DHCP服务器的网络的物理端口。在本文档中，该端口被称为"服务器端口"。在附图
14中，名称为P0的端口是服务器端口。
另外，网桥还具有其他连接到客户端主机和网络的物理端口。其 被称为"客户端端口"。例如，每个客户端端口具有名称，例如P1、 P2 和P3。在附图14所示的实施例中，路由器连接提供者网络和外部网 络，诸如例如因特网。应该理解，附图14所示的网络是示例性的，并 且仅仅用于解释的目的。通过示例的方式，在各种其他的网络中，系 统可以实质上存在多种变化，诸如例如可以存在多个验证器、多个 DHCP服务器、多个路由器、多个网桥和/或类似装置。
3.2转发数据库
现有网桥具有被称为转发数据库的表，其存储MAC地址和网桥 端口之间的关系。在本发明的优选实施例中，大量新型的转发数据库 被引入网桥中。
3.2.1授权转发数据库(authorized forwarding database ) 第一种示例性的新数据库被称为授权转发数据库(AFD)，其优 选地包括MAC地址和端口号组成的对的列表。示例性AFD在表l中 显示。
MAC 端口 MAC1 PI MAC2 P2 MAC3 P3 MAC4 P3 MAC5 P3 表1
优选地，AFD以下述方式被维护，即任何MAC地址决不出现两 次或更多次。优选地，如果给定MAC地址的记录存在于AFD中，则 这意味着具有该MAC地址并且被连接到该端口的客户端节点被验证 器验证。在优选实施例中，所有连接到网桥的经过验证的客户端节点 出现在网桥的AFD中。优选地，当客户端和验证器之间的验证会话被删除时，对应于客户端MAC地址的记录被迅速地从AFD中删除。优 选地，当记录^皮从AFD中删除时，对应于被删除记录的MAC地址的 验证会话纟皮迅速删除。
在优选实施例中，验证器被配置为请求网桥在AFD中增加或删除 记录。在一些实施例中，客户端节点的物理断开可以从AFD中删除该 客户端记录，也可以不从AFD中删除客户端记录，诸如例如取决于网 络提供者和/或客户端节点的策略。
*例如，如果客户端节点频繁地从一个端口切换到另一端口，则 其可能希望对应于其MAC地址的记录在其从端口断开时迅速 地被从AFD中删除。 *但是，断开时的自动删除会使服务拒绝(DoS)攻击更容易。 参见下面有关DoS攻击的讨论，其以示例性的威胁2和3在下 面描述。
3.2.2未授权转发数据库(unauthorized forwarding database ) 第二示例性的新数据库被称为未授权转发数据库(UFD)，其优 选地包括MAC地址和端口号组成的对的列表，即类似于AFD的情况。 优选地，在UFD中，任何MAC地址决不出现两次或者跟多次。优选 地，禁止系统添加已经存在于AFD或UFD中的MAC地址。在优选 实施例中，如果给定的MAC地址的记录存在于UFD中，则这意味着 具有该MAC地址并被认为连接到端口的客户端节点还没有被验证器 验证。
优选地，当客户端和验证器之间的验证会话被建立(即其被验证) 时，对应于客户端MAC地址的记录被从UFD中删除，并被添加到 AFD中。另一个方面，优选地，当验证消息交换失败时，诸如例如由 于错误或超时，对应于该客户端的记录优选地被从UFD中删除。
在优选实施例中，当在诸如例如上述的事件时记录需要被删除时， 验证器请求网桥在UFD中添加或删除该记录。优选地，UFD中的记 录具有生命周期。优选地，存在生命周期的上限。如果超过生命周期， 则记录优选地被从UFD中删除。在一些实施例中，如果在客户端和验证器之间验证消息交换中间删除UFD中的记录，则验证迅速失败。
优选地，记录的删除和验证会话的失败同步执行。以示例的方式， 一种用于保持同步的简单方法是仅由验证器决定UFD中记录的超时。 在其他实施例中，可以按照希望使用任何其他保持同步的方法。
优选地，如果网桥通过端口接收到来自MAC地址的分组，并且 该MAC地址没有出现在任何转发数据库中，则该MAC地址的记录 和端口被添加到UFD中。优选地，记录被保留，直到超过生命周期的 上限或者直到验证器请求删除记录或将记录移动到AFD。在一些实施 例中，当验证失败或超时发生时，记录可以被移动到在下一部分介绍 的处罚列表(penalty list)中，也可以不被被移动到该处罚列表中。
在一些优选实施例中，可以限制各端口的记录的最大值，以帮助 防止旨在使UFD溢出的各种DoS攻击。如果具有相同端口号的记录 的数目达到该限制，则网桥优选地拒绝添加用于该记录的请求，并阻 止与UFD中现存记录不匹配的任何分组，直到该端口的记录的数目降 低到某阈值以下。
在一些优选实施例中，网桥迅速地向验证器和/或动态主机配置服 务器(例如DHCP服务器)通知UFD中记录的添加和UFD中记录的 删除。优选地，该通知包括该记录的端口号和MAC地址。利用该通 知，验证器和/或动态主机配置服务器可以知道每个客户端的端口标识 符。验证器和/或动态主机配置服务器因此可以例如根据端口标识符阻 止来自可疑客户端的请求。参见标记为"记录添加/删除的通知，，的附图 14 (A)。在附图14 (A)所示的阐释性示例中，客户端1的记录被 添加或删除，并且网桥B1被显示为向验证器(诸如例如Pana验证代 理PAA)和/或动态主机配置服务器(诸如例如DHCP服务器) 发送通知消息。
在一些优选实施例中，网桥可以应答来自验证器和/或动态主机配 置服务器(例如DHCP服务器)对UFD记录的查询，使得验证器和/ 或DHCP服务器可以得知客户端的端口标识符。在一些实施例中，验 证器和/或DHCP服务器例如可以根据端口标识符阻止来自可疑客户端的请求。参见标记为"有关UFD记录的查询/应答"的附图14 (B)。 在附图14 (B)显示的阐释性示例中，验证器(诸如例如Pana验证 代理PAA)和/或动态主机配置服务器(诸如例如DHCP服务器) 向网桥bl发送查询，以询问例如客户端1 (MAC1)具有什么端口号。 然后，网桥B1检查客户端1 (MAC1)的记录。因此，网桥B1应答 验证器或动态主机配置服务器。 3.2.3处罚列表(Penalty List)
第三示例性的新数据库被称为处罚列表(PL)，其包括MAC地 址和端口号组成的对的列表，类似于AFD和UFD。优选地，PL中的 记录还具有超时信息-诸如例如时间戳或计时器-以处理超时。优 选地，PL中的每个记录具有生命周期，其中生命周期可以根据实施方 式而被静态地设置为特定长度或动态地变化。当生命周期计时器到期 时，记录优选地被自动地从PL中删除。
优选地，MAC地址可以在PL中出现两次或更多次，但是，优选 地，MAC地址和端口的结合在PL中是唯一的。示例性的处罚列表显 示在表2中。
MAC端口 超时信息 MAC1P2 30秒后到期 MAC3P2 IO秒后到期 MAC3P3 20秒后到期 表1
在各种实施例中，"超时信息"列的实际格式可以基于实现环境。 以示例的形式， 一种阐释性的实施方式可以存储距离到期的秒数(诸 如例如表2中所示的示例)。作为另一示例，另一实施例可以存储当 记录被添加到PL中时的当日时间，并可以自动确定到期的时间。
在一些可选实施例中，PL可以被扩展以将"计数器"字段包括到记 录中。在这点上，当相同的MAC地址和端口的组合被请求添加到PL 中时，用于该组合的计数器优选地增加。在一些实施例中，网络管理 员可以配置网桥以直到计时器达到特定值时才开始阻止(例如在到特定值时开始阻止)，网络管理员也可以不做此配置。其中，这可以使 用户能够在密码输入错误和/或其他诚实的错误后马上试图验证。优选
地，计数器的上限值可以被用于阻止任何来自相同MAC地址和端口 组合的进一步访问，以防止过度的错误访问。
另外，限制每个端口的最大记录数量是一种很好的防止各种企图 使PL溢出的DoS攻击的方法。优选地，如果具有相同端口号P的记 录的数目达到极限，则网桥添加"通配符"记录(*， P)，并删除具有 端口号P的其他记录，以为PL腾出空间。通配符记录可以具有例如 允许的最大生命周期。另外，不管计数器，通配符记录都可以生效。 优选地，通配符记录不影响与UFD或AFD中记录匹配的分组。如果 存在用于端口 P的通配符记录，则网桥优选地阻止来自端口 P的任何 不匹配分组。
3.2.4分组过滤
在优选实施例中，网桥优选地根据上述AFD、 UFD和PL转发数 据库过滤分组。优选地，如果记录的MAC地址字段等于分组的源 MAC地址并且记录的端口号字段包含P,则在客户端端口 P所接收 的分组被认为与转发数据库中的记录完全匹配。另一个方面，优选地， 如果记录的MAC地址字段等于分组的目的MAC地址，则在服务器 端口所接收的分组被认为与转发数据库中的记录完全匹配。
以示例的方式，标记为"分组过滤，，的附图15演示了根据本发明一 些示例性实施例的分组过滤方案。
在优选实施例中，为了过滤，以如下方式检查每个分组(即根据 下述方案中至少一些、优选为全部)
*如果分组完全匹配AFD中的记录，则网桥转发该分组。参见
例如附图15中所示的端口 1处的MAC1。 *如果分组完全匹配UFD中的记录，则网桥查看分组的IP首标。 如果分組寻址到访问网络之外的节点，则网桥阻止该分组。否 贝'J，如果其寻址到访问网络之内的节点，则网桥可以转发授权 类型的分组。例如， 一些类型的分组可以被网桥转发。在一些示例性实施例中，授权类型的分组可以包括验证(PANA)消
息和DHCP消息。参见例如附图15所示的端口 3上的MAC3。 *如果分组完全匹配PL中的记录，则网桥阻止该分组。参见例
如附图15中的端口 4上的MAC3。 *如果分组在客户端端口被接收，并且源MAC地址在AFD或
UFD中的记录中^皮发现，则网桥阻止该分组。参见例如附图
15中端口 3上的MAC1。 3.3端口标识符标签 3.3.1端口标识符标签的一般描述
在本文档中，网桥的标识符(即网桥标识符)和端口号的组合被 称为"端口标识符"。优选地，网桥标识符在用于访问网络的网桥中是 唯一的。
在优选实施例中，端口标识符有利地被附加于分组。在本公开中， 这被称为"端口标识符标签"(PIT)。如果端口标识符标签特征被使 負&，则网桥将端口标识符标记到寻址到验证器或DHCP服务器的分组， 并转发标记后的分组，而不是原始分组。当网桥接收到从验证器或 DHCP服务器所发送的标记后的分组时，网桥查看标签中的端口标识 符，并将未标记的分组转发到标签中所指定的端口。
标记为"具有端口标识符的转发"的附图16显示了示例性而非限制 性的示例，其使用两个网桥。连接到网桥l的端口 1的节点正发送分 组到PAA。在该点上，网桥1将端口标识符标签"B1: Pl"附加于分組， 其表明该分组被从网桥1 (Bl)的端口 1 (Pl)发送。于是，标记后 的分组被发送给PAA。如果原始分组的目的MAC地址是单播地址(例 如被通信到单个接收者)，则确定目的IP地址不重要。例如，目的 IP地址可以在PIT节点表(参见例如附图18)中发现。查看ARP(地 址解析协议)表是另一可能的实现方案。如果原始分组的目的MAC 地址是广播地址(例如被通信到任何人)或组播地址(例如被通信到 多个接收者)，则可以有更多设计方案选择，其中一些方案如下
*网桥可以将单播分组发送到在用于广播或组播地址的PIT节点表记录中发现的每个IP地址。 *网桥可以利用预先配置用于广播或组播分组的预共享密钥
(PSK: pre-shared key )发送广播或组播分组。 *网桥查看分组的IP首标，并确定希望什么业务。例如，如果 分组是UDP分组，并且其目的端口是引导协议(BOOTP)服 务器端口，则网桥将该分组转发到BOOTP (或DHCP)服务器。
在附图16中，DHCP服务器还将分组发送给连接到网桥2的端口 3的节点。在这方面，DHCP服务器优选地准备具有端口标识符标签 "B2: P3"的分组，并将其发送到网桥2。网桥2将端口标识符标签从 分组分离，并经由端口 3将分组转发到目的地。注意，网桥2优选地 根据端口标识符经由端口 3转发分组，即使在另一端口上存在具有相 同MAC3的另一节点。尽管MAC地址应该优选地是全球唯一的，但 是在现实中，这通常从未发生。然而，如果恶意欺骗节点存在，则可 以非常有利地通过端口标识符来区分具有相同MAC地址的节点。
3.3.2会话标识
一些网络服务器通过其客户端节点的MAC地址区分会话。PAA (PANA服务器)和DHCP服务器是这些类型的服务器的示例。然而， 如果设想由于偶然的和/或故意的攻击，多个节点可以具有相同的 MAC地址，则MAC地址不足以标识会话。
在这方面，标记为"具有PIT的会话识别"的附图17在附图左侧显 示了现有网桥和服务器(例如PAA)的问题。根据一些优选实施例， 当端口标识符标签使用时，端口标识符和MAC地址的组合可以被用 于区分会话。附图17的右侧演示了端口标识符和MAC地址的组合如 何可以被有利地用于区分会话。优选地，网桥应该被配置，使得只有 寻址到PIT使能服务器的分组被标记。
3.3.3端口标识符标签上的安全考虑
端口标识符标签是如此强大，以致于其应该优选地远离错误或恶 意使用。为了防止攻击者使用PIT作为攻击工具，优选地，配置网桥以阻止从客户端端口发送的具有PIT的分组。例如，参考附图16，在 一些优选实施例中，在附图中，网桥1和网桥2可以被配置为丟弃经 由端口 1到4发送的任何PIT分组，并接收仅经由端口 O发送的PIT。 另外，如果存在与外部网络的连接，诸如例如因特网，则网关路由器 或防火墙优选地应当被配置为丟弃从外部网络发送的和/或发送到外 部网络的PIT分组。
提高PIT的可靠性的另一种方法是使用HMAC(用于消息验证的 键控散列(Keyed-Hashing for Message Authentication ): 基于散歹'J 函数的消息验证码)或类似的消息验证技术。
3.3.4端口标识符标签的可能实现方案
在一些示例性实施例中，大量实现PIT的方法可以包括例如 參UDP/IP封装；
*新的以太网类型(ethertype); *新的IP选项。
标记为"PIT消息格式的示例"的附图18描述了示例性的而非限制 性的实施例，其中使用UDP/IP封装。附图18演示了网桥可以如何从 在客户端端点所接收的以太网帧建构UDP/IP封装分组。在优选实施 例中，网桥以如下方式处理分组
1. 网桥检查分组以根据AFD、 UFD和PL确定其是否可以被转发 或应当被阻止。如果要阻止分组，则其被丢弃。
2. 网桥在优选包括由MAC地址索引的IP地址和PSK (预共享 密钥)的记录的表-诸如例如"PIT节点表，，-中查找目的MAC地址。 在一些实施例中，PIT节点表可以在网桥中被管理员预配置。优选地， 如果没有在表中发现以太网分组的目的MAC地址，则该分组将以没 有PIT的通常方式被转发。
3. 网桥建构封装原始以太网分组的新的UDP/IP分组。从PIT节 点表中的记录复制目的IP地址。该记录可以包括在目的IP节点处接 收PIT分组的UDP端口号。源IP地址可以是网桥本身的IP地址。 如果网桥标识符由其IP地址代表，则下面的"网桥标识符，，字段可以被省略，以减小PIT分组的尺寸。网桥还填充PIT特定字段，包括"网 桥标识符"字段和"网桥端口号"字段。网桥标识符是在用于网络中的所 有网桥中唯一的数字。网络管理员可以为每个网桥预配置其。网桥端 口号用于标识网桥中的端口 。 HMAC字段可以被用于例如验证PIT 分组。优选地，网桥在PIT节点表中的记录中使用PSK，以计算PIT 消息的HMAC。优选地，在整个IP数据报上计算HMAC。 3.4网桥上的其他考虑
在一些优选实施例中，为了防止PAA和/或DHCP服务器的假冒， 网桥也可以,皮配置为不将PANA和DHCP分组从—一个客户端端口转发 到另一客户端端口。
4.实现方案示例
在下述子部分中，介绍两个示例性实施例子。基于公开的内容， 应当理解其仅仅是阐释性的示例。 4.1第一实现方案示例 4.1.1第一示例纵览
才艮据第一阐释性实施例，系统可以^吏用AFD、 UFD，并且可选地 还使用PL。在优选实施例中，系统执行下述内容中的至少一部分，优 选为全部
1- A.参考标记为"示例1:步骤1-A，，的附图19，考虑其中客户 端(客户端1)开始连接到访问网络的情况。此处，客户端1连接到 网桥(Bl)的端口 1 (Pl),并在引导过程中发送第一分组。例如， 这可以涉及路由器请求(router solicitation )消息、DHCP发现/请求
(discover/solicit)消息或其他形式的消息。
2- A.参考标记为"示例1:步骤2-A，，的附图20，因为在AFD、 UFD和PL中没有发现源MAC地址(MAC1)，所以网桥将新的记 录添加(或可以请求验证器来使网桥添加)到客户端1的UFD中。优 选地，网桥(或验证器)启动新的定时器以维持新记录的到期。
3- A.参考标记为"示例l:步骤3A，，的附图21，在引导过程中客 户端1处理消息交换。这些消息交换可以包括例如IP地址自动配置或DHCP消息和PANA验证消息。优选地，因为客户端1在UFD中有 记录，所以允许这些开始网络连接所需要的消息被转发。
4- A.参考标记为"示例1:步骤4A，，的附图22,如果客户端l被 成功验证，则验证器请求网桥(Bl)将UFD中的客户端1记录移动 到AFD。
5- A.参考标记为"示例1:步骤5A"的附图23，客户端1开始用 于其他应用的消息交换。在这方面，因为客户端1的记录(MAC1: Pl)存在于AFD中，因此网桥(Bl)优选地转发任何被验证分组。
另一方面，如果客户端1验证失败或如果在上述步骤3-A期间 UFD中的客户端1记录到期，则优选地，步骤4-A至5-A被下述 步骤4 - B到6 - B代替
4- B.参考标记为"示例l:步骤4B，，的附图24，客户端l的记录 被从UFD中删除；
5- B.参考标记为"示例l:步骤5B，，的附图25，可选地，新记录 (MAC， P1)被添加到PL中。在这方面，在记录维持在PL中的时
间段期间，网桥B1优选地禁止从客户端1转发的和/或被转发到客户 端1的任何分组。
6- B.在该步骤中，客户端1可以以步骤l-A再一次试图另一验 证，；也可以不3口》匕。
4.1.2安全考虑
4.1.2.1威胁l:通过欺骗的业务窃取
参考标记为"示例1:威胁l，，的附图26，在一些情况下，在客户端 1被验证之后或者在客户端被验证之前紧邻的时刻，在欺骗客户端1 的MAC地址MAC1期间，攻击者可以发送分组。例如，这可以为了 以下目的而进行，即使网桥根据恶意信息更新其转发数据库并将寻址 到客户端1的后续分组转发到攻击者，而非合法的客户端1。这是示 例性的业务窃取攻击。
然而，优选地，在记录(例如MAC1， Pl)存在于AFD或UFD 中的时间段期间，禁止经由除Pl之外的端口的来自/到MAC1的任何分组交换。因此，在上述步骤5-A(即AFD具有记录)和步骤2-A 至4-A (即UFD具有记录)期间，该类型的攻击将失败。 4.1.2.2威胁2:没有验证的DoS攻击
参考附图27 - 29，在一些情况下，攻击者可以发送分组，以在客 户端1第一次连接到网络之前欺骗客户端1的MAC地址MAC1。例 如，如果攻击者向网桥发送冒充MAC1的分组，则网桥会在UFD中 创建新的记录，使得客户端1在稍晚的时间发送的分组在该记录存在 期间会被网桥阻止。
接着，攻击者可以重复步骤1 - A到3 - A以及步骤4 - B到6 - B。 在攻击者的状态处于步骤1 - A和4 - B之间的时间段期间，合法客户 端1将不能获得对网络的访问。这是另一示例性的服务拒绝攻击(DoS 攻击)类型。标记为"示例1:威胁2:(步骤1 - A到3 - A和4-B)" 的附图27演示了这样的DoS攻击。
另外，如果攻击者验证企图失败并且步骤5-B被使能，则攻击者 的记录(MAC1， P2)可以被添加到处罚列表(PL)中。然而，在该 记录持续的时间段期间，客户端1可能不能将分组发送到在UFD中创 建客户端1的记录(MAC1， Pl)的网桥。然而， 一旦客户端l得到 UFD中的记录，则客户端l可以在不被攻击者影响的情况下试图验证。 如果攻击者可以使用多个端口用于DoS攻击，则攻击者可以潜在地用 PL中的其他攻击节点填充时间周期。
参考标记为"示例1:威胁2:同时攻击"的附图29，图表(l)显 示了来自多个端口的同时DoS攻击。在图表(1)中，攻击者使用端 口 P2、 P3和P4，并尝试反复发送欺骗分组到网桥。在时间0处，P2 处的节点发送分组，并且获得UFD中的记录。因此，其防止端口 Pl 处的受骗者经由网桥发送分组。UFD中的攻击记录在时间l处到期， 但是P3处的另一攻击节点向网桥发送分组，并获得UFD中的记录。 该记录在时间2处到期，然而，P4处的再一节点获得UFD中的记录。 当该记录到期时，第一节点Pl重新被使能以发送分组。如图所示， 这些步骤可以被重复以创建DoS条件。在一些实施例中，对该类型攻击的一种阐释性的解决方案是与具
有相同MAC地址的UFD和PL记录的数目成比例的增加PL记录的 生命周期。该类型解决方案的阐释性示例被显示在附图29的图表(2) 中。正如图表(2)中所示，在时间0处，P2处的攻击节点发送分组 并获得UFD中的记录；在时间1处，P3处的节点得到记录。P3处节 点的UFD记录在时间2处到期，并且记录(MAC1， P3);陂移动到 PL。然而，与图表(1)中的显示相反，与UFD中的类似记录和PL 中的记录的数目成比例的计算PL记录的生命周期。在该示例中，在 时间2处，存在两条在UFD和PL中具有MAC1的记录。相应地， 该记录的生命周期提高一倍。在时间3处，P4处的节点被移动到PL。 相应地，因为在UFD和PL中有三条MAC1的记录，因此其生命周 期提高两倍。因此，Pl处的合法节点有机会在时间4和6以及在时间 7和9之间将分组发送到网桥。
在其他实施例中，PL实现方案的其他可能扩展可以包括，在MAC 地址和端口的相同组合被重复添加到PL时以增长的比率或指数形式 地提高PL记录的生命周期。这使本部分所描述的DoS攻击更加不可 行。然而，其可能导致使另一类型的DoS攻击更容易。在这方面，如 果攻击者和受骗者使用相同的端口 Pl，则攻击者可以试图将MAC地 址MAC1多次从P1添加到PL。在此之后，受骗者可能试图将MAC 地址为MAC1的节点连接到端口 1，但是因为PL中的记录(MAC1， Pl)具有指数级大的生存期，所以其可能失败。为了防止后一种类型 的DoS攻击，适度的时间上限会对这样的指数级增长是有用的。 4.1.2.3威胁3:具有验证的DoS攻击
参考标记为"示例1:威胁3，，的附图30,考虑其中第一用户"用户 l"使用节点"客户端l"而第二用户"用户2"使用节点"客户端2"的情 况。如图所示，客户端1连接到Pl，并且客户端2连接到P2。在该 示例中，每个用户，用户1和用户2在验证器上具有自己的账户。为 了防止用户l连接到网络，攻击者用户2可以将客户端2连接到网络 上，以冒充客户端1的MAC地址。如果用户2验证失败，则情况类似于上一部分所描述的威胁2的情况。然而，此时，因为用户2在验 证器上具有有效账户，所以用户2能够利用用户自己的用户凭证 (credential)而被验证。因为使用用户2的凭证来验证客户端2,所 以在AFD中创建客户端2的记录。相应地，客户端1因此不能连接到 网桥B1。为了防止此类型攻击，网络管理员可以撤销有错误行为的用 户2的凭证。可选地，管理员可以配置验证器，使得只有用户l的凭 证可以被用于MAC1的验证。
在一些实施例中，验证器可以知道客户端的端口标识符，对于验 证器更为灵活的配置是可能的。例如，参见下面的4.2.2.3部分的最后 所列出的示例。
4.2第二实现方案示例
4.2.1第二示例纵览
根据第二阐释性实施例，系统可以使用AFD、 PIT，并且可选地 还使用PL。在优选实施例中，系统执行下述内容中至少一部分，优选 为全部
1- A.参考标记为"示例2:步骤l-A，，的附图31，在这样的示例 性环境下，客户端(客户端1)开始连接到访问网络。如图所示，客 户端l连接到网桥(Bl)的端口 1 (Pl)，并且在引导过程中发送第 一分组。该消息可以是路由器请求(router solicitation)消息、DHCP 发现/请求(discover/solicit)消息或者其他形式的消息。
2- A.参考标记为"示例2:步骤2-A，，的附图32,因为在AFD和 PL中没有发现源MAC地址(MAC1 ),所以网桥将PIT附加到从客 户端l发送的分组，并且将其转发到PIT节点表中所发现的目的节点。 如附图32的示例所示，因为原始分组的目的地址是广播地址，因此网 桥将分组发送到PAA和DHCP服务器。如上所述，其他实现方案也 可以用于广播分组。
3- A.参考标记为"示例2:步骤3-A"的附图33， DHCP服务器 向客户端l发送响应，附加从请求分组中所复制的PIT。
4- A.参考标记为"示例2:步骤4-A，，的附图34,网桥将PIT从分组分离，并且将其转发到PIT中所发现的端口。
5- A.参考标记为"示例2:步骤5-A"的附图35，在引导过程中， 客户端1继续进行消息交换。其可以包括例如IP地址自动配置或 DHCP消息和PANA验证消息。
6- A.参考标记为"示例2:步骤6-A"的附图36，如果客户端l 被成功验证，则验证器请求网桥(Bl)为客户端l将新的记录添加到 AFD中。
7- A.参考标记为"示例2:步骤7-A"的附图37，客户端l开始 用于其他应用的消息交换。在这方面，因为客户端1的记录(MAC1: Pl)在AFD中存在，因此网桥(Bl)转发任何被验证的分组。
在一些优选实施例中，如果客户端1在上述步骤5 - A中未能通过 验证，则验证器可以请求网桥为客户端1将新的记录添加到PL中。 4.2.2安全考虑
4.2.2.1威胁l:通过欺骗的业务窃取
参考附图38 -39,在一些情况下，在客户端1已经被验证之后或 在客户端被验证之前紧邻的时刻，攻击者可以发送冒用客户端1的 MAC地址MAC1的分组。这可以;陂完成，以使 使网桥才艮据恶意信息 更新其转发数据库并将后续的寻址到客户端1的分组转发到攻击者， 而非合法的客户端l。但是，优选地，验证器和DHCP服务器不仅通 过MAC地址、而且通过端口标识符来区分会话。相应地，它们不4皮 从不同端口所发送的冒用分组所迷惑。参见标记为"示例2:威胁l&2:
步骤5-A处的多会话，，的附图38。另外， 一旦在步骤6-A中客户端 1被验证并且客户端1的记录被添加到AFD中，就禁止经由除Pl之 外的端口的来自/到MAC1的任何分组交换。因此，该类型的攻击会 失败。参见标记为"示例2:威胁1&2:步骤7 - A，，的附图39。 4.2.2.2威胁2:没有验证的DoS攻击
仍然参考附图38 -39，在一些情况下，攻击者可以在客户端l第 一次连接到网络之前发送冒用客户端1的MAC地址MAC1的分组。 尽管这对于上述使用UFD的实现方案而言可能有问题，但是这对于上述使用PIT的实现方案而言不存在问题。
因为验证器和DHCP服务器可以区分多个会话，所以在攻击者发 送冒用分组期间，客户端1可以总是尝试其验证。参见标记为"示例2: 威胁1&2:步骤5-A处的多会话"的附图38。 一旦在步骤6-A中客 户端1被验证并且客户端1的记录被添加到AFD，就禁止经由除Pl 之外的端口的来自/到MAC1的任何分组交换。相应地，因此，这样 的攻击失败。参见标记为"示例2:威胁1&2:步骤7 - A"的附图39。
4.2.2.3威胁3:具有验证的DoS攻击
现在参考这样的示例性情况，其中a)用户"用户l"使用节点"客 户端1"，而用户"用户2"使用节点"客户端2"; b)客户端l连接到端 口 Pl，客户端2连接到端口 P2;以及c)用户1和用户2中每一个在 验证器上具有自己的账户。为了防止用户1连接到网络，攻击者用户 2可以将客户端2连接到网络上，冒充客户端1的MAC地址。如果 用户2验证失败，则情况类似于前一部分所描述的威胁2的情况。然 而，此时，因为用户2在验证器上具有有效账户，所以用户2可以使 用用户自己的用户凭证被验证。另外，因为利用用户2的凭证验证客 户端2，所以在AFD中创建客户端2的记录。因此，客户端l不能连 接到网桥B1。
为了防止此类型的攻击，网络管理员可以撤销有错误行为的用户2 的凭证。可选地，管理员可以配置验证器，使得只有用户l的凭证可 以用于MAC1的验证。
PIT支持验证器的更灵活的配置。例如，因为验证器知道每个消 息的端口标识符，所以可以利用端口标识符指定限制。例如， 一些或 全部下述规则可以在一些示例性实施例中被实现
*如果验证请求来自端口 Bl: P2,则拒绝MAC1的验证请求。
例如，该规则在上述情况下是有用的。 *如果凭证来自除端口 Bl: Pl之外的其他端口，则不接受用户 1的凭证。如果用户1在特定端口 Bl: Pl上使用用户的网络 节点，则该规则可以是有用的。因此，即使某人窃取了用户1的密钥，攻击者也不能在除端口 Bl: Pl之外的其他端口使用 该密钥。
*如果请求来自除端口B1: Pl之外的其他端口，则拒绝MAC1 的验证请求。假设网络节点连接到端口 Bl: Pl,并且节点在 多个用户之间共享。优选地，每个用户具有使用该节点的账户。 用户可以使用该节点，而攻击者不能从除端口 Bl: Pl之外的 其他端口进行DoS攻击。
*允许任何来自端口 Bl: Pl的有效凭证，而在除B1: Pl之外 的节点上仅仅允许有限的凭证和MAC的组合。该规则可以在
下述情况下是有用的，即端口 Bl: Pl位于安全房间，而其他 端口位于非安全的开放空间。第ni部分来自网络访问验证协议的引导组播安全 i.背景信息 i. i.参考文献
下述一般背景技术参考文献被引入此用作参考。
1、 B. Cain等，"Internet Group Management Protocol Version3，，， RFC3376， 2002年10月(此后被称为RFC3376)。
2、 R. Vida和L. Costa, "Multicast Listener Discovery Version2 (MLDv2) for IPv6", RFC3810， 2004年6月(此后被称为RFC3810)。
3、 T. Hayashi等,"Multicast Listener Discovery Authentication Protocol ( MLDA ) ，，， Internet-Draft, draft國hayashi画mlda國02.txt， 仍在进行中，2004年4月(此后被称为MLDA)。
4、 M. Christensen等，"Considerations for IGMP and MLD Snooping Switches" , Internet-Draft , draft-ietf画magma誦snoop-ll.txt,仍在进行中，2004年5月(此后 被称为MLDSNOOP)。
5、 B. Lloyed和W. Simpson, "PPP Authentication Protocols", RFC1334, 1992年10月(此后被称为RFC1334)。
6、 M. Baugher等，"The Secure Real - time Transport Protocol (SRTP)，，， RFC3711, 2004年3月(此后被称为RFC3711)。
7、 J. Arkko等，"MIKEY: Multimedia Internet Keying", Internet-Draft, draft-ietf國msec誦mikey-08.txt，仍在进行中，2003 年12月(此后,皮称为MIKEY)。
8、 M. Thomas和J. Vihuber， "Kerberized Internet Negotiation of Keys (KINK) ，，， Internet-Draft, draft-ietf陽kink-kink國05.txt，仍 在进行中，2003年1月(此后^皮称为KINK)。
9、 T. Hardjono和B. Weis， "The Multicast Group Security Architecture", RFC 3740， 2004年3月(此后被称为RFC3740)。 10 、H. Harney 等，"GSAKMP，， ，Internet-Draft ,draft-ietf-msec-gsakmp-sec-06.txt，仍在进行中，2004年6月(此 后被称为GSAKMP)。
11、 T. Narten和E. Nordmark, "Neighbor Discovery for IP Version6 (IPv6 ) ，，，RFC 2461， 1998年12月(此后被称为RFC 2461)。
12、 H. Schulzrinne等,"RTP: A Transport Protocol for Real-time Applications", RFC 3550， 2003年7月(jt匕后,皮称为RFC 3550)。
13、 B. Aboba等，"Extensible Authentication Protocol ( EAP )，，， RFC 3748， 2004年6月(此后4皮称为RFC3748)。
14、 B. Aboba等，"Extensible Authentication Protocol (EAP) Key Management Framework"， Internet-Draft ， draft-ietf-eap画keying-02.txt,仍在进行中，2004年6月(此后被 称为EAP-KEY)。
15 、 D. Waitzman 等，"Distance Vector Multicast Routing Protocol", RFC 1075， 1998年11月(此后被称为RFC1075)。
16、 A. Ballardie， "Core Based Trees ( CBT version2 ) Multicast Routing", RFC 2189， 1997年9月(此后被称为RFC2189)。
17、 D. Estrin等，"Protocol Independent Multicast - Sparse Mode (PIM-SM) ，， Protocol specificaiton，，, RFC2362, 1998年6
月(此后净皮称为RFC2362)。
18、 D. Forsberg等,"Protocol for Carrying Authentication for NetworkAccess(PANA )" ， Internet-Draft ， draft-ietf-pana-pana-04.txt，仍在进行中，2004年5月7日(此后 被称为PANA)。
19、 IEEE局域网和城域网标准，"Port-Based Network Access Control", IEEE标准802.1X- 2001 (此后被称为802.1X)。
1.2术语在本公开中，术语"组播路由器，，包括例如能够转发IP组播分组的 路由器。在一些示例中，在相同IP链路中存在多个IP组播路由器。
在本公开中，术语"组播接听者"包括例如期望接收IP组播分组的 主机或路由器。
1.3 IP组播概述
附图40显示了 IP组播网络的示例。在该阐释性示例中，S1和S2 是始发目的为网络上特定组播地址GIP的组播分组的节点。Rl、 R2 和R3是能够转发IP组播分组的路由器。另外，Dl、 D2和D3是作 为IP组播分组的最终接收者的节点。在该阐释性示例中，假设每个链 路都是点到点链路。
附图41-42分别显示到附图40中所示网络中组播地址G的始发 于Sl和S2的组播分组的IP组播分组转发路径的示例。组播路由表 由每个路由器维护，以将组播分组转送到接听者。组播路由表可以被 静态、动态或静态和动态地构建。组播路由协议-诸如距离矢量组播 路由协议(^^RFC1075)、基于树(Based Tree, ^JjRFC2189) 和PIM(协议独立组播)(参见RFC2362)-可以被用于动态构 建组播路由表。根据使用的组播路由协议，所得到的组播转发路径可 以是不同的。在这些示例中，路由器R3需要创建每个组播分组的多 个副本，以将其转发到用于组播地址G的多个下一中继(hop)节点。
附图43显示了包括共享链路的IP组播网络的阐释性示例。如图 所示，Sl和S2是始发目的为网络上特定组播地址G的IP组播分组 的节点。Rl、 R2和R3是能够转发IP组播分组的路由器。另外，Dl、 D2和D3是作为IP组播分组的最终接收者的节点。
附图44显示了始发于S1的到组播地址G的组播分组的IP组播分 组转发路径的示例。与前面的示例不同，此处路由器Rl不需要创建 组播分组的多个副本以转发该分组。
1.4组播接听者发现
组播接听者发现(MLD)是被设计以在相同IP链路上的IPv6组 播路由器和IPv6组播接听者之间运行用于维护组播接听者状态的协议。
MLD协议第二版的综述在下面描述(也参见RFC3810)。对 于IPv4， IGMP (因特网群管理协议)(参见RFC3376)被用于 与MLD相同的目的。因为MLD和IGMP提供类似的功能，所以可 以将类似的解释和讨论(除了在消息名称和地址类型方面的不同)应 用于IGMP。相应地，在本公开中，涉及IGMP的讨论在本公开中不 进一步详细阐述。
组播接听者状态由组播路由器的每个链路维护，并且在概念上涉 及一组该形式的记录
(IPv6组播地址，过滤模式，源列表)。
过滤才莫式表示INCLUDE或EXCLUDE,其中INCLUDE表明从 源列表中所列的任何源地址所发送并且目的为IPv6组播地址的组播 分组在链路上被转发；EXCLUDE表明组从源列表中所列的任何源地 址所发送并且目的为IPv6组播地址的组播分组在链路上不被转发。
在MLDv2中，组播路由器周期性地或根据请求在每个链路上组播 组播接听者查询(MLQ)消息。当在链路上接收到导致链路的组播接 听者状态变化的组播接听者报告(MLR)消息时，MLQ消息根据请 求被发送。组播接听者在其表达其希望接听或不再接听特定组播地址 (或源)时或当其接收MLQ消息时发送MLR消息。组播路由器在 其接收到MLR时更新组播接听者状态。如果并且仅仅如果链路的组 播接听者状态表明明确允许或不明确禁止转送具有源-目的地址对(S， G)的分组，则组播路由器在链路上转发始发于特定源S并且目的为 特定组播地址G的组播分组。
附图45显示了发送查询(S1， G)或(S2， G)组播业务量的组 播接听者是否存在的MLQ消息的示例。附图46显示了响应附图45 中的MLQ而发送报告(S1， G)组播业务量的组播接听者Nl和N2 存在的MLR消息的示例。
1.5 MLD探听
附图47-48显示了在附图45-46所示的MLD过程完成之后(S1，G)组播分组的分组转发。在附图47中，链路层交换机SW不具备被 称为"MLD探听"的功能(参见MLDSNOOP)。在附图48中， 链路层交换机SW具备该"MLD探听"功能。具备MLD探听的链路层 交换机查看链路层帧的有效负荷以查看包括MLD首标或有效负荷以 及ICMP的更高层信息，并且将承载IP组播分组的链路层组播数据 帧仅仅转发到这样的端口，即在该端口处，通过监控MLD消息交换 已知组播接听者的存在。更具体地，如果交换机在端口上看到MLR 信息，则组播接听者被认为出现在交换机的端口上，并且通过使用 MLR消息有效负荷的内容、诸如组播目的地址和组播源地址，更精细 的(并更有效的)链路层组播转发是可能的。在没有MLD探听的情
k括没有组播接听者的^口 ，这可能导致低一效的资源使用。
1.6 MLD验证
在上述参考文献MLDA中定义了被称为MLD验证协议或 MLDA协议的对MLD的安全扩展。MLDA协议为组播路由器提供用 于组播接听者验证的功能，从而只有链路上被验证的组播接听者才能 更新组播路由器的链路的组播接听者状态。以这种方式，MLD验证可 以被用于通过将数据业务量仅转发到被验证且被授权的用户节点而实 现基于预定的组播流内容传送。MLDA支持用于验证组播接听者的 PAP ( 口令验证协议)和CHAP ( 口令响应验证协议)验证协议，这 允许通过在组播路由器上具备AAA客户端功能而由后端AAA(验证、 授权和计费)服务器验证组播接听者，以便避免将组播接听者的密码 存储在访问网络中每个组播路由器上。
1.7 SRTP
SRTP (安全实时传输协议)在前面提及的参考文献RFC3711
中被提出，并且提供了应用层每个分组加密、完整性保护和应答保护。 2.现有方法存在的问题 如下所述，现有方法中存在大量问题和限制。 问题1:第 一个问题涉及MLD本身不防止未授权接听者发送MLR消息以 改变组播接听者接收组播分组的状态，这会导致基于组播业务的自由 釆用(free-riding)，而不管接听者和组播路由器之间链路的类型(例 如点到点或共享)，并且不管MLD探听技术在共享链路的情况下是 否被用在链路上。
在这方面，通过例如使用与MLDA所提供的接听者验证和授权相 关的适当的访问控制，MLDA可以被用于解决该安全问题。然而，还 不存在诸如MLDA的与接听者验证和授权机制相关的访问控制方法。
问题2:
第二个问题涉及由于MLDA所支持的验证协议的缺点而导致的安 全问题。由于在使用组播接听者的静态密码作为PAP和CHAP的共 享秘密时MLDA所支持的PAP和CHAP都被认为对于字典式攻击 (dictionary attack )而言是脆弱的，所以使用这些算法是危险的并且 是不被推荐的，除非这些验证协议在安全通信信道上运行。尤其，PAP 和CHAP不应当在无线LAN上使用，其中在无线局域网上，攻击者 可以很容易作为冒充的访问节点以获得或猜到用户密码。
问题3:
第三个问题涉及MLDA不提供MLDA有效负荷的机密性。另夕卜， MLDA需要对MLD的改变。 问题4:
笫四个问题涉及，尽管MLDA可以与AAA集成，但是由于大多 数商业访问网络需要也与AAA集成的网络访问验证，所以由于执行 AAA过程两次，出现一次用于网络访问验证以获得全局IP地址，而 出现一次用于接收凭证，所以也作为组播接听者的网络访问客户端可 能会导致效率低下的信令，其中用于接收凭证的一次较优地应当被尽 可能地避免。
问题5:
第五个问题涉及仅仅依靠包括MLDA和IEEE 802.11i的网络层和 /或链路层安全机制的解决方案无法防止被验证和授权用于在无线访播接听者的组播数据分组。这意味着，需要更高层逐分组的安全机制-
诸如SRTP (参见RFC3711)-以避免在全共享访问链路上组播 业务的自由采用。这样的更高层逐分组的组播安全机制需要交换协议 来将组播密钥传递到组播接听者，以便自动进行密钥分配过程。上述 MIKEY (参见MIKEY)和KINK (参见KINK)被设计以如 此工作。然而，不存在用于建立使用这样的组播密钥交换协议所需的 凭证的实际解决方案。
3.所提出的方案
3.1从网络访问验证SI导MLDA
使用MLDA的一个问题是由于使用组播接听者的静态密码作为 MLDA中PAP和CHAP的共享秘密。 一种解决方案是在MLDA中使 用动态生成的共享秘密用于PAP和CHAP。共享秘密优选地具有生命 周期，使得秘密仅仅在有限时间内有效。在本公开中，基于用于MLDA 中的共享秘密的组播接听者和组播路由器之间的安全关联被称为 MLDA安全关联或MLDA SA,并且共享秘密被称为MLDA密钥。在 优选实施例中，以下介绍了用于存档MLDA密钥的动态生成的两个示 例性方法。
在第一方法中，从通过使用网络访问验证协议、诸如PANA (参 见PANA)和IEEE 802.1X (参见802.1X)而动态创建的验证 会话密钥导出MLDA密钥。当PANA或IEEE 802.1X #皮用于网络访 问验证协议时，可以通过AAA密钥(参见EAP-KEY)从EAP (参见RFC3748)主会话密钥(MSK)导出验证会话密钥。
在第二方法中，MLDA密钥可以在网络访问验证协议、诸如例如 PANA和IEEE 802.1X上被加密和承载。当PANA被用作网络访问验 证时，加密后的MLDA密钥可以在例如PANA - Bind - Request和 PANA-Bind-Answer消息中承载。在这种情况下，MLDA密钥可以 由例如密钥分配中心(KDC)生成或管理。在这方面，MLDA密钥分 配机制可以被实现用于基于本公开适当的目的。附图49显示了第一方法中的MLDA密钥分层结构。在附图49中， 包括三个协议实体EAP;网络访问验证协议(例如PANA和IEEE 802.1X)和MLDA。注意，MLDA密钥的生命周期与MLDA密钥一 起可以被从网络访问验证实体传送到MLDA实体。
通过使用短期共享秘密作为MLDA密钥，而不是使用长期密码， MLDA的安全等级可以提高。另外，这提供了在前面的第二部分中所 描述的问题2的一种解决方案。另外，这些示例性方法是有效的，因 为一旦网络访问验证的AAA过程完成，就不需要MLDA的附加AAA 过程。因此，其也提供了在前面第二部分所描述的问题4的解决方案。
在各种实施例中，本领域技术人员可以基于本公开适当地实现 MLDA密钥推导算法。
附图53显示了第一方法的功能模块。如图所示，EAP-S (EAP 服务器)是EAP方法的端点。AA (验证代理)是网络访问验证协议 的验证器(诸如例如IEEE 802.1X验证器或PANA代理)。R是组播 路由器。L是组播接听者。在一些实施例中，EAP-S可以与AA共 处于同一物理实体中。另外，在一些实施例中，AA可以与EAP-S 或R共处于同一物理实体中。
参考附图53,在执行MLDA之前，在L和AA之间进行网络访 问验证。在一些实施例中，网络访问验证使用EAP验证L，其中AA 联系EAP - S以经由AAA协议或API获得AAA密钥。当网络访问验 证成功完成时，AA从AAA密钥推导MLDA密钥，并且将MLDA密 钥传送到R。 L在本地从其与AA共享的AAA密钥推导出相同的 MLDA密钥。在此之后，R和L能够执行MLDA。
附图54显示了第二方法的功能模块。如图所示，EAP-S (EAP 服务器)是EAP方法的端点。AA (验证代理)是网络访问验证协议 的验证器(诸如例如IEEE 802.1X验证器或PANA代理)。R是组播 路由器。L是组播接听者。另外，KDC是密钥分配中心。在一些实施 例中，EAP-S可以与AA共处于相同物理实体中。另外，在一些实 施例中，AA可以与EAP-S或R共处于相同物理实体。而且，KDC可以与EAP-S、 AA或R共处于相同物理实体。
参考附图54，网络访问验证首选在L和AA之间发生。网络访问 验证使用EAP来验证L，其中AA联系EAP - S以经由AAA协议或 API获得AAA密钥。在网络访问验证成功完成后，AA从KDC得到 MLDA密钥的副本，并且在网络访问验证协议上在加密的情况下将其 传送到L。 R可以从KDC获得MLDA密钥的副本。 一旦MLDA密 钥被发送到L， R和L就能够执行MLDA。
3.2以组播IPsec保护MLD
不使用MLDA,可以使用IPsec AH和/或ESP来保护MLD协议 交换。该方法不仅提供完整性保护和应答保护，而且还提供MLD消 息内容的保密性。另夕卜，该方法不需要对MLD协议本身做任何改变。 这二者(IPsec AH和/或ESP)提供了在前面第二部分所描述的问题3 的解决方案。因为MLD协议基于(例如链路本地)組播通信，所以 基本IPsec SA形成作为多到多关联(例如在MLD的情况下在组播接 听者和组播路由器之间)的群安全关联或GSA (参见RFC3740)。 为了自动创建IPsec GSA,可以使用组播密钥管理协议。存在大量可 以被用于建立GSA的密钥管理协议，诸如例如GSAKMP (参见GSAKMP)、MIKEY(参见MIKEY)和KINK(参见KINK)。
类似于诸如例如IKE的单播密钥管理协议，组播密钥管理协议一 般基于单播通信，并且应该具有端点的相互验证，以便避免组播密钥 被错误实体建立。这意味着，在组播密钥管理协议中用于相互验证的 特定密钥应当在组播密钥管理协议的每个端点上被预配置。这样的密 钥被称为组播密钥管理密钥或MKM密钥。在优选实施例中，所提出 的方法基于推导MKM密钥，并且以与推导MLDA密钥相同的方式 从网络访问验证协议中导出。
附图50显示了在通过使用组播密钥管理协议建立IPsec GSA并且 从网络访问验证协议推导MKM密钥的情况下的组播IPsee密钥分层 结构。
密钥推导模型不仅可以用于以组播Ipsec保护MLD，而且还可以用于以组播Ipsec保护其他组播通信协议，诸如例如IPv6邻元素发现 (Neighbor Discovery X参见RFC2461)和RTP(参见RFC3550)。
该示例性方案非常有效，因为一旦用于网络访问验证的AAA过程 完成，就不需要附加的用于MLDA的AAA过程。因此，其提供了在 前面的第二部分所描述的问题4的解决方案。
在各种实现方案中，本领域技术人员可以基于本公开适当地实现 用于每个可能的组播密钥管理协议的MKD密钥推导算法。
附图55显示了该方法的功能模块。如图所示，EAP-S(EAP月良 务器)是EAP方法的端点。AA (验证代理)是网络访问验证协议的 验证器(例如IEEE 802.1X验证器或PANA代理)。R是组播IPsec 接收者。S是组播IPsee发送者。KMS是密钥管理协议中心。此处， EAP-S可以与AA共处于相同的物理实体。另外，KMS可以与AA、 EAP - S或者S共处于相同的物理实体。
在附图55中，网络访问验证首先在R和AA之间发生。网络访问 验证使用EAP验证R，其中AA联系EAP - S以经由AAA协议或API 获得AAA密钥。当网络访问验证成功完成时，AA从AAA密钥导出 MKM密钥，并且将MKM密钥传送到KMS。接着，密钥管理协议在 KMS和R之间运行。 一旦密钥管理协议产生IPsec加密密钥，IPsec 加密密钥被从KMS传送到S，并且最终S和R能够在组播IPsec上 执行MLD或任何其他基于组播的协议。
3.3 MLD或MLDA与链路层组播访问控制的集成
在一些实施例中，支持将第二层组播帧复制到有限的一组端口 (例 如受限组播功能性)的链路层交换机可以被用于共享链路上组播业务 量的访问控制。
当具有IPsec的MLDA或MLD被用于安全地维护组播接听者状 态时，组播路由器可以以下述方式控制链路上的链路层交换机，即组 播分组被转发到这样的端口上，在该端口处存在从其接收密码学上有 效的MLR消息的组播接听者。在该方法中，通过使用前面的3.1和 3.2部分中所描述的方法，可以从网络访问验证协议、诸如PANA和IEEE 802.1X引导具有Ipsec的MLDA和MLD。
如果具有有限组播功能的链路层交换机还支持在标题为"绑定网
桥和网络访问验证，，的第II部分中所描述的方案，则可以滤出始发于和 目的为还没有被成功验证和授权用于网络访问的接听者的MLR和 MLQ消息。如果交换机还支持MLD探听，则可以在不依赖于具有 Ipsec的MLDA或MLD的情况下执行链路层组播访问控制。在该方 法中，通过使用网络访问验证协议、诸如例如PANA和IEEE 802.1X, 组播接听者被验证和被授权用于网络访问。
因此，该两种方法可以有利地提供第二部分的问题l的解决方案。 如果通过使用独立于MLD或MLDA而提供的信令机制，组播接 听者的组播业务量过滤信息(诸如例如被验证组播群地址和/或被验证 组播源地址)被安装到链路层交换机，并且使能将后续的被验证组播 业务量传送到链路层，则MLD或MLDA可以不被用于组播接听者和 组播路由器之间。
3.4从网络访问验证f 1导安全组播应用会话
如上述第二部分针对问题5所讨论的那样，需要更高层逐分组的 安全机制、诸如SRTP (参见RFC3711)，以避免在全共享访问 链路上组播业务的自由釆用。这样的机制包括应用程序数据业务量的 加密。对于工作在大规模环境中的应用层安全，可以使用一种机制来 自动建立安全应用会话与组播密钥的安全关联。在一些实施例中，存 在两种达到上述目标的示例性方法，该方法在下面详细描迷。
第一种方法基于引导用于建立安全应用会话的安全关联的组播密 钥管理协议。在各种实现方案中，存在大量可以被用于建立用于安全 组播应用会话的安全关联的密钥管理协议，诸如例如GSAKMP (参 见GSAKMP)、MIKEY(参见MIKEY)和KINK(参见KINK)。 另外，SIP可以被用作组播密钥管理协议。如3.2部分所述，需要MKM 密钥以用于组播密钥管理协议中的相互验证。该方法以与上述3.2部 分所描述的相同的方式从网络访问验证协议中导出MKM密钥。
附图51显示了第 一种方法中在SRTP被用作安全应用层协议的情况下组播应用会话密钥分层结构。在附图51中，通过使用组播密钥管 理协议建立SRTP主密钥(参见RFC3711)，并且从网络访问验 证协议导出MKM密钥。该密钥推导模型不仅可以被用于SRTP，而 且还可以被用于保护其他基于组播的应用层协议。本领域技术人员可 以基于本公开适当地实现用于每个可能的组播密钥管理协议的特定 MKM密钥推导算法和用于每个可能的组播应用的应用会话密钥推导 算法。
第二种方法基于在网络访问验证协议、诸如例如PANA和IEEE 802.1X上承载应用会话密钥。当PANA被用作网络访问验证时，应用 会话密钥、诸如例如SRTP主密钥可以;故加密地在PANA-Bind-Request和PANA-Bind-Answer消息中承载。在这种情况下，应用 会话密钥可以由密钥分配中心(KDC)生成或管理。本领域技术人员 可以基于本公开适当地实现应用会话密钥分配机制。
附图52显示了在第二种方法中在SRTP被用作安全应用层协议的 情况下组播应用会话密钥分层结构。在附图52中，通过使用组播密钥 管理协议建立SRTP主密钥(参见RFC3711)，并且从网络访问 验证协+义中导出MKM密钥。
在一些实施例中，这两种方法可以为上面第二部分中所描述的问 题5提供解决方案，并且可以与第3.1部分到第3.3部分所描述的其他 方法一起使用。
附图56显示了第一种方法的功能模块。EAP-S (EAP月良务器) 是EAP方法的端点。AA (验证代理)是网络访问验证协议的验证器 (例如IEEE 802.1X验证器或PANA代理)。R是组播应用接收者。 S是组播应用发送者。KMS是密钥管理协议服务器。另外，EAP-S 可以与AA共处于相同物理实体中。而且，KMS可以与AA、 EAP-S或S共处于相同物理实体中。
在附图56中，网络访问验证首先发生在R和AA之间。网络访问 验证使用EAP来对R进行验证，其中AA联系EAP - S以经由AAA 协议或API获得AAA密钥。当网络访问验证成功完成时，AA从AAA密钥推导出MKM密钥，并且将MKM密钥传送到KMS。接着，密 钥管理协议在KMS和R之间运行。 一旦密钥管理协议生成应用会话 密钥，S和R就能够发送和接收由应用层安全机制保护的组播应用业 务量。
附图57显示了第二种方法的功能模块。EAP-S (EAP月艮务器) 是EAP方法的端点。AA (验证代理)是网络访问验证协议的验证器 (例如IEEE 802.1X验证器或PANA代理)。R是组播应用接收者。 S是组播应用发送者。KDC是密钥分配中心。另外，EAP-S可以与 AA共处于相同物理实体中。而且，KDC可以与AA、 EAP-S或S 共处于相同物理实体中。
在附图57中，网络访问验证首先发生在R和AA之间。网络访问 验证使用EAP来对R进行验证，其中AA联系EAP - S以经由AAA 协议或API获得AAA密钥。在网络访问验证成功完成后，AA从KDC 获得应用会话密钥的副本，并且在网络访问验证协议上将其传送到R。 S可以从KDC获得应用会话密钥的副本。 一旦应用会话密钥被传送到 R, S和R就能够发送和接收由应用层安全机制保护的组播应用业务 量。
本发明的宽广范围
尽管这里已经介绍了本发明的示例性实施例，但是本发明并不局 限于此处描述的各种优选实施例，而是包括本领域技术人员基于本公 开应当理解的具有等效元件、改变、省略、组合(例如各种实施例许 多方面的组合)、调整和/或变化的任何和所有实施例。权利要求书中 的限制应该基于在权利要求中所使用的语言而被宽泛地解释，并且不 限于本说明书中或本申请的过程中所描述的示例，这些示例被解释为 非排他性。例如，在本文中，术语"优选地，，是非排他性的，并且意味 着"优选，但不限于"。在本文中以及本申请的过程中，将只使用"装置 加功能，，或"步骤加功能"的限制，其中对于具体权利要求限制，在该限 制中存在所有以下条件a)"用于…的装置"或"用于…的步骤，，被明确 记载；b)相应的功能被清楚地叙述；并且c)支持该结构的结构、材料或行为未被叙述。在本文中以及本申请的过程中，术语"本发明"或 "发明"可以被用于指本发明中的一个或多个方面。语言本发明或发明 不应该被不适当地解释为临界状态的标识，不应该被不适当地解释为 应用于所有方面或者实施例(即，应当理解，本发明具有大量方面和 实施例)，并且不应该被不适当地解释为限制本申请或权利要求的范 围。在本文中以及本申请的过程中，术语"实施例"可以被用于描述任 何方面、特征、过程或者步骤、其任何结合和/或其部分等等。在一些 示例中，各种实施例可以包括重叠特征。在本文中，可以使用下述缩
略语含义为"举例而言"的"例如"，含义为"适当注意"的"注意"。
权利要求
1. 一种用于绑定动态主机配置和网络访问验证的方法，包括提供网络访问验证器以验证至少一个客户端设备；提供动态主机配置服务器以为客户端设备动态分配IP地址；在验证会话或动态主机配置会话丢失时，维持所述至少一个客户端设备和所述网络访问验证器之间的验证会话与所述动态主机配置服务器和所述至少一个客户端设备之间的动态主机配置会话的同步。
2. —种用于绑定动态主机配置和网络访问验证的系统，包括 用于验证至少一个客户端设备的网络访问验证器； 被配置用以为客户端设备动态分配IP地址的动态主机配置服务器；其中所述系统被配置为以在验证会话或动态主机配置会话丟失时 维持同步的方式来维持所述至少一个客户端设备和网络访问验证器之 间的验证会话与所述动态主机配置服务器和所述至少一个客户端设备 之间的动态主机配置会话的同步。
3. 如权利要求2所述的系统，其中所述网络访问验证器使用验证 协议来承载网络访问验证信息。
4. 如权利要求3所述的系统，其中所述验证协议包括作为用于承 栽网络访问验证信息的协议的PAN A 。
5. 如权利要求4所述的系统，其中EAP被用作验证协议，其由 用于承载网络访问验证信息的协议承载。
6. 如权利要求2所述的系统，其中所述动态主机配置服务器是动 态主^L配置协议(DHCP)服务器。
7. 如权利要求2所述的系统，其中所述验证器被配置为在验证会 话终止后向所述动态主机配置服务器传送消息，以通知所述会话已经 终止。
8. 如权利要求7所述的系统，其中所述消息向所述动态主机配置 服务器通知从所述验证会话所导出的动态主机配置密钥不再有效。
9. 如权利要求7所述的系统，其中所述系统被配置为更新所述动 态主机配置服务器中的配置文件。
10. 如权利要求7所述的系统，其中所述系统被配置为在所述动态 主机配置服务器中重写或者重新加栽配置文件。
11. 如权利要求7所述的系统，其中所述验证器被配置为向所述 动态主机配置服务器传送删除请求，以删除客户端配置。
12. 如权利要求2所述的系统，其中所述系统被配置为在验证会 话终止后更新验证会话密钥，同时保持动态主机配置密钥不变。
13. 如权利要求2所述的系统，其中所述系统被配置为在验证会 话终止后更新验证会话密钥，但在稍晚的时间更新动态主机配置密钥。
14. 如权利要求2所述的系统，其中在验证会话终止后，在所述 验证器和客户端之间建立新的验证会话密钥，并且所述系统被配置为利用新的动态主机配置密钥迅速重启动态主机配置会话。
15. 如权利要求2所述的系统，其中所述系统被配置为使得在重 启所述动态主机配置服务器后，非易失性存储器被用于恢复所述动态主机配置密钥的状态。
16. 如权利要求15所述的系统，其中所述动态主机配置服务器被 配置，使得在重启后，所述动态主机配置服务器将动态主机配置密钥 表和绑定表保存到非易失性存储器。
17. 如权利要求2所述的系统，其中所述系统被配置，使得在重 新引导所述动态主机配置服务器后，所述动态主机配置服务器被配置 为向所述验证器通知动态主机配置密钥已经被擦除。
18. 如权利要求2所述的系统，其中所述系统被配置，使得在重 新引导所述动态主机配置服务器后，所述验证器获知所述动态主机配 置服务器的重新引导，从而知道动态主机配置密钥已经被擦除。
19. 如权利要求2所述的系统，其中所述系统被配置，使得在动 态主机配置密钥信息丢失后，所述动态主机配置服务器被配置为请求 所述验证器重新发送动态主机配置密钥信息，并且被配置为基于来自 所述验证器的响应而重新存储所述动态主机配置密钥表。
20. 如权利要求19所述的系统，其中所述动态主机配置服务器被 配置为在所述动态主机配置服务器启动时请求所述验证器重新发送动 态主机配置密钥。
21. 如权利要求19所述的系统，其中所述验证器被配置为向所述 动态主机配置服务器发送所有有效的动态主机配置密钥。
22. 如权利要求2所述的系统，其中所述系统被配置，使得在动 态主机配置绑定到期后，客户端请求所述验证器在动态主机配置消息 交换之前重新验证并更新所述动态主机配置密钥。
23. 如权利要求2所述的系统，其中所述系统被配置，使得在动 态主机配置绑定到期后，所述动态主机配置服务器请求所述验证器在 动态主机配置消息交换之前重新验证并更新所述动态主机配置密钥。
24. 如权利要求2所述的系统，其中所述系统被配置，使得在交 换验证消息以在所述验证器和客户端之间创建新的动态主机配置密钥 期间，所述验证器被配置为避免发送表明已经成功建立新的验证会话 的消息，直到所述动态主机配置密钥被安装在所述动态主机配置服务 器上。
25. —种用于绑定动态主机配置和网络访问验证的系统，包括 用于验证至少一个客户端设备的网络访问验证器； 被配置为为客户端设备动态分配IP地址的动态主机配置服务器； 其中所述系统被配置为在所述动态主机配置服务器和所述至少一个客户端设备之间的动态主机配置会话的初始引导之后同步所述至少 一个客户端设备和所述网络访问验证器之间的验证会话与所述动态主 机配置会话。
26. —种用于防止恶意攻击者获取对网络的非授权访问的网络访 问验证方法，包括设置网桥，以防止恶意攻击者获取对网络的非授权访问，其中所 述网桥具有用于与至少一个客户端通信的客户端端口和用于与所述网 络通信的至少一个服务器端口 ；利用所述网桥来基于所述网桥中的非授权转发数据库防止恶意攻 击者获取非授权访问。
27. —种用于网络访问验证的系统，包括被设置以防止恶意攻击者获取对网络的非授权访问的网桥；其中所述网桥具有用于与至少一个客户端通信的客户端端口和与所述网络通信的至少一个服务器端口；所述网桥包括至少一个存储地址和网桥端口数据的转发数据库， 其中所述转发数据库包括未授权转发数据库(UFD)，所述网桥被配 置为基于所述至少一个转发数据库防止恶意攻击者获取非授权访问。
28. 如权利要求27所述的系统，其中所述至少一个转发数据库包 括授权转发数据库(AFD )。
29. 如权利要求28所述的系统，其中所述数据包括多对MAC地 址和网桥端口号。
30. 如权利要求29所述的系统，其中所述网桥被配置，使得MAC 地址不在所述授权转发数据库中出现多于一次。
31. 如权利要求28所述的系统，其中所述系统被配置，使得当客 户端断开时，相应的记录被从所述授权转发数据库中删除。
32. 如权利要求27所述的系统，其中所述数据包括多对MAC地 址和网桥端口号。
33. 如权利要求32所述的系统，其中所述网桥被配置，使得MAC 地址不在所述未授权转发数据库中出现超过一次。
34. 如权利要求32所述的系统，其中所述系统被配置，使得禁止 将已经出现在未授权转发数据库或授权转发数据库中的MAC地址添 加到所述未授权转发数据库。
35. 如权利要求27所述的系统，其中所述至少一个转发数据库包括处罚列表(PL)数据库。
36. 如权利要求35所述的系统，其中所述数据包括多对MAC地 址和网桥端口号。
37. 如权利要求36所述的系统，其中所述数据还包括超时信息。
38. 如权利要求27所述的系统，其中所述至少一个转发数据库包 括从所述未授权转发数据库、授权转发数据库和处罚列表数据库中所 选出的至少一个数据库，并且所述网桥被配置为根据与所述至少一个 数据库的匹配来过滤分组。
39. 如权利要求38所述的系统，其中所述网桥被配置，使得如果 至少一个所述数据库中的记录的MAC地址字段等于在所述网桥的客 户端端口所接收的分組的源MAC地址，并且所述记录的端口号字段 包含所述客户端端口的值，则认为所述分组与所述记录匹配。
40. 如权利要求38所述的系统，其中所述网桥被配置，使得如果 至少一个所述数据库中的记录的MAC地址字段等于在所述网桥的服 务器端口所接收的分组的目的MAC地址，则认为所述分組与所述记 录匹配。
41. 如权利要求38所述的系统，其中所述网桥被配置，使得为了 过滤目的，以以下方式检查分组，即如果分组与授权转发数据库中的 记录匹配，则所述网桥转发所述分组。
42. 如权利要求38所述的系统，其中所述网桥被配置，使得为了 过滤目的，以以下方式检查分组，即如果分组与未授权转发数据库中 的记录匹配，则所述网桥查看所述分组的IP首标；并且如果所述分组被寻址到所述网络外的节点，则所述网桥阻止所述分组，而如果所述 分組寻址到所述网络内的节点，则所述网桥转发验证后的分组。
43. 如权利要求38所述的系统，其中所述网桥被配置，使得为了 过滤目的，以以下方式检查分组，即如果分组与处罚列表数据库中的 记录匹配，则所述网桥阻止所述分组。
44. 如权利要求38所述的系统，其中所述网桥被配置，使得为了 过滤目的，以以下方式检查分组，即如果在客户端端口所接收的分组 具有在授权转发数据库或未授权转发数据库中发现的MAC地址，则 所述网桥阻止所述分组。
45. —种用于防止恶意攻击者获取对网络的非授权访问的网络访 问验证方法，包括设置网桥以防止恶意攻击者获取对网络的非授权访问，其中所述 网桥具有用于与至少一个客户端通信的客户端端口和用于与所述网络 通信的至少一个服务器端口；和利用所述网桥来将端口标识符标签附加到要从服务器端口传送的 分组，并且转发所述标记后的分组而不是转发原始分组。
46. —种用于网络访问验证的系统，包括被设置以防止恶意攻击者获取对网络的非授权访问的网桥； 所述网桥包括用于与至少一个客户端通信的客户端端口和用于与所述网络通信的至少一个服务器端口；所述网桥被配置为将端口标识符标签附加到要从服务器端口传送的分组，并且转发标记后的分组而不是转发原始分组。
47. 如权利要求46所述的系统，其中所述网桥被配置，使得在所 述网桥接收从验证器或动态主机配置服务器所发送的标记后的分组时，所述网桥查看所述标签中的端口标识符，并且将未标记的分组转 发到所述标签中所指定的端口。
48. 如权利要求46所述的系统，其中所述端口标识符包括网桥标 识符和端口号。
49. 如权利要求46所述的系统，其中所述系统被配置为通过使用 端口标识符和MAC地址的组合来区分服务器会话。
50. 如权利要求46所述的系统，其中所述网桥被配置为阻止从客 户端端口发送的具有端口标识符标签的分组。
51. 如权利要求27所述的系统，其中为了防止伪装验证器或动态 主机配置服务器，所述网桥被配置为不将验证分组或动态主机配置分 组从一个客户端端口转发到另 一客户端端口 。
52. 如权利要求27所述的系统，其中所述至少一个数据库包括所 述未授权转发数据库，并且所述网桥被配置为向所述验证器和所述动 态主机配置服务器通知将记录添加到所述未授权转发数据库或从其中 删除记录，其中所述通知包括所述记录的端口号和MAC地址。
53. 如权利要求27所述的系统，其中所述至少一个数据库包括所 述未授权转发数据库，并且所述网桥被配置为应答来自所述验证器或 所述动态主机配置服务器的对于将记录添加到所述未授权转发数据库 或对于从其中删除记录的查询，使得所述验证器或动态主机配置服务 器可以了解客户端的端口标识符。
54. —种用于禁止对组播通信的未授权访问的方法，包括 从网络访问验证协议中引导组播安全，以避免IP组播流不必要地被未验证接收者接收和/或处理。
55. —种用于禁止对组播通信的未授权访问的系统，包括 为至少 一个组播发送者验证至少 一个组播接听者的验证代理， 所述系统被配置为从网络访问验证协议中引导组播安全，以避免IP组播流不必要地被未验证接收者接收和/或处理。
56. 如权利要求55所述的系统，其中所述系统被配置为使用动态 生成的共享秘密。
57. 如权利要求56所述的系统，其中所述共享秘密具有有限的使 用期限。
58. 如权利要求57所述的系统，其中所述系统被配置为基于所述 共享秘密在组播接听者和组播路由器之间建立安全关联。
59. 如权利要求58所述的系统，其中所述安全关联是MLDA安 全连接，并且所述共享秘密是MLDA密钥。
60. 如权利要求56所述的系统，其中从通过使用网络访问验证协 议而动态创建的验证会话密钥导出所述共享秘密。
61. 如权利要求60所述的系统，其中所述网络访问验证协议包括 PANA或IEEE 802.1X。
62. 如权利要求61所述的系统，其中通过AAA密钥从EAP主会 话密钥导出所述验证会话密钥。
63. 如权利要求56所述的系统，其中所述系统包括验证代理，其中所述验证代理是网络访问协议的验证器，所述验证代理被配置为从 验证服务器接收密钥并且被配置为将所述共享秘密传送到组播路由 器。
64. 如权利要求56所述的系统，其中所述共享秘密被加密，并且 被承载在网络验证访问协议上。
65. 如权利要求64所述的系统，其中所述网络访问验证协议包括 PANA或者或IEEE 802.1X。
66. 如权利要求64所述的系统，其中所述共享秘密是MLDA密钥。
67. 如权利要求64所述的系统，其中从密钥分配中心接收所述共 享秘密。
68. 如权利要求55所述的系统，进一步包括使用IPsec来保护协 议交换。
69. 如权利要求55所述的系统，进一步包括使用ESP来保护协议 交换。
70. 如权利要求68所述的系统，其中基本IPsee安全关联(SA) 形成组安全关联，其中组安全关联是组播接听者和组播路由器之间的 一到多或多到多关联。
71. 如权利要求70所述的系统，其中所述系统被配置，使得使用 组播密钥管理协议来自动创建IPsec组安全关联。
72. 如权利要求55所述的系统，进一步包括链路层交换机，其中 所述交换机支持将第二层组播帧复制到一组有限的端口，以在共享链 路上提供组播业务量的访问控制。
73. 如权利要求72所述的系统，其中组播路由器被配置为以以下 方式控制链路层交换机，即组播分组被转发到这样的端口，即在所述 端口处存在从其接收密码有效的消息的组播接听者。
74. 如权利要求55所述的系统，其中所述系统被配置为包括更高 层每个分组的安全，以防止组播业务在共享访问链路上自由采用。
75. 如权利要求74所述的系统，其中提供机制以自动建立用于具 有组播密钥的安全应用会话的安全关联。
76. 如权利要求75所述的系统，其中所述机制包括引导被用于建 立安全应用会话的组播密钥管理协议。
77. 如权利要求75所述的系统，其中所述机制包括在网络访问验 证协议上承栽应用会话密钥。
78. 如权利要求77所述的系统，其中所述系统被配置，使得在网 络访问验证成功完成之后，验证代理从密钥分配中心获得应用会话密 钥的副本，并且在网络访问验证协议上将密钥传送到组播应用接收者， 同时组播应用传送者也从所述密钥分配中心接收所述密钥的副本，从 而所述组播应用传送者和组播应用接收者可以以所述更高层每个分组 的安全而传送和接收组播应用业务量。
全文摘要
根据一些实施例，绑定动态主机配置和网络访问验证的系统和方法得以提供，其涉及其中PAA(PANA验证代理)和DHCP(动态主机配置协议)服务器之间的相互作用，举例而言，例如为了PANA SA状态和DHCP SA状态之间的同步，举例而言，例如为了当连接丢失的时候维持同步。在一些实施例中，绑定网桥和网络访问验证的系统和方法得以提供，其涉及其中PAA和第二层交换机之间的相互作用，举例而言，例如为了以例如上述内容的方式避免服务窃取以及类似情形(举例而言，例如MAC地址和/或IP地址欺骗)。在一些其他实施例中，从网络访问验证协议引导组播安全的系统和方法得以提供，其涉及其中对受保护的IP组播流进行的密钥管理，举例而言，例如为了避免IP组播流由未验证的接收者不必要地接收和/或处理，在例如上述内容方面该非验证的接收者与验证的接收者一样连接到同样的第二层的部分。
文档编号G06F15/16GK101416176SQ200580029696
公开日2009年4月22日 申请日期2005年7月8日 优先权日2004年7月9日
发明者大场义洋, 胜部泰弘, 藤本谦作 申请人:株式会社东芝;特尔科迪亚科技公司