From nobody Mon May 1 11:54:56 2017 Return-Path: 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 ; 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 ; 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 ; 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, 1 May 2017 18:51:53 +0000 (UTC) From: Reply-To: To: The IESG , Ben Campbell Cc: , Bill Cerveny , , , 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 18:54:45 -0000 -------------------------------------------- On Wed, 4/12/17, Ben Campbell wrote: Subject: [ippm] Ben Campbell's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Bill Cerveny" , 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. From nobody Tue May 2 04:08:07 2017 Return-Path: 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 404E8129A8E for ; Tue, 2 May 2017 04:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 frXwObTLCHAw for ; Tue, 2 May 2017 04:08:03 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B7C129411 for ; Tue, 2 May 2017 04:04:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=s+D9Lm3whJ29UiVZ2/PczMdBzy3MjvIDQkoW8fp8kPfWiBvaq16ZykQXVsWChbfc8PMhWetWSy6xyz1D5naC9th6DhUNSH/SzpomYFyOF7yuzizaf3nTZevPqCWGGgmHkKFrLMGlxzdbSrcpyUP2/+WeIt0/6FVuY8526R3ixps=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 29770 invoked from network); 2 May 2017 12:58:06 +0200 Received: from vpn-global-025-dhcp.ethz.ch (129.132.211.25) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 May 2017 12:58:05 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <1387097432.303756.1493224561374@mail.yahoo.com> Date: Tue, 2 May 2017 12:58:04 +0200 Cc: The IESG , draft-ietf-ippm-6man-pdm-option@ietf.org, acmorton@att.com, Bill Cerveny , ippm-chairs@ietf.org, ippm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <09A383BC-FB59-4B0B-9B7D-0191A0D83CD5@kuehlewind.net> References: <1387097432.303756.1493224561374.ref@mail.yahoo.com> <1387097432.303756.1493224561374@mail.yahoo.com> To: nalini.elkins@insidethestack.com X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170502105806.29760.42525@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [ippm] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ippm-6man-pdm-option-09=3A_=28with_COMMENT=29?= X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 11:08:06 -0000 Hi Nalini, sorry for my late reply. See below. > Am 26.04.2017 um 18:36 schrieb nalini.elkins@insidethestack.com: >=20 > Mirja, >=20 > Thanks for your comments. Please find my responses inline. >=20 >=20 > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 >=20 > -------------------------------------------- > On Wed, 4/12/17, Mirja K=C3=BChlewind wrote: >=20 > Subject: Mirja K=C3=BChlewind's No Objection on = draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) > To: "The IESG" > Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" = , "Bill Cerveny" , = ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org > Date: Wednesday, April 12, 2017, 10:53 AM >=20 > Mirja K=C3=BChlewind has entered the following ballot position for = draft-ietf-ippm-6man-pdm-option-09: No Objection >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more = information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: = https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 >> My main concern is that part of this document read like an = advertisement (e.g. "In our experience, valuable time is often lost.." = whose >> experience? The IETF? This is an IETF RFC!). I think most of this = text is not needed to understand the option and therefore should simply = be >> removed. More concretely, I propose to remove sections 1.2, 1.3., and = 1.5 as well as paragraphs 4-8 of section 1.4 (starting with "In our >> experience, valuable time is often lost..." to the end).=20 >=20 > I think that RFCs are often lacking context which makes them difficult = for new people or even people not intimately involved in the creation > of the draft to understand why they are being written. =20 I disagree. The important part of a protocol spec is that it is well = defined and to the point, so implementors can easily implement it = correctly without having knowledge about all the background discussions = that happen in the working group. > I am OK with moving the information to an appendix. What do you = think? I don=E2=80=99t think these section actually provide information that is = useful for implementor but I=E2=80=99m okay with moving them to the = appendix. I would still recommend to remove any language on business = model at least in section 1.2 (or remove at least 1.2 completely). >=20 > One question though, I believe you mean "paragraphs 4-8 of section 1.4 = (ENDING with "In our experience, valuable time is often lost...").=20 > The phrase "In our experience, valuable time is often lost..." is the = very last sentence of section 1.4.=20 Yes, sorry. I meat starting with "One of the important functions=E2=80=9C.= =20 One important point here about the language is that this document seems = to be written with the view of a specific group. However as RFC it=E2=80=99= s an IETF consensus document with represents the IETF=E2=80=99s view as = a whole. So any phrasing like "In our experience,=E2=80=A6=E2=80=9C or = =E2=80=9Ewe can=E2=80=9C/=E2=80=9Ewe may=E2=80=9C seems not appropriate = here and should be removed even if the text is moved to the appendix. >=20 >=20 >> I would also recommend these two changes to shorten the RFC:=20 >> - section 3.2.3. could just be moved into the appendix. >=20 > Fine. >=20 > I will move: "3.2.3 Considerations of this time-differential = representation" into an appendix >=20 >> - the diagrams from RFC4303 in sections 3.4.1. and 3.4.2 are not = needed >=20 > OK. >=20 >> In general I think another editing pass could help to bring the = document >> more to the point in a couple of cases. But that's not really an = issue. >=20 >=20 >> Further comments: >=20 >> 1) This text in 3.4.2 is a bit confusing: >> "As a completely new IP packet will be made, it means that PDM = information for that packet does not contain any information from the = inner packet, i.e. the PDM information will NOT be based on the >> transport layer (TCP, UDP, etc) ports etc in the inner header, but = will be specific to the ESP flow.=20 >=20 >> If PDM information for the inner packet is desired, the original = host sending the inner packet needs to put PDM header in the tunneled = packet, and then the PDM information will be specific for that >> stream." >=20 >> I think what you want to say is something like >=20 >> "A tunnel endpoint that creates a new packet may decide to use PDM = independent of the use of PDM of the original packet to enable delay = measurements between the two tunnel endpoints." >> Correct? >=20 > Yes, I think your wording represents what I wanted to convey and does = it better. >=20 >=20 >> 2) I'm not sure this is really useful to specify normatively in an = RFC as this is really implementation specific: >> "The PDM destination options extension header MUST be explicitly = turned on by each stack on a host node by administrative action. The = default value of PDM is off." >> I would recommend the following text instead (without normative = language): >> "An implementation should provide an interface to enable or disable = the use of PDM. This specification recommends to turn PDM off by = default." >=20 > I believe you are speaking of section 3.5.1 >=20 > The reason for this was because an implementation could be created = which automatically and dynamically turned on PDM when a packet = containing a PDM header was received. Then, PDM would be used > without the host being explicitly aware of it. And a number of = unfortunate things such as information leakage, DOS attacks, etc might = happen. So, we added language to say that administrative action is = required. This issue was brought up by the security area review of = this document. >=20 > The issue mentioned above is dealt with explicitly in section 3.5.1. = The entire text is below: >=20 > Current text > ---------------- >=20 > 3.5.1 PDM Activation >=20 > The PDM destination options extension header MUST be explicitly = turned on by each stack on a host node by administrative action. The = default value of PDM is off. >=20 > PDM MUST NOT be turned on merely if a packet is received with a PDM = header. The received packet could be spoofed by another device. I understand the intention here and the intention is correct. My comment = was that the use of normative language here might not be really = appropriate because this part does not talk about the protocol itself = but the interface to the higher layer and this depends very much on the = use case and environment in which it is implemented. Therefore I would = recommend to not use normative language here. >=20 >=20 >=20 >> 3) I don't understand section 3.6. Isn't that redundant with 3.5.1? = Or what's meant by 'dynamic configuration option'? In any case, I don't >> think the use of normative language is appropriate here. >=20 > This was also brought up by Warren. He accepted the change below. = Please let me know if that also works for you. >=20 > Current text > ---------------- >=20 > 3.6 Dynamic Configuration Options >=20 > If implemented, each operating system MUST have a default = configuration parameter, e.g. diag_header_sys_default_value=3Dyes/no. = The operating system MAY also have a dynamic configuration option to > change the configuration setting as needed. >=20 > If the PDM destination options extension header is used, then it MAY = be turned on for all packets flowing through the host, applied to an = upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP > address only. These are at the discretion of the implementation. >=20 >=20 > New text > ----------- >=20 > 3.6 Filtering of PDM >=20 > If the PDM destination options extension header is used, then it MAY = be turned on for all packets flowing through the host, applied to an = upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP > address only. These are at the discretion of the implementation. Okay. >=20 >=20 >> 4) I would also like to propose new text on 3.6 5-tuple Aging (btw. = 3.6. exists twice) >=20 > Thanks will fix the 3.6 twice. >=20 >> OLD >=20 >> "3.6 5-tuple Aging >=20 >> Within the operating system, metrics must be kept on a 5-tuple basis. >=20 >> The question comes of when to stop keeping data or restarting the = numbering for a 5-tuple. For example, in the case of TCP, at some >> point, the connection will terminate. Keeping data in control = blocks forever, will have unfortunate consequences for the operating >> system. >=20 >> So, the recommendation is to use a known aging parameter such as = Max Segment Lifetime (MSL) as defined in Transmission Control Protocol >> [RFC0793] to reuse or drop the control block. The choice of aging = parameter is left up to the implementation." >=20 >> NEW >=20 >> "3.6 Information Access and Storage >=20 >> Measurement information provided by PDM must be made accessible for = higher layers or the user itself. Similar as activating the use of >> PDM, the implementation may also provide an interface to indicate if = received >=20 >> PDM information should be stored or not. If a packet with PDM = information is received and the information should be stored, the upper = layers may be >> notified. Further it is recommend to define a configurable maximum = lifetime after which the information can be removed as well as >> a configurable maximum amount of memory that should be allocated for = PDM information." >=20 >> This text also addresses some of the "SYN flood attack" concerns as = described in the security considerations section. I would recommend to = rewrite this >> section as well and I would also recommend to not use the term SYN = flood as that is clearly associated with TCP only. >=20 > As far as: >=20 > "Measurement information provided by PDM must be made accessible for = higher layers or the user itself." >=20 > The information in PDM is in the extension header. What we had = envisioned is that diagnostics would be done by capturing a packet = trace. But, certainly what=20 > you suggest is very interesting. Higher layers as well as the user = could make very good use of PDM information. =20 >=20 > Are you OK with a minor change to that sentence to say: >=20 > "Measurement information provided by PDM may be made accessible for = higher layers or the user itself.=E2=80=9C >=20 Okay.=20 > As far as the rest of the text in that paragraph, I am fine with it. = In fact, in working on implementation, we are doing exactly that: a = configurable amount of memory / lifetime. > Actually, only memory is needed as then it controls everything else = quite well. This is why we said "limit on control blocks" in the = security section. I will make it > more explicit that what is meant by control blocks is memory. >=20 >=20 > Current Security section > -------------------------------- >=20 > 4.1. SYN Flood and Resource Consumption Attacks >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > We recommend that implementation of PDM SHOULD have a limit on the > number of control block entries. =20 >=20 > NEW > ------- > 4.1. Resource Consumption and Resource Consumption Attacks >=20 > 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. =20 >=20 > A limit on how much memory is being used SHOULD be=20 > implemented. >=20 > 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. >=20 > 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=20= > implementation of the Destination Option extension header. >=20 >=20 >> 5) Also section 4.1 (security consideration): I don't think this = sentence is true: >> " For PDM, the amount of data to be kept is quite small. That is, the = control block is quite lightweight." >> Because you eventually have to hold this data per packet, so it can = grow quickly. However, this is also really an implementation question = only. You could >> also just store the delay calculation and not the whole control = block, or even an moving average of the delay which only needs a fixed = amount of memory for a few >> values. I really depends what your use case is for the information = provided by PDM. >=20 > Please let me know if the above changes to section 4.1 addresses your = concerns. Maybe this: OLD: "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.=E2=80=9C NEW: =E2=80=9EWithout a memory limit, 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 could be used to compromise the end host.=E2=80=9C Thanks, Mirja From nobody Fri May 5 08:17:39 2017 Return-Path: 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 6613E12969E for ; Fri, 5 May 2017 08:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=unavailable 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 pOmT1P76h4xA for ; Fri, 5 May 2017 08:17:25 -0700 (PDT) Received: from nm38-vm1.bullet.mail.gq1.yahoo.com (nm38-vm1.bullet.mail.gq1.yahoo.com [98.136.217.60]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2E7129A8F for ; Fri, 5 May 2017 08:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1493997437; bh=3IuYBxVfyzJ644skBBn809tNXmDNNNiNh6A4vagSE+E=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=iW4tKKVDaikmWwngRwgs8mD7ihLIPCs+F6g5EqEh598RrN1chIMcgbVJGViabwzoJykoXRknQ+8zjIwTU5Kom6dHI2OCT1nRnj15v6hYxb9Hw+5X/p7jQUlleh8r3UVPKIhoUEBR8hw6FOxCyWoLf8AIcxHTHcqMHgXl90xOFvD6sGbvsmrFyGVnMXR8qKukt4rPPtbtFHlRMtrvXybRYojvyXVpxwmsXAnlALmZKpFKa0hSLG00KLk1fuBm98sF+P049vPhak+ztc8vutiSJbZ7PRVpG3cvH9h25hKQGzjKDUUriZ8DP+gOuG47Yk1yvCtWiG4WQhcIIprK4Njamw== Received: from [127.0.0.1] by nm38.bullet.mail.gq1.yahoo.com with NNFMP; 05 May 2017 15:17:17 -0000 Received: from [98.137.12.189] by nm38.bullet.mail.gq1.yahoo.com with NNFMP; 05 May 2017 15:14:24 -0000 Received: from [98.137.12.206] by tm10.bullet.mail.gq1.yahoo.com with NNFMP; 05 May 2017 15:14:24 -0000 Received: from [127.0.0.1] by omp1014.mail.gq1.yahoo.com with NNFMP; 05 May 2017 15:14:24 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 156721.31051.bm@omp1014.mail.gq1.yahoo.com X-YMail-OSG: eK82bHYVRDtgfAoCqOIpFuQf7CXNzbPmvwqKAF0E6WpCYH8GW8U- Received: from jws300058.mail.gq1.yahoo.com by sendmailws148.mail.gq1.yahoo.com; Fri, 05 May 2017 15:14:23 +0000; 1493997263.741 Date: Fri, 5 May 2017 15:14:23 +0000 (UTC) From: Reply-To: To: , "Mirja Kuehlewind (IETF)" Cc: The IESG , , , Bill Cerveny , , Message-ID: <1925618131.4324891.1493997263218@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <1925618131.4324891.1493997263218.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9539 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36 Archived-At: Subject: Re: [ippm] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ippm-6man-pdm-option-09=3A_=28with_COMMENT=29?= X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 15:17:28 -0000 Mirja, Thanks for your comments. My replies inline. As stated below, I will create a new version with the appendix and the chan= ges agreed upon so far. Then, we can continue. Thanks so much to Spenc= er and Al for their sage guidance through this process. =20 Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Tue, 5/2/17, Mirja Kuehlewind (IETF) wrote: Subject: Re: Mirja K=C3=BChlewind's No Objection on draft-ietf-ippm-6man-p= dm-option-09: (with COMMENT) To: nalini.elkins@insidethestack.com Cc: "The IESG" , draft-ietf-ippm-6man-pdm-option@ietf.org, = acmorton@att.com, "Bill Cerveny" , ippm-chairs@ietf.org= , ippm@ietf.org Date: Tuesday, May 2, 2017, 3:58 AM =20 >>-------------------------------------------- >>On Wed, 4/12/17, Mirja K=C3=BChlewind >wrote: >> >>Subject: Mirja K=C3=BChlewind's No Objection on draft-ietf-ippm-6man-pdm-= option-09: (with COMMENT) >>To: "The IESG" >>Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@at= t.com, ippm@ietf.org >>Date: Wednesday, April 12, 2017, 10:53 AM >> >>Mirja K=C3=BChlewind 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: http= s://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ >> >> >>---------------------------------------------------------------------- >>COMMENT: >>---------------------------------------------------------------------- >> >> >>>My main concern is that part of this document read like an advertisement= (e.g. "In our experience, valuable time is often lost.." whose >>>experience? The IETF? This is an IETF RFC!). I think most of this text i= s not needed to understand the option and therefore should simply be >>>removed. More concretely, I propose to remove sections 1.2, 1.3., and 1.= 5 as well as paragraphs 4-8 of section 1.4 (starting with "In our >>>experience, valuable time is often lost..." to the end).=20 >> >>I think that RFCs are often lacking context which makes them difficult fo= r new people or even people not intimately involved in the creation >>of the draft to understand why they are being written. =20 > I disagree. The important part of a protocol spec is that it is well defi= ned and to the point, so implementors can easily implement it correctly wit= hout > having knowledge about all the background discussions that happen in the = working group. Sure. >>I am OK with moving the information to an appendix. What do you think? > I don=E2=80=99t think these section actually provide information that is = useful for implementor but I=E2=80=99m okay with moving them to the appendi= x. I would still > recommend to remove any language on business model at least in section 1.= 2 (or remove at least 1.2 completely). OK. I will create a new version with a revised appendix and then wait for = your comments. >> >>One question though, I believe you mean "paragraphs 4-8 of section 1.4 (E= NDING with "In our experience, valuable time is often lost...").=20 >>The phrase "In our experience, valuable time is often lost..." is the ve= ry last sentence of section 1.4.=20 > Yes, sorry. I meat starting with "One of the important functions=E2=80=9C= .=20 > One important point here about the language is that this document seems t= o be written with the view of a specific group. However as RFC=20 > it=E2=80=99s an IETF consensus document with represents the IETF=E2=80=99= s view as a whole. So any phrasing like "In our experience,=E2=80=A6=E2=80= =9C or =E2=80=9Ewe can=E2=80=9C/=E2=80=9Ewe may=E2=80=9C=20 > seems not appropriate here and should be removed even if the text is move= d to the appendix. I will doublecheck that wording and remove. >> >> >>>I would also recommend these two changes to shorten the RFC:=20 >>>- section 3.2.3. could just be moved into the appendix. >> >>Fine. >> >>I will move: "3.2.3 Considerations of this time-differential representati= on" into an appendix >> >>>- the diagrams from RFC4303 in sections 3.4.1. and 3.4.2 are not needed >> >>OK. >> >>>In general I think another editing pass could help to bring the document >>>more to the point in a couple of cases. But that's not really an issue. >> >> >>>Further comments: >> >>>1) This text in 3.4.2 is a bit confusing: >>>"As a completely new IP packet will be made, it means that PDM informati= on for that packet does not contain any information from the inner packet, = i.e. the PDM information will NOT be based on the >>>transport layer (TCP, UDP, etc) ports etc in the inner header, but will = be specific to the ESP flow.=20 >> >>> If PDM information for the inner packet is desired, the original host s= ending the inner packet needs to put PDM header in the tunneled packet, and= then the PDM information will be specific for that >>>stream." >> >>>I think what you want to say is something like >> >>>"A tunnel endpoint that creates a new packet may decide to use PDM indep= endent of the use of PDM of the original packet to enable delay measurement= s between the two tunnel endpoints." >>>Correct? >> >>Yes, I think your wording represents what I wanted to convey and does it = better. >> >> >>>2) I'm not sure this is really useful to specify normatively in an RFC a= s this is really implementation specific: >>>"The PDM destination options extension header MUST be explicitly turned = on by each stack on a host node by administrative action. The default value= of PDM is off." >>>I would recommend the following text instead (without normative language= ): >>>"An implementation should provide an interface to enable or disable the = use of PDM. This specification recommends to turn PDM off by default." >> >>I believe you are speaking of section 3.5.1 >> >>The reason for this was because an implementation could be created which = automatically and dynamically turned on PDM when a packet containing a PDM = header was received. Then, PDM would be used >>without the host being explicitly aware of it. And a number of unfortuna= te things such as information leakage, DOS attacks, etc might happen. So, = we added language to say that administrative action is required. This issu= e was brought up by the security area review of this document. >> >>The issue mentioned above is dealt with explicitly in section 3.5.1. The= entire text is below: >> >>Current text >>---------------- >> >>3.5.1 PDM Activation >> >> The PDM destination options extension header MUST be explicitly turned= on by each stack on a host node by administrative action. The default valu= e of PDM is off. >> >> PDM MUST NOT be turned on merely if a packet is received with a PDM he= ader. The received packet could be spoofed by another device. > I understand the intention here and the intention is correct. My comment = was that the use of normative language here might not be really appropriate= because=20 > this part does not talk about the protocol itself but the interface to th= e higher layer and this depends very much on the use case and environment i= n which it is=20 > implemented. Therefore I would recommend to not use normative language he= re. OK. Will change. >> >> >> >>>3) I don't understand section 3.6. Isn't that redundant with 3.5.1? Or w= hat's meant by 'dynamic configuration option'? In any case, I don't >>>think the use of normative language is appropriate here. >> >>This was also brought up by Warren. He accepted the change below. Pleas= e let me know if that also works for you. >> >>Current text >>---------------- >> >>3.6 Dynamic Configuration Options >> >>If implemented, each operating system MUST have a default configuration p= arameter, e.g. diag_header_sys_default_value=3Dyes/no. The operating system= MAY also have a dynamic configuration option to >>change the configuration setting as needed. >> >>If the PDM destination options extension header is used, then it MAY be t= urned on for all packets flowing through the host, applied to an upper-laye= r protocol (TCP, UDP, SCTP, etc), a local port, or IP >>address only. These are at the discretion of the implementation. >> >> >>New text >>----------- >> >>3.6 Filtering of PDM >> >>If the PDM destination options extension header is used, then it MAY be t= urned on for all packets flowing through the host, applied to an upper-laye= r protocol (TCP, UDP, SCTP, etc), a local port, or IP >>address only. These are at the discretion of the implementation. > Okay. >> >> >>>4) I would also like to propose new text on 3.6 5-tuple Aging (btw. 3.6.= exists twice) >> >>Thanks will fix the 3.6 twice. >> >>>OLD >> >>>"3.6 5-tuple Aging >> >>>Within the operating system, metrics must be kept on a 5-tuple basis. >> >>>The question comes of when to stop keeping data or restarting the number= ing for a 5-tuple. For example, in the case of TCP, at some >>> point, the connection will terminate. Keeping data in control blocks f= orever, will have unfortunate consequences for the operating >>>system. >> >>> So, the recommendation is to use a known aging parameter such as Max Se= gment Lifetime (MSL) as defined in Transmission Control Protocol >>> [RFC0793] to reuse or drop the control block. The choice of aging para= meter is left up to the implementation." >> >>>NEW >> >>>"3.6 Information Access and Storage >> >>>Measurement information provided by PDM must be made accessible for high= er layers or the user itself. Similar as activating the use of >>>PDM, the implementation may also provide an interface to indicate if rec= eived >> >>>PDM information should be stored or not. If a packet with PDM informatio= n is received and the information should be stored, the upper layers may be >>>notified. Further it is recommend to define a configurable maximum lifet= ime after which the information can be removed as well as >>>a configurable maximum amount of memory that should be allocated for PDM= information." >> >>>This text also addresses some of the "SYN flood attack" concerns as desc= ribed in the security considerations section. I would recommend to rewrite = this >>>section as well and I would also recommend to not use the term SYN flood= as that is clearly associated with TCP only. >> >>As far as: >> >>"Measurement information provided by PDM must be made accessible for high= er layers or the user itself." >> >>The information in PDM is in the extension header. What we had envisione= d is that diagnostics would be done by capturing a packet trace. But, cert= ainly what=20 >>you suggest is very interesting. Higher layers as well as the user could= make very good use of PDM information. =20 >> >>Are you OK with a minor change to that sentence to say: >> >>"Measurement information provided by PDM may be made accessible for highe= r layers or the user itself.=E2=80=9C >> > Okay.=20 >>As far as the rest of the text in that paragraph, I am fine with it. In = fact, in working on implementation, we are doing exactly that: a configura= ble amount of memory / lifetime. >>Actually, only memory is needed as then it controls everything else quite= well. This is why we said "limit on control blocks" in the security sec= tion. I will make it >>more explicit that what is meant by control blocks is memory. >> >> >>Current Security 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. =20 >> >>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. =20 >> >> A limit on how much memory is being used SHOULD be=20 >> 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=20 >> implementation of the Destination Option extension header. >> >> >>>5) Also section 4.1 (security consideration): I don't think this sentenc= e is true: >>>" For PDM, the amount of data to be kept is quite small. That is, the co= ntrol block is quite lightweight." >>>Because you eventually have to hold this data per packet, so it can grow= quickly. However, this is also really an implementation question only. Yo= u could >>>also just store the delay calculation and not the whole control block, o= r even an moving average of the delay which only needs a fixed amount of me= mory for a few >>>values. I really depends what your use case is for the information prov= ided by PDM. >> >>Please let me know if the above changes to section 4.1 addresses your con= cerns. > Maybe this: > OLD: >"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.=E2=80=9C > NEW: >=E2=80=9EWithout a memory limit, any time a control block is kept in memor= y, an attacker >can try to mis-use the control blocks to cause excessive resource > consumption. This could be used to compromise the end host.=E2=80=9C Fine. Thanks, Nalini From nobody Fri May 5 08:28:13 2017 Return-Path: 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 D06A1129521 for ; Fri, 5 May 2017 08:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 RNviBzHBmWZz for ; Fri, 5 May 2017 08:28:06 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 55080129557 for ; Fri, 5 May 2017 08:28:06 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id n4so7727000qte.2 for ; Fri, 05 May 2017 08:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ubhD2ir0oI/aMoCqnxRby0wGQ2ci45juRM71E3EfxQk=; b=EA9Z6X0xZHYHqBi5UnpsqINqxMMSR56vuID9W5TnegDxX3dGiRNTVei43YGB82j2/w k9BWrNNn+2QRTs6Us6s6RA8d1nN9r1n+FvzjPdRHL+BrhFhfGHgfFNb0XI0KQhkyAaUr NSDOABYPuogTfjzqKmGEva4gxtYkarHAGJXXKC8ZCre07yWDxaMSsfkIxKPe/nICizSN U8xKsxuzM6ObOF1qd8Y+LRYckdJWTc2aowRglSAg2pTYk5+LHSdM2smWVAX8pegwORFY NOOKjg64BP8BDnZrhQlRqqeAqcNNqY5BIOjsuIveSVchCpRjayPZnJY5txFjfLjMxmgE 1R/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ubhD2ir0oI/aMoCqnxRby0wGQ2ci45juRM71E3EfxQk=; b=tQt9MJpe559au9VAkyNpIkQrcOiHZh3xdT6aR2dW6bK5fDoenrVynXxvxVEZwROXFJ XcJfutWro+4esjOZjHVwyQRx/6QvMdynpL0ZH0+HIrb/bXo7aE8jqwYhTibEtknvU8tB QMpHtiOhBkv98hyMvTSv9ocMoceLr+agbXibBAGdG6BwiLYl8Dux7xxmU2EVtGKcu3mW VjDWm6OEel8pICskJ5cbAQVmIkLtYMRYYHZoGZ3oTOk9O9w1U1r82eUvgBXJOO8wNs17 tQOi84pBPG8PES0TRmPZxhYk8f+/UzXTfG0ADoi3wiJ9/ZvsnhuWoAyDL3iQ0EVZWwcZ 9i4A== X-Gm-Message-State: AN3rC/6iX4ic17Nt9RBJEOk4hYR6wlDiz0bd6NOIIaiEYHREPaGDzZP4 JoBpgy84r7B5AOa4mKApg0tJFEcL6Ae1 X-Received: by 10.237.59.75 with SMTP id q11mr17090972qte.265.1493998085263; Fri, 05 May 2017 08:28:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.171.68 with HTTP; Fri, 5 May 2017 08:27:24 -0700 (PDT) In-Reply-To: <1925618131.4324891.1493997263218@mail.yahoo.com> References: <1925618131.4324891.1493997263218.ref@mail.yahoo.com> <1925618131.4324891.1493997263218@mail.yahoo.com> From: Warren Kumari Date: Fri, 5 May 2017 11:27:24 -0400 Message-ID: To: Nalini Elkins Cc: "Mirja Kuehlewind (IETF)" , ippm-chairs@ietf.org, "MORTON, ALFRED C (AL)" , ippm@ietf.org, Bill Cerveny , draft-ietf-ippm-6man-pdm-option@ietf.org, The IESG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ippm-6man-pdm-option-09=3A_=28with_COMMENT=29?= X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 15:28:10 -0000 I'm still holding a DISCUSS on this - the proposed changes by Nalini to address my concerns (earlier / in a different thread) are fine with me and address my concerns. Being unfamiliar with the custom (and blindly following the text on the DISCUSS page) I'd originally said that I'd remove my discuss once a new version was published - but I trust Spencer / the authors to include the promised, and so am clearing my DISCUSS.... Thanks all, W On Fri, May 5, 2017 at 11:14 AM, wrote: > Mirja, > > Thanks for your comments. > > My replies inline. > > As stated below, I will create a new version with the appendix and the ch= anges agreed upon so far. Then, we can continue. Thanks so much to Spe= ncer and Al for their sage guidance through this process. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > -------------------------------------------- > On Tue, 5/2/17, Mirja Kuehlewind (IETF) wrote: > > Subject: Re: Mirja K=C3=BChlewind's No Objection on draft-ietf-ippm-6man= -pdm-option-09: (with COMMENT) > To: nalini.elkins@insidethestack.com > Cc: "The IESG" , draft-ietf-ippm-6man-pdm-option@ietf.org= , acmorton@att.com, "Bill Cerveny" , ippm-chairs@ietf.o= rg, ippm@ietf.org > Date: Tuesday, May 2, 2017, 3:58 AM > >>>-------------------------------------------- >>>On Wed, 4/12/17, Mirja K=C3=BChlewind >wrote: >>> >>>Subject: Mirja K=C3=BChlewind's No Objection on draft-ietf-ippm-6man-pdm= -option-09: (with COMMENT) >>>To: "The IESG" >>>Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@a= tt.com, ippm@ietf.org >>>Date: Wednesday, April 12, 2017, 10:53 AM >>> >>>Mirja K=C3=BChlewind 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.htm= l for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>>The document, along with other ballot positions, can be found here: htt= ps://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ >>> >>> >>>---------------------------------------------------------------------- >>>COMMENT: >>>---------------------------------------------------------------------- >>> >>> >>>>My main concern is that part of this document read like an advertisemen= t (e.g. "In our experience, valuable time is often lost.." whose >>>>experience? The IETF? This is an IETF RFC!). I think most of this text = is not needed to understand the option and therefore should simply be >>>>removed. More concretely, I propose to remove sections 1.2, 1.3., and 1= .5 as well as paragraphs 4-8 of section 1.4 (starting with "In our >>>>experience, valuable time is often lost..." to the end). >>> >>>I think that RFCs are often lacking context which makes them difficult f= or new people or even people not intimately involved in the creation >>>of the draft to understand why they are being written. > >> I disagree. The important part of a protocol spec is that it is well def= ined and to the point, so implementors can easily implement it correctly wi= thout >> having knowledge about all the background discussions that happen in the= working group. > > Sure. > > >>>I am OK with moving the information to an appendix. What do you think? > >> I don=E2=80=99t think these section actually provide information that is= useful for implementor but I=E2=80=99m okay with moving them to the append= ix. I would still >> recommend to remove any language on business model at least in section 1= .2 (or remove at least 1.2 completely). > > OK. I will create a new version with a revised appendix and then wait fo= r your comments. > > >>> >>>One question though, I believe you mean "paragraphs 4-8 of section 1.4 (= ENDING with "In our experience, valuable time is often lost..."). >>>The phrase "In our experience, valuable time is often lost..." is the v= ery last sentence of section 1.4. > >> Yes, sorry. I meat starting with "One of the important functions=E2=80= =9C. > >> One important point here about the language is that this document seems = to be written with the view of a specific group. However as RFC >> it=E2=80=99s an IETF consensus document with represents the IETF=E2=80= =99s view as a whole. So any phrasing like "In our experience,=E2=80=A6=E2= =80=9C or =E2=80=9Ewe can=E2=80=9C/=E2=80=9Ewe may=E2=80=9C >> seems not appropriate here and should be removed even if the text is mov= ed to the appendix. > > I will doublecheck that wording and remove. > > >>> >>> >>>>I would also recommend these two changes to shorten the RFC: >>>>- section 3.2.3. could just be moved into the appendix. >>> >>>Fine. >>> >>>I will move: "3.2.3 Considerations of this time-differential representat= ion" into an appendix > >>> >>>>- the diagrams from RFC4303 in sections 3.4.1. and 3.4.2 are not needed >>> >>>OK. >>> >>>>In general I think another editing pass could help to bring the documen= t >>>>more to the point in a couple of cases. But that's not really an issue. >>> >>> >>>>Further comments: >>> >>>>1) This text in 3.4.2 is a bit confusing: >>>>"As a completely new IP packet will be made, it means that PDM informat= ion for that packet does not contain any information from the inner packet,= i.e. the PDM information will NOT be based on the >>>>transport layer (TCP, UDP, etc) ports etc in the inner header, but will= be specific to the ESP flow. >>> >>>> If PDM information for the inner packet is desired, the original host = sending the inner packet needs to put PDM header in the tunneled packet, an= d then the PDM information will be specific for that >>>>stream." >>> >>>>I think what you want to say is something like >>> >>>>"A tunnel endpoint that creates a new packet may decide to use PDM inde= pendent of the use of PDM of the original packet to enable delay measuremen= ts between the two tunnel endpoints." >>>>Correct? >>> >>>Yes, I think your wording represents what I wanted to convey and does it= better. >>> >>> >>>>2) I'm not sure this is really useful to specify normatively in an RFC = as this is really implementation specific: >>>>"The PDM destination options extension header MUST be explicitly turned= on by each stack on a host node by administrative action. The default valu= e of PDM is off." >>>>I would recommend the following text instead (without normative languag= e): >>>>"An implementation should provide an interface to enable or disable the= use of PDM. This specification recommends to turn PDM off by default." >>> >>>I believe you are speaking of section 3.5.1 >>> >>>The reason for this was because an implementation could be created which= automatically and dynamically turned on PDM when a packet containing a PDM= header was received. Then, PDM would be used >>>without the host being explicitly aware of it. And a number of unfortun= ate things such as information leakage, DOS attacks, etc might happen. So,= we added language to say that administrative action is required. This iss= ue was brought up by the security area review of this document. >>> >>>The issue mentioned above is dealt with explicitly in section 3.5.1. Th= e entire text is below: >>> >>>Current text >>>---------------- >>> >>>3.5.1 PDM Activation >>> >>> The PDM destination options extension header MUST be explicitly turne= d on by each stack on a host node by administrative action. The default val= ue of PDM is off. >>> >>> PDM MUST NOT be turned on merely if a packet is received with a PDM h= eader. The received packet could be spoofed by another device. > > >> I understand the intention here and the intention is correct. My comment= was that the use of normative language here might not be really appropriat= e because >> this part does not talk about the protocol itself but the interface to t= he higher layer and this depends very much on the use case and environment = in which it is >> implemented. Therefore I would recommend to not use normative language h= ere. > > OK. Will change. > >>> >>> >>> >>>>3) I don't understand section 3.6. Isn't that redundant with 3.5.1? Or = what's meant by 'dynamic configuration option'? In any case, I don't >>>>think the use of normative language is appropriate here. >>> >>>This was also brought up by Warren. He accepted the change below. Plea= se let me know if that also works for you. >>> >>>Current text >>>---------------- >>> >>>3.6 Dynamic Configuration Options >>> >>>If implemented, each operating system MUST have a default configuration = parameter, e.g. diag_header_sys_default_value=3Dyes/no. The operating syste= m MAY also have a dynamic configuration option to >>>change the configuration setting as needed. >>> >>>If the PDM destination options extension header is used, then it MAY be = turned on for all packets flowing through the host, applied to an upper-lay= er protocol (TCP, UDP, SCTP, etc), a local port, or IP >>>address only. These are at the discretion of the implementation. >>> >>> >>>New text >>>----------- >>> >>>3.6 Filtering of PDM >>> >>>If the PDM destination options extension header is used, then it MAY be = turned on for all packets flowing through the host, applied to an upper-lay= er protocol (TCP, UDP, SCTP, etc), a local port, or IP >>>address only. These are at the discretion of the implementation. > > >> Okay. > >>> >>> >>>>4) I would also like to propose new text on 3.6 5-tuple Aging (btw. 3.6= . exists twice) >>> >>>Thanks will fix the 3.6 twice. >>> >>>>OLD >>> >>>>"3.6 5-tuple Aging >>> >>>>Within the operating system, metrics must be kept on a 5-tuple basis. >>> >>>>The question comes of when to stop keeping data or restarting the numbe= ring for a 5-tuple. For example, in the case of TCP, at some >>>> point, the connection will terminate. Keeping data in control blocks = forever, will have unfortunate consequences for the operating >>>>system. >>> >>>> So, the recommendation is to use a known aging parameter such as Max S= egment Lifetime (MSL) as defined in Transmission Control Protocol >>>> [RFC0793] to reuse or drop the control block. The choice of aging par= ameter is left up to the implementation." >>> >>>>NEW >>> >>>>"3.6 Information Access and Storage >>> >>>>Measurement information provided by PDM must be made accessible for hig= her layers or the user itself. Similar as activating the use of >>>>PDM, the implementation may also provide an interface to indicate if re= ceived >>> >>>>PDM information should be stored or not. If a packet with PDM informati= on is received and the information should be stored, the upper layers may b= e >>>>notified. Further it is recommend to define a configurable maximum life= time after which the information can be removed as well as >>>>a configurable maximum amount of memory that should be allocated for PD= M information." >>> >>>>This text also addresses some of the "SYN flood attack" concerns as des= cribed in the security considerations section. I would recommend to rewrite= this >>>>section as well and I would also recommend to not use the term SYN floo= d as that is clearly associated with TCP only. >>> >>>As far as: >>> >>>"Measurement information provided by PDM must be made accessible for hig= her layers or the user itself." >>> >>>The information in PDM is in the extension header. What we had envision= ed is that diagnostics would be done by capturing a packet trace. But, cer= tainly what >>>you suggest is very interesting. Higher layers as well as the user coul= d make very good use of PDM information. >>> >>>Are you OK with a minor change to that sentence to say: >>> >>>"Measurement information provided by PDM may be made accessible for high= er layers or the user itself.=E2=80=9C >>> > >> Okay. > > >>>As far as the rest of the text in that paragraph, I am fine with it. In= fact, in working on implementation, we are doing exactly that: a configur= able amount of memory / lifetime. >>>Actually, only memory is needed as then it controls everything else quit= e well. This is why we said "limit on control blocks" in the security se= ction. I will make it >>>more explicit that what is meant by control blocks is memory. >>> >>> >>>Current Security 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. >>> >>> >>>>5) Also section 4.1 (security consideration): I don't think this senten= ce is true: >>>>" For PDM, the amount of data to be kept is quite small. That is, the c= ontrol block is quite lightweight." >>>>Because you eventually have to hold this data per packet, so it can gro= w quickly. However, this is also really an implementation question only. Y= ou could >>>>also just store the delay calculation and not the whole control block, = or even an moving average of the delay which only needs a fixed amount of m= emory for a few >>>>values. I really depends what your use case is for the information pro= vided by PDM. >>> >>>Please let me know if the above changes to section 4.1 addresses your co= ncerns. > >> Maybe this: > >> OLD: > >>"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.=E2=80=9C > >> NEW: > >>=E2=80=9EWithout a memory limit, any time a control block is kept in memo= ry, an attacker >>can try to mis-use the control blocks to cause excessive resource >> consumption. This could be used to compromise the end host.=E2=80=9C > > > Fine. > > Thanks, > Nalini > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri May 5 08:32:20 2017 Return-Path: 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 6570C129A9C for ; Fri, 5 May 2017 08:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.409 X-Spam-Level: X-Spam-Status: No, score=0.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309] 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 q0sp_iUwIwHb for ; Fri, 5 May 2017 08:32:04 -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 BF6F2129A9B for ; Fri, 5 May 2017 08:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1493998321; bh=+V1VTYxCT3/JIpJ2k0S9qjrSNUeToeGVYcUl46YfscE=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=iEYVbz2yEXZxp1Nr5Kf5Wau6vZNWrbhzn9//Ib2Dg/iJr+FxMsUtfOdoAUYQHiZFoxbBl4m2PXMDJSALRIJ0z5TZwOHZx18qLVbQHtY166uLE31m7SCvW2gYMkKI5aTfZHnD51kE1uByjMugKdrO8dDLGIQGmfrh7gCdDBs2X42TVQXMwmNISQy0gCPjTCFFFx+uIWr0P/vPQFc410LFMZF/rdFBSAVYZSWIFw2d/ApUHKoxoFiGnITnOwRCR7l2QRMTdKMvuDaM0B3WrCda17C8Aba9fPqxzun9kDMCjFXMqXNHLoMGrlrbfdm0vzkrQSv7WMCVexo1LtB57tvc9g== X-YMail-OSG: eK82bHYVRDtgfAoCqOIpFuQf7CXNzbPmvwqKAF0E6WpCYH8GW8U- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 5 May 2017 15:32:01 +0000 Date: Fri, 5 May 2017 15:32:00 +0000 (UTC) From: Reply-To: To: Nalini Elkins , Warren Kumari Cc: "Mirja Kuehlewind (IETF)" , , " ALFRED C (AL)MORTON" , , Bill Cerveny , , The IESG Message-ID: <1069726291.4378413.1493998320896@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <1069726291.4378413.1493998320896.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9539 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36 Archived-At: Subject: Re: [ippm] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ippm-6man-pdm-option-09=3A_=28with_COMMENT=29?= X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 15:32:07 -0000 Thanks, Warren! I am keeping track of all the changes promised & keeping Spencer / Al / the= co-authors updated. Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Fri, 5/5/17, Warren Kumari wrote: Subject: Re: Mirja K=C3=BChlewind's No Objection on draft-ietf-ippm-6man-p= dm-option-09: (with COMMENT) To: "Nalini Elkins" Cc: "Mirja Kuehlewind (IETF)" , ippm-chairs@ietf.org,= "MORTON, ALFRED C (AL)" , ippm@ietf.org, "Bill Cerveny" = , draft-ietf-ippm-6man-pdm-option@ietf.org, "The IESG" = Date: Friday, May 5, 2017, 8:27 AM =20 I'm still holding a DISCUSS on this - the proposed changes by Nalini to address my concerns (earlier / in a different thread) are fine with me and address my concerns. Being unfamiliar with the custom (and blindly following the text on the DISCUSS page) I'd originally said that I'd remove my discuss once a new version was published - but I trust Spencer / the authors to include the promised, and so am clearing my DISCUSS.... =20 Thanks all, W =20 On Fri, May 5, 2017 at 11:14 AM,=C2=A0 wrote: > Mirja, > > Thanks for your comments. > > My replies inline. > > As stated below, I will create a new version with the appendix and the changes agreed upon so far.=C2=A0 =C2=A0 Then, we can continue.=C2=A0 Thanks so much to Spencer and Al for their sage guidance through this process. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > -------------------------------------------- > On Tue, 5/2/17, Mirja Kuehlewind (IETF) wrote: > >=C2=A0 Subject: Re: Mirja K=C3=BChlewind's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) >=C2=A0 To: nalini.elkins@insidethestack.com >=C2=A0 Cc: "The IESG" , draft-ietf-ippm-6man-pdm-option@ietf.org, acmorton@att.com, "Bill Cerveny" , ippm-chairs@ietf.org, ippm@ietf.org >=C2=A0 Date: Tuesday, May 2, 2017, 3:58 AM > >>>-------------------------------------------- >>>On Wed, 4/12/17, Mirja K=C3=BChlewind >wrote: >>> >>>Subject: Mirja K=C3=BChlewind's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) >>>To: "The IESG" >>>Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org >>>Date: Wednesday, April 12, 2017, 10:53 AM >>> >>>Mirja K=C3=BChlewind 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:=C2=A0 https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-opti= on/ >>> >>> >>>---------------------------------------------------------------------- >>>COMMENT: >>>---------------------------------------------------------------------- >>> >>> >>>>My main concern is that part of this document read like an advertisement (e.g. "In our experience, valuable time is often lost.." whose >>>>experience? The IETF? This is an IETF RFC!). I think most of this text is not needed to understand the option and therefore should simply be >>>>removed. More concretely, I propose to remove sections 1.2, 1.3., and 1.5 as well as paragraphs 4-8 of section 1.4 (starting with "In our >>>>experience, valuable time is often lost..." to the end). >>> >>>I think that RFCs are often lacking context which makes them difficult for new people or even people not intimately involved in the creation >>>of the draft to understand why they are being written. > >> I disagree. The important part of a protocol spec is that it is well defined and to the point, so implementors can easily implement it correctly without >> having knowledge about all the background discussions that happen in the working group. > > Sure. > > >>>I am OK with moving the information to an appendix.=C2=A0 What do you think? > >> I don=E2=80=99t think these section actually provide information that is useful for implementor but I=E2=80=99m okay with moving them to the appendix. I would still >> recommend to remove any language on business model at least in section 1.2 (or remove at least 1.2 completely). > > OK.=C2=A0 I will create a new version with a revised appendix and then wait for your comments. > > >>> >>>One question though, I believe you mean "paragraphs 4-8 of section 1.4 (ENDING with "In our experience, valuable time is often lost..."). >>>The=C2=A0 phrase "In our experience, valuable time is often lost..." is the very last sentence of section 1.4. > >> Yes, sorry. I meat starting with "One of the important functions=E2=80=9C. > >> One important point here about the language is that this document seems to be written with the view of a specific group. However as RFC >> it=E2=80=99s an IETF consensus document with represents the IETF=E2=80=99s view as a whole. So any phrasing like "In our experience,=E2=80=A6=E2=80=9C or =E2=80=9Ewe can=E2=80=9C/=E2=80=9Ewe may=E2=80=9C >> seems not appropriate here and should be removed even if the text is moved to the appendix. > > I will doublecheck that wording and remove. > > >>> >>> >>>>I would also recommend these two changes to shorten the RFC: >>>>- section 3.2.3. could just be moved into the appendix. >>> >>>Fine. >>> >>>I will move: "3.2.3 Considerations of this time-differential representation" into an appendix > >>> >>>>- the diagrams from RFC4303 in sections 3.4.1. and 3.4.2 are not needed >>> >>>OK. >>> >>>>In general I think another editing pass could help to bring the document >>>>more to the point in a couple of cases. But that's not really an issue. >>> >>> >>>>Further comments: >>> >>>>1) This text in 3.4.2 is a bit confusing: >>>>"As a completely new IP packet will be made, it means that PDM information for that packet does not contain any information from the inner packet, i.e. the PDM information will NOT be based on the >>>>transport layer (TCP, UDP, etc) ports etc in the inner header, but will be specific to the ESP flow. >>> >>>> If PDM information for the inner packet is desired, the original host sending the inner packet needs to put PDM header in the tunneled packet, and then the PDM information will be specific for that >>>>stream." >>> >>>>I think what you want to say is something like >>> >>>>"A tunnel endpoint that creates a new packet may decide to use PDM independent of the use of PDM of the original packet to enable delay measurements between the two tunnel endpoints." >>>>Correct? >>> >>>Yes, I think your wording represents what I wanted to convey and does it better. >>> >>> >>>>2) I'm not sure this is really useful to specify normatively in an RFC as this is really implementation specific: >>>>"The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off." >>>>I would recommend the following text instead (without normative language): >>>>"An implementation should provide an interface to enable or disable the use of PDM.=C2=A0 This specification recommends to turn PDM off by default." >>> >>>I believe you are speaking of section 3.5.1 >>> >>>The reason for this was because an implementation could be created which automatically and dynamically turned on PDM when a packet containing a PDM header was received.=C2=A0 Then, PDM would be used >>>without the host being explicitly aware of it.=C2=A0 And a number of unfortunate things such as information leakage, DOS attacks, etc might happen.=C2=A0 So, we added language to say that administrative action is required.=C2=A0 This issue was brought up by the security area review of this document. >>> >>>The issue mentioned above is dealt with explicitly in section 3.5.1.=C2=A0 The entire text is below: >>> >>>Current text >>>---------------- >>> >>>3.5.1 PDM Activation >>> >>>=C2=A0 The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off. >>> >>>=C2=A0 PDM MUST NOT be turned on merely if a packet is received with a PDM header. The received packet could be spoofed by another device. > > >> I understand the intention here and the intention is correct. My comment was that the use of normative language here might not be really appropriate because >> this part does not talk about the protocol itself but the interface to the higher layer and this depends very much on the use case and environment in which it is >> implemented. Therefore I would recommend to not use normative language here. > > OK.=C2=A0 Will change. > >>> >>> >>> >>>>3) I don't understand section 3.6. Isn't that redundant with 3.5.1? Or what's meant by 'dynamic configuration option'? In any case, I don't >>>>think the use of normative language is appropriate here. >>> >>>This was also brought up by Warren.=C2=A0 He accepted the change below.=C2=A0 Please let me know if that also works for you. >>> >>>Current text >>>---------------- >>> >>>3.6 Dynamic Configuration Options >>> >>>If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=3Dyes/no. The operating system MAY also have a dynamic configuration option to >>>change the configuration setting as needed. >>> >>>If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP >>>address only.=C2=A0 These are at the discretion of the implementation. >>> >>> >>>New text >>>----------- >>> >>>3.6 Filtering of PDM >>> >>>If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP >>>address only.=C2=A0 These are at the discretion of the implementation. > > >> Okay. > >>> >>> >>>>4) I would also like to propose new text on 3.6 5-tuple Aging (btw. 3.6. exists twice) >>> >>>Thanks will fix the 3.6 twice. >>> >>>>OLD >>> >>>>"3.6 5-tuple Aging >>> >>>>Within the operating system, metrics must be kept on a 5-tuple basis. >>> >>>>The question comes of when to stop keeping data or restarting the numbering for a 5-tuple.=C2=A0 For example, in the case of TCP, at some >>>> point, the connection will terminate.=C2=A0 Keeping data in control blocks forever, will have unfortunate consequences for the operating >>>>system. >>> >>>> So, the recommendation is to use a known aging parameter such as Max Segment Lifetime (MSL) as defined in Transmission Control Protocol >>>> [RFC0793] to reuse or drop the control block.=C2=A0 The choice of aging parameter is left up to the implementation." >>> >>>>NEW >>> >>>>"3.6 Information Access and Storage >>> >>>>Measurement information provided by PDM must be made accessible for higher layers or the user itself. Similar as activating the use of >>>>PDM, the implementation may also provide an interface to indicate if received >>> >>>>PDM information should be stored or not. If a packet with PDM information is received and the information should be stored, the upper layers may be >>>>notified. Further it is recommend to define a configurable maximum lifetime after which the information can be removed as well as >>>>a configurable maximum amount of memory that should be allocated for PDM information." >>> >>>>This text also addresses some of the "SYN flood attack" concerns as described in the security considerations section. I would recommend to rewrite this >>>>section as well and I would also recommend to not use the term SYN flood as that is clearly associated with TCP only. >>> >>>As far as: >>> >>>"Measurement information provided by PDM must be made accessible for higher layers or the user itself." >>> >>>The information in PDM is in the extension header.=C2=A0 What we had envisioned is that diagnostics would be done by capturing a packet trace.=C2=A0 But, certainly what >>>you suggest is very interesting.=C2=A0 Higher layers as well as the user could make very good use of PDM information. >>> >>>Are you OK with a minor change to that sentence to say: >>> >>>"Measurement information provided by PDM may be made accessible for higher layers or the user itself.=E2=80=9C >>> > >> Okay. > > >>>As far as the rest of the text in that paragraph, I am fine with it.=C2=A0 In fact, in working on implementation, we are doing exactly that:=C2=A0 a configurable amount of memory / lifetime. >>>Actually, only memory is needed as then it controls everything else quite well.=C2=A0 =C2=A0 This is why we said "limit on control blocks" in the security section.=C2=A0 I will make it >>>more explicit that what is meant by control blocks is memory. >>> >>> >>>Current Security 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.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 PDM is an >>> implementation of the Destination Option extension header. >>> >>> >>>>5) Also section 4.1 (security consideration): I don't think this sentence is true: >>>>" For PDM, the amount of data to be kept is quite small. That is, the control block is quite lightweight." >>>>Because you eventually have to hold this data per packet, so it can grow quickly.=C2=A0 However, this is also really an implementation question only. You could >>>>also just store the delay calculation and not the whole control block, or even an moving average of the delay which only needs a fixed amount of memory for a few >>>>values.=C2=A0 I really depends what your use case is for the information provided by PDM. >>> >>>Please let me know if the above changes to section 4.1 addresses your concerns. > >> Maybe this: > >> OLD: > >>"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.=E2=80=9C > >> NEW: > >>=E2=80=9EWithout a memory limit, 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 could be used to compromise the end host.=E2=80=9C > > > Fine. > > Thanks, > Nalini > =20 =20 =20 --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. =C2=A0 ---maf From nobody Fri May 5 19:16:21 2017 Return-Path: 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 93D0F128B91; Fri, 5 May 2017 19:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GWpefyeUxRhm; Fri, 5 May 2017 19:16:12 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 564051287A3; Fri, 5 May 2017 19:16:12 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id p143so1768461yba.2; Fri, 05 May 2017 19:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4pmCpgMrl2+Qq4KEM3z22KZnVuwsstPxeEgnzn8ApAo=; b=uwWfxGD3B7vMhFYNzF1S9dwVMzEJKb6ttKoDkQmUETgXfIj9N0n5RgVkf1S/GodL6w 0dNTUorp9Pq1QjKZc29j1bKZoKXGCox6obv5duAqVt04BL5PB8lMucGMN0Qca/SzWbt6 pppMQouuIUeBOYpusZ8CfFr6LR21IAFHZdnTCEvKFEwdDbmP4zl2UgnPKBTKjF901AGC SlRuoSYAcFaIMLkE689Nk/Dmh7zxhr9Tt9RD0uJypQ21/RyldclREZlI2G1UXCAQtQ7M f+YPbkZyI0/LCvreXlBxjtJlaIwp1uLi46EhxtWLCwvL+x67GJgfBb4UWu4Eq0AVnOYJ 9CMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4pmCpgMrl2+Qq4KEM3z22KZnVuwsstPxeEgnzn8ApAo=; b=uaAYGWMcrNxag1Li8lTg96cNwQSP5c10bdLcjhVrtDgnqrA+u57JM3hpj87dfJxxHT KkJH2qa57wt9He90cx6exzP8WFMCK4zaGOYlGhWAIyGiv23AW3V+A2WqwHY3IFhTQoNe RMVWWcYUFfODSTlDOtoL2cvKPYUN/QjLNm6G8bbf6sTco35int8VfpNy8FA7JQMnHtq8 KjEIIAD4WMFlm4JV61dIyN3895aDi6JO+adIOnO9q0Nhm7f7KC1fUEw5t7KxNy4Un7TG vhi42zDo3fipN6W8+NlJ9oQGu7NDGi47muedgWJOUsF7Jrb4vRT/CDJvOXSthlsc+xk+ Bfsw== X-Gm-Message-State: AODbwcCEq82sNinrnNmN8GHzai8Yi8YN6oCgWMjrH0HNGAavOgmZPXJj omVNPO0C58eV5QivhLJZ7nNM43j53Q== X-Received: by 10.37.177.32 with SMTP id g32mr1477135ybj.82.1494036971670; Fri, 05 May 2017 19:16:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.161.198 with HTTP; Fri, 5 May 2017 19:16:11 -0700 (PDT) In-Reply-To: References: <1925618131.4324891.1493997263218.ref@mail.yahoo.com> <1925618131.4324891.1493997263218@mail.yahoo.com> From: Spencer Dawkins at IETF Date: Fri, 5 May 2017 21:16:11 -0500 Message-ID: To: Warren Kumari Cc: Nalini Elkins , "ippm-chairs@ietf.org" , "MORTON, ALFRED C (AL)" , ippm@ietf.org, Bill Cerveny , draft-ietf-ippm-6man-pdm-option@ietf.org, "Mirja Kuehlewind (IETF)" , The IESG Content-Type: multipart/alternative; boundary=f403045e5564fa5a23054ed1961c Archived-At: Subject: Re: [ippm] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ippm-6man-pdm-option-09=3A_=28with_COMMENT=29?= X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 02:16:14 -0000 --f403045e5564fa5a23054ed1961c Content-Type: text/plain; charset=UTF-8 Privately, On Fri, May 5, 2017 at 10:27 AM, Warren Kumari wrote: > I'm still holding a DISCUSS on this - the proposed changes by Nalini > to address my concerns (earlier / in a different thread) are fine with > me and address my concerns. > Being unfamiliar with the custom (and blindly following the text on > the DISCUSS page) I'd originally said that I'd remove my discuss once > a new version was published - but I trust Spencer / the authors to > include the promised, and so am clearing my DISCUSS.... > I appreciate your kind thoughts and confidence. Of course, https://en.wikipedia.org/wiki/Trust,_but_verify worked for Reagan ;-) Spencer --f403045e5564fa5a23054ed1961c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Privately,

On Fri, May 5, 2017 at 10:27 AM, Warren Kumari = <warren@kumari.ne= t> wrote:
https://en.wikipedia.org/wiki/Trust,_but_verify w= orked for Reagan ;-)

Spencer

<= div>=C2=A0

--f403045e5564fa5a23054ed1961c-- From nobody Tue May 9 09:06:22 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BEE12EA98; Tue, 9 May 2017 09:06:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149434597524.17955.14157458482199871528@ietfa.amsl.com> Date: Tue, 09 May 2017 09:06:15 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-6man-pdm-option-10.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 16:06:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics of the IETF. Title : IPv6 Performance and Diagnostic Metrics (PDM) Destination Option Authors : Nalini Elkins Robert M. Hamilton Michael S. Ackermann Filename : draft-ietf-ippm-6man-pdm-option-10.txt Pages : 30 Date : 2017-05-09 Abstract: To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real-time or after the fact. 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-10 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-6man-pdm-option-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-6man-pdm-option-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 9 09:13:43 2017 Return-Path: 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 554E31294D8 for ; Tue, 9 May 2017 09:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=unavailable 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 bWoAScs9sijG for ; Tue, 9 May 2017 09:13:32 -0700 (PDT) Received: from nm38-vm9.bullet.mail.gq1.yahoo.com (nm38-vm9.bullet.mail.gq1.yahoo.com [98.136.216.186]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EAA01294CC for ; Tue, 9 May 2017 09:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1494346408; bh=WPOIiYS3ekbCsMj19JZxDfnpwdvvLpDj0QvKRREbCFY=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=Uu/JucKZwmCmF48Nwcy+e9Ka2fo27ASd4A2oVezvk/KHND2s35vLOn5U6lYINWCoLM6vcgLtaDLs2y+ATW+xG7t/5RrmogiAq4tdzr4ZqH+Me1Elvg2O+UseNoILmXV7j9pppT5SWPaG3Q31pPKdppJjasEXHMQKPUxETOGuoIRDOpyosZByq+NbGD58yCsv38m8IGCNsB/DnhRdhw9yvImhuXzEvnL8V1oJBPxoroL9Qmm2JDFxu7khjbgvFVOAR396g0nd4VWf6C394uKHSQaKco/LKFOHXSFB9Bn8LxxkUkzee+kisfVfvzpJnozHq20AsB1fplVyK/Mt8PwDIg== Received: from [127.0.0.1] by nm38.bullet.mail.gq1.yahoo.com with NNFMP; 09 May 2017 16:13:28 -0000 Received: from [98.137.12.58] by nm38.bullet.mail.gq1.yahoo.com with NNFMP; 09 May 2017 16:10:28 -0000 Received: from [98.137.12.222] by tm3.bullet.mail.gq1.yahoo.com with NNFMP; 09 May 2017 16:10:28 -0000 Received: from [127.0.0.1] by omp1030.mail.gq1.yahoo.com with NNFMP; 09 May 2017 16:10:28 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 668129.27333.bm@omp1030.mail.gq1.yahoo.com X-YMail-OSG: eK82bHYVRDtgfAoCqOIpFuQf7CXNzbPmvwqKAF0E6WpCYH8GW8U- Received: from jws300060.mail.gq1.yahoo.com by sendmailws144.mail.gq1.yahoo.com; Tue, 09 May 2017 16:10:28 +0000; 1494346228.218 Date: Tue, 9 May 2017 16:10:27 +0000 (UTC) From: Reply-To: To: , "Mirja Kuehlewind (IETF)" Cc: The IESG , , , Bill Cerveny , , Message-ID: <1231870780.7928387.1494346227475@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <1231870780.7928387.1494346227475.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9539 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36 Archived-At: Subject: Re: [ippm] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ippm-6man-pdm-option-09=3A_=28with_COMMENT=29?= X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 16:13:34 -0000 Mirja, I have posted a new draft. I believe it responds to all your comments and= suggestions. Thanks so much for the care and consideration you took in re= viewing. Please let me know if there is anything more you would like to s= uggest as improvement. https://datatracker.ietf.org/doc/html/draft-ietf-ippm-6man-pdm-option-10 Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Fri, 5/5/17, wrote: Subject: Re: Mirja K=C3=BChlewind's No Objection on draft-ietf-ippm-6man-p= dm-option-09: (with COMMENT) To: nalini.elkins@insidethestack.com, "Mirja Kuehlewind (IETF)" Cc: "The IESG" , draft-ietf-ippm-6man-pdm-option@ietf.org, = acmorton@att.com, "Bill Cerveny" , ippm-chairs@ietf.org= , ippm@ietf.org Date: Friday, May 5, 2017, 8:14 AM =20 Mirja, =20 Thanks for your comments. =20 My replies inline. =20 As stated below, I will create a new version with the appendix and the changes agreed upon so far.=C2=A0 =C2=A0 Then, we can continue.=C2=A0 Thanks so much to Spencer and Al for their sage guidance through this process.=C2=A0 =20 =20 Thanks, =20 Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 =20 -------------------------------------------- On Tue, 5/2/17, Mirja Kuehlewind (IETF) wrote: =20 Subject: Re: Mirja K=C3=BChlewind's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) To: nalini.elkins@insidethestack.com Cc: "The IESG" , draft-ietf-ippm-6man-pdm-option@ietf.org, acmorton@att.com, "Bill Cerveny" , ippm-chairs@ietf.org, ippm@ietf.org Date: Tuesday, May 2, 2017, 3:58 AM =20 >>-------------------------------------------- >>On Wed, 4/12/17, Mirja K=C3=BChlewind >wrote: >> >>Subject: Mirja K=C3=BChlewind's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) >>To: "The IESG" >>Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org >>Date: Wednesday, April 12, 2017, 10:53 AM >> >>Mirja K=C3=BChlewind 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.htm= l for more information about IESG DISCUSS and COMMENT positions. >> >> >>The document, along with other ballot positions, can be found here:=C2=A0 https://datatracker.ietf.org/do= c/draft-ietf-ippm-6man-pdm-option/ >> >> >>---------------------------------------------------------------------- >>COMMENT: >>---------------------------------------------------------------------- >> >> >>>My main concern is that part of this document read like an advertisement (e.g. "In our experience, valuable time is often lost.." whose >>>experience? The IETF? This is an IETF RFC!). I think most of this text is not needed to understand the option and therefore should simply be >>>removed. More concretely, I propose to remove sections 1.2, 1.3., and 1.5 as well as paragraphs 4-8 of section 1.4 (starting with "In our >>>experience, valuable time is often lost..." to the end).=20 >> >>I think that RFCs are often lacking context which makes them difficult for new people or even people not intimately involved in the creation >>of the draft to understand why they are being written.=C2=A0=20 =20 > I disagree. The important part of a protocol spec is that it is well defined and to the point, so implementors can easily implement it correctly without > having knowledge about all the background discussions that happen in the working group. =20 Sure. =20 =20 >>I am OK with moving the information to an appendix.=C2=A0 What do you think? =20 > I don=E2=80=99t think these section actually provide information that is useful for implementor but I=E2=80=99m okay with moving them to the appendix. I would still > recommend to remove any language on business model at least in section 1.2 (or remove at least 1.2 completely). =20 OK.=C2=A0 I will create a new version with a revised appendix and then wait for your comments. =20 =20 >> >>One question though, I believe you mean "paragraphs 4-8 of section 1.4 (ENDING with "In our experience, valuable time is often lost...").=20 >>The=C2=A0 phrase "In our experience, valuable time is often lost..." is the very last sentence of section 1.4.=20 =20 > Yes, sorry. I meat starting with "One of the important functions=E2=80=9C.=20 =20 > One important point here about the language is that this document seems to be written with the view of a specific group. However as RFC=20 > it=E2=80=99s an IETF consensus document with represents the IETF=E2=80=99s view as a whole. So any phrasing like "In our experience,=E2=80=A6=E2=80=9C or =E2=80=9Ewe can=E2=80=9C/=E2=80=9Ewe may=E2=80=9C=20 > seems not appropriate here and should be removed even if the text is moved to the appendix. =20 I will doublecheck that wording and remove. =20 =20 >> >> >>>I would also recommend these two changes to shorten the RFC:=20 >>>- section 3.2.3. could just be moved into the appendix. >> >>Fine. >> >>I will move: "3.2.3 Considerations of this time-differential representation" into an appendix =20 >> >>>- the diagrams from RFC4303 in sections 3.4.1. and 3.4.2 are not needed >> >>OK. >> >>>In general I think another editing pass could help to bring the document >>>more to the point in a couple of cases. But that's not really an issue. >> >> >>>Further comments: >> >>>1) This text in 3.4.2 is a bit confusing: >>>"As a completely new IP packet will be made, it means that PDM information for that packet does not contain any information from the inner packet, i.e. the PDM information will NOT be based on the >>>transport layer (TCP, UDP, etc) ports etc in the inner header, but will be specific to the ESP flow.=20 >> >>> If PDM information for the inner packet is desired, the original host sending the inner packet needs to put PDM header in the tunneled packet, and then the PDM information will be specific for that >>>stream." >> >>>I think what you want to say is something like >> >>>"A tunnel endpoint that creates a new packet may decide to use PDM independent of the use of PDM of the original packet to enable delay measurements between the two tunnel endpoints." >>>Correct? >> >>Yes, I think your wording represents what I wanted to convey and does it better. >> >> >>>2) I'm not sure this is really useful to specify normatively in an RFC as this is really implementation specific: >>>"The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off." >>>I would recommend the following text instead (without normative language): >>>"An implementation should provide an interface to enable or disable the use of PDM.=C2=A0 This specification recommends to turn PDM off by default." >> >>I believe you are speaking of section 3.5.1 >> >>The reason for this was because an implementation could be created which automatically and dynamically turned on PDM when a packet containing a PDM header was received.=C2=A0 Then, PDM would be used >>without the host being explicitly aware of it.=C2=A0 And a number of unfortunate things such as information leakage, DOS attacks, etc might happen.=C2=A0 So, we added language to say that administrative action is required.=C2=A0 This issue was brought up by the security area review of this document. >> >>The issue mentioned above is dealt with explicitly in section 3.5.1.=C2=A0 The entire text is below: >> >>Current text >>---------------- >> >>3.5.1 PDM Activation >> >>=C2=A0 The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off. >> >>=C2=A0 PDM MUST NOT be turned on merely if a packet is received with a PDM header. The received packet could be spoofed by another device. =20 =20 > I understand the intention here and the intention is correct. My comment was that the use of normative language here might not be really appropriate because=20 > this part does not talk about the protocol itself but the interface to the higher layer and this depends very much on the use case and environment in which it is=20 > implemented. Therefore I would recommend to not use normative language here. =20 OK.=C2=A0 Will change. =20 >> >> >> >>>3) I don't understand section 3.6. Isn't that redundant with 3.5.1? Or what's meant by 'dynamic configuration option'? In any case, I don't >>>think the use of normative language is appropriate here. >> >>This was also brought up by Warren.=C2=A0 He accepted the change below.=C2=A0 Please let me know if that also works for you. >> >>Current text >>---------------- >> >>3.6 Dynamic Configuration Options >> >>If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=3Dyes/no. The operating system MAY also have a dynamic configuration option to >>change the configuration setting as needed. >> >>If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP >>address only.=C2=A0 These are at the discretion of the implementation. >> >> >>New text >>----------- >> >>3.6 Filtering of PDM >> >>If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP >>address only.=C2=A0 These are at the discretion of the implementation. =20 =20 > Okay. =20 >> >> >>>4) I would also like to propose new text on 3.6 5-tuple Aging (btw. 3.6. exists twice) >> >>Thanks will fix the 3.6 twice. >> >>>OLD >> >>>"3.6 5-tuple Aging >> >>>Within the operating system, metrics must be kept on a 5-tuple basis. >> >>>The question comes of when to stop keeping data or restarting the numbering for a 5-tuple.=C2=A0 For example, in the case of TCP, at some >>> point, the connection will terminate.=C2=A0 Keeping data in control blocks forever, will have unfortunate consequences for the operating >>>system. >> >>> So, the recommendation is to use a known aging parameter such as Max Segment Lifetime (MSL) as defined in Transmission Control Protocol >>> [RFC0793] to reuse or drop the control block.=C2=A0 The choice of aging parameter is left up to the implementation." >> >>>NEW >> >>>"3.6 Information Access and Storage >> >>>Measurement information provided by PDM must be made accessible for higher layers or the user itself. Similar as activating the use of >>>PDM, the implementation may also provide an interface to indicate if received >> >>>PDM information should be stored or not. If a packet with PDM information is received and the information should be stored, the upper layers may be >>>notified. Further it is recommend to define a configurable maximum lifetime after which the information can be removed as well as >>>a configurable maximum amount of memory that should be allocated for PDM information." >> >>>This text also addresses some of the "SYN flood attack" concerns as described in the security considerations section. I would recommend to rewrite this >>>section as well and I would also recommend to not use the term SYN flood as that is clearly associated with TCP only. >> >>As far as: >> >>"Measurement information provided by PDM must be made accessible for higher layers or the user itself." >> >>The information in PDM is in the extension header.=C2=A0 What we had envisioned is that diagnostics would be done by capturing a packet trace.=C2=A0 But, certainly what=20 >>you suggest is very interesting.=C2=A0 Higher layers as well as the user could make very good use of PDM information.=C2=A0 =C2=A0=20 >> >>Are you OK with a minor change to that sentence to say: >> >>"Measurement information provided by PDM may be made accessible for higher layers or the user itself.=E2=80=9C >> =20 > Okay.=20 =20 =20 >>As far as the rest of the text in that paragraph, I am fine with it.=C2=A0 In fact, in working on implementation, we are doing exactly that:=C2=A0 a configurable amount of memory / lifetime. >>Actually, only memory is needed as then it controls everything else quite well.=C2=A0 =C2=A0 This is why we said "limit on control blocks" in the security section.=C2=A0 I will make it >>more explicit that what is meant by control blocks is memory. >> >> >>Current Security 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.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 =C2=A0=20 >> >>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.=C2=A0=20 >> >> A limit on how much memory is being used SHOULD be=20 >> 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.=C2=A0 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.=C2=A0 PDM is an=20 >> implementation of the Destination Option extension header. >> >> >>>5) Also section 4.1 (security consideration): I don't think this sentence is true: >>>" For PDM, the amount of data to be kept is quite small. That is, the control block is quite lightweight." >>>Because you eventually have to hold this data per packet, so it can grow quickly.=C2=A0 However, this is also really an implementation question only. You could >>>also just store the delay calculation and not the whole control block, or even an moving average of the delay which only needs a fixed amount of memory for a few >>>values.=C2=A0 I really depends what your use case is for the information provided by PDM. >> >>Please let me know if the above changes to section 4.1 addresses your concerns. =20 > Maybe this: =20 > OLD: =20 >"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.=E2=80=9C =20 > NEW: =20 >=E2=80=9EWithout a memory limit, 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 could be used to compromise the end host.=E2=80=9C =20 =20 Fine. =20 Thanks, Nalini From nobody Tue May 9 09:16:13 2017 Return-Path: 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 DF028129ABD for ; Tue, 9 May 2017 09:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=unavailable 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 s-9Six_U67VH for ; Tue, 9 May 2017 09:16:00 -0700 (PDT) Received: from nm33-vm3.bullet.mail.gq1.yahoo.com (nm33-vm3.bullet.mail.gq1.yahoo.com [98.136.216.242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A70C12E049 for ; Tue, 9 May 2017 09:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1494346556; bh=8qEufjgJsz0zXUfOY24DKMM8oxVM6xF600LtPBXVfFA=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=MGzKRRM8Tfgl2b6fCta86KLW6VfEAyYOvIFxyAaa+nC+aypoqClF1NjbRZK8i016eAl6Y8RIafQ+k9eI7ESoCNrO3IBGMgDFMwXE1cgE5ud/XwZfLJ1eDl31UXarPZuIIqBpkS75SYCa/5wqNEiLnRZJJzpugAmdUjafzVul3yCiQbZGZmdiLLWe65dxF2UyiQIOK1/HnmfkwlE+sCYZrLQqR6lbFKXqQzRQsbHs/R8yBc3YpXAunf8jddtevXLBgyDQCgDasOk4sEBUfgrdCmLUnaXzRzBjNH+NpwODfxr/XgEl6G/JGaei3sBvfqbP1fZYcR9bC0NYaf1gjf/vAg== Received: from [127.0.0.1] by nm33.bullet.mail.gq1.yahoo.com with NNFMP; 09 May 2017 16:15:56 -0000 Received: from [98.137.12.59] by nm33.bullet.mail.gq1.yahoo.com with NNFMP; 09 May 2017 16:12:58 -0000 Received: from [98.137.12.212] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 09 May 2017 16:11:58 -0000 Received: from [127.0.0.1] by omp1020.mail.gq1.yahoo.com with NNFMP; 09 May 2017 16:11:58 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 226577.22601.bm@omp1020.mail.gq1.yahoo.com X-YMail-OSG: eK82bHYVRDtgfAoCqOIpFuQf7CXNzbPmvwqKAF0E6WpCYH8GW8U- Received: from jws300077.mail.gq1.yahoo.com by sendmailws101b.mail.gq1.yahoo.com; Tue, 09 May 2017 16:11:57 +0000; 1494346317.843 Date: Tue, 9 May 2017 16:11:57 +0000 (UTC) From: Reply-To: To: Nalini Elkins , Warren Kumari Cc: "Mirja Kuehlewind (IETF)" , , " ALFRED C (AL)MORTON" , , Bill Cerveny , , The IESG Message-ID: <108945347.7879058.1494346317497@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <108945347.7879058.1494346317497.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9539 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36 Archived-At: Subject: Re: [ippm] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ippm-6man-pdm-option-09=3A_=28with_COMMENT=29?= X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 16:16:03 -0000 Warren, I have posted a new draft. I believe it responds to all your comments as = well as the DISCUSS. Wonderful to have all your thoughtful comments which= have greatly improved the document. Please let me know if there is anyth= ing else. https://datatracker.ietf.org/doc/html/draft-ietf-ippm-6man-pdm-option-10 Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Fri, 5/5/17, Warren Kumari wrote: Subject: Re: Mirja K=C3=BChlewind's No Objection on draft-ietf-ippm-6man-p= dm-option-09: (with COMMENT) To: "Nalini Elkins" Cc: "Mirja Kuehlewind (IETF)" , ippm-chairs@ietf.org,= "MORTON, ALFRED C (AL)" , ippm@ietf.org, "Bill Cerveny" = , draft-ietf-ippm-6man-pdm-option@ietf.org, "The IESG" = Date: Friday, May 5, 2017, 8:27 AM =20 I'm still holding a DISCUSS on this - the proposed changes by Nalini to address my concerns (earlier / in a different thread) are fine with me and address my concerns. Being unfamiliar with the custom (and blindly following the text on the DISCUSS page) I'd originally said that I'd remove my discuss once a new version was published - but I trust Spencer / the authors to include the promised, and so am clearing my DISCUSS.... =20 Thanks all, W =20 On Fri, May 5, 2017 at 11:14 AM,=C2=A0 wrote: > Mirja, > > Thanks for your comments. > > My replies inline. > > As stated below, I will create a new version with the appendix and the changes agreed upon so far.=C2=A0 =C2=A0 Then, we can continue.=C2=A0 Thanks so much to Spencer and Al for their sage guidance through this process. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > -------------------------------------------- > On Tue, 5/2/17, Mirja Kuehlewind (IETF) wrote: > >=C2=A0 Subject: Re: Mirja K=C3=BChlewind's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) >=C2=A0 To: nalini.elkins@insidethestack.com >=C2=A0 Cc: "The IESG" , draft-ietf-ippm-6man-pdm-option@ietf.org, acmorton@att.com, "Bill Cerveny" , ippm-chairs@ietf.org, ippm@ietf.org >=C2=A0 Date: Tuesday, May 2, 2017, 3:58 AM > >>>-------------------------------------------- >>>On Wed, 4/12/17, Mirja K=C3=BChlewind >wrote: >>> >>>Subject: Mirja K=C3=BChlewind's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) >>>To: "The IESG" >>>Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org >>>Date: Wednesday, April 12, 2017, 10:53 AM >>> >>>Mirja K=C3=BChlewind 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:=C2=A0 https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-opti= on/ >>> >>> >>>---------------------------------------------------------------------- >>>COMMENT: >>>---------------------------------------------------------------------- >>> >>> >>>>My main concern is that part of this document read like an advertisement (e.g. "In our experience, valuable time is often lost.." whose >>>>experience? The IETF? This is an IETF RFC!). I think most of this text is not needed to understand the option and therefore should simply be >>>>removed. More concretely, I propose to remove sections 1.2, 1.3., and 1.5 as well as paragraphs 4-8 of section 1.4 (starting with "In our >>>>experience, valuable time is often lost..." to the end). >>> >>>I think that RFCs are often lacking context which makes them difficult for new people or even people not intimately involved in the creation >>>of the draft to understand why they are being written. > >> I disagree. The important part of a protocol spec is that it is well defined and to the point, so implementors can easily implement it correctly without >> having knowledge about all the background discussions that happen in the working group. > > Sure. > > >>>I am OK with moving the information to an appendix.=C2=A0 What do you think? > >> I don=E2=80=99t think these section actually provide information that is useful for implementor but I=E2=80=99m okay with moving them to the appendix. I would still >> recommend to remove any language on business model at least in section 1.2 (or remove at least 1.2 completely). > > OK.=C2=A0 I will create a new version with a revised appendix and then wait for your comments. > > >>> >>>One question though, I believe you mean "paragraphs 4-8 of section 1.4 (ENDING with "In our experience, valuable time is often lost..."). >>>The=C2=A0 phrase "In our experience, valuable time is often lost..." is the very last sentence of section 1.4. > >> Yes, sorry. I meat starting with "One of the important functions=E2=80=9C. > >> One important point here about the language is that this document seems to be written with the view of a specific group. However as RFC >> it=E2=80=99s an IETF consensus document with represents the IETF=E2=80=99s view as a whole. So any phrasing like "In our experience,=E2=80=A6=E2=80=9C or =E2=80=9Ewe can=E2=80=9C/=E2=80=9Ewe may=E2=80=9C >> seems not appropriate here and should be removed even if the text is moved to the appendix. > > I will doublecheck that wording and remove. > > >>> >>> >>>>I would also recommend these two changes to shorten the RFC: >>>>- section 3.2.3. could just be moved into the appendix. >>> >>>Fine. >>> >>>I will move: "3.2.3 Considerations of this time-differential representation" into an appendix > >>> >>>>- the diagrams from RFC4303 in sections 3.4.1. and 3.4.2 are not needed >>> >>>OK. >>> >>>>In general I think another editing pass could help to bring the document >>>>more to the point in a couple of cases. But that's not really an issue. >>> >>> >>>>Further comments: >>> >>>>1) This text in 3.4.2 is a bit confusing: >>>>"As a completely new IP packet will be made, it means that PDM information for that packet does not contain any information from the inner packet, i.e. the PDM information will NOT be based on the >>>>transport layer (TCP, UDP, etc) ports etc in the inner header, but will be specific to the ESP flow. >>> >>>> If PDM information for the inner packet is desired, the original host sending the inner packet needs to put PDM header in the tunneled packet, and then the PDM information will be specific for that >>>>stream." >>> >>>>I think what you want to say is something like >>> >>>>"A tunnel endpoint that creates a new packet may decide to use PDM independent of the use of PDM of the original packet to enable delay measurements between the two tunnel endpoints." >>>>Correct? >>> >>>Yes, I think your wording represents what I wanted to convey and does it better. >>> >>> >>>>2) I'm not sure this is really useful to specify normatively in an RFC as this is really implementation specific: >>>>"The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off." >>>>I would recommend the following text instead (without normative language): >>>>"An implementation should provide an interface to enable or disable the use of PDM.=C2=A0 This specification recommends to turn PDM off by default." >>> >>>I believe you are speaking of section 3.5.1 >>> >>>The reason for this was because an implementation could be created which automatically and dynamically turned on PDM when a packet containing a PDM header was received.=C2=A0 Then, PDM would be used >>>without the host being explicitly aware of it.=C2=A0 And a number of unfortunate things such as information leakage, DOS attacks, etc might happen.=C2=A0 So, we added language to say that administrative action is required.=C2=A0 This issue was brought up by the security area review of this document. >>> >>>The issue mentioned above is dealt with explicitly in section 3.5.1.=C2=A0 The entire text is below: >>> >>>Current text >>>---------------- >>> >>>3.5.1 PDM Activation >>> >>>=C2=A0 The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off. >>> >>>=C2=A0 PDM MUST NOT be turned on merely if a packet is received with a PDM header. The received packet could be spoofed by another device. > > >> I understand the intention here and the intention is correct. My comment was that the use of normative language here might not be really appropriate because >> this part does not talk about the protocol itself but the interface to the higher layer and this depends very much on the use case and environment in which it is >> implemented. Therefore I would recommend to not use normative language here. > > OK.=C2=A0 Will change. > >>> >>> >>> >>>>3) I don't understand section 3.6. Isn't that redundant with 3.5.1? Or what's meant by 'dynamic configuration option'? In any case, I don't >>>>think the use of normative language is appropriate here. >>> >>>This was also brought up by Warren.=C2=A0 He accepted the change below.=C2=A0 Please let me know if that also works for you. >>> >>>Current text >>>---------------- >>> >>>3.6 Dynamic Configuration Options >>> >>>If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=3Dyes/no. The operating system MAY also have a dynamic configuration option to >>>change the configuration setting as needed. >>> >>>If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP >>>address only.=C2=A0 These are at the discretion of the implementation. >>> >>> >>>New text >>>----------- >>> >>>3.6 Filtering of PDM >>> >>>If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP >>>address only.=C2=A0 These are at the discretion of the implementation. > > >> Okay. > >>> >>> >>>>4) I would also like to propose new text on 3.6 5-tuple Aging (btw. 3.6. exists twice) >>> >>>Thanks will fix the 3.6 twice. >>> >>>>OLD >>> >>>>"3.6 5-tuple Aging >>> >>>>Within the operating system, metrics must be kept on a 5-tuple basis. >>> >>>>The question comes of when to stop keeping data or restarting the numbering for a 5-tuple.=C2=A0 For example, in the case of TCP, at some >>>> point, the connection will terminate.=C2=A0 Keeping data in control blocks forever, will have unfortunate consequences for the operating >>>>system. >>> >>>> So, the recommendation is to use a known aging parameter such as Max Segment Lifetime (MSL) as defined in Transmission Control Protocol >>>> [RFC0793] to reuse or drop the control block.=C2=A0 The choice of aging parameter is left up to the implementation." >>> >>>>NEW >>> >>>>"3.6 Information Access and Storage >>> >>>>Measurement information provided by PDM must be made accessible for higher layers or the user itself. Similar as activating the use of >>>>PDM, the implementation may also provide an interface to indicate if received >>> >>>>PDM information should be stored or not. If a packet with PDM information is received and the information should be stored, the upper layers may be >>>>notified. Further it is recommend to define a configurable maximum lifetime after which the information can be removed as well as >>>>a configurable maximum amount of memory that should be allocated for PDM information." >>> >>>>This text also addresses some of the "SYN flood attack" concerns as described in the security considerations section. I would recommend to rewrite this >>>>section as well and I would also recommend to not use the term SYN flood as that is clearly associated with TCP only. >>> >>>As far as: >>> >>>"Measurement information provided by PDM must be made accessible for higher layers or the user itself." >>> >>>The information in PDM is in the extension header.=C2=A0 What we had envisioned is that diagnostics would be done by capturing a packet trace.=C2=A0 But, certainly what >>>you suggest is very interesting.=C2=A0 Higher layers as well as the user could make very good use of PDM information. >>> >>>Are you OK with a minor change to that sentence to say: >>> >>>"Measurement information provided by PDM may be made accessible for higher layers or the user itself.=E2=80=9C >>> > >> Okay. > > >>>As far as the rest of the text in that paragraph, I am fine with it.=C2=A0 In fact, in working on implementation, we are doing exactly that:=C2=A0 a configurable amount of memory / lifetime. >>>Actually, only memory is needed as then it controls everything else quite well.=C2=A0 =C2=A0 This is why we said "limit on control blocks" in the security section.=C2=A0 I will make it >>>more explicit that what is meant by control blocks is memory. >>> >>> >>>Current Security 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.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 PDM is an >>> implementation of the Destination Option extension header. >>> >>> >>>>5) Also section 4.1 (security consideration): I don't think this sentence is true: >>>>" For PDM, the amount of data to be kept is quite small. That is, the control block is quite lightweight." >>>>Because you eventually have to hold this data per packet, so it can grow quickly.=C2=A0 However, this is also really an implementation question only. You could >>>>also just store the delay calculation and not the whole control block, or even an moving average of the delay which only needs a fixed amount of memory for a few >>>>values.=C2=A0 I really depends what your use case is for the information provided by PDM. >>> >>>Please let me know if the above changes to section 4.1 addresses your concerns. > >> Maybe this: > >> OLD: > >>"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.=E2=80=9C > >> NEW: > >>=E2=80=9EWithout a memory limit, 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 could be used to compromise the end host.=E2=80=9C > > > Fine. > > Thanks, > Nalini > =20 =20 =20 --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. =C2=A0 ---maf From nobody Tue May 9 09:21:46 2017 Return-Path: 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 603CE12EA64 for ; Tue, 9 May 2017 09:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=unavailable 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 ZAs2yvq0TS9m for ; Tue, 9 May 2017 09:21:34 -0700 (PDT) Received: from nm34-vm8.bullet.mail.gq1.yahoo.com (nm34-vm8.bullet.mail.gq1.yahoo.com [98.136.216.159]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95CC812EA7C for ; Tue, 9 May 2017 09:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1494346885; bh=2p34BIDuTLXVcFB27uNqBbgPZi/vAPYeu8J38N5K3b4=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=tIHqnYdQn02A4fpXJz8Eym0pJ1h406gUqA9VZ/veyOVwUFqiz0CZb9K5y2M0dJWwn/84KwIbFMOZv/LR1kW6zWB2p0cygb4mVgdTJr4MQaZjFcmNh24AadOYJ7EQl3xUrRIJy4LEi6l7AcJPiIqi8qKFLAkMJp4lwRAGgi1eh1xSvbjuE2n3ufvc+D9ozd6kndvhKoagx6wqh0u07rfFI7ro/Paua2/7nWp7IW3PSmZJyjUxm1GPDMMsCmbZhw8XeNSpiDWKlKLq4iqX3qD3awKu63c8hZ5ynFcwShykj/sNFbBdSNWfHvt+zu0LS9YCUkQj2Cl8Fo3F6C+jv13uyg== Received: from [127.0.0.1] by nm34.bullet.mail.gq1.yahoo.com with NNFMP; 09 May 2017 16:21:25 -0000 Received: from [216.39.60.183] by nm34.bullet.mail.gq1.yahoo.com with NNFMP; 09 May 2017 16:18:29 -0000 Received: from [98.137.12.225] by tm19.bullet.mail.gq1.yahoo.com with NNFMP; 09 May 2017 16:18:29 -0000 Received: from [127.0.0.1] by omp1033.mail.gq1.yahoo.com with NNFMP; 09 May 2017 16:18:29 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 608956.55724.bm@omp1033.mail.gq1.yahoo.com X-YMail-OSG: brb4fYgVM1nm1B0TuDzZW6kJsAepQNolIbWewMszrTjsbL95rG8RIE9rBEnuqCS oIzYIVLZkskk9qR_eshviO4vXj6Gm3I6vFt7_cSeuWmlyn1c3paK.9B5wJuoAJdlxHfhUcGXWKvw YZgUaQNmJjAZbR48H6ZRxkUQbivilsPE3dQzQ8u8Qyrm9D_QIEscl08SrVCDzEMKiQigNORbIySX MuUaqNL_xFpdHkeRME5mbpr1BR_0FekuQ8e1uVJxFLZtRciE5XtWY6.zOXrAEuov4F6eInQHfUqK _KS8jPgAicV5zLI40haLu8Df4lGr3FqPtAvlt_IQPcuyn82HIk348a6hZG01C4SqIbzl3s9WMN7M 4X1A0RWQC3HplJPKjYWyjBYZI8txmZehaSbCGsX8eZnNqpwwc9Bvn.olfw.KTpwHiO73DWS5r0b_ Z_Zq9Df7KsSI9zqR7RD2IYWBLsfNcZBpgBXslUX3F9Ta9qAsboRuwrskRDd7QxoSxm8YBqiYXENz y5bFP5aCv21XF6j4jKY4HQPA85qlcb1InaqFvkp2Rtnik54e2bTXyoIw- Received: from jws300075.mail.gq1.yahoo.com by sendmailws111.mail.gq1.yahoo.com; Tue, 09 May 2017 16:18:29 +0000; 1494346709.161 Date: Tue, 9 May 2017 16:18:28 +0000 (UTC) From: Reply-To: To: The IESG , Deborah Brungard Cc: , Bill Cerveny , , , Message-ID: <1563341655.7894899.1494346708895@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <1563341655.7894899.1494346708895.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9539 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36 Archived-At: Subject: Re: [ippm] Deborah Brungard'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 16:21:35 -0000 Deborah, I have posted a new draft which incorporates responses to comments from Mirja and Warren. https://datatracker.ietf.org/doc/html/draft-ietf-ippm-6man-pdm-option-10 My responses inline to your comments. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Wed, 4/12/17, Deborah Brungard wrote: Subject: [ippm] Deborah Brungard's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org Date: Wednesday, April 12, 2017, 2:28 PM > Deborah Brungard 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- > Agree with the many comments by the other ADs. Especially, Mirja's and Ben's comments, the document reads like a white paper vs. an IETF specification. Please check the changes suggested by Mirja and incorporated in the document. I have responded to Ben and am waiting for his response. > The "Consent to be Measured" by a user (section 4.4) seems contra to the use case described in the document (estimate QoS as experienced by an end user device). It should be the network > provider who should be giving "consent to be measured" and the associated risks. Warren also noted these sentences as inappropriate. The document discusses the security aspects relative to the user but is > missing discussion with respect to the network provider. Please check the new wording below in response to Warren's comments. Please let me know if this addresses your concerns. New ------ An implementation may want to be sure that PDM is enabled only for certain ip addresses, or only for some ports. Additionally, the implementation SHOULD require an explicit restart of monitoring after a certain time period (for example for 1 hour), to make sure that PDM is not accidentally left on after debugging has been done etc. Even so, if using PDM, a user "Consent to be Measured" SHOULD be a pre-requisite for using PDM. Consent is common in enterprises and with some subscription services. 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 _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Thu May 18 07:45:42 2017 Return-Path: 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 024861289B0 for ; Thu, 18 May 2017 07:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.11 X-Spam-Level: *** X-Spam-Status: No, score=3.11 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 y5rFBnQf2V34 for ; Thu, 18 May 2017 07:45:39 -0700 (PDT) Received: from sonic305-29.consmr.mail.gq1.yahoo.com (sonic305-29.consmr.mail.gq1.yahoo.com [98.137.64.92]) (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 6723B12EAB0 for ; Thu, 18 May 2017 07:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1495118423; bh=81OkVToGo/oLlMDKHao+PvUznsAtBqD4pGeDjkemYj8=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=Jtpt4Dvu5dazILKo0eLc+r+hOGmA1JMDrti/V3V48qy4kiv3zx/UM5d5FJIyF+2JOBGbCX8oULnOXW/vKyJ+NKIRUHuiFVWze225r7x+VCv3EOhCQ4l5q3IM/Vv+1lkmQQBqlIolSg1yn68+lYsHV/MXxlZXqdXK6ytmZp09w2+n3Gy0FsCjIFI7w19+U3B+XRW/hbMtGS0a5TiP/PzV8uZyY28Sr7U6TjlBNBrSoIJG3Jbf6NxxBfQP5nJMCtXtx0KYttw7dbzpuf3n+i85vUGxrmN30tdtJSNahuLy8Im1DyVXBTdJVXb5dTkYw3twPemRUwb6EKQti1LoOHJ49Q== X-YMail-OSG: Sv.MBLcVM1nBizDXErXVa5CqbNVlPtlLjbAsqOQIIStnfGP5rk3SEFaK_ZWneKK tFIKu1lWA25J1GPCnsu.8vN6tEMEuBv7DobKmT_fW1HU2tDW8e2cad0m9s5zbsmrJWtc0i4KgIqS .YGbjZHcGOGjP3dIvN5k6nwurFUzJWrcbk_po01_5CZJ4MbqGAswQcY7l5h9fYTUoWacD9iQo.cl 59Tcw6ddiIyPiZ.gAC1gs3B.x_HZrRgk6MGGh3rN0J7MKXzYBXCrcMTJugLovcW0zjnwmdPEcka6 YBhy4xbkPdiZSAe52iPFNmzmr_wOiYfsohKUddYpRLgbVS2Ckb928R3NAjTMDwm10tt1FH7vt8oP Q3j8jq0biJDTdkLlyq1GSVtlj1xGU.QDqbfyIIJT7.HZ56tqUd.TOw4rrA6NtzPrhiem1hUjTxNQ BRQuN2bRj2Ch0LI5sJg5yNjisnKTnIUxI7X0CgOHVzR_mqZiKztNRnmtAIWBZyvGpDbfQs0kokHu BurMSHjki28.B2WwNrR8osTTrF_gFZpHVdudpYTGwsLj6BNrl Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Thu, 18 May 2017 14:40:23 +0000 Date: Thu, 18 May 2017 14:40:22 +0000 (UTC) From: Reply-To: To: The IESG , Cc: , , Bill Cerveny , , Message-ID: <538106496.805519.1495118422514@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <538106496.805519.1495118422514.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9679 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Archived-At: Subject: Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 14:45:41 -0000 Suresh, I am responding to all comments.=C2=A0 Once I get agreement from you, I wil= l create a new version and then maybe you can review & remove the DISCUSS. My comments inline. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Tue, 4/11/17, Suresh Krishnan wrote: Subject: Suresh Krishnan's Discuss on draft-ietf-ippm-6man-pdm-option-09: = (with DISCUSS and COMMENT) To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att= .com, ippm@ietf.org Date: Tuesday, April 11, 2017, 12:08 PM =20 > Suresh Krishnan has entered the following ballot position for draft-ietf= -ippm-6man-pdm-option-09:=C2=A0 Discuss =20 =20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html= for more information about IESG DISCUSS and COMMENT positions. =20 =20 > The document, along with other ballot=C2=A0 positions, can be found here= : https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ =20 =20 =20 --- > * Section 3.2.1. >The option length seems to be wrong here. This will make the parser >parse incorrectly onto a following option or worse. I think this MUST be >set to 10 instead of 16 (Or some field is missing from the description of >the option) > 8-bit unsigned integer. Length of the option, in octets, excluding > the Option Type and Option Length fields. This field MUST be set to > 16. Thank you.=C2=A0 Will fix. >* Section 3.2.1. > The option does not seem to state an alignment requirement, but I think >one is required to properly align the multi-byte PSN and Delta fields. >Can you please specify one. I can add the wording to this section to say that per RFC2460, the alignment is: 2n=C2=A0 =C2=A0 means any 2-octet offset from the start of the header. >* Section 5 >The IANA considerations section needs to be more specific as you are >requesting a specific type of option. >e.g. This draft requests an Destination Option Type assignment with >=C2=A0 the act bits set to 00 and the chg bit set to 0 from the ... Fine. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- > * Section 1.6=C2=A0 (Nalini: Find where this is in the new draft) > I am not sure where this inference comes from. Can you please clarify? > It is likely that an IPv6 packet containing PDM will be dropped if using > IPv6 transition technologies. This is now section 1.3.=C2=A0 I was meaning to discuss translation issues= . How is this proposed wording? NEW ---- It is possible that an IPv6 packet containing PDM may be dropped if using IPv6 transition technologies.=C2=A0 For example, an implementation using a = translation=20 technique (IPv6 to IPv4) which does not support or recognize the IPv6 Destination Options extension header may simply drop the packet rather than translating it without the extension header. >* Section 3.1 >This text is not correct as the PDM option is not an implementation of >the Destination options *header*. >The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is >an implementation of the Destination Options Header. > Suggest rewording to=20 >The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is >implemented as an IPv6 Option carried in the Destination Options Header. Fine. From nobody Mon May 22 08:36:52 2017 Return-Path: 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 1487812EB03 for ; Mon, 22 May 2017 08:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.611 X-Spam-Level: *** X-Spam-Status: No, score=3.611 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, 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 buUydydjocvC for ; Mon, 22 May 2017 08:36:49 -0700 (PDT) Received: from sonic319-30.consmr.mail.gq1.yahoo.com (sonic319-30.consmr.mail.gq1.yahoo.com [98.137.66.211]) (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 0D64512EAFF for ; Mon, 22 May 2017 08:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1495467408; bh=Oe2mBT/IPqjkI5WfthKOC/Q0OFWRUOQffwIxq8cmnxY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=lyI/4w2OA69n7wG8CVwrSsSiFGEgfyyqP+zisnaJgusX6cGEuNZa7jNlljWpxQ6mBluyOF/JE5Ph0aGXFCoqKc50AOdMdyprbup2/wmr/84mDiPMcYvNpky2EaPZcL3lGf7LNQdwcjLgzTOS9GH12G3C0IpqkAuPJ28XE8DFEvy6IOZzAIelkHPDMI85D7IGp6ZxqDi9tzjxWyPby0MR1/VSHAAkXPloztol2IswQi1DMFfFxL3fVhI1e+go3lZ8OojGlPLXZazHCEJDlxejknjWqxulwdXQeRQl88+/ZI1QeVmSPArU9zw1lKGHtjnMV5fatpeU7jyZiuD6pG2ZaA== X-YMail-OSG: nDjzmGgVM1mUMyFMZVygnjwstU1TfH6X1Xms8LwwGuoeqCP6Mzs7Qtq30zJcXJ4 d7d8769cz9Qhowra6qLH6gQzYVwQP_YTkU7Uu2dm_and9uka33WZ.b.Zyn0yDnJWswyxL3gLPHZN TL.6HsEQvvTfiEXQE9SwsRCy9NIzYHhFxj.0WdFa7c1iz2vGgB7RYiU9HxMiGThwJGnFqr0RnFEU 2Zjssr3YBQY3cbKEyA3c_P0kXG6iProqFBHTTf_RbtM9cvGaY9yW9.2VEgUS9z_cciYdricMOEyL sk8xX2rw0PJVvDP6nNXAOcmaa2H8BsuMjIsmcy1SVkPIXiLRL08aI1Eggj0iGCvh9Otnm_RQDDc1 qQbJDDxhw57h7p6leC95uoentMI27NZ1gLppmBfogtTIoQSJQEej9dgfxlD1OJSeNXiYOBN363q2 tJkoatCBQfjBAS7mvqclj6rPkgjCy7PJ7mZloGi_qXKH9X_zV1pFGclC43tHm4ylbsZIw_vcbk2_ hB1qaVXagXhtAnGW_io0dC3C5qbtr1c8cHBDkxSoz1HoUr1tORvKLxSGBEvQ8KpfTLjuCokJCluC ZWuHu.ae5zJHlczOs1lYur47tLXCxpAaeA_dxXzO4pRbAuo7wRyGNII63Dw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic319.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 May 2017 15:36:48 +0000 Date: Mon, 22 May 2017 15:26:46 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Alissa Cooper , The IESG Cc: "draft-ietf-ippm-6man-pdm-option@ietf.org" , Bill Cerveny , "ippm-chairs@ietf.org" , "acmorton@att.com" , "ippm@ietf.org" Message-ID: <922169529.4233696.1495466806431@mail.yahoo.com> In-Reply-To: <149200885746.15718.798617550888585150.idtracker@ietfa.amsl.com> References: <149200885746.15718.798617550888585150.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4233695_1329711182.1495466806423" X-Mailer: WebService/1.1.9679 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Archived-At: Subject: Re: [ippm] Alissa Cooper'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 15:36:50 -0000 ------=_Part_4233695_1329711182.1495466806423 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alissa, Please let me know if you are OK with the proposed change. >Alissa Cooper 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/ >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- >The analysis in Sec 4.2 seems to be missing some considerations. In cases >where the packet payload is encrypted and the attacker does not have >access to the keys, the attacker does not in fact have access to the >entire packet, in which case PDM provides more information than a packet >without PDM. Also in those cases, it seems like including PDM information >would generally make a packet stream more susceptible to traffic analysis >insofar as the timing and sequence information may provide additional >indicators about the type of application in use, not just the speed of >the end host. Are you OK if I do the following: OLD------=C2=A0Since PDM passes in the clear, a concern arises as to whethe= r the=C2=A0data can be used to fingerprint the system or somehow obtain=C2= =A0information about the contents of the payload. =C2=A0 =C2=A0Let us discuss fingerprinting of the end host first. It is possible= =C2=A0that seeing the pattern of deltas or the absolute values could give= =C2=A0some information as to the speed of the end host - that is, if it is= =C2=A0a very fast system or an older, slow device. =C2=A0 This may be usefu= l to=C2=A0the attacker. =C2=A0However, if the attacker has access to PDM, t= he=C2=A0attacker also has access to the entire packet and could make such a= =C2=A0deduction based merely on the time frames elapsed between packets=C2= =A0WITHOUT PDM. =C2=A0 =C2=A0As far as deducing the content of the payload, it appears to us that= =C2=A0PDM is quite unhelpful in this regard. New------ Since PDM passes in the clear, a concern arises as to whether the data can be used to fingerprint the system or somehow obtaininformation abo= ut the contents of the payload. =C2=A0 Let us discuss fingerprinting of the end host first. It is possiblethat see= ing the pattern of deltas or the absolute values could givesome information= as to the speed of the end host - that is, if it isa very fast system or a= n older, slow device. =C2=A0 This may be useful tothe attacker. =C2=A0Howev= er, if the attacker has access to PDM, theattacker also has access to the e= ntire packet and could make such adeduction based merely on the time frames= elapsed between packetsWITHOUT PDM. =C2=A0 As far as deducing the content of the payload, it is conceivablethat an att= acker could attempt to deduce the type of application inuse by noting the s= erver time and payload length. =C2=A0 Having said that,some encryption algo= rithms attempt to obfuscate the=C2=A0packet lengthto avoid just such vulner= abilities. =C2=A0In the future, encryption algorithmsmay wish to obfuscate = the server time as well. =C2=A0 =20 ------=_Part_4233695_1329711182.1495466806423 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alissa,
<= div id=3D"yui_3_16_0_ym19_1_1495466060991_6679">
Please let me know if you are OK with the p= roposed change.

<= /div>



>Alissa Cooper ha= s entered the following ballot position for
>draft-ietf-ippm-6man-pdm-option-09: No Obj= ection


>for more information about IESG DISCUSS and COMMENT posit= ions.


>The document, along with other ba= llot positions, can be found here:



&g= t;----------------------------------------------------------------------
>COMMENT:
>-----------= -----------------------------------------------------------

>The analysis in Sec 4.2 seems to be mis= sing some considerations. In cases
>where the packet payload is encrypted and the attac= ker does not have
>access to the keys, the attacker does not in fact have access to the=
>entire pac= ket, in which case PDM provides more information than a packet
>without PDM. Also in th= ose cases, it seems like including PDM information
>would generally make a packet strea= m more susceptible to traffic analysis
>insofar as the timing and sequence information = may provide additional
>indicators about the type of application in use, not just the s= peed of
>the= end host.

=

Are you OK if I do the following:


O= LD
------
 Since PDM passes in the clear, a concern = arises as to whether the
 data can be used to fingerprint the system or somehow obtain
 information a= bout the contents of the payload.  

 Let us discuss = fingerprinting of the end host first. It is possible
 that seeing the pattern of delta= s or the absolute values could give
 some information as to the speed of the end host - = that is, if it is
=  a very fast system or an older, slow device.   This may be usefu= l to
 the att= acker.  However, if the attacker has access to PDM, the
 attacker also has access t= o the entire packet and could make such a
 deduction based merely on the time frames e= lapsed between packets
 WITHOUT PDM.  

<= div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1495466060991_7008"> As far as deducing the co= ntent of the payload, it appears to us that
 PDM is quite unhelpful in this regard.



New
------

Since PDM passes in the clear, a concern arises a= s to whether the
data can be used t= o fingerprint the system or somehow obtain
information about the contents of the payload. &n= bsp;

Let us discuss fingerprinting of the end host first. It i= s possible
that se= eing the pattern of deltas or the absolute values could give
some information as to the speed= of the end host - that is, if it is
a very fast system or an older, slow device.   This= may be useful to
= the attacker.  However, if the attacker has access to PDM, the<= /div>
attacker also has access = to the entire packet and could make such a
deduction based merely on the time frames elapsed= between packets
W= ITHOUT PDM.  

As far as deducing the content of the paylo= ad, it is conceivable
that an attacker could attempt to deduce the type of application in
use by noting the ser= ver time and payload length.   Having said that,
some encryption algorithms attempt to = obfuscate the packet length
=
to avoid just such vulnerabilities.  In the future, encryptio= n algorithms
may wish t= o obfuscate the server time as well.  



------=_Part_4233695_1329711182.1495466806423-- From nobody Mon May 22 08:41:20 2017 Return-Path: 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 85BBB12EAFF for ; Mon, 22 May 2017 08:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.111 X-Spam-Level: *** X-Spam-Status: No, score=3.111 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ABTOYFj_pzMw for ; Mon, 22 May 2017 08:41:16 -0700 (PDT) Received: from sonic304-31.consmr.mail.gq1.yahoo.com (sonic304-31.consmr.mail.gq1.yahoo.com [98.137.68.212]) (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 BA14F1293D9 for ; Mon, 22 May 2017 08:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1495467676; bh=1k5IPL9AtEXHlGZArXKRixGQjuMAyGKkQdxAWBFYtlw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=CISVf7dCJ6JM76kJK0VK2vR6wEjQfNqPImOqT6AcbbCaQ/WjSBIJ+I3H8t2k3mwIBeCv+aVpTpBCnbOp7rBI7juIFhAb7UDqI5BVApMyM3KP6dUUJSTSiUoBnsbHWluS2jsyB2+WP75lyCDX7NyT2n2SusDzvL4G/QlO8YRfPLcKENY7xLfN3n51cNNIhWKcwRCerEoCOhmxj8dvRZo3skhEDRh5osa4nHKu689/HF4A/hQ0OGNaDRiYHd5veNdc6B9o6ZMRpzJ6MdP2+sLDVvIqoAHxsGWm5QOVeu62fwwOB6/uMcC3PwMNRvZJ7WyQxM10Hb90H4dMlrQ9uBiJ8w== X-YMail-OSG: RwHbZOQVM1lfZt1jLdhVRIxshvd9EMmPpIputZ78uiiaYedIueqNVwTZ.F3sk5v .Yi_CFucLmrXfMxptOEFbZaLBbBM9K5cEC4ZfR.ZiszSYIF_QSAyKb00y0rSoyw.K37sOlrOPl0R DQEm913JaRyQISHc6iEtMwL3hQff1tpoQgS0z9eZnYLvcBsOX4UG5XpS1pKqSHO9EDSX1gvHbBND EPgHo1KPhbkPXO7JIFAfgw0DH_RTm.nVfAl4tY4vgNq4_Ae43vhC36C7BHnqwhG6jY7RfslWQrkr EZ4SB_t5RCOdqZNpLdXi6.ebKgyTL.3JR2Pjm12m.ZsihfbIrZ_VHw8SK6Fr3_m9XCs3uIlhWBkP QR4LzkJg1_PBpzArQP8iMfwB3i7Fgtsb23hlAomnSr0bu3Lz_Wsjzj14ZdAHchkGVM5LxPviawGv UZqdpjdbyvKOWbaGip64f0wQ94KrBl__WN2FbiBXNPg3HkeHAfmpDqCrYcFsXcXntFC4sn4sClPW VbsdVpuQhg1.aFhtX20CBXFNLbhUZarZbmdf0KoRuVCjpz34GQocBRd2pcVsPaGf5qdR8LJOP1fZ ns5hPM7wxHOWro2YAG99.w52Kg0bcdsYilW.8mB0LmG9Hwl9tDB4rhyiSnQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 May 2017 15:41:16 +0000 Date: Mon, 22 May 2017 15:40:58 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Eric Rescorla , The IESG Cc: "draft-ietf-ippm-6man-pdm-option@ietf.org" , Al Morton , Bill Cerveny , "ippm-chairs@ietf.org" , "ippm@ietf.org" Message-ID: <1119101915.4268397.1495467658355@mail.yahoo.com> In-Reply-To: <149195586781.15796.5030067129991289423.idtracker@ietfa.amsl.com> References: <149195586781.15796.5030067129991289423.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4268396_425439693.1495467658348" X-Mailer: WebService/1.1.9679 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Archived-At: Subject: Re: [ippm] Eric Rescorla'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 15:41:19 -0000 ------=_Part_4268396_425439693.1495467658348 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >Eric Rescorla has entered the following ballot position for=C2=A0draf= t-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/ >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- >I think the description of timing attacks could use a bit more work. >Specifically: >- I am assuming that you should discard rather than using as timestamp > =C2=A0sources packets which fail ESP. This shouldn't be an issue for > =C2=A0transport mode because you process ESP first, but in tunnel mode > =C2=A0you allow either order, so it's a potential issue. I believe some of this is addressed in section 4.3. =C2=A0 I can add that t= hedestination host may also wish to look at this behavior and to=C2=A0disca= rd such packets. =C2=A0=C2=A0 OLD------ 4.3 PDM as a Covert Channel =C2=A0 =C2=A0PDM provides a set of fields in the packet which could be used= to=C2=A0 =C2=A0leak data. =C2=A0 But, there is no real reason to suspect t= hat PDM would=C2=A0 =C2=A0be chosen rather than another part of the payload= or another=C2=A0 =C2=A0Extension Header. =C2=A0 =C2=A0A firewall or another device could sanity check the fields wit= hin the=C2=A0 =C2=A0PDM but randomly assigned sequence numbers and delta ti= mes might be=C2=A0 =C2=A0expected to vary widely. =C2=A0 The biggest proble= m though is how an=C2=A0 =C2=A0attacker would get access to PDM in the firs= t place to leak data.=C2=A0=C2=A0 =C2=A0The attacker would have to either c= ompromise the end host or have Man=C2=A0 =C2=A0in the Middle (MitM). =C2=A0= It is possible that either one could change=C2=A0 =C2=A0the fields. =C2=A0 = But, then the other end host would get sequence numbers=C2=A0 =C2=A0and del= tas that don't make any sense. =C2=A0=C2=A0 =C2=A0 =C2=A0It is conceivable that someone could compromise an end host an= d make=C2=A0 =C2=A0it start sending packets with PDM without the knowledge = of the host.=C2=A0=C2=A0 =C2=A0But, again, the bigger problem is the compro= mise of the end host. =C2=A0=C2=A0 =C2=A0Once that is done, the attacker pr= obably has better ways to leak=C2=A0 =C2=A0data. =C2=A0 =C2=A0Having said that, if a PDM aware middle box or an implementati= on=C2=A0 =C2=A0detects some number of "nonsensical" sequence numbers it cou= ld take=C2=A0 =C2=A0action to block (or alert on) this traffic. New------=C2=A04.3 PDM as a Covert Channel =C2=A0 =C2=A0PDM provides a set of fields in the packet which could be used= to=C2=A0 =C2=A0leak data. =C2=A0 But, there is no real reason to suspect t= hat PDM would=C2=A0 =C2=A0be chosen rather than another part of the payload= or another=C2=A0 =C2=A0Extension Header. =C2=A0 =C2=A0A firewall or another device could sanity check the fields wit= hin the=C2=A0 =C2=A0PDM but randomly assigned sequence numbers and delta ti= mes might be=C2=A0 =C2=A0expected to vary widely. =C2=A0 The biggest proble= m though is how an=C2=A0 =C2=A0attacker would get access to PDM in the firs= t place to leak data.=C2=A0=C2=A0 =C2=A0The attacker would have to either c= ompromise the end host or have Man=C2=A0 =C2=A0in the Middle (MitM). =C2=A0= It is possible that either one could change=C2=A0 =C2=A0the fields. =C2=A0 = But, then the other end host would get sequence numbers=C2=A0 =C2=A0and del= tas that don't make any sense. =C2=A0=C2=A0 =C2=A0 =C2=A0It is conceivable that someone could compromise an end host an= d make=C2=A0 =C2=A0it start sending packets with PDM without the knowledge = of the host.=C2=A0=C2=A0 =C2=A0But, again, the bigger problem is the compro= mise of the end host. =C2=A0=C2=A0 =C2=A0Once that is done, the attacker pr= obably has better ways to leak=C2=A0 =C2=A0data. =C2=A0 =C2=A0Having said that, if a PDM aware middle box or an implementati= on (destination=C2=A0 =C2=A0host) detects some number of "nonsensical" sequ= ence numbers or timing=C2=A0 =C2=A0information, it could take action to blo= ck, discard, or alert on this traffic. >- It seems like you could use this technique for fine-grained> =C2=A0timin= g of the cryptographic operations traffic keys as well (cf. Lucky 13),> =C2= =A0not just long-term keys as you say in S 4.4. > Note that both of these attacks are not ameliorated by restricting > to host and ports because one assumes that the attacker controls > the network per 3552 I can change the language in section 4.4 as follows: Old----=C2=A0 =C2=A0Depending on the nature of the cryptographic protocol u= sed, it may be=C2=A0 =C2=A0possible to leak the long term credentials of th= e device. =C2=A0For=C2=A0 =C2=A0example, if an attacker is able to create a= n attack which causes the=C2=A0 =C2=A0enterprise to turn on PDM to diagnose= the attack, then the attacker=C2=A0 =C2=A0might use PDM during that debugg= ing time to launch a timing attack=C2=A0 =C2=A0against the long term keying= material used by the cryptographic=C2=A0 =C2=A0protocol. New----=C2=A0 =C2=A0Depending on the nature of the cryptographic protocol u= sed, it may be=C2=A0 =C2=A0possible to leak the credentials of the device. = =C2=A0For=C2=A0 =C2=A0example, if an attacker is able to create an attack w= hich causes the=C2=A0 =C2=A0enterprise to turn on PDM to diagnose the attac= k, then the attacker=C2=A0 =C2=A0might use PDM during that debugging time t= o launch a timing attack=C2=A0 =C2=A0against the keying material used by th= e cryptographic protocol. =C2=A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 =20 ------=_Part_4268396_425439693.1495467658348 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


>Eric Rescorla has entered the following ballot pos= ition for draft-ietf-ippm-6man-pdm-opti= on-09: No Objection

>for more information about IESG DISCUSS and COMMENT = positions.

=

>The document, along with oth= er ballot positions, can be found here:


>-----------------------= -----------------------------------------------
>COMMENT:
>---------------------------------------= -------------------------------

>I think the description of timing attacks could use a bit more work.=

>Specifically:
<= div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1495466060991_9145" style=3D"font-f= amily: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "L= ucida Grande", sans-serif; font-size: 16px;">
>- I am assuming that you should dis= card rather than using as timestamp
>  sources packets which fail ESP. This should= n't be an issue for
>  transport mode because you process ESP first, but in tunnel= mode
> &nbs= p;you allow either order, so it's a potential issue.


I be= lieve some of this is addressed in section 4.3.   I can add that the
destination host may= also wish to look at this behavior and to 
discard such packets.   


OLD
------

4.3 PDM as a Covert Channel

   PDM provides a set of fields in the packet which could b= e used to
   leak data.   But, there is no real reason to suspect th= at PDM would
   be chosen rather than another part of the payload or anot= her
&nbs= p;  Extension Header.

<= div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1495466060991_10678">   A= firewall or another device could sanity check the fields within the
<= div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1495466060991_10679">   P= DM but randomly assigned sequence numbers and delta times might be
   exp= ected to vary widely.   The biggest problem though is how an
   atta= cker would get access to PDM in the first place to leak data. 
   Th= e attacker would have to either compromise the end host or have Man
   in= the Middle (MitM).  It is possible that either one could change
=
   = the fields.   But, then the other end host would get sequence numbers<= /div>
  &= nbsp;and deltas that don't make any sense.   

   It is conceivable that someone could compromise= an end host and make
   it start sending packets with PDM without the kn= owledge of the host. 
   But, again, the bigger problem is the compr= omise of the end host.  
   Once that is done, the attacker probably= has better ways to leak
   data.

 = ;  Having said that, if a PDM aware middle box or an implementation
  &nb= sp;detects some number of "nonsensical" sequence numbers it could take
   = ;action to block (or alert on) this traffic.

<= /div>

New
 
4.3 PDM as a Covert Channel

   PDM provides a set of fields in the= packet which could be used to
   leak data.   But, there is no real= reason to suspect that PDM would
   be chosen rather than another part o= f the payload or another
   Extension Header.

   A firewall or another device could sanity check the fie= lds within the
   PDM but randomly assigned sequence numbers and delta ti= mes might be
   expected to vary widely.   The biggest problem thoug= h is how an
   attacker would get access to PDM in the first place to lea= k data. 
   The attacker would have to either compromise the end hos= t or have Man
   in the Middle (MitM).  It is possible that either o= ne could change
   the fields.   But, then the other end host would = get sequence numbers
   and deltas that don't make any sense.   = ;

   It is conceivable that som= eone could compromise an end host and make
   it start sending packets wi= th PDM without the knowledge of the host. 
   But, again, the bigger= problem is the compromise of the end host.  
   Once that is done, = the attacker probably has better ways to leak
   data.

   Having said that, if a PDM aware middle box or= an implementation (destination
   host) detects some number of "nonsensi= cal" sequence numbers or timing
   information, it could take action to b= lock, discard, or alert on this traffic.



>- It seems like you could use this technique for fine-graine= d
=
>  ti= ming of the cryptographic operations traffic keys as well (cf. Lucky 13),
> &nbs= p;not just long-term keys as you say in S 4.4.

> Note that both = of these attacks are not ameliorated by restricting
> to host and ports because one assumes that the attac= ker controls
> the network per = 3552
I can = change the language in section 4.4 as follows:

Old
----
   Depending on the nature of the cryptographic p= rotocol used, it may be
   possible to leak the long term credentials of = the device.  For
   example, if an attacker is able to create an att= ack 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
   against the long term keying material used by the cryp= tographic
   protocol.

New
---= -
   Depend= ing on the nature of the cryptographic protocol used, it may be
   possib= le to leak the credentials of the device.  For
   example, if an att= acker is able to create an attack which causes the
   enterprise to turn = on PDM to diagnose the attack, then the attacker
   might use PDM durin= g that debugging time to launch a timing attack
   against the keying mat= erial used by the cryptographic protocol.


 
Thanks,

Nalini Elkins
CE= O and Founder
Inside Produc= ts, Inc.
www.insidethestack= .com
(831) 659-8360


------=_Part_4268396_425439693.1495467658348-- From nobody Mon May 22 08:54:01 2017 Return-Path: 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 D3C2012EB00 for ; Mon, 22 May 2017 08:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.111 X-Spam-Level: *** X-Spam-Status: No, score=3.111 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 42Xgt1ipjbxZ for ; Mon, 22 May 2017 08:53:53 -0700 (PDT) Received: from sonic304-31.consmr.mail.gq1.yahoo.com (sonic304-31.consmr.mail.gq1.yahoo.com [98.137.68.212]) (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 36BED12EAFF for ; Mon, 22 May 2017 08:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1495468431; bh=e2Jjr1YExLLqXhxacDoPr6xxxu/EJs5iqMxCnEtAv5I=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=GF9svqUvAe6593nm6xxUXf497gHpcvdkOuedmAH3X/l98ExD6XQnj+aeJV0VfBWtcIN/QSJuTAF3c9SicE6Irx/OQ8hJ4kzHJWsh1hz1rAwnM95JD74rLoEqSTWdC4DHq7p7kv5jIylvybhOx8fYwdUP6wsv3OvqUi6/F6ppwU2Az+vXDsxkPI5kiFuRRou7WZjpgQHV/8SXs/CyKMB/Ri5sMyz+yqAsoymCleoyvr8w5BUowE0bPJTpGwvxXDDbLgZwk+u+/ylRJCw8iMWw/QAz9ss1prvn76GVmVpGg2thJttNSIsihwhOXvlDYYGBIXj1TvUk9h7jO8nPMERZ1w== X-YMail-OSG: 8PaifAsVM1lR_ckQte8R3aV9ZJxvxW_eUR4oa2Hw3ohHb41XLm8puQNZovyRmPb BARLI2.QgnnYEyqeTZZOWJFkxkj9Ow4nN6mv2oext6xGavqgTxIjMLevxxCwTsiiyATVWFjilJnF y5AHvLBBGHTmJDtnmMzdC8fLVwY0_GG3H217hGKz_Bvc29I6oWN9nvIi39W8IOgKaGiz7aP_c6Km cZBVI24OkKBh2XpiEgbAn9Hee_SYseMcSj0aMInydd0N6_nNKa9IHF0cFunnS2j3FNEY3exQtc3M eiRL51kQY8Zjfs7S70owG0mbdKPRHU4mq1Ju..hNmLswxM.nphixaXjne7d1L_bKSGLnkeeNEgGY A7tBSkR6utf_rSeBXBuPHxjHUI8KVnUELzCz_FaVLKjsLt5w3SPAKf7lDsFmhYKIS0LXUwaiAHtm RYlYx85cVB5QAPVcp1__avqjq6KhxdDjDWGzo4CH.GI2JlN8Wrgo850tg4JeN56moycEpuHqwTlV ReH512ZGuo.kw4Ig_dGn5XO.Rv.gL7YWxf39lQTlBZh9Xt.XpKPOeThZeU8V5toqaRCuxE3HIoEK j4181_GV8fJpkGCKRErOQ_iJb Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 May 2017 15:53:51 +0000 Date: Mon, 22 May 2017 15:53:50 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Kathleen Moriarty , The IESG Cc: "draft-ietf-ippm-6man-pdm-option@ietf.org" , Al Morton , Bill Cerveny , "ippm-chairs@ietf.org" , "ippm@ietf.org" Message-ID: <1204178987.1519503.1495468430679@mail.yahoo.com> In-Reply-To: <149192747464.15682.3691319250872731449.idtracker@ietfa.amsl.com> References: <149192747464.15682.3691319250872731449.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1519502_1559434566.1495468430675" X-Mailer: WebService/1.1.9679 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Archived-At: Subject: Re: [ippm] Kathleen Moriarty'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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 15:53:55 -0000 ------=_Part_1519502_1559434566.1495468430675 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Kathleen Moriarty has entered the following ballot position for draft-iet= f-ippm-6man-pdm-option-09: No Objection > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html= =C2=A0for more information about IESG DISCUSS and COMMENT positions. > The document, along with other ballot positions, can be found here:=C2=A0= https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ >---------------------------------------------------------------------- >COMMENT: > ---------------------------------------------------------------------- > I support Warren's discuss and comments and have a few additional comment= s to add. >Kind of related to Warren's discuss, I kept looking for a limitation to >the scope for this work in the draft and didn't get to one until the end >of the security considerations section.=C2=A0 The text there wasn't quite >clear enough for me.=C2=A0 It seems that this might only be used for small >periods of time while troubleshooting, is that correct?=C2=A0 It also seem= s >like this has to be end-to-end, is that right?=C2=A0 And if it does need t= o be >end-to-end, is the user aware of this troubleshooting so that they are >not sending traffic that contains sensitive data that should remain >confidential (security or privacy implications may also exist if this is >not the case). >If the scope were limited, I would not have as many security concerns.=20 >Network reconnaissance may or may not be an issue.=C2=A0 I don't think it = is, >but I need to better understand the scope of use for this option. We have added wording on the "Consent to be Measured" as a responseto Warre= n's comments. =C2=A0 Please let me know if that addresses yourconcerns. In Section 4.4 =C2=A0 =C2=A0An implementation may want to be sure that PDM is enabled only= for =C2=A0 =C2=A0certain ip addresses, or only for some ports. =C2=A0Additional= ly, the=C2=A0 =C2=A0implementation SHOULD require an explicit restart of mo= nitoring after=C2=A0 =C2=A0a certain time period (for example for 1 hour), = to make sure that PDM=C2=A0 =C2=A0is not accidentally left on after debuggi= ng has been done etc.=C2=A0 =C2=A0 =C2=A0Even so, if using PDM, a user "Consent to be Measured" SHOULD = be a=C2=A0 =C2=A0pre-requisite for using PDM. =C2=A0Consent is common in en= terprises and=C2=A0 =C2=A0with some subscription services. =C2=A0The actual= content of "Consent to=C2=A0 =C2=A0be Measured" will differ by site but it= SHOULD make clear that the=C2=A0 =C2=A0traffic is being measured for quali= ty of service and to assist in=C2=A0 =C2=A0diagnostics as well as to make c= lear that there may be potential=C2=A0 =C2=A0risks of certain vulnerabiliti= es if the traffic is captured during a=C2=A0 =C2=A0diagnostic session =C2=A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 =20 ------=_Part_1519502_1559434566.1495468430675 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



> Kat= hleen Moriarty has entered the following ballot position for draft-ietf-ipp= m-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: h= ttps://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/
<= div dir=3D"ltr" style=3D"font-family: HelveticaNeue, "Helvetica Neue&q= uot;, Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 1= 6px;" id=3D"yui_3_16_0_ym19_1_1495466060991_24010">

>----------------------------------------------= ------------------------
>COMMENT:
> ------------------------------------------------------------= ----------
> I support W= arren's discuss and comments and have a few additional comments to add.

>Kind of related to Warren's di= scuss, I kept looking for a limitation to
>the scope for this work in the draft and di= dn't get to one until the end
>of the security considerations section.  The text = there wasn't quite
>clear enough for me.  It seems that this might only be used f= or small
>p= eriods of time while troubleshooting, is that correct?  It also seems<= br>
>like this = has to be end-to-end, is that right?  And if it does need to be
>end-to-end, is t= he user aware of this troubleshooting so that they are
>not sending traffic that conta= ins sensitive data that should remain
>confidential (security or privacy implications = may also exist if this is
>not the case).

>If the scope were limited, I would not have as many security concer= ns.
>Netwo= rk reconnaissance may or may not be an issue.  I don't think it is,
>but I need = to better understand the scope of use for this option.


We have added wording on the "Consent to be Measured" as a r= esponse
to Warren'= s comments.   Please let me know if that addresses your
concerns.

In Section 4.4

   An implementation may want to be sure that PDM is enabl= ed only for
   certain= ip addresses, or only for some ports.  Additionally, the
=
   implementation = SHOULD require an explicit restart of monitoring after
   a certain time period (= for example for 1 hour), to make sure that PDM
   is not accidentally left on aft= er debugging has been done etc. 

   Even s= o, if using PDM, a user "Consent to be Measured" SHOULD be a
   pre-requisite for= using PDM.  Consent is common in enterprises and
   with some subscription = services.  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 o= f service and to assist in
   diagnostics as well as to make clear that there may= be potential
&n= bsp;  risks of certain vulnerabilities if the traffic is captured duri= ng a
  &nbs= p;diagnostic session


&n= bsp;
Thanks,
<= br id=3D"yui_3_16_0_ym19_1_1495466060991_23751">Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360



=
------=_Part_1519502_1559434566.1495468430675-- From nobody Mon May 22 10:23:00 2017 Return-Path: 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 C696E12EB34; Mon, 22 May 2017 10:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 heIZiDreWDBP; Mon, 22 May 2017 10:22:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E6F12EB31; Mon, 22 May 2017 10:22:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNO25288; Mon, 22 May 2017 17:22:49 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 22 May 2017 18:22:48 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.56]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0235.001; Mon, 22 May 2017 10:22:46 -0700 From: Haoyu song To: "ippm@ietf.org" , "draft-brockners-inband-oam-data.authors@ietf.org" Thread-Topic: draft on iOAM scalability improvement Thread-Index: AdLTH0fsZe3MoWIbQhuBeTS1CfmKpQ== Date: Mon, 22 May 2017 17:22:45 +0000 Message-ID: <78A2745BE9B57D4F9D27F86655EB87F925845299@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.217.123] Content-Type: multipart/alternative; boundary="_000_78A2745BE9B57D4F9D27F86655EB87F925845299SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59231E6C.00BB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 67b22826cc411efc1e0f0a145e1d47bf Archived-At: Subject: [ippm] draft on iOAM scalability improvement X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 17:22:58 -0000 --_000_78A2745BE9B57D4F9D27F86655EB87F925845299SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, We have submitted an iOAM related draft as follows. Please kindly provide = comments and also let us know if you have any questions which will help us= continue to improve the draft. Thank you very much! https://datatracker.ietf.org/doc/draft-song-ippm-ioam-scalability/ Abstract: This document describes several scalability issues in current in-situ OAM documents and proposes corresponding solutions. Specifically, we extend in-situ OAM to support more standard tracing data than is currently defined and add new features to avoid limitations on MTU, bandwidth, forwarding path length, and node processing capability. Haoyu --_000_78A2745BE9B57D4F9D27F86655EB87F925845299SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

We have submitted an iOAM related draft as follows. =  Please kindly provide  comments and also let us know if you have= any questions which will help us continue to improve the draft. Thank you = very much!

 

https://datatracker.ietf.org/doc/draft-song-ippm= -ioam-scalability/

 

Abstract:

   This document describes several scal= ability issues in current in-situ

   OAM documents and proposes correspon= ding solutions.  Specifically, we

   extend in-situ OAM to support more s= tandard tracing data than is

   currently defined and add new featur= es to avoid limitations on MTU,

   bandwidth, forwarding path length, a= nd node processing capability.

 

 

Haoyu

        &nbs= p;            &= nbsp;   

--_000_78A2745BE9B57D4F9D27F86655EB87F925845299SJCEML701CHMchi_-- From nobody Mon May 29 08:26:29 2017 Return-Path: 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 AAFDD129ABD for ; Mon, 29 May 2017 08:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 F4lH8rmr4FSx for ; Mon, 29 May 2017 08:26:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D37129A97 for ; Mon, 29 May 2017 08:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3768; q=dns/txt; s=iport; t=1496071586; x=1497281186; h=from:to:subject:date:message-id:mime-version; bh=VRSIbzoQApDBW2nn/741YvT0R1w+Y1bt7pt8lXq3qAY=; b=g/XT1jobr8UA7AScKxSoGgpSH0cBtx7dYQLPVtVjED6YyQIZBV5DaPUT lFagCDIA9sqROM7oJnw2ecP8kMiG02Xmhg3PUqJpDwzJLM/+/9o1/MAzu ZxIoDCpe6rAUSuAPAzXRiiDjfZ8Y4PwmuU+P6lcA5O6BQSae9kc6fY0Nv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAACJPCxZ/4UNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm5nYoEUjgOiJ4U4gg8siH0/GAECAQEBAQEBAWsdC4VMQR0BDHQmAQQ?= =?us-ascii?q?biT5kEJwDkjGLRgEBAQEBAQQBAQEBAQEBHAWGYYFggx+KWwWeIwGBWoVFi3+SA?= =?us-ascii?q?JRNAR84gQp0FUaHAok9gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.38,415,1491264000"; d="scan'208,217";a="251113542" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 May 2017 15:26:25 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v4TFQPRj026357 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 29 May 2017 15:26:25 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 29 May 2017 10:26:24 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Mon, 29 May 2017 10:26:24 -0500 From: "Frank Brockners (fbrockne)" To: "ippm@ietf.org" Thread-Topic: New version of draft-brockners-inband-oam-data Thread-Index: AdLYjvLxAPnurOCbRvq3lN56EHW3dg== Date: Mon, 29 May 2017 15:26:23 +0000 Message-ID: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.117.5] Content-Type: multipart/alternative; boundary="_000_7f26803fa1014333ba3854ef34429f20XCHRCD008ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [ippm] New version of draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 15:26:28 -0000 --_000_7f26803fa1014333ba3854ef34429f20XCHRCD008ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear IPPM WG, we've just posted an updated version of draft-brockners-inband-oam-data: ht= tps://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to ad= dress the recent comments on the mailing list. The main change is the verbi= age around the need to ensure that IOAM data is kept within the IOAM domain= . In addition, several editorial nits have been cleaned up. We appreciate your thoughts and comments. Regards, Frank --_000_7f26803fa1014333ba3854ef34429f20XCHRCD008ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear IPPM WG,=

 

we’ve just posted an upda= ted version of draft-brockners-inband-oam-data: = https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is= to address the recent comments on the mailing list. The main change is the= verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editor= ial nits have been cleaned up.

 

We appreciate your thoughts and= comments.

 

Regards, Frank

 

--_000_7f26803fa1014333ba3854ef34429f20XCHRCD008ciscocom_-- From nobody Tue May 30 00:14:44 2017 Return-Path: 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 71B4D129353 for ; Tue, 30 May 2017 00:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 ZQoad20o_PHJ for ; Tue, 30 May 2017 00:14:40 -0700 (PDT) Received: from mailout23.telekom.de (MAILOUT23.telekom.de [80.149.113.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C479F129B69 for ; Tue, 30 May 2017 00:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1496128479; x=1527664479; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EL7HrMJn6elE6A6PcUr58xSk7U1BNWCESllZfuMhy0Q=; b=WPcRZtmX5X4X3CSbuMM2bWn5age1AklbMlZ6n/mBlnZo8swAZBuiSxQD QzK/oIjgWpyxlEe96ReAtxLV64aSn+jsVHgKlruMFPSUkJXkMOklEu5gT BAMOL9465McpuDlyoZ2eiiE7caAtPilq3NkN3b9tBvsQetGFfe29HuqmS xpFUz0atmQ2XhjlEbdhbhsihNT+wMf6D2qG6aLOunGJLMVo7U++6dn52U RcIah9htLo3edOYBnpQ6q497Y1YUh2R6eVJvDOmzEpfefHQEQiXxakGQg zLwtSMPDU/F9NSsaRrJghlojwWXxfsYBL67OoMOdDQ+BvkvQ/2m7ORJCP g==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 May 2017 09:14:35 +0200 X-IronPort-AV: E=Sophos;i="5.38,417,1491256800"; d="scan'208,217";a="606397414" Received: from he101653.emea1.cds.t-internal.com ([10.134.226.13]) by qde0ps.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 May 2017 09:14:35 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101653.emea1.cds.t-internal.com (10.134.226.13) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 30 May 2017 09:14:34 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1263.000; Tue, 30 May 2017 09:14:34 +0200 From: To: CC: Thread-Topic: New version of draft-brockners-inband-oam-data Thread-Index: AdLYjvLxAPnurOCbRvq3lN56EHW3dgAhRlnw Date: Tue, 30 May 2017 07:14:34 +0000 Message-ID: <845b897770dc428b9e7c13b96989a7d5@HE101653.emea1.cds.t-internal.com> References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> In-Reply-To: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.165.15] Content-Type: multipart/alternative; boundary="_000_845b897770dc428b9e7c13b96989a7d5HE101653emea1cdstintern_" MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] New version of draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 07:14:42 -0000 --_000_845b897770dc428b9e7c13b96989a7d5HE101653emea1cdstintern_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Frank, the text relevant to keeping IOAM data within the IOAM domain is fine with = me. I quote it below: "Designers of carrier protocols for IOAM must specify mechanisms to ensure that in- situ OAM data stays within an IOAM domain. In addition, the operator of such a domain is expected to put provisions in place to ensure that IOAM data does not leak beyond the edge of an IOAM domain, e.g. using for example packet filtering methods." Regards, Ruediger Von: ippm [mailto:ippm-bounces@ietf.org] Im Auftrag von Frank Brockners (fb= rockne) Gesendet: Montag, 29. Mai 2017 17:26 An: ippm@ietf.org Betreff: [ippm] New version of draft-brockners-inband-oam-data Dear IPPM WG, we've just posted an updated version of draft-brockners-inband-oam-data: ht= tps://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is to ad= dress the recent comments on the mailing list. The main change is the verbi= age around the need to ensure that IOAM data is kept within the IOAM domain= . In addition, several editorial nits have been cleaned up. We appreciate your thoughts and comments. Regards, Frank --_000_845b897770dc428b9e7c13b96989a7d5HE101653emea1cdstintern_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Fran= k,

&n= bsp;

the tex= t relevant to keeping IOAM data within the IOAM domain is fine with me. I q= uote it below:

&n= bsp;

      “=
Designers of

   carrier protocols for IOAM mus= t specify mechanisms to ensure that in-

   situ OAM data stays within an = IOAM domain.  In addition, the operator

   of such a domain is expected t= o put provisions in place to ensure

   that IOAM data does not leak b= eyond the edge of an IOAM domain, e.g.

   using for example packet filte= ring methods.”

&n= bsp;

Regards= ,

&n= bsp;

Ruedige= r

&n= bsp;

Von: ippm [mai= lto:ippm-bounces@ietf.org] Im Auftrag von Frank Brockners (fbrockne)
Gesendet: Montag, 29. Mai 2017 17:26
An: ippm@ietf.org
Betreff: [ippm] New version of draft-brockners-inband-oam-data<= /o:p>

 

Dear IPPM WG,=

 

we’ve just posted an upda= ted version of draft-brockners-inband-oam-data: = https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is= to address the recent comments on the mailing list. The main change is the= verbiage around the need to ensure that IOAM data is kept within the IOAM domain. In addition, several editor= ial nits have been cleaned up.

 

We appreciate your thoughts and= comments.

 

Regards, Frank

 

--_000_845b897770dc428b9e7c13b96989a7d5HE101653emea1cdstintern_-- From nobody Tue May 30 01:17:52 2017 Return-Path: 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 4440C1287A3 for ; Tue, 30 May 2017 01:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 g0_JxmNdV7sv for ; Tue, 30 May 2017 01:17:47 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [IPv6:2001:8e0:40:325::45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C74129511 for ; Tue, 30 May 2017 01:17:47 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 708BB340E62 for ; Tue, 30 May 2017 10:17:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.19196); Tue, 30 May 2017 10:17:45 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for ; Tue, 30 May 2017 10:17:45 +0200 (CEST) Received: from [195.176.111.30] (account ietf@trammell.ch HELO public-docking-cx-1324.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 19083751 for ippm@ietf.org; Tue, 30 May 2017 10:17:45 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_91B8CD16-0DDE-40FB-A88D-92FB3195025D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> Date: Tue, 30 May 2017 10:17:44 +0200 Message-Id: <5D244444-2A45-474D-928E-EA18B206DA5D@trammell.ch> References: <7f26803fa1014333ba3854ef34429f20@XCH-RCD-008.cisco.com> To: "ippm@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [ippm] Adoption call for draft-brockners-inband-oam-data X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 08:17:50 -0000 --Apple-Mail=_91B8CD16-0DDE-40FB-A88D-92FB3195025D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, IPPM, At our Chicago meeting, we decided we needed a single, cleaned-up = document containing appropriate scoping and rationale in order to make a = decision as to whether we'd like to adopt IOAM within IPPM. This = revision of draft-brockners-inband-oam-data is that document. This message, therefore, starts a call for adoption on = draft-brockners-inband-oam-data, to run until EOB CEST (UTC +2) Tuesday = 20 June 2017. Please reply to ippm@ietf.org indicating: (1) whether you support addition of the following milestone to the IPPM = charter: date TBD: Submit an Experimental draft on inband OAM based measurement = methodologies to the IESG (2) whether you support the adoption of = draft-brockners-inband-oam-data-05 as the basis document for this = milestone (3) whether you commit to reviewing the document if adopted We are aware that there is an open question as to whether we can adopt = draft-brockners-inband-oam-data under our current charter; we'd like to = see if there is IPPM WG consensus on adoption before discussing a = recharter, hopefully before Prague, though we can take face-to-face time = in Prague for this if necessary. Our intention, as chairs, is to make = the minimal necessary change to the charter should there be consensus = for adoption. However, if you have particular opinions as to how this = should be done, please also address these in your message. Many thanks, best regards, Brian (as IPPM co-chair) > On 29 May 2017, at 17:26, Frank Brockners (fbrockne) = wrote: >=20 > Dear IPPM WG, >=20 > we=E2=80=99ve just posted an updated version of = draft-brockners-inband-oam-data: = https://tools.ietf.org/html/draft-brockners-inband-oam-data-05 which is = to address the recent comments on the mailing list. The main change is = the verbiage around the need to ensure that IOAM data is kept within the = IOAM domain. In addition, several editorial nits have been cleaned up. >=20 > We appreciate your thoughts and comments. >=20 > Regards, Frank >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_91B8CD16-0DDE-40FB-A88D-92FB3195025D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZLSqoAAoJEIoSt78L6kajXkcQAMn9kKVVmciCsIpysnzkfLmS O3zAw9GGgtYWx1zbzqSwatH8I0sBIWdOhUmbVkFj6EVH330Lr5r37UHfBo+UXsmu 61f1P1R6xx7+bn2bd2AyWY3aTKRgBp32AA/5gnvywewU0wRGu/+5yV2rDBJjo5Uq AbtJTX3sk+LCQcZ0sBHVZ1HmEKUcTNbhT3idf8hIPyOetbVc6wE3Y8bxDD1vg3NF 4G435HWvA04EkXvnLnHquld2wnZoGcbnJ99OOfIo3Bk3Blueev0CUKYMGYL8xg+u J+E+YRIuZ1oSnxNO91HtZUeN1aZtQrsIFxBQ/NNCVWVHQkWbbTbQOsRWgHQo8TLi IdtOobCz+ASx+ZmlgMOPGlyK/XqWkg/wFWC6dTAQRyCdqlg+q9tK7cyJiUf7Dhoo 4eznLSsiskAM6AI4GYkQt7GZg61j1YsQGGZy+rpRkuak8OLp2StDkId1ErvE9sI9 lNAwtYL4y+S0GyXc+JmUAkVh8brhIEs0SVjrDFkQQlJnGGpYHQJPHl31XIs/Tr5C AvsLD7M9FkThR4vOHgeRBzUcMyUrFL0z5/k+UWeka246M/R2gDLdPqbFOb05H1Af +AG2ANnfwt6bLaf9J5PO6ANoTwggOGvRxb9fK7vyfaLxd08ngxMiYoZ6OX50mBMi 5xYDbEh9RVvmto/3kPy1 =TbUx -----END PGP SIGNATURE----- --Apple-Mail=_91B8CD16-0DDE-40FB-A88D-92FB3195025D-- From nobody Tue May 30 08:51:52 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE29129AAA; Tue, 30 May 2017 08:51:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ietf@trammell.ch, ippm-chairs@ietf.org, spencerdawkins.ietf@gmail.com, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149615951050.14785.1158519878390040508.idtracker@ietfa.amsl.com> Date: Tue, 30 May 2017 08:51:50 -0700 Archived-At: Subject: [ippm] ippm - New Meeting Session Request for IETF 99 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:51:51 -0000 A new meeting session request has just been submitted by Brian Trammell, a Chair of the ippm working group. --------------------------------------------------------- Working Group Name: IP Performance Metrics Area Name: Transport Area Session Requester: Brian Trammell Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: tsvarea tsvwg tcpm taps bmwg lmap xrblock quic Second Priority: v6ops 6man 6lo sunset4 opsec tcpinc Third Priority: cdni alto People who must be present: Al Morton Frank Brockners Spencer Dawkins Brian Trammell Bill Cerveny Kostas Pentikousis Giuseppe Fioccola Resources Requested: Special Requests: Please try not to schedule opposite irtfopen, iccrg, maprg. Do not schedule opposite panrg (hard conflict with chair) --------------------------------------------------------- From nobody Tue May 30 08:53:32 2017 Return-Path: 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 D71071294C4 for ; Tue, 30 May 2017 08:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NhAAdSRkGcla for ; Tue, 30 May 2017 08:53:29 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [IPv6:2001:8e0:40:325::45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F0912954D for ; Tue, 30 May 2017 08:53:29 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E5E5A340F2A for ; Tue, 30 May 2017 17:53:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.2147); Tue, 30 May 2017 17:53:26 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for ; Tue, 30 May 2017 17:53:26 +0200 (CEST) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 19149521 for ippm@ietf.org; Tue, 30 May 2017 17:53:26 +0200 From: "Brian Trammell (IETF)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_7FEAEBCA-F901-4C8B-9788-2327E65C6063"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 30 May 2017 17:53:26 +0200 Message-Id: <385D6D26-8B95-4473-AD1A-D384C61809D5@trammell.ch> To: IETF IPPM WG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [ippm] WGLC on draft-ietf-ippm-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:53:31 -0000 --Apple-Mail=_7FEAEBCA-F901-4C8B-9788-2327E65C6063 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, IPPM, As discussed in Chicago, this message begins a Working Group Last Call = on draft-ietf-ippm-alt-mark, to to run until EOB CEST (UTC +2) Tuesday = 20 June 2017. Please reply to ippm@ietf.org indicating whether you = believe this document is ready for publication, and if not, why not. Many thanks, best regards, Brian (as IPPM co-chair) --Apple-Mail=_7FEAEBCA-F901-4C8B-9788-2327E65C6063 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZLZV2AAoJEIoSt78L6kajiGMP/RQvRB5faZGUOS5MJzrF0EqS ndCEsd5YbN14K5BjOma7n2aECTYIzPjUyLAV98LWdnEfe4Ui0yoHEKS7Q9sJojpB TGrnFxYCkdEdMi/9Ov5WFN+It1lVC+9pLx7bvTqvhqSFc/WLuRbcERuc4h1P3NYK bO5O5l9Ylfc076zoVDwm2vc6jbLd1ga/A7CGUL/n44xgE18POiH8mx+6nR8dDfbN x7YU55R2vgLCXFTDQTRET0roWZAWLrmnadt8eriUISonfdk5bUyFukJPNEwtnQjL 6utRPgaNUPNGWHGnrjuA4ohcSzgCowgimMcxPvn8tcfrdOHfq2HxaOuplceIVQrT XUPkf0YTgjl26TPcwV9mw8Hqm1uJUi46IiBOpIhnyPvgQ/OLWy3m5h3MBTx+0rwa iT1rqriyJoQ8C+gARgTL15EK3VX8bIGa/eakGEK+vaZ4/sDpakZL2ABNMPDoCYoc BmtUH0WNWRy04wTMAEWrMBXCgqpYoaqO4nfrNZ6DVSTYWN2KvhKXxZtR3JQillOn 2hRxrXIjss4scAsGoTfE+DhNWVyShNEAJUyz5VUHIvBSv7pkuAAxFqRX+6E3HP5l zIof/Dca5MztIqJiHhKG38B74jP7yZSXqwZcbDpee6rqphzeHBUvKQW7P6XICHiF FvYiYjy8AarLiKlYi4ZM =BjMU -----END PGP SIGNATURE----- --Apple-Mail=_7FEAEBCA-F901-4C8B-9788-2327E65C6063-- From nobody Wed May 31 14:43:12 2017 Return-Path: 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 B4C1212E3AE for ; Wed, 31 May 2017 14:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.823 X-Spam-Level: X-Spam-Status: No, score=-11.823 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 e7j-qtaurK7w for ; Wed, 31 May 2017 14:43:09 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C13129C4C for ; Wed, 31 May 2017 14:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3999; q=dns/txt; s=iport; t=1496266989; x=1497476589; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=XmSPrpJjPDqo2WnKTdd4cDNjqotfUoGJ6A9GGGWt7tM=; b=bAfHdKPO+vc8SiLuC7tvFwRzoTm2UGCDr3ZXwScP4u2SyALu/QXd1z9g mS/mNIrlQwkhu2AQund9xChuuzqYwBJfu08gJV0rOVp40nWbrONBR9otx uQMP6VapTDqnIF4u1o103eOAsG/9TYBsrTMgvCKlfCtb7Iikb8YaCW+Qc M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AwA6OC9Z/5FdJa1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBg1WFYZtqlhqCD4JuhiVBFgECAQEBAQEBAWsohUIPAXsCJgJsCAEBiiacGZA?= =?us-ascii?q?LgiaMAoELhVaBYCsLgmmHe4JgBZ4jgVuRTYIGiQUjhkmUTiYFLIEKUSMVhUkcg?= =?us-ascii?q?X8kigkBAQE?= X-IronPort-AV: E=Sophos;i="5.39,276,1493683200"; d="scan'208";a="433887606" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 May 2017 21:43:08 +0000 Received: from [10.82.210.181] (rtp-vpn4-693.cisco.com [10.82.210.181]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v4VLh7MD011991 for ; Wed, 31 May 2017 21:43:08 GMT To: ippm@ietf.org From: Joe Clarke Organization: Cisco Message-ID: <46e942a8-5890-8244-eba2-7ba104e2e601@cisco.com> Date: Wed, 31 May 2017 17:43:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [ippm] Review of draft-brockners-inband-oam-data-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 21:43:11 -0000 Hello, IPPM WG. I'm not an active IPPM WG participant, so while Brian recently called for adoption of this document, I will defer a comment there. I did, however, read the document, and I have some comments to the WG and authors for consideration. One overall comment is that while "IOAM" is defined in the terminology section, it is not often used. Instead, the full "in-situ OAM" spelling is preferred. To me, this gets a bit tiresome to read. You have defined the abbreviation, and you should use it. === Section 4: I think it should be noted that nodes can be both in-situ encap/decap and transit nodes. That is, a node that adds the container could also write to it. === Section 4.1: In Section 4 you state that every node need not be an IOAM transit node. But here in 4.1 you state that for the tracing option all nodes should be transit/encap/decap nodes. While it doesn't say all nodes MUST be IOAM-aware, I think it would be beneficial if you stated (at least for operation purposes) what one would expect from a domain that contains non-IOAM-aware nodes. === Since an IOAM deployment MAY choose to support either the software or hardware optimized tracing options, how would one know what is supported across all nodes? It seems like one would need to encapsulate both if there is no a priori way to learn about this. === Your text discussing IOAM tracing options states: o Identification of the interface that a packet was received on. o Identification of the interface that a packet was sent out on. Later on you use the terms "ingress" and "egress". I think it would be good to use them here as well. === Section 4.1.1 You refer to Section 4.1.4 as describing the format of the IOAM data types, but this is really in 4.1.3, with 4.1.4 being examples of the data types (same in 4.1.2). === You only define two bits for an 8-bit Flags field. What is expected of the other six bits? === Section 4.1.2 Seems like a missed copy-paste from Section 4.1.1. You describe Bit 1 as: Bit 1 When set indicates presence of ingress_if_id and egress_if_id in the node data. And Bit 9 as: Bit 9 When set indicates presence of ingress_if_id and egress_if_id wide in the node data. I think you should keep what you have in Section 4.1.1: Bit 1 When set indicates presence of ingress_if_id and egress_if_id (short format) in the node data. Bit 9 When set indicates presence of ingress_if_id and egress_if_id in wide format in the node data. === With respect to Maximum Length, you say a simple comparison between "Opt Data Len" and "Max Length" should be enough to decide if data can be added. I'm not sure. In your description in Section 4.1 you state that the option header will have fields for "number of fields recorded" and "maximum number". I don't see how that jibes with Section 4.1.2. === Section 4.1.3 You don't have a block figure for "app_data". Seems odd considering you do for all other options. I'm also not clear on what this might be. You don't really describe it (same thing for wide app data). === Your wide ingress and egress interfaces use an overall 8-byte field, but your "empty" indicator is still 0xFFFFFFFF. I think this should either be 0xFFFFFFFFFFFFFFFF or you need to state that EACH 4-byte field needs to be all-Fs. === Section 4.2 You use POT, but you haven't added this to your terminology section above. It's clear to me what it means, but I think it's worth standardizing all terminology. === Section 4.3 Same as above for "E2E." === Section 5 Above you stated that an IOAM transit node _could_ process IOAM data. I think this is useful. I think it's worth stating in Section 5 that each IOAM-aware node could choose to export IOAM data. It need not be at the edge. I think that's it for now. Joe