rfc3237.txt

RFC 的详细文档！


RFC 3237        Requirements for Reliable Server Pooling    January 2002


2.12.  Scalability

   The RSerPool architecture should not require a limitation on the
   number of server pools or on the number of pool users, although the
   size of an individual pool may be limited by timing requirements as
   defined above.

2.13.  Security Requirements

2.13.1.  General

   -  The scaling characteristics of the security architecture should be
      compatible with those given previously.

   -  The security architecture should support hosts having a wide range
      of processing powers.

2.13.2.  Name Space Services

   -  It must not be possible for an attacker to falsely register as a
      pool element with the name server either by masquerading as
      another pool element or by registering in violation of local
      authorization policy.

   -  It must not be possible for an attacker to deregister a server
      which has successfully registered with the name server.

   -  It must not be possible for an attacker to spoof the response to a
      query to the name server

   -  It must be possible to protect the privacy of queries to the name
      server and responses to those queries from the name server.

   -  Communication among name servers must be afforded the same
      protections as communication between clients and name servers.

2.13.3.  Security State

   The security context of an application is a subset of the overall
   context, and context or state sharing is explicitly out-of-scope for
   RSerPool.  Because RSerPool does introduce new security
   vulnerabilities to existing applications application designers
   employing RSerPool should be aware of problems inherent in failing
   over secured connections.  Security services necessarily retain some
   state and this state may have to be moved or re-established.
   Examples of this state include authentication or retained ciphertext





Tuexen, et al.               Informational                      [Page 6]

RFC 3237        Requirements for Reliable Server Pooling    January 2002


   for ciphers operating in cipher block chaining (CBC) or cipher
   feedback (CFB) mode.  These problems must be addressed by the
   application or by future work on RSerPool.

3.  Security Considerations

   Security issues are discussed in section 2.13.

4.  Acknowledgements

   The authors would like to thank Bernard Aboba, Matt Holdrege, Eliot
   Lear, Christopher Ross, Werner Vogels and many others for their
   invaluable comments and suggestions.

5.  References

   [RFC793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
             793, September 1981.

   [RFC959]  Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",
             STD 9, RFC 959, October 1985.

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
             3", BCP 9, RFC 2026, October 1996.

   [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
             Location Protocol, Version 2", RFC 2608, June 1999.

   [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene,
             L., Lin, H., Juhasz, I., Holdrege, M. and C. Sharp,
             "Framework Architecture for Signaling Transport", RFC 2719,
             October 1999.

   [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
             2914, September 2000.

   [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
             Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang,
             L. and V. Paxson, "Stream Control Transmission Protocol",
             RFC 2960, November 2000.











Tuexen, et al.               Informational                      [Page 7]

RFC 3237        Requirements for Reliable Server Pooling    January 2002


6.  Authors' Addresses

   Michael Tuexen
   Siemens AG
   ICN WN CS SE 51
   D-81359 Munich
   Germany

   Phone:   [phone]
   EMail: [e-mail]


   Qiaobing Xie
   Motorola, Inc.
   1501 W. Shure Drive, #2309
   Arlington Heights, Il 60004
   USA

   Phone: [phone]
   EMail: [e-mail]


   Randall Stewart
   Cisco Systems, Inc.
   24 Burning Bush Trail
   Crystal Lake, Il 60012
   USA

   Phone: [phone]
   EMail: [e-mail]


   Melinda Shore
   Cisco Systems, Inc.
   809 Hayts Rd
   Ithaca, NY 14850
   USA

   Phone: [phone]
   EMail: [e-mail]











Tuexen, et al.               Informational                      [Page 8]

RFC 3237        Requirements for Reliable Server Pooling    January 2002


   Lyndon Ong
   Ciena
   10480 Ridgeview Court
   Cupertino, CA 95014
   USA

   Phone: [phone]
   EMail: [e-mail]


   John Loughney
   Nokia Research Center
   PO Box 407
   FIN-00045 Nokia Group
   Finland

   Phone: [phone]
   EMail: [e-mail]


   Maureen Stillman
   Nokia
   127 W. State Street
   Ithaca, NY 14850
   USA

   Phone: [phone]
   EMail: [e-mail]























Tuexen, et al.               Informational                      [Page 9]

RFC 3237        Requirements for Reliable Server Pooling    January 2002


7.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Tuexen, et al.               Informational                     [Page 10]