Re: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Wed, 20 August 2014 04:16 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477481A86FD; Tue, 19 Aug 2014 21:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.563
X-Spam-Level:
X-Spam-Status: No, score=0.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 xAEHCpLFwGql; Tue, 19 Aug 2014 21:16:52 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647991A86F8; Tue, 19 Aug 2014 21:16:52 -0700 (PDT)
Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 20F9B278122; Wed, 20 Aug 2014 13:16:49 +0900 (JST)
Received: by mail-la0-f43.google.com with SMTP id gi9so4169622lab.2 for <multiple recipients>; Tue, 19 Aug 2014 21:16:47 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.52.130 with SMTP id t2mr23057091lbo.61.1408508207307; Tue, 19 Aug 2014 21:16:47 -0700 (PDT)
Received: by 10.114.160.145 with HTTP; Tue, 19 Aug 2014 21:16:47 -0700 (PDT)
In-Reply-To: <CAFggDF2jhQPz0Eez=AU9M-k862wD_=VSyVpXtRAjT4zC6H4tgA@mail.gmail.com>
References: <ecdbe694b6964c159f64b1d3311c8cc6@hioexcmbx02-prd.hq.netapp.com> <CAFggDF2jhQPz0Eez=AU9M-k862wD_=VSyVpXtRAjT4zC6H4tgA@mail.gmail.com>
Date: Tue, 19 Aug 2014 21:16:47 -0700
Message-ID: <CAO249ydGCxd+rxeLbNExdYcKEGT1ChXb8iqsgU5Ea9gtYqS=qg@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: Jacob Appelbaum <jacob@appelbaum.net>
Content-Type: multipart/alternative; boundary="001a11c3f4585c250f050107dfa0"
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/TmhV_2rV_nlDYWvYLlWCoA2ttI8
Cc: "tcpinc@ietf.org" <tcpinc@ietf.org>, "tcpm (tcpm@ietf.org)" <tcpm@ietf.org>, Joe Touch <touch@isi.edu>, Christian Grothoff <christian@grothoff.org>
Subject: Re: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 04:16:54 -0000

Hi Jacob,

I've read the draft. My concern is some middlebox update ISN (due to ISN
randomizations or transparent proxy, etc).
When ISN is modified, I don't know how TCP Stealth server can fall back to
normal TCP.

According to ( http://dl.acm.org/citation.cfm?id=2068834 ), you might run
into ISN modification around over 4%. In case of port 80, you'll see more
modifications, which is over 15%. I'm not very sure if this ratio is too
small to ignore.

Also, I am hesitant to say that this draft is compatible with other
standard RFCs.
Please see RFC6528. Also, It is not compatible what RFC793 mentions on ISN.

Thanks,
--
Yoshi


On Mon, Aug 18, 2014 at 5:50 AM, Jacob Appelbaum <jacob@appelbaum.net>
wrote:

> On 8/15/14, Scheffenegger, Richard <rs@netapp.com> wrote:
> > Hi,
> >
> > I just learned about an individual submission, which is probably of
> interest
> > not only to the members of these two WGs;
> >
> > http://tools.ietf.org/html/draft-kirsch-ietf-tcp-stealth-00
> >
>
> Hi,
>
> I'm one of the authors of the draft and I've cc'ed Christian who has
> been one of the driving forces behind the draft.
>
> >
> > On a first, casual glance, I am wondering if the authors have realized
> all
> > the implications of their suggestion;
> >
>
> This article we wrote may be of interest to you:
>
>
> http://www.heise.de/ct/artikel/NSA-GCHQ-The-HACIENDA-Program-for-Internet-Colonization-2292681.html
> (English)
>
> http://www.heise.de/ct/artikel/NSA-GCHQ-Das-HACIENDA-Programm-zur-Kolonisierung-des-Internet-2292574.html
> (German)
>
> > There seem to be at least two or three major issues that compromise
> either
> > the working and stability of TCP, or work against the intended
> > "stealthieness" of this modification (making it easy for an attacker to
> > identify such sessions, provided he is able to actively interfere with
> > segments in transit (ie. cause certain segments to be dropped).
>
> Could you expand on these thoughts a bit?
>
> > Nevertheless, it might be beneficial to discuss the generic idea in a
> wider
> > forum, among brighter minds than me.
>
> Thanks for bringing it up!
>
> All the best,
> Jacob
>
> _______________________________________________
> Tcpinc mailing list
> Tcpinc@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpinc
>