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

"Scheffenegger, Richard" <rs@netapp.com> Wed, 20 August 2014 12:22 UTC

Return-Path: <rs@netapp.com>
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 69D081A028E; Wed, 20 Aug 2014 05:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.57
X-Spam-Level:
X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, 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 GPfJ0Qxeffy2; Wed, 20 Aug 2014 05:22:37 -0700 (PDT)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E945F1A02FE; Wed, 20 Aug 2014 05:22:36 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.01,901,1400050800"; d="scan'208";a="183058671"
Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx12-out.netapp.com with ESMTP; 20 Aug 2014 05:22:35 -0700
Received: from HIOEXCMBX02-PRD.hq.netapp.com (10.122.105.35) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 20 Aug 2014 05:21:37 -0700
Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 20 Aug 2014 05:21:35 -0700
Received: from HIOEXCMBX05-PRD.hq.netapp.com ([fe80::f0a5:80a1:86de:fa66]) by hioexcmbx05-prd.hq.netapp.com ([fe80::f0a5:80a1:86de:fa66%21]) with mapi id 15.00.0913.011; Wed, 20 Aug 2014 05:21:35 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: Hagen Paul Pfeifer <hagen@jauu.net>
Thread-Topic: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG
Thread-Index: Ac+448Fsl9mI8tJfQO6l37mQPpygtgCOd38AABJQWoAADckrIP//pc+AgAEg4ACAABUIgIAADnKAgAAFl4CAAAkYAIAAAS8A//9okZCAAbQigIAAciXg
Date: Wed, 20 Aug 2014 12:21:35 +0000
Message-ID: <f6dc10652f7b4f3499cef22c25a7aaaf@hioexcmbx05-prd.hq.netapp.com>
References: <ecdbe694b6964c159f64b1d3311c8cc6@hioexcmbx02-prd.hq.netapp.com> <CAFggDF2jhQPz0Eez=AU9M-k862wD_=VSyVpXtRAjT4zC6H4tgA@mail.gmail.com> <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <CAPh34meB=EtgNu=_eBS6ekB20fRccAqXFWydkCWG+6VKSa98rg@mail.gmail.com> <CAFggDF39L+kLQLmiWJR3q6suPOtYmKJiJUqp0kBv7GjUtNVOjA@mail.gmail.com> <CAPh34mdPtKvVJ2FfshPFwrwRDOw9CxxHT4ZTFYZZEVSoKOEq0A@mail.gmail.com> <53F3970D.5080906@grothoff.org> <CAPh34mf2rnNuM=YZ1uin1_PtkB8buOskMtf3NAJMOwdFeMe9MQ@mail.gmail.com> <53F39FAC.9070500@grothoff.org> <817214c2e5b444c7a780c1387e91da15@hioexcmbx05-prd.hq.netapp.com> <CAPh34mf9+c_W+rg4f-wVVrB8yP+ExOvgaJ4cz9cVG1yPT2CHkQ@mail.gmail.com>
In-Reply-To: <CAPh34mf9+c_W+rg4f-wVVrB8yP+ExOvgaJ4cz9cVG1yPT2CHkQ@mail.gmail.com>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.120.60.34]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/zFZ5WDo1plGdToPcPMKEg_xS31k
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 12:22:38 -0000

Hi Hagen,

Actually, the initiator (sender) of a session could roll the dice multiple times (select different ISNs), until the hashed TSopt fulfills the PAWS requirement of being larger than the last TSopt sent in the previous session to that host/port/4-tuple... 

Would require a bit more state within that host, but would be manageable (using the system uptime really always was a kludge IMHO ).


To paraphrase:
TSecr SHOULD be zero on SYN, (even though some implementations didn't adhere to this), and MUST NOT be interpreted when ACK is not set.  

In my opinion, the only reason to not use the TSopt/TSecr combination would be to have this steganographic property to mislead a more advanced adversary that can sniff traffic in between two third parties.



Richard Scheffenegger

> -----Original Message-----
> From: Hagen Paul Pfeifer [mailto:hagen@jauu.net]
> Sent: Mittwoch, 20. August 2014 14:03
> To: Scheffenegger, Richard
> Cc: Christian Grothoff; Jacob Appelbaum; alfiej@fastmail.fm;
> tcpinc@ietf.org; tcpm (tcpm@ietf.org); Joe Touch
> Subject: Re: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG
> 
> On 20 August 2014 13:23, Scheffenegger, Richard <rs@netapp.com> wrote:
> 
> > If you want undetectable knocking, which authenticates a particular
> user, why not transport that hash as TSval (or optionally, the
> unused/empty TSecr; however, that would be detectable to someone with a
> sniffer, as early Win95 is not really that common any more). That would
> leave TCP ISN alone  - and as a true core component, arguing for a
> modification there has to come with very good arguments. Also, it would
> serve to randomize the TSval - as ISN is supposed to be choosen randomly -
> thus help close another indirect exploit vector.
> 
> Sounds better then messing with the ISN. One show stopper still
> exists: the TSval is required to strong monotonicity increasing for PAWS
> protection. To lower the barrier one more time: why not just use TSecr?
> 
> This relax just nearly all headaches and 32 bits are still enough for this
> mechanism?!
> 
> Hagen