--- 1/draft-ietf-ippm-2680-bis-04.txt 2015-08-20 12:15:05.805089637 -0700 +++ 2/draft-ietf-ippm-2680-bis-05.txt 2015-08-20 12:15:05.885091573 -0700 @@ -1,23 +1,23 @@ Network Working Group G. Almes Internet-Draft Texas A&M Obsoletes: 2680 (if approved) S. Kalidindi Intended status: Standards Track Ixia -Expires: February 13, 2016 M. Zekauskas +Expires: February 21, 2016 M. Zekauskas Internet2 A. Morton, Ed. AT&T Labs - August 12, 2015 + August 20, 2015 A One-Way Loss Metric for IPPM - draft-ietf-ippm-2680-bis-04 + draft-ietf-ippm-2680-bis-05 Abstract This memo (RFC 2680 bis) defines a metric for one-way loss of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2680 obsolete. Status of This Memo @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on February 13, 2016. + This Internet-Draft will expire on February 21, 2016. 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 @@ -74,27 +74,27 @@ 3.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 11 3.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 12 3.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 13 3.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 13 3.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 14 4. Some Statistics Definitions for One-way Packet Loss . . . . . 14 4.1. Type-P-One-way-Packet Loss-Ratio . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 7. Changes from RFC 2680 . . . . . . . . . . . . . . . . . . . . 16 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction This memo defines a metric for one-way packet loss across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, [RFC2330]; the reader is assumed to be familiar with that document, and its recent update [RFC7312]. This memo is intended to be parallel in structure to a companion document for One-way Delay ("A One-way Delay Metric for IPPM") @@ -429,23 +429,24 @@ for extensive discussion of reporting considerations for different audiences). 2.8.1. Type-P As noted in the Framework document, section 13 of [RFC2330], the value of the metric may depend on the type of IP packets used to make the measurement, or "Type-P". The value of Type-P-One-way-Delay could change if the protocol (UDP or TCP), port number, size, or arrangement for special treatment (e.g., IP DS Field [RFC2780], ECN - [RFC3168], or RSVP) changes. Additional packet distinctions included - in future extensions of the Type-P definition will apply. The exact - Type-P used to make the measurements MUST be accurately reported. + [RFC3168], or RSVP) changes. Additional packet distinctions + identified in future extensions of the Type-P definition will apply. + The exact Type-P used to make the measurements MUST be accurately + reported. 2.8.2. Loss Threshold The threshold, Tmax, (or methodology to distinguish) between a large finite delay and loss MUST be reported. 2.8.3. Calibration Results The degree of synchronization between the Src and Dst clocks MUST be reported. If possible, possibility that a test packet that arrives @@ -691,23 +692,37 @@ an attacker injecting artificial measurement traffic. If routers can recognize measurement traffic and treat it separately, the measurements will not reflect actual user traffic. If an attacker injects artificial traffic that is accepted as legitimate, the loss ratio will be artificially lowered. Therefore, the measurement methodologies SHOULD include appropriate techniques to reduce the probability measurement traffic can be distinguished from "normal" traffic. Authentication techniques, such as digital signatures, may be used where appropriate to guard against injected traffic attacks. - The privacy concerns of network measurement are limited by the active - measurements described in this memo. Unlike passive measurements, - there can be no release of existing user data. + When considering privacy of those involved in measurement or those + whose traffic is measured, the sensitive information available to + potential observers is greatly reduced when using active techniques + which are within this scope of work. Passive observations of user + traffic for measurement purposes raise many privacy issues. We refer + the reader to the privacy considerations described in the Large Scale + Measurement of Broadband Performance (LMAP) Framework + [I-D.ietf-lmap-framework], which covers active and passive + techniques. + + Collecting measurements or using measurement results for + reconnaissance to assist in subsequent system attacks is quite + common. Access to measurement results, or control of the measurement + systems to perform reconnaissance should be guarded against. See + Section 7 of [I-D.ietf-lmap-framework] (security considerations of + the LMAP Framework) for system requirements that help to avoid + measurement system compromise. 6. Acknowledgements For [RFC2680], thanks are due to Matt Mathis for encouraging this work and for calling attention on so many occasions to the significance of packet loss. Thanks are due also to Vern Paxson for his valuable comments on early drafts, and to Garry Couch and Will Leland for several useful suggestions. For RFC 2680 bis, thanks to Joachim Fabini, Ruediger Geib, Nalini @@ -755,22 +770,22 @@ the text, to reference key IPPM RFCs that were approved after [RFC2680] (see sections 3 and 3.6, above), and to address comments on the IPPM mailing list describing current conditions and experience. 1. Near the end of section 1.1, update of a network example using ATM and clarification of TCP's affect on queue occupation and importance of one-way delay measurement. 2. Clarification of the definition of "resolution" in section 1.2. - 3. Explicit inclusion of the maximum waiting time input parameter in - sections 2.2, 2.4, and 3.2, reflecting recognition of this + 3. Explicit inclusion of the maximum waiting time input parameter + in sections 2.2, 2.4, and 3.2, reflecting recognition of this parameter in more recent RFCs and ITU-T Recommendation Y.1540. 4. Addition of reference to RFC 6703 in the discussion of packet life time and application timeouts in section 2.5. 5. Replaced "precedence" with updated terminology (DS Field) in 2.6 and 2.8.1 (with reference). 6. Added parenthetical guidance on minimizing interval between timestamp placement to send time or reception time in section @@ -782,20 +797,24 @@ sampling in section 3, and also noting that a truncated Poisson distribution may be needed with modern networks as described in the IPPM Framework update, [RFC7312]. 8. Recognition that Time-slotted links described in [RFC7312] can greatly modify the sample characteristics, in section 3.5. 9. Add reference to RFC 4737 Reordering metric in the related discussion of section 3.6, Methodologies. + 10. Expanded and updated the material on Privacy, and added cautions + on use of measurements for reconnaissance in section 5, Security + Considerations. + Section 5.4.4 of [RFC6390] suggests a common template for performance metrics partially derived from previous IPPM and BMWG RFCs, but also contains some new items. All of the [RFC6390] Normative points are covered, but not quite in the same section names or orientation. Several of the Informative points are covered. Maintaining the familiar outline of IPPM literature has value and minimizes unnecessary differences between this revised RFC and current/future IPPM RFCs. 8. IANA Considerations @@ -853,20 +872,26 @@ Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March 2012, . [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, DOI 10.17487/RFC7312, August 2014, . 9.2. Informative References + [I-D.ietf-lmap-framework] + Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., + Aitken, P., and A. Akhter, "A framework for Large-Scale + Measurement of Broadband Performance (LMAP)", draft-ietf- + lmap-framework-14 (work in progress), April 2015. + [I-D.morton-ippm-2330-stdform-typep] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. Hegde, "Updates for IPPM's Active Metric Framework: Packets of Type-P and Standard-Formed Packets", draft- morton-ippm-2330-stdform-typep-00 (work in progress), August 2015. [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 10.17487/RFC4737, November 2006,