用于避免确定性清空安全流量的装置和方法
技术领域
本公开总体涉及前向纠错(FEC，forward error correction)高速通信链路上的安全有效载荷传输。
背景技术
光密集波分复用(DWDM，dense wavelength division multiplexing)网络通常使用具有非常低的误码率(BER，bit error rate)水平的隐藏错误底限(error floor)的现代迭代解码的前向纠错(FEC)编解码器。当以经认证的加密为特征的安全传输被添加到这类网络中时，存在后FEC错误引起错误的认证失败(AF，authentication fail)事件的可能性。这些错误的AF事件是FEC错误的结果，并且不表示非认证流量。
这类高吞吐量相干光传输系统采用具有迭代软解码的现代FEC编解码器，以便允许在高水平的前FEC BER下进行操作。与具有可预测的且越来越陡峭的BER“瀑布式”曲线的Reed-Solomon FEC编解码器不同，这些现代编解码器通常展现以下错误底限，该错误底限通常设置在较低的后FEC BER(通常低于10-15的BER)处。
在迭代解码的FEC编解码器中，错误底限可以由“混淆”解码器的错误模式产生。这类错误模式可以被称为“陷阱集”或“停顿模式”，因为解码器看起来是“停顿”的，即被锁定而没有在迭代中进一步减少位错误。
长期无错误操作实际需要的后FEC BER明显低于能够实际测量和验证的BER(例如，低于10-18，随着吞吐量的增加而进一步降低)。因此，因为错误底限实际可能始于例如10-16，所以在使用经典系统裕度分配时，在现场操作期间可能会出现零星的后FEC错误(在较早的文献和标准中称为背景块错误)的情况。
附图说明
结合附图，从下面的详细描述中，将更充分地理解和领会本公开，其中：
图1是根据示例实施例构造和操作的具有前向纠错(FEC)解码器和认证引擎的接收器系统、以及高速网络中的几个数据帧的简化框图；
图2是根据示例实施例构造和操作的解码器的第二实施例。
图3是描述图2实施例的清空(blanking)判定状态机的流程图；并且
图4是图2的实施例的替代的框图。
具体实施方式
概述
独立权利要求描述了本公开的各个方面，并且从属权利要求描述了优选特征。一个方面的特征可以单独地或与其他方面结合地应用于每个方面。
在一个实施例中，描述了一种装置、方法和系统，实施例装置、方法包括：在输入接口处接收数据帧的流，数据帧是以下各项中的一者：数据帧包括安全帧，或数据帧被包括在安全帧中，其中，安全帧包括有效载荷数据；通过前向纠错(FEC)解码器对数据帧执行前向纠错；在缓冲器和清空器(blanker)引擎处缓冲接收到的数据帧并且建立接收到的数据帧的完整安全帧；在认证引擎处基于认证错误的频率来确定是否抑制采取后续动作，其中，要采取或抑制的后续动作在采取时是对包括发生认证错误的数据帧的一个或多个安全帧的有效载荷数据采取的。还描述了相关的装置、方法和系统。
示例实施例
图1是根据示例实施例构造和操作的接收器系统100的简化框图。接收器系统100包括前向纠错(FEC)解码器110、认证引擎(AUTH)120和密码解密器(未示出)。接收器系统100位于例如光传输网络(OTN，optical transport network)中。在图1中几个OTN帧(下文中称为“数据帧”)被描绘为框130A-F、140和150A-B。所述数据帧130A-F、140和150A-B表示处于接收器系统100的各种处理状态的数据帧的连续流。数据帧130A-F、140和150A-B携带安全传输的客户端数据流量(例如，在物理编码子层(PCS，Physical Coding Sublayer)生成的块流中编码的以太网分组，该块流映射到数据传输帧的有效载荷部分中)。
在数据传输流是具有认证的安全传输流时，完整性检查值(ICV，integrity checkvalue)字段被上游发送器附加到安全帧(例如安全帧160)的有效载荷。如本领域中已知的，向数据传输流中添加安全帧通常需要数据传输流中的数据帧与安全帧之间的固定“相位关系”，以及能够用于安全帧的开销的未使用的数据帧开销。还应注意，所述有效载荷可以被加密。安全帧本身可以包括一组数据帧，例如，安全帧160被描绘为包括数据帧140和150A-B。替代地，几个安全帧可以被打包到单个数据帧的有效载荷区域中。例如，数据帧130D可以包括几个这样的安全帧(未示出)。ICV字段使得能够在接收器系统100处检查并且验证图1中由框130A-F、140、150A-B表示的各种数据帧的发送者的真实性(authenticity)。认证引擎120从数据帧重新计算ICV，并且将重新计算的ICV与接收到的ICV(即，在上游发送器处计算出的ICV)进行比较。当检测到重新计算的ICV和接收到的ICV之间的ICV不匹配时，认证引擎120调用认证失败(AF)事件。
应当理解，先前的描述适用于如上所述的数据帧的连续流，如在OTN中，或替代地例如，在同步数字体系(SDH，Synchronous Digital Hierarchy)或同步光网络(SONET，Synchronous Optical Networking)中。这样的连续流是在与离散分组流相比的情况下提及的，该离散分组流在分组之间具有可变大小的间隙。这样的离散分组流通常依赖于基于每个分组应用的安全分组协议，例如，媒体访问控制安全(MACsec)和互联网协议安全(IPsec)协议。在MACsec和IPsec协议中，认证失败的分组可以被丢弃或删除。在连续数据流中，数据帧可以被修改，但不被丢弃或删除。下面描述的用于避免AF事件之后的后续动作的实施例也可以应用于分组安全协议中。
框130E、140、150A-B和130F可以被称为“接收到的”帧，因为它们被描绘为已经由接收器系统100接收或正在由接收器系统100接收，但是尚未被接收器系统100处理。框130D可以被称为“解码的”帧，因为它已经被FEC解码器110解码，但是尚未被认证引擎120认证。框130A-C可以被称为“认证的”帧，因为它们已经被认证引擎120认证。
想要识别用于对网络流量中的数据传输进行加密和认证的密码密钥的入侵者可能执行暴力攻击(该暴力攻击需要执行大量尝试以将恶意分组引入数据传输流)作为向网络提供正确密码密钥的尝试。假设FEC解码器110中的解码失败在正常操作条件下最多零星地发生(通常低于可以在数周内测量的阈值)。然而，这样的解码失败通常引起在FEC解码失败之后在认证引擎120处的AF和后续清空(在下面解释)。如果接收器系统100被构造为接受由零星的FEC解码失败引起的零星的认证失败(AF)事件，则由此产生以低比率发生对接收器系统100的成功攻击的可能性。
在下文中可以将其中发生错误并且FEC解码器110不能正确解码的数据帧(例如，数据帧140)称为“不可校正数据帧”(UCF，uncorrectable data frame，如下面将描述的)。UCF也可以称为“不可校正块”或“不可校正帧”或“不可校正字”。
因此，如果将AF比率保持在这样的阈值之下(或者相应地，如果UCF的比率保持较低)，则在网络保护系统检测到意外数量的AF并且执行适当的后续动作(如下面将描述的)并警告网络管理员可疑数据传输流之前，攻击者可能仅能够注入几个帧/分组。
清空导致受影响的数据帧(例如，数据帧140、150A-B)的有效载荷被替换数据所覆盖，例如固定模式，例如全‘1’或全‘0’(即，‘11111111...’或‘00000000...’)，其中受影响的数据帧在统计上与该替换数据无关。连续数据传输流中的有效载荷的这种替换保护了数据传输流的完整性。这样，有效载荷内传输的信息将完全损坏。通常，在这种情况下，接收客户端层端点(例如交换机)将检测到无效模式并且触发警报。警报的触发还可以引起保护切换(即，切换到受保护的流量)的触发。
接收器系统100包括图1中未示出的其他标准组件，例如本领域中已知的存储器、处理器和存储装置。接收器系统100还包括本领域已知类型的输入接口和输出接口，它们分别用于接收由框130E-F、140、150A-B描绘的输入数据传输数据帧的流，以及输出由框130A-C描绘的解码和认证的有效载荷。
包括在接收器系统100中的FEC解码器110用于对数据传输流(即，帧130A-F、140、150A-B)上的所谓“现代”FEC码进行解码。如本领域中已知的，现代FEC编解码器可以包括但不限于低密度奇偶校验(LDPC)码、turbo码以及在高速网络通信中使用的其他迭代解码的FEC编解码器。认证引擎120接收包括认证和加密的客户端数据的FEC解码帧。例如，解码的数据帧130D被描绘为正在输入到认证引擎120中，已经从FEC解码器110输出。不会影响本公开的其他处理和操作(例如，解密)也可以在接收器系统100中发生，并且因此，在图1中用虚线示出了指示接收器系统100内的数据流的箭头。认证引擎120认证所述帧(例如，解码的帧130D)。认证失败(AF)可以是由于意外的损坏(例如，可以在不正确解码的数据中检测到AF)或是由于故意的数据操作(例如，作为对图1的系统攻击的一部分被恶意注入或覆盖的数据，如上所述)。
在用于高速联网的系统(例如，接收器系统100)中，FEC解码器110和认证引擎120通常在硬件中实现并且由硬件执行。适用于实现本文所描述的实施例的本领域已知的硬件的示例可以在思科技术公司的Loprieno等人的美国专利8,942,379中找到。
数据帧(例如，几个数据帧130A-F、140、150A-B)由系统处理，这将在下面的非限制性示例中进行描述。接收到的帧130E-F被描绘为不具有FEC解码器110将检测到的任何错误。类似地，解码的帧130D和认证的帧130A-C被描绘为不具有FEC解码器110已经检测到的任何错误。另一方面，用上覆“X”描绘的接收到的帧140具有将由FEC解码器110检测到的错误。接收到的帧150A-B不(必然)具有将由FEC解码器110检测到的错误。FEC解码器110通常将对数据帧(例如，接收到的数据帧130E-F和150A-B)进行解码。FEC解码器110通常还能够检测和校正例如接收到的帧140中的错误。
在罕见情况下，FEC解码器110无法校正数据帧中的错误，例如，接收到的帧140中的错误。在大多数这样的情况下，FEC解码器意识到它无法正确解码接收到的数据帧。
FEC解码器110不能正确解码的错误(例如，接收到的帧140中的错误)引起AF。AF进而引起后续操作，如下面将描述的。后续动作使得包括被不正确解码的数据帧的数据的(一个或多个)安全帧中的有效载荷数据被清空。在本示例中，接收到的帧150A-B在图1中用散列模式(hash pattern)描绘，并且包括在安全帧160中。散列模式指示以下内容：虽然接收到的帧150A-B不(必然)具有FEC解码器110将不能校正的错误，但是作为其安全帧160的接收到的帧140中的FEC错误所引起的后续动作，接收到的帧150A-B的有效载荷仍将被清空。
有理由怀疑，包括有效载荷已经被清空的安全帧160的数据帧140、150A-B至少有可能已经被恶意注入了数据传输流。因此，通过清空包括具有帧140的安全帧160的数据帧140、150A-B来提供针对这种攻击的保护水平。
为了克服由偶然发生的“随机”后FEC错误引起的AF导致的有效载荷的损失，与可能已经引入恶意有效载荷的攻击相反，在实施例中，当FEC解码器110处理诸如具有不可校正错误的数据帧140之类的数据帧时，认证引擎120可以从FEC解码器110接收UCF通知消息180。接收到通知消息180使得认证引擎120能够将UCF事件(即，FEC解码器110将数据帧140标识为具有UCF)与AF的检测以及认证引擎120对安全帧160的后续清空相关联。
在一些实施例中，当认证引擎120将UCF事件与AF事件相关联时，当UCF被分类为“罕见的”时，针对安全帧中的一些AF事件的后续动作可以被抑制，其中“罕见的”UCF被定义为符合统计假设或光链路的错误模型。统计(错误建模)假设描述了光链路上的“错误生成”机制。它允许测试假设的机制是否可能产生根据经验观察到的错误模式。例如，如果假设链路以非常低的概率p生成独立的单个错误，则观察到N个相邻错误的可能性pN非常低。然后，观察到N个相邻错误可以用来确定这样的错误很可能不是由信道引起的，而是由另一种机制(例如，入侵)引起的。然而，当假设链路上的错误机制生成突发错误时，实际上预期会相邻地出现几个错误，并且观察相邻错误并不是非常罕见的事件。
也就是说，可以抑制单个UCF(或AF)，并且有效载荷将不被清空。另一方面，假设攻击者可能已经注入了恶意流量，则大量连续或几乎连续的UCF将被清空。
现在参考图2，图2是根据本公开的实施例构造和操作的接收器系统100的第二实施例。接收器系统100现在被实现为具有清空判定状态机。在第一实施例中，如上所述，基于UCF来做出清空帧的决定。在当前描述的实施例中，基于时间AF事件到达模式来做出清空帧的决定。清空判定状态机将在下面参考图3更详细地描述。在FEC解码器110和认证引擎120之间已经添加了控制器210。控制器210具有两种状态，后续动作(CA，consequent action)待命220和CA解除待命230。控制器210包括饱和计数器，表示为guardCounter，其对安全帧进行计数。
当FEC解码器110检测到UCF事件时，控制器210从FEC解码器110接收通知(例如，图1的通知消息180)，并且相应地，使得能够抑制作为由罕见UCF事件引起的后续动作的清空。另一方面，当认证失败是由高UCF比率引起的时，或者当认证失败是由一些非UCF相关原因引起的时，控制器210将使得接收器100进入在需要时执行清空作为后续动作的模式中。
可以实现在较大时间间隔内实现的“泄漏桶(leaky bucket)”阈值检测器。实际上，时间间隔可以被测量为由FEC解码器110解码的帧的数量。如本领域中已知的，实现泄漏桶模型的方法基于这样的思想，在以下任一情况下，具有泄漏的桶将溢出：向桶中倒入水的平均速率超过桶泄漏的速率；或者一次性倒入比桶的容量更多的水(假设桶以恒定的速率泄漏)。
可以在图2的系统中将UCF比率阈值设置为在特定时间间隔内预期的UCF事件或AF事件的最大可接受数量(例如，但不限于前述的一般性，每两周三个UCF事件)。每当UCF比率低于设置的UCF比率阈值时，控制器210使得抑制(作为由UCF引起的后续动作的)对包括具有UCF事件的数据帧(例如，数据帧120)的安全帧的清空。在当前情况下，如果UCF错误的比率保持较低，则如上所述，使用“泄漏桶”阈值检测器。具体而言，可以忽略UCF错误，并且抑制后续动作(清空)。然而，如果UCF错误的比率变得较高，则后续动作不被抑制。
现在另外参考图3，图3是描绘图2的实施例的清空判定状态机300的流程图。图3的清空判定状态机300由控制器210执行。当控制器210处于CA待命状态220时，后续动作(即，有效载荷清空)将在AF时发生(框310)。在处于CA待命状态220时，当发生认证失败(即，检测到UCF)时，执行后续动作(清空)。重置饱和计数器guardCounter，并且维持CA待命状态220(框320)。当饱和计数器guardCounter超过时间间隔(在图3中表示为guardInterval)时，激活CA解除待命230(框330)。
当控制器210处于CA解除待命状态230时，抑制后续动作(即，有效载荷清空)(框350)。在处于CA解除待命状态230时，当发生认证失败(即，检测到UCF)并且guardCounter超过guardInterval时，抑制后续动作(清空)，并且维持CA解除待命状态230(框360)。然而，当guardCounter小于或等于guardInterval并且发生认证失败(即，检测到UCF)时，重置guardCounter，并且激活CA待命状态220(框370)。换句话说，控制返回到框310。
上面参考图1和图2描述的实施例包括FEC解码器110(图1和图2)知道实施例，即，FEC解码器110(图1和图2)对UCF的通知使得能够区分由后FEC解码器140(图1和图2)错误引起的认证失败和“真”认证失败。饱和计数器guardCounter的使用是未清空FEC(或AF)错误的最小间隔时间。
现在参考图4，图4是图2的实施例的替代的框图。图4的实施例被设计为接收FEC解码的数据帧，例如数据帧430、440、450和460。FEC解码的数据帧440、450和460被示出为包括在安全帧470中。
当认证引擎120接收到FEC解码的数据帧430、440、450和460并且知道例如数据帧440中的认证失败(例如上面参考解码的数据帧140描述发生的认证失败)时，认证引擎120将认证失败通知401发送给清空判定状态机300。
在这种情况下，并且在由UCF事件驱动清空状态机的实施例中，认证引擎120还向接收器系统100中包括的缓冲器和清空器引擎410发送安全帧开始(SOSF，start ofsecurity frame)通知420。为了完整性起见，数据帧480被描述为与SOSF 420并行地被发送到缓冲器和清空器引擎410。数据帧480可以是未示出的安全帧的开始，该安全帧可以例如还包括数据帧430。缓冲器和清空器引擎410缓冲接收到的数据帧以便构建完整安全帧(例如，安全帧470)，并且在必要时清空数据帧(例如，包括安全帧470的数据帧440、450和460)的有效载荷，如上所述。具体地，在从清空判定状态机300接收到doBlank信号403时，缓冲器和清空器引擎410清空数据帧440、450和460的有效载荷。
有效载荷清空可能对嵌入式客户端数据结构产生负面影响(甚至破坏)。对客户端嵌入式数据结构的这些影响可能进而引起客户端处的链路故障。因此，在本公开的另一实施例中，可以延迟清空，直到从传输容器解映射客户端数据结构为止。一旦发生解映射，则可以用客户端兼容的方式执行清空。例如，替代清空具有跟随UCF(例如，数据帧440)的几个数据帧的安全帧的有效载荷，可以用良好定义的“空闲”数据帧来替换几个解映射的客户端数据结构的有效载荷。也就是说，可以用一方面无意义但另一方面不会对客户端数据结构造成任何损坏的数据来替换原本将被清空并且随后损坏客户端侧数据错误的有效载荷。
例如，在被映射到OPU4(光有效载荷单元4)的100G以太网物理编码子层(PCS)块流中携带的客户端数据帧，在数据帧的流包括UCF的情况下，清空可以推迟到客户端已经从其OPU4容器(或本领域已知的其他适当的光传输网络数据结构)解映射之后。在这种情况下，可以用空闲块替换接收到的PCS块中的有效载荷。这种替换旨在避免引起由数据结构损坏引起的客户端侧故障。
用空闲帧替换数据帧会使得有效载荷与以太网分组间间隙(“IDLE”)混淆。这样，接收客户端层端点将不会检测到任何问题，因为它继续接收正确的以太网流量。在这种情况下，接收客户端层端点将不采取任何动作(即，触发警报)。
应当理解，如果需要，本公开的软件组件可以用ROM(只读存储器)形式实现。如果需要，通常可以使用常规技术在硬件中实现软件组件。还应当理解，软件组件可以例如被实例化为计算机程序产品，或被实例化在有形介质上。在某些情况下，可以将软件组件实例化为可由适当的计算机解释的信号，尽管在本公开的某些实施例中可能排除这样的实例。
应当理解，为了清楚起见，在分离的实施例的上下文中描述的实施例的各种特征也可以在单个实施例中组合提供。相反，为了简洁起见，在单个实施例的上下文中描述的实施例的各种特征也可以分离地或以任何合适的子组合来提供。
本领域技术人员将理解，本文描述的实施例不限于上文已经具体示出和描述的内容。相反，实施例的范围由所附权利要求及其等同物限定。
