idnits 2.17.1 draft-ietf-lsma-requirements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** 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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** 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 1 longer page, the longest (page 1) being 1012 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There are 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. 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 (20 Nov 1998) is 9283 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'Bagnall97' is defined on line 952, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Bagnall97' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 Working Group R Briscoe 3 Expiration: 21 May 1998 A Poppitt 4 BT 5 20 Nov 1998 7 Taxonomy of Communication Requirements 8 for Large-scale Multicast Applications 10 draft-ietf-lsma-requirements-02.txt 12 Status of this Memo 13 ------------------- 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as ``work 22 in progress.'' 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 NB: an html version of this draft may be found at 31 http://www.labs.bt.com/people/bagnalpm/lsma/ 32 draft-ietf-lsma-requirements-02.txt 34 Abstract 35 -------- 36 The intention of this draft is to define a classification system 37 for the communication requirements of any large-scale multicast 38 application (LSMA). It is very unlikely one protocol can achieve 39 a compromise between the diverse requirements of all the parties 40 involved in any LSMA. It is therefore necessary to understand the 41 worst-case scenarios in order to minimise the range of protocols 42 needed. Dynamic protocol adaptation is likely to be necessary 43 which will require logic to map particular combinations of 44 requirements to particular mechanisms. Standardising the way that 45 applications define their requirements is a necessary step 46 towards this. Classification is a first step towards 47 standardisation. 49 1.Introduction 50 -------------- 51 This taxonomy consists of a large number of parameters that are 52 considered useful for description of communication requirements 53 of LSMAs. To describe a particular application, each parameter 54 would be assigned a value. Typical ranges of values are given 55 wherever possible. Failing this, the type of any possible values 56 is given. The parameters are collected into ten or so higher 57 level categories, but this is purely for convenience. 58 The parameters are pitched at a level considered meaningful to 59 application programmers. However, they describe communications 60 not applications - the terms "3D virtual world", or "shared TV" 61 might imply communications requirements, but they don't 62 accurately describe them. Assumptions about the likely mechanism 63 to achieve each requirement are avoided where possible. The 64 exception to this is that receiver initiated join to multicast 65 address groups [refmcast] on an open access Internet is assumed. 66 While the parameters describe communications, it will be noticed 67 that few requirements concerning routing etc. are apparent. This 68 is because applications have few direct requirements on these 69 second order aspects of communications. Requirements in these 70 areas will have to be inferred from application requirements 71 (e.g. latency). 73 The taxonomy is likely to be useful in a number of ways: 74 1. most simply, it can be used as a checklist to create a 75 requirements statement for a particular LSMA. Example 76 applications will be classified [bagnall98] using the taxonomy in 77 order to exercise (and improve) it 78 2. because strictest requirement have been defined for many 79 parameters, it will be possible to identify worst case scenarios 80 for the design of protocols 81 3. because the scope of each parameter has been defined (per 82 session, per receiver etc.), it will be possible to highlight 83 where heterogeneity is going to be most marked 84 4. a step towards standardisation of the way LSMAs define their 85 communications requirements. This could lead to standard APIs 86 between applications and protocol adaptation middleware 87 5. identification of limitations in current Internet technology 88 for LSMAs to be added to the LSMA limitations draft [limitations] 89 6. identification of gaps in Internet Engineering Task Force 90 (IETF) working group coverage 91 =20 92 This approach is intended to complement that used where 93 application scenarios for Distributed Interactive Simulation 94 (DIS) are proposed [scenarios] in order to generate network 95 design metrics (values of communications parameters). Instead of 96 creating the communications parameters from the applications, we 97 try to imagine applications that might be enabled by stretching 98 communications parameters. 99 The above introduction assumes all the items under the "Further 100 Work" section (near the end) have been completed. As they 101 haven't, the reader is advised to read that section next! 103 2. Definitions 104 -------------- 106 2.1. Definition of Sessions 107 --------------------------- 108 The following terms have no agreed definition, so they will be 109 defined for this document. 110 Session 111 a happening or gathering consisting of flows of information 112 related by a common description that persists for a non- 113 trivial time (more than a few seconds) such that the 114 participants (be they humans or applications) are involved and 115 interested at intermediate times may be defined recursively as 116 a super-set of other sessions 117 Secure session 118 a session with restricted access 119 A session or secure session may be a sub and/or super set of a 120 multicast group. A session can simultaneously be both a sub and a 121 super-set of a multicast group by spanning a number of groups 122 while time-sharing each group with other sessions. 124 2.2. Definitions of Roles 125 ------------------------- 126 Defining all possible roles is not possible. The roles in a 127 communication are application dependant. 129 3. Taxonomy 130 ----------- 132 3.1 Summary of Communications Parameters 133 ---------------------------------------- 134 Before the communications parameters are defined, typed and given 135 worst-case values, they are simply listed for convenience. Also 136 for convenience they are collected under classification headings. 138 3.1.1 Reliability 139 Packet loss 140 Transactional 141 Guaranteed 142 Tolerated loss 143 Semantic loss 144 Component reliability 145 Setup fail-over time 146 Mean time between failures 147 Fail over time during a stream 149 3.1.2 Ordering 150 Ordering type 152 3.1.3 Timeliness 153 Hard Realtime 154 Synchronicity 155 Burstiness 156 Jitter 157 expiry 158 latency 159 optimum bandwidth 160 tolerable bandwidth 161 required by time and tolerance 162 host performance 163 fair delay 164 frame size 165 content size 167 3.1.4 Session Control 168 initiation 169 start time 170 end time 171 duration 172 active time 173 session burstiness 174 atomic join 175 late join allowed ? 176 temporary leave allowed ? 177 late join with catch-up allowed ? 178 potential streams per session 179 active streams per sessions 181 3.1.5 Session Topology 182 # of senders 183 # of receivers 185 3.1.6 Directory 186 fail-over timeout (see Reliability: fail-over time) 187 mobility 189 3.1.7 Security 190 authentication strengh 191 tamper-proofing 192 non-repudiation strength 193 denial of service 194 action restriction 195 privacy 196 retransmit prevention strength 197 membership criteria 198 membership principals 199 collusion prevention 200 fairness 201 action on compromise 203 3.1.8 Security dynamics 204 mean time between compromises 205 compromise detection time limit 206 compromise recovery time limit 208 3.1.9 Payment & Charging 209 Total Cost 210 Cost per time 211 Cost per Mb 213 3.2 Definitions, types and strictest requirements 214 ------------------------------------------------- 215 The terms used in the above table are now defined for the context 216 of this document. Under each definition, the type of their value 217 is given and where possible worst-case values and example 218 applications that would exhibit this requirement. 219 There is no mention of whether a communication is a stream or a 220 discrete interaction. An attempt to use this distinction as a way 221 of characterising communications proved to be remarkably 222 unhelpful and was dropped. 224 3.2.1 Types 225 ----------- 226 Each requirement has a type. The following is a list of all the 227 types used in the following definintions. 228 =B7 Application Benchmark (unknown) 229 =B7 Bandwidth (Kb/s) 230 =B7 Boolean 231 =B7 Abstract Currency (1970 US$) 232 =B7 Currency - current local 233 =B7 Date (ms since 0/1/1970) 234 =B7 Enumeration (int) 235 =B7 Fraction (none) 236 =B7 Idenfitiers 237 =B7 Int (none) 238 =B7 Identifiers (none) 239 =B7 membership list/rule 240 =B7 Duration (ms) 242 3.2.1 Reliability 243 ----------------- 245 3.2.1.1 Packet Loss 246 ------------------- 248 Transactional 249 When multiple operations must occur atomically, transactional 250 communications guarantee that either all occur or none occur and 251 a failure is flagged. 252 Type: Boolean 253 Meaning: Transactional or Not transaction 254 Strictest Requirement: Transactional 255 Example Application: Bank credit transfer, debit and=20 256 credit must be atomic. 257 NB: Transactions are potentially much more complex, 258 but it is believed this is an application=20 259 layer problem. 261 Guaranteed 262 Guarantees communications will succeed under certain conditions. 263 Type: Enumerated 264 Meaning: Deferrable =96 if communication fails it will be 265 deferred until a time when it will be 266 successful. 267 Guaranteed =96 the communication will succeed so=20 268 long as all necessary components are working. = 269 =20 270 No guarantee - failure will not be reported. 271 Strictest Requirement: Deferrable 272 Example Application: Stock quote feed =96 Guaranteed 273 NB: The application will need to set parameters to 274 more fully define Guarantees, which the 275 middleware may translate into, for example, 276 queue lengths. 278 Tolerated loss 279 This specifies the proportion of data from a communication that 280 can be lost before the application becomes completely unusable. 281 Type: Fraction 282 Strictest Requirement: 0% 283 Example Application: Video =96 20% 285 Semantic loss 286 The application specifies how many and which parts of the 287 communication can be discarded if necessary. 288 Type: Identifiers, name disposable application level 289 frames 290 Meaning: List of the identifiers of application frames 291 which may be lost 292 Strictest Requirement: No loss allowed 293 Example Application: Video feed - P frames may be lost, I frames not 294 =20 296 3.2.1.2. Component Reliability 297 ------------------------------ 299 Setup Fail-over time 301 The time before a failure is detected and a replacement component 302 is invoked. From the applications point of view this is the time 303 it may take in exceptional circumstances for a channel to be set- 304 up. It is not the "normal" operating delay before a channel is 305 created. 306 Type: Time 307 Strictest Requirement: Application Dependent 308 Example Application: Name lookup - 5 seconds 310 Mean time between failures 312 The mean time between two consecutive total failures of the 313 channel. 314 Type: Time 315 Strictest Requirement: Indefinite 316 Example Application: Telephony - 1000 hours 318 Fail over time during a stream 320 The time between a stream breaking and a replacement being set 321 up. 322 Type: Time 323 Strictest Requirement: Equal to latency requirement 324 Example Application: File Transfer - 10sec 326 3.2.2. Ordering 327 --------------- 329 Ordering type 331 Specifies what ordering must be preserved for the application 332 Type: Enumeration =20 333 Meaning: Timing Global 334 Per Sender 335 none 336 Sequencing Global 337 Per Sender 338 none 339 Causality Global 340 Per Sender 341 none 342 Strictest Requirement Global timing, sequencing and Causality 343 Example Application: Game - global causal (to make sure being 344 hit by bullet occurs after the shot is 345 fired!) 347 3.2.3. Timeliness 348 ----------------- 350 Hard-real time 351 There is a =93meta-requirement=94 on timeliness. If hard real-time is 352 required then the interpretation of all the other requirements 353 changes. Failures to achieve the required timeliness must be 354 reported before the communication is made. By contrast soft real- 355 time means that there is no guarantee that an event will occur in 356 time. However statistical measures can be used to indicate the 357 probability of completion in the required time, and policies such 358 as making sure the probability is 95% or better could be used. 359 Type: Boolean 360 Meaning: Hard or Soft realtime 361 Strictest Requirement: Hard 362 Example Application: Medical monitor - Hard 364 Synchronicity 365 To make sure that separate elements of a session are correctly 366 synchronised with respect to each other 367 Type: Time 368 Strictest Requirement: 80ms for humans 369 Example Application: TV lip-sync value 80ms 371 Burstiness 372 This is a measure of the variance of bandwidth requirements over 373 time. 374 Type: Fraction 375 Meaning: either: 376 Variation in b/w as fraction of b/w for 377 variable b/w communications 378 or 379 duty cycle (fraction of time at peak b/w) 380 for intermittent b/w communications. 381 =20 382 Strictest Requirement: Variation - max b/w 383 Duty cycle ~ 0 384 Example Application: Sharing video clips, with chat channel 385 sudden bursts as clips are swapped. 386 Compressed Audio - difference between 387 silence and talking 388 NB: More detailed analysis of communication 389 flow (eg max rate of b/w change or 390 Fourier Transform of the b/w requirement) 391 is possible but as complexity increases 392 usefulness and computability decrease. 393 ED: This may need to becomes two, namely B/W 394 variance and Duty Cycle 396 Jitter 397 Jitter is a measure of variance in the time taken for 398 communications to traverse from the sender (application) to the 399 receiver, as seen from the application layer. 400 Type: Time 401 Strictest Requirement: <1ms 402 Example Application: audio streaming - <1ms 403 NB: A jitter requirement implies that the 404 communication is a real-time stream. It 405 makes relatively little sense for a file 406 transfer for example. 408 Expiry 409 This specifies how long the information being transferred remains 410 valid for. 411 Type: Date 412 Strictest Requirement: For ever 413 Example Application: key distribution - 3600 seconds (valid 414 for at least one hour) 416 Latency 417 Time between initiation and occurrence of an action from 418 application perspective. 419 Type: Time 420 Strictest Requirement: Near zero for process control apps 421 Example Application: Audio conference 20ms 422 NB: Where an action consists of several 423 distinct sequential parts the latency 424 =93budget=94 must be split over those parts. 425 For process control the requirement may 426 take any value. 428 Optimum Bandwidth 429 Bandwidth required to complete communication in time 430 Type: Bandwidth 431 Strictest Requirement: Indefinate 432 Example Application: Internet Phone 8kb/s 434 Tolerable Bandwidth 435 Minimum bandwidth that application can tolerate 436 Type: Bandwidth 437 Strictest Requirement: Indefinate 438 Example Application: Internet phone 4kb/s 440 Required by time and tolerance 441 Time communication should complete by and time when failure to 442 complete renders communication useless (therefore abort). 443 Type: Date - preferred complete time 444 Date - essential complete time 445 Strictest Requirement: Application Dependent 446 Example Application: Email - Preferred 5 minutes & Essential 447 in 1 day 448 NB: Bandwidth * Duration - Size; only two of 449 these parameters may be specified. An API 450 though could allow application authors to 451 think in terms of any two. 453 Host performance 454 Ability of host to create/consume communication 455 Type: Application benchmark 456 Strictest Requirement: Full consumption 457 Example Application: Video - consume 15 frames a second 458 NB: Host performance is complex since load, 459 media type, media quality, h/w 460 assistance, and encoding scheme all 461 affect the processing load. These are 462 difficult to predict prior to a 463 communication starting. To some extent 464 these will need to be measured and 465 modified as the communication proceeds. 467 Fair delay 468 Time between receipt of communication and response by the client 469 should determine winner of race conditions, not the first 470 response at the server. The alternative is that the transport 471 should make sure that delivery is withheld until all reciepients 472 have the data. The specified requirement determines what delay is 473 acceptable between the first receiver getting the data and the 474 last receiver getting the data (assuming no system failures, but 475 including packet loss). Requirement: the variance in delay 476 between users that is acceptable 477 Type: Time 478 Strictest Requirement: 10ms 479 Example Application: auction room - <10ms 481 Frame size 482 Size of logical data packets from application perspective 483 Type: data size 484 Strictest Requirement: 6bytes (gaming) 485 Example Application: video - data size of single frame update 487 Content size 488 The total size of the content (not relevant for continuous media) 489 Type: data size 490 Strictest Requirement: N/A 491 Example Application: xxx 493 3.2.4. Session Control 494 ---------------------- 496 Initiation 497 Which initiation mechanism will be used. 498 Type: Enumeration 499 Meaning: Announcement 500 Invitation 501 Directive 502 Strictest Requirement: Directive 503 Example Application: Corporate s/w update - Directive 505 Start Time 506 Time sender starts sending! 507 Type: Date 508 Strictest Requirement: Now 509 Example Application: FTP - at 3am 511 End Time 513 Type: Date 514 Strictest Requirement: Now 515 Example Application: FTP - Now+30mins 517 Duration 518 (end time) - (start time) - (duration), therefore only two of 519 three should be specified. 520 Type: Time 521 Strictest Requirement: - 0ms for discrete, indefinite for 522 streams 523 Example Application: audio feed - 60mins 525 Active Time 526 Total time session is active, not including breaks 527 Type: Time 528 Example Application: Spectator sport transmission 530 Session Burstiness 531 expected level of burstiness of the session 532 Type: fixed point. variance as fraction of max 533 bandwidth 534 Strictest Requirement: -bandwidth 535 Example Application: commentary & slide show: 90% of max 537 atomic join 538 session fails unless a certain proportion of the potential 539 participants accept an invitation to join. Alternatively, may be 540 specified as a specific numeric quorum. 541 Type: fixed point (proportion required) or int 542 (quorum) 543 Strictest Requirement: 1.0 (proportion) 544 Example Application: price list update, committee meeting 545 Note: whether certain participants are 546 essential is application dependent. 548 late join allowed ? 549 does joining a session after it starts make sense 550 Type: Boolean & indirection 551 Strictest Requirement: allowed 552 Example Application: game - not allowed, indirect to spectator 553 channel 555 temporary leave allowed ? 556 does leaving and then coming back make sense for session 557 Type: Boolean 558 Strictest Requirement: allowed 559 Example Application: FTP - not allowed 561 late join with catch-up allowed ? 562 is there a mechanism for a late joiner to see what they've missed 563 Type: Boolean & indirection 564 Strictest Requirement: allowed 565 Example Application: sports event broadcast, allowed, indirect 566 to highlights channel 568 potential streams per session 569 total number of streams that are part of session, whether being 570 consumed or not 571 Type: Int 572 Strictest Requirement: indefinite 573 example app: football match mcast - multiple camera's, 574 commentary, 15 streams 576 active streams per sessions (ie max app can handle) 577 maximum number of streams that an application can consume 578 simeultaneously 579 Type: int 580 Strictest Requirements: indefinite 581 example app: football match mcast - 6, one main video, 582 four user selected, one audio commentary 583 =20 584 3.2.5. Session Topology 585 ----------------------- 587 Note: topology may be dynamic. One of the challenges in designing 588 adaptive protocol frameworks is to predict the topology before 589 the first join. 590 # of senders 591 the number of senders is a result the middleware may pass up to 592 the application 593 Type: int 594 Strictest Requirement: indefinite 595 example app: network MUD - 100 597 # of receivers 598 the number of receivers is a results the middleware may pass up 599 to the application 600 Type: int 601 Strictest Requirement: indefinite 602 example app: video mcast - 100,000 604 3.2.6. Directory 605 ---------------- 607 fail-over timeout (see Reliability: fail-over time) 609 mobility 610 defines restrictions on when directory entries may be changed 611 Type: Enumeration 612 Meaning: while entry is in use 613 while entry in unused 614 never 615 Strictest Requirement: while entry is in use 616 example app: voice over mobile phone, while entry is 617 in use (as phone gets new address when 618 changing cell). 619 =20 620 3.2.7. Security 621 --------------- 622 The strength of any security arrangement can be stated as the 623 expected cost of mounting a successful attack. This allows 624 mechanisms such as physical isolation to be considered alongside 625 encryption mechanisms. An example type would be 1970 UD$ (to 626 inflation proof). Security is an othogonal requirement. Many 627 requirements can have a security requirement on them which 628 mandates that the cost of causing the system to fail to meet that 629 requirement is more than the specified ammount. In terms of 630 impact on other requirements though, security does potentially 631 have a large impact so when a system is trying to determine which 632 mechanisms to use and whether the requirements can be met 633 security will clearly be a major influence. 634 Authentication Strength 635 Authentication aims to ensure that a principal is who they claim 636 to be. For each role in a communication (see 2.1) there is a 637 strength for the authentication of the principle who has taken on 638 that role. The principal could be a person, organisation or other 639 legal entity. It could not be a process since a process has no 640 legal representation. Requirement: That the cost of hijacking a 641 role is in excess of the specified amount. Each role is a 642 different requirement. 643 Type: Abstract Currency 644 Strictest Requirement: budget of largest attacker 645 Example Application: inter-governmental conference 647 Tamper-proofing 648 This allows the application to specify how much security will be 649 applied to ensuring that a communication is not tampered with. 650 This is specified as the minimum cost of successfully tampering 651 with the communication. Each non-security requirement has a 652 tamper-proofing requirement attached to it. Requirement: The cost 653 of tampering with the communication is in excess of the specified 654 amount. 655 Type: Abstract Currency: data is unchanged and complete? 656 Abstract Currency: no replay of transmission is= 657 possible? 658 Abstract Currency: data timeliness is assured (no= 659 malicious packet delay)? 660 Strictest Requirement: Each budget of largest attacker 661 Example Application: stock price feed 663 Non-repudiation strength 664 The non-repdiation strength defines how much care is taken to 665 make sure there is a reliable audit trail on all interactions. It 666 is measured as the cost of faking an audit trail, and therefore 667 being able to "prove" an untrue event. There are a number of 668 possible parameters of the event that need to be proved. The 669 following list is not exclusive but shows the typical set of 670 requirements. 671 1. Time 672 2. Ordering (when relative to other events) 673 3. Whom 674 4. What (the event itself) 675 There are a number of events that need to be provable. 676 1. sender proved sent 677 2. receiver proves received 678 3. sender proves received. 679 Type: Abstract Currency 680 Strictest Requirement: Budget of largest attacker 681 Example Application: Full audit trail: billing based on usage logs. 682 Random partial records: to deter users 683 from fraud with the threat of the 684 possibility of being able to detect it. 686 Denial of service 687 There may be a requirement for some systems (999,911,112 688 emergency sevices access for example) that denial of service 689 attacks cannot be launched. While this is difficult (maybe 690 impossible) in many systems at the moment it is still a 691 requirement, just one that can't be met. 692 Type: Abstract Currency 693 Meaning: Cost of launching a denial of service 694 attack is greater than specified amount. 695 Strictest Requirement: budget of largest attacker 696 Example Application: web hosting, to prevent individual 697 hackers stalling system. 699 Action restriction 700 For any given comunication there are a two actions, send and 701 receive. Operations like adding to members to a group are done as 702 a send to the membership list. Examining the list is a request to 703 and receive from the list. Other actions can be generalised to 704 send and receive on some communication, or are application level 705 not comms level issues. 706 Type: Membership list/rule for each action. 707 Strictest Requirement: Send and receive have different policies. 708 Example Application: TV broadcast, sender policy defines 709 transmitter, receiver policy is null. 710 NB: Several actions may share the same 711 membership policy. 713 Privacy 714 Privacy defines how well obscured a principals identity is. This 715 could be for any interaction. A list of participants may be 716 obscured, a sender may obscure their identity when they send. For 717 each possible action there is a need to define the privacy 718 required. There are also different types of privacy. For example 719 knowing two messages were sent by the same person breaks the 720 strongest type of privacy even if the identity of that sender is 721 still unknown. For each "level" of privacy there is a cost 722 associated with violating it. The requirement is that this cost 723 is excessive for the attacker. 724 Type: Abstract Currency 725 Meaning: Level of privacy, expected cost to 726 violate privacy level for:- 727 =B7 openly identified 728 =B7 anonymously identified (messages 729 from the same sender can be linked) 730 =B7 unadvertised (but tracable) [ed:what 731 does this mean?] 732 =B7 undetectable 733 Strictest Requirement: All levels budget of attacker 734 Example Application: Secret ballot voting system - anonymously 735 identified 737 Retransmit prevention strength 738 This is extremely hard at the moment. This is not to say it's not 739 a requirement. 740 Type: Abstract Currency 741 Meaning: The cost of retransmitting a secure piece 742 of information should exceed the 743 specified amount. 744 Strictest Requirement: Cost of retransmitting value of 745 information 747 Membership Criteria 748 If a principal attempts to participate in a communication then a 749 check will be made to see if it is allowed to do so. The 750 requirement is that certain principals will be allowed, and 751 others excluded. Given the application is being protected from 752 network details there are only two types of specification 753 available, per user, and per organisation (where an organisation 754 may contain other organisations, and each user may be a member of 755 multiple organisations). Rules could however be built on 756 properties of a user, for example does the user own a key? Host 757 properties could also be used, so users on slow hosts or hosts 758 running the wrong OS could be excluded. 759 Type: Macros 760 Meaning: Include or exclude 761 =B7 users (list) 762 =B7 organisations (list) 763 =B7 hosts (list) 764 =B7 user properties (rule) 765 =B7 org properties (rule) 766 =B7 hosts properties (rule) 767 Strictest Requirement: List of individual users 768 Example Application: Corporate video-conference - organisation 769 membership 771 Membership Principals 772 Entities that may join a rule-based secure session atomically. 773 That is, a group of individuals is a principal if they can only 774 all join or leave together. Principals can be considered as the 775 SUBJECT field of an access control list, but this is not intended 776 to imply ACL is a good method to use. 777 Type: Enumeration 778 Meaning: values: certified individuals 779 certified group ids (corporations, 780 organisations) 781 lists (i.e. lists of lists, such as 782 multicast groups, secure sessions) 783 hosts 784 [ed:get Bob to explain] 785 Strictest Requirement: mixture of all types. 786 Example Application: N/A 788 Collusion prevention 789 Which aspects of collusion it is required to prevent. Collusion 790 is defined as malicious co-operation between members of a secure 791 session. Superficially, it would appear that collusion is not a 792 relevant threat in a multicast, because everyone has the same 793 information, however, wherever there is differentiation, it can 794 be exploited. 795 Type: Abstract Currency 796 Meaning: time race collusion - cost of colluding 797 key encryption key (KEK) sharing - cost 798 of colluding 799 sharing of differential QoS (not strictly 800 collusion as across sessions not within 801 one) - cost of colluding 802 =20 803 Strictest Requirement: For all threats cost attackers combined 804 resources 805 Example Application: A race where delay of the start signal 806 may be allowed for, but one participant 807 may fake packet delay while receiving the 808 start signal from another participant. 809 NB: Time race collusion is the most difficult 810 one to prevent. Also note that while 811 these may be requirements for some 812 systems this does not mean there are 813 neccessarily solutions. Setting tough 814 requirements may result in the middleware 815 being unable to create a valid channel. 817 Fairness 818 Fairness is orthogonal to many other requirements. Of particular 819 interest are Reliability and Timeliness requirements. When a 820 communication is first created the creator may wish to specify a 821 set of requirements for these parameters. Principals which join 822 later may wish to set tigher limits. Fairness enforces a policy 823 that any improvement is requirement by one principal must be 824 matched by all others, in effect requirements can only be set for 825 the whole group. This increases the likelyhood that requirements 826 of this kind will fail to be met. If fairness if not an issue 827 then some parts of the network can use more friendly methods to 828 achieve those simpler requirements. 829 Type: delta of the requirement that needs to be 830 fair. 831 Meaning: The variance of performance with respect 832 to any other requirement is less than the 833 specified amount. 834 Example Application: Networked game, latency to receive 835 positions of players must be within 5ms 836 for all players. 838 Action on compromise 839 The action to take on detection of compromise (until security 840 reassured). Not sure this has anything to do with communications, 841 really. 842 Type: Boolean 843 Meaning: warn but continue 844 pause 845 Scope: Per communication 846 Strictest Requirement: pause 847 Example Application: Secure video conference - if intruder 848 alert, everyone is warned, but they can 849 continue while knowing not to discuss 850 sensitive matters (cf. catering staff 851 during a meeting). 852 =20 853 3.2.7.1. Security Dynamics 854 -------------------------- 855 Security dynamics are the temporal properties of the security 856 mechanisms that are deployed. They may affect other requirements 857 such as latency or simply be a reflection of the security 858 limitations of the system. The requirements are often concerned 859 with abnormal circumstances (eg. system violation). 861 Mean time between compromises 862 This is not the same as the strength of a system. A fairly weak 863 system may have a very long time between compromises because it 864 is not worth breaking in to, or it is only worth it for very few 865 people. Mean time between compromises is a combination of 866 strength, incentive and scale. 867 Type: Time 868 Scope: Per communication 869 Strictest Requirement: indefinate 870 Example Application: Secure Shell - 1500hrs 872 Compromise detection time limit 873 The average time it must take to detect a compromise (one 874 predicted in the design of the detection system, that is). 875 Type: Time 876 Scope: Per communication 877 Strictest Requirement: Round trip time 878 Example Application: Secure Shell - 2secs 880 Compromise recovery time limit 881 The maximum time it must take to re-seal the security after a 882 breach. This combined with the compromise detection time limit 883 defines how long the system must remain inactive to avoid more 884 security breaches. For example if a compromise is detected in one 885 minute, and recovery takes five, then one minute of traffic is 886 now insecure and the members of the communication must remain 887 silent for four minutes after detection while security is re- 888 established. 889 Type: Time 890 Scope: Per communication 891 Strictest Requirement: 1 second 892 Example Application: Audio conference - 10 seconds 894 3.2.8. Payment & Charging 895 ------------------------- 897 Total Cost 898 The total cost of communication must be limited to this amount. 899 This would be useful for tranfer as opposed to stream type 900 applications. 901 Type: Currency 902 Meaning: Maximum charge allowed 903 Scope: Per user per communication 904 Strictest Requirement: Free 905 Example Application: File Transfer: comms cost must be < 1p/Mb 907 Cost per Time 908 This is the cost per unit time. Some applications may not be able 909 to predict the duration of a communication. It may be more 910 meaningful for those to be able to specifiy price per time 911 instead. 912 Type: Currency 913 Scope: Per user per communication 914 Strictest&Requirement: Free 915 Example Application Video Conference - 15p / minute 917 Cost per Mb 918 This is the cost per unit of data. Some communications may be 919 charged by the amount of data transfered. Some applications may 920 prefer to specify requirements in this way. 921 Type: Currency 922 Scope: Per user per communication 923 Strictest&Requirement: Free 924 Example Application Email advertising - 15p / Mb 926 4. Mapping of Requirements to IETF Working Groups 927 -------------------------= 928 ------------------------ 929 TBA 931 5. Further Work 932 --------------- 933 Attempt to simplify! Refine definitions and types. In particular 934 clarify where enumerations aren't intended to be "one of" types. 935 Complete specifying worst case values & example apps. 936 Identification of scope of each parameter (per communication, per 937 receiver, per sender etc.) to highlight potential heterogeneity 938 problems Mapping between requirements and IETF Working Groups 939 Exercising the taxonomy with some scenarios Exercising the 940 taxonomy with some media-types which represent large sub- sets of 941 application capabilities so can potentially be "macros" or 942 shorthand to set values (or ranges) for a large number of 943 parameters at once. 945 6. Security Considerations 946 -------------------------= 947 - 948 See comprehensive security section of taxonomy. 950 7. References 951 ------------- 952 [Bagnall97] Bagnall Peter, Poppitt Alan, Example LSMA classifications [TBA] 954 [refmcast] IP multicast ref 956 [limitations] Pullen M, Myjak M, Bouwens C, Limitations of Internet 957 Protocol Suite for Distributed Simulation in the Large Multicast 958 Environment, Internet Draft, 26 Mar 1997, draft-ietf-lsma-limitations- 959 01.txt 961 [scenarios] Seidensticker S, Smith W, Myjak W, Scenarios and Appropriate 962 Protocols for Distributed Interactive Simulation, Internet Draft, 21 Jul 963 1997, draft-ietf-lsma-scenarios-01.txt 965 [rmodp] Open Distributed Processing Reference Model (RM-ODP), ISO/IEC 966 10746-1 to 10746-4 or ITU-T (formerly CCITT) X.901 to X.904. Jan 1995. 967 Catalogue entries: 970 [blaze95] Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson and 971 Wiener, Paper on minimal key lengths for security in secret key ciphers? 972 late 1995 974 8. Authors' Addresses 975 --------------------- 976 Bob Briscoe 977 B54/74 BT Labs 978 Martlesham Heath 979 Ipswich, IP5 3RE 980 England 981 Phone: +44 1473 645196 982 Fax: +44 1473 640929 983 EMail: briscorj@boat.bt.com 984 Home page: http://www.labs.bt.com/people/briscorj/ 986 Peter Bagnall 987 B54/74 BT Labs 988 Martlesham Heath 989 Ipswich, IP5 3RE 990 England 991 Phone: +44 1473 647372 992 Fax: +44 1473 640929 993 EMail: pbagnall@jungle.bt.co.uk 994 Home page: http://www.labs.bt.com/people/bagnalpm/ 996 Alan Poppitt 997 B54/74 BT Labs 998 Martlesham Heath 999 Ipswich, IP5 3RE 1000 England 1001 Phone: +44 1473 640889 1002 Fax: +44 1473 640929 1003 EMail: apoppitt@jungle.bt.co.uk 1004 Home page: http://www.labs.bt.com/people/poppitag/