CN101416176A

CN101416176A - 动态主机配置和网络访问验证

Info

Publication number: CN101416176A
Application number: CNA200580029696XA
Authority: CN
Inventors: 藤本谦作; 胜部泰弘; 大场义洋
Original assignee: Toshiba Corp; Telcordia Technologies Inc
Current assignee: Trachia Legaci Co ltd; Toshiba Corp
Priority date: 2004-07-09
Filing date: 2005-07-08
Publication date: 2009-04-22
Anticipated expiration: 2025-07-08
Also published as: JP2010183604A; US20060036733A1; KR20070032061A; JP5470113B2; KR20130059425A; US8688834B2; KR100931073B1; CN101416176B; EP1769384A4; KR101396042B1; WO2006017133A2; KR101528410B1; EP1769384B1; WO2006017133A3; KR101320721B1; JP2008536338A; KR101591609B1; KR20120076366A; KR20140025600A; KR20090089456A

Abstract

根据一些实施例，绑定动态主机配置和网络访问验证的系统和方法得以提供，其涉及其中PAA(PANA验证代理)和DHCP(动态主机配置协议)服务器之间的相互作用，举例而言，例如为了PANA SA状态和DHCP SA状态之间的同步，举例而言，例如为了当连接丢失的时候维持同步。在一些实施例中，绑定网桥和网络访问验证的系统和方法得以提供，其涉及其中PAA和第二层交换机之间的相互作用，举例而言，例如为了以例如上述内容的方式避免服务窃取以及类似情形(举例而言，例如MAC地址和/或IP地址欺骗)。在一些其他实施例中，从网络访问验证协议引导组播安全的系统和方法得以提供，其涉及其中对受保护的IP组播流进行的密钥管理，举例而言，例如为了避免IP组播流由未验证的接收者不必要地接收和/或处理，在例如上述内容方面该非验证的接收者与验证的接收者一样连接到同样的第二层的部分。

Description

动态主机配置和网络访问验证

技术领域

本申请涉及计算机网络，尤其涉及动态主机配置、组播安全和网络访问验证。

背景技术

网络和因特网协议

存在多种类型的计算机网络，其中因特网最具声名。因特网是计算机网络的全球网络。如今，因特网是数百万计用户可以使用的公共的并且自给的网络。因特网使用被称为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.11a、802.11b和802.11g设备的IEEE802.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 HostConfiguration Protocol的RFC2131中所详细描述的，DHCP提供对因特网主机的配置参数。DHCP包括两个组成部分：用于从DHCP服务器向主机传送主机特定的配置参数的协议和用于将网络地址分配给主机的机制。参见RFC2131。“DHCP基于客户机-服务器模型建立，其中指定的DHCP服务主机分配网络地址并将配置参数传送到动态配置的主机。”Id。

正如RFC2131中所描述的，DHCP服务器指通过DHCP提供初始化参数的主机，DHCP客户端指从DHCP服务器请求初始化参数的主机。主机不作为DHCP服务器，除非由系统管理员适当配置。DHCP支持IP地址分配的三种机制：1)“自动分配”，在该机制下，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))。

根据一些实施例，提供用于从网络访问验证协议引导组播安全的系统和方法，其中其涉及用于被保护IP组播流的密钥管理，诸如例如以在例如以上情形下避免IP组播流被与被验证的接收者连接到相同第二层部分的未验证的接收者不必要地接收和/或处理。

附图说明

本发明的优选实施例以示例而不是限制的形式显示在附图中，其中：

附图1-12是说明性原理图，其示出了根据本发明一些优选实施例的特征，其中其涉及绑定动态主机配置和网络访问验证，涉及优选实施例的详细描述的第I部分，更具体地：

附图1是一般结构模型的示意图；

附图2是演示网络访问验证和DHCP的示意图；

附图3是演示在验证会话进行的情况下服务器的行为的示意图；

附图4是演示在验证会话进行的情况下客户端的行为的示意图；

附图5是示意图，其中其演示了AAA密钥更新方法1：DHCP密钥保持不变；

附图6是示意图，其中其演示了AAA密钥更新方法2：延迟的DHCP密钥更新；

附图7是示意图，其中其演示了AAA密钥更新方法3：即时的DHCP密钥更新；

附图8是示意图，其演示了DHCP服务器重启方法1：非易失性存储器；

附图9是原理图，其演示了DHCP服务器重启方法2：从暂存区中再引导；

附图10是原理图，其演示了DHCP服务器重启方法3：向验证器请求密钥；

附图11是原理图，其演示了DHCP使用期限过期方法1：保持当前的DHCP密钥；和

附图12是原理图，其演示了DHCP使用周期过期方法2：请求重新验证；

附图13-39是说明性原理图，其演示了根据本发明一些优选实施例的特征，其涉及绑定网桥和网络访问验证，涉及优选实施例的详细描述的第II部分，并且更为具体地：

附图13是原理图，其演示了可能的业务窃取：MAC和IP地址欺骗；

附图14是原理图，其演示了示例性网络的概要；

附图14(A)是原理图，其演示了记录增加/删除的通知；

附图14(B)是原理图，其演示了UFD记录的查询/应答；

附图15是原理图，其演示了示例性分组过滤功能；

附图16是原理图，其演示了具有端口标识符标签(Port IdentifierTag)(PIT)功能的转发；

附图17是原理图，其演示了带有PIT的会话标识；

附图18是原理图，其演示了PIT消息格式的示例；

附图19-23是原理图，其分别演示了说明性示例1：步骤1-A到步骤5-A；

附图24-25是原理图，其分别演示了说明性示例1：步骤4-B到步骤5-B；

附图26是原理图，其演示了说明性示例1：威胁1；

附图27是原理图，其演示了说明性示例1：威胁2(步骤1-A到3-A和4-B)；

附图28是原理图，其演示了说明性示例1：威胁2(步骤5-B)；

附图29是原理图，其演示了说明性示例1：威胁2：同时攻击；

附图30是原理图，其演示了说明性示例1：威胁3；

附图31-37是原理图，其分别演示了说明性示例2：步骤1-A到7-A；

附图38是原理图，其演示了说明性示例2：威胁1&2：步骤5-A处的多会话；和

附图39是原理图，其演示了说明性示例2：威胁1&2：步骤7-A的多会话。

附图40-47是说明性原理图，其演示了根据本发明一些优选实施例的特征，其涉及从网络访问验证协议引导组播安全，涉及优选实施例的详细描述的第III部分，并且更为具体地：

附图40是说明性IP组播网络的示意性架构图；

附图41是用于(S1，G)的示例性分组转发路径的示意性架构图；

附图42是用于(S2，G)的示例性分组转发路径的示意性架构图；

附图43是具有共享链路的示例性IP组播网络的示意性架构图；

附图44是(S1，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地址欺骗)的方法。在另一方面，标题为“从网络访问验证协议引导组播安全”的第III部分涉及用于被保护IP组播流的密钥管理。其中，第III部分描述了在第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 xt 』处找到并被整体引入在此用作参考的由A.Yegin等人在2004年9月2日提出的标题为“Bootstrapping RFC3118 Delayed DhcpAuthentication UsingEAP-based Newtork Access Authenticaiton”的因特网草案文档介绍了利用基于EAP的网络访问验证引导RFC3118延迟DHCP验证。其概述了基于EAP的网络访问验证机制可以如何被用于建立本地信任关系并生成可以被用于与RFC3118结合的密钥。

2.一些当前局限性

RFC3118和RFC3115描述了可以如何利用延迟验证协议来验证DHCP/DHCPv6信息，但是其没有描述任何有关配置初始化延迟验证协议所需的共享密钥的内容。另一个方面，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客户端的实体。

尽管出于示例的目，附图1显示了验证器、DHCP服务器和客户端，但是本领域技术人员可以基于公开的内容知道可以根据需要改变其他实施例。例如，其他实施例可以使用多个验证器，多个DHCP服务器和/或多个客户端。

标记为“网络访问验证和DHCP”的附图2有助于演示用于一些优选实施例的一些原理。

尽管在这样的情形下介绍了一些示例性实施例，即其中PANA被用作传送用于网络访问的验证信息的协议，并且EAP被用作由传送网络访问验证信息的协议所传送的实际验证协议，但是其仅仅是一些示例。可以将可以基于这些公开内容所了解的本发明的多种实施例应用于任何提供与PANA和EAP类似功能的协议或协议集，例如作为成功验证和授权的结果，在客户端和验证器之间建立验证会话密钥的功能。作为一些示例，优选实施例的系统和方法可以被用于其中IEEE802.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密钥撤消的消息，并且如果主机配置协议允许，则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 从非易失性存储器中恢复整个状态(方法1)

根据本发明的第一个实施例，第一种方法包括使用非易失性存储器来恢复状态。在该点上，标记为“DHCP服务器重启：方法1：非易失性存储器”的附图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显示了该现有方法的特征。参考附图11，优选地，系统执行下述步骤：

(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)并且重新附接的具有合适授权的主机可以从被验证DHCP服务器自动配置的DHCP选项。

同样如上所述，RFC3315定义了用于IPv6的动态主机配置协议(DHCPv6)。DHCPv6使DHCP服务器能够向IPv6节点传递配置参数，诸如IPv6网络地址。其提供了自动分配可重用网络地址的能力，并提供了附加的配置灵活性。RFC3315还包括用于DHCPv6的延迟认证协议。

同样如上所述，Draft-Yegin-EAP-Boot-RFC3118-00.txt描述了利用基于EAP的网络访问验证引导RFC3118延迟的DHCP验证。其描述了基于EAP的网络访问验证机制可以如何被用于建立本地信任关系和生成可以与RFC3118结合使用的密钥。

另外，被整体引入此用作参考的标题为“Draft Stands for Localand Metropolitan Area Network：Standard for Port based NetworkAccess Control”的IEEE DRAFT P802.1X描述了这样的架构框架，在该框架中进行验证和随后的行为。然而，其没有描述交换机的不同物理端口之间的相互作用。

被整体引入此用作参考的、Rich Seifert所著的JOHNWILEY&SONS公司出版的ISBN0-471034586-5的Switch Book解释了现有的交换机和网桥如何工作。

2.现有方法的局限性

EAP和PANA提供了用于网络访问验证的框架。另外，延迟DHCP验证可以被用于验证DHCP分组。一旦这些过程完成，客户端就可以开始发送和接收分组，诸如例如应用数据。在这一点上，EAP/PANA和DHCP验证不再为这样的分组提供每个分组保护，并且可能存在业务窃取的可能性。

标记为“可能的业务窃取”的附图13显示了可以发生的业务窃取的一些示例。附图的(a)部分显示了简单的访问网络，其中PAA、DHCP服务器、路由器和一些客户端(例如，参见客户端1和攻击者)通过广播LAN-诸如例如广播集线器或同轴电缆以太网-连接到该访问网络。当客户端1正使用被显示为应用服务器(App)的网络服务时，从App服务器发送到客户端1的分组被广播到直接连接到LAN的所有节点。因此，攻击者潜在地可以从App服务器接收分组。另外，攻击者也可能能够通过欺骗源IP地址而将分组发送到App服务器，就好像这些分组被从客户端1发送。这被认为是示例性的“业务窃取”。

另一个方面，(b)部分显示了使用L2网桥作为LAN而代替广播介质的网络。网桥通常不将寻址到客户端1的单播分组发送到除客户端1之外的任何节点。但是，一旦攻击者发送欺骗客户端1的MAC地址的分组，网桥就根据恶意信息更新其转发数据库，并且将随后的寻址到客户端1的分组发送到攻击者，而不是合法的客户端1。因此，业务窃取仍然是可能的。通过使用这些攻击方法，攻击者可以在没有验证的情况下获得网络访问。

因此，需要新的方法来防止恶意攻击者在这些环境中获得非授权的网络访问。

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在表1中显示。

MAC 端口

MAC1 P1

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服务器)向网桥b1发送查询，以询问例如客户端1(MAC1)具有什么端口号。然后，网桥B1检查客户端1(MAC1)的记录。因此，网桥B1应答验证器或动态主机配置服务器。

3.2.3 处罚列表(Penalty List)

第三示例性的新数据库被称为处罚列表(PL)，其包括MAC地址和端口号组成的对的列表，类似于AFD和UFD。优选地，PL中的记录还具有超时信息-诸如例如时间戳或计时器-以处理超时。优选地，PL中的每个记录具有生命周期，其中生命周期可以根据实施方式而被静态地设置为特定长度或动态地变化。当生命周期计时器到期时，记录优选地被自动地从PL中删除。

优选地，MAC地址可以在PL中出现两次或更多次，但是，优选地，MAC地址和端口的结合在PL中是唯一的。示例性的处罚列表显示在表2中。

MAC 端口超时信息

MAC1 P2 30秒后到期

MAC3 P2 10秒后到期

MAC3 P3 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首标。如果分组寻址到访问网络之外的节点，则网桥阻止该分组。否则，如果其寻址到访问网络之内的节点，则网桥可以转发授权类型的分组。例如，一些类型的分组可以被网桥转发。在一些示例性实施例中，授权类型的分组可以包括验证(PANA)消息和DHCP消息。参见例如附图15所示的端口3上的MAC3。

●如果分组完全匹配PL中的记录，则网桥阻止该分组。参见例如附图15中的端口4上的MAC3。

●如果分组在客户端端口被接收，并且源MAC地址在AFD或UFD中的记录中被发现，则网桥阻止该分组。参见例如附图15中端口3上的MAC1。

3.3 端口标识符标签

3.3.1 端口标识符标签的一般描述

在本文档中，网桥的标识符(即网桥标识符)和端口号的组合被称为“端口标识符”。优选地，网桥标识符在用于访问网络的网桥中是唯一的。

在优选实施例中，端口标识符有利地被附加于分组。在本公开中，这被称为“端口标识符标签”(PIT)。如果端口标识符标签特征被使能，则网桥将端口标识符标记到寻址到验证器或DHCP服务器的分组，并转发标记后的分组，而不是原始分组。当网桥接收到从验证器或DHCP服务器所发送的标记后的分组时，网桥查看标签中的端口标识符，并将未标记的分组转发到标签中所指定的端口。

标记为“具有端口标识符的转发”的附图16显示了示例性而非限制性的示例，其使用两个网桥。连接到网桥1的端口1的节点正发送分组到PAA。在该点上，网桥1将端口标识符标签“B1：P1”附加于分组，其表明该分组被从网桥1(B1)的端口1(P1)发送。于是，标记后的分组被发送给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分组，并接收仅经由端口0发送的PIT。另外，如果存在与外部网络的连接，诸如例如因特网，则网关路由器或防火墙优选地应当被配置为丢弃从外部网络发送的和/或发送到外部网络的PIT分组。

提高PIT的可靠性的另一种方法是使用HMAC(用于消息验证的键控散列(Keyed-Hashing for Message Authentication)：基于散列函数的消息验证码)或类似的消息验证技术。

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连接到网桥(B1)的端口1(P1)，并在引导过程中发送第一分组。例如，这可以涉及路由器请求(router solicitation)消息、DHCP发现/请求(discover/solicit)消息或其他形式的消息。

2-A.参考标记为“示例1：步骤2-A”的附图20，因为在AFD、UFD和PL中没有发现源MAC地址(MAC1)，所以网桥将新的记录添加(或可以请求验证器来使网桥添加)到客户端1的UFD中。优选地，网桥(或验证器)启动新的定时器以维持新记录的到期。

3-A.参考标记为“示例1：步骤3A”的附图21，在引导过程中客户端1处理消息交换。这些消息交换可以包括例如IP地址自动配置或DHCP消息和PANA验证消息。优选地，因为客户端1在UFD中有记录，所以允许这些开始网络连接所需要的消息被转发。

4-A.参考标记为“示例1：步骤4A”的附图22，如果客户端1被成功验证，则验证器请求网桥(B1)将UFD中的客户端1记录移动到AFD。

5-A.参考标记为“示例1：步骤5A”的附图23，客户端1开始用于其他应用的消息交换。在这方面，因为客户端1的记录(MAC1：P1)存在于AFD中，因此网桥(B1)优选地转发任何被验证分组。

另一方面，如果客户端1验证失败或如果在上述步骤3-A期间UFD中的客户端1记录到期，则优选地，步骤4-A至5-A被下述步骤4-B到6-B代替：

4-B.参考标记为“示例1：步骤4B”的附图24，客户端1的记录被从UFD中删除；

5-B.参考标记为“示例1：步骤5B”的附图25，可选地，新记录(MAC，P1)被添加到PL中。在这方面，在记录维持在PL中的时间段期间，网桥B1优选地禁止从客户端1转发的和/或被转发到客户端1的任何分组。

6-B.在该步骤中，客户端1可以以步骤1-A再一次试图另一验证，；也可以不如此。

4.1.2 安全考虑

4.1.2.1 威胁1：通过欺骗的业务窃取

参考标记为“示例1：威胁1”的附图26，在一些情况下，在客户端1被验证之后或者在客户端被验证之前紧邻的时刻，在欺骗客户端1的MAC地址MAC1期间，攻击者可以发送分组。例如，这可以为了以下目的而进行，即使网桥根据恶意信息更新其转发数据库并将寻址到客户端1的后续分组转发到攻击者，而非合法的客户端1。这是示例性的业务窃取攻击。

然而，优选地，在记录(例如MAC1，P1)存在于AFD或UFD中的时间段期间，禁止经由除P1之外的端口的来自/到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，P1)的网桥。然而，一旦客户端1得到UFD中的记录，则客户端1可以在不被攻击者影响的情况下试图验证。如果攻击者可以使用多个端口用于DoS攻击，则攻击者可以潜在地用PL中的其他攻击节点填充时间周期。

参考标记为“示例1：威胁2：同时攻击”的附图29，图表(1)显示了来自多个端口的同时DoS攻击。在图表(1)中，攻击者使用端口P2、P3和P4，并尝试反复发送欺骗分组到网桥。在时间0处，P2处的节点发送分组，并且获得UFD中的记录。因此，其防止端口P1处的受骗者经由网桥发送分组。UFD中的攻击记录在时间1处到期，但是P3处的另一攻击节点向网桥发送分组，并获得UFD中的记录。该记录在时间2处到期，然而，P4处的再一节点获得UFD中的记录。当该记录到期时，第一节点P1重新被使能以发送分组。如图所示，这些步骤可以被重复以创建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的记录，因此其生命周期提高两倍。因此，P1处的合法节点有机会在时间4和6以及在时间7和9之间将分组发送到网桥。

在其他实施例中，PL实现方案的其他可能扩展可以包括，在MAC地址和端口的相同组合被重复添加到PL时以增长的比率或指数形式地提高PL记录的生命周期。这使本部分所描述的DoS攻击更加不可行。然而，其可能导致使另一类型的DoS攻击更容易。在这方面，如果攻击者和受骗者使用相同的端口P1，则攻击者可以试图将MAC地址MAC1多次从P1添加到PL。在此之后，受骗者可能试图将MAC地址为MAC1的节点连接到端口1，但是因为PL中的记录(MAC1，P1)具有指数级大的生存期，所以其可能失败。为了防止后一种类型的DoS攻击，适度的时间上限会对这样的指数级增长是有用的。

4.1.2.3 威胁3：具有验证的DoS攻击

参考标记为“示例1：威胁3”的附图30，考虑其中第一用户“用户1”使用节点“客户端1”而第二用户“用户2”使用节点“客户端2”的情况。如图所示，客户端1连接到P1，并且客户端2连接到P2。在该示例中，每个用户，用户1和用户2在验证器上具有自己的账户。为了防止用户1连接到网络，攻击者用户2可以将客户端2连接到网络上，以冒充客户端1的MAC地址。如果用户2验证失败，则情况类似于上一部分所描述的威胁2的情况。然而，此时，因为用户2在验证器上具有有效账户，所以用户2能够利用用户自己的用户凭证(credential)而被验证。因为使用用户2的凭证来验证客户端2，所以在AFD中创建客户端2的记录。相应地，客户端1因此不能连接到网桥B1。为了防止此类型攻击，网络管理员可以撤销有错误行为的用户2的凭证。可选地，管理员可以配置验证器，使得只有用户1的凭证可以被用于MAC1的验证。

在一些实施例中，验证器可以知道客户端的端口标识符，对于验证器更为灵活的配置是可能的。例如，参见下面的4.2.2.3部分的最后所列出的示例。

4.2 第二实现方案示例

4.2.1 第二示例纵览

根据第二阐释性实施例，系统可以使用AFD、PIT，并且可选地还使用PL。在优选实施例中，系统执行下述内容中至少一部分，优选为全部：

1-A.参考标记为“示例2：步骤1-A”的附图31，在这样的示例性环境下，客户端(客户端1)开始连接到访问网络。如图所示，客户端1连接到网桥(B1)的端口1(P1)，并且在引导过程中发送第一分组。该消息可以是路由器请求(router solicitation)消息、DHCP发现/请求(discover/solicit)消息或者其他形式的消息。

2-A.参考标记为“示例2：步骤2-A”的附图32，因为在AFD和PL中没有发现源MAC地址(MAC1)，所以网桥将PIT附加到从客户端1发送的分组，并且将其转发到PIT节点表中所发现的目的节点。如附图32的示例所示，因为原始分组的目的地址是广播地址，因此网桥将分组发送到PAA和DHCP服务器。如上所述，其他实现方案也可以用于广播分组。

3-A.参考标记为“示例2：步骤3-A”的附图33，DHCP服务器向客户端1发送响应，附加从请求分组中所复制的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，如果客户端1被成功验证，则验证器请求网桥(B1)为客户端1将新的记录添加到AFD中。

7-A.参考标记为“示例2：步骤7-A”的附图37，客户端1开始用于其他应用的消息交换。在这方面，因为客户端1的记录(MAC1：P1)在AFD中存在，因此网桥(B1)转发任何被验证的分组。

在一些优选实施例中，如果客户端1在上述步骤5-A中未能通过验证，则验证器可以请求网桥为客户端1将新的记录添加到PL中。

4.2.2 安全考虑

4.2.2.1 威胁1：通过欺骗的业务窃取

参考附图38-39，在一些情况下，在客户端1已经被验证之后或在客户端被验证之前紧邻的时刻，攻击者可以发送冒用客户端1的MAC地址MAC1的分组。这可以被完成，以便使网桥根据恶意信息更新其转发数据库并将后续的寻址到客户端1的分组转发到攻击者，而非合法的客户端1。但是，优选地，验证器和DHCP服务器不仅通过MAC地址、而且通过端口标识符来区分会话。相应地，它们不被从不同端口所发送的冒用分组所迷惑。参见标记为“示例2：威胁1&2：步骤5-A处的多会话”的附图38。另外，一旦在步骤6-A中客户端1被验证并且客户端1的记录被添加到AFD中，就禁止经由除P1之外的端口的来自/到MAC1的任何分组交换。因此，该类型的攻击会失败。参见标记为“示例2：威胁1&2：步骤7-A”的附图39。

4.2.2.2 威胁2：没有验证的DoS攻击

仍然参考附图38-39，在一些情况下，攻击者可以在客户端1第一次连接到网络之前发送冒用客户端1的MAC地址MAC1的分组。尽管这对于上述使用UFD的实现方案而言可能有问题，但是这对于上述使用PIT的实现方案而言不存在问题。

因为验证器和DHCP服务器可以区分多个会话，所以在攻击者发送冒用分组期间，客户端1可以总是尝试其验证。参见标记为“示例2：威胁1&2：步骤5-A处的多会话”的附图38。一旦在步骤6-A中客户端1被验证并且客户端1的记录被添加到AFD，就禁止经由除P1之外的端口的来自/到MAC1的任何分组交换。相应地，因此，这样的攻击失败。参见标记为“示例2：威胁1&2：步骤7-A”的附图39。

4.2.2.3 威胁3：具有验证的DoS攻击

现在参考这样的示例性情况，其中a)用户“用户1”使用节点“客户端1”，而用户“用户2”使用节点“客户端2”；b)客户端1连接到端口P1，客户端2连接到端口P2；以及c)用户1和用户2中每一个在验证器上具有自己的账户。为了防止用户1连接到网络，攻击者用户2可以将客户端2连接到网络上，冒充客户端1的MAC地址。如果用户2验证失败，则情况类似于前一部分所描述的威胁2的情况。然而，此时，因为用户2在验证器上具有有效账户，所以用户2可以使用用户自己的用户凭证被验证。另外，因为利用用户2的凭证验证客户端2，所以在AFD中创建客户端2的记录。因此，客户端1不能连接到网桥B1。

为了防止此类型的攻击，网络管理员可以撤销有错误行为的用户2的凭证。可选地，管理员可以配置验证器，使得只有用户1的凭证可以用于MAC1的验证。

PIT支持验证器的更灵活的配置。例如，因为验证器知道每个消息的端口标识符，所以可以利用端口标识符指定限制。例如，一些或全部下述规则可以在一些示例性实施例中被实现：

●如果验证请求来自端口B1:P2，则拒绝MAC1的验证请求。例如，该规则在上述情况下是有用的。

●如果凭证来自除端口B1:P1之外的其他端口，则不接受用户1的凭证。如果用户1在特定端口B1:P1上使用用户的网络节点，则该规则可以是有用的。因此，即使某人窃取了用户1的密钥，攻击者也不能在除端口B1:P1之外的其他端口使用该密钥。

●如果请求来自除端口B1:P1之外的其他端口，则拒绝MAC1的验证请求。假设网络节点连接到端口B1:P1，并且节点在多个用户之间共享。优选地，每个用户具有使用该节点的账户。用户可以使用该节点，而攻击者不能从除端口B1:P1之外的其他端口进行DoS攻击。

●允许任何来自端口B1:P1的有效凭证，而在除B1:P1之外的节点上仅仅允许有限的凭证和MAC的组合。该规则可以在下述情况下是有用的，即端口B1:P1位于安全房间，而其他端口位于非安全的开放空间。

第III部分：来自网络访问验证协议的引导组播安全

1.背景信息

1.1.参考文献

下述一般背景技术参考文献被引入此用作参考。

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 AuthenticationProtocol(MLDA)”，Internet-Draft，draft-hayashi-mlda-02.txt，仍在进行中，2004年4月(此后被称为【MLDA】)。

4、M.Christensen等，“Considerations for IGMP and MLDSnooping Switches”，Internet-Draft，draft-ietf-magma-snoop-11.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 ofKeys(KINK)”，Internet-Draft，draft-ietf-kink-kink-05.txt，仍在进行中，2003年1月(此后被称为【KINK】)。

9、T.Hardj ono和B.Weis，“The Multicast Group SecurityArchitecture”，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 IPVersion6(IPv6)”，RFC 2461，1998年12月(此后被称为【RFC2461】)。

12、H.Schulzrinne等，“RTP：A Transport Protocol for Real-time Applications”，RFC 3550，2003年7月(此后被称为【RFC3550】)。

13、B.Aboba等，“Extensible Authentication Protocol(EAP)”，RFC 3748，2004年6月(此后被称为【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 RoutingProtocol”，RFC 1075，1998年11月(此后被称为【RFC1075】)。

16、A.Ballardie，“Core Based Trees(CBT version2)MulticastRouting”，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 forNetwork Access(PANA)”，Internet-Draft，draft-ietf-pana-pana-04.txt，仍在进行中，2004年5月7日(此后被称为【PANA】)。

19、IEEE局域网和城域网标准，“Port-Based Network AccessControl”，IEEE标准802.1X-2001(此后被称为【802.1X】)。

1.2 术语

在本公开中，术语“组播路由器”包括例如能够转发IP组播分组的路由器。在一些示例中，在相同IP链路中存在多个IP组播路由器。

在本公开中，术语“组播接听者”包括例如期望接收IP组播分组的主机或路由器。

1.3 IP组播概述

附图40显示了IP组播网络的示例。在该阐释性示例中，S1和S2是始发目的为网络上特定组播地址GIP的组播分组的节点。R1、R2和R3是能够转发IP组播分组的路由器。另外，D1、D2和D3是作为IP组播分组的最终接收者的节点。在该阐释性示例中，假设每个链路都是点到点链路。

附图41-42分别显示到附图40中所示网络中组播地址G的始发于S1和S2的组播分组的IP组播分组转发路径的示例。组播路由表由每个路由器维护，以将组播分组转送到接听者。组播路由表可以被静态、动态或静态和动态地构建。组播路由协议-诸如距离矢量组播路由协议(参见【RFC1075】)、基于树(Based Tree，参见【RFC2189】)和PIM(协议独立组播)(参见【RFC2362】)-可以被用于动态构建组播路由表。根据使用的组播路由协议，所得到的组播转发路径可以是不同的。在这些示例中，路由器R3需要创建每个组播分组的多个副本，以将其转发到用于组播地址G的多个下一中继(hop)节点。

附图43显示了包括共享链路的IP组播网络的阐释性示例。如图所示，S1和S2是始发目的为网络上特定组播地址G的IP组播分组的节点。R1、R2和R3是能够转发IP组播分组的路由器。另外，D1、D2和D3是作为IP组播分组的最终接收者的节点。

附图44显示了始发于S1的到组播地址G的组播分组的IP组播分组转发路径的示例。与前面的示例不同，此处路由器R1不需要创建组播分组的多个副本以转发该分组。

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)组播业务量的组播接听者N1和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探听的情况下，交换机将转发任何被允许转发的链路层组播数据帧到所有端口，包括没有组播接听者的端口，这可能导致低效的资源使用。

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 从网络访问验证引导MLDA

使用MLDA的一个问题是由于使用组播接听者的静态密码作为MLDA中PAP和CHAP的共享秘密。一种解决方案是在MLDA中使用动态生成的共享秘密用于PAP和CHAP。共享秘密优选地具有生命周期，使得秘密仅仅在有限时间内有效。在本公开中，基于用于MLDA中的共享秘密的组播接听者和组播路由器之间的安全关联被称为MLDA安全关联或MLDA SA，并且共享秘密被称为MLDA密钥。在优选实施例中，以下介绍了用于存档MLDA密钥的动态生成的两个示例性方法。

在第一方法中，从通过使用网络访问验证协议、诸如PANA(参见【PANA】)和IEEE802.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和IEEE802.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密钥的情况下的组播IPsec密钥分层结构。

密钥推导模型不仅可以用于以组播Ipsec保护MLD，而且还可以用于以组播Ipsec保护其他组播通信协议，诸如例如IPv6邻元素发现(Neighbor Discovery)(参见【RFC2461】)和RTP(参见【RFC3550】)。

该示例性方案非常有效，因为一旦用于网络访问验证的AAA过程完成，就不需要附加的用于MLDA的AAA过程。因此，其提供了在前面的第二部分所描述的问题4的解决方案。

在各种实现方案中，本领域技术人员可以基于本公开适当地实现用于每个可能的组播密钥管理协议的MKD密钥推导算法。

附图55显示了该方法的功能模块。如图所示，EAP-S(EAP服务器)是EAP方法的端点。AA(验证代理)是网络访问验证协议的验证器(例如IEEE 802.1X验证器或PANA代理)。R是组播IPsec接收者。S是组播IPsec发送者。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，组播接听者被验证和被授权用于网络访问。

因此，该两种方法可以有利地提供第二部分的问题1的解决方案。

如果通过使用独立于MLD或MLDA而提供的信令机制，组播接听者的组播业务量过滤信息(诸如例如被验证组播群地址和/或被验证组播源地址)被安装到链路层交换机，并且使能将后续的被验证组播业务量传送到链路层，则MLD或MLDA可以不被用于组播接听者和组播路由器之间。

3.4 从网络访问验证引导安全组播应用会话

如上述第二部分针对问题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和IEEE802.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)支持该结构的结构、材料或行为未被叙述。在本文中以及本申请的过程中，术语“本发明”或“发明”可以被用于指本发明中的一个或多个方面。语言本发明或发明不应该被不适当地解释为临界状态的标识，不应该被不适当地解释为应用于所有方面或者实施例(即，应当理解，本发明具有大量方面和实施例)，并且不应该被不适当地解释为限制本申请或权利要求的范围。在本文中以及本申请的过程中，术语“实施例”可以被用于描述任何方面、特征、过程或者步骤、其任何结合和/或其部分等等。在一些示例中，各种实施例可以包括重叠特征。在本文中，可以使用下述缩略语：含义为“举例而言”的“例如”，含义为“适当注意”的“注意”。

Claims

1.一种用于绑定动态主机配置和网络访问验证的方法，包括：

提供网络访问验证器以验证至少一个客户端设备；

提供动态主机配置服务器以为客户端设备动态分配IP地址；

在验证会话或动态主机配置会话丢失时，维持所述至少一个客户端设备和所述网络访问验证器之间的验证会话与所述动态主机配置服务器和所述至少一个客户端设备之间的动态主机配置会话的同步。

2.一种用于绑定动态主机配置和网络访问验证的系统，包括：

用于验证至少一个客户端设备的网络访问验证器；

被配置用以为客户端设备动态分配IP地址的动态主机配置服务器；

其中所述系统被配置为以在验证会话或动态主机配置会话丢失时维持同步的方式来维持所述至少一个客户端设备和网络访问验证器之间的验证会话与所述动态主机配置服务器和所述至少一个客户端设备之间的动态主机配置会话的同步。

3.如权利要求2所述的系统，其中所述网络访问验证器使用验证协议来承载网络访问验证信息。

4.如权利要求3所述的系统，其中所述验证协议包括作为用于承载网络访问验证信息的协议的PANA。

5.如权利要求4所述的系统，其中EAP被用作验证协议，其由用于承载网络访问验证信息的协议承载。

6、如权利要求2所述的系统，其中所述动态主机配置服务器是动态主机配置协议(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所述的系统，其中基本IPsec安全关联(SA)形成组安全关联，其中组安全关联是组播接听者和组播路由器之间的一到多或多到多关联。

71.如权利要求70所述的系统，其中所述系统被配置，使得使用组播密钥管理协议来自动创建IPsec组安全关联。

72.如权利要求55所述的系统，进一步包括链路层交换机，其中所述交换机支持将第二层组播帧复制到一组有限的端口，以在共享链路上提供组播业务量的访问控制。

73.如权利要求72所述的系统，其中组播路由器被配置为以以下方式控制链路层交换机，即组播分组被转发到这样的端口，即在所述端口处存在从其接收密码有效的消息的组播接听者。

74.如权利要求55所述的系统，其中所述系统被配置为包括更高层每个分组的安全，以防止组播业务在共享访问链路上自由采用。

75.如权利要求74所述的系统，其中提供机制以自动建立用于具有组播密钥的安全应用会话的安全关联。

76.如权利要求75所述的系统，其中所述机制包括引导被用于建立安全应用会话的组播密钥管理协议。

77.如权利要求75所述的系统，其中所述机制包括在网络访问验证协议上承载应用会话密钥。

78.如权利要求77所述的系统，其中所述系统被配置，使得在网络访问验证成功完成之后，验证代理从密钥分配中心获得应用会话密钥的副本，并且在网络访问验证协议上将密钥传送到组播应用接收者，同时组播应用传送者也从所述密钥分配中心接收所述密钥的副本，从而所述组播应用传送者和组播应用接收者可以以所述更高层每个分组的安全而传送和接收组播应用业务量。