【24h】

Protocol Codesign

机译:协议代号

获取原文

摘要

This afternoon I’m going to talk to you about some work that we’re doing on protocol design. This is actually Hassen Saidi’s work; he spoke a little about this at the workshop here a couple of years ago1 and since then there’s been quite a bit of progress. There are many challenges in the design of protocols; both the ones that we have today, and the ones that we need to evolve in the future. The conversation here this morning clearly identified those challenges, so I don’t think I will preach here. But protocols are changing, and they’re changing form in a couple of ways. They’re changing by moving from the traditional place where one would do a protocol – from the network layer into the application layer – because the applications themselves are changing. Also our expectations of the technology that we develop for security applications has changed. For example, now we talk about intrusion tolerance; it’s not enough to build something that is secure, I also want to build it in such a way that even if attackers succeed in penetrating it it will still provide some level of service. In that one might see the influence of fault tolerance: today’s applications not only have traditional security requirements, but also things that have not traditionally been thought of as properties security protocols would implement. Nonetheless, now that we’re putting them together the protocols have got to do both jobs. New applications need new protocols and sometimes that happens, but sometimes known protocols get re-engineered (sometimes well, mostly badly), and what tends to happen is that unless one is very, very careful and thoughtful and systematic about the way that protocols are re-engineered or composed, you may end up actually making things worse. Rushby has a good example2 about putting together two protocols, a fault tolerant protocol and a security protocol, and ending up with something that is neither secure nor fault tolerant. We’ve been driven not just by changes in the application, but also by this variety of properties that they have to implement, so we need to understand the interactions of the properties, and the subtleties that those interactions entail, and the impact that those subtleties have on the final product: by and large this is a darn hard thing to do.
机译:今天下午我将与您谈论我们在协议设计上做的一些工作。这实际上是Hassen说的工作;他几年前的车间在工作坊中发表了一点关于这个,从那时起,已经存在了很多进展。协议设计存在许多挑战;我们今天拥有的那些,以及我们将来需要发展的那些。今天早上在这里的谈话明确确定了这些挑战,所以我不认为我会在这里讲道。但协议正在发生变化,并且它们以几种方式改变了形式。它们通过从传统的地方移动,其中一个人会从网络层进入应用程序层 - 因为应用程序本身正在发生变化。此外,我们对我们为安全应用程序开发的技术的期望已经发生了变化。例如,现在我们谈论入侵耐受性;建立安全的东西是不够的,我也想以这样的方式建立它,即使攻击者成功穿透它,它仍将提供一定程度的服务。在那个可能会看到容错的影响:今天的应用程序不仅具有传统的安全要求,而且还没有传统上被认为是属性安全协议的东西。尽管如此,现在我们将它们放在一起,该协议必须做两个工作。新的应用程序需要新的协议,有时会发生这种情况,但有时已知的协议重新设计(有时好,大多数情况下,大多数情况下),往往发生的是,除非一个人非常非常谨慎和周到和系统的方式,重新设计或组成,你可能最终实际上让事情变得更糟。 Rushby有一个很好的例子2,它可以一起放合两种协议,容错协议和安全协议,并结束既不安全也不容忍的东西。我们不仅仅是通过应用程序的变化,还被他们必须实现的各种属性,所以我们需要了解属性的交互,以及这些交互需要的微妙之处,以及那些的影响微妙的上限是最终产品:乘坐和大的这是一个难以做到的事情。

著录项

相似文献

  • 外文文献
  • 中文文献
  • 专利
获取原文

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号