Network Working Group E. Rescorla
Request for Comments: 4101 RTFM, Inc.
Category: Informational IAB
June 2005
Network Working Group E. Rescorla
Request for Comments: 4101 RTFM, Inc.
Category: Informational IAB
June 2005
Writing Protocol Models
编写协议模型
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system.
IETF过程取决于同行评审。然而，IETF文档的编写通常是为了对实施者有用，而不是对评审者有用。特别是，虽然通常会非常小心地提供状态机和线路上位的完整描述，但这种详细程度往往会妨碍初步理解。本文档描述了一种提供协议“模型”的方法，该模型允许审阅者快速掌握系统的本质。
The IETF process depends on peer review. However, in many cases, the documents submitted for publication are extremely difficult to review. Because reviewers have only limited amounts of time, this leads to extremely long review times, inadequate reviews, or both. In our view, a large part of the problem is that most documents fail to present an architectural model for how the protocol operates, opting instead to simply describe the protocol and let the reviewer figure it out.
IETF过程取决于同行评审。然而，在许多情况下，提交出版的文件极难审查。因为评审员的时间有限，这会导致评审时间过长、评审不足或两者兼而有之。在我们看来，问题的很大一部分在于，大多数文档都没有提供协议如何运行的体系结构模型，而是选择简单地描述协议，让审阅者理解它。
This is acceptable when documenting a protocol for implementors, because they need to understand the protocol in any case; but it dramatically increases the strain on reviewers. Reviewers need to get the big picture of the system and then focus on particular points. They simply do not have time to give the entire document the attention an implementor would.
这在为实施者记录协议时是可以接受的，因为他们在任何情况下都需要理解协议；但这大大增加了评论家的压力。评论者需要了解系统的整体情况，然后关注特定点。他们根本没有时间像实现者那样关注整个文档。
One way to reduce this load is to present the reviewer with a MODEL -- a short description of the system in overview form. This provides the reviewer with the context to identify the important or difficult pieces of the system and focus on them for review. As a side benefit, if the model is done first, it can be serve as an aid to the detailed protocol design and a focus for early review, prior to protocol completion. The intention is that the model would either be the first section of the protocol document or be a separate document provided with the protocol.
减少此负载的一种方法是向审阅者提供一个模型——以概述的形式对系统进行简短描述。这为审阅者提供了上下文，以确定系统的重要或困难部分，并集中精力进行审阅。作为一个附带的好处，如果先完成模型，它可以作为详细方案设计的辅助工具，并在方案完成之前作为早期审查的重点。其目的是，该模型要么是议定书文件的第一部分，要么是随议定书提供的一份单独文件。
A protocol model needs to answer three basic questions:
协议模型需要回答三个基本问题：
1. What problem is the protocol trying to achieve? 2. What messages are being transmitted and what do they mean? 3. What are the important, but unobvious, features of the protocol?
1. 协议试图解决什么问题？2.正在传输的信息是什么？它们意味着什么？3.协议的重要但不明显的特点是什么？
The basic idea is to provide enough information that the reader could design a protocol which was roughly isomorphic to the protocol being described. Of course, this doesn't mean that the protocol would be identical, but merely that it would share most important features. For instance, the decision to use a KDC-based authentication model is an essential feature of Kerberos [KERBEROS]. By contrast, the use of ASN.1 is a simple implementation decision. S-expressions -- or XML, had it existed at the time -- would have served equally well.
其基本思想是提供足够的信息，使读者能够设计一个大致与所描述的协议同构的协议。当然，这并不意味着协议将是相同的，而只是它将共享最重要的特性。例如，决定使用基于KDC的身份验证模型是Kerberos[Kerberos]的一个基本特性。相比之下，使用ASN.1是一个简单的实现决策。S表达式——或者说XML，如果当时存在的话——也同样适用。
The purpose of a protocol model is explicitly not to provide a complete or alternate description of the protocol being discussed. Instead, it is to provide a big picture overview of the protocol so that readers can quickly understand the essential elements of how it works.
协议模型的目的显然不是提供所讨论协议的完整或替代描述。相反，它是提供一个大的图片概述该协议，以便读者能够快速了解其工作原理的基本要素。
In this section we discuss basic principles that should guide your presentation.
在本节中，我们将讨论指导您演讲的基本原则。
Humans are only capable of keeping a very small number of pieces of information in their head at once. Because we're interested in ensuring that people get the big picture, we have to dispense with a lot of detail. That's good, not bad. The simpler you can make things the better.
人类一次只能在大脑中保存极少量的信息。因为我们有兴趣确保人们了解大局，所以我们必须省去很多细节。这很好，不坏。你越简单，事情就越好。
A key technique for representing complex systems is to try to abstract away pieces. For instance, maps are better than photographs for finding out where you want to go because they provide an abstract, stylized, view of the information you're interested in. Don't be afraid to compress multiple protocol elements into a single abstract piece for pedagogical purposes.
表示复杂系统的一个关键技术是试图抽象出各个部分。例如，地图比照片更能找出你想去的地方，因为它们提供了你感兴趣的信息的抽象、风格化的视图。出于教学目的，不要害怕将多个协议元素压缩成一个抽象片段。
The converse of the previous principle is that sometimes details help to bring a description into focus. Many people work better when given examples. Thus, it's often a good approach to talk about the material in the abstract and then provide a concrete description of one specific piece to bring it into focus. Authors should focus on the normal path. Error cases and corner cases should only be discussed where they help illustrate an important point.
与前一个原则相反的是，有时细节有助于突出描述。当给出例子时，许多人工作得更好。因此，以抽象的方式谈论材料，然后对某一特定部分进行具体描述，以使其成为焦点，这通常是一种很好的方法。作者应关注正常路径。只有在有助于说明要点的情况下，才应讨论错误案例和拐点案例。
Our experience indicates that it is easiest to grasp protocol models when they are presented in visual form. We recommend a presentation format centered around a few key diagrams, with explanatory text for each. These diagrams should be simple and typically consist of "boxes and arrows" -- boxes representing the major components, arrows representing their relationships, and labels indicating important features.
我们的经验表明，当协议模型以可视形式呈现时，最容易掌握它们。我们推荐以几个关键图表为中心的演示格式，每个图表都有解释性文本。这些图表应该很简单，通常由“方框和箭头”组成——代表主要组件的方框、代表它们之间关系的箭头以及指示重要功能的标签。
We recommend a presentation structured in three parts to match the three questions mentioned in the previous sections. Each part should contain 1-3 diagrams intended to illustrate the relevant points.
我们建议将演示分为三个部分，以匹配前面章节中提到的三个问题。每个部分应包含1-3个图表，用于说明相关点。
The most critical task that a protocol model must perform is to explain what the protocol is trying to achieve. This provides crucial context for understanding how the protocol works, and whether it meets its goals. Given the desired goals, an experienced reviewer will usually have an idea of how they would approach the problem and, thus, be able to compare that approach with the approach taken by the protocol under review.
协议模型必须执行的最关键的任务是解释协议试图实现什么。这为理解协议如何工作以及它是否满足其目标提供了重要的背景。鉴于预期目标，经验丰富的审查员通常会知道他们将如何处理问题，从而能够将该方法与所审查的方案所采取的方法进行比较。
The "Problem" section of the model should start with a short statement of the environments in which the protocol is expected to be used. This section should describe the relevant entities and the likely scenarios under which they would participate in the protocol. The Problem section should feature a diagram of the major
模型的“问题”部分应该从协议预期使用的环境的简短陈述开始。本节应描述相关实体及其参与协议的可能情景。问题部分应该有一个主要问题的图表
communicating parties and their inter-relationships. It is particularly important to lay out the trust relationships between the various parties, as these are often unobvious.
沟通各方及其相互关系。特别重要的是要确定各方之间的信任关系，因为这些关系通常是不明显的。
STUN [STUN] is a UNilateral Self-Address Fixing (UNSAF) [UNSAF] protocol that allows a machine located behind a NAT to determine what its external apparent IP address is. Although STUN provides a complete and thorough description of the operation of the protocol, it does not provide a brief, up-front overview suitable for a quick understanding of its operation. The rest of this section shows what a suitable overview might look like.
STUN[STUN]是一种单边自地址固定（UNSAF）[UNSAF]协议，允许位于NAT后面的机器确定其外部外观IP地址。虽然STUN提供了协议操作的完整和彻底的描述，但它没有提供适合快速了解其操作的简要、预先概述。本节的其余部分显示了合适的概述。
Network Address Translation (NAT) makes it difficult to run a number of classes of service from behind the NAT gateway. This is particularly a problem when protocols need to advertise address/port pairs as part of the application layer protocol. Although the NAT can be configured to accept data destined for that port, address translation means the address that the application knows about is not the same as the one on which it is reachable.
网络地址转换（NAT）使得从NAT网关后面运行多种服务变得困难。当协议需要作为应用层协议的一部分公布地址/端口对时，这尤其是一个问题。尽管可以将NAT配置为接受目的地为该端口的数据，但地址转换意味着应用程序知道的地址与可访问的地址不同。
Consider the scenario represented in the figure below. A SIP client is initiating a session with a SIP server in which it wants the SIP server to send it some media. In its Session Description Protocol (SDP) [SDP] request it provides the IP address and port on which it is listening. However, unbeknownst to the client, a NAT is in the way. The NAT translates the IP address in the header, but unless it is SIP aware, it doesn't change the address in the request. The result is that the media goes into a black hole.
考虑下面图中所示的场景。SIP客户端正在启动与SIP服务器的会话，希望SIP服务器向其发送一些媒体。在其会话描述协议（SDP）[SDP]请求中，它提供正在侦听的IP地址和端口。然而，在客户端不知道的情况下，NAT正在阻碍。NAT转换报头中的IP地址，但除非它是SIP感知的，否则不会更改请求中的地址。结果是介质进入黑洞。
+-----------+
| SIP |
| Server |
| |
+-----------+
^
| [FROM: 198.203.2.1:8954]
| [MSG: SEND MEDIA TO 10.0.10.5:6791]
|
|
+-----------+
| |
| NAT |
--------------+ Gateway +----------------
| |
+-----------+
^
| [FROM: 10.0.10.5:6791]
| [MSG: SEND MEDIA TO 10.0.10.5:6791]
|
10.0.10.5
+-----------+
| SIP |
| Client |
| |
+-----------+
+-----------+
| SIP |
| Server |
| |
+-----------+
^
| [FROM: 198.203.2.1:8954]
| [MSG: SEND MEDIA TO 10.0.10.5:6791]
|
|
+-----------+
| |
| NAT |
--------------+ Gateway +----------------
| |
+-----------+
^
| [FROM: 10.0.10.5:6791]
| [MSG: SEND MEDIA TO 10.0.10.5:6791]
|
10.0.10.5
+-----------+
| SIP |
| Client |
| |
+-----------+
The purpose of STUN is to allow clients to detect this situation and determine the address mapping. They can then place the appropriate address in their application-level messages. This is done by using an external STUN server. That server is able to determine the translated address and tell the STUN client, as shown below.
STUN的目的是允许客户端检测这种情况并确定地址映射。然后，他们可以在应用程序级消息中放置适当的地址。这是通过使用外部STUN服务器完成的。该服务器能够确定翻译后的地址并告诉STUN客户端，如下所示。
+-----------+
| STUN |
| Server |
| |
+-----------+
^ |
[IP HDR FROM: 198.203.2.1:8954] | | [IP HDR TO: 198.203.2.1:8954]
[MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 198.203.2.1:8954]
| v
+-----------+
| |
| NAT |
--------------+ Gateway +----------------
| |
+-----------+
^ |
[IP HDR FROM: 10.0.10.5:6791] | | [IP HDR TO: 10.0.10.5:6791]
[MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 198.203.2.1:8954]
| v
10.0.10.5
+-----------+
| SIP |
| Client |
| |
+-----------+
+-----------+
| STUN |
| Server |
| |
+-----------+
^ |
[IP HDR FROM: 198.203.2.1:8954] | | [IP HDR TO: 198.203.2.1:8954]
[MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 198.203.2.1:8954]
| v
+-----------+
| |
| NAT |
--------------+ Gateway +----------------
| |
+-----------+
^ |
[IP HDR FROM: 10.0.10.5:6791] | | [IP HDR TO: 10.0.10.5:6791]
[MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 198.203.2.1:8954]
| v
10.0.10.5
+-----------+
| SIP |
| Client |
| |
+-----------+
Once the problem has been described, the next task is to give a broad overview of the protocol. This means showing, either in "ladder diagram" or "boxes and arrows" form, the protocol messages that flow between the various networking agents. This diagram should be accompanied with explanatory text that describes the purpose of each message and the MAJOR data elements.
一旦问题被描述出来，下一个任务就是对协议进行全面的概述。这意味着以“梯形图”或“框和箭头”形式显示在各种网络代理之间流动的协议消息。该图表应附有解释性文本，说明每条信息的目的和主要数据元素。
This section SHOULD NOT contain detailed descriptions of the protocol messages or of each data element. In particular, bit diagrams, ASN.1 modules, and XML schema SHOULD NOT be shown. The purpose of this section is not to provide a complete description of the protocol, but to provide enough of a map that a person reading the full protocol document can see where each specific piece fits.
本节不应包含协议消息或每个数据元素的详细描述。特别是，不应显示位图、ASN.1模块和XML模式。本节的目的不是提供协议的完整描述，而是提供足够的地图，以便阅读完整协议文件的人员能够看到每个特定部分的适用位置。
In certain cases, it may be helpful to provide a state machine description of the behavior of network elements. However, such state machines should be kept as minimal as possible. Remember that the purpose is to promote high-level comprehension, not complete understanding.
在某些情况下，提供网络元素行为的状态机描述可能会有所帮助。然而，这种状态机应该尽可能地保持最小。记住，目的是促进高级理解，而不是完全理解。
Datagram Congestion Control Protocol [DCCP] is a protocol for providing datagram transport with network-friendly congestion avoidance behavior. The DCCP base protocol document is over 100 pages long and the congestion control mechanisms themselves are separate. Therefore, it is very helpful to have a an architectural overview of DCCP that abstracts away the details. The remainder of this section is an attempt to do so.
数据报拥塞控制协议[DCCP]是一种为数据报传输提供网络友好拥塞避免行为的协议。DCCP基本协议文档长达100多页，拥塞控制机制本身是独立的。因此，对DCCP有一个架构性的概述是非常有帮助的，它可以抽象出细节。本节剩余部分将尝试这样做。
NOTE: The author of this document was on the DCCP review team and his experience with that document was one of the motivating factors for this document. Since the review, the DCCP authors have added some overview material, some of which derives from earlier versions of this document.
注：本文件的作者是DCCP审查小组的成员，他对该文件的经验是本文件的激励因素之一。自审查以来，DCCP作者添加了一些概述材料，其中一些来自本文档的早期版本。
Although DCCP is datagram-oriented like UDP, it is stateful like TCP. Connections go through the following phases:
虽然DCCP像UDP一样是面向数据报的，但它像TCP一样是有状态的。连接经历以下阶段：
1. Initiation 2. Feature negotiation 3. Data transfer 4. Termination
1. 启动2。专题讨论3。数据传输4。结束
As with TCP, the initiation phase of DCCP involves a three-way handshake, shown below.
与TCP一样，DCCP的启动阶段涉及三方握手，如下所示。
Client Server
------ ------
DCCP-Request ->
[Ports, Service,
Features]
<- DCCP-Response
[Features,
Cookie]
DCCP-Ack ->
[Features,
Cookie]
Client Server
------ ------
DCCP-Request ->
[Ports, Service,
Features]
<- DCCP-Response
[Features,
Cookie]
DCCP-Ack ->
[Features,
Cookie]
DCCP 3-way handshake
三次握手
In the DCCP-Request message, the client tells the server the name of the service it wants to talk to and the ports it wants to communicate on. Note that ports are not tightly bound to services, as they are in TCP or UDP common practice. It also starts feature negotiation. For pedagogical reasons, we will present feature negotiation
在DCCP请求消息中，客户机告诉服务器它想要与之通信的服务的名称以及它想要在其上通信的端口。请注意，端口并不像TCP或UDP中常见的做法那样紧密地绑定到服务。它还启动功能协商。出于教学方面的原因，我们将介绍专题讨论
separately in the next section. However, realize that the early phases of feature negotiation happen concurrently with initiation.
在下一节中分别介绍。但是，请注意，功能协商的早期阶段与启动同时发生。
In the DCCP-Response message, the server tells the client that it is willing to accept the connection and continues feature negotiation. In order to prevent SYN flood-style DOS attacks, DCCP incorporates an IKE-style cookie exchange. The server can provide the client with a cookie that contains all of the negotiation state. This cookie must be echoed by the client in the DCCP-Ack, thus removing the need for the server to keep state.
在DCCP响应消息中，服务器告诉客户端它愿意接受连接并继续功能协商。为了防止SYN洪水式DOS攻击，DCCP合并了IKE式cookie交换。服务器可以向客户端提供包含所有协商状态的cookie。客户端必须在DCCP Ack中回显此cookie，从而消除服务器保持状态的需要。
In the DCCP-Ack message, the client acknowledges the DCCP-Response and returns the cookie to permit the server to complete its side of the connection. As indicated above, this message may also include feature negotiation messages.
在DCCP Ack消息中，客户端确认DCCP响应并返回cookie以允许服务器完成其连接端。如上所述，该消息还可以包括功能协商消息。
In DCCP, feature negotiation is performed by attaching options to other DCCP packets. Thus, feature negotiation can be piggybacked on any other DCCP message. This allows feature negotiation during connection initiation as well as during data flow.
在DCCP中，通过将选项附加到其他DCCP数据包来执行特征协商。因此，特性协商可以在任何其他DCCP消息上进行。这允许在连接启动和数据流期间进行功能协商。
Somewhat unusually, DCCP features are one-sided. Thus, it's possible to have a different congestion control regime for data sent from client to server than from server to client.
有些不同寻常的是，DCCP功能是片面的。因此，对于从客户机发送到服务器的数据，有可能采用不同于从服务器发送到客户机的拥塞控制机制。
Feature negotiation is done with the Change and Confirm options. There are four feature negotiation options in all: Change L, Confirm L, Change R, and Confirm R. The "L" options are sent by the feature location, where the feature is maintained, and the "R" options are sent by the feature remote.
使用更改和确认选项完成功能协商。共有四个功能协商选项：更改L、确认L、更改R和确认R。“L”选项由维护功能的功能位置发送，“R”选项由功能远程发送。
A Change R message says to the peer "change this option setting on your side". The peer can respond with a Confirm L, meaning "I've changed it". Some features allow Change R options to contain multiple values, sorted in preference order. For example:
Changer消息对对等方说“更改您这边的此选项设置”。同伴可以用“确认L”来回答，意思是“我已经改变了”。某些功能允许Changer选项包含多个按首选项顺序排序的值。例如：
Client Server
------ ------
Change R(CCID, 2) -->
<-- Confirm L(CCID, 2)
* agreement that CCID/Server = 2 *
Client Server
------ ------
Change R(CCID, 2) -->
<-- Confirm L(CCID, 2)
* agreement that CCID/Server = 2 *
Change R(CCID, 3 4) -->
<-- Confirm L(CCID, 4, 4 2)
* agreement that CCID/Server = 4 *
Change R(CCID, 3 4) -->
<-- Confirm L(CCID, 4, 4 2)
* agreement that CCID/Server = 4 *
In the second exchange, the client requests that the server use either CCID 3 or CCID 4, with 3 preferred. The server chooses 4 and supplies its preference list, "4 2".
在第二次交换中，客户机请求服务器使用CCID3或CCID4，其中3个是首选的。服务器选择4并提供其首选项列表“4 2”。
The Change L and Confirm R options are used for feature negotiations that are initiated by the feature location. In the following example, the server requests that CCID/Server be set to 3 or 2 (with 3 being preferred), and the client agrees.
更改L和确认R选项用于由特征位置启动的特征协商。在下面的示例中，服务器请求将CCID/server设置为3或2（首选3），并且客户机同意。
Client Server
------ ------
<-- Change L(CCID, 3 2)
Confirm R(CCID, 3, 3 2) -->
* agreement that CCID/Server = 3 *
Client Server
------ ------
<-- Change L(CCID, 3 2)
Confirm R(CCID, 3, 3 2) -->
* agreement that CCID/Server = 3 *
Rather than have a single congestion control regime, as in TCP, DCCP offers a variety of negotiable congestion control regimes. The DCCP documents describe two congestion control regimes: additive increase, multiplicative decrease (CCID-2 [CCID2]), and TCP-friendly rate control (CCID-3 [CCID3]). CCID-2 is intended for applications that want maximum throughput. CCID-3 is intended for real-time applications that want smooth response to congestion.
与TCP中的单一拥塞控制机制不同，DCCP提供了多种可协商的拥塞控制机制。DCCP文档描述了两种拥塞控制机制：加性增加、乘性减少（CCID-2[CCID2]）和TCP友好速率控制（CCID-3[CCID3]）。CCID-2适用于需要最大吞吐量的应用程序。CCID-3适用于需要平滑响应拥塞的实时应用程序。
CCID-2's congestion control is extremely similar to that of TCP. The sender maintains a congestion window and sends packets until that window is full. Packets are Acked by the receiver. Dropped packets and ECN [ECN] are used to indicate congestion. The response to congestion is to halve the congestion window. One subtle difference between DCCP and TCP is that the Acks in DCCP must contain the sequence numbers of all received packets (within a given window), not just the highest sequence number, as in TCP.
CCID-2的拥塞控制与TCP非常相似。发送方保持一个拥塞窗口并发送数据包，直到该窗口已满。数据包由接收方确认。丢弃的数据包和ECN[ECN]用于指示拥塞。应对拥堵的措施是将拥堵窗口减半。DCCP和TCP之间的一个细微差别是，DCCP中的ACK必须包含所有接收数据包的序列号（在给定窗口内），而不仅仅是TCP中的最高序列号。
CCID-3 is an equation-based form of rate control, intended to provide smoother response to congestion than CCID-2. The sender maintains a "transmit rate". The receiver sends Ack packets that contain information about the receiver's estimate of packet loss. The sender uses this information to update its transmit rate. Although CCID-3 behaves somewhat differently than TCP in its short-term congestion response, it is designed to operate fairly with TCP over the long term.
CCID-3是一种基于等式的速率控制形式，旨在提供比CCID-2更平滑的拥塞响应。发送方保持“传输速率”。接收机发送包含关于接收机分组丢失估计的信息的Ack分组。发送方使用此信息更新其传输速率。尽管CCID-3在短期拥塞响应方面的行为与TCP稍有不同，但它的设计是为了在长期内公平地使用TCP。
Connection termination in DCCP is initiated by sending a Close message. Either side can send a Close message. The peer then responds with a Reset message, at which point the connection is closed. The side that sent the Close message must quietly preserve the socket in TIMEWAIT state for 2MSL.
DCCP中的连接终止通过发送关闭消息来启动。任何一方都可以发送关闭消息。然后，对等方以重置消息进行响应，此时连接关闭。发送关闭消息的那一方必须安静地将套接字保持在TIMEWAIT状态2MSL。
Client Server
------ ------
Close ->
<- Reset
[Remains in TIMEWAIT]
Client Server
------ ------
Close ->
<- Reset
[Remains in TIMEWAIT]
Note that the server may wish to close the connection but not remain in TIMEWAIT (e.g., due to a desire to minimize server-side state). In order to accomplish this, the server can elicit a Close from the client by sending a CloseReq message and, thus, keep the TIMEWAIT state on the client.
请注意，服务器可能希望关闭连接，但不希望保持时间等待（例如，由于希望最小化服务器端状态）。为了实现这一点，服务器可以通过发送CloseReq消息从客户机获取Close，从而在客户机上保持TIMEWAIT状态。
The final section (if there is one) should contain an explanation of any important protocol features that are not obvious from the previous sections. In the best case, all the important features of the protocol would be obvious from the message flow. However, this isn't always the case. This section is an opportunity for the author to explain those features. Authors should think carefully before writing this section. If there are no important points to be made, they should not populate this section.
最后一节（如果有）应包含对前几节中不明显的任何重要协议功能的解释。在最好的情况下，协议的所有重要特性都将从消息流中显而易见。然而，情况并非总是如此。本节是作者解释这些特征的一个机会。作者在撰写本节之前应仔细考虑。如果没有要点，则不应填写本节。
Examples of the kind of feature that belongs in this section include: high-level security considerations, congestion control information, and overviews of the algorithms that the network elements are intended to follow. For instance, if you have a routing protocol, you might use this section to sketch out the algorithm that the router uses to determine the appropriate routes from protocol messages.
本节所述功能的示例包括：高级安全注意事项、拥塞控制信息，以及网络元素打算遵循的算法概述。例如，如果您有一个路由协议，您可以使用本节来勾勒出路由器用于根据协议消息确定适当路由的算法。
The WebDAV standard [WEBDAV] is fairly terse, preferring to define the required behaviors and let the reader work out the implications. In some situations, explanatory material that details those implications can help the reader understand the overall model. The rest of this section describes one such case.
WebDAV标准[WebDAV]相当简洁，更倾向于定义所需的行为，并让读者了解其含义。在某些情况下，详细说明这些含义的解释性材料可以帮助读者理解整个模型。本节其余部分将介绍一个此类案例。
WebDAV [WEBDAV] includes both a COPY method and a MOVE method. While a MOVE can be thought of as a COPY followed by DELETE, COPY+DELETE and MOVE aren't entirely equivalent.
WebDAV[WebDAV]包括复制方法和移动方法。虽然移动可以被认为是先复制后删除，但复制+删除和移动并不完全等同。
The use of COPY+DELETE as a substitute for MOVE is problematic because of the creation of the intermediate file. Consider the case where the user is approaching a quota boundary. A COPY+DELETE should be forbidden because it would temporarily exceed the quota. However, a simple rename should work in this situation.
使用COPY+DELETE代替MOVE是有问题的，因为创建了中间文件。考虑用户接近配额边界的情况。应禁止复制+删除，因为它将暂时超过配额。然而，在这种情况下，一个简单的重命名应该可以工作。
The second issue is permissions. The WebDAV permissions model allows the server to grant users permission to rename files, but not to create new ones. This is unusual in ordinary filesystems, but nothing prevents it in WebDAV. This is clearly not possible if a client uses COPY+DELETE to do a MOVE.
第二个问题是权限。WebDAV权限模型允许服务器授予用户重命名文件的权限，但不允许创建新文件。这在普通文件系统中是不寻常的，但在WebDAV中没有什么可以阻止它。如果客户端使用COPY+DELETE进行移动，这显然是不可能的。
Finally, a COPY+DELETE does not produce the same logical result as would be expected with a MOVE. Because COPY creates a new resource, it is permitted (but not required) to use the time of new file creation as the creation date property. By contrast, the expectation for MOVE is that the renamed file will have the same properties as the original.
最后，复制+删除不会产生与移动预期相同的逻辑结果。因为复制创建了一个新资源，所以允许（但不是必需的）将创建新文件的时间用作创建日期属性。相比之下，移动的期望是重命名的文件将具有与原始文件相同的属性。
The requirement that Internet-Drafts and RFCs be renderable in ASCII is a significant obstacle when writing the sort of graphics-heavy document being described here. Authors may find it more convenient to do a separate protocol model document in Postscript or PDF and simply make it available at review time -- though an archival version would certainly be handy.
互联网草稿和RFC必须以ASCII格式呈现，这一要求在编写本文描述的那种图形化文档时是一个重大障碍。作者可能会发现，用Postscript或PDF编写一个单独的协议模型文档更方便，只需在审查时提供即可——尽管存档版本肯定很方便。
Internet Key Exchange (IKE) [IKE] is one of the most complicated security protocols ever designed by the IETF. Although the basic IKE core is a fairly straightforward Diffie-Hellman-based handshake, this can often be difficult for new readers to understand abstractly, apart from the protocol details. The remainder of this section provides overview of IKE suitable for those new readers.
因特网密钥交换（IKE）[IKE]是IETF设计的最复杂的安全协议之一。虽然基本的IKE核心是一个相当简单的基于Diffie-Hellman的握手，但对于新读者来说，除了协议细节之外，这通常很难抽象地理解。本节的其余部分提供了适用于这些新读者的IKE概述。
Internet key Exchange (IKE) [IKE] is a key establishment and parameter negotiation protocol for Internet protocols. Its primary application is for establishing security associations (SAs) [IPSEC] for IPsec AH [AH] and ESP [ESP].
Internet密钥交换（IKE）[IKE]是一种用于Internet协议的密钥建立和参数协商协议。它的主要应用是为IPSEC AH[AH]和ESP[ESP]建立安全关联（SAs）[IPSEC]。
+--------------------+ +--------------------+
| | | |
| +------------+ | | +------------+ |
| | Key | | IKE | | Key | |
| | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | |
| +------------+ | | +------------+ |
| ^ | | ^ |
| | | | | |
| v | | v |
| +------------+ | | +------------+ |
| | IPsec | | AH/ESP | | IPsec | |
| | Stack | <-+-----------------------+-> | Stack | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| Initiator | | Responder |
+--------------------+ +--------------------+
+--------------------+ +--------------------+
| | | |
| +------------+ | | +------------+ |
| | Key | | IKE | | Key | |
| | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | |
| +------------+ | | +------------+ |
| ^ | | ^ |
| | | | | |
| v | | v |
| +------------+ | | +------------+ |
| | IPsec | | AH/ESP | | IPsec | |
| | Stack | <-+-----------------------+-> | Stack | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| Initiator | | Responder |
+--------------------+ +--------------------+
The general deployment model for IKE is shown above. The IPsec engines and IKE engines typically are separate modules. When no security association exists for a packet that needs to be processed (either sent or received), the IPsec engine contacts the IKE engine and asks it to establish an appropriate SA. The IKE engine contacts the appropriate peer and uses IKE to establish the SA. Once the IKE handshake is finished it registers the SA with the IPsec engine.
IKE的通用部署模型如上图所示。IPsec引擎和IKE引擎通常是独立的模块。当需要处理（发送或接收）的数据包不存在安全关联时，IPsec引擎会联系IKE引擎并要求其建立适当的SA。IKE引擎联系适当的对等方并使用IKE建立SA。IKE握手完成后，它会向IPsec引擎注册SA。
In addition, IKE traffic between the peers can be used to refresh keying material or adjust operating parameters, such as algorithms.
此外，对等方之间的IKE通信可用于刷新键控材料或调整操作参数，如算法。
Although IPsec is basically symmetrical, IKE is not. The party who sends the first message is called the INITIATOR. The other party is called the RESPONDER. In the case of TCP connections, the INITIATOR will typically be the peer doing the active open (i.e., the client).
虽然IPsec基本上是对称的，但IKE不是。发送第一条消息的一方称为发起方。另一方称为响应者。在TCP连接的情况下，发起方通常是执行主动打开的对等方（即客户端）。
One of the major concerns in IKE design was that traffic be protected even if the keying material of the nodes was later compromised, provided that the session in question had terminated and so the session-specific keying material was gone. This property is often called Perfect Forward Secrecy (PFS) or back traffic protection.
IKE设计中的一个主要问题是，即使节点的键控材料后来被破坏，流量也会受到保护，前提是相关会话已终止，因此特定于会话的键控材料已消失。这种特性通常被称为完美前向保密（PFS）或后向流量保护。
Because IKE allows arbitrary peers to initiate computationally-expensive cryptographic operations, it potentially allows resource consumption denial of service (DoS) attacks to be mounted against the IKE engine. IKE includes countermeasures designed to minimize this risk.
由于IKE允许任意对等方发起计算代价高昂的加密操作，因此它可能允许针对IKE引擎发起资源消耗拒绝服务（DoS）攻击。IKE包括旨在将此风险降至最低的对策。
Because Security Associations are essentially symmetric, both sides must, in general, be authenticated. Because IKE needs to be able to establish SAs between a broad range of peers with various kinds of prior relationships, IKE supports a very flexible keying model. Peers can authenticate via shared keys, digital signatures (typically from keys vouched for by certificates), or encryption keys.
因为安全关联本质上是对称的，所以通常双方都必须经过身份验证。由于IKE需要能够在具有各种先验关系的广泛对等方之间建立SA，因此IKE支持非常灵活的键控模型。对等方可以通过共享密钥、数字签名（通常来自证书证明的密钥）或加密密钥进行身份验证。
Although IKE requires the peers to authenticate to each other, it was considered desirable by the working group to provide some identity protection for the communicating peers. In particular, the peers should be able to hide their identity from passive observers and one peer should be able to require the author to authenticate before they self-identity. In this case, the designers chose to make the party who speaks first (the INITIATOR) identify first.
尽管IKE要求对等方相互认证，但工作组认为为通信对等方提供某种身份保护是可取的。特别是，对等方应该能够对被动观察者隐藏自己的身份，并且一个对等方应该能够要求作者在确认自己的身份之前进行身份验证。在这种情况下，设计师选择让首先发言的一方（发起者）首先确定身份。
At a very high level, there are two kinds of IKE handshake:
在非常高的级别上，有两种IKE握手：
(1) Those that establish an IKE security association. (2) Those that establish an AH or ESP security association.
(1) 建立IKE安全协会的人。（2） 建立AH或ESP安全协会的机构。
When two peers that have never communicated before need to establish an AH/ESH SA, they must first establish an IKE SA. This allows them to exchange an arbitrary amount of protected IKE traffic. They can then use that SA to do a second handshake to establish SAs for AH and ESP. This process is shown in schematic form below. The notation E(SA,XXXX) is used to indicate that traffic is encrypted under a given SA.
当两个以前从未沟通过的对等方需要建立AH/ESH SA时，他们必须首先建立IKE SA。这允许它们交换任意数量的受保护IKE流量。然后，他们可以使用该SA进行第二次握手，以建立AH和ESP的SA。该过程如下图所示。符号E（SA，XXXX）用于表示在给定SA下对通信量进行了加密。
Initiator Responder
--------- ---------
Initiator Responder
--------- ---------
Handshake MSG -> \ Stage 1:
<- Handshake MSG \ Establish IKE
/ SA (IKEsa)
[...] /
Handshake MSG -> \ Stage 1:
<- Handshake MSG \ Establish IKE
/ SA (IKEsa)
[...] /
\ Stage 2:
E(IKEsa, Handshake MSG) -> \ Establish AH/ESP
<- E(IKEsa, Handshake MSG) / SA
\ Stage 2:
E(IKEsa, Handshake MSG) -> \ Establish AH/ESP
<- E(IKEsa, Handshake MSG) / SA
The two kinds of IKE handshake
两种握手方式
IKE terminology is somewhat confusing, referring under different circumstances to "phases" and "modes". For maximal clarity we will refer to the Establishment of the IKE SA as "Stage 1" and the Establishment of AH/ESP SAs as "Stage 2". Note that it's quite possible for there to be more than one Stage 2 handshake, once Stage 1 has been finished. This might be useful for establishing multiple AH/ESP SAs with different cryptographic properties.
IKE术语有些混乱，在不同的情况下指的是“阶段”和“模式”。为了最大程度地澄清，我们将IKE SA的建立称为“阶段1”，AH/ESP SA的建立称为“阶段2”。请注意，一旦第1阶段完成，第2阶段握手很可能不止一次。这可能有助于建立具有不同加密属性的多个AH/ESP SA。
The Stage 1 and Stage 2 handshakes are actually rather different, because the Stage 2 handshake can, of course, assume that its traffic is being protected with an IKE SA. Accordingly, we will first discuss Stage 1 and then Stage 2.
第1阶段和第2阶段的握手实际上是相当不同的，因为第2阶段的握手当然可以假定其通信量受到IKE SA的保护。因此，我们将首先讨论第1阶段，然后讨论第2阶段。
There are a large number of variants of the IKE Stage 1 handshake, necessitated by use of different authentication mechanisms. However, broadly speaking Stage 1 handshakes fall into one of two basic categories: MAIN MODE, which provides identity protection and DoS resistance, and AGGRESSIVE MODE, which does not. We will cover MAIN MODE first.
IKE第1阶段握手有许多变体，需要使用不同的身份验证机制。但是，从广义上讲，第1阶段握手可分为两种基本类型之一：提供身份保护和拒绝服务抵抗的主模式和不提供身份保护和拒绝服务抵抗的攻击模式。我们将首先介绍主模式。
Main Mode is a six message (3 round trip) handshake, which offers identity protection and DoS resistance. An overview of the handshake is below.
主模式为六信息（3次往返）握手，提供身份保护和拒绝拒绝服务。下面是握手的概述。
Initiator Responder
--------- ---------
CookieI, Algorithms -> \ Parameter
<- CookieR, Algorithms / Establishment
Initiator Responder
--------- ---------
CookieI, Algorithms -> \ Parameter
<- CookieR, Algorithms / Establishment
CookieR, Nonce, Key Exchange -> <- Nonce, Key Exchange\ Establish / Shared key
CookieR，Nonce，密钥交换-><-Nonce，密钥交换\建立/共享密钥
E(IKEsa, Auth Data) ->
<- E(IKEsa, Auth data)\ Authenticate
/ Peers
E(IKEsa, Auth Data) ->
<- E(IKEsa, Auth data)\ Authenticate
/ Peers
IKE Main Mode handshake (Stage 1)
IKE主模式握手（第1阶段）
In the first round trip, the Initiator offers a set of algorithms and parameters. The Responder picks out the single set that it likes and responds with that set. It also provides CookieR, which will be used to prevent DoS attacks. At this point, there is no secure association but the peers have tentatively agreed upon parameters. These parameters include a Diffie-Hellman (DH) group, which will be used in the second round trip.
在第一次往返中，启动器提供一组算法和参数。响应者挑选出它喜欢的单个集合，并用该集合进行响应。它还提供CookieR，用于防止DoS攻击。此时，不存在安全关联，但对等方已初步商定了参数。这些参数包括Diffie-Hellman（DH）组，该组将用于第二次往返。
In the second round trip, the Initiator sends the key exchange information. This generally consists of the Initiator's Diffie-Hellman public share (Yi). He also supplies CookieR, which was provided by the responder. The Responder replies with his own DH share (Yr). At this point, both Initiator and Responder can compute the shared DH key (ZZ). However, there has been no authentication and, therefore, they don't know with any certainty that the connection hasn't been attacked. Note that as long as the peers generate fresh DH shares for each handshake, PFS will be provided.
在第二次往返中，启动器发送密钥交换信息。这通常包括发起人的Diffie-Hellman公共共享（Yi）。他还提供CookieR，由响应者提供。响应者用自己的DH份额（Yr）进行回复。此时，发起方和响应方都可以计算共享DH密钥（ZZ）。但是，没有身份验证，因此，他们无法确定连接是否未受到攻击。请注意，只要对等方为每次握手生成新的DH共享，就会提供PFS。
Before we move on, let's take a look at the cookie exchange. The basic anti-DoS measure used by IKE is to force the peer to demonstrate that it can receive traffic from you. This foils blind attacks like SYN floods [SYNFLOOD] and also makes it somewhat easier to track down attackers. The cookie exchange serves this role in IKE. The Responder can verify that the Initiator supplied a valid CookieR before doing the expensive DH key agreement. This does not totally eliminate DoS attacks, because an attacker who was willing to reveal his location could still consume server resources; but it does protect against a certain class of blind attack.
在我们继续之前，让我们来看看Cookie交换。IKE使用的基本反DoS措施是强制对等方证明它可以接收来自您的流量。这可以阻止像SYNFLOOD[SYNFLOOD]这样的盲目攻击，同时也使追踪攻击者变得更加容易。cookie交换在IKE中扮演这个角色。响应者可以在执行昂贵的DH密钥协议之前验证启动器是否提供了有效的CookieR。这并不能完全消除DoS攻击，因为愿意透露其位置的攻击者仍可能消耗服务器资源；但它确实可以防止某种类型的盲目攻击。
In the final round trip, the peers establish their identities. Because they share an (unauthenticated) key, they can send their identities encrypted, thus providing identity protection from eavesdroppers. The exact method of proving identity depends on what form of credential is being used (signing key, encryption key, shared secret, etc.), but in general you can think of it as a signature over some subset of the handshake messages. So, each side would supply its certificate and then sign using the key associated with that certificate. If shared keys are used, the authentication data would be a key ID and a MAC. Authentication using public key encryption follows similar principles, but is more complicated. Refer to the IKE document for more details.
在最后一次往返中，同伴们建立了自己的身份。因为他们共享一个（未经验证的）密钥，所以他们可以发送加密的身份，从而提供身份保护以防被窃听。证明身份的确切方法取决于使用何种形式的凭证（签名密钥、加密密钥、共享密钥等），但通常您可以将其视为握手消息某个子集上的签名。因此，每一方都将提供其证书，然后使用与该证书相关联的密钥进行签名。如果使用共享密钥，身份验证数据将是密钥ID和MAC。使用公钥加密的身份验证遵循类似的原则，但更为复杂。有关更多详细信息，请参阅IKE文档。
At the end of the Main Mode handshake, the peers share:
在主模式握手结束时，对等方共享：
(1) A set of algorithms for encryption of further IKE traffic. (2) Traffic encryption and authentication keys. (3) Mutual knowledge of the peer's identity.
(1) 用于进一步IKE通信加密的一组算法。（2） 流量加密和身份验证密钥。（3） 对同伴身份的相互了解。
Although IKE Main Mode provides the required services, there was concern that the large number of round trips required added, excessive latency. Accordingly, an Aggressive Mode was defined. Aggressive mode packs more data into fewer messages, and thus reduces latency. However, it does not provide identity protection or protection against DoS.
虽然IKE主模式提供了所需的服务，但有人担心，所需的大量往返会增加额外的延迟。因此，定义了攻击模式。主动模式将更多数据打包到更少的消息中，从而减少延迟。但是，它不提供身份保护或拒绝服务保护。
Initiator Responder
--------- ---------
Algorithms, Nonce,
Key Exchange, ->
<- Algorithms, Nonce,
Key Exchange, Auth Data
Auth Data ->
Initiator Responder
--------- ---------
Algorithms, Nonce,
Key Exchange, ->
<- Algorithms, Nonce,
Key Exchange, Auth Data
Auth Data ->
IKE Aggressive Mode Handshake (Stage 1)
IKE主动模式握手（第1阶段）
After the first round trip, the peers have all the required properties, but the Initiator has not authenticated to the Responder. The third message closes the loop by authenticating the Initiator. Note that since the authentication data is sent in the clear, no identity protection is provided; and because the Responder does the DH key agreement without a round trip to the Initiator, there is no DoS protection
在第一次往返之后，对等方具有所有必需的属性，但发起方尚未向响应方进行身份验证。第三条消息通过验证启动器来关闭循环。注意，由于认证数据以明文形式发送，因此不提供身份保护；而且，由于响应程序执行DH密钥协议，而不需要往返到启动器，因此没有DoS保护
Stage 1 on its own isn't very useful. The purpose of IKE, after all, is to establish associations to be used to protect other traffic, not merely to establish IKE SAs. Stage 2 (what IKE calls "Quick Mode") is used for this purpose. The basic Stage 2 handshake is shown below.
阶段1本身不是很有用。毕竟，IKE的目的是建立用于保护其他流量的关联，而不仅仅是建立IKE SA。第2阶段（IKE称之为“快速模式”）用于此目的。基本的第2阶段握手如下所示。
Initiator Responder
--------- ---------
AH/ESP parameters,
Algorithms, Nonce,
Handshake Hash ->
<- AH/ESP parameters,
Algorithms, Nonce,
Handshake Hash
Handshake Hash ->
Initiator Responder
--------- ---------
AH/ESP parameters,
Algorithms, Nonce,
Handshake Hash ->
<- AH/ESP parameters,
Algorithms, Nonce,
Handshake Hash
Handshake Hash ->
The Basic IKE Quick Mode (Stage 2)
基本IKE快速模式（第2阶段）
As with quick mode, the first two messages establish the algorithms and parameters while the final message is a check over the previous messages. In this case, the parameters also include the transforms to be applied to the traffic (AH or ESP) and the kinds of traffic that are to be protected. Note that there is no key exchange information shown in these messages.
与快速模式一样，前两条消息建立算法和参数，而最后一条消息是对前面消息的检查。在这种情况下，参数还包括要应用于流量（AH或ESP）的变换以及要保护的流量类型。请注意，这些消息中没有显示密钥交换信息。
In this version of Quick Mode, the peers use the preexisting Stage 1 keying material to derive fresh keying material for traffic protection (with the nonces to ensure freshness). Quick mode also allows for a new Diffie-Hellman handshake for per-traffic key PFS. In that case, the first two messages shown above would also include Key Exchange payloads, as shown below.
在此版本的快速模式中，对等方使用先前存在的第1阶段键控材料来派生用于流量保护的新键控材料（使用nonce以确保新鲜度）。快速模式还允许针对每个流量密钥PFS进行新的Diffie-Hellman握手。在这种情况下，上面显示的前两条消息还将包括密钥交换有效负载，如下所示。
Initiator Responder
--------- ---------
AH/ESP parameters,
Algorithms, Nonce,
Key Exchange, ->
Handshake Hash
<- AH/ESP parameters,
Algorithms, Nonce,
Key Exchange,
Handshake Hash
Handshake Hash ->
Initiator Responder
--------- ---------
AH/ESP parameters,
Algorithms, Nonce,
Key Exchange, ->
Handshake Hash
<- AH/ESP parameters,
Algorithms, Nonce,
Key Exchange,
Handshake Hash
Handshake Hash ->
A Variant of Quick Mode with PFS (Stage 2)
带PFS的快速模式变体（第2阶段）
There are a number of features of IKE that deserve special consideration. They are discussed here.
IKE有许多特性值得特别考虑。这里讨论这些问题。
As mentioned previously, IKE uses cookies as a partial defense against DoS attacks. When the responder receives Main Mode message 3 containing the Key Exchange data and the cookie, it verifies that the cookie is correct. However, this verification must not involve having a list of valid cookies. Otherwise, an attacker could potentially consume arbitrary amounts of memory by repeatedly requesting cookies from a responder. The recommended way to generate a cookie, as suggested by Phil Karn, is to have a single master key and compute a hash of the secret and the initiator's address information. This cookie can be verified by recomputing the cookie value based on information in the third message, and seeing if it matches.
如前所述，IKE使用cookie作为DoS攻击的部分防御。当响应程序接收到包含密钥交换数据和cookie的主模式消息3时，它将验证cookie是否正确。但是，此验证不得包含有效cookie的列表。否则，攻击者可能会通过重复请求响应者的Cookie来消耗任意数量的内存。正如Phil Karn所建议的那样，生成cookie的推荐方法是使用一个主密钥并计算机密和启动器地址信息的散列。可以通过基于第三条消息中的信息重新计算cookie值并查看其是否匹配来验证此cookie。
So far we have been rather vague about what kinds of endpoint identities are used. In principle, there are three ways a peer might be identified: by a shared key, a pre-configured public key, or a certificate.
到目前为止，我们对所使用的端点标识的类型还相当模糊。原则上，有三种方法可以识别对等方：通过共享密钥、预配置公钥或证书。
In a shared key scheme, the peers share a symmetric key. This key is associated with a key identifier, which is known to both parties. It is assumed that the party verifying that identity also has a table that indicates for which traffic (i.e., what addresses) that identity is allowed to negotiate SAs.
在共享密钥方案中，对等方共享对称密钥。该密钥与双方都知道的密钥标识符相关联。假设验证该身份的一方还具有一个表，该表指示允许该身份协商哪些流量（即，哪些地址）。
A pre-configured public key scheme is the same as a shared key scheme except that the verifying party has the authenticating party's public key instead of a shared key.
预配置的公钥方案与共享密钥方案相同，只是验证方拥有验证方的公钥而不是共享密钥。
In a certificate scheme, the authenticating party presents a certificate containing their public key. It is straightforward to establish that this certificate matches the authentication data provided by the peer. What is less straightforward is to determine whether a given peer is entitled to negotiate for a given class of traffic. In theory, one might be able to determine this from the name in the certificate (e.g., the subject name contains an IP address that matches the ostensible IP address). In practice, this is not clearly specified in IKE and, therefore, is not really interoperable. Currently, it is likely that a configuration table maps certificates to policies, as in the other two authentication schemes.
在证书方案中，认证方提供包含其公钥的证书。很容易确定此证书与对等方提供的身份验证数据相匹配。不那么简单的是确定给定的对等方是否有权为给定的流量类别进行协商。理论上，可以通过证书中的名称来确定这一点（例如，使用者名称包含与表面上的IP地址匹配的IP地址）。在实践中，IKE中没有明确规定这一点，因此，并不真正具有互操作性。目前，配置表可能会将证书映射到策略，就像在其他两个身份验证方案中一样。
This document does not define any protocols and therefore has no security issues.
本文档未定义任何协议，因此没有安全问题。
A. Appendix: IAB Members at the Time of This Writing
附录：撰写本文时的IAB成员
Bernard Aboba Harald Alvestrand Rob Austein Leslie Daigle Patrik Falstrom Sally Floyd Jun-ichiro Itojun Hagino Mark Handley Bob Hinden Geoff Huston Eric Rescorla Pete Resnick Jonathan Rosenberg
Bernard Aboba Harald Alvestrand Rob Austein Leslie Daigle Patrik Falstrom Sally Floyd Jun ichiro Itojun Hagino Mark Handley Bob Hinden Geoff Huston Eric Rescorla Pete Resnick Jonathan Rosenberg
Normative References
规范性引用文件
There are no normative references for this document.
本文件无规范性参考文件。
Informative References
资料性引用
[AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[CCID2] Floyd, S. and E. Kohler, "Profile for DCCP Congestion Control ID 2: TCP-like Congestion Control", Work in Progress, October 2003.
[CCID2]Floyd，S.和E.Kohler，“DCCP拥塞控制ID 2的配置文件：类似TCP的拥塞控制”，正在进行的工作，2003年10月。
[CCID3] Floyd, S., Kohler, E., and J. Padhye, "Profile for DCCP Congestion Control ID 3: TFRC Congestion Control", Work in Progress, February 2004.
[CCID3]Floyd，S.，Kohler，E.，和J.Padhye，“DCCP拥塞控制ID 3的配置文件：TFRC拥塞控制”，正在进行的工作，2004年2月。
[DCCP] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", Work in Progress, November 2004.
[DCCP]Kohler，E.，Handley，M.，和S.Floyd，“数据报拥塞控制协议（DCCP）”，正在进行的工作，2004年11月。
[ECN] Ramakrishnan, K. Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[ECN]Ramakrishnan，K.Floyd，S.和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]Kent，S.和R.Atkinson，“IP封装安全有效负载（ESP）”，RFC 2406，1998年11月。
[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月。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[KERBEROS]Kohl，J.和C.Neuman，“KERBEROS网络身份验证服务（V5）”，RFC15101993年9月。
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description Protocol" RFC 2327, April 1998.
[SDP]Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP)", RFC 3489, March 2003.
[STUN]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-用户数据报协议（UDP）的简单遍历”，RFC 3489，2003年3月。
[SYNFLOOD] CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks <http://www.cert.org/advisories/CA-1996-21.html>, September 19, 1996.
[SYNFLOOD]证书咨询CA-1996-21 TCP SYN洪泛和IP欺骗攻击<http://www.cert.org/advisories/CA-1996-21.html>，1996年9月19日。
[UNSAF] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[UNSAF]Daigle，L.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[WEBDAV] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[WEBDAV]Goland，Y.，Whitehead，E.，Faizi，A.，Carter，S.，和D.Jensen，“分布式创作的HTTP扩展——WEBDAV”，RFC25181999年2月。
Authors' Addresses
作者地址
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303
Eric Rescorla RTFM，Inc.加利福尼亚州帕洛阿尔托埃奇伍德大道2064号，邮编94303
Phone: (650)-320-8549 EMail: ekr@rtfm.com
电话：（650）-320-8549电子邮件：ekr@rtfm.com
Internet Architecture Board IAB
互联网架构委员会
EMail: iab@iab.org
EMail: iab@iab.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。