rfc3040.txt

很多RFC的中文文档

         WCCP V2提供可选择的协议鉴定。 
展开： 
网络元件：WCCP应用与各种CISCO路由器 
高速缓冲服务器：WCCP被许多销售商的高速缓冲服务器中配置。 
提交： 
文献编者：  David Forster
8.2网络元件控制协议（NECP）
常用参考材料： 
"NECP"网络元件控制协议[22]（work in progress） 
描述： 
NECP为网络元件获得服务器容量，可靠性提供了方法。并且暗示通过的数据流能否被服务。
这使得网络元件通过一个区域的服务器执行加载平衡，重定向侦听服务器，或切断通过的数
据流，使得服务器不能为这片区域体提供服务。 
安全性：有选择的使用HMAC-SHA-1 [11]共享伴随的复杂数字鉴定密码可以适度的增强安
全性。如果不使用密码鉴定，协议将受到攻击。 
展开： 目前未知；一些网络元件和高速缓冲服务器主明确目的，达成有关协议。 
提交：Gary Tomlinson
8.3 SOCKS
最常用的参考资料：GARY TOMLINSO 8.3  SOCKS  
                  RFC 1928〈HTTP：//WWW.FAQS.ORG/RFCS 
                      /RFC1928.HTML〉 
                  SOCKS PROTOCOL VERSION 5[7] 
叙述：SOCKS最初在防火墙协议中被用作高速缓冲器的代理人，尽管 firewalls不符合前面
所定义的狭隘的网络元件定义,但他们是网络基础构造的一个重要组成部分。当与防火墙共
同使用时，SOCKS在高速缓冲存储器和防火墙之间提供一个可信通道。 
安全性： 广泛的结构框架提供了多重的证明方法，当前，SSL，CHAP， DES 3DES被证
明是可利用的。 
展开性：SOCKS在互联网上被广泛地展开  
提交：文件编辑装置。
9.安全性考虑
这些文档为高速缓冲器及其复制品提供了一种分类方法.推荐的策略，体系结构和协议并没
有被详细的描述在这里，合法的含义是指：进行或保存暂用的或永久地拷贝不会覆盖原有的
内容。通过注释所参考的有关每个协议的安全性信息由先前部分提供，并保存在他们的伴随
文件中。   
HTTP的安全性在RFC 2616部分被讨论。 
HTTP：//WWW。FAQS。ORG/RFCS/RFC2616。HTML〉[1]， 
HTTP/1。1规范 and to a lesser extent in RFC1945 
<http://www.faqs.org/rfcs/rfc1945.html? 
[6] the HTTP/1.0 
RFC 2616〈http://www.faqs.org/rfcs/rfc2616.html>包含了对HTTP代理权的安全性考虑。 
高速缓冲存储器proxies与其它的应用级proxies有相同的安全性问题.应用级proxies不会被
这些安全性因素所覆盖。当proxy被用于通信时，经过鉴定的IP编号 是有问题的，在这里
将不再详细的讨论。
9.1鉴定
请求网上资源，并获得响应，可能被直接复制或通过中继代理传送到目的的。完整的通信需
要被预先保存，用来在发生存取错误和无意地修改时保护数据。
9.1.1 中介攻击
 HTTP服务器是计算机通信的中介, 它是最容易遭到攻击的部分，对于这部分的内容将在
RFC 2616的15部分进行讨论 
〈http://www.faqs.org/rfcs/rfc2616.html>
9.1.2值得信赖的第三方代理
代理商不仅仅是以营利为目地的源服务器或客户机，他还必须担任信息通道的任务。当现行
的高速缓冲服务器的对象是客户时，客户需要信任源服务器的代表即高速缓冲代理商A 
REPLICA也可能，从起点服务器处获得委任。
9.1.3 基于IP编码的鉴定
基于客户的IP编号的鉴定当通过代理商连接时是存在问题的，因为鉴定设备仅仅是接近代
理商的IP编号对这种问题的解答是此IP编号是代理商为了让客户请求服务的欺骗手段。基
于IP编号的鉴定设想即因特网的end-to-end 的特性被保持。这并不是典型的包含侦听的计
算机软件工程环境的代理
9.2保密性
9.2.1信任第三方的服务
当共同使用同一设备时，必须同时信任统一的起点服务器和共同的选择的系统。通信量的重
定向是自动地复制选择方法，或在代理范围内可以引入第三方的最终用户或值得信任的起点
服务器。在侦听代理的情况下，第三方汇聚通常是在其他两个通信的终端节点不知道的情况
自发生的。位置的第三方可以说具有相对的安全性。代理和复制选择的服务器可以对聚集的
信息进行存取。典型的代理知道，每个用户可以通过访问获得比单个起点服务器，提供的更
详细的信息。
9.2.2登陆和合法的含义
从代理处登陆将获得安全性的保持，因为他们提供有关用户信息和他们的行为模式，由于用
户的请求总是通过代理，因此代理的登记比网络服务器的登记更灵敏。从复制的起点服务器
登记可能需要从服务器合并获得聚集的统计数字，并且通过边框传送登陆来获得合法的暗
示。在一些国际阿，登陆控制被以法律的形式限制。在因特网这个大环境下，网络回应和高
速缓冲系统对对象安全性和隐秘性的要求是相同的，仅能依靠的方法是加强保密措施
end-to-end 加密经常使得信息源uncacheable,因为在这时，SSL加密页处于对话状态。
9.3服务器的安全性
9.3.1服务器拒绝  
通信量的任何重定向对拒绝服务的通过攻击代理商，可以使得大量的客户机不能访问服务器
据争论侦听代理的说明是一个服务攻击的否认
9.3.2重新实施攻击
高速缓冲存储器代理是通过定义重新攻击来实现的。
9.3.3乏味的代理配置
很容易理解他有一个能伤害内部消费者服务器的Stupy 配置。这是代理的最普通的安全性
问题。
9.3.4版权暂用拷贝
立法强制的范围是认定暂用拷贝的问题，像那些抑制反响和高速缓冲存储器系统就是合法
的。
9.3.5应用级存取
  高速缓冲代理在通信量流通路径中处于是应用级，可以让入侵者获得允许范围内的信息即
被处于网络级别的代理商允许使用的免费空间。一些网络级设备可以通过设置物理性通道来
获得详细的用户信息。应用级元件的引入可以达到更好的系统安全性。
10.鸣谢
编者对下列人物的协助而提出感谢： 
David Forster, Alex Rousskov, Josh Cohen, John Martin,  
John Dilley, Ivan Lovric, Joe Touch, Henrik Nordstrom, 
 Patrick McManus, Duane Wessels, Wojtek Sylwestrzak,  
Ted Hardie, Misha Rabinovich, Larry Masinter, Keith 
参考文献： 
    [1]   Fielding, R., Gettys, J., Mogul, J., Frystyk, 
          H., Masinter, L.,Leach, P. and T. Berners-Lee, 
          "Hypertext Transfer Protocol -- HTTP/1.1", 
          RFC 2616 <http://www.faqs.org/rfcs/rfc2616.html>, 
               June 1999. 
 
   [2]   Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), 
         Version 2", RFC 2186 <http://www.faqs.org/rfcs/rfc2186.html>, September 1997. 
 
   [3]   Wessels, D. and K. Claffy, "Application of Internet Cache 
         Protocol (ICP), Version 2", RFC 2187 <http://www.faqs.org/rfcs/rfc2187.html>, September 
1997. 
 
   [4]   Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 
         9, RFC 959 <http://www.faqs.org/rfcs/rfc959.html>, October 1985. 
 
   [5]   Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, 
         D. and B. Alberti, "The Internet Gopher Protocol", RFC 1436 
<http://www.faqs.org/rfcs/rfc1436.html>, 
         March 1993. 
 
   [6]   Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext 
         Transfer Protocol -- HTTP/1.0", RFC 1945 <http://www.faqs.org/rfcs/rfc1945.html>, May 
1996. 
   [7]   Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. 
         Jones, "SOCKS Protocol Version 5", RFC 1928 <http://www.faqs.org/rfcs/rfc1928.html>, 
March 1996. 
 
   [8]   Brisco, T., "DNS Support for Load Balancing", RFC 1794 
<http://www.faqs.org/rfcs/rfc1794.html>, April 
         1995. 
 
   [9]   Vixie, P. and D. Wessels, "Hyper Text Caching Protocol 
         (HTCP/0.0)", RFC 2756 <http://www.faqs.org/rfcs/rfc2756.html>, January 2000. 
 
   [10]  Fan, L., Cao, P., Almeida, J. and A. Broder, "Summary Cache: A 
         Scalable Wide-Area Web Cache Sharing Protocol", Proceedings of 
         ACM SIGCOMM'98 pp. 254-265, September 1998. 
 
   [11]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 
         for Message Authentication", RFC 2104 <http://www.faqs.org/rfcs/rfc2104.html>, February 
1997. 
 
   [12]  Netscape, Inc., "Navigator Proxy Auto-Config File Format", 
         March 1996, 
         <URL:<http://www.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-> 
         live.html>. 
 
   [13]  Gauthier, P., Cohen, J., Dunsmuir, M. and C. Perkins, "The Web 
         Proxy Auto-Discovery Protocol", Work in Progress. 
 
   [14]  Valloppillil, V. and K. Ross, "Cache Array Routing Protocol", 
         Work in Progress. 
 
   [15]  Microsoft Corporation, "Cache Array Routing Protocol (CARP) 
         v1.0 Specifications, Technical Whitepaper", August 1999, 
         <URL:<http://www.microsoft.com/Proxy/Guide/carpspec.asp>>. 
 
   [16]  Microsoft Corporation, "Cache Array Routing Protocol and 
         Microsoft Proxy Server 2.0, Technical White Paper", August 
         1998, 
         <URL:<http://www.microsoft.com/proxy/documents/CarpWP.exe>>. 
 
   [17]  Lovric, I., "Internet Cache Protocol Extension", Work in 
         Progress. 
 
   [18]  Cieslak, M. and D. Forster, "Cisco Web Cache Coordination 
         Protocol V1.0", Work in Progress. 
 
   [19]  Cieslak, M., Forster, D., Tiwana, G. and R. Wilson, "Cisco Web 
         Cache Coordination Protocol V2.0", Work in Progress. 
 
   [20]  Goutard, C., Lovric, I. and E. Maschio-Esposito, "Pre-filling a 
         cache - A satellite overview", Work in Progress. 
 
   [21]  Hamilton, M., Rousskov, A. and D. Wessels, "Cache Digest 
         specification - version 5", December 1998, 
         <URL:<http://www.squid-cache.org/CacheDigest/cache-digest-> 
         v5.txt>. 
 
   [22]  Cerpa, A., Elson, J., Beheshti, H., Chankhunthod, A., Danzig, 
         P., Jalan, R., Neerdaels, C., Shroeder, T. and G. Tomlinson, 
         "NECP: The Network Element Control Protocol", Work in Progress. 
 
   [23]  Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems", 
         Work in Progress. 

作者地址
   Ian Cooper 
   Equinix, Inc. 
   2450 Bayshore Parkway 
   Mountain View, CA  94043 
   USA 
  Phone: [phone] 
   EMail: [e-mail] <mailto:[e-mail]> 
 
   Ingrid Melve 
   UNINETT 
   Tempeveien 22 
   Trondheim  N-7465 
   Norway 
 
   Phone: [phone] 
   EMail: [e-mail] <mailto:[e-mail]> 
 
   Gary Tomlinson 
   CacheFlow Inc. 
   12034 134th Ct. NE, Suite 201 
   Redmond, WA  98052 
   USA 
 
   Phone: [phone] 
   EMail: [e-mail] <mailto:[e-mail]> 
此文档或其译文可能被拷贝或被其他人提供，由其引出的评论或其他的解释或有助于他的作
品可以被备用，拷贝，出版或分类。但是，文档本身不能被以任何形式修改，比如删除版权
信息或互联网组织或其他的互联网组织的参考书目.除了作为需要发展国际互联网的目的的
标准，在于哪一种计算机辅助软件工程为版本，而定义在国际互联网标准的过程必须随之定
义，或者需要把它翻译成不同于英语的语言。 
上述的有限的许可授予是永久的，将不会被国际互联网组织或特在这里，此文档及其所包含
的信息是在"参见"的基础上提供的。国际互联网组织，因特网工程任务的影响力放弃所有的
授权，专使，。。，包括但不是限制。
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.
 
认证 
RFC编辑装置函数的当前认证资金是由国际互联网组织提供的。
RFC3040——Internet Web Replication and Caching Taxonomy      Internet网复制和分类法
RFC文档中文翻译计划                                                              2