组织：中国互动出版网（https://www.doczj.com/doc/8216851146.html,/）
RFC文档中文翻译计划（https://www.doczj.com/doc/8216851146.html,/compters/emook/aboutemook.htm）E-mail：ouyang@https://www.doczj.com/doc/8216851146.html,
译者：刘建文（白狼janvin@https://www.doczj.com/doc/8216851146.html,）
译文发布时间：2001-10-15
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
Network Working Group B. Aboba
Request for Comments: 2809 Microsoft
Category: Informational G. Zorn
Cisco
April 2000
通过RADIUS的L2TP强制遂道的实现
（RFC2809 ——Implementation of L2TP Compulsory Tunneling via RADIUS）
本备忘录的状态
本文档为Internet团体提供了一些信息。它没有指定任何种类的Internet标准。本备忘录的发布不受任何限制。
版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
摘要
本文档讨论在使用L2TP协议的拨号网络中，出现在提供强制隧道时的实现问题。可以通过RADIUS和隧道协议综合来完成（强制隧道的）提供。关于其他隧道协议的实现问题留到单独的文档（讨论）。
目录
1．术语 (3)
2．约定语 (3)
3．引言 (3)
3.1．基于RADIUS的强制隧道的优点 (4)
4．两种认证选择 (4)
4.1．单一认证 (4)
4.1.1．NAS认证 (4)
4.1.2．有RADIUS应答转发的NAS认证 (5)
4.1.2.1．隧道服务器认证 (5)
4.1.2.2．基于电话号码认证 (6)
4.1.2.3. 用户名 (8)
4.2. 双重认证 (10)
5. 终止序列 (12)
6. 使用不同的RADIUS服务器 (13)
6.1. 不同的用户ID (13)
6.2. 多链路PPP问题 (14)
7. 用户ID问题 (14)
8. 参考资料 (14)
9. 安全考虑 (15)
10. 致谢 (15)
11. 主席地址 (15)
12. 作者地址 (16)
13. 知识产权声明 (16)
14. 完全版权声明 (17)
1．术语
自发隧道
自发隧道中，隧道是由用户来创建，典型的是通过一个隧道客户端的应用。
强制隧道
强制隧道中，隧道的建立没有用户的任何作用而且也不允许用户作任何选择。
隧道网络服务器
是一个用来终止一条隧道的服务器。在L2TP术语中，即为所知的L2TP网络服务
器（LNS）。
网络接入服务器
网络接入服务器（NAS）是客户端为了接入网络而连接的设备。在L2TP术语中，
一个执行强制隧道的NAS相当于作为L2TP接入集中器(LAC)。
RADIUS认证服务器
这是一个通过在(附录)[1]中所描述的协议来提供认证/授权的服务器。
RADIUS代理
为了向RADIUS路由提供认证请求，可以使用一个RADIUS代理。对于NAS，RADIUS代理看上去是作为一个RADIUS服务器，而对于RADIUS服务器，代理看上去是作为一个RADIUS客户端。当使用基于领域的隧道时，可以用来定位隧道终点。
2．约定语
本文档中，关键字“可以（MA Y）”、“必须（MUST）”、“不允许（MUST NOT）”、“可选（optional）”、“推荐（recommended）”、“应该（SHOULD）”和“不应该（SHOULD NOT）”按照参考文献[4]中的描述解释。
3．引言
隧道协议的大多应用包括拨号网络接入。有些，例如通过Internet提供到公司intranet （企业内部互联网）的可靠接入，具有主动隧道的特征：隧道是为某一特定目的在用户请求下建立。其他的应用包括强制隧道：隧道在没有来自于用户的任何作用而且不允许用户作任何选择的情况下建立。
可以利用强制隧道实现的应用实例是Internet软件升级服务器、软件注册服务器和银行系统服务。所有这些没有强制隧道的服务，都将可能利用专用网络或者至少是专用网络接入服务器（NAS）来提供，因为他们具有需要限制用户接入到特定主机的特性。
给定普遍支持强制隧道的实体，仍然可以通过任何因特网服务提供商（ISP）访问这些类型的服务。现今认证拨号网络用户的最流行的方式是通过RADIUS协议。RADIUS的作用是允许在一个中心位置维持拨号用户的授权和认证数据，而不是在每个NAS上。它对于使用RADIUS来集中管理强制隧道很有意义，因为RADIUS被广泛的配置和设计来传送这种类型的信息。需要新的RADIUS属性来传送从RADIUS服务器到NAS的隧道信息。那些属性在文献[3]中定义。
3.1．基于RADIUS的强制隧道的优点
当前对隧道请求的路由的建议包括静态隧道，其中所有用户被自动隧道接入到一个给定的终点，和基于领域的隧道，其中隧道终点从用户ID中的领域部分来决定。基于用户的隧道因为由RADIUS和隧道协议综合提供，具有这两种方法的重要优点。
为静态隧道这一目的需要专用一个NAS设备。ISP方面，这是不受欢迎的，因为它需要他们专用一个NAS来为一个特定客户提供隧道服务，而不是让他们应用在这个域中配置的已有的NAS。结果用静态隧道来开展全球服务可能是非常昂贵的。
基于领域的隧道假设在一个特定领域内的所有用户希望被以相同的方式对待。这限制了帐号管理中的适应性。例如，BIGCO可能希望给Janet提供一个帐号，允许他访问Internet 和intranet两种服务，Janet的intranet接入由位于工程部的一个隧道服务器提供。然而BIGCO可能希望给Fred提供一个只能接入到intranet的帐号，Fred的intranet接入由位于销售部的一个隧道服务器提供。这种情形不能使用基于领域的隧道，但可以通过被在文献[3]中定义的属性激活的基于用户的隧道来提供。
4．两种认证选择
基于RADIUS的强制隧道能支持两种认证，即，单一认证，用户在NAS和隧道服务器被认证，或双重认证，用户在NAS和隧道服务器两处都被认证。当支持单一认证时，可能有多种模式，其中包括基于电话号码认证。当使用双重认证时，也有许多模式可用，包括双重CHAP认证；CHAP/EAP认证；CHAP/PAP(token)认证；和EAP/EAP认证，对两个认证使用相同的EAP类型。EAP在资料[5]中描述。
下面对这两种选择作更详细的介绍。
4.1．单一认证
单一认证可供选择的方法包括：
NAS认证
有RADIUS应答转发的NAS认证
隧道服务器认证
4.1.1．NAS认证
用这种方法，认证和授权（包括隧道信息）在NAS上只发生一次。这个方法的优点是它禁止未经授权的的NAS用户接入网络，以及允许在NAS上记帐。缺点是它需要隧道服务器信任NAS，因为没有在隧道服务器上没有用户认证。由于缺少用户认证，不能在隧道服务器上进行需要严格保证准确用户结算的记帐。
单独NAS认证最典型的是与LCP转发和隧道认证一起使用，后面的二者都在L2TP中被支持，在资料[2]中描述。这样，隧道服务器可以设置为接受所有发生在已认证隧道中的呼叫，不需要PPP认证。然而这个方法不支持漫游，因为隧道服务器典型的设置为只接受
从限定的NAS来的隧道。典型的初始序列看上去是这样：
客户端和NAS：呼叫连接
客户端和NAS：PPP LCP协商
客户端和NAS：PPP认证
NAS到RADIUS服务器：RADIUS Access-request
RADIUS服务器到NAS：RADIUS Access-Accept/Access-Reject
NAS到隧道服务器：L2TP Incoming-Call-Request w/LCP forwarding(转发)
隧道服务器到NAS：L2TP Incoming-Call-Reply
NAS到隧道服务器：L2TP Incoming-Call-Connected
客户端和隧道服务器：NCP协商
该过程以一个到NAS的进入呼叫开始，接下来是客户端和NAS之间的PPP LCP协商。为了认证客户端，NAS会发送一个RADIUS Access-Request给RADIUS服务器并收到一个包含隧道属性的RADIUS Access-Accept或是一个Access-Reject。
在指定了一条L2TP隧道的情况下，如果之前不存在，NAS将提出一个控制连接，并且NAS 和隧道服务器将建立呼叫。至此，数据将开始流过这条隧道。NAS将典型的使用LCP转发，虽然对隧道服务器来说，重新协商LCP也是可能的。如果LCP允许重协商，NAS不应发送一个LCP CONFACK完成LCP协商。代替发送LCP CONFACK，NAS将变成发送一个LCP Configure-Request包，在资料[6]中描述。然后客户端可能重协商LCP，并且从这点向前，所有从客户端发起的PPP包将被封装并发送到隧道服务器。
由于地址分配将发生在隧道服务器上，客户端和NAS不许开始NCP协商。变为NCP 协商将发生在客户端和隧道服务器之间。
4.1.2．有RADIUS应答转发的NAS认证
这一方法中，认证和授权在NAS发生一次并且RADIUS应答转发给隧道服务器。该方法不接受未授权NAS用户的网络接入；并允许在隧道的两端进行记帐。然而，它也需要两端都与RADIUS服务器共享相同的密钥，因为那是隧道服务器能够检查RADIUS的Access-Reply的唯一方法。
这个方法中，隧道服务器将与所有的NAS和相关RADIUS服务器共享密钥，并且隧道服务器没有在这里提供LCP重协商。同样，隧道服务器需要知道如何去处理和验证RADIUS 的Access-Accept消息。
虽然如果应答直接来自于一个RADIUS服务器，这个方案是可用的，但如果包括一个RADIUS代理，它将变得难以管理，因为应答要用客户端和代理共享的密钥进行认证，而不是RADIUS服务器。结果，这个方案是不切实际的。
4.1.2.1．隧道服务器认证
这个方案中，认证和授权在隧道服务器发生一次。这要求NAS决定用户需要(怎样)建立隧道(通过RADIUS或是NAS配置)。如果使用了RADIUS，可使用下面方法之一来做决定：
基于电话号码认证
用户ID
4.1.2.2．基于电话号码认证
使用Calling-Station-Id和Called-station-Id RADIUS属性，授权和并发隧道属性能够以发起呼叫的电话号码或被呼叫号码为依据。这允许RADIUS服务器基于呼叫电话号码来授权用户或是基于Calling-Station-Id或Called-Station-Id来提供隧道属性。同样的，在L2TP 中隧道服务器可以基于包含在NAS发送的L2TP Incoming-Call-Request包中的被拨号码和拨叫号码来选择拒绝或接受这个呼叫。也可以基于Calling-Station-Id和Called-Station-Id 来进行记帐。
在资料[1]中定义的RADIUS要求一个Access-Request包包含一个User-Name属性，也（包含）一个必须为非空的CHAP-Password或User-Password属性。为满足这一要求，Called-Station-Id或Calling-Station-Id可以在User-Name属性中提供，而且一个伪值可以用于User-Password或CHAP-Password属性。
在基于电话号码认证的情况下，一个典型的开始顺序像这样：
客户端和NS：呼叫连接
NAS到RADIUS服务器：RADIUS Access-request
RADIUS服务器到NAS：RADIUS Access-Accept/Access-Reject
NAS到隧道服务器：L2TP Incoming-Call-Request
隧道服务器到NAS：L2TP Incoming-Call-Reply
NAS到隧道服务器：L2TP Incoming-Call-Connected
客户端和隧道服务器：PPP LCP协商
客户端和隧道服务器：PPP认证
隧道服务器到RADIUS服务器：RADIUS Access-request(可选)
RADIUS服务器到隧道服务器：RADIUS Access-Accept/Access-Reject
客户端和隧道服务器：NCP协商
该过程以一个到NAS的进入呼叫开始。如果配置为基于电话号码认证，NAS发送一个包含Calling-Station-Id和Called-Station-Id属性的RADIUS Access-Request。然后RADIUS 服务器将以一个RADIUS Access-Accept或Access-Reject响应。
在隧道建立起来之前，不允许NAS开始PPP认证。如果时限允许，NAS可以先于同对等实体开始LCP协商建立起隧道。如果这个完成，那么将不需要在对等实体和隧道服务器之间进行LCP重协商，也不需使用LCP转发。
如果基于电话号码的认证初始不成功，RADIUS服务器发送一个RADIUS Access-Reject。这种情况下，NAS必须发送一个LCP-Terminate并断开用户连接。
在隧道属性包含在RADIUS Access-Accept中，并且一条L2TP隧道被指出的情况下，NAS此刻将建立起一条控制连接，如果先前不存在。这通过向隧道服务器发送一个L2TP Start-Control-Connection-Request消息来实现。然后隧道服务器将用一个L2TP Start-Control-Connection-Reply应答。如果该消息指出一条错误(信息)，或者该控制连接在将来任意时刻被终止，那么NAS必须发送一个LCP-Terminate并断开用户连接。
之后，NAS将发送一个L2TP Incoming-Call-Request消息给隧道服务器。其他情况中，该消息将包含呼叫序列号，该号与NAS-IP-Address和Tunnel-Server-Endpoint一起用来唯一地确定这个呼叫。隧道服务器将用一个L2TP Incoming-Call-Reply消息应答。如果该消息指出一条错误，那么NAS必须发送一条LCP-Terminate并断开用户连接。如果没有指出错误，那么NAS就用一条L2TP Incoming-Call-Connected消息应答。
至此，数据可以开始通过隧道流通。如果NAS和客户端之间的LCP协商已经开始，然后就可以使用LCP转发，或者客户端和隧道服务器将现在重协商LCP并开始PPP认证。否则，
客户端和隧道服务器将第一次协商LCP并且之后转移到PPP认证阶段。
如果需要重协商，在重协商开始的时候，NAS不应该已经发送LCP CONFACK结束掉LCP 协商，而且不允许客户端和NAS已经开始NCP协商。胜于发送一条LCP CONFACK，NAS将代之于发送一个LCP Configure-Request包，在资料[6]中描述。之后客户端可以重协商LCP，并且从这一点之后，所有从客户端发出的PPP包将被封装并发送到隧道服务器。当LCP重协商已经结束， NCP阶段就将开始，并且隧道服务器将给客户端分配一个地址。
如果L2TP正在被用作隧道协议，且LCP重协商是必需的，NAS可以在它的初始设置通知（initial setup notification）中包括一份在每一方向发送来结束LCP协商的LCP CONFACK 的拷贝。之后隧道服务器可以用这条信息来避开一个附加的LCP协商。用L2TP，初始设置通知也可以包括认证信息，请求允许隧道服务器来认证用户以及决定接受或拒绝连接。然而，基于电话号码的认证中，PPP认证禁止在NAS建立隧道之前出现。其结果是禁止设置L2TP 认证转发。
PPP认证执行过程中，隧道服务器能够访问它自己的用户数据库，或是作为选择，能够发送一个RADIUS Access-Request请求。后面的方法在允许认证转发，比如有漫游或者共享使用网络的情况下很有用。在这种情况下，RADIUS和隧道服务器在统一的管理之下而且典型的被紧密放置在一起，可能在同一个LAN上。因此让隧道服务器担当RADIUS客户端提供了统一的用户管理。注意隧道服务器的RADIUS Access-Request典型地直接发送到本地RADIUS服务器而不是通过一个代理来转发。
下面概述这种包含在基于电话号码认证的强制隧道的初始化中的交互。为了简化下面的图表，我们省去了客户端。但是，应知道客户端通过PPP协商参与同隧道服务器的认证和并发数据交换。
初始化顺序
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call connected
Send RADIUS
Access-Request
with Called-Station-Id,
and/or Calling-Station-Id
LCP starts
IF authentication
succeeds
Send ACK
ELSE Send NAK
IF NAK DISCONNECT
ELSE
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send
Incoming-Call-Request
message to Tunnel Server
Send Incoming-Call-Reply
to NAS
Send
Incoming-Call-Connected
message to Tunnel Server
Send data through the tunnel
Re-negotiate LCP,
authenticate user,
bring up IPCP,
start accounting
4.1.2.3. 用户名
因为认证只发生在隧道服务器，在NAS的隧道初始化必须先于用户认证发生。结果，这一方案代表性地或者使用用户ID的域名部分，或者利用RADIUS服务器上的attribute-specific处理。因为用户身份从未被NAS验证，或者隧道服务器所有者必须乐于负担所有的入呼叫，或者为记帐目的，必须用诸如Calling-Station-Id的其他信息验证用户身份。
在attribute-specific处理中，可能使用RADIUS并且用一个属性发信号通知隧道初始化。例如，隧道属性可能被送回，如果User-Password属性包含一个伪值（比如“tunnel”或“L2TP”）。可选的，以一个特殊字符（‘*’）开始的用户ID可用来指出发起一条隧道的要求。当使用了attribute-specific处理，隧道服务器可能需要重协商LCP。
另外的解决方案包括使用用户ID的域名部分；在域X中的所有用户将通过隧道连到地址Y。这个建议支持强制建立隧道，但不提供基于用户建立隧道。
为了让NAS对连接开始记帐，将需要利用在到隧道服务器的认证过程中用户所声称的身份，因为它没有通过RADIUS来验证身份。但是，为使之在记帐中有用，隧道终点需要有一个与NAS属主相关联的帐号。这样即使用户拥有一个具有NAS属主的帐号，他们也不能利用这个帐号建立隧道，除非隧道终点还与NAS属主有一种商业关联。这样该方法与漫游是相矛盾的。
一个典型的包括利用用户ID域名部分的初始化顺序是这样的：
客户端和NAS：呼叫连接
客户端和NAS：PPP LCP协商
客户端和NAS：认证
NAS到隧道服务器：L2TP Incoming-Call-Request
隧道服务器到NAS：L2TP Incoming-Call-Reply
NAS到隧道服务器：L2TP Incoming-Call-Connected
客户端和隧道服务器：PPP LCP重协商
客户端和隧道服务器：PPP认证
隧道服务器到RADIUS服务器：RADIUS Access-request (可选)
RADIUS服务器到隧道服务器：RADIUS Access-Accept/Access-Reject
客户端和隧道服务器：NCP协商
此过程以一个到NAS的入呼叫开始，紧接着是客户端和NAS之间的PPP LCP协商。然后认证过程开始，且是基于用户ID的域名部分，如果先前没有，这时NAS将建立一条控制连接，并且NAS和隧道服务器将建立呼叫。至此，数据可以开始通过隧道传输。客户端和隧道服务器现在可以进行LCP重协商并将完成PPP认证。
在重协商开始时，NAS不应该已经发送LCP CONFACK完成LCP协商，而且客户端和NAS 不允许已开始NCP协商。胜于发送LCP CONFACK，该NAS将改为发送一个LCP Configure-Request包，详见资料[6]。然后客户端可以重协商LCP，并且从此刻开始，所有从客户端发起的PPP包将被封装并发送到隧道服务器。在单一认证的强制隧道中，不允许设置L2TP认证转发。当LCP重协商结束时，NCP阶段就会开始，而且隧道服务器将给客户端分配一个地址。
在PPP认证执行过程中，隧道服务器能够访问它自己的用户数据库，或者是它可以发送一个RADIUS Access-Request。隧道建立起来之后，NAS和隧道服务器能够开始记帐。
此交互概括如下。
初始序列
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call accepted
LCP starts
Authentication
phase starts
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
ENDIF
IF no control
connection exists
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send
Incoming-Call-Request
message to Tunnel Server
Send Incoming-Call-Reply
to NAS
Send
Incoming-Call-Connected
message to Tunnel Server
Send data through the tunnel
Re-negotiate LCP,
authenticate user,
bring up IPCP,
start accounting
4.2. 双重认证
此方案中，在NAS和隧道服务器两端都进行认证。这需要拨号客户端处理双重认证，伴随LCP重协商。为了让NAS和隧道服务器依据相同的数据库进行认证，要求隧道网络服务器上有RADIUS客户端能力，而且可能地在NAS终端上有一个RADIUS代理。
双重认证地优点包括在隧道的两端都支持认证和记帐；隧道网络服务器上的RADIUS的执行仅使用一个用户ID/口令对；不需要基于电话号码认证或者RADIUS服务器上的特殊属性处理。
双重认证允许在NAS和隧道服务器两端都生成记帐记录，使得能够进行审核。另外隧道终点不需要拥有一个筒NAS所有者想关联的帐号，使该方式适合于漫游。
双重认证的缺点是除非使用了LCP转发，LCP将需要被重新协商；有的客户端根本不支持这个，而其他的只支持双重认证组合的仅一个子集。可能的组合包括PAP/PAP（令牌环）、PAP/CHAP、PAP/EAP、CHAP/PAP（令牌环）、CHAP/CHAP、CHAP/EAP、EAP/CHAP以及EAP/EAP。EAP在资料[5]中详细描述。
在双重认证的情况下，一个典型的初始化顺序像这样：
客户端和NAS：PPP LCP 协商
客户端和NAS：PPP认证
NAS到RADIUS服务器：RADIUS Access-request
RADIUS服务器到NAS：RADIUS Access-Accept/Access-Reject
NAS到隧道服务器：L2TP Incoming-Call-Request
隧道服务器到NAS：L2TP Incoming-Call-Reply
NAS到隧道服务器：L2TP Incoming-Call-Connected
客户端和隧道服务器：PPP LCP 重协商(可选)
客户端和隧道服务器：PPP认证
隧道服务器到RADIUS服务器：RADIUS Access-request (optional)
RADIUS服务器到隧道服务器：RADIUS Access-Accept/Access-Reject
客户端和隧道服务器：NCP协商
这个过程以一个到NAS的入呼叫开始。然后客户端和NAS开始LCP协商。接下来PPP 认证阶段开始，并且NAS发送一个RADIUS Access-Request消息给RADIUS服务器。如果认证成功，RADIUS服务器用一个包含隧道属性的RADIUS Access-Accept响应。
在指定了一条L2TP隧道的情况下，如果先前不存在，NAS此刻将建立一条控制连接，并且NAS和隧道服务器将建立呼叫。至此，数据可以通过这条隧道开始流动。客户端和隧道服务器现在可以重协商LCP并经历另一轮PPP认证。在重协商开始时，NAS不应该已经发送一条LCP CONFACK结束LCP协商，并且客户端和NAS不允许已经开始NCP协商。胜于发送LCP CONFACK，NAS将改为发送一个LCP Configure-Request包，在资料[6]中描述。然后客户端可以重协商LCP，而且这之后，所有从客户端发起的PPP包都将被封装并发送给隧道服务器。当LCP重协商已经结束，就将开始NCP阶段，而且隧道服务器将分配一个地址给客户端。
如果用L2TP作为隧道协议，NAS可以在它的初始设置通知中包含在每一方向发送的用于结束LCP协商的LCP CONFACK的一份拷贝。然后隧道服务器可以使用该信息来避免额外的LCP协商。用L2TP,初始设置通知也能包含允许隧道服务器认证用户以及决定接受或拒绝连接所需要的认证信息。然而，这一功能引起重放攻击的弱点，并可能在NAS与隧道服务器依靠不同的RADIUS服务器认证的情况下引起问题。其结果，在实现通过RADIUS的基于用户的隧道的地方，不应设置L2TP认证转发。
在PPP认证执行过程中，隧道服务器能够访问它自己的用户数据库，或者它可以发送一条RADIUS Access-Request。在隧道建立起来之后，NAS和隧道服务器能够开始计费。
包含在有双重认证强制隧道初始化过程中的交互概括如下。
初始化序列
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call accepted
LCP starts
PPP authentication
phase starts
Send RADIUS
Access-Request
with userID and
authentication data
IF authentication
succeeds
Send ACK
ELSE Send NAK
IF NAK DISCONNECT
ELSE
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send
Incoming-Call-Request
message to Tunnel Server
Send Incoming-Call-Reply
to NAS
Send
Incoming-Call-Connected
message to Tunnel Server
Send data through the tunnel
Re-negotiate LCP,
authenticate user,
bring up IPCP,
start accounting
ENDIF
5. 终止序列
强制隧道的拆卸包含一个客户端、NAS和隧道服务器两两之间的交互。该交互事实上同样的不管是否使用的是基于电话号码认证、单一认证或者是双重认证。在任何情况下，下面的事件都要发生：
隧道服务器到NAS：L2TP Call-Clear-Request (可选)
NAS到隧道服务器：L2TP Call-Disconnect-Notify
隧道终止可能由于客户端请求（PPP终止）、隧道服务器请求(Call-Clear-Request)或者线路问题（呼叫断开）而发生。
在客户端请求终止的情况下，隧道服务器必须结束PPP会话。随后隧道服务器必须发送一个Call-Clear-Request给NAS。然后NAS必须发送一个Call-Disconnect-Notify消息给隧道服务器并将断开这个呼叫。
如果NAS收到从隧道服务器发来的一个没有client-requested终止的Call-Clear-Request，它必须也用一个Call-Disconnect-Notify消息响应并断开连接。
在线路问题或是用户挂断的情况下，NAS必须发送一条Call-Disconnect-Notify给隧道服务器。然后两侧都将拆掉这个呼叫。
包含在强制隧道的终止中的交互概括如下。为了简化随后的图表，我们略去了客户端。然而，客户端可以通过PPP参与终止和断开连接是明了的。
终止序列
NAS Tunnel Server RADIUS Server
--- ------------- -------------
IF user disconnected
send
Call-Disconnect-Notify
message to tunnel server
Tear down the call
stop accounting
ELSE IF client requests
termination
send
Call-Clear-Request
to the NAS
Send
Call-Disconnect-Notify
message to tunnel server
Disconnect the user
Tear down the call
stop accounting
ENDIF
6. 使用不同的RADIUS服务器
在NAS和隧道服务器使用不同的RADIUS服务器的情况下，一些有趣的情形可能会出现在强制隧道的提供过程中。
6.1. 不同的用户ID
如果使用不同的RADIUS服务器，可能会需要不同的用户ID/口令对来完成RADIUS和隧道认证。一对将用在同NAS的初始PPP认证中，另一对将用在隧道服务器上的认证。
这意味着NAS在初始设置通知中是否试图转发认证信息到隧道服务器。因为用于隧道认证的用户ID/口令对与用于NAS认证时的不同，在这种方式下转发认证信息将导致隧道认证失败。结果，在实现通过RADIUS的基于用户的隧道的地方，不应该设置L2TP认证转发。
为了在用户ID/口令对相同的情况下提供最大简化的应用，隧道客户端典型的尝试用与在初始PPP协商中所用的相同用户ID/口令对进行认证。仅当这种方式失败后才提示用户要求另外一对。胜于提供一条错误信息指出认证失败，更可取的是出现一个对话请求该隧道用户ID/口令组合。
类似的问题出现在使用了扩展认证方式时，像由EAP激活的，在资料[5]中描述。特别的，当使用了一次性口令或加密计算时，在初次和二次认证中将使用不同的口令。这样将需要提示用户输入第二口令。
6.2. 多链路PPP问题
两个RADIUS服务器返回不同的端口－限定（Port-Limit）属性是可能的。例如，可能NAS RADIUS服务器只准使用一条单一通道，而隧道RADIUS服务器允许使用多于一条的通道。在这种情况下，正确的行为是为隧道客户端打开一条到另一NAS的连接，目的是建立起一个隧道服务器上的多重链接束。客户端不允许向NAS指出该额外链接是作为多重链接束的一部分被建立；这将只能在与隧道服务器的并发协商中被指出。
也可能NAS RADIUS服务器会允许客户端建立多路通道，但隧道RADIUS服务器将允许比NAS RADIUS服务器更少的通道。在这种情况下，客户端应该终止额外通道的使用。
7. 用户ID问题
在提供漫游和共享使用网络时，必要条件之一是能够将认证请求发送到用户的本地RADIUS服务器。这种认证发送（路由）是基于在初始PPP认证阶段由用户向NAS提交的用户ID来完成的。用户ID随后被NAS在User-Name属性中转发给RADIUS服务器，作为RADIUS Access-Request的一部分。
类似的，资料[2]中引用了在决定隧道终点中用户ID的使用，虽然它并没有提供如何实现RADIUS或隧道路由的指导方针。这样存在译码不一致的可能。
RADIUS在强制隧道提供中的应用解除了用户ID必须具备双重用途的需要。用户ID现在只用于RADIUS认证/授权请求，胜于用在RADIUS认证/授权请求路由同时还要用在隧道终点的决定。然后在RADIUS Access-Response中的隧道属性被用来决定隧道终点。
由于本文档中描述的框架允许ISP以及隧道使用者二者来认证用户同时对他们所消费的资源计费，并且提供对两个不同用户ID/口令对的维护，本方案提供了高度的适应性。在设置了RADIUS代理和隧道的地方，可能允许用户在NAS和隧道终点两端用一个单一的用户ID/口令对进行认证。这通过向隧道服务器使用的相同的RADIUS服务器发送NAS RADIUS Access-Request来实现。
8. 参考资料
[1] Rigney C., Rubens A., Simpson W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997.
[2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
Palter, B., "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
August 1999.
[3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
Goyret, I., "RADIUS Attributes for Tunnel Protocol Support",
Work in Progress.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Blunk, L. anf J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
9. 安全考虑
在基于PPP的隧道中，PPP安全在客户端和隧道服务器二者之间来协商，并覆盖全部路线长度。这是因为客户端无法得知他们正在被建立隧道。这样，除了在客户端同NAS间的协商之外，任何安全也将发生在NAS与隧道服务器可能的协商中。
在L2TP强制隧道中，这意味着将在客户端和隧道服务器之间进行PPP加密和压缩的协商。另外，NAS可以在它自己和隧道服务器之间建立一个IPSEC安全联盟。这加强了针对一定数目可能攻击的保护。
在设置了RADIUS代理的地方，由RADIUS服务器发送的Access-Reply可以在被NAS接收之前被一个或多个代理处理。为了确保隧道属性没有任何修改的到达，中间的RADIUS代理转发Access-Reply不允许修改隧道属性。如果该RADIUS代理不支持隧道属性，那么它必须发送一条Access-Reject给NAS。这对于如果RADIUS服务器所查询的服务能够提供，确保用户被单独准许访问是必需的。
因为RADIUS隧道属性被用于强制隧道，地址分配由隧道服务器处理要胜于NAS。结果，如果存在隧道属性，NAS必须忽略由RADIUS服务器发送的任何地址分配属性。另外，NAS 和客户端不允许开始NCP协商，因为这可能会建立一个时间窗，在该时间窗内客户端将能够向传输网发送数据包，这在强制隧道中是不允许的。
10. 致谢
感谢Microsoft的Gurdeep Singh Pall对该问题空间的很多有益讨论，以及Tut系统的Allan Rubens和AT&T欧洲实验室的Bertrand Buclin，感谢他们对本文档所作的注释。
本文档的大部分工作在Glen Zorn供职于微软公司时完成。
11. 主席地址
可以通过当前主席联系RADIUS工作组：
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
Phone: +1 510-426-0770
EMail: cdr@https://www.doczj.com/doc/8216851146.html,
12. 作者地址
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425-936-6605
EMail: bernarda@https://www.doczj.com/doc/8216851146.html,
Glen Zorn
Cisco Systems, Inc.
500 108th Avenue N.E., Suite 500
Bellevue, WA 98004
USA
Phone: +1 425 438 8218
FAX: +1 425 438 1848
EMail: gwz@https://www.doczj.com/doc/8216851146.html,
13. 知识产权声明
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive Director.
14. 完全版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
感谢
Funding for the RFC Editor function is currently provided by the Internet Society.
标准Radius协议包结构 图9 Radius包格式 Code：包类型；1字节；指示RADIUS包的类型。 1Access- request 认证请求 2 Access- accept 认证响应 3 Access- reject 认证拒绝 4 Accounting-request 计费请求 5 Accounting-response 计费响应 *11 Access-challenge 认证挑战 Identifier：包标识；1字节，取值范围为0 ～255；用于匹配请求包和响应包，同一组请求包和响应包的Identifier应相同。 Length：包长度；2字节；整个包中所有域的长度。Authenticator：16 字节长；用于验证RADIUS服务器传回来的请求以及密码隐藏算法上。 该验证字分为两种： 1、请求验证字---Request Authenticator 用在请求报文中,必须为全局唯一的随机值。 2、响应验证字---Response Authenticator 用在响应报文中，用于鉴别响应报文的合法性。 响应验证字＝MD5(Code+ID+Length+请求验证字+Attributes+Key) Attributes：属性
图10 属性格式 Type 1 User-Name 2 User-Password 3 CHAP-Password 4 NAS-IP-Address 5 NAS-Port 6 Service-Type 7 Framed-Protocol 8 Framed-IP-Address 9 Framed-IP-Netmask 10 Framed-Routing 11 Filter-Id 12 Framed-MTU 13 Framed-Compression 14 Login-IP-Host 15 Login-Service 16 Login-TCP-Port 17 (unassigned) 18 Reply-Message 19 Callback-Number 20 Callback-Id 21 (unassigned) 22 Framed-Route 23 Framed-IPX-Network 24 State 25 Class 26 Vendor-Specific 27 Session-Timeout 28 Idle-Timeout 29 Termination-Action 30 Called-Station-Id 31 Calling-Station-Id
石药集团中诺药业（石家庄）有限公司 302车间三楼隧道烘箱性能确认方案 ZNYY/JB/YZ/F3/342/E00 起草人：起草日期： 验证领导小组组长： 批准日期：
目录 一引言 (3) 1 概述 (3) 2 目的 (3) 二验证准备 (4) 1 验证人员及职责 (4) 2 引用文件 (4) 3 培训 (5) 4 仪器、仪表及其校验 (5) 三验证实施 (5) 1 相关条件的确认 (5) 2 验证步骤 (6) 3 验证合格标准 (11) 四偏差分析及变更 (11) 五验证结论及评价 (11) 六附录及附表 (12)
302车间三楼隧道烘箱性能确认方案 一引言 1 概述： 302车间为青霉素类粉针剂生产车间，三楼现有C线和D线两条生产线，洗瓶岗位各安装一台隧道烘箱，分别是由济宁高新区康达自动化设备厂生产的KDSD-Ⅱ型隧道烘箱（设备编号为30207017）和上海华东制药机械有限公司生产的H-GMS-A型隧道烘箱（设备编号为30207018），用于清洁后的西林瓶的干燥、灭菌和冷却。这两条生产线可以适应多种规格西林瓶的干燥灭菌，包括7ml模制瓶、7ml管制瓶、10ml管制瓶、10ml模制瓶、12ml 模制瓶（仅D线有）、15ml模制瓶（仅D线有）、18ml模制瓶、20ml模制瓶等几种西林瓶的生产，高度从40.8毫米至58毫米。 本设备采用远红外石英加热管作为热源，连续进行干燥灭菌，不锈钢网带连续传送。具体分布情况见示意图如下，其中干燥灭菌部分分为预热段—灭菌段Ⅰ、灭菌段Ⅱ—保温三个加热段，均为上加热，加热管均匀分布，C线预热段12根、灭菌段Ⅰ20根、灭菌段Ⅱ18根、保温段12根，共62根加热管； D线预热段9根、灭菌段Ⅰ18根、灭菌段Ⅱ15根、保温段6根，共48根加热管。冷却段部分由耐高温百级层流高效过滤器将空气净化后对西林瓶进行冷却。 热辐射隧道烘箱干燥灭菌 整台设备安装在生产线洗瓶十万级洁净区内，其前端与洗瓶机相连，后端设在万级洁净室内。西林瓶从洗涤洁净至进入烘箱、从烘箱出口至万级洁净室内接瓶转盘均在100级层流保护下进行，保证清洁灭菌后的西林瓶没有再次污染的可能。同时设备运行状态能在触摸屏上动态显示，直观了解机组运行情况，并有自动记录和打印各主要运行参数的功能。 此设备验证为周期性再验证。 2 目的： 2.1 确认隧道烘箱和无菌室之间气流平衡，箱体内部空气洁净度达到百级标准。 2.2 确认烘箱运行正常，热分布均一性以及灭菌除热原性都能满足粉针生产需要。 2.3 通过西林瓶水分、出口温度等参数测试，确认烘箱对西林瓶烘干和冷却性能可
2020年山西省中小学教师职称改革细则 大家是否还不清楚20xx年最新陕西省中小学教师职称改革的最新方案呢?下面就等小雅告诉你吧! 20xx年山西省中小学教师职称改革方案 20xx年8月31日召开的国务院常务会议决定扩大中小学教师职称制度改革试点这一规定出台以后，意味着全国将有越来越多的中小学教师可以参评与教授级别一样的正高级职称，这一规定提高了中小学教师职称评定的做法，无疑是提高了教师的工作积极性，同时从侧面反映了国家对于教育行业的大力支持。我们来看看最新的规定吧。 8月26日，国务院召开常务会议决定全面推开中小学教师职称制度改革，为基础教育发展提供人才支撑。 会议决定，将中小学教师职称制度改革在全国全面推开： 一、是将分设的中学、小学教师职称(职务)系列统一为初、中、高级。 二、是修订评价标准，注重师德、实绩和实践经历，改变过分强调论文、学历倾向，并对农村和边远地区教师倾斜。 三、是建立以同行专家评审为基础的评价机制，并公示结果、接受监督。 四、是坚持职称评审与岗位聘用相结合，实现人尽其才、才尽其用。
中小学教师职称制度改革相关细则 健全制度体系 遵循中小学教师成长规律和职业特点，将原中学教师职务系列与小学教师职务系列统一并入新设置的中小学教师职称(职务)系列。统一后职称(职务)等级和名称为：员级、助理级、中级、副高级、正高级，职称(职务)名称依次为三级教师、二级教师、一级教师、高级教师和正高级教师。原中学高级教师(含小学小中高)对应高级教师;原中学一级教师和小学高级教师对应一级教师;原中学二级教师和小学一级教师对应二级教师;原中学三级教师和小学二级教师对应三级教师。 完善评价标准，创新评价机制 按照国家新制定的《中小学教师专业技术水平评价基本标准条件》，明年上半年省人力资源和社会保障厅、省教育厅将新出台我省中小学教师中、高级专业技术职务评聘条件。 重点是坚持育人为本、德育为先原则，注重师德素养、注重教育教学工作业绩、注重教育教学方法、注重教育教学一线实践经历，切实改变以往过分强调论文、学历的倾向，引导教师立德树人、爱岗敬业、积极进取，不断提高实施素质教育的能力和水平。 根据国家《中小学教师水平评价基本标准条件》第二条规定，中小学教师评聘各级专业技术职务须“具备相应的教师资格及专业知识和教育教学能力，在教育教学一线任教，切实履行教
AAA和RADIUS／HWTACACS协议简介 1.1.1 aaa概述 aaa是authentication，authorization and accounting（认证、授权和计费）的简称，它提供了一个用来对认证、授权和计费这三种安全功能进行配置的一致性框架，实际上是对网络安全的一种管理。 这里的网络安全主要是指访问控制，包括： 哪些用户可以访问网络服务器？ 具有访问权的用户可以得到哪些服务？ 如何对正在使用网络资源的用户进行计费？ 针对以上问题，aaa必须提供下列服务： 认证：验证用户是否可获得访问权。 授权：授权用户可使用哪些服务。 计费：记录用户使用网络资源的情况。 aaa一般采用客户/服务器结构：客户端运行于被管理的资源侧，服务器上集中存放用户信息。因此，aaa框架具有良好的可扩展性，并且容易实现用户信息的集中管理。 1.1.2 radius协议概述 如前所述，aaa是一种管理框架，因此，它可以用多种协议来实现。在实践中，人们最常使用radius协议来实现aaa。 1. 什么是radius radius是remote authentication dial-in user service（远程认证拨号用户服务）的简称，它是一种分布式的、客户机/服务器结构的信息交互协议，能保护网络不受未授权访问的干扰，常被应用在既要求较高安全性、又要求维持远程用户访问的各种网络环境中（例如，它常被应用在管理使用串口和调制解调器的大量分散拨号用户）。radius系统是nas（network access server）系统的重要辅助部分。 当radius系统启动后，如果用户想要通过与nas（pstn环境下的拨号接入服务器或以太网环境下带接入功能的以太网交换机）建立连接从而获得访问其它网络的权利或取得使用某些网络资源的权利时，nas，也就是radius客户端将把用户的认证、授权和计费请求传递给radius服务器。radius服务器上有一个用户数据库，其中包含了所有的用户认证和网络服务访问信息。radius服务器将在接收到nas传来的用户请求后，通过对用户数据库的查找、更
隧道烘箱温度验证方案 设备名称：隧道烘箱 规格型号：HQL3360 生产厂家： 使用厂家：有限公司 安装位置： 灭菌物品：7ml、10ml、25ml管制西林瓶；7ml、12ml模制西林瓶验证时间：
目录 一、验证实施的条件 (3) 二、验证的实施 (4) 1、空载热分布测试 (4) 2、满载热分布测试 (6) 3、满载热穿透测试 (8) 4、生物指示剂挑战性试验 (10) 5、验证结果的综合评价 (13)
验证的实施条件 1．验证名称 隧道烘箱温度验证方案 2．验证目的 检查并确认隧道烘箱在SOP（BY/5SJ-101-2004）控制条件下空载热分 布、满载热分布（即温度均一性）符合GMP规定要求，满载热穿透能 够达到除热原的作用。 3．验证依据 《药品生产质量管理规范实施指南》2003版 4．验证周期 根据设备使用情况，每年对设备进行一次验证。 5．验证小组人员及其分工 6．验证用标准仪器： 美国KAYE公司温度验证验证仪； HTR-400温度干井； IRTD-400智能热电阻(技术参数见校验报告)； T型热电偶
验证的实施 1.空载热分布测试 1.1.验证目的 检查并确认隧道烘箱在SOP控制条件下，空载运行时隧道烘箱的温度 均一性符合GMP规范。 1.2.验证规程 1.2.1.检查KAYE验证仪，模拟运行以证实其处于正常状态。 1.2.2.验证人员对隧道烘箱进行现场考察，以设计T型热电偶进入隧道烘箱 内部的方式及测点的分布。 ? ?10支T型热电偶垂直于网带运行方向均匀分布，从左往右编号依次为101到 110 1.2.4.使用HTR-400温度干井及IRTD-400智能热电阻，对验证所需的T型 热电偶进行前校验，保证可以正常使用的T型热电偶数量大于等于设 计所需数量，校验数据报告见附件。 1.2.5.按照热电偶的分布图将10支T型热电偶布到隧道烘箱内。 1.2.6.通知生产操作人员和技术人员，做好验证前的准备工作。 1.2.7.启动KAYE温度验证仪，设定采集数据记录的时间间隔为30s，验证记 录周期不小于隧道烘箱的灭菌周期。 1.2.8.操作人员按SOP规定进行隧道烘箱的操作，温度数据记录和相应最大 温差等的计算由KAYE温度验证仪自动完成，验证过程中的相关数据 由小组成员记录，记录时间间隔与验证仪所设定时间间隔相等。 1.2.9.验证连续进行三次，以确定结果的重现性。 1.2.10.空载热分布测定结果记录见附件 1.2.11.判断标准： 灭菌阶段，隧道烘箱达到稳定时空载热分布的最大温差≤15℃。 1.2.12.对空载热分布测定结果进行综合评价，记录见表1：
属性值属性名称意义 1 User-Name 用户名 2User-Password 用户密码 3Chap-Password Chap认证方式中的用户密码 4 Nas-IP-Address Nas的ip地址 5 Nas-Port 用户接入端口号 6 Service-Type 服务类型 7 Framed-Protocol协议类型 8 Framed-IP-Address 为用户提供的IP地址 9 Framed-IP-NetMask 地址掩码 10 Framed-Routing 为路由器用户设置的路由方式 11 Filter-Id 过滤表的名称 12 Framed-MTU 为用户配置的最大传输单元 13 Framed-Compression 该连接使用压缩协议 14 Login-IP-Host 对login用户提供的可连接主机的ip地址 15 Login-Service 对login用户可提供的服务 16 Login-TCP-Port TCP服务端口 18 Reply-Message 认证服务器返回用户的信息 24 State 认证服务器发送challenge包时传送的需在接下来的认证报文中回应的字符串（与Acess-Challenge相关的属性） 25 Class 认证通过时认证服务器返回的字符串信息，要求在该用户的计费报文中送给计费服务器 26 Vendor-Specific 可扩展属性 27 Session-Timeout 在认证通过报文或Challenge报文中，通知NAS该用户可用的会话时长（时长预付费） 28 Idle-Timeout 允许用户空闲在线的最大时长 32 NAS-Identifier 标识NAS的字符串 33 Proxy-State NAS通过代理服务器转发认证报文时服务器添加在报文中的属性 60 Chap-Challenge 可以代替认证字字段传送challenge的属性 61 Nas-Port-Type 接入端口的类型 62 Port-Limit 服务器限制NAS为用户开放的端口数 40 Acct-Status-Type 计费请求报文的类型 41 Acct-Delay-Time Radius客户端发送计费报文耗费的时间 42 Acct-Input-Octets 输入字节数 43 Acct-Output-Octets 输出字节数 44 Acct-Session-Id 计费会话标识 45 Acct-Authentic 在计费包中标识用户认证通过的方式 46 Acct-Session-Time 用户在线时长 47 Acct-Input-Packets 输入包数 48 Acct-Output-Packets 输出包数 49 Acct-Terminate-Case 用户下线原因 50 Acct-Multi_Session-Id 相关计费会话标识 51 Acct-Link-Count 生成计费记录时多连接会话的会话个数 ?
隧道烘箱的验证 一、方案制定：1999年8月15日 验证项目编号：EJ-003-99 方案批准人： 批准日期：1999.8.20 二、验证目的：头孢及青霉素粉针车间于99年8月停产大修，各流水线隧道烘箱仪表、机 械装置均经过检修并更换高效过滤器介质，需对灭菌效果再验证。 验证日期：1999年8月20日～9月30日 五、验证操作 1. 设备系统描述：隧道烘箱的型号、规格、生产能力、技术特性及运行状况。(见验证报 告) 2. 操作 (1)将已校正的热电偶与烘箱温度探头放在一起，以空载方式运行，同时校正温度控制器、 记时器、记录仪表及传送带速度。要求温度校正误差≤1℃，记时器校正误差≤1%。 (2)空载热分布试验 A.将一支热电偶放在烘箱自身的温度探头附近，另有九只热电偶绑在9只瓶子的外沿， 9只瓶子分别分布在传送带的左中右及前中后通过隧道(注意热电偶不应与腔室内金属接触)。 B.做热分布试验时，传送事带设定平时生产时的最大速度。 C.每隔1分钟记录一次，并应记录整个灭菌过程。 D.重复试验3次，以证明热分布的重现性。 六、灭菌效果的合格标准 (1)各点温度值与设定值之间的偏差≤15℃。 (2)每只瓶子的灭菌温度均能达到350℃5分钟以上或300℃以上3分钟，以保证去除 热原。 七、如空载热分布不符合标准，应调整进风，回风及循环风，改善空气流动，重新测试，直 至符合标准。 八、验证报告及原始记录(见附页) (1)热电偶位置示意图及热电偶编号。 (2)使用的主要检测仪器的名称、规格、型号 (二)操作方法
1. 准备工作 (1)新的或久放未用的玻璃电极应在水中浸泡一昼夜，使膜外形成水合胶层以稳定其不对称电位。平时最好浸泡在水中，以便下次用时可很快进行工作。使用前，把电极轻轻振摇，使电极内溶液下落到玻璃泡内。然后，将它装到电极夹中。玻璃电极装到电极夹中时应高于甘汞电极，避免烧杯底与球膜相碰，并将玻璃电极异线插入玻璃电极插孔处。 (2)甘汞电极中应充满饱和的氯化钾溶液，溶液中应保留有少量氯化钾结晶。并注意不得有气泡将溶液隔断。使用前，把电极弯管下端的橡皮套和加液口的胶塞除去，然后将甘汞电极的上部金属帽夹在电极夹中，因电极夹与仪器内部是连通的，所以不须再接导线。 (3)接通电源后，打开开关，指示灯即显示，预热30分钟后使用。 2. 校准 (1)将PH-MV开关转至PH档。 (2)将温度补偿器转至与待测溶液的温度一致。 (3)根据所用标准PH缓冲溶液的PH值，将量程选择开关转至“7～0”或“7～14”处。前者测量PH刻度范围为0～7，后者测量PH刻度范围为7～14。 (4)调节零点调节器，使表头指针恰好在PH为7的位置上。 (5)将电极插入标准PH缓冲溶液中。 (6)按下读数开关并略为转动，即可使读数开关按下不动(此时电池两电极接入测量线路中)，然后调节定位调节器，使电表上的读数恰为此时所用标准PH缓冲溶液的PH值。 (7)把读数开关反方向转动并放开它。电表指针应该恢复至PH7的位置。如有变动，则再反复调节零点调节器，使指针恰好在PH=7处。重复(6)(7)两项操作，反复核对直到符合为止。校正后，定位调节器不可再动，否则应重新校正。 (8)校正完毕，移去标准PH缓冲溶液，以蒸馏水冲洗电极。 3. 测量 (1)小心用滤纸将附在电极上的水分吸干，并用待测溶液冲洗电极，然后把两支电极浸入待测溶液中，轻轻摇动烧杯(杯壁远离玻璃电极)，使之均匀。 (2)待测溶液的温度应与校正用的标准PH缓冲溶液的温度相同，否则应用温度补偿器调节至与待测溶液的温度一致。 (3)检查电表指针是否指在PH=7处(此时读数开关未按下)，如果不在7处，应调节零点调节器，使指针恰好在PH7处。 (4)按下读数开关，指针所指即为待测溶液的PH值。如果指针超出刻度范围，应转换量程0～7或7～14，再重复(3)、(4)两步操作。 (5)测定完毕后，放开读数开关，关上电源开关，拔去电源插头。先取下玻璃电极，用蒸馏水洗净，浸泡在水中待下次用，再取下甘汞电极，加液口塞上胶塞，弯管下端套上橡皮帽，放置匣中。 4. 注意事项 (1)每次使用，在校正和测定前后都应该用蒸馏水将电极充分洗净。 (2)待测溶液与校正用标准缓冲溶液的温度应相近或相同，差异不宜超过2℃。待测液与标准缓冲液，PH的差值应小于2个PH单位。 (3)测量溶液的PH值不可大于9，如果超过则应该用231型锂玻璃电极测定。 (4)电表的指针应避免向两面打击，搬动或不用时，将电表短路使指针固定，以减少摆防止损坏。 (5)玻璃电极很易破碎，切不可用硬物碰它，使用前可用软纸轻轻吸去沾在玻球表面的水分。
P3温度验证仪在隧道式烘箱温度验证中的应用案例 服务的客户：XXX制药总厂 温度验证设备：干热灭菌隧道烘箱 隧道式烘箱温度验证的意义： 工作原理简述： 隧道烘箱一般采用长箱体热风循环或者远红外干燥方式进行干燥的一种烘箱。主要是为了针对产量高和效率高的产品，进行烘干干燥与灭菌的需求。隧道烘箱在计算机系统的监控下，瓶子随输送带的输送依次进入隧道灭菌烘箱的预热区、高温灭菌区和低温冷却区。输送带速度可调节。 隧道式烘箱温度验证的目的： 1、确认灭菌与烘干过程中，烘箱内温度达到稳定状态时各测试点温度符合要求； 2、确认灭菌过程中，箱体内各测试点灭菌有效，Fh值符合要求； 3、确认灭菌过程中，箱体内温度热分布情况，以及产品内温度分布情况； 4、确认预热过程中、恒温过程中、冷却过程中箱体隧道温度没有异常情况，且能达到预期要求。 验证仪器选用： 1、INON研工P3温度验证仪一台（INON研工温度验证仪可进行温度前校准和 后校验，保证验证的完整性与可追溯性，温度数据报告分析详细，温度与Fh值大小比较与总结直观，能很好提供给客户温度信息）
2.温度校准仪AMETEK PTC-425A 制药版干体炉/干式计量 2、INON研工 PT100型热电阻干热探头/干热温度传感器（INON研工温度验证系统中的干热温度探头采用德国进口PT100薄膜铂电阻，精度等级1/3B级（高
于A级的正负度），经过校准可达到正负度，远远高于药品生产验证指南正负度的要求。） 4、干热探头支架 验证步骤： 1、探头校准（根据厂家验证需求，选择一定数量的温度探头进行校准）
本次验证准备16根已编号的PT100型热电阻干热探头，在干式计量炉中，低温300℃、高温350℃进行校准，在320℃分别确认热电阻偏差，校准读取偏差应远小于℃。 2、探头布置 将干热探头并排放在支架上面固定（保证在同一个截面上），放在隧道烘箱轨道入口处。开启灭菌隧道烘箱，探头支架随隧道进入烘箱内，干热探头线通过入口门缝缓缓进入隧道烘箱内，验证仪启动记录数据。（详情见验证方案分布图） 3、操作电脑设定好灭菌参数，首先测空载，检查烘箱空载温度均匀性情况。然后依次做满载分布、满载穿透情况下温度情况。 4、温度验证合格标准 a、温度均匀性：在320℃恒温生产工艺灭菌时间内，箱体内同一时刻，同一截面所有测试点的温度最大值与最小值之差不得大于 10℃； b、隧道烘箱恒温段大于5分钟，恒温段温度在310℃与330℃之间，冷却段结束温度在50度以下； c、在灭菌过程中各测试点灭菌有效，Fh值合格。 5、生成报告 确认工作结束，通过软件生成 pdf 格式报告，打印生成的报告，由验证人员及审核人员审核签字，作为附件附于验证方案后，与验证方案中结论形成最终的温度确认报告。报告包括以下三个部分：验证报告、数据报表、校准证书。 验证报告为验证人员及审核人员对验证的全过程及报告做出的综合评价及最终结论。 注意事项： 1、本次隧道式烘箱温度验证预计共做九次： 恒温段为320℃灭菌条件下，空载三次、满载分布三次、满载穿透三次。 2、确保温度验证系统已经准备妥当，验证系统满足验证要求。温度验证系统连接电源可靠接地； 3、隧道烘箱温度可以先升温到稳定生产温度环境下再开始温度验证。
山西省义务教育地方课程设置方案
山西省义务教育地方课程设置方案（试行） 为了进一步深化全省基础教育课程改革工作，根据《国务院关于基础教育改革与发展的决定》、教育部《基础教育课程改革纲要（试行）》的精神，按照《山西省农村义务教育经费保障机制改革实施方案》和《山西省基础教育地方课程建设指导意见（试行）》的要求，结合我省社会、经济和教育发展实际，制定本方案。 一、地方课程的主要目标 １、地方课程开发与管理的目标 全面贯彻《基础教育课程改革纲要（试行）》，实行国家、地方、学校三级课程管理，改变课程管理过于集中的状况，建立和完善我省地方课程体系和管理机制。 加强课程与地方社会经济发展、学生生活实际的联系，不断优化义务教育课程结构。 推动全省基础教育课程研究、课程管理和课程开发队伍的建设，提高地方课程管理与课程开发的能力。 2、地方课程的教育目标 注重地方特色，增进学生对我省社会经济、自然、历史文化的认识和理解，培养和提高学生的人文精神，增强学生热爱生活、热爱家乡的情感，增强学生的社会责任感。
联系社会生活实际，增进学生对国情等方面的认识和理解；培养学生关注社会，关爱人类的意识和情感；增强学生明辨是非、善恶和美丑的能力；促进学生形成健康的生活态度和生活方式，养成良好的心理品质。 拓展学生知识领域，增进学生对适应我省经济社会发展需要的实用技能与技术的认识和理解，培养学生的探究和创新意识，提高探究和实践能力，增强学生的社会适应性。 二、地方课程设置的原则 地方课程是基础教育课程体系的重要组成部分，要突出地方特色，面向全体学生，增强对地方的适应性和针对性，体现鲜明的时代性和现实性，为地方经济发展和社会进步服务。 L、系统性原则 地方课程的设置要贯彻党的教育方针，符合学生的身心发展规律，注重学科知识的内在联系。要立足地方特点，统筹规划，整体设定课程门类和安排教学内容。 2、独立性原则 地方课程要与国家课程、学校课程相协调，形成相对完整的课程体系。要与国家课程、学校课程相辅相成，达成三级课程管理体系授予的课程目标和任务，不能用国家课程和校本课程代替地方课程。 3、选择性原则
Declaration 声明 本方案是XXXXXX 有限公司（中国）的知识产权，供-D600 隧道烘箱的用户用于商业运作及接受管理当局的审核。未经书面允许，禁止向第三方传播本方案。 APPROVALS 批准 原作者：XXXXXX 有限公司日期：20xx 年xx 月日 Approval 1 (Engineering): Date: 批准1（工程部门）日期 Approval 2 (Production): Date: 批准2（生产部门）日期 Approval 3 (Quality Assurance): Date: 批准3（质量保证）日期 Approval 4 (Validation): Date: 批准4（验证人员）日期
REVISION HISTORY 修订历史
Table of Contents 1.0 Purpose 目的 2.0 Responsibilities 责任 3.0 System Description 系统概述 4.0 Procedure 程序 5.0 Reference 参考 6.0 Signature Identification 签名 7.0 Operational Verifications 运行确认 7.1 IQ Verification IQ 确认 7.2 Critical Instrument Calibration Verification 关键仪表校准确认 7.3 Test Instruments Calibration Verification 测试仪表校准确认 7.4 SOPs Referenced and Training Verification 相关SOP 和培训确认 7.5 Installation and Mechanical Verification 更换规格件的安装和机械操作确认 7.6 Safety Equipment / Alarm / Interlocks Verification 安全设备/报警装置/联锁装置确认 7.7 Loss of Utilities and Restart Verification 断电后重启确认 7.8 触摸屏及PLC Operational Verification 触摸屏及PLC 操作确认 7.9 Software Version Verification 软件版本确认 7.10 7.10 隧道烘箱运行速度和产量确认 7.11 Compliance Verification 电气控制系统及PLC 符合性确认 7.12 Empty Run Verification 空运转操作确认 8.0 Deviations 偏差 9.0 Attachments 附件
山西省普通高中学生学分管理指导意见（试行） 根据教育部《普通高中课程方案(实验)》(教基[2003]6号)和《山西省普通高中新课程实验工作方案》(晋教基[2008]14号)有关规定，我省从2008年秋季入学的高一年级起进行普通高中新课程实验，对学生实行学分管理。为指导普通高中实施规范的学分认定和管理，促进普通高中新课程实验的有效实施，现就我省普通高中学分管理提出如下指导意见。 一、总体要求 1、学分反映学生在高中学校学习期间课程修习状况。从2008年秋季入学的高一年级起，对所有普通高中学生实行学分管理。学生修习一个模块并通过考核，可获得相应学分。 2、普通高中学生须修满三年，并且每学年在每个领域都获得一定学分，总共获得144个学分方可毕业。其中必修学分116个，学习各学科课程标准所设置的选修模块至少获得22个学分，学习学校自主开设的选修模块至少获得6个学分。 3、普通高中学校根据国家、省有关学分管理的要求和本市模块考试考核的相关规定制定本校学生学分管理具体办法，严格学分认定标准、程序，规范操作规程，形成完备的学分认定和管理制度。对学分的认定做到公正、公平、公开，确保学分认定的权威性和真实性。 二、学分分配 1、高中学生必修学分至少达到116个，包括：语文l0个学分、外语10个学分、数学10学分、思想政治8个学分、历史6个学分、地理6个学分、物理6个学分、化学6个学分、生物6个学分、技术8
个学分 (含信息技术和通用技术各4个学分)、艺术6个学分（或音乐、美术各3个学分）、体育与健康11个学分、研究性学习活动15个学分、社会实践6个学分、社区服务 2个学分。 2、选修课程至少获得28个学分,其中选修Ⅰ课程至少获得22个学分（参加高考按文理侧向要求一般应达到36个学分以上），由学生从各学科课程标准所设置的选修模块中修习获得；选修Ⅱ课程至少获得6个学分，由学生从学校自主开发的校本课程中修习获得。 3、根据普通高中新课程实验课程设置标准规定，每个模块通常为36学时，2个学分。其中体育与健康、艺术、音乐、美术每个模块原则上为l8学时，相当于1个学分；研究性学习的主要形式是课题研究，应当保证270学时，每学分不少于l8学时，计15个学分；社会实践活动每学年参加1周，获2个学分；社区服务按照工作日计算，三年不得少于10个工作日，获2个学分；选修Ⅱ课程开设，每个模块可以设计为18学时，1个学分，也可以为36学时，2个学分。 4、学有余力或希望多方面发展的学生达到毕业所需的144个学分后，学校应当创造条件鼓励他们修习更多选修课。凡是选修新的课程模块并通过考核的，可以获得更多的学分。 三、学分认定 1、学分认定的机构 学分由学校认定并负责组织实施。学校应成立学分认定委员会，并根据不同学习领域的特点设立若干学分认定小组。学分认定委员会由校长主持，有关校、处领导和各学科骨干教师组成。学分认定委员会应按照各学科课程标准和山西省普通高中新课程各学科教学指导意
RADIUS主要用于对远程拨入的用户进行授权和认证。它可以仅使用单一的“数据库”对用户进行认证（效验用户名和口令）。它主要针对的远程登录类型有：SLIP、PPP、telnet和rlogin 等。 其主要特征有： 1．客户机/服务器(C/S)模式 一个网络接入服务器(以下简称NAS)作为RADIUS的客户机，它负责将用户信息传入RADIUS服务器，然后按照RADIUS服务器的不同的响应来采取相应动作。另外，RADIUS 服务器还可以充当别的RADIUS服务器或者其他种类认证服务器的代理客户。 2．网络安全（Network Security） NAS和RADIUS服务器之间的事务信息交流由两者共享的密钥进行加密，并且这些信息不会在两者之间泄漏出去。 3．灵活认证机制（Flexible Authentication Mechanisms） RADIUS服务器支持多种认证机制。它可以验证来自PPP、PAP、CHAP和UNIX系统登录的用户信息的有效性。 4．协议可扩展性(Extensible Protocol) 所有的认证协议都是基于“属性－长度－属性值”3元素而组成的。所以协议是扩展起来非常方便。在目前很多比较高版本的Linux中，它们都把RADIUS的安装程序包含在系统源码中。这样使得我们可以很容易地通过免费的Linux系统学习RADIUS授权、认证的原理和应用。 RADIUS协议原理 要弄清楚RADIUS协议为何能实现授权和认证，我们必须应该从四个方面去认识RADIUS 协议：协议基本原理、数据包结构、数据包类型、协议属性。下面我们就来详细地介绍这些内容。 协议基本原理 NAS提供给用户的服务可能有很多种。比如，使用telnet时，用户提供用户名和口令信息，而使用PPP时，则是用户发送带有认证信息的数据包。 NAS一旦得到这些信息，就制造并且发送一个“Access-Request”数据包给RADIUS服务器，其中就包含了用户名、口令（基于MD5加密）、NAS的ID号和用户访问的端口号。
隧道烘箱及干热烤箱除内毒素效果验证方法 ——湛江博康海洋生物有限公司质量管理部提供 1. 概述： 干热可用于能耐受较高温度，却不宜被蒸汽穿透，同时干热灭菌也是制药工业生产流程的包装材料及试验器材用于除热原的方法。 干热灭菌设备是隧道式和干热恒温箱的灭菌除热原系统。隧道式灭菌除热原系统主要由加热器、高效过滤器、缓冲板、风阀气流调节器、风机、传送带、运行连锁控制系统、温度控制器及记录仪等7大部分组成。干热恒温箱主要由加热器、风阀气流调节器、风机、温度控制器及隔板等5部分组成。 2. 验证目的： 为了确认隧道式烘箱和干热恒温箱腔内不同位置的热分布情况，确认预定的灭菌、除热原程序能否达到预先设计要求。特制订本验证方案，拟对该设备的除内毒素效果进行验证。 3. 验证范围： 本验证方案适用于隧道式烘箱和干热恒温箱除内毒素的验证。 4. 验证内容： 4.1空载热分布测试： 检查灭菌腔内的热分布情况，调查灭菌腔内不同位置的偏差状况，确定可能存在的冷点。测试程序： 选择10个热电阻或热电偶作温度探头，编号后固定在输送带上的不同位置(一般10-15cm 设一个温度探头)。 电偶焊接的尖端不能与输送带表面接触。记录探头位置。温度探头分布图见下图。 设备按实际生产运行条件操作，记录腔内温度变化。空载热分布测试应至少进行3次重复性试验以证明热分布的重现性，若在试验过程中发现温度分布不符合设定要求，则应调整温度调节器进风、回风及循环风档板，改善空气流动状态等。 图. 空载热分布温度探头分布图。 评价标准：设备在空载状态下热分布应均匀，腔室内各点的温度值与设定值之间的偏差不得超过±5℃。 4.2装载热穿透试验： 进行装载热穿透试验的目的是在热分布试验的基础上，确定装载中的最冷点，并确认该点在灭菌设定时间内能够获得充分的灭菌保证值。 装载确定：满载或日常工作状态下。 装载类型：按实际情况填写 灭菌程序：350℃×6min 温度探头安装：温度探头应安装于待灭菌的物品中间部位，并使其与物品表面接触。 插有温度探头的产品应放在下列位置：
山西省中小学课程设置及标准表 小学年级初中年级高中年级 课程门类 一二三四五六一二三一（上、下学期）二（上、下学期）三（上、下学期）品德 与生活3 品德 与生活3 品德 与社会2 品德 与社会2 品德 与社会2 品德 与社会2 思想 品德2 思想 品德2 思想 品德2 思想政治2思想政治2思想政治4 语文9语文9语文7语文7语文7语文6语文4语文4语文4语文4语文4语文4 数学4数学4数学4数学4数学4数学4数学4数学4数学4数学4数学4数学4外语2外语2外语2外语2外语4外语4外语4英语4英语4英语4 物理2物理2物理2物理2、4（理科）物理4（理科） 化学3化学2化学2、4（理科）化学4（理科） 生物3生物3生物2生物2生物4科学2科学2科学2科学2历史2历史2历史2历史2历史2、4（文科）历史4（文科） 地理2地理2地理2地理2、4（文科）地理4（文科）音乐2音乐2音乐2音乐2音乐1.5音乐1.5音乐1音乐1音乐1音乐1音乐1音乐1 体育4体育4体育3体育3体育3体育3 体育 与健康3 体育 与健康3 体育 与健康3 体育与健康2体育与健康2体育与健康2美术2美术2美术2美术2美术1.5美术1.5美术1美术1美术1美术1美术1美术1综合实践 2-3 综合实践 2-3 综合实践 2-3 综合实践 2-3 综合实践 3 综合实践 3 综合实践 3 信息技术2、0信息技术0、2信息技术2、0 地方与学校编制的课程通用技术0、2通用技术2、0通用技术2、0 2 2 3-4 3-4 3-4 3-4 5 3 5 研究性学习活动3研究性学习活动3研究性学习活动3 社区服务（全学年不少于5个工作日） 社会实践（全学年参加一周社会实践活动） 周课时数 不超过 26 26 30 30 30 30 34 34 34 35 35 35 计算机：初一初二每周2节，小学3-6年级每周1节。安全教育、法制教育：1-9年级间周1节，以上均占综合实践课。
一、概述： RADIUS协议包括RADIUS AUTHENTICATION PROTOCOL 和RADIUS ACCOUNTING PROTOCOL 两部分。RADIUS AUTHENTICATION PROTOCOL 完成拨号用户的认证工作，而RADIUS ACCOUNTING PROTOCOL 则完成用户服务的计费任务。 事实上，为了更好地向分散的众多接入用户提供互联网服务,必须对接入服务提供有效的管理支持。它需要对安全，配置，计费等提供支持，这可以通过对一个用户数据库的管理来达到，这个数据库包括认证信息，及细化的服务配置信息和计费信息。通常这个数据库的维护管理，对用户信息的核实及配置有一个单独的实体完成，这个实体就是RADIUS server。由于这些管理信息的众多与繁杂，通常RADIUS server放在一个独立的计算机上，而为了向RADIUS server取得服务，必须首先构建一个RADIUS client，通常RADIUS client 位于Network Access Server（NAS，网络接入设备）上。 下图示例了这些实体之间的关系： 二、RADIUS认证协议格式： 1、RADIUS AUTHENTICATION PROTOCOL 包格式 下面是协议报文格式： CODE域可以包括如下一些值； 1Access-Request 2Access-Accept
3Access-Reject 4Accounting-Request 5Accounting-Response 11Access-Challenge 12Status-Server 13Status-Client 255Reserved 其中，CODE 1，2，3，11值为RADIUS AUTHENTICATION PROTOCOL使用，而CODE 4，5值为RADIUS ACCOUNTING PROTOCOL使用。其余未用或保留。CODE 占一个字节 IDENTIFIER占一个字节，用于匹配请求和应答。 LENGTH 占二个字节，是整个数据报的长度，包括CODE+IDENTIFIER+LENGTH +AUTHENTICATOR+A TTRIBUTES的所有长度。 AUTHENTICATOR 是16字节的随机数，高位在先，此域用于认证答复和加密口令字。 ATTRIBUTES是若干属性状态的集合，其长度是不确定的，不同的CODE值可以跟随不同的属性值。下表是一个总结：
针剂车间 SZA920/75型杀菌干燥机 再验证方案 XXXX药业有限公司
目录 1.概述 (3) 2.再验证目的 (3) 3.引用标准 (3) 4.验证组织职责 (3) 5.进度计划 (5) 6.验证实施的步骤和要求 (5) 6.1 预确认 (5) 6.2 运行确认 (5) 6.3 性能确认 (6) 7. 异常情况处理程序 (8) 8. 拟定验证周期 (8) 9. 结果与评定 (9)
1、概述 针剂车间SZA920/75杀菌干燥机是一种干热灭菌设备，是我公司注射剂车间的瓶子灭菌专用设备。瓶子随输送带的输送依次进入隧道灭菌烘箱的预热区、高温灭菌区和低温冷却区，整个过程始终处于百级层流保护之下。于2004年安装，2005年通过GMP 认证并于2010年通过了GMP再认证，现根据验证要求进行再验证。 2、验证目的： 2.1 确认本设备能够正常运行符合安装要求，各项性能指标符合生产工艺要求。 2.2提供必要的文件以证实本设备操作与所预期的完全一致。 2.3确认本方案所制定的操作程序及验证方案,能有效地使本设备处于确认状态下,并能稳定地、恒常地达成其所预期的功能。 3、引用标准： 《药品生产质量管理规范》国家药品监督管理局 2010年 《药品生产验证指南》国家食品药品监督管理局 2003版 《验证管理规程》 《SZA920/75杀菌干燥机标准操作规程》 《SZA920/75杀菌干燥机维护保养标准操作规程》 4、验证组织职责 4.1.验证领导小组： 4.1.1.人员结构： 4.1.2.验证领导小组职责： 4.1.2.1. 负责组织编写验证方案。
4.1.2.2. 负责对验证方案进行审核和批准。 4.1.2.3. 负责组织协调验证方案的实施。 4.1.2.4. 审核验证有关的数据、信息并批准验证报告。 4.2.验证工作小组： 4.2.1.人员结构： 4.2.2.工作小组职责： 4.2.2.1.根据验证领导小组的安排，编写再验证方案。 4.2.2.2.按批准的再验证方案实施验证工作。 4.2.2.3.收集再验证有关的数据、记录、信息，进行分析评价并编制再验证报告。 4.3.生产技术部： 4.3.1.协助验证工作小组实施验证方案。 4.3.2.负责验证参数的收集、记录、整理工作。 4.4.质量管理部： 4.4.1.负责制订验证的取样计划、检测方法。 4.4.2.负责验证实施过程中的取样、检测。 4.5.工程设备部： 4.5.1.负责验证使用的仪器、仪表的检定校验。 4.5.2.检测数据的收集、记录、整理、分析、结果评价报告。 4.5.2.确保系统的正常运行。 5、进度计划 验证小组提出完整的验证计划，经验证小组批准后实施，整个验证活动时间安排如下。
竭诚为您提供优质文档/双击可除 radius协议详解 篇一：Radius远程用户拨号认证系统详解 Radius远程用户拨号认证系统 Radius：Remoteauthenticationdialinuserservice，远程用户拨号认证系统由RFc2865，RFc2866定义，是目前应用最广泛的（aaa是authentication（认证）、authorization（授权）和accounting（计费）的简称）基本概念 aaaauthentication、authorization、accounting 验证、授权、记费 pappasswordauthenticationprotocol口令验证协议 chapchallenge-handshakeauthenticationprotocol盘问握手验证协议 nasnetworkaccessserver网络接入服务器 RadiusRemoteauthenticationdialinuserservice 远程验证拨入用户服务（拨入用户的远程验证服务） tcptransmissioncontrolprotocol传输控制协议 udpuserdatagramprotocol用户数据报协议
aaa实现途径 1.在网络接入服务器nas端：在nas端进行认证、授权和计费； 2.通过协议进行远程的认证、授权和记帐。实现aaa的协议有Radius Radius是Remoteauthenticationdialinuserservice的简称，ma5200、isn8850和md5500上目前使用Radius完成对ppp用户的认证、授权和计费。 当用户想要通过某个网络(如电话网)与nas建立连接从而获得访问其他网络的权利时，nas可以选择在nas上进行本地认证计费，或把用户信息传递给Radius服务器，由Radius进行认证计费；Radius协议规定了nas与Radius服务器之间如何传递用户信息和记账信息；Radius服务器负责接收用户的连接请求，完成验证，并把传递服务给用户所需的配置信息返回给nas。 本地（nas）验证——pap方式 pap（passwordauthenticationprotocol）是密码验证协议的简称，是认证协议的一种。用户以明文的形式把用户名和他的密码传递给nas，nas根据用户名在nas端查找本地数据库，如果存在相同的用户名和密码表明验证通过,否则表明验证未通过。 本地（nas）验证——chap方式