RFC 2729
Taxonomy of Communication Requirements for Large-scale Multicast Applications
Taxonomy of Communication Requirements for Large-scale Multicast Applications ✨
RFC 2729 🎀 (part 1 of 5)
okay so the title block is giving us everything we need 💅 This one is from the Network Working Group and it's written by P. Bagnall, R. Briscoe, and A. Poppitt, all three from BT 🦋 It's Category: Informational, dated December 1999. The title block doesn't list anything it obsoletes or updates, so there's no older RFC it's replacing 🌸
Status of This Memo 📜
bestie, this part is the legal-ish bit but it's short and sweet 🫶 This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 💜
Copyright Notice ©️
Copyright (C) The Internet Society (1999). All Rights Reserved. ✨
Abstract 🔮
so the whole point of this memo is to come up with a classification system for what any large-scale multicast application (LSMA) actually needs from the communications under it 🧚 And the tea is that one protocol basically can't make everyone happy at once, since all the parties in an LSMA have wildly different needs 💀 So you have to look at the worst-case scenarios first, which helps you shrink the number of protocols you'd need. Dynamic protocol adaptation is probably going to be necessary, and that means you need logic that maps particular combinations of requirements onto particular mechanisms 👑 Standardizing how applications describe their requirements is a necessary step toward all that. Classification is the first step toward standardization, periodt 💖
Table of Contents 🗂️
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 . . . . . . . . . . . . . . . .271. Introduction 🌈
this taxonomy is a big pile of parameters that are useful for describing what an LSMA needs from communications 💅 To describe a particular application, you give each parameter a value. Typical ranges of values are given wherever possible. If that's not possible, the type of any possible value is given instead. The parameters get bundled into ten or so higher level categories, but that's just for convenience, not a big deal 🎀
The parameters are pitched at a level that makes sense to application programmers 🧚 But they describe communications, not applications. Terms like '3D virtual world' or 'shared TV' might hint at communications requirements, but they don't accurately describe them 🙈 Assumptions about the likely mechanism for each requirement are avoided where possible, so no sneaky guessing 🫶
Now, the parameters describe communications, and you'll notice there aren't many requirements about routing and so on. That's because applications barely have direct requirements on these second order aspects of communications 🦋 Those requirements have to be inferred from application requirements instead, like latency 💜
The taxonomy is likely to be useful in a number of ways:
- Most simply, it can be used as a checklist to create a requirements statement for a particular LSMA. Example applications will be classified [bagnall98] using the taxonomy in order to exercise (and improve) it ✨
- Because strictest requirements have been defined for many parameters, it will be possible to identify worst case scenarios for the design of protocols 🔥
- Because the scope of each parameter has been defined (per session, per receiver etc.), it will be possible to highlight where heterogeneity is going to be most marked 🌸
- It is a step towards standardization of the way LSMAs define their communications requirements. This could lead to standard APIs between applications and protocol adaptation middleware 🧚
- Identification of limitations in current Internet technology for LSMAs to be added to the LSMA limitations memo [limitations] 🍓
- Identification of gaps in Internet Engineering Task Force (IETF) working group coverage 👑
This approach is meant to complement the one used where application scenarios for Distributed Interactive Simulation (DIS) are proposed in order to generate network design metrics (values of communications parameters). Instead of creating the communications parameters from the applications, we try to imagine applications that might be enabled by stretching communications parameters 🦄
2. Definition of Sessions 🎀
the following terms don't have an agreed definition yet, so this document defines them for itself 🫶
Session a happening or gathering made of flows of information related by a common description that persists for a non-trivial time (more than a few seconds) such that the participants (be they humans or applications) are involved and interested at intermediate times. A session may be defined recursively as a super-set of other sessions. 💖
Secure session a session with restricted access 🔒
A session or secure session may be a sub and/or super set of a multicast group. A session can be both a sub and a super-set of a multicast group at the same time, by spanning a number of groups while time-sharing each group with other sessions 🌈
3. Taxonomy 📚
3.1 Summary of Communications Parameters 💅
before the communications parameters get defined, typed, and given worst-case values, they're just listed here for convenience 🧚 They're also collected under classification headings, so it's easier to scan 🍓
Reliability . . . . . . . . . . . . . . . . . . . . . . 3.2.1
Packet loss . . . . . . . . . . . . . . . . . . . . 3.2.1.1
Transactional
Guaranteed
Tolerated loss
Semantic loss
Component reliability . . . . . . . . . . . . . . . 3.2.1.2
Setup fail-over time
Mean time between failures
Fail over time during a stream
Ordering . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2
Ordering type
Timeliness . . . . . . . . . . . . . . . . . . . . . . . 3.2.3
Hard Realtime
Synchronicity
Burstiness
Jitter
Expiry
Latency
Optimum bandwidth
Tolerable bandwidth
Required by time and tolerance
Host performance
Fair delay
Frame size
Content size
Session Control . . . . . . . . . . . . . . . . . . . . 3.2.4
Initiation
Start time
End time
Duration
Active time
Session Burstiness
Atomic join
Late join allowed ?
Temporary leave allowed ?
Late join with catch-up allowed ?
Potential streams per session
Active streams per sessions
Session Topology . . . . . . . . . . . . . . . . . . . . 3.2.5
Number of senders
Number of receivers
Directory . . . . . . . . . . . . . . . . . . . . . . . 3.2.6
Fail-over time-out (see Reliability: fail-over time)
Mobility
Security . . . . . . . . . . . . . . . . . . . . . . . . 3.2.7
Authentication strength
Tamper-proofing
Non-repudiation strength
Denial of service
Action restriction
Privacy
Confidentiality
Retransmit prevention strength
Membership criteria
Membership principals
Collusion prevention
Fairness
Action on compromise
Security dynamics . . . . . . . . . . . . . . . . . . . 3.2.8
Mean time between compromises
Compromise detection time limit
compromise recovery time limit
Payment & Charging . . . . . . . . . . . . . . . . . . . 3.2.9
Total Cost
Cost per time
Cost per Mb3.2 Definitions, types and strictest requirements 🔍
the terms in the table above are now defined for the context of this document 💜 Under each definition, you get the type of its value and, where possible, worst-case values and example applications that would show this requirement 🦋
There's no mention of whether a communication is a stream or a discrete interaction. The team tried using that distinction to characterize communications, but it turned out to be remarkably unhelpful, so it got dropped 🙈
3.2.1 Types 🧩
each requirement has a type, and here's the list of all the types used in the definitions that follow 🎀
Application Benchmark This is some measure of the processor load of an application, in some architecture neutral unit. This is non-trivial, since the processing an application requires may change radically with different hardware, for example a video client with and without hardware support. 💻
Bandwidth Measured in bits per second, or a multiple of. 📶
Boolean ✅
Abstract Currency An abstract currency is one which is adjusted to take inflation into account. The simplest way of doing this is to use the value of a real currency on a specific date. It's effectively a way of assessing the cost of something in "real terms". An example might be 1970 US$. Another measure might be "average man hours". 💸
Currency - current local 💰
Data Size 📦
Date (time since epoch) 📅
Enumeration 🔢
Fraction ➗
Identifiers A label used to distinguish different parts of a communication. 🏷️
Integer 🔟
Membership list/rule 📋
Macro A small piece of executable code used to describe policies. 🪄
Time ⏰
3.2.2 Reliability 🛡️
3.2.2.1 Packet Loss
okay so packet loss is giving "what happens when stuff goes missing" and there are four flavours of it 🦋 let's go bestie 💅
Transactional
okay transactional is the all-or-nothing queen 👑 when several operations have to happen atomically, transactional comms guarantee that either all of them occur or none of them do, and if something fails it gets flagged 🚩 no in-between, no cap 💀
Type: Boolean
Meaning: Transactional or Not transaction
Strictest Requirement: Transactional
Scope: per stream
Example Application: Bank credit transfer, debit and credit must
be atomic.
NB: Transactions are potentially much more
complex, but it is believed this is
an application layer problem.Guaranteed
this one is about communications succeeding under certain conditions ✨ it's a whole vibe of "will this actually get there??" 🫶
Type: Enumerated
Meaning: Deferrable - if communication fails it will
be deferred until a time when it will be
successful.
Guaranteed - the communication will succeed
so long as all necessary components are
working.
No guarantee - failure will not be
reported.
Strictest Requirement: Deferrable
Example Application: Stock quote feed - Guaranteed
Scope: per stream
NB: The application will need to set parameters
to more fully define Guarantees, which the
middleware may translate into, for example,
queue lengths.Tolerated loss
this one measures how much of a communication can vanish before the application is completely unusable 🥺 it's giving "how much can I lose and still be iconic" 🎀
Type: Fraction
Meaning: fraction of the stream that can be lost
Strictest Requirement: 0%
Scope: per stream
Example Application: Video - 20%Semantic loss
this is the chosen-ones energy ✨ the application decides how many parts, and which parts, can be thrown away if it has to 🧚 like the list of frames that are allowed to disappear 🍓
Type: Identifiers, name disposable application
level frames
Meaning: List of the identifiers of application
frames which may be lost
Strictest Requirement: No loss allowed
Scope: per stream
Example Application: Video feed - P frames may be lost, I frames
not3.2.2.2. Component Reliability
this section is all about the components underneath the channel and how they behave when things go sideways 🔧💖
Setup Fail-over time
this is the time before a failure is detected and a replacement component gets invoked 🌸 from the application's point of view, it's how long a channel might take to set up in exceptional circumstances. it is not the normal delay before a channel gets created, so don't mix them up 🙈
Type: Time
Strictest Requirement: Web server - 1 second
Scope: per stream
Example Application: Name lookup - 5 secondsMean time between failures
this is the mean time between two consecutive total failures of the channel 🕰️ it's the "how long can I trust this thing" stat 🥹
Type: Time
Strictest Requirement: Indefinite
Scope: per stream
Example Application: Telephony - 1000 hoursFail over time during a stream
this is the time between a stream breaking and a replacement getting set up mid-stream 😭 basically how long the stream is in limbo before the backup shows up 🦋
Type: Time
Strictest Requirement: Equal to latency requirement
Scope: per stream
Example Application: File Transfer - 10sec3.2.3. Ordering
okay ordering is the "who went first" department 💅 this is about what ordering the application needs preserved, and honestly it's so important 🌈
Ordering type
this one specifies what ordering must be preserved for the application 👑 there are three enumerations: timing, sequencing, and causality. each one can be Global, Per Sender, or none 💜
Type: {
Enumeration timing,
Enumeration sequencing,
Enumeration causality
}
Meaning: Timing - the events are timestamped
Global
Per Sender
none
Sequencing - the events are sequenced in
order of occurrence
Global
Per Sender
none
Causality - the events form a graph
relating cause and effect
Global
Per Sender
none
Strictest Requirement: Global, Global, Global
Scope: per stream
Example Application: Game - { none, per sender, global } (to
make sure being hit by bullet occurs
after the shot is fired!)3.2.4. Timeliness ✨
Hard real- time 🚨
Okay so this is the big boss of timeliness 👑. If hard real-time is required, it changes how you read every other requirement in the list 😭. Any failure to hit the required timing has to get reported before the communication even starts. Soft real-time is way more chill. Nothing is guaranteed to arrive on time, but you can use statistics to estimate the chance of finishing in time, like making sure it's 95% or better 📊.
Type: Boolean
Meaning: Hard or Soft realtime
Strictest Requirement: Hard
Scope: per stream
Example Application: Medical monitor - HardSynchronicity 🎬
This is all about keeping the separate parts of a session in sync with each other. Lip-sync is the classic example 👄.
Type: Time
Meaning: The maximum time drift between streams
Strictest Requirement: 80ms for human perception
Scope: per stream pair/set
Example Application: TV lip-sync value 80ms
NB: the scope is not necessarily the same as
the session. Some streams may no need to be
sync'd, (say, a score ticker in a football
matchBurstiness 🌊
This one measures how much your bandwidth needs jump around over time. Think clips getting swapped in a chat, or audio that goes from silence to talking 🗣️.
Type: Fraction
Meaning: either:
Variation in b/w as fraction of b/w for
variable b/w communications
or
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 stream
Example Application: Sharing video clips, with chat channel -
sudden bursts as clips are swapped.
Compressed Audio - difference between
silence and talking
NB: More detailed analysis of communication
flow (e.g. max rate of b/w change or
Fourier Transform of the b/w requirement) is
possible but as complexity increases
usefulness and computability decrease.Jitter 🫨
Jitter is how much the time it takes to get from the sender app to the receiver app wobbles, as seen from the application layer. A jitter requirement basically means you've got a real-time stream, so it doesn't really make sense for something like a file transfer 🙅.
Type: Time
Meaning: Maximum permissible time variance
Strictest Requirement: <1ms
Scope: per stream
Example Application: audio streaming - <1ms
NB: A jitter requirement implies that the
communication is a real-time stream. It
makes relatively little sense for a file
transfer for example.Expiry 🗓️
This tells you how long the information being transferred stays valid 🥛.
Type: Date
Meaning: Date at which data expires
Strictest Requirement: For ever
Scope: per stream
Example Application: key distribution - now+3600 seconds (valid
for at least one hour)Latency ⏱️
This is the time between starting an action and it actually happening, from the app's point of view. If an action has several distinct sequential parts, the latency budget has to get split across them. For process control the requirement can be any value 🎛️.
Type: Time
Strictest Requirement: Near zero for process control apps
Scope: per stream
Example Application: Audio conference 20ms
NB: Where an action consists of several
distinct sequential parts the latency
budget must be split over those parts. For
process control the requirement may take
any value.Optimum Bandwidth 🏃
This is the bandwidth you need to finish the communication in time 💫.
Type: Bandwidth
Strictest Requirement: No upper limit
Scope: per stream
Example Application: Internet Phone 8kb/sTolerable Bandwidth 🥲
This is the minimum bandwidth the application can put up with 😤.
Type: Bandwidth
Strictest Requirement: No upper limit
Scope: per stream
Example Application: Internet phone 4kb/sRequired by time and tolerance ⌛
This is the time you'd like the communication to finish by, plus the point where being late makes it totally useless (so you abort, bye 👋).
Type: {
Date - preferred complete time,
Date - essential complete time
}
Strictest Requirement: Both now.
Scope: per stream
Example Application: Email - Preferred 5 minutes & Essential in
1 day
NB: Bandwidth * Duration = Size; only two of
these parameters may be specified. An API
though could allow application authors to
think in terms of any two.Host performance 💻
This is how well the host can create or consume the communication. It's complicated, because load, media type, media quality, hardware assistance, and encoding scheme all affect the processing load 🤯. These are hard to predict before a communication starts, so they'll need to be measured and adjusted as things go along.
Type: Application benchmark
Meaning: Level of resources required by Application
Strictest Requirement: Full consumption
Scope: per stream
Example Application: Video - consume 15 frames a second
NB: Host performance is complex since load,
media type, media quality, h/w assistance,
and encoding scheme all affect the
processing load. These are difficult to
predict prior to a communication starting.
To some extent these will need to be
measured and modified as the communication
proceeds.Frame size 🖼️
This is the size of logical data packets from the application's perspective 🎮.
Type: data size
Strictest Requirement: 6 bytes (gaming)
Scope: per stream
Example Application: video = data size of single frame updateContent size 📦
This is the total size of the content. It's not relevant for continuous media 🎶.
Type: data size
Strictest Requirement: N/A
Scope: per stream
Example Application: document transfer, 4kbytes3.2.5. Session Control 🎀
This section covers the knobs that control how a session runs 🎛️.
Initiation 📣
This is about which initiation mechanism gets used.
Type: Enumeration
Meaning: Announcement - session is publicly
announced via a mass distribution
system
Invitation - specific participants are
explicitly invited, e.g. my email
Directive - specific participants are
forced to join the session
Strictest Requirement: Directive
Scope: per stream
Example Application: Corporate s/w update - DirectiveStart Time ⏰
This is the time the sender starts sending!
Type: Date
Strictest Requirement: Now
Scope: per stream
Example Application: FTP - at 3amEnd Time 🏁
Type: Date
Strictest Requirement: Now
Scope: per stream
Example Application: FTP - Now+30minsDuration ⏳
Here, (end time) - (start time) = (duration), so you only need to specify two of the three 🧮.
Type: Time
Strictest Requirement: - 0ms for discrete, indefinite for streams
Scope: per stream
Example Application: audio feed - 60minsActive Time 🙌
This is the total time the session is active, not counting breaks.
Type: Time
Strictest Requirement: equals duration
Scope: per stream
Example Application: Spectator sport transmissionSession Burstiness 💥
This is the expected level of burstiness across the whole session 📈.
Type: Fraction
Meaning: Variance as a fraction of maximum bandwidth
Strictest Requirement: =bandwidth
Scope: per stream
Example Application: commentary & slide show: 90% of maxAtomic join ⚛️
The session fails unless a certain proportion of the potential participants accept an invitation to join. You can also specify a specific numeric quorum instead 🙋♀️.
Type: Fraction (proportion required) or int
(quorum)
Strictest Requirement: 1.0 (proportion)
Example Application: price list update, committee meeting
Scope: per stream or session
NB: whether certain participants are essential
is application dependent.Late join allowed ? 🚪
This asks whether joining a session after it has started even makes sense 🎮.
Type: Boolean
Strictest Requirement: allowed
Scope: per stream or session
Example Application: game - not allowed
NB: An application may wish to define an
alternate session if late join is not
allowedTemporary leave allowed ? 🙋
This asks whether leaving and then coming back makes sense for the session 🔁.
Type: Boolean
Strictest Requirement: allowed
Scope: per stream or session
Example Application: FTP - not allowedLate join with catch-up allowed ? 📺
This asks whether there's a mechanism for a late joiner to see what they've missed 🏃♀️.
Type: Boolean
Strictest Requirement: allowed
Scope: per stream or session
Example Application: sports event broadcast, allowed
NB: An application may wish to define an
alternate session if late join is not
allowedPotential streams per session 🎥
This is the total number of streams that are part of the session, whether they're being consumed or not 🍿.
Type: Integer
Strictest Requirement: No upper limit
Scope: per session
Example Application: football match mcast - multiple camera's,
commentary, 15 streamsActive streams per sessions (i.e. max app can handle) 🧠
This is the maximum number of streams an application can consume at the same time 💅.
Type: Integer
Strictest Requirement: No upper limit
Scope: per session
Example Application: football match mcast - 6, one main video,
four user selected, one audio commentary3.2.6. Session Topology 🦋
Note: topology may be dynamic. One of the challenges in designing adaptive protocol frameworks is to predict the topology before the first join. 👀
Number of senders 📤
The middleware may pass the number of senders up to the application as a result. ✨
Type: Integer
Strictest Requirement: No upper limit
Scope: per stream
Example Application: network MUD - 100Number of receivers 📥
The middleware may also pass the number of receivers up to the application as a result. 💖
Type: Integer
Strictest Requirement: No upper limit
Scope: per stream
Example Application: video mcast - 100,0003.2.7. Directory 📒
Fail-over timeout 🕰️ See Reliability: fail-over time.
Mobility 🔄
This one defines the restrictions on when directory entries may be changed. 🎀
Type: Enumeration
Meaning: while entry is in use
while entry in unused
never
Strictest Requirement: while entry is in use
Scope: per stream
Example Application: voice over mobile phone, while entry is in
use (as phone gets new address when
changing cell).3.2.8. Security 🔐
Okay bestie, security is giving main character energy. 👑 The strength of any security setup can be stated as the expected cost of mounting a successful attack. That's what lets you compare stuff like physical isolation with encryption mechanisms side by side. 🧐 The cost is measured in an abstract currency, such as 1970 UD$ (to inflation proof). 💅
Security is an orthogonal requirement, which means it can sit on top of basically any other requirement. Lots of requirements can have a security requirement attached, saying the cost of making the system miss that requirement has to be more than the specified amount. 🔥 It can majorly affect everything else though, so when a system is picking its mechanisms and checking whether its requirements are achievable, security is going to be a huge influence. 😭
Authentication Strength 🪪
Authentication is about making sure a principal is who they claim to be. 🙈 For each role in a communication (e.g. sender, receiver), there is a strength for authenticating the principal who has taken on that role. The principal could be a person, an organization, or another legal entity. It couldn't be a process, since a process has no legal representation. 🤖❌
Type: Abstract Currency
Meaning: That the cost of hijacking a role is in
excess of the specified amount. Each role
is a different requirement.
Strictest Requirement: budget of largest attacker
Scope: per stream
Example Application: inter-governmental conferenceTamper-proofing 🧵
This lets the application say how much security goes into making sure a communication isn't tampered with. It's specified as the minimum cost of successfully tampering with the communication. Every non-security requirement gets a tamper-proofing requirement attached. 🫶
Requirement: The cost of tampering with the communication is in
excess of the specified amount.
Type: {
Abstract Currency,
Abstract Currency,
Abstract Currency
}
Meaning: cost to alter or destroy data,
cost to replay data (successfully),
cost to interfere with timeliness.
Scope: per stream
Strictest Requirement: Each budget of largest attacker
Example Application: stock price feedNon-repudiation strength 📜
This one is about how much care goes into making sure there's a reliable audit trail on all interactions. It's measured as the cost of faking an audit trail, which means being able to "prove" an event that never happened. 🕵️♀️ There are a bunch of possible parameters of the event that might need proving. The list below isn't exhaustive, but it shows the typical set of requirements:
- Time
- Ordering (when relative to other events)
- Whom
- What (the event itself)
There are also a few events that need to be provable:
- sender proved sent
- receiver proves received
- sender proves received
Type: Abstract Currency
Meaning: minimum cost of faking or denying an event
Strictest Requirement: Budget of largest attacker
Scope: per stream
Example Application: Online shopping systemDenial of service 🚫
Some systems (999,911,112 emergency services access, for example) might need a guarantee that denial of service attacks can't be launched. 🚨 That's really hard, maybe impossible, in lots of systems right now, but it's still a requirement, it's just one that can't be met yet. 😓
Type: Abstract Currency
Meaning: Cost of launching a denial of service
attack is greater than specified amount.
Strictest Requirement: budget of largest attacker
Scope: per stream
Example Application: web hosting, to prevent individual hackers
stalling system.Action restriction 🚦
For any communication there are two actions: send and receive. Stuff like adding members to a group is done as a send to the membership list. Examining the list is a request to, and a receive from, the list. Other actions can be generalized into send and receive on some communication, or they're application-level issues rather than comms-level ones. 💌
Type: Membership list/rule for each action.
Meaning: predicate for determining permission for
role
Strictest Requirement: Send and receive have different policies.
Scope: per stream
Example Application: TV broadcast, sender policy defines
transmitter, receiver policy is null.
NB: Several actions may share the same
membership policy.Privacy 🫥
Privacy is all about how well hidden a principal's identity is. This can apply to any interaction. A list of participants might be obscured, and a sender might obscure their identity when they send. 🎭 There are also different types of privacy. For example, knowing that two messages came from the same person breaks the strongest type of privacy, even if you still don't know who that sender is. 😳 For each "level" of privacy there's a cost of violating it, and the requirement is that this cost is excessive for the attacker. 🔒
Type: {
Abstract Currency,
Abstract Currency,
Abstract Currency,
Abstract Currency
}
Meaning: Level of privacy, expected cost to violate
privacy level for:-
openly identified - this is the unprotected
case
anonymously identified - (messages from
the same sender can be linked)
unadvertised (but traceable) - meaning that
traffic can be detected and traced to
it's source or destination, this is a
breach if the very fact that two
specific principals are communicating
is sensitive.
undetectable
Strictest Requirement: All levels budget of attacker
Scope: per stream
Example Application: Secret ballot voting system
openly identified - budget of any
interested party
anonymously identified - zero
unadvertised - zero
undetectable - zeroConfidentiality 🤫
Confidentiality is how well protected the content of a communication is from snooping. 👀
Type: Abstract Currency
Meaning: Level of Confidentiality, the cost of
gaining illicit access to the content of a
stream
Strictest Requirement: budget of attacker
Scope: per stream
Example Application: Secure email - value of transmitted
informationRetransmit prevention strength 🔁
This one is extremely hard at the moment, but that doesn't mean it isn't a requirement. 🥲
Type: Abstract Currency
Meaning: The cost of retransmitting a secure piece
of information should exceed the specified
amount.
Strictest Requirement: Cost of retransmitting value of
information
Scope: per streamMembership Criteria 🎟️
If a principal tries to join a communication, a check gets made to see whether it's allowed in. The requirement is that certain principals get in and others get kept out. 🚪 Since the application is shielded from network details, there are only two types of specification available: per user, and per organization. An organization can contain other organizations, and each user can be a member of several organizations. 🏢 Rules can also be built on properties of a user (for example, does the user own a key?). Host properties can be used too, 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
membershipCollusion prevention 🤝
This covers which aspects of collusion it's required to prevent. Collusion is defined as malicious co-operation between members of a secure session. 😈 At first glance it looks like collusion isn't a relevant threat in a multicast, because everyone has the same information. But wherever there's differentiation, it can be exploited, so it's still a thing to watch. 👀
Type: {
Abstract Currency,
Abstract Currency,
Abstract CurrencyOkay so the collusion row is literally the villain origin story of this whole taxonomy 😭🔪
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 🤝 is a meta-requirement, which means it's a requirement about other requirements. It's especially interested in Reliability and Timeliness. When a communication starts, the creator can set a bunch of requirements for these parameters. Principals who join later might want tighter limits, but fairness says any improvement one principal asks for has to be matched by everyone else. So requirements can only be set for the whole group, bestie. This makes it way more likely that these requirements just won't get met 💀. If fairness isn't an issue, some parts of the network can use friendlier methods to hit the 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
Example Application: Networked game, latency to receive
positions of players must be within 5ms for
all players.Action on compromise 🚨 is the move you make when a compromise gets detected, until the security is reassured. Think of it as the emergency plan that kicks in.
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 time-based behaviour of the security mechanisms you deploy 🕰️ They can mess with stuff like latency, or they can just show you the limits of what the system can do. These requirements are usually about the messy, abnormal moments, like when the system gets violated 😤
Mean time between compromises is NOT the same as how strong a system is 💅 A pretty weak system can go ages between compromises if nobody's bothered breaking in, or if only a few people would even want to. So this one is a mix of strength, incentive and scale 🧠
Type: Time
Scope: Per stream
Strictest Requirement: indefinite
Example Application: Secure Shell - 1500hrsCompromise detection time limit is the average time it has to take to detect a compromise. We mean one that the detection system was designed to predict, okay? 🔍
Type: Time
Scope: Per stream
Strictest Requirement: Round trip time
Example Application: Secure Shell - 2secsCompromise recovery time limit is the maximum time it can take to re-seal the security after a breach 🔒 This works together with the compromise detection time limit to show how long the system has to stay quiet so it doesn't get breached again. Say a compromise gets detected after one minute, and recovery takes five. Then that first minute of traffic is now insecure, so everyone has to stay silent for four minutes after detection while the security gets sorted out 🤫🫶
Type: Time
Scope: Per stream
Strictest Requirement: 1 second
Example Application: Audio conference - 10 seconds3.2.9. Payment & Charging 💸
Total Cost is a cap on how much the whole communication can cost. This is most useful for transfer-style apps rather than streams 📦
Type: Currency
Meaning: Maximum charge allowed
Scope: Per user per stream
Strictest Requirement: Free
Example Application: File Transfer: comms cost must be < 1p/MbCost per Time is the price per unit of time ⏱️ Some apps can't predict how long a communication will last, so it can make more sense to specify a price per time instead 🎀
Type: Currency per timeS
Scope: Per user per stream
Strictest Requirement: Free
Example Application: Video Conference - 15p / minuteCost per Mb is the price per unit of data 📊 Some communications get charged by how much data moves through them, so some apps might prefer to specify requirements this way 🌸
Type: Currency per data size
Scope: Per user per stream
Strictest Requirement: Free
Example Application: Email advertising - 15p / Mb4. Security Considerations 🔐
See comprehensive security section of taxonomy. The entire security story lives over there in the comprehensive security section of the taxonomy, so go read that. This one is serious business, bestie 🚨😭
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.6. Authors' Addresses 🫶
Peter Bagnall
c/o B54/77 BT Labs
Martlesham Heath
Ipswich, IP5 3RE
England
EMail: pete@surfaceeffect.com
Home page: http://www.surfaceeffect.com/people/pete/
Bob Briscoe
B54/74 BT Labs
Martlesham Heath
Ipswich, IP5 3RE
England
Phone: +44 1473 645196
Fax: +44 1473 640929
EMail: bob.briscoe@bt.com
Home page: http://www.labs.bt.com/people/briscorj/
Alan Poppitt
B54/77 BT Labs
Martlesham Heath
Ipswich, IP5 3RE
England
Phone: +44 1473 640889
Fax: +44 1473 640929
EMail: apoppitt@jungle.bt.co.uk
Home page: http://www.labs.bt.com/people/poppitag/7. Full Copyright Statement ©️
The legal bit comes in full, no edits, because it's important 🌈
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 💖
📦 where this page comes from
- ietf: rfc2729 1999-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms