From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4375.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc4375.txt (limited to 'doc/rfc/rfc4375.txt') diff --git a/doc/rfc/rfc4375.txt b/doc/rfc/rfc4375.txt new file mode 100644 index 0000000..803b47a --- /dev/null +++ b/doc/rfc/rfc4375.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group K. Carlberg +Request for Comments: 4375 G11 +Category: Informational January 2006 + + + Emergency Telecommunications Services (ETS) Requirements + for a Single Administrative Domain + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document presents a list of requirements in support of Emergency + Telecommunications Service (ETS) within a single administrative + domain. This document focuses on a 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. + + + + + +Carlberg Informational [Page 1] + +RFC 4375 ETS Domain Requirements January 2006 + + + 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", + + + +Carlberg Informational [Page 2] + +RFC 4375 ETS Domain Requirements January 2006 + + + "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. + + Quality of Service (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 only considers 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 Scope + + Resources owned or operated by other administrative authorities are + outside the scope of this document. One example is a SIP server that + operates in other domains. Another example is an access link + 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. + + + + +Carlberg Informational [Page 3] + +RFC 4375 ETS Domain Requirements January 2006 + + + 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 information about security in the + single-domain context is found below 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, 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 [FRAME]. + +3.4. Users + + Regarding existing IETF-specified applications, augmentations in the + form of labeling mechanisms to support ETS MUST NOT adversely affect + its legacy usage by non-ETS users. With respect to future + applications, such labeling mechanisms SHOULD allow the application + to support a "normal" (non-emergency) condition. + + + + + + + + +Carlberg Informational [Page 4] + +RFC 4375 ETS Domain Requirements January 2006 + + +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.7. MIB + + Management Information Bases (MIBs) SHOULD be defined for mechanisms + specifically in place to support ETS. These MIBs MAY include objects + representing accounting, policy, and 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. + + + + + + + + + + +Carlberg Informational [Page 5] + +RFC 4375 ETS Domain Requirements January 2006 + + +4.2. Redundancy + + The issue of making networks fault tolerant is important and yet not + one that can be easily articulated in terms of 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 their 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 tend 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, the following: + + - Most current deployments of Simple Network Management Protocol + (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 document. + + + + + +Carlberg Informational [Page 6] + +RFC 4375 ETS Domain Requirements January 2006 + + +7. Informative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol + Label Switching Architecture", RFC 3031, January 2001. + + [RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for + Emergency Telecommunication Service (ETS)", RFC 3689, + February 2004. + + [FRAME] Carlberg, K., "A Framework for Supporting Emergency + Telecommunications Services (ETS) Within a Single + Administrative Domain", Work in Progress, December 2005. + +Author's Address + + Ken Carlberg + G11 + 123a Versailles Circle + Baltimore, MD + USA + + EMail: carlberg@g11.org.uk + + + + + + + + + + + + + + + + + + + + + + + + + + +Carlberg Informational [Page 7] + +RFC 4375 ETS Domain Requirements January 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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. + + 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. + +Intellectual Property + + The IETF 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 or 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 procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF 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-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Carlberg Informational [Page 8] + -- cgit v1.2.3