idnits 2.17.1 draft-ietf-ieprep-ets-general-04.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 207: '...aling mechanism(s) MUST exist to carry...' RFC 2119 keyword, line 215: '...be the same, but MAY be related to eac...' RFC 2119 keyword, line 219: '... Policy MUST be kept separate fr...' RFC 2119 keyword, line 229: '... MUST NOT be stated in the defin...' RFC 2119 keyword, line 234: '... unrelated labels MUST NOT be embedded...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [12], but that reference does not seem to mention RFC 2119 either. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 15 looks like a reference -- Missing reference section? '12' on line 45 looks like a reference -- Missing reference section? '2' on line 100 looks like a reference -- Missing reference section? '7' on line 101 looks like a reference -- Missing reference section? '3' on line 104 looks like a reference -- Missing reference section? '4' on line 110 looks like a reference -- Missing reference section? '5' on line 115 looks like a reference -- Missing reference section? '6' on line 115 looks like a reference -- Missing reference section? '10' on line 135 looks like a reference -- Missing reference section? '9' on line 168 looks like a reference -- Missing reference section? '11' on line 225 looks like a reference -- Missing reference section? '8' on line 375 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Ken Carlberg 3 INTERNET DRAFT UCL 4 August 25, 2003 Ran Atkinson 5 Extreme Networks 7 General Requirements for 8 Emergency Telecommunication Service 9 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 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 26 Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 For potential updates to the above required-text see: 30 http://www.ietf.org/ietf/1id-guidelines.txt 32 Abstract 34 This document presents a list of general requirements in support of 35 Emergency Telecommunications Service (ETS). Solutions to these 36 requirements are not presented in this document. Additional 37 requirements pertaining to specific applications, or types of 38 applications, are to be specified in separate document(s). 40 Conventions Used In This Document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in [12]. 46 ^L 48 Terminology 50 Label: 51 The term label has been used for a number of years in various IETF 52 protocols. It is simply an identifier. It can be manifested in 53 the form of a numeric, alphanumeric value, or a specific bit 54 pattern, within a field of a packet header. The exact form is 55 dependent on the protocol in which it is used. 57 An example of a label can be found in RFC 3031; the Multiprotocol 58 label switching architecture. Another example can be found in RFC 59 2597 (and updated by RFC 3260); a bit pattern for the Assured 60 Forwarding PHB group. This latter case is a type of label that 61 does not involve routing. Note that specification of labels is 62 outside the scope of this document. Further comments on labels are 63 discussed below in section 3. 65 1. Introduction 67 Effective telecommunications capabilities can be imperative to 68 facilitate immediate recovery operations for serious disaster events, 69 such as, hurricanes, floods, earthquakes, and terrorist attacks. 70 Disasters can happen any time, any place, unexpectedly. Quick 71 response for recovery operations requires immediate access to any 72 public telecommunications capabilities at hand. These capabilities 73 include: conventional telephone, cellular phones, and Internet 74 access via online terminals, IP telephones, and wireless PDAs. The 75 commercial telecommunications infrastructure is rapidly evolving to 76 Internet-based technology. Therefore, the Internet community needs 77 to consider how it can best support emergency management and recovery 78 operations. 80 1.1 Existing Emergency Related Standards 82 The following are standards from other organizations that are 83 specifically aimed at supporting emergency communications. Most of 84 these standards specify telephony mechanisms or define telephony 85 related labels. 87 Standard / Organization 88 -------------------------- 89 1) T1.631 / ANSI 90 2) E.106 / ITU 91 3) F.706 / ITU 92 4) H.460.4 / ITU 93 5) I.255.3 / ITU 95 ^L 97 The first specifies an indicator for SS7 networks that signals the 98 need for a High Probability of Completion (HPC) service. This 99 indicator is termed National Security / Emergency Preparedness 100 (NS/EP) The T1.631 standard [2] is the basis for the U.S. Government 101 Emergency Telecomunications Service (GETS) [7]. 103 The second standard describes functional capabilities for the PSTN to 104 support International Emergency Preparedness System (IEPS) [3]. From 105 the PSTN perspective, one can view NS/EP as a standard with national 106 boundaries, while IEPS is an extention to international boundaries 107 for telephony. 109 The third standard extends IEPS beyond the scope of telephony into 110 other forms that encompass multimedia [4]. 112 The fourth and fifth standard focuses on a multi-level labeling 113 mechanism distinguishing emergency type traffic from that which is 114 not. The former case focuses on call signaling for H.323 networks 115 [5], while the latter has been applied for both SS7 [6] and data 116 networks. 118 While the above standards are outside the scope of the IETF, they do 119 represent existing efforts in the area of emergency communications, 120 as opposed to conceptual of potential possibilities. They act as 121 example manifestations of Emergency Telecommunications Service (ETS). 123 1.2 Problem 125 One problem faced by the IEPREP working group entails how, and to 126 what degree, support for these standards are to be realized within 127 the Internet architecture and the existing suite of IETF standards 128 and associated working groups. This support could be in the form of 129 interoperability with correponding IETF protocols. 131 A subsequent problem is to ensure that requirements associated with 132 potential support is not focused just on IP telephony applications. 133 The I-Am-Alive (IAA) database system is an example of an ETS type 134 application used in Japan that supports both signaled and non- 135 signaled access by users[10]. It is a distributed database system 136 that provides registration, querying, and reply primitives to 137 participants during times of an emergency (e.g., an earthquake) so 138 that others can make an after-the-event determination about the 139 status of a person. In this case, a separate signaling protocol like 140 SIP is not always required to establish or maintain a connection. 142 Given the case where signaling is optional, requirements and 143 subsequent solutions that address these problems must not assume the 144 existence of signaling and must be able to support applications that 146 ^L 147 only have labels in data packets. These label(s) may be in various 148 places, such as the application or IP header. 150 2. Scope 152 This document defines a set of general system requirements to achieve 153 support for ETS and addressing the problem space presented in Section 154 1.2. In defining these requirements, we consider known systems such 155 as GETS and IAA that represent existing manifestations of emergency 156 related systems. These two examples also represent a broad spectrum 157 of characteristics that range from signaling & interactive non- 158 elastic applications to non-signaled & elastic applications. 160 We stress that ETS, and its associated requirements, is not the only 161 means of supporting authorized emergency communications. It is 162 simply an approach influenced by existing systems and standards. 164 Solutions to requirements are not defined. This document does not 165 specify protocol enhancements or specifications. Requirements for 166 specific types of applications that go beyond the general set stated 167 in section 3 are to be specified in other document(s). At the 168 current writing of this document, [9] has been written for the case 169 of IP telephony. 171 The current IEPREP charter stipulates that any proposed solution to 172 support ETS that responds to the requirements of this document are to 173 be developed in other working groups. We note that other specific 174 requirements (like that of IP telephony) may be defined as an 175 extension of the general requirements presented in section 3 below. 177 2.1 Out of Scope 179 While the problem space stated in section 1.2 includes standards 180 related to telephony, this document is meant to be broader in scope. 181 Hence, emulation of specific architectures, like the PSTN, or focus 182 on a specific application is out of scope. Further, the 183 specifications of requirements that are aimed at adhering to 184 regulations or laws of governments is also out of scope of this 185 document. The focus of the IETF and its working groups is technical 186 positions that follow the architecture of the Internet. 188 Another item that is not in scope of this document is mandating 189 acceptance and support of the requirements presented in this 190 document. There is an expectation that business contracts, (e.g., 191 Service Level Agreements) , will be used to satisfy those 192 requirements that apply to service providers. Absence of an SLA 193 implies best effort service is provided. 195 ^L 197 3. General Requirements 199 These are general requirements that apply to authorized emergency 200 telecommunications service. The first requirement is presented as a 201 conditional one since not all applications use or are reliant on 202 signaling. 204 1) Signaling 206 IF signaling is to be used to convey the state or existence of 207 emergency, then signaling mechanism(s) MUST exist to carry 208 applicable labels. 210 2) Labels 212 Labels may exist in various forms at different layers. They 213 might be carried as part of signaling, and/or as part of the 214 header of a data packet. Labels from different layers are NOT 215 required to be the same, but MAY be related to each other. 217 3) Policy 219 Policy MUST be kept separate from label(s). This topic has 220 generated a fair amount of debate, and so we provide additional 221 guidance from the following: 223 A set of labels may be defined as being related to each other. 224 Characteristics (e.g., drop precedence) may also be attributed 225 to these labels. [11] is an example of a related set of labels 226 based on a specific characteristic. 228 However, the mechanisms used to achieve a stated characteristic 229 MUST NOT be stated in the definition of a label. Local policy 230 determines mechanism(s) used to achieve or support a specific 231 characteristic. This allows for the possibility of different 232 mechanisms to achieve the same stated characteristic. 234 The interaction between unrelated labels MUST NOT be embedded 235 within the definition of a label. Local policy states the 236 actions (if any) to be taken if unrelated labeled traffic 237 merges at a node. 239 Finally, labels may have additional characteristics added to 240 them as a result of local policy. 242 4) Network Functionality 244 Functionality to support better than best effort SHOULD focus 246 ^L 247 on probability versus guarantees. Probability can be realized 248 in terms of reduced probability of packet loss, and/or minimal 249 jitter, and/or minimal end-to-end delay. There is NO 250 requirement that better than best effort functionality MUST 251 exist. There is NO requirement that if better-than-best effort 252 functionality exists then it must be ubuiquitous between end 253 users. 255 3.1 General Security Related Requirements 257 The following are security related requirements that emerge given the 258 requirements 1 through 4 above. 260 5) Authorization 262 Authorization is a method of validating that a user or some 263 traffic is allowed by policy to use a particular service 264 offering. 266 Mechanisms must be implemented so that only authorised users 267 have access to emergency telecommunications services. Any 268 mechanism for providing such authorization beyond closed 269 private networks SHOULD meet IETF Security Area criterion 270 (e.g. clear-text passwords would not generally be acceptable). 271 Authorization protects network resources from excessive use, 272 from abuse, and might also support billing and accounting for 273 the offered service. 275 Such authorization mechanisms SHOULD be flexible enough to 276 provide various levels of restriction and authorization depending 277 on the expectations of a particular service or customer. 279 6) Integrity & Authentication 281 In practice, authentication and integrity for IP based 282 communications are generally bound within a single mechanism, 283 even though conceptually they are different. Authentication 284 ensures that the user or traffic is who it claims to be. 285 Integrity offers assurance that unauthorised modifications 286 to objects can be detected. 288 Authorised emergency traffic needs to have reduced risk of 289 adverse impact from denial of service. This implies a need to 290 ensure integrity of the authorised emergency network traffic. 291 It should be noted, though, that mechanisms used to ensure 292 integrity can also be subjects to Denial of Service attacks. 294 Users of emergency network services SHOULD consider deploying 296 ^L 297 end-to-end integrity and authentication, rather than relying on 298 services that might be offered by any single provider of 299 emergency network services. Users SHOULD also carefully 300 consider which application-layer security services might be 301 appropriate to use. 303 7) Confidentiality 305 Some emergency communications might have a requirement that they 306 not be susceptible to interception or viewing by others, due to 307 the sensitive and urgent nature of emergency response activities. 308 An emergency telecommunications service MAY offer options to 309 provide confidentiality for certain authorised user traffic. 311 Consistent with other IETF standards and the Internet 312 Architecture, this document recommends that IEPREP users SHOULD 313 deploy end-to-end security mechanisms, rather than rely on 314 security services that might be offered by a single network 315 operator. IEPREP users SHOULD carefully consider security 316 alternatives (e.g. PGP, TLS, IPsec transport-mode) at different 317 layers (e.g. Application Layer, Session Layer, Transport Layer) 318 of the Internet Architecture before deployment. 320 4. Issues 322 This section presents issues that arise in considering solutions for 323 the requirements that have been defined for ETS. This section does 324 not specify solutions nor is it to be confused with requirements. 325 Subsequent documents that articulate a more specific set of 326 requirements for a particular service may make a statement about the 327 following issues. 329 1) Accounting 331 Accounting represents a method of tracking actual usage of a 332 service. We assume that the usage of any service better than 333 best effort will be tracked and subsequently billed to the user. 334 Accounting is not addressed as a general requirement for ETS. 335 However, solutions used to realize ETS should not preclude an 336 accounting mechanism. 338 2) Admission Control 340 The requirements of section 3 discuss labels and security. 341 Those developing solutions should understand that the 342 ability labels provide to distinguish emergency flows does 343 not create an ability to selectively admit flows. Admission 345 ^L 346 control as it is commonly understood in circuit-switched 347 networks is not present in IP-based networks, and schemes 348 which presume the ability to selectively admit flows when 349 resources are scarce will fail outside of very controlled 350 environments. In cases where emergency related flows occur 351 outside of controlled environments, the development of 352 technologies based on admission control is not recommended 353 as the foundation of emergency services. 355 3) Digital Signatures 357 Verification of digital signatures is computationally expensive. 358 If an operator acts upon a label and hence needs to verify the 359 authenticity of the label, then there is a potential denial-of- 360 service attack on the entity performing the authentication. 361 The DoS attack works by flooding the entity performing the 362 authentication with invalid (i.e. not authentic) labelled 363 information, causing the victim to spend excessive amounts of 364 computing resources on signature validation. Even though the 365 invalid information might get discarded after the signature 366 validation fails, the adversary has already forced the victim to 367 expend significant amounts of computing resource. Accordingly, 368 any system requiring such validation SHOULD define operational 369 and protocol measures to reduce the vulnerability to such a DoS 370 attack. 372 5. Related Work 374 RFC 3487 describes requirements for resource priority mechanisms for 375 the Session Initiation Protocol [8]. The requirements specified in 376 that RFC pertain to a specific application level protocol. In 377 contrast, the requirements of this document are a generalization that 378 are not application specific. From this blueprint (acting as a 379 guideline), more specific requirements may be described in future 380 documents. 382 6. Security Considerations 384 Security in terms of requirements is discussed sections 3.1 and 4. 386 7. References 388 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 389 9, RFC 2026, October 1996. 391 ^L 393 2 ANSI, "Signaling System No. 7(SS7) "High Probability of 394 Completion (HPC) Network Capability" , ANSI T1.631-1993 (R1999). 396 3 "Description of an International Emergency Preference 397 Scheme (IEPS)", ITU-T Recommendation E.106 March, 2000. 399 4 "Description for an International Emergency Multimedia Service", 400 ITU Draft Recommendation F.706, February, 2002. 402 5 "Call Priority Designation for H.323 Calls", ITU Recommendation 403 H.460.4, November, 2002. 405 6 ITU, "Multi-Level Precedence and Preemption Service, ITU, 406 Recomendation, I.255.3, July, 1990. 408 7 U.S. National Communications System: http://www.ncs.gov 410 8 Schulzrinne, H., "Requirements for Resource Priority Mechanisms 411 for the Session Initiation Protocol (SIP)", RFC 3487, Feb 2003 413 9 Carlberg, K., Atkinson, R., "IP Telephony Reqirements for 414 Emergency Telecommunications Service", Internet Draft, Work In 415 Progress, March 1, 2003 417 10 Tada, N., et. al., "IAA System (I Am Alive): The Experiences of 418 the Internet Disaster Drills", Proceedings of INET-2000, June. 420 11 Heinanen, J., et. al., "Assured Forwarding PHB Group", RFC 2597, 421 June 1999 423 12 Bradner, S., "Key words for use in RFCs to Indicate Requirement 424 Levels", RFC 2119, March 1997. 426 8. Author's Addresses 428 Ken Carlberg Ran Atkinson 429 University College London Extreme Networks 430 Department of Computer Science 3585 Monroe Street 431 Gower Street Santa Clara, CA 432 London, WC1E 6BT 95051 USA 433 United Kingdom 434 k.carlberg@cs.ucl.ac.uk rja@extremenetworks.com 436 Full Copyright Statement 438 "Copyright (C) The Internet Society (2003). All Rights Reserved. 440 ^L 441 This document and translations of it may be copied and furnished to 442 others, and derivative works that comment on or otherwise explain it 443 or assist in its implementation may be prepared, copied, published 444 and distributed, in whole or in part, without restriction of any 445 kind, provided that the above copyright notice and this paragraph are 446 included on all such copies and derivative works. However, this 447 document itself may not be modified in any way, such as by removing 448 the copyright notice or references to the Internet Society or other 449 Internet organizations, except as needed for the purpose of 450 developing Internet standards in which case the procedures for 451 copyrights defined in the Internet Standards process must be 452 followed, or as required to translate it into languages other than 453 English. 455 The limited permissions granted above are perpetual and will not be 456 revoked by the Internet Society or its successors or assigns. 458 This document and the information contained herein is provided as an 459 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 460 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 461 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 462 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR 463 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.