idnits 2.17.1 draft-carlberg-ets-general-01.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 9 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 170: '...aling mechanism(s) MUST exist to carry...' RFC 2119 keyword, line 182: '... Policy MUST be kept separate fr...' RFC 2119 keyword, line 192: '... MUST NOT be stated in the defin...' RFC 2119 keyword, line 198: '... unrelated labels MUST NOT be embedded...' RFC 2119 keyword, line 208: '...t better than best effort SHOULD focus...' (4 more instances...) 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.) -- 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? '2' on line 75 looks like a reference -- Missing reference section? '7' on line 76 looks like a reference -- Missing reference section? '3' on line 79 looks like a reference -- Missing reference section? '4' on line 85 looks like a reference -- Missing reference section? '5' on line 89 looks like a reference -- Missing reference section? '6' on line 90 looks like a reference -- Missing reference section? '10' on line 105 looks like a reference -- Missing reference section? '9' on line 130 looks like a reference -- Missing reference section? '11' on line 188 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 12 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 December, 2002 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 1. Introduction 42 Effective telecommunications capabilities can be imperative to 43 facilitate immediate recovery operations for serious disaster events, 44 such as, hurricanes, floods, earthquakes, and terrorist attacks. 45 Disasters can happen any time, any place, unexpectedly. Quick 46 response for recovery operations requires immediate access to any 47 public telecommunications capabilities at hand. These capabilities 49 ^L 50 include: conventional telephone, cellular phones, and Internet 51 access via online terminals, IP telephones, and wireless PDAs. The 52 commercial telecommunications infrastructure is rapidly evolving to 53 Internet-based technology. Therefore, the Internet community needs to 54 consider how it can best support emergency management and recovery 55 operations. 57 1.1 Existing Emergency Related Standards 59 The following are standards from other organizations that are 60 specifically aimed at supporting emergency communications. Most of 61 these standards specify telephony mechanisms or define telephony 62 related labels. 64 Standard / Organization 65 ------------------------ 66 T1.631 / ANSI 67 E.106 / ITU 68 F.706 / ITU 69 H.GEF.4 / ITU 70 I.255.3 / ITU 72 The first specifies an indicator for SS7 networks that signals the 73 need for a High Probability of Completion (HPC) service. This 74 indicator is termed National Security / Emergency Preparedness 75 (NS/EP) The T1.631 standard [2] is the basis for the U.S. Government 76 Emergency Telecomunications Service (GETS) [7]. 78 The second standard describes functional capabilities for the PSTN to 79 support International Emergency Preparedness System (IEPS) [3]. From 80 the PSTN perspective, one can view NS/EP as a standard with national 81 boundaries, while IEPS is extention to international boundaries for 82 telephony. 84 The third standard extends IEPS beyond the scope of telephony into 85 other forms that encompass multimedia [4]. 87 The fourth and fifth standard focuses on a multi-level labeling 88 mechanism distinguishing emergency type traffic from that which is 89 not. The former case focuses on H.323 networks [5], while the latter 90 is for SS7 networks [6]. 92 1.2 Problem 94 One problem faced by the IEPREP working group entails how, and to 95 what degree, support for these standards are to be realized within 96 the Internet architecture and the existing suite of IETF standards 98 ^L 99 and associated working groups. 101 A subsequent problem is to ensure that this support is not focused 102 just on IP telephony applications. The I-Am-Alive (IAA) database 103 system is an example of an emergency related application used in 104 Japan that supports both signaled and non-signaled access by 105 users[10]. Hence, requirements and subsequent solutions that address 106 these problems must not assume the existance of signaling and must be 107 able to support applications that only have labels in data packets. 108 These label(s) may be in various places, such as the application or 109 IP header. Further comments on labels are discussed below in section 110 3. 112 2. Scope 114 This document defines a set of general system requirements to achieve 115 support for ETS and addressing the problem space presented in Section 116 1.2. In defining these requirements, we consider known systems such 117 as GETS and IAA that represent existing manifestations of emergency 118 related systems. These two examples also represent a broad spectrum 119 of characteristics that range from signaling/interactive non-elastic 120 applications to non-signaled/elastic applications. 122 We stress that ETS, and its associated requirements, is not the only 123 means of supporting authorized emergency communications. It is 124 simply an approach influenced by by existing systems and standards. 126 Solutions to requirements are not defined. This document does not 127 specify protocol enhancements or specifications. Requirements for 128 specific types of applications that go beyond the general set stated 129 in section 3 are to be specified in other document(s). At the 130 current writing of this document, [9] has been written for the case 131 of IP telephony. 133 Below we present a structural relationship of documents for the 134 IEPREP working group. Specific solutions that are proposed in 135 response to the requirements are to be developed in other working 136 groups. We note that other specific requrements (like that of IP 137 telephony) may be defined as an extension of the general requirements 138 presented in section 3 below. 140 2.1 Out of Scope 142 While the problem space stated in section 1.2 includes standards 143 related to telephony, this document is meant to be broader in scope. 144 Hence, emulation of specific architectures, like the PSTN, or focus 145 on a specific application is out of scope. Further, the 146 specifications of requirements that are aimed at adhering to 148 ^L 149 regulations or laws of governments is also out of scope of this 150 document. The focus of the IETF and its working groups is technical 151 positions that follow the architecture of the Internet. 153 Another item that is not in scope of this document is mandating 154 acceptance and support of the requirements presented in this 155 document. There is an expectation that business contracts, (e.g., 156 Service Level Agreements) , will be used to satisfy those 157 requirements that apply to service providers. Absence of an SLA 158 implies best effort service is provided. 160 3. General Requirements 162 These are general requirements that apply to authorized emergency 163 telecommunications service. The first requirement is presented as a 164 conditional one since not all applications use or are reliant on 165 signaling. 167 1) Signaling 169 IF signaling is to be used to convey the state or existance of 170 emergency, then signaling mechanism(s) MUST exist to carry 171 applicable labels. 173 2) Labels 175 Labels may exist in various forms at different layers. They 176 might be carried as part of signaling, and/or as part of the 177 header of a data packet. Labels from different layers are NOT 178 required to be related to each other. 180 3) Policy 182 Policy MUST be kept separate from label(s). This topic has 183 generated a fair amount of debate, and so we provide additional 184 guidance from the following: 186 A set of labels may be defined as being related to each other. 187 Characteristics (e.g., drop precedence) may also be attributed 188 to these labels. [11] is an example of a related set of labels 189 based on a specific characteristic. 191 However, the mechanisms used to achieve a stated characteristic 192 MUST NOT be stated in the definition of a label. Local policy 193 determines mechanism(s) used to achieve or support a specific 194 characteristic. This allows for the possibility of different 195 mechanisms to achieve the same stated characteristic. 197 ^L 198 The relationship between unrelated labels MUST NOT be embedded 199 within the definition of a label. Local policy states the 200 actions (if any) to be taken if unrelated labeled traffic 201 merges at a node. 203 Finally, labels may have additional characteristics added to 204 them as a result of local policy. 206 4) Network Functionality 208 Functionality to support better than best effort SHOULD focus 209 on probability versus guarantees. Probability can be realized 210 in terms of reduced probability of packet loss, and/or minimal 211 jitter, and/or minimal end-to-end delay. There is NO 212 requirement that better than best effort functionality MUST 213 exist. There is NO requirement that if better-than-best effort 214 functionality exists then it must be ubuiquitous between end 215 users. 217 5) Authorisation 219 Authorisation is a method of validating that a user or some 220 traffic is authorized by policy to use a particular service 221 offering. 223 Mechanisms must be implemented so that only authorised users 224 have access to emergency telecommunications services. Any 225 mechanism for providing such authorisation beyond closed 226 private networks should be acceptable to the IETF Security Area 227 (e.g. clear-text passwords would not generally be acceptable). 228 Authorization protects network resources from excessive use, 229 from abuse, and might also support billing and accounting for 230 the offered service. 232 Such authorization mechanisms should be flexible enough to 233 provide various levels of restriction and authorization depending 234 on the expectations of a particular service or customer. 236 6) Integrity & Authentication 238 In practice, authentication and integrity for IP based 239 communications are generally bound within a single mechanism, 240 even though conceptually they are different. Authentication 241 ensures that the user or traffic is who it claims to be. 242 Integrity offers assurance that unauthorised modifications 243 to objects can be detected. 245 ^L 246 Authorised emergency traffic needs to have reduced risk of 247 adverse impact from denial of service. This implies a need to 248 ensure integrity of the authorised emergency network traffic. 249 Users of emergency network services SHOULD consider deploying 250 end-to-end integrity and authentication, rather than relying on 251 services that might be offered by any single provider of 252 emergency network services. Users should also carefully 253 consider which application-layer security services might be 254 appropriate to use. 256 7) Confidentiality 258 Some emergency communications might have a requirement that they 259 not be susceptible to interception or viewing by others, due to 260 the sensitive and urgent nature of emergency response activities. 261 An emergency telecommunications service MAY offer options to 262 provide confidentiality for certain authorised user traffic. 264 Consistent with other IETF standards and the Internet 265 Architecture, this document recommends that IEprep users deploy 266 end-to-end security mechanisms, rather than rely on security 267 services that might be offered by a single network operator. 268 IEPREP users should carefully consider security alternatives 269 (e.g. PGP, TLS, IPsec transport-mode) at different layers 270 (e.g. Application Layer, Session Layer, Transport Layer) of the 271 Internet Architecture before deployment. 273 4. Issues 275 This section presents issues that arise in considering solutions for 276 the requirements that have been defined for ETS. This section does 277 not specify solutions nor is it to be confused with requirements. 278 Subsequent documents that articulate a more specific set of 279 requirements for a particular service may make a statement about the 280 following issues. 282 1) Accounting 284 Accounting represents a method of tracking actual usage of a 285 service. We assume that the usage of any service better than 286 best effort will be tracked and subsequently billed to the user. 287 Accounting is not addressed as a general requirement for ETS. 288 However, solutions used to realize ETS should not preclude an 289 accounting mechanism. 291 2) Admission Control 293 ^L 294 The requirements of section 3 discuss labels and security. In 295 going beyond this, the ability to distinguish emergency flows 296 implies the need for admission control if resources become 297 scarce. Solutions must recognize this when trying to satisfy 298 the above requirements such that the simple presence of a label 299 does not imply admission control always exists along the 300 end-to-end path. 302 3) Digital Signatures 304 Verification of digital signatures is computationally expensive. 305 If an operator acts upon a label and hence needs to verify the 306 authenticity of the label, then there is a potential denial-of- 307 service attack on the entity performing the authentication. 308 The DoS attack works by flooding the entity performing the 309 authentication with invalid (i.e. not authentic) labelled 310 information, causing the victim to spend excessive amounts of 311 computing resources on signature validation. Even though the 312 invalid information might get discarded after the signature 313 validation fails, the adversary has already forced the victim to 314 expend significant amounts of computing resource. Accordingly, 315 any system requiring such validation SHOULD define operational 316 and protocol measures to reduce the vulnerability to such a DoS 317 attack. 319 5. Security 321 Security in terms of requirements is discussed section 3 and 4. 323 6. References 325 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 326 9, RFC 2026, October 1996. 328 2 ANSI, "Signaling System No. 7(SS7) "High Probability of 329 Completion (HPC) Network Capability" , ANSI T1.631, 1993. 331 3 "Description of an International Emergency Preference 332 Scheme (IEPS)", ITU-T Recommendation E.106 March, 2002 334 4 "Description for an International Emergency Multimedia Service", 335 ITU Draft Recommendation F.706, February, 2002 337 5 "Service Class Designations for H.323 Calls", ITU Draft 338 Recommendation H.GEF.4, September, 2001 340 ^L 342 6 ITU, "Multi-Level Precedence and Preemption Service, ITU, 343 Recomendation, I.255.3, July, 1990. 345 7 U.S. National Communications System: http://www.ncs.gov 347 8 U.K Office of Telecommunications (Oftel): http://www.oftel.gov.uk/ 349 9 Carlberg, K., Atkinson, R., "General Requirements for Emergency 350 Telecommunications Service", Internet Draft, Work In Progress, 351 September, 2002 353 10 Tada, N., et. al., "IAA System (I Am Alive): The Experiences of 354 the Internet Disaster Drills", Proceedings of INET-2000, June. 356 11 Heinanen, J., et. al., "Assured Forwarding PHB Group", RFC 2597, 357 June 1999 359 7. Author's Addresses 361 Ken Carlberg Ran Atkinson 362 University College London Extreme Networks 363 Department of Computer Science 3585 Monroe Street 364 Gower Street Santa Clara, CA 365 London, WC1E 6BT 95051 USA 366 United Kingdom 367 k.carlberg@cs.ucl.ac.uk rja@extremenetworks.com 369 Full Copyright Statement 371 "Copyright (C) The Internet Society (date). All Rights Reserved. 372 This document and translations of it may be copied and furnished to 373 others, and derivative works that comment on or otherwise explain it 374 or assist in its implementation may be prepared, copied, published 375 and distributed, in whole or in part, without restriction of any 376 kind, provided that the above copyright notice and this paragraph are 377 included on all such copies and derivative works. However, this 378 document itself may not be modified in any way, such as by removing 379 the copyright notice or references to the Internet Society or other 380 Internet organizations, except as needed for the purpose of 381 developing Internet standards in which case the procedures for 382 copyrights defined in the Internet Standards process must be 383 followed, or as required to translate it into languages other than 384 English. 386 The limited permissions granted above are perpetual and will not be 387 revoked by the Internet Society or its successors or assigns. 389 This document and the information contained herein is provided as an 391 ^L 392 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 393 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 394 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 395 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR 396 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.