From mailman-bounces@core3.amsl.com Fri Feb 1 05:53:33 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5675728D80B for ; Fri, 1 Feb 2008 05:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbiO6FbS1VFs for ; Fri, 1 Feb 2008 05:52:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF0528D0BF for ; Fri, 1 Feb 2008 05:27:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: tcpm-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:04:33 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/tcpm/tcpm-archive%40megatron.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 05:54:22 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52DD28E493 for ; Fri, 1 Feb 2008 05:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXWjcmOQfuTf for ; Fri, 1 Feb 2008 05:51:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C644628D021 for ; Fri, 1 Feb 2008 05:27:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: tcpm-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:04:32 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/tcpm/tcpm-archive%40megatron.ietf.org From tcpm-bounces@ietf.org Sat Feb 2 06:46:08 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D21728C722; Sat, 2 Feb 2008 06:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.211 X-Spam-Level: X-Spam-Status: No, score=0.211 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_40=-0.185, HELO_EQ_DE=0.35] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0hO7syKO9RF; Sat, 2 Feb 2008 06:46:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411D63A6A35; Sat, 2 Feb 2008 06:46:07 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2813A6A40 for ; Sat, 2 Feb 2008 06:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vcPLF5ulxn7 for ; Sat, 2 Feb 2008 06:46:05 -0800 (PST) Received: from mail.enyo.de (mail.enyo.de [IPv6:2001:14b0:202:1::a7]) by core3.amsl.com (Postfix) with ESMTP id 242003A6A35 for ; Sat, 2 Feb 2008 06:46:03 -0800 (PST) Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1JLJeR-0001yh-Bh; Sat, 02 Feb 2008 15:47:27 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1JLJeO-0005jG-BB; Sat, 02 Feb 2008 15:47:24 +0100 From: Florian Weimer To: mahesh@cisco.com, mbashyam@ocarinatech.com Date: Sat, 02 Feb 2008 15:47:24 +0100 Message-ID: <8763x75sar.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Cc: tcpm@ietf.org Subject: [tcpm] draft-mahesh-persist-timeout-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This draft should mention the relationship to the Naphta/Netkill attacks. I believe they are quite similar, except that the zero window variant is slightly more effective because there is no self-healing effect. Do you plan to submit any IPR disclosures regarding this draft? _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 6 09:21:59 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7DEE3A6EB6; Wed, 6 Feb 2008 09:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+sNuQHVj-oz; Wed, 6 Feb 2008 09:21:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60D2A3A6D60; Wed, 6 Feb 2008 09:20:55 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 393603A6D60 for ; Wed, 6 Feb 2008 09:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbUa+HtzuIJK for ; Wed, 6 Feb 2008 09:20:53 -0800 (PST) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 5C4FC3A6C6B for ; Wed, 6 Feb 2008 09:20:53 -0800 (PST) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id m16HMOYD007847 for ; Wed, 6 Feb 2008 09:22:25 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id AF61F14DAD78 for ; Wed, 6 Feb 2008 12:22:19 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id F25AC36507A for ; Wed, 6 Feb 2008 12:21:29 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: It's Money That Matters MIME-Version: 1.0 Date: Wed, 06 Feb 2008 12:21:29 -0500 Message-Id: <20080206172129.F25AC36507A@lawyers.icir.org> Subject: [tcpm] new version (06) of early retransmit X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0450153174==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0450153174== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- We have just submitted a new version of the Early Retransmit I-D. We presented this in Chicago and the WG seemed to be in agreement to take this on as a WG item. We did not release this version as a WG version because I don't think we ever verified this decision on the list (although, I might mis-remember this because I obvious have no chair duties for this draft). We generally cleaned things up in this version. The big addition is a packet-based version of ER for implementations that want more precision and are willing to hold a little state about packet boundaries on the right side of the window. We welcome comments! allman The draft should be in the usual places soon and is already here: http://www.icir.org/mallman/papers/draft-allman-tcp-early-rexmt-06.txt --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHqeyZWyrrWs4yIs4RAtAwAJ42UTlLoR3sDHprHzAk+Y49aTWEIACeP49h gcoqfUXyeLf1MWRru9QTlO4= =Jhhc -----END PGP SIGNATURE----- --=_bOundary-- --===============0450153174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm --===============0450153174==-- From tcpm-bounces@ietf.org Wed Feb 6 09:39:44 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5227C3A6EC4; Wed, 6 Feb 2008 09:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qUKNiJjexbu; Wed, 6 Feb 2008 09:39:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB403A6EFE; Wed, 6 Feb 2008 09:39:43 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA75E3A6EFE for ; Wed, 6 Feb 2008 09:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eu7z5foCB-LL for ; Wed, 6 Feb 2008 09:39:41 -0800 (PST) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 22A5B3A6EC4 for ; Wed, 6 Feb 2008 09:39:41 -0800 (PST) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id m16HfCIV008094 for ; Wed, 6 Feb 2008 09:41:12 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 2CD7514DAF31 for ; Wed, 6 Feb 2008 12:41:07 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6977C36516E for ; Wed, 6 Feb 2008 12:40:17 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: It's Money That Matters MIME-Version: 1.0 Date: Wed, 06 Feb 2008 12:40:17 -0500 Message-Id: <20080206174017.6977C36516E@lawyers.icir.org> Subject: [tcpm] tcpsecure recommendations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0206536837==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0206536837== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- It'd be good to get some opinions on the new tcpsecure version and get it finished. The sticking point on this document is how strongly to recommend TCP stacks implement / use the three mitigations in the draft (to spoofed RSTs, SYNs and data segments). We had a discussion about this in Chicago and also on the list. Since it seemed that we were not converging because there was not WG-wide agreement on the scope of the document we asked the authors to generate an applicability statement. They did that, per a previous email from Anantha. The AS reads: The mitigations presented in this document talks about some known in-window attacks and the solutions to the same. The mitigations suggested in this draft SHOULD (RECOMMENDED) be implemented in devices where the TCP connections are most vulnerable to the attacks described in this document. Some examples of such TCP connections are the ones that tend to be long-lived where the connection end points can be determined, in cases where no auxiliary anti-spoofing protection mechanisms like TCP MD5 can be deployed. TCP secure MAY (OPTIONAL) be implemented in other cases. We can recommend each of mitigations with a MAY, SHOULD or MUST. In Chicago we winnowed the proposals to three three: (1) RST spoofing mitigation: MAY SYN spoofing mitigation: MAY data injection mitigation: MAY (2) RST spoofing mitigation: SHOULD SYN spoofing mitigation: SHOULD data injection mitigation: SHOULD (3) RST spoofing mitigation: SHOULD SYN spoofing mitigation: SHOULD data injection mitigation: MAY Nobody has advocated for other permutations of recommendations (although, clearly if people like some different combination they should advocate away!). Can folks please weigh in on their feeling about how strongly we should recommend these mitigations given the AS above? It'd be great to get this document moving and we're sort of stuck here. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHqfEBWyrrWs4yIs4RAiLPAKCLUXfeP1gpLwoiPtEwD4/Sb5RcDwCbB8yy KWS9lmOBvAzyEnjD5KfVYMI= =EaHz -----END PGP SIGNATURE----- --=_bOundary-- --===============0206536837== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm --===============0206536837==-- From tcpm-bounces@ietf.org Wed Feb 6 10:42:00 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF873A6F9E; Wed, 6 Feb 2008 10:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFg9kEkGMhlc; Wed, 6 Feb 2008 10:41:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3AB3A6DE6; Wed, 6 Feb 2008 10:41:56 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBBF13A6DE6 for ; Wed, 6 Feb 2008 10:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dduuE-SIGka for ; Wed, 6 Feb 2008 10:41:54 -0800 (PST) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 47BF53A6F3B for ; Wed, 6 Feb 2008 10:41:27 -0800 (PST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m16IgmPg004494; Wed, 6 Feb 2008 10:42:51 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 10:42:24 -0800 Received: from [172.25.34.4] ([172.25.34.4]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 10:42:24 -0800 Message-Id: <16384D1F-7536-4522-B1C9-2F9D90164537@windriver.com> From: David Borman To: mallman@icir.org In-Reply-To: <20080206174017.6977C36516E@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 6 Feb 2008 12:42:22 -0600 References: <20080206174017.6977C36516E@lawyers.icir.org> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 06 Feb 2008 18:42:24.0582 (UTC) FILETIME=[03D57660:01C868F0] Cc: tcpm@ietf.org Subject: Re: [tcpm] tcpsecure recommendations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I think the applicability statement is a great addition. I'm in favor of (3), SHOULD/SHOULD/MAY. -David Borman On Feb 6, 2008, at 11:40 AM, Mark Allman wrote: > > Folks- > > It'd be good to get some opinions on the new tcpsecure version and get > it finished. The sticking point on this document is how strongly to > recommend TCP stacks implement / use the three mitigations in the > draft > (to spoofed RSTs, SYNs and data segments). We had a discussion about > this in Chicago and also on the list. Since it seemed that we were > not > converging because there was not WG-wide agreement on the scope of the > document we asked the authors to generate an applicability statement. > They did that, per a previous email from Anantha. The AS reads: > > The mitigations presented in this document talks about some known > in-window attacks and the solutions to the same. The mitigations > suggested in this draft SHOULD (RECOMMENDED) be implemented in > devices where the TCP connections are most vulnerable to the > attacks > described in this document. Some examples of such TCP connections > are the ones that tend to be long-lived where the connection end > points can be determined, in cases where no auxiliary anti-spoofing > protection mechanisms like TCP MD5 can be deployed. TCP secure MAY > (OPTIONAL) be implemented in other cases. > > We can recommend each of mitigations with a MAY, SHOULD or MUST. In > Chicago we winnowed the proposals to three three: > > (1) RST spoofing mitigation: MAY > SYN spoofing mitigation: MAY > data injection mitigation: MAY > > (2) RST spoofing mitigation: SHOULD > SYN spoofing mitigation: SHOULD > data injection mitigation: SHOULD > > (3) RST spoofing mitigation: SHOULD > SYN spoofing mitigation: SHOULD > data injection mitigation: MAY > > Nobody has advocated for other permutations of recommendations > (although, clearly if people like some different combination they > should > advocate away!). > > Can folks please weigh in on their feeling about how strongly we > should > recommend these mitigations given the AS above? It'd be great to get > this document moving and we're sort of stuck here. > > Thanks, > allman > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > http://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Feb 6 10:49:13 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9132A3A701B; Wed, 6 Feb 2008 10:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k8-MHifqeYi; Wed, 6 Feb 2008 10:49:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BA83A703D; Wed, 6 Feb 2008 10:49:11 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8A93A6CB0 for ; Wed, 6 Feb 2008 10:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deyLSuyJ1NUX for ; Wed, 6 Feb 2008 10:49:09 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id F2FB93A6F21 for ; Wed, 6 Feb 2008 10:49:08 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 06 Feb 2008 10:50:37 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m16IobmY010644; Wed, 6 Feb 2008 10:50:37 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m16IobOK012615; Wed, 6 Feb 2008 18:50:37 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 10:50:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 10:50:22 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5804A741C1@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <16384D1F-7536-4522-B1C9-2F9D90164537@windriver.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure recommendations Thread-Index: Acho8DfW20dGSvStSQ20qOKQ6dopJQAAB7Nw References: <20080206174017.6977C36516E@lawyers.icir.org> <16384D1F-7536-4522-B1C9-2F9D90164537@windriver.com> From: "Anantha Ramaiah (ananth)" To: "David Borman" , X-OriginalArrivalTime: 06 Feb 2008 18:50:37.0470 (UTC) FILETIME=[299E33E0:01C868F1] Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] tcpsecure recommendations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I think it would be help if folks can also narrate the reason for chosing a particular permutation. My few cents, -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of David Borman > Sent: Wednesday, February 06, 2008 10:42 AM > To: mallman@icir.org > Cc: tcpm@ietf.org > Subject: Re: [tcpm] tcpsecure recommendations > > I think the applicability statement is a great addition. I'm > in favor of (3), SHOULD/SHOULD/MAY. > -David Borman > > On Feb 6, 2008, at 11:40 AM, Mark Allman wrote: > > > > > Folks- > > > > It'd be good to get some opinions on the new tcpsecure > version and get > > it finished. The sticking point on this document is how > strongly to > > recommend TCP stacks implement / use the three mitigations in the > > draft (to spoofed RSTs, SYNs and data segments). We had a > discussion > > about this in Chicago and also on the list. Since it > seemed that we > > were not converging because there was not WG-wide agreement on the > > scope of the document we asked the authors to generate an > > applicability statement. > > They did that, per a previous email from Anantha. The AS reads: > > > > The mitigations presented in this document talks about some known > > in-window attacks and the solutions to the same. The mitigations > > suggested in this draft SHOULD (RECOMMENDED) be implemented in > > devices where the TCP connections are most vulnerable to the > > attacks > > described in this document. Some examples of such TCP > connections > > are the ones that tend to be long-lived where the connection end > > points can be determined, in cases where no auxiliary > anti-spoofing > > protection mechanisms like TCP MD5 can be deployed. TCP > secure MAY > > (OPTIONAL) be implemented in other cases. > > > > We can recommend each of mitigations with a MAY, SHOULD or > MUST. In > > Chicago we winnowed the proposals to three three: > > > > (1) RST spoofing mitigation: MAY > > SYN spoofing mitigation: MAY > > data injection mitigation: MAY > > > > (2) RST spoofing mitigation: SHOULD > > SYN spoofing mitigation: SHOULD > > data injection mitigation: SHOULD > > > > (3) RST spoofing mitigation: SHOULD > > SYN spoofing mitigation: SHOULD > > data injection mitigation: MAY > > > > Nobody has advocated for other permutations of recommendations > > (although, clearly if people like some different combination they > > should advocate away!). > > > > Can folks please weigh in on their feeling about how strongly we > > should recommend these mitigations given the AS above? > It'd be great > > to get this document moving and we're sort of stuck here. > > > > Thanks, > > allman > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > http://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > http://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 7 07:55:11 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D363A7A2B; Thu, 7 Feb 2008 07:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfroRd9dvuKS; Thu, 7 Feb 2008 07:55:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D933A7A7D; Thu, 7 Feb 2008 07:54:41 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2E43A7974 for ; Thu, 7 Feb 2008 07:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSES3bsLzE8h for ; Thu, 7 Feb 2008 07:54:39 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E09133A7A7D for ; Thu, 7 Feb 2008 07:51:25 -0800 (PST) Received: from [127.0.0.1] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m17FqbgI006663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Feb 2008 07:52:39 -0800 (PST) Message-ID: <47AB293D.8040605@isi.edu> Date: Thu, 07 Feb 2008 07:52:29 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mallman@icir.org References: <20080206174017.6977C36516E@lawyers.icir.org> In-Reply-To: <20080206174017.6977C36516E@lawyers.icir.org> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] tcpsecure recommendations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Given the AS's statement below: | ... TCP secure MAY | (OPTIONAL) be implemented in other cases. | | We can recommend each of mitigations with a MAY, SHOULD or MUST. In | Chicago we winnowed the proposals to three three: #3 makes most sense tm oe. #1 weakens the AS statement too much, and #2 covers data plane protection that there are too many other ways to spoof (overwriting segments, or just writing segments with predicted header data). This appears to be best applied to an unauthenticated control plane. Joe | (1) RST spoofing mitigation: MAY | SYN spoofing mitigation: MAY | data injection mitigation: MAY | | (2) RST spoofing mitigation: SHOULD | SYN spoofing mitigation: SHOULD | data injection mitigation: SHOULD | | (3) RST spoofing mitigation: SHOULD | SYN spoofing mitigation: SHOULD | data injection mitigation: MAY | | Nobody has advocated for other permutations of recommendations | (although, clearly if people like some different combination they should | advocate away!). | | Can folks please weigh in on their feeling about how strongly we should | recommend these mitigations given the AS above? It'd be great to get | this document moving and we're sort of stuck here. | | Thanks, | allman | | | | | | ------------------------------------------------------------------------ | | _______________________________________________ | tcpm mailing list | tcpm@ietf.org | http://www.ietf.org/mailman/listinfo/tcpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHqyk9E5f5cImnZrsRAsi5AJ942eMHdpBGM7b1sU1N/YZKlfeSUwCgk9II 5mp3ZMUODozwLLajVqB+w3g= =qo2i -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Feb 10 09:38:00 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF3B3A6851; Sun, 10 Feb 2008 09:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m01eFGlDiv3h; Sun, 10 Feb 2008 09:38:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 162C93A680F; Sun, 10 Feb 2008 09:38:00 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511FF3A67EB for ; Sun, 10 Feb 2008 09:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bux8aklS+0Xc for ; Sun, 10 Feb 2008 09:37:57 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9013C3A67E1 for ; Sun, 10 Feb 2008 09:37:57 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 09 Feb 2008 20:08:29 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1A48SCa004646; Sat, 9 Feb 2008 20:08:28 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1A48G6K007116; Sun, 10 Feb 2008 04:08:16 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Feb 2008 20:08:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 9 Feb 2008 20:08:01 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5804AC099C@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <47AB293D.8040605@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure recommendations Thread-Index: AchpokGE8ULHoPv2RPScQii2uMhmqgB9YOsg References: <20080206174017.6977C36516E@lawyers.icir.org> <47AB293D.8040605@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , X-OriginalArrivalTime: 10 Feb 2008 04:08:16.0121 (UTC) FILETIME=[8FC46E90:01C86B9A] Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] tcpsecure recommendations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > > #3 makes most sense tm oe. #1 weakens the AS statement too > much, and > #2 covers data plane protection that there are too > many other ways to spoof (overwriting segments, or just > writing segments with predicted header data). This appears to > be best applied to an unauthenticated control plane. I am assuming you are characterizing the reception of certain segments like SYN/RST/FIN as control plane and pure data as otherwise?. Pl note that tcp-secure mainly talks about injecting a bad segment which eventually results in tearing down an established TCP connection. In other words, I can't understand your reasoning for not going with #2. What do you think are the issues going with #2 ? Can you elaborate? -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Feb 10 09:44:58 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0443A6835; Sun, 10 Feb 2008 09:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8En17IpL3CXd; Sun, 10 Feb 2008 09:44:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937FA3A6800; Sun, 10 Feb 2008 09:44:57 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A043A6800 for ; Sun, 10 Feb 2008 09:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds9Hdw4Mx-G2 for ; Sun, 10 Feb 2008 09:44:55 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 031503A67AC for ; Sun, 10 Feb 2008 09:44:54 -0800 (PST) Received: from [127.0.0.1] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m1AHisdA021407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 10 Feb 2008 09:44:55 -0800 (PST) Message-ID: <47AF380D.7030400@isi.edu> Date: Sun, 10 Feb 2008 09:44:45 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <20080206174017.6977C36516E@lawyers.icir.org> <47AB293D.8040605@isi.edu> <0C53DCFB700D144284A584F54711EC5804AC099C@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5804AC099C@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] tcpsecure recommendations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anantha Ramaiah (ananth) wrote: |> #3 makes most sense tm oe. #1 weakens the AS statement too |> much, and |> #2 covers data plane protection that there are too |> many other ways to spoof (overwriting segments, or just |> writing segments with predicted header data). This appears to |> be best applied to an unauthenticated control plane. | | I am assuming you are characterizing the reception of certain segments | like SYN/RST/FIN as control plane and pure data as otherwise?. Pl note | that tcp-secure mainly talks about injecting a bad segment which | eventually results in tearing down an established TCP connection. In | other words, I can't understand your reasoning for not going with #2. | What do you think are the issues going with #2 ? | | Can you elaborate? The key issues are: - - lack of protection against injected data itself (I'm not sure if the doc actually calls this out specifically; it probably should in the security considerations section - even an off-path attacker can do this, e.g.) - - the word "eventually" above IMO, if you are running a TCP connection that is susceptible to attacks only by a *stream* of forged segments, you probably ought to use something besides TCP-secure as protection. As a result, I think that you SHOULD protect the control plane (if you employ this technique), but that protection of attacks via data plane volume are not as critical, and thus a MAY. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHrzgME5f5cImnZrsRAtCoAKDsgOcVgbwKLrpmX68pnFXsrquajACfSox0 w/8ntF+s4KpzglNa3Gm3xzo= =f7AS -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Feb 10 11:37:07 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7933A68D5; Sun, 10 Feb 2008 11:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAIqVOhNpfjf; Sun, 10 Feb 2008 11:37:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B5E3A68E5; Sun, 10 Feb 2008 11:37:05 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BDB63A68E4 for ; Sun, 10 Feb 2008 11:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0psfswiC7Cqd for ; Sun, 10 Feb 2008 11:37:04 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DED143A68E9 for ; Sun, 10 Feb 2008 11:36:42 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 10 Feb 2008 11:38:09 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1AJc9jF013861; Sun, 10 Feb 2008 11:38:09 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1AJb46B015707; Sun, 10 Feb 2008 19:38:09 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Feb 2008 11:38:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 10 Feb 2008 11:37:53 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5804AC09CF@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <47AF380D.7030400@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure recommendations Thread-Index: AchsDNkM6Sw0keyTQ0GYzmSJxnLOnQACSU/A References: <20080206174017.6977C36516E@lawyers.icir.org> <47AB293D.8040605@isi.edu> <0C53DCFB700D144284A584F54711EC5804AC099C@xmb-sjc-21c.amer.cisco.com> <47AF380D.7030400@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 10 Feb 2008 19:38:08.0565 (UTC) FILETIME=[76A7C650:01C86C1C] Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] tcpsecure recommendations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > > The key issues are: > > - - lack of protection against injected data itself (I'm not > sure if the doc actually calls this out specifically; it > probably should in the security considerations section - even > an off-path attacker can do this, > e.g.) There are references to IPsec and MD5 etc., in the security section. I think all the above is implied and understood. Like it has been emphasised before many times, the purpose of TCP secure is to add robustness to some cases and not to replace IPsec/MD5. > > - - the word "eventually" above > > IMO, if you are running a TCP connection that is susceptible > to attacks only by a *stream* of forged segments, you > probably ought to use something besides TCP-secure as protection. Actaully it is not a "stream" of forged segments. A malicious segment (which utilizes the liberal range of ACK value) can come and occupy any place within the receive window, it could be in the re-assembly queue/or somewhere inline, but this just like a "time-bomb' waiting to explode. [The document mentions these possibilities under the data injection section] Also as mentioned in the document FIN attacks are also possible which is a control plane thingy ( using your terminology) > > As a result, I think that you SHOULD protect the control > plane (if you employ this technique), but that protection of > attacks via data plane volume are not as critical, and thus a MAY. Data injection is about strict ACK checking and applies to FIN segments. To re-iterate: preventing anything which causes the connection tear down maliciously is critical. So it could be a RST/SYN or Data or FIN. But if your point is the mitigation should not be called as "data injection" and something else, I agree. OTOH, the assumption is that any implementer (true for any RFC) is going to read and understand that tcp-secure provides adds robustness in some cases and for a comprehensive data/control protection one is going to use MD5/Ipsec. Like I pointed out earlier many times tcp-secure is not an authentication mechanism and lot of folks agree to that, but you seem to thinking this as an authentication mechanism and with that line of thinking, your reasoning is fine, but the basic point is tcp-secure is NOT a authentication mechanism, it is about protocol robustness :-) -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Feb 10 14:57:59 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFBFD3A695E; Sun, 10 Feb 2008 14:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYJFN6JPw5Rc; Sun, 10 Feb 2008 14:57:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0DC3A6890; Sun, 10 Feb 2008 14:57:58 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDD0B3A68D5 for ; Sun, 10 Feb 2008 14:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ig3K74hnph2 for ; Sun, 10 Feb 2008 14:57:56 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id EBC0C3A686B for ; Sun, 10 Feb 2008 14:57:55 -0800 (PST) Received: from [127.0.0.1] (c3-vpn1.isi.edu [128.9.176.72] (may be forged)) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m1AMx7gA011731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 10 Feb 2008 14:59:08 -0800 (PST) Message-ID: <47AF81B2.5030408@isi.edu> Date: Sun, 10 Feb 2008 14:58:58 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <20080206174017.6977C36516E@lawyers.icir.org> <47AB293D.8040605@isi.edu> <0C53DCFB700D144284A584F54711EC5804AC099C@xmb-sjc-21c.amer.cisco.com> <47AF380D.7030400@isi.edu> <0C53DCFB700D144284A584F54711EC5804AC09CF@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5804AC09CF@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] tcpsecure recommendations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anantha Ramaiah (ananth) wrote: ... | Actaully it is not a "stream" of forged segments. A malicious segment | (which utilizes the liberal range of ACK value) can come and occupy any | place within the receive window, it could be in the re-assembly queue/or | somewhere inline, but this just like a "time-bomb' waiting to explode. There are three issues listed in the ID: "Blind reset attack using the RST bit" "Blind reset attack using the SYN bit" "Blind data injection attack" The third one says "data corruption may result" - IMO, data corruption is a possibility any time you don't use strict authentication, so it's inaccurate to imply that if these checks are in place that data corruption won't occur (which is what is implied, IMO). The ACK war doesn't take down the connection. What takes down the connection is that it accepted data it shouldn't have. IMO, the UTO taking the connection down at this point is not as much an attack succeeding, as it is TCP succeeding in not letting the attack go unnoticed. Again, I don't see this case as needing a SHOULD. This is a data plane issue, not, IMO, a control plane one. ... | Data injection is about strict ACK checking and applies to FIN segments. | To re-iterate: preventing anything which causes the connection tear down | maliciously is critical. So it could be a RST/SYN or Data or FIN. If preventing anything that could cause a malicious teardown is critical, then use of strict authentication is required. Implications to the contrary endorse the use of this "protocol robustness" mechanism for true security (a misconception that the title doesn't help abate). - --- Also, FWIW, Section 9 doesn't appear to address the non-amplification ACK exchange issue promised in the end of each of the previous sections. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHr4GyE5f5cImnZrsRAjCgAJ0eVV71WUdJbgsi3qP/+CCgsNgD0gCeOr4t cDj47pw0ErxCpgVci+i1dWM= =bokx -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Feb 10 15:24:50 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482143A69B1; Sun, 10 Feb 2008 15:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozqo-PsBbgzD; Sun, 10 Feb 2008 15:24:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932E33A695D; Sun, 10 Feb 2008 15:24:48 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57CB53A68A8 for ; Sun, 10 Feb 2008 15:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFUCcL+EZ6RG for ; Sun, 10 Feb 2008 15:24:46 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 696823A6923 for ; Sun, 10 Feb 2008 15:24:25 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 10 Feb 2008 15:25:52 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1ANPqKK010524; Sun, 10 Feb 2008 15:25:52 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1ANPp6K002524; Sun, 10 Feb 2008 23:25:51 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Feb 2008 15:25:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 10 Feb 2008 15:25:36 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5804AC09E9@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <47AF81B2.5030408@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure recommendations Thread-Index: AchsOJnosIYR5+V6T96F7i2HTYU/4wAAN3CQ References: <20080206174017.6977C36516E@lawyers.icir.org><47AB293D.8040605@isi.edu><0C53DCFB700D144284A584F54711EC5804AC099C@xmb-sjc-21c.amer.cisco.com><47AF380D.7030400@isi.edu><0C53DCFB700D144284A584F54711EC5804AC09CF@xmb-sjc-21c.amer.cisco.com> <47AF81B2.5030408@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 10 Feb 2008 23:25:51.0534 (UTC) FILETIME=[466B64E0:01C86C3C] Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] tcpsecure recommendations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > There are three issues listed in the ID: > > "Blind reset attack using the RST bit" > "Blind reset attack using the SYN bit" > "Blind data injection attack" > > The third one says "data corruption may result" - IMO, data > corruption is a possibility any time you don't use strict > authentication, so it's inaccurate to imply that if these > checks are in place that data corruption won't occur (which > is what is implied, IMO). "data corruption may result" because it is not the data what the application intended to receive in the first place. Keeping the focus intact, the liberal ACK allowed by the RFC has led to this condition which otherwise would have been prevented. So data corruption can happen in various places and various layers, we are simply talking about plugging one hole which is in the jurisdiction of TCP. > > The ACK war doesn't take down the connection. What takes down > the connection is that it accepted data it shouldn't have. > IMO, the UTO taking the connection down at this point is not > as much an attack succeeding, as it is TCP succeeding in not > letting the attack go unnoticed. Agree that the connection might get torn down due to UTO/application timeout, but why did this happen due to the liberal ACK range allowed. Now this is what is being debated and the mitigation suggested. > > Again, I don't see this case as needing a SHOULD. This is a > data plane issue, not, IMO, a control plane one. Data plane versus control plane, the distinction becomes blurry when FIN comes into picture... Not sure how the data/control plane distinction is made and why it is needed for determining the strength of the mitigation. You haven't made this clear so far. > > ... > | Data injection is about strict ACK checking and applies to > FIN segments. > | To re-iterate: preventing anything which causes the connection tear > | down maliciously is critical. So it could be a RST/SYN or > Data or FIN. > > If preventing anything that could cause a malicious teardown > is critical, then use of strict authentication is required. > Implications to the contrary endorse the use of this > "protocol robustness" mechanism for true security (a > misconception that the title doesn't help abate). Agreed but again the above statement doesn't help in debate which we are having, ie., the strength of the data mitigation. All so far I can gather is that : somehow you are saying data mitigation is tied to "data plane" and the rest are tied to control plane and hence in one case is a SHOULD and the other a MAY. Sounds very dubious to me. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Feb 10 17:13:41 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF813A69BB; Sun, 10 Feb 2008 17:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.634 X-Spam-Level: X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZREl+wZMF7ja; Sun, 10 Feb 2008 17:13:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482D53A69AF; Sun, 10 Feb 2008 17:13:40 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BE0A3A69AE for ; Sun, 10 Feb 2008 17:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrarHw8IEg1T for ; Sun, 10 Feb 2008 17:13:37 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 8C43A3A69AD for ; Sun, 10 Feb 2008 17:13:37 -0800 (PST) Received: from [127.0.0.1] (c2-vpn04.isi.edu [128.9.176.213]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m1B1EChd009394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 10 Feb 2008 17:14:13 -0800 (PST) Message-ID: <47AFA15A.1070006@isi.edu> Date: Sun, 10 Feb 2008 17:14:02 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <20080206174017.6977C36516E@lawyers.icir.org><47AB293D.8040605@isi.edu><0C53DCFB700D144284A584F54711EC5804AC099C@xmb-sjc-21c.amer.cisco.com><47AF380D.7030400@isi.edu><0C53DCFB700D144284A584F54711EC5804AC09CF@xmb-sjc-21c.amer.cisco.com> <47AF81B2.5030408@isi.edu> <0C53DCFB700D144284A584F54711EC5804AC09E9@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5804AC09E9@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] tcpsecure recommendations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anantha Ramaiah (ananth) wrote: ... |> If preventing anything that could cause a malicious teardown |> is critical, then use of strict authentication is required. |> Implications to the contrary endorse the use of this |> "protocol robustness" mechanism for true security (a |> misconception that the title doesn't help abate). | | Agreed but again the above statement doesn't help in debate which we are | having, ie., the strength of the data mitigation. All so far I can | gather is that : somehow you are saying data mitigation is tied to "data | plane" and the rest are tied to control plane and hence in one case is a | SHOULD and the other a MAY. Sounds very dubious to me. My comments are not intended to convince you to agree with me. I have made my decision, and explained it, IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHr6FaE5f5cImnZrsRAhB0AJ43csP3MJQrccSJcNkV6zioSt6CYgCdHr2Y Aho6pzAr2Zjc02rAkn78fj0= =PoJC -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Feb 10 18:22:54 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BB903A69CF; Sun, 10 Feb 2008 18:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=-2.113, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-hSI+eJkSHZ; Sun, 10 Feb 2008 18:22:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7E523A69AB; Sun, 10 Feb 2008 18:22:53 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1853A69AB for ; Sun, 10 Feb 2008 18:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FShV1JSx0iEQ for ; Sun, 10 Feb 2008 18:22:51 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DD5193A6982 for ; Sun, 10 Feb 2008 18:22:51 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 10 Feb 2008 18:24:18 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1B2OI4n009342; Sun, 10 Feb 2008 18:24:18 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1B2OHEL015033; Mon, 11 Feb 2008 02:24:18 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Feb 2008 18:24:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 10 Feb 2008 18:24:00 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5804AC0A08@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <47AFA15A.1070006@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure recommendations Thread-Index: AchsS4pLLrBiLUvRQcmT51MBJe7V3wAAKcNQ References: <20080206174017.6977C36516E@lawyers.icir.org><47AB293D.8040605@isi.edu><0C53DCFB700D144284A584F54711EC5804AC099C@xmb-sjc-21c.amer.cisco.com><47AF380D.7030400@isi.edu><0C53DCFB700D144284A584F54711EC5804AC09CF@xmb-sjc-21c.amer.cisco.com> <47AF81B2.5030408@isi.edu> <0C53DCFB700D144284A584F54711EC5804AC09E9@xmb-sjc-21c.amer.cisco.com> <47AFA15A.1070006@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 11 Feb 2008 02:24:16.0257 (UTC) FILETIME=[32EE7F10:01C86C55] Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] tcpsecure recommendations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > Anantha Ramaiah (ananth) wrote: > ... > |> If preventing anything that could cause a malicious teardown is > |> critical, then use of strict authentication is required. > |> Implications to the contrary endorse the use of this "protocol > |> robustness" mechanism for true security (a misconception that the > |> title doesn't help abate). > | > | Agreed but again the above statement doesn't help in debate > which we > | are having, ie., the strength of the data mitigation. All > so far I can > | gather is that : somehow you are saying data mitigation is tied to > | "data plane" and the rest are tied to control plane and > hence in one > | case is a SHOULD and the other a MAY. Sounds very dubious to me. > > My comments are not intended to convince you to agree with > me. I have made my decision, and explained it, IMO. Well, I was seeking clarification on the reasoning which you gave for your choice! IMO, esp. after the AS is in place, it doesn't make sense to color each individual mitigation differently. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Feb 10 19:54:22 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C973A69FC; Sun, 10 Feb 2008 19:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[AWL=-0.985, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7WfILF-qvbs; Sun, 10 Feb 2008 19:54:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0BE3A68EB; Sun, 10 Feb 2008 19:54:21 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1146C3A68EB for ; Sun, 10 Feb 2008 19:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnH0+SIiKNcH for ; Sun, 10 Feb 2008 19:54:19 -0800 (PST) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 197633A698D for ; Sun, 10 Feb 2008 19:54:19 -0800 (PST) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id m1B3tjRV016252; Sun, 10 Feb 2008 19:55:45 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 0F29814FD881; Sun, 10 Feb 2008 22:55:40 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7551C36A3CC; Sun, 10 Feb 2008 22:54:41 -0500 (EST) To: "Anantha Ramaiah (ananth)" , "Joe Touch" , tcpm@ietf.org From: Mark Allman In-Reply-To: <0C53DCFB700D144284A584F54711EC5804AC0A08@xmb-sjc-21c.amer.cisco.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: It's Money That Matters MIME-Version: 1.0 Date: Sun, 10 Feb 2008 22:54:41 -0500 Message-Id: <20080211035441.7551C36A3CC@lawyers.icir.org> Subject: Re: [tcpm] tcpsecure recommendations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1561016644==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1561016644== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- We do not need more unending debate on this subject. We need to make a collective decision about how strongly to recommend these mitigations. I want to encourage folks to please poke their head up and voice their opinion on this question (my original request is below for reference). And, I would also like to ask folks to hold off on re-debating the issues again. Certainly, if you feel you have a *new* opinion to offer or the AS has brought something *new and different* to the fore of your thinking, by all means please raise the issue. Thanks, allman Folks- It'd be good to get some opinions on the new tcpsecure version and get it finished. The sticking point on this document is how strongly to recommend TCP stacks implement / use the three mitigations in the draft (to spoofed RSTs, SYNs and data segments). We had a discussion about this in Chicago and also on the list. Since it seemed that we were not converging because there was not WG-wide agreement on the scope of the document we asked the authors to generate an applicability statement. They did that, per a previous email from Anantha. The AS reads: The mitigations presented in this document talks about some known in-window attacks and the solutions to the same. The mitigations suggested in this draft SHOULD (RECOMMENDED) be implemented in devices where the TCP connections are most vulnerable to the attacks described in this document. Some examples of such TCP connections are the ones that tend to be long-lived where the connection end points can be determined, in cases where no auxiliary anti-spoofing protection mechanisms like TCP MD5 can be deployed. TCP secure MAY (OPTIONAL) be implemented in other cases. We can recommend each of mitigations with a MAY, SHOULD or MUST. In Chicago we winnowed the proposals to three three: (1) RST spoofing mitigation: MAY SYN spoofing mitigation: MAY data injection mitigation: MAY (2) RST spoofing mitigation: SHOULD SYN spoofing mitigation: SHOULD data injection mitigation: SHOULD (3) RST spoofing mitigation: SHOULD SYN spoofing mitigation: SHOULD data injection mitigation: MAY Nobody has advocated for other permutations of recommendations (although, clearly if people like some different combination they should advocate away!). Can folks please weigh in on their feeling about how strongly we should recommend these mitigations given the AS above? It'd be great to get this document moving and we're sort of stuck here. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHr8cBWyrrWs4yIs4RAtUNAKCYC1JbynC6naTBYLm2GAoEt7hXqgCgnIlJ QgBYQDxufm9yS2OE+5BoU+U= =HHXY -----END PGP SIGNATURE----- --=_bOundary-- --===============1561016644== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm --===============1561016644==-- From tcpm-bounces@ietf.org Mon Feb 11 17:44:30 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80DD428CB7F; Mon, 11 Feb 2008 17:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.766 X-Spam-Level: X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8n7oTeTj8rX; Mon, 11 Feb 2008 17:44:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 837E93A6DF2; Mon, 11 Feb 2008 17:44:29 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB013A6D3A for ; Mon, 11 Feb 2008 17:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a05m9X45euA7 for ; Mon, 11 Feb 2008 17:44:27 -0800 (PST) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.83]) by core3.amsl.com (Postfix) with ESMTP id 98F653A6CB4 for ; Mon, 11 Feb 2008 17:44:27 -0800 (PST) Received: from mac.com (asmtp007-s [10.150.69.70]) by smtpoutm.mac.com (Xserve/smtpout020/MantshX 4.0) with ESMTP id m1C1jlFQ016589; Mon, 11 Feb 2008 17:45:47 -0800 (PST) Received: from [192.168.1.101] (adsl-70-132-3-110.dsl.snfc21.sbcglobal.net [70.132.3.110]) (authenticated bits=0) by mac.com (Xserve/asmtp007/MantshX 4.0) with ESMTP id m1C1jjKx017594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Feb 2008 17:45:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <44B5A0DB-E692-4C07-AD35-D46A6FBEB860@mac.com> From: Sally Floyd Date: Mon, 11 Feb 2008 17:45:43 -0800 To: Ted Faber , Mark Allman X-Mailer: Apple Mail (2.753) Cc: Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , tcpm , Amit Mondal Subject: [tcpm] draft-ietf-tcpm-ecnsyn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org The revised version of draft-ietf-tcpm-ecnsyn-04 was submitted on January 8, and from the authors' perspective, this is ready for Working Group Last Call. It is available from: "http://tools.ietf.org/html/draft-ietf-tcpm-ecnsyn-04". The changes from the previous draft are as follows: Changes from draft-ietf-tcpm-ecnsyn-03: * General editing. This includes using the terms "initiator" and "responder" for the two ends of the TCP connection. Feedback from Alfred Hoenes. * Added some text to the backwards compatibility discussion, now in Appendix B, about the pros and cons of using a TCP flag for the TCP initiator to signal that it understands ECN-Capable SYN/ACK packets. The consensus at this time is not to use such a flag. Also added a recommendation that TCP implementations include a management interface to turn off the use of ECN for SYN/ACK packets. From email from Bob Briscoe. The second issue (of backwards compatibility with TCP clients that understand ECN, but that don't understand ECN-Capable SYN/ACK packets) was discussed at the December IETF, and on the mailing list since then, under the subject heading "[tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility" As far as the authors are concerned, this has been ready for Working Group Last Call since it was submitted in January... Many thanks, - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Feb 11 18:59:49 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402693A6DE4; Mon, 11 Feb 2008 18:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMAG+s71-Rss; Mon, 11 Feb 2008 18:59:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BC9B3A687E; Mon, 11 Feb 2008 18:59:48 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD0D3A6C3F for ; Mon, 11 Feb 2008 18:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUJbbKlTVQDc for ; Mon, 11 Feb 2008 18:59:46 -0800 (PST) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.73]) by core3.amsl.com (Postfix) with ESMTP id 6B5373A68C9 for ; Mon, 11 Feb 2008 18:59:01 -0800 (PST) Received: from mac.com (asmtp002-s [10.150.69.65]) by smtpoutm.mac.com (Xserve/smtpout010/MantshX 4.0) with ESMTP id m1C30LAG025764; Mon, 11 Feb 2008 19:00:21 -0800 (PST) Received: from [192.168.1.101] (adsl-70-132-3-110.dsl.snfc21.sbcglobal.net [70.132.3.110]) (authenticated bits=0) by mac.com (Xserve/asmtp002/MantshX 4.0) with ESMTP id m1C30CEQ015313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Feb 2008 19:00:14 -0800 (PST) In-Reply-To: <44B5A0DB-E692-4C07-AD35-D46A6FBEB860@mac.com> References: <44B5A0DB-E692-4C07-AD35-D46A6FBEB860@mac.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Sally Floyd Date: Mon, 11 Feb 2008 19:00:08 -0800 To: Ted Faber , Mark Allman X-Mailer: Apple Mail (2.753) Cc: Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , tcpm , Amit Mondal Subject: Re: [tcpm] draft-ietf-tcpm-ecnsyn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > The revised version of draft-ietf-tcpm-ecnsyn-04 was submitted on > January 8, and from the authors' perspective, this is ready for > Working > Group Last Call. Sorry, I should have said that the document went through Working Group Last Call in December, and the revision draft-ietf-tcpm-ecnsyn-04 was to address issues raised in WGLC. So the question is whether this is ready to move on the next stage... Apologies, - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Feb 11 20:01:19 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E65B3A67FC; Mon, 11 Feb 2008 20:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7gVTrbd9Owu; Mon, 11 Feb 2008 20:01:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC793A68A2; Mon, 11 Feb 2008 20:01:18 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 212D93A67FC for ; Mon, 11 Feb 2008 20:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAIk-WTljBjV for ; Mon, 11 Feb 2008 20:01:16 -0800 (PST) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 6EAE33A68A2 for ; Mon, 11 Feb 2008 20:01:16 -0800 (PST) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id m1C42fF7005811; Mon, 11 Feb 2008 20:02:41 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id E7BD6150733E; Mon, 11 Feb 2008 23:02:35 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0C2093AEC52; Mon, 11 Feb 2008 23:01:34 -0500 (EST) To: Sally Floyd From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Wishlist MIME-Version: 1.0 Date: Mon, 11 Feb 2008 23:01:34 -0500 Message-Id: <20080212040134.0C2093AEC52@lawyers.icir.org> Cc: Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , tcpm , Ted Faber , Amit Mondal Subject: Re: [tcpm] draft-ietf-tcpm-ecnsyn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1937681178==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1937681178== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Sorry, I should have said that the document went through Working Group > Last Call in December, and the revision draft-ietf-tcpm-ecnsyn-04 was > to address issues raised in WGLC. So the question is whether this is > ready to move on the next stage... Sally- I thought I had sent a note to the list announcing that we believe there to be consensus on this document and that it passed WGLC. However, it seems as though I did not. My apologies. I need to write a PROTO statement for this document and I have been tardy on this. I was supposed to do it last week, but it slipped the queue. I will try to get to it soon. Thanks! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHsRoeWyrrWs4yIs4RAgH3AJ0aA7jjq6g/HOCIhZA8DYf4PHjdJQCghnrp HieK8/Yx++WXbiAIEWyW9Ok= =AllR -----END PGP SIGNATURE----- --=_bOundary-- --===============1937681178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm --===============1937681178==-- From tcpm-bounces@ietf.org Wed Feb 13 11:29:23 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5B328C838; Wed, 13 Feb 2008 11:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNB9x5jlSG61; Wed, 13 Feb 2008 11:29:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3385B28C83E; Wed, 13 Feb 2008 11:29:21 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F233A6839 for ; Wed, 13 Feb 2008 11:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ju+0mAeINQT for ; Wed, 13 Feb 2008 11:29:19 -0800 (PST) Received: from widefw.csl.sony.co.jp (widefw.csl.sony.co.jp [133.138.1.1]) by core3.amsl.com (Postfix) with ESMTP id 089B228C24B for ; Wed, 13 Feb 2008 11:29:13 -0800 (PST) Received: from localhost (dhcp204.csl.sony.co.jp [133.138.1.204]) by widefw.csl.sony.co.jp (Postfix) with ESMTP id 6E4E65643A; Thu, 14 Feb 2008 04:30:36 +0900 (JST) Date: Thu, 14 Feb 2008 04:36:00 +0900 (JST) Message-Id: <20080214.043600.06791461.nishida@csl.sony.co.jp> To: tcpm@ietf.org, end2end-interest@postel.org From: Yoshifumi Nishida In-Reply-To: <20080212040134.0C2093AEC52@lawyers.icir.org> References: <20080212040134.0C2093AEC52@lawyers.icir.org> X-Mailer: Mew version 4.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Subject: [tcpm] tcpillust release announcement X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hello, Sorry for disturbing, but I hope it would be usefull for some people. A new stable version of tcpillust: a graphical TCP connection analysis tool is available at: http://www.jp.nishida.org/tcpillust/tcpillust-2.01.tar.gz Tcpillust takes tcpdump file(s) specified at the command line and draws pictures like figures in the ``TCP/IP Illustrated'' series. If you're interested, please check the following web site: http://www.jp.nishida.org/tcpillust/index.html You can see sample screen images of tcpillust or screen guide. If you have any problem, please let me know. Also, feedbacks, comments, suggestions and bug-reports are very welcome. Thanks, -- Yoshifumi Nishida nishida@csl.sony.co.jp _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Feb 15 14:15:16 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BEA728C5C1; Fri, 15 Feb 2008 14:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=-1.581, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2U47oZe01QIj; Fri, 15 Feb 2008 14:15:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54E928C300; Fri, 15 Feb 2008 14:15:09 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3783A68CB for ; Fri, 15 Feb 2008 14:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueGkbhlxY5a0 for ; Fri, 15 Feb 2008 14:15:07 -0800 (PST) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 7BB863A6B4C for ; Fri, 15 Feb 2008 14:15:04 -0800 (PST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m1FMGNEk026214 for ; Fri, 15 Feb 2008 14:16:23 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 14:16:23 -0800 Received: from [172.25.34.25] ([172.25.34.25]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 14:16:24 -0800 Message-Id: <25C477DF-381D-46E7-BF8F-05461B3FCC56@windriver.com> From: David Borman To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 15 Feb 2008 16:16:22 -0600 X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 15 Feb 2008 22:16:24.0343 (UTC) FILETIME=[66A54270:01C87020] Subject: [tcpm] 1323 & TCP MSS in Appendix A X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi, In Chicago we discussed moving the description of the TCP MSS option out of Appendix A and into a separate document. I don't recall coming to a decision, I think we were going to take it to the mailing list. So, here's the question: Should I take the description of the TCP MSS option out of Appendix A and put it into a separate draft, or should we just leave it in the revision for 1323? I believe the argument for moving it out into a separate document was that this is an important point the implementors continue to get wrong, so pulling it out into a separate document will bring more visibility. My personal opinion is that not that strong, I'd be fine with leaving it in 1323.bis, and also fine with moving it to its own draft document. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Feb 15 15:22:30 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CBB63A6BE8; Fri, 15 Feb 2008 15:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-1.834, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKtfQqkKLUfI; Fri, 15 Feb 2008 15:22:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82AB3A6BAB; Fri, 15 Feb 2008 15:22:29 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A813A6BAB for ; Fri, 15 Feb 2008 15:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uh8T-uwTd4VE for ; Fri, 15 Feb 2008 15:22:24 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 62FFC3A6B5E for ; Fri, 15 Feb 2008 15:22:24 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Feb 2008 00:23:44 +0100 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1FNNhsP028296; Sat, 16 Feb 2008 00:23:43 +0100 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1FNNcvn018895; Fri, 15 Feb 2008 23:23:38 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 15:23:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Feb 2008 15:23:20 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5804B70C05@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <25C477DF-381D-46E7-BF8F-05461B3FCC56@windriver.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] 1323 & TCP MSS in Appendix A Thread-Index: AchwIJjhTF6TLgc6T+m2RhCBH5zNxgAA1l0w References: <25C477DF-381D-46E7-BF8F-05461B3FCC56@windriver.com> From: "Anantha Ramaiah (ananth)" To: "David Borman" , X-OriginalArrivalTime: 15 Feb 2008 23:23:37.0326 (UTC) FILETIME=[CA7DA0E0:01C87029] Authentication-Results: ams-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [tcpm] 1323 & TCP MSS in Appendix A X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi David, I am not sure which way is better and I don't have issues either way, but I'll bite... I think having a separate document which explains the pro's and con's of accounting the the options in the advertised MSS, clarifying the right approach sounds good. Another point in favour of a separate doc is that TCP MSS description probably looks out of place in RFC 1323 which mainly talks about high performance TCP options. I do agree, that having larger MSS results in better TCP throughput and performance though :-) -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of David Borman > Sent: Friday, February 15, 2008 2:16 PM > To: tcpm@ietf.org > Subject: [tcpm] 1323 & TCP MSS in Appendix A > > Hi, > > In Chicago we discussed moving the description of the TCP MSS > option out of Appendix A and into a separate document. I > don't recall coming > to a decision, I think we were going to take it to the > mailing list. > So, here's the question: > > Should I take the description of the TCP MSS option out of > Appendix A and put it into a separate draft, or should we > just leave it in the revision for 1323? > > I believe the argument for moving it out into a separate > document was that this is an important point the implementors > continue to get wrong, so pulling it out into a separate > document will bring more visibility. > > My personal opinion is that not that strong, I'd be fine with > leaving it in 1323.bis, and also fine with moving it to its > own draft document. > > -David Borman > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > http://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Feb 18 10:44:06 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDC0C28C422; Mon, 18 Feb 2008 10:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.393 X-Spam-Level: X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z-HlFiHjbFD; Mon, 18 Feb 2008 10:44:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8EF83A6B73; Mon, 18 Feb 2008 10:44:04 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65323A6785 for ; Mon, 18 Feb 2008 10:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBD7qrl+4GDU for ; Mon, 18 Feb 2008 10:44:03 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id D68CB3A68D8 for ; Mon, 18 Feb 2008 10:44:02 -0800 (PST) X-Trace: 43355414/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.162.32 X-SBRS: None X-RemoteIP: 62.241.162.32 X-IP-MAIL-FROM: nwnetworks@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPpguUc+8aIg/2dsb2JhbACKcqJs X-IP-Direction: IN Received: from ranger.systems.pipex.net ([62.241.162.32]) by smtp.pipex.tiscali.co.uk with ESMTP; 18 Feb 2008 18:43:57 +0000 Received: from pc6 (1Cust144.tnt102.lnd4.gbr.da.uu.net [213.116.52.144]) by ranger.systems.pipex.net (Postfix) with SMTP id 2A518E00008E; Mon, 18 Feb 2008 18:43:55 +0000 (GMT) Message-ID: <01bd01c87255$83c0dae0$0601a8c0@pc6> From: "Tom Petch" To: , "Mark Allman" References: <20080206174017.6977C36516E@lawyers.icir.org> Date: Mon, 18 Feb 2008 18:32:00 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [tcpm] tcpsecure recommendations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Tom Petch List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org (2) my views are the same as last time. Tom Petch ----- Original Message ----- From: "Mark Allman" To: Sent: Wednesday, February 06, 2008 6:40 PM Subject: [tcpm] tcpsecure recommendations > It'd be good to get some opinions on the new tcpsecure version and get > it finished. The sticking point on this document is how strongly to > recommend TCP stacks implement / use the three mitigations in the draft > (to spoofed RSTs, SYNs and data segments). We had a discussion about > this in Chicago and also on the list. Since it seemed that we were not > converging because there was not WG-wide agreement on the scope of the > document we asked the authors to generate an applicability statement. > They did that, per a previous email from Anantha. The AS reads: > > The mitigations presented in this document talks about some known > in-window attacks and the solutions to the same. The mitigations > suggested in this draft SHOULD (RECOMMENDED) be implemented in > devices where the TCP connections are most vulnerable to the attacks > described in this document. Some examples of such TCP connections > are the ones that tend to be long-lived where the connection end > points can be determined, in cases where no auxiliary anti-spoofing > protection mechanisms like TCP MD5 can be deployed. TCP secure MAY > (OPTIONAL) be implemented in other cases. > > We can recommend each of mitigations with a MAY, SHOULD or MUST. In > Chicago we winnowed the proposals to three three: > > (1) RST spoofing mitigation: MAY > SYN spoofing mitigation: MAY > data injection mitigation: MAY > > (2) RST spoofing mitigation: SHOULD > SYN spoofing mitigation: SHOULD > data injection mitigation: SHOULD > > (3) RST spoofing mitigation: SHOULD > SYN spoofing mitigation: SHOULD > data injection mitigation: MAY > > Nobody has advocated for other permutations of recommendations > (although, clearly if people like some different combination they should > advocate away!). > > Can folks please weigh in on their feeling about how strongly we should > recommend these mitigations given the AS above? It'd be great to get > this document moving and we're sort of stuck here. > > Thanks, > allman > > _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Feb 18 16:12:15 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849BC3A6D90; Mon, 18 Feb 2008 16:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHNuhVQ9wKxr; Mon, 18 Feb 2008 16:12:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4C13A697F; Mon, 18 Feb 2008 16:12:14 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77243A697F for ; Mon, 18 Feb 2008 16:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yY52tgMOkBci for ; Mon, 18 Feb 2008 16:12:13 -0800 (PST) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 579DA3A6833 for ; Mon, 18 Feb 2008 16:12:11 -0800 (PST) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id m1J0C8Hf004174 for ; Mon, 18 Feb 2008 16:12:08 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 13F85163AE14 for ; Mon, 18 Feb 2008 19:11:57 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5CDB23D31DB for ; Mon, 18 Feb 2008 19:11:59 -0500 (EST) To: tcpm@ietf.org From: Mark Allman In-Reply-To: <01bd01c87255$83c0dae0$0601a8c0@pc6> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Glory Days MIME-Version: 1.0 Date: Mon, 18 Feb 2008 19:11:59 -0500 Message-Id: <20080219001159.5CDB23D31DB@lawyers.icir.org> Subject: Re: [tcpm] tcpsecure recommendations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2079320002==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============2079320002== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- Based on the minimal feedback in this thread and the hum we took in Chicago it seems that there is some preference for this path: > (3) RST spoofing mitigation: SHOULD > SYN spoofing mitigation: SHOULD > data injection mitigation: MAY The preference does not seem to be overwhelming, but in the absence of additional input Ted and I are inclined to take the above option as the WG's consensus. Note, we do not see overwhelming preference here, but we need to get this draft moving. So, if you are opposed to this approach and have not yet weighed in then now is your chance. We know that y'all will let us know if we have called this inappropriately. Thanks! allman tcpm co-chair --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHuh7PWyrrWs4yIs4RAnr+AJ4mDKXiQ9u4GGIu+7lmrAWqrsjIYwCgmxnm FPsJLtbkvvlvT/UiBDPARG4= =AC7g -----END PGP SIGNATURE----- --=_bOundary-- --===============2079320002== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm --===============2079320002==-- From tcpm-bounces@ietf.org Tue Feb 19 04:57:49 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140D73A69DD; Tue, 19 Feb 2008 04:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.478 X-Spam-Level: X-Spam-Status: No, score=-0.478 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWRZCGtEMdLX; Tue, 19 Feb 2008 04:57:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BEBE3A69D0; Tue, 19 Feb 2008 04:57:48 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1DE3A6990 for ; Tue, 19 Feb 2008 04:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9KPVBPG4Fcx for ; Tue, 19 Feb 2008 04:57:46 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id DA6593A680B for ; Tue, 19 Feb 2008 04:57:45 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m1JCvWh1030691; Tue, 19 Feb 2008 14:57:32 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m1JCvV75030687; Tue, 19 Feb 2008 14:57:32 +0200 Date: Tue, 19 Feb 2008 14:57:31 +0200 (EET) From: Pekka Savola To: tcpm@ietf.org Message-ID: User-Agent: Alpine 1.00 (LRH 882 2007-12-20) MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.92.1/5873/Tue Feb 19 00:37:39 2008 on otso.netcore.fi X-Virus-Status: Clean Subject: [tcpm] TCP option encoding in Timestamps X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org FYI, This may be of interest; RFC 4987 describes in Section 3.6 a FreeBSD 7.0 approach to encode TCP options in the TCP timestamp field in order to support a select set of TCP options when SYN cookies is enabled. There's now a proposed Linux implementation as well. This may be something worth thinking about in the context of draft-ietf-tcpm-1323bis as well. ---------- Forwarded message ---------- Date: Mon, 18 Feb 2008 15:45:12 -0800 From: Glenn Griffin To: ggriffin.kernel@gmail.com Cc: dada1@cosmosbay.com, johnpol@2ka.mipt.ru, alan@lxorguk.ukuu.org.uk, andi@firstfloor.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] Add IPv6 support to TCP SYN cookies I've posted a series of patches that I believe address Andi's concerns about syncookies not supporting valuable tcp options (primarily SACK, and window scaling). The premise being if the client support tcp timestamps we can encode the additional tcp options in the initial timestamp we send back to the client, and they will be echo'd back to us in the ack. Anyone interested have a look, and provide any suggestions you may have. The new patches are a superset of this patch, so if they are accepted this is one obsolete. Support arbitrary initial TCP timestamps http://lkml.org/lkml/2008/2/15/244 Enable the use of TCP options with syncookies http://lkml.org/lkml/2008/2/15/245 Add IPv6 Support to TCP SYN cookies http://lkml.org/lkml/2008/2/15/246 --Glenn -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Feb 19 05:57:18 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E19C628C571; Tue, 19 Feb 2008 05:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv-Slht6yEpi; Tue, 19 Feb 2008 05:57:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177BB28C580; Tue, 19 Feb 2008 05:57:18 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9725B28C549 for ; Tue, 19 Feb 2008 05:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQCCJP9s61F0 for ; Tue, 19 Feb 2008 05:57:14 -0800 (PST) Received: from mailer2.psc.edu (unknown [IPv6:2001:5e8:2:42:2e0:81ff:fe30:e898]) by core3.amsl.com (Postfix) with ESMTP id DC50628C581 for ; Tue, 19 Feb 2008 05:56:57 -0800 (PST) Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer2.psc.edu (8.14.2/8.13.3) with ESMTP id m1JDuqX7029177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 08:56:53 -0500 (EST) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id m1JDuqZ9006712; Tue, 19 Feb 2008 08:56:52 -0500 Date: Tue, 19 Feb 2008 08:56:52 -0500 (EST) From: Matt Mathis To: TCP Maintenance and Minor Extensions WG In-Reply-To: <0C53DCFB700D144284A584F54711EC5804B70C05@xmb-sjc-21c.amer.cisco.com> Message-ID: References: <25C477DF-381D-46E7-BF8F-05461B3FCC56@windriver.com> <0C53DCFB700D144284A584F54711EC5804B70C05@xmb-sjc-21c.amer.cisco.com> MIME-Version: 1.0 Cc: David Borman Subject: Re: [tcpm] 1323 & TCP MSS in Appendix A X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Fri, 15 Feb 2008, Anantha Ramaiah (ananth) wrote: > > I think having a separate document which explains the pro's and con's of > accounting the the options in the advertised MSS, clarifying the right > approach sounds good. Another point in favour of a separate doc is that > TCP MSS description probably looks out of place in RFC 1323 which mainly > talks about high performance TCP options. I agree. The MSS option really has a different scope: it applies to all TCP implementations, high speed or otherwise and is essentially a mandatory clarification of earlier documents. It is also valuable and important to help middle box implementers (who often futz with the MSS option) to get it less wrong. Thanks, --MM-- _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Feb 19 11:30:06 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9F6628C709; Tue, 19 Feb 2008 11:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYP+y5Sm4q-7; Tue, 19 Feb 2008 11:30:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AAAD28C629; Tue, 19 Feb 2008 11:30:03 -0800 (PST) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0B92F28C4F7; Tue, 19 Feb 2008 11:30:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080219193002.0B92F28C4F7@core3.amsl.com> Date: Tue, 19 Feb 2008 11:30:02 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --NextPart 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 : Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets Author(s) : S. Floyd, I. Property Filename : draft-ietf-tcpm-ecnsyn-05.txt Pages : 26 Date : 2008-02-19 This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document specifies the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to a report of an ECN-marked SYN/ACK packet by reducing its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. This document is intended to update RFC 3168. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-ecnsyn-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-ecnsyn-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-19112848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-ecnsyn-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-ecnsyn-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-19112848.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Tue Feb 19 15:18:27 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567613A6E37; Tue, 19 Feb 2008 15:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+vbRPYfIoZJ; Tue, 19 Feb 2008 15:18:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DA203A6DB0; Tue, 19 Feb 2008 15:18:23 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 141743A6D4C for ; Tue, 19 Feb 2008 15:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGoLU0kJ-NBn for ; Tue, 19 Feb 2008 15:18:19 -0800 (PST) Received: from mx-out-01.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id 005D828C696 for ; Tue, 19 Feb 2008 15:16:43 -0800 (PST) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id m1JNGeX5022045; Wed, 20 Feb 2008 01:16:40 +0200 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.32]) by mx-av-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id m1JNGegd000704; Wed, 20 Feb 2008 01:16:40 +0200 Received: from hell.hell.gr (adsl2-71.lsf.forthnet.gr [79.103.129.71]) by MX-IN-05.forthnet.gr (8.14.2/8.14.2) with ESMTP id m1JNGcnp027855; Wed, 20 Feb 2008 01:16:39 +0200 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-05.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: akuzma@northwestern.edu Date: Wed, 20 Feb 2008 01:16:26 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802200116.26451.v13@v13.gr> Cc: tcpm@ietf.org Subject: [tcpm] ECN+SYN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hello there, I've just read the proposal regarding ECN and SYN/ACK packets and I cannot understand why not to allow ECN in SYN packets too. Let me elaborate a bit further: In paragraph 4, page 10 you mention two reasons which I find incorrect: * First reason claims that there is no guarantee that the other TCP endpoint is ECN-capable. AFAICT this is exactly the case as in ECN in SYN/ACK packets. I fail to see why there is a difference when "the connection" looses the SYN instead of the SYN/ACK packet. * Next paragraph says that SYN packets can be missused. IMHO, this is already possible. A malicious host can send IP packets with the ECT codepoint set that include non-ECN TCP SYN packets, or even SYN/ECN+ECT packets. There is no guarantee that an endpoint will drop SYN/ECN+ECT packets and I believe there is no valid reason for having an ECN capable endpoint drop SYN/ECN packets (as being malicious). Because of my limited experience I believe that I'm not able to comment on reason (3) of page 22 (appendix A). Best regards, Harhalakis Stefanos p.s. Please excuse me if I'm wrong. I'm new in this area. _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Feb 19 15:26:29 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DD9428C6B5; Tue, 19 Feb 2008 15:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.177 X-Spam-Level: X-Spam-Status: No, score=-0.177 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HksBmAWixS+J; Tue, 19 Feb 2008 15:26:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8882528C67A; Tue, 19 Feb 2008 15:26:28 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ADD128C619 for ; Tue, 19 Feb 2008 15:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGtbQnvIkMIW for ; Tue, 19 Feb 2008 15:26:26 -0800 (PST) Received: from mx-out-05.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id AB22F28C40C for ; Tue, 19 Feb 2008 15:26:25 -0800 (PST) Received: from mx-av-02.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.13.8/8.13.8) with ESMTP id m1JNQLnN031291; Wed, 20 Feb 2008 01:26:21 +0200 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id m1JNQLxs006736; Wed, 20 Feb 2008 01:26:21 +0200 Received: from hell.hell.gr (adsl2-71.lsf.forthnet.gr [79.103.129.71]) by MX-IN-04.forthnet.gr (8.14.2/8.14.2) with ESMTP id m1JNQJJq009395; Wed, 20 Feb 2008 01:26:21 +0200 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-04.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: akuzma@northwestern.edu Date: Wed, 20 Feb 2008 01:26:07 +0200 User-Agent: KMail/1.9.7 References: <200802200116.26451.v13@v13.gr> In-Reply-To: <200802200116.26451.v13@v13.gr> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802200126.07909.v13@v13.gr> Cc: tcpm@ietf.org Subject: Re: [tcpm] ECN+SYN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wednesday 20 February 2008, Stefanos Harhalakis wrote: > Because of my limited experience I believe that I'm not able to comment > on reason (3) of page 22 (appendix A). Correction: The reason specified in the second paragraph of page 22 (appendix B) regarding the use of the extra bit for the ECN-SYN packets _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Feb 19 19:29:23 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391B128C0FE; Tue, 19 Feb 2008 19:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.015 X-Spam-Level: X-Spam-Status: No, score=-1.015 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sq9YYGY2b7C; Tue, 19 Feb 2008 19:29:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8373A6BB7; Tue, 19 Feb 2008 19:29:22 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370913A6BB7 for ; Tue, 19 Feb 2008 19:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ir+6BbXLBtQ for ; Tue, 19 Feb 2008 19:29:20 -0800 (PST) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 9B7353A68AC for ; Tue, 19 Feb 2008 19:29:20 -0800 (PST) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id m1K3THJB030382 for ; Tue, 19 Feb 2008 19:29:17 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 79A481667F80 for ; Tue, 19 Feb 2008 22:29:04 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 49EA03DB8D6 for ; Tue, 19 Feb 2008 22:29:07 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Glory Days MIME-Version: 1.0 Date: Tue, 19 Feb 2008 22:29:07 -0500 Message-Id: <20080220032907.49EA03DB8D6@lawyers.icir.org> Subject: [tcpm] meeting in Philly X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0496828739==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0496828739== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Some folks have noticed that we were late with our request and didn't make it on to the original agenda. The secratariet seemingly has forgiven our tardiness and given us the following slot: > TCPM Session 1 (2 hours) > Tuesday, Afternoon Session I 1300-1500 (I think all slots are still to be considered "draft", so YMMV.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHu56CWyrrWs4yIs4RAqK9AKCAdgW6U0apZqEVTCp28NeFBOdusgCfVE2R ccimlB5b36ODSl18h+rRR8M= =rZzq -----END PGP SIGNATURE----- --=_bOundary-- --===============0496828739== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm --===============0496828739==-- From tcpm-bounces@ietf.org Wed Feb 20 17:49:56 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0335028C6F4; Wed, 20 Feb 2008 17:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOm-G9NKIFat; Wed, 20 Feb 2008 17:49:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 001D63A6B54; Wed, 20 Feb 2008 17:49:54 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECB653A6BD1 for ; Wed, 20 Feb 2008 17:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TsfnuT2iBDR for ; Wed, 20 Feb 2008 17:49:51 -0800 (PST) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.68]) by core3.amsl.com (Postfix) with ESMTP id DF7DA3A6B54 for ; Wed, 20 Feb 2008 17:49:51 -0800 (PST) Received: from mac.com (asmtp001-s [10.150.69.64]) by smtpoutm.mac.com (Xserve/smtpout005/MantshX 4.0) with ESMTP id m1L1nm94000125; Wed, 20 Feb 2008 17:49:48 -0800 (PST) Received: from [192.168.1.65] (adsl-70-231-238-142.dsl.snfc21.sbcglobal.net [70.231.238.142]) (authenticated bits=0) by mac.com (Xserve/asmtp001/MantshX 4.0) with ESMTP id m1L1nhTL023814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2008 17:49:44 -0800 (PST) In-Reply-To: <200802200116.26451.v13@v13.gr> References: <200802200116.26451.v13@v13.gr> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Sally Floyd Date: Wed, 20 Feb 2008 17:49:44 -0800 To: Stefanos Harhalakis X-Mailer: Apple Mail (2.753) Cc: akuzma@northwestern.edu, tcpm@ietf.org Subject: Re: [tcpm] ECN+SYN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Stefanos - - Sally http://www.icir.org/floyd/ > I've just read the proposal regarding ECN and SYN/ACK packets and > I cannot > understand why not to allow ECN in SYN packets too. Let me > elaborate a bit > further: > > In paragraph 4, page 10 you mention two reasons which I find > incorrect: > > * First reason claims that there is no guarantee that the other > TCP endpoint > is ECN-capable. AFAICT this is exactly the case as in ECN in SYN/ > ACK packets. > I fail to see why there is a difference when "the connection" > looses the SYN > instead of the SYN/ACK packet. When a TCP initiator sends a SYN packet, the initiator does not know if the TCP at the other end is willing to use ECN in this connection. In contrast, when a TCP responder sends a SYN/ACK packet, that responder has already received a SYN packet from the TCP initiator, indicating whether or not the TCP initiator wishes to use ECN with this connection. The goal is for all ECN-capable TCP connections to be able to deal with an ECN-marked SYN/ACK packet. When this goal is reached, then if the TCP responder receives a SYN packet agreeing to use ECN for this connection, then the TCP responder would know that the TCP initiator is able to respond properly to an ECN-marked SYN/ACK packet. > * Next paragraph says that SYN packets can be missused. IMHO, this > is already > possible. A malicious host can send IP packets with the ECT > codepoint set > that include non-ECN TCP SYN packets, or even SYN/ECN+ECT packets. > There is > no guarantee that an endpoint will drop SYN/ECN+ECT packets and I > believe > there is no valid reason for having an ECN capable endpoint drop > SYN/ECN > packets (as being malicious). Yep, a malicious host could set the ECT codepoint on a TCP SYN packet now, or on any other packet, and there is no reason to assume that an ECN-capable router would look at anything other than the ECN field in the IP header before ECN-marking the packet instead of dropping it. Such concerns are discussed in Section 7 of RFC 3168, on "Non-compliance by the End Nodes". However, now, any host that would set the ECT codepoint on a TCP SYN packet would be clearly violating the protocol specified in draft-ietf-tcpm-ecnsyn-04.txt. And this violation would be clearly visible to any routers or TCP responder that cared to check. Thus, at some point there could be *policers* in the network that check to find end-nodes that are cheating about ECN and other matters. And such policers could easily identify cheaters that set the ECT codepoint on TCP SYN packets (and deal with them appropriately). And a popular and busy web server *might* be configured not to respond to TCP SYN packets from initiators that don't bother to follow the specified protocols. It might be that something can be misused now. However, that does not necessarily justify opening the door for even greater misuse (by standardizing the use of ECT with TCP SYN packets). In summary, I would be *strongly* opposed to any proposal for TCP SYN packets to be sent as ECN-capable. > Because of my limited experience I believe that I'm not able to > comment on > reason (3) of page 22 (appendix A). > > Best regards, > Harhalakis Stefanos > > p.s. Please excuse me if I'm wrong. I'm new in this area. Well, you would read this email, and see what you think. Take care, - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 21 13:53:46 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9127528CB3A; Thu, 21 Feb 2008 13:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.115 X-Spam-Level: X-Spam-Status: No, score=-0.115 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TITPwDRJt6Cv; Thu, 21 Feb 2008 13:53:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8C028CAC8; Thu, 21 Feb 2008 13:53:36 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6539E28C772 for ; Thu, 21 Feb 2008 13:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70D-yDNV28Kz for ; Thu, 21 Feb 2008 13:53:32 -0800 (PST) Received: from mx-out-01.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id 25FD63A69C1 for ; Thu, 21 Feb 2008 13:53:31 -0800 (PST) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id m1LLrQ0r007924; Thu, 21 Feb 2008 23:53:26 +0200 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-05.forthnet.gr (8.14.2/8.14.2) with ESMTP id m1LLrQ6J020708; Thu, 21 Feb 2008 23:53:26 +0200 Received: from hell.hell.gr (adsl3-182.lsf.forthnet.gr [79.103.130.182]) by MX-IN-02.forthnet.gr (8.14.2/8.14.2) with ESMTP id m1LLrNX4003641; Thu, 21 Feb 2008 23:53:24 +0200 Authentication-Results: MX-IN-02.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-02.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: Sally Floyd Date: Thu, 21 Feb 2008 23:53:08 +0200 User-Agent: KMail/1.9.7 References: <200802200116.26451.v13@v13.gr> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802212353.09084.v13@v13.gr> Cc: akuzma@northwestern.edu, tcpm@ietf.org Subject: Re: [tcpm] ECN+SYN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thursday 21 February 2008, Sally Floyd wrote: > In summary, I would be *strongly* opposed to any proposal > for TCP SYN packets to be sent as ECN-capable. Hello Sally and thank you for your detailed and explanatory reply! (I'm replying to the whole mail as a whole) After carefully reading your mail a couple of times, re-examining draft-ietf-tcpm-ecnsyn-05.txt and having in mind RFC3168, I still believe that the draft should be modified a bit regarding the SYN+ECT case. For the rest of the mail I'm using the term ECT when referring to flags in IP packets and ECN when referring to TCP flags. First of all, partially in contrast with RFC3168, the draft indirectly suggests that ECT should be used in SYN/ACK packets as: a) an improvement for detecting congestion a little bit earlier and starting with a reduced window size (smaller initial window) (p.8, bottom) b) a method of QoS that will result in less SYN/ACK looses when operating on an ECN enabled network (p.5, bottom (2)) (p.7, top). Point (a) has to do with ECN(+ECT) and (b) has to do with ECT. Also, the draft: a) Proposes ECT for SYN/ACK segments b) Forbids ECT for SYN segments I argue that the exact same reasons specified in point (b) (regarding QoS) apply to SYN segments too. In fact, if you imagine an ECN enabled Internet that uses RED everywhere then the only dropped segments of a TCP session because of congestion may be the SYNs (!!). Also consider that loosing the first SYN of a session MAY result in a ECN-less connection (RFC3168 6.1.1.1) - which increases its importance. I suggest that the draft: a) Do not forbid ECT for SYN segments b) Propose the usage of ECT for SYN segments Since on an ECN enabled Internet that uses AQM everywhere the ECN bits in IP will (most probably) also work as a kind of QoS, we should not consider ECT only as a congestion indication method. We should have in mind the effects of not using ECT which will result in poorer performance. I totally agree that most probably we will not benefit from congestion indication in SYN segments and I understand that RFC3168 explicitly says that "an ECT codepoint MUST NOT be set in a packet unless the loss of that packet in the network would be detected by the end nodes and interpreted as an indication of congestion" (RFC3168 5.2) but on the other hand, SYN and SYN/ACK segments are not exactly data (for normal operations) and (I believe that) they are only a very small fraction of the whole internet traffic (either as packet count or byte count). So, it may be wise and harmless to also propose in this draft that "when a host sends a SYN segment it MAY set the ECT codepoint to prevent intermediate routers from dropping it instead of marking it" Regarding security considerations: I fail to see why ECT+SYN may be a threat. Of course a malicious user may use it to prevent intermediate routers from dropping those packets but trying to prevent this: a) Is not what we're doing everywhere else b) Is like disallowing fast and reliable internet connections to prevent malicious users from performing SYN flooding. Hope that this clarifies my thoughts... and that they are not (totally) wrong :-) Best regards, Harhalakis Stefanos _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 21 14:52:19 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E88AA3A6CF5; Thu, 21 Feb 2008 14:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWS+sELUbWnF; Thu, 21 Feb 2008 14:52:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DFA53A6B51; Thu, 21 Feb 2008 14:52:18 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BC823A6882 for ; Thu, 21 Feb 2008 14:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ojqge3aTckPL for ; Thu, 21 Feb 2008 14:52:15 -0800 (PST) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by core3.amsl.com (Postfix) with ESMTP id 56AFC3A683C for ; Thu, 21 Feb 2008 14:51:49 -0800 (PST) Received: (qmail 35990 invoked from network); 21 Feb 2008 22:07:41 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Feb 2008 22:07:41 -0000 Message-ID: <47BE0080.1090009@freebsd.org> Date: Thu, 21 Feb 2008 23:51:44 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Matt Mathis References: <47952032.3030809@freebsd.org> <4797D53C.10908@freebsd.org> In-Reply-To: Cc: TCP Maintenance and Minor Extensions WG Subject: Re: [tcpm] Ordering of SACK blocks, flushing of reassembly queue after inactivity X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Matt Mathis wrote: > If you are thinking at the scale of a dozen packet windows with just a > couple of losses, I don't disagree with you. However, with 1000 packet > windows, you almost never see "just a couple of losses", and your > proposed simplification will be very exposed to lost ACKs. Given that > the ACK rate doubles, your chances are not good. Based on the excellent feedback and rationale I've implemented the RFC2018 suggested ordering of the SACK blocks. [The whole thing is still in a separate development tree] -- Andre > BTW 1000 packet windows are not all that big: 1500 Byte MTU, 70 ms RTT > and only 90 Mb/s - well within reach for any university user in the US > or Europe > and FIOS users in Korea or Japan. The real challenge is getting the > scoreboard to work well with 10k or 100k packet windows.... > > Thanks, > --MM-- > ------------------------------------------- > Matt Mathis http://www.psc.edu/~mathis > Work:412.268.3319 Home/Cell:412.654.7529 > ------------------------------------------- > Evil is defined by mortals who think they know > "The Truth" and use force to apply it to others. > > On Thu, 24 Jan 2008, Andre Oppermann wrote: > >> Matt Mathis wrote: >>>> The first is the ordering of SACK blocks. The block based reassembly >>>> queue lends itself to generate the SACK option from. The blocks are >>>> ordered ascending from the first segment closest to rcv_nxt. Per RFC >>>> 2018 Section 4 the first SACK block MUST be the one with the most >>>> recent addition to it. This is easily done by adding a pointer to >>>> the block last modified. However a bit later it says the following >>>> SACK blocks SHOULD be also in order of their 'recentness' while also >>>> specifying they may be listed in arbitrary order. Now tracking this >>>> information in the block based and sequence number ordered reassembly >>>> queue it a bit more involved and I wonder if it really necessary and >>>> useful. In general the SACK blocks tend to be ordered sequentially >>>> after the first SACK block in single random loss cases. Only in >>>> packet reordering cases, possibly mixed with loss, this may not be >>>> the case. On the other hand the most valuable information for the >>>> sender are the blocks closest to rcv_nxt so it can fill the hole and >>>> complete the sequence space. While the RFC leaves me free to do as >>>> I please I wonder if there are observations or rationales that clearly >>>> show the the ordering by recentness to be better than sequential >>>> ordering after the first SACK block? >>> >>> RFC 2018 is written the way it is written to maximize the robustness >>> in the presence of lost ACKs. If the network never looses ACKs, then >>> just reporting the single SACK block with the newest data is >>> guaranteed to be sufficient for the sender to have perfect knowledge >>> about the state of the reassembly queue at the receiver. >>> >>> If occasional ACKs and one of several non-contiguous retransmissions >>> are lost, the sender might not learn that some of the retransmissions >>> were successful if the 2nd and 3rd SACK block do not reflect the >>> history of the first block. >>> >>> Although in most cases you want to know about blocks closest to >>> rcv_nxt, that is not always true. In particular if the two oldest >>> retransmissions are lost and then some ACKs are also lost, the sender >>> will not know that some of the later holes have been successfully >>> filled. If you are going to take a timeout anyhow, this isn't so >>> important, but we tried to avoid timeouts at all costs. >> >> This pretty much where my question originates from. The approach of >> reporting the most recent block first and then closest and second >> closest to rcv_nxt works just fine as long as the number of holes is >> not large or excessive. However even then I may argue that filling >> the hole after rcv_nxt is the most important goal, above reporting >> second and third recent blocks (if different). Once the first hole >> is filled the closest and second closest blocks to rcv_nxt automatically >> shift to the right by one and get reported immediately. When a large >> number of holes appear the sender is very likely to face a collapsed >> congestion window and will have to throttle down its rate of sending. >> This makes it probable that guaranteed knowledge further out is not >> relevant at this point in time. By the time this becomes relevant it >> get reported because it gets closer to rcv_nxt. >> >> I'm not forcefully arguing this view but want to bring it up for further >> elaboration and comparison with the other recommended approaches. >> >>> If the 2nd and 3rd block reflect most recent history of the 1st >>> block, the sender will have perfect knowledge of the reassembly queue >>> as long as the network never looses 3 consecutive ACKs (and usually >>> tolerates many more losses). >>> >>> The "may use other algorithms" is there because we suspect that you >>> can do even better, for example by making the 2nd and 3rd blocks >>> periodically or randomly re-report all old SACK blocks. As far a I >>> know this has never been pursued, and we certainly did not want to >>> specify or even suggest it in 2018. >>> >>> Everyone else implements it as written.... >> >> FreeBSD currently does so as well. It's in my development branch I'm >> working and experimenting with alternative approaches. Using the block >> building logic of the reassembly queue itself for SACK reporting is >> quite tempting. ;-) >> >>> Oh, except nix "timeouts MUST clear the scoreboard"... If you >>> preserve the scoreboard on a timeout, you might be able to do >>> goodput=throughput (zero duplicate data at the receiver) under very >>> high loss rates, which is a good thing. >> >> Thanks for your extensive explanations. >> >> -- >> Andre >> > > _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 21 15:09:35 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68183A6ABE; Thu, 21 Feb 2008 15:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.564 X-Spam-Level: X-Spam-Status: No, score=-0.564 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc4Cqtu6qMU5; Thu, 21 Feb 2008 15:09:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41C83A68EF; Thu, 21 Feb 2008 15:09:34 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA83B3A6A24 for ; Thu, 21 Feb 2008 15:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcrZTF4RytD2 for ; Thu, 21 Feb 2008 15:09:32 -0800 (PST) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by core3.amsl.com (Postfix) with ESMTP id 95C633A6814 for ; Thu, 21 Feb 2008 15:09:31 -0800 (PST) Received: (qmail 36368 invoked from network); 21 Feb 2008 22:25:23 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Feb 2008 22:25:23 -0000 Message-ID: <47BE04A2.8000000@freebsd.org> Date: Fri, 22 Feb 2008 00:09:22 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: tcpm@ietf.org Subject: [tcpm] Handling of FIN in the reassembly queue X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org The TCP reassembly queue is very good at handling and queuing out of order data. However correctly handling and queuing an out of order FIN seems to be a bit tricky for a number of (broken) edge cases: 1. FIN points into the middle of already queued data (or hole); Ignore the FIN and integrate the data? Ignore the whole segment with the bogus FIN? Integrate the data, move the FIN and flush excess data? 2. FIN was already received and another one arrives pointing into the middle of already queue data (or hole); Ignore the FIN and integrate the data? Ignore the whole segment with the bogus FIN? Integrate the data, move the FIN and flush excess data? 3. FIN was already received and another one arrives pointing beyond the previous one; Ignore the FIN and integrate the data (if within previous FIN)? Ignore the whole segment with the bogus FIN? Integrate the data and move the FIN? 4. FIN without data pointing beyond already queued data; Queuing a standalone FIN w/o data and not directly attaching to the end of the queue complicates the implementation a lot. Is it acceptable to ignore the FIN for the moment and have it retransmitted (with or without data) later? For reference the traditional reassembly queue implementation doesn't care and queues any segment with FIN in any place. Depending on the hole situation this can lead to strange behavior and only ever partly dequeued data. Any input, insight and discussion welcome. :-) -- Andre _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Feb 21 18:25:10 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFAC13A6C16; Thu, 21 Feb 2008 18:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-1.741, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkce7ebbMDen; Thu, 21 Feb 2008 18:25:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11753A6C45; Thu, 21 Feb 2008 18:24:51 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD323A6D1A for ; Thu, 21 Feb 2008 18:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Esm-VNSebY8t for ; Thu, 21 Feb 2008 18:24:35 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5158A28CAA1 for ; Thu, 21 Feb 2008 18:24:08 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 21 Feb 2008 18:24:04 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1M2O4jk009662; Thu, 21 Feb 2008 18:24:04 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1M2O4R2016445; Fri, 22 Feb 2008 02:24:04 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 18:24:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 18:23:44 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5804BCF302@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <47BE04A2.8000000@freebsd.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Handling of FIN in the reassembly queue Thread-Index: Ach03tT4x2WBgSSETUOekVd2cO4zBAAECYNQ References: <47BE04A2.8000000@freebsd.org> From: "Anantha Ramaiah (ananth)" To: "Andre Oppermann" , X-OriginalArrivalTime: 22 Feb 2008 02:24:03.0925 (UTC) FILETIME=[FE200850:01C874F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3449; t=1203647044; x=1204511044; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20Handling=20of=20FIN=20in=20the =20reassembly=20queue |Sender:=20; bh=YGPM5zDKo3wLSN//Ndm661ivAUMCrRxur/qEV0QhUko=; b=DwmekBkhLLKX2MEg+ZPRxNkoMlimJ5qMSFthmf5utz0YHZUSpClXRurqcV l5tT1GVtPRzMoMs0+qEWbMOUXfLA6+WGKddBG9DPxN52f8E3CC5nU93Q8FV6 e9STfENu2qLUPNaWRqypFD3zkJSy0B1HWUniqKkNXL1kwtpYeKuMI=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [tcpm] Handling of FIN in the reassembly queue X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Andre, > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Andre Oppermann > Sent: Thursday, February 21, 2008 3:09 PM > To: tcpm@ietf.org > Subject: [tcpm] Handling of FIN in the reassembly queue > > The TCP reassembly queue is very good at handling and queuing > out of order data. However correctly handling and queuing an > out of order FIN seems to be a bit tricky for a number of > (broken) edge cases: > > 1. FIN points into the middle of already queuedh data (or hole); > Ignore the FIN and integrate the data? > Ignore the whole segment with the bogus FIN? > Integrate the data, move the FIN and flush excess data? I would think discarding the FIN would be fine, but if the FIN gets retransmitted again, then this puts a question mark on the data sitting on the reassembly queue and in such cases we can possibly conclude the data in the reassembly queue is bogus? This brings up another question : suppose a TCP stack has sent s1, s2 s3 and s3 with FIN, assume s1 is dropped, is it ok to retransmit s1 with FIN bit set (some stacks might see the state and blindly color the segment with FIN) I don't think this is allowed? > > 2. FIN was already received and another one arrives pointing > into the middle of already queue data (or hole); > Ignore the FIN and integrate the data? > Ignore the whole segment with the bogus FIN? > Integrate the data, move the FIN and flush excess data? In the regular case (in-order) if the data is already consumed by the application and the window has slided, TCP simply ignores the duplicate data. Now for data sitting in the retransmission queue, we should probably do the same, I would ignore the whole segment. [ I know in this case FIN is extra] > > 3. FIN was already received and another one arrives pointing > beyond the previous one; > Ignore the FIN and integrate the data (if within previous FIN)? > Ignore the whole segment with the bogus FIN? > Integrate the data and move the FIN? Ignore the FIN. > > 4. FIN without data pointing beyond already queued data; > Queuing a standalone FIN w/o data and not directly attaching > to the end of the queue complicates the implementation a lot. > Is it acceptable to ignore the FIN for the moment and have it > retransmitted (with or without data) later? Actually it depends on how the reassembly queue is implemented, if you have a descriptor block for each data element sitting in the reassembly queue, then you simply set a bit that indicating FIN is present which you could do for the last segment sitting in the reassembly queue. > > For reference the traditional reassembly queue implementation > doesn't care and queues any segment with FIN in any place. > Depending on the hole situation this can lead to strange > behavior and only ever partly dequeued data. > > Any input, insight and discussion welcome. :-) I think it is an interesting discussion for sure :-). There are other cases which come to mind as well (half-close and simultaneous close cases) -Anantha > > -- > Andre > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > http://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Feb 22 10:18:50 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1365128C451; Fri, 22 Feb 2008 10:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.239 X-Spam-Level: X-Spam-Status: No, score=-0.239 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoBONeStvu-6; Fri, 22 Feb 2008 10:18:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E3628C25B; Fri, 22 Feb 2008 10:18:47 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4656728C25B for ; Fri, 22 Feb 2008 10:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zC61Rsg-Bksd for ; Fri, 22 Feb 2008 10:18:45 -0800 (PST) Received: from frantic.weston.borman.com (frantic-dmz.weston.BORMAN.COM [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id 46FCE28C420 for ; Fri, 22 Feb 2008 10:17:29 -0800 (PST) Received: from [127.0.0.1] (frantic.weston.borman.com [206.196.45.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id m1MIHB5G025919; Fri, 22 Feb 2008 12:17:11 -0600 (CST) Message-Id: <03D0C184-E5FB-4FA3-AE2E-1DBF9906492F@weston.borman.com> From: David Borman To: Anantha Ramaiah (ananth) In-Reply-To: <0C53DCFB700D144284A584F54711EC5804BCF302@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 22 Feb 2008 12:17:10 -0600 References: <47BE04A2.8000000@freebsd.org> <0C53DCFB700D144284A584F54711EC5804BCF302@xmb-sjc-21c.amer.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: tcpm@ietf.org Subject: Re: [tcpm] Handling of FIN in the reassembly queue X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Andre (and Anantha), On Feb 21, 2008, at 8:23 PM, Anantha Ramaiah (ananth) wrote: > Andre, > >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of Andre Oppermann >> Sent: Thursday, February 21, 2008 3:09 PM >> To: tcpm@ietf.org >> Subject: [tcpm] Handling of FIN in the reassembly queue >> >> The TCP reassembly queue is very good at handling and queuing >> out of order data. However correctly handling and queuing an >> out of order FIN seems to be a bit tricky for a number of >> (broken) edge cases: >> >> 1. FIN points into the middle of already queuedh data (or hole); >> Ignore the FIN and integrate the data? >> Ignore the whole segment with the bogus FIN? >> Integrate the data, move the FIN and flush excess data? > > I would think discarding the FIN would be fine, but if the FIN gets > retransmitted again, then this puts a question mark on the data > sitting > on the reassembly queue and in such cases we can possibly conclude the > data in the reassembly queue is bogus? First, an important point: Despite the fact that the BSD code calls it a reassembly queue, TCP does *NOT* have a reassembly queue, it has a *resequencing* queue. This distinction is important, because its purpose is to defer processing of packets that were received out-of- order. TCP packets are processed in sequence, as ordered by SEG.SEQ. In the resequencing queue, optimizations can be done to coalesce adjacent packets, but that doesn't change the fact that it is still a resequencing queue, for packets that have not yet been processed. (But as a side note, that's not entirely true. Some processing of out- of-order packets has to happen when the packets arrive. For example, the ACK field needs to be processed, as well as the Urgent pointer, but I won't go into the details here.) For any TCP connection, in each direction there can be only one FIN, it will never move, and there will never be any valid data transmitted after the FIN. So, if you get into this situation, you already have a problem, you just don't know what the problem is. Either the previously received out-of-sequence data is bad, or the current packet with the FIN is bad, but you don't know which. As to what to do if this scenario should actually happen: If these packets were received in sequence, the packet with the FIN would put us into CLOSE-WAIT state. The data in the packets with SEG.SEQ after the FIN would then be ignored, see page 75 in RFC 793. So, it seems that the thing to do would be to integrate the data with the FIN, and flush the previously received data that is after the FIN. > > > This brings up another question : suppose a TCP stack has sent s1, s2 > s3 and s3 with FIN, assume s1 is dropped, is it ok to retransmit s1 > with > FIN bit set (some stacks might see the state and blindly color the > segment with FIN) I don't think this is allowed? Absolutely not. The FIN is part of the sequence space, it occupies one byte at the end of s3. If you set FIN on s1, that is the same place in the sequence space as the first byte of s2. > > >> >> 2. FIN was already received and another one arrives pointing >> into the middle of already queue data (or hole); >> Ignore the FIN and integrate the data? >> Ignore the whole segment with the bogus FIN? >> Integrate the data, move the FIN and flush excess data? > > In the regular case (in-order) if the data is already consumed by the > application and the window has slided, TCP simply ignores the > duplicate > data. Now for data sitting in the retransmission queue, we should > probably do the same, I would ignore the whole segment. [ I know in > this > case FIN is extra] You should be consistent. Once again, I'd say integrate the data and FIN into the resequencing queue, and flush the excess data beyond this FIN. > > >> >> 3. FIN was already received and another one arrives pointing >> beyond the previous one; >> Ignore the FIN and integrate the data (if within previous FIN)? >> Ignore the whole segment with the bogus FIN? >> Integrate the data and move the FIN? > > Ignore the FIN. Being consistent, throw away this new packet, since it is beyond the previous FIN. > > >> >> 4. FIN without data pointing beyond already queued data; >> Queuing a standalone FIN w/o data and not directly attaching >> to the end of the queue complicates the implementation a lot. >> Is it acceptable to ignore the FIN for the moment and have it >> retransmitted (with or without data) later? Yes, you can always throw away any out-of-sequence packets. It's the same as if the packet got lost and never arrived in the first place. It'll arrive again either with the missing data just before the FIN, or in a separate retranmission or any other non-data packets with the same sequence number as the FIN. >> > > Actually it depends on how the reassembly queue is implemented, if you > have a descriptor block for each data element sitting in the > reassembly > queue, then you simply set a bit that indicating FIN is present which > you could do for the last segment sitting in the reassembly queue. The FIN occupies a specific byte in the sequence space. You should still be able to attach the FIN at the end of the resequencing queue with a specific sequence number, you'd just have a length of zero with a bit saying that it contains the FIN. Otherwise, you can always just ignore the FIN. >> For reference the traditional reassembly queue implementation >> doesn't care and queues any segment with FIN in any place. >> Depending on the hole situation this can lead to strange >> behavior and only ever partly dequeued data. Yes, some interesting things could happen with the scenarios you mention, and not always the right thing. -David Borman >> >> >> Any input, insight and discussion welcome. :-) > > I think it is an interesting discussion for sure :-). There are other > cases which come to mind as well (half-close and simultaneous close > cases) > > -Anantha >> >> -- >> Andre >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> http://www.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > http://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Feb 22 11:40:51 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98DC28CBD6; Fri, 22 Feb 2008 11:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=-1.985, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FzYFQ+WXVJg; Fri, 22 Feb 2008 11:40:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D540E28C2B6; Fri, 22 Feb 2008 11:40:15 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17C1128CBAB for ; Fri, 22 Feb 2008 11:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQnHnOd7dAjq for ; Fri, 22 Feb 2008 11:40:07 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 76A3428CBAF for ; Fri, 22 Feb 2008 11:38:44 -0800 (PST) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 22 Feb 2008 11:38:40 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id m1MJceFw001590; Fri, 22 Feb 2008 11:38:40 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1MJcep4008568; Fri, 22 Feb 2008 19:38:40 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 11:38:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 11:38:16 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5804BCF58E@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <03D0C184-E5FB-4FA3-AE2E-1DBF9906492F@weston.borman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Handling of FIN in the reassembly queue Thread-Index: Ach1fzJWiGGUKy/DTGG4WpfwwP3IiQABM4Yw References: <47BE04A2.8000000@freebsd.org> <0C53DCFB700D144284A584F54711EC5804BCF302@xmb-sjc-21c.amer.cisco.com> <03D0C184-E5FB-4FA3-AE2E-1DBF9906492F@weston.borman.com> From: "Anantha Ramaiah (ananth)" To: "David Borman" X-OriginalArrivalTime: 22 Feb 2008 19:38:35.0879 (UTC) FILETIME=[83E48F70:01C8758A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3323; t=1203709120; x=1204573120; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20Handling=20of=20FIN=20in=20the =20reassembly=20queue |Sender:=20; bh=PSsfIZEw0baFWjJCSstYsrz+CmrASh+1nBipAxf4EGw=; b=zF7RN4SBT5AaPYvkcRxWEBEFfGONsiYgokdil4ma7L1JfMO041G9QYDmph CIv3yALs+XfArKCtUyxMdBmZ8rlgyaoxPf6cmEKCP2Fbhw/BU/UMhiu518t6 J+1AVYuY0G; Authentication-Results: sj-dkim-8; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] Handling of FIN in the reassembly queue X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org David, Pl see inline.. > For any TCP connection, in each direction there can be only > one FIN, it will never move, and there will never be any > valid data transmitted after the FIN. So, if you get into > this situation, you already have a problem, you just don't > know what the problem is. Either the previously received > out-of-sequence data is bad, or the current packet with the > FIN is bad, but you don't know which. > > As to what to do if this scenario should actually happen: If > these packets were received in sequence, the packet with the > FIN would put us into CLOSE-WAIT state. The data in the > packets with SEG.SEQ after the FIN would then be ignored, see > page 75 in RFC 793. So, it seems that the thing to do would > be to integrate the data with the FIN, and flush the > previously received data that is after the FIN. Agreed. Just to be clear, the rationale for me suggesting to drop the segment with FIN in this case is : If this is a genuine FIN, it would get retransmitted again. So you know what to do the next time, ie., So just give it a chance one time, I think this is more safer and robust but YMMV. > > > > > > >> > >> 2. FIN was already received and another one arrives pointing > >> into the middle of already queue data (or hole); > >> Ignore the FIN and integrate the data? > >> Ignore the whole segment with the bogus FIN? > >> Integrate the data, move the FIN and flush excess data? > > > > In the regular case (in-order) if the data is already > consumed by the > > application and the window has slided, TCP simply ignores the > > duplicate data. Now for data sitting in the retransmission > queue, we > > should probably do the same, I would ignore the whole segment. [ I > > know in this case FIN is extra] > > You should be consistent. Once again, I'd say integrate the > data and FIN into the resequencing queue, and flush the > excess data beyond this FIN. Well, we have already received a FIN, which means that ( going by your CLOSEWAIT state example) we don't want to accept any data beyond this as per RFC. Now we got a FIN which is way before the current sequence number, in which case I would think it makes sense to ignore it. My consistency reasons are :- - if it would have been received in-order, we would have moved to CLOSEWAIT and would have discarded the new FIN as duplicate ( the receive window already slided, app might have already the data). TCP window slides forward and in this and there is no provision for data "overwrite". > > > > > > >> > >> 3. FIN was already received and another one arrives pointing > >> beyond the previous one; > >> Ignore the FIN and integrate the data (if within > previous FIN)? > >> Ignore the whole segment with the bogus FIN? > >> Integrate the data and move the FIN? > > > > Ignore the FIN. > > Being consistent, throw away this new packet, since it is > beyond the previous FIN. Yes, when I said ignore I meant discard, sorry should have been clear. I would think it makes sense to throw away the FIN whether it is beyond or before the previous FIN, to make things consistent. YMMV. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Feb 22 13:28:45 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9881328C402; Fri, 22 Feb 2008 13:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.039 X-Spam-Level: X-Spam-Status: No, score=0.039 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbdE4QqCdavj; Fri, 22 Feb 2008 13:28:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FEC28C25A; Fri, 22 Feb 2008 13:28:41 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BF0D3A6BCE for ; Fri, 22 Feb 2008 13:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G02mkppRa-4C for ; Fri, 22 Feb 2008 13:28:39 -0800 (PST) Received: from frantic.weston.borman.com (frantic-dmz.weston.BORMAN.COM [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id 7825F3A69D7 for ; Fri, 22 Feb 2008 13:28:37 -0800 (PST) Received: from [127.0.0.1] (frantic.weston.borman.com [206.196.45.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id m1MLSF5G026529; Fri, 22 Feb 2008 15:28:17 -0600 (CST) Message-Id: From: David Borman To: Anantha Ramaiah (ananth) In-Reply-To: <0C53DCFB700D144284A584F54711EC5804BCF58E@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 22 Feb 2008 15:28:14 -0600 References: <47BE04A2.8000000@freebsd.org> <0C53DCFB700D144284A584F54711EC5804BCF302@xmb-sjc-21c.amer.cisco.com> <03D0C184-E5FB-4FA3-AE2E-1DBF9906492F@weston.borman.com> <0C53DCFB700D144284A584F54711EC5804BCF58E@xmb-sjc-21c.amer.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: tcpm@ietf.org Subject: Re: [tcpm] Handling of FIN in the reassembly queue X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Feb 22, 2008, at 1:38 PM, Anantha Ramaiah (ananth) wrote: > David, > Pl see inline.. > >> For any TCP connection, in each direction there can be only >> one FIN, it will never move, and there will never be any >> valid data transmitted after the FIN. So, if you get into >> this situation, you already have a problem, you just don't >> know what the problem is. Either the previously received >> out-of-sequence data is bad, or the current packet with the >> FIN is bad, but you don't know which. >> >> As to what to do if this scenario should actually happen: If >> these packets were received in sequence, the packet with the >> FIN would put us into CLOSE-WAIT state. The data in the >> packets with SEG.SEQ after the FIN would then be ignored, see >> page 75 in RFC 793. So, it seems that the thing to do would >> be to integrate the data with the FIN, and flush the >> previously received data that is after the FIN. > > Agreed. Just to be clear, the rationale for me suggesting to drop the > segment with FIN in this case is : > > If this is a genuine FIN, it would get retransmitted again. So you > know > what to do the next time, ie., So just give it a chance one time, I > think this is more safer and robust but YMMV. Well, now you have to remember that you previously got this FIN, so that if it shows up again out of sequence you can do something different. I don't like that additional complexity. Keep it simple. (Or are you saying just keep ignoring the out-of-sequence FIN until the holes are filled and it shows up in sequence?) >>>> 2. FIN was already received and another one arrives pointing >>>> into the middle of already queue data (or hole); >>>> Ignore the FIN and integrate the data? >>>> Ignore the whole segment with the bogus FIN? >>>> Integrate the data, move the FIN and flush excess data? >>> >>> In the regular case (in-order) if the data is already >> consumed by the >>> application and the window has slided, TCP simply ignores the >>> duplicate data. Now for data sitting in the retransmission >> queue, we >>> should probably do the same, I would ignore the whole segment. [ I >>> know in this case FIN is extra] >> >> You should be consistent. Once again, I'd say integrate the >> data and FIN into the resequencing queue, and flush the >> excess data beyond this FIN. > > Well, we have already received a FIN, which means that ( going by your > CLOSEWAIT state example) we don't want to accept any data beyond > this as > per RFC. Now we got a FIN which is way before the current sequence > number, in which case I would think it makes sense to ignore it. My > consistency reasons are :- > - if it would have been received in-order, we would have moved to > CLOSEWAIT and would have discarded the new FIN as duplicate ( the > receive window already slided, app might have already the data). TCP > window slides forward and in this and there is no provision for data > "overwrite". But we haven't processed that data & FIN yet, because they came out of order. They are to be processed in SEG.SEQ order, which means the earlier FIN is processed first (unless you received something like SEG1.SEQ=100,LEN=100,FIN and then SEG2.SEQ=150,LEN=0,FIN, in which case the later sequenced FIN would be processed first...) The bottom line is that if you have two FINs, or data beyond a FIN, the connection is screwed up and it probably isn't worth putting much effort into dealing with this scenario. Certainly it is not worth trying to optimize. Your safest bet is to go to a fallback position and toss all the suspect data. So, I'll stick with my original suggestion that all the out of sequence data after the earlier (sequence numbered) FIN be thrown away. But we should probably also throw away the earlier FIN (and any data that it arrived with). Then we've tossed all the suspect data, and the other side can retransmit what it thinks is the correct data, assuming it is able to do so. -David _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Feb 23 17:00:02 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311BB28C1E1; Sat, 23 Feb 2008 17:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AgF+xr0iT9O; Sat, 23 Feb 2008 17:00:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3303A6BD6; Sat, 23 Feb 2008 17:00:00 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68803A6B9A for ; Sat, 23 Feb 2008 16:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSbKMU+Vin5r for ; Sat, 23 Feb 2008 16:59:57 -0800 (PST) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by core3.amsl.com (Postfix) with ESMTP id 356A63A6AC5 for ; Sat, 23 Feb 2008 16:59:57 -0800 (PST) Received: (qmail 83259 invoked from network); 24 Feb 2008 00:15:23 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Feb 2008 00:15:23 -0000 Message-ID: <47C0C186.9090106@freebsd.org> Date: Sun, 24 Feb 2008 01:59:50 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: David Borman References: <47BE04A2.8000000@freebsd.org> <0C53DCFB700D144284A584F54711EC5804BCF302@xmb-sjc-21c.amer.cisco.com> <03D0C184-E5FB-4FA3-AE2E-1DBF9906492F@weston.borman.com> <0C53DCFB700D144284A584F54711EC5804BCF58E@xmb-sjc-21c.amer.cisco.com> In-Reply-To: Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] Handling of FIN in the reassembly queue X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org David Borman wrote: > > On Feb 22, 2008, at 1:38 PM, Anantha Ramaiah (ananth) wrote: David, Anantha, >> David, >> Pl see inline.. >> >>> For any TCP connection, in each direction there can be only >>> one FIN, it will never move, and there will never be any >>> valid data transmitted after the FIN. So, if you get into >>> this situation, you already have a problem, you just don't >>> know what the problem is. Either the previously received >>> out-of-sequence data is bad, or the current packet with the >>> FIN is bad, but you don't know which. >>> >>> As to what to do if this scenario should actually happen: If >>> these packets were received in sequence, the packet with the >>> FIN would put us into CLOSE-WAIT state. The data in the >>> packets with SEG.SEQ after the FIN would then be ignored, see >>> page 75 in RFC 793. So, it seems that the thing to do would >>> be to integrate the data with the FIN, and flush the >>> previously received data that is after the FIN. >> >> Agreed. Just to be clear, the rationale for me suggesting to drop the >> segment with FIN in this case is : >> >> If this is a genuine FIN, it would get retransmitted again. So you know >> what to do the next time, ie., So just give it a chance one time, I >> think this is more safer and robust but YMMV. > > Well, now you have to remember that you previously got this FIN, so that > if it shows up again out of sequence you can do something different. I > don't like that additional complexity. Keep it simple. (Or are you > saying just keep ignoring the out-of-sequence FIN until the holes are > filled and it shows up in sequence?) > > >>>>> 2. FIN was already received and another one arrives pointing >>>>> into the middle of already queue data (or hole); >>>>> Ignore the FIN and integrate the data? >>>>> Ignore the whole segment with the bogus FIN? >>>>> Integrate the data, move the FIN and flush excess data? >>>> >>>> In the regular case (in-order) if the data is already >>> consumed by the >>>> application and the window has slided, TCP simply ignores the >>>> duplicate data. Now for data sitting in the retransmission >>> queue, we >>>> should probably do the same, I would ignore the whole segment. [ I >>>> know in this case FIN is extra] >>> >>> You should be consistent. Once again, I'd say integrate the >>> data and FIN into the resequencing queue, and flush the >>> excess data beyond this FIN. >> >> Well, we have already received a FIN, which means that ( going by your >> CLOSEWAIT state example) we don't want to accept any data beyond this as >> per RFC. Now we got a FIN which is way before the current sequence >> number, in which case I would think it makes sense to ignore it. My >> consistency reasons are :- >> - if it would have been received in-order, we would have moved to >> CLOSEWAIT and would have discarded the new FIN as duplicate ( the >> receive window already slided, app might have already the data). TCP >> window slides forward and in this and there is no provision for data >> "overwrite". > > But we haven't processed that data & FIN yet, because they came out of > order. They are to be processed in SEG.SEQ order, which means the > earlier FIN is processed first (unless you received something like > SEG1.SEQ=100,LEN=100,FIN and then SEG2.SEQ=150,LEN=0,FIN, in which case > the later sequenced FIN would be processed first...) > > The bottom line is that if you have two FINs, or data beyond a FIN, the > connection is screwed up and it probably isn't worth putting much effort > into dealing with this scenario. Certainly it is not worth trying to > optimize. Your safest bet is to go to a fallback position and toss all > the suspect data. So, I'll stick with my original suggestion that all > the out of sequence data after the earlier (sequence numbered) FIN be > thrown away. But we should probably also throw away the earlier FIN > (and any data that it arrived with). Then we've tossed all the suspect > data, and the other side can retransmit what it thinks is the correct > data, assuming it is able to do so. After reading and sleeping one night over this excellent discussion I realized that we are unsafe at any speed here. We may get hit with a FIN attack just as we may get hit with a RST attack. A FIN anywhere in the window is valid and gets queued in the reassembly queue for later processing. This wrecks a TCP session by either ending it prematurely in one direction (accepting the FIN closest to left edge), or by preventing its legitimate ending (accepting only the first FIN and waiting for data that never comes). This is a serious threat. Maybe even more so than a pure RST attack with the same complexity. It is much more subtle and can cause long hangs for TCP based protocols that do not have their own keepalive ping exchange. tcpsecure doesn't even mention it. I guess nodoby thought of the reassembly and its effects yet. FIN deserves its own section as well. The solution I've come up with is to only accept a FIN when it matches the left edge (rcv_nxt) either perfectly or accompanied by data that advances rcv_nxt (the missing segment). All data beyond that point in the reassembly queue is then to be flushed. All FINs that do not fulfill this condition are to be ignored and not queued. The only remaining question then is whether to ignore the whole segment data that came with the FIN. Probably not. We can't say if this is real FIN or not and consequently we can't say whether the segment data is real or not. We however have to assume it is real because we don't have any evidence to the contrary (provided all tcp input validity checks have been done previously). This is a quite simple solution and it avoids a lot of complexity in FIN handling in the reassembly queue. If my reasoning and rationale is agreed with I can write up a FIN section for tcpsecure over the next few days. -- Andre _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Feb 23 18:00:41 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B9A3A6AE1; Sat, 23 Feb 2008 18:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-hXp9o3qyvl; Sat, 23 Feb 2008 18:00:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 819E53A68A7; Sat, 23 Feb 2008 18:00:40 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E383A6AC3 for ; Sat, 23 Feb 2008 18:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzn-1QZk3i-6 for ; Sat, 23 Feb 2008 18:00:37 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id DCCF93A6780 for ; Sat, 23 Feb 2008 18:00:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 43E4A56FB26; Sat, 23 Feb 2008 18:00:33 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15762-03; Sat, 23 Feb 2008 18:00:33 -0800 (PST) Received: from [127.0.0.1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 5F75E56FB24; Sat, 23 Feb 2008 18:00:32 -0800 (PST) Message-ID: <47C0CFC1.5090802@redback.com> Date: Sat, 23 Feb 2008 18:00:33 -0800 From: Jakob Heitz User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Andre Oppermann References: <47BE04A2.8000000@freebsd.org> <0C53DCFB700D144284A584F54711EC5804BCF302@xmb-sjc-21c.amer.cisco.com> <03D0C184-E5FB-4FA3-AE2E-1DBF9906492F@weston.borman.com> <0C53DCFB700D144284A584F54711EC5804BCF58E@xmb-sjc-21c.amer.cisco.com> <47C0C186.9090106@freebsd.org> In-Reply-To: <47C0C186.9090106@freebsd.org> X-Virus-Scanned: by amavisd-new at redback.com Cc: David Borman , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] Handling of FIN in the reassembly queue X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Andre Oppermann wrote: > David Borman wrote: >> On Feb 22, 2008, at 1:38 PM, Anantha Ramaiah (ananth) wrote: > > David, Anantha, > >>> David, >>> Pl see inline.. >>> >>>> For any TCP connection, in each direction there can be only >>>> one FIN, it will never move, and there will never be any >>>> valid data transmitted after the FIN. So, if you get into >>>> this situation, you already have a problem, you just don't >>>> know what the problem is. Either the previously received >>>> out-of-sequence data is bad, or the current packet with the >>>> FIN is bad, but you don't know which. >>>> >>>> As to what to do if this scenario should actually happen: If >>>> these packets were received in sequence, the packet with the >>>> FIN would put us into CLOSE-WAIT state. The data in the >>>> packets with SEG.SEQ after the FIN would then be ignored, see >>>> page 75 in RFC 793. So, it seems that the thing to do would >>>> be to integrate the data with the FIN, and flush the >>>> previously received data that is after the FIN. >>> Agreed. Just to be clear, the rationale for me suggesting to drop the >>> segment with FIN in this case is : >>> >>> If this is a genuine FIN, it would get retransmitted again. So you know >>> what to do the next time, ie., So just give it a chance one time, I >>> think this is more safer and robust but YMMV. >> Well, now you have to remember that you previously got this FIN, so that >> if it shows up again out of sequence you can do something different. I >> don't like that additional complexity. Keep it simple. (Or are you >> saying just keep ignoring the out-of-sequence FIN until the holes are >> filled and it shows up in sequence?) >> >> >>>>>> 2. FIN was already received and another one arrives pointing >>>>>> into the middle of already queue data (or hole); >>>>>> Ignore the FIN and integrate the data? >>>>>> Ignore the whole segment with the bogus FIN? >>>>>> Integrate the data, move the FIN and flush excess data? >>>>> In the regular case (in-order) if the data is already >>>> consumed by the >>>>> application and the window has slided, TCP simply ignores the >>>>> duplicate data. Now for data sitting in the retransmission >>>> queue, we >>>>> should probably do the same, I would ignore the whole segment. [ I >>>>> know in this case FIN is extra] >>>> You should be consistent. Once again, I'd say integrate the >>>> data and FIN into the resequencing queue, and flush the >>>> excess data beyond this FIN. >>> Well, we have already received a FIN, which means that ( going by your >>> CLOSEWAIT state example) we don't want to accept any data beyond this as >>> per RFC. Now we got a FIN which is way before the current sequence >>> number, in which case I would think it makes sense to ignore it. My >>> consistency reasons are :- >>> - if it would have been received in-order, we would have moved to >>> CLOSEWAIT and would have discarded the new FIN as duplicate ( the >>> receive window already slided, app might have already the data). TCP >>> window slides forward and in this and there is no provision for data >>> "overwrite". >> But we haven't processed that data & FIN yet, because they came out of >> order. They are to be processed in SEG.SEQ order, which means the >> earlier FIN is processed first (unless you received something like >> SEG1.SEQ=100,LEN=100,FIN and then SEG2.SEQ=150,LEN=0,FIN, in which case >> the later sequenced FIN would be processed first...) >> >> The bottom line is that if you have two FINs, or data beyond a FIN, the >> connection is screwed up and it probably isn't worth putting much effort >> into dealing with this scenario. Certainly it is not worth trying to >> optimize. Your safest bet is to go to a fallback position and toss all >> the suspect data. So, I'll stick with my original suggestion that all >> the out of sequence data after the earlier (sequence numbered) FIN be >> thrown away. But we should probably also throw away the earlier FIN >> (and any data that it arrived with). Then we've tossed all the suspect >> data, and the other side can retransmit what it thinks is the correct >> data, assuming it is able to do so. > > After reading and sleeping one night over this excellent discussion I realized > that we are unsafe at any speed here. > > We may get hit with a FIN attack just as we may get hit with a RST attack. > A FIN anywhere in the window is valid and gets queued in the reassembly > queue for later processing. This wrecks a TCP session by either ending > it prematurely in one direction (accepting the FIN closest to left edge), > or by preventing its legitimate ending (accepting only the first FIN and > waiting for data that never comes). This is a serious threat. Maybe even > more so than a pure RST attack with the same complexity. It is much more > subtle and can cause long hangs for TCP based protocols that do not have > their own keepalive ping exchange. tcpsecure doesn't even mention it. > I guess nodoby thought of the reassembly and its effects yet. FIN deserves > its own section as well. > > The solution I've come up with is to only accept a FIN when it matches the > left edge (rcv_nxt) either perfectly or accompanied by data that advances > rcv_nxt (the missing segment). All data beyond that point in the reassembly > queue is then to be flushed. All FINs that do not fulfill this condition are > to be ignored and not queued. The only remaining question then is whether to > ignore the whole segment data that came with the FIN. Probably not. We can't > say if this is real FIN or not and consequently we can't say whether the > segment data is real or not. We however have to assume it is real because > we don't have any evidence to the contrary (provided all tcp input validity > checks have been done previously). This is a quite simple solution and it > avoids a lot of complexity in FIN handling in the reassembly queue. > > If my reasoning and rationale is agreed with I can write up a FIN section > for tcpsecure over the next few days. > You are free to drop any received data (including FIN) that you have not yet acknowledged. The peer will retransmit. I suggest you drop any segment that contains a suspicious FIN, and I stress drop the whole segment. After all, if the FIN is suspicious, it will make the rest of the segment suspicious too. I would call a FIN suspicious if the resequencing queue contains any data (or another FIN) with a higher sequence number. I would then drop all of this data higher in the resequencing queue as well. All data in the resequencing queue has not been acknowledged (even if it's SACKed) and the peer will retransmit. -- Jakob Heitz. _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Feb 23 21:48:28 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7353A6B9F; Sat, 23 Feb 2008 21:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-1.611, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff4VGrihTF1l; Sat, 23 Feb 2008 21:48:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62113A69F9; Sat, 23 Feb 2008 21:48:26 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B93503A6850 for ; Sat, 23 Feb 2008 21:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbX-TZzP05ST for ; Sat, 23 Feb 2008 21:48:24 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BEB2E3A6C68 for ; Sat, 23 Feb 2008 21:48:14 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 23 Feb 2008 21:48:10 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1O5mAxA004151; Sat, 23 Feb 2008 21:48:10 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1O5m6R4024135; Sun, 24 Feb 2008 05:48:08 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Feb 2008 21:48:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 23 Feb 2008 21:47:44 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5804BCF860@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <47C0C186.9090106@freebsd.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Handling of FIN in the reassembly queue Thread-Index: Ach2gJBsYUd4u8yHR42vYfj0o1sPOwAFbgPA References: <47BE04A2.8000000@freebsd.org> <0C53DCFB700D144284A584F54711EC5804BCF302@xmb-sjc-21c.amer.cisco.com> <03D0C184-E5FB-4FA3-AE2E-1DBF9906492F@weston.borman.com> <0C53DCFB700D144284A584F54711EC5804BCF58E@xmb-sjc-21c.amer.cisco.com> <47C0C186.9090106@freebsd.org> From: "Anantha Ramaiah (ananth)" To: "Andre Oppermann" , "David Borman" X-OriginalArrivalTime: 24 Feb 2008 05:48:04.0299 (UTC) FILETIME=[D2C861B0:01C876A8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3119; t=1203832090; x=1204696090; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20Handling=20of=20FIN=20in=20the =20reassembly=20queue |Sender:=20; bh=8D1dK8aRqUcS20M+IcFiDDbbm03RcOVgG68VvEUiH0E=; b=Doqo6oUuAKRok89OuQ4KoUb5qume/ll5J8hAU+MAtEdUanmwi6bTbnXZTj vWWl7MgvLWbOrgI1dodu9pu2G1DQwtDNGuro5NN2d6PDDj/IkN8Sa15ZpQhi OnRSNb8/LZkxq8QxPl1tHJxO34T88KC9qBX+60ZHpWek1haCQxds4=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] Handling of FIN in the reassembly queue X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Andre, > > After reading and sleeping one night over this excellent > discussion I realized that we are unsafe at any speed here. > > We may get hit with a FIN attack just as we may get hit with > a RST attack. > A FIN anywhere in the window is valid and gets queued in the > reassembly queue for later processing. This wrecks a TCP > session by either ending it prematurely in one direction > (accepting the FIN closest to left edge), or by preventing > its legitimate ending (accepting only the first FIN and > waiting for data that never comes). This is a serious > threat. Maybe even more so than a pure RST attack with the > same complexity. It is much more subtle and can cause long > hangs for TCP based protocols that do not have their own > keepalive ping exchange. tcpsecure doesn't even mention it. > I guess nodoby thought of the reassembly and its effects yet. > FIN deserves its own section as well. Actually as part of the data mitigation tcp-secure does mention FIN attack, in the sense the strict ACK sequence number checking would strengthen robustness in dealing with malicious data segments and that includes FIN segments. FWIW, Murali and I are in the process of writing a document which outlines the re-assembly (re-sequencing to use the correct terminology) queue related DOS scenarios. We didn't consider FIN attacks as such.. > > The solution I've come up with is to only accept a FIN when > it matches the left edge (rcv_nxt) either perfectly or > accompanied by data that advances rcv_nxt (the missing > segment). All data beyond that point in the reassembly queue > is then to be flushed. All FINs that do not fulfill this > condition are to be ignored and not queued. The only > remaining question then is whether to ignore the whole > segment data that came with the FIN. Probably not. We can't > say if this is real FIN or not and consequently we can't say > whether the segment data is real or not. We however have to > assume it is real because we don't have any evidence to the > contrary (provided all tcp input validity checks have been > done previously). This is a quite simple solution and it > avoids a lot of complexity in FIN handling in the reassembly queue. > If my reasoning and rationale is agreed with I can write up a > FIN section for tcpsecure over the next few days. I would think having a separate document to address this instead of putting stuff in tcp-secure since : - the one which you are talking is about formulating the rules about what to do with out-of-order FIN. It makes sense for a descriptive document (like your original email) and outline pros and cons of each method. - tcpsecure has a section on data mitigation but it is about correcting the liberal ACK checking allowed by 793 and it applies to ANY data segment and also FIN. - tcpsecure has come a long way, and adding more stuff at this point sounds uneasy to me. But that's just me.. My few cents, -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Feb 25 09:32:07 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152CA28C7BA; Mon, 25 Feb 2008 09:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.021 X-Spam-Level: X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMacmM9h9j-a; Mon, 25 Feb 2008 09:32:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26C928C7B3; Mon, 25 Feb 2008 09:26:54 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A84E28C8B4 for ; Mon, 25 Feb 2008 09:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Rs50gVkfR9z for ; Mon, 25 Feb 2008 09:26:52 -0800 (PST) Received: from frantic.weston.borman.com (frantic-dmz.weston.BORMAN.COM [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id 238D828C8B8 for ; Mon, 25 Feb 2008 09:22:46 -0800 (PST) Received: from [127.0.0.1] (frantic.weston.borman.com [206.196.45.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id m1PHMQ5G001596; Mon, 25 Feb 2008 11:22:27 -0600 (CST) Message-Id: <2C572004-A053-4109-879E-2BA23DDDB12C@weston.borman.com> From: David Borman To: tcpm@ietf.org, Andre Oppermann In-Reply-To: <47C0CFC1.5090802@redback.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 25 Feb 2008 11:22:26 -0600 References: <47BE04A2.8000000@freebsd.org> <0C53DCFB700D144284A584F54711EC5804BCF302@xmb-sjc-21c.amer.cisco.com> <03D0C184-E5FB-4FA3-AE2E-1DBF9906492F@weston.borman.com> <0C53DCFB700D144284A584F54711EC5804BCF58E@xmb-sjc-21c.amer.cisco.com> <47C0C186.9090106@freebsd.org> <47C0CFC1.5090802@redback.com> X-Mailer: Apple Mail (2.919.2) Cc: "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] Handling of FIN in the reassembly queue X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org My comments are at the bottom. -David Borman On Feb 23, 2008, at 8:00 PM, Jakob Heitz wrote: > > > Andre Oppermann wrote: >> David Borman wrote: >>> On Feb 22, 2008, at 1:38 PM, Anantha Ramaiah (ananth) wrote: >> >> David, Anantha, >> >>>> David, >>>> Pl see inline.. >>>> >>>>> For any TCP connection, in each direction there can be only >>>>> one FIN, it will never move, and there will never be any >>>>> valid data transmitted after the FIN. So, if you get into >>>>> this situation, you already have a problem, you just don't >>>>> know what the problem is. Either the previously received >>>>> out-of-sequence data is bad, or the current packet with the >>>>> FIN is bad, but you don't know which. >>>>> >>>>> As to what to do if this scenario should actually happen: If >>>>> these packets were received in sequence, the packet with the >>>>> FIN would put us into CLOSE-WAIT state. The data in the >>>>> packets with SEG.SEQ after the FIN would then be ignored, see >>>>> page 75 in RFC 793. So, it seems that the thing to do would >>>>> be to integrate the data with the FIN, and flush the >>>>> previously received data that is after the FIN. >>>> Agreed. Just to be clear, the rationale for me suggesting to drop >>>> the >>>> segment with FIN in this case is : >>>> >>>> If this is a genuine FIN, it would get retransmitted again. So >>>> you know >>>> what to do the next time, ie., So just give it a chance one time, I >>>> think this is more safer and robust but YMMV. >>> Well, now you have to remember that you previously got this FIN, >>> so that >>> if it shows up again out of sequence you can do something >>> different. I >>> don't like that additional complexity. Keep it simple. (Or are you >>> saying just keep ignoring the out-of-sequence FIN until the holes >>> are >>> filled and it shows up in sequence?) >>> >>> >>>>>>> 2. FIN was already received and another one arrives pointing >>>>>>> into the middle of already queue data (or hole); >>>>>>> Ignore the FIN and integrate the data? >>>>>>> Ignore the whole segment with the bogus FIN? >>>>>>> Integrate the data, move the FIN and flush excess data? >>>>>> In the regular case (in-order) if the data is already >>>>> consumed by the >>>>>> application and the window has slided, TCP simply ignores the >>>>>> duplicate data. Now for data sitting in the retransmission >>>>> queue, we >>>>>> should probably do the same, I would ignore the whole segment. >>>>>> [ I >>>>>> know in this case FIN is extra] >>>>> You should be consistent. Once again, I'd say integrate the >>>>> data and FIN into the resequencing queue, and flush the >>>>> excess data beyond this FIN. >>>> Well, we have already received a FIN, which means that ( going by >>>> your >>>> CLOSEWAIT state example) we don't want to accept any data beyond >>>> this as >>>> per RFC. Now we got a FIN which is way before the current sequence >>>> number, in which case I would think it makes sense to ignore it. My >>>> consistency reasons are :- >>>> - if it would have been received in-order, we would have moved to >>>> CLOSEWAIT and would have discarded the new FIN as duplicate ( the >>>> receive window already slided, app might have already the data). >>>> TCP >>>> window slides forward and in this and there is no provision for >>>> data >>>> "overwrite". >>> But we haven't processed that data & FIN yet, because they came >>> out of >>> order. They are to be processed in SEG.SEQ order, which means the >>> earlier FIN is processed first (unless you received something like >>> SEG1.SEQ=100,LEN=100,FIN and then SEG2.SEQ=150,LEN=0,FIN, in which >>> case >>> the later sequenced FIN would be processed first...) >>> >>> The bottom line is that if you have two FINs, or data beyond a >>> FIN, the >>> connection is screwed up and it probably isn't worth putting much >>> effort >>> into dealing with this scenario. Certainly it is not worth trying >>> to >>> optimize. Your safest bet is to go to a fallback position and >>> toss all >>> the suspect data. So, I'll stick with my original suggestion that >>> all >>> the out of sequence data after the earlier (sequence numbered) FIN >>> be >>> thrown away. But we should probably also throw away the earlier FIN >>> (and any data that it arrived with). Then we've tossed all the >>> suspect >>> data, and the other side can retransmit what it thinks is the >>> correct >>> data, assuming it is able to do so. >> >> After reading and sleeping one night over this excellent discussion >> I realized >> that we are unsafe at any speed here. >> >> We may get hit with a FIN attack just as we may get hit with a RST >> attack. >> A FIN anywhere in the window is valid and gets queued in the >> reassembly >> queue for later processing. This wrecks a TCP session by either >> ending >> it prematurely in one direction (accepting the FIN closest to left >> edge), >> or by preventing its legitimate ending (accepting only the first >> FIN and >> waiting for data that never comes). This is a serious threat. >> Maybe even >> more so than a pure RST attack with the same complexity. It is >> much more >> subtle and can cause long hangs for TCP based protocols that do not >> have >> their own keepalive ping exchange. tcpsecure doesn't even mention >> it. >> I guess nodoby thought of the reassembly and its effects yet. FIN >> deserves >> its own section as well. >> >> The solution I've come up with is to only accept a FIN when it >> matches the >> left edge (rcv_nxt) either perfectly or accompanied by data that >> advances >> rcv_nxt (the missing segment). All data beyond that point in the >> reassembly >> queue is then to be flushed. All FINs that do not fulfill this >> condition are >> to be ignored and not queued. The only remaining question then is >> whether to >> ignore the whole segment data that came with the FIN. Probably >> not. We can't >> say if this is real FIN or not and consequently we can't say >> whether the >> segment data is real or not. We however have to assume it is real >> because >> we don't have any evidence to the contrary (provided all tcp input >> validity >> checks have been done previously). This is a quite simple solution >> and it >> avoids a lot of complexity in FIN handling in the reassembly queue. >> >> If my reasoning and rationale is agreed with I can write up a FIN >> section >> for tcpsecure over the next few days. >> > > You are free to drop any received data (including FIN) that you > have not yet acknowledged. The peer will retransmit. I suggest you > drop any segment that contains a suspicious FIN, and I stress drop > the whole segment. After all, if the FIN is suspicious, it will make > the rest of the segment suspicious too. I would call a FIN suspicious > if the resequencing queue contains any data (or another FIN) with a > higher sequence number. I would then drop all of this data higher in > the resequencing queue as well. All data in the resequencing queue > has not been acknowledged (even if it's SACKed) and the peer will > retransmit. I agree with Jakob. If you don't trust the FIN, you shouldn't trust the data, either. Accept and queue any out-of-sequence FINs, and only worry about them if you get 1) a second FIN that doesn't match the first, 2) a FIN before data that you've already received, or 3) data after the FIN. At that point, flush all the data from the first FIN to the end, including any data that came with that FIN. Otherwise, if you reject all FINs until they show up right at the end of the connection, you are placing a penalty on all well-behaved TCP connections that just happen to have a packet loss or reordering of data packets just prior to the FIN. Optimize for the common case, not the exception. And keep in mind that there are perfectly legitimate reasons to get overlapping data (including the FIN), especially when retransmitting, but I won't go into the details here. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Feb 26 14:40:43 2008 Return-Path: X-Original-To: ietfarch-tcpm-archive@core3.amsl.com Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7187628C517; Tue, 26 Feb 2008 14:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NmAbH5k4BP8; Tue, 26 Feb 2008 14:40:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CC8D28C372; Tue, 26 Feb 2008 14:40:42 -0800 (PST) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358D628C243 for ; Tue, 26 Feb 2008 14:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq-xHtV4z1Wp for ; Tue, 26 Feb 2008 14:40:40 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 514CC28C372 for ; Tue, 26 Feb 2008 14:40:40 -0800 (PST) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m1QMe4Z7005114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 26 Feb 2008 14:40:05 -0800 (PST) Received: (from faber@localhost) by zod.isi.edu (8.14.2/8.14.2/Submit) id m1QMe4TQ039273 for tcpm@ietf.org; Tue, 26 Feb 2008 14:40:04 -0800 (PST) (envelope-from faber) Date: Tue, 26 Feb 2008 14:40:04 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20080226224004.GC82182@zod.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu Subject: [tcpm] TCPM agenda items for Philly X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0365406813==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0365406813== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kVXhAStRUZ/+rrGn" Content-Disposition: inline --kVXhAStRUZ/+rrGn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable There's a very minimal TCPM agenda up for the coming meeting in Philly, but we need to gather a real one pretty quickly. If you'd like to be on the agenda, please send Mark and I a message. You can send it to our individual addresses or tcpm-chairs@tools.ietf.org Thanks. --=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 --kVXhAStRUZ/+rrGn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHxJVDaUz3f+Zf+XsRAkMNAKCuq37I7nHMG5vbYnv6qrEe+BWocgCdFiVb bEXZqZ0HvK180DLKxwfcdK8= =rlqY -----END PGP SIGNATURE----- --kVXhAStRUZ/+rrGn-- --===============0365406813== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org http://www.ietf.org/mailman/listinfo/tcpm --===============0365406813==--