Re: [secdir] Secdir review of draft-ietf-conex-tcp-modifications-09
"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Wed, 26 August 2015 10:36 UTC
Return-Path: <takeshi_takahashi@nict.go.jp>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7C51AD352; Wed, 26 Aug 2015 03:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.898
X-Spam-Level:
X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, 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 V8VWLf3WEg1y; Wed, 26 Aug 2015 03:36:00 -0700 (PDT)
Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id B163A1AD34E; Wed, 26 Aug 2015 03:36:00 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id t7QAZxX1016706; Wed, 26 Aug 2015 19:35:59 +0900 (JST)
Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id t7QAZxN9016694; Wed, 26 Aug 2015 19:35:59 +0900 (JST)
Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 6B4112CAC3; Wed, 26 Aug 2015 19:35:59 +0900 (JST)
Received: from VAIO (unknown [133.243.119.37]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 6015D2C6CE; Wed, 26 Aug 2015 19:35:59 +0900 (JST)
From: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
To: 'Mirja Kühlewind' <mirja.kuehlewind@tik.ee.ethz.ch>, draft-ietf-conex-tcp-modifications.all@tools.ietf.org
References: <011701d0dfac$0b38b8a0$21aa29e0$@nict.go.jp> <55DD8BBB.6070808@tik.ee.ethz.ch>
In-Reply-To: <55DD8BBB.6070808@tik.ee.ethz.ch>
Date: Wed, 26 Aug 2015 19:35:59 +0900
Message-ID: <001601d0dfea$ff363bb0$fda2b310$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJjv2QT+kxOYWm7dC09WicUulEe4QFFLORNnO4nU1A=
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.98.7 at zenith1
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/XOGWVg9pPz6URlQKchINN097Rrw>
Cc: conex-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-conex-tcp-modifications-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Aug 2015 10:36:03 -0000
Hi Mirja, > > I can understand that "the sender can choose to mark inaccurately, > > which will only increase the likelihood of loss at an audit function." > > Then, would it be the "sender" who will harm itself? > > Why do you say that "the receiver will only harm itself"? > > > > What we wanted to say here is that if the receiver does not provide accurate > feedback, by supporting SACK, ECN or AccECN, the sender has to estimate the > congestion level. In this case it's the sender's choice to make a very > conservative estimation by sending most likely too much or risking to get audit > losses by potentially understating. Therefore by not providing sufficient > feedback (based on SACK or ECN/AccECn), even if the receiver would be able > to do so, the receiver can only hurt itself. > > But you are right, I also had to rewrite it twice now, so I'll rephrase this > to make it more clear. > > > I think "mark inaccurately" in this case means that the sender marks > > less than actual congestion states. > > yes, but remember the sender might not have sufficient feedback to actually > know the exact congestion state and therefore has to estimate it. This can > be done conservatively with will usually send too much marks (where the sender > might have to pay for in some way)... or the sender might risk to send not > enough marks which can cause additional loss. I got it. (Until I read your email, I thought you were talking about a malicious sender who intentionally marks inaccurately.) This makes sense to me. > > Does this understanding correct? > > Or, if the sender marks more than actual congestion states, does that > > also increase the likelihood of loss at an audit function? > > No. > > > > > Questions2: on man-in-the middle attacks. > > > > Is it better to address the cases of TCP session hijacks? > > I don't think there is an additional risk of actual hijacking (compared to > TCP without ConEx). > As ConEx does neither improve nor worsen this, it's not discussed. I agree. I thought you wanted to mention this in the section, though it is totally up to you and I do not stick to that at all. Indeed, you clearly mentioned that ConEx specific security issues are considered in the other draft. (Likewise, I thought you also wanted to mention that TCP-specific security issues are still issues here.) I do not have any further comments. This was a fun to read the draft. Thank you for the work. Kind regards, Take > -----Original Message----- > From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch] > Sent: Wednesday, August 26, 2015 6:50 PM > To: Takeshi Takahashi; > draft-ietf-conex-tcp-modifications.all@tools.ietf.org > Cc: iesg@ietf.org; secdir@ietf.org; conex-chairs@tools.ietf.org > Subject: Re: Secdir review of draft-ietf-conex-tcp-modifications-09 > > Hi Take, > > thanks for you feedback! > > See below. > > Mirja > > On 26.08.2015 05:05, Takeshi Takahashi wrote: > > Hello, > > > > 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 written primarily for the benefit of the security > > area directors. > > Document editors and WG chairs should treat these comments just like > > any other last call comments. > > > > This document is almost ready, but I have a couple of clarification > > questions. > > > > [summary of this document] > > > > This document is an experimental draft, which talks about the > > modifications needed to use ConEx with TCP. > > Depending on the status of receivers' protocol support, the accuracy > > of the congestion control we can take may differ. > > Indeed, the receiver may or may not supports SACK, ECN, or accECN. > > This document thus considers assorted cases of receivers' protocol > > support status and provides the solution (or guideline) to use ConEx with > TCP. > > > > [clarification question] > > > > My comment focuses on Section 10 "Security Considerations". > > I am not familiar with ConEx (though I have read the related drafts in > > these days), so allow me to ask basic questions. > > > > Question 1: on the last two sentences in the second paragraph: " > > Instead the sender can choose to mark inaccurately, which will only > > increase the likelihood of loss at an audit function. Thus the > > receiver will only harm itself. " > > > > I can understand that "the sender can choose to mark inaccurately, > > which will only increase the likelihood of loss at an audit function." > > Then, would it be the "sender" who will harm itself? > > Why do you say that "the receiver will only harm itself"? > > > > What we wanted to say here is that if the receiver does not provide accurate > feedback, by supporting SACK, ECN or AccECN, the sender has to estimate the > congestion level. In this case it's the sender's choice to make a very > conservative estimation by sending most likely too much or risking to get audit > losses by potentially understating. Therefore by not providing sufficient > feedback (based on SACK or ECN/AccECn), even if the receiver would be able > to do so, the receiver can only hurt itself. > > But you are right, I also had to rewrite it twice now, so I'll rephrase this > to make it more clear. > > > I think "mark inaccurately" in this case means that the sender marks > > less than actual congestion states. > > yes, but remember the sender might not have sufficient feedback to actually > know the exact congestion state and therefore has to estimate it. This can > be done conservatively with will usually send too much marks (where the sender > might have to pay for in some way)... or the sender might risk to send not > enough marks which can cause additional loss. > > > Does this understanding correct? > > Or, if the sender marks more than actual congestion states, does that > > also increase the likelihood of loss at an audit function? > > No. > > > > > Questions2: on man-in-the middle attacks. > > > > Is it better to address the cases of TCP session hijacks? > > I don't think there is an additional risk of actual hijacking (compared to > TCP without ConEx). > As ConEx does neither improve nor worsen this, it's not discussed. Or what > exactly do you mean by 'hijacks'? > > > Or should I think that this issue is covered by the sentence "General > > Conex security considerations are covered extensively in the ConEx > > abstract mechanism"? > > Yes, the abstract mechanisms draft lists two potential attacks by the network, > see page 25 ("Attacks by networks on other networks"): > > https://tools.ietf.org/html/draft-ietf-conex-abstract-mech-13#section-8 > > Similar as described for the receiver in the TCP mods doc, the network could > also overstate congestion and cause the sender to send 'unnecessary' marks > and slow down. But in this case it's really not clear what unnecessary means, > as it is the networks task to signal congestion... and if the congestion was > signaled by the network and seen by the audit, the sender has to send the > respective amount of marks, so it effectively not unnecessary any more. I don't > think this case makes sense to discuss any further. Is that okay for you? > > > > > > Thank you. > > > > Take > >
- [secdir] Secdir review of draft-ietf-conex-tcp-mo… Takeshi Takahashi
- Re: [secdir] Secdir review of draft-ietf-conex-tc… Mirja Kühlewind
- Re: [secdir] Secdir review of draft-ietf-conex-tc… Takeshi Takahashi