Internet Engineering Task Force Ken Carlberg
Feb 4,Sep 12, 2005 Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain <draft-ietf-ieprep-domain-req-04.txt><draft-ietf-ieprep-domain-req-05.txt> Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667.By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomebecomes aware will be disclosed, in accordance with RFC 3668.Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document is an extension of the General Requirements of [rfc3689] and focuses on a more specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. 1. Introduction The objective of this document is to define a set of requirements that support ETS within a single domain. There have been a number of discussions in the IEPREP mailing list, as well as working group meetings, that have questioned the utility of a given mechanism to support ETS. Many have advocated over-provisioning, while others have favored specific schemas to provide a quantifiable measure of service. One constant in these discussions is that the administrative control of the resources plays a significant role in the effectiveness of any proposed solution. Specifically, if one administers a set of resources, a wide variety of approaches can be deployed upon that set. However, once the approach crosses an administrative boundary, its effectiveness comes into question, and at a minimum requires cooperation and trust from other administrative domains. To avoid this question, we constrain our scenario to the resources within a single domain. The following provides an explanation of some key terms used in this document. Resource: A resource can be a viewed from the general level as IP nodes such as a router or host as well as the physical media (e.g., fiber) used to connect them. A host can also be referred to in more specific terms as a client, server, or proxy. Resources can also be viewed more specifically in terms of the elements within a node (e.g., CPU, buffer, memory). However, this document shall focus its attention at the node level. Domain: This term has been used in many ways. We constrain its usage in this document to the perspective of the network layer, and view it as being synonymous with an administrative domain. A domain may span large geographic regions and may consist of many types of physical subnetworks. Administrative Domain: The collection of resources under the control of a single administrative authority. This authority establishes the design and operation of a set of resources (i.e., the network). Transit Domain: This is an administrative domain used to forward traffic from one domain to another. An Internet Service Provider (ISP) is an example of a transit domain. Stub Domain: This is an administrative domain that is either the source or the destination of a flow of IP packets. As a general rule, it does not forward traffic that is destined for other domains. The odd exception to this statement is the case of Mobile IP and its use of "dog-leg" routing to visiting hosts located in foreign networks. An enterprise network is an example of a stub domain. 1.1 Previous Work A list of General Requirements for support of ETS is presented in .[rfc3689]. The document articulates requirements when considering the broad case of supporting ETS over the Internet. Since that document is not constrained to specific applications, administrative boundaries, or scenarios, the requirements contained within it tend to be quite general in their description and scope. This follows the philosophy behind its inception in that the General Requirements are meant to be a baseline followed (if necessary) by more specific requirements that pertain to a more narrow scope. The requirements presented below in Section 3 are representative of the more narrow scope of a single administrative domain. As in the case of [rfc3689], the requirements articulated in this document represent aspects to be taken into consideration when solutions are being designed, specified, and deployed. Key words such as "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [rfc2119]. 2. Scope IETF standards that cover the resources within an administrative domain are within the scope of this document. This includes gateways, routers, servers, etc., that are located and administered within the domain. This document also does not restrict itself to a specific type of application such as Voice over IP. QoS mechanisms are also within the scope of this document. These mechanisms may reside at the application, transport, or IP network layer. While QoS mechanisms may exist at the link/physical layer, this document would only consider potential mappings of labels or code points. Finally, since this document focuses on a single administrative domain, we do not make any further distinction between transit and stub domains within this document. 2.1 Out of ScopeScope: Resources owned or operated by other administrative authorities are outside the scope of this document. One example are SIP servers that operate in other domains. Another example are access links connecting the stub domain and its provider. Controlling only 1/2 of a link (the egress traffic from the stub) is considered insufficient for including inter-domain access links as a subject for this document. 3. Requirements It must be understood that all of the following requirements pertain to mechanisms chosen by a domain's administrative authority to specifically support ETS. If that authority chooses not to support ETS or if these mechanisms exist within the domain exclusively for a different purpose, then the associated requirement does not apply. 3.1 Label Mechanisms Application or transport layer label mechanisms used for ETS MUST be extensible such that they can support more than one label. These mechanism MUST avoid a single off/on type of label (e.g., a single bit). In addition, designers of such a mechanism MUST assume that there may be more than one set of ETS users. Network layer label mechanisms used for ETS SHOULD be extensible such that they can support more than one label. We make this distinction in requirements because there may be fewer bits (a smaller field) available at the network layer than in the transport or application layer. 3.2 Proxies Proxies MAY set ETS labels on behalf of the source of a flow. This may involve removing labels that have been set by upstream node(s). If proxies take such action, then the security measures discussed in [rfc3689] MUST be considered. More discussion about security in the single domain context is discussed in section 5. 3.3 QoS mechanisms [rfc3689] defines a label as an identifier, and the set of characteristics associated with the label as policy. However, Quality of Service (QoS) in the traditional sense of delay or bandwidth is not automatically bound to a label. MPLS [rfc3031] is an example of a labeling mechanism that can provide specific QoS or simply traffic engineering of labeled flows. In the context of ETS, QoS mechanisms, at either the network or application layer, SHOULD be used when networks cannot be over- provisioned to satisfy high bursts of traffic load. Examples can involve bridging fiber networks to wireless subnetworks, or remote subnetworks connected over expensive bandwidth constrained wide area links. Note well. Over-provisioning is a normal cost-effective practice amongst network administrators/engineers. The amount of over- provisioning can be a topic of debate. More in-depth discussion on this topic is presented in the companion Framework document of [frame]. 3.4 Users Any application layer label mechanisms used to support ETS MUST be capable of supporting both the set of ETS and non-ETS (presumably, normal) users. 3.5 Policy Policy MUST be used to determine the percentage of resources of a mechanism used to support the various (ETS and non-ETS) users. Under certain conditions, this percentage MAY reach 100% for a specific set of users. However, we recommend that this "all-or-nothing" approach be considered with great care. 3.6 Discovery There should be a means of forwarding ETS labeled flows to those mechanisms within the domain used to support ETS. Discovery mechanisms SHOULD be used to determine where ETS labeled flows (either data or control) are to be forwarded. 3.8 MIB Management Information Bases (MIBs) SHOULD be defined for mechanisms specifically in place to support ETS. These MIBs MAY include objects representing accounting, policy, authorization. 4. Issues This section presents issues that arise in considering solutions for the requirements that have been defined for Stub Domains that support ETS. This section does not specify solutions nor is it to be confused with requirements. Subsequent documents that articulate a more specific set of requirements for a particular service may make a statement about the following issues. 4.1 Alternative Services The form of the service provided to ETS users and articulated in the form of policies may be realized in one of several forms. Better than best effort is probably the service that most ETS users would expect when the communication system is stressed and overall quality has degraded. However, the concept of best available service should also be considered under such stressed conditions. Further, a measure of degraded service may also be desirable to ensure a measure of communication versus none. These services may be made available at the network or application layer. 4.2 Redundancy The issue of making networknetworks fault tolerant is important and yet not one that can be easily articulated in terms of requirements.requirements of protocols. Redundancy in connectivity and nodes (be it routers or servers) is probably the most common approach taken by network administrators, and it can be assumed that administrative domains apply this approach in various degrees to there own resources. 5. Security Considerations This document recommends that readers review and follow the comments and requirements about security presented in [rfc3689]. Having said that, there tends to be many instances where intra-domain security is held at a lower standard (i.e., less stringent) that inter-domain security. For example, while administrators may allow telnet service between resources within an administrative domain, they would only allow SSH access from other domains. The disparity in security policy can be problematic when domains offer services other than best effort for ETS users. Therefore, any support within a domain for ETS should be accompanied by a detailed security policy for users and administrators. Given the "SHOULD" statement in section 3.8 concerning MIBs, there are a number of related security considerations that need to be brought to attention to the reader. Specifically, - Most current deployments of SNMP are of versions prior to SNMPv3, even though there are well-known security vulnerabilities in those versions of SNMP. - SNMP versions prior to SNMPv3 cannot support cryptographic security mechanisms. Hence, any use of SNMP prior to version 3 to write or modify MIB objects do so in a non-secure manner. As a result, it may be best to constrain the use of these objects to read-only by MIB managers. - Finally, any MIB defining writable objects should carefully consider the security implications of an SNMP compromise on the mechanism(s) being controlled by those writable MIB objects. 6. Acknowledgements Thanks to Ran Atkinson, James Polk, Scott Bradner, Jon Peterson, and Ian Brown for comments on previous versions of this draft. 7. References 7.1 Normative Reference [rfc3668] Bradner, S., "Intellectual Property Rights in IETF technology", BCP 79, RFC 3668, February 2004 7.2 Informative References [rfc3689] Carlberg, K., Atkinson, R., "General Requirements for Emergency Telecommunications Service", RFC3689 Feb 2004[rfc2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [rfc3031] Rosen, E., et. al., "Multiprotocol Label Switching Architecture", RFC3031, January 2001 [rfc3689] Carlberg, K., Atkinson, R., "General Requirements for Emergency Telecommunications Service", RFC3689 Feb 2004 [frame] Carlberg, K., "A Framework for Supporting ETS in Stub Domains", Internet Draft, Work in Progress, draft-ieprep-domain-frame-02.txt, June 2003. 8. Author's Addresses Ken Carlberg G11 123a Versailles Circle Baltimore, MD USA email@example.com Full CopyrightIntellectual Property Statement Copyright (C)The Internet Society (2004). ThisIETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document is subjector the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the rights, licenses and restrictions containedprocedures with respect to rights in RFC documents can be found in BCP 78,78 and except as set forth therein,BCP 79. Copies of IPR disclosures made to the authors retain all their rights. DisclamerIETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- firstname.lastname@example.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.