idnits 2.17.1 draft-ietf-lsma-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' Scope: Per user per stream' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (14 May 1999) is 9113 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Bagnall98' is defined on line 1126, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Bagnall98' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT P. Bagnall 2 Large-Scale Multicast Applications Group Working Group R. Briscoe 3 Expiration: 14 November 1999 A. Poppitt 4 BT 5 14 May 1999 6 Taxonomy of Communication Requirements 7 for Large-scale Multicast Applications 9 draft-ietf-lsma-requirements-03.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The intention of this draft is to define a classification system for 35 the communication requirements of any large-scale multicast 36 application (LSMA). It is very unlikely one protocol can achieve a 37 compromise between the diverse requirements of all the parties 38 involved in any LSMA. It is therefore necessary to understand the 39 worst-case scenarios in order to minimise the range of protocols 40 needed. Dynamic protocol adaptation is likely to be necessary which 41 will require logic to map particular combinations of requirements to 42 particular mechanisms. Standardising the way that applications 43 define their requirements is a necessary step towards this. 44 Classification is a first step towards standardisation. 46 Table of Contents 48 Status 49 Abstract 50 1. - Introduction 51 2. - Definitions 52 2.1. - Definitions of Sessions 53 2.2. - Definitions of Roles 54 3. Taxonomy 55 3.1. Summary of Communications Parameters 56 3.2. Definitions, types and strictest requirements 57 4. Security Considerations 58 5. References 59 6. Authors' Addresses 61 1.Introduction 63 This taxonomy consists of a large number of parameters that are 64 considered useful for describing the communication requirements of 65 LSMAs. To describe a particular application, each parameter would be 66 assigned a value. Typical ranges of values are given wherever 67 possible. Failing this, the type of any possible values is given. 68 The parameters are collected into ten or so higher level categories, 69 but this is purely for convenience. 71 The parameters are pitched at a level considered meaningful to 72 application programmers. However, they describe communications not 73 applications - the terms '3D virtual world', or 'shared TV' might 74 imply communications requirements, but they don't accurately describe 75 them. Assumptions about the likely mechanism to achieve each 76 requirement are avoided where possible. 78 While the parameters describe communications, it will be noticed that 79 few requirements concerning routing etc. are apparent. This is 80 because applications have few direct requirements on these second 81 order aspects of communications. Requirements in these areas will 82 have to be inferred from application requirements (e.g. latency). 84 The taxonomy is likely to be useful in a number of ways: 85 1. Most simply, it can be used as a checklist to create a 86 requirements statement for a particular LSMA. Example applications 87 will be classified [bagnall98] using the taxonomy in order to 88 exercise (and improve) it 90 2. Because strictest requirement have been defined for many 91 parameters, it will be possible to identify worst case scenarios 92 for the design of protocols 94 3. Because the scope of each parameter has been defined (per session, 95 per receiver etc.), it will be possible to highlight where 96 heterogeneity is going to be most marked 98 4. It is a step towards standardisation of the way LSMAs define their 99 communications requirements. This could lead to standard APIs 100 between applications and protocol adaptation middleware 102 5. Identification of limitations in current Internet technology for 103 LSMAs to be added to the LSMA limitations draft [limitations] 105 6. Identification of gaps in Internet Engineering Task Force (IETF) 106 working group coverage 108 This approach is intended to complement that used where application 109 scenarios for Distributed Interactive Simulation (DIS) are proposed 110 in order to generate network design metrics (values of communications 111 parameters). Instead of creating the communications parameters from 112 the applications, we try to imagine applications that might be 113 enabled by stretching communications parameters. 115 2. Definitions 117 2.1. Definition of Sessions 119 The following terms have no agreed definition, so they will be 120 defined for this document. 122 Session 123 a happening or gathering consisting of flows of information 124 related by a common description that persists for a non-trivial 125 time (more than a few seconds) such that the participants (be they 126 humans or applications) are involved and interested at 127 intermediate times. A sesssion may be defined recursively as a 128 super-set of other sessions. 130 Secure session 131 a session with restricted access 133 A session or secure session may be a sub and/or super set of a 134 multicast group. A session can simultaneously be both a sub and a 135 super-set of a multicast group by spanning a number of groups while 136 time-sharing each group with other sessions. 138 3.1 Summary of Communications Parameters 140 Before the communications parameters are defined, typed and given 141 worst- case values, they are simply listed for convenience. Also for 142 convenience they are collected under classification headings. 144 Reliability . . . . . . . . . . . . . . . . . . . . . . 3.2.1 145 Packet loss . . . . . . . . . . . . . . . . . . . . 3.2.1.1 146 Transactional 147 Guaranteed 148 Tolerated loss 149 Semantic loss 150 Component reliability . . . . . . . . . . . . . . . 3.2.1.2 151 Setup fail-over time 152 Mean time between failures 153 Fail over time during a stream 154 Ordering . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 155 Ordering type 156 Timeliness . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 157 Hard Realtime 158 Synchronicity 159 Burstiness 160 Jitter 161 Expiry 162 Latency 163 Optimum bandwidth 164 Tolerable bandwidth 165 Required by time and tolerance 166 Host performance 167 Fair delay 168 Frame size 169 Content size 170 Session Control . . . . . . . . . . . . . . . . . . . . 3.2.4 171 Initiation 172 Start time 173 End time 174 Duration 175 Active time 176 Session burstiness 177 Atomic join 178 Late join allowed ? 179 Temporary leave allowed ? 180 Late join with catch-up allowed ? 181 Potential streams per session 182 Active streams per sessions 183 Session Topology . . . . . . . . . . . . . . . . . . . . 3.2.5 184 Number of senders 185 Number of receivers 186 Directory . . . . . . . . . . . . . . . . . . . . . . . 3.2.6 187 Fail-over timeout (see Reliability: fail-over time) 188 Mobility 190 Security . . . . . . . . . . . . . . . . . . . . . . . . 3.2.7 191 Authentication strengh 192 Tamper-proofing 193 Non-repudiation strength 194 Denial of service 195 Action restriction 196 Privacy 197 Confidentiality 198 Retransmit prevention strength 199 Membership criteria 200 Membership principals 201 Collusion prevention 202 Fairness 203 Action on compromise 204 Security dynamics . . . . . . . . . . . . . . . . . . . 3.2.8 205 Mean time between compromises 206 Compromise detection time limit 207 compromise recovery time limit 208 Payment & Charging . . . . . . . . . . . . . . . . . . . 3.2.9 209 Total Cost 210 Cost per time 211 Cost per Mb 213 3.2 Definitions, types and strictest requirements 215 The terms used in the above table are now defined for the context of 216 this document. Under each definition, the type of their value is 217 given and where possible worst-case values and example applications 218 that would exhibit this requirement. 220 There is no mention of whether a communication is a stream or a 221 discrete interaction. An attempt to use this distinction as a way of 222 characterising communications proved to be remarkably unhelpful and 223 was dropped. 225 3.2.1 Types 227 Each requirement has a type. The following is a list of all the types 228 used in the following definintions. 230 Application Benchmark 232 This is some measure of the processor load of an application, in 233 some architecture neutral unit. This is non-trivial since the 234 processing an application requires may change radically with 235 different hardware, for example, a video client with and without 236 hardware support. 238 Bandwidth Measured in bits per second, or a multiple of. 240 Boolean 242 Abstract Currency 243 An abstract currency is one which is adjusted to take inflation 244 into account. The simplest way of doing this is to use the value 245 of a real currency on a specific date. It is effectively a way of 246 assessing the cost of something in "real terms". An example might 247 be 1970 US$. Another measure might be "average man hours". 249 Currency - current local 251 Data Size 253 Date (time since epoch) 255 Enumeration 257 Fraction 259 Identifiers 260 A label used to distinguish different parts of a communication 262 Integer 264 Membership list/rule 266 Macro 267 A small piece of executable code used to describe policies 269 Time 271 3.2.1 Reliability 273 3.2.1.1 Packet Loss 275 Transactional 277 When multiple operations must occur atomically, transactional 278 communications guarantee that either all occur or none occur and a 279 failure is flagged. 281 Type: Boolean 282 Meaning: Transactional or Not transaction 283 Strictest Requirement: Transactional 284 Scope: per stream 285 Example Application: Bank credit transfer, debit and credit must 286 be atomic. 287 NB: Transactions are potentially much more 288 complex, but it is believed this is 289 anpplication layer problem. 291 Guaranteed 293 Guarantees communications will succeed under certain conditions. 295 Type: Enumerated 296 Meaning: Deferrable - if communication fails it will 297 be deferred until a time when it will be 298 successful. 299 Guaranteed - the communication will succeed 300 so long as all necessary components are 301 working. 302 No guarantee - failure will not be 303 reported. 304 Strictest Requirement: Deferrable 305 Example Application: Stock quote feed - Guaranteed 306 Scope: per stream 307 NB: The application will need to set parameters 308 to more fully define Guarantees, which the 309 middleware may translate into, for example, 310 queue lengths. 312 Tolerated loss 314 This specifies the proportion of data from a communication that 315 can be lost before the application becomes completely unusable. 317 Type: Fraction 318 Meaning: fraction of the stream that can be lost 319 Strictest Requirement: 0% 320 Scope: per stream 321 Example Application: Video - 20% 323 Semantic loss 325 The application specifies how many and which parts of the 326 communication can be discarded if necessary. 328 Type: Identifiers, name disposable application 329 level frames 330 Meaning: List of the identifiers of application 331 frames which may be lost 332 Strictest Requirement: No loss allowed 333 Scope: per stream 334 Example Application: Video feed - P frames may be lost, I frames 335 not 337 3.2.1.2. Component Reliability 339 Setup Fail-over time 341 The time before a failure is detected and a replacement component 342 is invoked. From the applications point of view this is the time 343 it may take in exceptional circumstances for a channel to be set- 344 up. It is not the "normal" operating delay before a channel is 345 created. 347 Type: Time 348 Strictest Requirement: Web server - 1 second 349 Scope: per stream 350 Example Application: Name lookup - 5 seconds 352 Mean time between failures 354 The mean time between two consecutive total failures of the 355 channel. 357 Type: Time 358 Strictest Requirement: Indefinite 359 Scope: per stream 360 Example Application: Telephony - 1000 hours 362 Fail over time during a stream 364 The time between a stream breaking and a replacement being set up. 366 Type: Time 367 Strictest Requirement: Equal to latency requirement 368 Scope: per stream 369 Example Application: File Transfer - 10sec 371 3.2.2. Ordering 373 Ordering type 375 Specifies what ordering must be preserved for the application 377 Type: { 378 Enumeration timing, 379 Enumeration sequencing, 380 Enumeration causality 381 } 383 Meaning: Timing - the events are timestamped 384 Global 385 Per Sender 386 none 387 Sequencing - the events are sequenced in 388 order of occurance 389 Global 390 Per Sender 391 none 392 Causality - the events form a graph 393 relating cause and effect 394 Global 395 Per Sender 396 none 397 Strictest Requirement: Global, Global, Global 398 Scope: per stream 399 Example Application: Game - { none, per sender, global } (to 400 make sure being hit by bullet occurs after the shot is fired!) 402 3.2.3. Timeliness 404 Hard-real time 406 There is a meta-requirement on timeliness. If hard real-time is 407 required then the interpretation of all the other requirements 408 changes. Failures to achieve the required timeliness must be 409 reported before the communication is made. By contrast soft real- 410 time means that there is no guarantee that an event will occur in 411 time. However statistical measures can be used to indicate the 412 probability of completion in the required time, and policies such 413 as making sure the probability is 95% or better could be used. 415 Type: Boolean 416 Meaning: Hard or Soft realtime 417 Strictest Requirement: Hard 418 Scope: per stream 419 Example Application: Medical monitor - Hard 421 Synchronicity 423 To make sure that separate elements of a session are correctly 424 synchronised with respect to each other 426 Type: Time 427 Meaning: The maximum time drift between streams 428 Strictest Requirement: 80ms for human perception 429 Scope: per stream pair/set 430 Example Application: TV lip-sync value 80ms 431 NB: the scope is not neccessarily the same as 432 the session. Some streams may no need to be 433 sync'd, (say, a score ticker in a football 434 match 436 Burstiness 438 This is a measure of the variance of bandwidth requirements over 439 time. 441 Type: Fraction 442 Meaning: either: 443 Variation in b/w as fraction of b/w for 444 variable b/w communications 445 or 446 duty cycle (fraction of time at peak b/w) 447 for intermittent b/w communications. 448 Strictest Requirement: Variation = max b/w Duty cycle ~ 0 449 Scope: per stream 450 Example Application: Sharing video clips, with chat channel - 451 sudden bursts as clips are swapped. 452 Compressed Audio - difference between 453 silence and talking 454 NB: More detailed analysis of communication 455 flow (eg max rate of b/w change or Fourier 456 Transform of the b/w requirement) is 457 possible but as complexity increases 458 usefulness and computability decrease. 460 Jitter 462 Jitter is a measure of variance in the time taken for 463 communications to traverse from the sender (application) to the 464 receiver, as seen from the application layer. 466 Type: Time 467 Meaning: Maximum permissible time variance 468 Strictest Requirement: <1ms 469 Scope: per stream 470 Example Application: audio streaming - <1ms 471 NB: A jitter requirement implies that the 472 communication is a real-time stream. It 473 makes relatively little sense for a file 474 transfer for example. 476 Expiry 478 This specifies how long the information 479 being transferred remains valid for. 481 Type: Date 482 Meaning: Date at which data expires 483 Strictest Requirement: For ever 484 Scope: per stream 485 Example Application: key distribution - now+3600 seconds (valid 486 for at least one hour) 488 Latency 490 Time between initiation and occurrence of 491 an action from application perspective. 493 Type: Time 494 Strictest Requirement: Near zero for process control apps 495 Scope: per stream 496 Example Application: Audio conference 20ms 497 NB: Where an action consists of several 498 distinct sequential parts the latency 499 budget must be split over those parts. For 500 process control the requirement may take 501 any value. 503 Optimum Bandwidth 505 Bandwidth required to complete communication in time 507 Type: Bandwidth 508 Strictest Requirement: No upper limit 509 Scope: per stream 510 Example Application: Internet Phone 8kb/s 512 Tolerable Bandwidth 514 Minimum bandwidth that application can tolerate 516 Type: Bandwidth 517 Strictest Requirement: No upper limit 518 Scope: per stream 519 Example Application: Internet phone 4kb/s 521 Required by time and tolerance 523 Time communication should complete by and time when failure to 524 complete renders communication useless (therefore abort). 526 Type: { 527 Date - preferred complete time, 528 Date - essential complete time 529 } 530 Strictest Requirement: Both now. 531 Scope: per stream 532 Example Application: Email - Preferred 5 minutes & Essential in 533 1 day 534 NB: Bandwidth * Duration = Size; only two of 535 these parameters may be specified. An API 536 though could allow application authors to 537 think in terms of any two. 539 Host performance 541 Ability of host to create/consume communication 543 Type: Application benchmark 544 Meaning: Level of resources required by Application 545 Strictest Requirement: Full consumption 546 Scope: per stream 547 Example Application: Video - consume 15 frames a second 548 NB: Host performance is complex since load, 549 media type, media quality, h/w assistance, 550 and encoding scheme all affect the 551 processing load. These are difficult to 552 predict prior to a communication starting. 553 To some extent these will need to be 554 measured and modified as the communication 555 proceeds. 557 Frame size 559 Size of logical data packets from application perspective 561 Type: data size 562 Strictest Requirement: 6bytes (gaming) 563 Scope: per stream 564 Example Application: video = data size of single frame update 566 Content size 568 The total size of the content (not relevant for continuous media) 570 Type: data size 571 Strictest Requirement: N/A 572 Scope: per stream 573 Example Application: document transfer, 4kbytes 575 3.2.4. Session Control 577 Initiation 579 Which initiation mechanism will be used. 581 Type: Enumeration 582 Meaning: Announcement - session is publicly 583 announced via a mass distribution 584 system 585 Invitation - specific participants are 586 explicitly invited, eg my email 587 Directive - specfic participants are forced 588 to join the session 589 Strictest Requirement: Directive 590 Scope: per stream 591 Example Application: Corporate s/w update - Directive 593 Start Time 595 Time sender starts sending! 597 Type: Date 598 Strictest Requirement: Now 599 Scope: per stream 600 Example Application: FTP - at 3am 602 End Time 604 Type: Date 605 Strictest Requirement: Now 606 Scope: per stream 607 Example Application: FTP - Now+30mins 609 Duration 611 (end time) - (start time) = (duration), therefore only two of 612 three should be specified. 614 Type: Time 615 Strictest Requirement: -> 0ms for discrete, indefinite for streams 616 Scope: per stream 617 Example Application: audio feed - 60mins 619 Active Time 621 Total time session is active, not including breaks 622 Type: Time 623 Strictest Requirement: equals duration 624 Scope: per stream 625 Example Application: Spectator sport transmission 627 Session Burstiness 629 Expected level of burstiness of the session 631 Type: Fraction 632 Meaning: Variance as a fraction of maximum bandwidth 633 Strictest Requirement: =bandwidth 634 Scope: per stream 635 Example Application: commentary & slide show: 90% of max 637 Atomic join 639 Session fails unless a certain proportion of the potential 640 participants accept an invitation to join. Alternatively, may be 641 specified as a specific numeric quorum. 643 Type: Fraction (proportion required) or int 644 (quorum) 645 Strictest Requirement: 1.0 (proportion) 646 Example Application: price list update, committee meeting 647 Scope: per stream or session 648 NB: whether certain participants are essential 649 is application dependent. 651 Late join allowed ? 653 Does joining a session after it starts make sense 655 Type: Boolean 656 Strictest Requirement: allowed 657 Scope: per stream or session 658 Example Application: game - not allowed 659 NB: An application may wish to define an 660 alternate session if late join is not 661 allowed 663 Temporary leave allowed ? 665 Does leaving and then coming back make sense for session 667 Type: Boolean 668 Strictest Requirement: allowed 669 Scope: per stream or session 670 Example Application: FTP - not allowed 672 Late join with catch-up allowed ? 674 Is there a mechanism for a late joiner to see what they've missed 676 Type: Boolean 677 Strictest Requirement: allowed 678 Scope: per stream or session 679 Example Application: sports event broadcast, allowed 680 NB: An application may wish to define an 681 alternate session if late join is not 682 allowed 684 Potential streams per session 686 Total number of streams that are part of session, whether being 687 consumed or not 689 Type: Integer 690 Strictest Requirement: No upper limit 691 Scope: per session 692 Example Application: football match mcast - multiple camera's, 693 commentary, 15 streams 695 Active streams per sessions (ie max app can handle) 697 Maximum number of streams that an application can consume 698 simultaneously 700 Type: Integer 701 Strictest Requirement: No upper limit 702 Scope: per session 703 Example Application: football match mcast - 6, one main video, 704 four user selected, one audio commentary 706 3.2.5. Session Topology 708 Note: topology may be dynamic. One of the challenges in designing 709 adaptive protocol frameworks is to predict the topology before the 710 first join. 712 Number of senders 714 The number of senders is a result the middleware may pass up to 715 the application 717 Type: Integer 718 Strictest Requirement: No upper limit 719 Scope: per stream 720 Example Application: network MUD - 100 722 Number of receivers 724 The number of receivers is a results the middleware may pass up to 725 the application 727 Type: Integer 728 Strictest Requirement: No upper limit 729 Scope: per stream 730 Example Application: video mcast - 100,000 732 3.2.6. Directory 734 Fail-over timeout (see Reliability: fail-over time) 736 Mobility 738 Defines restrictions on when directory entries may be changed 740 Type: Enumeration 741 Meaning: while entry is in use 742 while entry in unused 743 never 744 Strictest Requirement: while entry is in use 745 Scope: per stream 746 Example Application: voice over mobile phone, while entry is in 747 use (as phone gets new address when 748 changing cell). 750 3.2.7. Security 752 The strength of any security arrangement can be stated as the 753 expected cost of mounting a successful attack. This allows mechanisms 754 such as physical isolation to be considered alongside encryption 755 mechanisms. The cost is measured in an abstract currency, such as 756 1970 UD$ (to inflation proof). 758 Security is an othogonal requirement. Many requirements can have a 759 security requirement on them which mandates that the cost of causing 760 the system to fail to meet that requirement is more than the 761 specified amount. In terms of impact on other requirements though, 762 security does potentially have a large impact so when a system is 763 trying to determine which mechanisms to use and whether the 764 requirements can be met security will clearly be a major influence. 766 Authentication Strength 768 Authentication aims to ensure that a principal is who they claim 769 to be. For each role in a communication, (eg sender, reciever) 770 there is a strength for the authentication of the principle who 771 has taken on that role. The principal could be a person, 772 organisation or other legal entity. It could not be a process 773 since a process has no legal representation. 775 Type: Abstract Currency 776 Meaning: That the cost of hijacking a role is in 777 excess of the specified amount. Each role 778 is a different requirement. 779 Strictest Requirement: budget of largest attacker 780 Scope: per stream 781 Example Application: inter-governmental conference 783 Tamper-proofing 785 This allows the application to specify how much security will be 786 applied to ensuring that a communication is not tampered with. 787 This is specified as the minimum cost of successfully tampering 788 with the communication. Each non-security requirement has a 789 tamper-proofing requirement attached to it. 791 Requirement: The cost of tampering with the communication is in 792 excess of the specified amount. 794 Type: { 795 Abstract Currency, 796 Abstract Currency, 797 Abstract Currency 798 } 799 Meaning: cost to alter or destroy data, 800 cost to replay data (successfully), 801 cost to interfere with timeliness. 802 Scope: per stream 803 Strictest Requirement: Each >budget of largest attacker 804 Example Application: stock price feed 806 Non-repudiation strength 808 The non-repudiation strength defines how much care is taken to 809 make sure there is a reliable audit trail on all interactions. It 810 is measured as the cost of faking an audit trail, and therefore 811 being able to "prove" an untrue event. There are a number of 812 possible parameters of the event that need to be proved. The 813 following list is not exclusive but shows the typical set of 814 requirements. 816 1. Time 2. Ordering (when relative to other events) 3. Whom 4. 817 What (the event itself) 819 There are a number of events that need to be provable. 1. sender 820 proved sent 2. receiver proves received 3. sender proves received. 822 Type: Abstract Currency 823 Meaning: minimum cost of faking or denying an event 824 Strictest Requirement: > Budget of largest attacker 825 Scope: per stream 826 Example Application: Online shopping system 828 Denial of service 830 There may be a requirement for some systems (999,911,112 emergency 831 sevices access for example) that denial of service attacks cannot 832 be launched. While this is difficult (maybe impossible) in many 833 systems at the moment it is still a requirement, just one that 834 can't be met. 836 Type: Abstract Currency 837 Meaning: Cost of launching a denial of service 838 attack is greater than specified amount. 839 Strictest Requirement: >budget of largest attacker 840 Scope: per stream 841 Example Application: web hosting, to prevent individual hackers 842 stalling system. 844 Action restriction 846 For any given comunication there are a two actions, send and 847 receive. Operations like adding to members to a group are done as 848 a send to the membership list. Examining the list is a request to 849 and receive from the list. Other actions can be generalised to 850 send and receive on some communication, or are application level 851 not comms level issues. 853 Type: Membership list/rule for each action. 854 Meaning: predicate for determining permission for 855 role 856 Strictest Requirement: Send and receive have different policies. 857 Scope: per stream 858 Example Application: TV broadcast, sender policy defines 859 transmitter, receiver policy is null. 860 NB: Several actions may share the same 861 membership policy. 863 Privacy 865 Privacy defines how well obscured a principals identity is. This 866 could be for any interaction. A list of participants may be 867 obscured, a sender may obscure their identity when they send. 868 There are also different types of privacy. For example knowing two 869 messages were sent by the same person breaks the strongest type of 870 privacy even if the identity of that sender is still unknown. For 871 each "level" of privacy there is a cost associated with violating 872 it. The requirement is that this cost is excessive for the 873 attacker. 875 Type: { 876 Abstract Currency, 877 Abstract Currency, 878 Abstract Currency, 879 Abstract Currency 880 } 881 Meaning: Level of privacy, expected cost to violate 882 privacy level for:- 883 openly identified - this is the unprotected 884 case 885 anonymously identified - (messages from 886 the same sender can be linked) 887 unadvertised (but tracable) - meaning that 888 traffic can be detected and traced to 889 it's source or destination, this is a 890 breach if the very fact that two 891 specfic principals are communicating is 892 sensitive. 893 undetectable 894 Strictest Requirement: All levels >budget of attacker 895 Scope: per stream 896 Example Application: Secret ballot voting system 897 openly identified -> budget of any 898 interested party 899 anonymously identified - zero 900 unadvertised - zero 901 undetectable - zero 903 Confidentiality 905 Confidentiality defines how well protected the content of a 906 communication is from snooping. 908 Type: Abstract Currency 909 Meaning: Level of Confidentiality, the cost of 910 gaining illicit access to the content of a 911 stream 912 Strictest Requirement: > budget of attacker 913 Scope: per stream 914 Example Application: Secure email - > value of transmitted 915 information 917 Retransmit prevention strength 919 This is extremely hard at the moment. This is not to say it's not 920 a requirement. 922 Type: Abstract Currency 923 Meaning: The cost of retransmitting a secure piece 924 of information should exceed the specified 925 amount. 926 Strictest Requirement: Cost of retransmitting > value of 927 information 928 Scope: per stream 930 Membership Criteria 932 If a principal attempts to participate in a communication then a 933 check will be made to see if it is allowed to do so. The 934 requirement is that certain principals will be allowed, and others 935 excluded. Given the application is being protected from network 936 details there are only two types of specification available, per 937 user, and per organisation (where an organisation may contain 938 other organisations, and each user may be a member of multiple 939 organisations). Rules could however be built on properties of a 940 user, for example does the user own a key? Host properties could 941 also be used, so users on slow hosts or hosts running the wrong OS 942 could be excluded. 944 Type: Macros 945 Meaning: Include or exclude 946 users (list) 947 organisations (list) 948 hosts (list) 949 user properties (rule) 950 org properties (rule) 951 hosts properties (rule) 952 Strictest Requirement: List of individual users 953 Scope: per stream 954 Example Application: Corporate video-conference - organisation 955 membership 957 Collusion prevention 958 Which aspects of collusion it is required to prevent. Collusion is 959 defined as malicious co-operation between members of a secure 960 session. Superficially, it would appear that collusion is not a 961 relevant threat in a multicast, because everyone has the same 962 information, however, wherever there is differentiation, it can be 963 exploited. 965 Type: { 966 Abstract Currency, 967 Abstract Currency, 968 Abstract Currency 969 } 970 Meaning: time race collusion - cost of colluding 971 key encryption key (KEK) sharing - cost of 972 colluding 973 sharing of differential QoS (not strictly 974 collusion as across sessions not within 975 one) - cost of colluding 976 Strictest Requirement: For all threats cost 977 > attackers 978 combined resources 979 Scope: per stream 980 Example Application: A race where delay of the start signal may 981 be allowed for, but one participant may 982 fake packet delay while receiving the start 983 signal from another participant. 984 NB: Time race collusion is the most difficult 985 one to prevent. Also note that while these 986 may be requirements for some systems this 987 does not mean there are neccessarily 988 solutions. Setting tough requirements may 989 result in the middleware being unable to 990 create a valid channel. 992 Fairness 994 Fairness is a meta-requirement of many other requirements. Of 995 particular interest are Reliability and Timeliness requirements. 996 When a communication is first created the creator may wish to 997 specify a set of requirements for these parameters. Principals 998 which join later may wish to set tigher limits. Fairness enforces 999 a policy that any improvement is requirement by one principal must 1000 be matched by all others, in effect requirements can only be set 1001 for the whole group. This increases the likelyhood that 1002 requirements of this kind will fail to be met. If fairness if not 1003 an issue then some parts of the network can use more friendly 1004 methods to achieve those simpler requirements. 1006 Type: Level of variance of the requirement that 1007 needs to be fair. For example, if the 1008 latency requirement states within 2 1009 seconds, the level of fairness required may 1010 be that variations in latency are not more 1011 than 0.1s. This has in fact become an issue 1012 in online gaming (eg Quake) 1013 Meaning: The variance of performance with respect to 1014 any other requirement is less than the 1015 specified amount. 1016 Scope: per stream, per requirement 1017 Example Application: Networked game, latency to receive 1018 positions of players must be within 5ms for 1019 all players. 1021 Action on compromise 1023 The action to take on detection of compromise (until security 1024 reassured). 1026 Type: Enumeration 1027 Meaning: warn but continue 1028 pause 1029 abort 1030 Scope: Per stream 1031 Strictest Requirement: pause 1032 Example Application: Secure video conference - if intruder 1033 alert, everyone is warned, but they can 1034 continue while knowing not to discuss 1035 sensitive matters (cf. catering staff 1036 during a meeting). 1038 3.2.7.1. Security Dynamics 1040 Security dynamics are the temporal properties of the security 1041 mechanisms that are deployed. They may affect other requirements 1042 such as latency or simply be a reflection of the security 1043 limitations of the system. The requirements are often concerned 1044 with abnormal circumstances (eg. system violation). 1046 Mean time between compromises 1048 This is not the same as the strength of a system. A fairly weak 1049 system may have a very long time between compromises because it is 1050 not worth breaking in to, or it is only worth it for very few 1051 people. Mean time between compromises is a combination of 1052 strength, incentive and scale. 1054 Type: Time 1055 Scope: Per stream 1056 Strictest Requirement: indefinate 1057 Example Application: Secure Shell - 1500hrs 1059 Compromise detection time limit 1061 The average time it must take to detect a compromise (one 1062 predicted in the design of the detection system, that is). 1064 Type: Time 1065 Scope: Per stream 1066 Strictest Requirement: Round trip time 1067 Example Application: Secure Shell - 2secs 1069 Compromise recovery time limit 1071 The maximum time it must take to re-seal the security after a 1072 breach. This combined with the compromise detection time limit 1073 defines how long the system must remain inactive to avoid more 1074 security breaches. For example if a compromise is detected in one 1075 minute, and recovery takes five, then one minute of traffic is now 1076 insecure and the members of the communication must remain silent 1077 for four minutes after detection while security is re-established. 1079 Type: Time 1080 Scope: Per stream 1081 Strictest Requirement: 1 second 1082 Example Application: Audio conference - 10 seconds 1084 3.2.8. Payment & Charging 1086 Total Cost 1088 The total cost of communication must be limited to this amount. 1089 This would be useful for tranfer as opposed to stream type 1090 applications. 1092 Type: Currency 1093 Meaning: Maximum charge allowed 1094 Scope: Per user per stream 1095 Strictest Requirement: Free 1096 Example Application: File Transfer: comms cost must be < 1p/Mb 1098 Cost per Time 1100 This is the cost per unit time. Some 1101 applications may not be able to predict the 1102 duration of a communication. It may be more 1103 meaningful for those to be able to specifiy 1104 price per time instead. 1105 Type: Currency per timeS 1106 Scope: Per user per stream 1107 Strictest Requirement: Free 1108 Example Application: Video Conference - 15p / minute 1110 Cost per Mb 1112 This is the cost per unit of data. Some communications may be 1113 charged by the amount of data transfered. Some applications may 1114 prefer to specify requirements in this way. 1116 Type: Currency per data size 1117 Scope: Per user per stream 1118 Strictest Requirement: Free 1119 Example Application: Email advertising - 15p / Mb 1121 4. Security Considerations See comprehensive security section of 1122 taxonomy. 1124 5. References 1126 [Bagnall98] Bagnall Peter, Poppitt Alan, Example LSMA classifications 1128 [limitations] Pullen M, Myjak M, Bouwens C, Limitations of Internet 1129 Protocol Suite for Distributed Simulation in the Large Multicast 1130 Environment, RFC 2502 1132 [rmodp] Open Distributed Processing Reference Model (RM-ODP), ISO/IEC 1133 10746-1 to 10746-4 or ITU-T (formerly CCITT) X.901 to X.904. Jan 1134 1995. 1136 [blaze95] Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson and 1137 Wiener, Minimal Key Lengths for Symmetric Ciphers to Provide Adequate 1138 Commercial Security, January 1996 1140 6. Authors' Addresses 1142 Peter Bagnall 1143 B54/77 BT Labs 1144 Martlesham Heath 1145 Ipswich, IP5 3RE 1146 England 1147 Phone: +44 1473 647372 1148 Fax: +44 1473 640929 1149 EMail: pbagnall@jungle.bt.co.uk 1150 Home page: http://www.labs.bt.com/people/bagnalpm/ 1152 Bob Briscoe 1153 B54/74 BT Labs 1154 Martlesham Heath 1155 Ipswich, IP5 3RE 1156 England 1157 Phone: +44 1473 645196 1158 Fax: +44 1473 640929 1159 EMail: briscorj@boat.bt.com 1160 Home page: http://www.labs.bt.com/people/briscorj/ 1162 Alan Poppitt 1163 B54/77 BT Labs 1164 Martlesham Heath 1165 Ipswich, IP5 3RE 1166 England 1167 Phone: +44 1473 640889 1168 Fax: +44 1473 640929 1169 EMail: apoppitt@jungle.bt.co.uk 1170 Home page: http://www.labs.bt.com/people/poppitag/