As per Relevance of the word communication, we have this rfc below:
Network Working Group P.
Request for Comments: 2729 R.
Category: Informational A.
December 1999
Taxonomy of Communication
for Large-scale Multicast
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
The intention of this memo is to define a classification system
the communication requirements of any large-scale
application (LSMA). It is very unlikely one protocol can achieve
compromise between the diverse requirements of all the
involved in any LSMA. It is therefore necessary to understand
worst-case scenarios in order to minimize the range of
needed. Dynamic protocol adaptation is likely to be necessary
will require logic to map particular combinations of requirements
particular mechanisms. Standardizing the way that
define their requirements is a necessary step towards this
Classification is a first step towards standardization
Bagnall, et al. Informational [Page 1]
RFC 2729 Taxonomy of Communication Requirements December 1999
Table of
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions of Sessions. . . . . . . . . . . . . . . . . 3
3. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Summary of Communications Parameters . . . . . . . . 4
3.2. Definitions, types and strictest requirements. . . . 5
3.2.1. Types . . . . . . . . . . . . . . . . . . . . . 6
3.2.2. Reliability . . . . . . . . . . . . . . . . . . 7
3.2.2.1. Packet Loss . . . . . . . . . . . . . . . . 7
3.2.2.2. Component Reliability . . . . . . . . . . . 8
3.2.3. Ordering . . . . . . . . . . . . . . . . . . . . 9
3.2.4. Timeliness . . . . . . . . . . . . . . . . . . . 9
3.2.5. Session Control . . . . . . . . . . . . . . . .13
3.2.6. Session Topology . . . . . . . . . . . . . . . .16
3.2.7. Directory . . . . . . . . . . . . . . . . . . .17
3.2.8. Security . . . . . . . . . . . . . . . . . . . .17
3.2.8.1. Security Dynamics . . . . . . . . . . . . .23
3.2.9. Payment & Charging . . . . . . . . . . . . . . .24
4. Security Considerations . . . . . . . . . . . . . . . .25
5. References . . . . . . . . . . . . . . . . . . . . . .25
6. Authors' Addresses . . . . . . . . . . . . . . . . . . .26
7. Full Copyright Statement . . . . . . . . . . . . . . . .27
1.
This taxonomy consists of a large number of parameters that
considered useful for describing the communication requirements
LSMAs. To describe a particular application, each parameter would
assigned a value. Typical ranges of values are given
possible. Failing this, the type of any possible values is given
The parameters are collected into ten or so higher level categories
but this is purely for convenience
The parameters are pitched at a level considered meaningful
application programmers. However, they describe communications
applications - the terms '3D virtual world', or 'shared TV'
imply communications requirements, but they don't accurately
them. Assumptions about the likely mechanism to achieve
requirement are avoided where possible
While the parameters describe communications, it will be noticed
few requirements concerning routing etc. are apparent. This
because applications have few direct requirements on these
order aspects of communications. Requirements in these areas
have to be inferred from application requirements (e.g. latency).
Bagnall, et al. Informational [Page 2]
RFC 2729 Taxonomy of Communication Requirements December 1999
The taxonomy is likely to be useful in a number of ways
1. Most simply, it can be used as a checklist to create
requirements statement for a particular LSMA. Example
will be classified [bagnall98] using the taxonomy in order
exercise (and improve)
2. Because strictest requirement have been defined for
parameters, it will be possible to identify worst case
for the design of
3. Because the scope of each parameter has been defined (per session
per receiver etc.), it will be possible to highlight
heterogeneity is going to be most
4. It is a step towards standardization of the way LSMAs define
communications requirements. This could lead to standard
between applications and protocol adaptation
5. Identification of limitations in current Internet technology
LSMAs to be added to the LSMA limitations memo [limitations
6. Identification of gaps in Internet Engineering Task Force (IETF
working group
This approach is intended to complement that used where
scenarios for Distributed Interactive Simulation (DIS) are
in order to generate network design metrics (values of
parameters). Instead of creating the communications parameters
the applications, we try to imagine applications that might
enabled by stretching communications parameters
2. Definition of
The following terms have no agreed definition, so they will
defined for this document
a happening or gathering consisting of flows of
related by a common description that persists for a non-
time (more than a few seconds) such that the participants (be
humans or applications) are involved and interested
intermediate times. A session may be defined recursively as
super-set of other sessions
Secure
a session with restricted
Bagnall, et al. Informational [Page 3]
RFC 2729 Taxonomy of Communication Requirements December 1999
A session or secure session may be a sub and/or super set of
multicast group. A session can simultaneously be both a sub and
super-set of a multicast group by spanning a number of groups
time-sharing each group with other sessions
3.
3.1 Summary of Communications
Before the communications parameters are defined, typed and
worst-case values, they are simply listed for convenience. Also
convenience they are collected under classification headings
Reliability . . . . . . . . . . . . . . . . . . . . . . 3.2.1
Packet loss . . . . . . . . . . . . . . . . . . . . 3.2.1.1
Tolerated
Semantic
Component reliability . . . . . . . . . . . . . . . 3.2.1.2
Setup fail-over
Mean time between
Fail over time during a
Ordering . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2
Ordering
Timeliness . . . . . . . . . . . . . . . . . . . . . . . 3.2.3
Hard
Optimum
Tolerable
Required by time and
Host
Fair
Frame
Content
Session Control . . . . . . . . . . . . . . . . . . . . 3.2.4
Start
End
Active
Session
Atomic
Late join allowed ?
Bagnall, et al. Informational [Page 4]
RFC 2729 Taxonomy of Communication Requirements December 1999
Temporary leave allowed ?
Late join with catch-up allowed ?
Potential streams per
Active streams per
Session Topology . . . . . . . . . . . . . . . . . . . . 3.2.5
Number of
Number of
Directory . . . . . . . . . . . . . . . . . . . . . . . 3.2.6
Fail-over time-out (see Reliability: fail-over time
Security . . . . . . . . . . . . . . . . . . . . . . . . 3.2.7
Authentication
Tamper-
Non-repudiation
Denial of
Action
Retransmit prevention
Membership
Membership
Collusion
Action on
Security dynamics . . . . . . . . . . . . . . . . . . . 3.2.8
Mean time between
Compromise detection time
compromise recovery time
Payment & Charging . . . . . . . . . . . . . . . . . . . 3.2.9
Total
Cost per
Cost per
3.2 Definitions, types and strictest
The terms used in the above table are now defined for the context
this document. Under each definition, the type of their value
given and where possible worst-case values and example
that would exhibit this requirement
There is no mention of whether a communication is a stream or
discrete interaction. An attempt to use this distinction as a way
characterizing communications proved to be remarkably unhelpful
was dropped
Bagnall, et al. Informational [Page 5]
RFC 2729 Taxonomy of Communication Requirements December 1999
3.2.1
Each requirement has a type. The following is a list of all the
used in the following definitions
Application
This is some measure of the processor load of an application,
some architecture neutral unit. This is non-trivial since
processing an application requires may change radically
different hardware, for example, a video client with and
hardware support
Bandwidth Measured in bits per second, or a multiple of
Abstract
An abstract currency is one which is adjusted to take
into account. The simplest way of doing this is to use the
of a real currency on a specific date. It is effectively a way
assessing the cost of something in "real terms". An example
be 1970 US$. Another measure might be "average man hours".
Currency - current
Data
Date (time since epoch
A label used to distinguish different parts of a
Membership list/
A small piece of executable code used to describe
Bagnall, et al. Informational [Page 6]
RFC 2729 Taxonomy of Communication Requirements December 1999
3.2.2
3.2.2.1 Packet
When multiple operations must occur atomically,
communications guarantee that either all occur or none occur and
failure is flagged
Type:
Meaning: Transactional or Not
Strictest Requirement:
Scope: per
Example Application: Bank credit transfer, debit and credit
be atomic
NB: Transactions are potentially much
complex, but it is believed this
an application layer problem
Guarantees communications will succeed under certain conditions
Type:
Meaning: Deferrable - if communication fails it
be deferred until a time when it will
successful
Guaranteed - the communication will
so long as all necessary components
working
No guarantee - failure will not
reported
Strictest Requirement:
Example Application: Stock quote feed -
Scope: per
NB: The application will need to set
to more fully define Guarantees, which
middleware may translate into, for example
queue lengths
Tolerated
This specifies the proportion of data from a communication
can be lost before the application becomes completely unusable
Bagnall, et al. Informational [Page 7]
RFC 2729 Taxonomy of Communication Requirements December 1999
Type:
Meaning: fraction of the stream that can be
Strictest Requirement: 0%
Scope: per
Example Application: Video - 20%
Semantic
The application specifies how many and which parts of
communication can be discarded if necessary
Type: Identifiers, name disposable
level
Meaning: List of the identifiers of
frames which may be
Strictest Requirement: No loss
Scope: per
Example Application: Video feed - P frames may be lost, I
3.2.2.2. Component
Setup Fail-over
The time before a failure is detected and a replacement
is invoked. From the applications point of view this is the
it may take in exceptional circumstances for a channel to be set
up. It is not the "normal" operating delay before a channel
created
Type:
Strictest Requirement: Web server - 1
Scope: per
Example Application: Name lookup - 5
Mean time between
The mean time between two consecutive total failures of
channel
Type:
Strictest Requirement:
Scope: per
Example Application: Telephony - 1000
Bagnall, et al. Informational [Page 8]
RFC 2729 Taxonomy of Communication Requirements December 1999
Fail over time during a
The time between a stream breaking and a replacement being set up
Type:
Strictest Requirement: Equal to latency
Scope: per
Example Application: File Transfer - 10
3.2.3.
Ordering
Specifies what ordering must be preserved for the
Type: {
Enumeration timing
Enumeration sequencing
Enumeration
}
Meaning: Timing - the events are
Per
Sequencing - the events are sequenced
order of
Per
Causality - the events form a
relating cause and
Per
Strictest Requirement: Global, Global,
Scope: per
Example Application: Game - { none, per sender, global } (
make sure being hit by bullet
after the shot is fired!)
3.2.4.
Hard real-
There is a meta-requirement on timeliness. If hard real-time
required then the interpretation of all the other
changes. Failures to achieve the required timeliness must
Bagnall, et al. Informational [Page 9]
RFC 2729 Taxonomy of Communication Requirements December 1999
reported before the communication is made. By contrast soft real
time means that there is no guarantee that an event will occur
time. However statistical measures can be used to indicate
probability of completion in the required time, and policies
as making sure the probability is 95% or better could be used
Type:
Meaning: Hard or Soft
Strictest Requirement:
Scope: per
Example Application: Medical monitor -
To make sure that separate elements of a session are
synchronized with respect to each
Type:
Meaning: The maximum time drift between
Strictest Requirement: 80ms for human
Scope: per stream pair/
Example Application: TV lip-sync value 80
NB: the scope is not necessarily the same
the session. Some streams may no need to
sync'd, (say, a score ticker in a
This is a measure of the variance of bandwidth requirements
time
Type:
Meaning: either
Variation in b/w as fraction of b/w
variable b/w
duty cycle (fraction of time at peak b/w
for intermittent b/w communications
Strictest Requirement: Variation = max b/w Duty cycle ~ 0
Scope: per
Example Application: Sharing video clips, with chat channel -
sudden bursts as clips are swapped
Compressed Audio - difference
silence and
NB: More detailed analysis of
flow (e.g. max rate of b/w change
Bagnall, et al. Informational [Page 10]
RFC 2729 Taxonomy of Communication Requirements December 1999
Fourier Transform of the b/w requirement)
possible but as complexity
usefulness and computability decrease
Jitter is a measure of variance in the time taken
communications to traverse from the sender (application) to
receiver, as seen from the application layer
Type:
Meaning: Maximum permissible time
Strictest Requirement: <1
Scope: per
Example Application: audio streaming - <1
NB: A jitter requirement implies that
communication is a real-time stream.
makes relatively little sense for a
transfer for example
This specifies how long the
being transferred remains valid for
Type:
Meaning: Date at which data
Strictest Requirement: For
Scope: per
Example Application: key distribution - now+3600 seconds (
for at least one hour
Time between initiation and occurrence
an action from application perspective
Type:
Strictest Requirement: Near zero for process control
Scope: per
Example Application: Audio conference 20
NB: Where an action consists of
distinct sequential parts the
budget must be split over those parts.
process control the requirement may
any value
Bagnall, et al. Informational [Page 11]
RFC 2729 Taxonomy of Communication Requirements December 1999
Optimum
Bandwidth required to complete communication in
Type:
Strictest Requirement: No upper
Scope: per
Example Application: Internet Phone 8kb/
Tolerable
Minimum bandwidth that application can
Type:
Strictest Requirement: No upper
Scope: per
Example Application: Internet phone 4kb/
Required by time and
Time communication should complete by and time when failure
complete renders communication useless (therefore abort).
Type: {
Date - preferred complete time
Date - essential complete
}
Strictest Requirement: Both now
Scope: per
Example Application: Email - Preferred 5 minutes & Essential
1
NB: Bandwidth * Duration = Size; only two
these parameters may be specified. An
though could allow application authors
think in terms of any two
Host
Ability of host to create/consume
Type: Application
Meaning: Level of resources required by
Strictest Requirement: Full
Scope: per
Example Application: Video - consume 15 frames a
NB: Host performance is complex since load
media type, media quality, h/w assistance
and encoding scheme all affect
Bagnall, et al. Informational [Page 12]
RFC 2729 Taxonomy of Communication Requirements December 1999
processing load. These are difficult
predict prior to a communication starting
To some extent these will need to
measured and modified as the
proceeds
Frame
Size of logical data packets from application
Type: data
Strictest Requirement: 6 bytes (gaming
Scope: per
Example Application: video = data size of single frame
Content
The total size of the content (not relevant for continuous media
Type: data
Strictest Requirement: N/
Scope: per
Example Application: document transfer, 4
3.2.5. Session
Which initiation mechanism will be used
Type:
Meaning: Announcement - session is
announced via a mass
Invitation - specific participants
explicitly invited, e.g. my
Directive - specific participants
forced to join the
Strictest Requirement:
Scope: per
Example Application: Corporate s/w update -
Bagnall, et al. Informational [Page 13]
RFC 2729 Taxonomy of Communication Requirements December 1999
Start
Time sender starts sending
Type:
Strictest Requirement:
Scope: per
Example Application: FTP - at 3
End
Type:
Strictest Requirement:
Scope: per
Example Application: FTP - Now+30
(end time) - (start time) = (duration), therefore only two
three should be specified
Type:
Strictest Requirement: - 0ms for discrete, indefinite for
Scope: per
Example Application: audio feed - 60
Active
Total time session is active, not including
Type:
Strictest Requirement: equals
Scope: per
Example Application: Spectator sport
Session
Expected level of burstiness of the
Type:
Meaning: Variance as a fraction of maximum
Strictest Requirement: =
Scope: per
Example Application: commentary & slide show: 90% of
Bagnall, et al. Informational [Page 14]
RFC 2729 Taxonomy of Communication Requirements December 1999
Atomic
Session fails unless a certain proportion of the
participants accept an invitation to join. Alternatively, may
specified as a specific numeric quorum
Type: Fraction (proportion required) or
(quorum
Strictest Requirement: 1.0 (proportion
Example Application: price list update, committee
Scope: per stream or
NB: whether certain participants are
is application dependent
Late join allowed ?
Does joining a session after it starts make
Type:
Strictest Requirement:
Scope: per stream or
Example Application: game - not
NB: An application may wish to define
alternate session if late join is
Temporary leave allowed ?
Does leaving and then coming back make sense for
Type:
Strictest Requirement:
Scope: per stream or
Example Application: FTP - not
Late join with catch-up allowed ?
Is there a mechanism for a late joiner to see what they've
Type:
Strictest Requirement:
Scope: per stream or
Example Application: sports event broadcast,
NB: An application may wish to define
alternate session if late join is
Bagnall, et al. Informational [Page 15]
RFC 2729 Taxonomy of Communication Requirements December 1999
Potential streams per
Total number of streams that are part of session, whether
consumed or
Type:
Strictest Requirement: No upper
Scope: per
Example Application: football match mcast - multiple camera's
commentary, 15
Active streams per sessions (i.e. max app can handle
Maximum number of streams that an application can
Type:
Strictest Requirement: No upper
Scope: per
Example Application: football match mcast - 6, one main video
four user selected, one audio
3.2.6. Session
Note: topology may be dynamic. One of the challenges in
adaptive protocol frameworks is to predict the topology before
first join
Number of
The number of senders is a result the middleware may pass up
the
Type:
Strictest Requirement: No upper
Scope: per
Example Application: network MUD - 100
Number of
The number of receivers is a results the middleware may pass up
the
Type:
Strictest Requirement: No upper
Scope: per
Example Application: video mcast - 100,000
Bagnall, et al. Informational [Page 16]
RFC 2729 Taxonomy of Communication Requirements December 1999
3.2.7.
Fail-over timeout (see Reliability: fail-over time
Defines restrictions on when directory entries may be
Type:
Meaning: while entry is in
while entry in
Strictest Requirement: while entry is in
Scope: per
Example Application: voice over mobile phone, while entry is
use (as phone gets new address
changing cell).
3.2.8.
The strength of any security arrangement can be stated as
expected cost of mounting a successful attack. This allows
such as physical isolation to be considered alongside
mechanisms. The cost is measured in an abstract currency, such
1970 UD$ (to inflation proof).
Security is an orthogonal requirement. Many requirements can have
security requirement on them which mandates that the cost of
the system to fail to meet that requirement is more than
specified amount. In terms of impact on other requirements though
security does potentially have a large impact so when a system
trying to determine which mechanisms to use and whether
requirements can be met security will clearly be a major influence
Authentication
Authentication aims to ensure that a principal is who they
to be. For each role in a communication, (e.g. sender, receiver
there is a strength for the authentication of the principle
has taken on that role. The principal could be a person
organization or other legal entity. It could not be a
since a process has no legal representation
Type: Abstract
Meaning: That the cost of hijacking a role is
excess of the specified amount. Each
is a different requirement
Bagnall, et al. Informational [Page 17]
RFC 2729 Taxonomy of Communication Requirements December 1999
Strictest Requirement: budget of largest
Scope: per
Example Application: inter-governmental
Tamper-
This allows the application to specify how much security will
applied to ensuring that a communication is not tampered with
This is specified as the minimum cost of successfully
with the communication. Each non-security requirement has
tamper-proofing requirement attached to it
Requirement: The cost of tampering with the communication is
excess of the specified amount
Type: {
Abstract Currency
Abstract Currency
Abstract
}
Meaning: cost to alter or destroy data
cost to replay data (successfully),
cost to interfere with timeliness
Scope: per
Strictest Requirement: Each budget of largest
Example Application: stock price
Non-repudiation
The non-repudiation strength defines how much care is taken
make sure there is a reliable audit trail on all interactions.
is measured as the cost of faking an audit trail, and
being able to "prove" an untrue event. There are a number
possible parameters of the event that need to be proved.
following list is not exclusive but shows the typical set
requirements
1. Time 2. Ordering (when relative to other events) 3. Whom 4.
What (the event itself
There are a number of events that need to be provable. 1.
proved sent 2. receiver proves received 3. sender proves received
Type: Abstract
Meaning: minimum cost of faking or denying an
Strictest Requirement: Budget of largest
Scope: per
Example Application: Online shopping
Bagnall, et al. Informational [Page 18]
RFC 2729 Taxonomy of Communication Requirements December 1999
Denial of
There may be a requirement for some systems (999,911,112
services access for example) that denial of service attacks
be launched. While this is difficult (maybe impossible) in
systems at the moment it is still a requirement, just one
can't be met
Type: Abstract
Meaning: Cost of launching a denial of
attack is greater than specified amount
Strictest Requirement: budget of largest
Scope: per
Example Application: web hosting, to prevent individual
stalling system
Action
For any given communication there are a two actions, send
receive. Operations like adding to members to a group are done
a send to the membership list. Examining the list is a request
and receive from the list. Other actions can be generalized
send and receive on some communication, or are application
not comms level issues
Type: Membership list/rule for each action
Meaning: predicate for determining permission
Strictest Requirement: Send and receive have different policies
Scope: per
Example Application: TV broadcast, sender policy
transmitter, receiver policy is null
NB: Several actions may share the
membership policy
Privacy defines how well obscured a principals identity is.
could be for any interaction. A list of participants may
obscured, a sender may obscure their identity when they send
There are also different types of privacy. For example knowing
messages were sent by the same person breaks the strongest type
privacy even if the identity of that sender is still unknown.
each "level" of privacy there is a cost associated with
it. The requirement is that this cost is excessive for
attacker
Bagnall, et al. Informational [Page 19]
RFC 2729 Taxonomy of Communication Requirements December 1999
Type: {
Abstract Currency
Abstract Currency
Abstract Currency
Abstract
}
Meaning: Level of privacy, expected cost to
privacy level for:-
openly identified - this is the
anonymously identified - (messages
the same sender can be linked
unadvertised (but traceable) - meaning
traffic can be detected and traced
it's source or destination, this is
breach if the very fact that
specific principals are
is sensitive
Strictest Requirement: All levels budget of
Scope: per
Example Application: Secret ballot voting
openly identified - budget of
interested
anonymously identified -
unadvertised -
undetectable -
Confidentiality defines how well protected the content of
communication is from snooping
Type: Abstract
Meaning: Level of Confidentiality, the cost
gaining illicit access to the content of
Strictest Requirement: budget of
Scope: per
Example Application: Secure email - value of
Retransmit prevention
This is extremely hard at the moment. This is not to say it's
a requirement
Bagnall, et al. Informational [Page 20]
RFC 2729 Taxonomy of Communication Requirements December 1999
Type: Abstract
Meaning: The cost of retransmitting a secure
of information should exceed the
amount
Strictest Requirement: Cost of retransmitting value
Scope: per
Membership
If a principal attempts to participate in a communication then
check will be made to see if it is allowed to do so.
requirement is that certain principals will be allowed, and
excluded. Given the application is being protected from
details there are only two types of specification available,
user, and per organization (where an organization may
other organizations, and each user may be a member of
organizations). Rules could however be built on properties of
user, for example does the user own a key? Host properties
also be used, so users on slow hosts or hosts running the wrong
could be excluded
Type:
Meaning: Include or
users (list
organizations (list
hosts (list
user properties (rule
org properties (rule
hosts properties (rule
Strictest Requirement: List of individual
Scope: per
Example Application: Corporate video-conference -
Collusion
Which aspects of collusion it is required to prevent. Collusion
defined as malicious co-operation between members of a
session. Superficially, it would appear that collusion is not
relevant threat in a multicast, because everyone has the
information, however, wherever there is differentiation, it can
exploited
Type: {
Abstract Currency
Abstract Currency
Abstract
Bagnall, et al. Informational [Page 21]
RFC 2729 Taxonomy of Communication Requirements December 1999
}
Meaning: time race collusion - cost of
key encryption key (KEK) sharing - cost
sharing of differential QoS (not
collusion as across sessions not
one) - cost of
Strictest Requirement: For all threats cost
combined
Scope: per
Example Application: A race where delay of the start signal
be allowed for, but one participant
fake packet delay while receiving the
signal from another participant
NB: Time race collusion is the most
one to prevent. Also note that while
may be requirements for some systems
does not mean there are
solutions. Setting tough requirements
result in the middleware being unable
create a valid channel
Fairness is a meta-requirement of many other requirements.
particular interest are Reliability and Timeliness requirements
When a communication is first created the creator may wish
specify a set of requirements for these parameters.
which join later may wish to set tighter limits. Fairness
a policy that any improvement is requirement by one principal
be matched by all others, in effect requirements can only be
for the whole group. This increases the likelihood
requirements of this kind will fail to be met. If fairness if
an issue then some parts of the network can use more
methods to achieve those simpler requirements
Type: Level of variance of the requirement
needs to be fair. For example, if
latency requirement states within 2
seconds, the level of fairness required
be that variations in latency are not
than 0.1s. This has in fact become an
in online gaming (e.g. Quake
Meaning: The variance of performance with respect
any other requirement is less than
specified amount
Scope: per stream, per
Bagnall, et al. Informational [Page 22]
RFC 2729 Taxonomy of Communication Requirements December 1999
Example Application: Networked game, latency to
positions of players must be within 5ms
all players
Action on
The action to take on detection of compromise (until
reassured).
Type:
Meaning: warn but
Scope: Per
Strictest Requirement:
Example Application: Secure video conference - if
alert, everyone is warned, but they
continue while knowing not to
sensitive matters (cf. catering
during a meeting).
3.2.8.1. Security
Security dynamics are the temporal properties of the
mechanisms that are deployed. They may affect other
such as latency or simply be a reflection of the
limitations of the system. The requirements are often
with abnormal circumstances (e.g. system violation).
Mean time between
This is not the same as the strength of a system. A fairly
system may have a very long time between compromises because it
not worth breaking in to, or it is only worth it for very
people. Mean time between compromises is a combination
strength, incentive and scale
Type:
Scope: Per
Strictest Requirement:
Example Application: Secure Shell - 1500
Compromise detection time
The average time it must take to detect a compromise (
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:
Scope: Per
Strictest Requirement: Round trip
Example Application: Secure Shell - 2
Compromise recovery time
The maximum time it must take to re-seal the security after
breach. This combined with the compromise detection time
defines how long the system must remain inactive to avoid
security breaches. For example if a compromise is detected in
minute, and recovery takes five, then one minute of traffic is
insecure and the members of the communication must remain
for four minutes after detection while security is re-established
Type:
Scope: Per
Strictest Requirement: 1
Example Application: Audio conference - 10
3.2.9. Payment &
Total
The total cost of communication must be limited to this amount
This would be useful for transfer as opposed to stream
applications
Type:
Meaning: Maximum charge
Scope: Per user per
Strictest Requirement:
Example Application: File Transfer: comms cost must be < 1p/
Cost per
This is the cost per unit time.
applications may not be able to predict
duration of a communication. It may be
meaningful for those to be able to
price per time instead
Type: Currency per
Scope: Per user per
Strictest Requirement:
Example Application: Video Conference - 15p /
Bagnall, et al. Informational [Page 24]
RFC 2729 Taxonomy of Communication Requirements December 1999
Cost per
This is the cost per unit of data. Some communications may
charged by the amount of data transferred. Some applications
prefer to specify requirements in this way
Type: Currency per data
Scope: Per user per
Strictest Requirement:
Example Application: Email advertising - 15p /
4. Security
See comprehensive security section of taxonomy
5.
[Bagnall98] Bagnall Peter, Poppitt Alan, Example
classifications, BT Tech report
[limitations] Pullen, M., Myjak, M. and C. Bouwens, "Limitations
Internet Protocol Suite for Distributed Simulation
the Large Multicast Environment", RFC 2502,
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,
and Wiener, Minimal Key Lengths for Symmetric
to Provide Adequate Commercial Security, January 1996.
Bagnall, et al. Informational [Page 25]
RFC 2729 Taxonomy of Communication Requirements December 1999
6. Authors'
Peter
c/o B54/77 BT
Martlesham
Ipswich, IP5 3
EMail: pete@surfaceeffect.
Home page: http://www.surfaceeffect.com/people/pete
Bob
B54/74 BT
Martlesham
Ipswich, IP5 3
Phone: +44 1473 645196
Fax: +44 1473 640929
EMail: bob.briscoe@bt.
Home page: http://www.labs.bt.com/people/briscorj
Alan
B54/77 BT
Martlesham
Ipswich, IP5 3
Phone: +44 1473 640889
Fax: +44 1473 640929
EMail: apoppitt@jungle.bt.co.
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
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Bagnall, et al. Informational [Page 27]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
