From toby.moncaster@bt.com Tue Sep 1 04:11:12 2009 Return-Path: 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 B53953A6C93 for ; Tue, 1 Sep 2009 04:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 3VgsKi4eWBzx for ; Tue, 1 Sep 2009 04:11:11 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 7820A3A6B14 for ; Tue, 1 Sep 2009 04:11:11 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 12:11:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Sep 2009 12:11:19 +0100 Message-ID: In-Reply-To: <4A9CB254.7050802@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcp-security: Request for feedback on the outline of the document Thread-Index: Acoqxd8bqFMulLRwSqCkbhczAy7+TwALSQcw References: <200908262238.AAA06336@TR-Sys.de><4A9624CB.6040203@isi.edu> <4A9894C3.4020300@gont.com.ar><4A9AB5C2.4090209@isi.edu> <4A9CB254.7050802@gont.com.ar> From: To: , X-OriginalArrivalTime: 01 Sep 2009 11:11:20.0513 (UTC) FILETIME=[EF170310:01CA2AF4] Cc: ah@tr-sys.de, tcpm@ietf.org Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 11:11:12 -0000 I think there needs to be some form of hum relating to this. There seems to be a relatively small number of people expressing relatively strong opinions on this document that are clearly incompatible. One key thing, regardless of how we actually decide to split the work, Fernando's current ToC is too long... 3 pages of ToC is excessive. I think the sections aren't grouped at a high enough level (e.g. connection establishment and tear-down could be in one section on connection management, buffer management and re-assembly could probably be grouped into memory management, etc). This is separate to any consideration as to whether you should be presenting things in a completely different order... I think Joe actually raised this before... 1 inline comment as well > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Fernando Gont > Sent: 01 September 2009 06:34 > To: Joe Touch > Cc: Alfred ?; tcpm@ietf.org > Subject: Re: [tcpm] tcp-security: Request for feedback on the outline > of the document >=20 > Hello, Joe, >=20 > >> The latter is true, but the document is still meant to target > >> implementers. If you spread the advice on a per-attack basis, or on > a > >> protocol-weaknesses vs. implementer's-choice-weaknesses, you're > >> basically spreading the advice about a single protocol field or > option > >> among multiple sections. > > > > Maybe - some fields are susceptible to only a small set of attacks > that > > may be related. >=20 > That's the exception, not the rule. >=20 >=20 > > However, we'd also be allowing (if not encouraging) use > > of protections as appropriate, rather than encouraging everyone to > > implement every protection - >=20 > Joe, this is about hardening a TCP implementation, not about mitigating > some vulnerabilities while leaving the door open to the rest of them. >=20 >=20 >=20 > > An implementer needs to know when they're playing inside a box the > spec > > created (#1), playing around in ways that could affect the protocol > now > > or in the future (#2), or just need to apply known algorithms rather > > than modify the protocol. >=20 > Exactly. That's why the document does not simply provide the "what to > do", but also provides a discussion of the mitigations, etc. >=20 > But the document is still aimed at implementers. A bunch of > implementers > have already reviewed the document, and found the current outline > useful. >=20 >=20 >=20 > > The point is that in the outline proposed in ID-0, there are multiple > > top-level sections where these issues are discussed. The idea that > "an > > implementer wants to find things in one place" is fine, but IMO the > > outline I proposed may to a mode useful job of aggregating this > > information than ID-0. >=20 > Again: the goal of this document is helping TCP implementers harden > their TCPs. And for that target, having everything about a protocol > field in a single place is the only document outline that does not get > in the middle of the developer and the implementation. If you spread > the > advice among lots of places, this is what will happen: some mitigations > will be missed. So if this is entirely aimed at implementers shouldn't that be explicitly stated in the title? I appreciate that in theory BCP is meant to imply implementation guidance but this might be more appropriately titled something like "Implementers guidelines for mitigating TCP security threats" or "Guidance on secure implementation of TCP" >=20 > I'm not saying the outline you propose is "wrong". I'm saying it's not > the best approach for the public this document targets. That doesn't > mean that an alternative outline can be included in an appendix. -- > that > may be useful. >=20 > Thanks! >=20 > Kind regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From wesley.m.eddy@nasa.gov Tue Sep 1 06:14:23 2009 Return-Path: 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 CAE073A6840 for ; Tue, 1 Sep 2009 06:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 6GKuyTtCxYzh for ; Tue, 1 Sep 2009 06:14:23 -0700 (PDT) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id EC6713A6820 for ; Tue, 1 Sep 2009 06:14:22 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 49F182D8190; Tue, 1 Sep 2009 08:14:36 -0500 (CDT) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n81DEUU0016034; Tue, 1 Sep 2009 08:14:33 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Tue, 1 Sep 2009 08:14:30 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: "toby.moncaster@bt.com" , "fernando@gont.com.ar" , "touch@ISI.EDU" Date: Tue, 1 Sep 2009 08:14:28 -0500 Thread-Topic: [tcpm] tcp-security: Request for feedback on the outline of the document Thread-Index: Acoqxd8bqFMulLRwSqCkbhczAy7+TwALSQcwAASmEHA= Message-ID: References: <200908262238.AAA06336@TR-Sys.de><4A9624CB.6040203@isi.edu> <4A9894C3.4020300@gont.com.ar><4A9AB5C2.4090209@isi.edu> <4A9CB254.7050802@gont.com.ar> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-09-01_10:2009-08-26, 2009-09-01, 2009-09-01 signatures=0 Cc: "ah@tr-sys.de" , "tcpm@ietf.org" Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 13:14:23 -0000 >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >toby.moncaster@bt.com >Sent: Tuesday, September 01, 2009 7:11 AM > >> Again: the goal of this document is helping TCP implementers harden >> their TCPs. And for that target, having everything about a protocol >> field in a single place is the only document outline that does not get >> in the middle of the developer and the implementation. If you spread >> the >> advice among lots of places, this is what will happen: some >mitigations >> will be missed. > >So if this is entirely aimed at implementers shouldn't that be >explicitly stated in the title? I appreciate that in theory BCP is meant >to imply implementation guidance but this might be more appropriately >titled something like "Implementers guidelines for mitigating TCP >security threats" or "Guidance on secure implementation of TCP" > This is a great point; in fact, the milestone we put on the TCPM charter says: "Submit document on security hardening of TCP implementations to the IESG for publication as a Best Current Practices RFC" so the titles you suggested, or something else that indicates "Secure TCP Implementation" would probably be more appropriate than the "Security Assessment ..." title it currently has. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From fernando@gont.com.ar Tue Sep 1 08:11:07 2009 Return-Path: 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 A9DFF28C7B1 for ; Tue, 1 Sep 2009 08:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 4peS0fV8n+vV for ; Tue, 1 Sep 2009 08:11:07 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 4E9A83A7076 for ; Tue, 1 Sep 2009 08:09:03 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 0970A6B660D; Tue, 1 Sep 2009 12:09:10 -0300 (ART) Received: from [192.168.1.107] (host133.190-139-184.telecom.net.ar [190.139.184.133]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n81F8wO4026136; Tue, 1 Sep 2009 12:09:00 -0300 Message-ID: <4A9D390E.4060403@gont.com.ar> Date: Tue, 01 Sep 2009 12:09:02 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" References: <200908262238.AAA06336@TR-Sys.de><4A9624CB.6040203@isi.edu> <4A9894C3.4020300@gont.com.ar><4A9AB5C2.4090209@isi.edu> <4A9CB254.7050802@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 01 Sep 2009 12:09:09 -0300 (ART) Cc: "ah@tr-sys.de" , "tcpm@ietf.org" , "touch@ISI.EDU" Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 15:11:07 -0000 Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > This is a great point; in fact, the milestone we put on the TCPM charter > says: > > "Submit document on security hardening of TCP implementations to the IESG > for publication as a Best Current Practices RFC" > > so the titles you suggested, or something else that indicates "Secure TCP > Implementation" would probably be more appropriate than the "Security > Assessment ..." title it currently has. FWIW, I have no problem with the proposed title change to, e.g., "Guidance on secure implementation of the Transmission Control Protocol (TCP)". Will start a new thread about the document title... Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From david.borman@windriver.com Tue Sep 1 08:12:48 2009 Return-Path: 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 16E6F3A702D for ; Tue, 1 Sep 2009 08:12:48 -0700 (PDT) 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8KF0DoF0t6Q for ; Tue, 1 Sep 2009 08:12:46 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id CA10D28C76A for ; Tue, 1 Sep 2009 08:12:10 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id n81FC6nh003431 for ; Tue, 1 Sep 2009 08:12:06 -0700 (PDT) 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); Tue, 1 Sep 2009 08:12:01 -0700 Received: from [172.25.44.8] ([172.25.44.8]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Sep 2009 08:12:05 -0700 From: David Borman Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Tue, 1 Sep 2009 10:12:04 -0500 Message-Id: To: tcpm Extensions WG Mime-Version: 1.0 (Apple Message framework v1075.2) X-Mailer: Apple Mail (2.1075.2) X-OriginalArrivalTime: 01 Sep 2009 15:12:05.0681 (UTC) FILETIME=[9114BA10:01CA2B16] Subject: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 15:12:48 -0000 Wes and I are starting a Working Group Last Call for the ICMP Attacks document: http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-06.txt This document is intended to be published as Informational. The WGLC will end on Sep. 15, 2009. Please send any comments to list before then. -David Borman & Wes Eddy, TCPM WG chairs From touch@ISI.EDU Tue Sep 1 08:13:39 2009 Return-Path: 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 D29293A6403 for ; Tue, 1 Sep 2009 08:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 8naJf-LSoydI for ; Tue, 1 Sep 2009 08:13:38 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E16843A6B15 for ; Tue, 1 Sep 2009 08:13:38 -0700 (PDT) Received: from [192.168.1.47] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n81FDGh3001342; Tue, 1 Sep 2009 08:13:18 -0700 (PDT) Message-ID: <4A9D3A0C.6050602@isi.edu> Date: Tue, 01 Sep 2009 08:13:16 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <200908262238.AAA06336@TR-Sys.de> <4A9624CB.6040203@isi.edu> <4A9894C3.4020300@gont.com.ar> <4A9AB5C2.4090209@isi.edu> <4A9CB254.7050802@gont.com.ar> In-Reply-To: <4A9CB254.7050802@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Alfred ? , tcpm@ietf.org Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 15:13:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: ... > I'm not saying the outline you propose is "wrong". I'm saying it's not > the best approach for the public this document targets. That doesn't > mean that an alternative outline can be included in an appendix. -- that > may be useful. The public already has the doc you already wrote. This discussion is about what the WG should produce. There is no current list of threats in TCP. If this doc is intended primarily at implementers, then we should consider splitting out the doc that talks about the threats as a separate doc. As to the current organization, I've proposed one that's hierarchical and has things in predictable places. The current outline is mostly flat, and has things in multiple places. Do you have a proposal to organize the current outline into an alternate hierarchical structure? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqdOgwACgkQE5f5cImnZrvydgCfQ1ygWZiRMLIJnMjGIK3Qn7m6 Rh4An1wcPGxbRxBj9SaLlwULcRlnyIdr =kI47 -----END PGP SIGNATURE----- From wesley.m.eddy@nasa.gov Tue Sep 1 12:28:23 2009 Return-Path: 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 EC9FD3A6A42 for ; Tue, 1 Sep 2009 12:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 UcCtCD6smbeW for ; Tue, 1 Sep 2009 12:28:23 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 23FA03A68A5 for ; Tue, 1 Sep 2009 12:28:23 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 7B797260357 for ; Tue, 1 Sep 2009 14:27:44 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n81JRinW015174 for ; Tue, 1 Sep 2009 14:27:44 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Tue, 1 Sep 2009 14:27:44 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: "tcpm@ietf.org" Date: Tue, 1 Sep 2009 14:27:43 -0500 Thread-Topic: poll for adoption of long connectivity disruptions draft Thread-Index: AcorOkcQoJjUMfz3QWuTzmBHEhBvFw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-09-01_14:2009-08-26, 2009-09-01, 2009-09-01 signatures=0 Subject: [tcpm] poll for adoption of long connectivity disruptions draft 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:28:24 -0000 Hello, the authors of the "Long Connectivity Disruptions" draft: http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt have given a couple presentations to the WG now and asked if it could be considered as an item for the WG for Experimental. If I'm not mistaken, there has been some positive feedback on the most recent incarnation, though not a lot, and not really any negative feedback that I could see. As chairs, David and I are asking the WG to voice whether we should: A) adopt this as a WG item for Experimental B) NOT adopt this as a WG item C) wait to decide (not ready) Please let us know what you think. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From wesley.m.eddy@nasa.gov Tue Sep 1 12:30:18 2009 Return-Path: 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 B6AAD28C95D for ; Tue, 1 Sep 2009 12:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 8YkhtcIUaebO for ; Tue, 1 Sep 2009 12:30:17 -0700 (PDT) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id E166728C877 for ; Tue, 1 Sep 2009 12:30:17 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 631FD2D81E6 for ; Tue, 1 Sep 2009 14:30:06 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n81JU6ET018612 for ; Tue, 1 Sep 2009 14:30:06 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Tue, 1 Sep 2009 14:30:06 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: "tcpm@ietf.org" Date: Tue, 1 Sep 2009 14:30:05 -0500 Thread-Topic: poll for adoption of SACK recovery entry drafty Thread-Index: AcorOpvGbikE1nfUR9yr7N3CeSSLzg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-09-01_14:2009-08-26, 2009-09-01, 2009-09-01 signatures=0 Subject: [tcpm] poll for adoption of SACK recovery entry drafty 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:30:18 -0000 Hello, the authors of the SACK Recovery Entry draft: http://tools.ietf.org/html/draft-jarvinen-tcpm-sack-recovery-entry-01 have given a couple presentations to the WG now and asked if it could be considered as an item for the WG for Proposed Standard (at least I'm assuming PS because the I-D says "Intended Status: Standards Track" ...). If I'm not mistaken, there has been some positive feedback on the most recent incarnation, though not a lot, and not really any negative feedback that I could see. As chairs, David and I are asking the WG to voice whether we should: A) adopt this as a WG item for Proposed Standard B) NOT adopt this as a WG item C) wait to decide (not ready) Please let us know what you think. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From wesley.m.eddy@nasa.gov Tue Sep 1 13:02:01 2009 Return-Path: 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 4D4133A68A6 for ; Tue, 1 Sep 2009 13:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 EOFR+KepLUNv for ; Tue, 1 Sep 2009 13:02:00 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 55D6B3A6AAD for ; Tue, 1 Sep 2009 13:02:00 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id E2D2FA81AA for ; Tue, 1 Sep 2009 14:43:09 -0500 (CDT) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n81Jh9GX008735 for ; Tue, 1 Sep 2009 14:43:09 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Tue, 1 Sep 2009 14:43:09 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: "tcpm@ietf.org" Date: Tue, 1 Sep 2009 14:43:08 -0500 Thread-Topic: WG status update 9/1/09 Thread-Index: AcorPG6ujRXzSOkQRBW24A+WBKLOtA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-09-01_14:2009-08-26, 2009-09-01, 2009-09-01 signatures=0 Subject: [tcpm] WG status update 9/1/09 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 20:02:01 -0000 Since David and I got good feedback that the WG status update 2 weeks ago was helpful, and it uncovered a couple of things, we'll try to continue it for awhile, hopefully at close to 2 week intervals. If that's too noisy, please let us know :). Here's our snapshot as of today: WG Items =3D=3D=3D=3D=3D=3D=3D=3D TCP Authentication Option http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-05.txt Milestone Target: Proposed Standard in April 2009 Action: Needs update parallel to AO-Crypto draft and then WGLC (action with= J. Touch) TCP Authentication Option Crypto http://www.ietf.org/internet-drafts/draft-lebovitz-ietf-tcpm-tcp-ao-crypto-= 02.txt Milestone Target: Proposed Standard with AO spec Action: Needs update parallel to AO draft and then WGLC (action with G. Leb= ovitz) ICMP Attacks http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-06.txt Milestone Target: Informational in July 2009 Action: WGLC started 9/1, to end 9/15 Early-Retransmit http://tools.ietf.org/wg/tcpm/draft-ietf-tcpm-early-rexmt/ Milestone Target: Experimental in July 2009 Action: WGLC finished; authors to update, chairs to forward (action with M.= Allman) 1323bis http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt Milestone Target: Proposed Standard in July 2009 Action: Revise & WGLC (action with D. Borman) MSS Option http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt Milestone Target: Proposed Standard in July 2009 Action: WGLC started 8/19, to end 9/8 (extended), being updated based on se= veral of the comments (action with D. Borman) Urgent Pointer http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-00.txt Milestone Target: Proposed Standard in January 2010 Action: Continue WG reviews TCP Security http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-00.txt Milestone Target: BCP in August 2010 Action: 00-draft / outline is under active discussion Other Proposals =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Persist http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt Action: WG Review Timestamps http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt Action: ??? Parameter Tuning (no I-D yet) Action: continue good discussion on mailing list presentation given in Stockholm Long Connectivity Disruptions http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt Action: need WG to read/discuss 2x presentations (SFO and Stockholm) have been given some support expressed chairs have polled WG for interest ... awaiting response SACK Entry http://tools.ietf.org/html/draft-jarvinen-tcpm-sack-recovery-entry-01 Action: need WG to read/discuss presentations in Stockholm and SFO given some support expressed chairs have polled WG for interest ... awaiting response TCP Option for Transparent Middlebox Discovery http://www.ietf.org/internet-drafts/draft-knutsen-tcpm-middlebox-discovery-= 00.txt Action: Needs WG review / discussion some discussion on mailing list clarifies purpose & intent NewReno Modification http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-01.t= xt Action: need WG to read/discuss presentation given, but WG list not yet polled for adoption --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From eblanton@cs.ohiou.edu Tue Sep 1 17:14:10 2009 Return-Path: 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 B03BE3A6BA4 for ; Tue, 1 Sep 2009 17:14:10 -0700 (PDT) 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=[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 9Bcur-kvQhAz for ; Tue, 1 Sep 2009 17:14:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C23423A6954 for ; Tue, 1 Sep 2009 17:14:09 -0700 (PDT) Received: from [99.52.196.7] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MidUQ-000Pn6-LW; Wed, 02 Sep 2009 00:14:22 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id D91273BC9B; Tue, 1 Sep 2009 20:14:17 -0400 (EDT) Date: Tue, 1 Sep 2009 20:14:17 -0400 From: Ethan Blanton To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" Message-ID: <20090902001417.GA25655@colt> Mail-Followup-To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" , "tcpm@ietf.org" References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of SACK recovery entry drafty 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 00:14:10 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Eddy, Wesley M. (GRC-MS00)[Verizon] spake unto us the following wisdom: > Hello, the authors of the SACK Recovery Entry draft: > http://tools.ietf.org/html/draft-jarvinen-tcpm-sack-recovery-entry-01 > have given a couple presentations to the WG now and asked if it > could be considered as an item for the WG for Proposed Standard (at > least I'm assuming PS because the I-D says "Intended Status: Standards > Track" ...). If I'm not mistaken, there has been some positive feedback > on the most recent incarnation, though not a lot, and not really any > negative feedback that I could see. >=20 > As chairs, David and I are asking the WG to voice whether we should: >=20 > A) adopt this as a WG item for Proposed Standard > B) NOT adopt this as a WG item > C) wait to decide (not ready) I believe that this draft contains some good ideas, and codifies a number of things that I think are generally a good idea. Specifically, using IsLost from RFC 3517 as an indicator that loss recovery can be entered. I believe that have not read the Aug 5 version of this draft, but a previous version that I read required some editorial work, and I had a few technical nits. WG feedback on this draft should be able to correct these minor issues. (I will provide my two cents, of course.) ;-) As to what status to give the draft, I leave that up to the WG. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSp242f8fixZ3H8crAQj3JAf/Wxb43N6ClTYtK/RO3sGykiNTbzGwlqfD ZQRv0GwavBckiwLkbBU4SpJ7RiD8m2UxOZB556BQkJl3JleYi7DRxrfoYH/ArQzq pZLD2CQQZYrp+RfXxSoPfnXjAZiccLgN6KYcfpzpUnNdlDczWGJK55cSeCJ3G/Mj UuTDgRTm1Sp504QJAZhr7nklarVIjaQm+4CnfCe1tbryjAvhX4SSi7twAQBJshug ErBvgGZJtlOc5W05ID9gB8xHxwStslwH4J4Vp61dJJzcUli9Pai5VkwLm6MvcQmD FdBLblVZWl5BygqCfWKRAJkx91tVswCa8GvFO86hrrG6rjSE8qYTgQ== =5qys -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From Donald.Smith@qwest.com Wed Sep 2 13:50:19 2009 Return-Path: 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 C27F728C130 for ; Wed, 2 Sep 2009 13:50:19 -0700 (PDT) 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 E60rS30bMiVC for ; Wed, 2 Sep 2009 13:50:18 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 9209628C105 for ; Wed, 2 Sep 2009 13:50:18 -0700 (PDT) Received: from sudnp796.qintra.com (sudnp796.qintra.com [151.116.2.212]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id n82KmfiA029462; Wed, 2 Sep 2009 15:48:41 -0500 (CDT) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.0/8.14.0) with ESMTP id n82Kmar5005529; Wed, 2 Sep 2009 14:48:36 -0600 (MDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Wed, 2 Sep 2009 14:48:35 -0600 From: "Smith, Donald" To: "'David Borman'" , "'tcpm Extensions WG'" Date: Wed, 2 Sep 2009 14:48:34 -0600 Thread-Topic: [tcpm] WG Last Call for ICMP Attacks Thread-Index: AcorFskRSIZDh8r5QwqfUYGf5oE7ZAAA38Kg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 20:50:19 -0000 1. ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, and is used mainly for reporting network error conditions. ICMP is part of the IP protocol suite. 2.2 Therefore, in the case of TCP, an attacker could send a forged ICMP message to the attacked system, and, as long as he is able to guess the four-tuple (i.e., Source IP Address, Source TCP port, Destination IP Address, and Destination TCP port) that identifies the communication instance to be attacked, he will be able to use ICMP to perform a variety of attacks. Forged usually implies that source ip address has been spoofed usually to c= ome from some type of trusted host. Crafted is the term generally used to mean the packets contents (not header= ) were modified. In this case there is no need to spoof the source ip address as the end hos= t has no knowledge about the routers in between them and the end host syste= m. So I recommend you change forged to crafted. 2.2 The need to be more more cautious when processing received ICMP error messages in order to mitigate or eliminate the impact of the attacks Grammer: The need to be more cautious when processing received ICMP error messages in order to mitigate or eliminate the impact of the attacks 4.1 Many TCP implementations have incorporated a validation check so makes TCP react only to those ICMP error messages elicited by segments that were "in-flight" to the destination system. Grammer and minor correction for elicited: Many TCP implementations have incorporated a validation check to make TCP react only to those ICMP error messages that=20 appear to have been caused by segments that were "in-flight" to the destina= tion system. 5.2 Assuming that once a connection is established it is not usual for the transport protocol to change (or be reloaded), it should be unusual to get these error messages. Should be: Assuming that once a connection is established it is usual for the transport protocol to change (or be reloaded), it should be unusual to get these error messages. ...(still 5.2) ICMPv6 type 1 (Destination Unreachable), code 1 (communication with destination administratively prohibited) This error message indicates that the destination is unreachable because of an administrative policy. For connection-oriented protocols such as TCP, one could expect to receive such an error as the result of a connection-establishment attempt. Receiving such an error for a connection in any of the synchronized states would mean that the administrative policy changed during the life of the connection. However, in the same way this error condition (which was not present when the conenction was established) appeared, it could get solved solved in the near term. This actually does occur in some cases where bruteforce password attempts c= auses a tool such as fail2ban to block access. and connection not conenction. 7.1 The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the IP header to dynamically discover the Path MTU. The basic idea behind the PMTUD mechanism is that a source system assumes that the MTU of the path is that of the first hop, and sends all its datagrams with the DF bit set. If any of the datagrams is too large to be forwarded without fragmentation by some intermediate router, the router will discard the corresponding datagram, and will return an ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF set" (code 4) error message to the sending system. This message will report the MTU of the constricting hop, so that the sending system can reduce the assumed Path-MTU accordingly. Spelling and grammer: If any of the datagrams is too large -> If any of the datagrams are too large. fragementation needed ... As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery mechanism can be used to attack TCP. An attacker could send a forged ICMP "Destination Unreachable, fragmentation needed and DF set" packet (or their ICMPv6 counterpart) to the sending system, advertising a small Next-Hop MTU. As a result, the attacked system would reduce the size of the packets it sends for the corresponding connection accordingly. Again I would suggest crafted instead of forged. 7.2 The IETF has standardized a Path-MTU Discuvery mechanism called "Packetization Layer Path MTU Discovery" that does not depend on ICMP error messages. Spelling -> Discovery Review stopped at page 17. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia =20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of David Borman > Sent: Tuesday, September 01, 2009 9:12 AM > To: tcpm Extensions WG > Subject: [tcpm] WG Last Call for ICMP Attacks >=20 > Wes and I are starting a Working Group Last Call for the ICMP=20 > Attacks =20 > document: >=20 > http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-06.txt >=20 > This document is intended to be published as Informational. =20 > The WGLC =20 > will end on Sep. 15, 2009. Please send any comments to list before =20 > then. >=20 > -David Borman & Wes Eddy, TCPM WG chairs > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From touch@ISI.EDU Wed Sep 2 14:11:00 2009 Return-Path: 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 6B2213A6A4B for ; Wed, 2 Sep 2009 14:11:00 -0700 (PDT) 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=[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 teyGPXkAMsOL for ; Wed, 2 Sep 2009 14:10:58 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 0C38A28C23B for ; Wed, 2 Sep 2009 14:10:58 -0700 (PDT) Received: from [75.212.161.208] (208.sub-75-212-161.myvzw.com [75.212.161.208]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n82L8jGF008013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Sep 2009 14:08:47 -0700 (PDT) Message-ID: <4A9EDEDD.2030308@isi.edu> Date: Wed, 02 Sep 2009 14:08:45 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Smith, Donald" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n82L8jGF008013 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: 'tcpm Extensions WG' , 'David Borman' Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 21:11:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Smith, Donald wrote: > 1. > ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, > and is used mainly for reporting network error conditions. > > ICMP is part of the IP protocol suite. > > 2.2 > Therefore, in the case of TCP, an attacker could send a forged ICMP > message to the attacked system, and, as long as he is able to guess > the four-tuple (i.e., Source IP Address, Source TCP port, Destination > IP Address, and Destination TCP port) that identifies the > communication instance to be attacked, he will be able to use ICMP to > perform a variety of attacks. > > Forged usually implies that source ip address has been spoofed usually to come from some type of trusted host. > Crafted is the term generally used to mean the packets contents (not header) were modified. > In this case there is no need to spoof the source ip address as the end host has no knowledge about the routers in between them and the end host system. So I recommend you change forged to crafted. I've not heard that there was such clarity on the term forged or crafted, but neither is the case here. The attacker emits an ICMP message. It doesn't need a falsified header. It doesn't need to be a "modified" packet. E.g., it can be created based on information seen on the media. It might just be called a "false ICMP message", i.e., it's reporting an event that didn't happen. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqe3t0ACgkQE5f5cImnZrvj4QCeLodfjABk7/bGxLSU9wv4dV+N 0foAoJ5qPOCkzsS/w0kvpuOzJdChMcCb =BJU2 -----END PGP SIGNATURE----- From Donald.Smith@qwest.com Wed Sep 2 15:08:09 2009 Return-Path: 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 0BF3028C13F for ; Wed, 2 Sep 2009 15:08:09 -0700 (PDT) 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=[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 lWpE2B9dfBAF for ; Wed, 2 Sep 2009 15:08:07 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id C193E3A6E6F for ; Wed, 2 Sep 2009 15:08:07 -0700 (PDT) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by sudnp799.qwest.com (8.14.0/8.14.0) with ESMTP id n82M72I4006904; Wed, 2 Sep 2009 16:07:02 -0600 (MDT) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.0/8.14.0) with ESMTP id n82M6uEA019554; Wed, 2 Sep 2009 17:06:57 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Wed, 2 Sep 2009 16:06:56 -0600 From: "Smith, Donald" To: "'Joe Touch'" Date: Wed, 2 Sep 2009 16:06:55 -0600 Thread-Topic: [tcpm] WG Last Call for ICMP Attacks Thread-Index: AcosEelB2unTBJx7TMyhtQJ9MPX1zwABO/8w Message-ID: References: <4A9EDEDD.2030308@isi.edu> In-Reply-To: <4A9EDEDD.2030308@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'tcpm Extensions WG' , 'David Borman' Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 22:08:09 -0000 The distinction is from SANS classes but also commonly used in network fore= nsics. Crafted implies it wasn't created naturally by an OS. A "special" tool is required to "craft" the packets. A crafted packet MIGHT have also had its source IP forged. So I see "forged or spoofed" as a subset of crafted packets. "ICMP packet with falsified content" would be a good description. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia =20 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Wednesday, September 02, 2009 3:09 PM > To: Smith, Donald > Cc: 'David Borman'; 'tcpm Extensions WG' > Subject: Re: [tcpm] WG Last Call for ICMP Attacks >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 >=20 > Smith, Donald wrote: > > 1. > > ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, > > and is used mainly for reporting network error conditions. > >=20 > > ICMP is part of the IP protocol suite. > >=20 > > 2.2 > > Therefore, in the case of TCP, an attacker could send a forged ICMP > > message to the attacked system, and, as long as he is=20 > able to guess > > the four-tuple (i.e., Source IP Address, Source TCP=20 > port, Destination > > IP Address, and Destination TCP port) that identifies the > > communication instance to be attacked, he will be able=20 > to use ICMP to > > perform a variety of attacks. > >=20 > > Forged usually implies that source ip address has been=20 > spoofed usually to come from some type of trusted host. > > Crafted is the term generally used to mean the packets=20 > contents (not header) were modified. > > In this case there is no need to spoof the source ip=20 > address as the end host has no knowledge about the routers in=20 > between them and the end host system. So I recommend you=20 > change forged to crafted. >=20 > I've not heard that there was such clarity on the term forged or > crafted, but neither is the case here. >=20 > The attacker emits an ICMP message. It doesn't need a=20 > falsified header. > It doesn't need to be a "modified" packet. E.g., it can be=20 > created based > on information seen on the media. >=20 > It might just be called a "false ICMP message", i.e., it's=20 > reporting an > event that didn't happen. >=20 > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAkqe3t0ACgkQE5f5cImnZrvj4QCeLodfjABk7/bGxLSU9wv4dV+N > 0foAoJ5qPOCkzsS/w0kvpuOzJdChMcCb > =3DBJU2 > -----END PGP SIGNATURE----- > = From touch@ISI.EDU Wed Sep 2 16:05:50 2009 Return-Path: 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 C286228C328 for ; Wed, 2 Sep 2009 16:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 txCa0qPpYIws for ; Wed, 2 Sep 2009 16:05:49 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id CA8143A6EDF for ; Wed, 2 Sep 2009 16:05:49 -0700 (PDT) Received: from [75.213.81.255] ([75.213.81.255]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n82N5AwG013366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Sep 2009 16:05:12 -0700 (PDT) Message-ID: <4A9EFA25.8080203@isi.edu> Date: Wed, 02 Sep 2009 16:05:09 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Smith, Donald" References: <4A9EDEDD.2030308@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: 'tcpm Extensions WG' , 'David Borman' Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 23:05:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Smith, Donald wrote: ... > "ICMP packet with falsified content" would be a good description. Sounds better to me. Joe >> -----Original Message----- >> From: Joe Touch [mailto:touch@ISI.EDU] >> Sent: Wednesday, September 02, 2009 3:09 PM >> To: Smith, Donald >> Cc: 'David Borman'; 'tcpm Extensions WG' >> Subject: Re: [tcpm] WG Last Call for ICMP Attacks >> > > > Smith, Donald wrote: >>>> 1. >>>> ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, >>>> and is used mainly for reporting network error conditions. >>>> >>>> ICMP is part of the IP protocol suite. >>>> >>>> 2.2 >>>> Therefore, in the case of TCP, an attacker could send a forged ICMP >>>> message to the attacked system, and, as long as he is > able to guess >>>> the four-tuple (i.e., Source IP Address, Source TCP > port, Destination >>>> IP Address, and Destination TCP port) that identifies the >>>> communication instance to be attacked, he will be able > to use ICMP to >>>> perform a variety of attacks. >>>> >>>> Forged usually implies that source ip address has been > spoofed usually to come from some type of trusted host. >>>> Crafted is the term generally used to mean the packets > contents (not header) were modified. >>>> In this case there is no need to spoof the source ip > address as the end host has no knowledge about the routers in > between them and the end host system. So I recommend you > change forged to crafted. > > I've not heard that there was such clarity on the term forged or > crafted, but neither is the case here. > > The attacker emits an ICMP message. It doesn't need a > falsified header. > It doesn't need to be a "modified" packet. E.g., it can be > created based > on information seen on the media. > > It might just be called a "false ICMP message", i.e., it's > reporting an > event that didn't happen. > > Joe >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqe+iUACgkQE5f5cImnZrs8RQCfVKb2M78n3eZfy32Fy3gpq6Jv V5sAoOu3p+aLhut9Nsx0I6t4BWbDUJbD =xri6 -----END PGP SIGNATURE----- From fernando@gont.com.ar Wed Sep 2 22:05:42 2009 Return-Path: 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 D8B643A684A for ; Wed, 2 Sep 2009 22:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.193 X-Spam-Level: X-Spam-Status: No, score=-3.193 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 SHkO2BUNdhPK for ; Wed, 2 Sep 2009 22:05:41 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 0E08E3A688C for ; Wed, 2 Sep 2009 22:05:40 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 1AB8F6B677D; Thu, 3 Sep 2009 01:48:59 -0300 (ART) Received: from [192.168.0.136] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n834mcnq013315; Thu, 3 Sep 2009 01:48:39 -0300 Message-ID: <4A9F4AB1.6070605@gont.com.ar> Date: Thu, 03 Sep 2009 01:48:49 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Smith, Donald" References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 03 Sep 2009 01:48:58 -0300 (ART) Cc: 'tcpm Extensions WG' , 'David Borman' Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 05:05:43 -0000 Hello, Donald, Thanks so much for your feedback! Comments inline.... (I have removed those comments that I will apply and didn't need further clarification...) Smith, Donald wrote: > 1. ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, > and is used mainly for reporting network error conditions. > > ICMP is part of the IP protocol suite. The protocol suite is referred to as "TCP/IP"... > 2.2 Therefore, in the case of TCP, an attacker could send a forged > ICMP message to the attacked system, and, as long as he is able to > guess the four-tuple (i.e., Source IP Address, Source TCP port, > Destination IP Address, and Destination TCP port) that identifies the > communication instance to be attacked, he will be able to use ICMP > to perform a variety of attacks. > > Forged usually implies that source ip address has been spoofed > usually to come from some type of trusted host. Crafted is the term [...] I'll adopt the term/phrase you and Joe have converged to. > 4.1 Many TCP implementations have incorporated a validation check so > makes TCP react only to those ICMP error messages elicited by > segments that were "in-flight" to the destination system. > > Grammer and minor correction for elicited: Many TCP implementations > have incorporated a validation check to make TCP react only to those > ICMP error messages that appear to have been caused by segments that > were "in-flight" to the destination system. Does "elicited" sound bad? (english as a second language here, sorry) > 5.2 Assuming that once a connection is established it is not usual > for the transport protocol to change (or be reloaded), it should be > unusual to get these error messages. Should be: Assuming that once a > connection is established it is usual for the transport protocol to > change (or be reloaded), it should be unusual to get these error > messages. > > > ...(still 5.2) > > ICMPv6 type 1 (Destination Unreachable), code 1 (communication with > destination administratively prohibited) > > This error message indicates that the destination is unreachable > because of an administrative policy. For connection-oriented > protocols such as TCP, one could expect to receive such an error as > the result of a connection-establishment attempt. Receiving such an > error for a connection in any of the synchronized states would mean > that the administrative policy changed during the life of the > connection. However, in the same way this error condition (which was > not present when the conenction was established) appeared, it could > get solved solved in the near term. > > This actually does occur in some cases where bruteforce password > attempts causes a tool such as fail2ban to block access. and > connection not conenction. Ok. Will add a note on this. If you have any proposed text, please let me know. > 7.1 The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in > the IP header to dynamically discover the Path MTU. The basic idea > behind the PMTUD mechanism is that a source system assumes that the > MTU of the path is that of the first hop, and sends all its datagrams > with the DF bit set. If any of the datagrams is too large to be > forwarded without fragmentation by some intermediate router, the > router will discard the corresponding datagram, and will return an > ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF > set" (code 4) error message to the sending system. This message will > report the MTU of the constricting hop, so that the sending system > can reduce the assumed Path-MTU accordingly. > > Spelling and grammer: If any of the datagrams is too large -> If any > of the datagrams are too large. mmmm... aren't we meaning that "as long as *one* of them is too large"? > As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery > mechanism can be used to attack TCP. An attacker could send a forged > ICMP "Destination Unreachable, fragmentation needed and DF set" > packet (or their ICMPv6 counterpart) to the sending system, > advertising a small Next-Hop MTU. As a result, the attacked system > would reduce the size of the packets it sends for the corresponding > connection accordingly. > > Again I would suggest crafted instead of forged. Well, even with the discussion you provided about "forged" vs. "crafted", the attacker does forge the IP/TCP packet contained in the ICMP payload... Thanks so much! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From toby.moncaster@bt.com Thu Sep 3 06:02:29 2009 Return-Path: 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 321783A6A13 for ; Thu, 3 Sep 2009 06:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.232 X-Spam-Level: X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 JbYt7gim31mm for ; Thu, 3 Sep 2009 06:02:28 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id D97283A6C60 for ; Thu, 3 Sep 2009 06:01:52 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 11:05:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Sep 2009 11:05:47 +0100 Message-ID: In-Reply-To: <4A9F4AB1.6070605@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WG Last Call for ICMP Attacks Thread-Index: AcosVD1b1g9yVBUiRXGetJUIlNrZdgAKJ+fA References: <4A9F4AB1.6070605@gont.com.ar> From: To: , X-OriginalArrivalTime: 03 Sep 2009 10:05:48.0931 (UTC) FILETIME=[1C82B530:01CA2C7E] Cc: tcpm@ietf.org, david.borman@windriver.com Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 13:02:29 -0000 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Fernando Gont > Sent: 03 September 2009 05:49 > To: Smith, Donald > Cc: 'tcpm Extensions WG'; 'David Borman' > Subject: Re: [tcpm] WG Last Call for ICMP Attacks >=20 > Hello, Donald, >=20 > Thanks so much for your feedback! Comments inline.... (I have removed > those comments that I will apply and didn't need further > clarification...) >=20 >=20 > Smith, Donald wrote: > > 1. ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, > > and is used mainly for reporting network error conditions. > > > > ICMP is part of the IP protocol suite. >=20 > The protocol suite is referred to as "TCP/IP"... >=20 >=20 >=20 > > 2.2 Therefore, in the case of TCP, an attacker could send a forged > > ICMP message to the attacked system, and, as long as he is able to > > guess the four-tuple (i.e., Source IP Address, Source TCP port, > > Destination IP Address, and Destination TCP port) that identifies the > > communication instance to be attacked, he will be able to use ICMP > > to perform a variety of attacks. > > > > Forged usually implies that source ip address has been spoofed > > usually to come from some type of trusted host. Crafted is the term > [...] >=20 > I'll adopt the term/phrase you and Joe have converged to. >=20 >=20 >=20 > > 4.1 Many TCP implementations have incorporated a validation check so > > makes TCP react only to those ICMP error messages elicited by > > segments that were "in-flight" to the destination system. > > > > Grammer and minor correction for elicited: Many TCP implementations > > have incorporated a validation check to make TCP react only to those > > ICMP error messages that appear to have been caused by segments that > > were "in-flight" to the destination system. >=20 > Does "elicited" sound bad? (english as a second language here, sorry) >=20 "elicited" implies that the packet specifically sought the ICMP packet to be sent (which I guess would indeed be the case in tcptraceroute) whereas the alternate wording is trying to make it clear that the ICMP packet wasn't the desired response in the first place. Not sure how clear my explanation actually is!=20 Possible alternative wording: "Many TCP implementations have incorporated a validation check such that they only react to those ICMP messages that appear to relate to segments currently "in-flight" to the destination system." >=20 >=20 >=20 > > 5.2 Assuming that once a connection is established it is not usual > > for the transport protocol to change (or be reloaded), it should be > > unusual to get these error messages. Should be: Assuming that once a > > connection is established it is usual for the transport protocol to > > change (or be reloaded), it should be unusual to get these error > > messages. > > > > > > ...(still 5.2) > > > > ICMPv6 type 1 (Destination Unreachable), code 1 (communication with > > destination administratively prohibited) > > > > This error message indicates that the destination is unreachable > > because of an administrative policy. For connection-oriented > > protocols such as TCP, one could expect to receive such an error as > > the result of a connection-establishment attempt. Receiving such an > > error for a connection in any of the synchronized states would mean > > that the administrative policy changed during the life of the > > connection. However, in the same way this error condition (which was > > not present when the conenction was established) appeared, it could > > get solved solved in the near term. > > > > This actually does occur in some cases where bruteforce password > > attempts causes a tool such as fail2ban to block access. and > > connection not conenction. >=20 > Ok. Will add a note on this. If you have any proposed text, please let > me know. >=20 >=20 >=20 > > 7.1 The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in > > the IP header to dynamically discover the Path MTU. The basic idea > > behind the PMTUD mechanism is that a source system assumes that the > > MTU of the path is that of the first hop, and sends all its datagrams > > with the DF bit set. If any of the datagrams is too large to be > > forwarded without fragmentation by some intermediate router, the > > router will discard the corresponding datagram, and will return an > > ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF > > set" (code 4) error message to the sending system. This message will > > report the MTU of the constricting hop, so that the sending system > > can reduce the assumed Path-MTU accordingly. > > > > Spelling and grammer: If any of the datagrams is too large -> If any > > of the datagrams are too large. >=20 > mmmm... aren't we meaning that "as long as *one* of them is too large"? >=20 >=20 >=20 > > As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery > > mechanism can be used to attack TCP. An attacker could send a forged > > ICMP "Destination Unreachable, fragmentation needed and DF set" > > packet (or their ICMPv6 counterpart) to the sending system, > > advertising a small Next-Hop MTU. As a result, the attacked system > > would reduce the size of the packets it sends for the corresponding > > connection accordingly. > > > > Again I would suggest crafted instead of forged. >=20 > Well, even with the discussion you provided about "forged" vs. > "crafted", the attacker does forge the IP/TCP packet contained in the > ICMP payload... >=20 > Thanks so much! >=20 > Kind regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From danny@tcb.net Thu Sep 3 07:39:11 2009 Return-Path: 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 C85413A6985 for ; Thu, 3 Sep 2009 07:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] 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 CMldABi7z3GN for ; Thu, 3 Sep 2009 07:39:11 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 035573A68A8 for ; Thu, 3 Sep 2009 07:39:11 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 3FC3B368046; Thu, 3 Sep 2009 08:37:35 -0600 (MDT) Received: from jchouinard-sim-318.eng.ellacoya.com (97-118-218-88.hlrn.qwest.net [97.118.218.88]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 03 Sep 2009 08:37:35 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.218.88; client-port=58983; syn-fingerprint=65535:56:1:64:M1408,N,W1,N,N,T,S; data-bytes=0 Message-Id: <275B75BC-634B-45A7-8F65-63870813A809@tcb.net> From: Danny McPherson To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" , tcpm@ietf.org In-Reply-To: <20090826135651.00EF23F8684@lawyers.icir.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 3 Sep 2009 08:37:33 -0600 References: <20090826135651.00EF23F8684@lawyers.icir.org> X-Mailer: Apple Mail (2.936) Subject: Re: [tcpm] WGLC for MSS document 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 14:39:11 -0000 I agree with Marks's comments - in general I like the document (my colleague Aaron Campbell and I asked for and offered to write) something similar quite a while back). It is worth noting that the confusion isn't universal, at least, the Linux, NetBSD, and OpenBSD people got it right (options are not subtracted from the advertised MSS on these systems from our past research). RFC2385 is wrong, though: ---------- 4.3 TCP Header Size As with other options that are added to every segment, the size of the MD5 option must be factored into the MSS offered to the other side during connection negotiation. Specifically, the size of the header to subtract from the MTU (whether it is the MTU of the outgoing interface or IP's minimal MTU of 576 bytes) is now at least 18 bytes larger. ---------- Perhaps the draft could cite RFC2385 as a bad example and point out the error? We saw this cause fragmentation with a Cisco GSR talking to a BSD box. The GSR was subtracting the size of the TCP MD5 option from the advertised MSS and assuming that the BSD box was doing the same. Since the management interface on the GSR was POS, it ended up sending an MSS of 4386, while the BSD box sent 1460 (Ethernet). The lower of the two values gets used, so the GSR assumed it could send 1460 bytes payload on top of the fixed IP + fixed TCP + TCP MD5 option, so it was overrunning the 1500 byte MTU by 18 bytes. Note, this isn't a problem for Ethernet-to-Ethernet, because the GSR would choose an MSS of 1442 (although Jumbo frames may be an issue at some point), and being lower than 1460, would be the negotiated maximum for both sides of the connection. -danny From dab@weston.borman.com Thu Sep 3 08:56:26 2009 Return-Path: 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 B945A3A6D8C for ; Thu, 3 Sep 2009 08:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 TZwrZMAZxs-Z for ; Thu, 3 Sep 2009 08:56:25 -0700 (PDT) Received: from frantic.weston.borman.com (frantic-dmz.weston.BORMAN.COM [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id 232AC3A696B for ; Thu, 3 Sep 2009 08:56:24 -0700 (PDT) Received: from [172.25.44.8] (weston-43.weston.borman.com [206.196.45.43]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id n83F0hlm017218; Thu, 3 Sep 2009 10:00:44 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: David Borman In-Reply-To: <275B75BC-634B-45A7-8F65-63870813A809@tcb.net> Date: Thu, 3 Sep 2009 10:00:43 -0500 Content-Transfer-Encoding: 7bit Message-Id: <1A061317-E555-41AC-9040-571DFCB2C317@weston.borman.com> References: <20090826135651.00EF23F8684@lawyers.icir.org> <275B75BC-634B-45A7-8F65-63870813A809@tcb.net> To: Danny McPherson X-Mailer: Apple Mail (2.1075.2) Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for MSS document 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 15:56:26 -0000 Danny, Thanks, I was unaware of this, and I'll add that in to the document. For everyone else that has provided comments so far, they are all good and I have an updated version of the draft that just isn't quite done, but I hope to get it posted by the end of Friday. The WG chairs are extending the WGLC for the revised version. :-) -David Borman On Sep 3, 2009, at 9:37 AM, Danny McPherson wrote: > > I agree with Marks's comments - in general I like the document > (my colleague Aaron Campbell and I asked for and offered to write) > something similar quite a while back). > > It is worth noting that the confusion isn't universal, at least, the > Linux, NetBSD, and OpenBSD people got it right (options are not > subtracted from the advertised MSS on these systems from our past > research). > > RFC2385 is wrong, though: > > ---------- > 4.3 TCP Header Size > > As with other options that are added to every segment, the size of > the MD5 option must be factored into the MSS offered to the other > side during connection negotiation. Specifically, the size of the > header to subtract from the MTU (whether it is the MTU of the > outgoing interface or IP's minimal MTU of 576 bytes) is now at least > 18 bytes larger. > ---------- > > Perhaps the draft could cite RFC2385 as a bad example and point out > the > error? We saw this cause fragmentation with a Cisco GSR talking to > a BSD > box. The GSR was subtracting the size of the TCP MD5 option from the > advertised MSS and assuming that the BSD box was doing the same. > Since the > management interface on the GSR was POS, it ended up sending an MSS > of 4386, > while the BSD box sent 1460 (Ethernet). The lower of the two values > gets > used, so the GSR assumed it could send 1460 bytes payload on top of > the fixed > IP + fixed TCP + TCP MD5 option, so it was overrunning the 1500 byte > MTU by > 18 bytes. Note, this isn't a problem for Ethernet-to-Ethernet, > because the > GSR would choose an MSS of 1442 (although Jumbo frames may be an > issue at > some point), and being lower than 1460, would be the negotiated > maximum for > both sides of the connection. > > -danny > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From fernando@gont.com.ar Thu Sep 3 10:31:03 2009 Return-Path: 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 9172128C38E for ; Thu, 3 Sep 2009 10:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.217 X-Spam-Level: X-Spam-Status: No, score=-3.217 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 w82RmLbS8i5Q for ; Thu, 3 Sep 2009 10:31:02 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 4747D28C38B for ; Thu, 3 Sep 2009 10:30:52 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 6B4266B6617; Thu, 3 Sep 2009 14:00:17 -0300 (ART) Received: from [192.168.0.136] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n83Gxtp0004187; Thu, 3 Sep 2009 13:59:59 -0300 Message-ID: <4A9FF60C.7030200@gont.com.ar> Date: Thu, 03 Sep 2009 13:59:56 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: toby.moncaster@bt.com References: <4A9F4AB1.6070605@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 03 Sep 2009 14:00:09 -0300 (ART) Cc: Donald.Smith@qwest.com, tcpm@ietf.org, david.borman@windriver.com Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 17:31:03 -0000 toby.moncaster@bt.com wrote: >>> Grammer and minor correction for elicited: Many TCP implementations >>> have incorporated a validation check to make TCP react only to those >>> ICMP error messages that appear to have been caused by segments that >>> were "in-flight" to the destination system. >> Does "elicited" sound bad? (english as a second language here, sorry) >> > > "elicited" implies that the packet specifically sought the ICMP packet > to be sent (which I guess would indeed be the case in tcptraceroute) > whereas the alternate wording is trying to make it clear that the ICMP > packet wasn't the desired response in the first place. Not sure how > clear my explanation actually is! Clear as water. :-) Thanks! > Possible alternative wording: "Many TCP implementations have > incorporated a validation check such that they only react to those ICMP > messages that appear to relate to segments currently "in-flight" to the > destination system." Will incorporate this one. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From Donald.Smith@qwest.com Thu Sep 3 10:59:49 2009 Return-Path: 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 36A303A67F8 for ; Thu, 3 Sep 2009 10:59:49 -0700 (PDT) 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 71GbBsnv2DDx for ; Thu, 3 Sep 2009 10:59:48 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id C33A83A67EC for ; Thu, 3 Sep 2009 10:59:44 -0700 (PDT) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id n83HwmT0008896; Thu, 3 Sep 2009 12:58:50 -0500 (CDT) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id n83Hwguk021889; Thu, 3 Sep 2009 12:58:43 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Thu, 3 Sep 2009 11:58:43 -0600 From: "Smith, Donald" To: "'toby.moncaster@bt.com'" , "'fernando@gont.com.ar'" Date: Thu, 3 Sep 2009 11:58:31 -0600 Thread-Topic: [tcpm] WG Last Call for ICMP Attacks Thread-Index: AcosVD1b1g9yVBUiRXGetJUIlNrZdgAKJ+fAAA5kAEA= Message-ID: References: <4A9F4AB1.6070605@gont.com.ar> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'tcpm@ietf.org'" , "'david.borman@windriver.com'" Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 17:59:49 -0000 Hi Fernando. Thanks for reviewing my comments. Toby and others did a good job of answering most of the addition questions = but I have one or two clarifications below inline. 01100101000010|10011010111101? Hint 7 bit ascii Donald.Smith@qwest.com gcia =20 > -----Original Message----- > From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com]=20 > Sent: Thursday, September 03, 2009 4:06 AM > To: fernando@gont.com.ar; Smith, Donald > Cc: tcpm@ietf.org; david.borman@windriver.com > Subject: RE: [tcpm] WG Last Call for ICMP Attacks >=20 >=20 >=20 > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf > Of > > Fernando Gont > > Sent: 03 September 2009 05:49 > > To: Smith, Donald > > Cc: 'tcpm Extensions WG'; 'David Borman' > > Subject: Re: [tcpm] WG Last Call for ICMP Attacks > >=20 > > Hello, Donald, > >=20 > > Thanks so much for your feedback! Comments inline.... (I=20 > have removed > > those comments that I will apply and didn't need further > > clarification...) > >=20 > >=20 > > Smith, Donald wrote: > > > 1. ICMP [RFC0792] is a fundamental part of the TCP/IP protocol > suite, > > > and is used mainly for reporting network error conditions. > > > > > > ICMP is part of the IP protocol suite. > >=20 > > The protocol suite is referred to as "TCP/IP"... Since this documents focus is TCP/IP's interaction with ICMP I am ok with i= t but ICMP is an IP protocol (protocol number 1 :) A LOT of people use the expression "tcp/ip" to describe things that are IP (not dependant o= n tcp). > >=20 > >=20 > >=20 > > > 2.2 Therefore, in the case of TCP, an attacker could send a forged > > > ICMP message to the attacked system, and, as long as he is able to > > > guess the four-tuple (i.e., Source IP Address, Source TCP port, > > > Destination IP Address, and Destination TCP port) that identifies > the > > > communication instance to be attacked, he will be able=20 > to use ICMP > > > to perform a variety of attacks. > > > > > > Forged usually implies that source ip address has been spoofed > > > usually to come from some type of trusted host. Crafted=20 > is the term > > [...] > >=20 > > I'll adopt the term/phrase you and Joe have converged to. > >=20 > >=20 > >=20 > > > 4.1 Many TCP implementations have incorporated a=20 > validation check so > > > makes TCP react only to those ICMP error messages elicited by > > > segments that were "in-flight" to the destination system. > > > > > > Grammer and minor correction for elicited: Many TCP=20 > implementations > > > have incorporated a validation check to make TCP react=20 > only to those > > > ICMP error messages that appear to have been caused by=20 > segments that > > > were "in-flight" to the destination system. > >=20 > > Does "elicited" sound bad? (english as a second language=20 > here, sorry) Not bad there is an implication that I don't think you intended. > >=20 >=20 > "elicited" implies that the packet specifically sought the ICMP packet > to be sent (which I guess would indeed be the case in tcptraceroute) > whereas the alternate wording is trying to make it clear that the ICMP > packet wasn't the desired response in the first place. Not sure how > clear my explanation actually is!=20 >=20 > Possible alternative wording: "Many TCP implementations have > incorporated a validation check such that they only react to=20 > those ICMP > messages that appear to relate to segments currently=20 > "in-flight" to the > destination system." This wording is better. Yes elicited tends to imply "caused by". By adding the "appear" above this statement is clearer. >=20 >=20 > >=20 > >=20 > >=20 > > > 5.2 Assuming that once a connection is established it is not usual > > > for the transport protocol to change (or be reloaded), it=20 > should be > > > unusual to get these error messages. Should be: Assuming=20 > that once a > > > connection is established it is usual for the transport=20 > protocol to > > > change (or be reloaded), it should be unusual to get these error > > > messages. > > > > > > > > > ...(still 5.2) > > > > > > ICMPv6 type 1 (Destination Unreachable), code 1=20 > (communication with > > > destination administratively prohibited) > > > > > > This error message indicates that the destination is unreachable > > > because of an administrative policy. For connection-oriented > > > protocols such as TCP, one could expect to receive such=20 > an error as > > > the result of a connection-establishment attempt. =20 > Receiving such an > > > error for a connection in any of the synchronized states=20 > would mean > > > that the administrative policy changed during the life of the > > > connection. However, in the same way this error condition (which > was > > > not present when the conenction was established)=20 > appeared, it could > > > get solved solved in the near term. > > > > > > This actually does occur in some cases where bruteforce password > > > attempts causes a tool such as fail2ban to block access. and > > > connection not conenction. > >=20 > > Ok. Will add a note on this. If you have any proposed text,=20 > please let > > me know. > >=20 > >=20 > >=20 > > > 7.1 The PMTUD mechanism for IPv4 uses the Don't Fragment=20 > (DF) bit in > > > the IP header to dynamically discover the Path MTU. The=20 > basic idea > > > behind the PMTUD mechanism is that a source system=20 > assumes that the > > > MTU of the path is that of the first hop, and sends all its > datagrams > > > with the DF bit set. If any of the datagrams is too large to be > > > forwarded without fragmentation by some intermediate router, the > > > router will discard the corresponding datagram, and will return an > > > ICMP "Destination Unreachable" (type 3) "fragmentation=20 > neeed and DF > > > set" (code 4) error message to the sending system. This message > will > > > report the MTU of the constricting hop, so that the=20 > sending system > > > can reduce the assumed Path-MTU accordingly. > > > > > > Spelling and grammer: If any of the datagrams is too=20 > large -> If any > > > of the datagrams are too large. > >=20 > > mmmm... aren't we meaning that "as long as *one* of them is too > large"? > >=20 > >=20 > >=20 > > > As discussed in both [RFC1191] and [RFC1981], the=20 > Path-MTU Discovery > > > mechanism can be used to attack TCP. An attacker could send a > forged > > > ICMP "Destination Unreachable, fragmentation needed and DF set" > > > packet (or their ICMPv6 counterpart) to the sending system, > > > advertising a small Next-Hop MTU. As a result, the=20 > attacked system > > > would reduce the size of the packets it sends for the=20 > corresponding > > > connection accordingly. > > > > > > Again I would suggest crafted instead of forged. > >=20 > > Well, even with the discussion you provided about "forged" vs. > > "crafted", the attacker does forge the IP/TCP packet=20 > contained in the > > ICMP payload... > >=20 > > Thanks so much! > >=20 > > Kind regards, > > -- > > Fernando Gont > > e-mail: fernando@gont.com.ar || fgont@acm.org > > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > = From fernando@gont.com.ar Thu Sep 3 11:47:46 2009 Return-Path: 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 B811B3A67E5 for ; Thu, 3 Sep 2009 11:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.238 X-Spam-Level: X-Spam-Status: No, score=-3.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 qUZqdN8mruVy for ; Thu, 3 Sep 2009 11:47:46 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id BACC53A672F for ; Thu, 3 Sep 2009 11:47:43 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D90C06B67BE; Thu, 3 Sep 2009 15:28:14 -0300 (ART) Received: from [192.168.0.136] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n83IS0MY020236; Thu, 3 Sep 2009 15:28:03 -0300 Message-ID: <4AA00AB2.5080707@gont.com.ar> Date: Thu, 03 Sep 2009 15:28:02 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Smith, Donald" References: <4A9F4AB1.6070605@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 03 Sep 2009 15:28:14 -0300 (ART) Cc: "'tcpm@ietf.org'" , "'david.borman@windriver.com'" Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 18:47:46 -0000 Hello, Donnald, Comments inline.... >>>> Grammer and minor correction for elicited: Many TCP >> implementations >>>> have incorporated a validation check to make TCP react >> only to those >>>> ICMP error messages that appear to have been caused by >> segments that >>>> were "in-flight" to the destination system. >>> Does "elicited" sound bad? (english as a second language >> here, sorry) > Not bad there is an implication that I don't think you intended. That pointed out by Toby? Thanks again! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From Donald.Smith@qwest.com Thu Sep 3 12:36:15 2009 Return-Path: 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 CF43F3A68C5 for ; Thu, 3 Sep 2009 12:36:15 -0700 (PDT) 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 ArWUQ2-U6YW6 for ; Thu, 3 Sep 2009 12:36:14 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 525E83A68BB for ; Thu, 3 Sep 2009 12:36:14 -0700 (PDT) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id n83JXSPX029124; Thu, 3 Sep 2009 14:33:28 -0500 (CDT) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.0/8.14.0) with ESMTP id n83JXLBI025787; Thu, 3 Sep 2009 14:33:22 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Thu, 3 Sep 2009 13:33:22 -0600 From: "Smith, Donald" To: "'Fernando Gont'" Date: Thu, 3 Sep 2009 13:33:20 -0600 Thread-Topic: [tcpm] WG Last Call for ICMP Attacks Thread-Index: AcosxE0cHldTQrRqTviquLKt2/PyRAACOxAA Message-ID: References: <4A9F4AB1.6070 605@gont.com.ar> <4AA00AB2.5080707@gont.com.ar> In-Reply-To: <4AA00AB2.5080707@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'tcpm@ietf.org'" , "'david.borman@windriver.com'" Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 19:36:15 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia =20 > -----Original Message----- > From: Fernando Gont [mailto:fernando@gont.com.ar]=20 > Sent: Thursday, September 03, 2009 12:28 PM > To: Smith, Donald > Cc: 'toby.moncaster@bt.com'; 'tcpm@ietf.org';=20 > 'david.borman@windriver.com' > Subject: Re: [tcpm] WG Last Call for ICMP Attacks >=20 > Hello, Donnald, >=20 > Comments inline.... >=20 >=20 > >>>> Grammer and minor correction for elicited: Many TCP > >> implementations > >>>> have incorporated a validation check to make TCP react > >> only to those > >>>> ICMP error messages that appear to have been caused by > >> segments that > >>>> were "in-flight" to the destination system. > >>> Does "elicited" sound bad? (english as a second language > >> here, sorry) > > Not bad there is an implication that I don't think you intended. >=20 > That pointed out by Toby? Yes elicited tends to imply "caused by". Adding appear to the statement as Toby did makes it more correct. >=20 > Thanks again! >=20 > Kind regards, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 > = From fernando@gont.com.ar Thu Sep 3 12:57:36 2009 Return-Path: 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 C960C3A67C2 for ; Thu, 3 Sep 2009 12:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.257 X-Spam-Level: X-Spam-Status: No, score=-3.257 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 O19lbldsfNeb for ; Thu, 3 Sep 2009 12:57:34 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id EF2053A67A1 for ; Thu, 3 Sep 2009 12:57:32 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 8A2C56B681E; Thu, 3 Sep 2009 14:40:37 -0300 (ART) Received: from [192.168.0.136] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n83HeQ5B032086; Thu, 3 Sep 2009 14:40:27 -0300 Message-ID: <4A9FFF8C.7040001@gont.com.ar> Date: Thu, 03 Sep 2009 14:40:28 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: toby.moncaster@bt.com References: <200908262238.AAA06336@TR-Sys.de><4A9624CB.6040203@isi.edu> <4A9894C3.4020300@gont.com.ar><4A9AB5C2.4090209@isi.edu> <4A9CB254.7050802@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 03 Sep 2009 14:40:36 -0300 (ART) Cc: ah@tr-sys.de, tcpm@ietf.org, touch@ISI.EDU Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 19:57:36 -0000 Hello, Toby, > opinions on this document that are clearly incompatible. One key thing, > regardless of how we actually decide to split the work, Fernando's > current ToC is too long... 3 pages of ToC is excessive. Well, it's a large document. Even If we reduce the number of top-level sections, the ToC would most likely still be that large (or it wouldn't be useful). > I think the > sections aren't grouped at a high enough level (e.g. connection > establishment and tear-down could be in one section on connection > management, buffer management and re-assembly could probably be grouped > into memory management, etc). I agree. Please let me have another look, and try to come up with something. > This is separate to any consideration as > to whether you should be presenting things in a completely different > order... I think Joe actually raised this before... I don't think this is what Joe raised. For the most part, he argued to organize the information on a per-attack-type basis. Anyway, you did raise it... so,.. point taken. >> Again: the goal of this document is helping TCP implementers harden >> their TCPs. And for that target, having everything about a protocol >> field in a single place is the only document outline that does not get >> in the middle of the developer and the implementation. If you spread >> the >> advice among lots of places, this is what will happen: some > mitigations >> will be missed. > > So if this is entirely aimed at implementers shouldn't that be > explicitly stated in the title? I appreciate that in theory BCP is meant > to imply implementation guidance but this might be more appropriately > titled something like "Implementers guidelines for mitigating TCP > security threats" or "Guidance on secure implementation of TCP" Point taken. How about "Guidance on secure implementation of the Transmission Control Protocol (TCP)"? Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From lars.eggert@nokia.com Thu Sep 3 16:31:51 2009 Return-Path: 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 D21523A6981 for ; Thu, 3 Sep 2009 16:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 G-amr6piPm6I for ; Thu, 3 Sep 2009 16:31:51 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id BCEE83A67A1 for ; Thu, 3 Sep 2009 16:31:50 -0700 (PDT) Received: from [IPv6:2001:14b8:18f::225:ff:fe45:eccf] ([IPv6:2001:14b8:18f:0:225:ff:fe45:eccf]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n83NUWv0081011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Sep 2009 02:30:32 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: multipart/signed; boundary=Apple-Mail-3-983003904; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4A9FFF8C.7040001@gont.com.ar> Date: Fri, 4 Sep 2009 02:30:27 +0300 Message-Id: References: <200908262238.AAA06336@TR-Sys.de><4A9624CB.6040203@isi.edu> <4A9894C3.4020300@gont.com.ar><4A9AB5C2.4090209@isi.edu> <4A9CB254.7050802@gont.com.ar> <4A9FFF8C.7040001@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1075.2) Cc: "ah@tr-sys.de" , "tcpm@ietf.org" , "touch@ISI.EDU" Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 23:31:51 -0000 --Apple-Mail-3-983003904 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On 2009-9-3, at 20:40, Fernando Gont wrote: So if this is entirely aimed at implementers shouldn't that be >> explicitly stated in the title? I appreciate that in theory BCP is >> meant >> to imply implementation guidance but this might be more appropriately >> titled something like "Implementers guidelines for mitigating TCP >> security threats" or "Guidance on secure implementation of TCP" > > Point taken. How about "Guidance on secure implementation of the > Transmission Control Protocol (TCP)"? Personally, I'd avoid the word "secured" in the title and maybe in other places in the document. Maybe use "hardened" or "robust" or "attack-resistant" or something, but "secure" isn't quite accurate. Lars --Apple-Mail-3-983003904 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MDkwMzIzMzAyN1owIwYJKoZIhvcNAQkEMRYEFDLyMMN3OuGXEm8zrYUojMupRfTrMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCCAOyYcsCdcP6ZKDDoU4IhzIN+/P7drEcHlWhqX/U8xeL9xQa0Dsyk9QnfpJg7XyfGUvUt HUSlvZmoUI6+kwfyus4tT2UGkbcTvd+utY/Ydw4W+oxTblQbZ0l8Ohu1VohVVVzbu7hk5vq3ePRp G4ZXxavenZ+ju0HPWhOaw6WM8ndXhhpGJ1Cl0Hmsf2msegrVEgR8/XeBcGeal2XDDrxp9OUB2mQ1 0kgnr4c49NE6+7hgloP2iVp0H7K4pHsxLAxjsXxdikU9nNUyj3lyjByVplKeCWtiCQzwJdfv+7n4 e9aTMrvUh9u39gxWHvf24ebRHvNVs69JIT7tuv0UttrkAAAAAAAA --Apple-Mail-3-983003904-- From touch@ISI.EDU Thu Sep 3 16:43:18 2009 Return-Path: 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 959F33A6853 for ; Thu, 3 Sep 2009 16:43:18 -0700 (PDT) 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=[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 WeIw7Fp8+S-1 for ; Thu, 3 Sep 2009 16:43:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 480B33A686A for ; Thu, 3 Sep 2009 16:43:14 -0700 (PDT) Received: from [75.214.129.204] (204.sub-75-214-129.myvzw.com [75.214.129.204]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n83Ng6Yf017350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Sep 2009 16:42:10 -0700 (PDT) Message-ID: <4AA0544E.5060802@isi.edu> Date: Thu, 03 Sep 2009 16:42:06 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <200908262238.AAA06336@TR-Sys.de><4A9624CB.6040203@isi.edu> <4A9894C3.4020300@gont.com.ar><4A9AB5C2.4090209@isi.edu> <4A9CB254.7050802@gont.com.ar> <4A9FFF8C.7040001@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "ah@tr-sys.de" , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 23:43:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Eggert wrote: > On 2009-9-3, at 20:40, Fernando Gont wrote: > So if this is entirely aimed at implementers shouldn't that be >>> explicitly stated in the title? I appreciate that in theory BCP is meant >>> to imply implementation guidance but this might be more appropriately >>> titled something like "Implementers guidelines for mitigating TCP >>> security threats" or "Guidance on secure implementation of TCP" >> >> Point taken. How about "Guidance on secure implementation of the >> Transmission Control Protocol (TCP)"? > > Personally, I'd avoid the word "secured" in the title and maybe in other > places in the document. Maybe use "hardened" or "robust" or > "attack-resistant" or something, but "secure" isn't quite accurate Guidance to Mitigate TCP Implementation-Based Vulnerabilities This makes more sense to me if this is indeed focused on implementation-based vulnerabilities, rather than general security threats If this is all the ways an implementer can avoid security threats in general, then I reiterate my suggestion that we need a security vulnerabilities doc. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqgVE4ACgkQE5f5cImnZrvXfwCdGZNJw5Wr0KsxR2N8zf0gADzQ mrIAn3/Tpr6tAazbnzX3tD80qQFLihrP =lejH -----END PGP SIGNATURE----- From rfc-editor@rfc-editor.org Fri Sep 4 15:20:22 2009 Return-Path: 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 5A8073A6850; Fri, 4 Sep 2009 15:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.526 X-Spam-Level: X-Spam-Status: No, score=-16.526 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 OuRGIyDfyaEU; Fri, 4 Sep 2009 15:20:21 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 8031E3A683D; Fri, 4 Sep 2009 15:20:21 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 3E6BE31548C; Fri, 4 Sep 2009 15:19:33 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090904221933.3E6BE31548C@bosco.isi.edu> Date: Fri, 4 Sep 2009 15:19:33 -0700 (PDT) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 5681 on TCP Congestion Control 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 22:20:22 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5681 Title: TCP Congestion Control Author: M. Allman, V. Paxson, E. Blanton Status: Standards Track Date: September 2009 Mailbox: mallman@icir.org, vern@icir.org, eblanton@cs.purdue.edu Pages: 18 Characters: 44339 Obsoletes: RFC2581 I-D Tag: draft-ietf-tcpm-rfc2581bis-07.txt URL: http://www.rfc-editor.org/rfc/rfc5681.txt This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581. [STANDARDS TRACK] This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Draft Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From root@core3.amsl.com Sat Sep 5 18:00:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9E36E3A6910; Sat, 5 Sep 2009 18:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090906010001.9E36E3A6910@core3.amsl.com> Date: Sat, 5 Sep 2009 18:00:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-ao-crypto-00.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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 01:00:01 -0000 --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 : Cryptographic Algorithms, Use, & Implementation Requirments for TCP Authentication Option Author(s) : G. Lebovitz, E. Rescorla Filename : draft-ietf-tcpm-tcp-ao-crypto-00.txt Pages : 17 Date : 2009-09-05 The TCP Authentication Option, TCP-AO, relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithm(s). This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-ao-crypto-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-tcpm-tcp-ao-crypto-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-05174756.I-D@ietf.org> --NextPart-- From Alexander.Zimmermann@nets.rwth-aachen.de Mon Sep 7 07:37:37 2009 Return-Path: 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 7476B3A69C0 for ; Mon, 7 Sep 2009 07:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.722 X-Spam-Level: X-Spam-Status: No, score=-3.722 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_05=-1.11, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] 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 suZIYIJHZdY8 for ; Mon, 7 Sep 2009 07:37:36 -0700 (PDT) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id 7D4033A6949 for ; Mon, 7 Sep 2009 07:37:36 -0700 (PDT) Received: from exchange-ts.nets.rwth-aachen.de (exchange-ts.nets.rwth-aachen.de [137.226.13.5]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id 5EC4957E66; Mon, 7 Sep 2009 16:38:03 +0200 (CEST) Received: from exchange-mb.nets.rwth-aachen.de ([2002:89e2:d06::89e2:d06]) by exchange-ts.nets.rwth-aachen.de ([2002:89e2:d05::89e2:d05]) with mapi; Mon, 7 Sep 2009 16:38:03 +0200 From: Alexander Zimmermann To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" Date: Mon, 7 Sep 2009 16:38:02 +0200 Thread-Topic: [tcpm] poll for adoption of SACK recovery entry drafty Thread-Index: AcovyM0LLwG+4S02RTOUFpQJH3Noaw== Message-ID: <45595CF4-95B3-46D0-ADEB-4F112CAB89CF@nets.rwth-aachen.de> References: In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of SACK recovery entry drafty 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 14:37:37 -0000 Hi all, since I have the feeling my last mail sent from my mobile is missing, I vote again: a) adopt this as a WG item for Proposed Standard Alex Am 01.09.2009 um 21:30 schrieb Eddy, Wesley M. (GRC-MS00)[Verizon]: > Hello, the authors of the SACK Recovery Entry draft: > http://tools.ietf.org/html/draft-jarvinen-tcpm-sack-recovery-entry-01 > have given a couple presentations to the WG now and asked if it > could be considered as an item for the WG for Proposed Standard (at > least I'm assuming PS because the I-D says "Intended Status: Standards > Track" ...). If I'm not mistaken, there has been some positive =20 > feedback > on the most recent incarnation, though not a lot, and not really any > negative feedback that I could see. > > As chairs, David and I are asking the WG to voice whether we should: > > A) adopt this as a WG item for Proposed Standard > B) NOT adopt this as a WG item > C) wait to decide (not ready) > > Please let us know what you think. > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From pasi.sarolahti@iki.fi Tue Sep 8 12:53:11 2009 Return-Path: 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 67C5228C2E7 for ; Tue, 8 Sep 2009 12:53:11 -0700 (PDT) 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=[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 wqU27Z05QXm5 for ; Tue, 8 Sep 2009 12:53:10 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 217B828C1AB for ; Tue, 8 Sep 2009 12:53:09 -0700 (PDT) Received: from wifi140.icsi.berkeley.edu (wifi140.icsi.berkeley.edu [192.150.187.140]) by argo.otaverkko.fi (Postfix) with ESMTP id CFF2A25ED10; Tue, 8 Sep 2009 22:53:38 +0300 (EEST) Message-Id: From: Pasi Sarolahti To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Sep 2009 12:53:36 -0700 References: X-Mailer: Apple Mail (2.936) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of long connectivity disruptions draft 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 19:53:11 -0000 Hi, I just read the LCD draft. Technically it looks good, and I think it would be ok for the TCPM start working on this as a WG item for Experimental RFC. Generally, I wonder if some kind of holistic overview of the documented TCP enhancements would be in place at some point. In the recent years quite a few of these have been introduced, that each help in a specific problem in some communication environments, but might not be so important for others. It might be useful to check that there are no unwanted interactions between the different schemes, or whether from the documents it is clear to the implementors how to implement RFCs A + B + C in a coherent manner with minimal additional implementation complexity. Then, some high-level comments on LCD draft: * The title would benefit from some tweaking. Maybe its just a matter of changing "Make" => "Making" * It might we worth noting in Section 3 when discussing ICMP message content that it assumes that the IP payload is not encrypted by IPsec. Probably other forms of tunneling might cause problems for ICMP, too. * Section 4.2, algorithm: this is really a nit, but might want to clarify in step (5) that if ICMP DU contains non-TCP header it should be ignored, without affecting the algorithm (right?) * It would be interesting to have an accompanying technical report on some (even preliminary) results on the performance improvements using the algorithm. It would also be interesting to have some understanding how often ICMP Destination unreachables actually arrive in case of a real connectivity disruption in real world. * Section 4.3, second paragraph says that with this algorithm "it has been proved that the retransmission was not lost due to congestion". This is a little questionable claim. I believe the algorithm is safe enough in congestion control aspects, but I'm not convinced that successful termination of the algorithm proves there is no congestion. So some rewording might be in place here. * Section 4.4: "TCP sender MAY use the following algorithm...." -- I believe something is missing here. There is no algorithm in this 3- line section. * You might consider if you just want to normatively refer directly RFC 1323 instead of the 1323bis draft. Is there something that has changed in 1323bis that is relevant for this document? (sometimes normative references to work-in-progress drafts have caused additional delays in the RFC ed queue, although I don't think that is much of a risk here) I will send some additional detailed nits directly to the authors. - Pasi On Sep 1, 2009, at 12:27 PM, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > Hello, the authors of the "Long Connectivity Disruptions" draft: > http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt > have given a couple presentations to the WG now and asked if it > could be considered as an item for the WG for Experimental. If > I'm not mistaken, there has been some positive feedback on the > most recent incarnation, though not a lot, and not really any > negative feedback that I could see. > > As chairs, David and I are asking the WG to voice whether we should: > > A) adopt this as a WG item for Experimental > B) NOT adopt this as a WG item > C) wait to decide (not ready) > > Please let us know what you think. > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@ISI.EDU Tue Sep 8 15:50:08 2009 Return-Path: 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 B26D93A6A04 for ; Tue, 8 Sep 2009 15:50:08 -0700 (PDT) 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=[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 tV64bAd3hoay for ; Tue, 8 Sep 2009 15:50:07 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 2D0A33A6822 for ; Tue, 8 Sep 2009 15:50:07 -0700 (PDT) Received: from [128.9.184.202] ([128.9.184.202]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n88MnZ6p024693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Sep 2009 15:49:36 -0700 (PDT) Message-ID: <4AA6DF7F.4040804@isi.edu> Date: Tue, 08 Sep 2009 15:49:35 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n88MnZ6p024693 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of long connectivity disruptions draft 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 22:50:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Overall, I think this is OK to adopt as experimental. Joe Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > Hello, the authors of the "Long Connectivity Disruptions" draft: > http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt > have given a couple presentations to the WG now and asked if it > could be considered as an item for the WG for Experimental. If > I'm not mistaken, there has been some positive feedback on the > most recent incarnation, though not a lot, and not really any > negative feedback that I could see. > > As chairs, David and I are asking the WG to voice whether we should: > > A) adopt this as a WG item for Experimental > B) NOT adopt this as a WG item > C) wait to decide (not ready) > > Please let us know what you think. > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqm338ACgkQE5f5cImnZrvw5wCePT223F7qQ5gLm5LqINpsg5ec wLYAn0TglLIzpERb+vd/5ZLaknbSGBSQ =pl3Y -----END PGP SIGNATURE----- From touch@ISI.EDU Tue Sep 8 15:50:14 2009 Return-Path: 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 0C9B33A6822 for ; Tue, 8 Sep 2009 15:50:14 -0700 (PDT) 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 aDGfL+5FKR10 for ; Tue, 8 Sep 2009 15:50:12 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id DE7BC3A6A34 for ; Tue, 8 Sep 2009 15:50:12 -0700 (PDT) Received: from [128.9.184.202] ([128.9.184.202]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n88MnHJc024677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Sep 2009 15:49:18 -0700 (PDT) Message-ID: <4AA6DF6D.10606@isi.edu> Date: Tue, 08 Sep 2009 15:49:17 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Pasi Sarolahti References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n88MnHJc024677 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of long connectivity disruptions draft 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 22:50:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pasi Sarolahti wrote: ... > * Section 4.2, algorithm: this is really a nit, but might want to > clarify in step (5) that if ICMP DU contains non-TCP header it should be > ignored, without affecting the algorithm (right?) It's not clear whether that is a feature or a bug. If you have TCP that's idle, and other packets from your host traverse a path and generate ICMP DUs, your TCP could benefit from reacting. I didn't see anything in 1122 that would prevent that. - -- FWIW, this draft continues the erroneous assumption that ICMPs are sent in a timely fashion. Routers aren't required to do this, and so the sequence number inside an ICMP should never be used as critical information. It'd be useful (if not important) to explain the impact of this on the algorithm in the draft. Hie -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqm32wACgkQE5f5cImnZruZ6QCgmy/Op6oqLMTq8XFoNSMNki6p 3zwAnRxph15X2K6pRQV1voL2PqJ3qVwf =rPsC -----END PGP SIGNATURE----- From touch@ISI.EDU Tue Sep 8 16:04:37 2009 Return-Path: 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 580933A683F for ; Tue, 8 Sep 2009 16:04:37 -0700 (PDT) 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=[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 Ig5wgp8r61MC for ; Tue, 8 Sep 2009 16:04:36 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 025363A6AB0 for ; Tue, 8 Sep 2009 16:04:35 -0700 (PDT) Received: from [128.9.184.202] ([128.9.184.202]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n88N3eEp027540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Sep 2009 16:03:41 -0700 (PDT) Message-ID: <4AA6E2CC.2000905@isi.edu> Date: Tue, 08 Sep 2009 16:03:40 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4A9F4AB1.6070605@gont.com.ar> In-Reply-To: <4A9F4AB1.6070605@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n88N3eEp027540 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Smith, Donald" , 'tcpm Extensions WG' , 'David Borman' Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 23:04:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Some additional feedback: - -- 2.1 indicates reasons why ICMPs are not reliable; it should include reasons why ICMPs could be late - so late that, e.g., sequence numbers aren't relevant. - -- In Sec 4.1: It should be note that as there are no timeliness for ICMP error messages, the TCP Sequence Number check described in this section might cause legitimate ICMP error messages to be discarded This should also note that it is also possible to end up acting on ICMPs that are old even when such checks are in place, depending on the lateness of the ICMP and the width of the valid sequence number window. - -- top Page 13, space is missing: synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT)as "soft errors". That is, they do ^ - -- Section 8 would benefit from a summary of the different techniques used (e.g., parameter checking to drop ICMPs, state checking to drop ICMPs, etc.) and a description of how each basic technique affects the system - i.e., they (in general) make the system more robust to deliberate attacks, but could make the system react less rapidly to legitimate network errors. This is a deliberate trade-off, and perhaps a reasonable one, but worth noting, IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqm4swACgkQE5f5cImnZrt64QCfYfRuDcVPdClVjcpIxSyWd9IL Q54AoMzxa0pGftaA8YcIODNmoLeipC2a =BQ+x -----END PGP SIGNATURE----- From fernando@gont.com.ar Tue Sep 8 22:11:20 2009 Return-Path: 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 EC1F33A6A9F for ; Tue, 8 Sep 2009 22:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.232 X-Spam-Level: X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 888pjtsSVlL5 for ; Tue, 8 Sep 2009 22:11:18 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 54E523A6B8C for ; Tue, 8 Sep 2009 22:11:17 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D23AB6B6723; Wed, 9 Sep 2009 02:11:54 -0300 (ART) Received: from [192.168.0.167] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id n895BkFU019854; Wed, 9 Sep 2009 02:11:47 -0300 Message-ID: <4AA73910.7080002@gont.com.ar> Date: Wed, 09 Sep 2009 02:11:44 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4A9F4AB1.6070605@gont.com.ar> <4AA6E2CC.2000905@isi.edu> In-Reply-To: <4AA6E2CC.2000905@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Wed, 09 Sep 2009 02:11:54 -0300 (ART) Cc: "Smith, Donald" , 'tcpm Extensions WG' , 'David Borman' Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 05:11:20 -0000 Hello, Joe, Thanks for your feedback! Comments in-line.... > - -- > 2.1 indicates reasons why ICMPs are not reliable; it should include > reasons why ICMPs could be late - so late that, e.g., sequence numbers > aren't relevant. > - -- Could you clarify what you have in mind, specificaly? ICMP error messages being assigned lower priority than normal traffic, or what? FWIW, routers typically rate-limit ICMP errors... > In Sec 4.1: > It should be note that as there are no timeliness for ICMP error > messages, the TCP Sequence Number check described in this section > might cause legitimate ICMP error messages to be discarded > > This should also note that it is also possible to end up acting on ICMPs > that are old even when such checks are in place, depending on the > lateness of the ICMP and the width of the valid sequence number window. I have no problem with this. However, the doc tries to address deliberate attacks rather than ligitimate old packets. That said, if you still feel this should be addressed in the document, please let me know and I will incorporate text about this.. > - -- > top Page 13, space is missing: > synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, > CLOSING, LAST-ACK or TIME-WAIT)as "soft errors". That is, they do Thanks! ^ > - -- > Section 8 would benefit from a summary of the different techniques used > (e.g., parameter checking to drop ICMPs, state checking to drop ICMPs, > etc.) and a description of how each basic technique affects the system - > i.e., they (in general) make the system more robust to deliberate > attacks, but could make the system react less rapidly to legitimate > network errors. This is a deliberate trade-off, and perhaps a reasonable > one, but worth noting, IMO. Will do. Thanks again! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando@gont.com.ar Tue Sep 8 22:35:57 2009 Return-Path: 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 5EF423A6804 for ; Tue, 8 Sep 2009 22:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 OvRWeB5EnMqZ for ; Tue, 8 Sep 2009 22:35:56 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 1D0343A672F for ; Tue, 8 Sep 2009 22:35:55 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 8409B6B681C; Wed, 9 Sep 2009 02:36:32 -0300 (ART) Received: from [192.168.0.167] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id n895aNsf027772; Wed, 9 Sep 2009 02:36:24 -0300 Message-ID: <4AA73ED5.6000806@gont.com.ar> Date: Wed, 09 Sep 2009 02:36:21 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: toby.moncaster@bt.com References: <200908262238.AAA06336@TR-Sys.de><4A9624CB.6040203@isi.edu> <4A9894C3.4020300@gont.com.ar><4A9AB5C2.4090209@isi.edu> <4A9CB254.7050802@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Wed, 09 Sep 2009 02:36:31 -0300 (ART) Cc: ah@tr-sys.de, tcpm@ietf.org, touch@ISI.EDU Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 05:35:57 -0000 Hello, Toby, Comments in-line... > I think there needs to be some form of hum relating to this. There seems > to be a relatively small number of people expressing relatively strong > opinions on this document that are clearly incompatible. One key thing, > regardless of how we actually decide to split the work, Fernando's > current ToC is too long... 3 pages of ToC is excessive. For the most part it's a three-page ToC because it's a 130+ page document. So no matter how the sections are reorganized, I don't think the ToC will get much shorter..... > I think the > sections aren't grouped at a high enough level (e.g. connection > establishment and tear-down could be in one section on connection > management, I have no problem with this. Probably the only drawback is that the corresponding sections will have a depth of four sections (i.e. one more level). But that shouldn't be a problem. Please let me know if you still feel this would improve the document, and I'll apply this change. > buffer management and re-assembly could probably be grouped > into memory management, etc). If you are referring to Section 7 and Section 8, one might argue that those are two different issues. Buffer management is memory management. Segment reassembly algorithm (Section 8) is about e.g., what you do if you get segments that overlap (which does not really have anything to do with how you manage memory). Nevertheless, if you have any specific proposal on how to merge these two sections, please let me know. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From lars.eggert@nokia.com Tue Sep 8 22:48:49 2009 Return-Path: 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 65E563A69B5 for ; Tue, 8 Sep 2009 22:48:49 -0700 (PDT) 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=[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 Tgo+qDZjX2cD for ; Tue, 8 Sep 2009 22:48:48 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 620C83A67A4 for ; Tue, 8 Sep 2009 22:48:31 -0700 (PDT) Received: from [192.168.11.109] ([88.218.117.32]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n895maNM046553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 9 Sep 2009 08:48:43 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: multipart/signed; boundary=Apple-Mail-68--709801162; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4AA73910.7080002@gont.com.ar> Date: Wed, 9 Sep 2009 08:48:25 +0300 Message-Id: References: <4A9F4AB1.6070605@gont.com.ar> <4AA6E2CC.2000905@isi.edu> <4AA73910.7080002@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1075.2) Cc: "Smith, Donald" , 'tcpm Extensions WG' , 'David Borman' , Joe Touch Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 05:48:49 -0000 --Apple-Mail-68--709801162 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On 2009-9-9, at 8:11, Fernando Gont wrote: > Could you clarify what you have in mind, specificaly? ICMP error > messages being assigned lower priority than normal traffic, or what? > FWIW, routers typically rate-limit ICMP errors... They are also sometimes forwarded at (much) lower priority, and esp. some CE devices have huge buffers that when full can lead to seconds of delay. (That's one factor why ICMPs may be arriving much later than the corresponding TCP segments, there may be others. (Who knows if some ITU-T transport network architecture defines a centralized "control plane signaling generator box" that sends out ICMPs on behalf of an entire network, for example. Yes, this is a made- up example.) Lars --Apple-Mail-68--709801162 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MDkwOTA1NDgyNlowIwYJKoZIhvcNAQkEMRYEFEsmRmRI2NLUGEY+j9ylE24Wkb2fMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQADZQvZUC6quz4hKjAyiiKImDz4RNu3W0Sey0cGU0RdsKEj3k4vPB5SMrWlHODkna65e5cC x6TvbKIgRRXRMU9rIqD0FVcvNM2QpX3/s7GL9dZ9pECYsVwZ7egk1BnnXpkQG3WASAhEz9KVfU+S +i4CveWMO3Y6kwLSP44KVtXOHjNeF6hEdX4r6YShjhICZWJWn9nTCvjFUUdBbZGMLFMqIVbFOqTc 17W0SR2aPXceTd+/FrStY+qf8wyV9jrGohjciO1KOstTRp5MszTWuRuKmtKS8XzsU/my4NOGaZbo 1YBQ1nUKy9NrGEtzLZYvszLYaXGsApU3nSjeGqLFXb17AAAAAAAA --Apple-Mail-68--709801162-- From fernando@gont.com.ar Tue Sep 8 22:59:21 2009 Return-Path: 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 396B43A6A8F for ; Tue, 8 Sep 2009 22:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 Mm6YeK6O3gkw for ; Tue, 8 Sep 2009 22:59:20 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 434163A681B for ; Tue, 8 Sep 2009 22:59:19 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D89056B67D5; Wed, 9 Sep 2009 02:59:56 -0300 (ART) Received: from [192.168.0.167] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id n895xmhi002337; Wed, 9 Sep 2009 02:59:49 -0300 Message-ID: <4AA74452.7060409@gont.com.ar> Date: Wed, 09 Sep 2009 02:59:46 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tcpm@ietf.org" X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Wed, 09 Sep 2009 02:59:56 -0300 (ART) Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] tcp-security: More feedback requested for the document outline 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 05:59:21 -0000 Folks, The original deadline for commenting on the document outline is over. These are the comments so far: * Joe: wants to change the outline from the current outline (which basically analyzes TCP on a "per-protocol-field", "per-protocol-mechanism" basis, etc.) to an outline that basically analyzes TCP on a "per-attack" basis (his proposal is available at: http://www.ietf.org/mail-archive/web/tcpm/current/msg04838.html) * Wesley: would like to change the outline as proposed by Joe, but could live without doing that. * Alfred: wants to leave the outline as is * Fernando: wants to leave the outline as is * Toby: wants to change the outline as proposed by Joe I don't personally see clear consensus for changing the outline (even less if we consider that many more people had agreed to accept the document "as is"). However, as there have not been that many opinions about the outline, I think it would be a good idea if wg participants that have not yet voiced their opinion regarding the document outline have another chance to do it. So let's set a new deadline for this second round off-comments: if you have any comments regarding the document outline, please voice your opinion till September 16th (Wednesday), 2009. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Tue Sep 8 23:08:00 2009 Return-Path: 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 EA4113A6A19 for ; Tue, 8 Sep 2009 23:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 uae+eYrdO5AA for ; Tue, 8 Sep 2009 23:08:00 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 01E5C3A69E1 for ; Tue, 8 Sep 2009 23:07:59 -0700 (PDT) Received: from [192.168.1.47] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n8967saX006816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Sep 2009 23:07:55 -0700 (PDT) Message-ID: <4AA74639.4000500@isi.edu> Date: Tue, 08 Sep 2009 23:07:53 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4A9F4AB1.6070605@gont.com.ar> <4AA6E2CC.2000905@isi.edu> <4AA73910.7080002@gont.com.ar> In-Reply-To: <4AA73910.7080002@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n8967saX006816 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Smith, Donald" , 'tcpm Extensions WG' , 'David Borman' Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 06:08:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Hello, Joe, > > Thanks for your feedback! Comments in-line.... > >> - -- >> 2.1 indicates reasons why ICMPs are not reliable; it should include >> reasons why ICMPs could be late - so late that, e.g., sequence numbers >> aren't relevant. >> - -- > > Could you clarify what you have in mind, specificaly? ICMP error > messages being assigned lower priority than normal traffic, or what? > FWIW, routers typically rate-limit ICMP errors... Routers aren't required to emit ICMP errors on any particular timescale. They can queue the events and get around to them - whenever. That includes queues, low priority processing, etc. Regardless of rate limiting, there's still no requirement about timeliness at all. >> In Sec 4.1: >> It should be note that as there are no timeliness for ICMP error >> messages, the TCP Sequence Number check described in this section >> might cause legitimate ICMP error messages to be discarded >> >> This should also note that it is also possible to end up acting on ICMPs >> that are old even when such checks are in place, depending on the >> lateness of the ICMP and the width of the valid sequence number window. > > I have no problem with this. However, the doc tries to address > deliberate attacks rather than ligitimate old packets. That said, if you > still feel this should be addressed in the document, please let me know > and I will incorporate text about this. The point is that the solutions tries to deal with deliberate attacks, but *in doing so* it changes how it reacts to legitimate events - whether legitimate old packets (above) or other legitimate events that would otherwise have been ignored (due to state). It's important to note this change. Joe >> - -- >> top Page 13, space is missing: >> synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, >> CLOSING, LAST-ACK or TIME-WAIT)as "soft errors". That is, they do > > Thanks! > > > ^ >> - -- >> Section 8 would benefit from a summary of the different techniques used >> (e.g., parameter checking to drop ICMPs, state checking to drop ICMPs, >> etc.) and a description of how each basic technique affects the system - >> i.e., they (in general) make the system more robust to deliberate >> attacks, but could make the system react less rapidly to legitimate >> network errors. This is a deliberate trade-off, and perhaps a reasonable >> one, but worth noting, IMO. > > Will do. > > Thanks again! > > Kind regards, -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqnRjkACgkQE5f5cImnZrsmZACg7OrUOrfV8HMx7jmXSndfolRO 0iQAoNnVicCl6ZMdLw5wj+PunXcY6zzz =EjYy -----END PGP SIGNATURE----- From touch@ISI.EDU Tue Sep 8 23:18:04 2009 Return-Path: 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 560003A6ACF for ; Tue, 8 Sep 2009 23:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 hPApODQAWx2z for ; Tue, 8 Sep 2009 23:18:03 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 73B6E3A6A59 for ; Tue, 8 Sep 2009 23:18:03 -0700 (PDT) Received: from [192.168.1.47] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n896HrGF008411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Sep 2009 23:17:54 -0700 (PDT) Message-ID: <4AA74891.4000407@isi.edu> Date: Tue, 08 Sep 2009 23:17:53 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4AA74452.7060409@gont.com.ar> In-Reply-To: <4AA74452.7060409@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n896HrGF008411 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] tcp-security: More feedback requested for the document outline 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 06:18:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Folks, > > The original deadline for commenting on the document outline is over. > These are the comments so far: > > * Joe: wants to change the outline from the current outline (which > basically analyzes TCP on a "per-protocol-field", > "per-protocol-mechanism" basis, etc.) to an outline that basically > analyzes TCP on a "per-attack" basis (his proposal is available at: > http://www.ietf.org/mail-archive/web/tcpm/current/msg04838.html) The outline I proposed breaks things down into groups based on: control plane in-band control plane out-of-band data plane API This is (loosely) based on how TCP is specified (order not withstanding). Although I did suggest talking about attacks first, then talking about mitigations (to separate the two, because a single attack can have multiple mitigations, and a single mitigation can inhibit multiple attacks), the overall structure is not per-attack as much as it based on breaking the protocol down into its component parts. - --- It also distinguishes between protocol weaknesses (places where the protocol creates a vulnerability, regardless of implementation - e.g., ICMP attacks), implementation choice issues (places where a choice left to implementers can cause problems if poorly chosen - e.g., how some SHOULDs turn into "don't do this in a secure implementation"), and implementation vulnerabilities (implementation issues not related to choices in the spec that create problems - e.g., searching the TIME-WAIT list linearly). Regardless of how we proceed, I believe that this latter issue should be considered in the presentation of solutions. > * Wesley: would like to change the outline as proposed by Joe, but could > live without doing that. > > * Alfred: wants to leave the outline as is > > * Fernando: wants to leave the outline as is > > * Toby: wants to change the outline as proposed by Joe > > I don't personally see clear consensus for changing the outline (even > less if we consider that many more people had agreed to accept the > document "as is"). > > However, as there have not been that many opinions about the outline, I > think it would be a good idea if wg participants that have not yet > voiced their opinion regarding the document outline have another chance > to do it. > > So let's set a new deadline for this second round off-comments: if you > have any comments regarding the document outline, please voice your > opinion till September 16th (Wednesday), 2009. > > Thanks! > > Kind regards, -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqnSJEACgkQE5f5cImnZrvSDACg07iCr3uC1ORZ8rvT3PWYrbmq yDYAoKzt6bDekRm6c5HLvgmDVenPW2m1 =Qg/w -----END PGP SIGNATURE----- From fernando@gont.com.ar Wed Sep 9 00:27:22 2009 Return-Path: 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 49C9928C122 for ; Wed, 9 Sep 2009 00:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 EuKtlYNzUfvq for ; Wed, 9 Sep 2009 00:27:21 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 7176C3A68D9 for ; Wed, 9 Sep 2009 00:27:20 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id B15FC6B6620; Wed, 9 Sep 2009 04:27:51 -0300 (ART) Received: from [192.168.0.167] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id n897RnFb002629; Wed, 9 Sep 2009 04:27:50 -0300 Message-ID: <4AA758F3.1080907@gont.com.ar> Date: Wed, 09 Sep 2009 04:27:47 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4AA74452.7060409@gont.com.ar> <4AA74891.4000407@isi.edu> In-Reply-To: <4AA74891.4000407@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Wed, 09 Sep 2009 04:27:51 -0300 (ART) Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] tcp-security: More feedback requested for the document outline 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 07:27:22 -0000 Hi, Joe, > It also distinguishes between protocol weaknesses (places where the > protocol creates a vulnerability, regardless of implementation - e.g., > ICMP attacks), implementation choice issues (places where a choice left > to implementers can cause problems if poorly chosen - e.g., how some > SHOULDs turn into "don't do this in a secure implementation"), and > implementation vulnerabilities (implementation issues not related to > choices in the spec that create problems - e.g., searching the TIME-WAIT > list linearly). > > Regardless of how we proceed, I believe that this latter issue should be > considered in the presentation of solutions. Yes. I think somebody else (David Borman?) already raised this issue. As we start discussing the technical stuff, I will make sure it is clear whether it's a protocol issue, an implementation issue, etc., whether the specs mandate the behavior as a MUST, SHOULD (or whatever), and whether the countermeasures comply with the specs or go against them. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From lars.eggert@nokia.com Wed Sep 9 00:34:50 2009 Return-Path: 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 CC70528C141 for ; Wed, 9 Sep 2009 00:34:50 -0700 (PDT) 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 Lu7AsehA6UG5 for ; Wed, 9 Sep 2009 00:34:50 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id B97393A6843 for ; Wed, 9 Sep 2009 00:34:49 -0700 (PDT) Received: from lars.lan (e701.rooms.aueb.gr [195.251.233.136]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n897Z3RN052917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 9 Sep 2009 10:35:04 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: multipart/signed; boundary=Apple-Mail-74--703403583; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4AA74452.7060409@gont.com.ar> Date: Wed, 9 Sep 2009 10:35:03 +0300 Message-Id: References: <4AA74452.7060409@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1075.2) Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] tcp-security: More feedback requested for the document outline 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 07:34:50 -0000 --Apple-Mail-74--703403583 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On 2009-9-9, at 8:59, Fernando Gont wrote: > So let's set a new deadline for this second round off-comments: if you > have any comments regarding the document outline, please voice your > opinion till September 16th (Wednesday), 2009. Since you asked: As an individual, I have a preference for Joe's proposed outline. It's not a very strong one, however. Lars --Apple-Mail-74--703403583 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MDkwOTA3MzUwM1owIwYJKoZIhvcNAQkEMRYEFDse6m25HoTCpJE72L0yukdLybAjMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQA+lK5PX7HbMvdUhKQmwcTRJkCd0G53HN0AydB+bstB5LIGNt7B1wrfzIRfIbxUiOCTYzne PzG56NAeYS2qP/PiAZXhYTSztJe23jtKPtm22HaEPiK04zlhBtJvDTWoMDtwbwIKgPxE0dzdLmYl wVMHqpQXe+q4dugad3XX3mG8aUTx2PN3T4jQewo/Hq2y/lpf9OZ7qHGupDlxjiqm7+ZDwIyWU5qv jJUbGaRbS/YHdtD4n5e8EdcpVGOxs0ImKPqB8KvsKOHGmJO4Xzadf2UrkrYdBcWE6sHmRGRzGewH /VMGq/62iWUNuDxucg7uIt80b+A9pOyA/UY+0f9vprGNAAAAAAAA --Apple-Mail-74--703403583-- From Alexander.Zimmermann@nets.rwth-aachen.de Wed Sep 9 06:42:22 2009 Return-Path: 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 5F6D028C3FE for ; Wed, 9 Sep 2009 06:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.415 X-Spam-Level: X-Spam-Status: No, score=-4.415 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] 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 Yhq4npEOyWeE for ; Wed, 9 Sep 2009 06:42:20 -0700 (PDT) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id 7962B28C135 for ; Wed, 9 Sep 2009 06:42:20 -0700 (PDT) Received: from exchange-ts.nets.rwth-aachen.de (exchange-ts.nets.rwth-aachen.de [137.226.13.5]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id 41F0157C02; Wed, 9 Sep 2009 15:42:52 +0200 (CEST) Received: from exchange-mb.nets.rwth-aachen.de ([2002:89e2:d06::89e2:d06]) by exchange-ts.nets.rwth-aachen.de ([2002:89e2:d05::89e2:d05]) with mapi; Wed, 9 Sep 2009 15:42:52 +0200 From: Alexander Zimmermann To: Pasi Sarolahti Date: Wed, 9 Sep 2009 15:42:52 +0200 Thread-Topic: [tcpm] poll for adoption of long connectivity disruptions draft Thread-Index: AcoxU2zWA2Lb0OljSUSZ5oLG+uYSwQ== Message-ID: <5D7CC3AE-684A-4E25-9325-318700E30B5F@nets.rwth-aachen.de> References: In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of long connectivity disruptions draft 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 13:42:22 -0000 Hi Pasi, thank you so much for the review. Comments are inline. Alex Am 08.09.2009 um 21:53 schrieb Pasi Sarolahti: > Hi, > > I just read the LCD draft. Technically it looks good, and I think it > would be ok for the TCPM start working on this as a WG item for > Experimental RFC. > > Generally, I wonder if some kind of holistic overview of the > documented TCP enhancements would be in place at some point. In the > recent years quite a few of these have been introduced, that each help > in a specific problem in some communication environments, but might > not be so important for others. It might be useful to check that there > are no unwanted interactions between the different schemes, or whether > from the documents it is clear to the implementors how to implement > RFCs A + B + C in a coherent manner with minimal additional > implementation complexity. > > Then, some high-level comments on LCD draft: > > * The title would benefit from some tweaking. Maybe its just a matter > of changing "Make" =3D> "Making" Ok, we will change the title to "Making TCP more Robust to Long =20 Connectivity Disruptions". I'm also fine with changing it to something completely =20 different, are there any suggestions? > > * It might we worth noting in Section 3 when discussing ICMP message > content that it assumes that the IP payload is not encrypted by IPsec. > Probably other forms of tunneling might cause problems for ICMP, too. Ack. We will come up with something describing the issues you mention. This seems to be a general problem for the IP layer (see below). > > * Section 4.2, algorithm: this is really a nit, but might want to > clarify in step (5) that if ICMP DU contains non-TCP header it should > be ignored, without affecting the algorithm (right?) In our algorithm we assume that the ICMP error message is passed up from the IP layer, for the corresponding connection. (See RFC 1122 Section 4.2.3.9 ). Ack, we will make this more clear. However, I think the fact that the ICMP message already got demultiplexed implies that the ICMP DU contains a TCP header, otherwise we would "not see" this ICMP DU at this layer. > > * It would be interesting to have an accompanying technical report on > some (even preliminary) results on the performance improvements using > the algorithm. It would also be interesting to have some understanding > how often ICMP Destination unreachables actually arrive in case of a > real connectivity disruption in real world. Depends on what you mean with "real world" we have already presented some measurements with Linux routers, see the slides from the last IETF meetings. And the ICMP DU arrive surprisingly reliable. However, we did not test juniper or cisco yet... > > * Section 4.3, second paragraph says that with this algorithm "it has > been proved that the retransmission was not lost due to congestion". > This is a little questionable claim. I believe the algorithm is safe > enough in congestion control aspects, but I'm not convinced that > successful termination of the algorithm proves there is no congestion. > So some rewording might be in place here. Ack. > > * Section 4.4: "TCP sender MAY use the following algorithm...." -- I > believe something is missing here. There is no algorithm in this 3- > line section. Yeah, I know :-) See Appendix A: TODO list > * You might consider if you just want to normatively refer directly > RFC 1323 instead of the 1323bis draft. Is there something that has > changed in 1323bis that is relevant for this document? (sometimes > normative references to work-in-progress drafts have caused additional > delays in the RFC ed queue, although I don't think that is much of a > risk here) I don't think there is something relevant. I only thought that 1323bis would be published before "our" RFC and wanted to avoid an outdated reference list ;-). > > I will send some additional detailed nits directly to the authors. > > - Pasi > > > On Sep 1, 2009, at 12:27 PM, Eddy, Wesley M. (GRC-MS00)[Verizon] =20 > wrote: > >> Hello, the authors of the "Long Connectivity Disruptions" draft: >> http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt >> have given a couple presentations to the WG now and asked if it >> could be considered as an item for the WG for Experimental. If >> I'm not mistaken, there has been some positive feedback on the >> most recent incarnation, though not a lot, and not really any >> negative feedback that I could see. >> >> As chairs, David and I are asking the WG to voice whether we should: >> >> A) adopt this as a WG item for Experimental >> B) NOT adopt this as a WG item >> C) wait to decide (not ready) >> >> Please let us know what you think. >> >> --------------------------- >> Wes Eddy >> Network & Systems Architect >> Verizon FNS / NASA GRC >> Office: (216) 433-6682 >> --------------------------- >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From cpignata@cisco.com Wed Sep 9 07:09:32 2009 Return-Path: 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 ABF853A688F for ; Wed, 9 Sep 2009 07:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.994 X-Spam-Level: X-Spam-Status: No, score=-5.994 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, J_BACKHAIR_22=1, RCVD_IN_DNSWL_MED=-4] 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 ClqOz0HNO3+P for ; Wed, 9 Sep 2009 07:09:31 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id A3B923A67A8 for ; Wed, 9 Sep 2009 07:09:31 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n89EA0NC016098; Wed, 9 Sep 2009 10:10:00 -0400 (EDT) Received: from [10.116.85.238] (rtp-cpignata-87113.cisco.com [10.116.85.238]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n89EA08r020780; Wed, 9 Sep 2009 10:10:00 -0400 (EDT) Message-ID: <4AA7B738.10400@cisco.com> Date: Wed, 09 Sep 2009 10:10:00 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Joe Touch References: <4A9F4AB1.6070605@gont.com.ar> <4AA6E2CC.2000905@isi.edu> <4AA73910.7080002@gont.com.ar> <4AA74639.4000500@isi.edu> In-Reply-To: <4AA74639.4000500@isi.edu> X-Enigmail-Version: 0.96.0 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "Smith, Donald" , 'tcpm Extensions WG' , 'David Borman' , Fernando Gont Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 14:09:32 -0000 Please find a couple of comments inline. On 9/9/2009 2:07 AM, Joe Touch wrote: > > > Fernando Gont wrote: >> Hello, Joe, > >> Thanks for your feedback! Comments in-line.... > >>> - -- >>> 2.1 indicates reasons why ICMPs are not reliable; it should include >>> reasons why ICMPs could be late - so late that, e.g., sequence numbers >>> aren't relevant. >>> - -- >> Could you clarify what you have in mind, specificaly? ICMP error >> messages being assigned lower priority than normal traffic, or what? >> FWIW, routers typically rate-limit ICMP errors... > > Routers aren't required to emit ICMP errors on any particular timescale. > They can queue the events and get around to them - whenever. IMHO, this comment might need some realistic qualification -- "whenever" seems overly excessive and too dramatic in real life. Routers do not try to do busywork and delay ICMP generation (exaggeration purposely intended to counter-balance). > That > includes queues, low priority processing, etc. Regardless of rate > limiting, there's still no requirement about timeliness at all. Yes, router architectures get more complex, but so do solutions. In many architectures, for example, ICMPs are generated by the line-card CPU, avoiding any central RP delay, and RP<->LC path. The more busy the router could get, the more switching is done in hardware, and the more free cycles control-plane CPUs get. My 2¢. If it feels like déjà vu, this topic was discussed at: Joe Touch > Routers are not required to return ICMPs on any particular Joe Touch > timescale. thread started at: Thanks, -- Carlos. > >>> In Sec 4.1: >>> It should be note that as there are no timeliness for ICMP error >>> messages, the TCP Sequence Number check described in this section >>> might cause legitimate ICMP error messages to be discarded >>> >>> This should also note that it is also possible to end up acting on ICMPs >>> that are old even when such checks are in place, depending on the >>> lateness of the ICMP and the width of the valid sequence number window. >> I have no problem with this. However, the doc tries to address >> deliberate attacks rather than ligitimate old packets. That said, if you >> still feel this should be addressed in the document, please let me know >> and I will incorporate text about this. > > The point is that the solutions tries to deal with deliberate attacks, > but *in doing so* it changes how it reacts to legitimate events - > whether legitimate old packets (above) or other legitimate events that > would otherwise have been ignored (due to state). It's important to note > this change. > > Joe > >>> - -- >>> top Page 13, space is missing: >>> synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, >>> CLOSING, LAST-ACK or TIME-WAIT)as "soft errors". That is, they do >> Thanks! > > >> ^ >>> - -- >>> Section 8 would benefit from a summary of the different techniques used >>> (e.g., parameter checking to drop ICMPs, state checking to drop ICMPs, >>> etc.) and a description of how each basic technique affects the system - >>> i.e., they (in general) make the system more robust to deliberate >>> attacks, but could make the system react less rapidly to legitimate >>> network errors. This is a deliberate trade-off, and perhaps a reasonable >>> one, but worth noting, IMO. >> Will do. > >> Thanks again! > >> Kind regards, _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From touch@ISI.EDU Wed Sep 9 07:18:54 2009 Return-Path: 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 04A2A3A6912 for ; Wed, 9 Sep 2009 07:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, J_BACKHAIR_22=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 KV5CU4wMFUdQ for ; Wed, 9 Sep 2009 07:18:53 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 86AD028C203 for ; Wed, 9 Sep 2009 07:18:26 -0700 (PDT) Received: from [192.168.1.47] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n89EIPFl016291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Sep 2009 07:18:27 -0700 (PDT) Message-ID: <4AA7B930.10300@isi.edu> Date: Wed, 09 Sep 2009 07:18:24 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Carlos Pignataro References: <4A9F4AB1.6070605@gont.com.ar> <4AA6E2CC.2000905@isi.edu> <4AA73910.7080002@gont.com.ar> <4AA74639.4000500@isi.edu> <4AA7B738.10400@cisco.com> In-Reply-To: <4AA7B738.10400@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Smith, Donald" , 'tcpm Extensions WG' , 'David Borman' , Fernando Gont Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 14:18:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carlos Pignataro wrote: > Please find a couple of comments inline. > > On 9/9/2009 2:07 AM, Joe Touch wrote: >> >> Fernando Gont wrote: >>> Hello, Joe, >>> Thanks for your feedback! Comments in-line.... >>>> - -- >>>> 2.1 indicates reasons why ICMPs are not reliable; it should include >>>> reasons why ICMPs could be late - so late that, e.g., sequence numbers >>>> aren't relevant. >>>> - -- >>> Could you clarify what you have in mind, specificaly? ICMP error >>> messages being assigned lower priority than normal traffic, or what? >>> FWIW, routers typically rate-limit ICMP errors... >> Routers aren't required to emit ICMP errors on any particular timescale. >> They can queue the events and get around to them - whenever. > > IMHO, this comment might need some realistic qualification -- "whenever" > seems overly excessive and too dramatic in real life. Routers do not try > to do busywork and delay ICMP generation (exaggeration purposely > intended to counter-balance). "whenever" is when routers get to do it. Consider a router that has an error in its queue to process. A user installs an upgrade and reboots it, during which it is offline. Or it goes down and comes back for power reasons. In either case, there is *no* requirement that such errors be flushed. Routers sometimes get locked up doing various things. Their control planes often operate completely independently of the data plane, and have priorities that can starve various routines that aren't required to be timely. Errors that get hit with that could end up on the wire seconds, minutes - *any* time later. And they'd be *compliant* with FC1812. >> That >> includes queues, low priority processing, etc. Regardless of rate >> limiting, there's still no requirement about timeliness at all. > > Yes, router architectures get more complex, but so do solutions. In many > architectures, for example, ICMPs are generated by the line-card CPU, > avoiding any central RP delay, and RP<->LC path. The more busy the > router could get, the more switching is done in hardware, and the more > free cycles control-plane CPUs get. My 2¢. > > If it feels like déjà vu, this topic was discussed at: > > Joe Touch > Routers are not required to return ICMPs on any particular > Joe Touch > timescale. > thread started at: > I raised it several times before. Bob Braden reiterated it in the microphone line at an IETF a while ago too. It never made it into this doc, however, and it should. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqnuTAACgkQE5f5cImnZrsY6QCfUEBATafVEX80QuC1qpS7r34s h10Anjni76IiXXNzQaFfLTh+G5F4LQFt =4My3 -----END PGP SIGNATURE----- From cpignata@cisco.com Wed Sep 9 07:46:33 2009 Return-Path: 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 2A12A3A6C31 for ; Wed, 9 Sep 2009 07:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.958 X-Spam-Level: X-Spam-Status: No, score=-5.958 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, J_BACKHAIR_22=1, RCVD_IN_DNSWL_MED=-4] 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 KV5xZo9vCHhd for ; Wed, 9 Sep 2009 07:46:32 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 0B2AE3A67D8 for ; Wed, 9 Sep 2009 07:46:31 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n89El1WN018405; Wed, 9 Sep 2009 10:47:01 -0400 (EDT) Received: from [10.116.85.238] (rtp-cpignata-87113.cisco.com [10.116.85.238]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n89El0ZA009505; Wed, 9 Sep 2009 10:47:01 -0400 (EDT) Message-ID: <4AA7BFE4.5050209@cisco.com> Date: Wed, 09 Sep 2009 10:47:00 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Joe Touch References: <4A9F4AB1.6070605@gont.com.ar> <4AA6E2CC.2000905@isi.edu> <4AA73910.7080002@gont.com.ar> <4AA74639.4000500@isi.edu> <4AA7B738.10400@cisco.com> <4AA7B930.10300@isi.edu> In-Reply-To: <4AA7B930.10300@isi.edu> X-Enigmail-Version: 0.96.0 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "Smith, Donald" , 'tcpm Extensions WG' , 'David Borman' , Fernando Gont Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 14:46:33 -0000 Joe, Thanks for the response, please see inline. On 9/9/2009 10:18 AM, Joe Touch wrote: > > > Carlos Pignataro wrote: >> Please find a couple of comments inline. > >> On 9/9/2009 2:07 AM, Joe Touch wrote: >>> Fernando Gont wrote: >>>> Hello, Joe, >>>> Thanks for your feedback! Comments in-line.... >>>>> - -- >>>>> 2.1 indicates reasons why ICMPs are not reliable; it should include >>>>> reasons why ICMPs could be late - so late that, e.g., sequence numbers >>>>> aren't relevant. >>>>> - -- >>>> Could you clarify what you have in mind, specificaly? ICMP error >>>> messages being assigned lower priority than normal traffic, or what? >>>> FWIW, routers typically rate-limit ICMP errors... >>> Routers aren't required to emit ICMP errors on any particular timescale. >>> They can queue the events and get around to them - whenever. >> IMHO, this comment might need some realistic qualification -- "whenever" >> seems overly excessive and too dramatic in real life. Routers do not try >> to do busywork and delay ICMP generation (exaggeration purposely >> intended to counter-balance). > > "whenever" is when routers get to do it. Consider a router that has an > error in its queue to process. A user installs an upgrade and reboots > it, during which it is offline. Or it goes down and comes back for power > reasons. In either case, there is *no* requirement that such errors be > flushed. > > Routers sometimes get locked up doing various things. Their control > planes often operate completely independently of the data plane, and > have priorities that can starve various routines that aren't required to > be timely. Errors that get hit with that could end up on the wire > seconds, minutes - *any* time later. My point was not about impossibility, but about qualifying these possibilities with a of tint of (and gauge them with their degree of) operational realism. Have you (personally or second hand) seen an ICMP being delayed by minutes? > > And they'd be *compliant* with FC1812. I think that it should refer to what the specs envision, and not necessarily to an ICMP delayed several minutes during an upgrade: e.g., rate-limit as per ; note that for example the specs even deal with ICMP generation for bursts of traffic (e.g., traceroute), at item (f). > >>> That >>> includes queues, low priority processing, etc. Regardless of rate >>> limiting, there's still no requirement about timeliness at all. >> Yes, router architectures get more complex, but so do solutions. In many >> architectures, for example, ICMPs are generated by the line-card CPU, >> avoiding any central RP delay, and RP<->LC path. The more busy the >> router could get, the more switching is done in hardware, and the more >> free cycles control-plane CPUs get. My 2¢. > >> If it feels like déjà vu, this topic was discussed at: >> >> Joe Touch > Routers are not required to return ICMPs on any particular >> Joe Touch > timescale. >> thread started at: >> > > I raised it several times before. Bob Braden reiterated it in the > microphone line at an IETF a while ago too. It never made it into this > doc, however, and it should. The document says the following; would s/discarded/discarded or delayed/ cover it? It is important to note that ICMP error messages are unreliable, and may be discarded due to data corruption, network congestion or rate- limiting. Thus, while they provide useful information, upper layer protocols cannot depend on ICMP for correct operation. Thanks, -- Carlos. > > Joe > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From touch@ISI.EDU Wed Sep 9 08:01:04 2009 Return-Path: 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 E2D003A698E for ; Wed, 9 Sep 2009 08:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 wVZEJX8vVjRf for ; Wed, 9 Sep 2009 08:01:04 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 18D893A67D8 for ; Wed, 9 Sep 2009 08:01:04 -0700 (PDT) Received: from [192.168.1.47] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n89F0xHu026490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Sep 2009 08:01:02 -0700 (PDT) Message-ID: <4AA7C32B.3020606@isi.edu> Date: Wed, 09 Sep 2009 08:00:59 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Carlos Pignataro References: <4A9F4AB1.6070605@gont.com.ar> <4AA6E2CC.2000905@isi.edu> <4AA73910.7080002@gont.com.ar> <4AA74639.4000500@isi.edu> <4AA7B738.10400@cisco.com> <4AA7B930.10300@isi.edu> <4AA7BFE4.5050209@cisco.com> In-Reply-To: <4AA7BFE4.5050209@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Smith, Donald" , 'tcpm Extensions WG' , 'David Borman' , Fernando Gont Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:01:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carlos Pignataro wrote: ... > The document says the following; would s/discarded/discarded or delayed/ > cover it? > > It is important to note that ICMP error messages are unreliable, and > may be discarded due to data corruption, network congestion or rate- > limiting. Thus, while they provide useful information, upper layer > protocols cannot depend on ICMP for correct operation. That would help there, but it is also useful in other places to indicate what happens when a legitimate ICMP is delayed, i.e., how that affects what your algorithm would do. It's OK to qualify it with "this is unlikely", but IMO it needs to be discussed with more than a single word in a single paragraph. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqnwysACgkQE5f5cImnZrvcNACguSsF9p5U0pEOhvnWDsp4NOjL XSAAmwSLA8HQjZz0ORO6z9WhL8y6wPAn =PuSR -----END PGP SIGNATURE----- From cpignata@cisco.com Wed Sep 9 08:11:47 2009 Return-Path: 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 29FC828C238 for ; Wed, 9 Sep 2009 08:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 7+wboHBAkuuq for ; Wed, 9 Sep 2009 08:11:46 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 360A428C2CB for ; Wed, 9 Sep 2009 08:11:46 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n89FCGq0019937; Wed, 9 Sep 2009 11:12:16 -0400 (EDT) Received: from [10.116.85.238] (rtp-cpignata-87113.cisco.com [10.116.85.238]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n89FCFZ3014907; Wed, 9 Sep 2009 11:12:16 -0400 (EDT) Message-ID: <4AA7C5CF.10400@cisco.com> Date: Wed, 09 Sep 2009 11:12:15 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Joe Touch References: <4A9F4AB1.6070605@gont.com.ar> <4AA6E2CC.2000905@isi.edu> <4AA73910.7080002@gont.com.ar> <4AA74639.4000500@isi.edu> <4AA7B738.10400@cisco.com> <4AA7B930.10300@isi.edu> <4AA7BFE4.5050209@cisco.com> <4AA7C32B.3020606@isi.edu> In-Reply-To: <4AA7C32B.3020606@isi.edu> X-Enigmail-Version: 0.96.0 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Smith, Donald" , 'tcpm Extensions WG' , 'David Borman' , Fernando Gont Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:11:47 -0000 On 9/9/2009 11:00 AM, Joe Touch wrote: > > > Carlos Pignataro wrote: > ... >> The document says the following; would s/discarded/discarded or delayed/ >> cover it? > >> It is important to note that ICMP error messages are unreliable, and >> may be discarded due to data corruption, network congestion or rate- >> limiting. Thus, while they provide useful information, upper layer >> protocols cannot depend on ICMP for correct operation. > > That would help there, but it is also useful in other places to indicate > what happens when a legitimate ICMP is delayed, i.e., how that affects > what your algorithm would do. > > It's OK to qualify it with "this is unlikely", but IMO it needs to be > discussed with more than a single word in a single paragraph. I think that "this is unlikely" or "this is highly unlikely" would still be understating the probability (I am curious to see any experienced example of ICMP being delayed minutes). Redundancy architectures of routers typically cover the planned upgrade (or even unexpected reload) scenarios you presented. Perhaps a separate sentence in that paragraph before the "Thus, " with some variation of "rate-limiting can delay ICMPs, and some other highly unlikely theoretical scenarios can compound the delay"? Thanks, -- Carlos. > > Joe From touch@ISI.EDU Wed Sep 9 08:21:05 2009 Return-Path: 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 8DA7228C2C9 for ; Wed, 9 Sep 2009 08:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 WTKuDgLHjFi3 for ; Wed, 9 Sep 2009 08:21:04 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 87DAF28C190 for ; Wed, 9 Sep 2009 08:21:04 -0700 (PDT) Received: from [192.168.1.47] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n89FL1GV001297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Sep 2009 08:21:03 -0700 (PDT) Message-ID: <4AA7C7DD.1000504@isi.edu> Date: Wed, 09 Sep 2009 08:21:01 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Carlos Pignataro References: <4A9F4AB1.6070605@gont.com.ar> <4AA6E2CC.2000905@isi.edu> <4AA73910.7080002@gont.com.ar> <4AA74639.4000500@isi.edu> <4AA7B738.10400@cisco.com> <4AA7B930.10300@isi.edu> <4AA7BFE4.5050209@cisco.com> <4AA7C32B.3020606@isi.edu> <4AA7C5CF.10400@cisco.com> In-Reply-To: <4AA7C5CF.10400@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Smith, Donald" , 'tcpm Extensions WG' , 'David Borman' , Fernando Gont Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:21:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carlos Pignataro wrote: ... >> It's OK to qualify it with "this is unlikely", but IMO it needs to be >> discussed with more than a single word in a single paragraph. > > I think that "this is unlikely" or "this is highly unlikely" would still > be understating the probability (I am curious to see any experienced > example of ICMP being delayed minutes). Redundancy architectures of > routers typically cover the planned upgrade (or even unexpected reload) > scenarios you presented. > > Perhaps a separate sentence in that paragraph before the "Thus, " with > some variation of "rate-limiting can delay ICMPs, and some other highly > unlikely theoretical scenarios can compound the delay"? You can't rely on something that isn't required. The fact that current implementations, in current operation, don't do this isn't relevant. Consider the proposal to resend 'the last packets seen' after a link outage, to 'tickle' TCP into waking up. That proposal was considered inappropriate because the router would hold the packet too long to satisfy requirements. However, if someone were to propose to hold ICMPs and issue them later, that would be *compliant*. Protocols aren't just about what happens to work today; they're about what you can expect to work tomorrow too. Anything that examines the contents of an ICMP needs to appreciate that those contents do NOT have to obey timeliness requirements - notably of the protocol being conveyed as payload. You need to explain what happens when your assumptions are wrong not because they're often wrong today, but because you cannot know whether they'll be wrong tomorrow. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqnx90ACgkQE5f5cImnZrvguwCgrm7/fLMiKak8gGb0QYQsROeK 5bcAn0fxfPIznaScGG9Tx0oq0OjCHk8x =xegI -----END PGP SIGNATURE----- From ananth@cisco.com Wed Sep 9 08:56:39 2009 Return-Path: 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 43BAC28C44E for ; Wed, 9 Sep 2009 08:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] 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 xtPdImwNTGVF for ; Wed, 9 Sep 2009 08:56:38 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id DB04228C29C for ; Wed, 9 Sep 2009 08:56:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,359,1249257600"; d="scan'208";a="188459834" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 09 Sep 2009 15:57:10 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n89FvAiC032126; Wed, 9 Sep 2009 08:57:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n89FvAgk029043; Wed, 9 Sep 2009 15:57:10 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 08:57:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Sep 2009 08:57:09 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5807F84E7A@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4AA7C7DD.1000504@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WG Last Call for ICMP Attacks Thread-Index: AcoxYTxr8TsqCXHrQnqry7pveb+GcQAAWSnw References: <4A9F4AB1.6070605@gont.com.ar> <4AA6E2CC.2000905@isi.edu> <4AA73910.7080002@gont.com.ar><4AA74639.4000500@isi.edu> <4AA7B738.10400@cisco.com><4AA7B930.10300@isi.edu> <4AA7BFE4.5050209@cisco.com><4AA7C32B.3020606@isi.edu> <4AA7C5CF.10400@cisco.com> <4AA7C7DD.1000504@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Carlos Pignataro (cpignata)" X-OriginalArrivalTime: 09 Sep 2009 15:57:10.0619 (UTC) FILETIME=[30A782B0:01CA3166] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4539; t=1252511830; x=1253375830; 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]=20WG=20Last=20Call=20for=20ICMP= 20Attacks |Sender:=20; bh=dqCoJ8dFtaFlVXmEY3b+U8isSVrGlz31lw4P5oViayQ=; b=sCUSJQaHcy0krG6sdxPoqi2unfebYe0G12faE9CWS/2Oqwgmfpth0K2A8Z PVZks7/c6lBDV8MzbXoKtLQimRBhG+AVwmEDy7D+YNiG45qye/K913xO+iyt NB9ZmDvx0YtqhhUZ0tj9Lbj4NMQMxtQNeFIJojQke4kuNWzEXFn5o=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "Smith, Donald" , tcpm Extensions WG , David Borman , Fernando Gont Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:56:39 -0000 Jumping in to this thread since I had mentioned it many times earlier that delayed ICMP's causing issues for seq # check is impractical today. On the client side validation we can have the following scenarios :- #1 - ICMP comes in and doesn't match the current segments (or in some implementations packets) sitting in the retransmission queue, thus the ICMP is silently dropped. No harm. #2 - ICMP arrives and it matches the sequence #, this is the usual case. No harm if false positives are handled correctly. The cause for concern is the case where the ICMP packet gets delayed for a long time and the sequence number has wrapped around and the seq # no. exactly falls in the window of packets sitting in the retransmit queue. This cam happen only when the data is sent at a very fast rate and such cases extra checks are necessary. OTOH, if the ICMP packet seq# falls outiside (> SNDNXT) in such cases this is for something not yet sent, discard it. No harm IMO, this is not an issue at all, these false positives can be handled with appropriate checks in the code. Joe has brought this up multiple # of times and I don't really see this as an issue. The merits of this seq# check far outweigh the de-merits, if any. If you have extendeded ICMP support then we could check more to get even more robustness. (example if timestmaps are available one could make use of it) We have been using the seq# check in our boxes for quite some time (Fernando's draft mentions many other popular OS'es using this method) So, far they have been no issues in the field.=20 My proposal would be to add some text to what Joe is concerned about, highlight the fact that it is mostly theoritical and hence should not be a concern. If needed some quantification can be done, but I really don't see the point.=20 Just my few bits... -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Joe Touch > Sent: Wednesday, September 09, 2009 8:21 AM > To: Carlos Pignataro (cpignata) > Cc: Smith, Donald; 'tcpm Extensions WG'; 'David Borman'; Fernando Gont > Subject: Re: [tcpm] WG Last Call for ICMP Attacks >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 >=20 > Carlos Pignataro wrote: > ... > >> It's OK to qualify it with "this is unlikely", but IMO it=20 > needs to be=20 > >> discussed with more than a single word in a single paragraph. > >=20 > > I think that "this is unlikely" or "this is highly unlikely" would=20 > > still be understating the probability (I am curious to see any=20 > > experienced example of ICMP being delayed minutes). Redundancy=20 > > architectures of routers typically cover the planned=20 > upgrade (or even=20 > > unexpected reload) scenarios you presented. > >=20 > > Perhaps a separate sentence in that paragraph before the=20 > "Thus, " with=20 > > some variation of "rate-limiting can delay ICMPs, and some other=20 > > highly unlikely theoretical scenarios can compound the delay"? >=20 > You can't rely on something that isn't required. The fact=20 > that current implementations, in current operation, don't do=20 > this isn't relevant. >=20 > Consider the proposal to resend 'the last packets seen' after=20 > a link outage, to 'tickle' TCP into waking up. That proposal=20 > was considered inappropriate because the router would hold=20 > the packet too long to satisfy requirements. However, if=20 > someone were to propose to hold ICMPs and issue them later,=20 > that would be *compliant*. >=20 > Protocols aren't just about what happens to work today;=20 > they're about what you can expect to work tomorrow too.=20 > Anything that examines the contents of an ICMP needs to=20 > appreciate that those contents do NOT have to obey timeliness=20 > requirements - notably of the protocol being conveyed as=20 > payload. You need to explain what happens when your=20 > assumptions are wrong not because they're often wrong today,=20 > but because you cannot know whether they'll be wrong tomorrow. >=20 > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAkqnx90ACgkQE5f5cImnZrvguwCgrm7/fLMiKak8gGb0QYQsROeK > 5bcAn0fxfPIznaScGG9Tx0oq0OjCHk8x > =3DxegI > -----END PGP SIGNATURE----- > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From touch@ISI.EDU Wed Sep 9 09:03:58 2009 Return-Path: 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 AD6C128C426 for ; Wed, 9 Sep 2009 09:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 87mDYU3ncRah for ; Wed, 9 Sep 2009 09:03:57 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1265428C449 for ; Wed, 9 Sep 2009 09:03:57 -0700 (PDT) Received: from [192.168.1.47] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n89G4ABK011251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Sep 2009 09:04:12 -0700 (PDT) Message-ID: <4AA7D1F7.5080803@isi.edu> Date: Wed, 09 Sep 2009 09:04:07 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <4A9F4AB1.6070605@gont.com.ar> <4AA6E2CC.2000905@isi.edu> <4AA73910.7080002@gont.com.ar><4AA74639.4000500@isi.edu> <4AA7B738.10400@cisco.com><4AA7B930.10300@isi.edu> <4AA7BFE4.5050209@cisco.com><4AA7C32B.3020606@isi.edu> <4AA7C5CF.10400@cisco.com> <4AA7C7DD.1000504@isi.edu> <0C53DCFB700D144284A584F54711EC5807F84E7A@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5807F84E7A@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Smith, Donald" , "Carlos Pignataro \(cpignata\)" , tcpm Extensions WG , David Borman , Fernando Gont Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 16:03:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Anantha, Anantha Ramaiah (ananth) wrote: > Jumping in to this thread since I had mentioned it many times earlier > that delayed ICMP's causing issues for seq # check is impractical today. > On the client side validation we can have the following scenarios :- > > #1 - ICMP comes in and doesn't match the current segments (or in some > implementations packets) sitting in the retransmission queue, thus the > ICMP is silently dropped. No harm. > #2 - ICMP arrives and it matches the sequence #, this is the usual case. > No harm if false positives are handled correctly. > > > The cause for concern is the case where the ICMP packet gets delayed for > a long time and the sequence number has wrapped around and the seq # no. > exactly falls in the window of packets sitting in the retransmit queue. > This cam happen only when the data is sent at a very fast rate and such > cases extra checks are necessary. OTOH, if the ICMP packet seq# falls > outiside (> SNDNXT) in such cases this is for something not yet sent, > discard it. No harm > > IMO, this is not an issue at all, these false positives can be handled > with appropriate checks in the code. Please just put this in the doc. This issue comes up. It may not affect this solution, but it is important to include it - to say that it isn't an impact. I have asked for similar language in the long-delays doc, but I'm not sure what the impact there is. ... > My proposal would be to add some text to what Joe is concerned about, > highlight the fact that it is mostly theoritical and hence should not be > a concern. If needed some quantification can be done, but I really don't > see the point. No quantification. A version of what's above is what I'm seeking, though if we're considering everything we never see in the wild theoretical, we can gut a lot of complexity out of TCP. IMO, this isn't theoretical - it's *compliant*, and you can make the case that you do no harm when it happens. That's the point, and that's what needs to be in the doc, IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqn0fcACgkQE5f5cImnZruF0QCg8YKWBuLtDuwNTiTxYjRtgK0X KJQAoJV+FzgzeQ7ZwxfaoBgkkET7TIBh =pyWu -----END PGP SIGNATURE----- From fernando@gont.com.ar Wed Sep 9 13:51:09 2009 Return-Path: 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 B324A3A6B1F for ; Wed, 9 Sep 2009 13:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] 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 1IfLsgeD46vG for ; Wed, 9 Sep 2009 13:51:09 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id B5E7A3A6965 for ; Wed, 9 Sep 2009 13:51:07 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5D9DE6B6656; Wed, 9 Sep 2009 17:51:42 -0300 (ART) Received: from [192.168.1.116] (190-50-215-11.speedy.com.ar [190.50.215.11] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id n89KpYWw029894; Wed, 9 Sep 2009 17:51:35 -0300 Message-ID: <4AA81555.3040403@gont.com.ar> Date: Wed, 09 Sep 2009 17:51:33 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4A9F4AB1.6070605@gont.com.ar> <4AA6E2CC.2000905@isi.edu> <4AA73910.7080002@gont.com.ar> <4AA74639.4000500@isi.edu> <4AA7B738.10400@cisco.com> <4AA7B930.10300@isi.edu> In-Reply-To: <4AA7B930.10300@isi.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Wed, 09 Sep 2009 17:51:41 -0300 (ART) Cc: "Smith, Donald" , Carlos Pignataro , 'tcpm Extensions WG' , 'David Borman' Subject: Re: [tcpm] WG Last Call for ICMP Attacks 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 20:51:09 -0000 Joe Touch wrote: > Routers sometimes get locked up doing various things. Their control > planes often operate completely independently of the data plane, and > have priorities that can starve various routines that aren't required to > be timely. Errors that get hit with that could end up on the wire > seconds, minutes - *any* time later. > > And they'd be *compliant* with FC1812. OT, but probably useful for the sake of theoretical discussion: There's no requirement in the TCP/IP specs that the TTL of packets get decremented according to the properties of the link on which the packets will be forwarded. This means that in theory you could forward a packet on a link that has a delay of 5 minutes (or, say, over quite a few links that have a delay of one minute, or whatever), and then any assumptions about "Maximum Segment Lifetime" are invalid (you'd need something like Delta-t). And these scenarios would still be compliant with RFC 791, RFC793, RFC1222, RFC 1812, and others. Nevertheless, your comment will be addressed in the icmp attacks I-D. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From Alexander.Zimmermann@nets.rwth-aachen.de Thu Sep 10 04:26:40 2009 Return-Path: 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 DFD7A3A6A35 for ; Thu, 10 Sep 2009 04:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.158 X-Spam-Level: X-Spam-Status: No, score=-4.158 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] 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 zzBGjOSDmGkX for ; Thu, 10 Sep 2009 04:26:39 -0700 (PDT) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id 799A33A699A for ; Thu, 10 Sep 2009 04:26:39 -0700 (PDT) Received: from exchange-ts.nets.rwth-aachen.de (exchange-ts.nets.rwth-aachen.de [137.226.13.5]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id A019457DCE; Thu, 10 Sep 2009 13:27:13 +0200 (CEST) Received: from exchange-mb.nets.rwth-aachen.de ([2002:89e2:d06::89e2:d06]) by exchange-ts.nets.rwth-aachen.de ([2002:89e2:d05::89e2:d05]) with mapi; Thu, 10 Sep 2009 13:27:13 +0200 From: Alexander Zimmermann To: Joe Touch Date: Thu, 10 Sep 2009 13:27:12 +0200 Thread-Topic: [tcpm] poll for adoption of long connectivity disruptions draft Thread-Index: AcoyCaQyikDQFABXScmN3KOEsKcI8w== Message-ID: References: <4AA6DF6D.10606@isi.edu> In-Reply-To: <4AA6DF6D.10606@isi.edu> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of long connectivity disruptions draft 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 11:26:41 -0000 Hi Joe, thanks for your remarks. As always, comments are inline... Alex Am 09.09.2009 um 00:49 schrieb Joe Touch: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Pasi Sarolahti wrote: > ... >> * Section 4.2, algorithm: this is really a nit, but might want to >> clarify in step (5) that if ICMP DU contains non-TCP header it =20 >> should be >> ignored, without affecting the algorithm (right?) > > It's not clear whether that is a feature or a bug. > > If you have TCP that's idle, and other packets from your host =20 > traverse a > path and generate ICMP DUs, your TCP could benefit from reacting. I > didn't see anything in 1122 that would prevent that. In my opinion the algorithm should only respond to ICMPs which can be =20 demultiplexed to a specific connection (see e-mail reply to Pasi). =20 Exploiting other ICMP DUs may be possible, as a future work, but I =20 fear it may be dangerous and collide with policy routing etc. For =20 instance I wouldn't be surprised if there are "creative" ISPs which =20 route HTTP connections differently than SMTP connections. > > - -- > > FWIW, this draft continues the erroneous assumption that ICMPs are =20 > sent > in a timely fashion. Routers aren't required to do this, and so the > sequence number inside an ICMP should never be used as critical > information. It'd be useful (if not important) to explain the impact =20 > of > this on the algorithm in the draft. Ack that we should it explain more deeply. However I have to disagree =20 with you: we explicitly allow routers to delay ICMPs, and try to =20 benefit from those "delayed" ICMPs as long as those delayed ICMPs =20 belong to the current RTO-induced loss recovery phase. Moreover, there =20 are two important things to note: 1.) We check for an exact match of SND.UNA (no window etc.) with the =20 sequence number included in the ICMP DU. What are the chances that a =20 delayed ICMP matches SND.UNA, but not belonging to that RTO period =20 arrives while this same TCP connection (ports and IPs match) is in =20 timeout-based loss recovery? I say you better play lottery ;-) 2,) Even if such an very unlikely event ever occurs the impact of such =20 an ICMP DU is obviously very low. Partly this is explained in Section 4.3 in the paragraph about =20 sequence number wraps. But we probably separately address the special timing issues of ICMPs. > > Hie > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkqm32wACgkQE5f5cImnZruZ6QCgmy/Op6oqLMTq8XFoNSMNki6p > 3zwAnRxph15X2K6pRQV1voL2PqJ3qVwf > =3DrPsC > -----END PGP SIGNATURE----- > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From Alexander.Zimmermann@nets.rwth-aachen.de Thu Sep 10 07:08:20 2009 Return-Path: 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 A342A28C19E for ; Thu, 10 Sep 2009 07:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.312 X-Spam-Level: X-Spam-Status: No, score=-4.312 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 aLCibeG1+4lr for ; Thu, 10 Sep 2009 07:08:19 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 86B6328C1A4 for ; Thu, 10 Sep 2009 07:08:19 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KPR00NKXDYS0QE0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 10 Sep 2009 16:08:52 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.44,364,1249250400"; d="sig'?scan'208";a="25447688" Received: from smarthost-1.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.89]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 10 Sep 2009 16:08:52 +0200 Received: from octopussy.informatik.RWTH-Aachen.DE (octopussy.informatik.RWTH-Aachen.DE [137.226.12.181]) by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n8AE8qte021531; Thu, 10 Sep 2009 16:08:52 +0200 (CEST) Message-id: <7C14E36A-B00F-48DD-80FA-431B530B7E6D@nets.rwth-aachen.de> From: Zimmermann Alexander To: =?ISO-8859-1?Q?Ilpo_J=E4rvinen?= In-reply-to: Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-1--593572196 Content-transfer-encoding: 7bit Date: Thu, 10 Sep 2009 16:05:34 +0200 References: X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.936) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-zimmermann-tcp-lcd-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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 14:08:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1--593572196 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Ilpo,... Am 31.08.2009 um 16:47 schrieb Ilpo J=E4rvinen: > On Wed, 26 Aug 2009, Alexander Zimmermann wrote: > >> I upload a new version of our draft to the IETF repository: >> http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt >> >> As always, comments are more than welcome. > > I did read throught -01 before -02 was made available and I quickly =20= > went > through the diffs for -02 (and also did read -00 earlier, was among =20= > those > who had read it). I support adopting this id as WG item. After =20 > reviewing > the Linux implementation too, I'd say it looks very straightforward, > simple and clean to implement too (with rather little effort). First of all, thanks a lot for your valuable input to both the Linux =20 implementation and the ID. > > Then some comments: > > 2., 2nd paragraph. > I somewhat feel a bit strange on the importance that is placed in =20 > this ID > for I-D.schuetz-... in defining the meaning "short" and "long" > connectivity disruptions. Ack. After all I-D.schuetz... describes a TCP option. However, I think =20= the definition of "short" and "long" connectivity is important for this draft. We'll rephrase =20= that paragraph. > > 3., 2nd to last paragraph. > "This may very well be the case when TCP is recovering lost segments =20= > (...)." > It's very unclear to me whether you mean negative or positive =20 > statement > here with the unclarity associated the use of "This". Ok, we'll rephrase that. > > 4.2., 1st paragraph. > "... a timeout-based loss recovery has already been started but not > completed". Are you sure that it is crystal clear what "not =20 > completing" > "timeout-based loss recovery" means? I thought so. But you are right. We should clarify that we regard the timeout-based loss recovery as "completed" as soon as an acceptable =20 ACK arrives. And not when all losses are recovered. Thanks! BTW: I think it was never defined in any RFC? > > 4.2., the algorithm itself. > Why not just increase backoff_cnt unconditionally on rto and provide =20= > the > proper cap in the "RTO :=3D RTO_base * 2^(Backoff_cnt)" formula? It =20= > makes > very little difference in practice and arquably can even be =20 > considered to > be more "safe" to count lost retransmissions correctly if the rto =20 > cap was > reached (and bypassed) before any icmps did come? Good point. We tried to allow for other RTO backoff schemes than =20 RFC2988, but as the formula now is already highly dependent on RFC2988 we could very well change that. I have to think about this. > > 4.2., last paragraph. > IMHO the change to the "new started retransmission timer" isn't that =20= > good, > however, I agree that changing it to something is necessary as the > the previous use of "RTO" wasn't that good either. Perhaps something =20= > like > "shortened" would be a good replacement to the "started"? Ack. We'll change that. > > 4.3., 4th paragraph. > A self-reference (see Section 4.3)? Yep. We'll change that. > > Same paragraph. > I think that the sentence starting with "However, " is mis-comma'fied. Jo. We'll change that. > > 4.3., 5th paragraph. > Isn't it enough that any TCP flow with the same 4-tuple matches with > previous one's seqno (not required to be exactly the same flow with =20= > the > correct seqno)? ...I guess it is most likely to happen with the same =20= > flow > though. True but it is even more unlikely. That would mean the ICMP is so =20 late, that a new flow could get created with the same 4-tuple (previous =20 connection out of TIME_WAIT). But as Joe had some concerns about this case we'll =20 explicitly address that too. Alex > > > Nits: > > An revert -> A revert (2.) > ..., back offs -> ..., backs off (4.2.) > scheme flood -> scheme to flood (7.) > to attempt to maliciously -> in attempt to maliciously (7.) ? > > > --=20 > i. --Apple-Mail-1--593572196 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkqpB64ACgkQdyiq39b9uS4RLACggOGQ1TB2g7UM5mO7QjlXttTa 3VoAn1h7CTKG2OCG7pPB7n7zc0fsDcuf =iLxl -----END PGP SIGNATURE----- --Apple-Mail-1--593572196-- From Donald.Smith@qwest.com Thu Sep 10 12:54:41 2009 Return-Path: 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 B1E9D3A6B8D for ; Thu, 10 Sep 2009 12:54:41 -0700 (PDT) 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=[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 TmjekhmYKMGP for ; Thu, 10 Sep 2009 12:54:40 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 5459528C11E for ; Thu, 10 Sep 2009 12:54:40 -0700 (PDT) Received: from sudnp796.qintra.com (sudnp796.qintra.com [151.116.2.212]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id n8AJtBdu019217; Thu, 10 Sep 2009 14:55:11 -0500 (CDT) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.0/8.14.0) with ESMTP id n8AJt524021025; Thu, 10 Sep 2009 13:55:05 -0600 (MDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Thu, 10 Sep 2009 13:55:05 -0600 From: "Smith, Donald" To: "'Joe Touch'" , "'Fernando Gont'" Date: Thu, 10 Sep 2009 13:55:04 -0600 Thread-Topic: [tcpm] tcp-security: More feedback requested for the documentoutline Thread-Index: AcoxFV+xhfpyX9AiS/WR8X0fbi/JCwBOv1jQ Message-ID: References: <4AA74452.7060409@gont.com.ar> <4AA74891.4000407@isi.edu> In-Reply-To: <4AA74891.4000407@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'tcpm-chairs@tools.ietf.org'" , "'tcpm@ietf.org'" Subject: Re: [tcpm] tcp-security: More feedback requested for the documentoutline 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 19:54:41 -0000 I think since this is primarily for developers the current outline is sligh= tly better then Joe's suggested outline. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia =20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Joe Touch > Sent: Wednesday, September 09, 2009 12:18 AM > To: Fernando Gont > Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org > Subject: Re: [tcpm] tcp-security: More feedback requested for=20 > the documentoutline >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 >=20 > Fernando Gont wrote: > > Folks, > >=20 > > The original deadline for commenting on the document=20 > outline is over. > > These are the comments so far: > >=20 > > * Joe: wants to change the outline from the current outline (which > > basically analyzes TCP on a "per-protocol-field", > > "per-protocol-mechanism" basis, etc.) to an outline that basically > > analyzes TCP on a "per-attack" basis (his proposal is available at: > > http://www.ietf.org/mail-archive/web/tcpm/current/msg04838.html) >=20 > The outline I proposed breaks things down into groups based on: > =09 > control plane in-band > control plane out-of-band > data plane > API >=20 > This is (loosely) based on how TCP is specified (order not=20 > withstanding). >=20 > Although I did suggest talking about attacks first, then talking about > mitigations (to separate the two, because a single attack can have > multiple mitigations, and a single mitigation can inhibit multiple > attacks), the overall structure is not per-attack as much as=20 > it based on > breaking the protocol down into its component parts. >=20 > - --- >=20 > It also distinguishes between protocol weaknesses (places where the > protocol creates a vulnerability, regardless of implementation - e.g., > ICMP attacks), implementation choice issues (places where a=20 > choice left > to implementers can cause problems if poorly chosen - e.g., how some > SHOULDs turn into "don't do this in a secure implementation"), and > implementation vulnerabilities (implementation issues not related to > choices in the spec that create problems - e.g., searching=20 > the TIME-WAIT > list linearly). >=20 > Regardless of how we proceed, I believe that this latter=20 > issue should be > considered in the presentation of solutions. >=20 > > * Wesley: would like to change the outline as proposed by=20 > Joe, but could > > live without doing that. > >=20 > > * Alfred: wants to leave the outline as is > >=20 > > * Fernando: wants to leave the outline as is > >=20 > > * Toby: wants to change the outline as proposed by Joe > >=20 > > I don't personally see clear consensus for changing the=20 > outline (even > > less if we consider that many more people had agreed to accept the > > document "as is"). > >=20 > > However, as there have not been that many opinions about=20 > the outline, I > > think it would be a good idea if wg participants that have not yet > > voiced their opinion regarding the document outline have=20 > another chance > > to do it. > >=20 > > So let's set a new deadline for this second round=20 > off-comments: if you > > have any comments regarding the document outline, please voice your > > opinion till September 16th (Wednesday), 2009. > >=20 > > Thanks! > >=20 > > Kind regards, > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAkqnSJEACgkQE5f5cImnZrvSDACg07iCr3uC1ORZ8rvT3PWYrbmq > yDYAoKzt6bDekRm6c5HLvgmDVenPW2m1 > =3DQg/w > -----END PGP SIGNATURE----- > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From touch@ISI.EDU Thu Sep 10 14:33:06 2009 Return-Path: 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 B12B528C0CE for ; Thu, 10 Sep 2009 14:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 J5LO62Ptt8lK for ; Thu, 10 Sep 2009 14:33:05 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 573A33A68AF for ; Thu, 10 Sep 2009 14:33:05 -0700 (PDT) Received: from [75.214.234.117] (117.sub-75-214-234.myvzw.com [75.214.234.117]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n8ALX7vA027436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Sep 2009 14:33:09 -0700 (PDT) Message-ID: <4AA97092.3080105@isi.edu> Date: Thu, 10 Sep 2009 14:33:06 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexander Zimmermann References: <4AA6DF6D.10606@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n8ALX7vA027436 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of long connectivity disruptions draft 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 21:33:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... >> > - -- >> > >> > FWIW, this draft continues the erroneous assumption that ICMPs are >> > sent >> > in a timely fashion. Routers aren't required to do this, and so the >> > sequence number inside an ICMP should never be used as critical >> > information. It'd be useful (if not important) to explain the impact >> > of >> > this on the algorithm in the draft. > > > Ack that we should it explain more deeply. However I have to disagree > with you: we explicitly allow routers to delay ICMPs, and try to > benefit from those "delayed" ICMPs as long as those delayed ICMPs > belong to the current RTO-induced loss recovery phase. Moreover, there > are two important things to note: > > 1.) We check for an exact match of SND.UNA (no window etc.) with the > sequence number included in the ICMP DU. What are the chances that a > delayed ICMP matches SND.UNA, but not belonging to that RTO period > arrives while this same TCP connection (ports and IPs match) is in > timeout-based loss recovery? I say you better play lottery ;-) A router that goes down and queues pending outgoing ICMPs, then emits them when up, could win the lottery by design. The question is whether it matters for your algorithm. If the connection didn't proceed anyway and this is still a useful signal, then say so. If the connection could proceed on other paths, and as a result the sequence numbers would need to wrap and be in-window to work, then the probability of this happening depends on the width of the window - which has been getting larger, and could make such a lottery more likely than you're planning for. Again, does it matter? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkqpcJIACgkQE5f5cImnZrs9oACePJC7XzJbjKBIpQsOX4o4cjAI knoAn06lbo0bzlPj+rS/bDjIccSEbbko =ravf -----END PGP SIGNATURE----- From pasi.sarolahti@iki.fi Fri Sep 11 00:11:28 2009 Return-Path: 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 6BBF83A68D6 for ; Fri, 11 Sep 2009 00:11:28 -0700 (PDT) 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=[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 XbKi-SVa6brj for ; Fri, 11 Sep 2009 00:11:27 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 4B2CA3A67A7 for ; Fri, 11 Sep 2009 00:11:27 -0700 (PDT) Received: from [192.168.1.66] (adsl-99-169-83-39.dsl.pltn13.sbcglobal.net [99.169.83.39]) by argo.otaverkko.fi (Postfix) with ESMTP id 2DEBE25ED11; Fri, 11 Sep 2009 10:12:01 +0300 (EEST) Message-Id: From: Pasi Sarolahti To: Alexander Zimmermann In-Reply-To: <5D7CC3AE-684A-4E25-9325-318700E30B5F@nets.rwth-aachen.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 11 Sep 2009 00:11:58 -0700 References: <5D7CC3AE-684A-4E25-9325-318700E30B5F@nets.rwth-aachen.de> X-Mailer: Apple Mail (2.936) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of long connectivity disruptions draft 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 07:11:28 -0000 On Sep 9, 2009, at 6:42 AM, Alexander Zimmermann wrote: >> * The title would benefit from some tweaking. Maybe its just a matter >> of changing "Make" => "Making" > > Ok, we will change the title to "Making TCP more Robust to Long > Connectivity > Disruptions". I'm also fine with changing it to something completely > different, > are there any suggestions? No. I think "Making TCP..." is just fine. >> >> * Section 4.2, algorithm: this is really a nit, but might want to >> clarify in step (5) that if ICMP DU contains non-TCP header it should >> be ignored, without affecting the algorithm (right?) > > In our algorithm we assume that the ICMP error message is passed > up from the IP layer, for the corresponding connection. > (See RFC 1122 Section 4.2.3.9 ). Ack, we will make this more clear. > However, I think the fact that the ICMP message already got > demultiplexed implies that the ICMP DU contains a TCP header, > otherwise > we would "not see" this ICMP DU at this layer. You are right, but I guess details might depend on implementation. And there might be possibilities for further optimization with non-TCP generated ICMPs, as per Joe's earlier mail. >> * It would be interesting to have an accompanying technical report on >> some (even preliminary) results on the performance improvements using >> the algorithm. It would also be interesting to have some >> understanding >> how often ICMP Destination unreachables actually arrive in case of a >> real connectivity disruption in real world. > > Depends on what you mean with "real world" we have already presented > some measurements with Linux routers, see the slides from the last > IETF meetings. And the ICMP DU arrive surprisingly reliable. > However, we did not test juniper or cisco yet... Yep, the graphs in the meeting slides are nice. As an optional further step (if someone had the time) they could be wrapped with some explanatory text into a paper format to be used as a reference for people trying to assess the benefits. Regarding "real world", I had something like today's 3G & WiFi networks in mind. - Pasi From root@core3.amsl.com Mon Sep 14 08:30:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 523FC3A68C8; Mon, 14 Sep 2009 08:30:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090914153001.523FC3A68C8@core3.amsl.com> Date: Mon, 14 Sep 2009 08:30:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcpsecure-12.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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 15:30:01 -0000 --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 : Improving TCP's Robustness to Blind In-Window Attacks Author(s) : A. Ramaiah, et al. Filename : draft-ietf-tcpm-tcpsecure-12.txt Pages : 26 Date : 2009-09-14 TCP has historically been considered protected against spoofed off- path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32 bit sequence number(s). A combination of increasing window sizes and applications using longer term connections (e.g. H-323 or Border Gateway Protocol [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks. Many of these long term TCP applications tend to have predictable IP addresses and ports which makes it far easier for the 4-tuple (4-tuple is the same as the socket pair mentioned in [RFC0793]) to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a TCP segment with the RST bit set, the SYN bit set or data into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to abort or cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-tcpm-tcpsecure-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-14082458.I-D@ietf.org> --NextPart-- From ananth@cisco.com Mon Sep 14 08:48:48 2009 Return-Path: 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 125FF3A68C8 for ; Mon, 14 Sep 2009 08:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Q+S1N48lbo4U for ; Mon, 14 Sep 2009 08:48:47 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0407E3A6814 for ; Mon, 14 Sep 2009 08:48:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI8CrkqrR7O6/2dsb2JhbADFfohMAY5FBYQY X-IronPort-AV: E=Sophos;i="4.44,384,1249257600"; d="scan'208";a="388354004" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 14 Sep 2009 15:49:31 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8EFnVAH031261; Mon, 14 Sep 2009 08:49:31 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8EFnVa8020259; Mon, 14 Sep 2009 15:49:31 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.3959); Mon, 14 Sep 2009 08:49:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Sep 2009 08:49:30 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5807FF03C6@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20090914153001.523FC3A68C8@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] I-D Action:draft-ietf-tcpm-tcpsecure-12.txt Thread-Index: Aco1UIrjoyIfPQzBQ+CHX3wOaaCoCQAAcxGg References: <20090914153001.523FC3A68C8@core3.amsl.com> From: "Anantha Ramaiah (ananth)" To: "tcpm Extensions WG" X-OriginalArrivalTime: 14 Sep 2009 15:49:31.0426 (UTC) FILETIME=[F304F820:01CA3552] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3047; t=1252943371; x=1253807371; c=relaxed/simple; s=sjdkim2002; 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]=20I-D=20Action=3Adraft-ietf-tcpm -tcpsecure-12.txt |Sender:=20; bh=GVFgUS4AAXMqx+4B38zjsAuHvfwpMO8McBBERj66dVg=; b=gsYjWZunzdDdbA4EPmGdmzdPK7M3jalouU7E7owW4peY+JWTBZrMLF3kYm gkD7QS893kRvx/1j1+f0S5KN1wT4UNuPrmEixLjyK42vN/LYvudvXe0IbF14 Gvc1vtNb/v; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Fernando Gont Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcpsecure-12.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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 15:48:48 -0000 =20 This basically has : The agreed upon Last Call comments incorporated. I have checked all the comments received and have incorporated the ones which are agreed upon. Briefly : - new template - No IPR disclsoures on IETF documents, the RFC editor would do what is needed. Brian clarified this. - Addressed the last call comments by Brian Carpenter. - Fernando's Last call comments agreed upon (added references to RFC 1948 and port randomization).=20 - Sandra Murphy's comments whichever has been agreed upon. - misc (typos etc.,) Thanks, Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Internet-Drafts@ietf.org > Sent: Monday, September 14, 2009 8:30 AM > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcpsecure-12.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor=20 > Extensions Working Group of the IETF. >=20 >=20 > Title : Improving TCP's Robustness to Blind=20 > In-Window Attacks > Author(s) : A. Ramaiah, et al. > Filename : draft-ietf-tcpm-tcpsecure-12.txt > Pages : 26 > Date : 2009-09-14 >=20 > TCP has historically been considered protected against=20 > spoofed off- path packet injection attacks by relying on the=20 > fact that it is difficult to guess the 4-tuple (the source=20 > and destination IP addresses and the source and destination=20 > ports) in combination with the 32 bit sequence number(s). A=20 > combination of increasing window sizes and applications using=20 > longer term connections (e.g. H-323 or Border Gateway=20 > Protocol [RFC4271]) have left modern TCP implementations more=20 > vulnerable to these types of spoofed packet injection attacks. >=20 > Many of these long term TCP applications tend to have=20 > predictable IP addresses and ports which makes it far easier=20 > for the 4-tuple (4-tuple is the same as the socket pair=20 > mentioned in [RFC0793]) to be guessed. Having guessed the=20 > 4-tuple correctly, an attacker can inject a TCP segment with=20 > the RST bit set, the SYN bit set or data into a TCP=20 > connection by systematically guessing the sequence number of=20 > the spoofed segment to be in the current receive window. =20 > This can cause the connection to abort or cause data=20 > corruption. This document specifies small modifications to=20 > the way TCP handles inbound segments that can reduce the=20 > chances of a successful attack. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-12.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 From Alexander.Zimmermann@nets.rwth-aachen.de Tue Sep 15 10:59:05 2009 Return-Path: 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 076753A6A5F for ; Tue, 15 Sep 2009 10:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_20=-0.74, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] 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 mpvad3SqBEF0 for ; Tue, 15 Sep 2009 10:59:03 -0700 (PDT) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id 4180A28C130 for ; Tue, 15 Sep 2009 10:58:39 -0700 (PDT) Received: from exchange-ts.nets.rwth-aachen.de (exchange-ts.nets.rwth-aachen.de [137.226.13.5]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id C5B7757CE4; Tue, 15 Sep 2009 19:59:25 +0200 (CEST) Received: from exchange-mb.nets.rwth-aachen.de ([2002:89e2:d06::89e2:d06]) by exchange-ts.nets.rwth-aachen.de ([2002:89e2:d05::89e2:d05]) with mapi; Tue, 15 Sep 2009 19:59:25 +0200 From: Alexander Zimmermann To: Joe Touch Date: Tue, 15 Sep 2009 19:59:24 +0200 Thread-Topic: [tcpm] poll for adoption of long connectivity disruptions draft Thread-Index: Aco2LkK5SXI9NaY0Qcu0XZw/g1RAvQ== Message-ID: References: <4AA6DF6D.10606@isi.edu> <4AA97092.3080105@isi.edu> In-Reply-To: <4AA97092.3080105@isi.edu> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of long connectivity disruptions draft 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 17:59:05 -0000 Hi Joe, first of all, thank you very much for your valuable comments! Since =20 I'm not sure I understand you correctly, I break down our problem to a concrete =20 example with we can play with. * If I understand you correctly in this threat as well in the threat =20 "WG Last Call for ICMP Attacks", the "possibility" and the "impact" of a false =20 positive is something different and both should be included in our I-D. Till =20 now only the "possibility" is included. I will fix that. * Every time I had the problem "RTO-based loss recovery AND router can =20 delay to send/generate ICMPs AND sequence space can wrap" in mind, I mean problem "B.4.2". However, I have the feeling you mean problem "2.4.2". Right? Alex --- Situation: S (Source) ---------------- R (Router) ---------------- D (Destination) - At time t0, a steady state TCP flow with packets p1,...,pn in flight =20 between a source S and a destination D. Packets are routed by an intermediate =20 router R. - At time t1 a connectivity disruption occurs at router R. - At time t2, S starts to send RTO based retransmissions r1,...,rm and =20 backs off and undoes according the algorithm. - At time t3, the connection is re-established - At time t4, the sequence space wraps - At time t5, the connection is in RTO-based loss recovery again The following scenarios are possible, when ICMP DUs for the packets =20 p1,...,pn are delayed for a longer time (or are not generated at all): 1. R does not generate ICMP DUs for p1,...,pn (congestion) =3D> Backoff according to RFC 2988, no undo by design. 2. R generates ICMP DUs for p1,...,pn 2.1 S receives ICMP DUs BEFORE t2 (standard) =3D> Impact: None. ICMP DUs are ignored by design. 2.2 S receives ICMP DUs AFTER t2, but BEFORE t3 =3D> Impact: Retransmission ambiguity. To be considered as not =20 harmful. (described in I-D section 4.3, para 5) 2.3 S receives ICMP DUs AFTER t3, but BEFORE t5 =3D> Impact: None. ICMP DUs are ignored by design. 2.4 S receives ICMP DUs AFTER t5 2.4.1 RTO due to connectivity disruption =3D> Impact: No false positives since we count backoffs. 2.4.2 RTO due to congestion =3D> Impact: one false positive possible =3D> Possibility: at most n/2^32 (not described in I-D yet!!!) The following scenarios are possible, when ICMP DUs for the =20 retransmissions r1,...,rm are delayed for a longer time (or are not generated at all): A. R does not generate ICMP DUs for r1,...,rm (congestion) =3D> Backoff according to RFC 2988, no undo by design. B. R generates ICMP DUs FOR ALL r1,...,rm B.1 S receives ICMP DUs BEFORE t3 =3D> ICMP DUs are exploited by design. =3D> Undo B.2 S receives ICMP DUs AFTER t3, but BEFORE t5 =3D> Impact: None. ICMP DUs are ignored by design. B.3 S receives ICMP DUs AFTER t5 B.4.1 RTO due to connectivity disruption =3D> Impact: No false positive since we count backoffs. B.4.2 RTO due to congestion =3D> Impact: at most m false positives =3D> Possibility: at most 1/2^32 (described (not completely correct) in I-D section 4.3, para 6) B.1) A steady state TCP flow between a sender S and a destination D is =20 disrupted at some router R. The first few RTO retransmissions trigger ICMP DUs =20 at R, but are delayed by it. Then, while S is still in the same loss recovery =20 phase, the accumulated ICMPs are emitted by R and received by S, triggering =20 multiple reversions. This is safe, as the result would be the same, when ICMPs =20 were emitted instantly. B.2) A steady state TCP flow between a sender S and a destination D is =20 disrupted at some router R. The first few RTO retransmission trigger ICMP DUs at =20 R, but are delayed by it. Then, connectivity is re-established by a successful retransmission and S leaves the loss state. If the delayed ICMPs are =20 emitted by R now, they will have no effect on S. 2.4.2) A steady state TCP flow between a sender S and a destination D is disrupted at some router R. Each packet p[i], which is in flight from =20 S to T passes R and may (ICMP rate limiting) trigger a DU message, which is =20 delayed at R. Afterwards, when the link outage is over, the connection is re-established, and S slow-starts the connection. When the sender's TCP performs a sequence number wrap and approaches the sequence numbers of =20 p[i], an RTO occurs and S enters RTO-based loss recovery. Now, R emits the =20 delayed ICMPs for the p[i] of the last sequence number cycle, which may =20 trigger one false reversion. In case of congestion, this leads to one false retransmission, while in the case of another link outage, the additional reversion is harmless. However, it is at most one false reversion, as =20 long as we assume only one sequence number cycle of delayed ICMPs. The =20 probability of this to happen depends on the number of packets which are in flight =20 towards R. B.4.2) A steady state TCP flow between a sender S and a destination T is disrupted at some router R. The sender performs multiple consecutive RTO retransmissions, but the corresponding ICMPs are delayed by R. Then, =20 after several more retransmissions, connectivity is re-established and S =20 leaves loss state. A sequence space wrap later, the path is disrupted again, =20 exactly at the time at which the current SND.UNA matches the SND.UNA form the =20 previous cycle. If the router R emits the delayed ICMPs now, but is currently =20 congested, S will undo the multiple backoffs falsely. The probability of this =20 should be at most 1 to 4 billion. Given sufficiently many RTO retransmissions in the first loss phase, the corresponding ICMPs can pull the RTO in the second loss phase from =20 MAX_RTO to the initial RTO. However, once the ICMPs are depleted, standard =20 exponential backoff will be performed. Roughly speaking, the standard congestion response will be delayed by a few false retransmissions, and after log2(MAX_RTO/MIN_RTO) of those retransmissions, MAX_RTO is reached =20 again. // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From touch@ISI.EDU Tue Sep 15 11:02:52 2009 Return-Path: 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 445E13A6BA1 for ; Tue, 15 Sep 2009 11:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 NgZB1y4hEaXE for ; Tue, 15 Sep 2009 11:02:51 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BEBF73A6A82 for ; Tue, 15 Sep 2009 11:02:50 -0700 (PDT) Received: from [192.168.1.47] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n8FI3Jn5002228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Sep 2009 11:03:21 -0700 (PDT) Message-ID: <4AAFD6E7.4050901@isi.edu> Date: Tue, 15 Sep 2009 11:03:19 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexander Zimmermann References: <4AA6DF6D.10606@isi.edu> <4AA97092.3080105@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of long connectivity disruptions draft 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 18:02:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Alex, Alexander Zimmermann wrote: > Hi Joe, > > first of all, thank you very much for your valuable comments! Since > I'm not sure > I understand you correctly, I break down our problem to a concrete > example with > we can play with. Thank you for doing this. This is the kind of discussion that, IMO, should appear in the document. I don't disagree with any of the conclusions below. Joe > > * If I understand you correctly in this threat as well in the threat > "WG Last > Call for ICMP Attacks", the "possibility" and the "impact" of a false > positive > is something different and both should be included in our I-D. Till > now only the > "possibility" is included. I will fix that. > > * Every time I had the problem "RTO-based loss recovery AND router can > delay to > send/generate ICMPs AND sequence space can wrap" in mind, I mean problem > "B.4.2". However, I have the feeling you mean problem "2.4.2". Right? > > Alex > > --- > > Situation: > > S (Source) ---------------- R (Router) ---------------- D (Destination) > > - At time t0, a steady state TCP flow with packets p1,...,pn in flight > between a > source S and a destination D. Packets are routed by an intermediate > router R. > > - At time t1 a connectivity disruption occurs at router R. > > - At time t2, S starts to send RTO based retransmissions r1,...,rm and > backs off > and undoes according the algorithm. > > - At time t3, the connection is re-established > > - At time t4, the sequence space wraps > > - At time t5, the connection is in RTO-based loss recovery again > > > The following scenarios are possible, when ICMP DUs for the packets > p1,...,pn > are delayed for a longer time (or are not generated at all): > > 1. R does not generate ICMP DUs for p1,...,pn (congestion) > => Backoff according to RFC 2988, no undo by design. > > 2. R generates ICMP DUs for p1,...,pn > 2.1 S receives ICMP DUs BEFORE t2 (standard) > => Impact: None. ICMP DUs are ignored by design. > > 2.2 S receives ICMP DUs AFTER t2, but BEFORE t3 > => Impact: Retransmission ambiguity. To be considered as not > harmful. > (described in I-D section 4.3, para 5) > > 2.3 S receives ICMP DUs AFTER t3, but BEFORE t5 > => Impact: None. ICMP DUs are ignored by design. > > 2.4 S receives ICMP DUs AFTER t5 > 2.4.1 RTO due to connectivity disruption > => Impact: No false positives since we count backoffs. > > 2.4.2 RTO due to congestion > => Impact: one false positive possible > => Possibility: at most n/2^32 > (not described in I-D yet!!!) > > > The following scenarios are possible, when ICMP DUs for the > retransmissions > r1,...,rm are delayed for a longer time (or are not generated at all): > > A. R does not generate ICMP DUs for r1,...,rm (congestion) > => Backoff according to RFC 2988, no undo by design. > > B. R generates ICMP DUs FOR ALL r1,...,rm > B.1 S receives ICMP DUs BEFORE t3 > => ICMP DUs are exploited by design. => Undo > > B.2 S receives ICMP DUs AFTER t3, but BEFORE t5 > => Impact: None. ICMP DUs are ignored by design. > > B.3 S receives ICMP DUs AFTER t5 > B.4.1 RTO due to connectivity disruption > => Impact: No false positive since we count backoffs. > > B.4.2 RTO due to congestion > => Impact: at most m false positives > => Possibility: at most 1/2^32 > (described (not completely correct) in I-D section 4.3, para 6) > > > B.1) A steady state TCP flow between a sender S and a destination D is > disrupted > at some router R. The first few RTO retransmissions trigger ICMP DUs > at R, but > are delayed by it. Then, while S is still in the same loss recovery > phase, the > accumulated ICMPs are emitted by R and received by S, triggering > multiple > reversions. This is safe, as the result would be the same, when ICMPs > were > emitted instantly. > > B.2) A steady state TCP flow between a sender S and a destination D is > disrupted > at some router R. The first few RTO retransmission trigger ICMP DUs at > R, but > are delayed by it. Then, connectivity is re-established by a successful > retransmission and S leaves the loss state. If the delayed ICMPs are > emitted by > R now, they will have no effect on S. > > 2.4.2) A steady state TCP flow between a sender S and a destination D is > disrupted at some router R. Each packet p[i], which is in flight from > S to T > passes R and may (ICMP rate limiting) trigger a DU message, which is > delayed > at R. Afterwards, when the link outage is over, the connection is > re-established, and S slow-starts the connection. When the sender's TCP > performs a sequence number wrap and approaches the sequence numbers of > p[i], > an RTO occurs and S enters RTO-based loss recovery. Now, R emits the > delayed > ICMPs for the p[i] of the last sequence number cycle, which may > trigger one > false reversion. In case of congestion, this leads to one false > retransmission, while in the case of another link outage, the additional > reversion is harmless. However, it is at most one false reversion, as > long > as we assume only one sequence number cycle of delayed ICMPs. The > probability of > this to happen depends on the number of packets which are in flight > towards R. > > B.4.2) A steady state TCP flow between a sender S and a destination T is > disrupted at some router R. The sender performs multiple consecutive RTO > retransmissions, but the corresponding ICMPs are delayed by R. Then, > after > several more retransmissions, connectivity is re-established and S > leaves > loss state. A sequence space wrap later, the path is disrupted again, > exactly > at the time at which the current SND.UNA matches the SND.UNA form the > previous > cycle. If the router R emits the delayed ICMPs now, but is currently > congested, > S will undo the multiple backoffs falsely. The probability of this > should be at > most 1 to 4 billion. > Given sufficiently many RTO retransmissions in the first loss phase, the > corresponding ICMPs can pull the RTO in the second loss phase from > MAX_RTO > to the initial RTO. However, once the ICMPs are depleted, standard > exponential > backoff will be performed. Roughly speaking, the standard congestion > response will be delayed by a few false retransmissions, and after > log2(MAX_RTO/MIN_RTO) of those retransmissions, MAX_RTO is reached > again. > > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 > // RWTH Aachen University > // Ahornstr. 55, 52056 Aachen, Germany > // phone: (49-241) 80-21422, fax: (49-241) 80-22220 > // email: zimmermann@cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkqv1uYACgkQE5f5cImnZrsSAgCfZDYtR6IIlzBcdEohceXzD574 FS4AoJ3uzBVZtrghN4HthCj+Ks7iQcCM =KWPc -----END PGP SIGNATURE----- From david.borman@windriver.com Thu Sep 17 11:09:12 2009 Return-Path: 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 6C6553A67AC for ; Thu, 17 Sep 2009 11:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-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 L95PHvNBwwvO for ; Thu, 17 Sep 2009 11:09:11 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 16FA428C164 for ; Thu, 17 Sep 2009 11:08:54 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id n8HI9jPe016982 for ; Thu, 17 Sep 2009 11:09:45 -0700 (PDT) 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); Thu, 17 Sep 2009 11:09:45 -0700 Received: from [172.25.44.8] ([172.25.44.8]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Sep 2009 11:09:44 -0700 From: David Borman Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Thu, 17 Sep 2009 13:09:42 -0500 Message-Id: To: tcpm Extensions WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 17 Sep 2009 18:09:44.0801 (UTC) FILETIME=[09055D10:01CA37C2] Subject: [tcpm] WG session in Hiroshima? 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 18:09:12 -0000 If tcpm meets in Hiroshima, are there topics that people want to cover at the meeting? We haven't requested a wg slot yet, and it is not clear if either of the wg chairs will be there, so we'd also be looking for someone to run the meeting. -David & Wes, TCPM WG co-chairs. From fernando.gont.netbook.win@gmail.com Thu Sep 17 11:57:14 2009 Return-Path: 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 1E7C13A6994 for ; Thu, 17 Sep 2009 11:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=-0.178, 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 eT1eG5eLOjjF for ; Thu, 17 Sep 2009 11:57:13 -0700 (PDT) Received: from mail-qy0-f127.google.com (mail-qy0-f127.google.com [209.85.221.127]) by core3.amsl.com (Postfix) with ESMTP id 47F433A6851 for ; Thu, 17 Sep 2009 11:57:13 -0700 (PDT) Received: by qyk33 with SMTP id 33so4059qyk.31 for ; Thu, 17 Sep 2009 11:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=zoz4hdwo7JXIPuWOuUsLhJ/Ng8gtMGZFnZ5hBUBN7eg=; b=HRcVg4wQTYM1gZGg2RBoYIxiXmYQlBbGV3jAiyWfx96997MB9ul3KvuBIhtiDOHxbF 0/CxlQyWYjiE4LhRgVKx6Q14+15TM+Uj7g4WYpVGBsaSUBDkBtlIAwPZkZNcZsgQtCa7 f7vQRBGFLkuGlOyip38f7JYAW7V2heeta4kYs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=phC6UGTKSUeBb5LlQvz73gGzMtJIf0GQtgBl4HIAycbL8jNuTRp/8Xa6dwSAn6gMTm fs5jFlZCNDmZYhc09Wi4GV8jwSBGqOKg5eOdB0MDg3ijlCTcY5zW1YqwBni/xmHT8989 qxjvilpX3GaP7ZSlicZi4fmm2ijoHZUKsVd0g= Received: by 10.224.81.148 with SMTP id x20mr675150qak.156.1253213882592; Thu, 17 Sep 2009 11:58:02 -0700 (PDT) Received: from ?192.168.0.167? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 6sm392341qwk.24.2009.09.17.11.58.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Sep 2009 11:58:01 -0700 (PDT) Sender: Fernando Gont Message-ID: <4AB286AC.60301@gont.com.ar> Date: Thu, 17 Sep 2009 15:57:48 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Borman References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm Extensions WG Subject: Re: [tcpm] WG session in Hiroshima? 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 18:57:14 -0000 David Borman wrote: > If tcpm meets in Hiroshima, are there topics that people want to cover > at the meeting? Yes. I'd like a slot to present the following I-Ds: * draft-ietf-tcp-security * draft-ietf-urgent-data * draft-gont-tcp-timestamps (?) I might be able to have another one ready shortly.... Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From wesley.m.eddy@nasa.gov Fri Sep 18 06:31:52 2009 Return-Path: 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 C46DF3A69B2 for ; Fri, 18 Sep 2009 06:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.571 X-Spam-Level: X-Spam-Status: No, score=-5.571 tagged_above=-999 required=5 tests=[AWL=-0.831, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] 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 GVMuSyt0Hl39 for ; Fri, 18 Sep 2009 06:31:51 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id D1FD828C1C4 for ; Fri, 18 Sep 2009 06:31:51 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id CB3623289FB for ; Fri, 18 Sep 2009 08:32:43 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n8IDWeAx027437 for ; Fri, 18 Sep 2009 08:32:43 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Fri, 18 Sep 2009 08:32:03 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" , "tcpm@ietf.org" Date: Fri, 18 Sep 2009 08:32:02 -0500 Thread-Topic: poll for adoption of SACK recovery entry draft Thread-Index: AcorOpvGbikE1nfUR9yr7N3CeSSLzgNKTY2g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-09-18_07:2009-09-17, 2009-09-18, 2009-09-18 signatures=0 Subject: Re: [tcpm] poll for adoption of SACK recovery entry draft 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 13:31:52 -0000 >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Eddy, Wesley M. (GRC-MS00)[Verizon] >Sent: Tuesday, September 01, 2009 3:30 PM > >Hello, the authors of the SACK Recovery Entry draft: >http://tools.ietf.org/html/draft-jarvinen-tcpm-sack-recovery-entry-01 >have given a couple presentations to the WG now and asked if it >could be considered as an item for the WG for Proposed Standard (at >least I'm assuming PS because the I-D says "Intended Status: Standards >Track" ...). If I'm not mistaken, there has been some positive feedback >on the most recent incarnation, though not a lot, and not really any >negative feedback that I could see. > >As chairs, David and I are asking the WG to voice whether we should: > >A) adopt this as a WG item for Proposed Standard >B) NOT adopt this as a WG item >C) wait to decide (not ready) It looks like there's a fair amount of positive support (choice A) for this based on both the mailing list and meeting feedback, so David and I will add a milestone. I'm guessing that 1 year from now is a reasonable timeframe to say we'll have the document ready within for the milestone. The authors can put in a draft-ietf-tcpm-... version at their leisure. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From wesley.m.eddy@nasa.gov Fri Sep 18 06:35:29 2009 Return-Path: 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 C096D3A67AD for ; Fri, 18 Sep 2009 06:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 9UPHKj3ruVaj for ; Fri, 18 Sep 2009 06:35:29 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id CC25E3A6885 for ; Fri, 18 Sep 2009 06:35:28 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 010BD1480FB for ; Fri, 18 Sep 2009 08:36:22 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01.ndc.nasa.gov [198.117.4.160]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n8IDa8Wh032239 for ; Fri, 18 Sep 2009 08:36:22 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.4.160]) with mapi; Fri, 18 Sep 2009 08:35:41 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" , "tcpm@ietf.org" Date: Fri, 18 Sep 2009 08:35:40 -0500 Thread-Topic: poll for adoption of long connectivity disruptions draft Thread-Index: AcorOkcQoJjUMfz3QWuTzmBHEhBvFwNKiRuA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-09-18_07:2009-09-17, 2009-09-18, 2009-09-18 signatures=0 Subject: Re: [tcpm] poll for adoption of long connectivity disruptions draft 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 13:35:29 -0000 >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Eddy, Wesley M. (GRC-MS00)[Verizon] >Sent: Tuesday, September 01, 2009 3:28 PM > >Hello, the authors of the "Long Connectivity Disruptions" draft: >http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt >have given a couple presentations to the WG now and asked if it >could be considered as an item for the WG for Experimental. If >I'm not mistaken, there has been some positive feedback on the >most recent incarnation, though not a lot, and not really any >negative feedback that I could see. > >As chairs, David and I are asking the WG to voice whether we should: > >A) adopt this as a WG item for Experimental >B) NOT adopt this as a WG item >C) wait to decide (not ready) Based on both mailing list feedback which primarily pointed to choice A, and the discussion at the last 2 meetings, it looks like this should be added to our milestones. My guess is that 1 year from now is an appropriate time to put the milestone at. The authors can go ahead and submit a draft-ietf-tcpm-... version when they're ready. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From alexander.zimmermann@nets.rwth-aachen.de Mon Sep 21 03:12:28 2009 Return-Path: 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 41E4528C110 for ; Mon, 21 Sep 2009 03:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.404 X-Spam-Level: X-Spam-Status: No, score=-4.404 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] 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 IPgIsYbIEtV8 for ; Mon, 21 Sep 2009 03:12:27 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 3DC4828C102 for ; Mon, 21 Sep 2009 03:12:27 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KQB00IL7GEFKDB0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 21 Sep 2009 12:13:27 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.44,424,1249250400"; d="scan'208";a="26574007" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 21 Sep 2009 12:13:27 +0200 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KQB0051VGEFW570@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 21 Sep 2009 12:13:27 +0200 (CEST) From: Alexander Zimmermann In-reply-to: Date: Mon, 21 Sep 2009 12:13:28 +0200 Message-id: <3863C493-D5FA-4B58-A80E-62FF2300F638@nets.rwth-aachen.de> References: To: David Borman , "Wesley Eddy M. (GRC-MS00)[Verizon]" X-Mailer: Apple Mail (2.1076) Cc: tcpm Extensions WG Subject: Re: [tcpm] WG session in Hiroshima? 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 10:12:28 -0000 Hi David, Hi Wes, provided that I get the funding for Hiroshima, I would like to have the slot to present the changes of our I-D. Alex Am 17.09.2009 um 20:09 schrieb David Borman: > If tcpm meets in Hiroshima, are there topics that people want to cover > at the meeting? We haven't requested a wg slot yet, and it is not > clear if either of the wg chairs will be there, so we'd also be > looking for someone to run the meeting. > > -David & Wes, TCPM WG co-chairs. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From mallman@icir.org Tue Sep 22 12:29:03 2009 Return-Path: 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 D3CD13A6ACF for ; Tue, 22 Sep 2009 12:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 vvXh+pb8Q82r for ; Tue, 22 Sep 2009 12:28:55 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 7B6123A6AC8 for ; Tue, 22 Sep 2009 12:28:53 -0700 (PDT) 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 n8MJTv8U005871; Tue, 22 Sep 2009 12:29:57 -0700 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 84DC03D2D8F1; Tue, 22 Sep 2009 15:29:50 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9A1BD4AB959; Tue, 22 Sep 2009 15:29:50 -0400 (EDT) To: Alexander Zimmermann From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: In the City MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma9646-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 22 Sep 2009 15:29:50 -0400 Sender: mallman@icir.org Message-Id: <20090922192950.9A1BD4AB959@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 19:29:03 -0000 ----------ma9646-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > as requested at the last TCPM meeting in Stockholm that we need some > reviews for Early Retransmit (draft-ietf-tcpm-early-rexmt-01), here > are some comments from me: Many thanks for the comments! > * The "entry point" of the algorithm could be better described. For > * example lets begin paragraph 2 in section 2.1 as follows: When an > * acknowledgment arrives at the sender, the sender ... I don't entirely understand where you're talking about in section 2.1. The above sentence fragment does not look like it meshes well with any of the paragraphs that I can identify that you might be talking about. I am going to take this for a nit and ignore it for now. If this is more than stylistic please send a more verbose change request. > * What about RFC4653 - Improving the Robustness of TCP to Non- > Congestion Events? Is Early Retransmit compatible to RFC4653? At > first glance I think yes, when we define a priority which algo > should alter Dupthresh We don't need a priority. The algorithms operate in different regions of the operating space. I put the following paragraph in the related work section: [RFC4653] also defines an orthogonal method for altering the duplicate ACK threshold. The mechanisms proposed in this document decrease the duplicate ACK threshold when a small amount of data is outstanding. Meanwhile, the mechanisms in [RFC4653] increase the duplicate ACK threshold (over the standard of 3) when the congestion window is large in an effort to increase robustness to packet reordering. > * Section 1, para 3: s/Small windows/Small congestion windows/ Done. > * Section 1, last para: Explanation of the difference between > * Limited Transmit and Early Retransmit. Maybe we can put here a > * pointer to the aforementioned case why a CWND can be small. For > * example (last sentence): The "Early Retransmit" mechanism > * outlined in this document covers the case when previously unsent > * data is not available (case 2) for transmission or cannot be > * transmitted due to an advertised window limitation (case 1). I did this, but instead of "case 1" I used "case 3" which is what I believe you meant. allman ----------ma9646-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkq5Ja4ACgkQWyrrWs4yIs6p6QCgmsG1MFawGLlS1xD4KZ4SlFVo WQAAnRAq+8lGzTfwqSjIzQAyfOUjyuC1 =fBAG -----END PGP SIGNATURE----- ----------ma9646-1-- From mallman@icir.org Wed Sep 23 06:03:59 2009 Return-Path: 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 93BF828C0E1 for ; Wed, 23 Sep 2009 06:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 rnH-hJ+Ceort for ; Wed, 23 Sep 2009 06:03:58 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id ED37F3A6883 for ; Wed, 23 Sep 2009 06:03:57 -0700 (PDT) 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 n8ND53uU028480; Wed, 23 Sep 2009 06:05:03 -0700 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 24C9D3D33169; Wed, 23 Sep 2009 09:04:57 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 50D1D4AEFE3; Wed, 23 Sep 2009 09:04:57 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <4A955C21.1010301@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: In the City MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma7413-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 23 Sep 2009 09:04:56 -0400 Sender: mallman@icir.org Message-Id: <20090923130457.50D1D4AEFE3@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 13:03:59 -0000 ----------ma7413-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Joe- Many thanks for the comments. > Regarding Jac88, it's useful to make sure you're referencing the right > paper. There are several versions of this doc, at least two are often > confused: the Sigcomm version (most often cited): > http://portal.acm.org/citation.cfm?doid=205447.205462 > This is 16 pages, and has only a very brief appendices section > > and an extended version that has a long appendix with footnotes (this is > the one that discusses idle times, too): > http://ccr.sigcomm.org/archive/1995/jan95/ccr-9501-jacobson.html > This one is 21 pages, and decidedly NOT a reprint (even with > formatting changes) of the one published at Sigcomm 1988, > despite the note on the web page. > > The second version has most of the details that ended up in TCP > implementations, several of which have been dogging us for years (lack > of slow-start restart after idle in the Web in particular). I don't know > if this is the case for the issues you're citing it for, but it's > certainly worth a check. I think we're OK here. I.e., as far as I know the general notion we are citing is discussed in all versions. And, we cite RFC5681 for the actual spec. > The example on page three considers a window of three segments (FWIW, > it should probably read "a window of three segments' worth of data", > since windows are in bytes not segments). I'm wondering if ACK > compression (as required) affects the example. It's worth either > fixing the example, or addressing the effect of ACK compression (even > if to clarify that there is none) somewhere in the doc. I think you're talking about duplicate ACKs and not ACK compression (ACKs getting squished together in the time domain), right? The assumption here is that stacks are following 5681 which says they should not use duplicate ACKs if there is a hole in the sequence space. I.e., that they should immediately ACK each incoming segment. I'll add a quick note. > The data from BPS+98 implies that the bulk of RTOs can be avoided with > early rexmit. Is that true? Or could there be other reasons for large > numbers of RTOs that early rexmit won't help? If so, it'd be useful to > caveat the impact of the proposed mod. BPS+98 notes the problem ER addresses and solves it using Limited Transmit and also a scheme that sends dummy packets to induce three duplicate ACKs. Without crunching that data I don't know precisely how ER would perform. However, the problems they describe as the big issues with RTOs are the problems that ER addresses. (And, this question of how ER will work in the wild is the key reason for experimental here.) > Also, this paragraph makes an error I saw at the last TCPM meeting > from the Google guy's talk - it equates median transfer size with > median TCP connection duration. HTTP still has persistent connections, > AFAIK, which mean that these aren't correlated. The conclusion that > non-RTO recovery would be useful may be true for short transfers over > persistent connections, not just short TCP connections (which is how I > read "short TCP transfers", since a TCP transfer is over when the FIN > sings ;-) You're just reading this differently from what I meant. I have re-worded: Furthermore, [All00] shows that for one particular web server the median number of bytes carried by a connection is less than four segments, indicating that more than half of the connections will be forced to rely on the RTO timer to recover from any losses that occur. I.e., I meant "transfer size" as the amount of data carried by a connection not the size of some subset of that data. Hopefully the new version is more clear. > Section 2 again starts with math that appears to assume ACK per segment > (maybe I'm not catching this - maybe it's that ACKs aren't compressed -- > or compressable -- when the data comes out of order, but that's worth > noting if so. Sorry, I figure you know this better than I do, so I'll > ask you before I dig into figuring it out. Let me know if you want me to > dig as well...). Per above, I don't think this is an issue. > Section 2 talks about TCP in bytes and SCTP in messages, neither one in > segments. It might be useful to put in enough context there, e.g., that > SCTP includes message boundaries, but that they don't correspond to > segment boundaries (right?). Right. I added a note. > Doublecheck the term 'packet' throughout; I think you mean segments > (i.e., TCP segments don't necessarily map to IP packets, e.g., given > fragmentation). Yep... just sloppy. All fixed. > Sec 2 talks about additional state at the sender for precision; this is > the first time you mention a side-specific cost. It might be useful to > hint earlier whether you are doing a send-side, receiver-side, or > require mods on both sides to achieve a benefit. Seems like it's all > send-side, but the benefit is receiver-side. Also worth noting that this > then would allow widescale impact by deploying this at busy servers, > avoiding per-client deployment for benefit. OK... added a couple words to the intro. > In 2.1, do you want to define this in terms a fixed value of 4*SMSS, > or define it as a pointer (i.e., to the initial CWND, so if init CWND > increases, so does this?) same for the part about packet-based (again, > would that be segment-based?) not referring to 4, but the number of > segments in the initial CWND (e.g., as "currently 4" -- PS, should > that be 4, or shouldn't it be "initial_CWND/SMSS", i.e., a max of 4, > but in most current cases it seems like this would still be 3). No, I don't. This doesn't have anything to do with the initial congestion window size. The "4"---which I thought was well motivated, perhaps not---comes from fast retransmit's magic constant of "3". I.e., if there are at least 4 segments outstanding and we lose one then we'll have a shot at getting 3 dupacks. If there are fewer segments outstanding then we will have no chance at getting 3 dupacks. So, this has nothing to do with the initial window. > (2.b) should call it the 'advertised receive window' (or > receiver-advertised window, whatever is more common) for clarity Fixed. (Also (3.b).) > These rules (2.a, 2.b) seem odd in the context of saying this is a MAY > for SCTP (above the list) and then have a different set of rules in the > paragraph below (end of page 4). IMO, put in two different rulesets > (ditto for section 3, FWIW): > > 1. TCP without SACK or for connections not supporting SACK > > 2. TCP with SACK and SCTP Good catch. I did not do major surgery, but added some words around the SACK / non-SACK variants to make it clear that the non-SACK variant is for TCP only. > This would avoid the self-reference to Early Rexmit in the last > paragraph, which is (AFAICT, again), not yet defined. Did you mean to > define it above: > > When the above two conditions hold and the connection does not > support SACK the duplicate ACK threshold used to trigger a > retransmission MUST be reduced to: > > ER_thresh = ceiling (ownd/SMSS) - 1 > > I would add "we call this reduced ACK threshhold enabling 'Early > Retransimission',and when a retransmission occurs because of ER_thresh, > we call that an Early Retransmission.", even if you split out the rules > for non-SACK and SACK. This allows you to refer to it at the top of page > 5 correctly, since it would now be defined. OK, I didn't add those words exactly, but I did add a quick sentence that concretely defines things (in both 2.1 & 2.2). > Also, maybe I'm missing something, but I searched for ER_thresh all over > the place. It isn't *used* anywhere. I.e., you define a variable but > never use it. Seems like you need to use it where you say "the timer > (ER_thresh) goes off and ..." somewhere specific. However, you say that > you're lowering the fast rexmit threshold. So then wouldn't you be > setting "FR_thresh", not "ER_thresh"? Even if so, it's useful to recap > how the *_thresh value is used. There is no "FR_thresh" sort of variable defined in RFC5681. So, while I understand sort of what you are saying I think this ... When the above two conditions hold and a TCP connection does not support SACK the duplicate ACK threshold used to trigger a retransmission MUST be reduced to: is clear about how one goes about using the threshold. (This is an example ... there are other places with the same text.) > The examples on page 5 need to include a bit about Nagle; if Nagle is > on, you would never have three outstanding 400-byte segments ;-) I didn't change anything here. You can pushback some more, but these examples are in fact advertised as illustrations and I am not sure I want to get into needless discussions about Nagle here. You are right that if Nagle is enable we wouldn't have 10 400~bytes segments outstanding. But, if Nagle is not enabled we certainly could. I don't think for the purposes of the examples this is an overly important point. > When you talk about packet-based rexmit, did you want to say as well > that "a TCP or SCTP that implements packet-based rexmit MUST NOT also > implement byte-based rexmit", i.e., that packet-based rexmit supecedes > byte-based rexmit? I could see the two MAYs being considered > simultaneously, and that would be bad, no? The intent was "here are two choices, pick one". In the intro to section 2 I added this: This document explicitly does not prefer one variant over the other, but leaves the choice to the implementer. > When you say MUST NOT use ER, do you mean to use FR (fast) and LR > (Limited), or is LR a superset of FR? I meant LT and FR. The words now say: When conditions (2.a) and (2.b) do not hold, the transport MUST NOT use Early Retransmit, but rather prefer the standard mechanisms, including Fast Retransmit and Limited Transmit. (and, also they were changed in 2.2). > Not sure about the explanation of the circular list for keeping track > of segment boundaries. You say "fall within this region", but with > SACK the region can be disconnected, so I'm not sure how to interpret > "region". Also, seems like you need to know the length of the > segments too, no? You can't assume they're all the same size... Keeping the list of sequence numbers *does* keep track of the segment sizes. And, SACK does not come into play. This is a list of *transmitted* segments. I added a couple words to note that this is the sender's notion of the right side of the current window. > Which brings me to a wrinkle - what happens if TCP resends data with > different segment sizes, resulting in some segments being on different > boundaries than those that may already be received (e.g., on multipath > when a PMTU update comes in, and data is resent and resegmented > differently). Your segment alg needs to be robust to this, or you need > to explain why that doesn't matter. It doesn't matter because once you retransmit all is moot. Early retransmit only *initiates* loss recovery. What happens after that is not ER's problem. > Sec 3 (Discussion) should start with an overview of what you intend to > discuss. Are these all issues? Do you want to say the benefits too? > Impact on legacy receivers (if any)? Deployment motivation (who does it > benefit, and who does the work?) Deployment asymmetry? etc. I'd then > break the section down to these sorts of topics (e.g., benefits, impact > of failure, deployment). (right now you jump in to the details of the > preferred variant - which IMO belongs in the packet-based section, not > here, then jump to the impact of failure without giving examples of > benefit first) Oh, I dunno ... I agree that this section is a collection of disparate things. I just added some subsections to perhaps make things flow better. > The SACK preference discussion needs more lead-in. The first paragraph > could easily be broken into three paragraphs with better context, and > would make the argument more clear. I didn't do anything here. I re-read and it looks OK to me and nobody else has tripped on it. So, unless you want to say more about what exactly you're looking for here I am going to think it's essentially fine. > Related work needs an intro. OK, I added a sentence. > Also, doesn't the second one > (Bal98) also result in a self-attack, i.e., it opens the CWND because > an additional ACK will be received, even though no data is sent? I.e., > there's a side-effect to this that is probably worth > avoiding... (separate question - has anyone noted that 0-window > segment ACKs shouldn't open the window, or is that already the case?) I don't think it is worth getting into such details in the related work section of this document. If someone wants to write the spec for the scheme from [Bal98] then we can argue about the specifics. > Other considerations: seems like you're making TCP send more segments > into the net when data is being lost, vs. the existing mechanisms. If > that's the case, and if loss is due to buffer overload, are you making > things potentially worse? If not, please explain. I don't understand this point. Is it relative to ER or [Bal98]? > I don't see why you have a normative reference to Eiffel; you don't > depend on it that way. Seems like that's an informational reference in > this case - esp. since you refer to it in the appendix discussing > research options, not the body. Yep. That has been moved previously. There is *no* reliance on Eifel. For more than one reason. Again, many thanks for the detailed comments. I have rolled the changes enumerated above into my working version. My collaborators will have to put their oar in the water, but I expect we'll get a new version pushed to the repository shortly. allman ----------ma7413-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkq6HPcACgkQWyrrWs4yIs5PEQCggwL43d48/ZBSsjToLwp3SMTc KxMAn0V2ah/IjXRVZnTBUDxpOHe7UhmT =Pp2x -----END PGP SIGNATURE----- ----------ma7413-1-- From touch@ISI.EDU Wed Sep 23 07:28:25 2009 Return-Path: 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 609CE3A6A22 for ; Wed, 23 Sep 2009 07:28:25 -0700 (PDT) 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=[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 2urxJNR-cwR0 for ; Wed, 23 Sep 2009 07:28:24 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 2D72B3A6A0F for ; Wed, 23 Sep 2009 07:28:24 -0700 (PDT) Received: from [70.208.68.126] (126.sub-70-208-68.myvzw.com [70.208.68.126]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n8NESEq8003755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Sep 2009 07:28:19 -0700 (PDT) Message-ID: <4ABA307D.5080408@isi.edu> Date: Wed, 23 Sep 2009 07:28:13 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mallman@icir.org References: <20090923130457.50D1D4AEFE3@lawyers.icir.org> In-Reply-To: <20090923130457.50D1D4AEFE3@lawyers.icir.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n8NESEq8003755 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 14:28:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Mark, Mark Allman wrote: > Joe- > > Many thanks for the comments. ... >> The example on page three considers a window of three segments (FWIW, >> it should probably read "a window of three segments' worth of data", >> since windows are in bytes not segments). I'm wondering if ACK >> compression (as required) affects the example. It's worth either >> fixing the example, or addressing the effect of ACK compression (even >> if to clarify that there is none) somewhere in the doc. > > I think you're talking about duplicate ACKs and not ACK compression > (ACKs getting squished together in the time domain), right? The > assumption here is that stacks are following 5681 which says they should > not use duplicate ACKs if there is a hole in the sequence space. I.e., > that they should immediately ACK each incoming segment. I'll add a > quick note. I had been thinking of compression (sending an ACK every other segment), i.e., you have a window of three segments, but you will receive one ACK quickly, and the second ACK will just stall for some time (200 ms?). It's like Nagle on the ACK side - would it wait for some time before sending an ACK for a single segment (i.e., in anticipation of squishing the next ACK with the pending one). At least that's what I'm wondering about. >> The data from BPS+98 implies that the bulk of RTOs can be avoided with >> early rexmit. Is that true? Or could there be other reasons for large >> numbers of RTOs that early rexmit won't help? If so, it'd be useful to >> caveat the impact of the proposed mod. > > BPS+98 notes the problem ER addresses and solves it using Limited > Transmit and also a scheme that sends dummy packets to induce three > duplicate ACKs. Without crunching that data I don't know precisely how > ER would perform. However, the problems they describe as the big issues > with RTOs are the problems that ER addresses. Worth noting that more explicitly. > (And, this question of how ER will work in the wild is the key reason > for experimental here.) > >> Also, this paragraph makes an error I saw at the last TCPM meeting >> from the Google guy's talk - it equates median transfer size with >> median TCP connection duration. HTTP still has persistent connections, >> AFAIK, which mean that these aren't correlated. The conclusion that >> non-RTO recovery would be useful may be true for short transfers over >> persistent connections, not just short TCP connections (which is how I >> read "short TCP transfers", since a TCP transfer is over when the FIN >> sings ;-) > > You're just reading this differently from what I meant. I have > re-worded: > > Furthermore, [All00] shows that for one particular web server the > median number of bytes carried by a connection is less than four > segments, indicating that more than half of the connections will be > forced to rely on the RTO timer to recover from any losses that > occur. > > I.e., I meant "transfer size" as the amount of data carried by a > connection not the size of some subset of that data. Hopefully the new > version is more clear. Yes. ... >> In 2.1, do you want to define this in terms a fixed value of 4*SMSS, >> or define it as a pointer (i.e., to the initial CWND, so if init CWND >> increases, so does this?) same for the part about packet-based (again, >> would that be segment-based?) not referring to 4, but the number of >> segments in the initial CWND (e.g., as "currently 4" -- PS, should >> that be 4, or shouldn't it be "initial_CWND/SMSS", i.e., a max of 4, >> but in most current cases it seems like this would still be 3). > > No, I don't. This doesn't have anything to do with the initial > congestion window size. The "4"---which I thought was well motivated, > perhaps not---comes from fast retransmit's magic constant of "3". I.e., > if there are at least 4 segments outstanding and we lose one then we'll > have a shot at getting 3 dupacks. If there are fewer segments > outstanding then we will have no chance at getting 3 dupacks. So, this > has nothing to do with the initial window. I didn't get that as clearly. It might be useful to reiterate it when the number is introduced (maybe a few times for people like me who miss it). ... >> Also, maybe I'm missing something, but I searched for ER_thresh all over >> the place. It isn't *used* anywhere. I.e., you define a variable but >> never use it. Seems like you need to use it where you say "the timer >> (ER_thresh) goes off and ..." somewhere specific. However, you say that >> you're lowering the fast rexmit threshold. So then wouldn't you be >> setting "FR_thresh", not "ER_thresh"? Even if so, it's useful to recap >> how the *_thresh value is used. > > There is no "FR_thresh" sort of variable defined in RFC5681. So, while > I understand sort of what you are saying I think this ... > > When the above two conditions hold and a TCP connection does not > support SACK the duplicate ACK threshold used to trigger a > retransmission MUST be reduced to: > > is clear about how one goes about using the threshold. (This is an > example ... there are other places with the same text.) It's simpler than that - you have a variable called ER_thresh. You don't define it. You explain what values to set it to, but you never use it to do anything. I.e., you have an undefined variable that you set, but don't declare and never use. ... >> The examples on page 5 need to include a bit about Nagle; if Nagle is >> on, you would never have three outstanding 400-byte segments ;-) > > I didn't change anything here. You can pushback some more, but these > examples are in fact advertised as illustrations and I am not sure I > want to get into needless discussions about Nagle here. You are right > that if Nagle is enable we wouldn't have 10 400~bytes segments > outstanding. But, if Nagle is not enabled we certainly could. I don't > think for the purposes of the examples this is an overly important > point. Nagle is on by default. Your example should be very clear about the fact that you expect the default to be overridden, or should include Nagle IMO. I don't think you need many different cases, but if this works much better with Nagle off, then the doc needs a bit of explanation on this. ... >> Which brings me to a wrinkle - what happens if TCP resends data with >> different segment sizes, resulting in some segments being on different >> boundaries than those that may already be received (e.g., on multipath >> when a PMTU update comes in, and data is resent and resegmented >> differently). Your segment alg needs to be robust to this, or you need >> to explain why that doesn't matter. > > It doesn't matter because once you retransmit all is moot. Early > retransmit only *initiates* loss recovery. What happens after that is > not ER's problem. Might (might) be worth noting, if only for corner-case people like me. ... >> Other considerations: seems like you're making TCP send more segments >> into the net when data is being lost, vs. the existing mechanisms. If >> that's the case, and if loss is due to buffer overload, are you making >> things potentially worse? If not, please explain. > > I don't understand this point. Is it relative to ER or [Bal98]? Relative to not doing ER. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkq6MH0ACgkQE5f5cImnZruN8ACfVaVK9dWqI7kY7Xsw8ITKK935 C1sAn2phkk5AuUaOsHGSYvpgqQtG98To =fhDK -----END PGP SIGNATURE----- From mallman@icir.org Wed Sep 23 07:32:50 2009 Return-Path: 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 D5A0C3A6A37 for ; Wed, 23 Sep 2009 07:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 RBYAaAWjfawO for ; Wed, 23 Sep 2009 07:32:49 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id E7E223A69C8 for ; Wed, 23 Sep 2009 07:32:49 -0700 (PDT) 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 n8NEXtV3001102; Wed, 23 Sep 2009 07:33:56 -0700 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 7BF9E3D33A09; Wed, 23 Sep 2009 10:33:49 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A77E94AF45B; Wed, 23 Sep 2009 10:33:49 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <4ABA307D.5080408@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: In the City MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma12748-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 23 Sep 2009 10:33:49 -0400 Sender: mallman@icir.org Message-Id: <20090923143349.A77E94AF45B@lawyers.icir.org> Cc: tcpm@ietf.org Subject: [tcpm] delayed ACKs (was Re: Review: draft-ietf-tcpm-early-rexmt-01) 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 14:32:50 -0000 ----------ma12748-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > >> The example on page three considers a window of three segments (FWIW, > >> it should probably read "a window of three segments' worth of data", > >> since windows are in bytes not segments). I'm wondering if ACK > >> compression (as required) affects the example. It's worth either > >> fixing the example, or addressing the effect of ACK compression (even > >> if to clarify that there is none) somewhere in the doc. > > > > I think you're talking about duplicate ACKs and not ACK compression > > (ACKs getting squished together in the time domain), right? The > > assumption here is that stacks are following 5681 which says they should > > not use duplicate ACKs if there is a hole in the sequence space. I.e., > > that they should immediately ACK each incoming segment. I'll add a > > quick note. > > I had been thinking of compression (sending an ACK every other > segment), i.e., you have a window of three segments, but you will > receive one ACK quickly, and the second ACK will just stall for some > time (200 ms?). It's like Nagle on the ACK side - would it wait for > some time before sending an ACK for a single segment (i.e., in > anticipation of squishing the next ACK with the pending one). At least > that's what I'm wondering about. Damn... "Joe, let me correct your terminology with some bogus terminology of my own!" Where I wrote "duplicate ACK" I meant "delayed ACK". I.e., what you're describing is not ACK compression, but delayed ACKs. And, it is certainly not duplicate ACKs as I tried to make it out to be. allman ----------ma12748-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkq6McwACgkQWyrrWs4yIs6MxwCfWgH/WAJv2shoh9kAH/yvxI0w oQIAn3JXuJFx6K2W+IcyGzQ2M/LGPKS6 =Tek+ -----END PGP SIGNATURE----- ----------ma12748-1-- From touch@ISI.EDU Wed Sep 23 07:42:33 2009 Return-Path: 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 E29CF3A6803 for ; Wed, 23 Sep 2009 07:42:33 -0700 (PDT) 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=[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 lLYktmJpd9CX for ; Wed, 23 Sep 2009 07:42:33 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 301ED3A659A for ; Wed, 23 Sep 2009 07:42:33 -0700 (PDT) Received: from [70.208.68.126] (126.sub-70-208-68.myvzw.com [70.208.68.126]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n8NEaBZL005128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Sep 2009 07:36:16 -0700 (PDT) Message-ID: <4ABA325B.2000607@isi.edu> Date: Wed, 23 Sep 2009 07:36:11 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mallman@icir.org References: <20090923143349.A77E94AF45B@lawyers.icir.org> In-Reply-To: <20090923143349.A77E94AF45B@lawyers.icir.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n8NEaBZL005128 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] delayed ACKs (was Re: Review: draft-ietf-tcpm-early-rexmt-01) 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 14:42:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Allman wrote: ... >> I had been thinking of compression (sending an ACK every other >> segment), i.e., you have a window of three segments, but you will >> receive one ACK quickly, and the second ACK will just stall for some >> time (200 ms?). It's like Nagle on the ACK side - would it wait for >> some time before sending an ACK for a single segment (i.e., in >> anticipation of squishing the next ACK with the pending one). At least >> that's what I'm wondering about. > > Damn... "Joe, let me correct your terminology with some bogus > terminology of my own!" > > Where I wrote "duplicate ACK" I meant "delayed ACK". I.e., what you're > describing is not ACK compression, but delayed ACKs. And, it is > certainly not duplicate ACKs as I tried to make it out to be. Thanks - yes, that's what I meant. Sorry for the confusion ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkq6MlsACgkQE5f5cImnZrv0/wCgpSYNMtFELC3ha9Qcua27jHME HdEAn1Vovig+nW5Aij1SGYyFo61m75Fp =aMhz -----END PGP SIGNATURE----- From mallman@icir.org Wed Sep 23 08:00:33 2009 Return-Path: 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 7D17F3A68DF for ; Wed, 23 Sep 2009 08:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 HpKLT+w1w6TC for ; Wed, 23 Sep 2009 08:00:32 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 794A828C128 for ; Wed, 23 Sep 2009 08:00:32 -0700 (PDT) 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 n8NF1ctE002446; Wed, 23 Sep 2009 08:01:38 -0700 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 7F9CD3D33CA0; Wed, 23 Sep 2009 11:01:32 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B2B3B4AF55C; Wed, 23 Sep 2009 11:01:32 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <4ABA307D.5080408@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: In the City MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma14410-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 23 Sep 2009 11:01:32 -0400 Sender: mallman@icir.org Message-Id: <20090923150132.B2B3B4AF55C@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 15:00:33 -0000 ----------ma14410-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Joe- Thanks for the followup. I am taking most of this as "Joe would have done it differently" and not as show-stoppers. Please yell if this is not the case. But, in particular, > > There is no "FR_thresh" sort of variable defined in RFC5681. So, while > > I understand sort of what you are saying I think this ... > > > > When the above two conditions hold and a TCP connection does not > > support SACK the duplicate ACK threshold used to trigger a > > retransmission MUST be reduced to: > > > > is clear about how one goes about using the threshold. (This is an > > example ... there are other places with the same text.) > > It's simpler than that - you have a variable called ER_thresh. You don't > define it. You explain what values to set it to, but you never use it to > do anything. > > I.e., you have an undefined variable that you set, but don't declare and > never use. ...in a *program* we didn't write. :-) I think it is clear from the text what is going on here. I.e., that "the duplicate ACK threshold used to trigger a retransmission MUST be reduced to: ER_thresh" is perfectly clear. (ER_thresh is used in the text and so removing it as spurious is not the simple answer.) > Nagle is on by default. Your example should be very clear about the > fact that you expect the default to be overridden, or should include > Nagle IMO. > > I don't think you need many different cases, but if this works much > better with Nagle off, then the doc needs a bit of explanation on > this. It's not a question or working better or worse with Nagle on or off. The examples are *illustrations* (advertised as such) of how a trivial estimation of the number of outstanding segments based on the number of bytes outstanding can be wrong (in both directions). It is not meant to be any deeper than that. It does not need to be complicated by extraneous details. > >> Other considerations: seems like you're making TCP send more > >> segments into the net when data is being lost, vs. the existing > >> mechanisms. If that's the case, and if loss is due to buffer > >> overload, are you making things potentially worse? If not, please > >> explain. > > > > I don't understand this point. Is it relative to ER or [Bal98]? > > Relative to not doing ER. In that case I think you're wrong. In the case of actual loss that loss is going to be repaired with a retransmit. We send that retransmit at a different point than the existing mechanism (which would wait for the RTO to resend the exact same packet). So, we are not sending more segments into the network. I suppose that one could argue that by sending the segment sooner than the RTO we are perhaps not giving the congestion as much of a chance to clear from the router buffers. But, that's a pretty thin argument given that fast retransmit does roughly the same thing and the network has not melted down because of it. I'd rather just leave this as part of the experiment that would need to be done to put this on the standards track and not something that gates an experimental document. In the case of reordering (no actual loss; not the case you bring up above) then, yes, ER does inject more segments than necessary into the network. That is shown in the appendix. Also, that doesn't worry me as much because we are not sending those extra segments into obviously congested networks. allman ----------ma14410-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkq6OEoACgkQWyrrWs4yIs5UZQCfemUQnEsg9BgOJ8Zr7A1TzD6R D9QAn2Ga1yE8VxeymRy29mQGow44MoAY =eMoH -----END PGP SIGNATURE----- ----------ma14410-1-- From touch@ISI.EDU Wed Sep 23 08:11:36 2009 Return-Path: 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 A5FB43A6967 for ; Wed, 23 Sep 2009 08:11:36 -0700 (PDT) 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 fNOqR6WoG4QO for ; Wed, 23 Sep 2009 08:11:35 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id B7E5C3A68AA for ; Wed, 23 Sep 2009 08:11:35 -0700 (PDT) Received: from [70.208.68.126] (126.sub-70-208-68.myvzw.com [70.208.68.126]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n8NFBCx9012187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Sep 2009 08:11:18 -0700 (PDT) Message-ID: <4ABA3A90.30901@isi.edu> Date: Wed, 23 Sep 2009 08:11:12 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mallman@icir.org References: <20090923150132.B2B3B4AF55C@lawyers.icir.org> In-Reply-To: <20090923150132.B2B3B4AF55C@lawyers.icir.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n8NFBCx9012187 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 15:11:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Allman wrote: > Joe- > > Thanks for the followup. I am taking most of this as "Joe would have > done it differently" and not as show-stoppers. Please yell if this is > not the case. Just suggestions on clarifications that might be useful. No show-stoppers. I think most of these can be addressed with brief bits of text. see below... > But, in particular, > >>> There is no "FR_thresh" sort of variable defined in RFC5681. So, while >>> I understand sort of what you are saying I think this ... >>> >>> When the above two conditions hold and a TCP connection does not >>> support SACK the duplicate ACK threshold used to trigger a >>> retransmission MUST be reduced to: >>> >>> is clear about how one goes about using the threshold. (This is an >>> example ... there are other places with the same text.) >> It's simpler than that - you have a variable called ER_thresh. You don't >> define it. You explain what values to set it to, but you never use it to >> do anything. >> >> I.e., you have an undefined variable that you set, but don't declare and >> never use. > > ...in a *program* we didn't write. :-) Well, you wrote the lines that *set* the variable ;-)) > I think it is clear from the text what is going on here. I.e., that > "the duplicate ACK threshold used to trigger a retransmission MUST be > reduced to: ER_thresh" is perfectly clear. OK, so I missed this. It might be useful to make it more clear, e.g., dupack_thresh = ER_thresh (or whatever the dupack threshold variable name is) > (ER_thresh is used in the text and so removing it as spurious is not the > simple answer.) I don't want to remove it. I just want to be more clear about using it. >> Nagle is on by default. Your example should be very clear about the >> fact that you expect the default to be overridden, or should include >> Nagle IMO. >> >> I don't think you need many different cases, but if this works much >> better with Nagle off, then the doc needs a bit of explanation on >> this. > > It's not a question or working better or worse with Nagle on or off. > The examples are *illustrations* (advertised as such) of how a trivial > estimation of the number of outstanding segments based on the number of > bytes outstanding can be wrong (in both directions). It is not meant to > be any deeper than that. It does not need to be complicated by > extraneous details. Can you just state that, i.e., "Nagle is off to simplify the example"? > >>>> Other considerations: seems like you're making TCP send more >>>> segments into the net when data is being lost, vs. the existing >>>> mechanisms. If that's the case, and if loss is due to buffer >>>> overload, are you making things potentially worse? If not, please >>>> explain. >>> I don't understand this point. Is it relative to ER or [Bal98]? > >> Relative to not doing ER. > > In that case I think you're wrong. In the case of actual loss that loss > is going to be repaired with a retransmit. We send that retransmit at a > different point than the existing mechanism (which would wait for the > RTO to resend the exact same packet). So, we are not sending more > segments into the network. I'm just suggesting it would be useful to include that answer. I didn't know what it was, just that it wasn't addressed. > I suppose that one could argue that by sending the segment sooner than > the RTO we are perhaps not giving the congestion as much of a chance to > clear from the router buffers. But, that's a pretty thin argument given > that fast retransmit does roughly the same thing and the network has not > melted down because of it. I'd rather just leave this as part of the > experiment that would need to be done to put this on the standards track" OK to also say "and this is expected to be confirmed by experiments". > In the case of reordering (no actual loss; not the case you bring up > above) then, yes, ER does inject more segments than necessary into the > network. That is shown in the appendix. Also, that doesn't worry me as > much because we are not sending those extra segments into obviously > congested networks. I'm not particularly worried, just asking that the issue be addressed - even briefly. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkq6OpAACgkQE5f5cImnZrvh9ACfa8z7QrPBMH78F777fkTG0gLE 5TkAnR15ZEeVOUNimtSW+drjqTL/UUeL =/uXV -----END PGP SIGNATURE----- From Alexander.Zimmermann@nets.rwth-aachen.de Wed Sep 23 08:37:06 2009 Return-Path: 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 24D513A6887 for ; Wed, 23 Sep 2009 08:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.434 X-Spam-Level: X-Spam-Status: No, score=-4.434 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] 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 gEcj-WxCkQ1M for ; Wed, 23 Sep 2009 08:37:05 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 006EB3A6A15 for ; Wed, 23 Sep 2009 08:37:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KQF00GU8KRLSID0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 23 Sep 2009 17:38:09 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.44,439,1249250400"; d="scan'208";a="14769303" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 23 Sep 2009 17:38:09 +0200 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KQF00EMQKRLVP70@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 23 Sep 2009 17:38:09 +0200 (CEST) From: Alexander Zimmermann In-reply-to: <4ABA307D.5080408@isi.edu> Date: Wed, 23 Sep 2009 17:38:09 +0200 Message-id: References: <20090923130457.50D1D4AEFE3@lawyers.icir.org> <4ABA307D.5080408@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1076) Cc: "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 15:37:06 -0000 Hi Joe, hi Mark, may be we can reuse a paragraph from RFC 3517: "We define a variable "DupThresh" that holds the number of duplicate acknowledgments required to trigger a retransmission. Per [RFC2581] this threshold is defined to be 3 duplicate acknowledgments. However, implementers should consult any updates to [RFC2581] to determine the current value for DupThresh (or method for determining its value)." First, it's easier to see where the magic *4* comes from, second it's future-proof when "5681bis" alters the number of duplicate Acks required for fast retransmit. :-) Alex Am 23.09.2009 um 16:28 schrieb Joe Touch: > ... >>> In 2.1, do you want to define this in terms a fixed value of 4*SMSS, >>> or define it as a pointer (i.e., to the initial CWND, so if init >>> CWND >>> increases, so does this?) same for the part about packet-based >>> (again, >>> would that be segment-based?) not referring to 4, but the number of >>> segments in the initial CWND (e.g., as "currently 4" -- PS, should >>> that be 4, or shouldn't it be "initial_CWND/SMSS", i.e., a max of 4, >>> but in most current cases it seems like this would still be 3). >> >> No, I don't. This doesn't have anything to do with the initial >> congestion window size. The "4"---which I thought was well >> motivated, >> perhaps not---comes from fast retransmit's magic constant of "3". >> I.e., >> if there are at least 4 segments outstanding and we lose one then >> we'll >> have a shot at getting 3 dupacks. If there are fewer segments >> outstanding then we will have no chance at getting 3 dupacks. So, >> this >> has nothing to do with the initial window. > > I didn't get that as clearly. It might be useful to reiterate it when > the number is introduced (maybe a few times for people like me who > miss it). // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From touch@ISI.EDU Wed Sep 23 08:40:11 2009 Return-Path: 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 A77013A659A for ; Wed, 23 Sep 2009 08:40:11 -0700 (PDT) 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=[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 7+42Ra2tKZPO for ; Wed, 23 Sep 2009 08:40:05 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 1C43C3A6887 for ; Wed, 23 Sep 2009 08:40:05 -0700 (PDT) Received: from [70.208.68.126] (126.sub-70-208-68.myvzw.com [70.208.68.126]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n8NFebfL018789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Sep 2009 08:40:41 -0700 (PDT) Message-ID: <4ABA4174.6030207@isi.edu> Date: Wed, 23 Sep 2009 08:40:36 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexander Zimmermann References: <20090923130457.50D1D4AEFE3@lawyers.icir.org> <4ABA307D.5080408@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n8NFebfL018789 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 15:40:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Works for me. Joe Alexander Zimmermann wrote: > Hi Joe, hi Mark, > > may be we can reuse a paragraph from RFC 3517: > > "We define a variable "DupThresh" that holds the number of duplicate > acknowledgments required to trigger a retransmission. Per [RFC2581] this > threshold is defined to be 3 duplicate acknowledgments. However, > implementers should consult any updates to [RFC2581] to determine the > current value for DupThresh (or method for determining its value)." > > First, it's easier to see where the magic *4* comes from, second it's > future-proof when "5681bis" alters the number of duplicate Acks required > for fast retransmit. :-) > > Alex > > Am 23.09.2009 um 16:28 schrieb Joe Touch: > >> ... >>>> In 2.1, do you want to define this in terms a fixed value of 4*SMSS, >>>> or define it as a pointer (i.e., to the initial CWND, so if init CWND >>>> increases, so does this?) same for the part about packet-based (again, >>>> would that be segment-based?) not referring to 4, but the number of >>>> segments in the initial CWND (e.g., as "currently 4" -- PS, should >>>> that be 4, or shouldn't it be "initial_CWND/SMSS", i.e., a max of 4, >>>> but in most current cases it seems like this would still be 3). >>> >>> No, I don't. This doesn't have anything to do with the initial >>> congestion window size. The "4"---which I thought was well motivated, >>> perhaps not---comes from fast retransmit's magic constant of "3". I.e., >>> if there are at least 4 segments outstanding and we lose one then we'll >>> have a shot at getting 3 dupacks. If there are fewer segments >>> outstanding then we will have no chance at getting 3 dupacks. So, this >>> has nothing to do with the initial window. >> >> I didn't get that as clearly. It might be useful to reiterate it when >> the number is introduced (maybe a few times for people like me who >> miss it). > > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 > // RWTH Aachen University > // Ahornstr. 55, 52056 Aachen, Germany > // phone: (49-241) 80-21422, fax: (49-241) 80-22220 > // email: zimmermann@cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkq6QXQACgkQE5f5cImnZrvejQCg53uwYJsYZ2S1vVQ1udQT4/LL eFUAn0/WXmKENoHZPHqWX6in8De+V3cw =eLRy -----END PGP SIGNATURE----- From andrew.knutsen@bluecoat.com Wed Sep 23 19:11:35 2009 Return-Path: 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 E75673A6879 for ; Wed, 23 Sep 2009 19:11:35 -0700 (PDT) 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 Gux12yryMeB7 for ; Wed, 23 Sep 2009 19:11:35 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 442A23A67AE for ; Wed, 23 Sep 2009 19:11:35 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n8O2CgH3020898 for ; Wed, 23 Sep 2009 19:12:42 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 19:12:37 -0700 Message-ID: <4ABAD595.7050303@bluecoat.com> Date: Wed, 23 Sep 2009 19:12:37 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Sep 2009 02:12:37.0632 (UTC) FILETIME=[7CA70800:01CA3CBC] Cc: Ron Frederick , Jamshid Mahdavi , Qing Li , Wei Jen Yeh Subject: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 02:11:36 -0000 This version addresses Wesley's comments and questions, and also has a re-organized "Operation" section addressing off-list comments. This version should not have any substantive changes to the option. It is available at . Again, your time reviewing this document is appreciated. Andrew From cait@asomi.com Thu Sep 24 11:01:44 2009 Return-Path: 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 8379728C173 for ; Thu, 24 Sep 2009 11:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 cqt-M3hRRJ9y for ; Thu, 24 Sep 2009 11:01:43 -0700 (PDT) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by core3.amsl.com (Postfix) with ESMTP id D500328C16B for ; Thu, 24 Sep 2009 11:01:41 -0700 (PDT) Received: (qmail 32721 invoked from network); 24 Sep 2009 18:02:42 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 24 Sep 2009 18:02:42 -0000 Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Caitlin Bestler In-Reply-To: <4ABAD595.7050303@bluecoat.com> Date: Thu, 24 Sep 2009 11:02:42 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <4ABAD595.7050303@bluecoat.com> To: Andrew Knutsen X-Mailer: Apple Mail (2.1075.2) Cc: tcpm@ietf.org Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 18:01:44 -0000 On Sep 23, 2009, at 7:12 PM, Andrew Knutsen wrote: > > This version addresses Wesley's comments and questions, and also > has a re-organized "Operation" section addressing off-list comments. > This version should not have any substantive changes to the option. > It is available at >. > > Again, your time reviewing this document is appreciated. > > Andrew > The applicability of this proposed option needs more explanation and justification. The part that makes perfect sense is the desire to have a middle-box discovery probe that follows the same path that a TCP packet would. What is not clear is why the probe is based on OUI-specific secret handshakes. 1) Why not simply probe for "first middlebox that sees this once the TTL is less than or equal to X"? That would enable discovering all middleboxes that understood this option, no matter who made them. Once identified SNMP can be used to obtain vendor specific information. 2) If vendor X has *two* middleboxes on the path from A to B, is there any way to control who answers? One further question, what is the correct handling of redundant SYN- ACKs from different sources? This could happen if a middle-box takes longer than the initiator anticipates and the retransmission follows a different path due to intermittent failures and/or load balancing. -- Caitlin Bestler cait@asomi.com http://www.asomi.com/CaitlinBestlerResume.html From shore@arsc.edu Thu Sep 24 12:06:23 2009 Return-Path: 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 672B83A67F4 for ; Thu, 24 Sep 2009 12:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 jA55YKZhAC9g for ; Thu, 24 Sep 2009 12:06:22 -0700 (PDT) Received: from arsc.edu (mail1.arsc.edu [IPv6:2001:480:150:75::229]) by core3.amsl.com (Postfix) with ESMTP id F05CE3A6838 for ; Thu, 24 Sep 2009 12:06:21 -0700 (PDT) Received: from viking-e0.arsc.edu (viking-e0.arsc.edu [IPv6:2001:480:150:860:223:32ff:feda:4a52]) by arsc.edu (20090828.ARSC) with ESMTP id n8OJ7BRZ010699; Thu, 24 Sep 2009 11:07:11 -0800 (AKDT) Message-Id: <9134DEC2-1457-4E6A-922C-4FEBA755D0C2@arsc.edu> From: Melinda Shore To: Caitlin Bestler In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Sep 2009 11:07:11 -0800 References: <4ABAD595.7050303@bluecoat.com> X-Mailer: Apple Mail (2.936) X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: No geolocation information available for 2001:480:150:860:223:32ff:feda:4a52 X-CanItPRO-Stream: default X-Canit-Stats-ID: 3171412 - 7c70225b4e76 X-Antispam-Training-Forget: https://canit.arsc.edu:8787/b.php?i=3171412&m=7c70225b4e76&c=f X-Antispam-Training-Nonspam: https://canit.arsc.edu:8787/b.php?i=3171412&m=7c70225b4e76&c=n X-Antispam-Training-Spam: https://canit.arsc.edu:8787/b.php?i=3171412&m=7c70225b4e76&c=s X-Scanned-By: CanIt (www . roaringpenguin . com) on IPv6:2001:480:150:75::167 Cc: tcpm@ietf.org Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 19:06:23 -0000 On Sep 24, 2009, at 10:02 AM, Caitlin Bestler wrote: > The part that makes perfect sense is the desire to have a middle-box > discovery probe that follows > the same path that a TCP packet would. I think there's a case to be made for in-band discovery options, which is no something we've seen previously. We've had out-of-band path- coupled and out-of-band path-decoupled, but not this. (Next up - in-band path-decoupled ... ) However, I agree about the OUI question, and I think the stuff discussing problems along a path could be considered either extremely clear or extremely muddled, since it doesn't exist. There are not just problems around two devices from the same vendor, but also problems about multiple types of devices from the same vendor, etc. Presumably you could infer some stuff about ordering and topology from TTL data if it were written into the response. I'd argue rather strongly that you'd want an ordered list of as many of the middleboxes as were discoverable - this is not that much like tunnel endpoint discovery. I like the idea of having some sort of in-band discovery mechanism but I'm not sure about tying it to TCP (although there's an implied requirement for a response, which you can't guarantee with, say, UDP or some other transports) and I'm really not sure about v4. Melinda From cait@asomi.com Thu Sep 24 13:10:17 2009 Return-Path: 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 B8BF73A6887 for ; Thu, 24 Sep 2009 13:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6] 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 6O+uefJLqxVf for ; Thu, 24 Sep 2009 13:10:16 -0700 (PDT) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by core3.amsl.com (Postfix) with ESMTP id CE08B3A67A8 for ; Thu, 24 Sep 2009 13:10:16 -0700 (PDT) Received: (qmail 8941 invoked from network); 24 Sep 2009 20:11:20 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 24 Sep 2009 20:11:20 -0000 Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed From: Caitlin Bestler In-Reply-To: <9134DEC2-1457-4E6A-922C-4FEBA755D0C2@arsc.edu> Date: Thu, 24 Sep 2009 13:11:20 -0700 Content-Transfer-Encoding: 7bit Message-Id: <7B4A912A-49F2-45F7-8EAB-CCE3525A2253@asomi.com> References: <4ABAD595.7050303@bluecoat.com> <9134DEC2-1457-4E6A-922C-4FEBA755D0C2@arsc.edu> To: Melinda Shore X-Mailer: Apple Mail (2.1075.2) Cc: tcpm@ietf.org Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 20:10:17 -0000 On Sep 24, 2009, at 12:07 PM, Melinda Shore wrote: > > this is not that much like tunnel endpoint discovery. > > I like the idea of having some sort of in-band > discovery mechanism but I'm not sure about tying > it to TCP (although there's an implied requirement > for a response, which you can't guarantee with, say, > UDP or some other transports) and I'm really not > sure about v4. > > Melinda > Doing the discovery in a TCP packet is the only way to ensure that the packet will be routed/forwarded on the same path as the actual TCP traffic. Consider that A is sending a connection request into cloud B for IP X, TCP Port Y. Now suppose there is a middle-box guarding cloud B which will divert connection requests for IP X:Port Y to IP Z. Even without knowing of this special discovery option, the B-entry middle-box will still divert the SYN packet to IP Z. If either the endpoint or a later middle-box understands the option there will be a Response. But if you tried doing a non-TCP probe then the packet will just continue on to the probably non-existent IP X, or perhaps be diverted to a different catchall internal box. This is actually true for *each* transport that wants to do middle-box discovery, since the set of middle-boxes can be different for each transport. Of course TCP middle-boxes are far more worthy of discovery because historically they tend to do more mischief/provide more services. By contrast, if middle-boxes do anything with SCTP packets it is typically to drop them or forward all of them to a default DMZ machine. I think the key issue here is whether a mechanism can be defined that will allow for discovery of any and all middle-boxes that have support for the newly defined probe, even if there are other forwarding nodes along the way that do not understand the new option. The OUI approach seems optimized for individual middle-box vendors to do custom probing for their boxes. I do not think that is a suitable strategy to be adopted as an RFC. -- Caitlin Bestler cait@asomi.com http://www.asomi.com/CaitlinBestlerResume.html From andrew.knutsen@bluecoat.com Thu Sep 24 18:19:53 2009 Return-Path: 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 0D0CE3A695C for ; Thu, 24 Sep 2009 18:19:53 -0700 (PDT) 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 GCtsfN9lGO9Y for ; Thu, 24 Sep 2009 18:19:51 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id DD87D3A690F for ; Thu, 24 Sep 2009 18:19:51 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n8P1JEwv022989; Thu, 24 Sep 2009 18:21:00 -0700 (PDT) Received: from [10.150.1.90] ([10.150.1.90]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Sep 2009 18:19:21 -0700 Message-ID: <4ABC1A99.1000409@bluecoat.com> Date: Thu, 24 Sep 2009 18:19:21 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: tcpm@ietf.org References: <4ABAD595.7050303@bluecoat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Sep 2009 01:19:22.0046 (UTC) FILETIME=[36590DE0:01CA3D7E] Cc: Jamshid Mahdavi , Qing Li , Wei Jen Yeh , Ron Frederick Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 01:19:53 -0000 I'll try to respond to all the issues raised today in this message: Caitlin Bestler wrote: > What is not clear is why the probe is based on OUI-specific secret > handshakes. This draft represents an effort to move technology which is currently shipping from at least three vendors toward standardization. The handshakes are currently not only "secret", but use invalid option kinds. This draft allows movement away from the invalid kinds; getting all vendors to disclose and agree on the rest is future effort, which would result in the OUI-less IANA-registered types. We could have put this "history" in the draft, but it didn't seem appropriate. I did include it in the last announcement. > > 1) Why not simply probe for "first middlebox that sees this once the > TTL is less than or equal to X"? > That would enable discovering all middleboxes that understood > this option, no matter who > made them. Once identified SNMP can be used to obtain vendor > specific information. - Generally, you want to probe for a specific type of device, which will pair with the originator. - Performance is a very important factor here. SNMP adds delay, just like the other existing alternates mentioned in the draft. > 2) If vendor X has *two* middleboxes on the path from A to B, is there > any way to control > who answers? This would be specific to the device type, presumably based on the target data, although other info like the TTL could of course be used. I don't think there is anything in the draft saying a node cannot both respond to the probe and send it farther along, or even modify the target data and send it along. These actions would be defined with the device type registration. > > One further question, what is the correct handling of redundant > SYN-ACKs from different > sources? This could happen if a middle-box takes longer than the > initiator anticipates > and the retransmission follows a different path due to intermittent > failures and/or > load balancing. This is a good question, however I think its best considered an endpoint issue, ie, not one requiring more protocol. All existing implementations (from the three or more vendors I mentioned above) should be prepared to handle this. Without saying anything specific, I will say we've never had a bug reported because of this situation ;-). Andrew From cait@asomi.com Fri Sep 25 11:14:10 2009 Return-Path: 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 7F4483A6877 for ; Fri, 25 Sep 2009 11:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ldvzoP2eL1JN for ; Fri, 25 Sep 2009 11:14:09 -0700 (PDT) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by core3.amsl.com (Postfix) with ESMTP id 86B8A3A6850 for ; Fri, 25 Sep 2009 11:14:09 -0700 (PDT) Received: (qmail 14749 invoked from network); 25 Sep 2009 18:15:18 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 25 Sep 2009 18:15:18 -0000 Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Caitlin Bestler In-Reply-To: <4ABC1A99.1000409@bluecoat.com> Date: Fri, 25 Sep 2009 11:15:17 -0700 Content-Transfer-Encoding: 7bit Message-Id: <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> To: Andrew Knutsen X-Mailer: Apple Mail (2.1075.2) Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , tcpm@ietf.org, Wei Jen Yeh Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 18:14:10 -0000 On Sep 24, 2009, at 6:19 PM, Andrew Knutsen wrote: > > I'll try to respond to all the issues raised today in this message: > > Caitlin Bestler wrote: >> What is not clear is why the probe is based on OUI-specific secret >> handshakes. > > This draft represents an effort to move technology which is > currently shipping from at least three vendors toward > standardization. The handshakes are currently not only "secret", but > use invalid option kinds. This draft allows movement away from the > invalid kinds; getting all vendors to disclose and agree on the rest > is future effort, which would result in the OUI-less IANA-registered > types. We could have put this "history" in the draft, but it didn't > seem appropriate. I did include it in the last announcement. TCP options are a limited resource. There is a strong rationale for their use here, because there is no other mechanism that ensures that the probe packet will follow the same path as the TCP flow. But limiting the standardization to only the basic wrapper makes no sense. Why not also define a "common" OUI which would have standard vendor- independent queries, such as a basic TTL dependent probe that can at least enumerate what all of the option- aware middle boxes are? > >> >> 1) Why not simply probe for "first middlebox that sees this once >> the TTL is less than or equal to X"? >> That would enable discovering all middleboxes that understood >> this option, no matter who >> made them. Once identified SNMP can be used to obtain vendor >> specific information. > > - Generally, you want to probe for a specific type of device, > which will pair with the originator. That may be your usage, but I think a more common usage would be to probe what if any middle-boxes are involved on a path to help diagnose a probleem or perform a security audit. > > - Performance is a very important factor here. SNMP adds delay, > just like the other existing alternates mentioned in the draft. Exactly how can discovery of a middle-box be time critical? How many times a second does a path change? In any event, once a middle-box is discovered, is there any need to continue to use the TCP-piggy-back to communicate with it? -- Caitlin Bestler cait@asomi.com http://www.asomi.com/CaitlinBestlerResume.html From andrew.knutsen@bluecoat.com Fri Sep 25 11:50:31 2009 Return-Path: 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 E77C93A682C for ; Fri, 25 Sep 2009 11:50:31 -0700 (PDT) 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 SsWBWeEuS6cI for ; Fri, 25 Sep 2009 11:50:31 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 17C1A3A68A7 for ; Fri, 25 Sep 2009 11:50:31 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n8PIpfNe025400; Fri, 25 Sep 2009 11:51:41 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 11:51:36 -0700 Message-ID: <4ABD1138.9000201@bluecoat.com> Date: Fri, 25 Sep 2009 11:51:36 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Caitlin Bestler References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> In-Reply-To: <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Sep 2009 18:51:36.0208 (UTC) FILETIME=[353DA900:01CA3E11] Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , tcpm@ietf.org, Wei Jen Yeh Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 18:50:32 -0000 Caitlin Bestler wrote: > > TCP options are a limited resource. There is a strong rationale for > their use here, because there is no other mechanism > that ensures that the probe packet will follow the same path as the > TCP flow. But limiting the standardization to only the > basic wrapper makes no sense. > > Why not also define a "common" OUI which would have standard > vendor-independent queries, such as a basic TTL > dependent probe that can at least enumerate what all of the > option-aware middle boxes are? Thats the purpose of the form with the P (Private) bit set to 0, where the device type is IANA registered and there is no OUI. Or am I missing something here? > >> >>> >>> 1) Why not simply probe for "first middlebox that sees this once the >>> TTL is less than or equal to X"? >>> That would enable discovering all middleboxes that understood >>> this option, no matter who >>> made them. Once identified SNMP can be used to obtain vendor >>> specific information. >> >> - Generally, you want to probe for a specific type of device, which >> will pair with the originator. > > That may be your usage, but I think a more common usage would be to > probe what if any middle-boxes are involved on a path > to help diagnose a probleem or perform a security audit. Then perhaps that would be a good first "standard" device type, basically "any device", with an action to both respond and forward. No "target data" would be required in the request, and the response might contain an SNMP public community string or whatever. > >> >> - Performance is a very important factor here. SNMP adds delay, >> just like the other existing alternates mentioned in the draft. > > Exactly how can discovery of a middle-box be time critical? How many > times a second does a path change? The usual, current case is when you're trying to set up a compression tunnel. In this topology, you have four devices: client, edge, core and server (the middle two are middleboxes). The edge intercepts a connection from the client, and wants to see if there is a core box in the path to the server. However, if there isn't, the connection should not be delayed. This is described in the "terminology" section, and referenced later. We didn't want to go too far into use cases, but if the consensus is that the draft needs more in this area we'll add it. > > In any event, once a middle-box is discovered, is there any need to > continue to use the TCP-piggy-back to > communicate with it? > I'm not sure what your question is here. After discovery the option is no longer used -- just regular connections. Andrew From david.borman@windriver.com Mon Sep 28 10:00:12 2009 Return-Path: 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 65FB83A69C9 for ; Mon, 28 Sep 2009 10:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-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 aepcpH3ljvCl for ; Mon, 28 Sep 2009 10:00:11 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 9092D3A696F for ; Mon, 28 Sep 2009 10:00:11 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id n8SH1Ui1009180 for ; Mon, 28 Sep 2009 10:01:30 -0700 (PDT) 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); Mon, 28 Sep 2009 10:01:29 -0700 Received: from [172.25.44.2] ([172.25.44.2]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Sep 2009 10:01:29 -0700 From: David Borman Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Mon, 28 Sep 2009 12:01:28 -0500 References: To: tcpm Extensions WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 28 Sep 2009 17:01:29.0308 (UTC) FILETIME=[5275F9C0:01CA405D] Subject: [tcpm] tcp-security and the outline 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 17:00:12 -0000 Hi everyone, There seems to be some confusion about the whole outline document for the tcp-security draft. Wes and I have discussed this. The background is that as the chairs of tcpm, our goal is to make it easy to transition from the original draft document to the new document, and to systematically transfer the information from the original draft to the new document. 1) The transfer of the information should happen in small sections that are reformatted into the style of RFC 1122/23, where each section states up front what is the recommendation, followed by a DISCUSSION and/or IMPLEMENTATION section that explains things in further detail. The goal is that if an implementor just wants to know what to do, that is up front in each section, and it is easy to skip over the supporting discussion for that recommendation. 2) The reformatted text can be put into an updated version of the draft, and then discussed on the mailing list. When agreement is reached, any necessary changes will go into a new draft, possibly along with the next section to be discussed. I fully expect that this will lead to many draft versions, we might even be able to set a record for the largest number of revisions to a draft. :-) As each new section is put into the draft for discussion, putting in some temporary formatting to indicate which section(s) are under discussion will eliminate confusion to the casual reader as to which sections have been agreed to, and which ones are under discussion. What we want to avoid is a shotgun approach where people are reviewing pieces from all over the original draft, we jump around reformatting sections, and have a mish-mash of a document in both old and new format, with both discussed and not discussed items. -David Borman and Wes Eddy, TCPM co-chairs From andrew.knutsen@bluecoat.com Mon Sep 28 12:04:19 2009 Return-Path: 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 BA2613A684C for ; Mon, 28 Sep 2009 12:04:19 -0700 (PDT) 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 gCLi7iVEPi1n for ; Mon, 28 Sep 2009 12:04:19 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 163843A6840 for ; Mon, 28 Sep 2009 12:04:19 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n8SJ5aWd024282; Mon, 28 Sep 2009 12:05:36 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 12:05:31 -0700 Message-ID: <4AC108FC.4060009@bluecoat.com> Date: Mon, 28 Sep 2009 12:05:32 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Caitlin Bestler References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> <4ABD1138.9000201@bluecoat.com> In-Reply-To: <4ABD1138.9000201@bluecoat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2009 19:05:31.0483 (UTC) FILETIME=[A657C2B0:01CA406E] Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , tcpm@ietf.org, Wei Jen Yeh Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 19:04:19 -0000 Andrew Knutsen wrote: > Caitlin Bestler wrote: >> >> That may be your usage, but I think a more common usage would be to >> probe what if any middle-boxes are involved on a path >> to help diagnose a probleem or perform a security audit. > > Then perhaps that would be a good first "standard" device type, > basically "any device", with an action to both respond and forward. > No "target data" would be required in the request, and the response > might contain an SNMP public community string or whatever. > The point was made off-list that "responding and forwarding" doesn't work, since the response is on the SYN-AK. However, the action defined for the device-type could be to send a UDP datagram back to the originator, and forward the SYN (with option intact) (unless you're the destination). Andrew From shore@arsc.edu Mon Sep 28 12:18:55 2009 Return-Path: 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 8F1EE3A69E3 for ; Mon, 28 Sep 2009 12:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 cVoS1+p5A13g for ; Mon, 28 Sep 2009 12:18:55 -0700 (PDT) Received: from arsc.edu (mail1.arsc.edu [IPv6:2001:480:150:75::229]) by core3.amsl.com (Postfix) with ESMTP id 56D873A691C for ; Mon, 28 Sep 2009 12:18:54 -0700 (PDT) Received: from viking-e0.arsc.edu (viking-e0.arsc.edu [IPv6:2001:480:150:860:223:32ff:feda:4a52]) by arsc.edu (20090828.ARSC) with ESMTP id n8SJJsVd000459; Mon, 28 Sep 2009 11:19:54 -0800 (AKDT) Message-Id: From: Melinda Shore To: Andrew Knutsen In-Reply-To: <4AC108FC.4060009@bluecoat.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 28 Sep 2009 11:19:54 -0800 References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> <4ABD1138.9000201@bluecoat.com> <4AC108FC.4060009@bluecoat.com> X-Mailer: Apple Mail (2.936) X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: No geolocation information available for 2001:480:150:860:223:32ff:feda:4a52 X-CanItPRO-Stream: default X-Canit-Stats-ID: 3187691 - d833d098369e X-Antispam-Training-Forget: https://canit.arsc.edu:8787/b.php?i=3187691&m=d833d098369e&c=f X-Antispam-Training-Nonspam: https://canit.arsc.edu:8787/b.php?i=3187691&m=d833d098369e&c=n X-Antispam-Training-Spam: https://canit.arsc.edu:8787/b.php?i=3187691&m=d833d098369e&c=s X-Scanned-By: CanIt (www . roaringpenguin . com) on IPv6:2001:480:150:75::167 Cc: Ron Frederick , Qing Li , tcpm@ietf.org, Wei Jen Yeh , Jamshid Mahdavi Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 19:18:55 -0000 On Sep 28, 2009, at 11:05 AM, Andrew Knutsen wrote: > The point was made off-list that "responding and forwarding" > doesn't work, since the response is on the SYN-AK. However, the > action defined for the device-type could be to send a UDP datagram > back to the originator, and forward the SYN (with option intact) > (unless you're the destination). That's going to fail if one of the middleboxes is a NAT. Melinda From andrew.knutsen@bluecoat.com Mon Sep 28 12:40:55 2009 Return-Path: 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 610833A6A12 for ; Mon, 28 Sep 2009 12:40:55 -0700 (PDT) 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 EC8HqJIVvq2y for ; Mon, 28 Sep 2009 12:40:54 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 8DA763A6A08 for ; Mon, 28 Sep 2009 12:40:54 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n8SJg0Ce000344; Mon, 28 Sep 2009 12:42:00 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 12:41:55 -0700 Message-ID: <4AC11183.6090509@bluecoat.com> Date: Mon, 28 Sep 2009 12:41:55 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Melinda Shore References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> <4ABD1138.9000201@bluecoat.com> <4AC108FC.4060009@bluecoat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2009 19:41:55.0063 (UTC) FILETIME=[BBDBA070:01CA4073] Cc: Ron Frederick , Qing Li , tcpm@ietf.org, Wei Jen Yeh , Jamshid Mahdavi Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 19:40:55 -0000 Melinda Shore wrote: > On Sep 28, 2009, at 11:05 AM, Andrew Knutsen wrote: >> The point was made off-list that "responding and forwarding" >> doesn't work, since the response is on the SYN-AK. However, the >> action defined for the device-type could be to send a UDP datagram >> back to the originator, and forward the SYN (with option intact) >> (unless you're the destination). > > That's going to fail if one of the middleboxes is a NAT. > True in many cases... Perhaps to implement the trace with this option, from a non-static source IP, a static destination IP would have to be included in the target data. It seems to me this might be reasonable, since the use case I see for this trace is management, where you'd want the response datagrams to go to a management station which would follow up with SNMP or some such. Note that this use is not the motivation for this option, even though the name may seem to imply it. If it works that great though. Andrew From shore@arsc.edu Mon Sep 28 13:28:16 2009 Return-Path: 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 6233E3A6933 for ; Mon, 28 Sep 2009 13:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 DmzMTDAxPHEE for ; Mon, 28 Sep 2009 13:28:15 -0700 (PDT) Received: from arsc.edu (mail1.arsc.edu [IPv6:2001:480:150:75::229]) by core3.amsl.com (Postfix) with ESMTP id 20B203A682C for ; Mon, 28 Sep 2009 13:28:14 -0700 (PDT) Received: from viking-e0.arsc.edu (viking-e0.arsc.edu [IPv6:2001:480:150:860:223:32ff:feda:4a52]) by arsc.edu (20090828.ARSC) with ESMTP id n8SKTFPf004273; Mon, 28 Sep 2009 12:29:16 -0800 (AKDT) Message-Id: <5C9A341F-EA0C-4A0A-ABE7-AB48058FE5F4@arsc.edu> From: Melinda Shore To: Andrew Knutsen In-Reply-To: <4AC11183.6090509@bluecoat.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 28 Sep 2009 12:29:14 -0800 References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> <4ABD1138.9000201@bluecoat.com> <4AC108FC.4060009@bluecoat.com> <4AC11183.6090509@bluecoat.com> X-Mailer: Apple Mail (2.936) X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: No geolocation information available for 2001:480:150:860:223:32ff:feda:4a52 X-CanItPRO-Stream: default X-Canit-Stats-ID: 3187991 - d4aa23718559 X-Antispam-Training-Forget: https://canit.arsc.edu:8787/b.php?i=3187991&m=d4aa23718559&c=f X-Antispam-Training-Nonspam: https://canit.arsc.edu:8787/b.php?i=3187991&m=d4aa23718559&c=n X-Antispam-Training-Spam: https://canit.arsc.edu:8787/b.php?i=3187991&m=d4aa23718559&c=s X-Scanned-By: CanIt (www . roaringpenguin . com) on IPv6:2001:480:150:75::167 Cc: Ron Frederick , Qing Li , tcpm@ietf.org, Wei Jen Yeh , Jamshid Mahdavi Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 20:28:16 -0000 On Sep 28, 2009, at 11:41 AM, Andrew Knutsen wrote: > True in many cases... Perhaps to implement the trace with this > option, from a non-static source IP, a static destination IP would > have to be included in the target data. It seems to me this might > be reasonable, since the use case I see for this trace is > management, where you'd want the response datagrams to go to a > management station which would follow up with SNMP or some such. And we're back to out-of-band solutions to the problem. I actually don't think this is reasonable - I think it's based on too many assumptions that don't hold in a sufficiently large number of cases, or it forces an architecture that's not widely used. Either way, I'm not comfortable with it. Melinda From andrew.knutsen@bluecoat.com Mon Sep 28 13:40:53 2009 Return-Path: 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 D2D2C3A63EC for ; Mon, 28 Sep 2009 13:40:53 -0700 (PDT) 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 MJj50tdfJQEJ for ; Mon, 28 Sep 2009 13:40:53 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 10C983A691E for ; Mon, 28 Sep 2009 13:40:52 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n8SKfnJ1010771; Mon, 28 Sep 2009 13:41:54 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 13:41:44 -0700 Message-ID: <4AC11F88.4030404@bluecoat.com> Date: Mon, 28 Sep 2009 13:41:44 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Melinda Shore References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> <4ABD1138.9000201@bluecoat.com> <4AC108FC.4060009@bluecoat.com> <4AC11183.6090509@bluecoat.com> <5C9A341F-EA0C-4A0A-ABE7-AB48058FE5F4@arsc.edu> In-Reply-To: <5C9A341F-EA0C-4A0A-ABE7-AB48058FE5F4@arsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2009 20:41:44.0212 (UTC) FILETIME=[17284D40:01CA407C] Cc: Ron Frederick , Qing Li , tcpm@ietf.org, Wei Jen Yeh , Jamshid Mahdavi Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 20:40:53 -0000 The particular solution to the particular problem we're talking about here is an in-band / out-of-band hybrid, which actually makes sense for a management probe of the path a SYN takes between arbitrary endpoints. However this is not the particular problem the option was designed, and is needed, for. If it solves other problems, such as management probes, thats great. Andrew Melinda Shore wrote: > On Sep 28, 2009, at 11:41 AM, Andrew Knutsen wrote: >> True in many cases... Perhaps to implement the trace with this >> option, from a non-static source IP, a static destination IP would >> have to be included in the target data. It seems to me this might be >> reasonable, since the use case I see for this trace is management, >> where you'd want the response datagrams to go to a management station >> which would follow up with SNMP or some such. > > And we're back to out-of-band solutions to the problem. > I actually don't think this is reasonable - I think > it's based on too many assumptions that don't hold > in a sufficiently large number of cases, or it forces > an architecture that's not widely used. Either way, > I'm not comfortable with it. > > Melinda > From hagen@jauu.net Mon Sep 28 13:53:07 2009 Return-Path: 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 53AA93A6A12 for ; Mon, 28 Sep 2009 13:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 txzgp6k0KXLM for ; Mon, 28 Sep 2009 13:53:06 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id 7C4D53A63EC for ; Mon, 28 Sep 2009 13:53:06 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 82F3CF4412F; Mon, 28 Sep 2009 22:58:33 +0200 (CEST) Date: Mon, 28 Sep 2009 22:54:22 +0200 From: Hagen Paul Pfeifer To: Andrew Knutsen Message-ID: <20090928205422.GA4428@nuttenaction> References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> <4ABD1138.9000201@bluecoat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ABD1138.9000201@bluecoat.com> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Ron Frederick , Qing Li , tcpm@ietf.org, Wei Jen Yeh , Jamshid Mahdavi Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 20:53:07 -0000 * Andrew Knutsen | 2009-09-25 11:51:36 [-0700]: > The usual, current case is when you're trying to set up a >compression tunnel. In this topology, you have four devices: client, >edge, core and server (the middle two are middleboxes). The edge >intercepts a connection from the client, and wants to see if there is >a core box in the path to the server. However, if there isn't, the >connection should not be delayed. > > This is described in the "terminology" section, and referenced >later. We didn't want to go too far into use cases, but if the >consensus is that the draft needs more in this area we'll add it. No use cases, but a more detailed high level description would be helpful. I missed that too. HGN -- Hagen Paul Pfeifer || http://jauu.net/ Telephone: +49 174 5455209 || Key Id: 0x98350C22 Key Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 Always in motion, the future is. From touch@ISI.EDU Wed Sep 30 11:06:28 2009 Return-Path: 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 D62A83A6932 for ; Wed, 30 Sep 2009 11:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 xgmN0L9NGA7A for ; Wed, 30 Sep 2009 11:06:28 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 049333A6963 for ; Wed, 30 Sep 2009 11:06:27 -0700 (PDT) Received: from [75.214.229.221] (221.sub-75-214-229.myvzw.com [75.214.229.221]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n8UI5DTN019542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Sep 2009 11:05:15 -0700 (PDT) Message-ID: <4AC39DD8.8060309@isi.edu> Date: Wed, 30 Sep 2009 11:05:12 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Caitlin Bestler References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> In-Reply-To: <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n8UI5DTN019542 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Ron Frederick , Qing Li , tcpm@ietf.org, Wei Jen Yeh , Jamshid Mahdavi Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 18:06:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Some comments: 1) use of the TCP option is OK, but the option needs some additional caveats: - undefined if length < 4 (i.e., receiver should send a RST) - there ought to be a max suggested length see, e.g., draft-ietf-tcpm-tcp-auth-opt-05 section-9.6 with TCP-AO, a typical SYN would have 7-9 bytes available for this option, e.g. IMO, the option should never be more than 7 bytes; there is never a reason for the SYN to carry the full weight of arbitrary "target data", and I don't see why it needs to carry a full IEEE OUI. IMO, there ought to be enough bits that IANA assigns to make this work in a *known, fixed* length, and I don't see a good reason to ever have this option exceed 4 bytes 2) the security considerations needs to be revised - IPsec encryption would prevent detection of the option; IPsec encryption *or* authentication would prevent response. - TLS allows both detection and response - TCP-AO allows detection in all cases. when options are included in the MAC, TCP-AO would prevent response - the "target data" should not appear in the option space, as noted above, but if it did it's not clear how it could possibly be protected separately unless *this doc* describes how to include a signature within the option (and there is no room for that, IMO) 3) Section 5.3 needs to be specific about other uses of this option i.e., it MUST NOT appear in segments other than SYN and the response what happens in simultaneous open? 4) the document is missing some key elements of any TCP option description; in this case: what is the API extension that allows this value to be set or detected? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrDndgACgkQE5f5cImnZrtXaACgpV/WeMDTv74XynK9pYbG5dOR L6kAoJesr0uh2HGAWhFUSzGquWwbgEKD =6O04 -----END PGP SIGNATURE----- From touch@ISI.EDU Wed Sep 30 11:25:22 2009 Return-Path: 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 B07FD3A68E6 for ; Wed, 30 Sep 2009 11:25:22 -0700 (PDT) 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=[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 Qfz+9VKB95y7 for ; Wed, 30 Sep 2009 11:25:21 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BF1253A68B5 for ; Wed, 30 Sep 2009 11:25:21 -0700 (PDT) Received: from [10.255.159.20] (166-205-133-118.mobile.mymmode.com [166.205.133.118] (may be forged)) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n8UIPnBR009000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 30 Sep 2009 11:25:54 -0700 (PDT) From: Joe Touch To: Joe Touch In-Reply-To: <4AC39DD8.8060309@isi.edu> X-Mailer: iPhone Mail (7C144) References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> <4AC39DD8.8060309@isi.edu> Message-Id: <5BBC83D4-1434-4B9D-A13B-75A08768088E@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7C144) Date: Wed, 30 Sep 2009 11:25:44 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Ron Frederick , Qing Li , "tcpm@ietf.org" , Wei Jen Yeh , Jamshid Mahdavi Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 18:25:22 -0000 Two other observations: - 'transparent' (that don't want to be seen) middleboxes will just ignore this too - this option is (IMO) as likely to result in a dropped or RST connection at firewalls, nats, or enpoints that incorrectly implement options (i.e., that treat unkown options as errors rather than ignoring them) as it may be to actually work Joe Sent from my iPhone On Sep 30, 2009, at 11:05 AM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Some comments: > > 1) use of the TCP option is OK, but the option needs some additional > caveats: > > - undefined if length < 4 (i.e., receiver should send a RST) > > - there ought to be a max suggested length > see, e.g., draft-ietf-tcpm-tcp-auth-opt-05 section-9.6 > > with TCP-AO, a typical SYN would have 7-9 bytes available > for this option, e.g. IMO, the option should never be more than > 7 bytes; there is never a reason for the SYN to carry the full > weight of arbitrary "target data", and I don't see why it needs > to carry a full IEEE OUI. IMO, there ought to be enough bits > that IANA assigns to make this work in a *known, fixed* length, > and I don't see a good reason to ever have this option exceed 4 > bytes > > 2) the security considerations needs to be revised > > - IPsec encryption would prevent detection of the option; > IPsec encryption *or* authentication would prevent response. > > - TLS allows both detection and response > > - TCP-AO allows detection in all cases. > when options are included in the MAC, TCP-AO would > prevent response > > - the "target data" should not appear in the option space, > as noted above, but if it did it's not clear how it could > possibly be protected separately unless *this doc* describes > how to include a signature within the option > > (and there is no room for that, IMO) > > 3) Section 5.3 needs to be specific about other uses of this option > > i.e., it MUST NOT appear in segments other than SYN and > the response > > what happens in simultaneous open? > > 4) the document is missing some key elements of any TCP option > description; in this case: > > what is the API extension that allows this value to be > set or detected? > > Joe > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAkrDndgACgkQE5f5cImnZrtXaACgpV/WeMDTv74XynK9pYbG5dOR > L6kAoJesr0uh2HGAWhFUSzGquWwbgEKD > =6O04 > -----END PGP SIGNATURE----- From andrew.knutsen@bluecoat.com Wed Sep 30 11:50:44 2009 Return-Path: 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 223A63A686B for ; Wed, 30 Sep 2009 11:50:44 -0700 (PDT) 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 iFu6Zw5XZ8dy for ; Wed, 30 Sep 2009 11:50:43 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id E76413A68B5 for ; Wed, 30 Sep 2009 11:50:42 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n8UIq5gN009744; Wed, 30 Sep 2009 11:52:05 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 11:51:59 -0700 Message-ID: <4AC3A8CF.7070205@bluecoat.com> Date: Wed, 30 Sep 2009 11:51:59 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Joe Touch References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> <4AC39DD8.8060309@isi.edu> In-Reply-To: <4AC39DD8.8060309@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Sep 2009 18:51:59.0880 (UTC) FILETIME=[176A7880:01CA41FF] Cc: Ron Frederick , Qing Li , tcpm@ietf.org, Wei Jen Yeh , Jamshid Mahdavi Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 18:50:44 -0000 I'll take a first shot at this. My colleagues may also want to chip in... Joe Touch wrote: > 1) use of the TCP option is OK, but the option needs some additional > caveats: > > - undefined if length < 4 (i.e., receiver should send a RST) > We'll add this. > - there ought to be a max suggested length > see, e.g., draft-ietf-tcpm-tcp-auth-opt-05 section-9.6 > > with TCP-AO, a typical SYN would have 7-9 bytes available > for this option, e.g. IMO, the option should never be more than > 7 bytes; there is never a reason for the SYN to carry the full > weight of arbitrary "target data", and I don't see why it needs > to carry a full IEEE OUI. IMO, there ought to be enough bits > that IANA assigns to make this work in a *known, fixed* length, > and I don't see a good reason to ever have this option exceed 4 > bytes > In current practice, we don't use the authentication option, but we do use scaling and timestamps. We end up just about filling the extended header, and wishing we had more room. This is without the OUI, using our present invalid kind (as do the other vendors in this market). What happens is a space vs time tradeoff. Leaving info out of the option can imply another roundtrip when setting up a tunnel. Forcing this would likely preclude use of the option for its primary (ie current) purpose. > 2) the security considerations needs to be revised > > - IPsec encryption would prevent detection of the option; > IPsec encryption *or* authentication would prevent response. > > - TLS allows both detection and response > > - TCP-AO allows detection in all cases. > when options are included in the MAC, TCP-AO would > prevent response > > We can add this additional detail. Which MAC options alter the behavior of AO? > - the "target data" should not appear in the option space, > as noted above, but if it did it's not clear how it could > possibly be protected separately unless *this doc* describes > how to include a signature within the option > (and there is no room for that, IMO) > As noted above and in the draft, removing the "target data" from the option would render it useless. Also note that the draft says that the format of the "target data" is dependent on the "device type". Thus the intent is that any desired protection would be defined in the spec for that type. Since different situations would require different protection, I think specifying it here might be overkill. > 3) Section 5.3 needs to be specific about other uses of this option > > i.e., it MUST NOT appear in segments other than SYN and > the response > I suppose this is clearer than saying it MUST be in the SYN/SYN-ACK packets... Mostly because the current wording might be construed to imply the option must be present in all SYN packets, which is unlikely since its an "option", but... > what happens in simultaneous open? > Wesley brought this up, and we added the last paragraph of section 5. It never happens in current use, so we haven't addressed it. Perhaps we should add some suggestions, but since its not expected or implemented, they would be vague. > 4) the document is missing some key elements of any TCP option > description; in this case: > > what is the API extension that allows this value to be > set or detected? > Its my understanding, and observation, that RFCs are protocol documents and do not generally specify APIs. Also, since all current implementations are proprietary, any APIs added to the draft would be speculative. Andrew From andrew.knutsen@bluecoat.com Wed Sep 30 11:58:48 2009 Return-Path: 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 2D7733A6910 for ; Wed, 30 Sep 2009 11:58:48 -0700 (PDT) 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 YFsxPXb-EpoP for ; Wed, 30 Sep 2009 11:58:47 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 4B1CF3A686B for ; Wed, 30 Sep 2009 11:58:47 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n8UJ08H1011252; Wed, 30 Sep 2009 12:00:08 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 12:00:02 -0700 Message-ID: <4AC3AAB2.4020200@bluecoat.com> Date: Wed, 30 Sep 2009 12:00:02 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Joe Touch References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> <4AC39DD8.8060309@isi.edu> <5BBC83D4-1434-4B9D-A13B-75A08768088E@isi.edu> In-Reply-To: <5BBC83D4-1434-4B9D-A13B-75A08768088E@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Sep 2009 19:00:02.0893 (UTC) FILETIME=[375067D0:01CA4200] Cc: Ron Frederick , Qing Li , "tcpm@ietf.org" , Wei Jen Yeh , Jamshid Mahdavi Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 18:58:48 -0000 Joe Touch wrote: > Two other observations: > > - 'transparent' (that don't want to be seen) middleboxes will just > ignore this too True. Lets just say they are not of any of the defined "device types"... > > - this option is (IMO) as likely to result in a dropped or RST > connection at firewalls, nats, or enpoints that incorrectly implement > options (i.e., that treat unkown options as errors rather than > ignoring them) as it may be to actually work But the situation will be better than the present one... and this problem is actually surprisingly rare with the current invalid kinds used by all vendors in the WAN optimization market. I suppose this is partly because people don't deploy equipment that breaks their network. Andrew From touch@ISI.EDU Wed Sep 30 12:57:12 2009 Return-Path: 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 BA10228C104 for ; Wed, 30 Sep 2009 12:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 KC-K3PsjmU2u for ; Wed, 30 Sep 2009 12:57:11 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 8DE5728C103 for ; Wed, 30 Sep 2009 12:57:11 -0700 (PDT) Received: from [75.214.229.221] (221.sub-75-214-229.myvzw.com [75.214.229.221]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n8UJvRG5021231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Sep 2009 12:57:29 -0700 (PDT) Message-ID: <4AC3B827.2090602@isi.edu> Date: Wed, 30 Sep 2009 12:57:27 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andrew Knutsen References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> <4AC39DD8.8060309@isi.edu> <4AC3A8CF.7070205@bluecoat.com> In-Reply-To: <4AC3A8CF.7070205@bluecoat.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n8UJvRG5021231 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Ron Frederick , Qing Li , tcpm@ietf.org, Wei Jen Yeh , Jamshid Mahdavi Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 19:57:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Andrew, Andrew Knutsen wrote: > > I'll take a first shot at this. My colleagues may also want to chip > in... ... >> - there ought to be a max suggested length >> see, e.g., draft-ietf-tcpm-tcp-auth-opt-05 section-9.6 >> >> with TCP-AO, a typical SYN would have 7-9 bytes available >> for this option, e.g. IMO, the option should never be more than >> 7 bytes; there is never a reason for the SYN to carry the full >> weight of arbitrary "target data", and I don't see why it needs >> to carry a full IEEE OUI. IMO, there ought to be enough bits >> that IANA assigns to make this work in a *known, fixed* length, >> and I don't see a good reason to ever have this option exceed 4 >> bytes > > In current practice, we don't use the authentication option, but we > do use scaling and timestamps. We end up just about filling the extended > header, and wishing we had more room. This is without the OUI, using our > present invalid kind (as do the other vendors in this market). You don't use TCP-AO, but the endpoints might. It's intended to be more generally useful than was TCP MD5 (which is used typically only for BGP). It's unrealistic to fill the option space with this one extension. It would basically preclude any other options from being included. The option space is severely limited, especially in SYNs. I would object to this going forward using more than a highly constrained amount of space. If additional space is needed for extended information, that can be exchanged in option fields after the initial negotiation- the info in the SYN is supposed to just be "do you speak X". > What happens is a space vs time tradeoff. Leaving info out of the > option can imply another roundtrip when setting up a tunnel. Forcing > this would likely preclude use of the option for its primary (ie > current) purpose. Using this much space in the option would kill all other future uses of the option space. If it's between an extra RTT and shutting down future use of options, we need to take the RTT hit. >> 2) the security considerations needs to be revised >> >> - IPsec encryption would prevent detection of the option; >> IPsec encryption *or* authentication would prevent response. >> >> - TLS allows both detection and response >> - TCP-AO allows detection in all cases. >> when options are included in the MAC, TCP-AO would >> prevent response > > We can add this additional detail. Which MAC options alter the > behavior of AO? TCP-AO allows endpoints to either include all the TCP options in the MAC or exclude them. This information is not visible on the wire. If you modify any of the options en-route and the options are included in the MAC, the packet will be silently dropped by the receiver. TCP is an endpoint protocol. It is not particularly intended for intermediate parties to modify its contents. Since you brought that up, I have to then consider whether it's appropriate to even have a TCP option whose primary purpose is NOT to communicate to the receiving endpoint, and I have to say that on that basis, this should not be a TCP option at all. I appreciate the desire to have a signal on the path with the TCP SYN, and to embed it in the that segment. Have you considered putting this in the IP option space? I.e., it would still fate-share with the TCP SYN, but it would be in a place it ought to be to be examined and/or modified by intermediate parties. That would also give you a bit more room to play in... >> - the "target data" should not appear in the option space, >> as noted above, but if it did it's not clear how it could >> possibly be protected separately unless *this doc* describes >> how to include a signature within the option >> (and there is no room for that, IMO) >> > > As noted above and in the draft, removing the "target data" from the > option would render it useless. > > Also note that the draft says that the format of the "target data" is > dependent on the "device type". Thus the intent is that any desired > protection would be defined in the spec for that type. Since different > situations would require different protection, I think specifying it > here might be overkill. Where you say it is protected separately, you should also indicate "inside the target data area, as specified by the target data format" >> 3) Section 5.3 needs to be specific about other uses of this option >> >> i.e., it MUST NOT appear in segments other than SYN and >> the response > > I suppose this is clearer than saying it MUST be in the SYN/SYN-ACK > packets... Mostly because the current wording might be construed to > imply the option must be present in all SYN packets, which is unlikely > since its an "option", but... It MAY appear in SYNs, or in ACKs to a SYN. It MUST NOT appear in other segments. >> what happens in simultaneous open? > > Wesley brought this up, and we added the last paragraph of section > 5. It never happens in current use, so we haven't addressed it. > Perhaps we should add some suggestions, but since its not expected or > implemented, they would be vague. You need to say *exactly* how it should be handled *when* it comes up. It may be a corner case, but addressing it is required for all TCP modifications. >> 4) the document is missing some key elements of any TCP option >> description; in this case: >> >> what is the API extension that allows this value to be >> set or detected? > > Its my understanding, and observation, that RFCs are protocol > documents and do not generally specify APIs. Also, since all current > implementations are proprietary, any APIs added to the draft would be > speculative. RFC 793 includes an API. You're extending that RFC, and by inclusion, its API. You need to state that, in an abstract way, the OPEN and STATUS calls are modified to include parameters that set and read the status of this option. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrDuCYACgkQE5f5cImnZrsifgCgxU0nTdaZ72AJ3fl3tZZ2l4zY +c0An1G8SygAZLHnVRoI8hZ9UMJZMlWW =hpWN -----END PGP SIGNATURE----- From touch@ISI.EDU Wed Sep 30 12:59:13 2009 Return-Path: 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 1EFBD3A69C0 for ; Wed, 30 Sep 2009 12:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 h5835bi7Ry4h for ; Wed, 30 Sep 2009 12:59:12 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 5C1953A69A1 for ; Wed, 30 Sep 2009 12:59:12 -0700 (PDT) Received: from [75.214.229.221] (221.sub-75-214-229.myvzw.com [75.214.229.221]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n8UJwJW9021448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Sep 2009 12:58:21 -0700 (PDT) Message-ID: <4AC3B85B.6090000@isi.edu> Date: Wed, 30 Sep 2009 12:58:19 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andrew Knutsen References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> <4AC39DD8.8060309@isi.edu> <5BBC83D4-1434-4B9D-A13B-75A08768088E@isi.edu> <4AC3AAB2.4020200@bluecoat.com> In-Reply-To: <4AC3AAB2.4020200@bluecoat.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n8UJwJW9021448 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Ron Frederick , Qing Li , "tcpm@ietf.org" , Wei Jen Yeh , Jamshid Mahdavi Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 19:59:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Knutsen wrote: > Joe Touch wrote: >> Two other observations: >> >> - 'transparent' (that don't want to be seen) middleboxes will just >> ignore this too > > True. Lets just say they are not of any of the defined "device types"... > >> >> - this option is (IMO) as likely to result in a dropped or RST >> connection at firewalls, nats, or enpoints that incorrectly implement >> options (i.e., that treat unkown options as errors rather than >> ignoring them) as it may be to actually work > > But the situation will be better than the present one... and this > problem is actually surprisingly rare with the current invalid kinds > used by all vendors in the WAN optimization market. I suppose this is > partly because people don't deploy equipment that breaks their network. I'm also asking whether they deploy equipment that breaks anything for the end user (and sure, vendors do this all the time - they're called NAT boxes ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrDuFsACgkQE5f5cImnZrscHgCgkFstfA5gy6HBUbuK1wSp05oR nYsAnicM5mEt9TZSsY/UyJhC0MwA6THS =S8C8 -----END PGP SIGNATURE----- From andrew.knutsen@bluecoat.com Wed Sep 30 13:20:21 2009 Return-Path: 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 D73DC28C108 for ; Wed, 30 Sep 2009 13:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 FCN8cUXmwoN7 for ; Wed, 30 Sep 2009 13:20:21 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 01F2D3A67F9 for ; Wed, 30 Sep 2009 13:20:20 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n8UKLhhh026140; Wed, 30 Sep 2009 13:21:43 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 13:21:38 -0700 Message-ID: <4AC3BDD2.7070607@bluecoat.com> Date: Wed, 30 Sep 2009 13:21:38 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Joe Touch References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> <4AC39DD8.8060309@isi.edu> <5BBC83D4-1434-4B9D-A13B-75A08768088E@isi.edu> <4AC3AAB2.4020200@bluecoat.com> <4AC3B85B.6090000@isi.edu> In-Reply-To: <4AC3B85B.6090000@isi.edu> Content-Type: multipart/alternative; boundary="------------070602020205090809070900" X-OriginalArrivalTime: 30 Sep 2009 20:21:38.0361 (UTC) FILETIME=[9D3D8A90:01CA420B] Cc: Ron Frederick , Qing Li , "tcpm@ietf.org" , Wei Jen Yeh , Jamshid Mahdavi Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 20:20:21 -0000 This is a multi-part message in MIME format. --------------070602020205090809070900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Joe Touch wrote: > Andrew Knutsen wrote: > >>> - this option is (IMO) as likely to result in a dropped or RST >>> connection at firewalls, nats, or enpoints that incorrectly implement >>> options (i.e., that treat unkown options as errors rather than >>> ignoring them) as it may be to actually work >>> >> But the situation will be better than the present one... and this >> problem is actually surprisingly rare with the current invalid kinds >> used by all vendors in the WAN optimization market. I suppose this is >> partly because people don't deploy equipment that breaks their network. >> > > I'm also asking whether they deploy equipment that breaks anything for > the end user (and sure, vendors do this all the time - they're called > NAT boxes ;-) > In the terminology I'm used to, vendors sell, end users deploy. Many end users deploy both WAN Op and NAT; they just need to be configured correctly (and not do anything stupid ;-). Andrew --------------070602020205090809070900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Joe Touch wrote:
Andrew Knutsen wrote:
  
- this option is (IMO) as likely to result in a dropped or RST
connection at firewalls, nats, or enpoints that incorrectly implement
options (i.e., that treat unkown options as errors rather than
ignoring them) as it may be to actually work
      
   But the situation will be better than the present one...  and this
problem is actually surprisingly rare with the current invalid kinds
used by all vendors in the WAN optimization market. I suppose this is
partly because people don't deploy equipment that breaks their network.
    

I'm also asking whether they deploy equipment that breaks anything for
the end user (and sure, vendors do this all the time - they're called
NAT boxes ;-)

    In the terminology I'm used to, vendors sell, end users deploy.

    Many end users deploy both WAN Op and NAT; they just need to be configured correctly (and not do anything stupid ;-).

Andrew

--------------070602020205090809070900-- From andrew.knutsen@bluecoat.com Wed Sep 30 13:24:12 2009 Return-Path: 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 EE3DE28C0FB for ; Wed, 30 Sep 2009 13:24:12 -0700 (PDT) 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 T9xpE23VkDUf for ; Wed, 30 Sep 2009 13:24:12 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 3773D28C0EF for ; Wed, 30 Sep 2009 13:24:12 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n8UKPYlY026979; Wed, 30 Sep 2009 13:25:34 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 13:25:29 -0700 Message-ID: <4AC3BEB9.4030105@bluecoat.com> Date: Wed, 30 Sep 2009 13:25:29 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Joe Touch References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> <4AC39DD8.8060309@isi.edu> <4AC3A8CF.7070205@bluecoat.com> <4AC3B827.2090602@isi.edu> In-Reply-To: <4AC3B827.2090602@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Sep 2009 20:25:29.0517 (UTC) FILETIME=[270525D0:01CA420C] Cc: Ron Frederick , Qing Li , tcpm@ietf.org, Wei Jen Yeh , Jamshid Mahdavi Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 20:24:13 -0000 I don't have time right now to address all of your points, but I will note one thing: Joe Touch wrote: > You don't use TCP-AO, but the endpoints might. > It sounds like you're thinking of a situation where an intermediate node adds the option to the SYN packet. This is not the intent. Do other options RFC's call this out explicitly? If so we will. Andrew From touch@ISI.EDU Wed Sep 30 13:28:15 2009 Return-Path: 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 85EEF3A69DA for ; Wed, 30 Sep 2009 13:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 8ngn8c2R9HQu for ; Wed, 30 Sep 2009 13:28:14 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id D00DD3A67E9 for ; Wed, 30 Sep 2009 13:28:14 -0700 (PDT) Received: from [75.214.229.221] (221.sub-75-214-229.myvzw.com [75.214.229.221]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n8UKSh2S000813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Sep 2009 13:28:46 -0700 (PDT) Message-ID: <4AC3BF7B.2060201@isi.edu> Date: Wed, 30 Sep 2009 13:28:43 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andrew Knutsen References: <4ABAD595.7050303@bluecoat.com> <4ABC1A99.1000409@bluecoat.com> <3DBBDA5E-54DD-4CBB-8423-E0841C584534@asomi.com> <4AC39DD8.8060309@isi.edu> <4AC3A8CF.7070205@bluecoat.com> <4AC3B827.2090602@isi.edu> <4AC3BEB9.4030105@bluecoat.com> In-Reply-To: <4AC3BEB9.4030105@bluecoat.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n8UKSh2S000813 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Ron Frederick , Qing Li , tcpm@ietf.org, Wei Jen Yeh , Jamshid Mahdavi Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 20:28:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Knutsen wrote: > > I don't have time right now to address all of your points, but I will > note one thing: > > Joe Touch wrote: >> You don't use TCP-AO, but the endpoints might. > > It sounds like you're thinking of a situation where an intermediate > node adds the option to the SYN packet. Or modifies the contents of an existing option. Maybe I'm missing something. Is this ONLY examined and modified at the destination? (i.e., the SYN dest IP address)? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrDv3sACgkQE5f5cImnZrv/0wCdF8ESYJWaEkcXSqNRxHWA09/g 3vAAoNtcBHAFgAHYcDwcbl9u4B6GnGYJ =j9Wv -----END PGP SIGNATURE----- From rfc-editor@rfc-editor.org Wed Sep 30 17:10:09 2009 Return-Path: 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 32F8F28C0EA; Wed, 30 Sep 2009 17:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.61 X-Spam-Level: X-Spam-Status: No, score=-16.61 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 O9FnSkzGoBU3; Wed, 30 Sep 2009 17:10:08 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 6CE1E3A6A36; Wed, 30 Sep 2009 17:10:08 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 2BE8D33319B; Wed, 30 Sep 2009 17:10:35 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091001001035.2BE8D33319B@bosco.isi.edu> Date: Wed, 30 Sep 2009 17:10:35 -0700 (PDT) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 5682 on Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP 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-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 00:10:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5682 Title: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP Author: P. Sarolahti, M. Kojo, K. Yamamoto, M. Hata Status: Standards Track Date: September 2009 Mailbox: pasi.sarolahti@iki.fi, kojo@cs.helsinki.fi, yamamotokaz@nttdocomo.co.jp, hatama@s1.nttdocomo.co.jp Pages: 19 Characters: 47337 Updates: RFC4138 I-D Tag: draft-ietf-tcpm-rfc4138bis-04.txt URL: http://www.rfc-editor.org/rfc/rfc5682.txt The purpose of this document is to move the F-RTO (Forward RTO-Recovery) functionality for TCP in RFC 4138 from Experimental to Standards Track status. The F-RTO support for Stream Control Transmission Protocol (SCTP) in RFC 4138 remains with Experimental status. See Appendix B for the differences between this document and RFC 4138. Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. [STANDARDS TRACK] This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute