Internet Architecture Board (IAB) H. Tschofenig
Request for Comments: 7452 ARM Ltd.
Category: Informational J. Arkko
ISSN: 2070-1721 D. Thaler
D. McPherson
March 2015
Internet Architecture Board (IAB) H. Tschofenig
Request for Comments: 7452 ARM Ltd.
Category: Informational J. Arkko
ISSN: 2070-1721 D. Thaler
D. McPherson
March 2015
Architectural Considerations in Smart Object Networking
智能对象网络中的体系结构考虑
Abstract
摘要
The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered by Internet protocols. Many of these devices, often called "smart objects", are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment. Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice.
术语“物联网”（IoT）表示大量嵌入式设备使用互联网协议提供的通信服务的趋势。其中许多设备通常被称为“智能对象”，它们不是由人类直接操作的，而是作为组件存在于建筑物或车辆中，或者分布在环境中。设计智能对象网络的工程师和研究人员需要根据“可以连接的一切都将被连接”的主题决定如何在实践中实现这一点。
This document offers guidance to engineers designing Internet-connected smart objects.
本文档为工程师设计互联网连接智能对象提供指导。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7452.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7452.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Smart Object Communication Patterns . . . . . . . . . . . . . 4
2.1. Device-to-Device Communication Pattern . . . . . . . . . 4
2.2. Device-to-Cloud Communication Pattern . . . . . . . . . . 6
2.3. Device-to-Gateway Communication Pattern . . . . . . . . . 7
2.4. Back-End Data Sharing Pattern . . . . . . . . . . . . . . 9
3. Reuse Internet Protocols . . . . . . . . . . . . . . . . . . 10
4. The Deployed Internet Matters . . . . . . . . . . . . . . . . 13
5. Design for Change . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
8. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. IAB Members at the Time of Approval . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Smart Object Communication Patterns . . . . . . . . . . . . . 4
2.1. Device-to-Device Communication Pattern . . . . . . . . . 4
2.2. Device-to-Cloud Communication Pattern . . . . . . . . . . 6
2.3. Device-to-Gateway Communication Pattern . . . . . . . . . 7
2.4. Back-End Data Sharing Pattern . . . . . . . . . . . . . . 9
3. Reuse Internet Protocols . . . . . . . . . . . . . . . . . . 10
4. The Deployed Internet Matters . . . . . . . . . . . . . . . . 13
5. Design for Change . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
8. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. IAB Members at the Time of Approval . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
RFC 6574 [RFC6574] refers to smart objects as devices with constraints on energy, bandwidth, memory, size, cost, etc. This is a fuzzy definition, as there is clearly a continuum in device capabilities and there is no hard line to draw between devices that can run Internet protocols and those that can't.
RFC 6574[RFC6574]将智能对象称为在能量、带宽、内存、大小、成本等方面有限制的设备。这是一个模糊的定义，因为设备功能中显然存在连续统一体，并且在能够运行互联网协议的设备和不能运行互联网协议的设备之间没有硬线。
Interconnecting smart objects with the Internet enables exciting new use cases and products. An increasing number of products put the Internet Protocol Suite on smaller and smaller devices and offer the ability to process, visualize, and gain insight from the collected sensor data. The network effect can be increased if the data collected from many different devices can be combined.
将智能对象与互联网互连可以实现令人兴奋的新用例和产品。越来越多的产品将Internet协议套件安装在越来越小的设备上，并提供处理、可视化和从收集的传感器数据中获得洞察力的能力。如果可以将从多个不同设备收集的数据进行组合，则可以增加网络效应。
Developing embedded systems is a complex task, and designers must make a number of design decisions such as:
开发嵌入式系统是一项复杂的任务，设计师必须做出许多设计决策，例如：
o How long is the device designed to operate?
o 设备的设计工作时间有多长？
o How does it interact with the physical world? Is it a sensor or actuator or both?
o 它是如何与物理世界互动的？它是传感器还是执行器，还是两者都有？
o How many "owners" does it have? One? Many? Is the owner likely to change over the lifetime of the device?
o 它有多少“所有者”？一许多的在设备的生命周期内，所有者是否可能发生变化？
o Is it continuously or intermittently powered? Does it sleep?
o 它是连续供电还是间歇供电？它睡觉吗？
o Is it connected to a network, and if so, how?
o 它是否连接到网络，如果是，如何连接？
o Will it be physically accessible for direct maintenance after deployment? How does that affect the security model?
o 部署后，它是否可以物理访问以进行直接维护？这对安全模型有何影响？
While developing embedded systems is itself a complex task, designing Internet-connected smart objects is even harder since it requires expertise with Internet protocols in addition to software programming and hardware skills. To simplify the development task, and thereby to lower the cost of developing new products and prototypes, we believe that reuse of prior work is essential. Therefore, we provide high-level guidance on the use of Internet technology for the development of smart objects, and connected systems in general.
虽然开发嵌入式系统本身是一项复杂的任务，但设计与互联网相连的智能对象则更加困难，因为它除了需要软件编程和硬件技能外，还需要互联网协议方面的专业知识。为了简化开发任务，从而降低开发新产品和原型的成本，我们相信重用以前的工作是必不可少的。因此，我们提供了关于使用互联网技术开发智能对象和连接系统的高级指导。
Utilize Existing Design Patterns
利用现有的设计模式
Design patterns are generally reusable solutions to a commonly occurring design problem (see [Gamma] for more discussion). Existing smart object deployments show communication patterns that can be reused by engineers with the benefit of lowering the design effort. As discussed in the sections below, individual patterns also have an implication on the required interoperability between the different entities. Depending on the desired functionality, already-existing patterns can be reused and adjusted. Section 2 talks about various communication patterns.
设计模式通常是针对常见设计问题的可重用解决方案（更多讨论请参见[Gamma]）。现有的智能对象部署显示了工程师可以重用的通信模式，从而降低了设计工作量。正如下面几节中所讨论的，各个模式对不同实体之间所需的互操作性也有影响。根据所需的功能，可以重用和调整现有的模式。第2节讨论各种通信模式。
Reuse Internet Protocols
重用因特网协议
Most smart object deployments can make use of the already-standardized Internet Protocol Suite. Internet protocols can be applied to almost any environment due to their generic design and typically offer plenty of potential for reconfiguration, which allows them to be tailored for the specific needs. Section 3 discusses this topic.
大多数智能对象部署都可以使用已经标准化的Internet协议套件。由于其通用设计，Internet协议几乎可以应用于任何环境，并且通常提供了大量的重新配置潜力，这使得它们能够根据特定需求进行定制。第3节讨论这个话题。
The Deployed Internet Matters
部署的互联网事务
When connecting smart objects to the Internet, take existing deployment into consideration to avoid unpleasant surprises. Assuming an ideal, clean-slate deployment is, in many cases, far too optimistic since the already-deployed infrastructure is convenient to use. In Section 4, we highlight the importance of this topic.
将智能对象连接到Internet时，请考虑现有部署，以避免不愉快的意外。在许多情况下，假设一个理想的、干净的部署是过于乐观的，因为已经部署的基础架构使用起来很方便。在第4节中，我们将强调此主题的重要性。
Design for Change
为改变而设计
The Internet infrastructure, applications, and preferred building blocks evolve over time. Especially long-lived smart object deployments need to take this change into account, and Section 5 is dedicated to that topic.
互联网基础设施、应用程序和首选构建块会随着时间的推移而发展。特别是长寿命的智能对象部署需要考虑到这一变化，第5节专门讨论这一主题。
This section illustrates a number of communication patterns utilized in the smart object environment. It is possible that more than one pattern can be applied at the same time in a product. Developers reusing those patterns will benefit from the experience of others as well as from documentation, source code, and available products.
本节说明了智能对象环境中使用的许多通信模式。一个产品中可能同时应用多个图案。开发人员重用这些模式将受益于其他人的经验以及文档、源代码和可用产品。
Figure 1 illustrates a communication pattern where two devices developed by different manufacturers are desired to interoperate and communicate directly. To pick an example from [RFC6574], consider a light switch that talks to a light bulb with the requirement that each may be manufactured by a different company, represented as Manufacturer A and B. Other cases can be found with fitness equipment, such as heart rate monitors and cadence sensors.
图1说明了一种通信模式，其中需要由不同制造商开发的两个设备进行互操作和直接通信。为了从[RCFC774]中选择一个例子，考虑一个光开关，它与一个灯泡对话，要求每一个可以由不同的公司制造，代表制造商A和B。其他情况可以用健身设备，如心率监视器和节奏传感器找到。
_,,,, ,,,,
/ -'`` \
| Wireless |
\ Network |
/ \
,''''''''| / . ,''''''''|
| Light | ------|------------------\------| Light |
| Bulb | . | | Switch |
|........' `'- / |........'
\ _-...-`
Manufacturer `. ,.' Manufacturer
A ` B
_,,,, ,,,,
/ -'`` \
| Wireless |
\ Network |
/ \
,''''''''| / . ,''''''''|
| Light | ------|------------------\------| Light |
| Bulb | . | | Switch |
|........' `'- / |........'
\ _-...-`
Manufacturer `. ,.' Manufacturer
A ` B
Figure 1: Device-to-Device Communication Pattern
图1：设备到设备的通信模式
In order to fulfill the promise that devices from different manufacturers are able to communicate out of the box, these vendors need to agree on the protocol stack. They need to make decisions about the following protocol-design aspects:
为了实现来自不同制造商的设备能够进行开箱即用通信的承诺，这些供应商需要就协议栈达成一致。他们需要就以下协议设计方面做出决策：
o Which physical layer(s) should be supported? Does it use low-power radio technologies (e.g., Bluetooth Smart, IEEE 802.15.4)?
o 应支持哪些物理层？它是否使用低功率无线电技术（例如，蓝牙智能、IEEE 802.15.4）？
o Can devices be IPv6-only, or must they also support IPv4 for backward-compatibility reasons? What IPv4-IPv6 transition technologies are needed?
o 设备可以仅为IPv6，或者出于向后兼容性的原因，它们还必须支持IPv4吗？需要哪些IPv4-IPv6转换技术？
o Which IP address configuration mechanism(s) is integrated into the device?
o 设备中集成了哪些IP地址配置机制？
o Which communication architectures shall be supported? Which devices are constrained, and what are those constraints? Is there a classical client-server model or rather a peer-to-peer model?
o 应支持哪些通信体系结构？哪些设备受到约束，这些约束是什么？是否有一个经典的客户机-服务器模型，或者更确切地说是一个对等模型？
o Is there a need for a service-discovery mechanism to allow users to discover light bulbs they have in their home or office?
o 是否需要一种服务发现机制，允许用户发现家中或办公室中的灯泡？
o Which transport-layer protocol (e.g., UDP) is used for conveying the sensor readings/commands?
o 哪个传输层协议（如UDP）用于传输传感器读数/命令？
o Which application-layer protocol is used (for example, the Constrained Application Protocol (CoAP) [RFC7252])?
o 使用哪种应用层协议（例如，受限应用协议（CoAP）[RFC7252]）？
o What information model is used for expressing the different light levels?
o 用什么信息模型来表示不同的光照强度？
o What data model is used to encode information? (See [RFC3444] for a discussion about the difference between data models and information models.)
o 什么数据模型用于编码信息？（有关数据模型和信息模型之间差异的讨论，请参见[RFC3444]）
o Finally, security and privacy require careful thought. This includes questions like: What are the security threats? What security services need to be provided to deal with the identified threats? Where do the security credentials come from? At what layer(s) in the protocol stack should the security mechanism(s) reside? What privacy implications are caused by various design decisions?
o 最后，安全和隐私需要仔细考虑。这包括以下问题：什么是安全威胁？需要提供哪些安全服务来应对已识别的威胁？安全凭证来自哪里？安全机制应该驻留在协议栈的哪一层？各种设计决策会对隐私造成什么影响？
This list is not meant to be exhaustive but aims to illustrate that for every usage scenario, many design decisions will have to be made in order to accommodate the constrained nature of a specific device in a certain usage scenario. Standardizing such a complete solution
此列表并非详尽无遗，而是旨在说明对于每个使用场景，必须做出许多设计决策，以适应特定使用场景中特定设备的受限性质。标准化这样一个完整的解决方案
to accomplish a full level of interoperability between two devices manufactured by different vendors takes time, but there are obvious rewards for end customers and vendors.
要在由不同供应商生产的两台设备之间实现完全级别的互操作性需要时间，但最终客户和供应商显然会得到回报。
Figure 2 shows a communication pattern for uploading sensor data to an application service provider. Often the application service provider (example.com in our illustration) also sells smart objects. In that case, the entire communication happens internal to the provider and no need for interoperability arises. Still, it is useful for example.com to reuse existing specifications to lower the design, implementation, testing, and development effort.
图2显示了将传感器数据上载到应用程序服务提供商的通信模式。通常，应用程序服务提供商（示例中的example.com）也销售智能对象。在这种情况下，整个通信发生在提供者内部，不需要互操作性。尽管如此，对于example.com来说，重用现有规范以降低设计、实现、测试和开发工作仍然很有用。
While this pattern allows using IP-based communication end to end, it may still lead to silos. To prevent silos, example.com may allow third-party device vendors to connect to their server infrastructure as well. For those cases, the protocol interface used to communicate with the server infrastructure needs to be made available, and various standards are available, such as CoAP, Datagram Transport Layer Security (DTLS) [RFC6347], UDP, IP, etc., as shown in Figure 2. A frequent concern from end users is that a change in the business model (or bankruptcy) of the IoT device/service provide might make the hardware become unusable. Companies might consider the possibility of releasing their source code for the IoT device or allowing other IoT operating systems (plus application software) to be installed on the IoT device.
虽然这种模式允许使用基于IP的端到端通信，但仍可能导致孤岛。为了防止筒仓，example.com可能还允许第三方设备供应商连接到其服务器基础设施。对于这些情况，需要提供用于与服务器基础设施通信的协议接口，并提供各种标准，如CoAP、数据报传输层安全性（DTLS）[RFC6347]、UDP、IP等，如图2所示。最终用户经常担心的一个问题是，物联网设备/服务提供的商业模式的改变（或破产）可能会使硬件变得不可用。企业可能会考虑在IOT设备上发布他们的源代码，或者允许其他IOT操作系统（加上应用软件）安装在IOT设备上。
Similarly, in many situations it is desirable to change which cloud service a device connects to, such as when an application service provider changes its hosting provider. Again, standard Internet protocols are needed.
类似地，在许多情况下，希望更改设备连接到的云服务，例如当应用程序服务提供商更改其宿主提供商时。同样，需要标准的互联网协议。
Since the access networks to which various smart objects are connected are typically not under the control of the application service provider, commonly used radio technologies (such as WLAN, wired Ethernet, and cellular radio) together with the network access authentication technology have to be reused. The same applies to standards used for IP address configuration.
由于各种智能对象连接到的接入网络通常不在应用服务提供商的控制下，因此必须重用常用的无线电技术（例如WLAN、有线以太网和蜂窝无线电）以及网络接入认证技术。这同样适用于用于IP地址配置的标准。
.................
| Application |
| Service |
| Provider |
| example.com |
|_______________|
_, .
HTTP ,' `. CoAP
TLS _,' `. DTLS
TCP ,' `._ UDP
IP -' - IP
,'''''''''''''| ,'''''''''''''''''|
| Device with | | Device with |
| Temperature | | Carbon Monoxide |
| Sensor | | Sensor |
|.............' |.................'
.................
| Application |
| Service |
| Provider |
| example.com |
|_______________|
_, .
HTTP ,' `. CoAP
TLS _,' `. DTLS
TCP ,' `._ UDP
IP -' - IP
,'''''''''''''| ,'''''''''''''''''|
| Device with | | Device with |
| Temperature | | Carbon Monoxide |
| Sensor | | Sensor |
|.............' |.................'
TLS = Transport Layer Security
TLS = Transport Layer Security
Figure 2: Device-to-Cloud Communication Pattern
图2：设备到云通信模式
The device-to-cloud communication pattern, described in Section 2.2, is convenient for vendors of smart objects and works well if they choose a radio technology that is widely deployed in the targeted market, such as Wi-Fi based on IEEE 802.11 for smart home use cases. Sometimes, less-widely-available radio technologies are needed (such as IEEE 802.15.4) or special application-layer functionality (e.g., local authentication and authorization) has to be provided or interoperability is needed with legacy, non-IP-based devices. In those cases, some form of gateway has to be introduced into the communication architecture that bridges between the different technologies and performs other networking and security functionality. Figure 3 shows this pattern graphically. Often, these gateways are provided by the same vendor that offers the IoT product, for example, because of the use of proprietary protocols, to lower the dependency on other vendors or to avoid potential interoperability problems. It is expected that in the future, more generic gateways will be deployed to lower cost and infrastructure complexity for end consumers, enterprises, and industrial environments. Such generic gateways are more likely to exist if IoT device designs make use of generic Internet protocols and not require application-layer gateways that translate one application-layer protocol to another one. The use of application-layer gateways will, in general, lead to a more fragile deployment, as has been observed in the past with [RFC3724] and [RFC3238].
第2.2节中描述的设备到云通信模式对智能对象供应商来说非常方便，如果他们选择在目标市场广泛部署的无线电技术，例如基于IEEE 802.11的Wi-Fi用于智能家居用例，则该模式工作良好。有时，需要不太广泛的可用无线电技术（如IEEE 802.15.4），或必须提供特殊的应用层功能（如本地身份验证和授权），或需要与传统的、非基于IP的设备进行互操作。在这些情况下，必须在通信体系结构中引入某种形式的网关，以桥接不同技术并执行其他联网和安全功能。图3以图形方式显示了此模式。通常，这些网关由提供物联网产品的同一供应商提供，例如，由于使用专有协议，以降低对其他供应商的依赖性或避免潜在的互操作性问题。预计未来将部署更多通用网关，以降低终端消费者、企业和工业环境的成本和基础架构复杂性。如果物联网设备设计使用通用互联网协议，而不需要将一个应用层协议转换为另一个应用层协议的应用层网关，则更可能存在此类通用网关。通常，应用层网关的使用将导致更脆弱的部署，正如过去在[RFC3724]和[RFC3238]中所观察到的那样。
This communication pattern can frequently be found with smart object deployments that require remote configuration capabilities and real-time interactions. The gateway is thereby assumed to be always connected to the Internet.
这种通信模式通常适用于需要远程配置功能和实时交互的智能对象部署。因此，假定网关始终连接到因特网。
.................
| Application |
| Service |
| Provider |
| example.com |
|_______________|
|
|
| IPv4/IPv6
.................
| Local |
| Gateway |
| |
|_______________|
_, .
HTTP ,' `. CoAP
TLS _,' Bluetooth Smart `. DTLS
TCP ,' IEEE 802.11 `._ UDP
IPv6 -' IEEE 802.15.4 - IPv6
,'''''''''''''| ,'''''''''''''''''|
| Device with | | Device with |
| Temperature | | Carbon Monoxide |
| Sensor | | Sensor |
|.............' |.................'
.................
| Application |
| Service |
| Provider |
| example.com |
|_______________|
|
|
| IPv4/IPv6
.................
| Local |
| Gateway |
| |
|_______________|
_, .
HTTP ,' `. CoAP
TLS _,' Bluetooth Smart `. DTLS
TCP ,' IEEE 802.11 `._ UDP
IPv6 -' IEEE 802.15.4 - IPv6
,'''''''''''''| ,'''''''''''''''''|
| Device with | | Device with |
| Temperature | | Carbon Monoxide |
| Sensor | | Sensor |
|.............' |.................'
Figure 3: Device-to-Gateway Communication Pattern
图3：设备到网关的通信模式
If the gateway is mobile, such as when the gateway is a smartphone, connectivity between the devices and the Internet may be intermittent. This limits the applicability of such a communication pattern but is nevertheless very common with wearables and other IoT devices that do not need always-on Internet or real-time Internet connectivity. From an interoperability point of view, it is worth noting that smartphones, with their sophisticated software update mechanism via app stores, allow new functionality to be updated regularly at the smartphone and sometimes even at the IoT device. With special apps that are tailored to each specific IoT device, interoperability is mainly a concern with regard to the lower layers of the protocol stack, such as the radio interface, and less so at the application layer (if users are willing to download a new app for each IoT device).
如果网关是移动的，例如当网关是智能手机时，设备与互联网之间的连接可能是间歇性的。这限制了这种通信模式的适用性，但对于不需要始终在线或实时互联网连接的可穿戴设备和其他物联网设备来说，这种情况非常普遍。从互操作性的角度来看，值得注意的是，智能手机凭借其通过应用商店的复杂软件更新机制，允许在智能手机上定期更新新功能，有时甚至在物联网设备上更新。对于针对每个特定物联网设备定制的特殊应用程序，互操作性主要涉及协议栈的较低层，如无线电接口，而在应用层则较少（如果用户愿意为每个物联网设备下载新应用程序）。
It is also worth pointing out that a gateway allows supporting both IPv6 and IPv4 (for compatibility with legacy application service providers) externally, while allowing devices to be IPv6-only to reduce footprint requirements. If devices do not have the resources to support both IPv4 and IPv6 themselves, being IPv6-only (rather than IPv4-only) with a gateway enables the most flexibility, avoiding the need to update devices to support IPv6 later, whereas IPv4 address exhaustion makes it ill-suited to scale to smart object networks. See [RFC6540] for further discussion.
还值得指出的是，网关允许在外部同时支持IPv6和IPv4（与传统应用程序服务提供商兼容），同时允许设备使用IPv6只是为了减少占用空间要求。如果设备本身没有资源同时支持IPv4和IPv6，那么使用网关仅支持IPv6（而不是仅支持IPv4）可以实现最大的灵活性，从而避免以后需要更新设备以支持IPv6，而IPv4地址耗尽则不适合扩展到智能对象网络。有关进一步的讨论，请参见[RFC6540]。
The device-to-cloud pattern often leads to silos; IoT devices upload data only to a single application service provider. However, users often demand the ability to export and to analyze data in combination with data from other sources. Hence, the desire for granting access to the uploaded sensor data to third parties arises. This design is shown in Figure 4. This pattern is known from the Web in case of mashups and is, therefore, reapplied to the smart object context. To offer familiarity for developers, typically a RESTful API design in combination with a federated authentication and authorization technology (like OAuth 2.0 [RFC6749]) is reused. While this offers reuse at the level of building blocks, the entire protocol stack (including the information/data model and RESTful Web APIs) is often not standardized.
设备到云模式通常会导致筒仓；物联网设备仅向单个应用程序服务提供商上传数据。但是，用户通常要求能够将数据与其他来源的数据结合起来导出和分析。因此，希望将上传的传感器数据的访问权授予第三方。此设计如图4所示。在mashup的情况下，这个模式是从Web上知道的，因此，它被重新应用到智能对象上下文中。为了让开发人员熟悉，通常会重用RESTful API设计与联合身份验证和授权技术（如OAuth 2.0[RFC6749]）。虽然这提供了构建块级别的重用，但整个协议栈（包括信息/数据模型和RESTfulWebAPI）通常没有标准化。
.................
| Application |
.| Service |
,-` | Provider |
.` | b-example.com |
,-` |_______________|
.`
................. ,-`
| Application |-` HTTPS
| Service | OAuth 2.0
| Provider | JSON
| example.com |-,
|_______________| '.
_, `',
,' '.
_,' CoAP or `', .................
,' HTTP '. | Application |
-' `'| Service |
,''''''''| | Provider |
| Light | | c-example.com |
| Sensor | |_______________|
|........'
.................
| Application |
.| Service |
,-` | Provider |
.` | b-example.com |
,-` |_______________|
.`
................. ,-`
| Application |-` HTTPS
| Service | OAuth 2.0
| Provider | JSON
| example.com |-,
|_______________| '.
_, `',
,' '.
_,' CoAP or `', .................
,' HTTP '. | Application |
-' `'| Service |
,''''''''| | Provider |
| Light | | c-example.com |
| Sensor | |_______________|
|........'
Figure 4: Back-End Data Sharing Pattern
图4：后端数据共享模式
When discussing the need for reuse of available standards versus extending or redesigning protocols, it is useful to look back at the criteria for success of the Internet.
在讨论重用可用标准与扩展或重新设计协议的必要性时，回顾互联网成功的标准是很有用的。
RFC 1958 [RFC1958] provides lessons from the early days of the Internet and says:
RFC 1958[RFC1958]提供了互联网早期的经验教训，并指出：
The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan.
互联网及其架构从一开始就以进化的方式发展，而不是从一个宏大的计划开始。
And adds:
并补充说：
A good analogy for the development of the Internet is that of constantly renewing the individual streets and buildings of a city, rather than razing the city and rebuilding it.
互联网发展的一个很好的类比是不断更新城市的街道和建筑物，而不是将城市夷为平地并重建。
Yet, because building very small, battery-powered devices is challenging, it may be difficult to resist the temptation to build solutions tailored to specific applications, or even to redesign networks from scratch to suit a particular application.
然而，由于构建非常小的电池供电设备具有挑战性，因此可能很难抵制构建针对特定应用的解决方案的诱惑，甚至很难从头开始重新设计网络以适应特定应用。
While developing consensus-based standards in an open and transparent process takes longer than developing proprietary solutions, the resulting solutions often remain relevant over a longer period of time.
虽然在公开透明的过程中开发基于共识的标准比开发专有解决方案需要更长的时间，但最终的解决方案往往在更长的时间内保持相关性。
RFC 1263 [RFC1263] considers protocol-design strategy and the decision to design new protocols or to use existing protocols in a non-backward compatible way:
RFC 1263[RFC1263]考虑协议设计策略和设计新协议或以不向后兼容的方式使用现有协议的决策：
We hope to be able to design and distribute protocols in less time than it takes a standards committee to agree on an acceptable meeting time. This is inevitable because the basic problem with networking is the standardization process. Over the last several years, there has been a push in the research community for lightweight protocols, when in fact what is needed are lightweight standards. Also note that we have not proposed to implement some entirely new set of 'superior' communications protocols, we have simply proposed a system for making necessary changes to the existing protocol suites fast enough to keep up with the underlying change in the network. In fact, the first standards organization that realizes that the primary impediment to standardization is poor logistical support will probably win.
我们希望能够在比标准委员会商定可接受的会议时间更短的时间内设计和分发协议。这是不可避免的，因为网络的基本问题是标准化过程。在过去的几年中，研究界推动了轻量级协议的发展，而实际上需要的是轻量级标准。还要注意的是，我们没有提出实施一些全新的“高级”通信协议，我们只是提出了一个系统，用于对现有协议套件进行必要的更改，以足够快的速度跟上网络中的基本更改。事实上，第一个认识到标准化的主要障碍是糟糕的后勤支持的标准化组织可能会获胜。
While [RFC1263] was written in 1991 when the standardization process was more lightweight than today, these thoughts remain relevant in smart object development.
虽然[RFC1263]是在1991年编写的，当时的标准化过程比今天更加轻量级，但这些思想仍然与智能对象开发相关。
Interestingly, a large number of already-standardized protocols are relevant for smart object deployments. RFC 6272 [RFC6272], for example, made the attempt to identify relevant IETF specifications for use in smart grids.
有趣的是，大量已经标准化的协议与智能对象部署相关。例如，RFC 6272[RFC6272]试图确定智能电网中使用的相关IETF规范。
Still, many commercial products contain proprietary or industry-specific protocol mechanisms, and researchers have made several attempts to design new architectures for the entire Internet system. There are several architectural concerns that deserve to be highlighted:
尽管如此，许多商业产品包含专有或特定于行业的协议机制，研究人员已经多次尝试为整个互联网系统设计新的体系结构。有几个架构问题值得强调：
Vertical Profiles
垂直剖面
The discussions at the IAB workshop (see Section 3.1.2 of [RFC6574]) revealed the preference of many participants to develop domain-specific profiles that select a minimum subset of protocols needed for a specific operating environment. Various standardization organizations and industry fora are currently engaged in activities of defining their preferred profile(s).
IAB研讨会上的讨论（见[RFC6574]第3.1.2节）表明，许多参与者倾向于开发特定领域的概要文件，以选择特定操作环境所需的协议的最小子集。各种标准化组织和行业论坛目前都在从事定义其首选配置文件的活动。
Ultimately, however, the number of domains where smart objects can be used is essentially unbounded. There is also an ever-evolving set of protocols and protocol extensions.
然而，最终，可以使用智能对象的域的数量基本上是无限的。还有一组不断发展的协议和协议扩展。
However, merely changing the networking protocol to IP does not necessarily bring the kinds of benefits that industries are looking for in their evolving smart object deployments. In particular, a profile is rigid and leaves little room for interoperability among slightly differing or competing technology variations. As an example, Layer 1 through 7 type profiles do not account for the possibility that some devices may use different physical media than others, and that in such situations, a simple router could still provide an ability to communicate between the parties.
然而，仅仅将网络协议更改为IP并不一定会带来行业在不断发展的智能对象部署中所寻求的各种好处。特别是，概要文件是严格的，在略有不同或相互竞争的技术变体之间几乎没有互操作性的空间。例如，第1层到第7层类型配置文件不考虑某些设备可能使用与其他设备不同的物理介质的可能性，并且在这种情况下，简单路由器仍然可以提供双方之间通信的能力。
Industry-Specific Solutions
特定于行业的解决方案
The Internet Protocol Suite is more extensive than merely the use of IP. Often, significant benefits can be gained from using additional, widely available, generic technologies, such as the Web. Benefits from using these kinds of tools include access to a large available workforce, software, and education already geared towards employing the technology.
互联网协议套件比仅仅使用IP更广泛。通常，使用其他广泛可用的通用技术（如Web）可以获得显著的好处。使用这些工具的好处包括获得大量可用的劳动力、软件和教育，这些都是为了使用这项技术。
Tight Coupling
紧耦合
Many applications are built around a specific set of servers, devices, and users. However, often the same data and devices could be useful for many purposes, some of which may not be easily identifiable at the time the devices are deployed.
许多应用程序是围绕一组特定的服务器、设备和用户构建的。然而，通常相同的数据和设备可用于多种用途，其中一些在部署设备时可能不容易识别。
In addition to the architectural concerns, developing new protocols and mechanisms is generally more risky and expensive than reusing existing standards, due to the additional costs involved in design, implementation, testing, and deployment. Secondary costs, such as the training of technical staff and, in the worst case, the training of end users, can be substantial.
除了架构方面的考虑之外，开发新的协议和机制通常比重用现有标准更具风险和成本，因为设计、实现、测试和部署都涉及额外的成本。二次成本，例如培训技术人员，以及在最坏的情况下培训最终用户，可能是巨大的。
As a result, while there are some cases where specific solutions are needed, the benefits of general-purpose technology are often compelling, be it choosing IP over some more specific communication mechanism, a widely deployed link layer (such as wireless LAN) over a more specific one, web technology over application-specific protocols, and so on.
因此，尽管在某些情况下需要特定的解决方案，但通用技术的好处往往是引人注目的，无论是选择IP而不是更具体的通信机制，选择广泛部署的链路层（如无线LAN）而不是更具体的链路层，选择web技术而不是应用程序特定的协议，等等。
However, when employing these technologies, it is important to embrace them in their entirety, allowing for the architectural flexibility that is built into them. As an example, it rarely makes
然而，在使用这些技术时，重要的是要将它们作为一个整体来使用，并考虑到它们内置的体系结构灵活性。举个例子，它很少让人感到惊讶
sense to limit communications to on-link or to specific media. Design your applications so that the participating devices can easily interact with multiple other applications.
将通信限制在链路上或特定媒体上。设计您的应用程序，以便参与的设备可以轻松地与多个其他应用程序交互。
Despite the applicability of Internet protocols for smart objects, picking the specific protocols for a particular use case can be tricky. As the Internet has evolved, certain protocols and protocol extensions have become the norm, and others have become difficult to use in all circumstances.
尽管互联网协议适用于智能对象，但为特定用例选择特定协议可能很棘手。随着互联网的发展，某些协议和协议扩展已成为常态，而其他协议则难以在所有情况下使用。
Taking into account these constraints is particularly important for smart objects, as there is often a desire to employ specific features to support smart object communication. For instance, from a pure protocol-specification perspective, some transport protocols may be more desirable than others. These constraints apply both to the use of existing protocols as well as designing new ones on top of the Internet protocol stack.
考虑到这些约束对智能对象尤其重要，因为人们通常希望使用特定功能来支持智能对象通信。例如，从纯协议规范的角度来看，某些传输协议可能比其他传输协议更可取。这些约束既适用于现有协议的使用，也适用于在Internet协议栈顶部设计新协议。
The following list illustrates a few of those constraints, but every communication protocol comes with its own challenges.
下面的列表说明了其中的一些限制，但每个通信协议都有自己的挑战。
In 2005, Fonseca, et al. [IPoptions] studied the usage of IP options-enabled packets in the Internet and found that overall, approximately half of Internet paths drop packets with options, making extensions using IP options "less ideal" for extending IP.
2005年，Fonseca等人[IPoptions]研究了互联网上启用IP选项的数据包的使用情况，发现总体而言，大约一半的互联网路径会丢弃带有选项的数据包，这使得使用IP选项的扩展对扩展IP“不太理想”。
In 2010, Honda, et al. [HomeGateway] tested 34 different home gateways regarding their packet dropping policy of UDP, TCP, the Datagram Congestion Control Protocol (DCCP), the Stream Control Transmission Protocol (SCTP), ICMP, and various timeout behavior. For example, more than half of the tested devices do not conform to the IETF-recommended timeouts for UDP, and for TCP the measured timeouts are highly variable, ranging from less than 4 minutes to longer than 25 hours. For NAT traversal of DCCP and SCTP, the situation is poor. None of the tested devices, for example, allowed establishing a DCCP connection.
2010年，Honda等人[HomeGateway]测试了34个不同的家庭网关的UDP、TCP、数据报拥塞控制协议（DCCP）、流控制传输协议（SCTP）、ICMP和各种超时行为的丢包策略。例如，超过一半的测试设备不符合IETF建议的UDP超时，而对于TCP，测量的超时变化很大，从小于4分钟到大于25小时不等。对于DCCP和SCTP的NAT穿越，情况很糟糕。例如，所有测试设备都不允许建立DCCP连接。
In 2011, the behavior of networks with regard to various TCP extensions was tested in [TCPextensions]: "From our results we conclude that the middleboxes implementing layer 4 functionality are very common -- at least 25% of paths interfered with TCP in some way beyond basic firewalling."
2011年，在[TCPextensions]中对各种TCP扩展的网络行为进行了测试：“根据我们的结果，我们得出结论，实现第4层功能的中间件非常常见——至少25%的路径在基本防火墙之外的某些方面干扰TCP。”
Extending protocols to fulfill new uses and to add new functionality may range from very easy to difficult, as [RFC6709] explains in great detail. A challenge many protocol designers are facing is to ensure
正如[RFC6709]详细解释的那样，扩展协议以实现新的用途和添加新的功能可能从非常容易到困难不等。许多协议设计者面临的一个挑战是如何确保
incremental deployability and interoperability with incumbent elements in a number of areas. In various cases, the effort it takes to design incrementally deployable protocols has not been taken seriously enough at the outset. RFC 5218 on "What Makes For a Successful Protocol" [RFC5218] defines wildly successful protocols as protocols that are widely deployed beyond their envisioned use cases.
在多个领域增强部署能力和与现有要素的互操作性。在各种情况下，设计增量部署协议所需的努力在一开始就没有得到足够的重视。关于“成功协议的要素”[RFC5218]的RFC 5218将非常成功的协议定义为广泛部署在其预期用例之外的协议。
As these examples illustrate, protocol architects have to take developments in the greater Internet into account, as not all features can be expected to be usable in all environments. For instance, middleboxes [RFC3234] complicate the use of extensions in basic IP protocols and transport layers.
正如这些示例所示，协议架构师必须考虑到更大的互联网的发展，因为并非所有功能都可以在所有环境中使用。例如，中间盒[RFC3234]使基本IP协议和传输层中扩展的使用复杂化。
RFC 1958 [RFC1958] considers this aspect and says "... the community believes that the goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network." This statement is challenged more than ever with the perceived need to develop intermediaries interacting with less intelligent end devices. However, RFC 3724 [RFC3724] has this to say about this crucial aspect: "One desirable consequence of the end-to-end principle is protection of innovation. Requiring modification in the network in order to deploy new services is still typically more difficult than modifying end nodes." Even this statement will become challenged, as large numbers of devices are deployed, and it indeed might be the case that changing those devices will be hard. But RFC 4924 [RFC4924] adds that a network that does not filter or transform the data that it carries may be said to be "transparent" or "oblivious" to the content of packets. Networks that provide oblivious transport enable the deployment of new services without requiring changes to the core. It is this flexibility that is perhaps both the Internet's most essential characteristic as well as one of the most important contributors to its success.
RFC 1958[RFC1958]考虑到这一点，并表示“……社区认为目标是连通性，工具是互联网协议，情报是端到端的，而不是隐藏在网络中。”这种说法比以往任何时候都受到挑战，因为人们认为需要开发与智能程度较低的终端设备交互的中介。然而，RFC 3724[RFC3724]对这一关键方面有这样的说法：“端到端原则的一个理想结果是保护创新。为了部署新服务而要求修改网络通常比修改端节点更困难。”即使这一说法也会受到质疑，由于部署了大量的设备，因此很难更改这些设备。但是RFC 4924[RFC4924]补充说，不过滤或转换其承载的数据的网络可以被称为“透明”或“不受”分组内容的影响。提供不经意传输的网络允许部署新服务，而无需更改核心。正是这种灵活性可能是互联网最基本的特征，也是互联网成功的最重要因素之一。
How to embrace rapid innovation and at the same time accomplish a high level of interoperability is one of the key aspects for competing in the marketplace. RFC 1263 [RFC1263] points out that "protocol change happens and is currently happening at a very respectable clip...We simply propose [for engineers developing the technology] to explicitly deal with the changes rather [than] keep trying to hold back the flood."
如何拥抱快速创新，同时实现高水平的互操作性，是在市场上竞争的关键方面之一。RFC 1263[RFC1263]指出，“协议变化发生了，而且目前正在以一个非常值得尊敬的速度发生……我们只是建议[开发技术的工程师]明确处理这些变化，而不是[继续]试图阻止洪水。”
In [Tussles], Clark, et al. suggest to "design for variation in outcome, so that the outcome can be different in different places, and the tussle takes place within the design, not by distorting or violating it. Do not design so as to dictate the outcome. Rigid
在[争斗]中，Clark等人建议“为结果的变化而设计，这样结果在不同的地方可以不同，争斗在设计中发生，而不是通过扭曲或违反它。不要设计来支配结果。僵硬
designs will be broken; designs that permit variation will flex under pressure and survive." The term "tussle" refers to the process whereby different parties, which are part of the Internet milieu and have interests that may be adverse to each other, adapt their mix of mechanisms to try to achieve their conflicting goals, and others respond by adapting the mechanisms to push back.
设计将被打破；允许变化的设计将在压力下弯曲并存活下来“指作为互联网环境的一部分并拥有可能相互不利利益的不同各方调整其机制组合以试图实现其相互冲突的目标，而其他各方则通过调整机制进行反击的过程。
In order to accomplish this, Clark, et al. suggest to:
为了实现这一点，Clark等人建议：
1. Break complex systems into modular parts, so that one tussle does not spill over and distort unrelated issues.
1. 将复杂的系统分解成模块化的部分，这样一场争斗就不会溢出并扭曲不相关的问题。
2. Design for choice to permit the different players to express their preferences. Choice often requires open interfaces.
2. 为选择而设计，允许不同的玩家表达他们的偏好。选择通常需要开放的接口。
The main challenge with the suggested approach is predicting how conflicts among the different players will evolve. Since tussles evolve over time, there will be changes to the architecture, too. It is certainly difficult to pick the right set of building blocks and to develop a communication architecture that will last a long time, and many smart object deployments are envisioned to be rather long lived.
所建议的方法的主要挑战是预测不同参与者之间的冲突将如何演变。由于争斗会随着时间的推移而演变，因此架构也会发生变化。当然，选择正确的构建块集和开发能够持续很长时间的通信体系结构是很困难的，而且许多智能对象部署被认为是相当长寿的。
Luckily, the design of the system does not need to be cast in stone during the design phase. It may adjust dynamically since many of the protocols allow for configurability and dynamic discovery. But, ultimately, software update mechanisms may provide the flexibility needed to deal with more substantial changes.
幸运的是，在设计阶段，系统的设计不需要一成不变。它可以动态调整，因为许多协议允许配置和动态发现。但最终，软件更新机制可能会提供处理更大变化所需的灵活性。
A solid software update mechanism is needed not only for dealing with the changing Internet communication environment and for interoperability improvements but also for adding new features and for fixing security bugs. This approach may appear to be in conflict with classes of severely restricted devices since, in addition to a software update mechanism, spare flash and RAM capacity is needed. It is, however, a trade-off worth thinking about since better product support comes with a price.
一个可靠的软件更新机制不仅需要用于处理不断变化的互联网通信环境和提高互操作性，而且还需要用于添加新功能和修复安全漏洞。这种方法似乎与严格限制的设备类别相冲突，因为除了软件更新机制外，还需要备用闪存和RAM容量。然而，这是一个值得考虑的权衡，因为更好的产品支持是有代价的。
As technology keeps advancing, the constraints that technology places on devices evolve as well. Microelectronics have become more capable as time goes by, often making it possible for new devices to be both less expensive and more capable than their predecessors. This trend can, however, be in some cases offset by the desire to embed communications technology in even smaller and cheaper objects. But it is important to design communications technology not just for today's constraints but also for tomorrow's. This is particularly important since the cost of a product is not only determined by the
随着技术的不断进步，技术对设备的限制也在不断演变。随着时间的推移，微电子技术的能力越来越强，这往往使新设备比以前的设备更便宜、性能更强。然而，在某些情况下，这种趋势可能会被将通信技术嵌入更小更便宜的对象的愿望所抵消。但重要的是，设计通信技术不仅要考虑到今天的限制，还要考虑到明天的限制。这一点尤其重要，因为产品的成本不仅取决于
cost of hardware but also by the cost of not reusing already-available protocol stacks and software libraries by developing custom solutions.
硬件成本，还包括不通过开发定制解决方案重用现有协议栈和软件库的成本。
Software updates are common in operating systems and application programs today. Without them, most devices would pose a latent risk to the Internet at large. Arguably, the JavaScript-based web employs a very rapid software update mechanism with code being provided by many different parties (e.g., by websites loaded into the browser or by smartphone apps).
软件更新在当今的操作系统和应用程序中很常见。如果没有它们，大多数设备将对整个互联网构成潜在风险。可以说，基于JavaScript的web采用了非常快速的软件更新机制，代码由许多不同的方提供（例如，通过加载到浏览器中的网站或智能手机应用程序）。
Security is often even more important for smart objects than for more traditional computing systems, since interacting directly with the physical world can present greater dangers, and smart objects often operate autonomously without any human interaction for a long time period. The problem is compounded by the fact that there are often fewer resources available in constrained devices to actually implement security (e.g., see the discussion of "Class 0 devices" in Section 3 of [RFC7228]). As such, it is critical to design for security, taking into account a number of key considerations:
对于智能对象来说，安全性往往比传统计算系统更为重要，因为直接与物理世界交互可能会带来更大的危险，而智能对象通常会在长时间内自动运行，而不需要任何人的交互。受约束设备中用于实际实现安全性的可用资源通常较少（例如，参见[RFC7228]第3节中“0类设备”的讨论），这一事实使问题更加复杂。因此，考虑到以下几个关键因素，安全设计至关重要：
o A key part of any smart object design is the problem of how to establish trust for a smart object. Typically, bootstrapping trust involves giving the device the credentials it needs to operate within a larger network of devices or services.
o 任何智能对象设计的关键部分都是如何为智能对象建立信任的问题。通常，引导信任涉及为设备提供在更大的设备或服务网络中运行所需的凭据。
o Smart objects will, in many cases, be deployed in places where additional physical security is difficult or impossible. Designers should take into account that any such device can and will be compromised by an attacker with direct physical access. Thus, trust models should distinguish between devices susceptible to physical compromise and devices with some level of physical security. Physical attacks, such as timing, power analysis, and glitching, are commonly applied to extract secrets [PhysicalAttacks].
o 在许多情况下，智能对象将部署在难以或不可能实现额外物理安全的地方。设计者应考虑到，任何此类设备都可能并将受到具有直接物理访问权限的攻击者的危害。因此，信任模型应该区分易受物理危害的设备和具有一定物理安全级别的设备。物理攻击，如计时、功率分析和故障，通常用于提取机密[物理攻击]。
o Smart objects will, in many cases, be deployed as collections of identical or near identical devices. Protocols should be designed so that a compromise of a single device does not result in compromise of the entire collection, especially since the compromise of a large number of devices can enable additional attacks such as a distributed denial of service. Sharing secret keys across an entire product family is, therefore, also problematic since compromise of a single device might leave all devices from that product family vulnerable.
o 在许多情况下，智能对象将被部署为相同或接近相同设备的集合。协议的设计应确保单个设备的危害不会导致整个集合的危害，特别是因为大量设备的危害可能导致其他攻击，如分布式拒绝服务。因此，在整个产品系列中共享密钥也是有问题的，因为单个设备的泄露可能会使该产品系列中的所有设备都易受攻击。
o Smart objects will, in many cases, be deployed in ways that the designer never considered. Designers should either seek to minimize the impact of misuse of their systems and devices or implement controls to prevent such misuse where applicable.
o 在许多情况下，智能对象的部署方式是设计者从未考虑过的。设计师应尽量减少系统和设备误用的影响，或在适用的情况下实施控制措施以防止此类误用。
o It is anticipated that smart objects will be deployed with a long (e.g., 5-40 years) life cycle. Any security mechanism chosen at the outset may not be "good enough" for the full lifespan of the device. Thus, long-lived devices should start with good security and provide a path to deploy new security mechanisms over the lifetime of the device.
o 预计智能对象的部署生命周期较长（如5-40年）。在一开始选择的任何安全机制都可能不足以满足设备的整个使用寿命。因此，长寿命设备应该从良好的安全性开始，并提供在设备生命周期内部署新安全机制的途径。
o Security protocols often rely on random numbers, and offering randomness in embedded devices is challenging. For this reason, it is important to consider the use of hardware-based random number generators during early states of the design process.
o 安全协议通常依赖于随机数，在嵌入式设备中提供随机性是一项挑战。出于这个原因，重要的是考虑在设计过程的早期状态中使用基于硬件的随机数生成器。
A more detailed security discussion can be found in the "Report from the Smart Object Security Workshop" [RFC7397] that was held prior to the IETF meeting in Paris, March 2012, and in the report from the National Science Foundation's "Cybersecurity Ideas Lab" workshop [NSF] that was held in February 2014. For example, [NSF] includes, among other recommendations, these recommendations specific to the Internet of Things:
在2012年3月巴黎IETF会议之前举行的“智能对象安全研讨会报告”[RFC7397]以及2014年2月举行的国家科学基金会“网络安全理念实验室”研讨会[NSF]的报告中可以找到更详细的安全讨论。例如，[NSF]除其他建议外，还包括以下针对物联网的建议：
Enhance the Security of the Internet of Things by Identifying Enclaves: The security challenges posed by the emerging Internet of Things should be addressed now, to prepare before it is fully upon us. By identifying specific use segments, or "enclaves", Internet of Things infrastructure stakeholders can address the security requirements and devise event remediations for that enclave.
通过确定飞地来加强物联网的安全：新兴物联网所带来的安全挑战现在就应该解决，在它完全降临到我们面前之前做好准备。通过确定特定使用领域或“飞地”，物联网基础设施利益相关者可以满足安全要求，并为该飞地设计事件补救措施。
Create a Framework for Managing Software Updates: The Internet of Things will challenge our current channels for distributing security updates. An environment must be developed for distributing security patches that scales to a world where almost everything is connected to the Internet and many "things" are largely unattended.
创建一个管理软件更新的框架：物联网将挑战我们当前分发安全更新的渠道。必须开发一个环境来分发安全补丁，以适应几乎所有东西都连接到互联网，并且许多“东西”基本上无人值守的世界。
Finally, we reiterate that use of standards that have gotten wide review can often avoid a number of security issues that could otherwise arise. Section 3.3 of [RFC6574] reminds us about the IETF work style regarding security:
最后，我们重申，使用得到广泛审查的标准通常可以避免一些可能出现的安全问题。[RFC6574]第3.3节提醒我们IETF在安全方面的工作方式：
In the development of smart object applications, as with any other protocol application solution, security has to be considered early in the design process. As such, the recommendations currently provided to IETF protocol architects, such as RFC 3552 [RFC3552], and RFC 4101 [RFC4101], apply also to the smart object space.
在智能对象应用程序的开发过程中，与任何其他协议应用程序解决方案一样，必须在设计过程的早期考虑安全性。因此，目前提供给IETF协议架构师的建议，如RFC 3552[RFC3552]和RFC 4101[RFC4101]也适用于智能对象空间。
In the IETF, security functionality is incorporated into each protocol as appropriate, to deal with threats that are specific to them. It is extremely unlikely that there is a one-size-fits-all security solution given the large number of choices for the 'right' protocol architecture (particularly at the application layer). For this purpose, [RFC6272] offers a survey of IETF security mechanisms instead of suggesting a preferred one.
在IETF中，安全功能被适当地整合到每个协议中，以应对特定于它们的威胁。鉴于“正确”的协议体系结构（特别是在应用层）有大量选择，因此不太可能有一个一刀切的安全解决方案。为此，[RFC6272]提供了IETF安全机制的调查，而不是建议首选机制。
This document mainly focuses on an engineering audience, i.e., those who are designing smart object protocols and architectures. Since there is no value-free design, privacy-related decisions also have to be made, even if they are just implicit in the reuse of certain technologies. RFC 6973 [RFC6973] and the threat model in [CONFIDENTIALITY] were written as guidance specifically for that audience and are also applicable to the smart object context.
本文档主要关注工程受众，即设计智能对象协议和体系结构的人。由于没有无价值的设计，因此也必须做出与隐私相关的决策，即使这些决策只是隐含在某些技术的重用中。RFC 6973[RFC6973]和[机密性]中的威胁模型是专门为该受众编写的指南，也适用于智能对象上下文。
For those looking at privacy from a deployment point of view, the following additional guidelines are suggested:
对于那些从部署角度看待隐私的人，建议遵循以下附加准则：
Transparency: Transparency of data collection and processing is key to avoid unpleasant surprises for owners and users of smart objects. Users and impacted parties must be put in a position to understand what items of personal data concerning them are collected and stored, as well for what purposes they are sought.
透明度：数据收集和处理的透明度是避免智能对象所有者和用户不愉快惊喜的关键。必须让用户和受影响方了解收集和存储与他们有关的个人数据的项目，以及寻找这些数据的目的。
Data Collection / Use Limitation: Smart objects should only store personal data that is adequate, relevant, and not excessive in relation to the purpose(s) for which they are processed. The use of anonymized data should be preferred wherever possible.
数据收集/使用限制：智能对象应仅存储与其处理目的相关的充分、相关且不过度的个人数据。应尽可能优先使用匿名数据。
Data Access: Before deployment starts, it is necessary to consider who can access personal data collected by smart objects and under which conditions. Appropriate and clear procedures should be established in order to allow data subjects to properly exercise their rights.
数据访问：在部署开始之前，有必要考虑谁可以访问由智能对象收集的个人数据以及在何种条件下收集的个人数据。应制定适当和明确的程序，以使数据主体能够正确行使其权利。
Data Security: Standardized data security measures to prevent unlawful access, alteration, or loss of smart object data need to be defined and deployed. Robust cryptographic techniques and proper authentication frameworks have to be used to limit the risk of unintended data transfers or unauthorized access.
数据安全：需要定义和部署标准化的数据安全措施，以防止非法访问、更改或丢失智能对象数据。必须使用稳健的加密技术和适当的身份验证框架来限制意外数据传输或未经授权访问的风险。
A more detailed treatment of privacy considerations that extend beyond engineering can be found in a publication from the Article 29 Working Party [WP223].
第29条工作组[WP223]的出版物中提供了对超出工程范围的隐私考虑的更详细处理。
[CONFIDENTIALITY] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", Work in Progress, draft-iab-privsec-confidentiality-threat-04, March 2015.
[保密性]巴恩斯，R.，施奈尔，B.，詹宁斯，C.，哈迪，T.，特拉梅尔，B.，惠特马，C.，和D.博克曼，“面对普遍监视的保密性：威胁模型和问题陈述”，正在进行中的工作，草稿-iab-PriveSec-机密性-Threat-042015年3月。
[Gamma] Gamma, E., "Design Patterns: Elements of Reusable Object-Oriented Software", 1995.
[Gamma]Gamma，E.“设计模式：可重用面向对象软件的要素”，1995年。
[HomeGateway] Eggert, L., "An Experimental Study of Home Gateway Characteristics", In Proceedings of the 10th annual Internet Measurement Conference, 2010, <http://eggert.org/papers/2010-imc-hgw-study.pdf>.
[HomeGateway]Eggert，L.，“家庭网关特性的实验研究”，发表于2010年第十届年度互联网测量会议论文集<http://eggert.org/papers/2010-imc-hgw-study.pdf>.
[IPoptions] Fonseca, R., Porter, G., Katz, R., Shenker, S., and I. Stoica, "IP options are not an option", Technical Report UCB/EECS2005-24, 2005, <http://citeseer.ist.psu.edu/viewdoc/ summary?doi=10.1.1.123.4251>.
[IPoptions]Fonseca，R.，Porter，G.，Katz，R.，Shenker，S.，和I.Stoica，“IP选项不是选项”，技术报告UCB/EECS2005-242005<http://citeseer.ist.psu.edu/viewdoc/ 总结？doi=10.1.1.123.4251>。
[NSF] National Science Foundation, "Interdisciplinary Pathways towards a More Secure Internet", A report on the NSF-sponsored Cybersecurity Ideas Lab held in Arlington, Virginia, February 2014, <http://www.nsf.gov/cise/news/ CybersecurityIdeasLab_July2014.pdf>.
[国家科学基金会]国家科学基金会，“跨学科的途径，以更安全的互联网”，一份关于美国国家科学基金会赞助的网络安全思想实验室在Virginia阿灵顿举行，2014年2月，<http://www.nsf.gov/cise/news/ CybersecurityIdeasLab_July2014.pdf>。
[PhysicalAttacks] Koeune, F. and F. Standaert, "A Tutorial on Physical Security and Side-Channel Attacks", in Foundations of Security Analysis and Design III: FOSAD 2004/2005 Tutorial Lectures; Lecture Notes in Computer Science, Vol. 3655, pp. 78-108, September 2005, <http://link.springer.com/chapter/10.1007%2F11554578_3>.
[物理攻击]Koeune，F.和F.Standaert，“物理安全和侧通道攻击教程”，在《安全分析和设计基础III：FOSAD 2004/2005教程讲座》中；《计算机科学讲稿》，第3655卷，第78-108页，2005年9月<http://link.springer.com/chapter/10.1007%2F11554578_3>.
[RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered Harmful", RFC 1263, October 1991, <http://www.rfc-editor.org/info/rfc1263>.
[RFC1263]O'Malley，S.和L.Peterson，“TCP扩展被认为是有害的”，RFC1263，1991年10月<http://www.rfc-editor.org/info/rfc1263>.
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996, <http://www.rfc-editor.org/info/rfc1958>.
[RFC1958]Carpenter，B.，“互联网的建筑原理”，RFC19581996年6月<http://www.rfc-editor.org/info/rfc1958>.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002, <http://www.rfc-editor.org/info/rfc3234>.
[RFC3234]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 32342002年2月<http://www.rfc-editor.org/info/rfc3234>.
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002, <http://www.rfc-editor.org/info/rfc3238>.
[RFC3238]Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB架构和政策考虑”，RFC 3238，2002年1月<http://www.rfc-editor.org/info/rfc3238>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003, <http://www.rfc-editor.org/info/rfc3444>.
[RFC3444]Pras，A.和J.Schoenwaeld，“关于信息模型和数据模型之间的差异”，RFC 3444，2003年1月<http://www.rfc-editor.org/info/rfc3444>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003, <http://www.rfc-editor.org/info/rfc3552>.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月<http://www.rfc-editor.org/info/rfc3552>.
[RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004, <http://www.rfc-editor.org/info/rfc3724>.
[RFC3724]Kempf，J.，Austein，R.，和IAB，“中部崛起和端到端的未来：对互联网架构演变的思考”，RFC 37242004年3月<http://www.rfc-editor.org/info/rfc3724>.
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005, <http://www.rfc-editor.org/info/rfc4101>.
[RFC4101]Rescorla，E.和IAB，“编写协议模型”，RFC 41012005年6月<http://www.rfc-editor.org/info/rfc4101>.
[RFC4924] Aboba, B. and E. Davies, "Reflections on Internet Transparency", RFC 4924, July 2007, <http://www.rfc-editor.org/info/rfc4924>.
[RFC4924]Aboba，B.和E.Davies，“关于互联网透明度的思考”，RFC 49242007年7月<http://www.rfc-editor.org/info/rfc4924>.
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, July 2008, <http://www.rfc-editor.org/info/rfc5218>.
[RFC5218]Thaler，D.和B.Aboba，“什么是成功的方案？”，RFC 5218，2008年7月<http://www.rfc-editor.org/info/rfc5218>.
[RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart Grid", RFC 6272, June 2011, <http://www.rfc-editor.org/info/rfc6272>.
[RFC6272]Baker，F.和D.Meyer，“智能电网的互联网协议”，RFC 62722011年6月<http://www.rfc-editor.org/info/rfc6272>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, April 2012, <http://www.rfc-editor.org/info/rfc6540>.
[RFC6540]George，W.，Donley，C.，Liljenstolpe，C.，和L.Howard，“所有具有IP能力的节点都需要IPv6支持”，BCP 177，RFC 65402012年4月<http://www.rfc-editor.org/info/rfc6540>.
[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object Workshop", RFC 6574, April 2012, <http://www.rfc-editor.org/info/rfc6574>.
[RFC6574]Tschofenig，H.和J.Arkko，“智能对象研讨会的报告”，RFC 6574，2012年4月<http://www.rfc-editor.org/info/rfc6574>.
[RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, September 2012, <http://www.rfc-editor.org/info/rfc6709>.
[RFC6709]Carpenter，B.，Aboba，B.和S.Cheshire，“协议扩展的设计考虑”，RFC 6709，2012年9月<http://www.rfc-editor.org/info/rfc6709>.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749]Hardt，D.，“OAuth 2.0授权框架”，RFC 6749，2012年10月<http://www.rfc-editor.org/info/rfc6749>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 69732013年7月<http://www.rfc-editor.org/info/rfc6973>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228]Bormann，C.，Ersue，M.和A.Keranen，“受限节点网络的术语”，RFC 7228，2014年5月<http://www.rfc-editor.org/info/rfc7228>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
[RFC7252]Shelby，Z.，Hartke，K.和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，2014年6月<http://www.rfc-editor.org/info/rfc7252>.
[RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart Object Security Workshop", RFC 7397, December 2014, <http://www.rfc-editor.org/info/rfc7397>.
[RFC7397]Gilger，J.和H.Tschofenig，“智能对象安全研讨会报告”，RFC 7397，2014年12月<http://www.rfc-editor.org/info/rfc7397>.
[TCPextensions] Honda, M., Nishida, Y., Greenhalgh, A., Handley, M., and H. Tokuda, "Is it Still Possible to Extend TCP?", In Proceedings of the ACM Internet Measurement Conference (IMC), Berlin, Germany, November 2011, <http://conferences.sigcomm.org/imc/2011/docs/p181.pdf>.
[TCPextensions]本田，M.，西田，Y.，格林豪尔，A.，汉德利，M.，和H.德田，“是否仍有可能扩展TCP？”，载于2011年11月在德国柏林举行的ACM互联网测量会议（IMC）的会议记录<http://conferences.sigcomm.org/imc/2011/docs/p181.pdf>.
[Tussles] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", In Proceedings of ACM SIGCOMM, 2002, <http://conferences.sigcomm.org/sigcomm/2002/papers/ tussle.html>.
[Tussle]Clark，D.，Wroclawski，J.，Sollins，K.，和R.Braden，“网络空间中的争斗：定义明天的互联网”，ACM SIGCOMM会议记录，2002年<http://conferences.sigcomm.org/sigcomm/2002/papers/ tussle.html>。
[WP223] Article 29 Data Protection Working Party, "Opinion 8/2014 on the Recent Developments on the Internet of Things", 14/ EN, WP 223, September 2014, <http://ec.europa.eu/justice/ data-protection/article-29/documentation/ opinion-recommendation/files/2014/wp223_en.pdf>.
[WP223]第29条数据保护工作组，“2014年8月关于物联网最新发展的意见”，14/EN，WP 223，2014年9月<http://ec.europa.eu/justice/ 数据保护/article-29/documentation/opinion Recommension/files/2014/wp223_en.pdf>。
Jari Arkko Mary Barnes Marc Blanchet Joel Halpern Ted Hardie Joe Hildebrand Russ Housley Eliot Lear Xing Li Erik Nordmark Andrew Sullivan Dave Thaler Brian Trammell
雅丽·阿尔科·玛丽·巴恩斯·马克·布兰切特·乔尔·哈尔本·泰德·哈代·乔·希尔德布兰德·罗斯·霍斯利·艾略特·李尔星·李·埃里克·诺德马克·安德鲁·沙利文·戴夫·泰勒·布莱恩·特拉梅尔
Acknowledgements
致谢
We would like to thank the participants of the IAB Smart Object workshop for their input to the overall discussion about smart objects.
我们要感谢IAB智能物体研讨会的参与者对智能物体整体讨论的投入。
Furthermore, we would like to thank Mike St. Johns, Jan Holler, Patrick Wetterwald, Atte Lansisalmi, Hannu Flinck, Bernard Aboba, Markku Tuohino, Wes George, Robert Sparks, S. Moonsesamy, Dave Crocker, and Steve Crocker in particular for their review comments.
此外，我们还要特别感谢迈克·圣约翰、扬·霍勒、帕特里克·维特瓦尔德、阿特·兰西萨尔米、汉努·弗林克、伯纳德·阿博巴、马克库·图希诺、韦斯·乔治、罗伯特·斯帕克斯、S.穆塞萨米、戴夫·克罗克和史蒂夫·克罗克的评论。
Authors' Addresses
作者地址
Hannes Tschofenig ARM Ltd. 6060 Hall in Tirol Austria
Hannes Tschofenig ARM Ltd.位于奥地利蒂罗尔的6060大厅
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Jari Arkko Jorvas 02420 Finland
Jari Arkko Jorvas 02420芬兰
EMail: jari.arkko@piuha.net
EMail: jari.arkko@piuha.net
Dave Thaler One Microsoft Way Redmond, WA 98052 United States
Dave Thaler One Microsoft Way Redmond，华盛顿州，美国，98052
EMail: dthaler@microsoft.com
EMail: dthaler@microsoft.com
Danny McPherson 12061 Bluemont Way Reston, VA 20190 United States
丹尼·麦克弗森美国弗吉尼亚州雷斯顿市布鲁蒙特大道12061号，邮编：20190
EMail: dmcpherson@verisign.com
EMail: dmcpherson@verisign.com