From nobody Tue Sep 22 05:46:48 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 EDECF1A6FFE; Tue, 22 Sep 2015 05:46:46 -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 pPCkXXq5-wgU; Tue, 22 Sep 2015 05:46:44 -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 51FF31A6FEE; Tue, 22 Sep 2015 05:46:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DF8D9D9314; Tue, 22 Sep 2015 14:46:33 +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 5kbmlc3C2GSf; Tue, 22 Sep 2015 14:46:33 +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 6A733D930A; Tue, 22 Sep 2015 14:46:33 +0200 (MEST) To: Robert Sparks , General Area Review Team , draft-ietf-conex-destopt@ietf.org, conex@ietf.org References: <55DE1F65.5070106@nostrum.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <56014D94.9070002@tik.ee.ethz.ch> Date: Tue, 22 Sep 2015 14:46:12 +0200 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: <55DE1F65.5070106@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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: Tue, 22 Sep 2015 12:46:47 -0000 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. 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#). 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. 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? 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? > > 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. > -- ------------------------------------------ Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63 26932 email: mirja.kuehlewind@tik.ee.ethz.ch ------------------------------------------ From nobody Wed Sep 23 07:08: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 7EAE21A1BED; Wed, 23 Sep 2015 07:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 DaebF8a_rhbY; Wed, 23 Sep 2015 07:08:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 272B21A1EF3; Wed, 23 Sep 2015 07:08:26 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150923140826.16277.10734.idtracker@ietfa.amsl.com> Date: Wed, 23 Sep 2015 07:08:26 -0700 Archived-At: Cc: conex mailing list , conex chair , RFC Editor Subject: [conex] Document Action: 'Congestion Exposure (ConEx) Concepts, Abstract Mechanism and Requirements' to Informational RFC (draft-ietf-conex-abstract-mech-13.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: Wed, 23 Sep 2015 14:08:34 -0000 The IESG has approved the following document: - 'Congestion Exposure (ConEx) Concepts, Abstract Mechanism and Requirements' (draft-ietf-conex-abstract-mech-13.txt) as Informational RFC This document is the product of the Congestion Exposure Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-abstract-mech/ Technical Summary This document describes an abstract mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by ECN markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called congestion exposure or ConEx. The companion document "ConEx Concepts and Use Cases" provides the entry-point to the set of ConEx documentation. Working Group Summary There were no special issues worth noting during the WG process. Document Quality The document received several thorough reviews. It is worth noting the reviews from Mirja Kuehlewind and David Wagner. Personnel Marcelo Bagnulo (marcelo@it.uc3m.es) is the document shepherd. Martin Stiemerling (mls.ietf@gmail.com) is the responsible Area Director. From nobody Mon Sep 28 12:37:47 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 5A7B01B2C19; Mon, 28 Sep 2015 12:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZlaQh01ZEoDH; Mon, 28 Sep 2015 12:37:43 -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 C11CB1B2C15; Mon, 28 Sep 2015 12:37:43 -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 t8SJbfqp013723 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 28 Sep 2015 14:37:42 -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: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , General Area Review Team , draft-ietf-conex-destopt@ietf.org, conex@ietf.org References: <55DE1F65.5070106@nostrum.com> <56014D94.9070002@tik.ee.ethz.ch> From: Robert Sparks Message-ID: <56099700.6050004@nostrum.com> Date: Mon, 28 Sep 2015 14:37:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56014D94.9070002@tik.ee.ethz.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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: Mon, 28 Sep 2015 19:37:45 -0000 On 9/22/15 7:46 AM, Mirja Kühlewind 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?") > 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. > > 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. > > 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? >> >> 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. >> > From nobody Wed Sep 30 06:09: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 73A1D1A702A; Wed, 30 Sep 2015 06:09:31 -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 G5HHTZUcWvNM; Wed, 30 Sep 2015 06:09:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 551581A7015; Wed, 30 Sep 2015 06:09:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150930130930.15603.87942.idtracker@ietfa.amsl.com> Date: Wed, 30 Sep 2015 06:09:30 -0700 Archived-At: Cc: draft-ietf-conex-destopt.ad@ietf.org, conex-chairs@ietf.org, conex@ietf.org, draft-ietf-conex-destopt@ietf.org Subject: [conex] Brian Haberman's Discuss on draft-ietf-conex-destopt-09: (with DISCUSS and 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: Wed, 30 Sep 2015 13:09:31 -0000 Brian Haberman has entered the following ballot position for draft-ietf-conex-destopt-09: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support the publication of this document given the need for experimentation in this area. However, there is one point that I would like to discuss... Section 3 contains R-1 which says that this marking "needs to be visible to all ConEx-capable nodes on the path." Additionally, Section 5 says that the choice of using an IPv6 Destination Option precludes non-ConEx-capable devices from having to deal with the extension header. However, RFC 2460 clearly says that Destination Options are not inspected by intermediate devices. We all know that a variety of intermediate devices ignore the rule in 2460. Given that, I would like this document to explicitly state that it does not abide by the rule in 2460 so that implementations that do follow 2460 but want to support this approach know to update all their extension header processing code. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Why does the word "foo" appear in the middle of Section 4? * Do you want the Option Type description in Section 4 to have a value = TBD construct so that the IANA-assigned value can be inserted? From nobody Wed Sep 30 15:19: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 D142C1A92B1; Wed, 30 Sep 2015 15:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] 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 91dKRuLZnPxg; Wed, 30 Sep 2015 15:19:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAB81A902B; Wed, 30 Sep 2015 15:19:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150930221934.1004.61285.idtracker@ietfa.amsl.com> Date: Wed, 30 Sep 2015 15:19:34 -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] Alissa Cooper'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: Wed, 30 Sep 2015 22:19:36 -0000 Alissa Cooper 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: ---------------------------------------------------------------------- Section 3.1.1: s/a ConEx MAY also chose to not componsate/a ConEx sender MAY also chose not to compensate/ Section 4.2: s/To maintain half of the packet in flight/To maintain half of the packets in flight/ From nobody Wed Sep 30 16:20:03 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 4DB501ACC8D; Wed, 30 Sep 2015 16:20:01 -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 Vwp0FyoEmCIM; Wed, 30 Sep 2015 16:19:59 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C9C1ACC8C; Wed, 30 Sep 2015 16:19:56 -0700 (PDT) X-AuditID: c618062d-f79ef6d000007f54-34-560c0e928e5f Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EC.77.32596.29E0C065; Wed, 30 Sep 2015 18:32:18 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 19:19:55 -0400 From: Suresh Krishnan To: Brian Haberman , The IESG Thread-Topic: Brian Haberman's Discuss on draft-ietf-conex-destopt-09: (with DISCUSS and COMMENT) Thread-Index: AQHQ+4FB4tQNUvzqqEOgswG8zQ11rA== Date: Wed, 30 Sep 2015 23:19:53 +0000 Message-ID: References: <20150930130930.15603.87942.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXRPiO4kPp4wg90v5C1m9vxjtDj38DKT xaFrPxktHj5Kt3h/6gu7RffqX+wWM/5MZHZg91iy5CeTx8zjX1g8Zhx7yR7AHMVlk5Kak1mW WqRvl8CVsfsCS8Fm6YpF/34wNjCeFeti5OSQEDCR+HbxOBOELSZx4d56ti5GLg4hgaOMEk3N HSwQznJGidlLmllBqtiAOjbs/AzWISLgLvHi02RGkCJmgflMEkf/XWYGSQgLJEk87J3NDFGU LHHl7ic2CFtPYtX1lewgNouAqsSZXRuAajg4eAV8JY5OzgcJCwk4SrxfvpMFxGYEuuj7qTVg u5gFxCVuPZkPdamAxJI955khbFGJl4//sULYShJzXl9jhqjXkViwG2Its4C2xLKFr8HivAKC EidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypGjtLi1LLcdCODTYzAODomwaa7g3HPS8tDjAIc jEo8vAsucoUJsSaWFVfmHmKU5mBREufdv+R+qJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG VrVsg91Wp230JqdVbTn8r4rlb9bh4vX13s7CyUElgc9mLv2yv3/TZWEu/XWH6/ZMkL3EKdhu f05q9r5exhvJoTY6sSkf7CcnZWckff5tmTHv9+XW6u352tExcq5mbWJ1UvmvE6N4Vd1tko4+ DDW8ecTzoOLXmcf7WMy2HZ2y2jlk5gnv23eVWIozEg21mIuKEwFcsNCAhAIAAA== Archived-At: Cc: "draft-ietf-conex-destopt.ad@ietf.org" , "conex-chairs@ietf.org" , "conex@ietf.org" , "draft-ietf-conex-destopt@ietf.org" Subject: Re: [conex] Brian Haberman's Discuss on draft-ietf-conex-destopt-09: (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: Wed, 30 Sep 2015 23:20:01 -0000 Hi Brian,=0A= Thanks for your comments. Please see responses inline.=0A= =0A= On 09/30/2015 09:09 AM, Brian Haberman wrote:=0A= > Brian Haberman has entered the following ballot position for=0A= > draft-ietf-conex-destopt-09: Discuss=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.html= =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= > DISCUSS:=0A= > ----------------------------------------------------------------------=0A= >=0A= > I support the publication of this document given the need for=0A= > experimentation in this area. However, there is one point that I would=0A= > like to discuss...=0A= >=0A= > Section 3 contains R-1 which says that this marking "needs to be visible= =0A= > to all ConEx-capable nodes on the path." Additionally, Section 5 says=0A= > that the choice of using an IPv6 Destination Option precludes=0A= > non-ConEx-capable devices from having to deal with the extension header.= =0A= > However, RFC 2460 clearly says that Destination Options are not inspected= =0A= > by intermediate devices. We all know that a variety of intermediate=0A= > devices ignore the rule in 2460. Given that, I would like this document= =0A= > to explicitly state that it does not abide by the rule in 2460 so that=0A= > implementations that do follow 2460 but want to support this approach=0A= > know to update all their extension header processing code.=0A= =0A= Makes perfect sense. Will this additional text at the end of Section 3 work= ?=0A= =0A= NEW:=0A= Please note that the IPv6 specification [RFC2460] does not require or =0A= expect intermediate nodes to inspect destination options such as the =0A= ConEx destination option. This implies that ConEx-aware intermediate =0A= nodes following this specification will need updated extension header =0A= processing code to be able read the destination options.=0A= =0A= >=0A= >=0A= > ----------------------------------------------------------------------=0A= > COMMENT:=0A= > ----------------------------------------------------------------------=0A= >=0A= > * Why does the word "foo" appear in the middle of Section 4?=0A= =0A= There was some issue with submitting the XML source into the ID =0A= submission tool instead of the text document that resulted in the loss =0A= of formatting as well as this text appearing between -08 and -09. Will =0A= remove in new version.=0A= =0A= >=0A= > * Do you want the Option Type description in Section 4 to have a value = =3D=0A= > TBD construct so that the IANA-assigned value can be inserted?=0A= =0A= Sounds good. Replaced the value with TBA1 as described in the IANA =0A= considerations.=0A= =0A= OLD:=0A= =0A= 8-bit identifier of the type of option. The option identifier=0A= for the ConEx destination option will be allocated by the IANA.=0A= =0A= NEW:=0A= =0A= 8-bit identifier of the type of option. Set to the value TBA1.=0A= =0A= Thanks=0A= Suresh=0A= =0A= From nobody Wed Sep 30 16:29:43 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 7B3131ACD03; Wed, 30 Sep 2015 16:29:41 -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 WCkvMIphufDN; Wed, 30 Sep 2015 16:29:39 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7CE81ACD02; Wed, 30 Sep 2015 16:29:38 -0700 (PDT) X-AuditID: c618062d-f79ef6d000007f54-4a-560c10d73377 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BC.C7.32596.7D01C065; Wed, 30 Sep 2015 18:41:59 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 19:29:35 -0400 From: Suresh Krishnan To: Ben Campbell , The IESG Thread-Topic: Ben Campbell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT) Thread-Index: AQHQ+5aS0gLdTHh1tU+4uZD2vaud+w== Date: Wed, 30 Sep 2015 23:29:34 +0000 Message-ID: References: <20150930154206.2672.6582.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXRPlO51AZ4wgx0rpSzmd55mtzj38DKT xaFrPxktHj5Kt3h/6gu7RffqX+wWM/5MZHZg91iy5CeTx4xjL9k9Zu18whLAHMVlk5Kak1mW WqRvl8CVcffKB/aCpVwVmy4fYW5gvMrRxcjJISFgInH5wUlmCFtM4sK99WxdjFwcQgJHGSXe PjjCCJIQEljOKNH2UwLEZgNq2LDzMxOILSJgI7H84EuwBmaB+UwSR/9dBpskLBAp0Tz1DBtE UZTEna4OqAY9idlv2tlBbBYBVYnOY3NZQWxeAV+JrwuvskIss5do79zAAmIzAl30/dQasF5m AXGJW0/mM0FcKiCxZM95qKtFJV4+/scKYStJzHl9jRmiXkdiwe5PbBC2tsSyha+ZIXYJSpyc +YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYOUqLU8ty040MNjECI+mYBJvuDsY9Ly0PMQpwMCrx 8C64yBUmxJpYVlyZe4hRmoNFSZx3/5L7oUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYeaav uK7p28W+Yu7M74qXHFvEphYGS06ePkNbbYHxv56Mnm0qLmd2ZwbnLj8Zy7Qs+5yW69U9b9sl J2XFHqqOurFW/m0o07NtiW8eyuxbdtJP9VrIcmdT3i1JUxrmC1w61Lpo7S8Tloi39mtOTNwq 9fPyqkV3npw+/ripWJLfJTWh7cWuyVuOJSuxFGckGmoxFxUnAgDU6x3ShQIAAA== Archived-At: Cc: "draft-ietf-conex-destopt.ad@ietf.org" , "conex-chairs@ietf.org" , "conex@ietf.org" , "draft-ietf-conex-destopt@ietf.org" Subject: Re: [conex] Ben Campbell'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: Wed, 30 Sep 2015 23:29:41 -0000 Hi Ben,=0A= Thanks a lot for your comment. I will clean up the unused references =0A= when I submit a new revision. Some of them may end up being required =0A= depending on how we end up addressing Kathleen's DISCUSS.=0A= =0A= Cheers=0A= Suresh=0A= =0A= On 09/30/2015 11:42 AM, Ben Campbell wrote:=0A= > Ben Campbell 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.html= =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= > Thanks for including the paragraphs on the purpose of the experiment!=0A= >=0A= > IDNits mentions some unused references.=0A= >=0A= >=0A= >=0A= =0A= From nobody Wed Sep 30 16:41: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 8E5EF1ACD04; Wed, 30 Sep 2015 16:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 j7-rlgpQ2GJ0; Wed, 30 Sep 2015 16:41:50 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9BA1ACD15; Wed, 30 Sep 2015 16:41:50 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D78508816D; Wed, 30 Sep 2015 16:41:49 -0700 (PDT) Received: from [192.168.1.8] (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id AE1B3328081A; Wed, 30 Sep 2015 16:41:49 -0700 (PDT) References: <20150930130930.15603.87942.idtracker@ietfa.amsl.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0BD5F0DE-4C37-4DE5-B174-13B5A7AEE87B@innovationslab.net> X-Mailer: iPad Mail (13A404) From: Brian Haberman Date: Wed, 30 Sep 2015 19:41:47 -0400 To: Suresh Krishnan Archived-At: Cc: "draft-ietf-conex-destopt.ad@ietf.org" , The IESG , "conex@ietf.org" , "conex-chairs@ietf.org" , "draft-ietf-conex-destopt@ietf.org" Subject: Re: [conex] Brian Haberman's Discuss on draft-ietf-conex-destopt-09: (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: Wed, 30 Sep 2015 23:41:51 -0000 Suresh, Looks good to me. Brian > On Sep 30, 2015, at 7:19 PM, Suresh Krishnan wrote: >=20 > Hi Brian, > Thanks for your comments. Please see responses inline. >=20 >> On 09/30/2015 09:09 AM, Brian Haberman wrote: >> Brian Haberman has entered the following ballot position for >> draft-ietf-conex-destopt-09: Discuss >>=20 >> 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.) >>=20 >>=20 >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html= >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> I support the publication of this document given the need for >> experimentation in this area. However, there is one point that I would >> like to discuss... >>=20 >> Section 3 contains R-1 which says that this marking "needs to be visible >> to all ConEx-capable nodes on the path." Additionally, Section 5 says >> that the choice of using an IPv6 Destination Option precludes >> non-ConEx-capable devices from having to deal with the extension header. >> However, RFC 2460 clearly says that Destination Options are not inspected= >> by intermediate devices. We all know that a variety of intermediate >> devices ignore the rule in 2460. Given that, I would like this document >> to explicitly state that it does not abide by the rule in 2460 so that >> implementations that do follow 2460 but want to support this approach >> know to update all their extension header processing code. >=20 > Makes perfect sense. Will this additional text at the end of Section 3 wor= k? >=20 > NEW: > Please note that the IPv6 specification [RFC2460] does not require or=20 > expect intermediate nodes to inspect destination options such as the=20 > ConEx destination option. This implies that ConEx-aware intermediate=20 > nodes following this specification will need updated extension header=20 > processing code to be able read the destination options. >=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> * Why does the word "foo" appear in the middle of Section 4? >=20 > There was some issue with submitting the XML source into the ID=20 > submission tool instead of the text document that resulted in the loss=20 > of formatting as well as this text appearing between -08 and -09. Will=20 > remove in new version. >=20 >>=20 >> * Do you want the Option Type description in Section 4 to have a value =3D= >> TBD construct so that the IANA-assigned value can be inserted? >=20 > Sounds good. Replaced the value with TBA1 as described in the IANA=20 > considerations. >=20 > OLD: >=20 > 8-bit identifier of the type of option. The option identifier > for the ConEx destination option will be allocated by the IANA. >=20 > NEW: >=20 > 8-bit identifier of the type of option. Set to the value TBA1. >=20 > Thanks > Suresh >=20 From nobody Wed Sep 30 17:06:58 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 ED7DD1AC405; Wed, 30 Sep 2015 17:06:56 -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 dFgrr3BJAx1v; Wed, 30 Sep 2015 17:06:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6145A1ACD53; Wed, 30 Sep 2015 17:06:55 -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: <20151001000655.11590.32411.idtracker@ietfa.amsl.com> Date: Wed, 30 Sep 2015 17:06:55 -0700 Archived-At: Cc: draft-ietf-conex-destopt.ad@ietf.org, conex-chairs@ietf.org, conex@ietf.org, draft-ietf-conex-destopt@ietf.org Subject: [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 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 00:06:57 -0000 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. - 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 From nobody Wed Sep 30 18:41:59 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 9406B1ACE2D; Wed, 30 Sep 2015 18:41:57 -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 2AkM5T8EOuUA; Wed, 30 Sep 2015 18:41:55 -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 3CECD1ACE2C; Wed, 30 Sep 2015 18:41:55 -0700 (PDT) X-AuditID: c6180641-f792c6d00000686a-98-560c23b782e6 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 97.D8.26730.7B32C065; Wed, 30 Sep 2015 20:02:31 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 21:41:53 -0400 From: Suresh Krishnan To: Kathleen Moriarty , The IESG Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-conex-destopt-09: (with DISCUSS and COMMENT) Thread-Index: AQHQ+7Vq9thQLxuvy0KgOa4wEJ46Lg== Date: Thu, 1 Oct 2015 01:41:53 +0000 Message-ID: References: <20150930192253.28856.7833.idtracker@ietfa.amsl.com> 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+NgFnrPLMWRmVeSWpSXmKPExsUyuXSPt+52ZZ4wg0l3zCzOPbzMZHHo2k9G i4eP0i3en/rCbtG9+he7xYw/E5ktGnbmO7B77Jx1l91jyZKfTB4zjr1kD2CO4rJJSc3JLEst 0rdL4Mo4NOE0Y8ESjYrt59QbGDcqdjFycEgImEisX6bcxcgJZIpJXLi3nq2LkYtDSOAoo8SL G6/YQBJCAssZJSbPlAKx2YDqN+z8zARiiwiESDz8PIUFpIFZYD6TxNF/l5lBEsICqRIH7p5m hChKk5h0/iRUg57E8s5jYENZBFQkPu/tBrN5BXwlDn+cwQixzEHi8OmLLCA2I9BF30+tAetl FhCXuPVkPhPEpQISS/acZ4awRSVePv7HCmErSXz8PZ8dol5HYsHuT2wQtrbEsoWvmSF2CUqc nPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDcxAmPomASb4w7GBZ8sDzEKcDAq 8fAqAGNLiDWxrLgy9xCjNAeLkjjvvBn3Q4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwavsW zPmUOe1KxqFFjJz9vW9ZrziVntvP0fL0sfH8SQGzJlb2/AgQ5dJieqX/foHa+v53F1gdou5p 5D21++l5zSnjivTFqPJLa3/pfHUwZkv+NUGm8eMtLSElf6ddIU76YR+7Zi73fqPFN9XvsSL7 SaGbX983zTGYILtgy8GCHR33tz7f636bUYmlOCPRUIu5qDgRALVjuO+CAgAA Archived-At: Cc: "draft-ietf-conex-destopt.ad@ietf.org" , "conex-chairs@ietf.org" , "conex@ietf.org" , "draft-ietf-conex-destopt@ietf.org" Subject: Re: [conex] Kathleen Moriarty's Discuss on draft-ietf-conex-destopt-09: (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 01:41:57 -0000 Hi Kathleen,=0A= Thanks a lot for your comments. Please find responses inline.=0A= =0A= =0A= On 09/30/2015 03:22 PM, Kathleen Moriarty wrote:=0A= > Kathleen Moriarty has entered the following ballot position for=0A= > draft-ietf-conex-destopt-09: Discuss=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.html= =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= > DISCUSS:=0A= > ----------------------------------------------------------------------=0A= >=0A= > I think this should be easy to address, but wanted to discuss options for= =0A= > the text in section 7. Since there is text that says IPsec=0A= > Authentication should be used when integrity protection and the section= =0A= > goes on to also discuss encryption, shouldn't there be a similar=0A= > statement that says IPsec encryption should be used when there is a need= =0A= > to protect confidentiality?=0A= =0A= Yes. We were worried more about the authentication because tampering of =0A= the packet to scrub the markings would cause audit devices to penalize =0A= the connection. Encryption on the other hand would be counterproductive =0A= as the intermediate nodes would be unable to observe the markings.=0A= =0A= >=0A= > Also, in reading this, I think because of the selected wording, I was=0A= > thinking that it wasn't clear enough on the need/recommendation for=0A= > authentication or encryption with IPsec since there are options for both= =0A= > to be set to NULL/none. You can have a NULL cipher-suite and you can=0A= > also have authentication set to none to allow for opportunistic security= =0A= > negotiations (fairly new RFC for the latter). There's no need to mention= =0A= > these options explicitly, but rather to make it clear that IPsec can be= =0A= > used to provide authentication and encryption. So I think one additional= =0A= > sentence and some possible rewording in this section would be helpful.=0A= =0A= I have added a new sentence about encryption and reworded some of the =0A= text to clarify. Does this text change work for you?=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. If an=0A= 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= In IPv6 a Destination Option header can be placed in two possible=0A= position in the order of possible headers, either before the Routing=0A= header or after the Encapsulating Security Payload (ESP) header=0A= [RFC2460]. As the CDO is placed in the destination option header=0A= before the AH and/or ESP, it is not encrypted in transport mode=0A= [RFC4301]. Otherwise, if the CDO were placed in the latter position=0A= and an ESP header were used, the CDO would also be encrypted and=0A= could not be interpreted by ConEx-aware devices.=0A= =0A= NEW:=0A= =0A= If the transport network cannot be trusted, the IPsec Authentication =0A= Header (AH) [RFC4302] should be used to ensure integrity of the ConEx =0A= information. If an attacker would be able to remove the ConEx marks, =0A= this could cause an audit device to penalize the respective connection, =0A= while the sender cannot easily detect that ConEx information is missing. = =0A= Similarly, if confidentiality of the transmitted information is desired, = =0A= the IPsec Encapsulating Security Payload (ESP) [RFC4303] should be used.=0A= =0A= Inside an IPv6 packet, a Destination Option header can be placed in two =0A= possible positions, either before the Routing header or after the ESP/AH = =0A= headers as described in Section 4.1 of [RFC2460]. When the CDO is =0A= placed in the destination option header before the AH and/or ESP, it is =0A= not encrypted in transport mode [RFC4301]. Otherwise, if the CDO were =0A= placed in the latter position and an ESP header was used with =0A= encryption, the CDO cannot be viewed and interpreted by ConEx-aware =0A= intermediate nodes effectively rendering it useless.=0A= =0A= >=0A= >=0A= > ----------------------------------------------------------------------=0A= > COMMENT:=0A= > ----------------------------------------------------------------------=0A= >=0A= > For the Security Considerations section, I'd just ask that you add in=0A= > "IPsec" when AH and ESP are first mentioned so this is clear.=0A= =0A= Does the above wording change work to resolve this as well?=0A= =0A= Cheers=0A= Suresh=0A= =0A= From nobody Wed Sep 30 20:52: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 B43AF1AD084; Wed, 30 Sep 2015 20:52:30 -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 clzdUpcOjiy7; Wed, 30 Sep 2015 20:52:29 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9A81AD080; Wed, 30 Sep 2015 20:52:28 -0700 (PDT) X-AuditID: c618062d-f79ef6d000007f54-21-560c4e70200e Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 78.6C.32596.07E4C065; Wed, 30 Sep 2015 23:04:48 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 23:52: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: Thu, 1 Oct 2015 03:52:26 +0000 Message-ID: References: <20151001000655.11590.32411.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXSPt26BH0+Ywdud4hbnHl5msjh07Sej xcNH6RbvT31ht+he/YvdYsaficwW0/deY3dg91jbfZXNY8mSn0weM469ZA9gjuKySUnNySxL LdK3S+DKWPitg7HgkFhFz5OdLA2MJ4S6GDk5JARMJPbcm8oGYYtJXLi3Hsjm4hASOMoo8fJP GyuEs5xRYu+TfnaQKjagjg07PzOB2CICnhIP+06xgBQxC8xnkjj67zIzSEJYIEaiaUErI0RR rMS1YwehGvQk5k3cDWazCKhI7N2/lRXE5hXwlfh94gELiC0k4Chx4fJOsDgj0EnfT60Bq2cW EJe49WQ+E8SpAhJL9pxnhrBFJV4+/scKYStJzHl9jRmiXkdiwe5PbBC2tsSyha+ZIXYJSpyc +YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYOUqLU8ty040MNjECY+mYBJvuDsY9Ly0PMQpwMCrx 8Coo84QJsSaWFVfmHmKU5mBREufdv+R+qJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGZMkl 8bPv1oSZr1plfuOvf2KqkGIb85kXT1fqX58XPeHFdCOGP+rJgnwWf5kMMo5fYl86pe6r4i+m uuWVj2MV16Zcvxc1jV9j5uGI7PWHND8pVvYXSujvaZK/esQ9OOdlkt6J8tATgnY5n0U6GQ3q rKu6OTRkFh41+nngvEWIcUwZj+XC6/uVWIozEg21mIuKEwH7cu14hgIAAA== Archived-At: Cc: "draft-ietf-conex-destopt.ad@ietf.org" , "conex-chairs@ietf.org" , "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 03:52:30 -0000 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.html= =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. 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= >=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/msg05957.htm= l=0A= =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 check = =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 protocols=0A= that use this option and how those protocols can protect themselves=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= From nobody Wed Sep 30 22:32: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 7FB4A1B29DC; Wed, 30 Sep 2015 22:32:15 -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 CjO6AN3_X0rS; Wed, 30 Sep 2015 22:32:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B32E1B29D4; Wed, 30 Sep 2015 22:32:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151001053214.2021.10816.idtracker@ietfa.amsl.com> Date: Wed, 30 Sep 2015 22:32:14 -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] Barry Leiba'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 05:32:15 -0000 Barry Leiba 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: ---------------------------------------------------------------------- Section 7 is nice -- thanks for the detail.