Re: [ippm] Ben Campbell's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)
<nalini.elkins@insidethestack.com> Mon, 01 May 2017 18:54 UTC
Return-Path: <nalini.elkins@insidethestack.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD40E12EB07 for <ippm@ietfa.amsl.com>; Mon, 1 May 2017 11:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.41
X-Spam-Level:
X-Spam-Status: No, score=0.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 556cXO_4q-Xr for <ippm@ietfa.amsl.com>; Mon, 1 May 2017 11:54:42 -0700 (PDT)
Received: from sonic308-16.consmr.mail.gq1.yahoo.com (sonic308-16.consmr.mail.gq1.yahoo.com [98.137.68.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF81D129C39 for <ippm@ietf.org>; Mon, 1 May 2017 11:51:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1493664714; bh=aBnImU41ddSo7WO+8Fl1VV1QRq2seQJElCPIliwhHWY=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=nN872bLGAVL8/U21Wteid5PORuUR72IMwRKqdMF0TcgC7tptBWo8VCbl114Nb5TWxV3E95e6wmEm7J2Dl3GB+W031a6QPphMOlHeifIKF6xYtwnt2qRMGbjr3moeGh/8ZA8ZLOtrvbixiepf8IgoOGdisQQZzB7AZuNR8vLDcil6W6ElUhGxY8+CskQqM3NZlvMO3DaFgLFH3iNnuxWW3Qql6UcyQJD7W/ZK+9LtRQA36TNdplY603Y1uTcdkUxUt8ynb4ZIeuk8HabnxFCF47a00Z2b+DGmfbsIaGYy4EiXs8VgTzt+FIAbFbfZ6dga/fcvzPR2vQdzlyJpP7y1Tg==
X-YMail-OSG: eK82bHYVRDtgfAoCqOIpFuQf7CXNzbPmvwqKAF0E6WpCYH8GW8U-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Mon, 1 May 2017 18:51:54 +0000
Date: Mon, 01 May 2017 18:51:53 +0000
From: nalini.elkins@insidethestack.com
Reply-To: nalini.elkins@insidethestack.com
To: The IESG <iesg@ietf.org>, Ben Campbell <ben@nostrum.com>
Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, Bill Cerveny <ietf@wjcerveny.com>, ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org
Message-ID: <891819038.1857829.1493664713691@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
References: <891819038.1857829.1493664713691.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.9521 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/cNBqR6aicMscH0HHzPzczhu1A4A>
Subject: Re: [ippm] Ben Campbell's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 May 2017 18:54:45 -0000
-------------------------------------------- On Wed, 4/12/17, Ben Campbell <ben@nostrum.com> wrote: Subject: [ippm] Ben Campbell's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) To: "The IESG" <iesg@ietf.org> Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Bill Cerveny" <ietf@wjcerveny.com>, ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org Date: Wednesday, April 12, 2017, 1:26 PM > Ben Campbell has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: No Objection > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. > The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ Ben Campbell >Substantive Comments: >- 1.4, 2nd to last paragraph: Please don't make assumptions about >organizational models; different organizations do it differently. Does >the motivation still make sense if the organization doesn't follow this >model? I believe that you are referring to this: "What PDM will tell you is whether the problem is in the network or the server. In our experience, there is often a different group which is involved to troubleshoot the problem depending on the nature of the problem. That is, the problem may be escalated to the application developers or the team that deals with the routers and infrastructure. Both the network group and the application group have quite a few specialized tools at their disposal to further investigate their own areas. What is missing is the first step, which PDM provides." Certainly organizations do this differently. That is why I said: "In our experience, there is often a different group" I can say: "In some organizations, there may be a different group" if you prefer that wording. But for any group doing troubleshooting (after having done quite a bit of it myself!), the need to isolate at every level is critical. The first level being network and host. > - 1.5, first paragraph: "The purpose of the PDM is not to supplant all > the variables present in all other headers but to provide data which is > not available or very difficult to get." >How is that different than for any other extension? True. That wording came about because initially there was confusion as to whether PDM would by itself provide all the data needed. So, that paragraph continues to explain that PDM variables are used in conjunction with other variables from other headers. I can reword as follows. Current ------- The purpose of the PDM is not to supplant all the variables present in all other headers but to provide data which is not available or very difficult to get. The way PDM would be used is by a technician (or tool) looking at a packet capture. New --- PDM may be used in conjunction with variables in other headers. For example, if PDM may be used by a technician (or tool) looking at a packet capture. >3.2.1, PSNTP definition: > What are the consequences if people "spoof and insert such packets."? The consequences would be that the measurements would likely be wrong. We have taken care that a resource consumption attack would not happen. That is, that if a host receives a packet with a PDM extension, that it would not automatically respond by starting to collect PDM data. This is why we have PDM started by administrative action only. >- 3.2.2: Are there really use cases for attosecond precision? We were trying to future-proof. I know Wireshark is looking at nanosecond precision, if they don't have it already. I have customers with single digit microsecond for network time already. In discussions with previous reviewers, we settled on attosecond precision. >- 4.1, last paragraph: Can you provide guidance on selecting a reasonable >limit? At least a lower bound so that the limit does not negatively >impact the PDM function? I assume you are talking about this statement: "We recommend that implementation of PDM SHOULD have a limit on the number of control block entries." That section has been redone per Mirja's comments. Please let me know if you agree. The essence of Mirja's discussion in this area was that using control blocks was merely one potential implementation. It is really memory which is of concern. I agree with Mirja's point. So, the statement has been changed to: "A limit on how much memory is being used SHOULD be implemented." Having said all this, I do not feel comfortable about indicating a hard limit. This is very implementation dependent. They may choose to have a running total, average, etc. Current section --------------- 4.1. SYN Flood and Resource Consumption Attacks PDM needs to calculate the deltas for time and keep track of the sequence numbers. This means that control blocks must be kept at the end hosts per 5-tuple. Any time a control block is kept, an attacker can try to mis-use the control blocks such that there is a compromise of the end host. PDM is used only at the end hosts and the control blocks are only kept at the end host and not at routers or middle boxes. Remember, PDM is an implementation of the Destination Option extension header. A "SYN flood" type of attack succeeds because a TCP SYN packet is small but it causes the end host to start creating a place holder for the session such that quite a bit of control block and other storage is used. This is an asynchronous type of attack in that a small amount of work by the attacker creates a large amount of work by the resource attacked. For PDM, the amount of data to be kept is quite small. That is, the control block is quite lightweight. Concerns about SYN Flood and other type of resource consumption attacks (memory, processing power, etc) can be alleviated by having a limit on the number of control block entries. We recommend that implementation of PDM SHOULD have a limit on the number of control block entries. NEW ------- 4.1. Resource Consumption and Resource Consumption Attacks PDM needs to calculate the deltas for time and keep track of the sequence numbers. This means that control blocks which reside in memory may be kept at the end hosts per 5-tuple. A limit on how much memory is being used SHOULD be implemented. Additionally, any time a control block is kept in memory, an attacker can try to mis-use the control blocks to cause excessive resource consumption. This may create compromise of the end host. PDM is used only at the end hosts and the control blocks are only kept at the end host and not at routers or middle boxes. PDM is an implementation of the Destination Option extension header. >-4.2: >Could PDM be used to (help) deduce the nature of the application, or >possibly network topology? The last paragraph says it will be unhelpful >in deducing content; I suspect otherwise. Section 4.4 talks about how it >might help timing attacks against key material. >Does PDM really offer no more information to an observer than they could >get by observing packet intervals of otherwise encrypted traffic? For >example, it seems like one could not differentiate between wire-time and >processing-time from observation alone. I believe what you are talking about is the statement: "As far as deducing the content of the payload, it appears to us that PDM is quite unhelpful in this regard." No, one could not differentiate between wire-time and processing-time from observation alone. Indeed, that is the very reason for the existence of PDM. Let's take this one at a time. As far as network topology, one could probably deduce some level of network topology. It would be in the nature of is this likely to be a LAN, fiber link, or slow horrible link. But, I may already be able to tell that from the L2 information in the packet trace combined with the address. That is, if I know from L2 that it is a VM and then I know from the IP address that it is a 192.168 address, then I already know quite a bit about the connection. This is all without using PDM. So, then with PDM, I know if the LAN is fast or slow. That is the reason for PDM. If it is a global address, then I may have some idea of the network topology in terms of possibly number of hops or route length or how fast the links are. But, I already have TTL available to me to make some guesses in that area. Again, I believe for network topology, I think link speed is likely what one could deduce from PDM - which is its stated purpose. As far as being able to deduce the type of application, I can deduce many things from the traffic pattern alone. If it is all one-way traffic, it is likely to be an FTP and so forth. Of course, PDM adds the timing component which is key additional information. What we meant is that PDM does not tell you which HTTPS page is being requested or the user password, etc. Please let me know what you think of the following change: Current ------- As far as deducing the content of the payload, it appears to us that PDM is quite unhelpful in this regard. New ------- As far as deducing the content of the payload, in terms of the application level information such as web page, user name, user password and so on, it appears to us that PDM is quite unhelpful in this regard. Having said that, the ability to separate wire-time from processing time may potentially provide an attacker with additional information. > -4.4, 2nd paragraph: Why does the attacker need to induce the host to > turn on PDM? What about cases where the host already uses PDM? Good point. Current ------- For example, if an attacker is able to create an attack which causes the enterprise to turn on PDM to diagnose the attack, then the attacker might use PDM during that debugging time to launch a timing attack... New ------- For example, if an attacker can see that PDM is being used, then the attacker might use PDM to launch a timing attack... >-- last paragraph:The text recommends that a user SHOULD consent. I think >you mean to say that user consent SHOULD be required. They mean very > different things. True. Current ------- So, if with PDM, we recommend that the user SHOULD consent to its use. New --- So, if with PDM, we recommend that the user consent SHOULD be required. > But along those lines, do you expect the average user to make informed > consent decisions? At what scope should such decisions be made? Some OSs > ask a user if they are willing to share diagnostic info at a global > level. Does the guidance about using PDM on limited IP addresses or ports > suggest consent apply at a smaller granularity? We have added the folllowing because of comments made by Warren: "The actual content of "Consent to be Measured" will differ by site but it SHOULD make clear that the traffic is being measured for quality of service and to assist in diagnostics as well as to make clear that there may be potential risks of certain vulnerabilities if the traffic is captured during a diagnostic session. " As far as your comment on whether an average user can make an informed decision, frankly, I have thought for many years that it seems quite unimaginable that users can actually deal with PCs, cell phones or actually any of it! Most of my non-technology friends have no idea how much of anything works. It is like me with cars. I can drive (usually!) but have zero idea of what to do when anything goes wrong. I suppose that boat sailed a long time ago with technology. But, here we are. Meaning, technology that people don't understand is in everyone's hands and home. I don't know how much the average user actually understands about any of it. Having said that, I can add the following: "The "Consent to be Measured" SHOULD be written in language that is understandable to an average user." >Editorial Comments: >-General: Much of the text reads more like a white paper than an IETF >standards-track RFC. This makes some sections seem like advertisements. >The heavy use of "we" calls into question whether it documents the >opinions of the WG, or the opinions of the authors. It also makes some >sections longer than they need to be (e.g. the discussions related to >time scaling factors read more like a classroom lecture than a >specification.) I recognize that fixing this would require a re-write. I >will leave it to the authors, chairs, and AD to decide if that is >worthwhile this late in the process. Please see my response to comments from Mirja. A number of the sections are being moved to an Appendix or left out. > - Abstract: Last sentence is long and convoluted. Please consider > breaking it up. Current ------- An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage of the PDM in measurement are included in this document. New --- The field limits, calculations, and usage in measurement of the Performance and Diagnostic Metrics (PDM) Destination Options extension header are included in this document. > - 1.4, list of advantages: How is 5 different than 2? Good point. Current ------- 1. Real measure of actual transactions. 2. Independence from transport layer protocols. 3. Ability to span organizational boundaries with consistent instrumentation. 4. No time synchronization needed between session partners 5. Ability to handle all transport protocols (TCP, UDP, SCTP, etc) in a uniform way New --- 1. Real measure of actual transactions. 2. Ability to span organizational boundaries with consistent instrumentation. 3. No time synchronization needed between session partners 4. Ability to handle all transport protocols (TCP, UDP, SCTP, etc) in a uniform way > -- 2nd paragraph after end of list: s/"to do"/"to" Current ------- One of the important functions of PDM is to allow you to do quickly dispatch the right set of diagnosticians. New --- One of the important functions of PDM is to allow you to quickly dispatch the right set of diagnosticians. > - 3.2, 2nd paragraph: Please expand DTN Current ------- .. and time differentials in a DTN-type environment ... New ---- .. and time differentials in a Delay/Disruption Tolerant Networking (DTN) environment ... >- 3.2, last paragraph: >The reference to Appendix A is worded in a way that suggests you have to >read that section to understand how to implement time scaling factors. >That led me to wonder why the appendix was not part of the body. But when >I read the appendix, I realized that it really was additional >explanation, and not a normative part of the process. Please consider >something like the following: >OLD: >For a full description of this process... >NEW: >For additional discussion about this process... Fine. > - 3.4.1, first paragraph: The MAY seems like a statement of fact, not a > normative requirement. (Same for 3.4.2) Current ------- Note that Destination Options MAY be placed before or after ESP or both. New --- Note that Destination Options may be placed before or after ESP or both. Same change will be made for section 3.4.2.
- [ippm] Ben Campbell's No Objection on draft-ietf-… Ben Campbell
- Re: [ippm] Ben Campbell's No Objection on draft-i… nalini.elkins