rfc2729.txt

中、英文RFC文档大全打包下载完全版 .

      check will be made to see if it is allowed to do so. The
      requirement is that certain principals will be allowed, and others
      excluded. Given the application is being protected from network
      details there are only two types of specification available, per
      user, and per organization (where an organization may contain
      other organizations, and each user may be a member of multiple
      organizations). Rules could however be built on properties of a
      user, for example does the user own a key? Host properties could
      also be used, so users on slow hosts or hosts running the wrong OS
      could be excluded.

      Type:                  Macros
      Meaning:               Include or exclude
                                users (list)
                                organizations (list)
                                hosts (list)
                                user properties (rule)
                                org properties (rule)
                                hosts properties (rule)
      Strictest Requirement: List of individual users
      Scope:                 per stream
      Example Application:   Corporate video-conference - organization
                             membership

   Collusion prevention

      Which aspects of collusion it is required to prevent. Collusion is
      defined as malicious co-operation between members of a secure
      session.  Superficially, it would appear that collusion is not a
      relevant threat in a multicast, because everyone has the same
      information, however, wherever there is differentiation, it can be
      exploited.

      Type:                  {
                               Abstract Currency,
                               Abstract Currency,
                               Abstract Currency



Bagnall, et al.              Informational                     [Page 21]

RFC 2729         Taxonomy of Communication Requirements    December 1999


                             }
      Meaning:               time race collusion - cost of colluding
                             key encryption key (KEK) sharing - cost of
                             colluding
                             sharing of differential QoS (not strictly
                             collusion as across sessions not within
                             one) - cost of colluding
      Strictest Requirement: For all threats cost attackers
                             combined resources
      Scope:                 per stream
      Example Application:   A race where delay of the start signal may
                             be allowed for, but one participant may
                             fake packet delay while receiving the start
                             signal from another participant.
      NB:                    Time race collusion is the most difficult
                             one to prevent. Also note that while these
                             may be requirements for some systems this
                             does not mean there are necessarily
                             solutions. Setting tough requirements may
                             result in the middleware being unable to
                             create a valid channel.

   Fairness

      Fairness is a meta-requirement of many other requirements. Of
      particular interest are Reliability and Timeliness requirements.
      When a communication is first created the creator may wish to
      specify a set of requirements for these parameters. Principals
      which join later may wish to set tighter limits. Fairness enforces
      a policy that any improvement is requirement by one principal must
      be matched by all others, in effect requirements can only be set
      for the whole group. This increases the likelihood that
      requirements of this kind will fail to be met. If fairness if not
      an issue then some parts of the network can use more friendly
      methods to achieve those simpler requirements.

      Type:                  Level of variance of the requirement that
                             needs to be fair. For example, if the
                             latency requirement states within 2
                             seconds, the level of fairness required may
                             be that variations in latency are not more
                             than 0.1s. This has in fact become an issue
                             in online gaming (e.g. Quake)
      Meaning:               The variance of performance with respect to
                             any other requirement is less than the
                             specified amount.
      Scope:                 per stream, per requirement




Bagnall, et al.              Informational                     [Page 22]

RFC 2729         Taxonomy of Communication Requirements    December 1999


      Example Application:   Networked game, latency to receive
                             positions of players must be within 5ms for
                             all players.

   Action on compromise

      The action to take on detection of compromise (until security
      reassured).

      Type:                  Enumeration
      Meaning:               warn but continue
                             pause
                             abort
      Scope:                 Per stream
      Strictest Requirement: pause
      Example Application:   Secure video conference - if intruder
                             alert, everyone is warned, but they can
                             continue while knowing not to discuss
                             sensitive matters (cf. catering staff
                             during a meeting).

3.2.8.1. Security Dynamics

      Security dynamics are the temporal properties of the security
      mechanisms that are deployed. They may affect other requirements
      such as latency or simply be a reflection of the security
      limitations of the system. The requirements are often concerned
      with abnormal circumstances (e.g. system violation).

   Mean time between compromises

      This is not the same as the strength of a system. A fairly weak
      system may have a very long time between compromises because it is
      not worth breaking in to, or it is only worth it for very few
      people. Mean time between compromises is a combination of
      strength, incentive and scale.

      Type:                  Time
      Scope:                 Per stream
      Strictest Requirement: indefinite
      Example Application:   Secure Shell - 1500hrs

   Compromise detection time limit

      The average time it must take to detect a compromise (one
      predicted in the design of the detection system, that is).





Bagnall, et al.              Informational                     [Page 23]

RFC 2729         Taxonomy of Communication Requirements    December 1999


      Type:                  Time
      Scope:                 Per stream
      Strictest Requirement: Round trip time
      Example Application:   Secure Shell - 2secs

   Compromise recovery time limit

      The maximum time it must take to re-seal the security after a
      breach.  This combined with the compromise detection time limit
      defines how long the system must remain inactive to avoid more
      security breaches. For example if a compromise is detected in one
      minute, and recovery takes five, then one minute of traffic is now
      insecure and the members of the communication must remain silent
      for four minutes after detection while security is re-established.

      Type:                  Time
      Scope:                 Per stream
      Strictest Requirement: 1 second
      Example Application:   Audio conference - 10 seconds

3.2.9. Payment & Charging

   Total Cost

      The total cost of communication must be limited to this amount.
      This would be useful for transfer as opposed to stream type
      applications.

      Type:                  Currency
      Meaning:               Maximum charge allowed
      Scope:                 Per user per stream
      Strictest Requirement: Free
      Example Application:   File Transfer: comms cost must be < 1p/Mb

   Cost per Time

                             This is the cost per unit time. Some
                             applications may not be able to predict the
                             duration of a communication. It may be more
                             meaningful for those to be able to specify
                             price per time instead.
      Type:                  Currency per timeS

      Scope:                 Per user per stream
      Strictest Requirement: Free
      Example Application:   Video Conference - 15p / minute





Bagnall, et al.              Informational                     [Page 24]

RFC 2729         Taxonomy of Communication Requirements    December 1999


   Cost per Mb

      This is the cost per unit of data. Some communications may be
      charged by the amount of data transferred. Some applications may
      prefer to specify requirements in this way.

      Type:                  Currency per data size
      Scope:                 Per user per stream
      Strictest Requirement: Free
      Example Application:   Email advertising - 15p / Mb

4. Security Considerations

   See comprehensive security section of taxonomy.

5. References

   [Bagnall98]   Bagnall Peter, Poppitt Alan, Example LSMA
                 classifications, BT Tech report,
                 <URL:http://www.labs.bt.com/projects/mware/>

   [limitations] Pullen, M., Myjak, M. and C. Bouwens, "Limitations of
                 Internet Protocol Suite for Distributed Simulation in
                 the Large Multicast Environment", RFC 2502, February
                 1999.

   [rmodp]       Open Distributed Processing Reference Model (RM-ODP),
                 ISO/IEC 10746-1 to 10746-4 or ITU-T (formerly CCITT)
                 X.901 to X.904. Jan 1995.

   [blaze95]     Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson
                 and Wiener, Minimal Key Lengths for Symmetric Ciphers
                 to Provide Adequate Commercial Security, January 1996.


















Bagnall, et al.              Informational                     [Page 25]

RFC 2729         Taxonomy of Communication Requirements    December 1999


6. Authors' Addresses

   Peter Bagnall
   c/o B54/77 BT Labs
   Martlesham Heath
   Ipswich, IP5 3RE
   England

   EMail: [e-mail]
   Home page: http://www.surfaceeffect.com/people/pete/


   Bob Briscoe
   B54/74 BT Labs
   Martlesham Heath
   Ipswich, IP5 3RE
   England

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]
   Home page: http://www.labs.bt.com/people/briscorj/


   Alan Poppitt
   B54/77 BT Labs
   Martlesham Heath
   Ipswich, IP5 3RE
   England

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]
   Home page: http://www.labs.bt.com/people/poppitag/

















Bagnall, et al.              Informational                     [Page 26]

RFC 2729         Taxonomy of Communication Requirements    December 1999


7.  Full Copyright Statement

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



















Bagnall, et al.              Informational                     [Page 27]