From nobody Tue Aug 5 00:11:52 2014 Return-Path: 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 E54A41A0273 for ; Mon, 4 Aug 2014 12:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 P5yGmydeJ0CX for ; Mon, 4 Aug 2014 12:47:09 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 584F41A01F7 for ; Mon, 4 Aug 2014 12:47:09 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id s74JkvQP009952; Mon, 4 Aug 2014 12:46:57 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 51DC6C21517; Mon, 4 Aug 2014 15:46:58 -0400 (EDT) To: RFC Errata System From: Mark Allman In-Reply-To: <20140804174107.B5C6D18000E@rfc-editor.org> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Centerfield X-URL-0: http://www.icir.org/mallman-files/Document75876.jpg X-URL-1: http://www.icir.org/mallman-files/Document75291.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma58159-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 04 Aug 2014 15:46:58 -0400 Sender: mallman@icir.org Message-Id: <20140804194658.51DC6C21517@lawyers.icir.org> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/brJcSeRpKJrri9Fhxk0cqpgB__k X-Mailman-Approved-At: Tue, 05 Aug 2014 00:11:50 -0700 Cc: tcpm@ietf.org, vern@icir.org, eblanton@cs.purdue.edu, mls.ietf@gmail.com, mtaylor@unicoi.com Subject: Re: [tcpm] [Editorial Errata Reported] RFC5681 (4068) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 19:47:11 -0000 ----------ma58159-1 Content-Type: text/plain Content-Disposition: inline I think "new data" is context sensitive in this case. The RFC uses it as the community has used it for a long time. I wouldn't be surprised to find such usage in a fair number of TCP RFCs. That said, I have no problem with the errata. The document could be more precise and if we ever update the document we could certainly take care of this nit. allman ----------ma58159-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPf4zIACgkQWyrrWs4yIs4VtQCfaJWt3GFdrWDOV+BIs7LF/34q AQIAn2WIEUISrkiq9roP19DVCLi3u6nX =ETjf -----END PGP SIGNATURE----- ----------ma58159-1-- From nobody Tue Aug 5 00:12:10 2014 Return-Path: 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 AAA571A0089 for ; Mon, 4 Aug 2014 10:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 ztio_texVRSs for ; Mon, 4 Aug 2014 10:42:31 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4609A1A004D for ; Mon, 4 Aug 2014 10:42:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B5C6D18000E; Mon, 4 Aug 2014 10:41:07 -0700 (PDT) To: mallman@icir.org, vern@icir.org, eblanton@cs.purdue.edu, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, michael.scharf@alcatel-lucent.com, nishida@sfc.wide.ad.jp, pasi.sarolahti@iki.fi X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140804174107.B5C6D18000E@rfc-editor.org> Date: Mon, 4 Aug 2014 10:41:07 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/soYvxTuLSUodn65QcXDJ5MlWV2c X-Mailman-Approved-At: Tue, 05 Aug 2014 00:12:02 -0700 Cc: mtaylor@unicoi.com, tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] [Editorial Errata Reported] RFC5681 (4068) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 17:42:35 -0000 The following errata report has been submitted for RFC5681, "TCP Congestion Control". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5681&eid=4068 -------------------------------------- Type: Editorial Reported by: Michael Taylor Section: GLOBAL Original Text ------------- Corrected Text -------------- Notes ----- The problem is the use of the phrase "new data" in an imprecise manner to sometimes mean "previously unacknowledged data" and other times mean "never before sent data". For example, in Section 3.1 During slow start, a TCP increments cwnd by at most SMSS bytes for each ACK received that cumulatively acknowledges new data. This should read During slow start, a TCP increments cwnd by at most SMSS bytes for each ACK received that cumulatively acknowledges previously unacknowledged data. I believe that throughout Section 3.1 "new data" refers to "previously unacknowledged data". However, in Section 3.2 we have After the fast retransmit algorithm sends what appears to be the missing segment, the "fast recovery" algorithm governs the transmission of new data until a non-duplicate ACK arrives. I believe that here "new data" refers to "previously unsent data". This is clearer in the following paragraph from Section 3.2 1. On the first and second duplicate ACKs received at a sender, a TCP SHOULD send a segment of previously unsent data per [RFC3042] provided that the receiver's advertised window allows, the total FlightSize would remain less than or equal to cwnd plus 2*SMSS, and that new data is available for transmission. Here we can see the use of "previously unsent data" followed by "new data" which refers to the aforementioned "previously unsent data". While the meaning of "new data" might be clear to those with extensive experience in TCP it is imprecise and therefore may be quite confusing to those who are learning about the protocol. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5681 (draft-ietf-tcpm-rfc2581bis-07) -------------------------------------- Title : TCP Congestion Control Publication Date : September 2009 Author(s) : M. Allman, V. Paxson, E. Blanton Category : DRAFT STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From elb@kb8ojh.net Wed Aug 6 11:41:08 2014 Return-Path: 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 7F1851B27AC for ; Wed, 6 Aug 2014 11:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 K16Ztnf-6UeN for ; Wed, 6 Aug 2014 11:41:05 -0700 (PDT) Received: from cathode.kb8ojh.net (cathode.kb8ojh.net [162.243.72.198]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1DC1B27A8 for ; Wed, 6 Aug 2014 11:41:01 -0700 (PDT) Received: from mail.kb8ojh.net (99-52-197-125.lightspeed.crmlin.sbcglobal.net [99.52.197.125]) by cathode.kb8ojh.net (Postfix) with ESMTPSA id 605DC401BE; Wed, 6 Aug 2014 18:41:00 +0000 (UTC) Received: by mail.kb8ojh.net (Postfix, from userid 1000) id 796F7408F4; Wed, 6 Aug 2014 14:40:59 -0400 (EDT) Date: Wed, 6 Aug 2014 14:40:59 -0400 From: Ethan Blanton To: RFC Errata System Message-ID: <20140806184059.GB19328@mail.kb8ojh.net> References: <20140804174107.B5C6D18000E@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140804174107.B5C6D18000E@rfc-editor.org> X-GnuPG-Fingerprint: 2A9A 7752 8B91 6586 6289 FD3D 6CA9 2AC6 A1A8 AD0E User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/bVkYxVTG7OHVbFPAFClD5jxECNs X-Mailman-Approved-At: Thu, 07 Aug 2014 05:08:19 -0700 Cc: tcpm@ietf.org, vern@icir.org, mallman@icir.org, mls.ietf@gmail.com, mtaylor@unicoi.com Subject: Re: [tcpm] [Editorial Errata Reported] RFC5681 (4068) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 18:47:43 -0000 RFC Errata System spake unto us the following wisdom: > The problem is the use of the phrase "new data" in an imprecise manner > to sometimes mean "previously unacknowledged data" and other times > mean "never before sent data". I concur with Mark. New data has a different meaning for TCP as a receiver versus TCP as a sender. I don't think this is anything we introduced. That said, when 5681 is next revved I see no harm in differentiating the terms (or, at the very least, explicitly defining the difference). This errata seems inoffensive to me. Ethan From nobody Thu Aug 7 05:08:36 2014 Return-Path: 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 785941B2ACA for ; Thu, 7 Aug 2014 05:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 TqJXahpBFIdm for ; Thu, 7 Aug 2014 05:03:54 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.197]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3961B2AC6 for ; Thu, 7 Aug 2014 05:03:54 -0700 (PDT) Received: from pc114.netlab.hut.fi (130.233.154.114) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 53C62CBF01FC01EF; Thu, 7 Aug 2014 15:03:39 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: <20140806184059.GB19328@mail.kb8ojh.net> Date: Thu, 7 Aug 2014 15:03:30 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <20140804174107.B5C6D18000E@rfc-editor.org> <20140806184059.GB19328@mail.kb8ojh.net> To: Ethan Blanton X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/fWVO7VaAVB_93kS90a7b5GLjih4 X-Mailman-Approved-At: Thu, 07 Aug 2014 05:08:10 -0700 Cc: tcpm@ietf.org, vern@icir.org, mallman@icir.org, mls.ietf@gmail.com, mtaylor@unicoi.com, RFC Errata System Subject: Re: [tcpm] [Editorial Errata Reported] RFC5681 (4068) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 12:03:59 -0000 Yep, I agree. This seems an obvious "Hold for Document Update" case to me. - Pasi On 06 Aug 2014, at 21:40, Ethan Blanton wrote: > RFC Errata System spake unto us the following wisdom: >> The problem is the use of the phrase "new data" in an imprecise manner >> to sometimes mean "previously unacknowledged data" and other times >> mean "never before sent data". > > I concur with Mark. New data has a different meaning for TCP as a > receiver versus TCP as a sender. I don't think this is anything we > introduced. That said, when 5681 is next revved I see no harm in > differentiating the terms (or, at the very least, explicitly defining > the difference). > > This errata seems inoffensive to me. > > Ethan From nobody Mon Aug 11 23:36:04 2014 Return-Path: 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 9E9001A06DE; Mon, 11 Aug 2014 23:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qagVAa6WU8gg; Mon, 11 Aug 2014 23:36:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBBC1A0327; Mon, 11 Aug 2014 23:36:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140812063600.17540.3362.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 23:36:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/omsjU-295x4ppiSxhBFBGw5heAU Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-rfc4614bis-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 06:36:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : A Roadmap for Transmission Control Protocol (TCP) Specification Documents Authors : Martin Duke Robert Braden Wesley M. Eddy Ethan Blanton Alexander Zimmermann Filename : draft-ietf-tcpm-tcp-rfc4614bis-08.txt Pages : 52 Date : 2014-08-11 Abstract: This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This document obsoletes RFC 4614. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-rfc4614bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 12 05:50:45 2014 Return-Path: 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 6AFFB1A0842 for ; Tue, 12 Aug 2014 05:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 aigVIEWDCRVv for ; Tue, 12 Aug 2014 05:50:36 -0700 (PDT) Received: from atl4mhob18.myregisteredsite.com (atl4mhob18.myregisteredsite.com [209.17.115.111]) by ietfa.amsl.com (Postfix) with ESMTP id 729EE1A06E5 for ; Tue, 12 Aug 2014 05:50:36 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob18.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s7CCoYEZ027393 for ; Tue, 12 Aug 2014 08:50:34 -0400 Received: (qmail 7771 invoked by uid 0); 12 Aug 2014 12:50:34 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.108?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 12 Aug 2014 12:50:34 -0000 Message-ID: <53EA0D90.2030902@mti-systems.com> Date: Tue, 12 Aug 2014 08:50:24 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/fGTSXUbCLeGz1ODk9CHWJm2Bb_k Subject: [tcpm] 793bis: -03 update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 12:50:41 -0000 I uploaded a new (-03) copy of the proposed RFC 793bis: http://www.ietf.org/id/draft-eddy-rfc793bis-03.txt The diff from the prior copy (-02) is available at: http://www.ietf.org/rfcdiff?url1=draft-eddy-rfc793bis-02&url2=draft-eddy-rfc793bis-03 The changes in this version were focused on: - incorporating urgent pointer updates from 1122 and 6093/1011 - adding the 1122 requirements list, since the urgent pointer requirements from 1122 are part of that list Any comments folks have on this are appreciated. Specifically, I hope it's evolving into something the working group will adopt and would be interested in knowing what more should be done to enable that. -- Wes Eddy MTI Systems From nobody Tue Aug 12 06:05:57 2014 Return-Path: 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 092911A089A for ; Tue, 12 Aug 2014 06:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 XuqhjjDUuk0t for ; Tue, 12 Aug 2014 06:05:45 -0700 (PDT) Received: from atl4mhob08.myregisteredsite.com (atl4mhob08.myregisteredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id 877141A089B for ; Tue, 12 Aug 2014 06:05:45 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob08.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s7CD5hoU021023 for ; Tue, 12 Aug 2014 09:05:43 -0400 Received: (qmail 17402 invoked by uid 0); 12 Aug 2014 13:05:43 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.108?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 12 Aug 2014 13:05:43 -0000 Message-ID: <53EA111D.9040106@mti-systems.com> Date: Tue, 12 Aug 2014 09:05:33 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/q8nv5qDR6_7jz0Q08M666jTpMY8 Subject: [tcpm] sequence number validation? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 13:05:54 -0000 I'm curious about the working group status of: http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-01 It seems quite obvious to me that it should be adopted. Since this should be fairly quick to take care of, and is one of the open issues with RFC 793, I'd like to see it adopted, finished off relatively quickly, and then incorporated into the 793bis work. To that end, I'll happily contribute reviews or any other support needed. -- Wes Eddy MTI Systems From nobody Tue Aug 12 08:39:27 2014 Return-Path: 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 E2F281A095A for ; Tue, 12 Aug 2014 08:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.668, 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 xzdOL4V60Irz for ; Tue, 12 Aug 2014 08:39:22 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B36F61A0983 for ; Tue, 12 Aug 2014 08:39:17 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id h18so7082620igc.0 for ; Tue, 12 Aug 2014 08:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GqG7klzBo+EZ1AUMb+rDnuuO3mNxVEyX/GY7/wtmVHc=; b=I1DdmFnxTD+U12kbkD6zFzukKqzhi7m1bC1n/HG8K81C8xL8iv/u6c0/ofB0fGTmpv qyZ0GNznaVH3QPF7FDNSuCpXlNmw15TBGewvGxlWEU7nrex1jSgjqYEuOCd2BITsKzQx PRWna+U+eHoVqYXT0CrCTDadya95mBizWhk+ezgNSzVKJpY1cFYcPAEWTnnlO86RqJ6i LCbICIrcxD9uWfVAv2PV4iqrHbvvUZLohWhUqtSaAs9r5fnuJAYWvm8tW65rTzMsOG++ i+sdizcSQc4wLNBGwqY4CWYuA2MDt7Su7Yn8j0ewf7qhXUWxUKTJFTfDcKvuAYU9fIaa hh+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GqG7klzBo+EZ1AUMb+rDnuuO3mNxVEyX/GY7/wtmVHc=; b=dJKEeRBRCfqygH4fXlVlQt9PTBDJczTDLWjkn6WY2XjwM9nUCaKP1U24zvevJZjjue 7Zu1ArHoLJBC7skG8vyBXo+w8VOIszBAKGa8Nxdw+qInRMgXR55ejeUUsNroXQcxBi9c 2R/QdDynj8yWC4pB5VOUi4AGYpStktkF0g5rHcIaJeYj7/26TIvWJafEgotfyj1rVYMg SHYrzaMcBtEDfydd/rlDjnUvMePZiTgaAnNzpr+vDYpfeyayrhaOjw2vrz3qXAY5ZMTv 3JwWjC7K0cMqUakmgZcY3cDEp4VUur/grA87CCXRqUBsFZJRlL+94JB50K79Chmxl6dM Uyuw== X-Gm-Message-State: ALoCoQkJu7zDAn9rED8YgXkbErc2bIh3ul+VHEHK3bleLPtGUo2h4YJKPiWC5HBiCM/Xr8bvMOEj X-Received: by 10.50.2.42 with SMTP id 10mr39510650igr.33.1407857956985; Tue, 12 Aug 2014 08:39:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.71.163 with HTTP; Tue, 12 Aug 2014 08:38:36 -0700 (PDT) In-Reply-To: <53EA0D90.2030902@mti-systems.com> References: <53EA0D90.2030902@mti-systems.com> From: Yuchung Cheng Date: Tue, 12 Aug 2014 08:38:36 -0700 Message-ID: To: Wesley Eddy Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ShaF2Sa57qoEG7u4PsNYyWknYx8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] 793bis: -03 update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 15:39:24 -0000 On Tue, Aug 12, 2014 at 5:50 AM, Wesley Eddy wrote: > I uploaded a new (-03) copy of the proposed RFC 793bis: > http://www.ietf.org/id/draft-eddy-rfc793bis-03.txt > The diff from the prior copy (-02) is available at: > http://www.ietf.org/rfcdiff?url1=draft-eddy-rfc793bis-02&url2=draft-eddy-rfc793bis-03 > > The changes in this version were focused on: > - incorporating urgent pointer updates from 1122 and 6093/1011 > - adding the 1122 requirements list, since the urgent pointer > requirements from 1122 are part of that list > > Any comments folks have on this are appreciated. > > Specifically, I hope it's evolving into something the working group > will adopt and would be interested in knowing what more should be done > to enable that. +1 for adoption > > -- > Wes Eddy > MTI Systems > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Aug 13 00:37:39 2014 Return-Path: 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 6D56F1A7023 for ; Wed, 13 Aug 2014 00:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.556 X-Spam-Level: * X-Spam-Status: No, score=1.556 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, RELAY_IS_203=0.994, 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 x63kyERHJi_2 for ; Wed, 13 Aug 2014 00:37:36 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F3F1A7022 for ; Wed, 13 Aug 2014 00:37:34 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D04482780CD for ; Wed, 13 Aug 2014 16:37:29 +0900 (JST) Received: by mail-lb0-f173.google.com with SMTP id u10so5986185lbd.4 for ; Wed, 13 Aug 2014 00:37:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.157.132 with SMTP id wm4mr811214lbb.89.1407915446889; Wed, 13 Aug 2014 00:37:26 -0700 (PDT) Received: by 10.114.160.145 with HTTP; Wed, 13 Aug 2014 00:37:26 -0700 (PDT) In-Reply-To: <53EA111D.9040106@mti-systems.com> References: <53EA111D.9040106@mti-systems.com> Date: Wed, 13 Aug 2014 00:37:26 -0700 Message-ID: From: Yoshifumi Nishida To: Wesley Eddy Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/aMrw6RWkFUwuvBHJBwjAvKxlMp0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] sequence number validation? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 07:37:37 -0000 Hi Wes, I agree the problem described in the draft, However, I'm not very sure we can take care of it quickly. There seems to be some solutions in the wild as the problem has existed for long time. If this draft will be incorporated into 793bis work, it should be a single solution. I think we should check other existing solutions (at least major OSs) to see if there's any differences or conflicts. Also, I would like to know if the solution in the draft have some implementation experiences. Thanks, -- Yoshi On Tue, Aug 12, 2014 at 6:05 AM, Wesley Eddy wrote: > I'm curious about the working group status of: > http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-01 > > It seems quite obvious to me that it should be adopted. > > Since this should be fairly quick to take care of, and is one > of the open issues with RFC 793, I'd like to see it adopted, > finished off relatively quickly, and then incorporated into the > 793bis work. > > To that end, I'll happily contribute reviews or any other support > needed. > > -- > Wes Eddy > MTI Systems > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Aug 13 00:50:06 2014 Return-Path: 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 E485D1A7022 for ; Wed, 13 Aug 2014 00:50:04 -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 vtmUBfYtLVPm for ; Wed, 13 Aug 2014 00:50:03 -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 F27B91A03B7 for ; Wed, 13 Aug 2014 00:50:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,855,1400050800"; d="asc'?scan'208";a="181670360" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 13 Aug 2014 00:50:01 -0700 Received: from HIOEXCMBX08-PRD.hq.netapp.com (10.122.105.41) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 13 Aug 2014 00:49:28 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 13 Aug 2014 00:49:09 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::8c6:4c4c:718d:b192%21]) with mapi id 15.00.0913.011; Wed, 13 Aug 2014 00:49:09 -0700 From: "Zimmermann, Alexander" To: Wesley Eddy Thread-Topic: [tcpm] 793bis: -03 update Thread-Index: AQHPtiv39DzAOcFP8U+7uJj1edSylJvOn0kA Date: Wed, 13 Aug 2014 07:49:08 +0000 Message-ID: References: <53EA0D90.2030902@mti-systems.com> In-Reply-To: <53EA0D90.2030902@mti-systems.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_C0E23639-91C2-497D-8271-25C9D6C6E6ED"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/LUG4tqiKaKPaxXpBKXS18-ou6cI Cc: "tcpm@ietf.org" Subject: Re: [tcpm] 793bis: -03 update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 07:50:05 -0000 --Apple-Mail=_C0E23639-91C2-497D-8271-25C9D6C6E6ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Am 12.08.2014 um 14:50 schrieb Wesley Eddy : > I uploaded a new (-03) copy of the proposed RFC 793bis: > http://www.ietf.org/id/draft-eddy-rfc793bis-03.txt > The diff from the prior copy (-02) is available at: > = http://www.ietf.org/rfcdiff?url1=3Ddraft-eddy-rfc793bis-02&url2=3Ddraft-ed= dy-rfc793bis-03 >=20 > The changes in this version were focused on: > - incorporating urgent pointer updates from 1122 and 6093/1011 > - adding the 1122 requirements list, since the urgent pointer > requirements from 1122 are part of that list >=20 > Any comments folks have on this are appreciated. >=20 > Specifically, I hope it's evolving into something the working group > will adopt and would be interested in knowing what more should be done > to enable that. +1 for adoption too >=20 > --=20 > Wes Eddy > MTI Systems >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_C0E23639-91C2-497D-8271-25C9D6C6E6ED Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlPrGJYACgkQdyiq39b9uS6fGQCfWfTdIK5cY/y79BGyLeBn8hPz OAUAnRiF0sNj/hsHOEJzYABS7ldtRF7o =W8hH -----END PGP SIGNATURE----- --Apple-Mail=_C0E23639-91C2-497D-8271-25C9D6C6E6ED-- From nobody Fri Aug 15 16:53:13 2014 Return-Path: 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 D0D621A0887; Fri, 15 Aug 2014 16:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 FGbduKCnPC0h; Fri, 15 Aug 2014 16:53:09 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E6021A0886; Fri, 15 Aug 2014 16:53:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,874,1400050800"; d="scan'208,217";a="140424739" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 15 Aug 2014 16:53:07 -0700 Received: from HIOEXCMBX04-PRD.hq.netapp.com (10.122.105.37) by vmwexceht06-prd.hq.netapp.com (10.106.77.104) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 15 Aug 2014 16:52:24 -0700 Received: from HIOEXCMBX02-PRD.hq.netapp.com (10.122.105.35) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 15 Aug 2014 16:52:06 -0700 Received: from HIOEXCMBX02-PRD.hq.netapp.com ([::1]) by hioexcmbx02-prd.hq.netapp.com ([fe80::bd51:14bc:cba2:6b32%21]) with mapi id 15.00.0913.011; Fri, 15 Aug 2014 16:51:48 -0700 From: "Scheffenegger, Richard" To: "tcpm (tcpm@ietf.org)" , "tcpinc@ietf.org" Thread-Topic: TCP Stealth - possible interest to the WG Thread-Index: Ac+448Fsl9mI8tJfQO6l37mQPpygtg== Date: Fri, 15 Aug 2014 23:51:47 +0000 Message-ID: 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: multipart/alternative; boundary="_000_ecdbe694b6964c159f64b1d3311c8cc6hioexcmbx02prdhqnetappc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/3qBIt6ZJCecRnqK0fSGBdOGGQa4 Cc: Joe Touch Subject: [tcpm] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 23:53:11 -0000 --_000_ecdbe694b6964c159f64b1d3311c8cc6hioexcmbx02prdhqnetappc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I just learned about an individual submission, which is probably of interes= t not only to the members of these two WGs; http://tools.ietf.org/html/draft-kirsch-ietf-tcp-stealth-00 On a first, casual glance, I am wondering if the authors have realized all = the implications of their suggestion; 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 "stealthiene= ss" of this modification (making it easy for an attacker to identify such s= essions, provided he is able to actively interfere with segments in transit= (ie. cause certain segments to be dropped). Nevertheless, it might be beneficial to discuss the generic idea in a wider= forum, among brighter minds than me. Richard Scheffenegger --_000_ecdbe694b6964c159f64b1d3311c8cc6hioexcmbx02prdhqnetappc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I just learned about an individual submission, which is probably of in= terest not only to the members of these two WGs;
 
 
 
On a first, casual glance, I am wondering if the authors have realized= all the implications of their suggestion;
 
There seem to be at least two or three major issues that compromise ei= ther the working and stability of TCP, or work against the intended “= stealthieness” of this modification (making it easy for an attacker t= o identify such sessions, provided he is able to actively interfere with segments in transit (ie. cause certain segments = to be dropped).
 
Nevertheless, it might be beneficial to discuss the generic idea in a = wider forum, among brighter minds than me.
 
Richard Scheffenegger
 
 
 --_000_ecdbe694b6964c159f64b1d3311c8cc6hioexcmbx02prdhqnetappc_-- From nobody Mon Aug 18 07:00:15 2014 Return-Path: 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 BA08D1A0382 for ; Mon, 18 Aug 2014 07:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 A86gv2t7v_z3 for ; Mon, 18 Aug 2014 07:00:06 -0700 (PDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169DA1A0343 for ; Mon, 18 Aug 2014 07:00:04 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id b17so4468643lan.25 for ; Mon, 18 Aug 2014 07:00:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HyqDEyVZlMGh7JSfHNF9dUVr9O6u+vmz0Q2yBHBFUJs=; b=AyYO7bemjkA3GdGNGE+ta+NbB2/aZCHPvXLLEM0N6Pdk4F1WKqFT2zOynMXGVNFqXC As45k1q+VpSA+X16dwrzUJYZtGtv3Hxcfc53Zmi4zLtJKb5vnHGpblTP4A2WZO7GA/Ey YjbOj+rsRlIP9epgbtXxaILnPvDAEm8+0XINquJu3d5QkC8LKIL941oW+SeKykdbQZID BEI9ic71RrAuBPAr3zArDtseYWTTYU9Nt9X5BYx0KLlKfMDYhfH9exNzIvClTAflrAAE mp/aaKDTQ7azSYFvtg/RTfrYFeKdvAqu7KIsjHxReQjmrQoFjLw3eZ2IaRs+m3kmZVld wjmg== X-Gm-Message-State: ALoCoQnaxwM69KeCDKNLEma1Pe0COsJBkK+ke6wnhG6S24mntuLbNiu6wBCgYNIzHtbU3TjH14U3 MIME-Version: 1.0 X-Received: by 10.112.172.38 with SMTP id az6mr27991641lbc.53.1408370403089; Mon, 18 Aug 2014 07:00:03 -0700 (PDT) Received: by 10.152.242.42 with HTTP; Mon, 18 Aug 2014 07:00:03 -0700 (PDT) X-Originating-IP: [80.246.32.33] In-Reply-To: References: Date: Mon, 18 Aug 2014 16:00:03 +0200 Message-ID: From: Hagen Paul Pfeifer To: "Scheffenegger, Richard" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/00TS_PYJgOijT1QYnrW7mrJ_BlM Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 14:00:11 -0000 Hi Richard, tcpm, tcpinc the ground work for the ID is likely the following master thesis titled "Improved Kernel-Based Port-Knocking in Linux"[1]: Feeling a little bit unfortunate with this obfuscation technique but highly appreciate efforts to prevent mass scanning. BTW: discussion on this ID already started on perpass. Cheers, Hagen [1] https://gnunet.org/sites/default/files/ma_kirsch_2014.pdf On 16 August 2014 01:51, Scheffenegger, Richard wrote: > Hi, > > I just learned about an individual submission, which is probably of inter= est > not only to the members of these two WGs; > > http://tools.ietf.org/html/draft-kirsch-ietf-tcp-stealth-00 > > > On a first, casual glance, I am wondering if the authors have realized al= l > the implications of their suggestion; > > There seem to be at least two or three major issues that compromise eithe= r > the working and stability of TCP, or work against the intended > =E2=80=9Cstealthieness=E2=80=9D 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). > > Nevertheless, it might be beneficial to discuss the generic idea in a wid= er > forum, among brighter minds than me. > > Richard Scheffenegger > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Mon Aug 18 08:02:24 2014 Return-Path: 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 6F99F1A0307 for ; Mon, 18 Aug 2014 05:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 Gy7XHFBq4Lul for ; Mon, 18 Aug 2014 05:50:13 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71831A02F4 for ; Mon, 18 Aug 2014 05:50:13 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id w7so4704147qcr.18 for ; Mon, 18 Aug 2014 05:50:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d8cWmGMJ3AK25gShJKg+TRVm0wHr1u5C/+KBA8dDrAY=; b=K4b1BKAmmWWOfzq6G47rgCDT5bJdkM2W1lzyRKgxhk0iaqjavmCCe+hsa0qkFsnmqb EYNqPwnIbiTo1XJwPUmpolXdNQhMYV/bt67VZrxVb15hQkItaQZIDLh2PqOGf+nyzOBu yNM+Rn7W+au3Nc7ag5veVmNY7Zlp5svbvA7r3KG5lwcRLvEK1bS8s3/gUXfuz+ATq0I8 Q4n0L9wnU8NvRs08zUG+g7irHyCOwX+8Ulipd1fLHLOz7dYmB5kBLXQ+lewCpecb332H NFdv48O0pRAtVmmIAkQtrdFS0zG5dGX2SElbsyZqOeiaVXFCJfF1U+WAvX9zOW5l2ngQ IcFA== X-Gm-Message-State: ALoCoQlxdnDxXfknQ5N14syGavJ8vMgzYcI0Spn0NEuJAPrtCD49j9rbdEPovu93YCzREYdtoTRJ MIME-Version: 1.0 X-Received: by 10.224.138.8 with SMTP id y8mr56065733qat.38.1408366212961; Mon, 18 Aug 2014 05:50:12 -0700 (PDT) Received: by 10.140.91.50 with HTTP; Mon, 18 Aug 2014 05:50:12 -0700 (PDT) X-Originating-IP: [192.155.86.99] In-Reply-To: References: Date: Mon, 18 Aug 2014 12:50:12 +0000 Message-ID: From: Jacob Appelbaum To: "Scheffenegger, Richard" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/07QowdGmDMiFhh90Xl6bKxwT7io X-Mailman-Approved-At: Mon, 18 Aug 2014 08:02:23 -0700 Cc: Christian Grothoff , "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 12:50:15 -0000 On 8/15/14, Scheffenegger, Richard 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 From nobody Mon Aug 18 09:46:32 2014 Return-Path: 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 8A33E1A06E2 for ; Mon, 18 Aug 2014 09:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 CGYcISVKcE9v for ; Mon, 18 Aug 2014 09:46:29 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B8981A06D1 for ; Mon, 18 Aug 2014 09:46:29 -0700 (PDT) Received: from vim.isi.edu (vim.isi.edu [128.9.168.184]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s7IGjsNj026058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Aug 2014 09:45:54 -0700 (PDT) Message-ID: <53F22DBB.5010400@isi.edu> Date: Mon, 18 Aug 2014 09:45:47 -0700 From: Ted Faber User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: tcpm@ietf.org References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tkUsF38UCQsEB37kh7KhpL8EsUEImUUIc" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ZT1Nf9YD5NdYvquYSnr3BgqFLVU Cc: faber@isi.edu Subject: Re: [tcpm] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 16:46:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tkUsF38UCQsEB37kh7KhpL8EsUEImUUIc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 08/15/14 16:51, Scheffenegger, Richard wrote: > Hi, > =20 > I just learned about an individual submission, which is probably of > interest not only to the members of these two WGs; > =20 > _http://tools.ietf.org/html/draft-kirsch-ietf-tcp-stealth-00_ Neat. I think interested parties should bat it around for improvement. I'm not in that set at the moment. In case it comes up in the future, I don't think this needs to be standardized. It's basically a SYN cookie variant, and that's (correctly) not a standard. I see they're aiming at an informational RFC now, to which I have no objection. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --tkUsF38UCQsEB37kh7KhpL8EsUEImUUIc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPyLbsACgkQaUz3f+Zf+XtwKACgya/lvKnaaMKkJicTniDtQ9Fc OTcAoKjbAHwXSLaZwObkjZvIp9UqGbe1 =6ON+ -----END PGP SIGNATURE----- --tkUsF38UCQsEB37kh7KhpL8EsUEImUUIc-- From nobody Mon Aug 18 15:08:44 2014 Return-Path: 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 829C51A86E4; Mon, 18 Aug 2014 15:08:41 -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 fxFNv7pjxWMI; Mon, 18 Aug 2014 15:08: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 CB6D31A86DD; Mon, 18 Aug 2014 15:08:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,888,1400050800"; d="scan'208";a="182697367" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 18 Aug 2014 15:08:27 -0700 Received: from HIOEXCMBX08-PRD.hq.netapp.com (10.122.105.41) by vmwexceht02-prd.hq.netapp.com (10.106.76.240) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 18 Aug 2014 15:07:32 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 18 Aug 2014 15:07:31 -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; Mon, 18 Aug 2014 15:07:31 -0700 From: "Scheffenegger, Richard" To: "alfiej@fastmail.fm" , Jacob Appelbaum Thread-Topic: [tcpinc] TCP Stealth - possible interest to the WG Thread-Index: Ac+448Fsl9mI8tJfQO6l37mQPpygtgCOd38AABJQWoAADckrIA== Date: Mon, 18 Aug 2014 22:07:31 +0000 Message-ID: <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> In-Reply-To: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.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.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/RCZzhlO0ZjDNXR6rkAdNCqBjBdE Cc: Christian Grothoff , "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 22:08:41 -0000 Hi Alfie, my concern is with the use of a static ISN for each 4-tuple; this significa= ntly increases the chance of a collision between sessions (ie. when the se= nder terminates a sluggish earlier session, some segments of that last sess= ion will very likely be in-window for a session that was started a short ti= me later). (I understand that an application could use some crude time-based salt, to = address this concern. But that would mean application/socket level modifica= tions; and additional failure modes - like Kerberos has with the 5 min time= window). Of course, the ephemeral source ports (the remaining 3 fields of the 4 tupl= e will again be static for a given service) will provide some protection, a= s each different source port will have a different ISN. OTOH, detection of this knocking scheme will be rather easy by passive mean= s - currently the probability to two identical ISNs between two different s= essions for the same 4-tuple (IP + ports) will be around 2^-32; with this, = it is 1; and the number of ephemeral ports is limited so observing a protec= ted web server will be rather straight forwards. Which probably will flag such a service as a primary target for those adver= saries this scheme is supposed to protect against. Or am I missing something? Richard Scheffenegger > -----Original Message----- > From: Alfie John [mailto:alfiej@fastmail.fm] > Sent: Montag, 18. August 2014 23:35 > To: Jacob Appelbaum; Scheffenegger, Richard > Cc: Wesley Eddy; Christian Grothoff; tcpinc@ietf.org; tcpm > (tcpm@ietf.org); Joe Touch > Subject: Re: [tcpinc] TCP Stealth - possible interest to the WG >=20 > On Mon, Aug 18, 2014, at 02:50 PM, Jacob Appelbaum wrote: > > On 8/15/14, Scheffenegger, Richard wrote: > > > 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 > > > > > 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. >=20 > Let's look at Richard's concerns: >=20 > > compromise either the working and stability of TCP >=20 > This RFC only modifies the calculation of the SQN number in order to get > port-knockable services. Every other host between just continues to see > the SQN as a random number as it did before. Unless between hops were to > modify the packet's timestamps, this will be completely backwards > compatible. >=20 > > 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 >=20 > This is not about hiding from big brother who is listening on the wire. > This is about minimising your visible footprint to the wider internet. > It's on par to your server's firewall dropping all incoming connections > unless you have the shared secret. But with this RFC, you don't need to > know the source IP address before hand. >=20 > I think it's a great idea. Nice work. >=20 > Alfie >=20 > -- > Alfie John > alfiej@fastmail.fm From nobody Tue Aug 19 03:12:59 2014 Return-Path: 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 A57461A03A2 for ; Tue, 19 Aug 2014 03:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, 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 TqUVDA9fvkPa for ; Tue, 19 Aug 2014 03:12:50 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DADA11A0392 for ; Tue, 19 Aug 2014 03:12:49 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 19 Aug 2014 11:12:48 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 19 Aug 2014 11:12:47 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Tue, 19 Aug 2014 11:12:45 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.230.241]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s7JACegt022734; Tue, 19 Aug 2014 11:12:42 +0100 Message-ID: <201408191012.s7JACegt022734@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 19 Aug 2014 11:12:39 +0100 To: "ALLMAN, Mark" , , From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/p9nU2nd93QiF9Xd_PeoI1RQ7Fgk Cc: tcpm IETF list Subject: [tcpm] RFC5681 erratum regarding stretch ACK violation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 10:12:57 -0000 Mark, Vern, Ethan, (as authors of RFC5681) I noticed a (minor) inconsistency in S.4.2 of RFC5681 "Generating Acknowledgements" between the two blocks of text quoted below. The second block says the receiver will generate stretch ACKs if it satisfies the requirement just given in the first clause for /not/ generating stretch ACKs. I know what it means. But it doesn't say what it means. Please confirm whether you agree that there is an inconsistency, and whether you agree with my proposed fix, and whether you agree that a fix can wait for the next revision. CURRENT In some cases, the sender and receiver may not agree on what constitutes a full-sized segment. An implementation is deemed to comply with this requirement if it sends at least one acknowledgment every time it receives 2*RMSS bytes of new data from the sender, where RMSS is the Maximum Segment Size specified by the receiver ... The sender may be forced to use a segment size less than RMSS due to the maximum transmission unit (MTU), the path MTU discovery algorithm or other factors. For instance, consider the case when the receiver announces an RMSS of X bytes but the sender ends up using a segment size of Y bytes (Y < X) due to path MTU discovery (or the sender's MTU size). The receiver will generate stretch ACKs if it waits for 2*X bytes to arrive before an ACK is sent. Clearly this will take more than 2 segments of size Y bytes. Therefore, while a specific algorithm is not defined, it is desirable for receivers to attempt to prevent this situation, for example, by acknowledging at least every second segment, regardless of size. An erratum could alter the inconsistent phrase "the receiver will generate stretch ACKs". However, I think it would give a better sense of what was intended if the earlier definition of compliant behaviour was also changed to explicitly describe it as a 'pragmatic requirement', which also means the text needs to have already explained the need for pragmatism. SUGGESTED: In some cases, the sender and receiver may not agree on what constitutes a full-sized segment, and the receiver may not know ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ they disagree. Therefore, pragmatically, an implementation is deemed to ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^ comply with this requirement if it sends at least one acknowledgment every time it receives 2*RMSS bytes of new data from the sender, where RMSS is the Maximum Segment Size specified by the receiver ... The sender may be forced to use a segment size less than RMSS due to the maximum transmission unit (MTU), the path MTU discovery algorithm or other factors. For instance, consider the case when the receiver announces an RMSS of X bytes but the sender ends up using a segment size of Y bytes (Y < X) due to path MTU discovery (or the sender's MTU size). If the receiver waits for ^^^^^^^^^^^^^^^ 2*X bytes to arrive before it sends an ACK, it could cause a burst ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ from the sender of more than 2 segments of size Y bytes. ^^^^^^^^^^^^^^^^^^ Therefore, while a specific algorithm is not defined, it is desirable for receivers to attempt to prevent this situation, for example, by acknowledging at least every second segment, regardless of size. This also solves another problem I came across while thinking about app-limited streams containing many smaller segments. Despite some digging, I could not find any rationale anywhere for the requirement in RFC5681 (and RFC1122 where it came from) that an ACK may be delayed by two *full-sized* segments worth of bytes. You can work it out if you think about it, but it is far from obvious. I know a spec doesn't have to give rationale for rules, but it surely helps. The above amendments don't explicitly explain why, but they give a good hint. Cheers Bob ________________________________________________________________ Bob Briscoe, BT From nobody Tue Aug 19 08:01:37 2014 Return-Path: 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 CF5DB1A6F2A for ; Mon, 18 Aug 2014 14:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 JP2xkcL1KtEB for ; Mon, 18 Aug 2014 14:34:37 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161AE1A000B for ; Mon, 18 Aug 2014 14:34:37 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by gateway1.nyi.internal (Postfix) with ESMTP id 2BDBB232BE for ; Mon, 18 Aug 2014 17:34:36 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute4.internal (MEProxy); Mon, 18 Aug 2014 17:34:36 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:subject:reply-to:date:in-reply-to:references; s= mesmtp; bh=2ikeGNz3vIFi/uwN2Bdy0kWIpeM=; b=llMsvPB0yiWFAZMjiWpcK rBLXGbN9nR5HooWgV2/VFA9iZl59zcJbMhmgRSo6hJ79FLaRi7ppJxILf5dFWXsx oPomxvnbUbSJ3/31o6aD5qFZWNMu/eTJvRbhGSPCZx3/hchyMVaqgrzkHN2C0+iB xk3weCBzaLCh1xqjOEbCMs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:subject:reply-to:date :in-reply-to:references; s=smtpout; bh=2ikeGNz3vIFi/uwN2Bdy0kWIp eM=; b=IJ8dhWSQgCx+LpEFVDG60WJRBF5FIOYOXko0UnfmgRSHicwsgf7zzcg9k W6m/c1B/eTJQ0lyDEmBdvVsmfq/RHeZJNapbElra4mNdqYjeDgd+/nafg8FJ9zOR Elu1khgsNVy/z63aVKNZm7xYGXREsGvKJRVPDhY/4d50uJhb3w= Received: by web2.nyi.internal (Postfix, from userid 99) id 0641A540211; Mon, 18 Aug 2014 17:34:36 -0400 (EDT) Message-Id: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> X-Sasl-Enc: 0mUKHRI1hJp/303iaQwsqJhUK09ryrtHpqowW6PFvXc/ 1408397675 From: Alfie John To: Jacob Appelbaum , "Scheffenegger, Richard" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-5f815d4c Date: Mon, 18 Aug 2014 23:34:35 +0200 In-Reply-To: References: Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/jG9T42yXa5uZ-yIHL7ZIVwyqoio X-Mailman-Approved-At: Tue, 19 Aug 2014 08:01:35 -0700 Cc: Christian Grothoff , tcpinc@ietf.org, "tcpm \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: alfiej@fastmail.fm List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 21:34:39 -0000 On Mon, Aug 18, 2014, at 02:50 PM, Jacob Appelbaum wrote: > On 8/15/14, Scheffenegger, Richard wrote: > > 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 > > > 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. Let's look at Richard's concerns: > compromise either the working and stability of TCP This RFC only modifies the calculation of the SQN number in order to get port-knockable services. Every other host between just continues to see the SQN as a random number as it did before. Unless between hops were to modify the packet's timestamps, this will be completely backwards compatible. > 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 This is not about hiding from big brother who is listening on the wire. This is about minimising your visible footprint to the wider internet. It's on par to your server's firewall dropping all incoming connections unless you have the shared secret. But with this RFC, you don't need to know the source IP address before hand. I think it's a great idea. Nice work. Alfie -- Alfie John alfiej@fastmail.fm From nobody Tue Aug 19 08:02:56 2014 Return-Path: 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 806121A86DE for ; Mon, 18 Aug 2014 15:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 vnPIMqgw71n8 for ; Mon, 18 Aug 2014 15:46:34 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A201A8549 for ; Mon, 18 Aug 2014 15:46:34 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by gateway1.nyi.internal (Postfix) with ESMTP id A00E723E4A for ; Mon, 18 Aug 2014 18:46:31 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute4.internal (MEProxy); Mon, 18 Aug 2014 18:46:32 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:reply-to:in-reply-to:references:subject:date; s= mesmtp; bh=1f+4YcDrhfyiPaRRXs5aWyphHJ0=; b=ogOHF1LMdStr8QkPFwIF2 kepMT28iWQEPEvlRWPschPLiLgVCf7SKZnO9TGjg/3tU0az8Yc8n+KbY3+BmSS3Z 5d2JHRObCAGf+HVkvqUhbWAakhesDTM4Tew40RbBarHg+KjAZDHR825WIusSMQ9k ioFZ7835lqS6jD+gPp8lp0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:reply-to:in-reply-to :references:subject:date; s=smtpout; bh=1f+4YcDrhfyiPaRRXs5aWyph HJ0=; b=uaeKUZO9NSkvhdBTYDlYLiPCDl11UhbvT4kjOiamB5Y0x7jPF+lHUQXe mnLTbves5nC3JdiPBFlSndn9xaajRtYPwkgrLzhlvjvdXfP3rUaSRtlqMngMRIzW vsUP9KurYxkFhf+/qVxl602NPUtSowsj6b0VWV5QjKdBeyfP57w= Received: by web2.nyi.internal (Postfix, from userid 99) id 68528540211; Mon, 18 Aug 2014 18:46:31 -0400 (EDT) Message-Id: <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> X-Sasl-Enc: JHBeGcH/f8MHvuuzfKmlgTgCzKpRvZuWu+EKNuwYG5JW 1408401991 From: Alfie John To: "Scheffenegger, Richard" , Jacob Appelbaum MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-5f815d4c In-Reply-To: <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> Date: Tue, 19 Aug 2014 00:46:31 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/8JvPI_5ZBqllVhm0fn5k_OpDSKM X-Mailman-Approved-At: Tue, 19 Aug 2014 08:02:54 -0700 Cc: Christian Grothoff , tcpinc@ietf.org, "tcpm \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: alfiej@fastmail.fm List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 22:46:36 -0000 On Tue, Aug 19, 2014, at 12:07 AM, Scheffenegger, Richard wrote: > my concern is with the use of a static ISN for each 4-tuple; this > significantly increases the chance of a collision between sessions > (ie. when the sender terminates a sluggish earlier session, some > segments of that last session will very likely be in-window for a > session that was started a short time later). > > (I understand that an application could use some crude time-based > salt, to address this concern. But that would mean application/socket > level modifications; and additional failure modes - like Kerberos has > with the 5 min time window). > > Of course, the ephemeral source ports (the remaining 3 fields of the 4 > tuple will again be static for a given service) will provide some > protection, as each different source port will have a different ISN. Yeah, unless the client is using a fixed source port for whatever reason, the source port should uniquely identify connections. Maybe this wouldn't be useful from a high-traffic NAT as source port reuse is a possibility, but apart from that I'm still all for this. > OTOH, detection of this knocking scheme will be rather easy by passive > means - currently the probability to two identical ISNs between two > different sessions for the same 4-tuple (IP + ports) will be around > 2^-32; with this, it is 1; and the number of ephemeral ports is > limited so observing a protected web server will be rather straight > forwards. > > Which probably will flag such a service as a primary target for those > adversaries this scheme is supposed to protect against. > > Or am I missing something? I don't think you're understanding it's main use case. Just like with vanilla port knocking, it would completely transparent to someone listening on the wire. But this isn't what it would be used for. It's purpose is to protect services from the common script kiddie, but the NSA. e.g. I wish to setup a web server on my home machine protected by a password. The only user is me, but I don't know where I will be connecting from so I can't firewall because I don't know my source IP address. If this RFC were in place, port 80 would only be available to me since I know the shared secret. Sure anyone listening on the wire can see that I've got a service listening on port 80, but my main concern are the script kiddies who try to find open services and then hammer my home server with common exploits. This RFC completely protects my web server from the script kiddies without me having to setup port knocking (off- topic, but port knocking can sometimes be a pain). Alfie -- Alfie John alfiej@fastmail.fm From nobody Tue Aug 19 09:00:42 2014 Return-Path: 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 335321A0468 for ; Tue, 19 Aug 2014 09:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.01 X-Spam-Level: ** X-Spam-Status: No, score=2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988, RCVD_IN_DNSWL_LOW=-0.7] 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 7dDS4ADk92HR for ; Tue, 19 Aug 2014 09:00:30 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E6C1A03EE for ; Tue, 19 Aug 2014 09:00:29 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so6140213lam.0 for ; Tue, 19 Aug 2014 09:00:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3o+1W5jocMpoHM6412Gm5j3IZXTbiWahx4wce9QJIzY=; b=AoFk40rwjOozhQOLRxUuC2LA12+QgGmNRl0h6J0bbWouCaximwn6U26onhj2Fq7LY2 +JOpR2XIQb7vOHwvKUo0GJI8tEPy/BhUPFuhk6420VYCZ6In/E/qlQ1goNRoniEdWE1I inWDvvOQWFAhbwYiJIYryP812eZm7G0RyUUr7hOuF26KFBG5OHWPRErhIHl5D5I5tAuw SFFQUM43z/FidX7nZO3zCeqZS8+2qVo9M7YXdY4S4ecrMT4ZeE/3TaeLP8sV2Mir5Bbw jU92ZMjVYJPBRrjYdvTmSsKKG46s4Y1v2pN6Vxn1kX4ddWp3ly7/EoY/weONqGcZjQGX TF2g== X-Gm-Message-State: ALoCoQkd0PKqejlwgG4pwWENqAtrAm+p2nuRombRez8F5MdY73AY7ehLpl/rzsQAjyWVfnZx6zdD MIME-Version: 1.0 X-Received: by 10.152.87.97 with SMTP id w1mr10667817laz.92.1408464026689; Tue, 19 Aug 2014 09:00:26 -0700 (PDT) Received: by 10.152.242.42 with HTTP; Tue, 19 Aug 2014 09:00:26 -0700 (PDT) X-Originating-IP: [80.246.32.33] In-Reply-To: <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> Date: Tue, 19 Aug 2014 18:00:26 +0200 Message-ID: From: Hagen Paul Pfeifer To: alfiej@fastmail.fm Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/1YJyFplfVDJKLiY6ZNjhUopdc58 Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch , Christian Grothoff 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 16:00:31 -0000 On 19 August 2014 00:46, Alfie John wrote: > Sure anyone listening on the wire can see that I've got a service > listening on port 80, but my main concern are the script kiddies > who try to find open services and then hammer my home server with > common exploits. This RFC completely protects my web server from > the script kiddies without me having to setup port knocking (off- > topic, but port knocking can sometimes be a pain). For this use case it would be more secure to use TLS client certificates!? I mean a) TLS is strong crypto with all benefits (authentication, encryption, integrity) and b) a discovered, open TLS port do not open any security whole at all - the only script kiddy conclusion is "a unknown service is running at a specific port and that cipher suite 1,2,3 are supported". Nothing is more secure then a protocol protected by strong underlying cryptography. Do I miss something? I mean the benefits of this draft are clear: the proposed implementation effort is small, the application setup is one additional setsockopt() line, etc. pp. But on the other hand the mechanism smells: it address the problem of service discovery by abusing TCP's ISN. Another objection: the mechanism help only for a small fraction of use cases. Especially when the server communicate with one or a few clients where the "shared secret" is no problem. But especially in these setups TLS client certificates could be used without any problems. Anyway, I am little bit ambivalent regarding this ID. It may help in some situations and reduce the attack vector. Any effort to improve the security should be reviewed! I mean if there are no negative impacts: why not? ;-) Hagen From nobody Tue Aug 19 10:15:55 2014 Return-Path: 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 53C5F1A0584 for ; Tue, 19 Aug 2014 10:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.01 X-Spam-Level: ** X-Spam-Status: No, score=2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988, RCVD_IN_DNSWL_LOW=-0.7] 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 8aFwALajJ-7u for ; Tue, 19 Aug 2014 10:15:50 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E80A1A0650 for ; Tue, 19 Aug 2014 10:15:49 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id f51so6109685qge.25 for ; Tue, 19 Aug 2014 10:15:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=F7zbRAiXMg+NKztioPiR4z6TnDCit5t3AfnRtcjaA9A=; b=NrzDau6HqHyT1hib29WF6RAqFWSFR6qhBL6cQL2MFYOBqTno+lTq/8PNfUAVDOe/Rw dvav2S09ybuDT1wszn+4sh0TvNQZe+UkcPWy4WTkbJtBpCmdKod4sEGiFzGwPZ51MBn3 ocxagMPESIlwICpNQ19AhUNt4rsQMskoNWPsNdW1Lxc4d7raac/HFakLIgo0z7lYVTZi bQgkgRkyCvWNVnWVVJEhyxD2jyk1oQTj4dwW6pcBaW/2X+AfeT/m5ccvzwC0sejaxKl+ 8j4GUE8da4OjOOqIxoTYnnohM+brEjAy7c3ac60yd8lItqmQksWEPpMZf5JLGV8jd12J VaEw== X-Gm-Message-State: ALoCoQm/FEPAHZRh/srWG1WHSM37jCKDWR8pfqyR7UxWHL9lnUJRqKMj44+gDPvqX4xsLsXNYMe9 MIME-Version: 1.0 X-Received: by 10.229.212.194 with SMTP id gt2mr68851992qcb.6.1408468543359; Tue, 19 Aug 2014 10:15:43 -0700 (PDT) Received: by 10.140.91.50 with HTTP; Tue, 19 Aug 2014 10:15:43 -0700 (PDT) X-Originating-IP: [85.25.43.84] In-Reply-To: References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> Date: Tue, 19 Aug 2014 17:15:43 +0000 Message-ID: From: Jacob Appelbaum To: Hagen Paul Pfeifer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/YEjOT49pDAuse4EWv0eATtjoJ1w Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch , Christian Grothoff , alfiej@fastmail.fm 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 17:15:51 -0000 On 8/19/14, Hagen Paul Pfeifer wrote: > On 19 August 2014 00:46, Alfie John wrote: > >> Sure anyone listening on the wire can see that I've got a service >> listening on port 80, but my main concern are the script kiddies >> who try to find open services and then hammer my home server with >> common exploits. This RFC completely protects my web server from >> the script kiddies without me having to setup port knocking (off- >> topic, but port knocking can sometimes be a pain). > > For this use case it would be more secure to use TLS client certificates!? No. I want to protect my TLS service from implementation exploitation. You cannot probe my TLS service for the next heartbleed without a shared secret. > > I mean > > a) TLS is strong crypto with all benefits (authentication, encryption, > integrity) and > b) a discovered, open TLS port do not open any security whole at all - > the only script kiddy conclusion is "a unknown service is running at a > specific port and that cipher suite 1,2,3 are supported". Nothing is > more secure then a protocol protected by strong underlying > cryptography. This is false - see heartbleed for the most concrete example. > > Do I miss something? I mean the benefits of this draft are clear: the > proposed implementation effort is small, the application setup is one > additional setsockopt() line, etc. pp. But on the other hand the > mechanism smells: it address the problem of service discovery by > abusing TCP's ISN. It isn't abuse - we're even trying to make it a standard to ensure that it is well documented non-abusive behavior - rather different than most other port knocking, I'd add. > > Another objection: the mechanism help only for a small fraction of use > cases. Especially when the server communicate with one or a few > clients where the "shared secret" is no problem. But especially in > these setups TLS client certificates could be used without any > problems. > What happens in your example when there is exploitable code in the client certificate parsing code? > Anyway, I am little bit ambivalent regarding this ID. It may help in > some situations and reduce the attack vector. Any effort to improve > the security should be reviewed! I mean if there are no negative > impacts: why not? ;-) > That was one of our thoughts as well. This does no harm to anyone and does help specific people who wish to use it. When combined with a secure protocols, it is even better. All the best, Jacob From nobody Tue Aug 19 10:21:21 2014 Return-Path: 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 EFF0A1A04DC; Tue, 19 Aug 2014 10:21:18 -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 j4XpM3H9wiAz; Tue, 19 Aug 2014 10:21:18 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71781A048D; Tue, 19 Aug 2014 10:21:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,896,1400050800"; d="scan'208";a="141013171" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 19 Aug 2014 10:21:18 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 19 Aug 2014 10:20:21 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 19 Aug 2014 10:20:20 -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; Tue, 19 Aug 2014 10:20:20 -0700 From: "Scheffenegger, Richard" To: Hagen Paul Pfeifer , "alfiej@fastmail.fm" Thread-Topic: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG Thread-Index: Ac+448Fsl9mI8tJfQO6l37mQPpygtgCOd38AABJQWoAADckrIP//pc+AgAEg4ACAAGEqkA== Date: Tue, 19 Aug 2014 17:20:19 +0000 Message-ID: <651312c598e44d05af8212c2eb691001@hioexcmbx05-prd.hq.netapp.com> References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/3YSSLEq70qyLw0R60KRgs2D1_d4 Cc: Christian Grothoff , "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 17:21:19 -0000 SGkgSGFnZW4sDQoNCj4gQW55d2F5LCBJIGFtIGxpdHRsZSBiaXQgYW1iaXZhbGVudCByZWdhcmRp bmcgdGhpcyBJRC4gSXQgbWF5IGhlbHAgaW4gc29tZQ0KPiBzaXR1YXRpb25zIGFuZCByZWR1Y2Ug dGhlIGF0dGFjayB2ZWN0b3IuIEFueSBlZmZvcnQgdG8gaW1wcm92ZSB0aGUNCj4gc2VjdXJpdHkg c2hvdWxkIGJlIHJldmlld2VkISBJIG1lYW4gaWYgdGhlcmUgYXJlIG5vIG5lZ2F0aXZlDQo+IGlt cGFjdHM6IHdoeSBub3Q/IDstKQ0KDQpJJ20gcmVsdWN0YW50IHRvIGNvbmNsdWRlIHRoYXQgdGhl cmUgYXJlIG5vIG5lZ2F0aXZlIGltcGFjdHMuDQoNCkFzIGFuIGV4YW1wbGUsIHRoaW5rIG9mIGEg bGlnaHR3ZWlnaHQgaHR0cCBzZXJ2ZXIgcnVubmluZyB0aGlzIG9uIGEgc2VydmVyLCBhbiBsZWdp bXRhdGUgY2xpZW50IChrbm93aW5nIHRoZSBzZWNyZXQpIHJ1bm5pbmcgb24gYSBzaW1pbGFyIGxl aWdodHdlaWdodCBjbGllbnQgd2l0aG91dCBUU29wdCBhbmQgb25seSB2ZXJ5IGZldyBlcGhlbWVy YWwgcG9ydHMuDQoNCkZvciBlYWNoIGh0dHAgc2Vzc2lvbiwgdGhlIHZlcnkgc2FtZSBJU04gd2ls bCBiZSByZS11c2VkIGZvciBldmVyeSBpZGVudGljYWwgc291cmNlIHBvcnQuIEluIHRoYXQgZW52 aW9ybm1lbnQgdGhlIGNoYW5jZXMgZm9yIGEgZGVsYXllZCBwYWNrZXQgdG8gY29ycnVwdCBhIFRD UCBzdHJlYW0gYXJlIG5vbi1uZWdsaWdpYmxlIGFueSBtb3JlLi4uICggdGhlIGludmVyc2Ugb2Yg dGhlIG51bWJlciBvZiBlcGhlbWVyYWwgc291cmNlIHBvcnRzIGF2YWlsYWJsZSkuDQoNCkFsc28s IHRoZSBjbGllbnQgd2lsbCBoYXZlIHRvIGRvIGEgZmFsbC1iYWNrIFNZTiB3aXRob3V0IFRTb3B0 LCBpZiBhbiBpbnRlcm1lZGlhdGUgbWVkZGxlYm94IG1vZGlmaWVzIHRoZSBUU29wdCBpbiBhbnkg d2F5OyBhbmQgYWNyb3NzIG5vcm1hbGl6ZXJzIChhbHNvIG5vdCBjb21wbGV0ZWx5IHVuY29tbW9u KSB0aGUgc2NoZW1lIGJyZWFrcyBkb3duLiBCdXQgdGhlbiwgdGhvc2UgbWVkZGxlYm94ZXMgc2hv dWxkbid0IHJlYWxseSBiZSBtZXNzaW5nIGFyb3VuZCB0byBiZWdpbiB3aXRoLi4uIDopDQoNCg0K SSBndWVzcyB3aGF0IEknbSBzYXlpbmcgaXMgdGhhdCBpZiBzb21lIHJhbmRvbW5lc3MgKGhpZ2gg b3JkZXIgYml0cykgY291bGQgYmUgbWFpbnRhaW5lZCBldmVuIHdoZW4gdGhlIDQtdHVwbGVzIGFy ZSBpZGVudGljYWwsIHRoYXQgd291bGQgYXQgbGVhc3QgYWRkcmVzcyB0aGlzIGNvbmNlcm4gKHN1 Y2ggc2Vzc2lvbnMgd291bGQgc3RpbGwgYmUgZGV0ZWN0YWJsZSwgYnkgY2hlY2tpbmcgaWYgdGhl IGxvdyBvcmRlciBiaXRzIGFyZSBpZGVudGljYWw7IHVubGVzcyB0aGVyZSBpcyBzb21lIGNsZXZl ciB3YXkgdG8gcmFuZG9tbHkgZGlzdHJpYnV0ZSB0aGUgaGFzaC1iaXRzIGFuZCByYW5kb20gYml0 cywgcGVyaGFwcyBhbHNvIGJhc2VkIG9uIGEgKGRpZmZlcmVudD8pIGhhc2ggb2YgdGhlIDQtdHVw bGUuLi4NCg0KDQpCZXN0IHJlZ2FyZHMsDQoNCg0KUmljaGFyZCBTY2hlZmZlbmVnZ2VyDQoNCg== From nobody Tue Aug 19 11:07:41 2014 Return-Path: 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 54D0F1A0684 for ; Tue, 19 Aug 2014 11:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 vK25rEBn8vvr for ; Tue, 19 Aug 2014 11:07:27 -0700 (PDT) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61AEC1A0665 for ; Tue, 19 Aug 2014 11:07:27 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id pv20so6280017lab.1 for ; Tue, 19 Aug 2014 11:07:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pmotbsUgAlQbsGxenyIVVMObpkAMjCWIKZeywVRO7c8=; b=NoSR/Zwsn/JdVuYLiHxM3pnl4WjNFn2lvjBC3WGTyoZsgpdDYyqloW2rlvgI769e7n kbcMcoBd1hSOSoRwRpBLkNkX64Yn2O25cQJIZkmBC5o5jz6JWGEvLummFHjJtQ7N04iE bEJc+vHSrDQhkRXI975zs0cDAYoaZv9wN/Evk2IJzFBCEyXHXxyvOCsW52j9QgWoec5X tDs1gOwEJweGh+ViIiGD8BM0wMZ4UTOOCt4W6VVd4wvdoRxo7pD7zF+H96tXs1gMS1mI 9Qswh+KwlNYgoAhS97jFxae71E4yiPQ2Nxxc9Xfx6eWoVGAsNT6pqtWTKU9sWtnOZwVS WJyg== X-Gm-Message-State: ALoCoQl0AysOowGrsfNLEKqUiLCJWBrtY/TUqEOMOj8+0psCz7Gwkq8eg2OixrB4CDgW+N9R+E+Z MIME-Version: 1.0 X-Received: by 10.152.87.97 with SMTP id w1mr11322668laz.92.1408471645560; Tue, 19 Aug 2014 11:07:25 -0700 (PDT) Received: by 10.152.242.42 with HTTP; Tue, 19 Aug 2014 11:07:25 -0700 (PDT) X-Originating-IP: [2a02:810d:740:57c:6a05:caff:fe03:ab31] In-Reply-To: References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> Date: Tue, 19 Aug 2014 20:07:25 +0200 Message-ID: From: Hagen Paul Pfeifer To: Jacob Appelbaum Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/j5ANa06k9xHQdxXxaODIu-XSyM0 Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch , Christian Grothoff , alfiej@fastmail.fm 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 18:07:29 -0000 On 19 August 2014 19:15, Jacob Appelbaum wrote: > No. I want to protect my TLS service from implementation exploitation. > You cannot probe my TLS service for the next heartbleed without a > shared secret. C'mon Jacob, this smells fishy! Let's assume you protect *your* service from one potential TLS bugs, this is (partly) possible with the mechanism described in the ID. But what happens in the meantime with your https:// browsing, openvpn, ... communications? If you assume bugs in TLS you must stop all your communications! TLS and strong cryptography is the fundamental building block - when it is broken the whole communication system is b0rken. The other way, if you trust TLS you can also trust the TLS client certificates mechanism as well. I understand your objection but the "fix" feels wrong. We should do everything we can to make TLS fast, clean and strong. But to repeat myself: I see advantages and benefits and _if_ there are no major disadvantages we can push things forward. Well, no need to answer here, I got your point in detail and I want to make sure we discuss all possibilities, using TLS client certificates is one alternative. > It isn't abuse - we're even trying to make it a standard to ensure > that it is well documented non-abusive behavior - rather different > than most other port knocking, I'd add. The ISN has 32 bits, reduce this space leads to problems in the past. We must do everything to not open any other attack vectors regarding TCP by mistake. If you *prove* that this will not lead to problems, I will never ever mention the word "abuse" in an email to you! ;-) Hagen From nobody Tue Aug 19 11:22:01 2014 Return-Path: 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 BCAC21A0690 for ; Tue, 19 Aug 2014 11:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 WaHL-9OrH-1X for ; Tue, 19 Aug 2014 11:21:55 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBCBE1A0691 for ; Tue, 19 Aug 2014 11:21:54 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id x3so6519770qcv.23 for ; Tue, 19 Aug 2014 11:21:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J4r8TORtB2HPOD4IDVrrQ96vEQz66MP/wekmlodPW40=; b=eD5VbQRbU/Lc6ZK9EFEUki5qF2t1LKYVLcTP+pN9L285en0IL5naWtiVT3einqiVW9 vXV7mDavnBpEETHJFX0fnm53/0hqpZpqCUS43rFM2nk5Lx6lnB7Yz+kW8uuDMGAGgNL2 1Bf9AYvsZ8QAQWCqVKqVFvVKeYMBD/bwsZ/5j3VNjmFh1GwbzHXLftdCE+qPSqbpAAP0 X0uRy7nsb+uFVukZE0h0mjUANF13xWA9Upv//hmnavxCxWSd1iO3a3/q2x27RPHv/kJe oChJajsKa7T6LymtAHBBjGK3sPmvfMH4RpJb2UfA6V6XZENO4ZZVrq3deCV1rYVY+DzD W1tQ== X-Gm-Message-State: ALoCoQlCKscvvDRencgLbMOvFvWxlHMyIMoXRbDogZjSldL/F7mvVRPMbHf6bjZsRA3XZ5dxJnru MIME-Version: 1.0 X-Received: by 10.229.74.3 with SMTP id s3mr8521005qcj.2.1408472512019; Tue, 19 Aug 2014 11:21:52 -0700 (PDT) Received: by 10.140.91.50 with HTTP; Tue, 19 Aug 2014 11:21:51 -0700 (PDT) X-Originating-IP: [89.207.128.241] In-Reply-To: References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> Date: Tue, 19 Aug 2014 18:21:51 +0000 Message-ID: From: Jacob Appelbaum To: Hagen Paul Pfeifer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/hJdjwpgxujbvMpOMsTFMGhUhFm8 Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch , Christian Grothoff , alfiej@fastmail.fm 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 18:21:56 -0000 On 8/19/14, Hagen Paul Pfeifer wrote: > On 19 August 2014 19:15, Jacob Appelbaum wrote: > >> No. I want to protect my TLS service from implementation exploitation. >> You cannot probe my TLS service for the next heartbleed without a >> shared secret. > > C'mon Jacob, this smells fishy! Let's assume you protect *your* > service from one potential TLS bugs, this is (partly) possible with > the mechanism described in the ID. But what happens in the meantime > with your https:// browsing, openvpn, ... communications? If you > assume bugs in TLS you must stop all your communications! TLS and > strong cryptography is the fundamental building block - when it is > broken the whole communication system is b0rken. No, it isn't. It isn't a zero sum game. We are trying to protect against people port scanning - that an authorized user may abuse a service is another issue - we do not protect against it, except that you may revoke that user's ability to exploit the service, of course. > > The other way, if you trust TLS you can also trust the TLS client > certificates mechanism as well. This is false. I use heartbleed as the example. > > I understand your objection but the "fix" feels wrong. We should do > everything we can to make TLS fast, clean and strong. But to repeat > myself: I see advantages and benefits and _if_ there are no major > disadvantages we can push things forward. Well, no need to answer > here, I got your point in detail and I want to make sure we discuss > all possibilities, using TLS client certificates is one alternative. > We should do both. It would be nice if TCP helped us with this realistic issue - services are exploitable, let us mitigate the problem with authentication for specific services at a different layer. We can authenticate the use of a service in a forward compatible manner and that is what the draft seeks to standardize. >> It isn't abuse - we're even trying to make it a standard to ensure >> that it is well documented non-abusive behavior - rather different >> than most other port knocking, I'd add. > > The ISN has 32 bits, reduce this space leads to problems in the past. > We must do everything to not open any other attack vectors regarding > TCP by mistake. If you *prove* that this will not lead to problems, I > will never ever mention the word "abuse" in an email to you! ;-) The ISN is still 32bits. We do not reduce the space and the entropy of the space does not change. There are corner cases where a passive observer may replay a packet as if it was normal TCP. Thus in the worst case, we're as bad as TCP is in every case, all the time. All the best, Jacob From nobody Tue Aug 19 12:00:36 2014 Return-Path: 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 22FB31A070B for ; Tue, 19 Aug 2014 12:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 e9rl0_yYgsH7 for ; Tue, 19 Aug 2014 12:00:10 -0700 (PDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6079A1A06FB for ; Tue, 19 Aug 2014 12:00:01 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id b17so6218879lan.39 for ; Tue, 19 Aug 2014 11:59:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=c3tVvZG8aMiNCzlOp2Jd/spZx4C7J+NRfjXvPmbitq8=; b=KF/Vol5aClRw8sRc5lHw9sLG84wrdMlkyjN4IoF+hy6H4UoDWnI1yVc4F+coQQ+JLW pjX/jud+91WIUnuvjddqWI93fQCSiL9TrUYma/OJU24KorchzOjZVtMmogGI5a8JCHNn 1gfzjlNx4DuBV9CYHHStLdWy3/KPYaj0GfzVXZtnaujx46sP9Igh5AOKtMrR+nZdMOex U+P6519cPYsD5ihUaw5zv06fPeqPwicVLAk5CBUxEKk2wxNSy5TEHgP9I3ooEGTQN0bI GUVBL0FPHvZx7myESENs5KBDwiwb+Wut6sTrfNIZbJn86EmBVNt1Kp7Dr2m40iNVyPUT CKNA== X-Gm-Message-State: ALoCoQmHU4ZTzTjSVT+XvojnnGXN6z35i8aKjgQ8H28pOgy2ISk0GgxlzA8J+EX43zFuDGQ2qJD8 MIME-Version: 1.0 X-Received: by 10.112.25.102 with SMTP id b6mr35797923lbg.17.1408474798532; Tue, 19 Aug 2014 11:59:58 -0700 (PDT) Received: by 10.152.242.42 with HTTP; Tue, 19 Aug 2014 11:59:58 -0700 (PDT) X-Originating-IP: [2a02:810d:740:57c:6a05:caff:fe03:ab31] In-Reply-To: <53F3970D.5080906@grothoff.org> References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <53F3970D.5080906@grothoff.org> Date: Tue, 19 Aug 2014 20:59:58 +0200 Message-ID: From: Hagen Paul Pfeifer To: Christian Grothoff Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/nVNCGMrnikFbAzxJWc5EHf3d7_k Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch , alfiej@fastmail.fm 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 19:00:18 -0000 On 19 August 2014 20:27, Christian Grothoff wrote: > You clearly also deliberately missunderstand the difference between > design / specification / mechanism, and the reality of an implementation. No, I don't. But you are right, we should talk about implementation issues. > Prove is a strong word. Now, I would not mind if the standard included > some strong wording on using a random TSval in combination with TCP > Stealth by default. But, as was pointed out, due to some NATs messing > with TSvals, we decided to keep it optional, as opposed to mandatory. > But I think that is a point I would be open to discuss, as it is really > a trade-off. TSvals *are* optional, you propose TCP stealth should depend on an "optional option"? I clearly see problems here because they can be filtered, disabled or simple the limited option space is exhausted by other options. What about PAWS? What about ISN duplicates and how are these handled (and differentiated)? Hagen From nobody Tue Aug 19 14:24:00 2014 Return-Path: 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 D1C481A6F58; Tue, 19 Aug 2014 14:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 m67cgEkFP6qQ; Tue, 19 Aug 2014 14:23:55 -0700 (PDT) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09B01A6F55; Tue, 19 Aug 2014 14:23:55 -0700 (PDT) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.80) (envelope-from ) id 1XJqsh-00089n-Cw; Tue, 19 Aug 2014 23:23:51 +0200 Date: Tue, 19 Aug 2014 23:23:51 +0200 From: Florian Westphal To: Jacob Appelbaum Message-ID: <20140819212351.GB11767@breakpoint.cc> References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/eMekVFMfEZcd-RV92tAIA93oWZ4 Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch , Christian Grothoff 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 21:23:59 -0000 Jacob Appelbaum wrote: > No. I want to protect my TLS service from implementation exploitation. > You cannot probe my TLS service for the next heartbleed without a > shared secret. So you won't accept e.g. smtp STARTTLS on your mail server? Also, once this becomes widespread, people will add --probe-all-isns switch to their port scanners.... It looks to me like this (I apologize In advance if this seems offensive): Q: - I want to run $service, but I don't want anyone to see it! A: - don't run it. Q: - But I need to access the service sometimes from random locations! A: - protect it with a password/some other form of secret. Q: - But then its visible to port scanners! A: - So what? Q: - But it allows people who have detected service presence to try running exploits against it! A: - If you really care, tunnel via ssh perhaps? Q: But I really really want to hide the presence of all services, i.e. all tcp ports should appear to be closed A1: - There are portknock schemes to add obfuscation if you really want this. Q: - But I cannot use portknocking because....? A: - ? I tried to find explanation in draft-kirsch-ietf-tcp-stealth-00, but did not find any. It talks about "pitfalls" of applications trying to "reimplement tcp in user space". Perhaps there should be a paragraph as to why ra But even assuming that there is a need for portknocking and/or TCP Stealth: - How does this relate to TCP-AO? (The draft mentions tcp md5sig only, then disregards it as it doesn't work in NATted environments) [ I realize TCP AO has other issues esp. vs. the proposed stealth scheme, especially wrt. complexity. Anything else? ] Problems I see with the proposal (ignoring the TCP related issues others pointed out and the "obscurity only" approach), and a few questions: - What about timing? I.e. is response time different regarding RST-from-closed-port vs. RST-from-stealth port? - e.g., are hosts required to perform authentication even for SYN-to-closed-port, etc? - Your adversary may be able to do full passive monitoring of all network traffic (also compare "replay" above), so whats the purpose of "avoiding" active scans? - Key Propagation (either your group is very very small, or I can probably find the secret-secret-word via a web search...) - Seems most services cannot use it since they have to accept connections from (almost) anyone In fact, this is one of the main problems that I see with the proposal; its use seems severely limited; up to the point where its unusable in practice. Perhaps it would help to show specific usage examples of how this would be deployed/where this is usable? > > Another objection: the mechanism help only for a small fraction of use > > cases. Especially when the server communicate with one or a few > > clients where the "shared secret" is no problem. But especially in > > these setups TLS client certificates could be used without any > > problems. > > > > What happens in your example when there is exploitable code in the > client certificate parsing code? "What happens in your example when there is exploitable code in the payload protection verification?" [ Its rhetoric question. I am aware of complexity difference. The point is, do your really think its worth to add yet another layer -- which can have issues both in the specification and the implementation -- rather than e.g. slim down/fix security transport protocol specs and implementations? ] Else, I guess I could argue that running your service via SCTP is "more secure" since its "less likely to be found in scan..." From nobody Tue Aug 19 16:40:38 2014 Return-Path: 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 C38BC1A6FDD; Tue, 19 Aug 2014 16:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, SPF_HELO_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 VXGCN-kUU2cb; Tue, 19 Aug 2014 16:40:35 -0700 (PDT) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936571A6FDA; Tue, 19 Aug 2014 16:40:35 -0700 (PDT) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.80) (envelope-from ) id 1XJt0w-0008Rd-4t; Wed, 20 Aug 2014 01:40:30 +0200 Date: Wed, 20 Aug 2014 01:40:30 +0200 From: Florian Westphal To: Christian Grothoff Message-ID: <20140819234030.GC11767@breakpoint.cc> References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <20140819212351.GB11767@breakpoint.cc> <53F3C75F.4030407@grothoff.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F3C75F.4030407@grothoff.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ZUw8d4XzehTUBq5r6_9SxpzL47w Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 23:40:36 -0000 Christian Grothoff wrote: > On 08/19/2014 11:23 PM, Florian Westphal wrote: > > Jacob Appelbaum wrote: > >> No. I want to protect my TLS service from implementation exploitation. > >> You cannot probe my TLS service for the next heartbleed without a > >> shared secret. > > > > So you won't accept e.g. smtp STARTTLS on your mail server? > > > > Also, once this becomes widespread, people will add > > --probe-all-isns switch to their port scanners.... > > If that makes port scanning 2 billion times more expensive, great. > As we said, that would really Knock down the HACIENDA-style ultra-large > scale port scanning of machines. So if we get there, for TCP Stealth > that would be mission accomplished. Sorry, I think this is a very very poor motivation for an extension of a widely deployed protocol that will have to be maintained forever, especially given that your "ultra large scale port scanning machines" would just be turned into "ultra large scale 3-way-handshake monitoring machines" (although I am sympathetic to the cause). > > It looks to me like this (I apologize In advance if this seems > > offensive): > > > > Q: - I want to run $service, but I don't want anyone to see it! > > A: - don't run it. > > > > Q: - But I need to access the service sometimes from random locations! > > A: - protect it with a password/some other form of secret. > > Sorry, did you even see the NSA slide with the brute-forcing of > passwords? Are _all_ of your passwords longer and/or more complex than > those shown there? It depends on the value of the service the password is for. > enough, please make sure the same applies to everyone else administering > systems on the planet. You cannot? Then help us deploy TCP Stealth. Sorry, but I don't see how "everyone administering systems on the planet" would be capable of using Stealth-TCP, even assuming everyone would want to use it if implemented. > > Q: - But then its visible to port scanners! > > A: - So what? > > So what? Then the GCHQ/NSA will use TAO-developed or purchased 0-day > attacks to turn me into an ORB, I don't like my machine to be turned > into an CSEC-bot that then attacks other systems. You may think that > doesn't matter, but I do. Well, I don't want that either. But I don't see how STEALTH helps me preventing that. > I do really care. But they do scan for SSH (did you see the slides?). So > what if they have an undisclosed vulnerability for SSH? Then criminals can break into my system. Again, I fail to understand/see how TCP Stealth would help. I could use stealth to protect vs. sshd pre-authentication bugs. I cannot use TCP stealth to protect against bugs in the TLS implementation. > > Q: But I really really want to hide the presence of all services, > > i.e. all tcp ports should appear to be closed > > > > A1: - There are portknock schemes to add obfuscation if you really want > > this. > > Yes, and TCP Stealth provides a standardized port knocking method that > works reasonably well with NAT and is not easy to detect, so I really > want this. > > > Q: - But I cannot use portknocking because....? > > A: - ? > > > > I tried to find explanation in draft-kirsch-ietf-tcp-stealth-00, > > but did not find any. It talks about "pitfalls" of applications > > trying to "reimplement tcp in user space". Perhaps there > > should be a paragraph as to why ra > > ? Ugh. Sorry. Fat fingers. ... as to why other methods, such as traditional port knocking, or restricting access by IP, or a source otherwise authenticated, e.g. TCP-AO, TCP-CRYPT, IPSEC, etc. are infeasible/lacking compared to Stealth-TCP. > > But even assuming that there is a need for portknocking and/or > > Problems I see with the proposal (ignoring the TCP related issues > > others pointed out and the "obscurity only" approach), > > Sorry, this is not "obscurity only", with a shared secret this is > defense in depth, not at all security by obscurity. Well, I agree its better than "rsh running on port 3242"... > A detailed > explanation of this point is in Julian's thesis. Fair enough. Lets assume I am wrong on the "obscurity" part. > > and a few questions: > > > > - What about timing? I.e. is response time different regarding > > RST-from-closed-port vs. RST-from-stealth port? > > First of all, that's an implementation issue, and one of the reasons why > this should be done in-kernel and with MD5. But yes, implementors > should be wary of timing attacks. If you're a standards writer you should consider the implementors to be clueless. If you think its important, consider using MUST in the spec (I am not specifically talking about stealth tcp here). > > - Your adversary may be able to do full passive monitoring of > > all network traffic (also compare "replay" above), so whats the purpose > > of "avoiding" active scans? > > Again, defense in depth. Not every adversary can do passive scans. Hmmm. In that case, I really hope this won't go far, sorry :-/ You talk about "state adversaries". a) How long do you think it takes these to deploy new technique for service discovery, e.g. via passive monitoring? b) How many services, in your opinion, will remain rechable -- by specific intent/requirement? c) how many feasible attack vectors remain to compromise a host even if you could not access a single service? My guesses are a) not much b) a h*ll of a lot c) too many, probably Perhaps I am too pessimistic but I think you'll lose on the ground that this game is rigged from the start. To me problem statement is: The networks I am connected to are widely used by criminals trying to obtain access to my systems abusing the services that I provide, and running latest versions is insufficent as these criminals might be in possession of 0-day exploits. I am afraid the only working solution to this scenario is don't use the same network For the scenarios you described above, e.g. IPsec could be used to form a private network used only by trusted parties. > > - Key Propagation (either your group is very very small, or I can > > probably find the secret-secret-word via a web search...) > > Yes, the group should be small. Or you could use the GNU Name System to > share the secret securely via the name system, but that's way too > radical for IETF at this time. Hm, not following here. Are you proposing GNS as a possible side channel to share secret among the trusted parties? > > Perhaps it would help to show specific usage examples > > of how this would be deployed/where this is usable? > > I login into my machine at my office via SSH dozens of times a day from > all over the world. I am the only user. TBH I wouldn't care provided its kept updated & strong secret, simply on the grounds that I don't have any more trust in the underlying machine than in sshd. But ok. Yes, TCP Stealth would be suitable to hide sshd from "everyone else". > We run a build server farm, there are like five users. The handful of > build servers accesses the master server via HTTPS. Should be easy to restrict by source ip, right? But in case of dynamic addresses, ok. > I access my personal IMAPS server on another system also from all over > the planet, there are two other users of that IMAPS service. And > updating certificates and keys after Heartbleat knowing that my mail may > have been compromised in the meantime is not something I like. I don't like that either. But *especially* considering Heartbleed I think one should be very careful as to which features to add. > > [ Its rhetoric question. I am aware of complexity difference. The point > > is, do your really think its worth to add yet another layer -- which can > > have issues both in the specification and the implementation -- rather than > > e.g. slim down/fix security transport protocol specs and implementations? ] > > Once you have a secure transport protocol implementation with smaller > complexity than the TCP Stealth implementation and are getting it > universally deployed (including for legacy services), I'll concede your > point. Fair enough. Lets just say I dislike adding more features to already complex protocol stacks like tcp for this use case. From nobody Tue Aug 19 21:16:57 2014 Return-Path: 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 ; 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: References: Date: Tue, 19 Aug 2014 21:16:47 -0700 Message-ID: From: Yoshifumi Nishida To: Jacob Appelbaum Content-Type: multipart/alternative; boundary=001a11c3f4585c250f050107dfa0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/TmhV_2rV_nlDYWvYLlWCoA2ttI8 Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch , Christian Grothoff 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 04:16:54 -0000 --001a11c3f4585c250f050107dfa0 Content-Type: text/plain; charset=UTF-8 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 wrote: > On 8/15/14, Scheffenegger, Richard 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 > --001a11c3f4585c250f050107dfa0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jacob,

I've read the = draft. My concern is some middlebox update ISN (due to ISN randomizations o= r 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=3D2068834 ), you migh= t 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 ra= tio is too small to ignore.

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

Thank= s,
--
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 in= terest
> not only to the members of these two WGs;
>
> http://tools.ietf.org/html/draft-kirsch-ietf-tcp-stealt= h-00
>

Hi,

I'm one of the authors of the draft and I've cc'ed Christian wh= o 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.hei= se.de/ct/artikel/NSA-GCHQ-Das-HACIENDA-Programm-zur-Kolonisierung-des-Inter= net-2292574.html
(German)

> There seem to be at least two or three major issues that compromise ei= ther
> 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

--001a11c3f4585c250f050107dfa0-- From nobody Wed Aug 20 04:24:47 2014 Return-Path: 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 9505A1A020A; Wed, 20 Aug 2014 04:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.87 X-Spam-Level: X-Spam-Status: No, score=-4.87 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 gASqBcdHO4FI; Wed, 20 Aug 2014 04:24:42 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC011A0205; Wed, 20 Aug 2014 04:24:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,901,1400050800"; d="scan'208";a="339715209" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx1-out.netapp.com with ESMTP; 20 Aug 2014 04:24:43 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 20 Aug 2014 04:23:43 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 20 Aug 2014 04:23:42 -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 04:23:42 -0700 From: "Scheffenegger, Richard" To: Christian Grothoff , Jacob Appelbaum Thread-Topic: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG Thread-Index: Ac+448Fsl9mI8tJfQO6l37mQPpygtgCOd38AABJQWoAADckrIP//pc+AgAEg4ACAABUIgIAADnKAgAAFl4CAAAkYAIAAAS8A//9okZA= Date: Wed, 20 Aug 2014 11:23:41 +0000 Message-ID: <817214c2e5b444c7a780c1387e91da15@hioexcmbx05-prd.hq.netapp.com> References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <53F3970D.5080906@grothoff.org> <53F39FAC.9070500@grothoff.org> In-Reply-To: <53F39FAC.9070500@grothoff.org> 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/t_Q_CWHbSQMOQkn_qB9nrBwbQKA Cc: "tcpm \(tcpm@ietf.org\)" , "tcpinc@ietf.org" , Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 11:24:44 -0000 SmFjb2IsIENocmlzdGlhbiwNCg0KVG8gYWRkIHNvbWUgY29uc3RydWN0aXZlIGRpc2N1c3Npb24g cG9pbnRzOg0KDQoNCkFzIHRoZSBlZGl0b3Igb2YgUkZDNzMyMyAoc29vbiB0byBiZSByZWxlYXNl ZCksIHdoaWNoIGlzIHRoZSB1cGRhdGUgdG8gMTMyMywgYW5kIHRoZSBkaXNjdXNzaW9uIEkgbG9v a2VkIGF0IG92ZXIgYXQgaHR0cDovL3RocmVhZC5nbWFuZS5vcmcvZ21hbmUubGludXgubmV0d29y ay8yOTQzODYgYW5kIG9mIGNvdXJzZSBoZXJlLCBJIHdhcyB3b25kZXJpbmcgaWYgeW91IG1pZ2h0 IGhhdmUgaXQgYmFja3dhcmRzLi4uDQoNCg0KSSBoYXZlIG5vdCBzZWVuIGEgY29udmluY2luZyBl bm91Z2ggYXJndW1lbnQsIHRoYXQgcnVubmluZyBhIGZpeGVkIElTTiBmb3IgYSA0LXR1cGxlIGlz IHJlYWxseSBzYWZlLiAoQW5kIHllcywgcmUtdXNlIG9mIGEgNC10dXBsZSBzaG91bGQgYmUgcmFy ZSwgYnV0IGl0IGNhbiBoYXBwZW4pLg0KDQpBbHNvLCB5b3Ugd2FudCB0byBhZGQgc29tZSBhZGRp dGlvbmFsICJyYW5kb21uZXNzIiBieSBhZGRpbmcgdGhlIFRTdmFsIGludG8gdGhlIGhhc2gsIGlm IGF2YWlsYWJsZS4NCg0KSG93ZXZlciwgVFN2YWwgaXMgbm90IHJhbmRvbSwgaXQncyBpbiBtb3N0 IGltcGxlbWVudGF0aW9ucyBhIHByZXR0eSBhY2N1cmF0ZSB1cHRpbWUgaW5kaWNhdG9yICh0aGF0 IHRoaXMgaW4gaXRzZWxmIGlzIGEgYmFkIGlkZWEsIGlzIGtub3duIGZvciBhIGxvbmcgdGltZS4g VGhhdCBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvIHJhbmRvbWl6ZSB0aGUgVFN2YWwgaW4gdGhlIHNh bWUgd2F5IGFzIHRoZSBJU04gaXMgbm93IG11Y2ggbW9yZSBwcm9taW5lbnRseSBzdGF0ZWQgaW4g UkZDNzMyMykuDQoNCg0KU28sIEkgY291bGQgbm90IGhlbHAgbXlzZWxmIGZyb20gd29uZGVyaW5n LCBpZiB5b3UgaGF2ZW4ndCBnb3QgeW91ciBmaWVsZHMgYmFja3dhcmRzLi4uLg0KDQpJZiB5b3Ug d2FudCB1bmRldGVjdGFibGUga25vY2tpbmcsIHdoaWNoIGF1dGhlbnRpY2F0ZXMgYSBwYXJ0aWN1 bGFyIHVzZXIsIHdoeSBub3QgdHJhbnNwb3J0IHRoYXQgaGFzaCBhcyBUU3ZhbCAob3Igb3B0aW9u YWxseSwgdGhlIHVudXNlZC9lbXB0eSBUU2VjcjsgaG93ZXZlciwgdGhhdCB3b3VsZCBiZSBkZXRl Y3RhYmxlIHRvIHNvbWVvbmUgd2l0aCBhIHNuaWZmZXIsIGFzIGVhcmx5IFdpbjk1IGlzIG5vdCBy ZWFsbHkgdGhhdCBjb21tb24gYW55IG1vcmUpLiBUaGF0IHdvdWxkIGxlYXZlIFRDUCBJU04gYWxv bmUgIC0gYW5kIGFzIGEgdHJ1ZSBjb3JlIGNvbXBvbmVudCwgYXJndWluZyBmb3IgYSBtb2RpZmlj YXRpb24gdGhlcmUgaGFzIHRvIGNvbWUgd2l0aCB2ZXJ5IGdvb2QgYXJndW1lbnRzLiBBbHNvLCBp dCB3b3VsZCBzZXJ2ZSB0byByYW5kb21pemUgdGhlIFRTdmFsIC0gYXMgSVNOIGlzIHN1cHBvc2Vk IHRvIGJlIGNob29zZW4gcmFuZG9tbHkgLSB0aHVzIGhlbHAgY2xvc2UgYW5vdGhlciBpbmRpcmVj dCBleHBsb2l0IHZlY3Rvci4NCg0KQW5kIGFzIHlvdSBhbHJlYWR5IHN0YXRlZCB0aGF0IGNvbm5l Y3Rpb25zIGFjcm9zcyBNZWRkbGVib3hlcyAodGhvc2UgdGhhdCB0d2VhayBhcm91bmQgd2l0aCBJ U04gb3IgVFN2YWwpIGFyZSBvdXQgb2Ygc2NvcGUgYW5kIG1heSBmYWlsLCB5b3UgZG9uJ3QgcmVh bGx5IHJlZHVjZSB0aGUgcG9wdWxhdGlvbiBvZiBzZXNzaW9ucyB0aGF0IGNvdWxkIGJlbmVmaXQg ZnJvbSB0aGlzLg0KDQoNCkZpbmFsbHksIGFzIFRTb3B0IGlzIG9wdGlvbmFsLCBtb2RpZmljYXRp b25zIHRoZXJlIGhhdmUgYSBtdWNoIGxvd2VyIGJhciBmb3IgYWNjZXB0YW5jZSwgY29tcGFyZWQg dG8gYSBtb2RpZmljYXRpb24gbGlrZSB0aGUgSVNOOyBhIHNlcnZlciBpbXBsZW1lbnRpbmcgdGhl IHNjaGVtZSB3b3VsZCBzdGlsbCBiZSBmcmVlIHRvIHNpbGVudGx5IGRpc2NhcmQgVENQIFNZTnMg d2l0aG91dCBUU09wdCwgb3IgdGhlIHdyb25nIFRTdmFsIC8gVFNlY3IuLi4gKEFzIHlvdSBjb3Vs ZCBpbnN0cnVjdCB5b3VyIGZpcmV3YWxsIHRvIGJsb2NrIGVtcHR5LCBub24tcmVsYXRlZCBSU1Rz KS4gDQoNCkZpbmFsbHksIHRoZSBjb21iaW5hdGlvbiBvZiBUU3ZhbC9UU2VjciB3b3VsZCB5aWVs ZCA2NCBiaXRzLCBidHcuIEJ1dCBvbmx5IG9uIHRoZSBTWU4uLi4NCg0KDQoNCg0KDQpSaWNoYXJk IFNjaGVmZmVuZWdnZXINCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogQ2hyaXN0aWFuIEdyb3Rob2ZmIFttYWlsdG86Y2hyaXN0aWFuQGdyb3Rob2ZmLm9yZ10NCj4g U2VudDogRGllbnN0YWcsIDE5LiBBdWd1c3QgMjAxNCAyMTowNA0KPiBUbzogSGFnZW4gUGF1bCBQ ZmVpZmVyDQo+IENjOiBKYWNvYiBBcHBlbGJhdW07IGFsZmllakBmYXN0bWFpbC5mbTsgU2NoZWZm ZW5lZ2dlciwgUmljaGFyZDsNCj4gdGNwaW5jQGlldGYub3JnOyB0Y3BtICh0Y3BtQGlldGYub3Jn KTsgSm9lIFRvdWNoDQo+IFN1YmplY3Q6IFJlOiBbdGNwbV0gW3RjcGluY10gVENQIFN0ZWFsdGgg LSBwb3NzaWJsZSBpbnRlcmVzdCB0byB0aGUgV0cNCj4gDQo+IE9uIDA4LzE5LzIwMTQgMDg6NTkg UE0sIEhhZ2VuIFBhdWwgUGZlaWZlciB3cm90ZToNCj4gPiBPbiAxOSBBdWd1c3QgMjAxNCAyMDoy NywgQ2hyaXN0aWFuIEdyb3Rob2ZmIDxjaHJpc3RpYW5AZ3JvdGhvZmYub3JnPg0KPiB3cm90ZToN Cj4gPg0KPiA+PiBZb3UgY2xlYXJseSBhbHNvIGRlbGliZXJhdGVseSBtaXNzdW5kZXJzdGFuZCB0 aGUgZGlmZmVyZW5jZSBiZXR3ZWVuDQo+ID4+IGRlc2lnbiAvIHNwZWNpZmljYXRpb24gLyBtZWNo YW5pc20sIGFuZCB0aGUgcmVhbGl0eSBvZiBhbg0KPiBpbXBsZW1lbnRhdGlvbi4NCj4gPg0KPiA+ IE5vLCBJIGRvbid0LiBCdXQgeW91IGFyZSByaWdodCwgd2Ugc2hvdWxkIHRhbGsgYWJvdXQgaW1w bGVtZW50YXRpb24NCj4gaXNzdWVzLg0KPiA+DQo+ID4+IFByb3ZlIGlzIGEgc3Ryb25nIHdvcmQu ICBOb3csIEkgd291bGQgbm90IG1pbmQgaWYgdGhlIHN0YW5kYXJkIGluY2x1ZGVkDQo+ID4+IHNv bWUgc3Ryb25nIHdvcmRpbmcgb24gdXNpbmcgYSByYW5kb20gVFN2YWwgaW4gY29tYmluYXRpb24g d2l0aCBUQ1ANCj4gPj4gU3RlYWx0aCBieSBkZWZhdWx0LiAgQnV0LCBhcyB3YXMgcG9pbnRlZCBv dXQsIGR1ZSB0byBzb21lIE5BVHMgbWVzc2luZw0KPiA+PiB3aXRoIFRTdmFscywgd2UgZGVjaWRl ZCB0byBrZWVwIGl0IG9wdGlvbmFsLCBhcyBvcHBvc2VkIHRvIG1hbmRhdG9yeS4NCj4gPj4gQnV0 IEkgdGhpbmsgdGhhdCBpcyBhIHBvaW50IEkgd291bGQgYmUgb3BlbiB0byBkaXNjdXNzLCBhcyBp dCBpcyByZWFsbHkNCj4gPj4gYSB0cmFkZS1vZmYuDQo+ID4NCj4gPiBUU3ZhbHMgKmFyZSogb3B0 aW9uYWwsIHlvdSBwcm9wb3NlIFRDUCBzdGVhbHRoIHNob3VsZCBkZXBlbmQgb24gYW4NCj4gPiAi b3B0aW9uYWwgb3B0aW9uIj8NCj4gDQo+IFdoYXQgSSBzYWlkIGlzIHRoYXQgaWYgcG9zc2libGUs IGNsaWVudHMgc2hvdWxkIHVzZSBUQ1Agc3RlYWx0aCBpbg0KPiBjb21iaW5hdGlvbiB3aXRoIHRo aXMgb3B0aW9uYWwgb3B0aW9uLiBBcyBpdCBpcyBhbiBvcHRpb24sIHdlIGRpZCBub3QNCj4gbWFr ZSBpdCBtYW5kYXRvcnksIGJ1dCBJIHRoaW5rIGl0IGlzIHRvdGFsbHkgYWNjZXB0YWJsZSB0byBy ZWNvbW1lbmQNCj4gdXNpbmcgdGhlIG9wdGlvbi4NCj4gDQo+ID4gSSBjbGVhcmx5IHNlZSBwcm9i bGVtcyBoZXJlIGJlY2F1c2UgdGhleSBjYW4gYmUNCj4gPiBmaWx0ZXJlZCwgZGlzYWJsZWQgb3Ig c2ltcGxlIHRoZSBsaW1pdGVkIG9wdGlvbiBzcGFjZSBpcyBleGhhdXN0ZWQgYnkNCj4gPiBvdGhl ciBvcHRpb25zLg0KPiANCj4gV2UgZG8gaGF2ZSBhIG1lYXN1cmVtZW50IHN0dWR5IG9uIHRoaXMg aW4gSnVsaWFuJ3MgbWFzdGVyJ3MgdGhlc2lzLiBZZXMsDQo+IGl0IGRvZXMgaGFwcGVuLCBidXQg aXQgaXMgdW5jb21tb24uDQo+IA0KPiA+IFdoYXQgYWJvdXQgUEFXUz8gV2hhdCBhYm91dCBJU04g ZHVwbGljYXRlcyBhbmQgaG93IGFyZQ0KPiA+IHRoZXNlIGhhbmRsZWQgKGFuZCBkaWZmZXJlbnRp YXRlZCk/DQo+IA0KPiBXZSBkaXNjdXNzIFRDUCBTWU4gcmV0cmFuc21pc3Npb25zIGluIHRoZSBk cmFmdC4NCg== From nobody Wed Aug 20 05:03:20 2014 Return-Path: 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 659801A0282 for ; Wed, 20 Aug 2014 05:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 U3AzNBX8zCs8 for ; Wed, 20 Aug 2014 05:03:14 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22491A0277 for ; Wed, 20 Aug 2014 05:03:13 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id l4so6746924lbv.30 for ; Wed, 20 Aug 2014 05:03:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fMh6ruEo8cgo7pPezgFMwMuUNss+o5acSVuSTf4Viy8=; b=NFBk+1OHzWMQzUFkwszjZh0sWU1ghCqUwNRPurjIdfRHf7f6zjP5IqeZTcPltsvs3w HFJyqWTvf0JaieTHPwXy8Wjcbz+hhObdVVGIoLDe4dZ9QRD5B2QdKTHS3Dbiow3HDIFz cRwLKoGIUlzoN17QQnwBrieN4wR+1BhgPXrh5PxjvAqsPbO2YGh63s16mzFsKE1lwipU QoFGYGI9GF7vMA6UNHkYMgoYye1uL69ukWMkoKDlzOVJWlnCnaIiNoZQWqFScxxX5BCA rOiUsu8tL0M5Jx0YRgpJmAt1fmlzlGUogpYLjLXJay6QYqvIAu0HjMx/5dbAm/92xmL5 esRw== X-Gm-Message-State: ALoCoQnqHf4RpCWIN/NzndCjWL1/B4Kf59D2K3UeqQaufBL0XN6zQk6ePWUP3MCfTz8ReDnwyBTQ MIME-Version: 1.0 X-Received: by 10.112.34.47 with SMTP id w15mr9621926lbi.84.1408536192041; Wed, 20 Aug 2014 05:03:12 -0700 (PDT) Received: by 10.152.242.42 with HTTP; Wed, 20 Aug 2014 05:03:11 -0700 (PDT) X-Originating-IP: [80.246.32.33] In-Reply-To: <817214c2e5b444c7a780c1387e91da15@hioexcmbx05-prd.hq.netapp.com> References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <53F3970D.5080906@grothoff.org> <53F39FAC.9070500@grothoff.org> <817214c2e5b444c7a780c1387e91da15@hioexcmbx05-prd.hq.netapp.com> Date: Wed, 20 Aug 2014 14:03:11 +0200 Message-ID: From: Hagen Paul Pfeifer To: "Scheffenegger, Richard" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/0IIZsFX4r45EdU0sRI-gRUmXX1M Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch , Christian Grothoff 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 12:03:16 -0000 On 20 August 2014 13:23, Scheffenegger, Richard wrote: > If you want undetectable knocking, which authenticates a particular user,= why not transport that hash as TSval (or optionally, the unused/empty TSec= r; however, that would be detectable to someone with a sniffer, as early Wi= n95 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 e= xploit 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 From nobody Wed Aug 20 05:14:24 2014 Return-Path: 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 C3AFD1A02DB; Wed, 20 Aug 2014 05:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.97 X-Spam-Level: X-Spam-Status: No, score=-6.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, 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 u3Spq51Off0A; Wed, 20 Aug 2014 05:14:18 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35AA41A02DD; Wed, 20 Aug 2014 05:14:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,901,1400050800"; d="scan'208";a="141171891" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 20 Aug 2014 05:14:04 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by vmwexceht06-prd.hq.netapp.com (10.106.77.104) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 20 Aug 2014 05:13:05 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 20 Aug 2014 05:13:04 -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:13:04 -0700 From: "Scheffenegger, Richard" To: Christian Grothoff , Jacob Appelbaum Thread-Topic: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG Thread-Index: Ac+448Fsl9mI8tJfQO6l37mQPpygtgCOd38AABJQWoAADckrIP//pc+AgAEg4ACAABUIgIAADnKAgAAFl4CAAAkYAIAAAS8A//9okZCAAbIzAIAAct2g Date: Wed, 20 Aug 2014 12:13:03 +0000 Message-ID: <566aa460cc4b48658337d94f41843db1@hioexcmbx05-prd.hq.netapp.com> References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <53F3970D.5080906@grothoff.org> <53F39FAC.9070500@grothoff.org> <817214c2e5b444c7a780c1387e91da15@hioexcmbx05-prd.hq.netapp.com> <53F48CE0.1020507@grothoff.org> In-Reply-To: <53F48CE0.1020507@grothoff.org> 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/rLBJA0LOmHi2IsuN9vSAhB6Q-_s Cc: "tcpm \(tcpm@ietf.org\)" , "tcpinc@ietf.org" , Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 12:14:20 -0000 SGkgQ2hyaXN0aWFuLA0KDQo+ID4gQWxzbywgeW91IHdhbnQgdG8gYWRkIHNvbWUgYWRkaXRpb25h bCAicmFuZG9tbmVzcyIgYnkgYWRkaW5nIHRoZSBUU3ZhbA0KPiA+IGludG8gdGhlIGhhc2gsIGlm IGF2YWlsYWJsZS4NCj4gDQo+IFdlIGRvIHRoYXQsIGRpZCB5b3UgZXZlbiByZWFkIHRoZSBkcmFm dD8NCg0KDQpJIGRpZCwgYnV0IG15IHdvcmRpbmcgd2FzIHVuZm9ydHVuYXRlOyBMZXQgbWUgcmVw aHJhc2U6IFRoZSB1c2Ugb2YgVFNvcHQgaXMgb3B0aW9uYWwgaW4geW91ciBkcmFmdC4gV2h5IG5v dCBtYWtlIGl0IG1hbmRhdG9yeT8NCg0KDQo+IA0KPiA+IEhvd2V2ZXIsIFRTdmFsIGlzIG5vdCBy YW5kb20sIGl0J3MgaW4gbW9zdCBpbXBsZW1lbnRhdGlvbnMgYSBwcmV0dHkNCj4gPiBhY2N1cmF0 ZSB1cHRpbWUgaW5kaWNhdG9yICh0aGF0IHRoaXMgaW4gaXRzZWxmIGlzIGEgYmFkIGlkZWEsIGlz IGtub3duDQo+ID4gZm9yIGEgbG9uZyB0aW1lLiBUaGF0IGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8g cmFuZG9taXplIHRoZSBUU3ZhbCBpbg0KPiA+IHRoZSBzYW1lIHdheSBhcyB0aGUgSVNOIGlzIG5v dyBtdWNoIG1vcmUgcHJvbWluZW50bHkgc3RhdGVkIGluDQo+ID4gUkZDNzMyMykuDQo+IA0KPiBX ZSBkbyBhZ3JlZSB0aGF0IHRoZSBUU3ZhbCBzaG91bGQgYmUgcmFuZG9taXplZC4NCj4gPiANCj4g UmlnaHQgbm93LCBUU3ZhbCBpcyByYXJlbHkgY2hvc2VuIGF0IHJhbmRvbSBieSBpbXBsZW1lbnRh dGlvbnMgKHNlZSBvdXINCj4gbWVhc3VyZW1lbnQgc3R1ZHkgaW4gSnVsaWFuJ3MgdGhlc2lzKS4g IFNvIHB1dHRpbmcgdGhlIGF1dGhlbnRpY2F0b3IgaW50bw0KPiB0aGUgVFN2YWwgd291bGQgaGF2 ZSBwcm92aWRlZCBhbiBlYXN5IGRpc3Rpbmd1aXNoZXIsIHdoaWNoIHdlIHdhbnRlZCB0bw0KPiBh dm9pZC4gIEhvd2V2ZXIsIEkgd291bGQgaW4gcHJpbmNpcGxlIHN1cHBvcnQgX2Fsc29fIHVzaW5n IHRoZSBUU3ZhbCwgdGhhdA0KPiB3YXkgd2UgY291bGQgZ2V0IDY0IGJpdHMuICBCdXQsIGFzIHNh aWQgYmVmb3JlLCB0aGlzIGlzIGEgdHJhZGUtb2ZmIHdpdGgNCj4gcmVzcGVjdCB0byBob3cgbWFu eSBtaWRkbGVib3hlcyB3aWxsIHdvcmssIGFzIHNvbWUgZmlkZGxlIHdpdGggVFN2YWwgYnV0DQo+ IG5vdCB0aGUgSVNOIChhbmQgdmljZSB2ZXJzYSkuDQoNCldlbGwsIE9wZW5CU0QgZG9lcyBwcm9w ZXIgcmFuZG9taXphdGlvbjsgYWxzbywgd2hlbiBzb21lb25lIGZvbGxvd3MgUkZDNzMyMywgcHJv cGVyIHJhbmRvbWl6YXRpb24gb2YgVFN2YWwgc2hvdWxkIGJlY29tZSB0aGUgbm9ybSBvdmVyIHRp bWUuLi4gQW5kIGFzIHlvdSBtZW50aW9uZWQgZWFybGllciwgZnVsbCBwcm90ZWN0aW9uIGFnYWlu c3Qgc29tZW9uZSBhYmxlIHRvIGJvdGggc25pZmYgYW5kIHNlbGVjdGl2ZWx5IGRyb3AgcGFja2V0 cyBpcyBub3QgaW50ZW5kZWQsIGlmIEkgcmVhZCB0aGUgZHJhZnQgY29ycmVjdGx5Lg0KDQogDQo+ IFJpZ2h0LCBidXQgdGhlIFNZTiBpcyB3aGF0IG1hdHRlcnMgbW9zdCBJTU8uICBXZSBjb3VsZCB1 c2UgMzIgYml0cyBvZiB0aGUNCj4gSVNOIGZvciB0aGUgY29udGVudCBpbnRlZ3JpdHkgcHJvdGVj dG9yLCBhbmQgYW5vdGhlciAzMiBiaXRzIG9mIHRoZQ0KPiB0aW1lc3RhbXAgZm9yIHRoZSBhdXRo ZW50aWNhdG9yIHBhcnQsIHRoYXQgd291bGQgYmUgZmluZS4gIEJ1dCwgYXMgSSBzYWlkLA0KPiB0 aGUgcHJvYmxlbSBpcyB0aGF0IHRoaXMgbWVhbnMgdGhhdCBoYW5kc2hha2VzIGRvaW5nIHNvIHdv dWxkIHN0YW5kIG91dA0KPiBmcm9tIGN1cnJlbnQgdHJhZmZpYy4gIFNvIHJlYWxseSB0aGlzIGlz IGEgYml0IG9mIGEgdHJhZGUtb2ZmIGJldHdlZW4NCj4gcGFzc2l2ZSBkZXRlY3Rpb24gb2YgdGhl IGtub2NrIGluIHRoZSBjdXJyZW50IGVudmlyb25tZW50IGFuZCBnZXR0aW5nIGENCj4gZmV3IG1v cmUgYml0cyBvZiBzZWN1cml0eS4NCg0KTm90aGluZyByZWFsbHkgcHJldmVudHMgeW91IGZyb20g bWFuZGF0aW5nIGEgU1lOK1RTT1BUIGFzIGJhc2lzIGZvciBUQ1AgU3RlYWx0aC4gV2hlbiBwdXR0 aW5nIHRoZSBhdXRoZW50aWNhdG9yIGludG8gVFN2YWwgKHdpdGggSVNOIGFzIGFkZGl0aW9uYWwg Yml0cyBvZiByYW5kb21uZXNzKSwgYWxsIHRob3NlIHNlc3Npb25zIGRvbid0IGxvb2sgYW55IGRp ZmZlcmVudCBmcm9tIGFuIE9wZW5CU0QgYm94IGNvbm5lY3RpbmcgLSBleGNlcHQgZm9yIHNvbWUg cGFzc2l2ZSBUQ1Agb3B0aW9uIGZpbmdlcnByaW50aW5nIHBlcmhhcHMuIEJ1dCBhZ2FpbiwgYWxs IHlvdSB3YW50IHRvIGRvIGlzIG5vdCByZWFjdCB0byBTWU5zIGZyb20gcGVvcGxlIHRoYXQgY2Fu IG5vdCBvYnNlcnZlIGFuZCBtZWRkbGUgd2l0aCBmdW5jdGlvbmluZyBzZXNzaW9ucyBiZXR3ZWVu IHR3byB0aGlyZCBwYXJ0aWVzLi4uDQoNCg0KPiBBbm90aGVyIGlzc3VlIG1heWJlIHRoYXQgc29t ZSBjdXJyZW50IE9TZXMgZG9uJ3QgdXNlIFRTdmFsIGF0IGFsbCwgc28gSQ0KPiBmaWd1cmVkIGp1 c3QgY2hhbmdpbmcgdGhlIElTTiBjYWxjdWxhdGlvbiBtaWdodCBiZSB0aGUgbW9yZSBjb25zZXJ2 YXRpdmUNCj4gc3VnZ2VzdGlvbiwgYnV0IGFnYWluLCB0aGlzIGlzIGNsZWFybHkgYSB0cmFkZS1v ZmYgYW5kIGlmIElFVEYgZGVjaWRlZCB0bw0KPiBpbnN0ZWFkIHRvIElTTitUU3ZhbCBvciBldmVu IGp1c3QgVFN2YWwsIEkgd291bGQgc3RpbGwgY29uc2lkZXIgdGhpcyBhIGJpZw0KPiBwcm9ncmVz cy4NCg0KSSdkIGJlIGluIGZ1bGwgc3VwcG9ydCBmb3IgeW91ciBwcm9wb3NhbCwgd2hlbiBJU04g aXMga2VwdCB1bm1vZGlmaWVkLCBhbmQgdGhlIGF1dGhlbnRpY2F0b3IgYml0cyBwdXQgaW50byBU U3ZhbCBvciBUU2VjciBvZiBhIFNZTi4gQWdhaW4sIHB1dHRpbmcgYml0cyBpbiBUU2VjciB3b3Vs ZCBtYWtlIHlvdXIgdHJhZmZpYyBzdGFuZCBvdXQsIG5vdCB0aGF0IHRob3NlIGltcGxlbWVudGF0 aW9ucyB0aGF0IHdlcmUgYnJva2VuIGluIHRoYXQgcmVzcGVjdCwgaGF2ZSB2YW5pc2hlZC4NCg0K QmVzdCByZWdhcmRzLA0KICAgUmljaGFyZA0KDQo= From nobody Wed Aug 20 05:22:39 2014 Return-Path: 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" To: Hagen Paul Pfeifer 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: References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <53F3970D.5080906@grothoff.org> <53F39FAC.9070500@grothoff.org> <817214c2e5b444c7a780c1387e91da15@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: 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" , "tcpm \(tcpm@ietf.org\)" , Joe Touch , Christian Grothoff 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 12:22:38 -0000 SGkgSGFnZW4sDQoNCkFjdHVhbGx5LCB0aGUgaW5pdGlhdG9yIChzZW5kZXIpIG9mIGEgc2Vzc2lv biBjb3VsZCByb2xsIHRoZSBkaWNlIG11bHRpcGxlIHRpbWVzIChzZWxlY3QgZGlmZmVyZW50IElT TnMpLCB1bnRpbCB0aGUgaGFzaGVkIFRTb3B0IGZ1bGZpbGxzIHRoZSBQQVdTIHJlcXVpcmVtZW50 IG9mIGJlaW5nIGxhcmdlciB0aGFuIHRoZSBsYXN0IFRTb3B0IHNlbnQgaW4gdGhlIHByZXZpb3Vz IHNlc3Npb24gdG8gdGhhdCBob3N0L3BvcnQvNC10dXBsZS4uLiANCg0KV291bGQgcmVxdWlyZSBh IGJpdCBtb3JlIHN0YXRlIHdpdGhpbiB0aGF0IGhvc3QsIGJ1dCB3b3VsZCBiZSBtYW5hZ2VhYmxl ICh1c2luZyB0aGUgc3lzdGVtIHVwdGltZSByZWFsbHkgYWx3YXlzIHdhcyBhIGtsdWRnZSBJTUhP ICkuDQoNCg0KVG8gcGFyYXBocmFzZToNClRTZWNyIFNIT1VMRCBiZSB6ZXJvIG9uIFNZTiwgKGV2 ZW4gdGhvdWdoIHNvbWUgaW1wbGVtZW50YXRpb25zIGRpZG4ndCBhZGhlcmUgdG8gdGhpcyksIGFu ZCBNVVNUIE5PVCBiZSBpbnRlcnByZXRlZCB3aGVuIEFDSyBpcyBub3Qgc2V0LiAgDQoNCkluIG15 IG9waW5pb24sIHRoZSBvbmx5IHJlYXNvbiB0byBub3QgdXNlIHRoZSBUU29wdC9UU2VjciBjb21i aW5hdGlvbiB3b3VsZCBiZSB0byBoYXZlIHRoaXMgc3RlZ2Fub2dyYXBoaWMgcHJvcGVydHkgdG8g bWlzbGVhZCBhIG1vcmUgYWR2YW5jZWQgYWR2ZXJzYXJ5IHRoYXQgY2FuIHNuaWZmIHRyYWZmaWMg aW4gYmV0d2VlbiB0d28gdGhpcmQgcGFydGllcy4NCg0KDQoNClJpY2hhcmQgU2NoZWZmZW5lZ2dl cg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEhhZ2VuIFBhdWwgUGZl aWZlciBbbWFpbHRvOmhhZ2VuQGphdXUubmV0XQ0KPiBTZW50OiBNaXR0d29jaCwgMjAuIEF1Z3Vz dCAyMDE0IDE0OjAzDQo+IFRvOiBTY2hlZmZlbmVnZ2VyLCBSaWNoYXJkDQo+IENjOiBDaHJpc3Rp YW4gR3JvdGhvZmY7IEphY29iIEFwcGVsYmF1bTsgYWxmaWVqQGZhc3RtYWlsLmZtOw0KPiB0Y3Bp bmNAaWV0Zi5vcmc7IHRjcG0gKHRjcG1AaWV0Zi5vcmcpOyBKb2UgVG91Y2gNCj4gU3ViamVjdDog UmU6IFt0Y3BtXSBbdGNwaW5jXSBUQ1AgU3RlYWx0aCAtIHBvc3NpYmxlIGludGVyZXN0IHRvIHRo ZSBXRw0KPiANCj4gT24gMjAgQXVndXN0IDIwMTQgMTM6MjMsIFNjaGVmZmVuZWdnZXIsIFJpY2hh cmQgPHJzQG5ldGFwcC5jb20+IHdyb3RlOg0KPiANCj4gPiBJZiB5b3Ugd2FudCB1bmRldGVjdGFi bGUga25vY2tpbmcsIHdoaWNoIGF1dGhlbnRpY2F0ZXMgYSBwYXJ0aWN1bGFyDQo+IHVzZXIsIHdo eSBub3QgdHJhbnNwb3J0IHRoYXQgaGFzaCBhcyBUU3ZhbCAob3Igb3B0aW9uYWxseSwgdGhlDQo+ IHVudXNlZC9lbXB0eSBUU2VjcjsgaG93ZXZlciwgdGhhdCB3b3VsZCBiZSBkZXRlY3RhYmxlIHRv IHNvbWVvbmUgd2l0aCBhDQo+IHNuaWZmZXIsIGFzIGVhcmx5IFdpbjk1IGlzIG5vdCByZWFsbHkg dGhhdCBjb21tb24gYW55IG1vcmUpLiBUaGF0IHdvdWxkDQo+IGxlYXZlIFRDUCBJU04gYWxvbmUg IC0gYW5kIGFzIGEgdHJ1ZSBjb3JlIGNvbXBvbmVudCwgYXJndWluZyBmb3IgYQ0KPiBtb2RpZmlj YXRpb24gdGhlcmUgaGFzIHRvIGNvbWUgd2l0aCB2ZXJ5IGdvb2QgYXJndW1lbnRzLiBBbHNvLCBp dCB3b3VsZA0KPiBzZXJ2ZSB0byByYW5kb21pemUgdGhlIFRTdmFsIC0gYXMgSVNOIGlzIHN1cHBv c2VkIHRvIGJlIGNob29zZW4gcmFuZG9tbHkgLQ0KPiB0aHVzIGhlbHAgY2xvc2UgYW5vdGhlciBp bmRpcmVjdCBleHBsb2l0IHZlY3Rvci4NCj4gDQo+IFNvdW5kcyBiZXR0ZXIgdGhlbiBtZXNzaW5n IHdpdGggdGhlIElTTi4gT25lIHNob3cgc3RvcHBlciBzdGlsbA0KPiBleGlzdHM6IHRoZSBUU3Zh bCBpcyByZXF1aXJlZCB0byBzdHJvbmcgbW9ub3RvbmljaXR5IGluY3JlYXNpbmcgZm9yIFBBV1MN Cj4gcHJvdGVjdGlvbi4gVG8gbG93ZXIgdGhlIGJhcnJpZXIgb25lIG1vcmUgdGltZTogd2h5IG5v dCBqdXN0IHVzZSBUU2Vjcj8NCj4gDQo+IFRoaXMgcmVsYXgganVzdCBuZWFybHkgYWxsIGhlYWRh Y2hlcyBhbmQgMzIgYml0cyBhcmUgc3RpbGwgZW5vdWdoIGZvciB0aGlzDQo+IG1lY2hhbmlzbT8h DQo+IA0KPiBIYWdlbg0K From nobody Wed Aug 20 05:33:13 2014 Return-Path: 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 D61041A02FC for ; Wed, 20 Aug 2014 05:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 m1lvutavKifu for ; Wed, 20 Aug 2014 05:33:11 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7E541A02E1 for ; Wed, 20 Aug 2014 05:33:10 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gl10so6979340lab.7 for ; Wed, 20 Aug 2014 05:33:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EZj+cV84IfHsw5Zus4Kr4CE3uYzUsCfsLTrKtN6ztC8=; b=gUc01zaW4GNHhSrY9vL18RVZqJd2gjRAIbi6V2/KgmSYiGzpbnZ8QSZUZEYg+MURJs d8fHfOARiB2h+PSNTZFa/M6tbl1zQ+7bsPbiwGez2vgI7GwBTaCej2iRC9PES7M10Wca q+2QZDYEa6NTTar854zECW9CR7fc8hL6iWU438JpQlhLNnT7mDIFr0Bt/V/OeReYqUNz gfzEXtcN2Avrz81shATOukwtDVLkBXTI5FW1uL6E31tKhjBVmol3OF588dQWdqlsnKqp tjTlw69mvb9FoyvxY14sZd0UXCAUy4qI+u2q8zIk6TGgvDJTvHmX2hPntGsbsk5zNP/f lQ3A== X-Gm-Message-State: ALoCoQld6SL4+rpiHVs60waqUHAeri1TDWZrg5fRugge5enkFc3d0WlpNllLDFqIJUWP8TdA2uzJ MIME-Version: 1.0 X-Received: by 10.112.52.130 with SMTP id t2mr25205468lbo.61.1408537986089; Wed, 20 Aug 2014 05:33:06 -0700 (PDT) Received: by 10.152.242.42 with HTTP; Wed, 20 Aug 2014 05:33:05 -0700 (PDT) X-Originating-IP: [80.246.32.33] In-Reply-To: References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <53F3970D.5080906@grothoff.org> <53F39FAC.9070500@grothoff.org> <817214c2e5b444c7a780c1387e91da15@hioexcmbx05-prd.hq.netapp.com> Date: Wed, 20 Aug 2014 14:33:05 +0200 Message-ID: From: Hagen Paul Pfeifer To: "Scheffenegger, Richard" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/YRwx1TuuNAPvyAwG63DfxjSPryw Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch , Christian Grothoff 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 12:33:12 -0000 On 20 August 2014 14:21, Scheffenegger, Richard wrote: > 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. Yes, my intention was the following: all currently discussed ideas "abuse" TCP fields in some way - they have a meaning, functionality. But touching TSecr in the initial SYN has no meaning, in particular it SHOULD be zero. Why not change this to something like this: the TSecr in the first packet can serve as a stealth cookie and could be any value. It is up to the implementation .... You know what I mean. Hagen From nobody Wed Aug 20 06:43:15 2014 Return-Path: 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 255731A039F for ; Wed, 20 Aug 2014 06:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 uIA33XuEn_L7 for ; Wed, 20 Aug 2014 06:43:09 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536CA1A038F for ; Wed, 20 Aug 2014 06:43:09 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id m5so6895936qaj.21 for ; Wed, 20 Aug 2014 06:43:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MabwwMyCN+cZ2dCGNPiQnF242wX90JIsmhSQTDvUoCI=; b=Rj4FcALsAiosRIEn8ZpJOxeAX7s8PdEvvKncMcg9KxqT9/WDElnPA70dhxHTSddLcg BD9oJ/44XZAqqqOa4BvcwA6XqfCTaga2VbKfA8ByD6rXiUR090tyefWbfngDCHbAYvwq K2x0MnCqrvnRr0m7reOAyk1ZlBUWsRLItaabEGPflC35WOtxc2CXn8BGfB0aJSG982VC n61M6ObUUhKXAOX4EYWiWa3bUN3zOP7NRODoRoSRXcbBj+2+Pl+tem5T8UHdVfIseREI f2PFHMB3OHA6GEETjBHHcqQgom8PeFzzOOVRco83BwcwiIwFsePkgVizrjxkQdrbfojj 71oQ== X-Gm-Message-State: ALoCoQmH8ZDoCgtcRAQVs5uWzKtU/CKvIZye52Y1Xy9DvloMkH0pSFzEJgucjFu/2fcEuNQoYHI4 MIME-Version: 1.0 X-Received: by 10.224.30.14 with SMTP id s14mr79577491qac.70.1408542188066; Wed, 20 Aug 2014 06:43:08 -0700 (PDT) Received: by 10.140.91.50 with HTTP; Wed, 20 Aug 2014 06:43:07 -0700 (PDT) X-Originating-IP: [216.75.21.31] In-Reply-To: <20140819212351.GB11767@breakpoint.cc> References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <20140819212351.GB11767@breakpoint.cc> Date: Wed, 20 Aug 2014 13:43:07 +0000 Message-ID: From: Jacob Appelbaum To: Florian Westphal Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/-Z__ROgXHziVOA1eOpVZr3zUUp4 Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch , Christian Grothoff 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 13:43:11 -0000 On 8/19/14, Florian Westphal wrote: > Jacob Appelbaum wrote: >> No. I want to protect my TLS service from implementation exploitation. >> You cannot probe my TLS service for the next heartbleed without a >> shared secret. > > So you won't accept e.g. smtp STARTTLS on your mail server? That is likely a public service that is never going to be restricted with TCP Stealth. > > Also, once this becomes widespread, people will add > --probe-all-isns switch to their port scanners.... > That sounds fantastic - it suggests that a person is willing to send 2^32 packets to a single port. That will stick out like a sore thumb and of course, a system can detect this probing and take reasonable precautions. > It looks to me like this (I apologize In advance if this seems > offensive): > > Q: - I want to run $service, but I don't want anyone to see it! > A: - don't run it. That isn't an option. > > Q: - But I need to access the service sometimes from random locations! > A: - protect it with a password/some other form of secret. > That is exactly what is done here - we protect it with "some other form of secret." > Q: - But then its visible to port scanners! > A: - So what? Defense in depth - we don't need to run faster than the bear, only faster than everyone else. :) > > Q: - But it allows people who have detected service presence > to try running exploits against it! > A: - If you really care, tunnel via ssh perhaps? Using a VPN or something like a VPN is one option, yes. When that edge software has issues, it would be nice to ensure that a casual attacker will not even discover this software is running. > > Q: But I really really want to hide the presence of all services, > i.e. all tcp ports should appear to be closed > > A1: - There are portknock schemes to add obfuscation if you really want > this. > That is exactly what TCP Stealth aims to standardize. > Q: - But I cannot use portknocking because....? > A: - ? > > I tried to find explanation in draft-kirsch-ietf-tcp-stealth-00, > but did not find any. It talks about "pitfalls" of applications > trying to "reimplement tcp in user space". Perhaps there > should be a paragraph as to why ra > ...? > But even assuming that there is a need for portknocking and/or > TCP Stealth: > > - How does this relate to TCP-AO? > (The draft mentions tcp md5sig only, then disregards it as it > doesn't work in NATted environments) > > [ I realize TCP AO has other issues esp. vs. the proposed stealth > scheme, especially wrt. complexity. Anything else? ] > > > Problems I see with the proposal (ignoring the TCP related issues > others pointed out and the "obscurity only" approach), > and a few questions: > > - What about timing? I.e. is response time different regarding > RST-from-closed-port vs. RST-from-stealth port? This will vary by implementation and configuration. At the moment, I think that it is minimal over the internet but I wouldn't be surprised if there was a detectable jitter. I defer to Christian about specifics on this measurement though. Perhaps we can put up a service as a demo? :) > - e.g., are hosts required to perform authentication even for > SYN-to-closed-port, etc? > > - Your adversary may be able to do full passive monitoring of > all network traffic (also compare "replay" above), so whats the purpose > of "avoiding" active scans? > Exactly the purpose - we wish to avoid active scans. The GCHQ/NSA/CSEC do active scans when their full passive monitoring isn't enough. This hampers that angle of information gathering. It also ensures that even if they are monitoring with a passive/active tap - we can authenticate the first bytes of a secure protocol setup. This is good news - it means that even a sniffer can't wait for a sysadmin to ssh into the server and then hijack the session. > - Key Propagation (either your group is very very small, or I can > probably find the secret-secret-word via a web search...) The first is certain for many services, the second assumes a totally public service. There is no reason that the second must be true, even if the first assertion is correct. > > - Seems most services cannot use it since they have to accept > connections from (almost) anyone Huh? > > In fact, this is one of the main problems that I see with the proposal; > its use seems severely limited; up to the point where its unusable in > practice. > > Perhaps it would help to show specific usage examples > of how this would be deployed/where this is usable? I think gnunet.org is a good example of where it is currently deployed. > >> > Another objection: the mechanism help only for a small fraction of use >> > cases. Especially when the server communicate with one or a few >> > clients where the "shared secret" is no problem. But especially in >> > these setups TLS client certificates could be used without any >> > problems. >> > >> >> What happens in your example when there is exploitable code in the >> client certificate parsing code? > > "What happens in your example when there is exploitable code in the > payload protection verification?" > > [ Its rhetoric question. I am aware of complexity difference. The point > is, do your really think its worth to add yet another layer -- which can > have issues both in the specification and the implementation -- rather than > e.g. slim down/fix security transport protocol specs and implementations? ] > > Else, I guess I could argue that running your service via SCTP is "more > secure" since its "less likely to be found in scan..." > There is specific cryptographic complexity in TCP Stealth and that is not the case with SCTP in your example. All the best, Jacob From nobody Wed Aug 20 08:02:48 2014 Return-Path: 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 3CFA11A0675; Tue, 19 Aug 2014 10:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 CXEtcKlkwiLe; Tue, 19 Aug 2014 10:52:41 -0700 (PDT) Received: from smtp1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F5C1A067B; Tue, 19 Aug 2014 10:52:39 -0700 (PDT) Received: from [192.168.178.20] (pd95c0f92.dip0.t-ipconnect.de [217.92.15.146]) by mail.net.in.tum.de (Postfix) with ESMTPSA id B0FED191C878; Tue, 19 Aug 2014 19:52:34 +0200 (CEST) Message-ID: <53F38EE3.9060300@grothoff.org> Date: Tue, 19 Aug 2014 19:52:35 +0200 From: Christian Grothoff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.7.0 MIME-Version: 1.0 To: "Scheffenegger, Richard" , Hagen Paul Pfeifer , "alfiej@fastmail.fm" References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <651312c598e44d05af8212c2eb691001@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: <651312c598e44d05af8212c2eb691001@hioexcmbx05-prd.hq.netapp.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/fCsWl7ZKsDTJBH2YtqZijC_qX9M X-Mailman-Approved-At: Wed, 20 Aug 2014 08:02:47 -0700 Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 17:52:43 -0000 On 08/19/2014 07:20 PM, Scheffenegger, Richard wrote: > Hi Hagen, > >> Anyway, I am little bit ambivalent regarding this ID. It may help >> in some situations and reduce the attack vector. Any effort to >> improve the security should be reviewed! I mean if there are no >> negative impacts: why not? ;-) > > I'm reluctant to conclude that there are no negative impacts. > > As an example, think of a lightweight http server running this on a > server, an legimtate client (knowing the secret) running on a similar > leightweight client without TSopt and only very few ephemeral ports. > > For each http session, the very same ISN will be re-used for every > identical source port. No, that is nonsense, you are constructing a pretty narrow scenario. First of all, with integrity protection, the client can include the first N bytes of the HTTP header in what is hashed into the ISN, so different URLs would created different ISNs. Furthermore, even without integrity protection, the client should use the TCP timestamp option, which will add another 32-bits of entropy to the hash, making each new request have a very much random ISN. Finally, I question that it is realistic that a client will 1) create SO MANY connections to an administrative service (sign of BAD application-level protocol design) that the number of available ephemeral source ports is exceeded before connections can be properly timed out; 2) not be able to enable TSopt 3) not be able to use integrity protections You need _all_ of these. And note that using TCP Stealth is supposed to be an option that applications can enable, not something every server has to require for every TCP client. So if the above scenario really is what happens, just don't use it. > In that enviornment the chances for a delayed packet to corrupt a > TCP stream are non-negligible any more... ( the inverse of the number of ephemeral source ports available). Btw, isn't a proper TCP implementation supposed to not re-use ephemeral ports for a sufficiently long time out to ensure this cannot happen, regardless of ISN collision possibilities? After all, the ISN almost doesn't matter here, as the connection might have been used to transfer 4 GB and then _every_ ISN may cause this problem. So I think you are considering the case of a very, very broken TCP client implementation. > Also, the client will have to do a fall-back SYN without TSopt, if an > intermediate meddlebox modifies the TSopt in any way; and across > normalizers (also not completely uncommon) the scheme breaks down. > But then, those meddleboxes shouldn't really be messing around to > begin with... :) Exactly. > > I guess what I'm saying is that if some randomness (high order bits) > could be maintained even when the 4-tuples are identical, that would > at least address this concern (such sessions would still be > detectable, by checking if the low order bits are identical; unless > there is some clever way to randomly distribute the hash-bits and > random bits, perhaps also based on a (different?) hash of the > 4-tuple... Look, with TSval and optionally hashing in the content, you do have already two good ways to increase entropy. A third way would be if the application-logic decides to change the secret after each successful connection (one-time secrets), which for _some_ scenarios with only one legitimate user of the TCP server is also realistic. Happy hacking! Christian From nobody Wed Aug 20 08:04:25 2014 Return-Path: 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 EECB41A06CB; Tue, 19 Aug 2014 11:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3] 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 wDs2RQ2ci36y; Tue, 19 Aug 2014 11:27:28 -0700 (PDT) Received: from smtp1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19EB1A06C7; Tue, 19 Aug 2014 11:27:27 -0700 (PDT) Received: from [192.168.178.20] (pd95c0f92.dip0.t-ipconnect.de [217.92.15.146]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 9CE47191C878; Tue, 19 Aug 2014 20:27:24 +0200 (CEST) Message-ID: <53F3970D.5080906@grothoff.org> Date: Tue, 19 Aug 2014 20:27:25 +0200 From: Christian Grothoff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.7.0 MIME-Version: 1.0 To: Hagen Paul Pfeifer , Jacob Appelbaum References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/GhMfFCJ0mWdKA4S-prP848vw6Qc X-Mailman-Approved-At: Wed, 20 Aug 2014 08:04:23 -0700 Cc: Joe Touch , "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 18:27:33 -0000 On 08/19/2014 08:07 PM, Hagen Paul Pfeifer wrote: > On 19 August 2014 19:15, Jacob Appelbaum wrote: > >> No. I want to protect my TLS service from implementation exploitation. >> You cannot probe my TLS service for the next heartbleed without a >> shared secret. > > C'mon Jacob, this smells fishy! Let's assume you protect *your* > service from one potential TLS bugs, this is (partly) possible with > the mechanism described in the ID. But what happens in the meantime > with your https:// browsing, openvpn, ... communications? If you > assume bugs in TLS you must stop all your communications! TLS and > strong cryptography is the fundamental building block - when it is > broken the whole communication system is b0rken. Well, that pretty much sums up what I have been saying in the past to the IETF: https://gnunet.org/strint2014gnunet And yes, I do not like SSH, TLS, GPG or X.509. But we cannot fix everything at once, and sometimes a hot fix can be useful. TCP Stealth is just that: a small fix to a small problem, it does not try to solve everything. > The other way, if you trust TLS you can also trust the TLS client > certificates mechanism as well. You clearly also deliberately missunderstand the difference between design / specification / mechanism, and the reality of an implementation. > I understand your objection but the "fix" feels wrong. We should do > everything we can to make TLS fast, clean and strong. Then standardize TCPCurve. In the meantime, this is about TCP, not TLS. And the service I would see this use with most is SSH, not HTTPS. > But to repeat > myself: I see advantages and benefits and _if_ there are no major > disadvantages we can push things forward. Well, no need to answer > here, I got your point in detail and I want to make sure we discuss > all possibilities, using TLS client certificates is one alternative. > >> It isn't abuse - we're even trying to make it a standard to ensure >> that it is well documented non-abusive behavior - rather different >> than most other port knocking, I'd add. > > The ISN has 32 bits, reduce this space leads to problems in the past. We do not propose a reduction of the space, only under some unfortunate and clearly undesirable circumstances with several of the entropy sources being unavailable this may happen, and even then I do not believe the problem is quite as big as you make it out to be. > We must do everything to not open any other attack vectors regarding > TCP by mistake. If you *prove* that this will not lead to problems, I > will never ever mention the word "abuse" in an email to you! ;-) Prove is a strong word. Now, I would not mind if the standard included some strong wording on using a random TSval in combination with TCP Stealth by default. But, as was pointed out, due to some NATs messing with TSvals, we decided to keep it optional, as opposed to mandatory. But I think that is a point I would be open to discuss, as it is really a trade-off. Happy hacking! Christian From nobody Wed Aug 20 08:04:41 2014 Return-Path: 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 298671A0715; Tue, 19 Aug 2014 12:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 Xue1sEtyFyQg; Tue, 19 Aug 2014 12:04:14 -0700 (PDT) Received: from smtp1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 515F11A05D1; Tue, 19 Aug 2014 12:04:14 -0700 (PDT) Received: from [192.168.178.20] (pd95c0f92.dip0.t-ipconnect.de [217.92.15.146]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 4A61B191C878; Tue, 19 Aug 2014 21:04:11 +0200 (CEST) Message-ID: <53F39FAC.9070500@grothoff.org> Date: Tue, 19 Aug 2014 21:04:12 +0200 From: Christian Grothoff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.7.0 MIME-Version: 1.0 To: Hagen Paul Pfeifer References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <53F3970D.5080906@grothoff.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/EJQu_tm7rVC8bUAsr617h5kcJek X-Mailman-Approved-At: Wed, 20 Aug 2014 08:04:35 -0700 Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 19:04:17 -0000 On 08/19/2014 08:59 PM, Hagen Paul Pfeifer wrote: > On 19 August 2014 20:27, Christian Grothoff wrote: > >> You clearly also deliberately missunderstand the difference between >> design / specification / mechanism, and the reality of an implementation. > > No, I don't. But you are right, we should talk about implementation issues. > >> Prove is a strong word. Now, I would not mind if the standard included >> some strong wording on using a random TSval in combination with TCP >> Stealth by default. But, as was pointed out, due to some NATs messing >> with TSvals, we decided to keep it optional, as opposed to mandatory. >> But I think that is a point I would be open to discuss, as it is really >> a trade-off. > > TSvals *are* optional, you propose TCP stealth should depend on an > "optional option"? What I said is that if possible, clients should use TCP stealth in combination with this optional option. As it is an option, we did not make it mandatory, but I think it is totally acceptable to recommend using the option. > I clearly see problems here because they can be > filtered, disabled or simple the limited option space is exhausted by > other options. We do have a measurement study on this in Julian's master's thesis. Yes, it does happen, but it is uncommon. > What about PAWS? What about ISN duplicates and how are > these handled (and differentiated)? We discuss TCP SYN retransmissions in the draft. From nobody Wed Aug 20 08:05:03 2014 Return-Path: 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 606CE1A017F; Tue, 19 Aug 2014 14:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 x5cJS7ZXt0Fc; Tue, 19 Aug 2014 14:53:39 -0700 (PDT) Received: from smtp1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13FB71A017D; Tue, 19 Aug 2014 14:53:39 -0700 (PDT) Received: from [192.168.178.20] (pd95c0f92.dip0.t-ipconnect.de [217.92.15.146]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 9F369191C878; Tue, 19 Aug 2014 23:53:35 +0200 (CEST) Message-ID: <53F3C75F.4030407@grothoff.org> Date: Tue, 19 Aug 2014 23:53:35 +0200 From: Christian Grothoff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.7.0 MIME-Version: 1.0 To: Florian Westphal , Jacob Appelbaum References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <20140819212351.GB11767@breakpoint.cc> In-Reply-To: <20140819212351.GB11767@breakpoint.cc> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/kpyyaQgqU-JwN7YM94MdIvt1-hU X-Mailman-Approved-At: Wed, 20 Aug 2014 08:05:00 -0700 Cc: "tcpm \(tcpm@ietf.org\)" , "tcpinc@ietf.org" , Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 21:53:41 -0000 On 08/19/2014 11:23 PM, Florian Westphal wrote: > Jacob Appelbaum wrote: >> No. I want to protect my TLS service from implementation exploitation. >> You cannot probe my TLS service for the next heartbleed without a >> shared secret. > > So you won't accept e.g. smtp STARTTLS on your mail server? > > Also, once this becomes widespread, people will add > --probe-all-isns switch to their port scanners.... If that makes port scanning 2 billion times more expensive, great. As we said, that would really Knock down the HACIENDA-style ultra-large scale port scanning of machines. So if we get there, for TCP Stealth that would be mission accomplished. > It looks to me like this (I apologize In advance if this seems > offensive): > > Q: - I want to run $service, but I don't want anyone to see it! > A: - don't run it. > > Q: - But I need to access the service sometimes from random locations! > A: - protect it with a password/some other form of secret. Sorry, did you even see the NSA slide with the brute-forcing of passwords? Are _all_ of your passwords longer and/or more complex than those shown there? If not, you loose. Also, even if yours are long enough, please make sure the same applies to everyone else administering systems on the planet. You cannot? Then help us deploy TCP Stealth. > Q: - But then its visible to port scanners! > A: - So what? So what? Then the GCHQ/NSA will use TAO-developed or purchased 0-day attacks to turn me into an ORB, I don't like my machine to be turned into an CSEC-bot that then attacks other systems. You may think that doesn't matter, but I do. > Q: - But it allows people who have detected service presence > to try running exploits against it! > A: - If you really care, tunnel via ssh perhaps? I do really care. But they do scan for SSH (did you see the slides?). So what if they have an undisclosed vulnerability for SSH? > Q: But I really really want to hide the presence of all services, > i.e. all tcp ports should appear to be closed > > A1: - There are portknock schemes to add obfuscation if you really want > this. Yes, and TCP Stealth provides a standardized port knocking method that works reasonably well with NAT and is not easy to detect, so I really want this. > Q: - But I cannot use portknocking because....? > A: - ? > > I tried to find explanation in draft-kirsch-ietf-tcp-stealth-00, > but did not find any. It talks about "pitfalls" of applications > trying to "reimplement tcp in user space". Perhaps there > should be a paragraph as to why ra ? > But even assuming that there is a need for portknocking and/or > TCP Stealth: > > - How does this relate to TCP-AO? > (The draft mentions tcp md5sig only, then disregards it as it > doesn't work in NATted environments) I didn't post it here, so I cannot answer that. > [ I realize TCP AO has other issues esp. vs. the proposed stealth > scheme, especially wrt. complexity. Anything else? ] > > > Problems I see with the proposal (ignoring the TCP related issues > others pointed out and the "obscurity only" approach), Sorry, this is not "obscurity only", with a shared secret this is defense in depth, not at all security by obscurity. A detailed explanation of this point is in Julian's thesis. > and a few questions: > > - What about timing? I.e. is response time different regarding > RST-from-closed-port vs. RST-from-stealth port? First of all, that's an implementation issue, and one of the reasons why this should be done in-kernel and with MD5. But yes, implementors should be wary of timing attacks. > - e.g., are hosts required to perform authentication even for > SYN-to-closed-port, etc? No, but of course they may choose to do so to defend against timing attacks. The calculation is fast enough for this to be feasible. > - Your adversary may be able to do full passive monitoring of > all network traffic (also compare "replay" above), so whats the purpose > of "avoiding" active scans? Again, defense in depth. Not every adversary can do passive scans. > - Key Propagation (either your group is very very small, or I can > probably find the secret-secret-word via a web search...) Yes, the group should be small. Or you could use the GNU Name System to share the secret securely via the name system, but that's way too radical for IETF at this time. > - Seems most services cannot use it since they have to accept > connections from (almost) anyone This is intended for administrative services with a limited user group. > In fact, this is one of the main problems that I see with the proposal; > its use seems severely limited; up to the point where its unusable in > practice. It is an _option_. I can equally argue VPNs or firewalls are severely limited and unusable in practice -- but that would only be true if my mind was not open to use-cases outside of my personal domain. For me personally, VPNs and firewalls are useless. Still, I acknowledge that they may have value for other users. TCP Stealth is merely one additional tool for system administrators we propose, and you can say that for your work others are more appropriate, or you can combine multiple methods. > Perhaps it would help to show specific usage examples > of how this would be deployed/where this is usable? I login into my machine at my office via SSH dozens of times a day from all over the world. I am the only user. We run a build server farm, there are like five users. The handful of build servers accesses the master server via HTTPS. I access my personal IMAPS server on another system also from all over the planet, there are two other users of that IMAPS service. And updating certificates and keys after Heartbleat knowing that my mail may have been compromised in the meantime is not something I like. >> What happens in your example when there is exploitable code in the >> client certificate parsing code? > > "What happens in your example when there is exploitable code in the > payload protection verification?" > > [ Its rhetoric question. I am aware of complexity difference. The point > is, do your really think its worth to add yet another layer -- which can > have issues both in the specification and the implementation -- rather than > e.g. slim down/fix security transport protocol specs and implementations? ] Once you have a secure transport protocol implementation with smaller complexity than the TCP Stealth implementation and are getting it universally deployed (including for legacy services), I'll concede your point. > Else, I guess I could argue that running your service via SCTP is "more > secure" since its "less likely to be found in scan..." True, but again in the real world there are NATs, so good luck accessing your SCTP service on the modern ossified Internet. From nobody Wed Aug 20 08:05:37 2014 Return-Path: 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 A7A461A0270; Wed, 20 Aug 2014 04:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-2.3] 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 EVJrIe5CWFRN; Wed, 20 Aug 2014 04:56:22 -0700 (PDT) Received: from smtp1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E3E1A0201; Wed, 20 Aug 2014 04:56:22 -0700 (PDT) Received: from [192.168.178.20] (pd95c0f92.dip0.t-ipconnect.de [217.92.15.146]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 77CF519BF034; Wed, 20 Aug 2014 13:56:16 +0200 (CEST) Message-ID: <53F48CE0.1020507@grothoff.org> Date: Wed, 20 Aug 2014 13:56:16 +0200 From: Christian Grothoff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.7.0 MIME-Version: 1.0 To: "Scheffenegger, Richard" , Jacob Appelbaum References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <53F3970D.5080906@grothoff.org> <53F39FAC.9070500@grothoff.org> <817214c2e5b444c7a780c1387e91da15@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: <817214c2e5b444c7a780c1387e91da15@hioexcmbx05-prd.hq.netapp.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/1AjFRLiLx3kPn8cOCRHCUWEsvH4 X-Mailman-Approved-At: Wed, 20 Aug 2014 08:05:30 -0700 Cc: "tcpm \(tcpm@ietf.org\)" , "tcpinc@ietf.org" , Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 11:56:24 -0000 On 08/20/2014 01:23 PM, Scheffenegger, Richard wrote: > Jacob, Christian, > > To add some constructive discussion points: > > > As the editor of RFC7323 (soon to be released), which is the update > to 1323, and the discussion I looked at over at > http://thread.gmane.org/gmane.linux.network/294386 and of course > here, I was wondering if you might have it backwards... > > > I have not seen a convincing enough argument, that running a fixed > ISN for a 4-tuple is really safe. (And yes, re-use of a 4-tuple > should be rare, but it can happen). > > Also, you want to add some additional "randomness" by adding the > TSval into the hash, if available. We do that, did you even read the draft? > However, TSval is not random, it's in most implementations a pretty > accurate uptime indicator (that this in itself is a bad idea, is > known for a long time. That it would make sense to randomize the > TSval in the same way as the ISN is now much more prominently stated > in RFC7323). We do agree that the TSval should be randomized. > So, I could not help myself from wondering, if you haven't got your > fields backwards.... > > 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. Right now, TSval is rarely chosen at random by implementations (see our measurement study in Julian's thesis). So putting the authenticator into the TSval would have provided an easy distinguisher, which we wanted to avoid. However, I would in principle support _also_ using the TSval, that way we could get 64 bits. But, as said before, this is a trade-off with respect to how many middleboxes will work, as some fiddle with TSval but not the ISN (and vice versa). > And as you already stated that connections across Meddleboxes (those > that tweak around with ISN or TSval) are out of scope and may fail, > you don't really reduce the population of sessions that could benefit > from this. Based on our experiments, it would reduce it only slightly (within the margin of error of our experiments), so yes, that maybe acceptable. > > Finally, as TSopt is optional, modifications there have a much lower > bar for acceptance, compared to a modification like the ISN; a server > implementing the scheme would still be free to silently discard TCP > SYNs without TSOpt, or the wrong TSval / TSecr... (As you could > instruct your firewall to block empty, non-related RSTs). > > Finally, the combination of TSval/TSecr would yield 64 bits, btw. But > only on the SYN... Right, but the SYN is what matters most IMO. We could use 32 bits of the ISN for the content integrity protector, and another 32 bits of the timestamp for the authenticator part, that would be fine. But, as I said, the problem is that this means that handshakes doing so would stand out from current traffic. So really this is a bit of a trade-off between passive detection of the knock in the current environment and getting a few more bits of security. Another issue maybe that some current OSes don't use TSval at all, so I figured just changing the ISN calculation might be the more conservative suggestion, but again, this is clearly a trade-off and if IETF decided to instead to ISN+TSval or even just TSval, I would still consider this a big progress. Happy hacking! Christian From nobody Wed Aug 20 08:06:33 2014 Return-Path: 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 C1D0C1A0B76 for ; Tue, 19 Aug 2014 18:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Jz_h_-DpWI7q for ; Tue, 19 Aug 2014 18:25:14 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 03D351A1F04 for ; Tue, 19 Aug 2014 18:25:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id EAC8E2C4070; Tue, 19 Aug 2014 18:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QSc9s2bTifc5; Tue, 19 Aug 2014 18:25:01 -0700 (PDT) Received: from akane.icir.org (akane.ICIR.org [192.150.187.87]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id B93EC2C405F; Tue, 19 Aug 2014 18:25:01 -0700 (PDT) To: Bob Briscoe In-Reply-To: <201408191012.s7JACegt022734@bagheera.jungle.bt.co.uk> (Tue, 19 Aug 2014 11:12:39 BST). Date: Tue, 19 Aug 2014 18:25:01 -0700 From: Vern Paxson Message-Id: <20140820012501.B93EC2C405F@rock.ICSI.Berkeley.EDU> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/AiXUzpAdihJSY8uSNorL0m92nBE X-Mailman-Approved-At: Wed, 20 Aug 2014 08:06:18 -0700 Cc: eblanton@cs.purdue.edu, tcpm IETF list , "ALLMAN, Mark" Subject: Re: [tcpm] RFC5681 erratum regarding stretch ACK violation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 01:25:15 -0000 Hi Bob, Thanks for flagging this. I believe I see your point (though haven't read that part of 5681 more broadly to double-check), and your adjustments to the text make sense to me. Vern From nobody Wed Aug 20 08:44:59 2014 Return-Path: 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 B39A61A070A; Wed, 20 Aug 2014 08:44:58 -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 GRNoLGPQTa8E; Wed, 20 Aug 2014 08:44:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B861A06FE; Wed, 20 Aug 2014 08:44:57 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7KFifAd018945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 20 Aug 2014 11:44:41 -0400 Received: from [10.36.4.100] (vpn1-4-100.ams2.redhat.com [10.36.4.100]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7KFibSE009864 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 20 Aug 2014 11:44:39 -0400 Message-ID: <53F4C265.4000402@redhat.com> Date: Wed, 20 Aug 2014 17:44:37 +0200 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jacob Appelbaum References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <20140819212351.GB11767@breakpoint.cc> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/r6pnnn42mtuQcTJVsghsNV1r0eA Cc: Christian Grothoff , "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 15:44:59 -0000 On 08/20/2014 03:43 PM, Jacob Appelbaum wrote: > On 8/19/14, Florian Westphal wrote: [...] >> - Your adversary may be able to do full passive monitoring of >> all network traffic (also compare "replay" above), so whats the purpose >> of "avoiding" active scans? > > Exactly the purpose - we wish to avoid active scans. The GCHQ/NSA/CSEC > do active scans when their full passive monitoring isn't enough. This > hampers that angle of information gathering. It also ensures that even [...] Ok, but for the majority of use cases, lets presume that you'd pass one of these secretly hidden taps located at some cooperative IX. Assuming the worst case that some passive adversary has access to enough taps distributed at convenient locations, did a previous active port scan and knows that from your machine port 22 is closed. Later, it observes a two-way flow to port 22 to that machine and the existence of the service is of course nevertheless revealed. You might be able then to 'mitigate' actual access to the service a bit, but then again 32 bit is perhaps a limited sense of 'security'. It would also be required that machines running more than one service have /all/ services somewhat protected by TCP stealth, otherwise an attacker moves on with the next service as an attack vector. Again, if also services over other transport protocols are used on the machines (that cannot make use of TCP stealth), an attacker might first probe for these as an easier target to get in. Key propagation is certainly an issue I assume; you might also want to consider to rotate them etc; large public sites most likely cannot make use of TCP stealth, and the larger a group becomes, the more weak points might arise (including humans) to disclose the shared secret somehow. Then again, it might also not be worth it for pubkeys as it would significantly increase computational complexity on the server side and we're only talking about 32 bit ... /offtopic here, but wouldn't it then be better to work towards full encryption like CurveCP et al is trying to solve ... From nobody Wed Aug 20 09:01:18 2014 Return-Path: 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 048521A1F16 for ; Wed, 20 Aug 2014 09:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 Z6CqUj_8tinV for ; Wed, 20 Aug 2014 09:01:09 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC711A7D82 for ; Wed, 20 Aug 2014 09:00:22 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id w7so7797269qcr.20 for ; Wed, 20 Aug 2014 09:00:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RTTF9wJXVaJ7Co0KUCkJqoqA3CxmFpAfW+l5zsG+IP4=; b=IDVYCkxoJn2mBNEAP9rFLH+GHPWONmVe37dgUTPUVxzztmReHeB6FXCyRBoY5y3YGH Hn42wctfRnNBgh5LNQWzBrn83a2hHi7NdruLzuUMzRZp4aU9csoWK0g0d9881renIDSU iMKH9m1RTx4oFBkxdEJK+N5U2qUlGb5OpWMO57/f2AVCNNiGsbNOSLhuuY1GiLcPRJpz HJFpsW2/N9WIOEz6PBacd1xSB8QxD2t4LSoZM1BPTpzNG3Lh6JgpLC2svCuEkSleAfCG UQZ/3CV7sfDr1lu93ReRRGj6OwU4zz7b7vjJ1lg8DU4mGN5Me1RtH3jJioxqKqQvQcyx laFA== X-Gm-Message-State: ALoCoQlFsjBx9CVJKuHgS4QkAzDQkTg4i+JgQdaKZKhjVrZYXm71ZDuKapRqeBbddBEOR5S+bhPL MIME-Version: 1.0 X-Received: by 10.224.138.8 with SMTP id y8mr79809868qat.38.1408550417917; Wed, 20 Aug 2014 09:00:17 -0700 (PDT) Received: by 10.140.91.50 with HTTP; Wed, 20 Aug 2014 09:00:17 -0700 (PDT) X-Originating-IP: [91.185.200.222] In-Reply-To: <53F4C265.4000402@redhat.com> References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <20140819212351.GB11767@breakpoint.cc> <53F4C265.4000402@redhat.com> Date: Wed, 20 Aug 2014 16:00:17 +0000 Message-ID: From: Jacob Appelbaum To: Daniel Borkmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/V_NCk5pcK_wriM-eyj9uM0rB-Lw Cc: Christian Grothoff , "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.org\)" , Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 16:01:11 -0000 On 8/20/14, Daniel Borkmann wrote: > On 08/20/2014 03:43 PM, Jacob Appelbaum wrote: >> On 8/19/14, Florian Westphal wrote: > [...] >>> - Your adversary may be able to do full passive monitoring of >>> all network traffic (also compare "replay" above), so whats the purpose >>> of "avoiding" active scans? >> >> Exactly the purpose - we wish to avoid active scans. The GCHQ/NSA/CSEC >> do active scans when their full passive monitoring isn't enough. This >> hampers that angle of information gathering. It also ensures that even > [...] > > Ok, but for the majority of use cases, lets presume that you'd > pass one of these secretly hidden taps located at some cooperative > IX. Assuming the worst case that some passive adversary has access > to enough taps distributed at convenient locations, did a previous > active port scan and knows that from your machine port 22 is closed. > Later, it observes a two-way flow to port 22 to that machine and the > existence of the service is of course nevertheless revealed. Sounds good. We've just taken detection of the service from everyone in the world to a passive wiretapping attacker observing a sysadmin/user and the service. Otherwise they're going to need to send ~2^32-1 packets per port guess. > > You might be able then to 'mitigate' actual access to the service > a bit, but then again 32 bit is perhaps a limited sense of 'security'. Sure, I agree. We're limiting against a specific, well scoped specific issue that is pervasive and a problem. We do not solve every problem for every attacker. We have deployed code that is running today and it works, roughly. :) > It would also be required that machines running more than one service > have /all/ services somewhat protected by TCP stealth, otherwise an > attacker moves on with the next service as an attack vector That would be consistent but it isn't required. Not all services are created equally - e.g.: OpenSSH ( + ssh keys + TCP Stealth) has root privileges on a system, even if privilege separated. Not all services are so enabled. Another use case is for Tor bridges - in this case - we only care about active probing. Even in advanced cases like the "great" firewall of China, they use active probing to confirm their wiretapped machine learning decisions... > Again, > if also services over other transport protocols are used on the > machines (that cannot make use of TCP stealth), an attacker might > first probe for these as an easier target to get in. Of course. > Key propagation is certainly an issue I assume; you might also want > to consider to rotate them etc; large public sites most likely cannot > make use of TCP stealth, and the larger a group becomes, the more weak > points might arise (including humans) to disclose the shared secret > somehow. Per user shared secrets seem to fit the bill here. > Then again, it might also not be worth it for pubkeys as it > would significantly increase computational complexity on the server > side and we're only talking about 32 bit ... > I think that the decoy routing field holds some interesting tricks for public keys. Telex hides a signature in the TLS handshake, for example. Perhaps for a later version of TCP stealth? :) > /offtopic here, but wouldn't it then be better to work towards full > encryption like CurveCP et al is trying to solve ... I'd like to see that too. We'll get there and this is one step in a similar direction. All the best, Jacob From nobody Wed Aug 20 14:29:33 2014 Return-Path: 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 F16121A87A3 for ; Wed, 20 Aug 2014 14:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xk0yBM3rGpjC for ; Wed, 20 Aug 2014 14:29:28 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAEE21A87CE for ; Wed, 20 Aug 2014 14:29:24 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by gateway2.nyi.internal (Postfix) with ESMTP id 838FE208CF for ; Wed, 20 Aug 2014 17:29:23 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute2.internal (MEProxy); Wed, 20 Aug 2014 17:29:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:reply-to:in-reply-to:references:subject:date; s= mesmtp; bh=pyTz7I8/TtHf/n7kwtkqEsg/XVA=; b=V//amL75aKLNRMyrM7MrS qJLhXlbxvTW0RF5yOD0KHOits3xnGcGggxJlLTv0WwUo5on4+6AVJG7+lfXgNtCr UVwo7YfdbqEBqmiD9mBo5b+h15uBbuACGipySDkbYBb+q4XYGXBUl2b27cPLIEIW deWY5rPa8IPVGq+2SXQgRU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:reply-to:in-reply-to :references:subject:date; s=smtpout; bh=pyTz7I8/TtHf/n7kwtkqEsg/ XVA=; b=OdfcRs1eedmAZUMnlFaukoVBVxWjbWtxPBqtBXOatPnTtj2tMDt+8jKR HZC1FRh4yrApcwY/Fcd4smhbVngPpJTjyad8HBGKpe/5Olw5Wp5xJ5zVMXLdqCxq pYatvOguRq2+M2ywqDr7+3tC2xAi4xgrZ3W8PFhjP83n4Shv98A= Received: by web2.nyi.internal (Postfix, from userid 99) id 58CEE5401DF; Wed, 20 Aug 2014 17:29:23 -0400 (EDT) Message-Id: <1408570163.1317092.154976257.5364EFB1@webmail.messagingengine.com> X-Sasl-Enc: Tq6K4t/X+MCh03VmqSrbOZbMfzzRWoneb1sQhsxOpFHI 1408570163 From: Alfie John To: Jacob Appelbaum , Florian Westphal MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-5f815d4c In-Reply-To: References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <1408401991.317123.154137701.0A30F30C@webmail.messagingengine.com> <20140819212351.GB11767@breakpoint.cc> Date: Wed, 20 Aug 2014 23:29:23 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/gHiVDXQ-wkWTMlINQgVbTP2SvjI Cc: Christian Grothoff , "tcpm \(tcpm@ietf.org\)" , tcpinc@ietf.org, Joe Touch Subject: Re: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: alfiej@fastmail.fm List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 21:29:31 -0000 On Wed, Aug 20, 2014, at 03:43 PM, Jacob Appelbaum wrote: > That is exactly what TCP Stealth aims to standardize. > > > Q: - But I cannot use portknocking because....? > > A: - ? > > > > I tried to find explanation in draft-kirsch-ietf-tcp-stealth-00, but > > did not find any. It talks about "pitfalls" of applications trying > > to "reimplement tcp in user space". Perhaps there should be a > > paragraph as to why ra > > > > ...? When you're on a network that filters everything but DNS, HTTP and HTTPS, you don't have the option of port knocking. Alfie -- Alfie John alfiej@fastmail.fm From nobody Wed Aug 20 21:17:13 2014 Return-Path: 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 DE6661A700E; Wed, 20 Aug 2014 21:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 ArJwTKbGMe8e; Wed, 20 Aug 2014 21:16:30 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3158E1A700B; Wed, 20 Aug 2014 21:16:30 -0700 (PDT) Received: from [192.168.1.3] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s7L4FwB7003333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 20 Aug 2014 21:16:01 -0700 (PDT) Message-ID: <53F57281.2020302@isi.edu> Date: Wed, 20 Aug 2014 21:16:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Scheffenegger, Richard" , "alfiej@fastmail.fm" , Jacob Appelbaum References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/8f7ETXB4Q8wzs6Z5B_FNkL25UVQ Cc: Christian Grothoff , "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 04:16:37 -0000 On 8/18/2014 3:07 PM, Scheffenegger, Richard wrote: > Hi Alfie, > > my concern is with the use of a static ISN for each 4-tuple; this > significantly increases the chance of a collision between sessions (ie. > when the sender terminates a sluggish earlier session, some segments of > that last session will very likely be in-window for a session that was > started a short time later). +1, and I haven't seen a satisfactory answer to this yet. FWIW, the doc refers to TCP MD5, which has been deprecated and replaced by TCP-AO. TCP-AO has an experimental extension to support NAT traversal. Additionally, responding with a TCP RST isn't the best response if you're trying to hide from port knocking. Silence is best in that case. Joe From nobody Thu Aug 21 10:03:17 2014 Return-Path: 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 BE4951A06A7; Thu, 21 Aug 2014 10:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 Ei_elYcDM7bj; Thu, 21 Aug 2014 10:03:13 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A481A024C; Thu, 21 Aug 2014 10:03:13 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s7LH1ncm010056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 Aug 2014 10:01:51 -0700 (PDT) Message-ID: <53F625FB.5030207@isi.edu> Date: Thu, 21 Aug 2014 10:01:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Christian Grothoff , "Scheffenegger, Richard" , "alfiej@fastmail.fm" , Jacob Appelbaum References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <53F57281.2020302@isi.edu> <53F61CB2.2090108@grothoff.org> In-Reply-To: <53F61CB2.2090108@grothoff.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/GAmo3CRuOhFoAPZa5J7WA2bDEE4 Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:03:14 -0000 On 8/21/2014 9:22 AM, Christian Grothoff wrote: > On 08/21/14 06:16, Joe Touch wrote: >> >> >> On 8/18/2014 3:07 PM, Scheffenegger, Richard wrote: >>> Hi Alfie, >>> >>> my concern is with the use of a static ISN for each 4-tuple; this >>> significantly increases the chance of a collision between sessions (ie. >>> when the sender terminates a sluggish earlier session, some segments of >>> that last session will very likely be in-window for a session that was >>> started a short time later). >> >> +1, and I haven't seen a satisfactory answer to this yet. >> >> FWIW, the doc refers to TCP MD5, which has been deprecated and replaced >> by TCP-AO. TCP-AO has an experimental extension to support NAT traversal. > > Well, several people seem to suggest that making the use of TSval > _mandatory_ with TCP Stealth would solve this and other concerns; so if > we put that into the draft, would you be happy? You still have the ISN validity to deal with. TSval helps differentiate wrap - i.e., first use of a sequence number space vs. future use. Your ISN calculation could easily generate an ISN that's valid for the TSval used. >> Additionally, responding with a TCP RST isn't the best response if >> you're trying to hide from port knocking. Silence is best in that case. > > That depends on what the system does for a closed port. No, it depends on what the system does for a port for which no process is listening. CLOSED is a TCP state. RST says something is listening on the connection but doesn't want to talk to you given the SYN parameters you gave. ICMP destination unreachable/port unreachable seems more what you're aiming for if you want to prevent someone from trying again. Joe The draft says > the system should react in the same way as it usually does, and usually > MY servers respond with TCP RST if the port is closed. If you usually > drop, you should drop. If this is about hiding, the key thing is to not > change the behavior for the stealth-open port in relation to the > behavior of a closed port. > From nobody Thu Aug 21 11:07:27 2014 Return-Path: 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 A5F3D1A0700; Thu, 21 Aug 2014 11:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Wp7ZslRCf7qH; Thu, 21 Aug 2014 11:07:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E851A1F16; Thu, 21 Aug 2014 11:07:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821180708.989.70035.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 11:07:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/SvkqMT2gaccbtp3DciJy81af-N4 Cc: tcpm chair , tcpm mailing list , RFC Editor Subject: [tcpm] Document Action: 'A Roadmap for Transmission Control Protocol (TCP) Specification Documents' to Informational RFC (draft-ietf-tcpm-tcp-rfc4614bis-08.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 18:07:20 -0000 The IESG has approved the following document: - 'A Roadmap for Transmission Control Protocol (TCP) Specification Documents' (draft-ietf-tcpm-tcp-rfc4614bis-08.txt) as Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Martin Stiemerling and Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis/ Technical Summary Due to long-term development efforts, understanding TCP is becoming difficult as it consists of many separated RFCs. This document provides a summary of the various documents related to TCP standards, guidelines and best current practices. The objective of the document is to provide a roadmap for TCP standards so that implementers and other parties can reach proper information smoothly and quickly. Working Group Summary This document is the update from RFC4614 which has been published for the same purpose. As the information in RFC4614 is getting stale, there has been consensus in the WG to publish a new version. One discussion point was whether we will keep publishing this type of documents from time to time or find a way to provide up-to-date information through dynamic contents such as Wiki or perpetual I-D. After some discussions, we have concluded to publish this document as an RFC. The consensus was clear as we need further discussions for the other methods and there was no strong support for them. Document Quality The document has been reviewed and discussed by multiple participants in the WG. Personnel Yoshifumi Nishida is the Document Shepherd for this document. The Responsible Area Director is Martin Stiemerling From nobody Thu Aug 21 12:13:36 2014 Return-Path: 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 2F2291A067A for ; Thu, 21 Aug 2014 12:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 Cns1a9UFDp5R for ; Thu, 21 Aug 2014 12:13:33 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.232]) by ietfa.amsl.com (Postfix) with ESMTP id 3841B1A048D for ; Thu, 21 Aug 2014 12:13:33 -0700 (PDT) Received: from pasisarahtismbp.lan (80.223.92.46) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 53C62CBF034341E3 for tcpm@ietf.org; Thu, 21 Aug 2014 22:13:32 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <49AD71D6-9D6B-4345-8BFA-D8F87D55BB6B@iki.fi> Date: Thu, 21 Aug 2014 22:13:29 +0300 To: "tcpm@ietf.org (tcpm@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/yJ9bedkBT2AjPK_j5J6s_tmHszQ Subject: [tcpm] Submitting draft-ietf-tcpm-accecn-reqs for publication X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:13:35 -0000 Hi, To follow up the WGLC that ended on July, we are about to submit = draft-ietf-tcpm-accecn-reqs-07 for publication. Below is the write-up to = go along with the document (following a new alternate format). - Pasi --------- 1. Summary Document shepherd is Pasi Sarolahti. Responsible AD is Martin = Stiemerling. Traditionally the explicit congestion notification can deliver only one = congestion signal in a round-trip time with TCP. This Informational = document motivates the case for delivering more accurate congestion = information for TCP. It discusses high-level requirements for methods = for delivering more accurate congestion information, but does not = specify such mechanism. Therefore Informational is considered = appropriate document type. 2. Review and Consensus The document was reviewed by a few WG participants in its different = phases, also during the WGLC. There has been no controversy over it. = TCPM chairs believe the document is stable and has gone through a = sufficient review, and is ready for publication. 3. Intellectual Property=20 There are no IPR disclosures on this document, and the authors have = confirmed that they are not aware of undisclosed IPR related to this = document. The draft discusses the possible solution space and related earlier = proposals, some of which have disclosed IPRs = (draft-bensley-tcpm-dctcp-01, draft-kuehlewind-tcpm-accurate-ecn-03). = These disclosures can be found on the IPR page based on the respective = draft names. 4. Other points None. There were no issues based on the checklist provided with the = alternative write-up instructions. From nobody Fri Aug 22 08:02:08 2014 Return-Path: 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 B0E351A03E2; Thu, 21 Aug 2014 09:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 a1wh1QwHxBcE; Thu, 21 Aug 2014 09:23:44 -0700 (PDT) Received: from smtp1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028F11A0693; Thu, 21 Aug 2014 09:23:43 -0700 (PDT) Received: from [IPv6:::1] (fulcrum.net.in.tum.de [131.159.20.52]) by mail.net.in.tum.de (Postfix) with ESMTP id 8997419BF034; Thu, 21 Aug 2014 18:23:40 +0200 (CEST) Message-ID: <53F61CB2.2090108@grothoff.org> Date: Thu, 21 Aug 2014 18:22:10 +0200 From: Christian Grothoff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.6.0 MIME-Version: 1.0 To: Joe Touch , "Scheffenegger, Richard" , "alfiej@fastmail.fm" , Jacob Appelbaum References: <1408397675.299896.154112109.6F69043F@webmail.messagingengine.com> <8c5f6a1e9f2340e48e25dd151406b7d3@hioexcmbx05-prd.hq.netapp.com> <53F57281.2020302@isi.edu> In-Reply-To: <53F57281.2020302@isi.edu> X-Enigmail-Version: 1.6 OpenPGP: id=48426C7E Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nqkE2hv6xdh2TdLpflMUWH6QC5eDv7JXl" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Pl3UdO-YGLdkaIGwhG8o0kTTIqw X-Mailman-Approved-At: Fri, 22 Aug 2014 08:02:05 -0700 Cc: "tcpinc@ietf.org" , "tcpm \(tcpm@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 16:23:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nqkE2hv6xdh2TdLpflMUWH6QC5eDv7JXl Content-Type: multipart/mixed; boundary="------------060201010109060409060904" This is a multi-part message in MIME format. --------------060201010109060409060904 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 08/21/14 06:16, Joe Touch wrote: >=20 >=20 > On 8/18/2014 3:07 PM, Scheffenegger, Richard wrote: >> Hi Alfie, >> >> my concern is with the use of a static ISN for each 4-tuple; this >> significantly increases the chance of a collision between sessions (ie= =2E >> when the sender terminates a sluggish earlier session, some segments o= f >> that last session will very likely be in-window for a session that was= >> started a short time later). >=20 > +1, and I haven't seen a satisfactory answer to this yet. >=20 > FWIW, the doc refers to TCP MD5, which has been deprecated and replaced= > by TCP-AO. TCP-AO has an experimental extension to support NAT traversa= l. Well, several people seem to suggest that making the use of TSval _mandatory_ with TCP Stealth would solve this and other concerns; so if we put that into the draft, would you be happy? > Additionally, responding with a TCP RST isn't the best response if > you're trying to hide from port knocking. Silence is best in that case.= That depends on what the system does for a closed port. The draft says the system should react in the same way as it usually does, and usually MY servers respond with TCP RST if the port is closed. If you usually drop, you should drop. If this is about hiding, the key thing is to not change the behavior for the stealth-open port in relation to the behavior of a closed port. --------------060201010109060409060904 Content-Type: application/pgp-keys; name="0x48426C7E.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x48426C7E.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.12 (GNU/Linux) mQGiBEWG8eYRBACEKhMeV+mWFfJM7Gh8zK9fS9Lzny/uKyuTPKkrCXei6VhhzjXJ ir4WYE93wbkfhV9H6RvjApf11+lY/8wYOclYC4YrKCURAIIQv55cIO4WiZvVv+Wp pqnOUWOuSMthAXk+LrYeotKkXdDCexyR3Oyp5UBWZS6YdxtwDXEyxIT99wCguP+5 CIGyeqAoCcaC6X5bE6Lv0kUD/1HS2Q2Ojw84LKpzFR04pe2r6ItyKjHvwTL42lZW AsFKheOS/7wYbwjUacu5YoqFKUwwyPj8t/cG02zUzbRV4DFToPFRDL9uNxrzVQEO pwcv4NLGad7iKnbXSwqWsDy3zq+YOpNkhRpEWCyBvMN6Rk8lgt51ziWIx7tscG7M 5FnlBACAL9xcGnf0sIyjzW6sb/C27hL5ESpiqWDxMryJgnFChrz3esO9o2r96pmN Er4P9T+UdzS1FdoaVd3GPucRdnnfJ80w/wax/WLP6DxPNJfOWuYigzVcWRt6b0pc Ur38bzfgTcOcVYVr7nOBGe4Jq9NERJdoVPyjOSk5lThM32ZtsrQrQ2hyaXN0aWFu IEdyb3Rob2ZmIDxjaHJpc3RpYW5AZ3JvdGhvZmYub3JnPohgBBMRAgAgBQJFhvHm AhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQv2Bwi0hCbH7+fgCeNvz3W5hn /gviUXWZa0aADfZTj4IAn0r+E6vn8qw5zvb6LrORjChNUK2biEYEEBECAAYFAlAN v50ACgkQYk3FZRNepmjlxACfUNqjKE0jmYTYprpiWD9x4RqPgFUAnRS6fw307RdH Xzi5fk9VpHTbN+NPiEYEEBECAAYFAkWJitoACgkQTrrjev9JbHJWHgCgj9UR+PGl Wgm/rrOIbu/8P2C/o+kAn3jxEg8EZeNfku/qYpyA7JkbsDZOiEYEEBECAAYFAkXv sPcACgkQfatJ0lCvrtn5CQCcD2tuYosyuHypO73u1EFkFuM3u7IAoLWLvjoU8226 6L1hY0zvv2rmUBG7iEYEEBECAAYFAkxL988ACgkQgxIgkKLogl5eDACeIo/lKIzT YNd2URDMyiGtZNEVIEgAnAj8R5k79T1+/3pgPtgwBHQdVy6eiEYEEBECAAYFAkxN 5vcACgkQZR3zUj0j8l2bwQCgvq0V9n9WRuTA/L27qzIMuCbEdiQAnjSTm9l+m5LE 65F3s+MYZK50WqjYiEYEEBECAAYFAkxZHQAACgkQbiFv7WQGnVzzjgCfRuAcIrmR bU0n5Zne14HJSz/YdioAn3jTFqXHld/VSuH8QbQsQvVsSTiliEYEEBECAAYFAk6R /Z4ACgkQxxpMZfBZsdFjUwCfSk9OeDDEof8q93kt5NAjHf49zzsAn0szhfdGnEPT DeO8OMe1uRv9U5NYiEYEEBECAAYFAlLPegkACgkQUHLQNqxYNSDElQCgqTsBFWLw kZaPQRR7wSyArvTKujkAn1funBphZutrrk2yrrqkAUyQqB1qiEYEExECAAYFAk+n /bsACgkQF3cojWTQ7raTFwCfXtPH02PWS1WKi0g8TygPbUYv4KoAoJFUy761G8xu 9sKOsokSgO3auYvXiEoEEBECAAoFAk684e8DBQN4AAoJEDtvivFDwh871Z8An1F7 MyN1bfUTkC+3T6mCEsYGwYBdAKC1sOhD3gwenF30o54Wu8KWhEVnf4hWBBARCwAG BQJMus1QAAoJEPKthaweQrNnB64A4Ks7rHsvs5+766lx7u78xbn5JAMvcUkzPcBi LMsA4PXTisd/OV/gkOyZ2mBqKWesU5SuEQqE7xvKQcuIXgQQEQgABgUCUBPWigAK CRD31cm/dlxh43ecAPwPbhZ/nBKRPK7Xh8TcXjRSHe2jwiimZ5nXoy86knU2WwEA kjnncGArwVDy/KZJcmyftdY+RZxTJ9STSKQYokNsWwSInAQQAQIABgUCTFkc4wAK CRD1TYragIIf6gOFA/9sL/WrvwL3ujmnyiIMDB4/JX6wgQxSYvy3MxrJ7mzpfvPA tEn8QqlbD6Qexw6OxnVxVhQ+9s3bpYibdXQfwpkB77if6E5eGBckw+sbgmjGOtxW dqJ0zbSnWMwIUN+EMpNxinbjb2ni5EfmkPpfUa80YqNGcatyFliCqByrU+YTQYkB HAQQAQIABgUCTFW0oQAKCRCyCVpXeB7ZCT3dCAClPgfP0bDZF4mMThhNZ+C1ScI1 WAs6D1+WXUcaOoV1Y0UwuLCNjYldRlWGa5A38imI4KjmHh7JoNjTY4Ms/v/qrzhe MoIdv9wtvzn0wWYSHtPGrKHhsiLDPkDPCtVeKsZfFj1rToIGUYqik9MSOIT+nBY7 yIcj1S3lRDmWxaNve86pMDYQAoQvnbmwAzvwz01BaRfli7K2UfaGAfFSHHHU+NN8 Ernk4xxpseGuYw4sDggvAm4walcFB2VsDnfA0JmXo2uq7/FlPAsey8lk/mS6Tylh yBj1HKRlsCo870Tm4s0mgZLy+iRfhR7/3dkEYsjtsg34rghbSrtewrsCPN9ViQEc BBABAgAGBQJTFdsEAAoJEOmPTfDSnwlMxloH/j8ZFfsjFKY4iLg0bjChx5W89NEW +U2Mh8LEYFy1MTKxW1yWc9d4Pu9h8rod5psE80uLJpOicToz0JIhXgSD+UR/j8ID gdsZ5ab0NEWL0VN5siMb1EIr1DmP817HaeppUrppakeFI78LVppg3hIi5NifQaFt OWSpwwbEGazUtjB2xoVXB1/fjD2CWH5kmPyvXlN78b7Iy+guzCb8TPV9Kp4zECk6 G+NXWVJNbzyCjBScL5kROw7sSuS3WxJ8Z9rT4bDAlLKicAXnesIdS34udavNffnX Q60fzwkI4ET9O0cbxBDyj3h4Yfb6IVk8QZKe+V5In5keZMyRp6ptfqlEP5SJARwE EwECAAYFAlKvFtgACgkQ3CQ5a21FEDjyuQf+OjAfLe7u4xW2VY6mZBY0VvO5+iKW 04qAwEFeH0N0q5NvaWNP7m6oXiGTB6I0VKXoN3lruD0GVOeLc0XiXfJkcU03sFN0 PzX/hE0BlXqxRT6jrY+2zRgMeW5d1DIcvyrrd48zsuucuFIqK4VkGl7s30GkFEYR gCyepLmK2OBViiwh/STiJqag+DI1CbO5agB//f2DLhO4LXGafq5vBEn16gzUq2n3 C0YPyQPElgbNdNUCxFWT9Ujo/9s28cuXMuQT6rm9pq5+tDn9IpqDTwCksJQq7gsb I/lkYteJ3+h4PcF2BsnRjwRiKihQp7GdaeaG+p6vgR5qUtyNEefOhAwI7okCHAQQ AQIABgUCTm87CgAKCRCb0tZAmgxS+hefD/96DhOaSeWYxr0VoEu5rFo2cVEx+AGT 0/tkod0WO46RVUecfImARtK7+S47cHVBPpJrlUG9tdGJqH810lyyP+A4877j56Xg hlB+dmamHcJQ3C+IrI14xlWRJP3sECDYrrFiCH/uWXC25p1E/QZ+WAXywnA52xyd B96OmFNSUhX5rRFPUWD22F5HmKeWyDRJ0u/TawqBnWNDfoI40ka0WLcNomgbdHbH B20nuIMadd1hIG2Yxvw0cPlYCWZCnLlsDllLDOpBzsY77gxde0nhF1pD6BnW1sBK 2Xn778WDZbbeRraM94z2bwBl6qlx3RjRWRRM+jGticBCIIAF9XYTJBnS+wG6jEve 6IMjOly+w7X/9SeVmRPsDHS2fB0Ux0kOzxcWC/0dObdra7LIKwiADABbtfRHBGge 1qy3zL9YsDDeJS46OFTWnxAvERiQPHV8kWwKlUAH48zI0NYGmcnelLFSs5w2PawR I8t4vXvNugRG/aknbgTj1hoqmFsPxFwMw6pGEezf0ft0oGxVBs1tF5RNLBQt6UgT qHdd5RtRC5qxB8XqI6s+VNFCGIrs3EOfBxpI0fjRLlNaAnI5wnosxa0l2PkI5TeE q7FByJxfsuInHSy8ePoQa0cE6NN3nyLC9/oa3Ol0inR8TEvmz6iBSl/06tu3sU9p 223KxMP3+RsSxYkCHAQQAQIABgUCUBOyfgAKCRAoBkC5qUwXDcrMEACBw9i6tjEO tKqUBYXXUrQ5zanbzjr+6swcnsePEAU0celtU4/XUjl4B0yw2VaV3LINLd+WBnz1 ZAblWFtmKpycZ8NkZtyQAolM3g84oezrKUHMyr2c3M2W0yPyxx/ntDb4lk9CfBJa OAT6ahxr512E7AvZMYzPCGK5lP9GW9g/PLVhZOlwzVhSxl6aMumNbA1TtlvVIBw5 4ql5Z8qfjXEjMcglzEpK6weNK30xr+0/GsDizuzvGjMv3tSWbyXtoTLqQOI4CuyX 3RM1BkhRD5muKQVoZ3s3OllNzWhPsPqoPyKQI7IGt4fWOw2bnNHEBi2snCyzI/DH FC/g4JmnVy4EmcRaY2D/U4Surx7Tt7JJoS7/VfF9VM40ShDS6RUHnHFrn/ZulEU9 V8IePCBoGrRJLRBBk1HvsclTpH/CGEIgxELTsdgSS888cV6Jc9gHnUxYZBSTwBx4 NClzKa0cBzGpACpzVvpBsdwBAkY579BfcqeTN6kqT0ocp8IwJKrhgg3MGKUVEaSj Dtw4woklv3oXUxaJ8Y2D02zj1IOss8+mhGrLSgZnCU90iGAGP0oavtWmdD35Py0h 2qklxILtXmTUAt9uYEpmcFUuoitplo6c6adtTEzIET9uPr9UMIgje5FZ3WMjM2wT 2oF5EfZEqNubD4TGwA/GJ6sytq+TOc+wbIkCHAQQAQIABgUCUs96QQAKCRAJGrhW BpqqHDQqD/44rc+EJvvNSg64SmnXs+1drCzEng4ZxK4dOhpbk6HSIVjFyIpnAWUO AKBJSEacnjmWDL9xYSkI51Qf09jya6S+T9EWv/sUgbWhqwO7Zgu+69Ip7tiEaCY8 d/qGRlpRQrtByW29c67b7bf7OAgBGm+fYC7H/3ker+ZLkw+jYiokna13TxLF9I03 q/RQBAwApCE6XMqSUFXrPjAIvl/kCUXEo9npIa12WKg1DDGEKXPi0s//rWIw+pqK SzWNkrmqNT4fN2MYJra3XV7SvbVlNPP3rg957JFDagbWp7hED7PNPddDVcTF0iTi l3oXAaDRjtDE9v/J1smcusDDYCz/H/10tL0N8KNxd7sOW1Rv6qTc/oLk0UGYg6AG Nvip60mndfv7xCazAFIYhIJOzYfrYdy26/M0SKDkBZ23Ju+gYOtAT0PzS/6j8vTk obmizjM5wJWtL6lBYGFVulNINcth1AWqWHKkp4mV2SD2y0GV74q2MfWjI/oMHmeN AdjPcYeZaGhMW5G5o243zicgK5W8hbBNGAbhfiDY7781YGOhHN7x/b6tQYfV5a0l WYY2oAVqbxvqyJDOrJaZphTkqqR84RjnnVnc+Hkf1rNwaAU5lzF7SFd8VKMMzOIp PUztP+cnkLCs4elgD2QLvJqbkGCY6i/W//pMJr5iTtXPb2IvGn/dw4kCHAQQAQgA BgUCTzJgJgAKCRBxizNWQt3oT9SaEACv/07RCpSJdFL1lMx5yNacJYmqicbCq1ft cYbvAWeS4rDjTu7w3+xhpAt3kFvVDafLEiBu4fv4XkpvFro+MHhEzU7HquHPpqNa TTwnKx4erqkOGJpwkkYbg1eiayaCWiCUJoLqHSGKKA3yapswFVKH55v9BF383PqQ 8Pa+Q8iNBRPAoHc2lN3qFQ9kaqju3qKGZx5dmKf0pZQYwIcv7m2+Z6oLoslcoiix QQToLfqJXhkDc2Gri7lSueAWJlo7UO9SI30IJV5ZotvAVWDQOxx1dDIOfZToNz1d vQgTGapmYKhSHRBeLvcea5E493/5WxVZh/qRAwGXwcCvR0kCATYOpeqxlLbC7OoD JqPjfGpFi/954o8mC86HwQrKOTN4gGWe0JpGUhrzASms/E3UQcvDfr6L3sHfoVgD UE8DMMDsxGzf6H6gDx7IcLketBGY0asWV7oDcV8kI1eJTnpcR+kGt5tWniU7f8mN YICoCGNPp0FQjwGQ5zm+kYp+rSy30/vh3O1qL+4OjuRLttVpxdt8msmdPJcCBtpZ nBuxs/g1AY7plXgC+yUleSrZKKUw+a5zvHKVFRnJpgy2Fw60Tz+AE24zDrL0hMpQ Ul0TAe+9aL0aIuVQPNUhhiAjyXNn6mc+74SjK3qGXNVEE/Ns1ljqptW2LHZ40e5A cEdtyGam+4kCHAQQAQgABgUCUuwk0AAKCRDCGFJYGfeEUdfwD/0eZb+QD0ypJC5Q ZYFTlhpCziGASIaCh0DMCTkJHFaEYoi57n3iyuk+RFNQ4lbJn98fdEi7vqQh3QOf tyI+UOoSDkTs9VTQdDg6ckGNR9UVNcQxOCTc9HMh2ButsjEeUrvQ5di+Dv1p1cq5 54ZTC9X8FO7kS6fRtlih5SPri4PRyQ4ddEmTWTywq3QaAfCZ+ilMgqdNPpCp7qRk DhVbUbgTMusPVApuDCpnm/gTT02sPZ5+/CAzx1BBDkf/y9U9/Cg5Huxw892sBIa8 IIFhGwka1dyiaYR6qulH1i0cjngeZd2f8hC/ACmpm+qs1tnYVM385IXUJrODMWMv 1DjtGJFoPQ1oAUwDt/2WUvEnebIU+yF6wl/toZDkQnXP1p8LIPrWC0JF/RkB8Wz/ T3ENabNoDfiGosvIK48RO56hQJNfl5PU51HRBZSbLn2F6SqGFs5P8u+UN5llaieH uqm3CgvVeR1Fsl0WSEkVKx8EcHGdz7bZ3lb32dEOX/0crUH49mqnyNineeOVpoMc ml/5jOFt80rlrMpD/XiUKnzoNTVHqcMDfAi/teK2FrX3q4GB/J2wY0fvNFwt+sNP nTSUfQslexdlcMK4EKUjXah3y55qChCu+/W7y1vzoar+t4gagNwzWoV7iqGTFcza rH4cYpaN5Ha6R3dSljnuXKgP+koeSokCHAQQAQoABgUCUkRHBQAKCRDiTpLK54mM O2EMD/4robjOeoshY9lgIoCQVniE4BQ8aL9KGUlniM3Wki+3R8uPoI4WjwNZBVK5 047oJfYSTqkjyXUsCWOEJ+iORSycovTmbLfXwzMbQr2dbgqMpZmTvi3jb9jAsVmH CqfI9VkxVDBOKW9foVbD7WlSxRCahNUciJGNG7IIKWMHDRzhw0l2GHtHr5EAEM+I nFPFc7Q5ChbBoricNkbybMRY/aKUVdWoXU3T19xMW3pJZKguPe5uUjMa2cSNIXrV FbJWFFeom/hV7C8zwSKGCQ++AQw+bWMbTLh0NcHDMtnQXha8o4ZCpcGg6wmfLCFk WAIHqhs1YXztzD/86qHn7SjcJJkr/1LPm7JuuGjqPXGxWtYefFtORD7lQlsYp44J v7bzy4y8YqLm+T7tF8fUgAwXfSSDsYq0zSTLWKIxfUGtkvGa/WzA92MeMiCYneGG 7Sn1i6hZsQb9r17SMatGhsRwlh0wniSiyi468+LUpq9k41Bfy765cP5xQr4zMLtB aoYmqO+mEZYa8yXhA7x27r0jhEjdfb7q0ka+CxXAlzppW1hWLjkXuQkAVYxVbDy8 4NCvfqYRbTrRP/RcXcgjK0V80Yf7QEhyG03mphfqbr1I+E1MPmng7gdVCGPKPSD4 IPQ6VDed5LDKFihxBWOUP3U+KftCZFH6+stWkNYxmkXN8ipkkYkEHAQQAQoABgUC UxShrAAKCRCwC5zILXrfLGqPH/9Pohpq6Fcd5emBv5VJc6rDjTx9SRyz9jmVtBDG Amee3tVGGJNQXUY5OuHI3+ltiolOdf8imoZ5iBAfFkuTnHy9qcARfCv0beIO2kIK wnvKmtT1JCSs3ctWOQjMjM+AfD3ILySnKRiIVmNKPzxdN2LiSWFRWPCnDtv/5DnJ 823L7HlrbLLwkaG/uqMuGEN85kW16wooEjfObQyatHnkgnRvXrj99MJ7RWp+jWPc E1UwTbNg3yfxplPcurG0RXX4tSW5r7Fc/kAeTFc3xgaOwqYeuvYjb1KVoAoQkxEw 9Xv09LsVWE6+PWx23ExFZWTjqE/U3jXH35kFYeZMJ5EYSpJ8ONDLTj0FtlrmhaMV I8beuCNvUoRIuk66BTlZcbXdNi5lFwWzYmQpeaGAkSyVY3ASqVqPCPrv6prtKC5J 5+Bza/MSZuD0MPHYnig9ZZd8fMJTLhdVTHIQR7S2MmGUzOCDr9HAwK6HLl4Lb8IO sNP1MrCw/sjlmNYRkleVLjN9qnHWBI+ua+C8e6HY/NlpfcA7ITa5VAp5s3EjmRQ7 97eY43I+BE3vBDwzEe4dfKbt5wHHUDs0jZ5Fd2hNoRDqgxQVGC+bu090Bvq4OvDs Fcupq+z4um6lDw6OhlxwoLlQOducCfDyPawe+CSMZJ26grT6LBUSof0mqQeOWRvQ q4TcFgrT85hDVHvLjIfEkIlTBx/5hxYusigvO6YJQ61ssnNAJsbOaPMfE2UCgE60 F94/d6JjOVeNWX+hfeWWqgnyHpkm7xYqshdRwaQk8SmBsEibfV8139MsWvYdXFxa pfwGkT4WRPy+nLwUuSMM2+tL9QyFSFe04qhdk7jhBcfWH9KEBvs2FfPS3/jdtev5 Rb9r/AS07c902YKVRbMKPoKjl3AlirFSWdWNsf51AILAq6s58uoNT2KdHfo/AS2M LSkBIpsXEQfyj1V9LDwByICa4D7lGnKbJh5MpAw1pTQ4MKPGkkWo+WF/sG0cbz8M 3cyjzG0JO1WiOP7UiHpvS+blvg6VNQxEi0Yk+jV8pavXRKsnwJ6FTSh0VARH578P 4RzzoOm07GKWT+RKa4ztaza56vziJvRy/BKKKcIo/qy0qBbITl0MbXqq2nbWS95p lyaF1y/PLsZltJw4H8ybh93NDMbhUfrJfh2QT7Xz6nAgRCPYJYtaUxMhnSbf8CBU RHA0x7JafA7j8NsaHXvH5nKIVGJUs6vLSmebJDmbndwIgk3EVS+MKBQnHjuA7dpy wffXCacdk01D7+e3FxyqbxY974kyrZrpNx1bvrwhgDSJLhbdZXuheGIjGTsZO/qg 3Jc0uZ0SblHLEuur7XMUROKgtcx9SnJZdTdwnJrP1gNyDiQTtCRDaHJpc3RpYW4g R3JvdGhvZmYgPGdyb3Rob2ZmQHR1bS5kZT6IRgQQEQIABgUCUs96CQAKCRBQctA2 rFg1IAa2AJ9H5Ep9B26MmNxwSEfvs8gseQSEzwCghHWYfftJtIV+Rb8fQaxwPyaS dKCIYgQTEQIAIgUCUjGT4AIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ v2Bwi0hCbH5qRwCgtclA5YgXCG9H3qPoCkH1q8x5mGIAniFkPuI4a+lHXaw0dBm2 iHsGsqHNiQEcBBMBAgAGBQJSrxbYAAoJENwkOWttRRA4ZW8IAJ9yqwSyfwc0bVAh V394s9eEKMPAm6Nqt77uFmMAbRzrs6IZbW/lH5D+P9Qg6weTHFvg5ZJOFd+kkqrn dKnd2jgEKXaSnKT+dsZL+tIIBXUZgBorGZv2U8tZK2NPFTaq/sgqrDZoYkg9Q8zU di82JJLtgk4IWHSAixo5myQMb193o+abd9ujbe98qj9+twDdC1x9Q4kdLt/VgwjR 3v544vKsrEh75ACveDcDc/EG0EIK6+FYUwMvALwQRxWyrbyRb/K6X1WOpN0hLjqe pY08/oQTbvOYnWlSPy5jHTgpA3+lPZYWms8EcTINiTsgtMfbFcC30K3TXUANzD0c dHp3le6JAhwEEAECAAYFAlLPekEACgkQCRq4VgaaqhxUxg//bOsQoKQGDQBFKjJx GQ0RmrpDQSphHeLx94r4jZrzRYqd927hsaWl8aBdk7OhiRTaF9nGMEO4goK8JyYa ihlVliT/l/Xm/EVfbvIvM/GYVtSm2ZswWF1ehv5wHkWHfuEdj/Oft4O6z5+eazyN jIujASR8uRQxKD2hY2o+3E9JWGZYHVhqSVGWgz8BajPAKWcbNAd0QLUQ2k789Rca owhC3Hk7PUAs2rZ/ewBe5BIM7jnxrQqsJLU2Dk7cHBIRkCot7j9zxTnq5+HeaL/S LuIWz8IHH06qA+STfHXoixr5uA/RKKb/JP9L8O7t+8qNSr4jVPmwPvghbjBOMUNt TnOP2bICQuJu9wUG1F7vngYHqv22+JFoIQuQiepyC4FSMP8+SYJOZPRdpfrrNQZe t5D3c6E4k8ILsDliEuZuj7d+ef7TcKbXKH+hhibuMIudezPd58BBFoIWySFDmwuE +e2p/KuYzXudLmxlcyM2jcs0zndPAUjaxROBLKP2m2UEIN1nybdFHBO6d+7C7eMR 1dcTgwSp4IN/k+1qhyTCnlMPc6kQt1CDdC7atCXvXTErOBNjioktmK6ou5/WTnpP wew0w6ozr+8+iQLqX56ej85pJXOOnyQs5395wRcR/lk98wvmNftwxbWpC6GcD/YE o/7zNz8zhrQkZwgroFMQMrUtkTqJAhwEEAEIAAYFAlLsJNAACgkQwhhSWBn3hFH2 OBAAtz8iEHOJEppKjy+D0R72xBQHbgYMWjGK/zH5mvpeseFm75e04FknIlLJAJc0 hlkPimZIPlymvSLW96+kTD0geLf2lawx+BAKSAlp0vCZQkwzXj7+StyvifT6UC70 aFydYGirwrpI/fd2pw2K9qsNCEAlwXpRgjzEXIc81NjYszr6WKUi1H/7hB+93Z8f SN0yyI1n4w+O6RCLtIp/9cv4pO09A3dJyxuoCjsE952tgqRKTfgBWunRhMo7FZXY GGl5hW/zVRfiOhypNZPu/L0oKwtvyrYNqmtUzhPnjCtctVds85MK7WqUly9qJbeX qXSTSZLh5Faof+n+yCguWvznf75SvMMHCAsk/M2sQ7PHRWGQX3V3zu/eDIesFcxz ovpbHBzlZa8RWDYSZm0bzq0IZnkp1xLR42D8YLFUG33h5WSuI1YHfYMzwWVdMXd6 N82JKQtIr3fL3ro8fD6874oRLfSP+UQuIK6txSvqv+tlEoVKVEDqLAQo1fxR6TEL f4AnHHysr2Hqvs+MJwFj5D69ieKyV0OWHioPA5RdjhT7KJtxtYTNPNXSSd27igJ5 L7pH+vmRm0iRtWFjUFw0mhnhkDOBOlJzZ2L+zSHXClAIfm3SiHCSbmILda40c5qB 0OHTE+xSj0J+aIyMsD36C9SmN42MBzTne/kO+Tb3zlk6JnOJBBwEEAEKAAYFAlMU oawACgkQsAucyC163yxBMh//S1li5UZ+Q0lRGrI/25HSqlC7xLuv5nSFrwXmgHpx uPIVuXyWywdyMP/sN2NbvU2IrPPjYhyQVHrCIG8HiI91bqeM45E4JzMYULM9xA2H OkspWaN3L6sHBW6CT8dubZZLVvjH93BaQPUQFKrvpX8FIQdWYXyjY4wjVYNxenrp qI5/PgX8f8os86rK5nHpBNG6DtpVMVpCPpZyMT4vyppgSQd+8OiVCZMI8/BmVKXP TmRTnc3izcm2+W0gu4FtW+9t538QvHdYejS/aq6ASGqRpW9ePVbSKzmZtYsfOJOt eZIVm5nmMZKfSUADy/dauyDSUWAFcp1/eSao3TOf1hlaa1EVZsubMY5Ls2XTQovI hmNEjBsJkSaVjqEVcYQ97+pLNILsxAkY1dTqU2gQMoqWosVmTsOUpZga66k6VK1U 00HsTi0dSqZiAGKIjKiLhhZ0JGhZw8gtaKxiAm8/lr5VkmMLcAuWnjauNfvxIRHZ 5a/rRB3cv0+13QVs7EwI1Bqax9D0alXTirZPgRdJ/UidHXG+Wxpu/a+KzBbzVE3e RiTEPn4+lxU+CzaMNk55CxWELUyavdY4hGYILukBIMXsSYGPztUBkvu0NCEBj4Vu VIFzetkCZ6+TM9vqD6T5+f5JoqCtmnwoidwdHmqawL++CQf7QYEFj0fg5GbKm5PB Bh0cKpHJSxqO/JpM7julFW5sqy58XqOzRvEstnOvgUVlQDj9zvtfv6j6O1v9Ty+d MfxuA3tzCtu3BVjCAZWIMSH7bMedyNyKh1rX3ksiAhN9y8zuE/h0PrPEQD4rnyrL 207tVcv7fBeQIb+71M9oQU3MtRh8AA/DRgtozkjmMtnrxal5VgrrcXbptto8ysvv LBjMTd/3y59sZZwvKSmz/+BBAE7toS/zw/zr7l1mKVLmS159lPdATKUOetjqaq2x MBa5seegtkoK1Bdn2WrGvLoxqFMwRwwUQ1scw1GwrzCztrH/5m4ZBTiHGF52YC5J v1kcuk3ojo1NoKQwrprIXPTQLaaMf+SVD19IZQ3KYEtZSgtPIh9CJcEHO9FlqMF1 j9RR2tR9WrjVguY26BYwFATd/npmu+kjx4ziSHxJSi5Ydt9MU2m1jPp+7i1rN8UG 74ieULBOge7i6L/63zOZmArZ3K1+vEZKbO+e6kr1bEF5Xx/1DxxNGz40RGe8K3RL gQINCWtWk2L9RJJGrkc8gcKI9Q58aWphSya0WoUORLqxCERP6NzxtYgnJ5G4dBKC Q/R8xNYKOdubRQR3W4bcFUIyQVrHHI1jRFirunGAk8cKQOZZXDeF9W5Eog1frbiL oSxGQ6YDtOasF0tBbev+VM+Nz54NRAcNUqeEWVTwCqbRfLQnQ2hyaXN0aWFuIEdy b3Rob2ZmIDxncm90aG9mZkBpbi50dW0uZGU+iEYEEBECAAYFAlLPegkACgkQUHLQ NqxYNSBLJACggjVkOTWy799WmUm8imh3HZMQIJ0AoLSweM6T8mv90ZMtoErwcZSR i0PBiGIEExECACIFAlIxk6cCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJ EL9gcItIQmx+vb0An1MmoZCJS6g0yt3zYyGfJHsAKq5HAJ44c8HytmeP5dZWXUN2 FDTuVmrWaIkBHAQTAQIABgUCUq8W2AAKCRDcJDlrbUUQOL20B/9QarOdRUL1SNkk fFRsOpwr0nu4nayuy4uhZQ9TNGevm+/BU9Q14aE0AyFy1lRiLawIuAgd6zFdDpUx dlm/GQmv1gpZB5xENQTXJqNX4NN4K9yN4RVPhsJnLdUrDX4sDz4KmspQYc1Etq5i kF8FEUyn8K8m6uVt0C7GVPVMxxKbBjMLjguTLMvm7QITIph0IHjifSBUji0rislW xDobc7T6x1k7/oCxyBVPot/+GvhqNdIGwbu8AeHJmIFCgieKfqL2GcykmhhOiw5I AoCe0kYUUyf4uuh34M43+CufmyP21yrC6jvGJIhGJsArvXpXucL1m/L7j+Fjp0nc WKdWNNNgiQIcBBABAgAGBQJSz3pBAAoJEAkauFYGmqocLg8QAIjwA3EfG7uz/5cU hYnHck3+ioBDFfHyicoYltmEedmbNyk3qW+wmBsOPMqbjGWxL5fZRbkxN3n+TJie FDsYMCOZVntT+yZPNvb4BfSCiDc1jTmVAHOsIED5NnX417deIM9RlNm8TduHwRsW T40OLOZ5L3boRLf8siTbITQMcMC1wLTiOBdKZ6JaHliYLnAJ0gUpi+V+GdZKMHdn zpdbdPaxNInb5l7gwvoy2ffSR11hF6oVjymnwOz55Ruzi0ZvKMUxvmfnJnt8mDit kfjjPkqfv9tV608OecMiA2Mr0w020aFDbpaKi7WBYwSJ3Ib7vxY5+VfVjYkkZNUl A/tQHOSJ7MCCE5BLFcXjvwoYmOxz3HyyWWq+KzlewW4qGCWtyVPKrAa5HzvxxBGj JGdZ8QCIa75u8zQhzKbHE148n8z+/VBPcZziC5DRUxXFynUvZfHWZS9mOH1CV+Os uJnzjy4Eeu7Ikw3vZ0GYSbkeMxpi1UCmccofG4YeS2ctVvwUu+/diD8NJ5y9zu7e WFhIZ9Yrk6TppiGxir6kHubo+sBuCs2qcjuy6kQD8SCzQhCPGxufgemH1ONtqxcC ++Rwo95HNzyXbsIp1zpdLUH56dWjVtxWaIeKa9iCiAWmFIk20bcDaaiGGH05oxnb rYQD8TR3eQ5EKRS532Lcz6apEAZ1iQIcBBABCAAGBQJS7CTQAAoJEMIYUlgZ94RR rTIP/j93Mcvz5wK7cVmfHvvx7WMREvFtQPbqHck1vpk6qtaAooMS2IRdeQuh+5qh X786LoOhkaA1IjVDTqPiPwbJdNKCMq4AGmpXk3DJkEOKjcwdGs/VZSTLNhSO1W6+ 2xJaDvxl8rztV3CzjEiXcy3zXRXtwdmVN1h0heU/8VnYa0FOzFKBwhCvi03I/zoI PexzHUvp1l1UVusSMTAULZ0vPSc56T/xbwEs5WayImra+58NfC7Dne5o3GNWnoct ziOfV4wKYRj/4CntI+PLFvDxnFfyrG+RgQnFXhJ8WU7jLRTIeg50lsM6pI563zF3 hzHgnSn64/XEtVD/CVE2ifeXhIxf8VEfh99e4eTeNyWDvM3rqoSejP8EMDgsRd2V XoVccOc4f14qsbdkkBX1Daep6OXvtXwts8JrG4o7PkduEp7U5hCJWqzsGhF1aZhr 4uk2uF9WBNk5T4F92/IZp/dSYMDINjMVtLTiTcthrY1iwG/Nnjl8IVqT+k/R/ARQ GQ6PHcLo8gVPxZA7P59q2PZo2Q1oNQZPG9+9VwR2F/VNthfPWokG0NXK1+QxUvbC G8GBMyJ2MblIshQ3QdQ+V0uhIbg9amQ5TKHR9QrDAdigym5dMcIvaGG9puZFP3M4 kp11xMYm3T/ygSLYDcXnD7t8d9YvwQogZmdKDqEvegTNjtpoiQQcBBABCgAGBQJT FKGsAAoJELALnMgtet8s054f/1coQOW7ROk4eRs3OHXa9snvGe7WIQrn5Xj6YEhW 0tmepnNMmnajgBkwYsY2ftZzc5yd97I8YeftKEL+rHbmg9sjOfg5vpiQqIiRG9r0 GEWcUJKW1xQSCVmasXzK8XLIopvcZFWRZcBRmMMrJx/jbgCoJFV2IUNfX3t28BLt 7TS0Geo5yPhJK99JLlTXuiI5AbUjHbXt22bMv4/jTGo0DvifkKCjIACGvwJZTOma YyUiDRRQhCBH+u3vTORI40Py7QDtWM76kji6pIed00jI6Hawum/gsA2+3jwHCzt/ B7v1zALGchcvyXkU/308s1rlp2NjPbnXPVIyax9Iy6vg5xn6Dzpafiv6Eg31pe2E R3s9bXtItElzWL9y/M2ftjrz5CgUluG8aX2rvFvWniANYeRPlgBdL1g1Og2FFhoV KTf5jCAiiKzkanIvRjfc2Yzgcec68MEpp1l+FXx35Ag881SAx4PV/qJ+B6wdHtAu SEovlBKei4Oj3LZwaMcAKuAr8ncXH5eV+Xz96V7pkq+83scWp6UXFq61TvBYM5S0 smE+IoC/bV/vSxSVKfr/bNdaY1szdaCUKOzE8gPru1P16Tf69Meyd7TuEgz3dE/t +B+28zlU6T4cZPGht9eCeyBUk9MUf+d9JYefZkJIfk6GFoMzpgySNnHf7R+Yydhl jtUQoOJl4Ao8CJFdfT50Ww2PWcN/F73fOYWoARHvm4uXjXaP5LsKt3bYABWrLkKc mKZHh+3kBCXHlRbbPxgZVOcCr6sydxdxHi7FLCdKlt0tWjx1AthPrkh4ZAOZSNLE r8GFl1D05ur/33cYZBT0A+vWiEiP4dDvQ3dtFrRwMoCPCSalYiYta7k3ZU0++iJz /MFgXS9LW3FfUKPhh0KmDOxbdPc2QJ1vmJ6d8apuVb+mlMK7SG7NzwlKg5xD2Q/h /gosE5bLh3ZjAuzqUzE27TG2q9f5qJ8iCSKjUDFeR+UVnIMlz624OfDeF9NfQnBr eFgAXpYC7TuToI9fNMLOeuUY1DndcXd5KPBk7p2Y1jj6PhPl2T8sLSp3fZi4pIWF OS2vOFAj9/lVxLoAJjwJmlDSsAuMmYW5TKnXF0jq38gCwbyvJcax8xnsiWnUbaXK jNE+6eCPV2WDd7+d7a4rK+U3D14B8vuGnSxdmOzdhp5BPxpDh/oFETH4IRJm5uh5 5RzGpCoE+vdSzMTna1R+4H9dO5SnOhzkNRpa64V4sblCwi+YJguWYHrE1lx9UXt1 3d86PNxuBgFdsI5eTfliOfR0kTKQcQsiyP3aYhmwaxeqttn/7IhDmnL9jbl9VYcH FD9lRd/pRgJcSN8Pc+rviyKSrQ2HbGSBvJo3z9mjts/xc220KENocmlzdGlhbiBH cm90aG9mZiA8Z3JvdGhvZmZAZ251bmV0Lm9yZz6IRgQQEQIABgUCUs96CQAKCRBQ ctA2rFg1IAumAJ472+7dXQsxZ87ATliBhLlJNzAIwQCfUAYJKQDF1rO4OmN2OjZD lsViaUGIYgQTEQIAIgUCUjGTbgIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AA CgkQv2Bwi0hCbH53NwCePdeBGKHxYvsxHYsBAG1OhSWK+v8AnjE2LHs3m/T45k6W 5TtlWxUcRMyFiQEcBBMBAgAGBQJSrxbYAAoJENwkOWttRRA4+0QH/RzGgkMKVF2x Jr2HTFBkQXUwFB6ZlTW0iZSm95NxQpSIcmBrIhyN1//zBFdz4iugQQLs3EL4qgZo rebfSP3PQHZc5UfboDf4fMGpPXaoCUfdHHnx4R8a+i7qwXT094Z8i1kyFJV76yd1 9vfqaNikfa9a9nYvJRmCNqTEz2DRNCvwgwb7wJquVqQ6VNaFSZkNkwxWWd8dLjaT 3PVIMODf8Grsy6Q1KcIxuzqkwNQkR/ZJEr7QdJ+5KEOjdTSu/yGPnrJM7KpHOFMu mprdyLWhFtW+OjI9HV/OfX/5Nf52ELNw6n84s3y5LlKcrTxL7IVDgAq0zbXC+YSh 9I+M5/aBDG2JAhwEEAECAAYFAlLPekEACgkQCRq4VgaaqhxUtw//QCzUpaTBCx01 PCth/VCkUzNofbYSsCkL9gPRIwVaxHg3cdlPK5+jpj3FU5lmMI2mkVEMH3SzKhyk 2mnvYwj8iYFMWNCmnJip0vN8Fu3RykRLfNe9RdgHabuqF2BgSbtE8pUBxVbJ4k9r cgeHmsx8bKnUb43r2F+jrzYrg7hOd/k5LMnoA6jmk4abMFko856VDpnj6iyYONIl 61CUaKxpya+5J1NAWTOPwDwZCbS09PME1PUTbRUJsHT1MwsA7xRCB+YHiStfA7zD uTHW1sqmmHqk/RPtFbfk11akEDamdriGkO3ls1DqfIfhaNGq6xGDucROjilk8SMe TAYgkkWvG1BsSv+mALe/FFVg8nAtQJUOgNXer+d/EJj17d3Gidqd8APFaIIKZYk4 aLXL+WDLcDfvzjZdDBm2B2u3kaTi8K/q4pVzxRGsMotcMVwfEewC3njxBf9RB3OA liEHGjciAbbMDCM64p2lpKjPqN/w+k712kBWSGX2plGxI+ngWG3r2g8RnlFZf3Bu BowWfjVekXBeqJUpbv4d1gNyptNI+52YYCqDtWywq6ekqcpwRy8d5/kZak5YbbET WAUJyc/SYPA7WuOw22mmem4t+Un4AXusnY27uzubxJGuCAZFi8g4WrG6N0PdmiDi KBvF5wegkLsays3PKKOrGIKid6xDW2WJAhwEEAEIAAYFAlLsJNAACgkQwhhSWBn3 hFFNYhAAg/id2bpUM2YESiyMwODNxJrDjaVOpw1dsZ/vnuWUcW1jpu9dYG6HAu/v V56fZS6X68A6jUIi7HTEFD1u5CwKyzc6YpZT2xGata3DBplfDipV8/a07aD66DN9 g7Gi6wBzbvkwcZq8LMVpWaoT3HTd0xurZXL80hFpl6/1QHYX8q+PCBJAb5DW4PaO m3uEao26uiOYJD2Ib39qg51se6xsP4LXUd1SRjeH4aOcIb1ViNQh+V6GtwXGvQze d9X1pBw0VwKWcxQHu+x257X3xCtVam8O9KSSh6Hb61O3paTYuE4oD1HJZV2wbXX+ oH9L/LIdjCElQiRJx1KIGiiG0nxiqUYGC8cIOBZe4D6XqQYXaTueR8nCX6rWPjFx ae5LdcgLLfyAVnnL+ncVxnOKyH3J1eYXIEFIFT9kIjAINQBxUNZhhMM+63xhu70O L9k3yttXL1kOZyYK3VJfCCLf8LstpWAZADepGhAl8B3A+ZCJwfcTFPKEE7wdCS0V v5+bZAlJY27mVynW3PDitmXJDPz9+TYT0BjEc6EGkEhpzU1UAOBJXcGrwJYcFwjk B5N7f1GfpTsmwvguXOdMuzZbLTM+JdWIVYPAyuNOfIDCgqiFwfl0t5CRlPOQYD3I mTu+tUBpIEk9/1dBB7dKAa3I6koxFrloJ9cpyRualsRlK5T4KwmJAhwEEAEKAAYF AlJERrQACgkQ4k6SyueJjDs7BQ//Xb7nizRW1Zn5oOyGBNofGjdWp2xOCkQIHQwz PO9h7ahhnTtdNA2yyor3Kkm/Z5mbSykaToVwSUImzPsS5aVV5voypJ01595RmxCw 3gRekaSK7QxymfGc8ri44E984S0hahwqHRgkJdT0lUB3xulHJlw5O+Kr9wk/ilf8 jGgCFpS9canPiozmt8mtRI/aXLBpnxNqDqkhAMhUm2XAdo1sh29KyMF9BKs2JBfB Cgw6pJUV2SkUSHvBq3cX9tz3hLj3wVv7fXd6stOCQyStnCn3fOySUYt6NSMpPcZ1 FkDleaZQ/skahMkp6113IToC27P3U4ePXP2f7oqomrXKCL/SplmOKSleiOXdy3Yx g+feXw/wlD2hlU1BmjPSMio01HNZxMMCrc223mYQmdc1twZT6zjZ4mG5ZL73HLVK YvgLq7xCpngLnfehCyQoYFKRrPTzxG1yGfnVTKYlbZBM5jnhVih1xGWKBsnNg+kv 1etOudQx+47nBY3DOb5KmnK9AV6elQSZDRcap2VvGDfkf3Zm5P7jnohEwQK18daL MllUFxVP0XixYsQ8d3bHYilz5/enOKlH/nVohaeRLnVktH++EcbNBCPF/zRwzL7z zHvEIfwGUfdxd12U47Yi2GINEYGmLn1JQwia9VS4e/Ci1PRsK4RPSzh2nN9pyVB8 TdtAp/2JBBwEEAEKAAYFAlMUoawACgkQsAucyC163yw7OSAAg1VSmjoGveagb5+T LIsY88kDFWc8OT9SAteLYs2U8ywzIEFeVSOmUAHf5s4zq1GWQVrpDBBzKp5rI9i4 tLDG98QQGvc1LOJVPKfaIPQSQa+woL84Fje9h6bm5g6e9YThRDARhRyihGJB96fl OFMmOfPkZ7KLryH0kzKVNZuHIxqJBDqkL+J4r1KcJtFQ4E9sKaBFWQ9qQXI0VL/q jKHwXb0lQvz6Xd1Io8VSXW3VBmheC52tfVk0UlU7gzFPMeWkRR5XBUjQWEzPAngl 7y+r9TBqUYDpkboh5wGn8MlYoNR5sv7IyL1JAE1oOUHO2hay2HwrIEgGqpqGYik3 eCQeoo4rZVj8AwpevZTDKHWem6gLgBfRPmYkHlL9hwPJVe/zLpBfjcGVWvBghuGu TVcIUc4Dp3W4cjJm9IMQxZzyQt6CQTqrQ1k//IRLZ+Y02VYuTstbii05dXYN8P0i E6NyAw1ZgVEjDJvCXAPG4WZ8riZkXwyv53EkM1erjdH3/x3fooFVdWYZH56m8wHG 0rnzcWMNkbs5jD0SySraT3m7sTDM7Z+LAvFfO3ssCJhn2LF4B9Y4vTFiU8RrRIoi VPdk+n9d/v0N8DLMnQPGT0qSkwiDIioov8DWuCfYcdttDCF+jyHiJevBSqtRCNt4 Dl8jruMdTKpHUi3rI+akAJQC6plB6ln4SIZfrNJfW7lRgrXNsEAA62QXsocMNZjl 2LYcm7R3erfXryBy9daQZofWwc0q9KnvGvvLvYzE5W0n+UAOsLJrZ149vAImkq5S pOoCHGPNlWrjT7nz58pe0Jg1diPDZVr2Ty3jT+g/5Pw9WdrbofqMd9IjWMk9pd0h VCxDlNdT0onKOPexVsmoB9/SdIYdDPvfPMUYJgwv4ckkAQnlphib1JvuLOcVpozS 1MbOrij7KhiuGNz/rvslnABPl0YchWDXxanD5t0eJd/E/8G1GKi/VOzeXccpid9X 9XLw/KznTXdbYU4paF40d+uIESCuKbNxtGnYtJrCIEt6TxFsxPEbFENmKy+OXvYx lpKajTWgB+fbXeDkYRKiYqmNsF0ROFnbIWNIv1+0CEPMLkx7bI+qeAv+LzrDtoL1 EF0jPCgXFwbagw+oV2pvaqzOtTJeAkSx9cki+XVm5Eq4dYbnqoRReZ6kk9Dx1pRg o5h/Tvop/FHi2TMSRMFkXDGpqsM8wbOXTvg3vYp+TiV/KWt+nYHD7X1oRTYGDfc+ zQLUzsVLrODylhy7BxqpDdSsKNjm7RIbDcnef9D+tpYHVLviRn85CyaAA3t+0sIT tPQG02tVGPjEfzbRStr5xYf5eVy1P2lgB2DeA5d3dcVxuTQ0R6zfOH9x6ZlWeEPM hnSTVLQrQ2hyaXN0aWFuIEdyb3Rob2ZmIDxncm90aG9mZkBuZXQuaW4udHVtLmRl PohGBBARAgAGBQJSz3oJAAoJEFBy0DasWDUg8JcAn3rGKrAbaw+8G/8ayo0rSliW 0dWoAJ459fbj6W6e6rmnQ/MdHEFwaHUjPohiBBMRAgAiBQJSMZPOAhsDBgsJCAcD AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRC/YHCLSEJsfjscAJ9Pr+YACJEhAYpA6vuV Rvxcow0lFgCgoqN6CY7GF6eGRW/UsoApFOae8EmJARwEEwECAAYFAlKvFtgACgkQ 3CQ5a21FEDjW9wf+OgSok0xmriQAKNgbg6WoAqP8IcRHo7WL6YauxcrnWM73snY1 WhltlQXEfaxy8fSjuSQPmKnOt6RT4o8tRVFI/767ZCnyr++12bWsT8wPkhorvl/f 5/xnoTQs6BrXwB24srIYZaU3AlxNS7kSUhd2aTvzFMfrzHZ4f7YM74oIK8jzFyOx oIqH1swrEdg4rwrxThc3Dn/IwZemhqjWDYLYq6B6ZUrMWQw5SjX6Vg1Bhp5LGJms PLZe1OsfU8Ryw/6t1rWY7wcisxMr/zOmx3maL5cXARPh6lzDz1+h+yMezyEVPUEZ Y+9CtrFc4gbDZlAIMtMQ+XFP/IOgHcgnnOr1K4kCHAQQAQIABgUCUs96QQAKCRAJ GrhWBpqqHPnmEACXfug60yglEvylthQWomb15DCE1RpV6DXjlxf0UUN1SeoTwMmp Cubznk4k1W+ueil5RqWAfQd4ZZfa3nAQudyt/y1cToKjGCpH1PjNp+NTcTavqkOC PVgvOevfsJ1NdhdUO5lSW9TpKUzaIunJVA2Ng9ciurO/QKaE2LmVNuuAg9Bcncgu 0a1az9h44x8CFTUZ9r/tpHirlGX37JlIbYvEwZCtl2W+SF0QMFL0y3FQWTTVDDUn wFjAlWYarJ4UlNbpCWLEZ0gJ8SIzZABvRyE9jOnuqVYL0GLd7VPf/CmXrLgWV2p7 +ttNPQmI4cyXJONGRze3uaabIgQQl8nlzlUImEqUvJmztSbvdpzB2rhSkw5eDkuA 4HDThT1tSsSSyPdLyqBHOkDG946qJfqmqJVy94DsJRBs/9L+98n7bRYvmF4MLKqd QtZHxg2nQFBEI4NyQdyab/9Sd5Qr/oTs5mS9QQ2n1cnJw8hS/hpjbuA7H1kr99/N Bek5uYdxZZfZbkDg+/xQFmOy71QRzJtTm8cuw2HCSdwqNQ4XB8hpTU982WxBTeaC Qq6XvT/Nrl2IzsqGuEBxaP/hpk9mEiN9N5YtTfx+OdgEPwZ2yZiOKVWI+pwA7IvJ yhJ9/eI8GohigVoCiNSKO0XuOdugnOLtc9wRb4pAfYIh3Y5u/2T3pjjk1YkCHAQQ AQgABgUCUuwk0AAKCRDCGFJYGfeEUdfbEACg8h0DJSQV2SWN8zsNyqA/6BFvuN8l KJYl9PV8sa39Vp1rlC+zFvZjET4ig4JLpjvAgcYkmokYx7PPLZXYVI5rAi3nyndq qm6brZp5qc755bbri30E+BhJXwxUqry6jBKYlvm+wE3Q3WZExY7bZeyMnlj9lXYx qkomXehynzov1oUxIH95zOFuyI3OGJfXaVO5cCFn6oiKsx2SPwMiaFrw/OFiCwI3 RLXmI2tinT6rjjgj0qbpw6NS3V8AMF4aYBQvwYXtcRsznSAouk5T2JiZtDQZqZYc IHvbTPsM5Ein4WqwbPyNYlGWX5VexpaHUrboDI+mSYMEmSY5B2/8SR6LXGbZhnhq SwcaBYsemQufEsuxCKES+qd7WDg5V3n3Pc+zYpBTJexdYyIOlC90zbMxfqwqCWqc D/TejrkAHaGcFzWVyahjlKDoUoQ0ba+D3mteTowVlArjBz8DOI6PUCuEXK3YsUbZ q/gMyDoaPV2fKmdTavIGoprWA2g1Dy/VKMJmRZ3FEuvIFEpgmCtXcg+DeZQVlueC GWI2Xxa4YK9ogOrdt91MnzEHsOrwqQxjw4ciMXQ2BAFGt+IM65p3niMZ8Yx1JJLu pAobFcG04z/Zgo/qaRfA6tPU8fzCfCxVsY2E7sHH2IiVgDfSwjNcdtW5/Y3fFg5p kK+ScyZUFtyseIkEHAQQAQoABgUCUxShrAAKCRCwC5zILXrfLH0dH/9SN4MNSE26 t/nd03e5ctXVjRbFaEB1v4XHaAK3mM6j8DdvNtcs6g8eF01PxcghqMOvwgrrHoq3 W90I6bnC1Dhr+WSkCCHuo0ss/t49ZLZmI259xMfI3ZNSqePvAA8CmognEeSUhfQj InYpn11h7I6ccFxQ3x5jvkvkye/YiAShAXqfhcflKxqIuVgpEbbeMU7RLEHnvFfi zKyq2+Z6O/j7qkQbkFL7EOFENirgT2K9Bv6p1QE1ztaoUMjFzvAeHUF2dbj5kECG +Nq598vhQIxCJu8q+TUrVj/uD20Et+qMbXBnQ01oi/Pc1eXO93j4fMrK/MjLawUV 2qdM2TcsNjpiNnEws+NmxGAkVfBmmep1GMNOz/x2rMBhk8xmJ6NX11AwAzCKDcNx nIjE8zkqX/k6ecbsQBpozBVrcjs7cpBH4BZFPw267gsy49mwv5fVHIiH4j1j6KFb TPyh1NpMXj049fYph8v2bbKiaOFj/DRghcoEg5h6d3GSVk5hM0BuEwczJtS+9+wq 2nBuCI50fhPlnCPBHyO0QjpaU5UGGFGANWOhPT3eNhMYsSRq99G5DAMvjxA8wJJ4 881crSaSdcXiSTvZv2TWExnMWQwuy4Gh0b2pg9c32Ps7w0c6qXIC/l0AHQ0TCtov EuwvaSErM/p/EnTFTXnBKhpVOPZnZPm3Feu73dt2x9iJ4M/SNFdIgt80YYHubFS+ yk7ShatDZOWtfM3XwRW+6ubysJQaZdKfb6WAmyugs9E5VgDqzOdh1fRCFsrWrWPj cpY8NdFf4zy0clvVOgUbgNLzA12PumlJVBhRe5MEJH5xi8L+k2jmVxGN/asE1a2M Cf7VS/0a8U5gk5b0I2+LRLMjRdoFfaqZheI9juxEUooVt+RFdrEKbx7CYbjm8HCw +wYEjM4zTNxo6+L1dCbAc5x/Q1um0vMhTHbtdNRcxIIH92PhD/9LEhnZ4Htf9Lce VRTMzIYLPLwK3/ResymnuQ1Q8GSf/pfLzcuAKurd3lsJejNR+c5yElk/XyHRlozA HD2RDxzpQ28ifW4CJcsPf3E2FZ3Cf2+TLVR2KATII7gZokYuM8UhxrUmIX+PKL4q CVmea8ljc5R+gD1NH/asCys3+XiANj7BxGrdAWkURrdW18H/lYCx0QaaKibxj07b M6Kda1iv+e7WNHT6c1WOAwnxKTLcRDH53mYGVAKf5wAu8QGQo+EO1UmliQnvkGts 8LTjUrvJPtE+dp7/j7kxhbJ+Fo33f76T5cmhdkrx4ERtYFZl/jWFeY7cmppJVNon GilEzNCYSAh1Xs+m/KuLeUSQQM0DZEmWoP6PcLkkeNl+la73XiRPNRa9R9LskHeo lZIQs5nZNtreuQQNBEWG8m8QEADgHLsnKPKnZ4ktkrgj/mGq/W57tWQ6NnHGsDDC 5QOwUU2c5pfFL+HMt115xI7kpOR63hWbG/aYSbmKUp+62+JVrN/FUkzcu3Q3NEOa cQCNVYhST/4QDVeS83Rj0ahMxxoIv31+NV93hEYlivpxznyBdaMX4KH9hH/aRGN/ y/qcRylfnPsajmMyYiCCmxIEP5nmcB4eioBvdGlce3YibfWoziBgEG/QQrtoIy5m 8g9AmzqRdOVVqf09tGN3vSKP1uyQ/WiRlz6NLAITjn9s9hpmNp8dmKMvlGC6RhG0 440RywoQ+oqDJsNMOIhA1gfUzfWluStTK1cHaNlS49pJxdOhymSL/GTmoWmXuj+6 VAKXBtjcR52lqh/dZj3SAklHmpoWgfLGfwclzjr0LEx9dpVwjD1VXQ8OPXIRR0ia ynWNtdLjueTqG1aHcetk782UxFG9OnI7WgtxCH/vBv5nXvDuT2qRlWB1ZVKA2w3U fExJmgcR4x4T0QRc2qVjx8Xcc8G/5DfptfNuqPvIWf8gggzRr12Rypl6RL9sYC5G B+4+eSVHiHNwRYW47G+CVtQPirDbvLAU/2vSb2MyAHXe7lFrRqzlpwdoviBzUcRh yN2wYCNrnqumUdXuE+puevrHY8wjCQvd9GEzXsrBonQPXbtB1orOVzSOK2WIT+jL AYlJqwADBg/7BU//L5pL6Kx6F4ii9ys/yyVrEhIXgKcBz6uB6amrjDufAijylEpu TsIA+4uqH4utqpjkSGeQlT0gvwiQlhABgSaO12b2W9og8JfpkXXfl0A91lC+bGmp r4KxR1m8tO2LwTvsfQRFhzEjUizc24abRAyPXCOHHHF/OPAmMSzMB7KYENjKAsSV gBcDstuUJoPgfDQehNI6kfZ5BNObqmQHY2v67PtM5ryfSsQvSP/n1cJ2NcPHUpXo erOpLU9Z0eSFV9AbVJo+Z+c2lw466n9nZ5X9Rm4m7Ll02nfecFx0KOnoWvoYNphC XTG59ZCE9ZRJMMS55tuySoL/RcQqdPSpopAuwU/s6rSWORPVeJ+uPCd1ZJ56qF1r jNEBmC7Cs0lzx46gaLacuGUtGG1bPZDadCoBQT4OjfacYAjzwfJcPORDp253w5/h OrQWZBfDZ7/qVcV8YW/WYZNRhFac0FPB51wTZewPotb7yXZ4z+ExK/RdF/xd2AeH Utb1+24cQugytWdfNt9r26MEJayINr88h//bkPqHR57XAANR4vrcTJGieVM2Fscg YyCLeq89rhZwNvybJIbQGL6dhIsfC7KU/MA4XVuJ0QRsO+aJsB6OaxyzWlsprzRo TSo3vg0sDcAwvXUgt6e8ZB1D5lTmEHhrFnXjKdVDUb1nonGkOxzriWCISQQYEQIA CQUCRYbybwIbDAAKCRC/YHCLSEJsfsycAJ9zK2nweFaTxsLD1roEtaMpSt3HyQCf W0j5FnfdS1KuAEVlVauY2kKKQxk=3D =3DRXya -----END PGP PUBLIC KEY BLOCK----- --------------060201010109060409060904-- --nqkE2hv6xdh2TdLpflMUWH6QC5eDv7JXl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlP2HLIACgkQv2Bwi0hCbH68CACfX5NaKCyeg0pZVYBKHThVR6QA gwcAn178xiVfcl38DVWDG8CdFbAdg9R5 =lK5o -----END PGP SIGNATURE----- --nqkE2hv6xdh2TdLpflMUWH6QC5eDv7JXl-- From nobody Tue Aug 26 05:42:17 2014 Return-Path: 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 75C871A6FC0 for ; Tue, 26 Aug 2014 05:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 tF7zDdFm4SWs for ; Tue, 26 Aug 2014 05:42:15 -0700 (PDT) Received: from atl4mhob03.myregisteredsite.com (atl4mhob03.myregisteredsite.com [209.17.115.41]) by ietfa.amsl.com (Postfix) with ESMTP id ECCAA1A6FBE for ; Tue, 26 Aug 2014 05:42:14 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob03.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s7QCgCGi028851 for ; Tue, 26 Aug 2014 08:42:12 -0400 Received: (qmail 32062 invoked by uid 0); 26 Aug 2014 12:42:12 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.108?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 26 Aug 2014 12:42:12 -0000 Message-ID: <53FC80A2.7040805@mti-systems.com> Date: Tue, 26 Aug 2014 08:42:10 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/EMSQqM6tuDQTGyw5JkbgII0GnwA Subject: [tcpm] 793bis: ISN generation in -04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 12:42:16 -0000 I submitted version -04 of the RFC 793bis draft: http://www.ietf.org/id/draft-eddy-rfc793bis-04.txt The main purpose of this revision was to add the RFC 6528 description on ISN generation. Since this text in 6528 uses a "SHOULD", I also added the use of a PRF in ISN generation to the checklist of TCP requirements pulled from 1122 (currently in an appendix of 793bis). The diffs are: http://www.ietf.org/rfcdiff?url2=draft-eddy-rfc793bis-04 Any comments, questions, suggestions, etc. are welcome. -- Wes Eddy MTI Systems