Network Working Group R. Housley
Request for Comments: 4705 Vigil Security
Category: Informational A. Corry
GigaBeam
October 2006
Network Working Group R. Housley
Request for Comments: 4705 Vigil Security
Category: Informational A. Corry
GigaBeam
October 2006
GigaBeam High-Speed Radio Link Encryption
GigaBeam高速无线链路加密
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes the encryption and key management used by GigaBeam as part of the WiFiber(tm) family of radio link products. The security solution is documented in the hope that other wireless product development efforts will include comparable capabilities.
本文档描述了GigaBeam作为无线链路产品WiFiber（tm）系列的一部分所使用的加密和密钥管理。该安全解决方案记录在案，希望其他无线产品开发工作将包括类似的功能。
The GigaBeam WiFiber(tm) product family provides a high-speed point-to-point radio link. Data rates exceed 1 gigabit/second at a distance of about a mile. The transmission beam width is less than one degree, which means that attempts to intercept the signal are most successful when the attacker is either between the transmitter and receiver or the attacker is directly behind the receiver. Since interception is possible, some customers require confidentiality and integrity protection for the data on the radio link. This document describes the security solution designed and deployed by GigaBeam to provide these security services.
GigaBeam WiFiber（tm）产品系列提供高速点对点无线链路。在大约一英里的距离内，数据速率超过1千兆位/秒。传输波束宽度小于1度，这意味着当攻击者位于发射器和接收器之间或攻击者位于接收器正后方时，拦截信号的尝试最为成功。由于可以进行拦截，一些客户要求对无线链路上的数据进行保密和完整性保护。本文档描述了GigaBeam为提供这些安全服务而设计和部署的安全解决方案。
The GigaBeam security solution employs:
GigaBeam安全解决方案采用：
o AES-GCM [GCM] with a custom security protocol specified in this document to provide confidentiality and integrity protection of subscriber traffic on the radio link;
o AES-GCM[GCM]，具有本文件规定的自定义安全协议，以提供无线链路上用户流量的机密性和完整性保护；
o AES-CBC [CBC] and HMAC-SHA-1 [HMAC] with IPsec ESP [ESP] to provide confidentiality and integrity protection of management traffic between the radio control modules;
o AES-CBC[CBC]和HMAC-SHA-1[HMAC]以及IPsec ESP[ESP]，为无线电控制模块之间的管理通信提供机密性和完整性保护；
o AES-CBC [CBC] and HMAC-SHA-1 [HMAC] with the IKE protocol [IKE] to provide confidentiality and integrity protection of key management traffic between the radio control modules; and
o AES-CBC[CBC]和HMAC-SHA-1[HMAC]以及IKE协议[IKE]，为无线电控制模块之间的密钥管理通信提供机密性和完整性保护；和
o OAKLEY key agreement [OAKLEY] and RSA digital signatures [PKCS1] are used with IKE to establish keying material and to provide authentication.
o OAKLEY密钥协议[OAKLEY]和RSA数字签名[PKCS1]与IKE一起用于建立密钥材料和提供身份验证。
AES-GCM is used with the custom security protocol in a manner that is very similar to its use in ESP [ESP-GCM].
AES-GCM与自定义安全协议的使用方式非常类似于其在ESP中的使用[ESP-GCM]。
The GigaBeam high-speed radio link appears to be a fiber interface between two network devices. Figure 1 illustrates the connection of two devices that normally communicate using Gigabit Ethernet over a fiber optic cable.
GigaBeam高速无线链路似乎是两个网络设备之间的光纤接口。图1显示了两个设备的连接，这两个设备通常通过光纤电缆使用千兆以太网进行通信。
+---------+ +----------+ +----------+ +---------+
| | | +----/ | | | |
| Network | | GigaBeam | / | GigaBeam | | Network |
| Device +=====+ Radio | /---- + Radio +=====+ Device |
| | | | | | | |
+---------+ ^ +----------+ ^ +----------+ ^ +---------+
| | |
| | |
Gigabit Ethernet | Gigabit Ethernet
GigaBeam Radio Link
+---------+ +----------+ +----------+ +---------+
| | | +----/ | | | |
| Network | | GigaBeam | / | GigaBeam | | Network |
| Device +=====+ Radio | /---- + Radio +=====+ Device |
| | | | | | | |
+---------+ ^ +----------+ ^ +----------+ ^ +---------+
| | |
| | |
Gigabit Ethernet | Gigabit Ethernet
GigaBeam Radio Link
Figure 1. GigaBeam Radio Link Example.
图1。千兆波束无线电链路示例。
Gigabit Ethernet traffic is encoded in 8B/10B format. The GigaBeam Radio Control Module (RCM) removes this coding to recover the 8-bit characters plus an indication of whether the character is a control code. The radio link frame is constructed from 224 10-bit input words, and a 4-way interleaved (56,50,10) Reed-Solomon Forward Error Correction (FEC) block is employed. Conversion of the Gigabit Ethernet data from 8B/10B format creates 224 bits of additional capacity in each frame, and another 196 bits is gained by recoding the 9-bit data using 64B/65B block codes. This additional 420 bits of capacity is used for the framing overhead required for FEC and link control.
千兆以太网流量以8B/10B格式编码。GigaBeam无线电控制模块（RCM）删除该编码，以恢复8位字符以及该字符是否为控制代码的指示。无线链路帧由224个10位输入字构成，并采用4路交错（56,50,10）里德-所罗门前向纠错（FEC）块。从8B/10B格式转换千兆以太网数据在每个帧中产生224位的额外容量，另外196位通过使用64B/65B块代码重新编码9位数据获得。额外的420比特容量用于FEC和链路控制所需的帧开销。
The GigaBeam radio link frame fields are summarized in Figure 2, which also provides the length of each field in bits.
图2总结了GigaBeam无线链路帧字段，还提供了每个字段的长度（以位为单位）。
Field Length Description
----- ------ -----------
SYNC 11 Frame Synchronization Pattern ('10110111000'b)
KEYSEL 1 Indicates which AES key was used for this frame
PN 40 AES-GCM Packet Number
FLAGS 28 Control bits, one bit for each 64B/65B data block
DCC 8 Data Communications Channel
DATA 1792 Data (28 encrypted 64B/65B code blocks)
TAG 96 Authentication Tag
SPARE 24 Reserved for alternative FEC algorithms
CHECK 240 Reed-Solomon Check Words for 4 10-bit
symbol (56,50) code
Field Length Description
----- ------ -----------
SYNC 11 Frame Synchronization Pattern ('10110111000'b)
KEYSEL 1 Indicates which AES key was used for this frame
PN 40 AES-GCM Packet Number
FLAGS 28 Control bits, one bit for each 64B/65B data block
DCC 8 Data Communications Channel
DATA 1792 Data (28 encrypted 64B/65B code blocks)
TAG 96 Authentication Tag
SPARE 24 Reserved for alternative FEC algorithms
CHECK 240 Reed-Solomon Check Words for 4 10-bit
symbol (56,50) code
Figure 2. GigaBeam Radio Link Frame Structure.
图2。千兆波束无线电链路帧结构。
Each of the fields in the GigaBeam 2240-bit radio link frame is described below.
GigaBeam 2240位无线电链路帧中的每个字段如下所述。
SYNC Synchronization field, an 11-bit Barker code. Always set to '10110111000'b.
同步同步字段，一个11位巴克码。始终设置为'10111000'b。
KEYSEL Key Selector -- select the appropriate key register for this frame. Two key registers are maintained to allow seamless rollover between encryption keys.
KEYSEL键选择器——为此帧选择适当的键寄存器。维护两个密钥寄存器以允许加密密钥之间的无缝滚动。
PN Packet Number -- needed by AES-GCM; it carries the unique counter value for this frame. The value is incremented for each frame.
PN包编号——AES-GCM所需；它携带此帧的唯一计数器值。每个帧的值都会递增。
FLAGS Control bits, one for each 64B/65B data block carried in the DATA field. If the bit is set, then the corresponding 64B/65B block in the DATA field contains a control code. This field is integrity protected by AES-GCM.
标记控制位，数据字段中每个64B/65B数据块一个。如果设置了该位，则数据字段中相应的64B/65B块包含一个控制代码。此字段受AES-GCM的完整性保护。
DCC Data Communications Channel -- each frame carries one octet of the point-to-point data communications channel between the two radio control modules. See Section 2.2 for more information on the DCC.
DCC数据通信信道——每帧承载两个无线电控制模块之间点对点数据通信信道的一个八位字节。有关DCC的更多信息，请参见第2.2节。
DATA Subscriber data carried as 28 64B/65B code blocks. This field is encrypted and integrity protected by AES-GCM.
数据订户数据作为28 64B/65B代码块携带。此字段由AES-GCM加密和完整性保护。
TAG The authentication tag generated by AES-GCM, truncated to 96 bits.
标记AES-GCM生成的身份验证标记，截断为96位。
SPARE 24 bits, set to zero.
备用24位，设置为零。
CHECK Forward error correction check value -- 24 check symbols are generated by a 4-way interleaved Reed-Solomon (56,50,10) algorithm. FEC is always active, but correction can be selectively enabled. For each frame, FEC processing also returns the number of bit errors, the number of symbols in error, and whether the FEC processing failed for the frame. This information allows an estimation of the bit error rate for the link.
检查前向纠错检查值——24个检查符号由4路交错Reed-Solomon（56,50,10）算法生成。FEC始终处于活动状态，但可以有选择地启用校正。对于每个帧，FEC处理还返回位错误数、出错符号数以及帧的FEC处理是否失败。此信息允许估计链路的误码率。
The Data Communications Channel (DCC) field reserves eight bits in each 2240-bit radio link frame for use in constructing a dedicated point-to-point link between the two RCMs. The DCC content is connected to a Universal Asynchronous Receiver/Transmitter (UART) controller that processes the DCC bit stream to provide an asynchronous serial channel that is visible to the RCM operating system. The Point-to-Point Protocol (PPP) [PPP] is used on the serial channel to create a simple two-node Internet Protocol (IP) network. Each IP datagram is spread over a large number of radio link frames. This two-node IP network carries management protocols between the GigaBeam RCMs.
数据通信信道（DCC）字段在每个2240位无线链路帧中保留8位，用于在两个RCM之间构建专用点到点链路。DCC内容连接到通用异步收发器（UART）控制器，该控制器处理DCC比特流，以提供RCM操作系统可见的异步串行通道。点对点协议（PPP）[PPP]在串行信道上用于创建简单的两节点互联网协议（IP）网络。每个IP数据报分布在大量的无线链路帧上。该双节点IP网络在GigaBeam RCM之间承载管理协议。
IKE [IKE] runs on this two-node IP network to manage all cryptographic keying material. IPsec ESP [ESP] is used in the usual fashion to protect all non-IKE traffic on the data control channel. IPsec ESP employs AES-CBC as described in [ESP-CBC] and HMAC-SHA-1 as described in [ESP-HMAC].
IKE[IKE]在这个双节点IP网络上运行，以管理所有加密密钥材料。IPsec ESP[ESP]通常用于保护数据控制通道上的所有非IKE流量。IPsec ESP使用[ESP-CBC]中所述的AES-CBC和[ESP-HMAC]中所述的HMAC-SHA-1。
The fiber interface constantly provides a stream of data encoded in 8B/10B format. A radio link frame is constructed from 224 10-bit input words. Conversion of the data from 8B/10B format creates 224 bits of additional capacity in each frame, and then recoding using 64B/65B block codes creates another 196 bits of additional capacity. After encryption, the 64B/65B blocks are carried in the DATA field, and the control code indicator bits are carried in the FLAGS field. The additional capacity is used for the framing overhead.
光纤接口不断提供8B/10B格式编码的数据流。无线链路帧由224个10位输入字构成。从8B/10B格式转换数据会在每个帧中产生224位的额外容量，然后使用64B/65B块代码重新编码会产生另外196位的额外容量。加密后，64B/65B块在数据字段中携带，控制代码指示符位在标志字段中携带。附加容量用于框架开销。
Processing proceeds as follows:
处理过程如下：
o encryption and integrity protection as described in Section 3.1;
o 第3.1节所述的加密和完整性保护；
o forward error correction (FEC) processing as described in Section 3.2;
o 如第3.2节所述的前向纠错（FEC）处理；
o scrambling as described in Section 3.3; and
o 第3.3节所述的加扰；和
o differential encoding as described in Section 3.4.
o 第3.4节所述的差分编码。
The GigaBeam RCM contains two key registers. The single-bit KEYSEL field indicates which of the two registers was used for the frame.
GigaBeam RCM包含两个密钥寄存器。单位KEYSEL字段指示两个寄存器中的哪一个用于帧。
AES-GCM [GCM] employs counter mode for encryption. Therefore, a unique value for each frame is needed to construct the counter. The counter includes a 32-bit salt value provided by IKE and a 40-bit packet number from the PN field in the radio link frame. The same counter value must not be used for more than one frame encrypted with the same key. The 128-bit counter block is constructed as shown in Figure 3. The first 96 bits of the AES counter block are called the Nonce in the AES-GCM algorithm description. Note that AES-GCM uses BLOCK values of zero and one for its own use. The values beginning with two are used for encrypting the radio link frame payload.
AES-GCM[GCM]采用计数器模式进行加密。因此，构造计数器需要每个帧的唯一值。计数器包括由IKE提供的32位salt值和来自无线链路帧中PN字段的40位分组号。同一计数器值不得用于使用同一密钥加密的多个帧。128位计数器块的构造如图3所示。AES计数器块的前96位在AES-GCM算法描述中称为Nonce。请注意，AES-GCM将块值0和1用于其自身用途。以2开头的值用于加密无线链路帧有效负载。
Field Length Description
----- ------ -----------
SALT 32 Salt value generated during the IKE exchange
MBZ1 24 These bits must be zero
PN 40 AES-GCM Packet Number carried in PN field
MBZ2 28 These bits must be zero
BLOCK 4 Block counter used in AES-GCM
Field Length Description
----- ------ -----------
SALT 32 Salt value generated during the IKE exchange
MBZ1 24 These bits must be zero
PN 40 AES-GCM Packet Number carried in PN field
MBZ2 28 These bits must be zero
BLOCK 4 Block counter used in AES-GCM
Figure 3. AES Counter Block Construction.
图3。AES计数器块构造。
AES-GCM is used to protect the FLAGS and DATA fields. The FLAGS field is treated as authenticated header data, and it is integrity protected, but it is not encrypted. The DATA field is encrypted and authenticated. The TAG field contains the authentication tag generated by AES-GCM, truncated to 96 bits.
AES-GCM用于保护标志和数据字段。FLAGS字段被视为经过身份验证的标头数据，它受完整性保护，但未加密。数据字段经过加密和身份验证。标签字段包含AES-GCM生成的认证标签，截断为96位。
Reception processing performs decryption and integrity checking. If the integrity checks fail, to maintain a continuous stream of traffic, the frame is replaced with K30.7 control characters. These
接收处理执行解密和完整性检查。如果完整性检查失败，为了保持连续的通信流，帧将替换为K30.7控制字符。这些
control characters are normally used to mark errors in the data stream. Without encryption and integrity checking, these control characters usually indicate 8B/10B running disparity or code errors.
控制字符通常用于标记数据流中的错误。在没有加密和完整性检查的情况下，这些控制字符通常表示8B/10B运行差异或代码错误。
The 224 10-bit data symbols that make up each radio link frame are grouped into 4 subframes each consisting of 56 symbols. The subframes are formed by symbol interleaving. A Reed-Solomon Code, RS(56,50), designed for 10-bit symbols is applied to each subframe.
构成每个无线电链路帧的224个10位数据符号被分组为4个子帧，每个子帧由56个符号组成。子帧通过符号交错形成。为10位符号设计的里德-所罗门码RS（56,50）应用于每个子帧。
This Reed Solomon Code detects 6 errors and corrects 3 errors within each subframe. The FEC function is always active; however, it is possible to disable correction of the received data to support debugging.
此Reed-Solomon代码在每个子帧内检测6个错误并纠正3个错误。FEC功能始终处于激活状态；但是，可以禁用对接收数据的更正以支持调试。
The scrambler ensures that long series of one bits and long series of zero bits do not occur. When encryption is enabled, long series of common bit values is very unlikely; however, during the initial IKE exchange, the radio link frame payload is all zero bits.
扰码器确保不会出现一位长序列和零位长序列。启用加密时，不太可能出现长系列的公共位值；然而，在初始IKE交换期间，无线链路帧有效载荷全部为零位。
The scrambling polynomial is (1 + x^14 + x^15). All words of a frame except the SYNC pattern are scrambled prior to transmission using this linear feedback shift register (LFSR). The LFSR is initialized to all ones at the start of each frame, prior to the first processed bit. Each processed input bit is added modulo 2 (i.e., an XOR) to the output of the x15 tap to form the output bit.
置乱多项式为（1+x^14+x^15）。除了同步模式外，帧的所有字在传输之前都使用该线性反馈移位寄存器（LFSR）进行加扰。LFSR在每帧开始时，在第一个处理位之前初始化为所有帧。每个处理后的输入位都以模2（即XOR）的形式添加到x15抽头的输出，以形成输出位。
On reception, an identical process is performed after frame synchronization and prior to subsequent processing to recover the original bit pattern.
在接收时，在帧同步之后和后续处理之前执行相同的处理以恢复原始比特模式。
The data stream is differentially encoded to avoid symbol ambiguity at the receiver. Since the demodulator could produce true or inverted data depending on the details of the radio frequency (RF) and intermediate frequency (IF) processing chains, differential encoding is used to ensure proper reception of the intended bit value. A zero bit is encoded as no change from the previous output bit, and a one bit is encoded as a change from the previous output bit. Thus, an output bit is the result of XORing the unencoded bit with the previously transmitted encoded bit.
数据流被差分编码以避免接收机处的符号模糊。由于解调器可根据射频（RF）和中频（IF）处理链的细节产生真实或反转数据，因此使用差分编码以确保正确接收预期比特值。零位编码为前一输出位的无变化，一位编码为前一输出位的变化。因此，输出位是未编码位与先前传输的编码位异或的结果。
On reception, a complementary operation will be performed to produce the decoded datastream. The bitstream is formed by XORing the received encoded bit and the previously received encoded bit.
在接收时，将执行补充操作以产生解码的数据流。比特流是通过对接收到的编码比特和先前接收到的编码比特进行异或而形成的。
The Internet Key Exchange (IKE) is used for key management [IKE]. IKE has two phases. In Phase 1, two Internet Security Association and Key Management Protocol (ISAKMP) peers establish a secure, authenticated channel with which to communicate. This is called the ISAKMP Security Association (SA). In the GigaBeam environment, the Phase 1 exchange is IKE Aggressive Mode with signatures and certificates. The RSA signature algorithm is used.
Internet密钥交换（IKE）用于密钥管理[IKE]。IKE有两个阶段。在第1阶段，两个Internet安全关联和密钥管理协议（ISAKMP）对等方建立一个安全的、经过身份验证的通道进行通信。这被称为ISAKMP安全协会（SA）。在GigaBeam环境中，第1阶段交换采用IKE攻击模式，带有签名和证书。采用RSA签名算法。
Phase 2 negotiates the Security Associations for the GigaBeam custom security protocol that protects subscriber traffic and IPsec ESP that protects management traffic between the GigaBeam RCMs. In the GigaBeam environment, the Phase 2 exchange is IKE Quick Mode, without perfect forward secrecy (PFS). The information exchanged along with Quick Mode is protected by the ISAKMP SA. That is, all payloads except the ISAKMP header are encrypted. A detailed description of Quick Mode can be found in Section 5.5 of [IKE].
第2阶段协商GigaBeam自定义安全协议（保护订户流量）和IPsec ESP（保护GigaBeam RCM之间的管理流量）的安全关联。在GigaBeam环境中，第2阶段交换为IKE快速模式，没有完全前向保密（PFS）。与快速模式一起交换的信息受ISAKMP SA保护。除ISAP之外的所有有效载荷都是加密的。有关快速模式的详细说明，请参见[IKE]第5.5节。
When the Security Association is no longer needed, the ISAKMP Delete Payload is used to tell the peer GigaBeam device that it is being discarded.
当不再需要安全关联时，ISAKMP Delete有效负载用于通知对等GigaBeam设备它正在被丢弃。
Each GigaBeam device generates its own public/private key pair. This generation is performed at the factory, and the public key is certified by a Certification Authority (CA) in the factory. The certificate includes a name of the following format:
每个GigaBeam设备都会生成自己的公钥/私钥对。此生成在工厂中执行，公钥由工厂中的证书颁发机构（CA）认证。证书包括以下格式的名称：
C=US O=GigaBeam Corporation OU=GigaBeam WiFiber(tm)
SerialNumber=<device-model-identifier>/<device-serial-number>
C=US O=GigaBeam Corporation OU=GigaBeam WiFiber(tm)
SerialNumber=<device-model-identifier>/<device-serial-number>
The ISAKMP Certificate Payload is used to transport certificates, and in the GigaBeam environment, the "X.509 Certificate - Signature" certificate encoding type (indicated by a value of 4) is always used.
ISAKMP证书有效负载用于传输证书，在GigaBeam环境中，始终使用“X.509证书-签名”证书编码类型（由值4表示）。
GigaBeam devices are always installed in pairs. At installation time, each one is configured with the device model identifier and device serial number of its peer. The device model identifier and device serial number of a backup device can also be provided. An access control check is performed when certificates are exchanged. The certificate subject name must match one of these configured
GigaBeam设备始终成对安装。在安装时，每个设备都配置有其对等设备的设备型号标识符和设备序列号。还可以提供备份设备的设备型号标识符和设备序列号。在交换证书时执行访问控制检查。证书使用者名称必须与以下配置之一匹配
values, and the certification path must validate to a configured trust anchor, such as the GigaBeam Root CA, using the validation rules in [PKIX1].
值，并且证书路径必须使用[PKIX1]中的验证规则验证到已配置的信任锚点，例如GigaBeam根CA。
With IKE, several possible Diffie-Hellman groups are supported. These groups originated with the Oakley protocol and are therefore called "Oakley Groups".
使用IKE，可以支持几个可能的Diffie-Hellman组。这些团体起源于奥克利协议，因此被称为“奥克利团体”。
GigaBeam devices use group 14, which is described in Section 3 of [MODP].
GigaBeam设备使用组14，这在[MODP]第3节中有描述。
The ISAKMP proposal syntax was specifically designed to allow for the simultaneous negotiation of multiple Phase 2 security protocol suites. The identifiers for the IPsec Domain of Interpretation (DOI) are given in [IPDOI].
ISAKMP提案语法专门设计用于同时协商多个第2阶段安全协议套件。IPsec解释域（DOI）的标识符在[IPDOI]中给出。
The GigaBeam custom security protocol has been assigned the PROTO_GIGABEAM_RADIO protocol identifier, with a value of 5.
GigaBeam自定义安全协议已分配PROTO_GigaBeam_无线电协议标识符，值为5。
The PROTO_GIGABEAM_RADIO specifies the use of the GigaBeam radio link frame structure, which uses a single algorithm for both confidentiality and authentication. The following table indicates the algorithm values that are currently defined.
PROTO_GIGABEAM_RADIO指定使用GIGABEAM RADIO链路帧结构，该结构使用单一算法实现机密性和身份验证。下表显示了当前定义的算法值。
Transform ID Value
------------ -----
RESERVED 0
GIGABEAM_AES128_GCM 1
Transform ID Value
------------ -----
RESERVED 0
GIGABEAM_AES128_GCM 1
GIGABEAM_AES128_GCM requires 20 octets of keying material (called KEYMAT in [IKE]). The first 16 octets are the 128-bit AES key, and the remaining four octets are used as the salt value in the AES counter block.
GIGABEAM_AES128_GCM需要20个八位字节的键控材料（在[IKE]中称为键控材料）。前16个八位字节是128位AES密钥，其余四个八位字节用作AES计数器块中的salt值。
Presently, AES with a 128-bit key is the only encryption algorithm that is supported. Other encryption algorithms could be registered in the future.
目前，具有128位密钥的AES是唯一受支持的加密算法。将来可能会注册其他加密算法。
The following table lists the assigned values for the Identification Type field found in the ISAKMP Identification Payload.
下表列出了ISAKMP标识有效负载中标识类型字段的分配值。
ID Type Value
------- -----
RESERVED 0
ID_IPV4_ADDR 1
ID_FQDN 2
ID_USER_FQDN 3
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
ID_DER_ASN1_DN 9
ID_DER_ASN1_GN 10
ID_KEY_ID 11
ID Type Value
------- -----
RESERVED 0
ID_IPV4_ADDR 1
ID_FQDN 2
ID_USER_FQDN 3
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
ID_DER_ASN1_DN 9
ID_DER_ASN1_GN 10
ID_KEY_ID 11
The ID_DER_ASN1_DN will be used when negotiating security associations for use with the GigaBeam custom security protocol. The provided distinguished name must match the peer's subject name provided in the X.509 certificate.
协商与GigaBeam自定义安全协议使用的安全关联时，将使用ID_DER_ASN1_DN。提供的可分辨名称必须与X.509证书中提供的对等方的使用者名称匹配。
The least significant bit of the Security Parameter Index (SPI) is used in the GigaBeam custom security protocol. When two GigaBeam custom security protocol security associations are active at the same time for communications in the same direction, the least significant bit of the SPI must be different to ensure that these active security associations can be distinguished by the single bit in the GigaBeam custom security protocol.
安全参数索引（SPI）的最低有效位用于GigaBeam自定义安全协议。当两个GigaBeam自定义安全协议安全关联在同一方向的通信中同时处于活动状态时，SPI的最低有效位必须不同，以确保可以通过GigaBeam自定义安全协议中的单个位来区分这些活动安全关联。
The IKE exchange over the DCC must complete before subscriber data can be exchanged in the GigaBeam radio link frame payload. Since each radio link frame carries a small portion of an IP datagram, many radio link frames carrying all zero bits must be sent and received to complete the IKE exchange.
在GigaBeam无线链路帧有效载荷中交换用户数据之前，必须完成DCC上的IKE交换。由于每个无线链路帧承载IP数据报的一小部分，因此必须发送和接收承载所有零位的许多无线链路帧以完成IKE交换。
Once the initial keying material is in place, the IKE exchanges to establish subsequent keying material can be performed concurrent with the transfer of subscriber data in the radio link frame payload. The KEYSEL field in the radio link frame is used to indicate which keying material is being used.
一旦初始键控材料就位，就可以在无线链路帧有效载荷中的用户数据传输的同时执行用于建立后续键控材料的IKE交换。无线电链路帧中的KEYSEL字段用于指示正在使用的键控材料。
The PN field in radio link frame provides a continuous indication of the number of frames that have been encrypted with a particular key. Once a threshold is exceeded, the IKE exchanges begin to establish the replacement keying material. Currently, the exchanges begin when half of the packet numbers have been used, but any threshold can be employed, as long as the replacement keying material is available before the packet counters are exhausted.
无线链路帧中的PN字段提供已使用特定密钥加密的帧数的连续指示。一旦超过阈值，IKE交换就开始建立替换键控材料。目前，交换在使用了一半的数据包编号时开始，但只要在数据包计数器耗尽之前替换密钥材料可用，就可以使用任何阈值。
The security considerations in [IKE], [OAKLEY], [PKCS1], and [ESP] apply to the security system defined in this document.
[IKE]、[OAKLEY]、[PKCS1]和[ESP]中的安全注意事项适用于本文档中定义的安全系统。
Confidentiality and integrity are provided by the use of negotiated algorithms. AES-GCM [GCM] is used with the GigaBeam custom security protocol to provide confidentiality and integrity protection of subscriber traffic on the radio link. AES-CBC [CBC] and HMAC-SHA-1 [HMAC] are used with IPsec ESP [ESP] to provide confidentiality and integrity protection of management traffic between the radio control modules.
保密性和完整性是通过使用协商算法实现的。AES-GCM[GCM]与GigaBeam自定义安全协议一起使用，为无线链路上的用户流量提供机密性和完整性保护。AES-CBC[CBC]和HMAC-SHA-1[HMAC]与IPsec ESP[ESP]一起使用，为无线电控制模块之间的管理通信提供机密性和完整性保护。
AES-GCM makes use of AES Counter mode to provide confidentiality. Unfortunately, it is very easy to misuse counter mode. If counter block values are ever used for more than one frame with the same key, then the same key stream will be used to encrypt both frames, and the confidentiality guarantees are voided. Using AES Counter mode with the same counter values to encrypt two plaintexts under the same key leaks the plaintext. The automated key management described here is intended to prevent this from ever happening.
AES-GCM利用AES计数器模式提供机密性。不幸的是，很容易误用计数器模式。如果计数器块值用于具有相同密钥的多个帧，则将使用相同的密钥流加密两个帧，并且机密性保证无效。使用具有相同计数器值的AES计数器模式加密同一密钥下的两个明文会泄漏明文。这里描述的自动密钥管理旨在防止这种情况发生。
Since AES has a 128-bit block size, regardless of the mode employed, the ciphertext generated by AES encryption becomes distinguishable from random values after 2^64 blocks are encrypted with a single key. Since the GigaBeam radio link frame allows for up to 2^40 fixed-length frames in a single security association, there is no possibility for more than 2^64 blocks to be encrypted with one key.
由于AES具有128位的块大小，因此无论采用何种模式，AES加密生成的密文在使用单个密钥加密2^64个块后可与随机值区分开来。由于GigaBeam无线链路帧允许在单个安全关联中最多2^40个固定长度帧，因此不可能使用一个密钥加密超过2^64个块。
The lifetime of a particular AES key can be shorter than 2^40 frames. A smaller threshold can be used as a trigger to transition to the next key. This capability allows straightforward implementation of policies that require the key to be changed after a particular volume of traffic or a particular amount of time.
特定AES密钥的生存期可以短于2^40帧。较小的阈值可用作切换到下一个关键点的触发器。此功能允许直接执行需要在特定流量或特定时间后更改密钥的策略。
There are fairly generic precomputation attacks against all block cipher modes that allow a meet-in-the-middle attack against the key. These attacks require the creation and searching of huge tables of ciphertext associated with known plaintext and known keys. Assuming that the memory and processor resources are available for a
存在针对所有分组密码模式的相当通用的预计算攻击，这些攻击允许针对密钥的中间相遇攻击。这些攻击需要创建和搜索与已知明文和已知密钥相关的大量密文表。假设内存和处理器资源可用于
precomputation attack, then the theoretical strength of AES Counter mode (and any other block cipher mode) is limited to 2^(n/2) bits, where n is the number of bits in the key. The use of long keys is the best countermeasure to precomputation attacks. The unpredictable nonce value in the counter block significantly increases the size of the table that the attacker must compute to mount a successful precomputation attack.
预计算攻击，则AES计数器模式（和任何其他分组密码模式）的理论强度限制为2^（n/2）位，其中n是密钥中的位数。使用长密钥是对付预计算攻击的最佳对策。计数器块中不可预测的nonce值显著增加了表的大小，攻击者必须计算该表才能成功发起预计算攻击。
Rekeying with Quick Mode results in new keys to protect GigaBeam radio link frames; however, these keys are generated from the same Diffie-Hellman shared secret. In order to limit the amount of data that would be exposed by the disclosure of this Diffie-Hellman shared secret or the associated Diffie-Hellman private key, implementations should periodically rekey using a new Phase 1 exchange.
使用快速模式重新设置密钥会产生新密钥，以保护GigaBeam无线链路帧；但是，这些密钥是由相同的Diffie-Hellman共享密钥生成的。为了限制此Diffie-Hellman共享密钥或相关Diffie-Hellman私钥的泄露所暴露的数据量，实现应定期使用新的阶段1交换重新密钥。
Diffie-Hellman exponents used in IKE Phase 1 should be erased from memory immediately after use. Likewise, AES and HMAC-SHA-1 keying material should be erased from memory when it is no longer needed.
IKE阶段1中使用的Diffie-Hellman指数应在使用后立即从内存中删除。同样，当不再需要AES和HMAC-SHA-1键控材料时，应将其从内存中删除。
This security solution makes use of IKEv1 [IKE]. IKEv1 was selected over IKEv2 [IKEv2] primarily due to the availability of an implementation for the processing environment. The use of IKEv2 would provide some useful capabilities, such as Diffie-Hellman group negotiation. These additional capabilities would not significantly improve the security of the overall key management solution that runs on the two-node IP network.
此安全解决方案使用IKEv1[IKE]。选择IKEv1而不是IKEv2[IKEv2]主要是因为处理环境的实现可用。IKEv2的使用将提供一些有用的功能，例如Diffie-Hellman组协商。这些附加功能不会显著提高在两节点IP网络上运行的整个密钥管理解决方案的安全性。
IANA has assigned one IPsec Security Protocol Identifier in http://www.iana.org/assignments/isakmp-registry for PROTO_GIGABEAM_RADIO. It was assigned the value 5.
IANA已在中分配了一个IPsec安全协议标识符http://www.iana.org/assignments/isakmp-registry 用于PROTO_GIGABEAM_无线电。它被赋值为5。
[CBC] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques," NIST Special Publication 800-38A, December 2001.
[CBC]德沃金，M.，“分组密码操作模式的建议：方法和技术”，NIST特别出版物800-38A，2001年12月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]Kent，S.，“IP封装安全有效负载（ESP）”，RFC 4303，2005年12月。
[ESP-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[ESP-CBC]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[ESP-GCM] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[ESP-GCM]Viega，J.和D.McGrew，“在IPsec封装安全负载（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，2005年6月。
[ESP-HMAC] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[ESP-HMAC]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of
Operation (GCM)", Submission to NIST.
http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/
gcm/gcm-spec.pdf, January 2004. [Soon: NIST SP 800-38D.]
[GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of
Operation (GCM)", Submission to NIST.
http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/
gcm/gcm-spec.pdf, January 2004. [Soon: NIST SP 800-38D.]
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[IKEv2] Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", RFC 2306, December 2005.
[IKEv2]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC2306，2005年12月。
[IPDOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[IPDOI]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[MODP] Kivinen, T. and M. Kojo. "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[MODP]Kivinen，T.和M.Kojo。“因特网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman组”，RFC 3526，2003年5月。
[OAKLEY] Orman, H., "The Oakley Key Determination Protocol", RFC 2412, November 1998.
[OAKLEY]Orman，H.，“OAKLEY密钥确定协议”，RFC 2412，1998年11月。
[PKCS1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 1998.
[PKCS1]Kaliski，B.，“PKCS#1:RSA加密版本1.5”，RFC 2313，1998年3月。
[PKIX1] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIX1]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[PPP]辛普森，W.“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
The authors thank Bob Sutherland and Dave Marcellas for their contributions and review.
作者感谢Bob Sutherland和Dave Marcellas的贡献和评论。
Authors' Addresses
作者地址
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州，邮编20170
EMail: housley@vigilsec.com
EMail: housley@vigilsec.com
Alan Corry GigaBeam Corporation 470 Springpark Place, Suite 900 Herndon, VA 20170 USA
Alan Corry GigaBeam Corporation美国弗吉尼亚州赫恩顿市斯普林帕克广场470号900室，邮编：20170
EMail: publications@gigabeam.com
EMail: publications@gigabeam.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。