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: "=?iso-8859-1?Q?'Mirja_K=FChlewind'?=" <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
> >