From nobody Thu Oct 1 01:31:21 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7CC1B2BD8; Thu, 1 Oct 2015 01:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8qvG86hfpaIe; Thu, 1 Oct 2015 01:31:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CCB1B2BD7; Thu, 1 Oct 2015 01:31:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 65B86BE35; Thu, 1 Oct 2015 09:31:16 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jn-_qQ7TLUsG; Thu, 1 Oct 2015 09:31:14 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.22.228]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6392FBE33; Thu, 1 Oct 2015 09:31:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1443688274; bh=pBQfmxBfgt/i4Vj/zLBeOf87qERRzYenI+c+b3Gx8eY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=WTIzxloyZ+qCEygwRCTjW8SzU91BMRcJnYiq/pRcCy0azP5V7qm292lPC/N7Gy9Nb FuNjL7f+H8Jdq63G+0OFmn3OUy+y0vVaApBtsCvkP2E7sn4N0VPzpbV7KbmLVIjDmy fRAh4X2HUezpbVZt6j8fL0eEvcozh6//YhMxifQI= To: Suresh Krishnan , The IESG References: <20151001000655.11590.32411.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <560CEF4E.5080409@cs.tcd.ie> Date: Thu, 1 Oct 2015 09:31:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-conex-destopt@ietf.org" , "draft-ietf-conex-destopt.ad@ietf.org" , "conex-chairs@ietf.org" , "conex@ietf.org" Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 08:31:21 -0000 Hiya, On 01/10/15 04:52, Suresh Krishnan wrote: > Hi Stephen, > Thanks for your comments. Please find responses inline > > On 09/30/2015 08:06 PM, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-conex-destopt-09: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> 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-conex-destopt/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - section 7: "If the transport network cannot be trusted, IPsec >> Authentication should be used to ensure integrity of the ConEx >> information." Hmm. Transport networks cannot be trusted so the >> first condition is always met. That means you are saying IPsec >> should be used. I don't see how the key management required is >> going to happen and even if it did, would that affect conex >> calculations? I'm ok with an experiment on that basis though, >> but it'd be better if the real relationship between this and IPsec >> were more fully fleshed out somewhere as part of the experiment. > > I am not sure if the form of key management chosen would affect the > conex calculations at all. My point is that the key management implied here is basically not going to happen. That means IPsec will not be used and hence conex calculations will need to take into account the potential for routers to mess with the CDO. And I think the text of this would be better if it recognised the improbability of IPsec being used in the wild, or else spoke to how one could arrange experiments so that use of IPsec is more likely. Cheers, S. > I did read RFC5406 and I am still not sure > what can be said here about key management. I would really appreciate > some pointers/suggestions/text here. > >> >> - The secdir review [1] touches on similar issues. I'm not sure if >> that got a response, but it raises a good point that seems to me to >> deserve a response. >> >> [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05957.html > > I have added the following text in the Security Considerations section > of my local copy. Will submit this version after the telechat will check > with Robert. There is one item pending regarding audit in the Gen-ART > review and that may end up affecting this text. > > This document does not define how audit mechanisms work in protocols > that use this option and how those protocols can protect themselves > from likely attacks. This option MUST only be used alongside > protocols that define the audit mechanisms and the means for > protecting against likely attacks on such mechanisms. > > Thanks > Suresh > > > From nobody Thu Oct 1 02:15:07 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F167E1B2C57; Thu, 1 Oct 2015 02:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 X3C-b36Y-4de; Thu, 1 Oct 2015 02:15:04 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 3FFD61B2C4F; Thu, 1 Oct 2015 02:14:58 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so23296460wic.0; Thu, 01 Oct 2015 02:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=bfe2f1lU2CG6gaf1RtrmuQxhh6Vdg/ngDSuPZyXiWzA=; b=tLfC3p9h6vlkOunGY2zYLf4h0nrjz+Z1/mtv42yi1X3wltEBmLfSG8Gkb1kKekEH7Q HV2ONhHH8TbqGcZckXlgfbYdV6Cc5CmcfsCv8gjP5TX1lW9tGsC4uVxXYTV/MWNh/96c OAJbgxGrIogxIZ/MY8/YcCzgOThvfzbpbIxJBSoG9EiQHC7T9o+10lhvrKRybOFYwWI/ 4PqsXPBLm8Rk3I8nHQIFp4+IQ8+IiIqNSggY3o7gEDJADMJxsSstTGzzIsC5VJhJ1A1b WuXjJpfFJYx6MxA8zmaaQnsC0VNJFQj7UP4yTWvfCUrB+HzrS23k4Qfgr3wXZbOGW6ru dZ9g== X-Received: by 10.194.84.42 with SMTP id v10mr10387870wjy.1.1443690896727; Thu, 01 Oct 2015 02:14:56 -0700 (PDT) Received: from Martins-MBP.fritz.box ([2001:1a80:280a:ab00:396c:b014:4d5f:ee5b]) by smtp.googlemail.com with ESMTPSA id d8sm3004622wiy.1.2015.10.01.02.14.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 02:14:55 -0700 (PDT) To: Ben Campbell , The IESG References: <20150930211624.25308.24463.idtracker@ietfa.amsl.com> From: Martin Stiemerling Message-ID: <560CF98E.8080300@gmail.com> Date: Thu, 1 Oct 2015 11:14:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20150930211624.25308.24463.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-conex-mobile.ad@ietf.org, conex-chairs@ietf.org, conex@ietf.org, draft-ietf-conex-mobile@ietf.org Subject: Re: [conex] Ben Campbell's Discuss on draft-ietf-conex-mobile-05: (with DISCUSS and COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 09:15:06 -0000 Hi Ben, Am 30.09.15 um 23:16 schrieb Ben Campbell: > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > The security considerations section seems substantially incomplete. The > phrase "include, but are not limited to" seems to indicate that people > thought there were additional considerations. Please write them down, or > explain why there really aren't additional considerations. A bit more text can help here, though a number of threats might be obvious by now or might depend on the "version" of the mobile network. However, I let the authors to get more text and suggestions to you. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > There is an IPR declaration that lists this as an "associated draft". I'm > not sure what to make of that, but it was not mentioned in the shepherd > review. The IPR you are mention (https://datatracker.ietf.org/ipr/1922/) is sort of a spread shot across all conex documents. The shepherd write-up should have mentioned it, indeed. However, the WG did and does know about this IPR. Use this as anchor in the mail archive if you are looking for it: https://mailarchive.ietf.org/arch/msg/conex/cDSGuMhPDwMPOZH8YJGdVEi0yuk > > This reads much like an advocacy white paper. There's useful information > in it, but I would have preferred less of the marketing tone. But that's > just me, and I don't expect that to change this late in the process. ok, thanks. Martin From nobody Thu Oct 1 03:11:36 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A445A1A1B28; Thu, 1 Oct 2015 03:11:34 -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] autolearn=ham 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 a1drWNrR6Iz3; Thu, 1 Oct 2015 03:11:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EAC1A1B1C; Thu, 1 Oct 2015 03:11:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151001101133.22467.47580.idtracker@ietfa.amsl.com> Date: Thu, 01 Oct 2015 03:11:33 -0700 Archived-At: Cc: tjw.ietf@gmail.com, draft-ietf-conex-mobile@ietf.org, conex@ietf.org, draft-ietf-conex-mobile.ad@ietf.org, conex-chairs@ietf.org Subject: [conex] Benoit Claise's No Objection on draft-ietf-conex-mobile-05: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 10:11:34 -0000 Benoit Claise has entered the following ballot position for draft-ietf-conex-mobile-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) 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-conex-mobile/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Not too happy that a document on the IESG table doesn't take into account the shepherd feedback. See "A few editing nits that should be addressed before final publication: " at https://datatracker.ietf.org/doc/draft-ietf-conex-mobile/shepherdwriteup/, which corresponds to Tim's OPS DIR feedback below. My review found several issues with the document references and discussions, and several of them mirror those of the document shepherd. I suggest the OPs ADs heed the document shepherd words. 2.3. Accounting for Congestion Volume 3G and LTE networks provide extensive support for accounting and charging already, for example cf. the Policy Charging Control (PCC) architecture. issue: There is no reference to the PCC architecture, even though its referenced several times. Section 2.4: [I-D.briscoe-conex-initial-deploy] provides specific examples of how ConEx deployments can be initiated, focusing on unilateral typo: unilateral 3.1. Possible Deployment Scenarios We present three different deployment scenarios for congestion exposure in the figures below: issue: There are 4 items listed numerically below this statement. Please adjust this. issue: The drawings are not close to the deployment scenarios. I would suggest doing the work to include each drawing with the appropriate scenario. issue: Figures 1-4 refer to objects "UE", "eNB", "S-GW", and "P-GW". These are not defined in the document anywhere. 6. Security Considerations Security considerations for applying CONEX to EPS include, but are not limited to, the security considerations that apply to the CONEX protocols. issue: There should be a reference to the draft that discusses the security considerations that apply to the CONEX protocols References: I-D.briscoe-conex-initial-deploy - "work in progress" is stated, but draft is expired. I-D.briscoe-tsvwg-ecn-encap-guidelines - also expired Appendix B: The EPS architecture and some of its standardized interfaces are depicted in Figure 1. This should be Figure 5, which is also distant from the description. More effort should be used to place descriptions and figures in close proximity. From nobody Thu Oct 1 03:13:45 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E40E1A1B2D; Thu, 1 Oct 2015 03:13:44 -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] autolearn=ham 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 TUjiAE7r7Kpd; Thu, 1 Oct 2015 03:13:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9221A1B25; Thu, 1 Oct 2015 03:13:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151001101343.18866.3379.idtracker@ietfa.amsl.com> Date: Thu, 01 Oct 2015 03:13:43 -0700 Archived-At: Cc: draft-ietf-conex-destopt.ad@ietf.org, sob@harvard.edu, conex@ietf.org, conex-chairs@ietf.org, draft-ietf-conex-destopt@ietf.org Subject: [conex] Benoit Claise's No Objection on draft-ietf-conex-destopt-09: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 10:13:44 -0000 Benoit Claise has entered the following ballot position for draft-ietf-conex-destopt-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) 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-conex-destopt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As mentiond by Scott in his OPS-DIR review: As an experiment this should have few operational concerns for any network not involved in the experiment but if the technology becomes standardized at some later time it will add somewhat to the complexity of configuring network devices (i.e. routers). Bottom line, technology-wise this ID seems ready to publish. But I do have some comments on the use of rfc 2119 terminology in the ID. I do not think I’ve seen a case where a document says SHOULD NOT and MAY in the same paragraph referring to the same thing: As with any destination option, an ingress tunnel endpoint will not natively copy the CDO when adding an encapsulating outer IP header. In general an ingress tunnel SHOULD NOT copy the CDO to the outer header as this would changed the number of bytes that would be counted. However, it MAY copy the CDO to the outer header in order to facilitate visibility by subsequent on-path ConEx functions if the configuration of the tunnel ingress and the ConEx nodes is co- ordinated. This trades off the performance of ConEx functions against that of tunnel processing. I suggest that this be reworded to say something like “SHOULD NOT unless xxx, in which case it MAY xxx” The next paragraph says An egress tunnel endpoint SHOULD ignore any CDO on decapsulation of an outer IP header. The information in any inner CDO will always be considered correct, even if it differs from any outer CDO. Therefore, the decapsulator can strip the outer CDO without comparison to the inner. Why is this a SHOULD rather than a MUST? imo, SHOULDs should only be used when there is a known reason that an otherwise MUST behavior might not be followed – in that case the reason should be explained From nobody Thu Oct 1 03:22:55 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303951A1B24; Thu, 1 Oct 2015 03:22:49 -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] autolearn=ham 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 mWvNLJmv42CQ; Thu, 1 Oct 2015 03:22:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA77D1A1B1F; Thu, 1 Oct 2015 03:22:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151001102237.23843.68553.idtracker@ietfa.amsl.com> Date: Thu, 01 Oct 2015 03:22:37 -0700 Archived-At: Cc: draft-ietf-conex-tcp-modifications.ad@ietf.org, draft-ietf-conex-tcp-modifications@ietf.org, conex@ietf.org, conex-chairs@ietf.org, warren@kumari.net Subject: [conex] Benoit Claise's No Objection on draft-ietf-conex-tcp-modifications-09: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 10:22:49 -0000 Benoit Claise has entered the following ballot position for draft-ietf-conex-tcp-modifications-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) 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-conex-tcp-modifications/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to the document itself, but I really expect a new version based on Warren's feedback, as agreed by Suresh (document shepherd) Warren's feedback below. Be ye not afraid -- I have reviewed this document as part of the operations directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operation area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Version reviewed: draft-ietf-conex-tcp-modifications-09 Summary: I am not sure that this document is ready, and believe that review is needed from the Ops ADs. I believe that interactions with TCP feedback need to be performed very carefully, and I do not have the knowledge to adequately evaluate these, hopefully others with this experience (Transport ADs?) have also evaluated the document. The document needs significant readability cleanup and nit fixing. Detail: I found the document difficult to read -- there are a large number of typos, areas with lack of precision, ambiguities and grammar issues. This made a full evaluation difficult. I went to read the 'Document Quality' section of the Shepherd report to see if this was noted, but it was simply boilerplate. The document is marked as Experimental. I would be more concerned if it were a different stream... Open questions: Section 7 Open Areas for Experimentation; "This decision was taken because most network devices today expirience byte-congestion where the memory is filled exactly with the number of bytes a packet carries. However, there are also devices that may allocate a certain amount of memory per packet, no matter how larger a packet is." Citation needed; many devices I am familiar with split packets into multiple fixed size cells. e.g Juniper Q5 chips split packets into 96, 112, 128, 144, 160, or 176 byte cells and spray these across the fabric.I believe the Cisco CRS (and similar architectures) perform similar cell splitting. RFC7141 did not seem to contain this, but I may have missed it. In my opinion the document should discuss monitoring and reporting. What parameters should implementations expose to the user / operator? I think that the document should also discuss how this technique does or does not suffer from the potential of global synchronization (although this may be covered in other ConEx documents that I am not familiar with). The Security Considerations and Open Areas for Experimentation sections sort of discuss coexistence / deployment, but not in much depth Nits are readability issues - in a number of cases I was not entirely sure what was intended, so my suggestions may not be correct. Whereas loss has to be minimized, ECN can provide more fine-grained [O] Whereas loss has to be minimized, [P] Do you mean While, not whereas? I'm not sure how to parse this. feedback information. ConEx-based traffic measurement or management mechanisms could benefit from this. ... 3. Counting congestion ... The outstanding bytes counted based on ECN feedback information are maintained in the congestion exposure gauge (CEG), as explained in Section 3.2. When the sender sends a ConEx capable packet with the E or L flag set [O] When the sender sends a ConEx capable packet with the E or L flag set [P] When the sender sends a ConEx capable packet with the E or L flag set, [R] punctuation it reduces the respective counter by the byte-size of the packet. This is explained for both counters in Section 4.1. Note that all bytes of an IP packet must be counted in the LEG or CEG to capture the right number of bytes that should be marked. Therefore the sender SHOULD take the payload and headers into account, up to and including the IP header. However, in TCP the information how large the headers of an lost or marked pacekt were is [O] information how large the headers of an lost or marked pacekt [P] information regarding how large the headers of a lost or marked packet [R] readability, grammar, and typo (three changes) usually not available, as only payload data will be acknowledged. If equal-sized packets, or at least equally distributed packet sizes [O] or at least equally distributed packet sizes [P] or at least equally distributed packet sizes, [R] grammar can be assumed, the sender MAY only add and subtract TCP payload bytes. ... 3.1. Loss Detection This section applies whether or not SACK support is available. The following subsection in addition handles the case when SACK is not [O] The following subsection in addition handles [P] The following subsection (3.1.1) handles [R] Clarity available. A TCP sender detects losses and subsequently retransmits the lost data. Therefore, ConEx sender can simply set the ConEx L flag on all retransmissions in order to at least cover the amount of bytes lost. If this aprroach is taken, no LEG is needed. [O] aprroach [P] approach [R] spelling However, any retransmission may be spurious. In this case more bytes have been marked than necessary. To compensate this effect a ConEx [O] To compensate this effect [P] To compensate for this effect, [R] grammar sender can maintain a local signed counter, the (LEG), that indicats [O] indicats [P] inidicates [R] spelling the number of outstanding bytes to be sent with the ConEx L flag and also can become negative. Using the LEG, when a TCP sender decides that a data segment needs to be retransmitted, it will increase LEG by the size of the TCP payload bytes in the retransmission (assuming equal sized segments such that the retransmitted packet will have the same number of header bytes as the original ones): For each retransmision: [O] retransmision [P] retransmission [R] spelling LEG += payload Note, how the LEG is reduced when the ConEx L marking are set is described in section Section 4. Further to accommodate spurious restransmissions, a ConEx sender [O] restransmissions [P] retransmissions [R] spelling SHOULD make use of heuristics to detect such spurious retransmissions (e.g. F-RTO [RFC5682], DSACK [RFC3708], and Eifel [RFC3522], [RFC4015]) if are already available in a given implementation. If no [O] if are already available in a given implementation. [P] if already available in a given implementation. [R] grammar mechanism for detecting spurious retransmissions is available, the ConEx sender MAY chose to implement one of the mechanism stated above. However, given the inaccuracy that ConEx may have anyway and the timeliness of ConEx information, a ConEx MAY also chose to not componsate for spurious retransmission. In this case if spurious [O] componsate [P] compensate [R] spelling retransmissions occur, the ConEx sender simple has sent too much [O] retransmissions occur, the ConEx sender simple has sent too much [P] retransmissions occur, the ConEx sender simply has sent too many [R] grammar x 2 ConEx signals which e.g would decrease the congestion allowance in a ConEx policer unnecessary. [O] in a ConEx policer unnecessary. [R] ? Cannot parse. If a heuristic to detect spurious retransmission is used and has [O] If a heuristic to detect spurious retransmission is used [P] If a heuristic method is used to detect spurious retransmission [R] readability, and was missing a noun after heuristic. Could use analysis instead. determined that a certain number of packets were retransmitted erroneously, the ConEx sender subtracts the payload size of these TCP packets from LEG. If a spurious reransmission is detected: [O] reransmission [P] retransmission [R] spelling LEG -= payload Note that the LEG can get negative, if too many L marking have [O] Note that the LEG can get negative [P] Note that LEG can become negative [R] clarity already been sent. This case is further discussed in section Section 6. 3.1.1. Without SACK Support If multiple losses occur within one RTT and SACK is not used, it may take several RTTs until all lost data is retransmitted. With the scheme described above, the ConEx information will be delayed considerably, but timeliness is important for ConEx. However, for ConEx it is not important to know which data got lost but only how much. During the first RTT after the initial loss detection, the [O] However, for ConEx it is not important to know which data got lost but only how much. [P] For ConEx, it is important to know how much data was lot; it is not important to know what data is lost. [R] readability amount of received data and thus also the amount of lost data can be estimated based on the number of received ACKs. ... 3.2. ECN ... DeliveredData covers the number of bytes that has been newly delivered to the receiver. Therefore on each arrival of an ACK, DeliveredData will be increased by the newly acknowledged bytes (acked_bytes) as indicated by the current ACK, relative to all past ACKs. The formula depends on whether SACK is available: if SACK is not avaialble SACK_diff is always zero, whereas is ACK information is [O] avaialble [P] available [R] spelling available is_dup and is_after_dup are always zero. With SACK, DeliveredData is increased by the number of bytes provided by (new) SACK information (SACK_diff). Note, if less unacknowledged bytes are announced in the new SACK information than in the previous ACK, SACK_diff can be negative. In this case, data is newly acknowledged (in acked_bytes), that has previously already been accumulated into DeliveredData based on SACK information. Otherwise without SACK, DeliveredData is increased by 1 SMSS on duplicate acknowledgements as duplicate acknowledgements do not [O] as duplicate acknowledgements [P] because duplicate acknowedgements [R] grammar. Since would also be fine, instead of as. acknowlegde any new data (and acked_bytes will be zero). For the [O] acknowlegde [P] acknowledge [R] spelling subsequent partial or full ACK, acked_bytes cover all newly acknowledged bytes including the ones that where already accounted which the receiption of any duplicate acknowledgement. Therefore [O] the ones that where already accounted which the receiption of any duplicate acknowledgement [P] those already accounted for with the receipt of any duplicate acknowledgement. [R] spelling, grammar, inability to parse the original. I *think* this is what was meant. DeliveredData is reduced by one SMSS for each preceding duplicate ACK. Consequently, is_dup is one if the current ACK is a duplicated ACK without SACK, and zero otherwise. is_after_dup is only one for the next full or partial ACK after a number of duplicated ACKs without SACK and num_dup counts the number of duplicated ACKs in a row (which usually is 3 or more). With classic ECN, one congestion marked packet causes continuous congestion feedback for a whole round trip, thus hiding the arrival of any further congestion marked packets during that round trip. A more accurate ECN feedback scheme (AccECN) is needed to ensure that feedback properly reflects the extent of congestion marking. The two cases, with and without a receiver capable of AccECN, are discussed in the following sections. 3.2.1. Accurate ECN feedback With a more accurate ECN feedback scheme (AccECN) that is supported by the receiver either the number of marked packets or the number of [O] by the receiver either the number [P] by the receiver, either the number [R] grammar/punctuation marked bytes will be feed back from the receiver to the sender and is [O] feed back [P] fed back [R] spelling therefore know at sender-side. In the latter case the CEG can [O] therefore know at sender-side. In the latter case the CEG can [P] therefore know at sender-side. In the latter case, the CEG can [R] grammar/punctuation directly be increased by the number of marked bytes. Otherwise if D is assumed to be the number of marks, the gauge (CEG) will be conservatively increased by one SMSS for each marking or at max the number of newly acknowledged bytes: CEG += min(SMSS*D, DeliveredData) 3.2.2. Classic ECN support ... To extract more than one ECE indication per RTT, a ConEx sender could set the CWR flag continuously to force the receiver to signal only one ECE per CE mark. Unfortunately, the use of delayed ACKs [RFC5681] (which is common) will prevent feedback of every CE mark; if a CWR confirmation is received before the ECE can be sent out on the next ACK, ECN feedback information could get lost (depeding on [O] depeding [P] depending [R] spelling the actual receiver implementation). Thus a sender SHOULD set CWR only on those data segments that will presumably trigger a (delayed ACK. The sender would need an additional control loop to estimated [O] to estimated [P] to estimate [R] grammar which data segments will trigger an ACK in order to extract more timely congestion notifications. Still the CEG SHOULD be increased [O] Still the CEG SHOULD be increased [P] Still, the CEG SHOULD be increased [R] readability by DeliveredData, as one or more CE marked packets could be acknowledged by one delayed ACK. 4. Setting the ConEx Flags By setting the X flag, a packet is marked as ConEx-capable. All packets carrying payload MUST be marked with the X flag set, including retransmissions. Only if no congestion feedback information is (currently) available, the X flag SHOULD be zero, such as for control packets on a connection that has not sent any (user) data for some time e.g., sending only pure ACKs which are not carrying any payload. [O] Only if no congestion feedback information is (currently) available, the X flag SHOULD be zero, such as for control packets on a connection that has not sent any (user) data for some time e.g., sending only pure ACKs which are not carrying any payload. [P] The X flag SHOULD be zero only if no congestion feedback information is (currently) available (e.g. for control packets on a connection that not sent any user data for some time and is sending only pure ACKs that are not carrying any payload). [R] grammar and readability 4.1. Setting the E or the L Flag As described in section Section 3.1, the sender needs to maintain a CEG counter and might maintain a LEG counter. If no LEG is used, all retransmission will be marked with the L flag. Further, as long as the LEG or CEG counter is positive, the sender marks each ConEx-capable packet with L or E respectively, and decreases the LEG or CEG counter by the TCP payload bytes carried in the marked packet (assuming headers are not being counted because packet sizes are regular). No matter how small the value of LEG or CEG, if it is positive, the sender MUST NOT defer packet marking to ensure ConEx signals are timely. Therefore the value of LEG and CEG [O] No matter how small the value of LEG or CEG, if it is positive, the sender MUST NOT defer packet marking to ensure ConEx signals are timely. [P] No matter how small the value of LEG or CEG, if the value is positive the sender MUST NOT defer packet marking; this ensure ConEx signals are timely. [R] readability. will commonly be negative. If both LEG and CEG are positive, the sender MUST mark each ConEx- capable packet with both L and E. If a credit signal is also pending (see next section), the C flag can be set as well. 4.2. Setting the Credit Flag ... Recall that CSC will be decreased whenever congestion occurs, therefore CSC will need to be replenished as soon as CSC drops below [O] Recall that CSC will be decreased whenever congestion occurs, therefore CSC will need [P] CSC will be decreased whenever congestion occurs; therefore, CSC will need [R] grammar F. Also recall that the sender can set the C flag on a ConEx-capable packet whether or not the E or L flags are also set. In TCP Slow Start, the congestion window might grow much larger than during the rest of the transmission. Likely, a sender could consider sending fewer than F credits but risking being penalized by an audit function. However, the credits should at least cover the increase in sending rate. Given the exponential increase as implemented in the TCP Slow Start algorithm which means that the sending rate doubles every RTT, a ConEx sender should at least cover half the number of packets in flight by credits. Note that the number of losses or markings within one RTT does not solely depend on the sender's actions. In general, the behavior of the cross traffic, whether active queue management (AQM) is used and how it is parameterized influence how many packets might be dropped or marked. As long as any AQM encountered is not overly aggressive with ECN marking, sending half the flight size as credits should be sufficient whether congestion is signaled by loss or ECN. To maintain half of the packet in flight as credits, of course half [O] To maintain half of the packet in flight as credits, of course half [P] consider removing "of course" -- otherwise, put commas around it. [R] readability/grammer of the packet of the initial window must be C marked. In Slow Start marking every fourth packet introduces the correct amount of credit as can be seen in Figure 1. ... 5. Loss of ConEx information Packets carrying ConEx signals could be discarded themselves. This will be a second order problem (e.g. if the loss probability is 0.1%, the probability of losing a ConEx L signal will be 0.1% of 0.1% = 0.01%). Further, the penality an audit induces should be propotional [O] Further, the penality an audit induces should be propotional [P] Further, the penalty an audit induces should be proportionate [R] spelling x 2 to the mismatch of expected ConEx marks and observed congestion, therefore the audit might only slightly increase the loss level of this flow. Therefore, an implementer MAY choose to ignore this problem, accepting instead the risk that an audit function might wrongly penalize a flow. Nonetheless, a ConEx sender is responsible to always signal [O] responsible to always signal [P] responsible for always signalling [R] grammar sufficient congestion feedback and therefore SHOULD remember which packet was marked with either the L, the E or the C flag. If one of these packets is detected as lost, the sender SHOULD increase the respective gauge(s), LEG or CEG, by the number of lost payload bytes in addition to increasing LEG for the loss. 6. Timeliness of the ConEx Signals ConEx signals will only be useful to a network node within a time delay of about one RTT after the congestion occurred. To avoid further delays, a ConEx sender SHOULD send the ConEx signaling on the next available packet. Any or all of the ConEx flags can be used in the same packet, which allows delay to be minimised when multiple signals are pending. The need to set multiple ConEx flags at the same time, can occur if e.g [O] at the same time, can occur [P] at the same time can occur [R] unnecessary comma; grammar an ACK is received by the sender that simultaneously indicates that at least one ECN mark was received, and that one or more segements [O] segements [P] segments [R] spelling were lost. This may e.g. happen during excessive congestion, where [O] may e.g. happen uring excessive congestion, where [P] may happen during excessive congestion, if [R] readability the queues overflow even though ECN was used and currently all forwarded packets are marked, while others have to be dropped nevertheless. Another case when this might happen is when ACKs are [O] nevertheless. [P] [delete "nevertheless"] [R] readability lost, so that a subsequent ACK carries summary information not previously available to the sender. If a flow becomes application-limited, there could be insufficient bytes to send to reduce the gauges to zero or below. In such cases, the sender cannot help but delay ConEx signals. Nonetheless, as long as the sender is marking all outgoing packets, an audit function is unlikely to penalize ConEx-marked packets. Therefore, no matter how long a gauge has been positive, a sender MUST NOT reduce the gauge by more than the ConEx marked bytes it has sent. If the CEG or LEG counter is negative, the respective counter MAY be reset to zero within one RTT after it was decreased the last time or one RTT after recovery if no further congestion occurred. 7. Open Areas for Experimentation All proposed mechanisms in this document are experimental, and therefore further large-scale experimentation in the Internet is required to evaluate if the signaling provided by these mechanisms is accurate and timely enough to produce value for ConEx-based (traffic management or other) mechanisms. The current ConEx specifications assume that congestion is counted in number of bytes (including the IP header that directly encapsulates the CDO and everything that IP header encapsulates) [draft-ietf-conex-destopt]. This decision was taken because most network devices today expirience byte-congestion where the memory is [O] expirience [P] experience [R] spelling filled exactly with the number of bytes a packet carries. However, there are also devices that may allocate a certain amount of memory per packet, no matter how larger a packet is. These devices get congested based on the number of packets in their memory and therefore in this case congestion is determined by the number of packets that have been lost or marked. Furthermore, a transport layer endpoint, such as a TCP sender or receiver, might not know the exact number of bytes that a lower layer was carrying. Therefore a TCP endpoint may only be able to estimate the exact number of congested bytes (assuming that all lower layer header have the same length). If this estimation is sufficient to work with the ConEx [O] If this estimation is sufficient to work with the ConEx [P] If this estimation is sufficient to work with, the ConEx [R] readability signal needs to be further evaluated in tests in the Internet together with different auditor implementations. Further, the proposed marking schemes in this document are designed under the assumption that all TCP packets of a ConEx-capable flow are of equal size or that flows have a constant mean packet size over a rather small time frame, like one RTT or less. In most implementations this assumption might be taken as well and probably is true for most of the traffic flows. However, it should be evaluted how much the accuracy degrades if this precondition is not fulfilled, while the proposed scheme is used. Especially evaluating this with real traffic from different application is important to make a decision if the proposed schemes are sufficient or a more complexe scheme is needed. [O] However, it should be evaluted how much the accuracy degrades if this precondition is not fulfilled, while the proposed scheme is used. Especially evaluating this with real traffic from different application is important to make a decision if the proposed schemes are sufficient or a more complexe scheme is needed. [P] If this proposed scheme is used, it is necessary to evaluate how much accuracy degrades if this precondition is not met. Evaluating with real traffic from different applications is especially important in making the decision regarding whether the proposed schemes are sufficient or whether a more complex scheme is needed. [R] grammar, spelling, readability In this context the proposed scheme to set credit markings in Slow Start runs a risk to provide an insufficient number of markings which can cause an audit function to penalize this flow. Both the proposed credit scheme for Slow Start as well as the scheme in Congestion Avoidance must be evaluated together with one or more specific implementations of an ConEx auditor to ensure that both algorithms, in the sender and in the auditor, work propoerly together with a low [O] propoerly [P] properly [R] spelling risk of false positives (which would lead to penalization of an honest sender). However, if a sender is wrongly assumed to cheat, the penalization of the audit should be adequate and should allow an honest sender using a congestion control scheme that is commonly used today to recover quickly. Another open issue is the accuracy of the ECN feedback signal. At time of publication of this document there is no AccECN mechanism s pecified yet, and further AccECN will also take some time to be [O] s pecified yet, [P] specified yet, [R] spelling widely deployed. This document proposes an advanced compatibility mode for Classic ECN. The proposed mechanism can provide more accurate feedback by utilizing the way Classic ECN is speficed but [O] speficed [P] specified [R] spelling [O] loosing information [P] losing information [R] spelling this risk is in a real deployment scenario, further experimental evaluation is needed. The following argument is intended to prove that suppressing repetitions of ECE, however, is still safe against possible congestion collapse due to lost congestion feedback and should be further proven in experimentation: Repetition of ECE in classic ECN is intended to ensure reliable delivery of congestion feedback. However, with advanced compatibility mode, it is possible to miss congestion notifications. This can happen in some implementations if delayed acknowledgements are used. Further an ACK containing ECE can simply get lost. If [O] Further an ACK [P] Further, an ACK [R] readability only a few CE marks are received within one congestion event (e.g., only one), the loss of one acknowledgements due to (heavy) congestion on the reverse path can prevent that any congestion notification is received by the sender. However, if loss of feedback exacerbates congestion on the forward path, more forward packets will be CE marked, increasing the likelihood that feedback from at least one CE will get through per RTT. As long as one ECE reaches the sender per RTT, the sender's congestion response will be the same as if CWR were not continuous. The only way that heavy congestion on the forward path could be completely hidden would be if all ACKs on the reverse path were lost. If total ACK loss persisted, the sender would time out and do a congestion response anyway. Therefore, the problem seems confined to potential suppression of a congestion response during light congestion. Anyway, even if loss of all ECN feedback leads to no congestion [O] Anyway [P] Furthermore [R] tone response, the worst that could happen would be loss instead of ECN- signaled congestion on the forward path. Given compatibility mode does not affect loss feedback, there would be no risk of congestion collapse. 10. Security Considerations ... However, if the receiver is solely interested in making the sender draw down its allowance, the net effect will depend on the sender's congestion control algorithm as permanetly adding more and more [O] permanetly [P] permanently From nobody Thu Oct 1 03:40:37 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532F01A1B5C; Thu, 1 Oct 2015 03:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 VG5Yy0sLo4Ad; Thu, 1 Oct 2015 03:40:35 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 C92A51A1B5B; Thu, 1 Oct 2015 03:40:34 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so26433031wic.1; Thu, 01 Oct 2015 03:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=NkNCZSXPN6PfolpHonWdOAww9DcgYa5xT402ljdPIhs=; b=bKk1UQ02vMwDcTN6jM1+atY2gFcPLsDP3FLlAe3IAkCjL6l1MDaOU4A3fTY5lExuaC RF0udTEjJLwoo15XsDK3ATyeEBAVwOJSXB6DEerzOlZtS8/0uHB06gyYqAtWJwAYlrzg dHijeYXIH518K2+HxFqGgxYo+KFquM02jqjLaMauSUye58IP8wmGCRYIjMFa5fvDyCE2 Mx7ygFp+8u6MKFH99MebwV5MUkYGkfVaEQGygMrm7drlqo3PVD5g3mUIaCGDuP9s6ON2 M0FOKEyxf1qXS7Plbo5SeK0HWhlocTAEwAut5tofu9jm/O8VYkn0INLoBcl5UDfzRkLn SGJw== X-Received: by 10.194.77.240 with SMTP id v16mr9272244wjw.109.1443696033424; Thu, 01 Oct 2015 03:40:33 -0700 (PDT) Received: from Martins-MBP.fritz.box ([2001:1a80:280a:ab00:396c:b014:4d5f:ee5b]) by smtp.googlemail.com with ESMTPSA id x9sm5416181wjf.44.2015.10.01.03.40.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 03:40:32 -0700 (PDT) To: Benoit Claise , The IESG References: <20151001101133.22467.47580.idtracker@ietfa.amsl.com> From: Martin Stiemerling Message-ID: <560D0D9F.60008@gmail.com> Date: Thu, 1 Oct 2015 12:40:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151001101133.22467.47580.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: tjw.ietf@gmail.com, draft-ietf-conex-mobile@ietf.org, conex@ietf.org, draft-ietf-conex-mobile.ad@ietf.org, conex-chairs@ietf.org Subject: Re: [conex] Benoit Claise's No Objection on draft-ietf-conex-mobile-05: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 10:40:36 -0000 Am 01.10.15 um 12:11 schrieb Benoit Claise: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Not too happy that a document on the IESG table doesn't take into account > the shepherd feedback. > See "A few editing nits that should be addressed before final > publication: " at > https://datatracker.ietf.org/doc/draft-ietf-conex-mobile/shepherdwriteup/, > which corresponds to Tim's OPS DIR feedback below. It will be fixed before it is going forward. Martin From nobody Thu Oct 1 04:49:38 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D8F1A21A4; Thu, 1 Oct 2015 04:49:36 -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] autolearn=ham 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 VXvjhzV1Cbpz; Thu, 1 Oct 2015 04:49:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8EB1A2130; Thu, 1 Oct 2015 04:49:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151001114934.21091.71499.idtracker@ietfa.amsl.com> Date: Thu, 01 Oct 2015 04:49:34 -0700 Archived-At: Cc: draft-ietf-conex-mobile.ad@ietf.org, conex-chairs@ietf.org, conex@ietf.org, draft-ietf-conex-mobile@ietf.org Subject: [conex] Stephen Farrell's No Objection on draft-ietf-conex-mobile-05: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 11:49:36 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-conex-mobile-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) 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-conex-mobile/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - There is a huge amount of sales-speak in this document. Frankly there is so much of that here, and no counterpoint nor real analysis that is technically, but fairly, critical of conex, that this seems like marketing material. Why are the authors, the WG, the area and the IETF producing that kind of thing? I'm sure there are good reasons to produce the material, but I'm not at all sure that ought be done within the IETF. - Same IPR comment as Ben's. Were the WG aware? From nobody Thu Oct 1 04:56:28 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D7C1A21BB; Thu, 1 Oct 2015 04:56:22 -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] autolearn=ham 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 sFe6Dd9h6DKA; Thu, 1 Oct 2015 04:56:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A38F61A21BE; Thu, 1 Oct 2015 04:56:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151001115619.27054.3625.idtracker@ietfa.amsl.com> Date: Thu, 01 Oct 2015 04:56:19 -0700 Archived-At: Cc: draft-ietf-conex-tcp-modifications.ad@ietf.org, draft-ietf-conex-tcp-modifications@ietf.org, conex-chairs@ietf.org, conex@ietf.org Subject: [conex] Stephen Farrell's No Objection on draft-ietf-conex-tcp-modifications-09: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 11:56:23 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-conex-tcp-modifications-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) 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-conex-tcp-modifications/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Seems like a fine thing to experiment with. I hope the results are interesting. The security considerations really ought take into account or at least mention potential misbehaviour by middleboxes and also how conex might be affected by DoS attacks. From nobody Thu Oct 1 05:40:16 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD991ACE63; Thu, 1 Oct 2015 05:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 7uFOt702kyAs; Thu, 1 Oct 2015 05:40:13 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::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 D5FBE1B2C75; Thu, 1 Oct 2015 05:40:11 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so31321528wic.0; Thu, 01 Oct 2015 05:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=5p+96Q5nCKsghBbdlZi41VUFJZrRVMeubhppkB113p4=; b=1JYdumCKwAe8A8OUaIm5rvLR8OpeO8WsCtzlWvBnBpi/XMU0N+7rbBoO8IFAumqFqf vPyAIFQYQcOzRB3940iZxI9aL8c36KHHrUcnvTHN3PGP1J9eMAF1KMWokUrxQcg0gEBx W5LJtK6ldRP/6dtmu5y1Kid3mt2/ed55th2RCRkaJAyWtqgSxeTa81c/zFBTe9AU99W8 mkpyUlBwk4x7L1Z2dqMkSFpTrm3HY9Ygz2oxu6pXcWr2dfJvzfggsPBlNGIhvVxVh9cw F24ER0TOGVZ5SwfmMyEbKOMxhTu2RhD1sqAXRq6IBFaJ25i15StBFGl2+UW7HKpbnPe3 0w0g== X-Received: by 10.180.186.10 with SMTP id fg10mr3234679wic.30.1443703210321; Thu, 01 Oct 2015 05:40:10 -0700 (PDT) Received: from Martins-MBP.fritz.box ([2001:1a80:280a:ab00:5589:1c2e:a53:2f4e]) by smtp.googlemail.com with ESMTPSA id o10sm3017158wia.4.2015.10.01.05.40.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 05:40:09 -0700 (PDT) To: Stephen Farrell , The IESG References: <20151001114934.21091.71499.idtracker@ietfa.amsl.com> From: Martin Stiemerling Message-ID: <560D29A7.3010601@gmail.com> Date: Thu, 1 Oct 2015 14:40:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151001114934.21091.71499.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-conex-mobile.ad@ietf.org, conex-chairs@ietf.org, conex@ietf.org, draft-ietf-conex-mobile@ietf.org Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-mobile-05: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 12:40:14 -0000 Hi Stephen, Am 01.10.15 um 13:49 schrieb Stephen Farrell: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > > - There is a huge amount of sales-speak in this document. Frankly > there is so much of that here, and no counterpoint nor real analysis > that is technically, but fairly, critical of conex, that this seems > like marketing material. Why are the authors, the WG, the area and > the IETF producing that kind of thing? I'm sure there are good > reasons to produce the material, but I'm not at all sure that ought > be done within the IETF. I will let this to the authors. > > - Same IPR comment as Ben's. Were the WG aware? Yes. The IPR notifications where posted to the list at the time when they showed up. Martin From nobody Thu Oct 1 10:27:31 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D001B2DFC; Thu, 1 Oct 2015 10:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 1q4eZSxqqZmQ; Thu, 1 Oct 2015 10:27:23 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 9BFD71B2E1F; Thu, 1 Oct 2015 10:27:22 -0700 (PDT) Received: from 1.83.200.146.dyn.plus.net ([146.200.83.1]:47550 helo=[192.168.0.16]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZhhdX-0005lg-Ld; Thu, 01 Oct 2015 18:27:20 +0100 To: Robert Sparks , =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <55DE1F65.5070106@nostrum.com> <56014D94.9070002@tik.ee.ethz.ch> <56099700.6050004@nostrum.com> From: Bob Briscoe Message-ID: <560D6CF6.4050700@bobbriscoe.net> Date: Thu, 1 Oct 2015 18:27:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56099700.6050004@nostrum.com> Content-Type: multipart/alternative; boundary="------------040101010303080407010304" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net Archived-At: Cc: General Area Review Team , conex@ietf.org, draft-ietf-conex-destopt@ietf.org Subject: Re: [conex] Gen-art LC review: draft-ietf-conex-destopt-09 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 17:27:28 -0000 This is a multi-part message in MIME format. --------------040101010303080407010304 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Robert, Mirja, Responding (eventually) as one of the authors of conex-abstract-mech First one point I picked up that might be a misconception from Robert: On 26.08.2015 22:19, Robert Sparks wrote: > Should > there be a statement that this option must not be used unless by a > transport extension that's discussed how to use it? If not, then > shouldn't this document talk about what happens if there's no > transport header below to inform audit function behavior? ConEx is designed so that audit is agnostic to the particular transport behaviour. One would not expect the audit function to look for a transport header and change its audit behaviour accordingly (ConEx is designed on the assumption the transport header is or at least could be encrypted). conex-abstract-mech says: Transport Oblivious: Audit SHOULD NOT be designed around one particular rate response, such as any particular TCP congestion control algorithm or one particular resource sharing regime such as TCP-friendliness [RFC5348 ]. An important goal is to give ingress networks the freedom to unilaterally allow different rate responses to congestion and different resource sharing regimes [Evol_cc ], without having to coordinate with other networks over details of individual flow behaviour; I'd be interested to know where in the docs you got a different impression, because we ought to try to fix that. Now, responding to the conversation... On 28/09/15 20:37, Robert Sparks wrote: > > > On 9/22/15 7:46 AM, Mirja Khlewind wrote: >> Hi, >> >> regarding M1: >> >> I don't think we can say much more in this doc than what is already >> said in the abstract mechanism doc as we simply don't know which >> protocol will be used on top of it. > So should this document restrict the use of the extension to those > protocols that are used on top of it where the discussion can be > concrete? (That's what I was suggesting when I asked " Should there be > a statement that this option must not be used unless by a transport > extension that's discussed how to use it?") That /seems/ reasonable. But let's consider a test-case before adopting this last sentence: e.g. DNS I could implement ConEx for a sender of DNS datagrams (that receives no congestion feedback). conex-abstract-mech says: Alternatively, without sufficiently precise congestion feedback from the receiver, the source may have to conservatively send extra ConEx markings in order to avoid understating congestion. So, I could modify my DNS sender to add a CDO header to all IPv6 packets and always set the credit flag. Then, if my sender was behind a ConEx policer, it would consume some degree of congestion allowance, but it could never be accused of understating congestion by an audit function. Would I need a DNS-specific ConEx document to make this modification? or could I just implement it based on conex-abstract-mech and conex-dest-opt? Actually just these two docs would be sufficient. A DNS-conex document might be able to suggest a better more efficient mechanism, but it wouldn't be /necessary/ to write that doc to implement ConEx in DNS. The subtle point here is that the top-level requirement that ConEx places on a transport protocol is merely not to understate the congestion you cause. Any doc defining how a transport sets ConEx information is really just guidance on how not to look like you are being dishonest if you intend to be honest. The DNS example shows how you can be sufficiently honest without a document. > >> What we can do is to add one sentence saying that there must be a way >> in the higher layer protocol to provide feedback about congestion >> (loss and/or ECN) and that the specification for the higher layer >> protocol must discuss how an audit function in the network can access >> information on congestion on the forward path (e.g. monitoring seq#). > That makes sense to me. conex-abstract-mech deliberately does not require transports to use congestion feedback (as in the DNS example above). Also, as quoted above, conex-abstract-mech requires audit to be transport-agnostic, altho optimisations are possible when the transport is visible. So please don't contradict conex-abstract-mech by saying either of these things. The way the ConEx docs are structured, conex-abstract-mech is the place to state requirements on transport protocols and on audit, and I haven't yet seen anything in this conversation to say we've missed one (altho I have noticed below that we failed to act on one requirement). I certainly agree that a doc giving examples of good audit functions would be extremely useful. But I think the requirements on audit in conex-abstract-mech are sufficient. I know some people really want the rules to be clearer. But the requirements for audit in conex-abstract-mech will still carry more weight than how one particular example audit device works. >> >> Further regarding the abstract mechanism doc, it says the following: >> >> "The general goal of an auditor is to make sure that any ConEx-enabled >> traffic is sent with sufficient ConEx-Re-Echo and ConEx-Credit >> signals. A concrete definition of the ConEx protocol MUST define >> what sufficient means." >> >> I'm not sure if this is a correct usage of normative language, but I >> will double-check with the author of this document. However, I don't >> think we can say more about what sufficient means that it is already >> described in the abstract mechanism doc (further down in section 5.5). >> >> It might also be the case that the authors actually meant to say here >> something like >> >> "A transport that uses the ConEx protocol MUST define >> what sufficient means." >> >> which would probably me more sensical. I'll check with them. Bear in mind that abstract-mech is /ultra/ abstract (Matt Mathis suggested this and we all agreed). abstract-mech envisages that conex-dest-opt might not be the only concrete ConEx protocol. So this sentence means that conex-dest-opt has to state the basic audit rules. I.e. the three penalty criteria in If David Wagner is not available to re-write these for conex-destopt and the draft authors can't, I could have a go, but I have other stuff I'm meant to be doing this week. Sorry, when I reviewed conex-dest-opt for compliance with abstract-mech, I failed to notice the gap where this important requirement should have been satisfied - probably because we stuck the requirement in section "5.5 Audit", whereas we should have added it to the list in "3.3. Requirements for non-abstract ConEx specifications". I suspect fixing this will resolve your concern, Robert. I'm grateful you pointed this out - it is a huge omission - we were all assuming it, but the actual writing has fallen between the cracks of all the docs. One more response in the nits below... >> >> However, while writing these documents, we figured that we actually >> would need another document on auditing because there are some >> assumption that must be taken in the protocol design. The main >> purpose of that doc is/was to give guidance how to design an audit >> without caring of all the details in the tcp-mods doc. There is an >> (expired) draft (draft-wagner-conex-audit-01) which we did not follow >> because there was no energy in the wg and it was not in the original >> milestone list. We should definitely consider to revisit this draft >> if we plan further experimentation on ConEx. >> >> Does this makes sense to you? > Yes. >> >> Mirja >> >> >> >> On 26.08.2015 22:19, Robert Sparks wrote: >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>> >>> For more information, please see the FAQ at >>> >>> . >>> >>> Document: draft-ietf-conex-destopt-09 >>> Reviewer: Robert Sparks >>> Review Date: 26 Aug 2015 >>> IETF LC End Date: 31 Aug 2015 >>> IESG Telechat date: 1 Oct 2015 >>> >>> Summary: On the right track with open issues >>> >>> Major issues: >>> >>> M1) This document claims to specify "the ConEx wire protocol in IPv6". >>> But it reads more like "this document just defines an option, other >>> documents will talk about how and when the option is used". The >>> abstract-mech document requires that concrete ConEx specifications >>> discuss the audit function explicitly, with several requirements for >>> detail scattered through that document. In particular, it asks for a >>> discussion of how the concrete protocol defends against a set of >>> likely attacks against the audit function. This document is silent, >>> and I think a side-effect of being processed in parallel with >>> tcp-modifications, and suspect most of the thinking on meeting the >>> requirements for discussing the audit function has concentrated there. >>> However, nothing in _this_ document restricts its use to other >>> transport extensions that have talked about these things. Should >>> there be a statement that this option must not be used unless by a >>> transport extension that's discussed how to use it? If not, then >>> shouldn't this document talk about what happens if there's no >>> transport header below to inform audit function behavior? >>> >>> >>> Minor issues: >>> >>> m1) Figure 1 isn't right. I think what you want is: >>> >>> 0 1 2 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Option Type | Option Length |X|L|E|C| res | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> m2) There is confusion in two places in the document where you discuss >>> where to put the CDO (at the end of page 5 and the end of page 7). The >>> current text says the option MUST be the first option in whatever >>> destination options block it appears in. That seems problematic. What >>> if some other option also declares it MUST be the first option? I >>> wonder if instead of trying to say "must be the first option in the >>> block" you are trying only to say "If you use a CDO, use it in the >>> destination options block that comes before an AH block, not the one >>> that might come after". >>> >>> m3) Third paragraph of section 6: Should the last sentence end with >>> "in a given stream." ? >>> >>> Nits/editorial comments: >>> >>> Introduction: Should "Due to space limitation" be "Due to space >>> limitations in the IPV4 header"? >>> >>> Section 4: Right after the definition of Reserved, there is a line >>> that says "foo". What should it say instead? I noticed just after "foo" it says: All packets sent over a ConEx-capable TCP connection or belonging to the same ConEx-capable flow MUST carry the CDO. I think this was meant to say: All packets belonging to the same ConEx-capable flow (e.g. sent over the same ConEx-capable TCP connection) MUST carry the CDO. Thanks again, particularly for revealing the huge gap we had missed. Regards Bob >>> >>> The last sentence on page 6: I don't think it's the network node that >>> you are saying must be aware. Perhaps you mean designers of network >>> nodes? >>> >>> At the top of page 7, you have "They MAY log". You shouldn't use a >>> 2119 MAY here - it's not part of the protocol. Similarly, in section >>> 6, "MAY compare the two, and MAY log" should not use 2119. >>> >>> First paragraph of section 6: "natively" is not clear. Perhaps >>> replacing "will not natively copy" with "will not normally copy"? >>> >>> Second paragraph of section 6: I suggest replacing "ignore any >>> CDO" with "ignore any CDO in the outer header". >>> >>> Consider moving the description of the bits in the option type field, >>> particularly the chg bit, earlier in the document. Right now, the >>> first mention is in the security consideration section, and most >>> of the definition doesn't happen until the IANA considerations. >>> It would help if it were clear what that bit was going to be before >>> you ever mention AH. >>> >> > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ --------------040101010303080407010304 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Robert, Mirja,

Responding (eventually) as one of the authors of conex-abstract-mech

First one point I picked up that might be a misconception from Robert:

On 26.08.2015 22:19, Robert Sparks wrote:
Should
there be a statement that this option must not be used unless by a
transport extension that's discussed how to use it? If not, then
shouldn't this document talk about what happens if there's no
transport header below to inform audit function behavior?
ConEx is designed so that audit is agnostic to the particular transport behaviour. One would not expect the audit function to look for a transport header and change its audit behaviour accordingly (ConEx is designed on the assumption the transport header is or at least could be encrypted). conex-abstract-mech says:

   Transport Oblivious:  Audit SHOULD NOT be designed around one
      particular rate response, such as any particular TCP congestion
      control algorithm or one particular resource sharing regime such
      as TCP-friendliness [RFC5348].  An important goal is to give
      ingress networks the freedom to unilaterally allow different rate
      responses to congestion and different resource sharing regimes
      [Evol_cc], without having to coordinate with other networks over
      details of individual flow behaviour;
I'd be interested to know where in the docs you got a different impression, because we ought to try to fix that.

Now, responding to the conversation...


On 28/09/15 20:37, Robert Sparks wrote:


On 9/22/15 7:46 AM, Mirja Khlewind wrote:
Hi,

regarding M1:

I don't think we can say much more in this doc than what is already said in the abstract mechanism doc as we simply don't know which protocol will be used on top of it.
So should this document restrict the use of the extension to those protocols that are used on top of it where the discussion can be concrete? (That's what I was suggesting when I asked " Should there be a statement that this option must not be used unless by a transport extension that's discussed how to use it?")
That /seems/ reasonable. But let's consider a test-case before adopting this last sentence: e.g. DNS

I could implement ConEx for a sender of DNS datagrams (that receives no congestion feedback). conex-abstract-mech says:
      Alternatively, without sufficiently precise
      congestion feedback from the receiver, the source may have to
      conservatively send extra ConEx markings in order to avoid
      understating congestion.
So, I could modify my DNS sender to add a CDO header to all IPv6 packets and always set the credit flag. Then, if my sender was behind a ConEx policer, it would consume some degree of congestion allowance, but it could never be accused of understating congestion by an audit function.

Would I need a DNS-specific ConEx document to make this modification? or could I just implement it based on conex-abstract-mech and conex-dest-opt?
Actually just these two docs would be sufficient. A DNS-conex document might be able to suggest a better more efficient mechanism, but it wouldn't be /necessary/ to write that doc to implement ConEx in DNS.

The subtle point here is that the top-level requirement that ConEx places on a transport protocol is merely not to understate the congestion you cause. Any doc defining how a transport sets ConEx information is really just guidance on how not to look like you are being dishonest if you intend to be honest. The DNS example shows how you can be sufficiently honest without a document.


What we can do is to add one sentence saying that there must be a way in the higher layer protocol to provide feedback about congestion (loss and/or ECN) and that the specification for the higher layer protocol must discuss how an audit function in the network can access information on congestion on the forward path (e.g. monitoring seq#).
That makes sense to me.
conex-abstract-mech deliberately does not require transports to use congestion feedback (as in the DNS example above).
Also, as quoted above, conex-abstract-mech requires audit to be transport-agnostic, altho optimisations are possible when the transport is visible.

So please don't contradict conex-abstract-mech by saying either of these things.

The way the ConEx docs are structured, conex-abstract-mech is the place to state requirements on transport protocols and on audit, and I haven't yet seen anything in this conversation to say we've missed one (altho I have noticed below that we failed to act on one requirement). I certainly agree that a doc giving examples of good audit functions would be extremely useful. But I think the requirements on audit in conex-abstract-mech are sufficient.

I know some people really want the rules to be clearer. But the requirements for audit in conex-abstract-mech will still carry more weight than how one particular example audit device works.



Further regarding the abstract mechanism doc, it says the following:

"The general goal of an auditor is to make sure that any ConEx-enabled
traffic is sent with sufficient ConEx-Re-Echo and ConEx-Credit
signals. A concrete definition of the ConEx protocol MUST define
what sufficient means."

I'm not sure if this is a correct usage of normative language, but I will double-check with the author of this document. However, I don't think we can say more about what sufficient means that it is already described in the abstract mechanism doc (further down in section 5.5).

It might also be the case that the authors actually meant to say here something like

"A transport that uses the ConEx protocol MUST define
what sufficient means."

which would probably me more sensical. I'll check with them.
Bear in mind that abstract-mech is /ultra/ abstract (Matt Mathis suggested this and we all agreed). abstract-mech envisages that conex-dest-opt might not be the only concrete ConEx protocol. So this sentence means that conex-dest-opt has to state the basic audit rules. I.e. the three penalty criteria in <https://tools.ietf.org/html/draft-wagner-conex-audit-01#section-2.3>

If David Wagner is not available to re-write these for conex-destopt and the draft authors can't, I could have a go, but I have other stuff I'm meant to be doing this week.

Sorry, when I reviewed conex-dest-opt for compliance with abstract-mech, I failed to notice the gap where this important requirement should have been satisfied - probably because we stuck the requirement in section "5.5 Audit", whereas we should have added it to the list in "3.3. Requirements for non-abstract ConEx specifications".

I suspect fixing this will resolve your concern, Robert.
I'm grateful you pointed this out - it is a huge omission - we were all assuming it, but the actual writing has fallen between the cracks of all the docs.

One more response in the nits below...


However, while writing these documents, we figured that we actually would need another document on auditing because there are some assumption that must be taken in the protocol design. The main purpose of that doc is/was to give guidance how to design an audit without caring of all the details in the tcp-mods doc. There is an (expired) draft (draft-wagner-conex-audit-01) which we did not follow because there was no energy in the wg and it was not in the original milestone list. We should definitely consider to revisit this draft if we plan further experimentation on ConEx.

Does this makes sense to you?
Yes.

Mirja



On 26.08.2015 22:19, Robert Sparks wrote:
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-conex-destopt-09
Reviewer: Robert Sparks
Review Date: 26 Aug 2015
IETF LC End Date: 31 Aug 2015
IESG Telechat date: 1 Oct 2015

Summary: On the right track with open issues

Major issues:

M1) This document claims to specify "the ConEx wire protocol in IPv6".
But it reads more like "this document just defines an option, other
documents will talk about how and when the option is used". The
abstract-mech document requires that concrete ConEx specifications
discuss the audit function explicitly, with several requirements for
detail scattered through that document. In particular, it asks for a
discussion of how the concrete protocol defends against a set of
likely attacks against the audit function. This document is silent,
and I think a side-effect of being processed in parallel with
tcp-modifications, and suspect most of the thinking on meeting the
requirements for discussing the audit function has concentrated there.
However, nothing in _this_ document restricts its use to other
transport extensions that have talked about these things. Should
there be a statement that this option must not be used unless by a
transport extension that's discussed how to use it? If not, then
shouldn't this document talk about what happens if there's no
transport header below to inform audit function behavior?


Minor issues:

m1) Figure 1 isn't right. I think what you want is:

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |X|L|E|C| res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

m2) There is confusion in two places in the document where you discuss
where to put the CDO (at the end of page 5 and the end of page 7). The
current text says the option MUST be the first option in whatever
destination options block it appears in. That seems problematic. What
if some other option also declares it MUST be the first option? I
wonder if instead of trying to say "must be the first option in the
block" you are trying only to say "If you use a CDO, use it in the
destination options block that comes before an AH block, not the one
that might come after".

m3) Third paragraph of section 6: Should the last sentence end with
"in a given stream." ?

Nits/editorial comments:

Introduction: Should "Due to space limitation" be "Due to space
limitations in the IPV4 header"?

Section 4: Right after the definition of Reserved, there is a line
that says "foo". What should it say instead?
I noticed just after "foo" it says:

All packets sent over a ConEx-capable TCP connection or belonging to
the same ConEx-capable flow MUST carry the CDO.
I think this was meant to say:

All packets belonging to the same ConEx-capable flow (e.g. sent over 
the same ConEx-capable TCP connection) MUST carry the CDO.


Thanks again, particularly for revealing the huge gap we had missed.

Regards


Bob

The last sentence on page 6: I don't think it's the network node that
you are saying must be aware. Perhaps you mean designers of network
nodes?

At the top of page 7, you have "They MAY log". You shouldn't use a
2119 MAY here - it's not part of the protocol. Similarly, in section
6, "MAY compare the two, and MAY log" should not use 2119.

First paragraph of section 6: "natively" is not clear. Perhaps
replacing "will not natively copy" with "will not normally copy"?

Second paragraph of section 6: I suggest replacing "ignore any
CDO" with "ignore any CDO in the outer header".

Consider moving the description of the bits in the option type field,
particularly the chg bit, earlier in the document. Right now, the
first mention is in the security consideration section, and most
of the definition doesn't happen until the IANA considerations.
It would help if it were clear what that bit was going to be before
you ever mention AH.



_______________________________________________
conex mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex 

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------040101010303080407010304-- From nobody Thu Oct 1 15:06:39 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816671A0264; Thu, 1 Oct 2015 15:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 QQcYErJ9PPFw; Thu, 1 Oct 2015 15:06:35 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 A03B11A0248; Thu, 1 Oct 2015 15:06:35 -0700 (PDT) Received: from 1.83.200.146.dyn.plus.net ([146.200.83.1]:47661 helo=[192.168.0.16]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Zhlzk-0008OI-U3; Thu, 01 Oct 2015 23:06:33 +0100 To: Stephen Farrell , Suresh Krishnan References: <20151001000655.11590.32411.idtracker@ietfa.amsl.com> <560CEF4E.5080409@cs.tcd.ie> From: Bob Briscoe Message-ID: <560DAE68.60401@bobbriscoe.net> Date: Thu, 1 Oct 2015 23:06:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560CEF4E.5080409@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net Archived-At: Cc: "draft-ietf-conex-destopt.ad@ietf.org" , "conex-chairs@ietf.org" , The IESG , "conex@ietf.org" , "draft-ietf-conex-destopt@ietf.org" Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 22:06:38 -0000 Stephen, Suresh, As the person that contributed some of the text for this IPsec section, I can see what's happened during the evolution of the doc... In section 4 it says CDO MUST be placed as the first option in the destination option header before the AH and/or ESP (if present). IPsec Authentication Header (AH) MAY be used to verify that the CDO has not been modified. We started out writing Section 7 "Compatibility with use of IPsec" to answering the question: "What if IPsec is being used; how do we ensure ConEx is still visible?" The answer was the above rule about placing CDO before AH and/or ESP. In the process, we showed how endpoints that were already authenticating their IP headers with IPsec would automatically get coverage for the ConEx header. By some perverse document evolution process, this has become: [Old] If the transport network cannot be trusted, IPsec Authentication should be used to ensure integrity of the ConEx information. So I suggest the following change: [Proposed] If the endpoints are using the IPsec Authentication Header (AH) [RFC4302] to detect alteration of IP headers along the path, AH will also ensure the e2e integrity of the CDO header. Actually, both parts of the subsequent sentence are wrong as well: [Old] If an attacker would be able to remove the ConEx marks, this could cause an audit device to penalize the respective connection, while the sender cannot easily detect that ConEx information is missing. a) Removing ConEx marks would make audit ignore those packets, not drop them. b) And It's not hard to design a protocol for the sender to detect tampering with ConEx information. So I suggest instead: [Proposed] A network-based attacker could alter ConEx information to fool an audit function in a downstream network into discarding packets. An attack on one network from another by changing an immutable field can be traced, so it would be unlikely givennetwork operators care about their reputation.Nonetheless, if ConEx information was being altered within a network, IPsec AH or other more stealthy e2e integrity checks could be useful tools to help pin-point the attack location. No need to say this, but a similar attack is already possible: decrement TTL in one network to cause another network to drop packets. This is less easy to trace too, because it uses a mutable field. BTW, I designed the precursor to ConEx (re-ECN) to make it possible for networks to identify other rogue networks mounting such attacks, without needing e2e authentication. But all the inter-network security only works with ECN, not drop. When we decided to use ConEx to expose drop as well as ECN, I couldn't make the drop-based aspects support these nice security properties. That is admitted in conex-abstract-mech. But the ECN side of ConEx still supports all the inter-domain security. None of the inter-domain security techniques are written in the ConEx drafts, but they're in my PhD thesis, and referenced from conex-abstract-mech Security Considerations. Bob On 01/10/15 09:31, Stephen Farrell wrote: > Hiya, > > On 01/10/15 04:52, Suresh Krishnan wrote: >> Hi Stephen, >> Thanks for your comments. Please find responses inline >> >> On 09/30/2015 08:06 PM, Stephen Farrell wrote: >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-conex-destopt-09: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> 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-conex-destopt/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> - section 7: "If the transport network cannot be trusted, IPsec >>> Authentication should be used to ensure integrity of the ConEx >>> information." Hmm. Transport networks cannot be trusted so the >>> first condition is always met. That means you are saying IPsec >>> should be used. I don't see how the key management required is >>> going to happen and even if it did, would that affect conex >>> calculations? I'm ok with an experiment on that basis though, >>> but it'd be better if the real relationship between this and IPsec >>> were more fully fleshed out somewhere as part of the experiment. >> I am not sure if the form of key management chosen would affect the >> conex calculations at all. > My point is that the key management implied here is basically not > going to happen. That means IPsec will not be used and hence conex > calculations will need to take into account the potential for routers > to mess with the CDO. > > And I think the text of this would be better if it recognised the > improbability of IPsec being used in the wild, or else spoke to how > one could arrange experiments so that use of IPsec is more likely. > > Cheers, > S. > >> I did read RFC5406 and I am still not sure >> what can be said here about key management. I would really appreciate >> some pointers/suggestions/text here. >> >>> - The secdir review [1] touches on similar issues. I'm not sure if >>> that got a response, but it raises a good point that seems to me to >>> deserve a response. >>> >>> [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05957.html >> I have added the following text in the Security Considerations section >> of my local copy. Will submit this version after the telechat will check >> with Robert. There is one item pending regarding audit in the Gen-ART >> review and that may end up affecting this text. >> >> This document does not define how audit mechanisms work in protocols >> that use this option and how those protocols can protect themselves >> from likely attacks. This option MUST only be used alongside >> protocols that define the audit mechanisms and the means for >> protecting against likely attacks on such mechanisms. >> >> Thanks >> Suresh >> >> >> > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ From nobody Thu Oct 1 21:08:56 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998D91ACD17; Thu, 1 Oct 2015 21:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 l0o3wDr4clJs; Thu, 1 Oct 2015 21:08:50 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6FA61ACD11; Thu, 1 Oct 2015 21:08:49 -0700 (PDT) X-AuditID: c6180641-f792c6d00000686a-76-560d979789ca Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9C.7E.26730.7979D065; Thu, 1 Oct 2015 22:29:12 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Fri, 2 Oct 2015 00:08:48 -0400 From: Suresh Krishnan To: Bob Briscoe , Stephen Farrell Thread-Topic: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT) Thread-Index: AQHQ+90XGTaaybntuU+HziqlvMWDDQ== Date: Fri, 2 Oct 2015 04:08:47 +0000 Message-ID: References: <20151001000655.11590.32411.idtracker@ietfa.amsl.com> <560CEF4E.5080409@cs.tcd.ie> <560DAE68.60401@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyuXRPgu6M6bxhButNLc49vMxkcejaT0aL 96e+sFt0r/7FbjHjz0Rmi6MPF7BaTN97jd2B3ePV/QusHmu7r7J5LFnykymAOYrLJiU1J7Ms tUjfLoErY87Zm4wF6+wrZu65ydLAeMO4i5GTQ0LARGL9y0mMELaYxIV769m6GLk4hASOMkoc 2X6dHcJZxigx5Vs3C0gVG1DHhp2fmUBsEYEQiTnvzrOAFDEL9DFJvNm5gg0kISyQInGpYwpU UarEituT2CBsPYl5E3eDxVkEVCTunWxgB7F5BXwl+je9ZoHYdoRRYtODN2AJRqCbvp9aA9bA LCAucevJfCaIWwUkluw5zwxhi0q8fPyPFcJWkvj4ez47RL2OxILdn9ggbG2JZQtfM0MsE5Q4 OfMJywRG0VlIxs5C0jILScssJC0LGFlWMXKUFqeW5aYbGW5iBEbTMQk2xx2MCz5ZHmIU4GBU 4uFdUMIbJsSaWFZcmXuIUZqDRUmcd96M+6FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGPtU khkEL02cbafUu8BwiXm1387Ubyy7jy2erRqj9z2hReqQ5+QzwbpuM16uet0XEjtl9sm/ekeP 9DCbNW1imrApXFz7yqvuu/ah+y/khUtp3lveZ37EOlPDYNoXs+87Lm3tuO82N93ZvfTi270P GXI9/xS9uXmKtyLoTM21OR927Ju63fpT8RYlluKMREMt5qLiRABDYuSChwIAAA== Archived-At: Cc: "draft-ietf-conex-destopt.ad@ietf.org" , "conex-chairs@ietf.org" , The IESG , "conex@ietf.org" , "draft-ietf-conex-destopt@ietf.org" Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 04:08:52 -0000 Hi Bob,=0A= Thanks for your clarification. Since the security section seems to =0A= potentially have some dependence on the text needed for audit to address = =0A= Robert's Gen-ART review, is it possible for you and Mirja to work =0A= offline and agree to some text before presenting it to the IESG?=0A= =0A= Thanks=0A= Suresh=0A= =0A= On 10/01/2015 06:06 PM, Bob Briscoe wrote:=0A= > Stephen, Suresh,=0A= >=0A= > As the person that contributed some of the text for this IPsec section,= =0A= > I can see what's happened during the evolution of the doc...=0A= >=0A= > In section 4 it says=0A= >=0A= > CDO MUST be placed as the first option in the destination option=0A= > header before the AH and/or ESP (if present). IPsec Authentication=0A= > Header (AH) MAY be used to verify that the CDO has not been modified.=0A= >=0A= > We started out writing Section 7 "Compatibility with use of IPsec" to=0A= > answering the question:=0A= > "What if IPsec is being used; how do we ensure ConEx is still visible?"= =0A= > The answer was the above rule about placing CDO before AH and/or ESP.=0A= >=0A= > In the process, we showed how endpoints that were already authenticating= =0A= > their IP headers with IPsec would automatically get coverage for the=0A= > ConEx header. By some perverse document evolution process, this has becom= e:=0A= >=0A= > [Old]=0A= >=0A= > If the transport network cannot be trusted, IPsec Authentication=0A= > should be used to ensure integrity of the ConEx information.=0A= >=0A= > So I suggest the following change:=0A= >=0A= > [Proposed]=0A= >=0A= > If the endpoints are using the IPsec Authentication Header (AH) [RFC4302]= to detect alteration of=0A= > IP headers along the path, AH will also ensure the e2e integrity of the C= DO header.=0A= >=0A= > Actually, both parts of the subsequent sentence are wrong as well:=0A= >=0A= > [Old]=0A= >=0A= > If an attacker would be able to remove the ConEx marks, this could cause = an=0A= > audit device to penalize the respective connection, while the sender=0A= > cannot easily detect that ConEx information is missing.=0A= >=0A= > a) Removing ConEx marks would make audit ignore those packets, not drop= =0A= > them.=0A= > b) And It's not hard to design a protocol for the sender to detect=0A= > tampering with ConEx information.=0A= >=0A= > So I suggest instead:=0A= >=0A= > [Proposed]=0A= > A network-based attacker could alter ConEx information to fool an audit= =0A= > function in a downstream network into discarding packets. An attack on=0A= > one network from another by changing an immutable field can be traced,=0A= > so it would be unlikely givennetwork operators care about their=0A= > reputation.Nonetheless, if ConEx information was being altered within a= =0A= > network, IPsec AH or other more stealthy e2e integrity checks could be=0A= > useful tools to help pin-point the attack location.=0A= >=0A= > No need to say this, but a similar attack is already possible: decrement= =0A= > TTL in one network to cause another network to drop packets. This is=0A= > less easy to trace too, because it uses a mutable field.=0A= >=0A= >=0A= > BTW, I designed the precursor to ConEx (re-ECN) to make it possible for= =0A= > networks to identify other rogue networks mounting such attacks, without= =0A= > needing e2e authentication. But all the inter-network security only=0A= > works with ECN, not drop. When we decided to use ConEx to expose drop as= =0A= > well as ECN, I couldn't make the drop-based aspects support these nice=0A= > security properties. That is admitted in conex-abstract-mech. But the=0A= > ECN side of ConEx still supports all the inter-domain security. None of= =0A= > the inter-domain security techniques are written in the ConEx drafts,=0A= > but they're in my PhD thesis, and referenced from conex-abstract-mech=0A= > Security Considerations.=0A= >=0A= >=0A= >=0A= >=0A= > Bob=0A= >=0A= >=0A= >=0A= > On 01/10/15 09:31, Stephen Farrell wrote:=0A= >> Hiya,=0A= >>=0A= >> On 01/10/15 04:52, Suresh Krishnan wrote:=0A= >>> Hi Stephen,=0A= >>> Thanks for your comments. Please find responses inline=0A= >>>=0A= >>> On 09/30/2015 08:06 PM, Stephen Farrell wrote:=0A= >>>> Stephen Farrell has entered the following ballot position for=0A= >>>> draft-ietf-conex-destopt-09: No Objection=0A= >>>>=0A= >>>> When responding, please keep the subject line intact and reply to all= =0A= >>>> email addresses included in the To and CC lines. (Feel free to cut thi= s=0A= >>>> introductory paragraph, however.)=0A= >>>>=0A= >>>>=0A= >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml=0A= >>>> for more information about IESG DISCUSS and COMMENT positions.=0A= >>>>=0A= >>>>=0A= >>>> The document, along with other ballot positions, can be found here:=0A= >>>> https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> ----------------------------------------------------------------------= =0A= >>>> COMMENT:=0A= >>>> ----------------------------------------------------------------------= =0A= >>>>=0A= >>>>=0A= >>>> - section 7: "If the transport network cannot be trusted, IPsec=0A= >>>> Authentication should be used to ensure integrity of the ConEx=0A= >>>> information." Hmm. Transport networks cannot be trusted so the=0A= >>>> first condition is always met. That means you are saying IPsec=0A= >>>> should be used. I don't see how the key management required is=0A= >>>> going to happen and even if it did, would that affect conex=0A= >>>> calculations? I'm ok with an experiment on that basis though,=0A= >>>> but it'd be better if the real relationship between this and IPsec=0A= >>>> were more fully fleshed out somewhere as part of the experiment.=0A= >>> I am not sure if the form of key management chosen would affect the=0A= >>> conex calculations at all.=0A= >> My point is that the key management implied here is basically not=0A= >> going to happen. That means IPsec will not be used and hence conex=0A= >> calculations will need to take into account the potential for routers=0A= >> to mess with the CDO.=0A= >>=0A= >> And I think the text of this would be better if it recognised the=0A= >> improbability of IPsec being used in the wild, or else spoke to how=0A= >> one could arrange experiments so that use of IPsec is more likely.=0A= >>=0A= >> Cheers,=0A= >> S.=0A= >>=0A= >>> I did read RFC5406 and I am still not sure=0A= >>> what can be said here about key management. I would really appreciate= =0A= >>> some pointers/suggestions/text here.=0A= >>>=0A= >>>> - The secdir review [1] touches on similar issues. I'm not sure if=0A= >>>> that got a response, but it raises a good point that seems to me to=0A= >>>> deserve a response.=0A= >>>>=0A= >>>> [1] https://www.ietf.org/mail-archive/web/secdir/current/msg0595= 7.html=0A= >>> I have added the following text in the Security Considerations section= =0A= >>> of my local copy. Will submit this version after the telechat will chec= k=0A= >>> with Robert. There is one item pending regarding audit in the Gen-ART= =0A= >>> review and that may end up affecting this text.=0A= >>>=0A= >>> This document does not define how audit mechanisms work in protoc= ols=0A= >>> that use this option and how those protocols can protect themselv= es=0A= >>> from likely attacks. This option MUST only be used alongside=0A= >>> protocols that define the audit mechanisms and the means for=0A= >>> protecting against likely attacks on such mechanisms.=0A= >>>=0A= >>> Thanks=0A= >>> Suresh=0A= >>>=0A= >>>=0A= >>>=0A= >> _______________________________________________=0A= >> conex mailing list=0A= >> conex@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/conex=0A= >>=0A= >> --=0A= >> ________________________________________________________________=0A= >> Bob Briscoe http://bobbriscoe.net/=0A= >=0A= =0A= From nobody Thu Oct 1 21:14:35 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D641ACD26; Thu, 1 Oct 2015 21:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 CDI1e86HqC88; Thu, 1 Oct 2015 21:14:29 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5891B1A1BEC; Thu, 1 Oct 2015 21:14:29 -0700 (PDT) X-AuditID: c6180641-f792c6d00000686a-bf-560d98ebbb53 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 5C.8E.26730.BE89D065; Thu, 1 Oct 2015 22:34:51 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Fri, 2 Oct 2015 00:14:27 -0400 From: Suresh Krishnan To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT) Thread-Index: AQHQ+90XGTaaybntuU+HziqlvMWDDQ== Date: Fri, 2 Oct 2015 04:14:26 +0000 Message-ID: References: <20151001000655.11590.32411.idtracker@ietfa.amsl.com> <560CEF4E.5080409@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXRPuO7rGbxhBnu3q1ice3iZyeLQtZ+M Fg8fpVu8P/WF3aJ79S92ixl/JjJbTN97jd2B3WNt91U2jyVLfjJ5zDj2kj2AOYrLJiU1J7Ms tUjfLoEr4/PL3cwFb0Urfq99xdzA2C3UxcjJISFgIvG0p4MdwhaTuHBvPRuILSRwlFGibatP FyMXkL2MUWL24zlgCTaghg07PzOB2CICnhIP+06xgBQxC8xnktjacQ2sSFggRqJpQSsjRFGs xLVjB6Ea9CTmTdwNZrMIqEgcPLQLzOYV8JXofXmLGWLbEkaJk6/6wAYxAp30/dQasCJmAXGJ W0/mM0GcKiCxZM95ZghbVOLl43+sELaSxMff89kh6nUkFuz+xAZha0ssW/iaGWKZoMTJmU9Y JjCKzkIydhaSlllIWmYhaVnAyLKKkaO0OLUsN93IcBMjMJaOSbA57mBc8MnyEKMAB6MSD++C Et4wIdbEsuLK3EOM0hwsSuK882bcDxUSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAyH6yoz74 U4aAd6Q2e8ojkR/cCh0yXOH7bu4MUZt1om4l727H4Ds1jj2mu+PzZdedO/luUYpY7L4Dx/0f bJxSbrrHNe6YjEH60uWn9L7az/+5wsXVSlV8+5Ery3vrbG657e3brXLvP4OM2WaelbyFsifd CyPL1hbO4VF5PWFDUIfivoSEo/uPKrEUZyQaajEXFScCAC0s0oqGAgAA Archived-At: Cc: "draft-ietf-conex-destopt@ietf.org" , "draft-ietf-conex-destopt.ad@ietf.org" , "conex-chairs@ietf.org" , "conex@ietf.org" Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 04:14:31 -0000 Hi Stephen,=0A= =0A= On 10/01/2015 04:31 AM, Stephen Farrell wrote:=0A= >=0A= > Hiya,=0A= >=0A= > On 01/10/15 04:52, Suresh Krishnan wrote:=0A= >> Hi Stephen,=0A= >> Thanks for your comments. Please find responses inline=0A= >>=0A= >> On 09/30/2015 08:06 PM, Stephen Farrell wrote:=0A= >>> Stephen Farrell has entered the following ballot position for=0A= >>> draft-ietf-conex-destopt-09: No Objection=0A= >>>=0A= >>> When responding, please keep the subject line intact and reply to all= =0A= >>> email addresses included in the To and CC lines. (Feel free to cut this= =0A= >>> introductory paragraph, however.)=0A= >>>=0A= >>>=0A= >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml=0A= >>> for more information about IESG DISCUSS and COMMENT positions.=0A= >>>=0A= >>>=0A= >>> The document, along with other ballot positions, can be found here:=0A= >>> https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/=0A= >>>=0A= >>>=0A= >>>=0A= >>> ----------------------------------------------------------------------= =0A= >>> COMMENT:=0A= >>> ----------------------------------------------------------------------= =0A= >>>=0A= >>>=0A= >>> - section 7: "If the transport network cannot be trusted, IPsec=0A= >>> Authentication should be used to ensure integrity of the ConEx=0A= >>> information." Hmm. Transport networks cannot be trusted so the=0A= >>> first condition is always met. That means you are saying IPsec=0A= >>> should be used. I don't see how the key management required is=0A= >>> going to happen and even if it did, would that affect conex=0A= >>> calculations? I'm ok with an experiment on that basis though,=0A= >>> but it'd be better if the real relationship between this and IPsec=0A= >>> were more fully fleshed out somewhere as part of the experiment.=0A= >>=0A= >> I am not sure if the form of key management chosen would affect the=0A= >> conex calculations at all.=0A= >=0A= > My point is that the key management implied here is basically not=0A= > going to happen. That means IPsec will not be used and hence conex=0A= > calculations will need to take into account the potential for routers=0A= > to mess with the CDO.=0A= >=0A= > And I think the text of this would be better if it recognised the=0A= > improbability of IPsec being used in the wild, or else spoke to how=0A= > one could arrange experiments so that use of IPsec is more likely.=0A= =0A= Thanks. I think it may unfortunately end up being the former. Once the =0A= audit text is finalized, I will come back with alternate text for this. =0A= I will keep track of this issue along with Kathleen's DISCUSS as they =0A= will probably end up needing the same resolution.=0A= =0A= Regards=0A= Suresh=0A= =0A= From nobody Fri Oct 2 01:21:19 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF6E1A1A4C; Fri, 2 Oct 2015 01:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 0QVme0uaAHwc; Fri, 2 Oct 2015 01:21:12 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 869171A1A45; Fri, 2 Oct 2015 01:21:12 -0700 (PDT) Received: from 26.226.114.87.dyn.plus.net ([87.114.226.26]:50964 helo=[192.168.0.15]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZhvaX-0005Up-HC; Fri, 02 Oct 2015 09:21:09 +0100 To: Suresh Krishnan , Stephen Farrell References: <20151001000655.11590.32411.idtracker@ietfa.amsl.com> <560CEF4E.5080409@cs.tcd.ie> <560DAE68.60401@bobbriscoe.net> From: Bob Briscoe Message-ID: <560E3E75.1060402@bobbriscoe.net> Date: Fri, 2 Oct 2015 09:21:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net Archived-At: Cc: "draft-ietf-conex-destopt.ad@ietf.org" , "conex-chairs@ietf.org" , The IESG , "conex@ietf.org" , "draft-ietf-conex-destopt@ietf.org" Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 08:21:15 -0000 Suresh, Sure - if Mirja is OK with that too. Bob On 02/10/15 05:08, Suresh Krishnan wrote: > Hi Bob, > Thanks for your clarification. Since the security section seems to > potentially have some dependence on the text needed for audit to address > Robert's Gen-ART review, is it possible for you and Mirja to work > offline and agree to some text before presenting it to the IESG? > > Thanks > Suresh > > On 10/01/2015 06:06 PM, Bob Briscoe wrote: >> Stephen, Suresh, >> >> As the person that contributed some of the text for this IPsec section, >> I can see what's happened during the evolution of the doc... >> >> In section 4 it says >> >> CDO MUST be placed as the first option in the destination option >> header before the AH and/or ESP (if present). IPsec Authentication >> Header (AH) MAY be used to verify that the CDO has not been modified. >> >> We started out writing Section 7 "Compatibility with use of IPsec" to >> answering the question: >> "What if IPsec is being used; how do we ensure ConEx is still visible?" >> The answer was the above rule about placing CDO before AH and/or ESP. >> >> In the process, we showed how endpoints that were already authenticating >> their IP headers with IPsec would automatically get coverage for the >> ConEx header. By some perverse document evolution process, this has become: >> >> [Old] >> >> If the transport network cannot be trusted, IPsec Authentication >> should be used to ensure integrity of the ConEx information. >> >> So I suggest the following change: >> >> [Proposed] >> >> If the endpoints are using the IPsec Authentication Header (AH) [RFC4302] to detect alteration of >> IP headers along the path, AH will also ensure the e2e integrity of the CDO header. >> >> Actually, both parts of the subsequent sentence are wrong as well: >> >> [Old] >> >> If an attacker would be able to remove the ConEx marks, this could cause an >> audit device to penalize the respective connection, while the sender >> cannot easily detect that ConEx information is missing. >> >> a) Removing ConEx marks would make audit ignore those packets, not drop >> them. >> b) And It's not hard to design a protocol for the sender to detect >> tampering with ConEx information. >> >> So I suggest instead: >> >> [Proposed] >> A network-based attacker could alter ConEx information to fool an audit >> function in a downstream network into discarding packets. An attack on >> one network from another by changing an immutable field can be traced, >> so it would be unlikely givennetwork operators care about their >> reputation.Nonetheless, if ConEx information was being altered within a >> network, IPsec AH or other more stealthy e2e integrity checks could be >> useful tools to help pin-point the attack location. >> >> No need to say this, but a similar attack is already possible: decrement >> TTL in one network to cause another network to drop packets. This is >> less easy to trace too, because it uses a mutable field. >> >> >> BTW, I designed the precursor to ConEx (re-ECN) to make it possible for >> networks to identify other rogue networks mounting such attacks, without >> needing e2e authentication. But all the inter-network security only >> works with ECN, not drop. When we decided to use ConEx to expose drop as >> well as ECN, I couldn't make the drop-based aspects support these nice >> security properties. That is admitted in conex-abstract-mech. But the >> ECN side of ConEx still supports all the inter-domain security. None of >> the inter-domain security techniques are written in the ConEx drafts, >> but they're in my PhD thesis, and referenced from conex-abstract-mech >> Security Considerations. >> >> >> >> >> Bob >> >> >> >> On 01/10/15 09:31, Stephen Farrell wrote: >>> Hiya, >>> >>> On 01/10/15 04:52, Suresh Krishnan wrote: >>>> Hi Stephen, >>>> Thanks for your comments. Please find responses inline >>>> >>>> On 09/30/2015 08:06 PM, Stephen Farrell wrote: >>>>> Stephen Farrell has entered the following ballot position for >>>>> draft-ietf-conex-destopt-09: No Objection >>>>> >>>>> When responding, please keep the subject line intact and reply to all >>>>> email addresses included in the To and CC lines. (Feel free to cut this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> 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-conex-destopt/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> >>>>> - section 7: "If the transport network cannot be trusted, IPsec >>>>> Authentication should be used to ensure integrity of the ConEx >>>>> information." Hmm. Transport networks cannot be trusted so the >>>>> first condition is always met. That means you are saying IPsec >>>>> should be used. I don't see how the key management required is >>>>> going to happen and even if it did, would that affect conex >>>>> calculations? I'm ok with an experiment on that basis though, >>>>> but it'd be better if the real relationship between this and IPsec >>>>> were more fully fleshed out somewhere as part of the experiment. >>>> I am not sure if the form of key management chosen would affect the >>>> conex calculations at all. >>> My point is that the key management implied here is basically not >>> going to happen. That means IPsec will not be used and hence conex >>> calculations will need to take into account the potential for routers >>> to mess with the CDO. >>> >>> And I think the text of this would be better if it recognised the >>> improbability of IPsec being used in the wild, or else spoke to how >>> one could arrange experiments so that use of IPsec is more likely. >>> >>> Cheers, >>> S. >>> >>>> I did read RFC5406 and I am still not sure >>>> what can be said here about key management. I would really appreciate >>>> some pointers/suggestions/text here. >>>> >>>>> - The secdir review [1] touches on similar issues. I'm not sure if >>>>> that got a response, but it raises a good point that seems to me to >>>>> deserve a response. >>>>> >>>>> [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05957.html >>>> I have added the following text in the Security Considerations section >>>> of my local copy. Will submit this version after the telechat will check >>>> with Robert. There is one item pending regarding audit in the Gen-ART >>>> review and that may end up affecting this text. >>>> >>>> This document does not define how audit mechanisms work in protocols >>>> that use this option and how those protocols can protect themselves >>>> from likely attacks. This option MUST only be used alongside >>>> protocols that define the audit mechanisms and the means for >>>> protecting against likely attacks on such mechanisms. >>>> >>>> Thanks >>>> Suresh >>>> >>>> >>>> >>> _______________________________________________ >>> conex mailing list >>> conex@ietf.org >>> https://www.ietf.org/mailman/listinfo/conex >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoe http://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri Oct 2 01:53:00 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAE21ACED7; Fri, 2 Oct 2015 01:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1BO9NBa0RdNU; Fri, 2 Oct 2015 01:52:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4081ACED6; Fri, 2 Oct 2015 01:52:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4620ABE39; Fri, 2 Oct 2015 09:52:52 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TqIAxfdX3ck; Fri, 2 Oct 2015 09:52:51 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.22.228]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 63781BDD0; Fri, 2 Oct 2015 09:52:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1443775971; bh=aqeWW8u29KKwyrqD/ZaqEcyuPVumMXBp6Ul/X+Vt6Js=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=jEZYiCkbcs+qxh4NtN49CGA8Iirgj/Y+mCgzagEeCKqjq23+38JYFaCMPKJZpLkIZ Yh+Qtoe+llK774nhnU5x32YumYwLUJdmq92BWD2hzbe8MiAAu4OP7YvfLBsuPyDbyd BxrZyOrpMEruy8gizmbJodHD1mdohj4c5RoN++Eg= To: Bob Briscoe , Suresh Krishnan References: <20151001000655.11590.32411.idtracker@ietfa.amsl.com> <560CEF4E.5080409@cs.tcd.ie> <560DAE68.60401@bobbriscoe.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <560E45E2.2040809@cs.tcd.ie> Date: Fri, 2 Oct 2015 09:52:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560DAE68.60401@bobbriscoe.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-conex-destopt.ad@ietf.org" , "conex-chairs@ietf.org" , The IESG , "conex@ietf.org" , "draft-ietf-conex-destopt@ietf.org" Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 08:52:56 -0000 Hi Bob, Those all sound like pretty good changes except perhaps for... On 01/10/15 23:06, Bob Briscoe wrote: > > > [Proposed] > A network-based attacker could alter ConEx information to fool an audit > function in a downstream network into discarding packets. An attack on > one network from another by changing an immutable field can be traced, > so it would be unlikely givennetwork operators care about their > reputation. If the attack is carried out by a compromised node then the goals of the rightful owner of that node aren't relevant. > Nonetheless, if ConEx information was being altered within a > network, IPsec AH or other more stealthy e2e integrity checks could be > useful tools to help pin-point the attack location. I'd omit "more stealthy" unless you want to add a reference. (I guess that'd be to your Phd thesis and why not include that.) Cheers, S. From nobody Fri Oct 2 08:21:30 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669B61A6FD4 for ; Fri, 2 Oct 2015 08:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 z5WGwdFe-0ih for ; Fri, 2 Oct 2015 08:21:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D5AAD1A6FE2 for ; Fri, 2 Oct 2015 08:21:23 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t92FLGlH046280 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Fri, 2 Oct 2015 10:21:19 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: Bob Briscoe , =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <55DE1F65.5070106@nostrum.com> <56014D94.9070002@tik.ee.ethz.ch> <56099700.6050004@nostrum.com> <560D6CF6.4050700@bobbriscoe.net> From: Robert Sparks Message-ID: <560EA0E7.90503@nostrum.com> Date: Fri, 2 Oct 2015 10:21:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <560D6CF6.4050700@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------050107080207010108080202" Archived-At: Cc: General Area Review Team , conex@ietf.org, draft-ietf-conex-destopt@ietf.org Subject: Re: [conex] Gen-art LC review: draft-ietf-conex-destopt-09 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 15:21:28 -0000 This is a multi-part message in MIME format. --------------050107080207010108080202 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 10/1/15 12:27 PM, Bob Briscoe wrote: > Robert, Mirja, > > Responding (eventually) as one of the authors of conex-abstract-mech > > First one point I picked up that might be a misconception from Robert: > > On 26.08.2015 22:19, Robert Sparks wrote: >> Should >> there be a statement that this option must not be used unless by a >> transport extension that's discussed how to use it? If not, then >> shouldn't this document talk about what happens if there's no >> transport header below to inform audit function behavior? > ConEx is designed so that audit is agnostic to the particular > transport behaviour. One would not expect the audit function to look > for a transport header and change its audit behaviour accordingly > (ConEx is designed on the assumption the transport header is or at > least could be encrypted). conex-abstract-mech says: > > Transport Oblivious: Audit SHOULD NOT be designed around one > particular rate response, such as any particular TCP congestion > control algorithm or one particular resource sharing regime such > as TCP-friendliness [RFC5348 ]. An important goal is to give > ingress networks the freedom to unilaterally allow different rate > responses to congestion and different resource sharing regimes > [Evol_cc > ], without having to coordinate with other networks over > details of individual flow behaviour; > I'd be interested to know where in the docs you got a different > impression, because we ought to try to fix that. I didn't actually think the audit function code would change per transport. But as you point out, my suggested fix to the disconnect I think I see implies that, so it is off the mark. Your suggestions below will address the concern. > > Now, responding to the conversation... > > > On 28/09/15 20:37, Robert Sparks wrote: >> >> >> On 9/22/15 7:46 AM, Mirja Khlewind wrote: >>> Hi, >>> >>> regarding M1: >>> >>> I don't think we can say much more in this doc than what is already >>> said in the abstract mechanism doc as we simply don't know which >>> protocol will be used on top of it. >> So should this document restrict the use of the extension to those >> protocols that are used on top of it where the discussion can be >> concrete? (That's what I was suggesting when I asked " Should there >> be a statement that this option must not be used unless by a >> transport extension that's discussed how to use it?") > That /seems/ reasonable. But let's consider a test-case before > adopting this last sentence: e.g. DNS > > I could implement ConEx for a sender of DNS datagrams (that receives > no congestion feedback). conex-abstract-mech says: > Alternatively, without sufficiently precise > congestion feedback from the receiver, the source may have to > conservatively send extra ConEx markings in order to avoid > understating congestion. > So, I could modify my DNS sender to add a CDO header to all IPv6 > packets and always set the credit flag. Then, if my sender was behind > a ConEx policer, it would consume some degree of congestion allowance, > but it could never be accused of understating congestion by an audit > function. > > Would I need a DNS-specific ConEx document to make this modification? > or could I just implement it based on conex-abstract-mech and > conex-dest-opt? > Actually just these two docs would be sufficient. A DNS-conex document > might be able to suggest a better more efficient mechanism, but it > wouldn't be /necessary/ to write that doc to implement ConEx in DNS. > > The subtle point here is that the top-level requirement that ConEx > places on a transport protocol is merely not to understate the > congestion you cause. Any doc defining how a transport sets ConEx > information is really just guidance on how not to look like you are > being dishonest if you intend to be honest. The DNS example shows how > you can be sufficiently honest without a document. I follow that. It's a minor pedantic point, but I think the above indicates that -destopt- doesn't define a concrete ConEx protocol by itself. > >> >>> What we can do is to add one sentence saying that there must be a >>> way in the higher layer protocol to provide feedback about >>> congestion (loss and/or ECN) and that the specification for the >>> higher layer protocol must discuss how an audit function in the >>> network can access information on congestion on the forward path >>> (e.g. monitoring seq#). >> That makes sense to me. > conex-abstract-mech deliberately does not require transports to use > congestion feedback (as in the DNS example above). > Also, as quoted above, conex-abstract-mech requires audit to be > transport-agnostic, altho optimisations are possible when the > transport is visible. > > So please don't contradict conex-abstract-mech by saying either of > these things. > > The way the ConEx docs are structured, conex-abstract-mech is the > place to state requirements on transport protocols and on audit, and I > haven't yet seen anything in this conversation to say we've missed one > (altho I have noticed below that we failed to act on one requirement). > I certainly agree that a doc giving examples of good audit functions > would be extremely useful. But I think the requirements on audit in > conex-abstract-mech are sufficient. > > I know some people really want the rules to be clearer. But the > requirements for audit in conex-abstract-mech will still carry more > weight than how one particular example audit device works. Right. The "must discuss how" above was what was tempting for me. > > >>> >>> Further regarding the abstract mechanism doc, it says the following: >>> >>> "The general goal of an auditor is to make sure that any ConEx-enabled >>> traffic is sent with sufficient ConEx-Re-Echo and ConEx-Credit >>> signals. A concrete definition of the ConEx protocol MUST define >>> what sufficient means." >>> >>> I'm not sure if this is a correct usage of normative language, but I >>> will double-check with the author of this document. However, I don't >>> think we can say more about what sufficient means that it is already >>> described in the abstract mechanism doc (further down in section 5.5). >>> >>> It might also be the case that the authors actually meant to say >>> here something like >>> >>> "A transport that uses the ConEx protocol MUST define >>> what sufficient means." >>> >>> which would probably me more sensical. I'll check with them. > Bear in mind that abstract-mech is /ultra/ abstract (Matt Mathis > suggested this and we all agreed). abstract-mech envisages that > conex-dest-opt might not be the only concrete ConEx protocol. So this > sentence means that conex-dest-opt has to state the basic audit rules. > I.e. the three penalty criteria in > > > If David Wagner is not available to re-write these for conex-destopt > and the draft authors can't, I could have a go, but I have other stuff > I'm meant to be doing this week. > > Sorry, when I reviewed conex-dest-opt for compliance with > abstract-mech, I failed to notice the gap where this important > requirement should have been satisfied - probably because we stuck the > requirement in section "5.5 Audit", whereas we should have added it to > the list in "3.3. Requirements for non-abstract ConEx specifications". > > I suspect fixing this will resolve your concern, Robert. Yes. > I'm grateful you pointed this out - it is a huge omission - we were > all assuming it, but the actual writing has fallen between the cracks > of all the docs. > > One more response in the nits below... > >>> >>> However, while writing these documents, we figured that we actually >>> would need another document on auditing because there are some >>> assumption that must be taken in the protocol design. The main >>> purpose of that doc is/was to give guidance how to design an audit >>> without caring of all the details in the tcp-mods doc. There is an >>> (expired) draft (draft-wagner-conex-audit-01) which we did not >>> follow because there was no energy in the wg and it was not in the >>> original milestone list. We should definitely consider to revisit >>> this draft if we plan further experimentation on ConEx. >>> >>> Does this makes sense to you? >> Yes. >>> >>> Mirja >>> >>> >>> >>> On 26.08.2015 22:19, Robert Sparks wrote: >>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>> by the IESG for the IETF Chair. Please treat these comments just >>>> like any other last call comments. >>>> >>>> For more information, please see the FAQ at >>>> >>>> . >>>> >>>> Document: draft-ietf-conex-destopt-09 >>>> Reviewer: Robert Sparks >>>> Review Date: 26 Aug 2015 >>>> IETF LC End Date: 31 Aug 2015 >>>> IESG Telechat date: 1 Oct 2015 >>>> >>>> Summary: On the right track with open issues >>>> >>>> Major issues: >>>> >>>> M1) This document claims to specify "the ConEx wire protocol in IPv6". >>>> But it reads more like "this document just defines an option, other >>>> documents will talk about how and when the option is used". The >>>> abstract-mech document requires that concrete ConEx specifications >>>> discuss the audit function explicitly, with several requirements for >>>> detail scattered through that document. In particular, it asks for a >>>> discussion of how the concrete protocol defends against a set of >>>> likely attacks against the audit function. This document is silent, >>>> and I think a side-effect of being processed in parallel with >>>> tcp-modifications, and suspect most of the thinking on meeting the >>>> requirements for discussing the audit function has concentrated there. >>>> However, nothing in _this_ document restricts its use to other >>>> transport extensions that have talked about these things. Should >>>> there be a statement that this option must not be used unless by a >>>> transport extension that's discussed how to use it? If not, then >>>> shouldn't this document talk about what happens if there's no >>>> transport header below to inform audit function behavior? >>>> >>>> >>>> Minor issues: >>>> >>>> m1) Figure 1 isn't right. I think what you want is: >>>> >>>> 0 1 2 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Option Type | Option Length |X|L|E|C| res | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> m2) There is confusion in two places in the document where you discuss >>>> where to put the CDO (at the end of page 5 and the end of page 7). The >>>> current text says the option MUST be the first option in whatever >>>> destination options block it appears in. That seems problematic. What >>>> if some other option also declares it MUST be the first option? I >>>> wonder if instead of trying to say "must be the first option in the >>>> block" you are trying only to say "If you use a CDO, use it in the >>>> destination options block that comes before an AH block, not the one >>>> that might come after". >>>> >>>> m3) Third paragraph of section 6: Should the last sentence end with >>>> "in a given stream." ? >>>> >>>> Nits/editorial comments: >>>> >>>> Introduction: Should "Due to space limitation" be "Due to space >>>> limitations in the IPV4 header"? >>>> >>>> Section 4: Right after the definition of Reserved, there is a line >>>> that says "foo". What should it say instead? > I noticed just after "foo" it says: > > All packets sent over a ConEx-capable TCP connection or belonging to > the same ConEx-capable flow MUST carry the CDO. > I think this was meant to say: > > All packets belonging to the same ConEx-capable flow (e.g. sent over > the same ConEx-capable TCP connection) MUST carry the CDO. > > > Thanks again, particularly for revealing the huge gap we had missed. > > Regards > > > Bob >>>> >>>> The last sentence on page 6: I don't think it's the network node that >>>> you are saying must be aware. Perhaps you mean designers of network >>>> nodes? >>>> >>>> At the top of page 7, you have "They MAY log". You shouldn't use a >>>> 2119 MAY here - it's not part of the protocol. Similarly, in section >>>> 6, "MAY compare the two, and MAY log" should not use 2119. >>>> >>>> First paragraph of section 6: "natively" is not clear. Perhaps >>>> replacing "will not natively copy" with "will not normally copy"? >>>> >>>> Second paragraph of section 6: I suggest replacing "ignore any >>>> CDO" with "ignore any CDO in the outer header". >>>> >>>> Consider moving the description of the bits in the option type field, >>>> particularly the chg bit, earlier in the document. Right now, the >>>> first mention is in the security consideration section, and most >>>> of the definition doesn't happen until the IANA considerations. >>>> It would help if it were clear what that bit was going to be before >>>> you ever mention AH. >>>> >>> >> >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ --------------050107080207010108080202 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 10/1/15 12:27 PM, Bob Briscoe wrote:
Robert, Mirja,

Responding (eventually) as one of the authors of conex-abstract-mech

First one point I picked up that might be a misconception from Robert:

On 26.08.2015 22:19, Robert Sparks wrote:
Should
there be a statement that this option must not be used unless by a
transport extension that's discussed how to use it? If not, then
shouldn't this document talk about what happens if there's no
transport header below to inform audit function behavior?
ConEx is designed so that audit is agnostic to the particular transport behaviour. One would not expect the audit function to look for a transport header and change its audit behaviour accordingly (ConEx is designed on the assumption the transport header is or at least could be encrypted). conex-abstract-mech says:

   Transport Oblivious:  Audit SHOULD NOT be designed around one
      particular rate response, such as any particular TCP congestion
      control algorithm or one particular resource sharing regime such
      as TCP-friendliness [RFC5348].  An important goal is to give
      ingress networks the freedom to unilaterally allow different rate
      responses to congestion and different resource sharing regimes
      [Evol_cc], without having to coordinate with other networks over
      details of individual flow behaviour;
I'd be interested to know where in the docs you got a different impression, because we ought to try to fix that.
I didn't actually think the audit function code would change per transport. But as you point out, my suggested fix to the disconnect I think I see implies that, so it is off the mark.

Your suggestions below will address the concern.



Now, responding to the conversation...


On 28/09/15 20:37, Robert Sparks wrote:


On 9/22/15 7:46 AM, Mirja Khlewind wrote:
Hi,

regarding M1:

I don't think we can say much more in this doc than what is already said in the abstract mechanism doc as we simply don't know which protocol will be used on top of it.
So should this document restrict the use of the extension to those protocols that are used on top of it where the discussion can be concrete? (That's what I was suggesting when I asked " Should there be a statement that this option must not be used unless by a transport extension that's discussed how to use it?")
That /seems/ reasonable. But let's consider a test-case before adopting this last sentence: e.g. DNS

I could implement ConEx for a sender of DNS datagrams (that receives no congestion feedback). conex-abstract-mech says:
      Alternatively, without sufficiently precise
      congestion feedback from the receiver, the source may have to
      conservatively send extra ConEx markings in order to avoid
      understating congestion.
So, I could modify my DNS sender to add a CDO header to all IPv6 packets and always set the credit flag. Then, if my sender was behind a ConEx policer, it would consume some degree of congestion allowance, but it could never be accused of understating congestion by an audit function.

Would I need a DNS-specific ConEx document to make this modification? or could I just implement it based on conex-abstract-mech and conex-dest-opt?
Actually just these two docs would be sufficient. A DNS-conex document might be able to suggest a better more efficient mechanism, but it wouldn't be /necessary/ to write that doc to implement ConEx in DNS.

The subtle point here is that the top-level requirement that ConEx places on a transport protocol is merely not to understate the congestion you cause. Any doc defining how a transport sets ConEx information is really just guidance on how not to look like you are being dishonest if you intend to be honest. The DNS example shows how you can be sufficiently honest without a document.
I follow that.

It's a minor pedantic point, but I think the above indicates that -destopt- doesn't define a concrete ConEx protocol by itself.


What we can do is to add one sentence saying that there must be a way in the higher layer protocol to provide feedback about congestion (loss and/or ECN) and that the specification for the higher layer protocol must discuss how an audit function in the network can access information on congestion on the forward path (e.g. monitoring seq#).
That makes sense to me.
conex-abstract-mech deliberately does not require transports to use congestion feedback (as in the DNS example above).
Also, as quoted above, conex-abstract-mech requires audit to be transport-agnostic, altho optimisations are possible when the transport is visible.

So please don't contradict conex-abstract-mech by saying either of these things.

The way the ConEx docs are structured, conex-abstract-mech is the place to state requirements on transport protocols and on audit, and I haven't yet seen anything in this conversation to say we've missed one (altho I have noticed below that we failed to act on one requirement). I certainly agree that a doc giving examples of good audit functions would be extremely useful. But I think the requirements on audit in conex-abstract-mech are sufficient.

I know some people really want the rules to be clearer. But the requirements for audit in conex-abstract-mech will still carry more weight than how one particular example audit device works.
Right.

The "must discuss how" above was what was tempting for me.




Further regarding the abstract mechanism doc, it says the following:

"The general goal of an auditor is to make sure that any ConEx-enabled
traffic is sent with sufficient ConEx-Re-Echo and ConEx-Credit
signals. A concrete definition of the ConEx protocol MUST define
what sufficient means."

I'm not sure if this is a correct usage of normative language, but I will double-check with the author of this document. However, I don't think we can say more about what sufficient means that it is already described in the abstract mechanism doc (further down in section 5.5).

It might also be the case that the authors actually meant to say here something like

"A transport that uses the ConEx protocol MUST define
what sufficient means."

which would probably me more sensical. I'll check with them.
Bear in mind that abstract-mech is /ultra/ abstract (Matt Mathis suggested this and we all agreed). abstract-mech envisages that conex-dest-opt might not be the only concrete ConEx protocol. So this sentence means that conex-dest-opt has to state the basic audit rules. I.e. the three penalty criteria in <https://tools.ietf.org/html/draft-wagner-conex-audit-01#section-2.3>

If David Wagner is not available to re-write these for conex-destopt and the draft authors can't, I could have a go, but I have other stuff I'm meant to be doing this week.

Sorry, when I reviewed conex-dest-opt for compliance with abstract-mech, I failed to notice the gap where this important requirement should have been satisfied - probably because we stuck the requirement in section "5.5 Audit", whereas we should have added it to the list in "3.3. Requirements for non-abstract ConEx specifications".

I suspect fixing this will resolve your concern, Robert.
Yes.
I'm grateful you pointed this out - it is a huge omission - we were all assuming it, but the actual writing has fallen between the cracks of all the docs.

One more response in the nits below...


However, while writing these documents, we figured that we actually would need another document on auditing because there are some assumption that must be taken in the protocol design. The main purpose of that doc is/was to give guidance how to design an audit without caring of all the details in the tcp-mods doc. There is an (expired) draft (draft-wagner-conex-audit-01) which we did not follow because there was no energy in the wg and it was not in the original milestone list. We should definitely consider to revisit this draft if we plan further experimentation on ConEx.

Does this makes sense to you?
Yes.

Mirja



On 26.08.2015 22:19, Robert Sparks wrote:
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-conex-destopt-09
Reviewer: Robert Sparks
Review Date: 26 Aug 2015
IETF LC End Date: 31 Aug 2015
IESG Telechat date: 1 Oct 2015

Summary: On the right track with open issues

Major issues:

M1) This document claims to specify "the ConEx wire protocol in IPv6".
But it reads more like "this document just defines an option, other
documents will talk about how and when the option is used". The
abstract-mech document requires that concrete ConEx specifications
discuss the audit function explicitly, with several requirements for
detail scattered through that document. In particular, it asks for a
discussion of how the concrete protocol defends against a set of
likely attacks against the audit function. This document is silent,
and I think a side-effect of being processed in parallel with
tcp-modifications, and suspect most of the thinking on meeting the
requirements for discussing the audit function has concentrated there.
However, nothing in _this_ document restricts its use to other
transport extensions that have talked about these things. Should
there be a statement that this option must not be used unless by a
transport extension that's discussed how to use it? If not, then
shouldn't this document talk about what happens if there's no
transport header below to inform audit function behavior?


Minor issues:

m1) Figure 1 isn't right. I think what you want is:

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |X|L|E|C| res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

m2) There is confusion in two places in the document where you discuss
where to put the CDO (at the end of page 5 and the end of page 7). The
current text says the option MUST be the first option in whatever
destination options block it appears in. That seems problematic. What
if some other option also declares it MUST be the first option? I
wonder if instead of trying to say "must be the first option in the
block" you are trying only to say "If you use a CDO, use it in the
destination options block that comes before an AH block, not the one
that might come after".

m3) Third paragraph of section 6: Should the last sentence end with
"in a given stream." ?

Nits/editorial comments:

Introduction: Should "Due to space limitation" be "Due to space
limitations in the IPV4 header"?

Section 4: Right after the definition of Reserved, there is a line
that says "foo". What should it say instead?
I noticed just after "foo" it says:

All packets sent over a ConEx-capable TCP connection or belonging to
the same ConEx-capable flow MUST carry the CDO.
I think this was meant to say:

All packets belonging to the same ConEx-capable flow (e.g. sent over 
the same ConEx-capable TCP connection) MUST carry the CDO.


Thanks again, particularly for revealing the huge gap we had missed.

Regards


Bob

The last sentence on page 6: I don't think it's the network node that
you are saying must be aware. Perhaps you mean designers of network
nodes?

At the top of page 7, you have "They MAY log". You shouldn't use a
2119 MAY here - it's not part of the protocol. Similarly, in section
6, "MAY compare the two, and MAY log" should not use 2119.

First paragraph of section 6: "natively" is not clear. Perhaps
replacing "will not natively copy" with "will not normally copy"?

Second paragraph of section 6: I suggest replacing "ignore any
CDO" with "ignore any CDO in the outer header".

Consider moving the description of the bits in the option type field,
particularly the chg bit, earlier in the document. Right now, the
first mention is in the security consideration section, and most
of the definition doesn't happen until the IANA considerations.
It would help if it were clear what that bit was going to be before
you ever mention AH.



_______________________________________________
conex mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex 

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

--------------050107080207010108080202-- From nobody Mon Oct 5 16:43:18 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D451B346D; Mon, 5 Oct 2015 16:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 EPXv_rzVtiOd; Mon, 5 Oct 2015 16:43:14 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 0C3C51B2DDC; Mon, 5 Oct 2015 16:43:13 -0700 (PDT) Received: from 242.23.189.80.dyn.plus.net ([80.189.23.242]:41464 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZjFPT-0001IZ-Ev; Tue, 06 Oct 2015 00:43:11 +0100 To: Stephen Farrell , Suresh Krishnan References: <20151001000655.11590.32411.idtracker@ietfa.amsl.com> <560CEF4E.5080409@cs.tcd.ie> <560DAE68.60401@bobbriscoe.net> <560E45E2.2040809@cs.tcd.ie> From: Bob Briscoe Message-ID: <56130B0E.3000906@bobbriscoe.net> Date: Tue, 6 Oct 2015 00:43:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560E45E2.2040809@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net Archived-At: Cc: "draft-ietf-conex-destopt.ad@ietf.org" , "conex-chairs@ietf.org" , The IESG , "conex@ietf.org" , "draft-ietf-conex-destopt@ietf.org" Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 23:43:17 -0000 Stephen On 02/10/15 09:52, Stephen Farrell wrote: > Hi Bob, > > Those all sound like pretty good changes except perhaps for... > > On 01/10/15 23:06, Bob Briscoe wrote: >> >> [Proposed] >> A network-based attacker could alter ConEx information to fool an audit >> function in a downstream network into discarding packets. An attack on >> one network from another by changing an immutable field can be traced, >> so it would be unlikely given network operators care about their >> reputation. > If the attack is carried out by a compromised node then the goals > of the rightful owner of that node aren't relevant. Yes, I know. I was trying not to side-track too much into a whole treatise on all the more damaging and less traceable attacks that become possible if a network node is compromised (e.g. the TTL expiry attack I mentioned in the email, but not in proposed draft text). Perhaps the solution is to say less rather than more, and not mention operator reputation, given other attacks are more fruitful whether the attacker is the operator or not. How about this: [Proposal #2] A network-based attacker could alter ConEx information to fool an audit function in a downstream network into discarding packets. However, otherexisting attacks from one network on another such a TTL expiry attacks are more damaging (because ConEx audit discards silently) and less traceable (because TTL is meant to change, whereas CDO is not). Then the following para can still pick up on the traceability aspect. > >> Nonetheless, if ConEx information was being altered within a >> network, IPsec AH or other more stealthy e2e integrity checks could be >> useful tools to help pin-point the attack location. > I'd omit "more stealthy" unless you want to add a reference. (I > guess that'd be to your Phd thesis and why not include that.) I'll leave the authors to decide - a ref to my S.12.1.4 of my thesis at this point would work. Cheers Bob > > Cheers, > S. -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Mon Oct 5 18:02:57 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD241B3006; Mon, 5 Oct 2015 18:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tm0e3Vvy-sUF; Mon, 5 Oct 2015 18:02:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12191B3005; Mon, 5 Oct 2015 18:02:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 92CC9BE49; Tue, 6 Oct 2015 02:02:53 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv-qokUTgBhE; Tue, 6 Oct 2015 02:02:52 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.26.211]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 79F3ABE35; Tue, 6 Oct 2015 02:02:49 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1444093372; bh=ZNl3wzEtmQKL2a1rIZsOtFkgJAZWMwAAD/oPZJa9pSQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=O7o4RfHE4zxBhq57XLkk8k0n3q6St1stOWCAcjDF7er3AB7bjkttaQHVQoPlzr2ws mQ14k2Jf7WIIq4DjJG6wvvslIkQhC8ayAyjr9at18CpBmNpvpeUl9SJPaD3iLtQ3Ra SAmb9OHOBeZKLzXFhJPCrKFLTDJIaSbvDWv/iz64= To: Bob Briscoe , Suresh Krishnan References: <20151001000655.11590.32411.idtracker@ietfa.amsl.com> <560CEF4E.5080409@cs.tcd.ie> <560DAE68.60401@bobbriscoe.net> <560E45E2.2040809@cs.tcd.ie> <56130B0E.3000906@bobbriscoe.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56131DB8.1040109@cs.tcd.ie> Date: Tue, 6 Oct 2015 02:02:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56130B0E.3000906@bobbriscoe.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-conex-destopt.ad@ietf.org" , "conex-chairs@ietf.org" , The IESG , "conex@ietf.org" , "draft-ietf-conex-destopt@ietf.org" Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 01:02:56 -0000 Hiya, On 06/10/15 00:43, Bob Briscoe wrote: > > [Proposal #2] > A network-based attacker could alter ConEx information to fool an audit > function in a downstream network into discarding packets. However, > otherexisting attacks from one network on another such a TTL expiry > attacks are more damaging (because ConEx audit discards silently) and > less traceable (because TTL is meant to change, whereas CDO is not). That's better, yes. Probably no need to address it in this document but I guess our assumptions about other existing attacks might change as more and more network traffic is ciphertext at various layers. I'm also generally leery of arguments of the form "no need to do something here as there's a worse thing there" since those encourage us to do nothing anywhere, so I'd lose that kind of language if it can be done. S. From nobody Thu Oct 8 09:03:40 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC661A90FD; Thu, 8 Oct 2015 09:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Y8hxMTHaADVb; Thu, 8 Oct 2015 09:03:33 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E52C1A90DB; Thu, 8 Oct 2015 09:03:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 09A75D9321; Thu, 8 Oct 2015 18:03:21 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QPglbOop3BpI; Thu, 8 Oct 2015 18:03:20 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AD649D9320; Thu, 8 Oct 2015 18:03:20 +0200 (MEST) To: Stephen Farrell , Bob Briscoe , Suresh Krishnan References: <20151001000655.11590.32411.idtracker@ietfa.amsl.com> <560CEF4E.5080409@cs.tcd.ie> <560DAE68.60401@bobbriscoe.net> <560E45E2.2040809@cs.tcd.ie> <56130B0E.3000906@bobbriscoe.net> <56131DB8.1040109@cs.tcd.ie> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <561693A4.2000609@tik.ee.ethz.ch> Date: Thu, 8 Oct 2015 18:02:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56131DB8.1040109@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-conex-destopt.ad@ietf.org" , "conex-chairs@ietf.org" , The IESG , "conex@ietf.org" , "draft-ietf-conex-destopt@ietf.org" Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 16:03:35 -0000 Hi, I'm fine with the text below. But a quick question: Is there really a case where the attacker would alter the packet to make another network potentially drop the packet, instead of juts dropping it on its own? Mirja On 06.10.2015 03:02, Stephen Farrell wrote: > > Hiya, > > On 06/10/15 00:43, Bob Briscoe wrote: >> >> [Proposal #2] >> A network-based attacker could alter ConEx information to fool an audit >> function in a downstream network into discarding packets. However, >> otherexisting attacks from one network on another such a TTL expiry >> attacks are more damaging (because ConEx audit discards silently) and >> less traceable (because TTL is meant to change, whereas CDO is not). > > That's better, yes. > > Probably no need to address it in this document but I guess our > assumptions about other existing attacks might change as more and > more network traffic is ciphertext at various layers. I'm also > generally leery of arguments of the form "no need to do something > here as there's a worse thing there" since those encourage us to > do nothing anywhere, so I'd lose that kind of language if it can > be done. > > S. > From nobody Fri Oct 9 02:44:41 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2761B3238; Fri, 9 Oct 2015 02:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 BvIVJ5MXtVjE; Fri, 9 Oct 2015 02:44:38 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0FF1B3235; Fri, 9 Oct 2015 02:44:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E580FD9305; Fri, 9 Oct 2015 11:44:32 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HYdZGKvAqKX6; Fri, 9 Oct 2015 11:44:32 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9C8B8D9304; Fri, 9 Oct 2015 11:44:32 +0200 (MEST) To: Stephen Farrell , The IESG References: <20151001115619.27054.3625.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <56178C5B.1000609@tik.ee.ethz.ch> Date: Fri, 9 Oct 2015 11:43:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151001115619.27054.3625.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-conex-tcp-modifications.ad@ietf.org, draft-ietf-conex-tcp-modifications@ietf.org, conex-chairs@ietf.org, conex@ietf.org Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-tcp-modifications-09: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 09:44:40 -0000 Hi Stephan, quick reply to you comment below. The two points below are discussed in draft-ietf-conex-destopt as ConEx is signaled in the IP layer and the attacks would (from my point of view) only interfere with the signaling (and not any additional algorithms that are used in TCP to decide when to set a marking). draft-ietf-conex-destopt even has an own section on "Mitigating flooding attacks by using preferential drop". I guess that's what you've been looking for, right? Further, draft-ietf-conex-destopt says in the security section that IPsec AH can be used to detect changes to ConEx information. Actually it does not say what to do if such changes are detected. I'll check with my co-authors if we can add some more information here. Regarding draft-ietf-conex-tcp-modifications, I've added two sentences at the beginning of the security section to say that these issues are discussed in draft-ietf-conex-destopt. Is that okay for you? Mirja On 01.10.2015 13:56, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-conex-tcp-modifications-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > 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-conex-tcp-modifications/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Seems like a fine thing to experiment with. I hope the results > are interesting. > > The security considerations really ought take into account or at > least mention potential misbehaviour by middleboxes and also how > conex might be affected by DoS attacks. > From nobody Fri Oct 9 04:04:32 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E1E1B3255; Fri, 9 Oct 2015 04:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 PFkT7lpd7-BS; Fri, 9 Oct 2015 04:04:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC1D71A9092; Fri, 9 Oct 2015 04:04:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3C506BE59; Fri, 9 Oct 2015 12:04:23 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twQ7rsA1SHUV; Fri, 9 Oct 2015 12:04:23 +0100 (IST) Received: from [134.226.63.110] (cswireless63-110.scss.tcd.ie [134.226.63.110]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 079C1BE54; Fri, 9 Oct 2015 12:04:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1444388663; bh=58Vqd1MQzy9dT0m8Rtj+O02oe+TQk6tuT+CpteKqkco=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=dNBES6cOZlaGCNqKygq9nD3MVr7QfQpESj8ik3sAOKXj1r88H4EplN0KlR0MzI0Sk 1RXh8SiaZ5MYDdss/2M8XFj54gD1CRtKF2jsMAYNXbLzCi4vSd+ARKmnGRtz1q8Guy 3A21LTkCqDj6N/YWH8ofEjKyzeMgQ5f6EL0dCDOk= To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Bob Briscoe , Suresh Krishnan References: <20151001000655.11590.32411.idtracker@ietfa.amsl.com> <560CEF4E.5080409@cs.tcd.ie> <560DAE68.60401@bobbriscoe.net> <560E45E2.2040809@cs.tcd.ie> <56130B0E.3000906@bobbriscoe.net> <56131DB8.1040109@cs.tcd.ie> <561693A4.2000609@tik.ee.ethz.ch> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <56179F35.2010807@cs.tcd.ie> Date: Fri, 9 Oct 2015 12:04:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <561693A4.2000609@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-conex-destopt@ietf.org" , "draft-ietf-conex-destopt.ad@ietf.org" , "conex-chairs@ietf.org" , The IESG , "conex@ietf.org" Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 11:04:28 -0000 On 08/10/15 17:02, Mirja Kühlewind wrote: > Hi, > > I'm fine with the text below. But a quick question: Is there really a > case where the attacker would alter the packet to make another network > potentially drop the packet, instead of juts dropping it on its own? Good point. But I guess that'd provide a way for an attacker to hide their tracks, though so yeah it probably could happen. S. > > Mirja > > > On 06.10.2015 03:02, Stephen Farrell wrote: >> >> Hiya, >> >> On 06/10/15 00:43, Bob Briscoe wrote: >>> >>> [Proposal #2] >>> A network-based attacker could alter ConEx information to fool an audit >>> function in a downstream network into discarding packets. However, >>> otherexisting attacks from one network on another such a TTL expiry >>> attacks are more damaging (because ConEx audit discards silently) and >>> less traceable (because TTL is meant to change, whereas CDO is not). >> >> That's better, yes. >> >> Probably no need to address it in this document but I guess our >> assumptions about other existing attacks might change as more and >> more network traffic is ciphertext at various layers. I'm also >> generally leery of arguments of the form "no need to do something >> here as there's a worse thing there" since those encourage us to >> do nothing anywhere, so I'd lose that kind of language if it can >> be done. >> >> S. >> > From nobody Fri Oct 9 04:07:27 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D511B360C; Fri, 9 Oct 2015 04:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pMJ1-YI_-xu3; Fri, 9 Oct 2015 04:07:21 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A171B3607; Fri, 9 Oct 2015 04:07:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1F37DBE59; Fri, 9 Oct 2015 12:07:20 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OX6_5JcTiw7f; Fri, 9 Oct 2015 12:07:20 +0100 (IST) Received: from [134.226.63.110] (cswireless63-110.scss.tcd.ie [134.226.63.110]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D8464BE54; Fri, 9 Oct 2015 12:07:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1444388839; bh=AwRTcEe1cJK9Tg50XInMxbJFs2ByyYdZDqbU18LuqwM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=2PcseQgx7RdgLAC2sL2f2Hf18MlfpgmsQSnLL0az9vUBoR5GMqc1Siw5+EFhWcPjN x9reQqf9moOcVy9IeOakEMs4RiSU3RdYOmgZVLAH4HoXoM+xrlJ39ktVsN61T4k9ND tS5lMyJShsxAM1KeLG09nOSWoklHoxRZM4/o2nE8= To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , The IESG References: <20151001115619.27054.3625.idtracker@ietfa.amsl.com> <56178C5B.1000609@tik.ee.ethz.ch> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56179FE6.1000700@cs.tcd.ie> Date: Fri, 9 Oct 2015 12:07:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56178C5B.1000609@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-conex-tcp-modifications.ad@ietf.org, draft-ietf-conex-tcp-modifications@ietf.org, conex-chairs@ietf.org, conex@ietf.org Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-tcp-modifications-09: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 11:07:24 -0000 On 09/10/15 10:43, Mirja Kühlewind wrote: > Hi Stephan, > > quick reply to you comment below. The two points below are discussed in > draft-ietf-conex-destopt as ConEx is signaled in the IP layer and the > attacks would (from my point of view) only interfere with the signaling > (and not any additional algorithms that are used in TCP to decide when > to set a marking). > > draft-ietf-conex-destopt even has an own section on "Mitigating flooding > attacks by using preferential drop". I guess that's what you've been > looking for, right? > > Further, draft-ietf-conex-destopt says in the security section that > IPsec AH can be used to detect changes to ConEx information. Actually it > does not say what to do if such changes are detected. I'll check with my > co-authors if we can add some more information here. > > Regarding draft-ietf-conex-tcp-modifications, I've added two sentences > at the beginning of the security section to say that these issues are > discussed in draft-ietf-conex-destopt. Is that okay for you? Seems good, thanks, S. > > Mirja > > > > On 01.10.2015 13:56, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-conex-tcp-modifications-09: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> 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-conex-tcp-modifications/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> Seems like a fine thing to experiment with. I hope the results >> are interesting. >> >> The security considerations really ought take into account or at >> least mention potential misbehaviour by middleboxes and also how >> conex might be affected by DoS attacks. >> > From nobody Tue Oct 13 07:43:24 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1931B44CD; Tue, 13 Oct 2015 07:43:23 -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] autolearn=ham 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 ook7sUpz5Z57; Tue, 13 Oct 2015 07:43:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B391B44D3; Tue, 13 Oct 2015 07:43:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.5.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151013144319.19512.93834.idtracker@ietfa.amsl.com> Date: Tue, 13 Oct 2015 07:43:19 -0700 Archived-At: Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-tcp-modifications-10.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 14:43:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion Exposure Working Group of the IETF. Title : TCP modifications for Congestion Exposure Authors : Mirja Kuehlewind Richard Scheffenegger Filename : draft-ietf-conex-tcp-modifications-10.txt Pages : 20 Date : 2015-10-13 Abstract: Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-tcp-modifications/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-conex-tcp-modifications-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 Fri Oct 16 03:17:57 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAFB1A03AA; Fri, 16 Oct 2015 03:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 egfOv5LhiCta; Fri, 16 Oct 2015 03:17:51 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA8F1A1A70; Fri, 16 Oct 2015 03:17:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id EE5F610AC9A; Fri, 16 Oct 2015 12:17:49 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlxVp7nFsbRx; Fri, 16 Oct 2015 12:17:49 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id D0E4C10AC59; Fri, 16 Oct 2015 12:17:35 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.18]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Fri, 16 Oct 2015 12:17:25 +0200 From: Dirk Kutscher To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's No Objection on draft-ietf-conex-mobile-05: (with COMMENT) Thread-Index: AQHQ/D9EqnFaRM/xaE2DAPKBEbWThZ5t/PHQ Date: Fri, 16 Oct 2015 10:17:25 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F5249A6737E2D@PALLENE.office.hd> References: <20151001114934.21091.71499.idtracker@ietfa.amsl.com> In-Reply-To: <20151001114934.21091.71499.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.198] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-conex-mobile.ad@ietf.org" , "conex-chairs@ietf.org" , "conex@ietf.org" , "draft-ietf-conex-mobile@ietf.org" Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-mobile-05: (with COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 10:17:53 -0000 SEkgU3RlcGhlbiwNCg0KdGhhbmtzIGZvciB0aGUgcmV2aWV3Lg0KDQpZb3UgYXJlIG1ha2luZyBh IGZhaXIgcG9pbnQuIFRoZSBkb2N1bWVudCB3ZW50IHRocm91Z2ggYSBmZXcgaXRlcmF0aW9ucyBp biB0aGUgV0cuIEluaXRpYWxseSBpdCBwcm92aWRlZCBtb3JlIGRldGFpbGVkIGRpc2N1c3Npb24g b2YgdGVjaG5pY2FsIGRlcGxveW1lbnQgYXNwZWN0cywgaG93ZXZlciBpdCBzZWVtZWQgdG8gYmUg V0cgY29uc2Vuc3VzIHRvIHJlZHVjZSB0aGF0LiBBcyBpdCBzdGFuZHMgbm93LCBpdCBkb2N1bWVu dHMgdXNlIGNhc2VzIGFuZCBpbml0aWFsIGRlcGxveW1lbnQgb3B0aW9ucyBmb3IgQ29uRXggaW4g TFRFLCB3aGljaCBpcyBhIGRvbWFpbiB3aGVyZSB0aGVyZSBpcyBhKSBhIG5lZWQgZm9yIHNvbWUg YXBwbGljYXRpb24taW5kZXBlbmRlbnQgdHJhZmZpYyBtYW5hZ2VtZW50IGFuZCBiKSB0aGUgcG9z c2liaWxpdHkgZm9yIGluaXRpYWwgZGVwbG95bWVudCAod2l0aGluIGFuIG9wZXJhdG9yIGRvbWFp biBmb3IgZXhhbXBsZSkuIFNvIHRoZSB2YWx1ZSBvZiB0aGUgZG9jdW1lbnQgd291bGQgYmUgdG8g ZG9jdW1lbnQgdGhhdC4NCg0KQXMgTWFydGluIG1lbnRpb25lZCwgdGhlIFdHIGFuZCBhbGwgcGVv cGxlIGludm9sdmVkIGFyZSB3ZWxsIGF3YXJlIG9mIHRoZSBkZWNsYXJlZCBJUFIuDQoNCkNoZWVy cywNCkRpcmsNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN0ZXBoZW4gRmFy cmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdIA0KU2VudDogRG9ubmVyc3Rh ZywgMS4gT2t0b2JlciAyMDE1IDEzOjUwDQpUbzogVGhlIElFU0cNCkNjOiBkcmFmdC1pZXRmLWNv bmV4LW1vYmlsZS5hZEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb25leC1tb2JpbGVAaWV0Zi5vcmc7 IGNvbmV4LWNoYWlyc0BpZXRmLm9yZzsgTWlyamEgS3VlaGxld2luZDsgY29uZXhAaWV0Zi5vcmcN ClN1YmplY3Q6IFN0ZXBoZW4gRmFycmVsbCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWNv bmV4LW1vYmlsZS0wNTogKHdpdGggQ09NTUVOVCkNCg0KU3RlcGhlbiBGYXJyZWxsIGhhcyBlbnRl cmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1jb25leC1t b2JpbGUtMDU6IE5vIE9iamVjdGlvbg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRo ZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGlu Y2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50 cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBz Oi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9y IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9u cy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywg Y2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLWNvbmV4LW1vYmlsZS8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCg0KDQotIFRoZXJlIGlzIGEgaHVnZSBhbW91bnQgb2Ygc2FsZXMtc3BlYWsg aW4gdGhpcyBkb2N1bWVudC4gIEZyYW5rbHkgdGhlcmUgaXMgc28gbXVjaCBvZiB0aGF0IGhlcmUs IGFuZCBubyBjb3VudGVycG9pbnQgbm9yIHJlYWwgYW5hbHlzaXMgdGhhdCBpcyB0ZWNobmljYWxs eSwgYnV0IGZhaXJseSwgY3JpdGljYWwgb2YgY29uZXgsIHRoYXQgdGhpcyBzZWVtcyBsaWtlIG1h cmtldGluZyBtYXRlcmlhbC4gV2h5IGFyZSB0aGUgYXV0aG9ycywgdGhlIFdHLCB0aGUgYXJlYSBh bmQgdGhlIElFVEYgcHJvZHVjaW5nIHRoYXQga2luZCBvZiB0aGluZz8gSSdtIHN1cmUgdGhlcmUg YXJlIGdvb2QgcmVhc29ucyB0byBwcm9kdWNlIHRoZSBtYXRlcmlhbCwgYnV0IEknbSBub3QgYXQg YWxsIHN1cmUgdGhhdCBvdWdodCBiZSBkb25lIHdpdGhpbiB0aGUgSUVURi4NCg0KLSBTYW1lIElQ UiBjb21tZW50IGFzIEJlbidzLiBXZXJlIHRoZSBXRyBhd2FyZT8NCg0KDQo= From nobody Fri Oct 16 04:12:19 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3B21A8AE9; Fri, 16 Oct 2015 04:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8WoPIS6mFqPM; Fri, 16 Oct 2015 04:12:15 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B7D1A8AEB; Fri, 16 Oct 2015 04:12:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id DD15310ACA0; Fri, 16 Oct 2015 13:12:12 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QZ75q2rmk1a; Fri, 16 Oct 2015 13:12:12 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id A341710AC9A; Fri, 16 Oct 2015 13:11:58 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.18]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Fri, 16 Oct 2015 13:11:58 +0200 From: Dirk Kutscher To: Ben Campbell , The IESG Thread-Topic: Ben Campbell's Discuss on draft-ietf-conex-mobile-05: (with DISCUSS and COMMENT) Thread-Index: AQHQ+8VKPMg47AVai0eE3ieIjIoz/55uDVGQ Date: Fri, 16 Oct 2015 11:11:58 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F5249A673802E@PALLENE.office.hd> References: <20150930211624.25308.24463.idtracker@ietfa.amsl.com> In-Reply-To: <20150930211624.25308.24463.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.198] Content-Type: multipart/mixed; boundary="_002_82AB329A76E2484D934BBCA77E9F5249A673802EPALLENEofficehd_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-conex-mobile.ad@ietf.org" , "conex-chairs@ietf.org" , "conex@ietf.org" , "draft-ietf-conex-mobile@ietf.org" Subject: Re: [conex] Ben Campbell's Discuss on draft-ietf-conex-mobile-05: (with DISCUSS and COMMENT) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 11:12:18 -0000 --_002_82AB329A76E2484D934BBCA77E9F5249A673802EPALLENEofficehd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVuLA0KDQp0aGFua3MgZm9yIHRoZSByZXZpZXcuDQoNCkluIGdlbmVyYWwsIHlvdSBhcmUg cmlnaHQgLS0gdGhlcmUgYXJlIGFkZGl0aW9uYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGhh dCBjb3VsZCBiZSBtZW50aW9uZWQgbW9yZSBleHBsaWNpdGx5LiBNb3N0IG9mIHRoZW0gYXBwbHkg dG8gQ29uRXggaW4gZ2VuZXJhbCwgcmVnYXJkbGVzcyBvZiB0aGUgZGVwbG95bWVudCBzY2VuYXJp by4NCg0KSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHlvdSB3ZXJlIG9uICB0aGUgYXR0YWNoZWQgZS1t YWlsIHRocmVhZCBkaXNjdXNzaW5nIHRoaXMgaW4gdGhlIGNvbnRleHQgb2YgdGhlIHNlY3VyaXR5 IGRpcmVjdG9yYXRlIHJldmlldy4NCg0KV2Ugd2lsbCBhZGQgc29tZXRoaW5nIGFsb25nIHRob3Nl IGxpbmVzIHRvIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9ucyAodGhlcmUgYXJl IG90aGVyIG5pdHMgdGhhdCB3YXJyYW50IGFub3RoZXIgcmV2KS4NCg0KVGhlIG1lbnRpb25lZCBJ UFIgYXBwbGllcyBhbGwgQ29uRXggZG9jdW1lbnRzLCBhbmQgdGhlIFdHIGlzIGF3YXJlIG9mIHRo YXQuDQoNCkJlc3QgcmVnYXJkcywNCkRpcmsNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0cnVtLmNvbV0gDQpTZW50 OiBNaXR0d29jaCwgMzAuIFNlcHRlbWJlciAyMDE1IDIzOjE2DQpUbzogVGhlIElFU0cNCkNjOiBk cmFmdC1pZXRmLWNvbmV4LW1vYmlsZS5hZEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb25leC1tb2Jp bGVAaWV0Zi5vcmc7IGNvbmV4LWNoYWlyc0BpZXRmLm9yZzsgTWlyamEgS3VlaGxld2luZDsgY29u ZXhAaWV0Zi5vcmcNClN1YmplY3Q6IEJlbiBDYW1wYmVsbCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0 Zi1jb25leC1tb2JpbGUtMDU6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCkJlbiBDYW1w YmVsbCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0 LWlldGYtY29uZXgtbW9iaWxlLTA1OiBEaXNjdXNzDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNl IGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRy ZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQg dGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIg dG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5o dG1sDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQg cG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9z aXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtY29uZXgtbW9iaWxlLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRElTQ1VT UzoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24g c2VlbXMgc3Vic3RhbnRpYWxseSBpbmNvbXBsZXRlLiBUaGUgcGhyYXNlICJpbmNsdWRlLCBidXQg YXJlIG5vdCBsaW1pdGVkIHRvIiBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0IHBlb3BsZSB0aG91Z2h0 IHRoZXJlIHdlcmUgYWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucy4gUGxlYXNlIHdyaXRlIHRoZW0g ZG93biwgb3IgZXhwbGFpbiB3aHkgdGhlcmUgcmVhbGx5IGFyZW4ndCBhZGRpdGlvbmFsIGNvbnNp ZGVyYXRpb25zLg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN ClRoZXJlIGlzIGFuIElQUiBkZWNsYXJhdGlvbiB0aGF0IGxpc3RzIHRoaXMgYXMgYW4gImFzc29j aWF0ZWQgZHJhZnQiLiBJJ20gbm90IHN1cmUgd2hhdCB0byBtYWtlIG9mIHRoYXQsIGJ1dCBpdCB3 YXMgbm90IG1lbnRpb25lZCBpbiB0aGUgc2hlcGhlcmQgcmV2aWV3Lg0KDQpUaGlzIHJlYWRzIG11 Y2ggbGlrZSBhbiBhZHZvY2FjeSB3aGl0ZSBwYXBlci4gVGhlcmUncyB1c2VmdWwgaW5mb3JtYXRp b24gaW4gaXQsIGJ1dCBJIHdvdWxkIGhhdmUgcHJlZmVycmVkIGxlc3Mgb2YgdGhlIG1hcmtldGlu ZyB0b25lLiBCdXQgdGhhdCdzIGp1c3QgbWUsIGFuZCBJIGRvbid0IGV4cGVjdCB0aGF0IHRvIGNo YW5nZSB0aGlzIGxhdGUgaW4gdGhlIHByb2Nlc3MuDQoNCg0K --_002_82AB329A76E2484D934BBCA77E9F5249A673802EPALLENEofficehd_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Fri, 16 Oct 2015 11:11:57 GMT"; modification-date="Fri, 16 Oct 2015 11:11:57 GMT" From: Dirk Kutscher To: "Xialiang (Frank)" CC: secdir , "iesg@ietf.org" , "draft-ietf-conex-mobile.all@ietf.org" Subject: RE: secdir review of draft-ietf-conex-mobile-05 Thread-Topic: secdir review of draft-ietf-conex-mobile-05 Thread-Index: AdDsK7I1VyJu7Bl6QJ2ZXX3RKt6srwAQblSwAAEGHKAAAMkDEA== Date: Fri, 11 Sep 2015 09:48:48 +0000 References: <82AB329A76E2484D934BBCA77E9F52499A07A349@Hydra.office.hd> In-Reply-To: Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6565687570747278807878697470697676747980808070667370747_" MIME-Version: 1.0 --_000_6565687570747278807878697470697676747980808070667370747_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRnJhbmssDQoNCg0KDQpJbiBnZW5lcmFsLCB0aGUgQ29uRXgtcmVsYXRlZCByaXNrcyByZWdh cmRpbmcgbWFuaXB1bGF0aW5nIGNvbmdlc3Rpb24gbm90aWZpY2F0aW9uL2V4cG9zdXJlIGNhbiBh cHBseSB0byBtb2JpbGUgbmV0d29ya3MsIHRvby4NCg0KDQoNCldoYXQgY291bGQgcGVyaGFwcyBi ZSBzYWlkIGlzIHRoYXQgbW9iaWxlIG5ldHdvcmtzIChVTVRTLCBMVEUpIGVtcGxveSBhIHZpcnR1 YWwtY2lyY3VpdC1saWtlIGJlYXJlciBtb2RlbCBmb3IgdGhlIGFjY2VzcywgaS5lLiwgdXNlcnMg aW4gYSBjZWxsIGNhbiBnZW5lcmFsbHkgbm90IHNlZSBvdGhlciB1c2Vyc6GvIHRyYWZmaWMgqEMg c28gdGhhdCB3b3VsZCBydWxlIG91dCBzb21lIHRocmVhdHMuIEFsc28sIGF1dGhlbnRpY2F0aW9u IGlzIHBhcnQgb2YgdGhlIGJlYXJlciBlc3RhYmxpc2htZW50LCBzbyB0aGUgbmV0d29yayBnZW5l cmFsbHkga25vd3MgdGhlIHVzZXIgYW5kIGRldmljZSBpZGVudGl0eS4NCg0KDQoNCk5vdywgYXNz dW1pbmcgdGhhdCBtb2JpbGUgbmV0d29ya3MgY2FuIGJlIHN1YmplY3QgdG8gcGFzc2l2ZSBtb25p dG9yaW5nLCBvbmUgY291bGQgY2xhaW0gdGhhdCB0aGlzIHdvdWxkIGVuYWJsZSBhdHRhY2tlcnMg dG8gY29sbGVjdCBpbmZvcm1hdGlvbiBhYm91dCBhIHVzZXKhr3MgY29uZ2VzdGlvbiBjb250cmli dXRpb24gKGFsc28gb3ZlciB0aW1lKSwgYnV0IHRoYXQgdGhyZWF0IHNlZW1zIGxlc3MgY3JpdGlj YWwgKGNvbXBhcmVkIHRvIGV4cG9zaW5nIHRoZSBwYXlsb2FkIGl0c2VsZikuDQoNCg0KDQpCZXN0 IHJlZ2FyZHMsDQoNCkRpcmsNCg0KDQoNCg0KDQpGcm9tOiBYaWFsaWFuZyAoRnJhbmspIFttYWls dG86ZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbV0NClNlbnQ6IEZyZWl0YWcsIDExLiBTZXB0ZW1i ZXIgMjAxNSAxMToyMA0KVG86IERpcmsgS3V0c2NoZXINCkNjOiBzZWNkaXI7IGllc2dAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtY29uZXgtbW9iaWxlLmFsbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IHNl Y2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb25leC1tb2JpbGUtMDUNCg0KDQoNCkhpIERpcmss DQoNClRoYW5rIHlvdSBmb3IgcXVpY2sgcmVzcG9uc2UuDQoNCkkgcmV2aWV3ZWQgdGhlIGRyYWZ0 cyB5b3UgbWVudGlvbmVkIGJlbG93LiBJIGFncmVlIHRoYXQgdGhleSBhbHJlYWR5IGRpc2N1c3Nl ZCB0aGUgZ2VuZXJhbCBzZWN1cml0eSBpc3N1ZXMgSSBhbSBjb25jZXJuZWQsIGVzcGVjaWFsbHkg aW4gdGhlIGRyYWZ0LWNvbmV4LWFic3RyYWN0LW1lY2gtMTMgYW5kIGl0cyByZWZlcmVuY2UuDQoN Cg0KDQpTbywgaW4gZ2VuZXJhbCwgbXkgY29uY2VybnMgYXJlIGFkZHJlc3NlZC4gQnV0IEkgc3Rp bGwgaGF2ZSBhIGxpdHRsZSBiaXQgZG91YnRzIGFib3V0IHBvc3NpYmx5IG5ldyBzZWN1cml0eSBp c3N1ZXMgZm9yIHRoZSB1c2UgY2FzZXMgb2YgdXNpbmcgQ29uRXggcHJvdG9jb2wgb3ZlciB0aGUg bW9iaWxlIGNvbW11bmljYXRpb24gbmV0d29ya3MuIEkgYW0gbm90IGFuIGV4cGVydCBpbiB0aGlz IGFyZWEsIGNhbiB5b3UgY2xhcmlmeSBtZT8NCg0KDQoNClRoYW5rcyENCg0KDQoNCkIuUi4NCg0K RnJhbmsNCg0KDQoNCreivP7IyzogRGlyayBLdXRzY2hlciBbbWFpbHRvOkRpcmsuS3V0c2NoZXJA bmVjbGFiLmV1XQ0Kt6LLzcqxvOQ6IDIwMTXE6jnUwjExyNUgMTY6NTINCsrVvP7IyzogWGlhbGlh bmcgKEZyYW5rKTsgc2VjZGlyOyBpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPjsg ZHJhZnQtaWV0Zi1jb25leC1tb2JpbGUuYWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNv bmV4LW1vYmlsZS5hbGxAaWV0Zi5vcmc+DQrW98ziOiBSRTogc2VjZGlyIHJldmlldyBvZiBkcmFm dC1pZXRmLWNvbmV4LW1vYmlsZS0wNQ0KDQoNCg0KSGkgRnJhbmssDQoNCg0KDQp0aGFua3MgZm9y IHRoZSByZXZpZXcuDQoNCg0KDQpUaGUgc2VjdXJpdHkgaXNzdWVzIHlvdSBtZW50aW9uZWQgd291 bGQgYXBwbHkgdG8gQ29uRXggaW4gZ2VuZXJhbC4gVGhlIGNvcnJlc3BvbmRpbmcgZG9jdW1lbnRz IGFyZSBkaXNjdXNzaW5nIHBvdGVudGlhbCBzZWN1cml0eSBpc3N1ZXM6DQoNCg0KDQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb25leC1hYnN0cmFjdC1tZWNoLTEzI3Bh Z2UtMjQgKGFsc28gc2VlIHRoZSByZWZlcmVuY2VzKQ0KDQpodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1jb25leC1kZXN0b3B0LTA5I3BhZ2UtMTANCg0KaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29uZXgtdGNwLW1vZGlmaWNhdGlvbnMtMDQjcGFn ZS0xMQ0KDQoNCg0KV2Whr2QgdGhlcmVmb3JlIHJhdGhlciBub3QgZHVwbGljYXRlIHRoYXQgZGlz Y3Vzc2lvbiBpbiBjb25leC1tb2JpbGUuDQoNCg0KDQpSZWdhcmRpbmcgdGhlIHNlY3VyaXR5IHJp c2tzIHlvdSBtZW50aW9uZWQsIEmhr2Qgc2F5IGl0IGlzIHF1ZXN0aW9uYWJsZSB3aGV0aGVyIENv bkV4IGludHJvZHVjZXMgYWRkaXRpb25hbCBpc3N1ZXMgZm9yIGNvbmZpZGVudGlhbGl0eSAoY29t cGFyZWQgdG8gSVAgYWxvbmUpLg0KDQoNCg0KVGhhbmtzLA0KDQpEaXJrDQoNCg0KDQoNCg0KDQoN CkZyb206IFhpYWxpYW5nIChGcmFuaykgW21haWx0bzpmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29t XQ0KU2VudDogRnJlaXRhZywgMTEuIFNlcHRlbWJlciAyMDE1IDAyOjQ5DQpUbzogc2VjZGlyOyBp ZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1jb25leC1tb2Jp bGUuYWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNvbmV4LW1vYmlsZS5hbGxAaWV0Zi5v cmc+DQpTdWJqZWN0OiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29uZXgtbW9iaWxlLTA1 DQoNCg0KDQpIaSwNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0 aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElF VEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRz IHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBh cmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJl YXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudC4N Cg0KDQoNClRoaXMgbWVtbyBkZXNjcmliZXMgYSBtb2JpbGUgY29tbXVuaWNhdGlvbnMgdXNlIGNh c2UgZm9yIGNvbmdlc3Rpb24gZXhwb3N1cmUgKENvbkV4KSB3aXRoIGEgcGFydGljdWxhciBmb2N1 cyBvbiB0aG9zZSBtb2JpbGUgY29tbXVuaWNhdGlvbiBuZXR3b3JrcyB0aGF0IGFyZSBhcmNoaXRl Y3R1cmFsbHkgc2ltaWxhciB0byB0aGUgM0dQUCBFdm9sdmVkIFBhY2tldCBTeXN0ZW0gKEVQUyku DQoNCg0KDQpJIGhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50czoNCg0KbCAgMS4gSXQgc2hvdWxk IGJlIGhlbHBmdWwgdG8gY29uc2lkZXIgdGhlIGNvbW11bmljYXRpb24gc2VjdXJpdHkgYmV0d2Vl biB0aGUgQ29uRXggc2VuZGVycyBhbmQgcmVjZWl2ZXJzIHN1Y2ggYXMgdGhlIENvbmZpZGVudGlh bGl0eSwgZGF0YSBpbnRlZ3JpdHkgYW5kIHBlZXIgZW50aXR5IGF1dGhlbnRpY2F0aW9uIGluIHRo ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBwYXJ0LiBCZWNhdXNlIGluIGdlbmVyYWwsIHRoZSBj b3JyZXNwb25kaW5nIHJpc2tzIGFyZSBzdGlsbCBwb3NzaWJsZSB0byBleGlzdC4NCg0KbCAgMi4g VGhlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBhbW9uZyBhbGwgdGhlIGVsZW1lbnRzIG9mIENv bkV4IHNvbHV0aW9uIHNob3VsZCBhbHNvIGJlIGNvbnNpZGVyZWQgdG8gaGFuZGxlIHRoZSBjb25k aXRpb24gb2YgZmFrZWQgbWVzc2FnZXMgb3IgaW52YWxpZCBwZWVyIGVsZW1lbnRzLg0KDQoNCg0K UmVjb21tZW5kYXRpb246ICBSZWFkeSBXaXRoIElzc3Vlcw0KDQoNCg0KQi5SLg0KDQpGcmFuaw0K DQoNCg0K --_000_6565687570747278807878697470697676747980808070667370747_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Frank,

 <= /p>

In general= , the ConEx-related risks regarding manipulating congestion notification/ex= posure can apply to mobile networks, too.

 = ;

What could= perhaps be said is that mobile networks (UMTS, LTE) employ a virtual-circu= it-like bearer model for the access, i.e., users in a cell can generally not see other users=A1=AF traffic =A8C so that would rule ou= t some threats. Also, authentication is part of the bearer establishment, s= o the network generally knows the user and device identity.

 = ;

Now, assum= ing that mobile networks can be subject to passive monitoring, one could cl= aim that this would enable attackers to collect information about a user=A1=AFs congestion contribution (also over time), but that thr= eat seems less critical (compared to exposing the payload itself).

 = ;

Best regar= ds,

Dirk<= /o:p>

 = ;

 

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Freitag, 11. September 2015 11:20
To: Dirk Kutscher
Cc: secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
Subject: Re: secdir review of draft-ietf-conex-mobile-05<= /span>

 

Hi Dirk,

Thank you = for quick response.

I reviewed= the drafts you mentioned below. I agree that they already discussed the ge= neral security issues I am concerned, especially in the draft-conex-abstrac= t-mech-13 and its reference.

 = ;

So, in gen= eral, my concerns are addressed. But I still have a little bit doubts about= possibly new security issues for the use cases of using ConEx protocol over the mobile communication networks. I am not an expert in thi= s area, can you clarify me?

 = ;

Thanks!

 = ;

B.R.<= /o:p>

Frank=

 = ;

=B7=A2=BC=FE=C8=CB: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu= ]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA9=D4=C211=C8=D5 16:52
=CA=D5=BC=FE=C8=CB: Xialiang (Frank); secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
=D6=F7=CC=E2: RE: secdir review of draft-ietf-conex-mobile-05

 

Hi Frank,<= o:p>

 = ;

thanks for= the review.

 = ;

The securi= ty issues you mentioned would apply to ConEx in general. The corresponding = documents are discussing potential security issues:

 = ;

htt= ps://tools.ietf.org/html/draft-ietf-conex-abstract-mech-13#page-24 (also see the references)

https://t= ools.ietf.org/html/draft-ietf-conex-destopt-09#page-10

https://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-04#page-11<= /a>

 = ;

We=A1=AFd = therefore rather not duplicate that discussion in conex-mobile.<= /span>

 = ;

Regarding = the security risks you mentioned, I=A1=AFd say it is questionable whether C= onEx introduces additional issues for confidentiality (compared to IP alone).

 = ;

Thanks,

Dirk<= /o:p>

 = ;

 = ;

 = ;

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Freitag, 11. September 2015 02:49
To: secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
Subject: secdir review of draft-ietf-conex-mobile-05

 

Hi,

I have reviewed this document as part of = the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were writ= ten primarily for the benefit of the security area directors.  Do= cument editors and WG chairs should treat these comments just like any= other last call comment.

 

This memo describes a mobile communicatio= ns use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally simi= lar to the 3GPP Evolved Packet System (EPS). 

 

I have the following comments:=

l  1. It should be = helpful to consider the communication security between the ConEx senders an= d receivers such as the Confidentiality, data integrity and peer entity authentication in the security considerations part. Becaus= e in general, the corresponding risks are still possible to exist.

l  2. The authentic= ation mechanism among all the elements of ConEx solution should also be con= sidered to handle the condition of faked messages or invalid peer elements.

 

Recommendation:  Ready With Issues

 

B.R.

Frank

 =

--_000_6565687570747278807878697470697676747980808070667370747_-- --_002_82AB329A76E2484D934BBCA77E9F5249A673802EPALLENEofficehd_-- From nobody Sun Oct 18 12:50:46 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F23F1ACEF3; Sun, 18 Oct 2015 12:50:43 -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] autolearn=ham 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 rEjJMc6iqlUy; Sun, 18 Oct 2015 12:50:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2281ACEE6; Sun, 18 Oct 2015 12:50:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151018195041.2697.53885.idtracker@ietfa.amsl.com> Date: Sun, 18 Oct 2015 12:50:41 -0700 Archived-At: Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-mobile-06.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 19:50:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion Exposure Working Group of the IETF. Title : Mobile Communication Congestion Exposure Scenario Authors : Dirk Kutscher Faisal Ghias Mir Rolf Winter Suresh Krishnan Ying Zhang Carlos J. Bernardos Filename : draft-ietf-conex-mobile-06.txt Pages : 25 Date : 2015-10-18 Abstract: This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPP Evolved Packet System (EPS). The draft provides a brief overview of the architecture of these networks (both access and core networks), current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this, this memo suggests a set of requirements for ConEx mechanisms that particularly apply to these mobile networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-mobile/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-conex-mobile-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-conex-mobile-06 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 Mon Oct 19 08:05:32 2015 Return-Path: X-Original-To: conex@ietf.org Delivered-To: conex@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 309581ACC8F; Mon, 19 Oct 2015 08:05:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019150529.5231.94568.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 08:05:29 -0700 Archived-At: Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-destopt-10.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 15:05:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion Exposure Working Group of the IETF. Title : IPv6 Destination Option for Congestion Exposure (ConEx) Authors : Suresh Krishnan Mirja Kuehlewind Carlos Ralli Filename : draft-ietf-conex-destopt-10.txt Pages : 12 Date : 2015-10-19 Abstract: Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-conex-destopt-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-conex-destopt-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 Mon Oct 19 16:04:18 2015 Return-Path: X-Original-To: conex@ietf.org Delivered-To: conex@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FA91B2DBC; Mon, 19 Oct 2015 16:04:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019230417.5856.33308.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 16:04:17 -0700 Archived-At: Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-destopt-11.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 23:04:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion Exposure Working Group of the IETF. Title : IPv6 Destination Option for Congestion Exposure (ConEx) Authors : Suresh Krishnan Mirja Kuehlewind Carlos Ralli Filename : draft-ietf-conex-destopt-11.txt Pages : 13 Date : 2015-10-19 Abstract: Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-conex-destopt-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-conex-destopt-11 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/