[secdir] Secdir review of draft-ietf-conex-tcp-modifications-09

"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Wed, 26 August 2015 03:05 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 45EAA1A8A9D; Tue, 25 Aug 2015 20:05:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.298
X-Spam-Level: ***
X-Spam-Status: No, score=3.298 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8xnHwk9ox0dg; Tue, 25 Aug 2015 20:05:18 -0700 (PDT)
Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id B09AC1A8A6C; Tue, 25 Aug 2015 20:05:17 -0700 (PDT)
Received: from gw2.nict.go.jp (gw2.nict.go.jp []) by ns2.nict.go.jp with ESMTP id t7Q35FnO043355; Wed, 26 Aug 2015 12:05:15 +0900 (JST)
Received: from TakeVaioVJP13 (ssh1.nict.go.jp []) by gw2.nict.go.jp with ESMTP id t7Q35FVn042967; Wed, 26 Aug 2015 12:05:15 +0900 (JST)
From: "Takeshi Takahashi" <takeshi_takahashi@nict.go.jp>
To: <draft-ietf-conex-tcp-modifications.all@tools.ietf.org>
Date: Wed, 26 Aug 2015 12:05:20 +0900
Message-ID: <011701d0dfac$0b38b8a0$21aa29e0$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdDfq9eExC5yeHr0RsiCr88Q9w6+1Q==
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.98.7 at zenith2
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/pGxAUb9qvZhiW6kPFMrdlUjiNgQ>
Cc: conex-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: [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 03:05:19 -0000


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
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

[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"?

I think "mark inaccurately" in this case means that the sender marks less
than actual congestion states.
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?

Questions2: on man-in-the middle attacks.

Is it better to address the cases of TCP session hijacks?
Or should I think that this issue is covered by the sentence "General Conex
security considerations are covered extensively in the ConEx abstract

Thank you.