doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc3689.txt b/doc/rfc/rfc3689.txt
new file mode 100644
index 0000000..f56b8f9
--- /dev/null
+++ b/doc/rfc/rfc3689.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                        K. Carlberg
+Request for Comments: 3689                                           UCL
+Category: Informational                                      R. Atkinson
+                                                        Extreme Networks
+                                                           February 2004
+
+
+                        General Requirements for
+               Emergency Telecommunication Service (ETS)
+
+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 (2004).  All Rights Reserved.
+
+Abstract
+
+   This document presents a list of general requirements in support of
+   Emergency Telecommunications Service (ETS).  Solutions to these
+   requirements are not presented in this document.  Additional
+   requirements pertaining to specific applications, or types of
+   applications, are to be specified in separate document(s).
+
+1.  Introduction
+
+   Effective telecommunications capabilities can be imperative to
+   facilitate immediate recovery operations for serious disaster events,
+   such as, hurricanes, floods, earthquakes, and terrorist attacks.
+   Disasters can happen any time, any place, unexpectedly.  Quick
+   response for recovery operations requires immediate access to any
+   public telecommunications capabilities at hand.  These capabilities
+   include:  conventional telephone, cellular phones, and Internet
+   access via online terminals, IP telephones, and wireless PDAs.  The
+   commercial telecommunications infrastructure is rapidly evolving to
+   Internet-based technology.  Therefore, the Internet community needs
+   to consider how it can best support emergency management and recovery
+   operations.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119 [1].
+
+
+
+
+
+Carlberg, et al.             Informational                      [Page 1]
+
+RFC 3689                ETS General Requirements           February 2004
+
+
+1.1.  Terminology
+
+   Label:
+      The term label has been used for a number of years in various IETF
+      protocols.  It is simply an identifier.  It can be manifested in
+      the form of a numeric, alphanumeric value, or a specific bit
+      pattern, within a field of a packet header.  The exact form is
+      dependent on the protocol in which it is used.
+
+      An example of a label can be found in RFC 3031; the Multiprotocol
+      Label Switching Architecture.  Another example can be found in RFC
+      2597 (and updated by RFC 3260); a bit pattern for the Assured
+      Forwarding PHB group.  This latter case is a type of label that
+      does not involve routing.  Note that specification of labels is
+      outside the scope of this document.  Further comments on labels
+      are discussed below in section 3.
+
+1.2.  Existing Emergency Related Standards
+
+      The following are standards from other organizations that are
+      specifically aimed at supporting emergency communications.  Most
+      of these standards specify telephony mechanisms or define
+      telephony related labels.
+
+       Standard   / Organization
+      --------------------------
+      1) T1.631   /   ANSI
+      2) E.106    /   ITU
+      3) F.706    /   ITU
+      4) H.460.4  /   ITU
+      5) I.255.3  /   ITU
+
+   The first specifies an indicator for SS7 networks that signals the
+   need for a High Probability of Completion (HPC) service.  This
+   indicator is termed National Security / Emergency Preparedness
+   (NS/EP) The T1.631 standard [2] is the basis for the U.S. Government
+   Emergency Telecommunications Service (GETS) [7].
+
+   The second standard describes functional capabilities for the Public
+   Switched Telephone Network (PSTN) to support International Emergency
+   Preparedness System (IEPS) [3].  From the PSTN perspective, one can
+   view NS/EP as a standard with national boundaries, while IEPS is an
+   extension to international boundaries for telephony.
+
+   The third standard extends IEPS beyond the scope of telephony into
+   other forms that encompass multimedia [4].
+
+
+
+
+
+Carlberg, et al.             Informational                      [Page 2]
+
+RFC 3689                ETS General Requirements           February 2004
+
+
+   The fourth and fifth standard focuses on a multi-level labeling
+   mechanism distinguishing emergency type traffic from that which is
+   not.  The former case focuses on call signaling for H.323 networks
+   [5], while the latter has been applied for both SS7 [6] and data
+   networks.
+
+   While the above standards are outside the scope of the IETF, they do
+   represent existing efforts in the area of emergency communications,
+   as opposed to conceptual of potential possibilities.  They act as
+   example manifestations of Emergency Telecommunications Service (ETS).
+
+1.3.  Problem
+
+   One problem faced by the IEPREP working group entails how, and to
+   what degree, support for these standards are to be realized within
+   the Internet architecture and the existing suite of IETF standards
+   and associated working groups.  This support could be in the form of
+   interoperability with corresponding IETF protocols.
+
+   A subsequent problem is to ensure that requirements associated with
+   potential support is not focused just on IP telephony applications.
+   The I-Am-Alive (IAA) database system is an example of an ETS type
+   application used in Japan that supports both signaled and non-
+   signaled access by users [10].  It is a distributed database system
+   that provides registration, querying, and reply primitives to
+   participants during times of an emergency (e.g., an earthquake) so
+   that others can make an after-the-event determination about the
+   status of a person.  In this case, a separate signaling protocol like
+   SIP is not always required to establish or maintain a connection.
+
+   Given the case where signaling is optional, requirements and
+   subsequent solutions that address these problems must not assume the
+   existence of signaling and must be able to support applications that
+   only have labels in data packets.  These label(s) may be in various
+   places, such as the application or IP header.
+
+2.  Scope
+
+   This document defines a set of general system requirements to achieve
+   support for ETS and addressing the problem space presented in Section
+   1.3.  In defining these requirements, we consider known systems such
+   as GETS and IAA that represent existing manifestations of emergency
+   related systems.  These two examples also represent a broad spectrum
+   of characteristics that range from signaling & interactive non-
+   elastic applications to non-signaled & elastic applications.
+
+
+
+
+
+
+Carlberg, et al.             Informational                      [Page 3]
+
+RFC 3689                ETS General Requirements           February 2004
+
+
+   We stress that ETS, and its associated requirements, is not the only
+   means of supporting authorized emergency communications.  It is
+   simply an approach influenced by existing systems and standards.
+
+   Solutions to requirements are not defined.  This document does not
+   specify protocol enhancements or specifications.  Requirements for
+   specific types of applications that go beyond the general set stated
+   in section 3 are to be specified in other document(s).  At the
+   current writing of this document, [9] has been written for the case
+   of IP telephony.
+
+   The current IEPREP charter stipulates that any proposed solution to
+   support ETS that responds to the requirements of this document are to
+   be developed in other working groups.  We note that other specific
+   requirements (like that of IP telephony) may be defined as an
+   extension of the general requirements presented in section 3 below.
+
+2.1.  Out of Scope
+
+   While the problem space stated in section 1.3 includes standards
+   related to telephony, this document is meant to be broader in scope.
+   Hence, emulation of specific architectures, like the PSTN, or focus
+   on a specific application is out of scope.  Further, the
+   specifications of requirements that are aimed at adhering to
+   regulations or laws of governments is also out of the scope of this
+   document.  The focus of the IETF and its working groups is technical
+   positions that follow the architecture of the Internet.
+
+   Another item that is not in scope of this document is mandating
+   acceptance and support of the requirements presented in this
+   document.  There is an expectation that business contracts, (e.g.,
+   Service Level Agreements), will be used to satisfy those requirements
+   that apply to service providers.  Absence of an SLA implies best
+   effort service is provided.
+
+3.  General Requirements
+
+   These are general requirements that apply to authorized emergency
+   telecommunications service.  The first requirement is presented as a
+   conditional one since not all applications use or are reliant on
+   signaling.
+
+   1) Signaling
+
+      IF signaling is to be used to convey the state or existence of
+      emergency, then signaling mechanism(s) MUST exist to carry
+      applicable labels.
+
+
+
+
+Carlberg, et al.             Informational                      [Page 4]
+
+RFC 3689                ETS General Requirements           February 2004
+
+
+   2) Labels
+
+      Labels may exist in various forms at different layers.  They might
+      be carried as part of signaling, and/or as part of the header of a
+      data packet.  Labels from different layers are NOT required to be
+      the same, but MAY be related to each other.
+
+   3) Policy
+
+      Policy MUST be kept separate from label(s).  This topic has
+      generated a fair amount of debate, and so we provide additional
+      guidance from the following:
+
+      A set of labels may be defined as being related to each other.
+      Characteristics (e.g., drop precedence) may also be attributed to
+      these labels.  [11] is an example of a related set of labels based
+      on a specific characteristic.
+
+      However, the mechanisms used to achieve a stated characteristic
+      MUST NOT be stated in the definition of a label.  Local policy
+      determines mechanism(s) used to achieve or support a specific
+      characteristic.  This allows for the possibility of different
+      mechanisms to achieve the same stated characteristic.
+
+      The interaction between unrelated labels MUST NOT be embedded
+      within the definition of a label.  Local policy states the actions
+      (if any) to be taken if unrelated labeled traffic merges at a
+      node.
+
+      Finally, labels may have additional characteristics added to them
+      as a result of local policy.
+
+   4) Network Functionality
+
+      Functionality to support a better than best effort SHOULD focus on
+      probability versus guarantees.  Probability can be realized in
+      terms of reduced probability of packet loss, and/or minimal
+      jitter, and/or minimal end-to-end delay.  There is NO requirement
+      that a better than best effort functionality MUST exist.  There is
+      NO requirement that if a better than best effort functionality
+      exists then it must be ubiquitous between end users.
+
+3.1.  General Security Related Requirements
+
+   The following are security related requirements that emerge given the
+   requirements 1 through 4 above.
+
+
+
+
+
+Carlberg, et al.             Informational                      [Page 5]
+
+RFC 3689                ETS General Requirements           February 2004
+
+
+   5) Authorization
+
+      Authorization is a method of validating that a user or some
+      traffic is allowed by policy to use a particular service offering.
+
+      Mechanisms must be implemented so that only authorized users have
+      access to emergency telecommunications services.  Any mechanism
+      for providing such authorization beyond closed private networks
+      SHOULD meet IETF Security Area criterion (e.g., clear-text
+      passwords would not generally be acceptable).  Authorization
+      protects network resources from excessive use, from abuse, and
+      might also support billing and accounting for the offered service.
+
+      Such authorization mechanisms SHOULD be flexible enough to provide
+      various levels of restriction and authorization depending on the
+      expectations of a particular service or customer.
+
+   6) Integrity & Authentication
+
+      In practice, authentication and integrity for IP based
+      communications are generally bound within a single mechanism, even
+      though conceptually they are different.  Authentication ensures
+      that the user or traffic is who it claims to be.  Integrity offers
+      assurance that unauthorized modifications to objects can be
+      detected.
+
+      Authorized emergency traffic needs to have reduced risk of adverse
+      impact from denial of service.  This implies a need to ensure
+      integrity of the authorized emergency network traffic.  It should
+      be noted, though, that mechanisms used to ensure integrity can
+      also be subject to Denial of Service attacks.
+
+      Users of emergency network services SHOULD consider deploying
+      end-to-end integrity and authentication, rather than relying on
+      services that might be offered by any single provider of emergency
+      network services.  Users SHOULD also carefully consider which
+      application-layer security services might be appropriate to use.
+
+   7) Confidentiality
+
+      Some emergency communications might have a requirement that they
+      not be susceptible to interception or viewing by others, due to
+      the sensitive and urgent nature of emergency response activities.
+      An emergency telecommunications service MAY offer options to
+      provide confidentiality for certain authorized user traffic.
+
+
+
+
+
+
+Carlberg, et al.             Informational                      [Page 6]
+
+RFC 3689                ETS General Requirements           February 2004
+
+
+      Consistent with other IETF standards and the Internet
+      Architecture, this document recommends that IEPREP users SHOULD
+      deploy end-to-end security mechanisms, rather than rely on
+      security services that might be offered by a single network
+      operator.  IEPREP users SHOULD carefully consider security
+      alternatives (e.g., PGP, TLS, IPsec transport-mode) at different
+      layers (e.g., Application Layer, Session Layer, Transport Layer)
+      of the Internet Architecture before deployment.
+
+4.  Issues
+
+   This section presents issues that arise in considering solutions for
+   the requirements that have been defined for 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.
+
+   1) Accounting
+
+      Accounting represents a method of tracking actual usage of a
+      service.  We assume that the usage of any service better than best
+      effort will be tracked and subsequently billed to the user.
+      Accounting is not addressed as a general requirement for ETS.
+      However, solutions used to realize ETS should not preclude an
+      accounting mechanism.
+
+   2) Admission Control
+
+      The requirements of section 3 discuss labels and security.  Those
+      developing solutions should understand that the ability labels
+      provide to distinguish emergency flows does not create an ability
+      to selectively admit flows.  Admission control as it is commonly
+      understood in circuit-switched networks is not present in IP-based
+      networks, and schemes which presume the ability to selectively
+      admit flows when resources are scarce will fail outside of very
+      controlled environments.  In cases where emergency related flows
+      occur outside of controlled environments, the development of
+      technologies based on admission control is not recommended as the
+      foundation of emergency services.
+
+   3) Digital Signatures
+
+      Verification of digital signatures is computationally expensive.
+      If an operator acts upon a label and hence needs to verify the
+      authenticity of the label, then there is a potential denial-of-
+      service attack on the entity performing the authentication.  The
+      DoS attack works by flooding the entity performing the
+
+
+
+Carlberg, et al.             Informational                      [Page 7]
+
+RFC 3689                ETS General Requirements           February 2004
+
+
+      authentication with invalid (i.e., not authentic) labelled
+      information, causing the victim to spend excessive amounts of
+      computing resources on signature validation.  Even though the
+      invalid information might get discarded after the signature
+      validation fails, the adversary has already forced the victim to
+      expend significant amounts of computing resource.  Accordingly,
+      any system requiring such validation SHOULD define operational and
+      protocol measures to reduce the vulnerability to such a DoS
+      attack.
+
+5.  Related Work
+
+   RFC 3487 describes requirements for resource priority mechanisms for
+   the Session Initiation Protocol [8].  The requirements specified in
+   that RFC pertain to a specific application level protocol.  In
+   contrast, the requirements of this document are a generalization that
+   are not application specific.  From this blueprint (acting as a
+   guideline), more specific requirements may be described in future
+   documents.
+
+6.  Security Considerations
+
+   Security in terms of requirements is discussed sections 3.1 and 4.
+
+7.  References
+
+7.1.  Normative Reference
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+7.2.  Informative References
+
+   [2]  ANSI, "Signaling System No. 7(SS7) "High Probability of
+        Completion (HPC) Network Capability" , ANSI T1.631-1993 (R1999).
+
+   [3]  "Description of an International Emergency Preference Scheme
+        (IEPS)", ITU-T Recommendation  E.106 March, 2000.
+
+   [4]  "Description for an International Emergency Multimedia Service",
+        ITU Draft Recommendation F.706, February, 2002.
+
+   [5]  "Call Priority Designation for H.323 Calls", ITU Recommendation
+        H.460.4, November, 2002.
+
+   [6]  ITU, "Multi-Level Precedence and Preemption Service, ITU,
+        Recommendation, I.255.3, July, 1990.
+
+
+
+
+Carlberg, et al.             Informational                      [Page 8]
+
+RFC 3689                ETS General Requirements           February 2004
+
+
+   [7]  U.S. National Communications System: http://www.ncs.gov
+
+   [8]  Schulzrinne, H., "Requirements for Resource Priority Mechanisms
+        for the Session Initiation Protocol (SIP)", RFC 3487, February
+        2003.
+
+   [9]  Carlberg, K. and R. Atkinson, "IP Telephony Requirements for
+        Emergency Telecommunications Service", RFC 3690, February 2004.
+
+   [10] Tada, N., et. al., "IAA System (I Am Alive): The Experiences of
+        the Internet Disaster Drills", Proceedings of INET-2000, June.
+
+   [11] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured
+        Forwarding PHB Group", RFC 2597, June 1999.
+
+8.  Authors' Addresses
+
+   Ken Carlberg
+   University College London
+   Department of Computer Science
+   Gower Street
+   London, WC1E 6BT
+   United Kingdom
+
+   EMail: k.carlberg@cs.ucl.ac.uk
+
+
+   Ran Atkinson
+   Extreme Networks
+   3585 Monroe Street
+   Santa Clara, CA
+   95051  USA
+
+   EMail: rja@extremenetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carlberg, et al.             Informational                      [Page 9]
+
+RFC 3689                ETS General Requirements           February 2004
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carlberg, et al.             Informational                     [Page 10]
+