summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7718.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7718.txt')
-rw-r--r--doc/rfc/rfc7718.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc7718.txt b/doc/rfc/rfc7718.txt
new file mode 100644
index 0000000..3170ed7
--- /dev/null
+++ b/doc/rfc/rfc7718.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Morton
+Request for Comments: 7718 AT&T Labs
+Updates: 4656 December 2015
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ Registries for the One-Way Active Measurement Protocol (OWAMP)
+
+Abstract
+
+ This memo describes the registries for OWAMP -- the One-Way Active
+ Measurement Protocol. The registries allow assignment of Mode bit
+ positions and OWAMP Command numbers. Per this memo, IANA has
+ established the registries for new features, called the OWAMP-Modes
+ registry and the OWAMP Control Command Number registry. This memo
+ updates RFC 4656.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7718.
+
+Copyright Notice
+
+ Copyright (c) 2015 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+Morton Standards Track [Page 1]
+
+RFC 7718 OWAMP Registries December 2015
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
+ 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. IANA Considerations for OWAMP-Control Registries . . . . . . 3
+ 3.1. Control Command Number Registry . . . . . . . . . . . . . 3
+ 3.1.1. Registry Specification . . . . . . . . . . . . . . . 3
+ 3.1.2. Registry Management . . . . . . . . . . . . . . . . . 3
+ 3.1.3. Experimental Numbers . . . . . . . . . . . . . . . . 3
+ 3.1.4. OWAMP-Control Command Numbers Initial Contents . . . 3
+ 3.2. OWAMP-Modes . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.2.1. Registry Specification . . . . . . . . . . . . . . . 4
+ 3.2.2. Registry Management . . . . . . . . . . . . . . . . . 4
+ 3.2.3. Experimental Numbers . . . . . . . . . . . . . . . . 4
+ 3.2.4. OWAMP-Modes Initial Contents . . . . . . . . . . . . 4
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
+ 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.1. Normative References . . . . . . . . . . . . . . . . . . 6
+ 5.2. Informative References . . . . . . . . . . . . . . . . . 6
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
+
+1. Introduction
+
+ The One-Way Active Measurement Protocol (OWAMP) [RFC4656] was
+ prepared to support measurements of metrics specified by the IP
+ Performance Metrics (IPPM) working group in the IETF. The Two-Way
+ Active Measurement Protocol (TWAMP) [RFC5357] is an extension of
+ OWAMP. The TWAMP specification gathered wide review as it approached
+ completion, and the by-products were several recommendations for new
+ features in TWAMP. As a result, a registry of new features was
+ established for TWAMP. However, there were no new features proposed
+ for OWAMP until recently [RFC7717].
+
+ This memo establishes the needed registries for OWAMP and updates
+ [RFC4656].
+
+1.1. Requirements Language
+
+ 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 RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+Morton Standards Track [Page 2]
+
+RFC 7718 OWAMP Registries December 2015
+
+
+2. Purpose and Scope
+
+ The purpose and scope of this memo is to describe and request the
+ establishment of registries for future OWAMP [RFC4656] extensions.
+ IANA already administers the "Two-way Active Measurement Protocol
+ (TWAMP) Parameters", and this request follows a similar form (with
+ one exception identified below).
+
+ This memo also provides the initial contents for the OWAMP
+ registries.
+
+3. IANA Considerations for OWAMP-Control Registries
+
+ The OWAMP-Control protocol coordinates the measurement capability.
+ All OWAMP-Control messages follow specifications defined in Section 3
+ of [RFC4656].
+
+3.1. Control Command Number Registry
+
+ IANA has created an OWAMP-Control Command Number registry.
+
+ OWAMP-Control Commands follow specifications defined in Section 3.4
+ of [RFC4656].
+
+3.1.1. Registry Specification
+
+ OWAMP-Control Command Numbers are specified in the first octet of
+ OWAMP-Control-Client command messages consistent with Section 3 of
+ [RFC4656]. There are a maximum of 256 command numbers.
+
+3.1.2. Registry Management
+
+ Because the "OWAMP-Control Command Numbers" registry can contain only
+ 256 values, and because OWAMP is an IETF protocol, these registries
+ MUST be updated only by "IETF Review" as specified in [RFC5226] (an
+ RFC that documents registry use and is approved by the IESG).
+
+3.1.3. Experimental Numbers
+
+ One experimental value is currently assigned in the Command Numbers
+ Registry, as indicated in the initial contents below.
+
+3.1.4. OWAMP-Control Command Numbers Initial Contents
+
+ OWAMP-Control Commands follows the procedure defined in Section 3.5
+ of [RFC4656] and in the remainder of Section 3 of that document.
+
+
+
+
+
+Morton Standards Track [Page 3]
+
+RFC 7718 OWAMP Registries December 2015
+
+
+ The complete set of OWAMP-Control Command Numbers are as follows
+ (including two reserved values):
+
+ OWAMP-Control Command Numbers
+
+ Value Description Semantics Reference
+ Definition
+ ==========================================================
+ 0 Reserved Section 3.1.4 RFC 7718
+ 1 Request-Session Section 3.5 RFC 4656
+ 2 Start-Sessions Section 3.7 RFC 4656
+ 3 Stop-Sessions Section 3.8 RFC 4656
+ 4 Fetch-Sessions Section 3.9 RFC 4656
+ 5-253 Unassigned
+ 254 Experimentation Section 3.1.4 RFC 7718
+ 255 Reserved Section 3.1.4 RFC 7718
+
+3.2. OWAMP-Modes
+
+ IANA has created an OWAMP-Modes registry.
+
+3.2.1. Registry Specification
+
+ OWAMP-Modes are specified in OWAMP Server Greeting messages and Set-
+ up Response messages consistent with Section 3.1 of [RFC4656]. Modes
+ are currently indicated by setting single bits in the 32-bit Modes
+ field. However, more complex encoding may be used in the future.
+
+3.2.2. Registry Management
+
+ Because the "OWAMP-Modes" are based on only 32 bit positions with
+ each position conveying a unique feature, and because OWAMP is an
+ IETF protocol, these registries MUST be updated only by "IETF Review"
+ as specified in [RFC5226] (an RFC that documents registry use and is
+ approved by the IESG). IANA SHOULD allocate monotonically increasing
+ bit positions when requested.
+
+3.2.3. Experimental Numbers
+
+ No experimental bit positions are currently assigned in the Modes
+ registry, as indicated in the initial contents below.
+
+3.2.4. OWAMP-Modes Initial Contents
+
+ OWAMP-Control connection establishment follows the procedure defined
+ in Section 3.1 of [RFC4656].
+
+
+
+
+
+Morton Standards Track [Page 4]
+
+RFC 7718 OWAMP Registries December 2015
+
+
+ In the OWAMP-Modes registry, assignments are straightforward on the
+ basis of bit positions, and there are no references to values -- this
+ is a difference from the comparable TWAMP registry (and a topic for
+ improvement in the TWAMP-Modes registry that is reconciled in
+ [RFC7717]).
+
+ An extension of the OWAMP-Modes is proposed in [RFC7717]. With this
+ extension, the complete set of OWAMP Mode bit positions are as
+ follows (including one reserved bit position):
+
+ OWAMP-Modes
+
+ Bit Semantics
+ Pos. Description Definition Reference
+ =======================================================
+ 0 Unauthenticated Section 3.1 RFC 4656
+ 1 Authenticated Section 3.1 RFC 4656
+ 2 Encrypted Section 3.1 RFC 4656
+ 3 Reserved Section 3.2.4 RFC 7718
+ ------------------------------------------------------
+ 4 IKEv2-derived Shared Section 3.2.4 RFC 7718
+ Secret Key of RFC 7718,
+ Section 5 of RFC 7717
+ of RFC 7717
+ ------------------------------------------------------
+ 5-31 Unassigned
+
+ In the original OWAMP Modes field, setting bit position 0, 1, or 2
+ indicated the security mode of the Control protocol, and the Test
+ protocol inherited the same mode (see Section 4 of [RFC4656]).
+
+ The value of the Modes field sent by the Server in the Server-
+ Greeting message is the bit-wise OR of the modes (bit positions) that
+ it is willing to support during this session. Thus, the five least
+ significant bits of the 32-bit Modes field are used. When no other
+ features are activated, the 27 most significant bits MUST be zero. A
+ Control-Client conforming to [RFC4656] MAY ignore the values in the
+ 29 most significant bits of the Modes field, or it MAY support
+ features that are communicated in other bit positions, such as the
+ IKEv2-derived Shared Secret Key extension [RFC7717].
+
+ OWAMP and TWAMP registries for Modes may grow to contain different
+ features and functions due to the inherent differences in one-way and
+ two-way measurement configurations and the metrics they measure. No
+ attempt will be made to coordinate them unnecessarily, except for the
+ Reserved bit position 3 above. This is available for assignment if a
+ mixed security mode similar to [RFC5618] is defined for OWAMP; it
+ would allow alignment with the comparable TWAMP feature.
+
+
+
+Morton Standards Track [Page 5]
+
+RFC 7718 OWAMP Registries December 2015
+
+
+4. Security Considerations
+
+ As this memo simply documents the creation of OWAMP registries, it
+ presents no new security or privacy issues for the Internet.
+
+ The security considerations that apply to any active measurement of
+ live networks are relevant here as well. See [RFC4656] and
+ [RFC5357].
+
+ Privacy considerations for measurement systems, particularly when
+ Internet users participate in the tests in some way, are described in
+ [RFC7594].
+
+5. References
+
+5.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
+ Zekauskas, "A One-way Active Measurement Protocol
+ (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
+ <http://www.rfc-editor.org/info/rfc4656>.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ DOI 10.17487/RFC5226, May 2008,
+ <http://www.rfc-editor.org/info/rfc5226>.
+
+ [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
+ Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
+ RFC 5357, DOI 10.17487/RFC5357, October 2008,
+ <http://www.rfc-editor.org/info/rfc5357>.
+
+5.2. Informative References
+
+ [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the
+ Two-Way Active Measurement Protocol (TWAMP)", RFC 5618,
+ DOI 10.17487/RFC5618, August 2009,
+ <http://www.rfc-editor.org/info/rfc5618>.
+
+
+
+
+
+
+
+
+Morton Standards Track [Page 6]
+
+RFC 7718 OWAMP Registries December 2015
+
+
+ [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
+ Aitken, P., and A. Akhter, "A Framework for Large-Scale
+ Measurement of Broadband Performance (LMAP)", RFC 7594,
+ DOI 10.17487/RFC7594, September 2015,
+ <http://www.rfc-editor.org/info/rfc7594>.
+
+ [RFC7717] Pentikousis, K., Ed., Zhang, E., and Y. Cui,
+ "IKEv2-Derived Shared Secret Key for the One-Way Active
+ Measurement Protocol (OWAMP) and Two-Way Active
+ Measurement Protocol (TWAMP)", RFC 7717,
+ DOI 10.17487/RFC7717, December 2015,
+ <http://www.rfc-editor.org/info/rfc7717>.
+
+Acknowledgements
+
+ The author would like to thank Kostas Pentikousis, Nalini Elkins,
+ Mike Ackermann, and Greg Mirsky for insightful reviews and comments.
+ We thought Spencer Dawkins caught the last of the small errors in his
+ AD review, but Nevil Brownlee found a few more during OPS-DIR review.
+ Roni Even found our use of "IETF Consensus" was out of date with
+ [RFC5226]. Michelle Cotton helped to clarify the IANA
+ considerations.
+
+Author's Address
+
+ Al Morton
+ AT&T Labs
+ 200 Laurel Avenue South
+ Middletown,, NJ 07748
+ United States
+
+ Phone: +1 732 420 1571
+ Fax: +1 732 368 1192
+ Email: acmorton@att.com
+ URI: http://home.comcast.net/~acmacm/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morton Standards Track [Page 7]
+