Network Working Group S. Hollenbeck
Request for Comments: 4934 VeriSign, Inc.
Obsoletes: 3734 May 2007
Category: Standards Track
Network Working Group S. Hollenbeck
Request for Comments: 4934 VeriSign, Inc.
Obsoletes: 3734 May 2007
Category: Standards Track
Extensible Provisioning Protocol (EPP) Transport over TCP
TCP上的可扩展资源调配协议（EPP）传输
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 3734.
本文档描述如何将可扩展资源调配协议（EPP）会话映射到单个传输控制协议（TCP）连接。此映射需要使用传输层安全性（TLS）协议来保护EPP客户端和EPP服务器之间交换的信息。本文件淘汰了RFC 3734。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . . 2
2. Session Management . . . . . . . . . . . . . . . . . . . . . . 2
3. Message Exchange . . . . . . . . . . . . . . . . . . . . . . . 2
4. Data Unit Format . . . . . . . . . . . . . . . . . . . . . . . 5
5. Transport Considerations . . . . . . . . . . . . . . . . . . . 5
6. Internationalization Considerations . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Changes from RFC 3734 . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . . 2
2. Session Management . . . . . . . . . . . . . . . . . . . . . . 2
3. Message Exchange . . . . . . . . . . . . . . . . . . . . . . . 2
4. Data Unit Format . . . . . . . . . . . . . . . . . . . . . . . 5
5. Transport Considerations . . . . . . . . . . . . . . . . . . . 5
6. Internationalization Considerations . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Changes from RFC 3734 . . . . . . . . . . . . . . . . 9
This document describes how the Extensible Provisioning Protocol (EPP) is mapped onto a single client-server TCP connection. Security services beyond those defined in EPP are provided by the Transport Layer Security (TLS) Protocol [RFC2246]. EPP is described in [RFC4930]. TCP is described in [RFC0793]. This document obsoletes RFC 3734 [RFC3734].
本文档描述如何将可扩展资源调配协议（EPP）映射到单个客户机-服务器TCP连接。EPP中定义的安全服务以外的安全服务由传输层安全（TLS）协议[RFC2246]提供。[RFC4930]中描述了EPP。[RFC0793]中描述了TCP。本文件废除了RFC 3734[RFC3734]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Mapping EPP session management facilities onto the TCP service is straightforward. An EPP session first requires creation of a TCP connection between two peers, one that initiates the connection request and one that responds to the connection request. The initiating peer is called the "client", and the responding peer is called the "server". An EPP server MUST listen for TCP connection requests on a standard TCP port assigned by IANA.
将EPP会话管理设施映射到TCP服务非常简单。EPP会话首先需要在两个对等方之间创建TCP连接，一个启动连接请求，另一个响应连接请求。发起方称为“客户机”，响应方称为“服务器”。EPP服务器必须在IANA分配的标准TCP端口上侦听TCP连接请求。
The client MUST issue an active OPEN call, specifying the TCP port number on which the server is listening for EPP connection attempts. The EPP server MUST return an EPP <greeting> to the client after the TCP session has been established.
客户端必须发出活动的OPEN调用，指定服务器正在侦听EPP连接尝试的TCP端口号。TCP会话建立后，EPP服务器必须向客户端返回EPP<greeting>。
An EPP session is normally ended by the client issuing an EPP <logout> command. A server receiving an EPP <logout> command MUST end the EPP session and close the TCP connection with a CLOSE call. A client MAY end an EPP session by issuing a CLOSE call.
EPP会话通常由客户端发出EPP<logout>命令来结束。接收EPP<logout>命令的服务器必须结束EPP会话，并通过close调用关闭TCP连接。客户端可以通过发出关闭调用来结束EPP会话。
A server MAY limit the life span of an established TCP connection. EPP sessions that are inactive for more than a server-defined period MAY be ended by a server issuing a CLOSE call. A server MAY also close TCP connections that have been open and active for longer than a server-defined period.
服务器可能会限制已建立TCP连接的寿命。超过服务器定义的时间段处于非活动状态的EPP会话可能会由服务器发出关闭调用来结束。服务器还可以关闭已打开并处于活动状态超过服务器定义时间的TCP连接。
With the exception of the EPP server greeting, EPP messages are initiated by the EPP client in the form of EPP commands. An EPP server MUST return an EPP response to an EPP command on the same TCP connection that carried the command. If the TCP connection is closed after a server receives and successfully processes a command but
除EPP服务器问候语外，EPP消息由EPP客户端以EPP命令的形式启动。EPP服务器必须在承载该命令的同一TCP连接上返回对EPP命令的EPP响应。如果TCP连接在服务器接收并成功处理命令后关闭，但
before the response can be returned to the client, the server MAY attempt to undo the effects of the command to ensure a consistent state between the client and the server. EPP commands are idempotent, so processing a command more than once produces the same net effect on the repository as successfully processing the command once.
在将响应返回到客户端之前，服务器可能会尝试撤消命令的效果，以确保客户端和服务器之间的状态一致。EPP命令是幂等的，因此多次处理命令会在存储库中产生与成功处理命令一次相同的净效果。
An EPP client streams EPP commands to an EPP server on an established TCP connection. A client MUST NOT distribute commands from a single EPP session over multiple TCP connections. A client MAY establish multiple TCP connections to support multiple EPP sessions with each session mapped to a single connection. A server SHOULD limit a client to a maximum number of TCP connections based on server capabilities and operational load.
EPP客户端通过已建立的TCP连接将EPP命令流式传输到EPP服务器。客户端不得通过多个TCP连接分发来自单个EPP会话的命令。客户端可以建立多个TCP连接以支持多个EPP会话，每个会话映射到单个连接。服务器应根据服务器功能和操作负载将客户端限制为最大TCP连接数。
EPP describes client-server interaction as a command-response exchange where the client sends one command to the server and the server returns one response to the client. A client might be able to realize a slight performance gain by pipelining (sending more than one command before a response for the first command is received) commands with TCP transport, but this feature does not change the basic single command, single response operating mode of the core protocol.
EPP将客户机-服务器交互描述为命令-响应交换，其中客户机向服务器发送一个命令，服务器向客户机返回一个响应。客户机可能能够通过TCP传输管道化（在接收到第一个命令的响应之前发送多个命令）命令来实现轻微的性能提升，但此功能不会改变核心协议的基本单命令、单响应操作模式。
Each EPP data unit MUST contain a single EPP message. Commands MUST be processed independently and in the same order as sent from the client.
每个EPP数据单元必须包含一条EPP消息。命令必须独立处理，处理顺序与从客户端发送的顺序相同。
A server SHOULD impose a limit on the amount of time required for a client to issue a well-formed EPP command. A server SHOULD end an EPP session and close an open TCP connection if a well-formed command is not received within the time limit.
服务器应限制客户端发出格式良好的EPP命令所需的时间。如果在时间限制内未收到格式良好的命令，服务器应结束EPP会话并关闭打开的TCP连接。
A general state machine for an EPP server is described in Section 2 of [RFC4930]. General client-server message exchange using TCP transport is illustrated in Figure 1.
[RFC4930]第2节描述了EPP服务器的通用状态机。使用TCP传输的通用客户机-服务器消息交换如图1所示。
Client Server
| |
| Connect |
| >>------------------------------->> |
| |
| Send Greeting |
| <<-------------------------------<< |
| |
| Send <login> |
| >>------------------------------->> |
| |
| Send Response |
| <<-------------------------------<< |
| |
| Send Command |
| >>------------------------------->> |
| |
| Send Response |
| <<-------------------------------<< |
| |
| Send Command X |
| >>------------------------------->> |
| |
| Send Command Y |
| >>---------------+ |
| | |
| | |
| Send Response X |
| <<---------------(---------------<< |
| | |
| | |
| +--------------->> |
| |
| Send Response Y |
| <<-------------------------------<< |
| |
| Send <logout> |
| >>------------------------------->> |
| |
| Send Response & Disconnect |
| <<-------------------------------<< |
| |
Client Server
| |
| Connect |
| >>------------------------------->> |
| |
| Send Greeting |
| <<-------------------------------<< |
| |
| Send <login> |
| >>------------------------------->> |
| |
| Send Response |
| <<-------------------------------<< |
| |
| Send Command |
| >>------------------------------->> |
| |
| Send Response |
| <<-------------------------------<< |
| |
| Send Command X |
| >>------------------------------->> |
| |
| Send Command Y |
| >>---------------+ |
| | |
| | |
| Send Response X |
| <<---------------(---------------<< |
| | |
| | |
| +--------------->> |
| |
| Send Response Y |
| <<-------------------------------<< |
| |
| Send <logout> |
| >>------------------------------->> |
| |
| Send Response & Disconnect |
| <<-------------------------------<< |
| |
Figure 1: TCP Client-Server Message Exchange
图1:TCP客户机-服务器消息交换
The EPP data unit contains two fields: a 32-bit header that describes the total length of the data unit, and the EPP XML instance. The length of the EPP XML instance is determined by subtracting four octets from the total length of the data unit. A receiver must successfully read that many octets to retrieve the complete EPP XML instance before processing the EPP message.
EPP数据单元包含两个字段：描述数据单元总长度的32位标头和EPP XML实例。EPP XML实例的长度是通过从数据单元的总长度中减去四个八位字节来确定的。在处理EPP消息之前，接收方必须成功读取这么多个八位字节才能检索完整的EPP XML实例。
EPP Data Unit Format (one tick mark represents one bit position):
EPP数据单元格式（一个记号表示一位位置）：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EPP XML Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EPP XML Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Total Length (32 bits): The total length of the EPP data unit measured in octets in network (big endian) byte order. The octets contained in this field MUST be included in the total length calculation.
总长度（32位）：EPP数据单元的总长度，以网络（大端）字节顺序的八位字节为单位。此字段中包含的八位字节必须包含在总长度计算中。
EPP XML Instance (variable length): The EPP XML instance carried in the data unit.
EPP XML实例（可变长度）：数据单元中携带的EPP XML实例。
Section 2.1 of the EPP core protocol specification [RFC4930] describes considerations to be addressed by protocol transport mappings. This mapping addresses each of the considerations using a combination of features described in this document and features provided by TCP as follows:
EPP核心协议规范[RFC4930]第2.1节描述了协议传输映射需要考虑的事项。此映射使用本文档中描述的功能和TCP提供的功能的组合来解决每个注意事项，如下所示：
- TCP includes features to provide reliability, flow control, ordered delivery, and congestion control. Section 1.5 of RFC 793 [RFC0793] describes these features in detail; congestion control principles are described further in RFC 2581 [RFC2581] and RFC 2914 [RFC2914]. TCP is a connection-oriented protocol, and Section 2 of this mapping describes how EPP sessions are mapped to TCP connections.
- TCP包括提供可靠性、流量控制、有序交付和拥塞控制的功能。RFC 793[RFC0793]第1.5节详细描述了这些特性；RFC 2581[RFC2581]和RFC 2914[RFC2914]中进一步描述了拥塞控制原理。TCP是一种面向连接的协议，本映射的第2节描述了如何将EPP会话映射到TCP连接。
- Sections 2 and 3 of this mapping describe how the stateful nature of EPP is preserved through managed sessions and controlled message exchanges.
- 该映射的第2节和第3节描述了如何通过托管会话和受控消息交换来保持EPP的状态性质。
- Section 3 of this mapping notes that command pipelining is possible with TCP, though batch-oriented processing (combining multiple EPP commands in a single data unit) is not permitted.
- 此映射的第3节指出，命令管道可以通过TCP实现，但不允许面向批处理的处理（在单个数据单元中组合多个EPP命令）。
- Section 4 of this mapping describes features to frame data units by explicitly specifying the number of octets used to represent a data unit.
- 此映射的第4节通过明确指定用于表示数据单元的八位字节数来描述帧数据单元的功能。
This mapping does not introduce or present any internationalization or localization issues.
此映射不会引入或呈现任何国际化或本地化问题。
System port number 700 has been assigned by the IANA for mapping EPP onto TCP.
IANA已分配系统端口号700，用于将EPP映射到TCP。
User port number 3121 (which was used for development and test purposes) has been reclaimed by the IANA.
IANA已回收用户端口号3121（用于开发和测试目的）。
EPP as-is provides only simple client authentication services using identifiers and plain text passwords. A passive attack is sufficient to recover client identifiers and passwords, allowing trivial command forgery. Protection against most other common attacks MUST be provided by other layered protocols.
EPP原样仅提供使用标识符和纯文本密码的简单客户端身份验证服务。被动攻击足以恢复客户端标识符和密码，从而允许少量命令伪造。针对大多数其他常见攻击的保护必须由其他分层协议提供。
When layered over TCP, the Transport Layer Security (TLS) Protocol version 1.0 [RFC2246] or its successors (such as TLS 1.1 [RFC4346]), using the latest version supported by both parties, MUST be used to provide integrity, confidentiality, and mutual strong client-server authentication. Implementations of TLS often contain a weak cryptographic mode that SHOULD NOT be used to protect EPP. Clients and servers desiring high security SHOULD instead use TLS with cryptographic algorithms that are less susceptible to compromise.
在TCP上分层时，必须使用传输层安全（TLS）协议版本1.0[RFC2246]或其后续版本（如TLS 1.1[RFC4346]），使用双方支持的最新版本，以提供完整性、机密性和相互强大的客户机-服务器身份验证。TLS的实现通常包含不应用于保护EPP的弱加密模式。需要高安全性的客户机和服务器应改为使用TLS和不易被破坏的加密算法。
Mutual client and server authentication using the TLS Handshake Protocol is REQUIRED. Signatures on the complete certification path for both client machine and server machine MUST be validated as part of the TLS handshake. Information included in the client and server certificates, such as validity periods and machine names, MUST also be validated. A complete description of the issues associated with certification path validation can be found in RFC 3280 [RFC3280]. EPP service MUST NOT be granted until successful completion of a TLS
需要使用TLS握手协议进行客户端和服务器的相互身份验证。客户端计算机和服务器计算机的完整认证路径上的签名必须作为TLS握手的一部分进行验证。还必须验证客户端和服务器证书中包含的信息，如有效期和计算机名称。有关认证路径验证相关问题的完整说明，请参见RFC 3280[RFC3280]。在成功完成TLS之前，不得授予EPP服务
handshake and certificate validation, ensuring that both the client machine and the server machine have been authenticated and cryptographic protections are in place.
握手和证书验证，确保客户端计算机和服务器计算机都已通过身份验证，并且密码保护已到位。
Authentication using the TLS Handshake Protocol confirms the identity of the client and server machines. EPP uses an additional client identifier and password to identify and authenticate the client's user identity to the server, supplementing the machine authentication provided by TLS. The identity described in the client certificate and the identity described in the EPP client identifier can differ, as a server can assign multiple user identities for use from any particular client machine. Acceptable certificate identities MUST be negotiated between client operators and server operators using an out-of-band mechanism. Presented certificate identities MUST match negotiated identities before EPP service is granted.
使用TLS握手协议的身份验证确认客户端和服务器机器的身份。EPP使用一个附加的客户端标识符和密码来向服务器标识和验证客户端的用户身份，以补充TLS提供的机器身份验证。客户端证书中描述的标识和EPP客户端标识符中描述的标识可能不同，因为服务器可以分配多个用户标识，以便从任何特定的客户端计算机使用。必须使用带外机制在客户端操作员和服务器操作员之间协商可接受的证书标识。在授予EPP服务之前，提供的证书标识必须与协商的标识匹配。
There is a risk of login credential compromise if a client does not properly identify a server before attempting to establish an EPP session. Before sending login credentials to the server, a client needs to confirm that the server certificate received in the TLS handshake is an expected certificate for the server. A client also needs to confirm that the greeting received from the server contains expected identification information. After establishing a TLS session and receiving an EPP greeting on a protected TCP connection, clients MUST compare the certificate subject and/or subjectAltName to expected server identification information and abort processing if a mismatch is detected. If certificate validation is successful, the client then needs to ensure that the information contained in the received certificate and greeting is consistent and appropriate. As described above, both checks typically require an out-of-band exchange of information between client and server to identify expected values before in-band connections are attempted.
如果客户端在尝试建立EPP会话之前未正确标识服务器，则存在登录凭据泄露的风险。在向服务器发送登录凭据之前，客户端需要确认在TLS握手中接收的服务器证书是服务器的预期证书。客户端还需要确认从服务器接收的问候语是否包含预期的标识信息。在建立TLS会话并在受保护的TCP连接上接收EPP问候语后，客户端必须将证书主题和/或主题名称与预期的服务器标识信息进行比较，并在检测到不匹配时中止处理。如果证书验证成功，则客户端需要确保接收到的证书和问候语中包含的信息一致且适当。如上所述，在尝试带内连接之前，这两种检查通常都需要在客户端和服务器之间进行带外信息交换，以确定预期值。
EPP TCP servers are vulnerable to common TCP denial-of-service attacks including TCP SYN flooding. Servers SHOULD take steps to minimize the impact of a denial-of-service attack using combinations of easily implemented solutions, such as deployment of firewall technology and border router filters to restrict inbound server access to known, trusted clients.
EPP TCP服务器容易受到常见的TCP拒绝服务攻击，包括TCP SYN洪泛攻击。服务器应采取措施，结合使用易于实施的解决方案（如部署防火墙技术和边界路由器过滤器）将拒绝服务攻击的影响降至最低，以限制对已知可信客户端的入站服务器访问。
This document was originally written as an individual submission Internet-Draft. The PROVREG working group later adopted it as a working group document and provided many invaluable comments and suggested improvements. The author wishes to acknowledge the efforts of WG chairs Edward Lewis and Jaap Akkerhuis for their process and editorial contributions.
本文件最初是作为个人提交的互联网草案编写的。PROVREG工作组后来将其作为工作组文件通过，并提出了许多宝贵的意见和改进建议。作者希望感谢工作组主席Edward Lewis和Jaap Akkerhuis的工作过程和编辑贡献。
Specific suggestions that have been incorporated into this document were provided by Chris Bason, Randy Bush, Patrik Faltstrom, Ned Freed, James Gould, Dan Manley, and John Immordino.
Chris Bason、Randy Bush、Patrik Faltstrom、Ned Freed、James Gould、Dan Manley和John Immordino提供了纳入本文件的具体建议。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC4930] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 4930, May 2007.
[RFC4930]Hollenbeck，S.，“可扩展资源调配协议（EPP）”，RFC 4930，2007年5月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC3280] 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.
[RFC3280]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[RFC3734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Transport Over TCP", RFC 3734, March 2004.
[RFC3734]Hollenbeck，S.，“TCP上的可扩展供应协议（EPP）传输”，RFC 3734，2004年3月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
1. Minor reformatting as a result of converting I-D source format from nroff to XML.
1. 由于将I-D源格式从nroff转换为XML，因此需要进行较小的重新格式化。
2. Updated Security Considerations to include strong authentication among the list of needed security services. Removed paragraph describing replay attacks because it's not specific to TCP. New text has been added to RFC 4930 to describe this issue.
2. 更新了安全注意事项，将强身份验证包括在所需安全服务列表中。删除了描述重播攻击的段落，因为它不是特定于TCP的。RFC 4930中添加了新文本来描述此问题。
3. Modified description of TCP operation as a result of IESG evaluation.
3. 由于IESG评估，修改了TCP操作的描述。
4. Moved RFCs 2581 and 2914 from the normative reference section to the informative reference section.
4. 将RFCs 2581和2914从标准参考部分移至信息参考部分。
5. Added informative references to RFCs 3280 and 4346 and descriptive text for each as a result of IESG evaluation.
5. 作为IESG评估的结果，增加了对RFCs 3280和4346的信息性参考和描述性文本。
6. Revised security considerations as a result of IESG evaluation.
6. 根据IESG评估结果修订了安全注意事项。
7. Updated EPP references.
7. 更新了EPP参考资料。
Author's Address
作者地址
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
Scott Hollenbeck VeriSign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21345，邮编20166-6503
EMail: shollenbeck@verisign.com
EMail: shollenbeck@verisign.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。