idnits 2.17.1 draft-ietf-ieprep-sip-reqs-02.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 18 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 257 has weird spacing: '... proxy recei...' -- 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 (December 2, 2002) is 7815 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) -- Missing reference section? '1' on line 700 looks like a reference -- Missing reference section? '2' on line 704 looks like a reference -- Missing reference section? '3' on line 708 looks like a reference -- Missing reference section? '4' on line 712 looks like a reference -- Missing reference section? '5' on line 716 looks like a reference -- Missing reference section? '6' on line 720 looks like a reference -- Missing reference section? '7' on line 724 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force IEPREP 3 Internet Draft H. Schulzrinne 4 Columbia U. 5 draft-ietf-ieprep-sip-reqs-02.txt 6 December 2, 2002 7 Expires: May 2003 9 Requirements for Resource Priority Mechanisms for the Session 10 Initiation Protocol 12 STATUS OF THIS MEMO 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 To view the list Internet-Draft Shadow Directories, see 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document summarizes requirements for prioritizing access to 36 circuit-switched network, end system and proxy resources for 37 emergency preparedness communications using the Session Initiation 38 Protocol (SIP). 40 1 Introduction 42 During emergencies, communications resources including telephone 43 circuits, IP bandwidth and gateways between the circuit-switched and 44 IP networks may become congested due to heavy usage, loss of 45 resources caused by the disaster and attack during man-made 46 emergencies, making it difficult for persons charged with emergency 47 assistance, recovery or law enforcement to coordinate their efforts. 49 As IP networks become part of converged or hybrid networks along with 50 public and private circuit-switched (telephone) networks, it becomes 51 necessary to ensure that these networks can assist during such 52 emergencies. 54 There are many IP-based services that can assist during emergencies. 55 This memo only covers requirements for real-time communications 56 applications involving SIP, including voice-over-IP, multimedia 57 conferencing and instant messaging/presence. 59 This document takes no position as to which mode of communication is 60 preferred during an emergency, as such discussion appears to be of 61 little practical value. Based on past experience, real-time 62 communications is likely to be an important component of any overall 63 suite of applications, particularly for coordination of emergency- 64 related efforts. 66 As we will describe in detail below, such SIP applications involve at 67 least five different resources that may become scarce and congested 68 during emergencies. In order to improve emergency response, it may 69 become necessary to prioritize access to such resources during 70 periods of emergency-induced resource scarcity. We call this 71 "resource prioritization". 73 This document describes requirements rather than possible existing or 74 new protocol features. Although it is scoped to deal with SIP-based 75 applications, this should not be taken to imply that mechanisms have 76 to be SIP protocol features such as header fields, methods or URI 77 parameters. 79 The document is organized as follows. In Section 2, we explain core 80 technical terms and acronyms that are used throughout the document. 81 Section 3 describes the five types of resources that may be subject 82 to resource prioritization. Section 4 enumerates four network hybrids 83 that determine which of these resources are relevant. Since the 84 design choices may be constrained by the assumptions placed on the IP 85 network, Section 5 attempts to classify networks into categories 86 according to the restrictions placed on modifications and traffic 87 classes. 89 Since this is a major source of confusion due to similar names, 90 Section 6 attempts to distinguish emergency call services placed by 91 civilians from the topic of this document. 93 Request routing is a core component of SIP, covered in Section 7. 95 Providing resource priority entails complex implementation choices, 96 so that a single priority scheme leads to a set of algorithms that 97 manage queues, resource consumption and resource usage of existing 98 calls. Even within a single administrative domain, the combination of 99 mechanisms is likely to vary. Since it will also depend on the 100 interaction of different policies, it appears inappropriate to have 101 SIP applications specify the precise mechanisms. Section 8 discusses 102 the call-by-value (specification of mechanisms) and call-by-reference 103 (invoke labeled policy) distinction. 105 Based on these discussions, Section 9 summarizes some general 106 requirements that try to achieve generality and feature-transparency 107 across hybrid networks. 109 The most challenging component of resource prioritization is likely 110 to be security (Section 10). Without adequate security mechanisms, 111 resource priority may cause more harm than good, so that the section 112 attempts to enumerate some of the specific threats present when 113 resource prioritization is being employed. 115 2 Terminology 117 CSN: Circuit-switched network, encompassing both private 118 (closed) networks and the public switched telephone network 119 (PSTN). 121 ETS: Emergency telecommunications service, identifying a 122 communications service to be used during large-scale 123 emergencies that allows authorized individuals to 124 communicate. Such communication may reach end points either 125 within a closed network or any endpoint on the CSN or the 126 Internet. The communication service may use voice, video, 127 text or other multimedia streams. 129 Request: In this document, we define "request" as any SIP 130 request. This includes call setup requests, instant message 131 requests and event notification requests. 133 3 Resources 135 Prioritized access to at least five resource types may be useful: 137 Gateway resources: The number of channels (trunks) on a CSN 138 gateway is finite. Resource prioritization may prioritize 139 access to these channels, by priority queuing or 140 preemption. 142 CSN resources: Resources in the CSN itself, away from the access 143 gateway, may be congested. This is the domain of 144 traditional resource prioritization as MLPP and GETS, where 145 circuits are granted to ETS communications based on 146 queueing priority or preemption (if allowed by local 147 telecommunication regulatory policy). A gateway may also 148 use alternate routing (Section 8) to increase the 149 probability of call completion. 151 Specifying CSN behavior is beyond the scope of this 152 document, but as noted below, a central requirement is to 153 be able to invoke all such behaviors from an IP endpoint. 155 IP network resources: SIP may initiate voice and multimedia 156 sessions. In many cases, audio and video streams are 157 inelastic and have tight delay and loss requirements. Under 158 conditions of IP network overload, emergency services 159 applications may not be able to obtain sufficient bandwidth 160 in a best-effort network. While quality of service 161 management is necessary to solve this problem, this is 162 orthogonal to SIP, out of the scope for SIP, and as such 163 these requirements will be discussed in another document. 165 Bandwidth used for SIP signaling itself may be subject to 166 prioritization. 168 Receiving end system resources: End systems may include 169 automatic call distribution systems (ACDs) or media servers 170 as well as traditional telephone-like devices. Gateways are 171 also end systems, but have been discussed earlier. 173 If the receiving end system can only manage a finite number 174 of sessions, a prioritized call may need to preempt an 175 existing call or indicate to the callee that a high- 176 priority call is waiting. (The precise user agent behavior 177 is beyond the scope of this document and considered a 178 matter of policy and implementation.) 180 Such terminating services may be needed to avoid 181 overloading, say, an emergency coordination center. 182 However, other approaches beyond prioritization, e.g., 183 random request dropping by geographic origin, need to be 184 employed if the number of prioritized calls exceeds the 185 terminating capacity. Such approaches are beyond the scope 186 of this memo. 188 SIP proxy resources: While SIP proxies often have large request 189 handling capacities, their capacity is likely to be smaller 190 than their access network bandwidth. (This is true in 191 particular since different SIP requests consume vastly 192 different amounts of proxy computational resources, 193 depending on whether they invoke external services, sip-cgi 194 [1] and CPL [2] scripts, etc. Thus, avoiding proxy overload 195 by restricting access bandwidth is likely to lead to 196 inefficient utilization of the proxy.) Therefore, some 197 types of proxies may need to silently drop selected SIP 198 requests under overload, reject requests, with overload 199 indication or provide multiple queues with different drop 200 and scheduling priorities for different types of SIP 201 requests. However, this is strictly an implementation 202 isssue and does not appear to influence the protocol 203 requirements nor the on-the-wire protocol. Thus, it is out 204 of scope for the protocol requirements discussion pursued 205 here. 207 Responses should naturally receive the same treatment 208 as the corresponding request. Responses already have 209 to be securely mapped to requests, so this requirement 210 does not pose a significant burden. Since proxies 211 often do not maintain call state, it is not generally 212 feasible to assign elevated priority to requests 213 originating from a lower-privileged callee back to the 214 higher-privileged caller. 216 There is no requirement that a single mechanism be used for all five 217 resources. 219 4 Network Topologies 221 We consider four types of combinations of IP and circuit-switched 222 networks. 224 IP end-to-end: Both request originator and destination are on an | 225 IP network, without intervening CSN-IP gateways. Here, any | 226 SIP request could be subject to prioritization. | 228 IP-to-CSN (IP at the start): The request originator is in the IP | 229 network, while the callee is in the CSN. Clearly, this | 230 model only applies to SIP-originated phone calls, not | 231 generic SIP requests such as those supporting instant | 232 messaging services. | 234 CSN-to-IP (IP at the end): A call originates in the CSN and | 235 terminates, via an Internet telephony gateway, in the IP | 236 network. | 238 CSN-IP-CSN (IP bridging): This is a concatenation of the two | 239 previous ones. It is worth calling out specifically to note | 240 that the two CSN sides may use different signaling | 241 protocols. Also, the originating CSN endpoint and the | 242 gateway to the IP network may not know the nature of the | 243 terminating CSN. Thus, encapsulation of originating CSN | 244 information is insufficient. | 246 The bridging model (IP-CSN-IP) can be treated as the concatenation of 247 the IP-to-CSN and CSN-to-IP cases. 249 It is worth emphasizing that CSN-to-IP gateways are unlikely to know 250 whether the final destination is in the IP network, the CSN or, via 251 SIP forking, in both. 253 These models differ in the type of controllable resources, identified 254 as gateway, CSN, IP network resources, proxy and receiver. Items 255 marked as (x) are beyond the scope of this document. 257 Topology Gateway CSN IP proxy receiver 258 _________________________________________________ 259 IP-end-to-end (x) (x) x 260 IP-to-CSN x x (x) (x) (x) 261 CSN-to-IP x x (x) (x) x 262 CSN-IP-CSN x x (x) (x) (x) 264 5 Network Models 266 There are at least four IP network models that influence the 267 requirements for resource priority. Each model inherits the 268 restrictions of the model above it. 270 Pre-configured for ETS: In a pre-configured network, an ETS 271 application can use any protocol carried in IP packets and 272 modify the behavior of existing protocols. As an example, 273 if an ETS agency owns the IP network, it can add traffic 274 shaping, scheduling or support for a resource reservation 275 protocol to routers. 277 Transparent: In a transparent network, an ETS application can 278 rely on the network to forward all valid IP packets, 279 however, the ETS application cannot modify network 280 elements. Commercial ISP offer transparent networks as long 281 as they do not filter certain types of packets. Networks 282 employing firewalls, NATs and "transparent" proxies are not 283 transparent. Sometimes, these types of networks are also 284 called common-carrier networks since they carry IP packets 285 without concern as to their content. 287 SIP/RTP transparent: Networks that are SIP/RTP transparent allow 288 users to place and receive SIP calls. The network allows 289 ingress and egress for all valid SIP messages, possibly 290 subject to authentication. Similarly, it allows RTP media 291 streams in both directions. However, it may block, in 292 either inbound or outbound direction, other protocols such 293 as RSVP or it may disallow non-zero DSCPs. There are many 294 degrees of SIP/RTP transparency, e.g., depending on whether 295 firewalls require inspection of SDP content, thus 296 precluding end-to-end encryption of certain SIP message 297 bodies, or whether only outbound calls are allowed. Many 298 firewalled corporate networks and semi-public access 299 networks such as in hotels are likely to fall into this 300 category. 302 Restricted SIP networks: In restricted SIP networks, users may 303 be restricted to particular SIP applications and cannot add 304 SIP protocol elements such as header fields or use SIP 305 methods beyond a prescribed set. It appears likely that 306 3GPP/3GPP2 networks will fall into this category, at least 307 initially. 309 A separate and distinct problem are SIP networks that 310 administratively prohibit or fail to configure access 311 to special access numbers, e.g., the 710 area code 312 used by GETS. Such operational failures are beyond the 313 reach of a protocol specification. 315 It appears desirable that ETS users can employ the broadest possible 316 set of networks during an emergency. Thus, it appears preferable that 317 protocol enhancements work at least in SIP/RTP transparent networks 318 and are added explicitly to restricted SIP networks. 320 The existing GETS system is an example of an "opportunistic" network, 321 allowing use from most unmodified telephones, while MLPP systems are 322 typically pre-configured. 324 6 Relationship to Emergency Call Services 326 The resource priority mechanisms are used to have selected 327 individuals place calls with elevated priority during times when the 328 network is suffering from a shortage of resources. Generally, calls 329 for emergency help placed by non-officials (e.g., "911" and "112" 330 calls) do not need resource priority under normal circumstances. If 331 such emergency calls are placed during emergency-induced network 332 resource shortages, the call identifier itself is sufficient to 333 identify the emergency nature of the call. Adding an indication of 334 resource priority may be less appropriate, as this would require that 335 all such calls carry this indicator. Also, it opens another attack 336 mechanism, where non-emergency calls are marked as emergency calls. 337 (If the entity can recognize the request URI as an emergency call, it 338 would not need the resource priority mechanism.) 340 7 SIP Call Routing 342 The routing of a SIP request, i.e., the proxies it visits and the UAs 343 it ends up at, may depend on the fact that the SIP request is an ETS 344 request. The set of destinations may be larger or smaller, depending 345 on the SIP request routing policies implemented by proxies. For 346 example, certain gateways may be reserved for ETS use and thus only 347 be reached by labeled SIP requests. 349 8 Policy and Mechanism 351 Most priority mechanisms can be roughly categorized by whether they: 353 o use a priority queue for resource attempts, 355 o make additional resources available (e.g., via alternate 356 routing (ACR)), or 358 o preempt existing resource users (e.g., calls.) 360 For example, in GETS, alternate routing attempts to use alternate 361 GETS-enabled interexchange carriers (IXC) if it cannot be completed 362 through the first-choice carrier. 364 Priority mechanisms may also exempt certain calls from network 365 management traffic controls. 367 The choice between these mechanisms depends on the operational needs 368 and characteristics of the network, e.g., on the number of active 369 requests in the system and the fraction of prioritized calls. 370 Generally, if the number of prioritized calls is small compared to 371 the system capacity and the system capacity is large, it is likely 372 that another call will naturally terminate in short order when a 373 higher-priority call arrives. Thus, it is conceivable that the 374 priority indication can cause preemption in some network entities, 375 while elsewhere it just influences whether requests are queued 376 instead of discarded and what queueing policy is being applied. 378 Some namespaces may inherently imply a preemption policy, while 379 others may be silent on whether preemption is to be used or not, 380 leaving this to local entity policy. 382 Similarly, the precise relationships between labels, e.g., what 383 fraction of capacity is set aside for each priority level, is also a 384 matter of local policy. This is similar to how differentiated 385 services labels are handled. 387 9 Requirements 389 In the PSTN and certain private circuit-switched networks, such as 390 those run by military organizations, calls are marked in various ways 391 to indicate priorities. We call this a "priority scheme". 393 Below are some requirements for providing a similar feature in a SIP 394 environment; security requirements are discussed in Section 10. We 395 will refer to the feature as a "SIP indication" and to requests 396 carrying such an indication as "labelled requests". 398 REQ-1: Not specific to one scheme or country: The SIP indication 399 should support existing and future priority schemes. For 400 example, there are currently at least four priority schemes 401 in widespread use: Q.735, also implemented by the U.S. 402 defense network and NATO, has five levels, the United 403 States GETS (Government Emergency Telecommunications 404 Systems) scheme with implied higher priority and the 405 British Government Telephone Preference Scheme (GTPS) 406 system, which provides three priority levels for receipt of 407 dial tone. 409 The SIP indication may support these existing CSN priority 410 schemes through the use of different name spaces. 412 Private-use namespaces may also be useful for certain 413 applications. 415 REQ-2: Independent of particular network architecture: The SIP 416 indication should work in the widest variety of SIP-based 417 systems. It should not be restricted to particular 418 operators or types of networks, such as wireless networks 419 or protocol profiles and dialects in certain types of 420 networks. The originator of a SIP request cannot be 421 expected to know what kind of CS technology is used by the 422 destination gateway. 424 REQ-3: Invisible to network (IP) layer: The SIP indication must 425 be usable in IP networks that are unaware of the 426 enhancement and in SIP/RTP-transparent networks. Obviously, 427 such networks will not be able to provide enhanced 428 services. 430 This requirement can be translated to mean that the request 431 has to be a valid SIP request and that out-of-band 432 signaling is not acceptable. 434 REQ-4: Mapping of existing schemes: Existing CSN schemes must be 435 translatable to SIP-based systems. 437 REQ-5: No loss of information: For the CSN-IP-CSN case, there 438 should be no loss of signaling information caused by 439 transiting the IP network if both circuit-switched networks 440 use the same priority scheme. Loss of information may be 441 unavoidable if the destination CSN uses a different 442 priority scheme from the origin. 444 One cannot assume that both CSNs are using the same 445 signaling protocol or protocol version, such as ISUP, so 446 that transporting ISUP objects in MIME [3,4] is unlikely to 447 be sufficient. 449 REQ-6: Extensibility: Any naming scheme specified as part of the 450 SIP indication should allow for future expansion. Expanded 451 naming schemes may be needed as resource priority is 452 applied in additional private networks, or if VoIP-specific 453 priority schemes are defined. 455 REQ-7: Separation of policy and mechanism: The SIP indication 456 should not describe a particular detailed treatment, as it 457 is likely that this depends on the nature of the resource 458 and local policy. Instead, it should invoke a particular 459 named policy. As an example, instead of specifying that a 460 certain SIP request should be granted queueing priority, 461 not cause preemption, but be restricted to three-minute 462 sessions, the request invokes a certain named policy that 463 may well have those properties in a particular 464 implementation. An IP-to-CSN gateway may need to be aware 465 of the specific actions required for the policy, but the 466 protocol indication itself should not. 468 Even in the CSN, the same MLPP indication may result 469 in different behavior for different networks. 471 REQ-8: Request-neutral: The SIP indication chosen should work 472 for any SIP request, not just, say, INVITE. 474 REQ-9: Default behavior: Network terminals configured to use a 475 priority scheme may occasionally end up making calls in a 476 network that does not support such a scheme. In those 477 cases, the protocol must support a sensible default 478 behavior that treats the call no worse than a call that did 479 not invoke the priority scheme. Some networks may choose to 480 disallow calls unless they have a suitable priority marking 481 and appropriate authentication. This is a matter of local 482 policy. 484 REQ-10: Address-neutral: Any address or URI scheme may be a 485 valid destination and must be usable with the priority 486 scheme. The SIP indication cannot rely on identifying a set 487 of destination addresses or URI schemes for special 488 treatment. This requirement is motivated by existing ETS 489 systems. For example, in GETS and similar systems, the 490 caller can reach any PSTN destination with increased 491 probability of call completion, not just a limited set. 492 (This does not preclude local policy that allows or 493 disallows, say, calls to international numbers for certain 494 users.) 496 Some schemes may have an open set of destinations, 497 such as any valid E.164 number or any valid domestic 498 telephone number, while others may only reach a 499 limited set of destinations. 501 REQ-11: Identity-independent: The user identity, such as the 502 From header field in SIP, is insufficient to identify the 503 priority level of the request. The same identity can issue 504 non-prioritized requests as well as prioritized ones, with 505 the range of priorities determined by the job function of 506 the caller. The choice of the priority is made based on 507 human judgement, following a set of general rules that are 508 likely to be applied by analogy rather than precise mapping 509 of each condition. For example, a particular circumstance 510 may be considered similarly grave compared to one which is 511 listed explicitly. 513 REQ-12: Independent of network location: While some existing CSN 514 schemes restrict the set of priorities based on the line 515 identity, it is recognized that future IP-based schemes 516 should be flexible enough to avoid such reliance. Instead, 517 a combination of authenticated user identity, user choice 518 and policy determines the request treatment. 520 REQ-13: Multiple simultaneous schemes: Some user agents will 521 need to support multiple different priority schemes, as 522 several will remain in use in networks run by different 523 agencies and operators. (Not all user agents will have the 524 means of authorizing callers using different schemes, and 525 thus may be configured at run-time to only recognize 526 certain namespaces.) 528 REQ-14: Discovery: A terminal should be able to discover which, 529 if any, priority name spaces are supported by a network 530 element. Discovery may be explicit, where a user agent 531 requests a list of the supported name spaces or it may be 532 implicit, where it attempts to use a particular name space 533 and is then told that this name space is not supported. 534 This does not imply that every element has to support the 535 priority scheme. However, entities should be able discover 536 whether a network element supports it or not. 538 REQ-15: Testing: It must be possible to test the system outside 539 of emergency conditions, to increase the chances that all 540 elements work during an actual emergency. In particular, 541 critical elements such as indication, authentication, 542 authorization and call routing must be testable. Testing 543 under load is desirable. Thus, it is desirable that the SIP 544 indication is available continuously, not just during 545 emergencies. 547 REQ-16: 3PCC: The system has to work with SIP third-party call 548 control. 550 REQ-17: Proxy-visible: Proxies may want to use the indication to 551 influence request routing (see Section 7) or impose 552 additional authentication requirements. 554 10 Security Requirements 556 Any resource priority mechanism can be abused to obtain resources and 557 thus deny service to other users. While the indication itself does 558 not have to provide separate authentication, any SIP request carrying 559 such information has more rigorous authentication requirements than 560 regular requests. Below, we describe authentication and authorization 561 aspects, confidentiality and privacy requirements, protection against 562 denial of service attacks and anonymity requirements. Additional 563 discussion can be found in [5]. 565 10.1 Authentication and Authorization 567 SEC-1: More rigorous: Prioritized access to network and end 568 system resources enumerated in Section 3 imposes 569 particularly stringent requirements on authentication and 570 authorization mechanisms since access to prioritized 571 resources may impact overall system stability and 572 performance, not just result in theft of, say, a single 573 phone call. 575 The authentication and authorization requirements for ETS 576 calls are, in particular, much stronger than for emergency 577 calls (112, 911), where wide access is the design 578 objective, sacrificing caller identification if necessary. 580 SEC-2: Attack protection: Under certain emergency conditions, 581 the network infrastructure, including its authentication 582 and authorization mechanism, may be under attack. Thus, 583 authentication and authorization must be able to survive 584 such attacks and defend the resources against these 585 attacks. 587 Mechanisms to delegate authentication and to authenticate 588 as early as possible are required. In particular, the 589 number of packets and the amount of other resources such as 590 computation or storage that an unauthorized user can 591 consume needs to be minimized. 593 Unauthorized users must not be able to block CSN resources, 594 as they are likely to be more scarce than packet resources. 595 This implies that authentication and authorization must 596 take place on the IP network side rather than using, say, a 597 CSN circuit to authenticate oneself via a DTMF sequence. 599 Given the urgency during emergency events, normal 600 statistical fraud detection may be less effective, thus 601 placing a premium on reliable authentication. 603 SIP nodes should be able to independently verify the 604 authorization of requests to receive prioritized service 605 and not rely on transitive trust within the network. 607 SEC-3: Independent of mechanism: Any indication of the resource 608 priority must be independent of the authentication 609 mechanism, since end systems will impose different 610 constraints on the applicable authentication mechanisms. 611 For example, some end systems may only allow user input via 612 a 12-digit keypad, while others may have the ability to 613 acquire biometrics or read smartcards. 615 SEC-4: Non-trusted end systems: Since ETS users may use devices 616 that are not their own, systems should support 617 authentication mechanisms that do not require the user to 618 reveal her secret, such as a PIN or password, to the 619 device. 621 SEC-5: Replay: The authentication mechanisms must be resistant 622 to replay attacks. 624 SEC-6: Cut-and-paste: The authentication mechanisms must be 625 resistant to cut-and-paste attacks. 627 SEC-7: Bid-down: The authentication mechanisms must be resistant 628 to bid down attacks. 630 10.2 Confidentiality and Integrity 632 SEC-8: Confidentiality: All aspects of ETS are likely to be 633 sensitive and should be protected from unlawful intercept 634 and alteration. In particular, requirements for protecting 635 the confidentiality of communications relationships may be 636 higher than for normal commercial service. For SIP, the To, 637 From, Organization, Subject, Priority and Via header fields 638 are examples of particularly sensitive information. Callers 639 may be willing to sacrifice confidentiality if the only 640 alternative is abandoning the call attempt. 642 Unauthorized users must not be able to discern that a 643 particular request is using a resource priority mechanism, 644 as that may reveal sensitive information about the nature 645 of the request to the attacker. Information not required 646 for request routing should be protected end-to-end from 647 intermediate SIP nodes. 649 The act of authentication, e.g., by contacting a particular 650 server, itself may reveal that a user is requesting 651 prioritized service. 653 SIP allows protection of header fields not used for 654 request routing via S/MIME, while hop-by-hop channel 655 confidentiality can be provided by TLS or IPsec. 657 10.3 Anonymity 659 SEC-9: Anonymity: Some users may wish to remain anonymous to the 660 request destination. For the reasons noted earlier, users 661 have to authenticate themselves towards the network 662 carrying the request. The authentication may be based on 663 capabilities and noms, not necessarily their civil name. 664 Clearly, they may remain anonymous towards the request 665 destination, using the network-asserted identity and 666 general privacy mechanisms [6,7]. 668 10.4 Denial-of-Service Attacks 670 SEC-10: Denial-of-service: ETS systems are likely to be subject 671 to deliberate denial-of-service attacks during certain 672 types of emergencies. DOS attacks may be launched on the 673 network itself as well as its authentication and 674 authorization mechanism. 676 SEC-11: Minimize resource use by unauthorized users: Systems 677 should minimize the amount of state, computation and 678 network resources that an unauthorized user can command. 680 SEC-12: Avoid amplification: The system must not amplify attacks 681 by causing the transmission of more than one packet or SIP 682 request to a network address whose reachability has not 683 been verified. 685 11 Security Considerations 687 Section 10 discusses the security issues related to priority 688 indication for SIP in detail and derives requirements for the SIP 689 indicator. As discussed in Section 6, identification of priority 690 service should avoid multiple concurrent mechanisms, to avoid 691 allowing attackers to exploit inconsistent labeling. 693 12 Acknowledgements 695 Fred Baker, Scott Bradner, Ian Brown, Ken Carlberg, Janet Gunn, 696 Kimberly King, Rohan Mahy and James Polk provided helpful comments. 698 13 Bibliography 700 [1] J. Lennox, H. Schulzrinne, and J. Rosenberg, "Common gateway 701 interface for SIP," RFC 3050, Internet Engineering Task Force, Jan. 702 2001. 704 [2] J. Lennox and H. Schulzrinne, "CPL: A language for user control 705 of internet telephony services," Internet Draft, Internet Engineering 706 Task Force, Nov. 2001. Work in progress. 708 [3] E. Zimmerer, J. Peterson, A. Vemuri, L. Ong, F. Audet, M. Watson, 709 and M. Zonoun, "MIME media types for ISUP and QSIG objects," RFC 710 3204, Internet Engineering Task Force, Dec. 2001. 712 [4] A. Vemuri and J. Peterson, "Session initiation protocol for 713 telephones (SIP-T): (SIP-T): context and architectures," RFC 3372, 714 Internet Engineering Task Force, Sept. 2002. 716 [5] I. Brown, "A security framework for emergency communications," 717 Internet Draft, Internet Engineering Task Force, June 2002. Work in 718 progress. 720 [6] J. Peterson, "A privacy mechanism for the session initiation 721 protocol (SIP)," Internet Draft, Internet Engineering Task Force, 722 June 2002. Work in progress. 724 [7] M. Watson, "Short term requirements for network asserted 725 identity," Internet Draft, Internet Engineering Task Force, June 726 2002. Work in progress. 728 14 Authors' Address 730 Henning Schulzrinne 731 Dept. of Computer Science 732 Columbia University 733 1214 Amsterdam Avenue 734 New York, NY 10027 735 USA 736 electronic mail: schulzrinne@cs.columbia.edu