B、6LoWPAN
6LoWPAN标准定义了与IPv6相关的WSNs中的IPv6数据报的标题压缩和分化机制的，也称为6LowPAN网络。压缩机制包括IP头压缩(IPHC)和下一个头压缩(NHC)。IPHC加密可以在单跳网络中将IPv6头长度压缩至2字节，在多跳网络中压缩至7字节（1字节IPHC、1字节发送、1字节跳限制，2字节源地址，2字节目的地地址）。在IPHC中的其他加密比特是NH比特，它在设置时显示下一个头是用NHC压缩。NHC是用来加密IPv6的扩展头和UDP头。
NHC的大小是一个多重的八位字节（主要是一个八位字节），它包含可变长度ID比特和一个特定的头编码比特。有些协议是UDP负载的一部分，有着类似于IP和UDP 的头结构。例如DTLS，IKE。因此，值得推广6LowPAN头压缩机制来压缩这些协议头。6LowPAN标准的定义了NHC编码，可用于UDP头压缩，但不能用于上层。需要一个新的NHC，因为在NHC中没有给UDP的NH位，这表明UDP负载也压缩了。在第四部分，我们提供了6LowPAN-DTLS的集合和6LowPAN NHCs来压缩DTLS。
如图1所示是头压缩在6LowPAN网络中应用。例如，在有限的节点和6LowPAN边界路由器之间的应用。6BR是用在网络和英特网之间转发消息前，来压缩/解压缩或者片段化/重新组装它们之间的消息。在这种物联网设备中，CoAP使得设备可以与网络主机之间安全通信，例如标准的电脑和智能电话等，它支持CoAPs协议。为了适应安全协议，例如在资源受限的物联网中的DTLS，把6LowPAN头压缩机制应用到这些协议中也是非常有益的。第四节里我们提出了DTLS的6LowPAN头压缩机制。以DTLS标准来设计这些报头压缩是非常重要的，要能够在传统的互联网上与现有的和新的DTLS主机之间互操作。
四、DTLS压缩
DTLS头压缩类似于IPHC，仅在6LowPAN网络中应用，如在传感器节点和6BR中使用。这是因为DTLS报头是UDP负载的一部分，而且路由所需的所有信息已经在IP层提取。在本章中除了描述DTLS的6LowPAN头压缩，我们详细介绍了如何以符合标准的方式将压缩的DTLS连接到6 LowPAN。
A、DTLS-6LowPAN
为了将6LowPAN头压缩机制应用于压缩UDP负载中的头，我们要么需要在6LowPAN协议中修改当前UDP中的NHC编码 ，要么需要给UDP定义一个不同于ID位的新的NHC。第一个解决方案需在当前标准中修改，因此不是一个有
5
利的解决方案。在这篇论文中我们用了第二种方案，它是6LowPAN标准的延伸，有一个类似的方法适合于区分NHC和GHC。UDP中NHC的ID位11110，与6LowPAN中定义的标准一样，表明UDP负载不压缩。定义ID位11011表明UDP负载用6LowPAN-NHC压缩。ID位1101目前在6LowPAN标准中还未定义。图4给出了我们提出的UDP中的NHC，它允许UDP负载的压缩。在我们的例子中，UDP负载包含用6LowPAN-NHC压缩的DTLS头。
B、用于记录头和握手头的6LowPAN-NHC记录协议 在使用DTLS的设备的生命周期中，给发送的每个数据包增加了13个字节长的头字段，另一方面，握手协议，在握手消息中增加了12字节的头。我们提出6LowPAN-NHC来压缩记录协议和握手协议，并分别把头长度减少到3~5个字节。在所有情况下，记录头仍是未加密的。因此，总是用在这章中解释的机制来压缩。
为了向记录和握手头提供头压缩，我们考虑两种情况。在第一种情况中，记录头的片段（见第三部分）包含握手消息，我们用加密字节来压缩记录和握手头消息，并且给出了记录+握手中6LowPAN-NHC的定义。在第二种情况下，我们给记录头定义了6LowPAN-NHC（6LowPAN-NHC-R），与第一种情况不同的是，在记录头中的片段是应用数据而不是握手消息。
我们成功实现了在DTLS握手后应用6LowPAN-NHC-R，并且对随后的消息进行加密和完整性保护。图2a给出了记录+握手头和记录头的6LowPAN-NHC加密。加密为有以下功能：前4位代表的ID字段用来区分 6LowPAN-NHC-RHS和其他编码，而且符合 6LowPAN-NHC编码方案。在 6LoWPAN-NHC-RHS情况下我们把ID位设置到了1000，在 6LoWPAN-NHC-R情况下ID位设置到了1001。
版本（V）：如果是0，是最新的DTLS，版本1.2，省略了字段。如果是1，版本字段进行内联。
时代（EC）：如果是0，使用了八位表示时代，最左边的八位省略。如果是1，所有16为进行内联。在大多数情况下实际年代要么是0要么是1。所以通常使用8位表示年代，这样允许更大的空间。
6
序列号（SN）：序列号包含48位，有些事前导0。如果序列号设为0，就用了16位的序列号，并且左边的32位省略了。如果是1，所有的48位用于内联。如图5a所示，在 6LoWPAN-NHC-R情况下，我们的SN设为2位，这样可以更高效的压缩序列号字段。如果SN=00，就用了16位的序列号，并且左边的32位省略了。如果SN=01，就用了32位的序列号并且最左边的32位省略。如果SN=01，就用了32位的序列号，并且最左边的16位省略了。如果SN=10，就用了24位的序列号，并且最左边的24位省略了。如果SN=11，所有的48位序列号用于内联。
片段（F）：如果F=0，则握手消息没有片段化，并且省略了fragment_offset 和 fragment_length字段。这是常见的情况，如果握手消息短于最大记录长度时就会发生。如果F=1，fragment_offset 和 fragment_length字段用于互联。
在记录头上，content_ type字段总是用于内联。记录头中的长度字段总是省略，因为可以从较低层推算出：或者从 6LoWPAN的头，或者从 IEEE 802.15.4的头。我们必须从低层到高层解压layer-wise，直到完全解压出UDP报头。然后就可以知道UDP有效负载的长度并可以计算出DTLS负载长度。由于我们希望在受限的环境中每个UDP包只有一个DTLS记录头，所以记录头的长度字段也省略了。当 6LoWPAN中的源装置在每个UDP包中发送一个DTLS记录时，传统网络侧会有典型的目的装置在一个UDP包中传送多个DTLS记录头。然而，当6BR对传入的包执行压缩/解压时，有可能在6LoWPAN网络中给出这些包的路由之前，对每个UDP包执行一个DTLS记录。
C、6LoWPAN-NHC for ClientHello
我们提出了客户端友好型的消息6LoWPAN-NHC （6LoWPAN-NHC-C）。在握手过程中会发送两次客户端友好型消息，第一次没有cookie而第二次有服务器的cookie。图5b给出了用6LoWPAN-NHC对客户端友好型消息进行加密的过程。
每一个压缩头字段的功能描述如下： 6LoWPAN-NHC-CH中前四位设为1010用来表示ID字段。
会话ID（SI）：如果SI=0，session_id不可用，并将这一字段和8位的前缀长度字段省略。在DTLS协议中如果没有字段可用，或者用户想生成新的安全参数，那么session_id就是空的。只有在DTLS客户想要恢复旧会话时，才会使用ClientHello消息。真正的ClientHello中session_id字段包含0-32字节。然而，它的前缀中总是有一个8位的字段来表示session_id的大小。如果SI=1，session_id字段用于内联。
Cookie（C）如果C=0，cookie字段不可用，省略这一字段和前缀8位。在ClientHello中真正的cookie字段包含1-255字节。然而，它总是有8位来表示cookie的长度。如果C=1，cookie字段用于内联。
密码套件（CS): 如果CS=0，使用了CoAP默认的（强制性）支持自动的键管理的密码套件，并且这个字段和前缀16位被省略了。在当前的CoAP草稿中，TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8是一个强制性的密码套件。真正的密码套件字段包含2- 2^16?1字节。并且在前缀中包含16字节来表示 cIPher_suites的大小。如果C=1， cipher_suites用于内线互联。
压缩方法（CM）：如果CM=0，就为默认的压缩方法，例如， 用到了COMPRESSION_NULL，省略这个字段和前缀8位字段。实际上压缩方法字段包含1-2^8-1字节。它总是在前缀八位包含压缩方法的大小。如果CM=1，那么压缩
7
方法字段用于内线互联。
在ClientHello中随机字段总是用于内线互联并且总是省略版本字段。版本字段包含的值与DTLS记录头中的值一样。在TLS/SSL情况下，定义版本字段来让一个TLS的客户指定一个旧版本以兼容SSL客户机，而这在实际中很少用到。当前所有的Web浏览器在记录和ClientHello中使用相同的TLS版本。DTLS1.2（改编自TLS 1.2）提到客户在ClientHello消息中发送最新的支持版本。所有DTLS版本(1.0和1.2)的ClientHello消息相兼容。如果客户机不兼容这种版本，那么ServerHello消息将包含支持的版本。如果客户不能够处理服务器的版本，它将给出终止与协议版本连接的警报。
使用 6LoWPAN-NHC-CH，通常只传送 ClientHello消息中的随机字段，而省略所有其他字段。同时，cookie会包含可压缩的字段。图6给出了一个包含ClientHello且未压缩的IP/UDP数据报。图7给出了我们提出的压缩DTLS，它包含ClientHello消息。在应用IPHC和 6LoWPAN-NHC头压缩后，数据报的尺寸是显著降低了。
8
相关推荐：
loading