Network Working Group P. Srisuresh
Request for Comments: 2888 Campio Communications
Category: Informational August 2000
Network Working Group P. Srisuresh
Request for Comments: 2888 Campio Communications
Category: Informational August 2000
Secure Remote Access with L2TP
使用L2TP实现安全的远程访问
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
L2TP protocol is a virtual extension of PPP across IP network infrastructure. L2TP makes possible for an access concentrator (LAC) to be near remote clients, while allowing PPP termination server (LNS) to be located in enterprise premises. L2TP allows an enterprise to retain control of RADIUS data base, which is used to control Authentication, Authorization and Accountability (AAA) of dial-in users. The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet. This is accomplished without creating new protocols and using the existing practices of Remote Access and IPsec. Specifically, the document proposes three new RADIUS parameters for use by the LNS node, acting as Secure Remote Access Server (SRAS) to mandate network level security between remote clients and the enterprise. The document also discusses limitations of the approach.
L2TP协议是PPP在IP网络基础设施上的虚拟扩展。L2TP使访问集中器（LAC）靠近远程客户端成为可能，同时允许PPP终端服务器（LNS）位于企业内部。L2TP允许企业保留对RADIUS数据库的控制，该数据库用于控制拨入用户的身份验证、授权和责任（AAA）。本文档的目的是将IPsec的安全特性扩展到远程访问用户，因为他们通过Internet拨入。这是在不创建新协议和使用远程访问和IPsec的现有实践的情况下实现的。具体而言，该文件提出了三个新的RADIUS参数供LNS节点使用，充当安全远程访问服务器（SRA），以强制远程客户端和企业之间的网络级安全。该文件还讨论了该方法的局限性。
Now-a-days, it is common practice for employees to dial-in to their enterprise over the PSTN (Public Switched Telephone Network) and perform day-to-day operations just as they would if they were in corporate premises. This includes people who dial-in from their home and road warriors, who cannot be at the corporate premises. As the Internet has become ubiquitous, it is appealing to dial-in through the Internet to save on phone charges and save the dedicated voice lines from being clogged with data traffic.
如今，员工通过PSTN（公共交换电话网络）拨入企业，并像在企业场所一样执行日常操作，这是一种常见的做法。这包括从家里拨电话的人和不能在公司办公场所的公路战士。随着互联网变得无处不在，通过互联网拨号以节省电话费，并避免专用语音线路被数据流量堵塞，这是一种很有吸引力的做法。
The document suggests an approach by which remote access over the Internet could become a reality. The approach is founded on the well-known techniques and protocols already in place. Remote Access extensions based on L2TP, when combined with the security offered by IPSec can make remote access over the Internet a reality. The approach does not require inventing new protocol(s).
该文件提出了一种通过互联网实现远程访问的方法。该方法建立在已有的众所周知的技术和协议的基础上。基于L2TP的远程访问扩展，当与IPSec提供的安全性相结合时，可以通过Internet实现远程访问。该方法不需要发明新的协议。
The trust model of remote access discussed in this document is viewed principally from the perspective of an enterprise into which remote access clients dial-in. A remote access client may or may not want to enforce end-to-end IPsec from his/her end to the enterprise. However, it is in the interest of the enterprise to mandate security of every packet that it accepts from the Internet into the enterprise. Independently, remote users may also pursue end-to-end IPsec, if they choose to do so. That would be in addition to the security requirement imposed by the enterprise edge device.
本文档中讨论的远程访问信任模型主要是从远程访问客户端拨入的企业的角度来看待的。远程访问客户端可能希望也可能不希望从其端到企业强制实施端到端IPsec。然而，为了企业的利益，必须对从互联网接收到的每个数据包进行安全保护。如果远程用户选择采用端到端IPsec，那么他们也可以独立地采用端到端IPsec。这将是企业边缘设备强加的安全要求之外的要求。
Section 2 has reference to the terminology used throughout the document. Also mentioned are the limited scope in which some of these terms may be used in this document. Section 3 has a brief description of what constitutes remote access. Section 4 describes what constitutes network security from an enterprise perspective. Section 5 describes the model of secure remote access as a viable solution to enterprises. The solution presented in section 5 has some limitations. These limitations are listed in section 6. Section 7 is devoted to describing new RADIUS attributes that may be configured to turn a NAS device into Secure Remote Access Server.
第2节参考了本文件中使用的术语。还提到了本文件中某些术语可能使用的有限范围。第3节简要介绍了远程访问的构成。第4节从企业的角度描述了网络安全的构成。第5节描述了作为企业可行解决方案的安全远程访问模型。第5节中介绍的解决方案有一些局限性。第6节列出了这些限制。第7节专门介绍新的RADIUS属性，这些属性可以配置为将NAS设备转变为安全的远程访问服务器。
Definition of terms used in this document may be found in one of (a) L2TP Protocol document [Ref 1], (b) IP security Architecture document [Ref 5], or (c) Internet Key Exchange (IKE) document [Ref 8].
本文件中使用的术语定义可在（a）L2TP协议文件[Ref 1]、（b）IP安全体系结构文件[Ref 5]或（c）互联网密钥交换（IKE）文件[Ref 8]中找到。
Note, the terms Network Access Server (NAS) and Remote Access Server(RAS) are used interchangeably throughout the document. While PPP may be used to carry a variety of network layer packets, the focus of this document is limited to carrying IP datagrams only.
注意，术语网络访问服务器（NAS）和远程访问服务器（RAS）在整个文档中交替使用。虽然PPP可用于承载各种网络层数据包，但本文档的重点仅限于承载IP数据报。
"Secure Remote Access Server" (SRAS) defined in this document refers to a NAS that supports tunnel-mode IPsec with its remote clients. Specifically, LNS is the NAS that is referred. Further, involuntary tunneling is assumed for L2TP tunnel setup, in that remote clients initiating PPP session and the LAC that tunnels the PPP sessions are presumed to be distinct physical entities.
本文档中定义的“安全远程访问服务器”（SRAS）指的是支持远程客户端隧道模式IPsec的NAS。具体而言，LNS是指参考的NAS。此外，假定L2TP隧道设置为非自愿隧道，因为发起PPP会话的远程客户端和隧道PPP会话的LAC被假定为不同的物理实体。
Lastly, there are a variety of transport mediums by which to tunnel PPP packets between a LAC and LNS. Examples include Frame Relay or ATM cloud and IP network infrastructure. For simplicity, the document assumes a public IP infrastructure as the medium to transport PPP packets between LAC and LNS. Security of IP packets (embedded within PPP) in a trusted private transport medium is less of a concern for the purposes of this document.
最后，有多种传输介质可用于在LAC和LN之间隧道PPP数据包。示例包括帧中继或ATM云和IP网络基础设施。为简单起见，本文件假设公共IP基础设施作为在LAC和LN之间传输PPP数据包的媒介。在本文档中，受信任的专用传输介质中的IP数据包（嵌入PPP中）的安全性不太重要。
Remote access is more than mere authentication of remote clients by a Network Access Server(NAS). Authentication, Authorization, Accounting and routing are integral to remote access. A client must first pass the authentication test before being granted link access to the network. Network level services (such as IP) are granted based on the authorization characteristics specified for the user in RADIUS. Network Access Servers use RADIUS to scale for large numbers of users supported. NAS also monitors the link status of the remote access clients.
远程访问不仅仅是通过网络访问服务器（NAS）对远程客户端进行身份验证。身份验证、授权、记帐和路由是远程访问的组成部分。客户端必须首先通过身份验证测试，然后才能被授予对网络的链接访问权限。基于RADIUS中为用户指定的授权特征授予网络级服务（如IP）。网络访问服务器使用RADIUS来扩展支持的大量用户。NAS还监视远程访问客户端的链路状态。
There are a variety of techniques by which remote access users are connected to their enterprise and the Internet. At a link level, the access techniques include ISDN digital lines, analog plain-old-telephone-service lines, xDSL lines, cable and wireless to name a few. PPP is the most common Layer-2 (L2)protocol used for carrying network layer packets over these remote access links. PPP may be used to carry a variety of network layer datagrams including IP, IPX and AppleTalk. The focus of this document is however limited to IP datagrams only.
远程访问用户通过各种技术连接到他们的企业和Internet。在链路级，接入技术包括ISDN数字线、模拟普通旧电话服务线、xDSL线、有线和无线等。PPP是最常见的第2层（L2）协议，用于通过这些远程访问链路承载网络层数据包。PPP可用于承载各种网络层数据报，包括IP、IPX和AppleTalk。然而，本文档的重点仅限于IP数据报。
L2TP is a logical extension of PPP over an IP infrastructure. While a LAC provides termination of Layer 2 links, LNS provides the logical termination of PPP. As a result, LNS becomes the focal point for (a) performing the AAA operations for the remote users, (b) assigning IP address and monitoring the logical link status (i.e., the status of LAC-to-LNS tunnel and the link between remote user and LAC), and (c) maintaining host-route to remote user network and providing routing infrastructure into the enterprise.
L2TP是PPP在IP基础设施上的逻辑扩展。LAC提供第2层链路的终止，LNS提供PPP的逻辑终止。因此，LNS成为（a）为远程用户执行AAA操作，（b）分配IP地址并监控逻辑链路状态（即LAC至LNS隧道的状态以及远程用户与LAC之间的链路）和（c）的焦点维护到远程用户网络的主机路由，并向企业提供路由基础设施。
L2TP uses control messages to establish, terminate and monitor the status of the logical PPP sessions (from remote user to LNS). These are independent of the data messages. L2TP data messages contain an L2TP header, followed by PPP packets. The L2TP header identifies the PPP session (amongst other things) to which the PPP packet belongs. The IP packets exchanged from/to the remote user are carried within the PPP packets. The L2TP data messages, carrying end-to-end IP packets in an IP transport medium may be described as follows. The exact details of L2TP protocol may be found in [Ref 1].
L2TP使用控制消息来建立、终止和监控逻辑PPP会话（从远程用户到LNS）的状态。这些独立于数据消息。L2TP数据消息包含一个L2TP报头，后跟PPP数据包。L2TP报头标识PPP数据包所属的PPP会话（除其他外）。与远程用户交换/与远程用户交换的IP数据包在PPP数据包中携带。在IP传输介质中承载端到端IP分组的L2TP数据消息可以如下描述。L2TP协议的确切细节可在[Ref 1]中找到。
+----------------------+
| IP Header |
| (LAC <->LNS) |
+----------------------+
| UDP Header |
+----------------------+
| L2TP Header |
| (incl. PPP Sess-ID) |
+----------------------+
| PPP Header |
| (Remote User<->LNS) |
+----------------------+
| End-to-end IP packet |
| (to/from Remote User)|
+----------------------+
+----------------------+
| IP Header |
| (LAC <->LNS) |
+----------------------+
| UDP Header |
+----------------------+
| L2TP Header |
| (incl. PPP Sess-ID) |
+----------------------+
| PPP Header |
| (Remote User<->LNS) |
+----------------------+
| End-to-end IP packet |
| (to/from Remote User)|
+----------------------+
Today's enterprises are aware of the various benefits of connecting to the Internet. Internet is a vast source of Information and a means to disseminate information and make available certain resources to the external world. However, enterprises are also aware that security breaches (by being connected to the Internet) can severely jeopardize internal network.
今天的企业意识到连接到互联网的各种好处。因特网是一个巨大的信息来源，是向外部世界传播信息和提供某些资源的手段。然而，企业也意识到安全漏洞（通过连接到互联网）会严重危害内部网络。
As a result, most enterprises restrict access to a pre-defined set of resources for external users. Typically, enterprises employ a firewall to restrict access to internal resources and place externally accessible servers in the DeMilitarized Zone (DMZ), in front of the firewall, as described below in Figure 1.
因此，大多数企业限制外部用户访问预定义的资源集。通常，企业使用防火墙来限制对内部资源的访问，并将外部可访问的服务器放置在防火墙前面的非军事区（DMZ）中，如图1所示。
----------------
( )
( )
( Internet )
( )
(_______________ )
----------------
( )
( )
( Internet )
( )
(_______________ )
WAN |
.........|\|....
|
+-----------------+
|Enterprise Router|
+-----------------+
|
| DMZ - Network
---------------------------------
| | |
+--+ +--+ +----------+
|__| |__| | Firewall |
/____\ /____\ +----------+
DMZ-Name DMZ-Web ... |
Server Server |
|
------------------
( )
( Internal Network )
( (private to the )
( enterprise) )
(_________________ )
WAN |
.........|\|....
|
+-----------------+
|Enterprise Router|
+-----------------+
|
| DMZ - Network
---------------------------------
| | |
+--+ +--+ +----------+
|__| |__| | Firewall |
/____\ /____\ +----------+
DMZ-Name DMZ-Web ... |
Server Server |
|
------------------
( )
( Internal Network )
( (private to the )
( enterprise) )
(_________________ )
Figure 1: Security model of an Enterprise using Firewall
图1：使用防火墙的企业安全模型
Network Access Servers used to allow direct dial-in access (through the PSTN) to employees are placed within the private enterprise network so as to avoid access restrictions imposed by a firewall.
用于允许员工（通过PSTN）直接拨号访问的网络访问服务器位于私有企业网络内，以避免防火墙施加的访问限制。
With the above model, private resources of an enterprise are restricted for access from the Internet. Firewall may be configured to occasionally permit access to a certain resource or service but is not recommended on an operational basis as that could constitute a security threat to the enterprise. It is of interest to note that even when the firewall is configured to permit access to internal resources from pre-defined external node(s), many internal servers, such as NFS, enforce address based authentication and do not co-operate when the IP address of the external node is not in corporate IP address domain. In other words, with the above security model, it
在上述模型中，企业的私有资源被限制从Internet访问。防火墙可配置为偶尔允许访问特定资源或服务，但不建议在操作基础上使用，因为这可能对企业构成安全威胁。值得注意的是，即使将防火墙配置为允许从预定义的外部节点访问内部资源，许多内部服务器（如NFS）也会强制执行基于地址的身份验证，并且当外部节点的IP地址不在公司IP地址域中时，它们也不会合作。换言之，使用上述安全模型
becomes very difficult to allow employees to access corporate resources, via the Internet, even if you are willing to forego security over the Internet.
允许员工通过互联网访问公司资源变得非常困难，即使您愿意放弃互联网上的安全保护。
With the advent of IPsec, it is possible to secure corporate data across the Internet by employing a Security Gateway within the enterprise. Firewall may be configured to allow IKE and IPsec packets directed to a specific Security Gateway behind the firewall. It then becomes the responsibility of the Security Gateway to employ the right access list for external connections seeking entry into the enterprise. Essentially, the access control functionality for IPsec secure packets would be shifted to the Security Gateway (while the access control for clear packets is retained with the firewall). The following figure illustrates the model where a combination of Firewall and Security Gateway control access to internal resources.
随着IPsec的出现，通过在企业内使用安全网关，可以在Internet上保护企业数据。防火墙可以配置为允许IKE和IPsec数据包定向到防火墙后面的特定安全网关。然后，安全网关负责为寻求进入企业的外部连接使用正确的访问列表。本质上，IPsec安全数据包的访问控制功能将转移到安全网关（而清除数据包的访问控制由防火墙保留）。下图说明了防火墙和安全网关组合控制对内部资源访问的模型。
------------
( )
( )
( Internet )
( )
(___________ )
------------
( )
( )
( Internet )
( )
(___________ )
WAN |
.........|\|....
|
+-----------------+
|Enterprise Router|
+-----------------+
|
| DMZ - Network
------------------------------------------------------------
| | |
+--+ +--+ +----------+
|__| |__| | Firewall |
/____\ /____\ +----------+
DMZ-Name DMZ-Web ... |
Server Server etc. | LAN
|
------------------------------------
| |
+----------+ +------------------+
| LNS | | Security Gateway |
| Server | | (SGW) |
+----------+ +------------------+
|
------------------
( )
( Internal Network )
( (Private to the )
( enterprise) )
(_________________ )
WAN |
.........|\|....
|
+-----------------+
|Enterprise Router|
+-----------------+
|
| DMZ - Network
------------------------------------------------------------
| | |
+--+ +--+ +----------+
|__| |__| | Firewall |
/____\ /____\ +----------+
DMZ-Name DMZ-Web ... |
Server Server etc. | LAN
|
------------------------------------
| |
+----------+ +------------------+
| LNS | | Security Gateway |
| Server | | (SGW) |
+----------+ +------------------+
|
------------------
( )
( Internal Network )
( (Private to the )
( enterprise) )
(_________________ )
Figure 2: Security Model based on Firewall and Security Gateway
图2：基于防火墙和安全网关的安全模型
In order to allow employee dial-in over the Internet, an LNS may be placed behind a firewall, and the firewall may be configured to allow UDP access to the LNS from the Internet. Note, it may not be possible to know all the IP addresses of the LACs located on the Internet at configuration time. Hence, the need to allow UDP access from any node on the Internet. The LNS may be configured to process only the L2TP packets and drop any UDP packets that are not L2TP.
为了允许员工通过Internet拨入，可以将LNS放置在防火墙后面，并且可以将防火墙配置为允许从Internet对LNS进行UDP访问。注意，在配置时可能无法知道位于Internet上的LAC的所有IP地址。因此，需要允许Internet上任何节点的UDP访问。LNS可被配置为仅处理L2TP分组并丢弃任何不是L2TP的UDP分组。
Such a configuration allows remote access over the Internet. However, the above setup is prone to a variety of security attacks over the Internet. It is easy for someone on the Internet to steal a remote access session and gain access to precious resources of the enterprise. Hence it is important that all packets are preserved with IPsec to a security Gateway (SGW) behind the LNS, so the Security Gateway will not allow IP packets into corporate network unless it can authenticate the same.
这种配置允许通过Internet进行远程访问。但是，上述设置容易通过Internet受到各种安全攻击。互联网上的某个人很容易窃取远程访问会话并访问企业的宝贵资源。因此，使用IPsec将所有数据包保存到LNS后面的安全网关（SGW）是很重要的，因此安全网关不允许IP数据包进入公司网络，除非它能够对其进行身份验证。
The trust model of secure remote access assumes that the enterprise and the end user are trusted domains. Everything in between is not trusted. Any examination of the end-to-end packets by the nodes enroute would violate this trust model. From this perspective, even the LAC node enroute must not be trusted with the end-to-end IP packets. Hence, location and operation of LAC is not relevant for the discussion on security. On the other hand, location and operation of LNS and the Security Gateway (SGW) are precisely the basis for discussion.
安全远程访问的信任模型假定企业和最终用户是受信任的域。两者之间的一切都不可信。在路由过程中，节点对端到端数据包的任何检查都将违反此信任模型。从这个角度来看，即使是路由中的LAC节点也不能被端到端IP数据包信任。因此，拉丁美洲和加勒比海的位置和运作与安全问题的讨论无关。另一方面，LNS和安全网关（SGW）的位置和操作正是讨论的基础。
Having security processing done on an independent Security gateway has the following shortcomings.
在独立的安全网关上进行安全处理有以下缺点。
1. Given the trust model for remote access, the SGW must be configured with a set of security profiles, access control lists and IKE authentication parameters for each user. This mandates an independent provisioning of security parameters on a per-user basis. This may not be able to take advantage of the user-centric provisioning on RADIUS, used by the LNS node.
1. 鉴于远程访问的信任模型，SGW必须为每个用户配置一组安全配置文件、访问控制列表和IKE身份验证参数。这要求在每个用户的基础上独立提供安全参数。这可能无法利用LNS节点使用的RADIUS上以用户为中心的资源调配。
2. Unlike the LNS, SGW may not be in the routing path of remote access packets. I.e., there is no guarantee that the egress IP packets will go through the chain of SGW and LNS before they are delivered to remote user. As a result, packets may be subject to IPSec in one direction, but not in the other. This can be a significant threat to the remote access trust model.
2. 与LN不同，SGW可能不在远程访问数据包的路由路径中。即，无法保证出口IP数据包在交付给远程用户之前将通过SGW和LN链。因此，数据包可能在一个方向上受IPSec约束，但在另一个方向上不受IPSec约束。这可能对远程访问信任模型构成重大威胁。
3. Lastly, the SGW node does not have a way to know when a remote user node(s) simply died or the LAC-LNS tunnel failed. Being unable to delete the SAs for users that no longer exist could drain the resources of the SGW. Further, the LNS cannot even communicate the user going away to the SGW because, the SGW maintains its peer nodes based on IKE user ID, which could be different the user IDs employed by the LNS node.
3. 最后，SGW节点无法知道远程用户节点何时死亡或LAC-LNS隧道何时失败。无法删除不再存在的用户的SAs可能会耗尽SGW的资源。此外，LNS甚至不能将离开的用户与SGW通信，因为SGW基于IKE用户ID维护其对等节点，IKE用户ID可能不同于LNS节点所使用的用户ID。
Combining the functions of IPsec Security Gateway and LNS into a single system promises to offer a viable solution for secure remote access. By doing this, remote access clients will use a single node as both (a) PPP termination point providing NAS service, and (b) the Security gateway node into the enterprise. We will refer this node as "Secure Remote Access Server" (SRAS).
将IPsec安全网关和LNS的功能结合到一个系统中，有望为安全远程访问提供一个可行的解决方案。通过这样做，远程访问客户端将使用单个节点作为（a）提供NAS服务的PPP终止点和（b）进入企业的安全网关节点。我们将此节点称为“安全远程访问服务器”（SRAS）。
The SRAS can benefit greatly from the confluence of PPP session and IPsec tunnel end points. PPP session monitoring capability of L2TP directly translates to being able to monitor IPsec tunnels. Radius based user authorization ability could be used to configure the security characteristics for IPsec tunnel. This includes setting access control filters and security preferences specific to each user. This may also be extended to configuring IKE authentication and other negotiation parameters, when automated key exchange is solicited. Security attributes that may be defined in Radius are discussed in detail in section 7. Needless to say, the centralized provisioning capability and scalability of Radius helps in the configuration of IPsec.
SRA可以从PPP会话和IPsec隧道端点的融合中获益匪浅。L2TP的PPP会话监控能力直接转化为能够监控IPsec隧道。基于Radius的用户授权能力可用于配置IPsec隧道的安全特性。这包括设置特定于每个用户的访问控制筛选器和安全首选项。当请求自动密钥交换时，这还可以扩展到配置IKE身份验证和其他协商参数。第7节详细讨论了Radius中可能定义的安全属性。不用说，Radius的集中式资源调配功能和可扩展性有助于IPsec的配置。
As for remote access, the benefit is one of IPsec security as befitting the trust model solicited by enterprises for the end-to-end IP packets traversing the Internet. You may use simply AH where there is no fear of external eaves-dropping, but you simply need to authenticate packet data, including the source of packet. You may use ESP (including ESP-authentication), where there is no trust of the network and you do not want to permit eaves-dropping on corporate activities.
至于远程访问，其好处是IPsec安全性符合企业对通过Internet的端到端IP数据包所要求的信任模型。您可以在不担心外部屋檐掉落的情况下简单地使用AH，但您只需要验证数据包数据，包括数据包的来源。您可以使用ESP（包括ESP身份验证），其中不存在对网络的信任，并且您不希望允许在公司活动中放置屋檐。
Operation of SRAS requires that the firewall be configured to permit UDP traffic into the SRAS node. The SRAS node in turn will process just the L2TP packets and drop the rest. Further, the SRAS will require all IP packets embedded within PPP to be one of AH and ESP packets, directed to itself. In addition, the SRAS will also permit IKE UDP packets (with source and destination ports sets to 500) directed to itself in order to perform IKE negotiation and generate IPsec keys dynamically. All other IP packets embedded within PPP will be dropped. This enforces the security policy for the enterprise by permitting only the secure remote access packets into the enterprise. When a PPP session is dropped, the IPsec and ISAKMP SAs associated with the remote access user are dropped from the SRAS. All the shortcomings listed in the previous section with LNS and SGW on two systems disappear withe Secure Remote Access Server. Figure 3 below is a typical description of an enterprise supporting remote access users using SRAS system.
SRAS的操作需要将防火墙配置为允许UDP流量进入SRAS节点。SRAS节点将依次处理L2TP数据包，并丢弃其余数据包。此外，sra将要求嵌入PPP中的所有IP分组都是指向自身的AH和ESP分组之一。此外，SRA还将允许IKE UDP数据包（源端口和目标端口设置为500）指向自身，以便执行IKE协商并动态生成IPsec密钥。嵌入PPP中的所有其他IP数据包将被丢弃。这通过只允许安全远程访问数据包进入企业来强制企业的安全策略。当删除PPP会话时，与远程访问用户关联的IPsec和ISAKMP SA将从SRA中删除。上一节中列出的LNS和SGW在两个系统上的所有缺点在安全远程访问服务器上消失。下面的图3是使用SRAS系统支持远程访问用户的企业的典型描述。
------------
Remote Access +-------------+ ( )
+--+______ Link | Local Access| ( )
|__| /___________| Concentrator|----( Internet )
/____\ | (LAC) | ( )
RA-Host +-------------+ (____________)
------------
Remote Access +-------------+ ( )
+--+______ Link | Local Access| ( )
|__| /___________| Concentrator|----( Internet )
/____\ | (LAC) | ( )
RA-Host +-------------+ (____________)
WAN |
.........|\|....
|
+-----------------+
|Enterprise Router|
+-----------------+
|
| DMZ - Network
------------------------------------------
| | |
+--+ +--+ +----------+
|__| |__| | Firewall |
/____\ /____\ +----------+
DMZ-Name DMZ-Web ... |
Server Server etc. | LAN
|
------------------------------------
|
+---------------+
| Secure Remote |
| Access Server |
| (SRAS) |
+---------------+
|
---------------------
( )
+--+ ( Internal Network )
|__|------( (Private to the )
/____\ ( enterprise) )
Ent-Host (______________________)
WAN |
.........|\|....
|
+-----------------+
|Enterprise Router|
+-----------------+
|
| DMZ - Network
------------------------------------------
| | |
+--+ +--+ +----------+
|__| |__| | Firewall |
/____\ /____\ +----------+
DMZ-Name DMZ-Web ... |
Server Server etc. | LAN
|
------------------------------------
|
+---------------+
| Secure Remote |
| Access Server |
| (SRAS) |
+---------------+
|
---------------------
( )
+--+ ( Internal Network )
|__|------( (Private to the )
/____\ ( enterprise) )
Ent-Host (______________________)
Figure 3: Secure Remote Access Server operation in an Enterprise
图3：企业中的安全远程访问服务器操作
The following is an illustration of secure remote access data flow as end-to-end IP packets traverse the Internet and the SRAS. The example shows IP packet tunneling and IPsec transformation as packets are exchanged between a remote Access host (RA-Host) and a host within the enterprise (say, Ent-Host).
以下是端到端IP数据包穿过Internet和SRA时安全远程访问数据流的说明。该示例显示了在远程访问主机（RA主机）和企业内的主机（如Ent主机）之间交换数据包时的IP数据包隧道和IPsec转换。
Note, the IP packets originating from or directed to RA-Host are shown within PPP encapsulation, whereas, all other packets are shown simply as IP packets. It is done this way to highlight the PPP packets encapsulated within L2TP tunnel. The PPP headers below are identified by their logical source and destination in parenthesis. Note, however, the source and recipient information of the PPP data is not a part of PPP header. This is described thus, just for clarity. In the case of an L2TP tunnel, the L2TP header carries the PPP session ID, which indirectly identifies the PPP end points to the LAC and the LNS. Lastly, the IPsec Headers section below include the tunneling overhead and the AH/ESP headers that are attached to the tunnel.
注意，源自或定向到RA主机的IP数据包显示在PPP封装中，而所有其他数据包仅显示为IP数据包。这样做是为了突出显示封装在L2TP隧道中的PPP数据包。下面的PPP头由括号中的逻辑源和目标标识。然而，请注意，PPP数据的来源和接收者信息不是PPP标题的一部分。因此，仅为清楚起见，对其进行了描述。在L2TP隧道的情况下，L2TP报头携带PPP会话ID，该ID间接标识到LAC和LN的PPP端点。最后，下面的IPsec头部分包括隧道开销和附加到隧道的AH/ESP头。
RA-Host to Ent-Host Packet traversal:
------------------------------------
RA-Host to Ent-Host Packet traversal:
------------------------------------
RA-Host LAC SRAS Ent-Host
=====================================================================
RA-Host LAC SRAS Ent-Host
=====================================================================
+----------------------+
| PPP Header |
| (RA-Host ->SRAS) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(RA-Host->SRAS)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (RA-Host->Ent-Host) |
+----------------------+
---------------------->
+----------------------+
| PPP Header |
| (RA-Host ->SRAS) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(RA-Host->SRAS)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (RA-Host->Ent-Host) |
+----------------------+
---------------------->
+----------------------+
| IP Header |
| (LAC->SRAS) |
+----------------------+
| UDP Header |
+----------------------+
| L2TP Header |
| (incl. PPP Sess-ID) |
+----------------------+
| PPP Header |
| (RA-Host ->SRAS) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(RA-Host->SRAS)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (RA-Host->Ent-Host) |
+----------------------+
---------------------->
+----------------------+
| IP Header |
| (LAC->SRAS) |
+----------------------+
| UDP Header |
+----------------------+
| L2TP Header |
| (incl. PPP Sess-ID) |
+----------------------+
| PPP Header |
| (RA-Host ->SRAS) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(RA-Host->SRAS)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (RA-Host->Ent-Host) |
+----------------------+
---------------------->
+----------------------+
| End-to-end IP packet |
| (RA-Host->Ent-Host) |
+----------------------+
---------------------->
+----------------------+
| End-to-end IP packet |
| (RA-Host->Ent-Host) |
+----------------------+
---------------------->
Ent-Host to RA-Host Packet traversal:
------------------------------------
Ent-Host to RA-Host Packet traversal:
------------------------------------
Ent-Host SRAS LAC RA-Host
=====================================================================
Ent-Host SRAS LAC RA-Host
=====================================================================
+----------------------+
| End-to-end IP packet |
| (Ent-Host->Ra-Host) |
+----------------------+
---------------------->
+----------------------+
| End-to-end IP packet |
| (Ent-Host->Ra-Host) |
+----------------------+
---------------------->
+----------------------+
| IP Header |
| (SRAS->LAC) |
+----------------------+
| UDP Header |
+----------------------+
| L2TP Header |
| (incl. PPP Sess-ID) |
+----------------------+
| PPP Header |
| (SRAS->RA-Host) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(SRAS->RA-Host)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (Ent-Host->RA-Host) |
+----------------------+
---------------------->
+----------------------+
| IP Header |
| (SRAS->LAC) |
+----------------------+
| UDP Header |
+----------------------+
| L2TP Header |
| (incl. PPP Sess-ID) |
+----------------------+
| PPP Header |
| (SRAS->RA-Host) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(SRAS->RA-Host)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (Ent-Host->RA-Host) |
+----------------------+
---------------------->
+----------------------+
| PPP Header |
| (SRAS->RA-Host) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(SRAS->RA-Host)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (Ent-Host->RA-Host) |
+----------------------+
---------------------->
+----------------------+
| PPP Header |
| (SRAS->RA-Host) |
+----------------------+
| Tunnel-Mode IPsec |
| Hdr(s)(SRAS->RA-Host)|
+----------------------+
| End-to-end IP packet |
| transformed as needed|
| (Ent-Host->RA-Host) |
+----------------------+
---------------------->
The SRAS model described is not without its limitations. Below is a list of the limitations.
所描述的SRAS模型并非没有其局限性。下面是限制的列表。
1. Tunneling overhead: There is considerable tunneling overhead on the end-to-end IP packet. Arguably, there is overlap of information between tunneling headers. This overhead will undercut packet throughput.
1. 隧道开销：端到端IP数据包上有相当大的隧道开销。可以说，隧道头之间存在信息重叠。这种开销将降低数据包吞吐量。
The overhead is particularly apparent at the LAC and SRAS nodes. Specifically, the SRAS has the additional computational overhead of IPsec processing on all IP packets exchanged with remote users. This can be a significant bottleneck in the ability of SRAS to scale for large numbers of remote users.
这种开销在LAC和SRAS节点上尤其明显。具体地说，sra在与远程用户交换的所有IP分组上具有IPsec处理的额外计算开销。这可能是SRA为大量远程用户扩展能力的一个重要瓶颈。
2. Fragmentation and reassembly: Large IP packets may be required to undergo Fragmentation and reassembly at the LAC or the LNS as a result of multiple tunnel overhead tagged to the packet. Fragmentation and reassembly can havoc on packet throughput and latency. However, it is possible to avoid the overhead by reducing the MTU permitted within PPP frames.
2. 碎片和重组：由于标记到数据包的多个隧道开销，可能需要在LAC或LN处对大型IP数据包进行碎片和重组。碎片化和重组会严重影响数据包吞吐量和延迟。然而，可以通过减少PPP帧内允许的MTU来避免开销。
3. Multiple identity and authentication requirement: Remote Access users are required to authenticate themselves to the SRAS in order to be obtain access to the link. Further, when they require the use of IKE to automate IPsec key exchange, they will need to authenticate once again with the same or different ID and a distinct authentication approach. The authentication requirements of IKE phase 1 [Ref 8] and LCP [Ref 3] are different.
3. 多重身份和身份验证要求：远程访问用户需要向SRA进行身份验证，以获得对链路的访问。此外，当他们需要使用IKE来自动化IPsec密钥交换时，他们将需要使用相同或不同的ID和不同的身份验证方法再次进行身份验证。IKE阶段1[Ref 8]和LCP[Ref 3]的认证要求不同。
However, it is possible to have a single authentication approach (i.e., a single ID and authentication mechanism) that can be shared between LCP and IKE phase 1. The Extended Authentication Protocol(EAP) [Ref 4] may be used as the base to transport IKE authentication mechanism into PPP. Note, the configuration overhead is not a drag on the functionality perse.
然而，有可能在LCP和IKE阶段1之间共享单个身份验证方法（即，单个ID和身份验证机制）。扩展认证协议（EAP）[Ref 4]可用作将IKE认证机制传输到PPP的基础。注意，配置开销不是对功能的拖累。
4. Weak security of Link level authentication: As LCP packets traverse the Internet, the Identity of the remote user and the password (if a password is used) is sent in the clear. This makes it a target for someone on the net to steal the information and masquerade as remote user. Note, however, this type of password stealing will not jeopardize the security of the enterprise per se, but could result in denial of service to remote users. An intruder can collect the password data and simply steal the link, but will not be able to run any IP applications subsequently, as the SRAS will fail non-IPsec packet data.
4. 链路级身份验证的安全性较弱：当LCP数据包穿越互联网时，远程用户的身份和密码（如果使用密码）以明文形式发送。这使得它成为网络上有人窃取信息并伪装成远程用户的目标。但是，请注意，这种类型的密码窃取不会危害企业本身的安全，但可能会导致拒绝为远程用户提供服务。入侵者可以收集密码数据并简单地窃取链接，但随后将无法运行任何IP应用程序，因为SRA将使非IPsec数据包失败。
A better approach would be to employ Extended Authentication Protocol (EAP) [Ref 4] and select an authentication technique that is not prone to stealing over the Internet. Alternately, the LAC and the SRAS may be independently configured to use IPsec to secure all LCP traffic exchanged between themselves.
更好的方法是使用扩展认证协议（EAP）[Ref 4]并选择一种不容易在互联网上窃取的认证技术。或者，LAC和sra可以独立地配置为使用IPsec来保护它们之间交换的所有LCP通信。
7. Configuring RADIUS to support Secure Remote Access.
7. 配置RADIUS以支持安全的远程访问。
A centralized RADIUS database is used by enterprises to maintain the authentication and authorization requirements of the dial-in Users. It is also believed that direct dial-in access (e.g., through the PSTN network is) safe and trusted and does not need any scrutiny outside of the link level authentication enforced in LCP. This belief is certainly not shared with the dial-in access through the Internet.
企业使用集中的RADIUS数据库来维护拨入用户的身份验证和授权要求。人们还认为，直接拨号接入（例如，通过PSTN网络）是安全和可信的，不需要在LCP中实施的链路级认证之外进行任何审查。这种信念肯定不会与通过互联网的拨号接入共享。
So, while the same RADIUS database may be used for a user directly dialing-in or dialing in through the Internet, the security requirements may vary. The following RADIUS attributes may be used to mandate IPsec for the users dialing-in through the Internet. The exact values for the attributes and its values may be obtained from IANA (refer Section 10).
因此，虽然同一RADIUS数据库可用于用户直接拨入或通过互联网拨入，但安全要求可能有所不同。以下RADIUS属性可用于为通过Internet拨入的用户强制IPsec。属性及其值的准确值可从IANA获得（参考第10节）。
A new RADIUS attribute IPSEC_MANDATE (91) may be defined for each user. This attribute may be given one of the following values.
可以为每个用户定义新的RADIUS属性（91）。此属性可以被赋予以下值之一。
NONE (=0) No IPsec mandated on the IP packets embedded within PPP.
无（=0）PPP中嵌入的IP数据包上未强制IPsec。
LNS_AS_SRAS (=1) Mandates Tunnel mode IPsec on the IP packets embedded within PPP, only so long as the PPP session terminates at an LNS. LNS would be the tunnel mode IPsec end point.
LNS_AS_SRAS（=1）仅在PPP会话终止于LNS时，才对嵌入在PPP中的IP数据包强制使用隧道模式IPsec。LNS将是隧道模式IPsec的端点。
SRAS (=2) Mandates Tunnel mode IPsec on the IP packets embedded within PPP, irrespective of the NAS type the PPP terminates in. I.e., the IPsec mandate is not specific to LNS alone, and is applicable to any NAS, terminating PPP. NAS would be the tunnel mode IPsec end point.
SRA（=2）在嵌入PPP的IP数据包上强制使用隧道模式IPsec，而与PPP终止的NAS类型无关。也就是说，IPsec授权不仅仅针对LNS，而且适用于任何NAS，终止PPP。NAS将是隧道模式IPsec的端点。
When IPSEC_MANDATE attribute is set to one of LNS_AS_SRAS or SRAS, that would direct the NAS to drop any IP packets in PPP that are not associated with an AH or ESP protocol. As an exception, the NAS will continue to process IKE packets (UDP packets, with source and destination port set to 500) directed from remote users. Further, the security profile parameter, defined in the following section may add additional criteria for which security is not mandatory.
当IPSEC_委托属性设置为LNS_AS_sra或sra之一时，将指示NAS丢弃PPP中与AH或ESP协议无关的任何IP数据包。作为例外，NAS将继续处理来自远程用户的IKE数据包（UDP数据包，源端口和目标端口设置为500）。此外，以下部分中定义的security profile参数可能会添加安全性不是强制性的其他标准。
A new SECURITY_PROFILE (92) parameter may be defined in RADIUS to describe security access requirements for the users. The profile could contain information such as the access control security filters, security preferences and the nature of Keys (manual or automatic generated via the IKE protocol) used for security purposes.
可以在RADIUS中定义新的安全配置文件（92）参数，以描述用户的安全访问要求。配置文件可以包含用于安全目的的访问控制安全过滤器、安全首选项和密钥（通过IKE协议手动或自动生成）的性质等信息。
The SECURITY-PROFILE attribute can be assigned a filename, as a string of characters. The contents of the file could be vendor specific. But, the contents should include (a) a prioritized list access control security policies, (b) Security Association security preferences associated with each security policy.
可以为SECURITY-PROFILE属性分配一个文件名，作为字符串。文件的内容可以是特定于供应商的。但是，内容应该包括（a）优先级列表访问控制安全策略，（b）与每个安全策略关联的安全关联安全首选项。
If the security profile of a user requires dynamic generation of security keys, the parameters necessary for IKE negotiation may be configured separately using a new IKE_NEGOTIATION_PROFILE (93) parameter in RADIUS. IKE-NEGOTIATION_PROFILE attribute may be assigned a filename, as a string of characters. The contents of the file could however be vendor specific. The contents would typically include (a) the IKE ID of the user and SRAS, (b) preferred authentication approach and the associated parameters, such as a pre-shared-key or a pointer to X.509 digital Certificate, and, (c) ISAKMP security negotiation preferences for phase I.
如果用户的安全简档需要动态生成安全密钥，则可使用RADIUS中的新IKE_协商_简档（93）参数单独配置IKE协商所需的参数。IKE-U配置文件属性可以指定一个文件名，作为字符串。但是，文件的内容可能是特定于供应商的。内容通常包括（a）用户和sra的IKE ID，（b）优选认证方法和相关参数，例如预共享密钥或指向X.509数字证书的指针，以及（c）阶段I的ISAKMP安全协商偏好。
The author would like to express sincere thanks to Steve Willens for initially suggesting this idea. The author is also thankful to Steve for the many informal conversations which were instrumental in the author being able to appreciate the diverse needs of the Remote Access area.
作者要对史蒂夫·威伦斯最初提出这一想法表示衷心的感谢。作者还感谢Steve的许多非正式对话，这些对话有助于作者理解远程访问区域的各种需求。
This document is about providing secure remote access to enterprises via the Internet. However, the document does not address security issues for network layers other than IP. While the document focus is on security over the Internet, the security model provided is not limited to the Internet or the IP infrastructure alone. It may also be applied over other transport media such as Frame Relay and ATM clouds. If the transport media is a trusted private network infrastructure, the security measures described may not be as much of an issue. The solution suggested in the document is keeping in view the trust model between a remote user and enterprise.
本文档旨在通过Internet为企业提供安全的远程访问。但是，本文档并未解决IP以外的网络层的安全问题。虽然本文档的重点是Internet上的安全，但提供的安全模型并不局限于Internet或IP基础设施。它也可以应用于其他传输媒体，如帧中继和ATM云。如果传输介质是一个受信任的专用网络基础设施，那么所述的安全措施可能不是一个大问题。文档中建议的解决方案是考虑远程用户和企业之间的信任模型。
This document proposes a total of three new RADIUS attributes to be maintained by the IANA. These attributes IPSEC_MANDATE, SECURITY_PROFILE and IKE_NEGOTIATION_PROFILE may be assigned the values 91, 92 and 93 respectively so as not to conflict with the definitions for recognized radius types, as defined in http://www.isi.edu/in-notes/iana/assignments/radius-types.
本文件建议IANA总共维护三个新的RADIUS属性。这些属性IPSEC_委托书、安全_配置文件和IKE_协商_配置文件可分别分配值91、92和93，以避免与中定义的已识别半径类型的定义冲突http://www.isi.edu/in-notes/iana/assignments/radius-types.
The following sub-section explains the criteria to be used by the IANA to assign additional numbers as values to the IPSEC-MANDATE attribute described in section 7.1.
以下小节解释IANA将使用的标准，以将附加数字作为第7.1节中描述的IPSEC-Commission属性的值。
Values 0-2 of the IPSEC-MANDATE-Type Attribute are defined in Section 7.1; the remaining values [3-255] are available for assignment by the IANA with IETF Consensus [Ref 11].
IPSEC委托类型属性的值0-2在第7.1节中定义；剩余值[3-255]可由IANA在IETF协商一致的情况下分配[Ref 11]。
REFERENCES
参考资料
[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol L2TP", RFC 2661, August 1999.
[1] 汤斯利，W.，巴伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.和B.帕尔特，“第二层隧道协议L2TP”，RFC 26611999年8月。
[2] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[2] Rigney，C.，Rubens，A.，Simpson，W.和S.Willens，“远程认证拨入用户服务（RADIUS）”，RFC 21381997年4月。
[3] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[3] 辛普森，W.，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[4] Blunk, L. and Vollbrecht, J. "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[4] Blunk，L.和Vollbrecht，J.“PPP可扩展认证协议（EAP）”，RFC 2284，1998年3月。
[5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[6] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[7] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[7] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[8] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[9] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[9] Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also http://www.iana.org/numbers.html
[10] Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。另见http://www.iana.org/numbers.html
[11] Narten, T. and H. Alvestrand, "Guidelines for writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[11] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[12] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[12] Meyer，G.，“PPP加密控制协议（ECP）”，RFC 1968，1996年6月。
[13] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998.
[13] Sklower，K.和G.Meyer，“PPP DES加密协议，第2版（DESE bis）”，RFC 2419，1998年9月。
Author's Address
作者地址
Pyda Srisuresh Campio Communications 630 Alder Drive Milpitas, CA 95035 U.S.A.
美国加利福尼亚州米尔皮塔斯阿尔德大道630号Pyda Srisuresh Campio Communications，邮编95035。
Phone: +1 (408) 519-3849
EMail: srisuresh@yahoo.com
Phone: +1 (408) 519-3849
EMail: srisuresh@yahoo.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。