summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3788.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3788.txt')
-rw-r--r--doc/rfc/rfc3788.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc3788.txt b/doc/rfc/rfc3788.txt
new file mode 100644
index 0000000..97a008c
--- /dev/null
+++ b/doc/rfc/rfc3788.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group J. Loughney
+Request for Comments: 3788 Nokia Research Center
+Category: Standards Track M. Tuexen, Ed.
+ Univ. of Applied Sciences Muenster
+ J. Pastor-Balbas
+ Ericsson Espana S.A.
+ June 2004
+
+
+ Security Considerations for
+ Signaling Transport (SIGTRAN) Protocols
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This document discusses how Transport Layer Security (TLS) and IPsec
+ can be used to secure communication for SIGTRAN protocols. The main
+ goal is to recommend the minimum security means that a SIGTRAN node
+ must implement in order to attain secured communication. The support
+ of IPsec is mandatory for all nodes running SIGTRAN protocols. TLS
+ support is optional.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al. Standards Track [Page 1]
+
+RFC 3788 SIGTRAN Security June 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Convention . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Security in Telephony Networks . . . . . . . . . . . . . . . . 4
+ 4. Threats and Goals . . . . . . . . . . . . . . . . . . . . . . 4
+ 5. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 6. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 7. Support of IPsec and TLS . . . . . . . . . . . . . . . . . . . 8
+ 8. Peer-to-Peer Considerations . . . . . . . . . . . . . . . . . 9
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
+ 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . 11
+ 12.2. Informative References . . . . . . . . . . . . . . . . . 11
+ 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
+ 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
+
+1. Introduction
+
+1.1. Overview
+
+ The SIGTRAN protocols are designed to carry signaling messages for
+ telephony services. These protocols will be used between
+
+ o customer premise and service provider equipment in case of ISDN
+ Q.921 User Adaptation Layer (IUA) [9].
+
+ o service provider equipment only. This is the case for SS7 MTP2
+ User Adaptation Layer (M2UA) [12], SS7 MTP2 Peer-to-Peer User
+ Adaptation Layer (M2PA) [15], SS7 MTP3 User Adaptation Layer
+ (M3UA) [13] and SS7 SCCP User Adaptation Layer (SUA) [16]. The
+ carriers may be different and may use other transport network
+ providers.
+
+ The security requirements for these situations may be different.
+
+ SIGTRAN protocols involve the security needs of several parties, the
+ end-users of the services, the service providers and the applications
+ involved. Additional security requirements may come from local
+ regulation. While having some overlapping security needs, any
+ security solution should fulfill all of the different parties' needs.
+
+ The SIGTRAN protocols assume that messages are secured by using
+ either IPsec or TLS.
+
+
+
+Loughney, et al. Standards Track [Page 2]
+
+RFC 3788 SIGTRAN Security June 2004
+
+
+1.2. Abbreviations
+
+ This document uses the following abbreviations:
+
+ ASP: Application Server Process
+
+ CA: Certification Authority
+
+ DOI: Domain Of Interpretation
+
+ ESP: Encapsulating Security Payload
+
+ FQDN: Full-Qualified Domain Names
+
+ IPsec: IP Security Protocol
+
+ IKE: Internet Key Exchange Protocol
+
+ ISDN: Integrated Services Digital Network
+
+ IUA: ISDN Q.921 User Adaptation Layer
+
+ M2PA: SS7 MTP2 Peer-to-Peer User Adaptation Layer
+
+ M2UA: SS7 MTP2 User Adaptation Layer
+
+ M3UA: SS7 MTP3 User Adaptation Layer
+
+ PKI: Public Key Infrastructure
+
+ SA: Security Association
+
+ SCTP: Stream Control Transmission Protocol
+
+ SS7: Signaling System No. 7
+
+ SUA: SS7 SCCP User Adaptation Layer
+
+ TLS: Transport Layer Security
+
+2. Convention
+
+ The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+ SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
+ they appear in this document, are to be interpreted as described in
+ [1].
+
+
+
+
+
+Loughney, et al. Standards Track [Page 3]
+
+RFC 3788 SIGTRAN Security June 2004
+
+
+3. Security in Telephony Networks
+
+ The security in telephony networks is mainly based on the closed
+ network principle. There are two main protocols used: Access
+ protocols (ISDN and others) are used for signaling in the access
+ network and the SS7 protocol stack in the core network.
+
+ As SS7 networks are often physically remote and/or inaccessible to
+ the user, it is assumed that they are protected from malicious users.
+ Equipment is often under lock and key. At network boundaries between
+ SS7 networks, packet filtering is sometimes used. End-users are not
+ directly connected to SS7 networks.
+
+ The access protocols are used for end-user signaling. End-user
+ signaling protocols are translated to SS7 based protocols by
+ telephone switches run by network operators.
+
+ Regulatory Authorities often require SS7 switches with connections to
+ different SS7 switches to be conformant to national and/or
+ international test specifications.
+
+ There are no standardized ways of using encryption technologies for
+ providing confidentiality or using technologies for authentication.
+
+ This description applies to telephony networks operated by a single
+ operator, and also to multiple telephony networks being connected and
+ operated by different operators.
+
+4. Threats and Goals
+
+ The Internet threats can be divided into one of two main types. The
+ first one is called "passive attacks". It happens whenever the
+ attacker reads packets off the network but does not write them.
+ Examples of such attacks include confidentiality violations, password
+ sniffing and offline cryptographic attacks amongst others.
+
+ The second kind of threat is called "active attacks". In this case,
+ the attacker also writes data to the network. Examples for this
+ attack include replay attacks, message insertion, message deletion,
+ message modification or man-in-the-middle attacks, amongst others.
+
+ In general, Internet protocols have the following security
+ objectives:
+
+
+
+
+
+
+
+
+Loughney, et al. Standards Track [Page 4]
+
+RFC 3788 SIGTRAN Security June 2004
+
+
+ o Communication Security:
+
+ * Authentication of peers
+
+ * Integrity of user data transport
+
+ * Confidentiality of user data
+
+ * Replay protection
+
+ o Non-repudiation
+
+ o System Security, avoidance of:
+
+ * Unauthorized use
+
+ * Inappropriate use
+
+ * Denial of Service
+
+ Communication security is mandatory in some network scenarios to
+ prevent malicious attacks. The main goal of this document is to
+ recommend the minimum security means that a SIGTRAN node must
+ implement in order to attain secured communication. To achieve this
+ goal, we will explore the different existing security options
+ regarding communication.
+
+ All SIGTRAN protocols use the Stream Control Transmission Protocol
+ (SCTP) defined in [8] and [11] as its transport protocol. SCTP
+ provides certain transport related security features, such as
+ resistance against:
+
+ o Blind Denial of Service Attacks such as:
+
+ * Flooding.
+
+ * Masquerade.
+
+ * Improper Monopolization of Services.
+
+ There is no quick fix, one-size-fits-all solution for security.
+
+ When a network using SIGTRAN protocols involves more than one party,
+ it may not be reasonable to expect that all parties have implemented
+ security in a sufficient manner. End-to-end security should be the
+ goal; therefore, it is recommended that IPsec or TLS be used to
+ ensure confidentiality of user payload. Consult [3] for more
+ information on configuring IPsec services.
+
+
+
+Loughney, et al. Standards Track [Page 5]
+
+RFC 3788 SIGTRAN Security June 2004
+
+
+5. IPsec Usage
+
+ This section is only relevant for SIGTRAN nodes using IPsec to secure
+ communication between SIGTRAN nodes.
+
+ All SIGTRAN nodes using IPsec MUST implement IPsec ESP [4] in
+ transport mode with non-null encryption and authentication algorithms
+ to provide per-packet authentication, integrity protection and
+ confidentiality, and MUST implement the replay protection mechanisms
+ of IPsec. In those scenarios where IP layer protection is needed,
+ ESP in tunnel mode SHOULD be used. Non-null encryption should be
+ used when using IPSec ESP.
+
+ All SIGTRAN nodes MUST support IKE for peer authentication,
+ negotiation of security associations, and key management, using the
+ IPsec DOI [5]. The IPsec implementations MUST support peer
+ authentication using a pre-shared key, and MAY support certificate-
+ based peer authentication using digital signatures. Peer
+ authentication using the public key encryption methods outlined in
+ IKE's sections 5.2 and 5.3 [6] SHOULD NOT be used.
+
+ Conformant implementations MUST support IKEs Main Mode and Aggressive
+ Mode. For transport mode, when pre-shared keys are used for
+ authentication, IKE Aggressive Mode SHOULD be used, and IKE Main Mode
+ SHOULD NOT be used. When digital signatures are used for
+ authentication, either IKE Main Mode or IKE Aggressive Mode MAY be
+ used. When using ESP tunnel mode, IKE Main Mode MAY be used to
+ create an ISAKMP association with identity protection during Phase 1.
+
+ When digital signatures are used to achieve authentication, an IKE
+ negotiator SHOULD use IKE Certificate Request Payload(s) to specify
+ the certification authority (or authorities) that is trusted in
+ accordance with its local policy. IKE negotiators SHOULD use
+ pertinent certificate revocation checks before accepting a PKI
+ certificate for use in IKE's authentication procedures. See [10] for
+ certificate revocation and [7] for online-checking.
+
+ The Phase 2 Quick Mode exchanges used to negotiate protection for
+ SIGTRAN sessions MUST explicitly carry the Identity Payload fields
+ (IDci and IDcr). The DOI provides for several types of
+ identification data. However, when used in conformant
+ implementations, each ID Payload MUST carry a single IP address and a
+ single non-zero port number, and MUST NOT use the IP Subnet or IP
+ Address Range formats. This allows the Phase 2 security association
+ to correspond to specific TCP and SCTP connections.
+
+
+
+
+
+
+Loughney, et al. Standards Track [Page 6]
+
+RFC 3788 SIGTRAN Security June 2004
+
+
+ Since IPsec acceleration hardware may only be able to handle a
+ limited number of active IKE Phase 2 SAs, Phase 2 delete messages may
+ be sent for idle SAs as a means of keeping the number of active Phase
+ 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message
+ SHOULD NOT be interpreted as a reason for tearing down a SIGTRAN
+ session. Rather, it is preferable to leave the connection up,
+ whereby another IKE Phase 2 SA will be brought up to protect it if
+ additional traffic is sent. This avoids the potential of continually
+ bringing connections up and down.
+
+ It should be noted that SCTP supports multi-homed hosts and this
+ results in the need for having multiple security associations for one
+ SCTP association. This disadvantage of IPsec has been addressed by
+ [17]. So IPsec implementations used by SIGTRAN nodes SHOULD support
+ the IPsec feature described in [17].
+
+6. TLS Usage
+
+ This section is only relevant for SIGTRAN nodes using TLS to secure
+ the communication between SIGTRAN nodes.
+
+ A SIGTRAN node that initiates a SCTP association to another SIGTRAN
+ node acts as a TLS client according to [2], and a SIGTRAN node that
+ accepts a connection acts as a TLS server. SIGTRAN peers
+ implementing TLS for security MUST mutually authenticate as part of
+ TLS session establishment. In order to ensure mutual authentication,
+ the SIGTRAN node acting as TLS server must request a certificate from
+ the SIGTRAN node acting as TLS client, and the SIGTRAN node acting as
+ TLS client MUST be prepared to supply a certificate on request.
+
+ [14] requires the support of the cipher suite
+ TLS_RSA_WITH_AES_128_CBC_SHA. SIGTRAN nodes MAY negotiate other TLS
+ cipher suites.
+
+ TLS MUST be used on all bi-directional streams. Other uni-
+ directional streams MUST NOT be used.
+
+ It should also be noted that a SCTP implementation used for TLS over
+ SCTP MUST support fragmentation of user data and might also need to
+ support the partial delivery API. This holds even if all SIGTRAN
+ messages are small. Furthermore, the 'unordered delivery' feature of
+ SCTP can not be used in conjunction with TLS. See [14] for more
+ details.
+
+ Because TLS only protects the payload, the SCTP header and all
+ control chunks are not protected. This can be used for DoS attacks.
+ This is a general problem with security provided at the transport
+ layer.
+
+
+
+Loughney, et al. Standards Track [Page 7]
+
+RFC 3788 SIGTRAN Security June 2004
+
+
+ The SIGTRAN protocols use the same SCTP port number and payload
+ protocol identifier when run over TLS. A session upgrade procedure
+ has to be used to initiate the TLS based communication.
+
+ The session upgrade procedure should be as follows:
+
+ o If an ASP has been configured to use TLS, it sends a STARTTLS
+ message on stream 0 and starts a timer T_TLS. This is the first
+ message sent and the ASP sends no other adaptation layer messages
+ until the TLS based communication has been established.
+
+ o If the peer does not support TLS, it sends back an ERROR message
+ indicating an unsupported message type. In this case, the SCTP
+ association is terminated and it is reported to the management
+ layer that the peer does not support TLS.
+
+ o If the peer does support TLS, it sends back a STARTTLS_ACK
+ message. The client then starts TLS based communication.
+
+ o If T_TLS expires without getting any of the above answers, the
+ association is terminated and the failure is reported to the
+ management layer.
+
+ All SIGTRAN adaptation layers share a common message format. The
+ STARTTLS message consists of a common header only using the message
+ class 10 and message type 1. The STARTTLS_ACK message uses the same
+ message class 10 and the message type 2. Neither messages contain
+ any parameters.
+
+ Using this procedure, it is possible for a man-in-the-middle to do a
+ denial of service attack by indicating that the peer does not support
+ TLS. But this kind of attack is always possible for a man-in-the-
+ middle.
+
+7. Support of IPsec and TLS
+
+ If content of SIGTRAN protocol messages is to be protected, either
+ IPsec ESP or TLS can be used. In both IPsec ESP Transport Mode and
+ TLS cases, the IP header information is neither encrypted nor
+ protected. If IPsec ESP is chosen, the SCTP control information is
+ encrypted and protected whereas in the TLS based solution, the SCTP
+ control information is not encrypted and only protected by SCTP
+ procedures.
+
+ In general, both IPsec and TLS have enough mechanisms to secure the
+ SIGTRAN communications.
+
+
+
+
+
+Loughney, et al. Standards Track [Page 8]
+
+RFC 3788 SIGTRAN Security June 2004
+
+
+ Therefore, in order to have a secured model working as soon as
+ possible, the following recommendation is made: A SIGTRAN node MUST
+ support IPsec and MAY support TLS.
+
+8. Peer-to-Peer Considerations
+
+ M2PA, M3UA and SUA support the peer-to-peer model as a generalization
+ to the client-server model which is supported by IUA and M2UA. A
+ SIGTRAN node running M2PA, M3UA or SUA and operating in the peer-to-
+ peer mode is called a SIGTRAN peer.
+
+ As with any peer-to-peer protocol, proper configuration of the trust
+ model within a peer is essential to security. When certificates are
+ used, it is necessary to configure the trust anchors trusted by the
+ peer. These trust anchors are likely to be unique to SIGTRAN usage
+ and distinct from the trust anchors that might be trusted for other
+ purposes such as Web browsing. In general, it is expected that those
+ trust anchors will be configured so as to reflect the business
+ relationships between the organization hosting the peer and other
+ organizations. As a result, a peer will not typically be configured
+ to allow connectivity with any arbitrary peer. When certificate
+ authentication peers may not be known beforehand, peer discovery may
+ be required.
+
+ Note that IPsec is considerably less flexible than TLS when it comes
+ to configuring trust anchors. Since use of Port identifiers is
+ prohibited within IKE Phase 1, it is not possible to uniquely
+ configure trusted trust anchors for each application individually
+ within IPsec; the same policy must be used for all applications.
+ This implies, for example, that a trust anchor trusted for use with a
+ SIGTRAN protocol must also be trusted to protect other protocols (for
+ example SNMP). These restrictions are awkward at best.
+
+ When pre-shared key authentication is used with IPsec to protect
+ SIGTRAN based communication, unique pre-shared keys are configured
+ with peers that are identified by their IP address (Main Mode), or
+ possibly their FQDN (AggressivenMode). As a result, it is necessary
+ for the set of peers to be known beforehand. Therefore, peer
+ discovery is typically not necessary.
+
+ The following is intended to provide some guidance on the issue.
+
+ It is recommended that SIGTRAN peers use the same security mechanism
+ (IPsec or TLS) across all its sessions with other SIGTRAN peers.
+ Inconsistent use of security mechanisms can result in redundant
+ security mechanisms being used (e.g., TLS over IPsec) or worse,
+ potential security vulnerabilities. When IPsec is used with a
+ SIGTRAN protocol, a typical security policy for outbound traffic is
+
+
+
+Loughney, et al. Standards Track [Page 9]
+
+RFC 3788 SIGTRAN Security June 2004
+
+
+ "Initiate IPsec, from me to any, destination port P"; for inbound
+ traffic, the policy would be "Require IPsec, from any to me,
+ destination port P". Here, P denotes one of the registered port
+ numbers for a SIGTRAN protocol.
+
+ This policy causes IPsec to be used whenever a SIGTRAN peer initiates
+ a session to another SIGTRAN peer, and to be required whenever an
+ inbound SIGTRAN session occurs. This policy is attractive, since it
+ does not require policy to be set for each peer or dynamically
+ modified each time a new SIGTRAN session is created; an IPsec SA is
+ automatically created based on a simple static policy. Since IPsec
+ extensions are typically not available to the sockets API on most
+ platforms, and IPsec policy functionality is implementation
+ dependent, use of a simple static policy is the often the simplest
+ route to IPsec-enabling a SIGTRAN peer.
+
+ If IPsec is used to secure a SIGTRAN peer-to-peer session, IPsec
+ policy SHOULD be set so as to require IPsec protection for inbound
+ connections, and to initiate IPsec protection for outbound
+ connections. This can be accomplished via use of inbound and
+ outbound filter policy.
+
+9. Security Considerations
+
+ This document discusses the usage of IPsec and TLS for securing
+ SIGTRAN traffic.
+
+10. IANA Considerations
+
+ The message class 12 has been reserved in the Signaling User Adaption
+ Layer Assignments Registry. For this message class, message type 1
+ has been reserved for the STARTTLS message, and message type 2 for
+ the STARTTLS_ACK message.
+
+11. Acknowledgements
+
+ The authors would like to thank B. Aboba, K. Morneault and many
+ others for their invaluable comments and suggestions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney, et al. Standards Track [Page 10]
+
+RFC 3788 SIGTRAN Security June 2004
+
+
+12. References
+
+12.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+12.2. Informative References
+
+ [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+ 2246, January 1999.
+
+ [3] Kent, S. and R. Atkinson, "Security Architecture for the
+ Internet Protocol", RFC 2401, November 1998.
+
+ [4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
+ (ESP)", RFC 2406, November 1998.
+
+ [5] Piper, D., "The Internet IP Security Domain of Interpretation
+ for ISAKMP", RFC 2407, November 1998.
+
+ [6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
+ RFC 2409, November 1998.
+
+ [7] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams,
+ "X.509 Internet Public Key Infrastructure Online Certificate
+ Status Protocol - OCSP", RFC 2560, June 1999.
+
+ [8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
+ H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
+ "Stream Control Transmission Protocol", RFC 2960, October 2000.
+
+ [9] Morneault, K., Rengasami, S., Kalla, M. and G. Sidebottom,
+ "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001.
+
+ [10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
+ Public Key Infrastructure Certificate and Certificate
+ Revocation List (CRL) Profile", RFC 3280, April 2002.
+
+ [11] Stone, J., Stewart, R. and D. Otis, "Stream Control
+ Transmission Protocol (SCTP) Checksum Change", RFC 3309,
+ September 2002.
+
+ [12] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and J.
+ Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2)
+ - User Adaptation Layer", RFC 3331, September 2002.
+
+
+
+
+
+Loughney, et al. Standards Track [Page 11]
+
+RFC 3788 SIGTRAN Security June 2004
+
+
+ [13] Sidebottom, G., Ed., Morneault, K., Ed. and J. Pastor-Balbas,
+ Ed., "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -
+ User Adaptation Layer (M3UA)", RFC 3332, September 2002.
+
+ [14] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer
+ Security over Stream Control Transmission Protocol", RFC 3436,
+ December 2002.
+
+ [15] George, T., "SS7 MTP2-User Peer-to-Peer Adaptation Layer", Work
+ in Progress, February 2004.
+
+ [16] Loughney, J., "Signalling Connection Control Part User
+ Adaptation Layer (SUA)", Work in Progress, December 2003.
+
+ [17] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On
+ the Use of Stream Control Transmission Protocol (SCTP) with
+ IPsec", RFC 3554, July 2003.
+
+13. Authors' Addresses
+
+ John Loughney
+ Nokia Research Center
+ PO Box 407
+ FIN-00045 Nokia Group
+ Finland
+
+ EMail: john.loughney@nokia.com
+
+
+ Michael Tuexen (editor)
+ Univ. of Applied Sciences Muenster
+ Stegerwaldstr. 39
+ 48565 Steinfurt
+ Germany
+
+ EMail: tuexen@fh-muenster.de
+
+
+ Javier Pastor-Balbas
+ Ericsson Espana S.A.
+ Via de los Poblados, 13
+ 28033 Madrid
+ Spain
+
+ EMail: j.javier.pastor@ericsson.com
+
+
+
+
+
+
+Loughney, et al. Standards Track [Page 12]
+
+RFC 3788 SIGTRAN Security June 2004
+
+
+14. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). 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 currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Loughney, et al. Standards Track [Page 13]
+