From tcpm-bounces@ietf.org Thu Apr 3 11:51:04 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A353A6809; Thu, 3 Apr 2008 11:51:04 -0700 (PDT) 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 C37213A6DCE for ; Thu, 3 Apr 2008 11:51:02 -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 yEaGFHrDMcaw for ; Thu, 3 Apr 2008 11:50: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 6C5203A6809 for ; Thu, 3 Apr 2008 11:50:58 -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 m33Ip1V8026686 for ; Thu, 3 Apr 2008 11:51:02 -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 782B41DD0BB4 for ; Thu, 3 Apr 2008 14:49:52 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7D08147605F for ; Thu, 3 Apr 2008 14:49:29 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Dreams MIME-Version: 1.0 Date: Thu, 03 Apr 2008 14:49:29 -0400 Message-Id: <20080403184929.7D08147605F@lawyers.icir.org> Subject: [tcpm] minutes from Philly X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1479727282==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1479727282== Content-Type: multipart/signed; boundary="==_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --==_bOundary Content-Type: multipart/mixed; boundary="=_bOundary" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- Attached are a first cut at minutes from the TCPM meeting in Philadelphia. Please let us know if there are corrections. Also, there is a "???" where there should be a name in the authentication option discussion. If that person could raise their hand, it'd be great. Thanks! allman --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Disposition: attachment; filename=tcpm-minutes.txt TCP Maintenance and Minor Extensions WG March 11, 2008, IETF-71 Minutes taken by Gorry Fairhurst 1. WG Status + Agenda bashing (10min) Mark Allman reviewed the Agenda. Status: ECN-SYN has been sent to IESG Waiting for proto writeup by WG Chairs: Soft-errors UTO TCP-Secure has been through WGLC. Applicability statement has been drafted, and recommendations need to be firmed-up. Did anyone object or have comments ion this topic? Two new items of work were expected: Compound TCP (from ICCRG) Early Retransmit (to be verified as a TCPM Item by the WG) PSavola via jabber: What is the status of draft-ietf-tcpm-icmp-attacks? This needs some work, and has been languishing for some time. The WG Chairs don't have any update on the current status. Mark is looking for energy - offers of help from people interested. The Chairs will contact the author and check the status. 2. 2581bis update - Mark Allman draft-ietf-tcpm-rfc2581bis-03.txt Ted (on the list) considered this document has passed WGLC when the comments have been addresed. The authors think all changes have been implemented. 3. Advancing F-RTO - Pasi Sarolahti draft-ietf-tcpm-rfc4138bis-01.txt Pasi presented the draft. Lars said they had talked about F-RTO at the last meeting, and there was support for this going forward. Ted and Mark have discussed this and people seem to be liking this and the experience is good. We think we should start a WGLC after this meeting. There were no objections. 4. 1323bis - David Borman draft-ietf-tcpm-1323bis-00.txt David said this now referenced RFC 2581. There was currently a null security considerations section. Joe Touch said we should identify issues. Matt Mathis - there could be security issues. Time Stamps can cause robustness issues. Eric Rescorla - see if this changes anything. Joe Touch - can the path change. Matt there is a robustness issue with middleboxes doing things they should not. Joe Touch: It was suggesting the middleboxes can protect only some headers, if you are protecting the TCP header, must this be included? Eric: The option could be removed on path (e.g. from the initial SYN), he will send comments. David will get back to the list with these comments. Gorry: How appropriate are Jumbograms to a general internet deployment? David said this was really meant for point-to-point links, and not for the general Internet. Matt added the experimentation was 15 years old. PSavola: One potential issue in RFC 1323bis: do we want to discuss the specifics how Timestamps option have been used in practice? (e.g., for signalling in the presence of SYN cookies. David had added text describing an offset. David said that he would like to make a separate I-D on TCP MSS issues. Mark said this sounds OK, people can comment if this needs to be done different. Joe Touch: If you supply one example in section 3.3 on RTTM, this will become the default. David, we could choose an alternative RTTM implementation style. Mark: A few people have solved this by changing the weights on the sample. David said that he expected that this should then illustrate that there were multiple approaches. ... We should be careful that we don't suggest something that is too extreme, we need to support this with research. Mark said there were published papers that talk about weight changes. Joe said we should recommend alternatives that we know are safe - but not too much importance to one unless we know how to choose). David said that he should tell people what to do, and not prescribe an algorithm. Mark said we needed to keep the variance and adjust the gain based on the cwnd. Hope to make the next version ready for a WGLC. Lars said we should add milestones for the two documents (Ted to do). Mark: How many have read this version? (2). Mark: How many have read a version since we started updating 1323? (10). 5. TCP Authentication - Joe Touch draft-ietf-tcpm-tcp-auth-opt Presented the draft to SAAG in Vancouver, and feedback from Eric Rescorla. Are we writing an applicability statement here? Joe said it was in the document. Eric: Does this system assume we do not do key management? Joe said other people said this also. Eric: there are a number of styles of key management: manual, external key management, inside TCP, etc. The Design-Team seems convinced this does not fit in the space available, and must be established at SYN time, it starts authenticated and remains authenticated. Eric this could possibly be wrong. Joe said there was limited space in the SYN packet and then has to be consistent with the core of TCP. Eric said I am not convinced. Joe: There is a 40 Byte header in the SYN, but already used for TS, Window Scaling, and other things, at least half is already gone - if more than 15 bytes is needed, we are in trouble. Eric: Be clear what is included and what is not included and say why. Lars said that in previous discussions the key management would be done in SAAG, but not that this would be done in the SYN option. Danny Macpherson: If there is the capability how will this be reconsidered - can we think about other non-routing protocol solutions. Joe said we need some sort of automated key management. Joe: Do we need two documents for requirements and mechanism? Mark said he was not aware of the need for this, but if it made sense then we could split things up. ???: When you say asymmetric is not useful. I may want to be able to do this mid-connection. Joe said the Design-Team said do not do this within the connection. Eric said we should be clear what people want - this is not a replacement for TLS, it is DoS protection. Joe, yes it protects the transport key. Eric this means that we have prior arrangements, if either direction is DoSed then this attacks the connection. There is no management different between symmetric case and asymmetric, it's just performance - the keys are exchanged and then the packets are MAC'ed. Brian Weis said this is just for routing. Eric: This issue is about cut and paste with the same port quartet. You need to be on the wire to do this attack. A pair-wise key per host pair is OK. Joe said we could get this key from a key management system, SAAG mandated an automated key management system. The ISN may help. Eric the state in the TCB is used, the first packet is protected by the master key and the ISN, this provides a way to bootstrap this. Would TS option help against replay attacks? Eric and Joe discussed the relationship between the TSAD and TCB. Brian: The unkeyed case should result in silent reception. Lars: default deny will result in loss of a connection, which is bad. The migration case is important. Eric said if we turn on independently, then we need to handle this. This could be a case for asymmetric. Eric: We need to be concerned about sequence number roll-over, and that the key should not be used for a large number of operations (although this is no longer true for modern MACs). We don't need to change the key. Joe said the question was about coupling the ISN and MAC. One way is to synthesis a 64 bit sequence number, by counting the wraps of the sequence number space. There are pending modifications to the I-D. Joe said there was a list of open questions, all people were welcome to start discussions on this topic. --=_bOundary-- --==_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFH9Sa5WyrrWs4yIs4RAonEAJ4iQVmK+09UcIF86PM9Jk4TPGBHxQCeM4Cv +KHHUM93vcET/d/ZEqSSjqk= =IlSV -----END PGP SIGNATURE----- --==_bOundary-- --===============1479727282== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1479727282==-- From tcpm-bounces@ietf.org Thu Apr 3 23:59:16 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F093628C2C6; Thu, 3 Apr 2008 23:59:15 -0700 (PDT) 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 A823F28C2C6 for ; Thu, 3 Apr 2008 23:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.2 X-Spam-Level: * X-Spam-Status: No, score=1.2 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_05=-1.11, RCVD_IN_NJABL_PROXY=1.643, 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 NjOrWYkrSYTE for ; Thu, 3 Apr 2008 23:59:14 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id A5E4828C279 for ; Thu, 3 Apr 2008 23:59:12 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id F321D5A7458; Fri, 4 Apr 2008 03:59:22 -0300 (ART) Received: from notebook.gont.com.ar (201-254-61-200.speedy.com.ar [201.254.61.200] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m346wwtw000534; Fri, 4 Apr 2008 03:58:59 -0300 Message-Id: <200804040658.m346wwtw000534@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Apr 2008 03:56:02 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 04 Apr 2008 03:59:22 -0300 (ART) Cc: mallman@icir.org Subject: [tcpm] A question on tcpsecure & meeting minutes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Folks, I have just read the minutes from the last IETF meeting, and it says tcpsecure has been through WGLC. I don't seem to recall the WGLC for this document, and have checked the online mailing-list archives, and have not been able to find the WGLC. I'm sure this is just me not being able to find the WGLC in the mailing-list archives (unfortunately, my local mail archive is in some backup I cannot access right now). Would anybody remind me when the WGLC of this doc was issued? 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 4 05:13:18 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F8328C62A; Fri, 4 Apr 2008 05:13:18 -0700 (PDT) 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 A116C28C40C for ; Fri, 4 Apr 2008 05:13:17 -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 RFUa87dMggla for ; Fri, 4 Apr 2008 05:13:17 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 1A17928C62A for ; Fri, 4 Apr 2008 05:13:16 -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 m34CDEo8014207; Fri, 4 Apr 2008 05:13:15 -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 1A6B11DFB4E4; Fri, 4 Apr 2008 08:12:04 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 938804778E8; Fri, 4 Apr 2008 08:11:39 -0400 (EDT) To: Fernando Gont From: Mark Allman In-Reply-To: <200804040658.m346wwtw000534@venus.xmundo.net> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Dreams MIME-Version: 1.0 Date: Fri, 04 Apr 2008 08:11:36 -0400 Message-Id: <20080404121139.938804778E8@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] A question on tcpsecure & meeting minutes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0996957350==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0996957350== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I have just read the minutes from the last IETF meeting, and it says > tcpsecure has been through WGLC. That is because that is what I said. :-) However, you're right that I mis-spoke. With all the drafts we have in various stages I just botched this. The status is ... + We have nailed down the recommendation levels for the various mechanisms. + Those levels need worked into the document. + Then it seems that all outstanding issues have been taken care of and we can do WGLC. So, in other words it seems "WGLC is imminent" is the better summary. Thanks for catching this bit of confusion. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFH9hr2WyrrWs4yIs4RAupNAJ0bkC07vFPzA1STInyH4hy2izz6DwCffCoN lYOo9PGuYFHmMjWwNJlEVIE= =8zpx -----END PGP SIGNATURE----- --=_bOundary-- --===============0996957350== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0996957350==-- From tcpm-bounces@ietf.org Fri Apr 4 08:43:49 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC3873A6AB1; Fri, 4 Apr 2008 08:43:49 -0700 (PDT) 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 DF2A63A69A1 for ; Fri, 4 Apr 2008 08:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7P-1nHJUBi4 for ; Fri, 4 Apr 2008 08:43:45 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id F2E743A68A7 for ; Fri, 4 Apr 2008 08:43:38 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 04 Apr 2008 08:43:45 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m34Fhhbw004098; Fri, 4 Apr 2008 08:43:43 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m34FhhYH020232; Fri, 4 Apr 2008 15:43:43 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.1830); Fri, 4 Apr 2008 08:43:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 08:42:51 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804F48C9B@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20080404121139.938804778E8@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] A question on tcpsecure & meeting minutes Thread-Index: AciWTW9ZsXCMHPgTRwOfN1syFhj0egAE57VQ References: <200804040658.m346wwtw000534@venus.xmundo.net> <20080404121139.938804778E8@lawyers.icir.org> From: "Anantha Ramaiah (ananth)" To: , "Fernando Gont" X-OriginalArrivalTime: 04 Apr 2008 15:43:22.0121 (UTC) FILETIME=[9CC97F90:01C8966A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2219; t=1207323823; x=1208187823; c=relaxed/simple; s=sjdkim3002; 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]=20A=20question=20on=20tcpsecure= 20&=20meeting=20minutes |Sender:=20; bh=7HYv5TjA2x/7HgHisw/37LaekJ0AxrdprlUn0Wt3vu4=; b=b40vUBV8k8OnXfW2mF7kSH5h8NLfhbZ75YpkDWo/yUUQeM96sXVVWm4R6Z 7XDQ7hsoToz+IHUPRM38ON7113VIXA1Rsua9ag5rZ67yRgubptpUWIgsrUjD 7aza+cDrue; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] A question on tcpsecure & meeting minutes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Mark, I will go ahead and change the document to reflect the recommendation levels suggested and also would incorporate the applicable comments received. However, there is one item (which I have brought up earlier) which needs some help to be resolved. We need to mention in the document, the reasoning for the chosen levels for each mechanism, currently it is not clear and it makes the document incomplete. for eg, in particular:- some of the reasons why data mitigation was singled out and classified under MAY is because "it needs extra variables to implement this and it is not as simple as the other 2 mechanisms" "even with AS in place data mitigation is a MAY because originally it was "decided" to tag it as MAY. I am not sure we can put such a verbiage (like the one listed above) in the document. My suggestion is something like "it was felt that the data mitigation is a MAY beause it is harder to tear down the connection compared to the other 2 mechanisms OR in other words additional complexity and conditions required to cause harm when compared to the other two" I am open to suggestions. Thanks, -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Mark Allman > Sent: Friday, April 04, 2008 5:12 AM > To: Fernando Gont > Cc: tcpm@ietf.org > Subject: Re: [tcpm] A question on tcpsecure & meeting minutes > > > > I have just read the minutes from the last IETF meeting, > and it says > > tcpsecure has been through WGLC. > > That is because that is what I said. :-) > > However, you're right that I mis-spoke. With all the drafts > we have in various stages I just botched this. > > The status is ... > > + We have nailed down the recommendation levels for the various > mechanisms. > > + Those levels need worked into the document. > > + Then it seems that all outstanding issues have been taken care of > and we can do WGLC. > > So, in other words it seems "WGLC is imminent" is the better summary. > > Thanks for catching this bit of confusion. > > allman > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 4 11:32:43 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB3E63A6988; Fri, 4 Apr 2008 11:32:43 -0700 (PDT) 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 8CB913A6902 for ; Fri, 4 Apr 2008 11:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 cVA9cRiombNu for ; Fri, 4 Apr 2008 11:32:40 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 8B7F43A68B5 for ; Fri, 4 Apr 2008 11:32:39 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 063F55A8B32 for ; Fri, 4 Apr 2008 15:32:47 -0300 (ART) Received: from notebook.gont.com.ar (host138.190-139-181.telecom.net.ar [190.139.181.138]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m34IWTC5025090 for ; Fri, 4 Apr 2008 15:32:31 -0300 Message-Id: <200804041832.m34IWTC5025090@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Apr 2008 15:30:24 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 04 Apr 2008 15:32:42 -0300 (ART) Subject: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Folks, I have not yet reviewed the entire document (but will do). However, reading the security considerations section (and at the risk of sounding our own horn?), I see this document does not reference two closely related wg documents of the tcpm and tsvwg working groups. The first one is the ICMP attacks draft (draft-ietf-tcpm-icmp-attacks). While tcpsecure mentions the security implications of ICMP on TCP conenctions, it does not reference the I-D. IIRC, this had already been pointed out by Joe (?). As far as the specifications are concerned, you shouldn't bother to fix TCP-based reset attacks if you don't fix the the ICMP-based ones. The other doc is the port randomization draft (draft-tsvwg-port-randomization). All the math in the "Slipping in the window" paper assumes TCP implementtions use a small port number subspace for selecting the ephemeral ports. And also assumes that implementations use a trivially-predictable sequence. Clearly, port randomization is a trivial mitigation for both these and all other off-path attacks that require the attacker to guess or know the four-tuple that identifies the connection to be attacked. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 4 12:56:21 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63EEE28C1AE; Fri, 4 Apr 2008 12:56:21 -0700 (PDT) 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 B2FB828C4AF for ; Fri, 4 Apr 2008 12:56:20 -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 Ny-YuU-05WUO for ; Fri, 4 Apr 2008 12:56:18 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 8D2933A6FA8 for ; Fri, 4 Apr 2008 12:55:44 -0700 (PDT) Received: from [127.0.0.1] (193.sub-70-212-209.myvzw.com [70.212.209.193]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m34Jt0U6020439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Apr 2008 12:55:02 -0700 (PDT) Message-ID: <47F68794.6050100@isi.edu> Date: Fri, 04 Apr 2008 12:55:00 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Fernando Gont References: <200804041832.m34IWTC5025090@venus.xmundo.net> In-Reply-To: <200804041832.m34IWTC5025090@venus.xmundo.net> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1734783586==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1734783586== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig92F5E7EFB283B176A54EA4E4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig92F5E7EFB283B176A54EA4E4 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Folks, >=20 > I have not yet reviewed the entire document (but will do). However,=20 > reading the security considerations section (and at the risk of=20 > sounding our own horn?), I see this document does not reference two=20 > closely related wg documents of the tcpm and tsvwg working groups. >=20 > The first one is the ICMP attacks draft=20 > (draft-ietf-tcpm-icmp-attacks). While tcpsecure mentions the security=20 > implications of ICMP on TCP conenctions, it does not reference the=20 > I-D. IIRC, this had already been pointed out by Joe (?). As far as=20 > the specifications are concerned, you shouldn't bother to fix=20 > TCP-based reset attacks if you don't fix the the ICMP-based ones. Agreed; should this doc recommend filtering out ICMPs as a result?=20 (there's no in-window checks that are meaningful, since ICMPs are not=20 guaranteed to be timely) I.e., something stronger than "there's nothing=20 we can do", which is what is implied in the current security consideratio= ns. > The other doc is the port randomization draft=20 > (draft-tsvwg-port-randomization).=20 Also ISN randomization (RFC-1948), for similar reasons. Even though some = of the RST attacks span the entire window, knowing the ISN can help=20 during the initial handshake and shortly thereafter. Joe --------------enig92F5E7EFB283B176A54EA4E4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH9oeUE5f5cImnZrsRAkNjAJ49ype+avjU1Rh2c3+nyI+o07RQeQCcD5fM S/BKWyfu1L8+qb1xB6f20+E= =qrE7 -----END PGP SIGNATURE----- --------------enig92F5E7EFB283B176A54EA4E4-- --===============1734783586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1734783586==-- From tcpm-bounces@ietf.org Fri Apr 4 13:12:57 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FFA43A6CF2; Fri, 4 Apr 2008 13:12:57 -0700 (PDT) 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 368973A6C65 for ; Fri, 4 Apr 2008 13:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 M1c0sbAdEe5O for ; Fri, 4 Apr 2008 13:12:55 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 042F03A6CEB for ; Fri, 4 Apr 2008 13:12:53 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 840FF5A7460; Fri, 4 Apr 2008 17:13:02 -0300 (ART) Received: from notebook.gont.com.ar (168-226-14-25.speedy.com.ar [168.226.14.25] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m34KCk8U022643; Fri, 4 Apr 2008 17:12:47 -0300 Message-Id: <200804042012.m34KCk8U022643@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Apr 2008 17:10:54 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <47F68794.6050100@isi.edu> References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 04 Apr 2008 17:12:59 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 04:55 p.m. 04/04/2008, Joe Touch wrote: >>The first one is the ICMP attacks draft >>(draft-ietf-tcpm-icmp-attacks). While tcpsecure mentions the >>security implications of ICMP on TCP conenctions, it does not >>reference the I-D. IIRC, this had already been pointed out by Joe >>(?). As far as the specifications are concerned, you shouldn't >>bother to fix TCP-based reset attacks if you don't fix the the ICMP-based ones. > >Agreed; should this doc recommend filtering out ICMPs as a result? >(there's no in-window checks that are meaningful, since ICMPs are >not guaranteed to be timely) I.e., something stronger than "there's >nothing we can do", which is what is implied in the current security >considerations. Ha... So we have been arguing about the ICMP stuff for almost four years on the idea that it is too aggressive to require ICMP error messages to be in-window, and now we're going to propose to filter them out? Seems ironic to me. (And you cannot do it with "frag needed and DF bit set". Well, you *could* implement the new PMTUD that does not rely on ICMP error messages. But ignoring ICMP error messages will increse the PMTUD convergence time). And, for what is worth, strictly speaking there's no such a thing as a TCP MSL, either. TCP's MSL is based on the assumption that the IP TTL is decremented at least once every second. And this is not warranted, either. There's not such enforcement as there is in, e.g., Delta-t. >>The other doc is the port randomization draft >>(draft-tsvwg-port-randomization). > >Also ISN randomization (RFC-1948), for similar reasons. Even though >some of the RST attacks span the entire window, knowing the ISN can >help during the initial handshake and shortly thereafter. Agreed. (Although the math in "Slipping in the window" does not assume the attacker can predict the ISN). 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 4 13:21:37 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49813A6969; Fri, 4 Apr 2008 13:21:37 -0700 (PDT) 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 62E103A68BA for ; Fri, 4 Apr 2008 13:21: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=[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 4wNELlzrCnF0 for ; Fri, 4 Apr 2008 13:21:35 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 8CF633A6969 for ; Fri, 4 Apr 2008 13:21:35 -0700 (PDT) Received: from [127.0.0.1] (193.sub-70-212-209.myvzw.com [70.212.209.193]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m34KLS9i029045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Apr 2008 13:21:29 -0700 (PDT) Message-ID: <47F68DC7.2050303@isi.edu> Date: Fri, 04 Apr 2008 13:21:27 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Fernando Gont References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> In-Reply-To: <200804042012.m34KCk8U022643@venus.xmundo.net> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0048871778==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0048871778== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig86768CC810F01583157DD842" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig86768CC810F01583157DD842 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 04:55 p.m. 04/04/2008, Joe Touch wrote: >=20 >>> The first one is the ICMP attacks draft=20 >>> (draft-ietf-tcpm-icmp-attacks). While tcpsecure mentions the security= =20 >>> implications of ICMP on TCP conenctions, it does not reference the=20 >>> I-D. IIRC, this had already been pointed out by Joe (?). As far as=20 >>> the specifications are concerned, you shouldn't bother to fix=20 >>> TCP-based reset attacks if you don't fix the the ICMP-based ones. >> >> Agreed; should this doc recommend filtering out ICMPs as a result?=20 >> (there's no in-window checks that are meaningful, since ICMPs are not = >> guaranteed to be timely) I.e., something stronger than "there's=20 >> nothing we can do", which is what is implied in the current security=20 >> considerations. >=20 > Ha... So we have been arguing about the ICMP stuff for almost four year= s=20 > on the idea that it is too aggressive to require ICMP error messages to= =20 > be in-window, and now we're going to propose to filter them out?=20 ICMPs are already filtered out for security reasons at firewalls. The=20 key here is whether to recommend that action or not. As to filtering them when they're in- vs out- of window, the issue there = is whether that even means anything. The point is that with arbitrary=20 delays, the location of an ICMP's TCP header with respect to the current = outstanding window has no useful meaning, so it cannot (and thus should=20 not) serve as a useful descriminator. > Seems > ironic to me. (And you cannot do it with "frag needed and DF bit set". = > Well, you *could* implement the new PMTUD that does not rely on ICMP=20 > error messages. But ignoring ICMP error messages will increse the PMTUD= =20 > convergence time). >=20 > And, for what is worth, strictly speaking there's no such a thing as a = > TCP MSL, either. TCP's MSL is based on the assumption that the IP TTL i= s=20 > decremented at least once every second. And this is not warranted,=20 > either. There's not such enforcement as there is in, e.g., Delta-t. If there's no MSL, then that's even more reason not to use window=20 information to determine the validity of an ICMP. At that point, not=20 only might you be receiving a very old ICMP, you might be receiving a=20 very recent ICMP for a very old TCP segment. >>> The other doc is the port randomization draft=20 >>> (draft-tsvwg-port-randomization). >> >> Also ISN randomization (RFC-1948), for similar reasons. Even though=20 >> some of the RST attacks span the entire window, knowing the ISN can=20 >> help during the initial handshake and shortly thereafter. >=20 > Agreed. (Although the math in "Slipping in the window" does not assume = > the attacker can predict the ISN). Right - it's not nearly as important as the port randomization for this=20 case. Joe --------------enig86768CC810F01583157DD842 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH9o3HE5f5cImnZrsRAhWmAJ4wLeqSCJzhzgDqYsrVH/e0Nk9yJgCg+OTn lG4REKziwuAX+7RxyH0dV1M= =1++r -----END PGP SIGNATURE----- --------------enig86768CC810F01583157DD842-- --===============0048871778== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0048871778==-- From tcpm-bounces@ietf.org Fri Apr 4 14:36:31 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CBAD28C11C; Fri, 4 Apr 2008 14:36:31 -0700 (PDT) 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 740DB3A67F7 for ; Fri, 4 Apr 2008 14:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w595lgNM5hDg for ; Fri, 4 Apr 2008 14:36:29 -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 35CA428C11C for ; Fri, 4 Apr 2008 14:35:02 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 04 Apr 2008 14:35:09 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m34LZ9tt018637; Fri, 4 Apr 2008 14:35:09 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m34LZ9R5004220; Fri, 4 Apr 2008 21:35:09 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 14:35:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 14:34:37 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804F48EC2@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <200804041832.m34IWTC5025090@venus.xmundo.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Some comments on tcpsecure Thread-Index: AciWgkufkcG5ljaTR6OLDpQCn+uXTQAF7MAg References: <200804041832.m34IWTC5025090@venus.xmundo.net> From: "Anantha Ramaiah (ananth)" To: "Fernando Gont" , X-OriginalArrivalTime: 04 Apr 2008 21:35:08.0618 (UTC) FILETIME=[C13D5AA0:01C8969B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2703; t=1207344909; x=1208208909; 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]=20Some=20comments=20on=20tcpsecu re |Sender:=20; bh=UdzenUa5Xv5MNIHX9RBG5q11BdbmVC8Y18QB0DOdIaU=; b=E1ZJJJ0pM/oCHnqlbJfxbFjmWkePf2VGRe2v1co3ZbzPlSbUvfAosIb9Bc PnmdovnbAGZkq+u99mCuw9dcyZ0UqdnBXN40yVBCbKs0tKt2/ogn24k6x0bm B2Ukh8LYukzIoMhwhNgfN+kgPBUO7yT1jAiIi4juKFRuqqyF8tv8I=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Fernando Gont > Sent: Friday, April 04, 2008 11:30 AM > To: tcpm@ietf.org > Subject: [tcpm] Some comments on tcpsecure > > Folks, > > I have not yet reviewed the entire document (but will do). > However, reading the security considerations section (and at > the risk of sounding our own horn?), I see this document does > not reference two closely related wg documents of the tcpm > and tsvwg working groups. > > The first one is the ICMP attacks draft > (draft-ietf-tcpm-icmp-attacks). While tcpsecure mentions the > security implications of ICMP on TCP conenctions, it does not > reference the I-D. IIRC, this had already been pointed out by Well, if this was really needed we should have fixed this in the document by now. I think at this stage where most of the issues have been ironed out, I would excerxise caution before making any changes. With that I mean if the group strongly feels about citing this reference then we could add it in some place. > Joe (?). As far as the specifications are concerned, you > shouldn't bother to fix TCP-based reset attacks if you don't > fix the the ICMP-based ones. I am not saying we shouldn't be fixing ICMP based attacks, we should fix both, but these are separate documents and needs to be treated seperately. > > The other doc is the port randomization draft > (draft-tsvwg-port-randomization). All the math in the > "Slipping in the window" paper assumes TCP implementtions use > a small port number subspace for selecting the ephemeral > ports. And also assumes that implementations use a > trivially-predictable sequence. Clearly, port randomization > is a trivial mitigation for both these and all other off-path > attacks that require the attacker to guess or know the > four-tuple that identifies the connection to be attacked. I can only agree that randomization makes the attack harder to accomplish, but like you noted many systems don't do it today. Like for example if you use TCP MD5 the attacks are difficult to be made... So wondering what is the point being made here? Are you saying that we should put a reference to the port randomization document? -Anantha > > Thanks, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org PGP > Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > _______________________________________________ > 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 From tcpm-bounces@ietf.org Fri Apr 4 22:57:26 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6E53A688F; Fri, 4 Apr 2008 22:57:26 -0700 (PDT) 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 C6C533A67E9 for ; Fri, 4 Apr 2008 22:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[AWL=1.472, BAYES_00=-2.599, 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 oso46XzVdI28 for ; Fri, 4 Apr 2008 22:57:25 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 93DDA3A688F for ; Fri, 4 Apr 2008 22:57:23 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5FB7F5A745D; Sat, 5 Apr 2008 02:57:36 -0300 (ART) Received: from notebook.gont.com.ar (201-254-42-144.speedy.com.ar [201.254.42.144] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m355vAjU013266; Sat, 5 Apr 2008 02:57:11 -0300 Message-Id: <200804050557.m355vAjU013266@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 05 Apr 2008 02:55:18 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <47F68DC7.2050303@isi.edu> References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sat, 05 Apr 2008 02:57:32 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 05:21 p.m. 04/04/2008, Joe Touch wrote: >>>Agreed; should this doc recommend filtering out ICMPs as a result? >>>(there's no in-window checks that are meaningful, since ICMPs are >>>not guaranteed to be timely) I.e., something stronger than >>>"there's nothing we can do", which is what is implied in the >>>current security considerations. >>Ha... So we have been arguing about the ICMP stuff for almost four >>years on the idea that it is too aggressive to require ICMP error >>messages to be in-window, and now we're going to propose to filter them out? > >ICMPs are already filtered out for security reasons at firewalls. >The key here is whether to recommend that action or not. tcpsecure should not talk about what to do with ICMP error messages. Just point out that they can be exploited to perform more trivial attacks, and reference the ICMP attacks as a reference on what the industry has done to solve these issues. > > Seems >>ironic to me. (And you cannot do it with "frag needed and DF bit >>set". Well, you *could* implement the new PMTUD that does not rely >>on ICMP error messages. But ignoring ICMP error messages will >>increse the PMTUD convergence time). >>And, for what is worth, strictly speaking there's no such a thing >>as a TCP MSL, either. TCP's MSL is based on the assumption that the >>IP TTL is decremented at least once every second. And this is not >>warranted, either. There's not such enforcement as there is in, e.g., Delta-t. > >If there's no MSL, then that's even more reason not to use window >information to determine the validity of an ICMP. And no reason to use sequence numbers at all, and no reason for TCP's quiet time, and no reason for TCP's TIME-WAIT state, etc., etc., etc. From that purist (??) point of view, TCP would not even work at all. Joe, don't be more purist than the specifications themselves. Talk with anybody working on the TCP code of NetBSD, FreeBSD, OpenBSD, Linux, or Cisco IOS, and they won't believe you are actually arguing about this....for four years. It would look to them as if you were doing your best to keep the specs as outdated as possible. 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 4 23:07:22 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D0E3A67FF; Fri, 4 Apr 2008 23:07:22 -0700 (PDT) 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 8C8763A688F for ; Fri, 4 Apr 2008 23:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.687 X-Spam-Level: X-Spam-Status: No, score=-0.687 tagged_above=-999 required=5 tests=[AWL=1.104, BAYES_00=-2.599, 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 SgOqYF5lmgld for ; Fri, 4 Apr 2008 23:07:20 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 53E983A67A4 for ; Fri, 4 Apr 2008 23:07:19 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id AEF885A745D; Sat, 5 Apr 2008 03:07:32 -0300 (ART) Received: from notebook.gont.com.ar (201-254-42-144.speedy.com.ar [201.254.42.144] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m35679ER022947; Sat, 5 Apr 2008 03:07:11 -0300 Message-Id: <200804050607.m35679ER022947@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 05 Apr 2008 03:04:58 -0300 To: "Anantha Ramaiah (ananth)" , From: Fernando Gont In-Reply-To: <0C53DCFB700D144284A584F54711EC5804F48EC2@xmb-sjc-21c.amer. cisco.com> References: <200804041832.m34IWTC5025090@venus.xmundo.net> <0C53DCFB700D144284A584F54711EC5804F48EC2@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sat, 05 Apr 2008 03:07:32 -0300 (ART) Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 06:34 p.m. 04/04/2008, Anantha Ramaiah (ananth) wrote: > > The first one is the ICMP attacks draft > > (draft-ietf-tcpm-icmp-attacks). While tcpsecure mentions the > > security implications of ICMP on TCP conenctions, it does not > > reference the I-D. IIRC, this had already been pointed out by > >Well, if this was really needed we should have fixed this in the >document by now. I think at this stage where most of the issues have >been ironed out, I would excerxise caution before making any changes. >With that I mean if the group strongly feels about citing this reference >then we could add it in some place. There's no actual "change". Just mention that the ICMP issues, and reference the ICMP attacks draft for information on the problem, and what the industry has done about it. > > Joe (?). As far as the specifications are concerned, you > > shouldn't bother to fix TCP-based reset attacks if you don't > > fix the the ICMP-based ones. > >I am not saying we shouldn't be fixing ICMP based attacks, we should fix >both, but these are separate documents and needs to be treated >seperately. Exactly. Don't get into recommendations on the ICMP issues. Just direct people to the document where this stuff is discussed. >I can only agree that randomization makes the attack harder to >accomplish, but like you noted many systems don't do it today. Nowadays, at least FreeBSD, OpenBSD and Linux do it. >Like for >example if you use TCP MD5 the attacks are difficult to be made... So >wondering what is the point being made here? Are you saying that we >should put a reference to the port randomization document? Yes. Something along the lines of "TCP port randomization [draft-ietf-port-randomization] increases the amount of work on the side of the attacker by obfuscating the TCP ephemeral port value" To make my point clear: I'm not saying you should make "statements" on whether host should or should implement "icmp attacks" or "port randomization". But you should note that the ICMP attacks are easier, and direct people to the icmp attacks draft for more information about this. And you should note that port randomization is a general mitigation-technique for off-path attacks against TCP that require more work on the side of the attacker to successfully perform such attacks. 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Apr 5 10:18:52 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CFD728C2CB; Sat, 5 Apr 2008 10:18:52 -0700 (PDT) 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 9028028C234 for ; Sat, 5 Apr 2008 10:18:51 -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 FNI++EuoAwvH for ; Sat, 5 Apr 2008 10:18:50 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BD43028C2CE for ; Sat, 5 Apr 2008 10:18:50 -0700 (PDT) Received: from [127.0.0.1] (pool-71-105-89-117.lsanca.dsl-w.verizon.net [71.105.89.117]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m35HHoBn009906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 5 Apr 2008 10:17:51 -0700 (PDT) Message-ID: <47F7B43E.6010004@isi.edu> Date: Sat, 05 Apr 2008 10:17:50 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Fernando Gont References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> In-Reply-To: <200804050557.m355vAjU013266@venus.xmundo.net> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0514453536==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0514453536== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig31A4F91DB2A2B7F72C5B59F2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig31A4F91DB2A2B7F72C5B59F2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 05:21 p.m. 04/04/2008, Joe Touch wrote: >=20 =2E.. >> ICMPs are already filtered out for security reasons at firewalls. The = >> key here is whether to recommend that action or not. >=20 > tcpsecure should not talk about what to do with ICMP error messages.=20 I disagree; as you noted, to accomplish any level of protection by=20 filtering RSTs etc., ICMPs need to be filtered as well. It can cite your = doc on the issues, but IMO needs to include a recommendation on=20 accompanying requirements.s =2E.. >>> And, for what is worth, strictly speaking there's no such a thing as = >>> a TCP MSL, either. TCP's MSL is based on the assumption that the IP=20 >>> TTL is decremented at least once every second. And this is not=20 >>> warranted, either. There's not such enforcement as there is in, e.g.,= =20 >>> Delta-t. >> >> If there's no MSL, then that's even more reason not to use window=20 >> information to determine the validity of an ICMP. >=20 > And no reason to use sequence numbers at all, and no reason for TCP's=20 > quiet time, and no reason for TCP's TIME-WAIT state, etc., etc., etc.=20 > From that purist (??) point of view, TCP would not even work at all. Absolutely - that's the absurdity of *your* point about there being no=20 such thing as MSL. However, MSL is irrelevant to ICMP even if (contrary=20 to your point above) MSL is meaningful to TCP. Jo --------------enig31A4F91DB2A2B7F72C5B59F2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH97Q+E5f5cImnZrsRAua+AKDidgAg0ymZSFZ9XTZdTwP+lcB3SACg2k7X oZhOgYUQFT6lcOf7k+SL4Xc= =qn9Q -----END PGP SIGNATURE----- --------------enig31A4F91DB2A2B7F72C5B59F2-- --===============0514453536== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0514453536==-- From tcpm-bounces@ietf.org Sat Apr 5 11:30:32 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8276C28C3D7; Sat, 5 Apr 2008 11:30:32 -0700 (PDT) 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 1BBCA28C3D7 for ; Sat, 5 Apr 2008 11:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYCaI+vCL47e for ; Sat, 5 Apr 2008 11:30:30 -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 A743F28C381 for ; Sat, 5 Apr 2008 11:30:00 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 Apr 2008 11:30:09 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m35IU9QV016205; Sat, 5 Apr 2008 11:30:09 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m35IU9Ci008409; Sat, 5 Apr 2008 18:30:09 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Apr 2008 11:30:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 5 Apr 2008 11:29:37 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804FA106D@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <200804050607.m35679ER022947@venus.xmundo.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Some comments on tcpsecure Thread-Index: AciW41PaNoXzv4MoQD+9DLyyuhlfoQAXqIqA References: <200804041832.m34IWTC5025090@venus.xmundo.net> <0C53DCFB700D144284A584F54711EC5804F48EC2@xmb-sjc-21c.amer.cisco.com> <200804050607.m35679ER022947@venus.xmundo.net> From: "Anantha Ramaiah (ananth)" To: "Fernando Gont" , X-OriginalArrivalTime: 05 Apr 2008 18:30:09.0280 (UTC) FILETIME=[13EE8800:01C8974B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1487; t=1207420209; x=1208284209; 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]=20Some=20comments=20on=20tcpsecu re |Sender:=20; bh=aov48mAXmO9w2wAdZY9Ae+5Iy5Y0Fgsp4LEMk1KiXyw=; b=P7FfSQjOoaQ2+NskdI6VCho5EMR3NmLGWwAeXSZtbQTzn9Tb6ZP8NtZThd k7xEVQkBZxz6LDw1VbyoObPpnf8MdxxY0fktQYiHqoW4WPpMzrm93zRdLBAb OorLfeSFz+; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > > >I can only agree that randomization makes the attack harder to > >accomplish, but like you noted many systems don't do it today. > > Nowadays, at least FreeBSD, OpenBSD and Linux do it. Just for the sake of record, we have been doing port randomization in some of our main protocol stacks for about 3 years or so and the algorithms we follow are more less the ones recommended in the port randomization draft. > Yes. Something along the lines of "TCP port randomization > [draft-ietf-port-randomization] increases the amount of work on the > side of the attacker by obfuscating the TCP ephemeral port value" > > To make my point clear: I'm not saying you should make "statements" > on whether host should or should implement "icmp attacks" or "port > randomization". But you should note that the ICMP attacks are easier, > and direct people to the icmp attacks draft for more information > about this. And you should note that port randomization is a general > mitigation-technique for off-path attacks against TCP that require > more work on the side of the attacker to successfully perform > such attacks. One point which I wish to add : the long lived nature of some TCP connections gives enough time for the attacker (attack program) to successfully penetrate the connection. I'll leave it to the WG consensus to determine whether citing these references is ok at this point in the game. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Apr 5 13:24:53 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8545D3A6C85; Sat, 5 Apr 2008 13:24:53 -0700 (PDT) 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 D13003A6C85 for ; Sat, 5 Apr 2008 13:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599, 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 NHCTT-jwnFaG for ; Sat, 5 Apr 2008 13:24:52 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id A74033A6C0C for ; Sat, 5 Apr 2008 13:24:50 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 70C9C5A8A3A; Sat, 5 Apr 2008 17:25:01 -0300 (ART) Received: from notebook.gont.com.ar (201-254-42-144.speedy.com.ar [201.254.42.144] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m35KOlmj018418; Sat, 5 Apr 2008 17:24:48 -0300 Message-Id: <200804052024.m35KOlmj018418@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 05 Apr 2008 17:15:41 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <47F7B43E.6010004@isi.edu> References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sat, 05 Apr 2008 17:25:00 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 02:17 p.m. 05/04/2008, Joe Touch wrote: >>>>And, for what is worth, strictly speaking there's no such a thing >>>>as a TCP MSL, either. TCP's MSL is based on the assumption that >>>>the IP TTL is decremented at least once every second. And this is >>>>not warranted, either. There's not such enforcement as there is >>>>in, e.g., Delta-t. >>> >>>If there's no MSL, then that's even more reason not to use window >>>information to determine the validity of an ICMP. >>And no reason to use sequence numbers at all, and no reason for >>TCP's quiet time, and no reason for TCP's TIME-WAIT state, etc., >>etc., etc. From that purist (??) point of view, TCP would not even work at all. > >Absolutely - that's the absurdity of *your* point about there being >no such thing as MSL. However, MSL is irrelevant to ICMP even if >(contrary to your point above) MSL is meaningful to TCP. The ICMP attacks drafts used to propose (unfortunately, right now it only "documents") a number of mitigation techniques for ICMP-based attacks. Among these were: 1) Require ICMP messages to be in window. 2) Don't reset connections in the synchronized (>ESTABLISHED) states upno receipt of the so-called ICMP hard errors. You argument against (1) is that there's not such a timing requirement for ICMP messages. If that's your argument, then please also propose to remove any sequence number checks and any other assumptions on the MSL (e.g., quiet time concept, TIME-WAIT state) that are based on timing assumptions of TCP segments (and hence IP datagrams) that are *not* required in the protocols, *either*. Or well, that at least cannot be enforced. (Again, if you want this, you want something like Delta-t). Your argument against (2) is that...mmm... that would be incorrect, because it would assume that every packet is an attack. But you do want to advocate ICMP filtering at firewalls. I'd love to get everybody who's everyday job is to work on the TCP code of real TCP stacks. But while I have been in contact with many of these people (both for the I-Ds I published at the IETF, and for other work), the general idea is that it is a waste of time to argue for years what everybody has already been doing for years now (not to say 20+ years). The only real discussion here is how irrelevant we want the IETF specs to be. 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Apr 5 13:37:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E7A28C36C; Sat, 5 Apr 2008 13:37:02 -0700 (PDT) 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 0AC893A6BC0 for ; Sat, 5 Apr 2008 13:37:02 -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 h7SvvJIGr9+D for ; Sat, 5 Apr 2008 13:37:01 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2B2713A69A0 for ; Sat, 5 Apr 2008 13:37:01 -0700 (PDT) Received: from [127.0.0.1] (pool-71-105-89-117.lsanca.dsl-w.verizon.net [71.105.89.117]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m35KaWO8019494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 5 Apr 2008 13:36:33 -0700 (PDT) Message-ID: <47F7E2D0.8010802@isi.edu> Date: Sat, 05 Apr 2008 13:36:32 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Fernando Gont References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> In-Reply-To: <200804052024.m35KOlmj018418@venus.xmundo.net> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0872641951==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0872641951== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig56C8CBE98A687E5DCFF8EFDF" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig56C8CBE98A687E5DCFF8EFDF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 02:17 p.m. 05/04/2008, Joe Touch wrote: >=20 >>>>> And, for what is worth, strictly speaking there's no such a thing=20 >>>>> as a TCP MSL, either. TCP's MSL is based on the assumption that the= =20 >>>>> IP TTL is decremented at least once every second. And this is not=20 >>>>> warranted, either. There's not such enforcement as there is in,=20 >>>>> e.g., Delta-t. >>>> >>>> If there's no MSL, then that's even more reason not to use window=20 >>>> information to determine the validity of an ICMP. >>> And no reason to use sequence numbers at all, and no reason for TCP's= =20 >>> quiet time, and no reason for TCP's TIME-WAIT state, etc., etc., etc.= =20 >>> From that purist (??) point of view, TCP would not even work at all. >> >> Absolutely - that's the absurdity of *your* point about there being no= =20 >> such thing as MSL. However, MSL is irrelevant to ICMP even if=20 >> (contrary to your point above) MSL is meaningful to TCP. >=20 > The ICMP attacks drafts used to propose (unfortunately, right now it=20 > only "documents") a number of mitigation techniques for ICMP-based=20 > attacks. Among these were: >=20 > 1) Require ICMP messages to be in window. > 2) Don't reset connections in the synchronized (>ESTABLISHED) states=20 > upno receipt of the so-called ICMP hard errors. >=20 > You argument against (1) is that there's not such a timing requirement = > for ICMP messages. If that's your argument, then please also propose to= =20 > remove any sequence number checks and any other assumptions on the MSL = > (e.g., quiet time concept, TIME-WAIT state) that are based on timing=20 > assumptions of TCP segments (and hence IP datagrams) that are *not*=20 > required in the protocols, *either*. Or well, that at least cannot be=20 > enforced. (Again, if you want this, you want something like Delta-t). As I said before: TCP *has* an MSL requirement (RFC793) this means that TCP segments should not live in the network beyond approx 2 minutes ICMP does *not* have a requirement to respond with an MSL so a TCP segment's header can exist inside an ICMP packet long after the segment's MSL period As a result, it remains incorrect to validate a TCP segment inside the=20 ICMP as needing to be "in window". > Your argument against (2) is that...mmm... that would be incorrect,=20 > because it would assume that every packet is an attack. But you do want= =20 > to advocate ICMP filtering at firewalls. Correct. If an individual host or subnet wants to assume that ALL ICMPs=20 are suspect, then that's its decision - and that already happens at some = firewalls. However, it is incorrect to *assume* that a particular kind of ICMP is=20 an attack and another is not simply because it is unexpected. That's the = flaw in #2. What "everyone implements" isn't the issue; that is covered in BCPs when = the IETF agrees with it and things like RFC 2525 (Known TCP=20 Implementation Problems) when the IETF does not feel it is appropriate=20 to change the standard merely to align with what is deployed. In this case, since ICMPs *are* delayed, I don't think it is appropriate = to align ICMP checks with what is deployed. Joe --------------enig56C8CBE98A687E5DCFF8EFDF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH9+LQE5f5cImnZrsRAmbbAKDNSMIN7BEcBqWHf93onqjmtYe8lQCgoRoi ZQ8fjhUtwQdI4quG642k0b4= =SOyE -----END PGP SIGNATURE----- --------------enig56C8CBE98A687E5DCFF8EFDF-- --===============0872641951== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0872641951==-- From tcpm-bounces@ietf.org Sat Apr 5 16:53:48 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529753A6A9C; Sat, 5 Apr 2008 16:53:48 -0700 (PDT) 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 56ABE3A6A9C for ; Sat, 5 Apr 2008 16:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.055 X-Spam-Level: X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, 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 mSEJfzqAgVDf for ; Sat, 5 Apr 2008 16:53:46 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 37B5E3A6810 for ; Sat, 5 Apr 2008 16:53:45 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id A8BA25A899E; Sat, 5 Apr 2008 20:53:58 -0300 (ART) Received: from notebook.gont.com.ar (201-254-42-144.speedy.com.ar [201.254.42.144] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m35NrdO1031661; Sat, 5 Apr 2008 20:53:40 -0300 Message-Id: <200804052353.m35NrdO1031661@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 05 Apr 2008 20:51:05 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <47F7E2D0.8010802@isi.edu> References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sat, 05 Apr 2008 20:53:57 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 05:36 p.m. 05/04/2008, Joe Touch wrote: >As I said before: > > TCP *has* an MSL requirement (RFC793) > this means that TCP segments should not live > in the network beyond approx 2 minutes Yes, and this requirement cannot be met, as it is based on the assumption that the IP TTL can be enforced. (Not to say that the MSL sort of imposes a requirement on the TTL you set in IP packets. If you set a TTL of say 240, then the TTL becomes 4 minutes, and 2*MSL becomes eight minutes. As a result, if anything, this is as incorrect as requiring ICMPs to be in window. Well, unless you run TCP on anything other than IP.... > ICMP does *not* have a requirement to respond with an MSL > so a TCP segment's header can exist inside > an ICMP packet long after the segment's MSL period > >As a result, it remains incorrect to validate a TCP segment inside >the ICMP as needing to be "in window". If there's an error, the the window won't advance, and in the event the window does advance, then the error was not really "hard". And it would have been incorrect to abort the TCP connection. (see e.g., Clark's paper). >>Your argument against (2) is that...mmm... that would be incorrect, >>because it would assume that every packet is an attack. But you do >>want to advocate ICMP filtering at firewalls. > >Correct. If an individual host or subnet wants to assume that ALL >ICMPs are suspect, then that's its decision - and that already >happens at some firewalls. Welcome to the real world. We're suspicious by default. >What "everyone implements" isn't the issue; that is covered in BCPs >when the IETF agrees with it and things like RFC 2525 (Known TCP >Implementation Problems) when the IETF does not feel it is >appropriate to change the standard merely to align with what is deployed. What "everyone implements" isn't the issue? ahem... "rough consensus and running code". There's no code that runs what you're describing, Joe. Everybody is doing what is described in the ICMP attacks draft. 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Apr 5 18:02:59 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F20C3A6B92; Sat, 5 Apr 2008 18:02:59 -0700 (PDT) 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 2C10B3A6AA7 for ; Sat, 5 Apr 2008 18:02:58 -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 jMs7bwtJ+X+f for ; Sat, 5 Apr 2008 18:02:57 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0BC523A682D for ; Sat, 5 Apr 2008 18:02:57 -0700 (PDT) Received: from [127.0.0.1] (pool-71-105-89-117.lsanca.dsl-w.verizon.net [71.105.89.117]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m3612ewe003745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 5 Apr 2008 18:02:42 -0700 (PDT) Message-ID: <47F82129.2000603@isi.edu> Date: Sat, 05 Apr 2008 18:02:33 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Fernando Gont References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> <200804052353.m35NrdO1031661@venus.xmundo.net> In-Reply-To: <200804052353.m35NrdO1031661@venus.xmundo.net> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1178772018==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1178772018== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig68C56FA31F53EEE850025980" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig68C56FA31F53EEE850025980 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 05:36 p.m. 05/04/2008, Joe Touch wrote: >=20 >> As I said before: >> >> TCP *has* an MSL requirement (RFC793) >> this means that TCP segments should not live >> in the network beyond approx 2 minutes >=20 > Yes, and this requirement cannot be met, as it is based on the=20 > assumption that the IP TTL can be enforced. (Not to say that the MSL=20 > sort of imposes a requirement on the TTL you set in IP packets. If you = > set a TTL of say 240, then the TTL becomes 4 minutes, and 2*MSL becomes= =20 > eight minutes. >=20 > As a result, if anything, this is as incorrect as requiring ICMPs to be= =20 > in window. Well, unless you run TCP on anything other than IP.... If you want to win this part of the argument, then - as you note -=20 window information is never useful within TCP. What's the point of this=20 straw-man? >> ICMP does *not* have a requirement to respond with an MSL >> so a TCP segment's header can exist inside >> an ICMP packet long after the segment's MSL period >> >> As a result, it remains incorrect to validate a TCP segment inside the= =20 >> ICMP as needing to be "in window". >=20 > If there's an error, the the window won't advance, and in the event the= =20 > window does advance, then the error was not really "hard". And it would= > have been incorrect to abort the TCP connection. (see e.g., Clark's pap= er). The ICMP error isn't "TCP failing to make progress" - if you want that=20 one, please create a new ICMP error type. Whether you do or not, please=20 stop trying to imply those semantics to the current ICMP errors. >>> Your argument against (2) is that...mmm... that would be incorrect,=20 >>> because it would assume that every packet is an attack. But you do=20 >>> want to advocate ICMP filtering at firewalls. >> >> Correct. If an individual host or subnet wants to assume that ALL=20 >> ICMPs are suspect, then that's its decision - and that already happens= =20 >> at some firewalls. >=20 > Welcome to the real world. We're suspicious by default. Postel's rule applies; be conservative in what you do, be liberal in=20 what you receive. You can be suspicious all you want - but unfounded=20 suspicion isn't appropriate. >> What "everyone implements" isn't the issue; that is covered in BCPs=20 >> when the IETF agrees with it and things like RFC 2525 (Known TCP=20 >> Implementation Problems) when the IETF does not feel it is appropriate= =20 >> to change the standard merely to align with what is deployed. >=20 > What "everyone implements" isn't the issue? ahem... "rough consensus an= d=20 > running code". It's rough consensus AND running code. Not 'running code trumps everythin= g'. > There's no code that runs what you're describing, Joe. Everybody is=20 > doing what is described in the ICMP attacks draft. Popular vote does not determine correctness. Part of the problem is that = there are some people who've deployed prototype code and convinced=20 everyone it's appropriate. That is NOT how protocol specifications are=20 determined. We've had this debate before. If there's nothing new to add, let's let=20 others chime in. Joe --------------enig68C56FA31F53EEE850025980 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+CEwE5f5cImnZrsRAvwMAJ49suHYcQoFlEuNX3UBaQ10XOpwqQCdGkIm Ywp2o7aNptEkP9+1EhwOhz0= =kz3y -----END PGP SIGNATURE----- --------------enig68C56FA31F53EEE850025980-- --===============1178772018== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1178772018==-- From tcpm-bounces@ietf.org Sat Apr 5 19:34:13 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 899C43A68CF; Sat, 5 Apr 2008 19:34:13 -0700 (PDT) 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 672F63A686B for ; Sat, 5 Apr 2008 19:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+XOha++XhKC for ; Sat, 5 Apr 2008 19:34:10 -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 E25E03A68CF for ; Sat, 5 Apr 2008 19:34:10 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 05 Apr 2008 19:34:20 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m362YKQb026871; Sat, 5 Apr 2008 19:34:20 -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.13.8) with ESMTP id m362YKQe004182; Sun, 6 Apr 2008 02:34:20 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.1830); Sat, 5 Apr 2008 19:34:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 5 Apr 2008 19:33:48 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804FA108B@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <47F82129.2000603@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Some comments on tcpsecure Thread-Index: AciXgfxnoMwiTq4DR+KE1fvEqqV9NgAB+zeQ References: <200804041832.m34IWTC5025090@venus.xmundo.net><47F68794.6050100@isi.edu><200804042012.m34KCk8U022643@venus.xmundo.net><47F68DC7.2050303@isi.edu><200804050557.m355vAjU013266@venus.xmundo.net><47F7B43E.6010004@isi.edu><200804052024.m35KOlmj018418@venus.xmundo.net><47F7E2D0.8010802@isi.edu><200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Fernando Gont" X-OriginalArrivalTime: 06 Apr 2008 02:34:20.0276 (UTC) FILETIME=[B7ACBB40:01C8978E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1616; t=1207449260; x=1208313260; c=relaxed/simple; s=sjdkim3002; 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]=20Some=20comments=20on=20tcpsecu re |Sender:=20; bh=/0FjJvm8CXwfttTb/dphSRL5v/RDbsCN5MpAjKqfgOU=; b=uhNV1GbXv87E6YCzRB8lUOxAwohLlCvfVkc95CUSkU1MBP/m63V+1WWIl5 v6DjMAWCIAEHR2uzGGUJXPPw2eg0rumlfCCSbtNrHkir2dDIUFoa/dYuIFgq 1OzT6wepxU; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > > > > What "everyone implements" isn't the issue? ahem... "rough > consensus > > and running code". > > It's rough consensus AND running code. Not 'running code > trumps everything'. > > > There's no code that runs what you're describing, Joe. Everybody is > > doing what is described in the ICMP attacks draft. > > Popular vote does not determine correctness. Part of the > problem is that there are some people who've deployed > prototype code and convinced everyone it's appropriate. That > is NOT how protocol specifications are determined. > > We've had this debate before. If there's nothing new to add, > let's let others chime in. I'll chime in, my few cents follows : Protocol specifications do evolve from time to time. For example, if most of the devices which is running in the internet is already implementing what is being proposed for quite sometime, the proof is in the pudding. In such cases it CAN be considered for standardization and also this (ICMP attacks) is already a WG document and I think making forward progress is important here. So what is being said above comes across as totally out of place given the current context. Well, there are tons of examples where "prototype" code has become a standard, should I start giving examples, I won't since everyone who has been around knows this is a fact and I am in no mood to spend my energy in debating something so obvious. May be someone's definition of prototype code isn't the same as mine, then that is a different discussion altogether ;-) -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Apr 6 03:42:56 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5613A6D37; Sun, 6 Apr 2008 03:42:55 -0700 (PDT) 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 40CE93A6D37 for ; Sun, 6 Apr 2008 03:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, 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 MqBc5DyFW92z for ; Sun, 6 Apr 2008 03:42:53 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 2CE603A6D34 for ; Sun, 6 Apr 2008 03:42:52 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id F29C85A898D; Sun, 6 Apr 2008 07:43:02 -0300 (ART) Received: from notebook.gont.com.ar (201-254-42-144.speedy.com.ar [201.254.42.144] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m36AgYGx028003; Sun, 6 Apr 2008 07:42:37 -0300 Message-Id: <200804061042.m36AgYGx028003@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 06 Apr 2008 07:40:44 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <47F82129.2000603@isi.edu> References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> <200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sun, 06 Apr 2008 07:42:56 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 10:02 p.m. 05/04/2008, Joe Touch wrote: >>> TCP *has* an MSL requirement (RFC793) >>> this means that TCP segments should not live >>> in the network beyond approx 2 minutes >>Yes, and this requirement cannot be met, as it is based on the >>assumption that the IP TTL can be enforced. (Not to say that the >>MSL sort of imposes a requirement on the TTL you set in IP packets. >>If you set a TTL of say 240, then the TTL becomes 4 minutes, and >>2*MSL becomes eight minutes. >>As a result, if anything, this is as incorrect as requiring ICMPs >>to be in window. Well, unless you run TCP on anything other than IP.... > >If you want to win this part of the argument, then - as you note - >window information is never useful within TCP. What's the point of >this straw-man? That if you want to be picky, that's where you should probably start. You talk about how incorrect it would be to enforce ICMP messages to be in-window... but even the most basic timing assumptions in TCP are not "correct", either. Yes, "It just works". But that does not imply "correctness". [...] >>>As a result, it remains incorrect to validate a TCP segment inside >>>the ICMP as needing to be "in window". >>If there's an error, the the window won't advance, and in the event >>the window does advance, then the error was not really "hard". And it would >>have been incorrect to abort the TCP connection. (see e.g., Clark's paper). > >The ICMP error isn't "TCP failing to make progress" - if you want >that one, please create a new ICMP error type. Whether you do or >not, please stop trying to imply those semantics to the current ICMP errors. We're not here to re-hash history, are we? >>There's no code that runs what you're describing, Joe. Everybody is >>doing what is described in the ICMP attacks draft. > >Popular vote does not determine correctness. Part of the problem is >that there are some people who've deployed prototype code and >convinced everyone it's appropriate. That is NOT how protocol >specifications are determined. There's a recent and wonderful book by old-timer John Day, in which he explains that the internet protocols themselves were what you call "prototype" (and I'm referencing that particular book just for the fact that the author is great, and I love his book). So... I find your comment a little bit ironic. :-) 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Apr 6 13:06:00 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B693A6DEE; Sun, 6 Apr 2008 13:05:59 -0700 (PDT) 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 1479F3A6DEE for ; Sun, 6 Apr 2008 13:05:59 -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 kvpoPa4FkiMo for ; Sun, 6 Apr 2008 13:05:58 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1F6553A6DC1 for ; Sun, 6 Apr 2008 13:05:58 -0700 (PDT) Received: from [127.0.0.1] (pool-71-105-89-117.lsanca.dsl-w.verizon.net [71.105.89.117]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m36K5hs5026804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 6 Apr 2008 13:05:45 -0700 (PDT) Message-ID: <47F92D13.4020809@isi.edu> Date: Sun, 06 Apr 2008 13:05:39 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Fernando Gont References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> <200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> <200804061042.m36AgYGx028003@venus.xmundo.net> In-Reply-To: <200804061042.m36AgYGx028003@venus.xmundo.net> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1817309857==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1817309857== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig01C6CB2C6983F7C49082D8C6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig01C6CB2C6983F7C49082D8C6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Let's try to move this forward constructively... Let's assume that we all want to make TCP's processing of error messages = depend on the coarse connection state - i.e., different interpretation=20 of errors in pre-established vs. established states. This is basically how the current TCP ICMP processing is already defined, and would extend it to be more uniform, which seems reasonable. Let's further assume, that in the established state, that "making=20 progress" should invalidate receipt of error messages to the contrary. This is a *departure* from current TCP ICMP processing, which basically says that errors trump progress. Whether this is reasonable depends on how slowly you want TCP to make progress while receiving legitimate errors (e.g., due to flakey links, multipath/routing errors, etc.), vs. making TCP robust to such behavior. I do believe we need to make this work in the case of non-malicious behavior. Only then should we consider whether or not it affords obfuscation protection against attackers. Given this case, then *progress* is the metric. That implies: - cache received ICMPs and log window state - determine if the window moves after the ICMP is received; if so, drop that ICMP One key issue above: it is NOT dependent on the window data in the ICMP=20 payload, for two reasons: 1) (my point) ICMPs are not required to be issued in a timely fashion, or for every individual error, a legitimate situation could involve receiving an old ICMP about an endpoint failure, without receiving further updates on any particular schedule 2) (Fernando's point) ICMPs are currently implemented widely as not being issued in a timely fashion, with the same results as #1 I.e., it doesn't matter if you design for spec or common=20 implementations; either way, ICMP payload window information is not=20 relevant to the "making progress" issue. If you want to recommend that we change ICMP interpretation when making=20 progress, then base your decision on a direct metric of making progress, = not an incorectly inferred one. Joe --------------enig01C6CB2C6983F7C49082D8C6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+S0XE5f5cImnZrsRAhbFAKCFAXO2j9jPZ8PJ7g/9YYr+E2hhIgCgqxbm jTM/RlO8Qz5e0ToziYOdMgU= =Nbwu -----END PGP SIGNATURE----- --------------enig01C6CB2C6983F7C49082D8C6-- --===============1817309857== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1817309857==-- From tcpm-bounces@ietf.org Sun Apr 6 15:41:24 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538733A6B0A; Sun, 6 Apr 2008 15:41:24 -0700 (PDT) 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 8C87D3A6B0A for ; Sun, 6 Apr 2008 15:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.162 X-Spam-Level: X-Spam-Status: No, score=-0.162 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, FRT_BELOW2=2.154, 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 THn6dpcQQ1sU for ; Sun, 6 Apr 2008 15:41:22 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 667CC3A69F2 for ; Sun, 6 Apr 2008 15:41:21 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 3C59A5A745A; Sun, 6 Apr 2008 19:41:36 -0300 (ART) Received: from notebook.gont.com.ar (201-254-42-144.speedy.com.ar [201.254.42.144] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m36MfGKx010325; Sun, 6 Apr 2008 19:41:22 -0300 Message-Id: <200804062241.m36MfGKx010325@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 06 Apr 2008 19:38:34 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <47F92D13.4020809@isi.edu> References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> <200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> <200804061042.m36AgYGx028003@venus.xmundo.net> <47F92D13.4020809@isi.edu> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sun, 06 Apr 2008 19:41:35 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 05:05 p.m. 06/04/2008, Joe Touch wrote: (Meta comment: The current version of the ICMP attacks draft is meant for the Informational path. I believe I have removed/rephrased those senteces which seemed to "propose" the mitigation-techniques, rather than simply document them. If I did a good job in this last revision, the doc shouldn't be far from being ready to be shipped to the IESG. The soft errors draft is already there. These two drafts, together with another one some of us will be submitting anytime soon would be of great help as a basis for further work that would include what you sketch bellow.) Please see my comments inline.... >Let's try to move this forward constructively... Agreed. [....] > I do believe we need to make this work in the case of > non-malicious behavior. Only then should we consider > whether or not it affords obfuscation protection against > attackers. > > Given this case, then *progress* is the metric. That implies: > - cache received ICMPs and log window state > - determine if the window moves after the ICMP > is received; if so, drop that ICMP (Thinking out loud, with no coffee in the last few hours ;-) ): I'd also add "Discard the ICMP message if there's no data in flight to the destination when the ICMP error message is received" (i.e., in such a scenario, there's no "forward progress" to be made). >One key issue above: it is NOT dependent on the window data in the >ICMP payload, for two reasons: > > 1) (my point) ICMPs are not required to be issued in a timely > fashion, or for every individual error, a legitimate situation > could involve receiving an old ICMP about an endpoint failure, > without receiving further updates on any particular schedule > > 2) (Fernando's point) ICMPs are currently implemented widely > as not being issued in a timely fashion, with the same results > as #1 > >I.e., it doesn't matter if you design for spec or common >implementations; either way, ICMP payload window information is not >relevant to the "making progress" issue. Agreed. You may say "making progress" and "requiring the TCP SEQ in the ICMP payload to be 'in-window'" are two different issues. The TCP SEQ check would help a bit in those scenarios in which an attacker might be able to spoof an ICMP error message, and cause the connection to be stuck for a little while (e.g., by means of causing congestion). That is, it would require more packets on the side of the attacker. However, if TCP waits for USER_TIMEOUT to check whether the connection is making forward progress, then this is basically the "hard errors should be considered to indicate soft errors when received for connections in any of the synchronized states" behavior, and thus an attacker could not exploit the so-called ICMP hard errors to perform reset attacks. (i.e., the "hard errors should be considered to indicate soft errors when received for connections in any of the synchronized states" becomes a degenerate case of the "checking for progress on the TCP connection" when TCP waits for USER_TIMEOUT seconds before concluding whether the connection is making progress or not). (FWIW, the TCP SEQ is of a little bit more of help for PMTUD, as during what I called 'Initial Path-MTU Discovery', you probably don't want to wait, so that you get a good convergence time for the PMTUD). Kind regards, and thanks for the clarification above! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Apr 6 22:05:40 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF7C3A680F; Sun, 6 Apr 2008 22:05:40 -0700 (PDT) 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 22C653A68B6 for ; Sun, 6 Apr 2008 22:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154] 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 qxOH76GbizRg for ; Sun, 6 Apr 2008 22:05:37 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6AEEB3A680F for ; Sun, 6 Apr 2008 22:05:36 -0700 (PDT) Received: from [127.0.0.1] (pool-71-105-89-117.lsanca.dsl-w.verizon.net [71.105.89.117]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m3755MqO011117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 6 Apr 2008 22:05:24 -0700 (PDT) Message-ID: <47F9AB92.80405@isi.edu> Date: Sun, 06 Apr 2008 22:05:22 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Fernando Gont References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> <200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> <200804061042.m36AgYGx028003@venus.xmundo.net> <47F92D13.4020809@isi.edu> <200804062241.m36MfGKx010325@venus.xmundo.net> In-Reply-To: <200804062241.m36MfGKx010325@venus.xmundo.net> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1283681700==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1283681700== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7C8B9831D58BB4C89212298C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7C8B9831D58BB4C89212298C Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 05:05 p.m. 06/04/2008, Joe Touch wrote: >=20 > (Meta comment: The current version of the ICMP attacks draft is meant=20 > for the Informational path. I believe I have removed/rephrased those=20 > senteces which seemed to "propose" the mitigation-techniques, rather=20 > than simply document them. If I did a good job in this last revision,=20 > the doc shouldn't be far from being ready to be shipped to the IESG. Th= e=20 > soft errors draft is already there. These two drafts, together with=20 > another one some of us will be submitting anytime soon would be of grea= t=20 > help as a basis for further work that would include what you sketch=20 > bellow.) >=20 > Please see my comments inline.... >=20 >=20 >> Let's try to move this forward constructively... >=20 > Agreed. >=20 >=20 > [....] >> I do believe we need to make this work in the case of >> non-malicious behavior. Only then should we consider >> whether or not it affords obfuscation protection against >> attackers. >> >> Given this case, then *progress* is the metric. That implies: >> - cache received ICMPs and log window state >> - determine if the window moves after the ICMP >> is received; if so, drop that ICMP >=20 > (Thinking out loud, with no coffee in the last few hours ;-) ): I'd als= o=20 > add "Discard the ICMP message if there's no data in flight to the=20 > destination when the ICMP error message is received" (i.e., in such a=20 > scenario, there's no "forward progress" to be made). OK - again, that has nothing to do with the contents of the ICMP message.= >> One key issue above: it is NOT dependent on the window data in the=20 >> ICMP payload, for two reasons: >> >> 1) (my point) ICMPs are not required to be issued in a timely >> fashion, or for every individual error, a legitimate situation= >> could involve receiving an old ICMP about an endpoint failure,= >> without receiving further updates on any particular schedule >> >> 2) (Fernando's point) ICMPs are currently implemented widely >> as not being issued in a timely fashion, with the same results= >> as #1 >> >> I.e., it doesn't matter if you design for spec or common=20 >> implementations; either way, ICMP payload window information is not=20 >> relevant to the "making progress" issue. >=20 > Agreed. You may say "making progress" and "requiring the TCP SEQ in the= =20 > ICMP payload to be 'in-window'" are two different issues. Agreed. > The TCP SEQ check would help a bit in those scenarios in which an=20 > attacker might be able to spoof an ICMP error message, and cause the=20 > connection to be stuck for a little while (e.g., by means of causing=20 > congestion). That is, it would require more packets on the side of the = > attacker. In those cases, I still see the contents of the ICMP to be moot (w.r.t.=20 window). That info is useful only if: - ICMPs are known to be returned in a timely fashion (and there's no way of knowing) OR - there's some way to differentiate between legitimate ICMPs and attack ICMPs Since neither is the case, this is a moot issue. I do not agree that=20 checking the TCP SEQ in the content of an ICMP is ever appropriate. =09 > However, if TCP waits for USER_TIMEOUT to check whether the connection = > is making forward progress, then this is basically the "hard errors=20 > should be considered to indicate soft errors when received for=20 > connections in any of the synchronized states" behavior, and thus an=20 > attacker could not exploit the so-called ICMP hard errors to perform=20 > reset attacks. Waiting that long defeats the purpose of the errors - to terminate=20 connections more rapidly than TCP would otherwise. That is, IMO, too far.= > (i.e., the "hard errors should be considered to indicate soft errors=20 > when received for connections in any of the synchronized states" become= s=20 > a degenerate case of the "checking for progress on the TCP connection" = > when TCP waits for USER_TIMEOUT seconds before concluding whether the=20 > connection is making progress or not). >=20 > (FWIW, the TCP SEQ is of a little bit more of help for PMTUD, as during= =20 > what I called 'Initial Path-MTU Discovery', you probably don't want to = > wait, so that you get a good convergence time for the PMTUD). I'd have to think further to see if this appropriate - i.e., if done=20 only once during a connection, before a wrap, then the SEQ might be=20 appropriate to check, but only within that period. Joe --------------enig7C8B9831D58BB4C89212298C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+auSE5f5cImnZrsRAi4JAJ9uLDMH/NYR6gDdWEGDmoZKplr8EACdH8WI KaDSe5Tvesu0y5QR6Kc+AuA= =alMe -----END PGP SIGNATURE----- --------------enig7C8B9831D58BB4C89212298C-- --===============1283681700== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1283681700==-- From tcpm-bounces@ietf.org Sun Apr 6 22:14:37 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03E9E3A6BAB; Sun, 6 Apr 2008 22:14:37 -0700 (PDT) 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 0639E3A6BAB for ; Sun, 6 Apr 2008 22:14: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 z6yltmc7rIKs for ; Sun, 6 Apr 2008 22:14:35 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id D75F03A67AB for ; Sun, 6 Apr 2008 22:14:34 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m375EFib020736; Mon, 7 Apr 2008 08:14:15 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m375EFlu020732; Mon, 7 Apr 2008 08:14:15 +0300 Date: Mon, 7 Apr 2008 08:14:15 +0300 (EEST) From: Pekka Savola To: Joe Touch In-Reply-To: <47F92D13.4020809@isi.edu> Message-ID: References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> <200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> <200804061042.m36AgYGx028003@venus.xmundo.net> <47F92D13.4020809@isi.edu> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.92.1/6635/Sun Apr 6 19:29:31 2008 on otso.netcore.fi X-Virus-Status: Clean Cc: tcpm@ietf.org, Fernando Gont Subject: [tcpm] ICMP error origination timeliness X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Sun, 6 Apr 2008, Joe Touch wrote: > 1) (my point) ICMPs are not required to be issued in a timely > fashion, or for every individual error, a legitimate situation > could involve receiving an old ICMP about an endpoint failure, > without receiving further updates on any particular schedule > > 2) (Fernando's point) ICMPs are currently implemented widely > as not being issued in a timely fashion, with the same results > as #1 What is "timely fashion" in 2)? What is not? What are the scenarios where this occurs? ICMP error generation has always seemed "timely" to me. The only exception, in a way, that I've noticed is if ICMP error origination rate-limiter is active at the moment the offending packet is received. The reason I say "in a way" is that the text above makes me think the point is that ICMP error generation is delayed (which rate-limiters don't do) rather than skipped altogether. Is point 2) referring to rate-limiting or something else? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Apr 6 22:21:27 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F44B3A68F6; Sun, 6 Apr 2008 22:21:27 -0700 (PDT) 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 BFDE93A68F6 for ; Sun, 6 Apr 2008 22:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 5TqWfRl-y-b0 for ; Sun, 6 Apr 2008 22:21:25 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 064503A67AB for ; Sun, 6 Apr 2008 22:21:25 -0700 (PDT) Received: from [127.0.0.1] (pool-71-105-89-117.lsanca.dsl-w.verizon.net [71.105.89.117]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m375LJPr014944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 6 Apr 2008 22:21:20 -0700 (PDT) Message-ID: <47F9AF4F.4060208@isi.edu> Date: Sun, 06 Apr 2008 22:21:19 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Pekka Savola References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> <200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> <200804061042.m36AgYGx028003@venus.xmundo.net> <47F92D13.4020809@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] ICMP error origination timeliness X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1109977816==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1109977816== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB8255DA8A11DA09FB81923EF" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB8255DA8A11DA09FB81923EF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Sun, 6 Apr 2008, Joe Touch wrote: >> 1) (my point) ICMPs are not required to be issued in a timely >> fashion, or for every individual error, a legitimate situation >> could involve receiving an old ICMP about an endpoint failure, >> without receiving further updates on any particular schedule >> >> 2) (Fernando's point) ICMPs are currently implemented widely >> as not being issued in a timely fashion, with the same results >> as #1 >=20 > What is "timely fashion" in 2)? What is not? What are the scenarios=20 > where this occurs? Routers are not required to return ICMPs on any particular timescale. Timely most specifically would mean "within the MSL during which the=20 original TCP segment was intended to be limited to"; most practically,=20 it might be "within one MSL of when the original TCP segment was=20 received and triggered the corresponding ICMP". Non-timely would definitely mean "more than one MSL after the TCP=20 segment that triggered the ICMP event was received". That could occur=20 when a router paces its ICMP output (as recommended in RFC 1812), and=20 when an implementation uses a tail-drop queue for that logging. > ICMP error generation has always seemed "timely" to me. The only=20 > exception, in a way, that I've noticed is if ICMP error origination=20 > rate-limiter is active at the moment the offending packet is received. Exactly. > The reason I say "in a way" is that the text above makes me think the=20 > point is that ICMP error generation is delayed (which rate-limiters=20 > don't do) rather than skipped altogether. Is point 2) referring to=20 > rate-limiting or something else? The case I described is when rate limiting causes a delay. Another case=20 would be when messages are queued up and only periodically handled, and=20 that router's control plane is under significant load. Joe --------------enigB8255DA8A11DA09FB81923EF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+a9PE5f5cImnZrsRAi+gAJ47Xz7R/xHJkuMc6Ck9i7IBmAv8tACgs48K FuerpBjyzxlCP4n9kcykW/o= =POMs -----END PGP SIGNATURE----- --------------enigB8255DA8A11DA09FB81923EF-- --===============1109977816== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1109977816==-- From tcpm-bounces@ietf.org Sun Apr 6 23:26:34 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41DF3A6A10; Sun, 6 Apr 2008 23:26:34 -0700 (PDT) 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 4B9F13A6A10 for ; Sun, 6 Apr 2008 23:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peFKNEYgNcE6 for ; Sun, 6 Apr 2008 23:26:32 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4029E3A689C for ; Sun, 6 Apr 2008 23:26:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,616,1199692800"; d="scan'208";a="20180204" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 06 Apr 2008 23:26:45 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m376Qibt027086; Sun, 6 Apr 2008 23:26:44 -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.13.8) with ESMTP id m376Qi15014234; Mon, 7 Apr 2008 06:26:44 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.1830); Sun, 6 Apr 2008 23:26:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 6 Apr 2008 23:26:13 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804FA1162@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <47F9AF4F.4060208@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] ICMP error origination timeliness Thread-Index: AciYb0Nee1tLbYFQSw+xVwrpUqxvygAADh1g References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> <200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> <200804061042.m36AgYGx028003@venus.xmundo.net> <47F92D13.4020809@isi.edu> <47F9AF4F.4060208@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Pekka Savola" X-OriginalArrivalTime: 07 Apr 2008 06:26:44.0687 (UTC) FILETIME=[599ABDF0:01C89878] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2992; t=1207549605; x=1208413605; c=relaxed/simple; s=sjdkim3002; 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]=20ICMP=20error=20origination=20t imeliness |Sender:=20; bh=6HqyAaBiIBCsIMoUohmdz/gWAvJPE8F7f1THARelAHw=; b=U1vuPd+j2vU/hnP0GIgaVNSEdvb7U4odRGjSLdy4bRo4MEowmlKr8aq38m /H5AAOOZknro6pAzCE1eCaAPucqRu5hfRfl/mADRHneKHcis6HAlYpwVH9tF 8Tu331NCGy; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] ICMP error origination timeliness X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > > > > What is "timely fashion" in 2)? What is not? What are the > scenarios > > where this occurs? > > Routers are not required to return ICMPs on any particular timescale. Routers are not going to delay the ICMP message generation unnecessarily. In most cases the ICMP messages are going to be generated in orderly and timely fashion. > > Timely most specifically would mean "within the MSL during > which the original TCP segment was intended to be limited > to"; most practically, it might be "within one MSL of when > the original TCP segment was received and triggered the > corresponding ICMP". > > Non-timely would definitely mean "more than one MSL after the > TCP segment that triggered the ICMP event was received". That > could occur when a router paces its ICMP output (as > recommended in RFC 1812), and when an implementation uses a > tail-drop queue for that logging. - Rate-limiting/ICMP messages being dropped can happen anytime/anywhere, but overly delaying ICMP isn't common. Anyways the end-points responsibility is to be robust and not fooled by the presense or the absense of the ICMP messages. PMTU blackhole detection and recovery is there for a reason. Since you cannot rely on the ICMP message being generated always, if one is generated then putting some additional checks to validate it doesn't look far-fetched, IMO. Please see below. > > The reason I say "in a way" is that the text above makes me > think the > > point is that ICMP error generation is delayed (which rate-limiters > > don't do) rather than skipped altogether. Is point 2) referring to > > rate-limiting or something else? > > The case I described is when rate limiting causes a delay. > Another case would be when messages are queued up and only > periodically handled, and that router's control plane is > under significant load. Even if all the conditions which you describe above are true, in most cases the packet is going to dropped before sending a ICMP message. (Eg;- DF bit set but needs to be fragment etc.,) in which case the sender SNDUNA is not going to advance since it is not going to get an ACK from the peer. This means that sender is going to see the ICMP message (assuming one is going to generated) as the first respone to the TCP segment it had sent on that particular TCP connection (forget bi-directional data for a moment). OR is the scenario which is causing a worry is that when the ACK arrived and advanced the SNDUNA, but the ICMP arrived pretty late whose sequence # did not match and hence we dropped it ( due to the recommendation of the draft), if so what is the big deal? In a nutshell, the benefits of adding robustness by dropping the suspicious ICMP messages far outwiegh the corner cases (which I am still not convinced that those are real) where we don't process an "outdated" ICMP message. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Apr 7 06:34:45 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4600E28C216; Mon, 7 Apr 2008 06:34:45 -0700 (PDT) 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 D9B373A6BC1 for ; Mon, 7 Apr 2008 06:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 K6H7zQvpD694 for ; Mon, 7 Apr 2008 06:34:39 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BEF883A6E9D for ; Mon, 7 Apr 2008 06:34:39 -0700 (PDT) Received: from [127.0.0.1] (pool-71-105-89-117.lsanca.dsl-w.verizon.net [71.105.89.117]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m37DXw8N029145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Apr 2008 06:33:59 -0700 (PDT) Message-ID: <47FA22C5.4090507@isi.edu> Date: Mon, 07 Apr 2008 06:33:57 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> <200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> <200804061042.m36AgYGx028003@venus.xmundo.net> <47F92D13.4020809@isi.edu> <47F9AF4F.4060208@isi.edu> <0C53DCFB700D144284A584F54711EC5804FA1162@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5804FA1162@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] ICMP error origination timeliness X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0448182308==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0448182308== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA15411CA7EB935A6514B9F4C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA15411CA7EB935A6514B9F4C Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: =2E.. > In a nutshell, the benefits of adding robustness by dropping the > suspicious ICMP messages far outwiegh the corner cases (which I am stil= l > not convinced that those are real) where we don't process an "outdated"= > ICMP message. The bulk of the benefits of robustness are afforded by having ICMPs=20 depend on the state and progress of the connection. We have got to get away from this notion, BTW, that 'unexpected messages = imply an attack'. The only thing such messages indicate is the inability = of the programmer to see a valid corner case. Joe --------------enigA15411CA7EB935A6514B9F4C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+iLGE5f5cImnZrsRAjkzAKCAyY7vaSIbzDBfn8bRCMBkq6jEjgCgldnG 0+5gBgScvpbt0Nq9+xsMDEs= =fj12 -----END PGP SIGNATURE----- --------------enigA15411CA7EB935A6514B9F4C-- --===============0448182308== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0448182308==-- From tcpm-bounces@ietf.org Mon Apr 7 08:17:40 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6720E3A683A; Mon, 7 Apr 2008 08:17:40 -0700 (PDT) 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 7328A3A6AC3 for ; Mon, 7 Apr 2008 08:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=0.610, BAYES_00=-2.599, 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 rCdm6dT8JY59 for ; Mon, 7 Apr 2008 08:17:38 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 3FBA93A683A for ; Mon, 7 Apr 2008 08:17:37 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 2B7345A8B34; Mon, 7 Apr 2008 12:17:51 -0300 (ART) Received: from notebook.gont.com.ar (201-254-42-144.speedy.com.ar [201.254.42.144] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m37FHcq4022232; Mon, 7 Apr 2008 12:17:39 -0300 Message-Id: <200804071517.m37FHcq4022232@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 07 Apr 2008 12:14:36 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <47F9AB92.80405@isi.edu> References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> <200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> <200804061042.m36AgYGx028003@venus.xmundo.net> <47F92D13.4020809@isi.edu> <200804062241.m36MfGKx010325@venus.xmundo.net> <47F9AB92.80405@isi.edu> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 07 Apr 2008 12:17:50 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 02:05 a.m. 07/04/2008, Joe Touch wrote: >>The TCP SEQ check would help a bit in those scenarios in which an >>attacker might be able to spoof an ICMP error message, and cause >>the connection to be stuck for a little while (e.g., by means of >>causing congestion). That is, it would require more packets on the >>side of the attacker. > >In those cases, I still see the contents of the ICMP to be moot >(w.r.t. window). That info is useful only if: > - ICMPs are known to be returned in a timely fashion > (and there's no way of knowing) If anything, isn't this the case for any type of packet? After all, any packet can get queued in a router or be delayed whilie transiting a link.... > OR > - there's some way to differentiate between legitimate > ICMPs and attack ICMPs > >Since neither is the case, this is a moot issue. I do not agree that >checking the TCP SEQ in the content of an ICMP is ever appropriate. Well, I do know that you don't like the idea, but the systems I know of will not consider a packet legitimate unless there's enough reason for that. For ICMPs, the bar for that is the SEQ contained in the payload. That's what everybody has been doing for quite some time. >>However, if TCP waits for USER_TIMEOUT to check whether the >>connection is making forward progress, then this is basically the >>"hard errors should be considered to indicate soft errors when >>received for connections in any of the synchronized states" >>behavior, and thus an attacker could not exploit the so-called ICMP >>hard errors to perform reset attacks. > >Waiting that long defeats the purpose of the errors - to terminate >connections more rapidly than TCP would otherwise. That is, IMO, too far. Well, that's just a matter of policy. In any case, Clark's RFC on "Fault Isolation and Recovery" and even "The Design of the DARPA..." seem to support this idea: data transfers should work when there is at least a working path to do the transfer. As I have seen you have mentioned a number of times, TCP is not supposed to be optimized for any scenario (e.g., multi-path scenarios). So if there's a working path, I think that for robustness sake the connection should not be aborted. In any case, I don't think we'd even have to stick to any particular timeout. Particularly, given that we can accommodate existing implementations (hard errors -> soft errors) as a degenerate case of the above. >>(i.e., the "hard errors should be considered to indicate soft >>errors when received for connections in any of the synchronized >>states" becomes a degenerate case of the "checking for progress on >>the TCP connection" when TCP waits for USER_TIMEOUT seconds before >>concluding whether the connection is making progress or not). >>(FWIW, the TCP SEQ is of a little bit more of help for PMTUD, as >>during what I called 'Initial Path-MTU Discovery', you probably >>don't want to wait, so that you get a good convergence time for the PMTUD). > >I'd have to think further to see if this appropriate - i.e., if done >only once during a connection, before a wrap, then the SEQ might be >appropriate to check, but only within that period. Most of all, the check is needed once at the beginning of the connection. Then, it might be nice to do it after the 10-minute PMTUD timeout when you want to discover the PMTU again. Although at that point (t>10 minutes) it wouldn't be much of a problem to just check for progress on the connection (what's most important is to avoid delays at he beginning of the connection, as that would hurt interactive applications) 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Apr 7 08:40:32 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6195C3A698B; Mon, 7 Apr 2008 08:40:32 -0700 (PDT) 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 E48AC3A6865 for ; Mon, 7 Apr 2008 08:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 82tBUHx6BVXR for ; Mon, 7 Apr 2008 08:40:28 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C1EFE3A6B72 for ; Mon, 7 Apr 2008 08:40:28 -0700 (PDT) Received: from [127.0.0.1] (pool-71-105-89-117.lsanca.dsl-w.verizon.net [71.105.89.117]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m37FeDJ1019853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Apr 2008 08:40:14 -0700 (PDT) Message-ID: <47FA4057.7050206@isi.edu> Date: Mon, 07 Apr 2008 08:40:07 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Fernando Gont References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> <200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> <200804061042.m36AgYGx028003@venus.xmundo.net> <47F92D13.4020809@isi.edu> <200804062241.m36MfGKx010325@venus.xmundo.net> <47F9AB92.80405@isi.edu> <200804071517.m37FHcq4022232@venus.xmundo.net> In-Reply-To: <200804071517.m37FHcq4022232@venus.xmundo.net> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1068714204==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1068714204== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig14EDE623E467F7AD487567D1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig14EDE623E467F7AD487567D1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 02:05 a.m. 07/04/2008, Joe Touch wrote: >=20 >>> The TCP SEQ check would help a bit in those scenarios in which an=20 >>> attacker might be able to spoof an ICMP error message, and cause the = >>> connection to be stuck for a little while (e.g., by means of causing = >>> congestion). That is, it would require more packets on the side of=20 >>> the attacker. >> >> In those cases, I still see the contents of the ICMP to be moot=20 >> (w.r.t. window). That info is useful only if: >> - ICMPs are known to be returned in a timely fashion >> (and there's no way of knowing) >=20 > If anything, isn't this the case for any type of packet? After all, any= =20 > packet can get queued in a router or be delayed whilie transiting a=20 > link.... Routers are supposed to forward packets in a timely fashion, but are=20 encouraged to delay control plane event processing when loaded - both=20 are in RFC 1812. I.e., for forwarding this is required, but for ICMP the contrary us=20 allowed and encouraged if needed. >> OR >> - there's some way to differentiate between legitimate >> ICMPs and attack ICMPs >> >> Since neither is the case, this is a moot issue. I do not agree that=20 >> checking the TCP SEQ in the content of an ICMP is ever appropriate. >=20 > Well, I do know that you don't like the idea, but the systems I know of= =20 > will not consider a packet legitimate unless there's enough reason for = > that. For ICMPs, the bar for that is the SEQ contained in the payload. = > That's what everybody has been doing for quite some time. Again, known implementation bugs aren't the issue - and since seq=20 checking isn't required, dropping packets due to that check qualifies=20 IMO as an implementation bug. But this is still somewhat off topic if there's a way to get 95% of the=20 way there without doing a seq check, which is what I'm suggesting. That=20 would correct the *intent* of the current code without *needing to=20 change the current specs* (which is the only way to *require* timely ICMP= s). >>> However, if TCP waits for USER_TIMEOUT to check whether the=20 >>> connection is making forward progress, then this is basically the=20 >>> "hard errors should be considered to indicate soft errors when=20 >>> received for connections in any of the synchronized states" behavior,= =20 >>> and thus an attacker could not exploit the so-called ICMP hard errors= =20 >>> to perform reset attacks. >> >> Waiting that long defeats the purpose of the errors - to terminate=20 >> connections more rapidly than TCP would otherwise. That is, IMO, too f= ar. > > Well, that's just a matter of policy. In any case, Clark's RFC on "Faul= t=20 > Isolation and Recovery" and even "The Design of the DARPA..." seem to=20 > support this idea: data transfers should work when there is at least a = > working path to do the transfer. > As I have seen you have mentioned a number of times, TCP is not suppose= d=20 > to be optimized for any scenario (e.g., multi-path scenarios). So if=20 > there's a working path, I think that for robustness sake the connection= =20 > should not be aborted. Robustness also allows signalled connection faults to recover quickly,=20 rather than on the same timescale as a 'no message' timeout. Yes,=20 though, the devil is in the detail of what that timeout would be. > In any case, I don't think we'd even have to stick to any particular=20 > timeout. Particularly, given that we can accommodate existing=20 > implementations (hard errors -> soft errors) as a degenerate case of th= e=20 > above. That's assuming the worst timeout, IMO, which is a particular timeout=20 value I disagree with. >>> (i.e., the "hard errors should be considered to indicate soft errors = >>> when received for connections in any of the synchronized states"=20 >>> becomes a degenerate case of the "checking for progress on the TCP=20 >>> connection" when TCP waits for USER_TIMEOUT seconds before concluding= =20 >>> whether the connection is making progress or not). >>> (FWIW, the TCP SEQ is of a little bit more of help for PMTUD, as=20 >>> during what I called 'Initial Path-MTU Discovery', you probably don't= =20 >>> want to wait, so that you get a good convergence time for the PMTUD).= >> >> I'd have to think further to see if this appropriate - i.e., if done=20 >> only once during a connection, before a wrap, then the SEQ might be=20 >> appropriate to check, but only within that period. >=20 > Most of all, the check is needed once at the beginning of the connectio= n. > Then, it might be nice to do it after the 10-minute PMTUD timeout when = > you want to discover the PMTU again. Although at that point (t>10=20 > minutes) it wouldn't be much of a problem to just check for progress on= =20 > the connection (what's most important is to avoid delays at he beginnin= g=20 > of the connection, as that would hurt interactive applications) The first one can easily have a seq num check, since the connection=20 isn't open long enough for a legitimate delay. However, the subesquent=20 ones don't seem to have that luxury, IMO. Joe --------------enig14EDE623E467F7AD487567D1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+kBdE5f5cImnZrsRAnv7AJ9p0QBSzR+o9JErtdPL+B5X4NwDEgCgsNsX SSgXVHDudPHccdDkalmzbxk= =9LGF -----END PGP SIGNATURE----- --------------enig14EDE623E467F7AD487567D1-- --===============1068714204== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1068714204==-- From tcpm-bounces@ietf.org Mon Apr 7 11:09:22 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B435F28C164; Mon, 7 Apr 2008 11:09:22 -0700 (PDT) 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 3A7403A6AF1 for ; Mon, 7 Apr 2008 07:01:04 -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 xmO1avNR5JBR for ; Mon, 7 Apr 2008 07:01:03 -0700 (PDT) Received: from banyan.nuim.ie (banyan.nuim.ie [149.157.1.4]) by core3.amsl.com (Postfix) with ESMTP id 4F59D28C3EF for ; Mon, 7 Apr 2008 07:00:50 -0700 (PDT) MIME-version: 1.0 Received: from [192.168.0.5] ([212.2.174.234]) by mango.nuim.ie (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTPSA id <0JYY00NAVK9Q4LB0@mango.nuim.ie> for tcpm@ietf.org; Mon, 07 Apr 2008 15:01:03 +0100 (IST) References: <1207573117.3691.254.camel@pc105-c703.uibk.ac.at> Message-id: <4A80F3F0-2B06-4262-9FE8-FE92AB5C40F3@nuim.ie> From: Douglas Leith Date: Mon, 07 Apr 2008 15:02:57 +0100 To: tcpm@ietf.org X-Mailer: Apple Mail (2.753) X-Mailman-Approved-At: Mon, 07 Apr 2008 11:09:21 -0700 Cc: iccrg Subject: [tcpm] updated h-tcp ID X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I've posted an updated version of the h-tcp internet draft at http:// www.ietf.org/internet-drafts/draft-leith-tcp-htcp-06.txt. The ID is changed to be more streamlined (general discussion removed etc) and so that the language conforms to RCF2119. Comments welcome. Although this ID predates the formation of the ICCRG and was originally submitted direct to TCPM for consideration as a work item and experimental RFC, the new process for moving things on is now via ICCRG review and so I'd like to ask the TCPM chairs to request consideration of the ID by ICCRG (as per the process here: http://www3.tools.ietf.org/group/irtf/trac/wiki/ ICCRG) Doug >> _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Apr 7 11:34:48 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9A7A28C32D; Mon, 7 Apr 2008 11:34:48 -0700 (PDT) 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 34AA328C302 for ; Mon, 7 Apr 2008 11:34: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=[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 2AQWAlKqQ6iN for ; Mon, 7 Apr 2008 11:34:47 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 2BA5828C2C9 for ; Mon, 7 Apr 2008 11:34:47 -0700 (PDT) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m37IY09h004604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Apr 2008 11:34:01 -0700 (PDT) Received: (from faber@localhost) by zod.isi.edu (8.14.2/8.14.2/Submit) id m37IY0vK036075; Mon, 7 Apr 2008 11:34:00 -0700 (PDT) (envelope-from faber) Date: Mon, 7 Apr 2008 11:34:00 -0700 From: Ted Faber To: Joe Touch Message-ID: <20080407183359.GB68982@zod.isi.edu> References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> Mime-Version: 1.0 In-Reply-To: <47F68DC7.2050303@isi.edu> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0952710080==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0952710080== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5I6of5zJg18YgZEa" Content-Disposition: inline --5I6of5zJg18YgZEa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 04, 2008 at 01:21:27PM -0700, Joe Touch wrote: >=20 >=20 > Fernando Gont wrote: > >At 04:55 p.m. 04/04/2008, Joe Touch wrote: > > > >>>The first one is the ICMP attacks draft=20 > >>>(draft-ietf-tcpm-icmp-attacks). While tcpsecure mentions the security= =20 > >>>implications of ICMP on TCP conenctions, it does not reference the=20 > >>>I-D. IIRC, this had already been pointed out by Joe (?). As far as=20 > >>>the specifications are concerned, you shouldn't bother to fix=20 > >>>TCP-based reset attacks if you don't fix the the ICMP-based ones. > >> > >>Agreed; should this doc recommend filtering out ICMPs as a result?=20 > >>(there's no in-window checks that are meaningful, since ICMPs are not= =20 > >>guaranteed to be timely) I.e., something stronger than "there's=20 > >>nothing we can do", which is what is implied in the current security=20 > >>considerations. > > > >Ha... So we have been arguing about the ICMP stuff for almost four years= =20 > >on the idea that it is too aggressive to require ICMP error messages to= =20 > >be in-window, and now we're going to propose to filter them out?=20 >=20 > ICMPs are already filtered out for security reasons at firewalls. The=20 > key here is whether to recommend that action or not. And, IMHO, hat off, we're not. Not here anyway. This document has generated enough controversy on its own. Hitching it to another controversial document guarantees even slower progress. Point off to the other documents that discuss the ICMP problem and move on. Yes there's a huge hole that someone's network architect needs to plug, but the purpose of this document is not to be that architect; the purpose of this document is to specify a standard protocol extension to address the problem of off-path TCP control message spoofing. Pointing off to documents that discuss other problems in detail is helpful and useful. IMHO. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --5I6of5zJg18YgZEa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkf6aRcACgkQaUz3f+Zf+XsbYACeK4LzLogDtV2KALD1dRbt6u0Z JVcAnjkIgT83vuCF+rEidK35/RArORcJ =6KEz -----END PGP SIGNATURE----- --5I6of5zJg18YgZEa-- --===============0952710080== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0952710080==-- From tcpm-bounces@ietf.org Mon Apr 7 11:43:45 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F65B28C1D6; Mon, 7 Apr 2008 11:43:45 -0700 (PDT) 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 895183A6C79 for ; Mon, 7 Apr 2008 11:43:43 -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 xJBthvDDWRyD for ; Mon, 7 Apr 2008 11:43:42 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id D3EC23A6D43 for ; Mon, 7 Apr 2008 11:43:42 -0700 (PDT) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m37IhOrE007940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Apr 2008 11:43:25 -0700 (PDT) Received: (from faber@localhost) by zod.isi.edu (8.14.2/8.14.2/Submit) id m37IhOSd036613; Mon, 7 Apr 2008 11:43:24 -0700 (PDT) (envelope-from faber) Date: Mon, 7 Apr 2008 11:43:24 -0700 From: Ted Faber To: Mark Allman Message-ID: <20080407184324.GC68982@zod.isi.edu> References: <20080403184929.7D08147605F@lawyers.icir.org> Mime-Version: 1.0 In-Reply-To: <20080403184929.7D08147605F@lawyers.icir.org> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] minutes from Philly X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2049064521==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============2049064521== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RIYY1s2vRbPFwWeW" Content-Disposition: inline --RIYY1s2vRbPFwWeW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 03, 2008 at 02:49:29PM -0400, Mark Allman wrote: > =20 > Folks- >=20 > Attached are a first cut at minutes from the TCPM meeting in > Philadelphia. Please let us know if there are corrections. Also, there > is a "???" where there should be a name in the authentication option > discussion. If that person could raise their hand, it'd be great. These are uploaded as the temporary minutes for TCPM. They'll finalize on 11 Apr 2008. If you have changes, get them to us before that. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --RIYY1s2vRbPFwWeW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkf6a0wACgkQaUz3f+Zf+Xt2rgCfd9T1DPkuPmkO2FFZ3R89biyG AtYAn1aqpb9wA0t6f1n1V6Xwi6H8RXwM =IJ+M -----END PGP SIGNATURE----- --RIYY1s2vRbPFwWeW-- --===============2049064521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============2049064521==-- From tcpm-bounces@ietf.org Mon Apr 7 13:31:51 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D3F3A6E0A; Mon, 7 Apr 2008 13:31:51 -0700 (PDT) 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 BEDB63A6C6E for ; Mon, 7 Apr 2008 13:31: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=[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 kgrwzIDG9Euo for ; Mon, 7 Apr 2008 13:31:48 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BD9EF28C37A for ; Mon, 7 Apr 2008 13:31:48 -0700 (PDT) Received: from [127.0.0.1] (205.sub-75-215-156.myvzw.com [75.215.156.205]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m37KVTte012917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Apr 2008 13:31:31 -0700 (PDT) Message-ID: <47FA84A0.1070904@isi.edu> Date: Mon, 07 Apr 2008 13:31:28 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Ted Faber References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <20080407183359.GB68982@zod.isi.edu> In-Reply-To: <20080407183359.GB68982@zod.isi.edu> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1002844878==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1002844878== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig28F01ACB1E2488A94F6F46C9" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig28F01ACB1E2488A94F6F46C9 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Fri, Apr 04, 2008 at 01:21:27PM -0700, Joe Touch wrote: >> >> Fernando Gont wrote: >>> At 04:55 p.m. 04/04/2008, Joe Touch wrote: >>> >>>>> The first one is the ICMP attacks draft=20 >>>>> (draft-ietf-tcpm-icmp-attacks). While tcpsecure mentions the securi= ty=20 >>>>> implications of ICMP on TCP conenctions, it does not reference the = >>>>> I-D. IIRC, this had already been pointed out by Joe (?). As far as = >>>>> the specifications are concerned, you shouldn't bother to fix=20 >>>>> TCP-based reset attacks if you don't fix the the ICMP-based ones. >>>> Agreed; should this doc recommend filtering out ICMPs as a result?=20 >>>> (there's no in-window checks that are meaningful, since ICMPs are no= t=20 >>>> guaranteed to be timely) I.e., something stronger than "there's=20 >>>> nothing we can do", which is what is implied in the current security= =20 >>>> considerations. >>> Ha... So we have been arguing about the ICMP stuff for almost four ye= ars=20 >>> on the idea that it is too aggressive to require ICMP error messages = to=20 >>> be in-window, and now we're going to propose to filter them out?=20 >> ICMPs are already filtered out for security reasons at firewalls. The = >> key here is whether to recommend that action or not. >=20 > And, IMHO, hat off, we're not. Not here anyway. If that's the case, then what's the point of protecting TCP this way? If ICMPs aren't filtered out, then they remain a simpler attack vector,=20 and thus the protections afforded are moot. Joe --------------enig28F01ACB1E2488A94F6F46C9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+oSgE5f5cImnZrsRAp6JAKCrDazNU/XnQyXFmcqEtlOxAhFcjACaA7ZH elfi0laADYcEG31nSbitCcY= =JMy0 -----END PGP SIGNATURE----- --------------enig28F01ACB1E2488A94F6F46C9-- --===============1002844878== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1002844878==-- From tcpm-bounces@ietf.org Mon Apr 7 13:58:47 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC43928C379; Mon, 7 Apr 2008 13:58:47 -0700 (PDT) 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 925D03A6D86 for ; Mon, 7 Apr 2008 13:58:46 -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 h-M-ho00wmpL for ; Mon, 7 Apr 2008 13:58:45 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 6E96D3A6B94 for ; Mon, 7 Apr 2008 13:58:45 -0700 (PDT) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m37KvBgP005245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Apr 2008 13:57:12 -0700 (PDT) Received: (from faber@localhost) by zod.isi.edu (8.14.2/8.14.2/Submit) id m37KvBtw042575; Mon, 7 Apr 2008 13:57:11 -0700 (PDT) (envelope-from faber) Date: Mon, 7 Apr 2008 13:57:11 -0700 From: Ted Faber To: Joe Touch Message-ID: <20080407205711.GF68982@zod.isi.edu> References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <20080407183359.GB68982@zod.isi.edu> <47FA84A0.1070904@isi.edu> Mime-Version: 1.0 In-Reply-To: <47FA84A0.1070904@isi.edu> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1010016966==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1010016966== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DO5DiztRLs659m5i" Content-Disposition: inline --DO5DiztRLs659m5i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 07, 2008 at 01:31:28PM -0700, Joe Touch wrote: > Ted Faber wrote: > >On Fri, Apr 04, 2008 at 01:21:27PM -0700, Joe Touch wrote: > >>ICMPs are already filtered out for security reasons at firewalls. The= =20 > >>key here is whether to recommend that action or not. > > > >And, IMHO, hat off, we're not. Not here anyway. >=20 > If that's the case, then what's the point of protecting TCP this way? >=20 > If ICMPs aren't filtered out, then they remain a simpler attack vector,= =20 > and thus the protections afforded are moot. You understand, of course, that our hypothetical network architect might read these documents in the other order - ICMP protections/ingress filtering first, then tcpsecure. In that sequence the point is closing the hole remaining after ICMP is blocked and assuming that IPSec (or however it's spelled) is ruled out. Again, the purpose of this document is to standardize a protocol extension that makes a specific attack more difficult. It is not a primer on securing TCP against all attacks - or even all spoofing attacks. It's not the job of a standards document to mandate all possible (or even all relevant) countermeasures to all related attacks. This document needs to point to the ICMP document - perhaps strongly - but needn't RECOMMEND, in a 2119 sense, anything therein. And given that this is a standards document, I don't think it should recommend them either. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --DO5DiztRLs659m5i Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkf6iqcACgkQaUz3f+Zf+XvjXgCg7/u9zfFihpa321hd6hpOz2Td ooEAoNqbTmOtzgZ3p0PfVN/6u5AB7Tdt =Gq/g -----END PGP SIGNATURE----- --DO5DiztRLs659m5i-- --===============1010016966== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1010016966==-- From tcpm-bounces@ietf.org Mon Apr 7 14:04:55 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2603A6990; Mon, 7 Apr 2008 14:04:55 -0700 (PDT) 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 C47593A6990 for ; Mon, 7 Apr 2008 14:04: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=[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 XBS6eBb7KgrC for ; Mon, 7 Apr 2008 14:04:51 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C96703A6774 for ; Mon, 7 Apr 2008 14:04:51 -0700 (PDT) Received: from [127.0.0.1] (205.sub-75-215-156.myvzw.com [75.215.156.205]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m37L2QGU023827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Apr 2008 14:02:28 -0700 (PDT) Message-ID: <47FA8BE2.3010005@isi.edu> Date: Mon, 07 Apr 2008 14:02:26 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Ted Faber References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <20080407183359.GB68982@zod.isi.edu> <47FA84A0.1070904@isi.edu> <20080407205711.GF68982@zod.isi.edu> In-Reply-To: <20080407205711.GF68982@zod.isi.edu> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1982343440==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1982343440== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCBFDD7A70E80A675388D1E6A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCBFDD7A70E80A675388D1E6A Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Mon, Apr 07, 2008 at 01:31:28PM -0700, Joe Touch wrote: >> Ted Faber wrote: >>> On Fri, Apr 04, 2008 at 01:21:27PM -0700, Joe Touch wrote: >>>> ICMPs are already filtered out for security reasons at firewalls. Th= e=20 >>>> key here is whether to recommend that action or not. >>> And, IMHO, hat off, we're not. Not here anyway. >> If that's the case, then what's the point of protecting TCP this way? >> >> If ICMPs aren't filtered out, then they remain a simpler attack vector= ,=20 >> and thus the protections afforded are moot. >=20 > You understand, of course, that our hypothetical network architect migh= t > read these documents in the other order - ICMP protections/ingress > filtering first, then tcpsecure. In that sequence the point is closin= g > the hole remaining after ICMP is blocked and assuming that IPSec (or > however it's spelled) is ruled out. >=20 > Again, the purpose of this document is to standardize a protocol > extension that makes a specific attack more difficult. It is not a > primer on securing TCP against all attacks - or even all spoofing > attacks. It's not the job of a standards document to mandate all > possible (or even all relevant) countermeasures to all related attacks.= > This document needs to point to the ICMP document - perhaps strongly - > but needn't RECOMMEND, in a 2119 sense, anything therein. And given th= at > this is a standards document, I don't think it should recommend them > either. Fair enough. It can warn - in the security considerations - that these=20 protections assume corresponding protections on ICMPs, however. I.e., it = would be incorrect to recommend, but it can warn that "without=20 corresponding ICMPs, this document may not provide the desired protection= " Joe --------------enigCBFDD7A70E80A675388D1E6A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+oviE5f5cImnZrsRAm2BAJ0b+z6BujhKQtLQcOvYspWDeZGH4ACghpyZ 8LvDaG/QnH8KBXqkpR/y7QI= =X1Wi -----END PGP SIGNATURE----- --------------enigCBFDD7A70E80A675388D1E6A-- --===============1982343440== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1982343440==-- From tcpm-bounces@ietf.org Mon Apr 7 14:25:28 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35EBE3A6BCE; Mon, 7 Apr 2008 14:25:28 -0700 (PDT) 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 1C3FB3A6DE4 for ; Mon, 7 Apr 2008 14:25:26 -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 bkSu5D9dhNBp for ; Mon, 7 Apr 2008 14:25:25 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id BF12C28C271 for ; Mon, 7 Apr 2008 14:25:08 -0700 (PDT) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m37LO0gR016271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Apr 2008 14:24:01 -0700 (PDT) Received: (from faber@localhost) by zod.isi.edu (8.14.2/8.14.2/Submit) id m37LO07T073274; Mon, 7 Apr 2008 14:24:00 -0700 (PDT) (envelope-from faber) Date: Mon, 7 Apr 2008 14:24:00 -0700 From: Ted Faber To: Joe Touch Message-ID: <20080407212400.GB20562@zod.isi.edu> References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <20080407183359.GB68982@zod.isi.edu> <47FA84A0.1070904@isi.edu> <20080407205711.GF68982@zod.isi.edu> <47FA8BE2.3010005@isi.edu> Mime-Version: 1.0 In-Reply-To: <47FA8BE2.3010005@isi.edu> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1257944453==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1257944453== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E/DnYTRukya0zdZ1" Content-Disposition: inline --E/DnYTRukya0zdZ1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 07, 2008 at 02:02:26PM -0700, Joe Touch wrote: > Fair enough. It can warn - in the security considerations - that these=20 > protections assume corresponding protections on ICMPs, however. I.e., it= =20 > would be incorrect to recommend, but it can warn that "without=20 > corresponding ICMPs, this document may not provide the desired protection" I think the quoted text, including a citation to an appropriate document, would be an excellent addition to the security concerns section of this document. That's speaking as an individual. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --E/DnYTRukya0zdZ1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkf6kPAACgkQaUz3f+Zf+XuhMgCg1D2mhHPLvOeaRMD0zIZAnNcU qcwAnjgpr8NJurxow7x7+sXt1VFpjPm/ =9BNX -----END PGP SIGNATURE----- --E/DnYTRukya0zdZ1-- --===============1257944453== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1257944453==-- From tcpm-bounces@ietf.org Mon Apr 7 18:46:39 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5281928C17E; Mon, 7 Apr 2008 18:46:39 -0700 (PDT) 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 1551428C1EA for ; Mon, 7 Apr 2008 18:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GAVhpC7-NbS for ; Mon, 7 Apr 2008 18:46:37 -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 BDC023A6C42 for ; Mon, 7 Apr 2008 18:46:36 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 07 Apr 2008 18:46:51 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m381kpmi015122; Mon, 7 Apr 2008 18:46:51 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m381kpFx029918; Tue, 8 Apr 2008 01:46:51 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 18:46:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 18:45:53 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804FA160F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20080407212400.GB20562@zod.isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Some comments on tcpsecure Thread-Index: AciY9fYJsY6v0DOlS86EAGZMH/X1YwAIdzFw References: <200804041832.m34IWTC5025090@venus.xmundo.net><47F68794.6050100@isi.edu><200804042012.m34KCk8U022643@venus.xmundo.net><47F68DC7.2050303@isi.edu> <20080407183359.GB68982@zod.isi.edu><47FA84A0.1070904@isi.edu> <20080407205711.GF68982@zod.isi.edu><47FA8BE2.3010005@isi.edu> <20080407212400.GB20562@zod.isi.edu> From: "Anantha Ramaiah (ananth)" To: "Ted Faber" , "Joe Touch" X-OriginalArrivalTime: 08 Apr 2008 01:46:25.0664 (UTC) FILETIME=[5B194000:01C8991A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1781; t=1207619211; x=1208483211; 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]=20Some=20comments=20on=20tcpsecu re |Sender:=20; bh=C8ZmgR0lcSB/aNob700fIFSB7RgC226nrKwcgA11YEI=; b=qEp9FPaVKxczoeNSkAecb2hrMZbUy4KlrPQshndpXc9qqho96d/bFykXPi yaCHzD5sofklZ85bhnKvo/FabzmKjixqni9pmKzSwaWXgptLI7gUCoZB5U8q gt6N52Ji5rzKgk8MClqAaOEnhaGRqtDL+gkpCzfK0qrtMiZZXaMf0=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Ted, > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Ted Faber > Sent: Monday, April 07, 2008 2:24 PM > To: Joe Touch > Cc: tcpm@ietf.org; Fernando Gont > Subject: Re: [tcpm] Some comments on tcpsecure > > On Mon, Apr 07, 2008 at 02:02:26PM -0700, Joe Touch wrote: > > Fair enough. It can warn - in the security considerations - > that these > > protections assume corresponding protections on ICMPs, > however. I.e., > > it would be incorrect to recommend, but it can warn that "without > > corresponding ICMPs, this document may not provide the > desired protection" > > I think the quoted text, including a citation to an > appropriate document, would be an excellent addition to the > security concerns section of this document. That's speaking > as an individual. Like it has been pointed out above, it would be incorrect to make any recommendation about ICMP or any other form of attack vectors in the tcpsecure doc since this document is not meant to be a repository of all currently known ( and going to be discovered in the near future ;-) attacks on TCP. So, IMO the verbiage needs to be chosen carefully if the consensus is to provide a pointer to the ICMP doc in the security consideration section. I would like to simply put an informative note telling "spoofed ICMP packets may also result in TCP connection stability issues, and this is discussed in more depth in......." or something of that sort. $0.02, -Anantha > > -- > Ted Faber > http://www.isi.edu/~faber PGP: > http://www.isi.edu/~faber/pubkeys.asc > Unexpected attachment on this mail? See > http://www.isi.edu/~faber/FAQ.html#SIG > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Apr 7 18:59:35 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C01028C1D1; Mon, 7 Apr 2008 18:59:35 -0700 (PDT) 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 0137F3A68EE for ; Mon, 7 Apr 2008 18:59:34 -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 qpDig3Zf28nD for ; Mon, 7 Apr 2008 18:59:33 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 30F583A683E for ; Mon, 7 Apr 2008 18:59:33 -0700 (PDT) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m381wUON026857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Apr 2008 18:58:31 -0700 (PDT) Received: (from faber@localhost) by zod.isi.edu (8.14.2/8.14.2/Submit) id m381wUSL094426; Mon, 7 Apr 2008 18:58:30 -0700 (PDT) (envelope-from faber) Date: Mon, 7 Apr 2008 18:58:30 -0700 From: Ted Faber To: "Anantha Ramaiah (ananth)" Message-ID: <20080408015830.GA94097@zod.isi.edu> References: <20080407212400.GB20562@zod.isi.edu> <0C53DCFB700D144284A584F54711EC5804FA160F@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <0C53DCFB700D144284A584F54711EC5804FA160F@xmb-sjc-21c.amer.cisco.com> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu Cc: tcpm@ietf.org, Fernando Gont , Joe Touch Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2118082790==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============2118082790== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 07, 2008 at 06:45:53PM -0700, Anantha Ramaiah (ananth) wrote: > Ted,=20 >=20 > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > > Behalf Of Ted Faber > > Sent: Monday, April 07, 2008 2:24 PM > > To: Joe Touch > > Cc: tcpm@ietf.org; Fernando Gont > > Subject: Re: [tcpm] Some comments on tcpsecure > >=20 > > On Mon, Apr 07, 2008 at 02:02:26PM -0700, Joe Touch wrote: > > > Fair enough. It can warn - in the security considerations -=20 > > that these=20 > > > protections assume corresponding protections on ICMPs,=20 > > however. I.e.,=20 > > > it would be incorrect to recommend, but it can warn that "without=20 > > > corresponding ICMPs, this document may not provide the=20 > > desired protection" > >=20 > > I think the quoted text, including a citation to an=20 > > appropriate document, would be an excellent addition to the=20 > > security concerns section of this document. That's speaking=20 > > as an individual. >=20 > Like it has been pointed out above, it would be incorrect to make any > recommendation about ICMP or any other form of attack vectors in the > tcpsecure doc since this document is not meant to be a repository of all > currently known ( and going to be discovered in the near future ;-) > attacks on TCP. So, IMO the verbiage needs to be chosen carefully if the > consensus is to provide a pointer to the ICMP doc in the security > consideration section. I would like to simply put an informative note > telling "spoofed ICMP packets may also result in TCP connection > stability issues, and this is discussed in more depth in......." or > something of that sort.=20 I'm not writing the document, but Joe's words [lightly edited] look good to me: "Unless implementors address spoofed ICMP messages[], the mitigations specified in this document may not provide the desired protection." Write what you want, but that seems to be exactly what needs to be said, and cut and paste is easy. I have no attachment to those particular words, but capture the thoughts because I'd rather not have this discussion again. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkf60UYACgkQaUz3f+Zf+XuD7wCfXuiJyJsarh07C+kTl1f9c8jg 218An2z2Z4y1oblu8D2bJ1T4L0jWpu5f =72bh -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- --===============2118082790== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============2118082790==-- From tcpm-bounces@ietf.org Tue Apr 8 12:12:34 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C082E28C159; Tue, 8 Apr 2008 12:12:34 -0700 (PDT) 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 9D6CC3A6B17 for ; Tue, 8 Apr 2008 12:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, 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 dzYu1NiP6r2S for ; Tue, 8 Apr 2008 12:12:28 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 05BF93A6820 for ; Tue, 8 Apr 2008 12:12:25 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id F1CF95A8DC3; Tue, 8 Apr 2008 16:12:41 -0300 (ART) Received: from notebook.gont.com.ar (201-254-61-175.speedy.com.ar [201.254.61.175] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m38JCQAM008441; Tue, 8 Apr 2008 16:12:27 -0300 Message-Id: <200804081912.m38JCQAM008441@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 08 Apr 2008 16:03:56 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <47FA4057.7050206@isi.edu> References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> <200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> <200804061042.m36AgYGx028003@venus.xmundo.net> <47F92D13.4020809@isi.edu> <200804062241.m36MfGKx010325@venus.xmundo.net> <47F9AB92.80405@isi.edu> <200804071517.m37FHcq4022232@venus.xmundo.net> <47FA4057.7050206@isi.edu> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 08 Apr 2008 16:12:38 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 12:40 p.m. 07/04/2008, Joe Touch wrote: >>>In those cases, I still see the contents of the ICMP to be moot >>>(w.r.t. window). That info is useful only if: >>> - ICMPs are known to be returned in a timely fashion >>> (and there's no way of knowing) >>If anything, isn't this the case for any type of packet? After all, >>any packet can get queued in a router or be delayed whilie >>transiting a link.... > >Routers are supposed to forward packets in a timely fashion, but are >encouraged to delay control plane event processing when loaded - >both are in RFC 1812. > >I.e., for forwarding this is required, but for ICMP the contrary us >allowed and encouraged if needed. I'd bet that it is more likely that packets get delayed longer for congestion probems or while transiting a link (e.g., a satellite link) than for that of delaying control plane event processing when loaded. >>>Since neither is the case, this is a moot issue. I do not agree >>>that checking the TCP SEQ in the content of an ICMP is ever appropriate. >>Well, I do know that you don't like the idea, but the systems I >>know of will not consider a packet legitimate unless there's enough >>reason for that. For ICMPs, the bar for that is the SEQ contained >>in the payload. That's what everybody has been doing for quite some time. > >Again, known implementation bugs aren't the issue - and since seq >checking isn't required, dropping packets due to that check >qualifies IMO as an implementation bug. Well, I guess we have to agree to disagree. :-) >But this is still somewhat off topic if there's a way to get 95% of >the way there without doing a seq check, which is what I'm >suggesting. That would correct the *intent* of the current code >without *needing to change the current specs* (which is the only way >to *require* timely ICMPs). ICMP code has been for a long time (>20+ years, in some cases) to do "hard errors -> soft errors". The TCP SEQ check was originally implemented in Linux as a general validation check. Then applied in virtually all stacks for the same reason. The TCP SEQ check is particularly useful as a mitigation against PMTUD attacks... and some have seen as something quicker/easier to implement than the mechanism proposed in my draft (although FWIW, I implemented the mechanism myself for OpenBSD, and it wasn't what pne would call "complex" at all...) >>>>However, if TCP waits for USER_TIMEOUT to check whether the >>>>connection is making forward progress, then this is basically the >>>>"hard errors should be considered to indicate soft errors when >>>>received for connections in any of the synchronized states" >>>>behavior, and thus an attacker could not exploit the so-called >>>>ICMP hard errors to perform reset attacks. >>> >>>Waiting that long defeats the purpose of the errors - to terminate >>>connections more rapidly than TCP would otherwise. That is, IMO, too far. >> >>Well, that's just a matter of policy. In any case, Clark's RFC on >>"Fault Isolation and Recovery" and even "The Design of the >>DARPA..." seem to support this idea: data transfers should work >>when there is at least a working path to do the transfer. >>As I have seen you have mentioned a number of times, TCP is not >>supposed to be optimized for any scenario (e.g., multi-path >>scenarios). So if there's a working path, I think that for >>robustness sake the connection should not be aborted. > >Robustness also allows signalled connection faults to recover >quickly, rather than on the same timescale as a 'no message' >timeout. Yes, though, the devil is in the detail of what that timeout would be. You say it allows a connection to recover quickly, but... why would it actually recover, if you are not affecting the path that packets follow? >>In any case, I don't think we'd even have to stick to any >>particular timeout. Particularly, given that we can accommodate >>existing implementations (hard errors -> soft errors) as a >>degenerate case of the above. > >That's assuming the worst timeout, IMO, which is a particular >timeout value I disagree with. That's how the Internet has worked during the last 20+ years. BSD-derived and Mentat-derived implementations have always done this. >>>>(i.e., the "hard errors should be considered to indicate soft >>>>errors when received for connections in any of the synchronized >>>>states" becomes a degenerate case of the "checking for progress >>>>on the TCP connection" when TCP waits for USER_TIMEOUT seconds >>>>before concluding whether the connection is making progress or not). >>>>(FWIW, the TCP SEQ is of a little bit more of help for PMTUD, as >>>>during what I called 'Initial Path-MTU Discovery', you probably >>>>don't want to wait, so that you get a good convergence time for the PMTUD). >>> >>>I'd have to think further to see if this appropriate - i.e., if >>>done only once during a connection, before a wrap, then the SEQ >>>might be appropriate to check, but only within that period. >>Most of all, the check is needed once at the beginning of the connection. >>Then, it might be nice to do it after the 10-minute PMTUD timeout >>when you want to discover the PMTU again. Although at that point >>(t>10 minutes) it wouldn't be much of a problem to just check for >>progress on the connection (what's most important is to avoid >>delays at he beginning of the connection, as that would hurt >>interactive applications) > >The first one can easily have a seq num check, since the connection >isn't open long enough for a legitimate delay. However, the >subesquent ones don't seem to have that luxury, IMO. Well, that wouldn't be a big deal. After all, the delay I'm more concerned about would be the one when the connection has just been established (as it would affect interactive applications). Although one might argue that with http persistent-connections, connections could be affected by the delay made after the 10-minute PMTUD-timeout..... 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Apr 8 13:31:32 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0E628C408; Tue, 8 Apr 2008 13:31:32 -0700 (PDT) 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 E64A228C395 for ; Tue, 8 Apr 2008 13:31:30 -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 TvA5710lEBXc for ; Tue, 8 Apr 2008 13:31:29 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 09DD428C36A for ; Tue, 8 Apr 2008 13:31:26 -0700 (PDT) Received: from [127.0.0.1] (61.sub-75-215-238.myvzw.com [75.215.238.61]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m38KVLpi003147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Apr 2008 13:31:23 -0700 (PDT) Message-ID: <47FBCDD9.2090201@isi.edu> Date: Tue, 08 Apr 2008 12:56:09 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Fernando Gont References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> <200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> <200804061042.m36AgYGx028003@venus.xmundo.net> <47F92D13.4020809@isi.edu> <200804062241.m36MfGKx010325@venus.xmundo.net> <47F9AB92.80405@isi.edu> <200804071517.m37FHcq4022232@venus.xmundo.net> <47FA4057.7050206@isi.edu> <200804081912.m38JCQAM008441@venus.xmundo.net> In-Reply-To: <200804081912.m38JCQAM008441@venus.xmundo.net> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0631882371==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0631882371== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig58B0D1218AF6AAD3FD3D345F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig58B0D1218AF6AAD3FD3D345F Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: =2E.. >> But this is still somewhat off topic if there's a way to get 95% of=20 >> the way there without doing a seq check, which is what I'm suggesting.= =20 >> That would correct the *intent* of the current code without *needing=20 >> to change the current specs* (which is the only way to *require*=20 >> timely ICMPs). >=20 > ICMP code has been for a long time (>20+ years, in some cases) to do=20 > "hard errors -> soft errors". The TCP SEQ check was originally=20 > implemented in Linux as a general validation check. Then applied in=20 > virtually all stacks for the same reason. > The TCP SEQ check is particularly useful as a mitigation against PMTUD = > attacks... and some have seen as something quicker/easier to implement = > than the mechanism proposed in my draft (although FWIW, I implemented=20 > the mechanism myself for OpenBSD, and it wasn't what pne would call=20 > "complex" at all...) I'd like to see a mechanism that's sufficiently easy to implement that=20 accomplishes the intent, even if it differs from what's currently=20 deployed. That presumes we're trying to find a good solution, rather=20 than document the existing deployed solution. =2E.. >> Robustness also allows signalled connection faults to recover quickly,= =20 >> rather than on the same timescale as a 'no message' timeout. Yes,=20 >> though, the devil is in the detail of what that timeout would be. >=20 > You say it allows a connection to recover quickly, but... why would it = > actually recover, if you are not affecting the path that packets follow= ? Recovery could involve the application terminating a poor connection in=20 favor of a better alternate, e.g., to a different IP address. By=20 prolonging the agony, we're failing to indicate that the connection is=20 having a substantial problem. Joe --------------enig58B0D1218AF6AAD3FD3D345F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+83ZE5f5cImnZrsRAlisAKCBQX6Kjjirfro1Ko8aaFGLRlmPbACfW4zo ZA5rnflh2wiRlPNFEZOkC9w= =T/dV -----END PGP SIGNATURE----- --------------enig58B0D1218AF6AAD3FD3D345F-- --===============0631882371== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0631882371==-- From tcpm-bounces@ietf.org Tue Apr 8 13:39:06 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E833A6C2D; Tue, 8 Apr 2008 13:39:06 -0700 (PDT) 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 D8E7128C134 for ; Tue, 8 Apr 2008 13:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, 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 61e0LMpf56+H for ; Tue, 8 Apr 2008 13:39:04 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 9AF963A6C2D for ; Tue, 8 Apr 2008 13:39:02 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 2FD105A8DC8; Tue, 8 Apr 2008 17:39:22 -0300 (ART) Received: from notebook.gont.com.ar (201-254-61-175.speedy.com.ar [201.254.61.175] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m38KcgjB026910; Tue, 8 Apr 2008 17:38:59 -0300 Message-Id: <200804082038.m38KcgjB026910@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 08 Apr 2008 17:36:36 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <47FBCDD9.2090201@isi.edu> References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net> <47F7E2D0.8010802@isi.edu> <200804052353.m35NrdO1031661@venus.xmundo.net> <47F82129.2000603@isi.edu> <200804061042.m36AgYGx028003@venus.xmundo.net> <47F92D13.4020809@isi.edu> <200804062241.m36MfGKx010325@venus.xmundo.net> <47F9AB92.80405@isi.edu> <200804071517.m37FHcq4022232@venus.xmundo.net> <47FA4057.7050206@isi.edu> <200804081912.m38JCQAM008441@venus.xmundo.net> <47FBCDD9.2090201@isi.edu> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 08 Apr 2008 17:39:16 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 04:56 p.m. 08/04/2008, Joe Touch wrote: >>>But this is still somewhat off topic if there's a way to get 95% >>>of the way there without doing a seq check, which is what I'm >>>suggesting. That would correct the *intent* of the current code >>>without *needing to change the current specs* (which is the only >>>way to *require* timely ICMPs). >>ICMP code has been for a long time (>20+ years, in some cases) to >>do "hard errors -> soft errors". The TCP SEQ check was originally >>implemented in Linux as a general validation check. Then applied in >>virtually all stacks for the same reason. >>The TCP SEQ check is particularly useful as a mitigation against >>PMTUD attacks... and some have seen as something quicker/easier to >>implement than the mechanism proposed in my draft (although FWIW, I >>implemented the mechanism myself for OpenBSD, and it wasn't what >>pne would call "complex" at all...) > >I'd like to see a mechanism that's sufficiently easy to implement >that accomplishes the intent, even if it differs from what's >currently deployed. That presumes we're trying to find a good >solution, rather than document the existing deployed solution. As I said, I did implement the PMTUD stuff in the icmp attacks draft. It now ships with OpenBSD and NetBSD, at least. And it's really easy to implement. Regarding the mechanism you want to see (I'd say it's the same thing that's currently in the draft, except for what happens after the 10-minute timeout), it will be the subject of some future standards-track draft. This one is informational, and documents what's done. >>>Robustness also allows signalled connection faults to recover >>>quickly, rather than on the same timescale as a 'no message' >>>timeout. Yes, though, the devil is in the detail of what that timeout would be. >>You say it allows a connection to recover quickly, but... why would >>it actually recover, if you are not affecting the path that packets follow? > >Recovery could involve the application terminating a poor connection >in favor of a better alternate, e.g., to a different IP address. By >prolonging the agony, we're failing to indicate that the connection >is having a substantial problem. Well, this is even more agressive than the soft errors stuff/draft we have argued about for years. However, applications can already benefit of the soft errors behavior (what's described in the draft), but cannot currently benefit from what you propose. They only loop through the A records while trying to establish a connection... but they don't loop through them if there's an error afterwards. The only exception to this might be an MTA. 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Apr 8 15:28:47 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE6A3A6C23; Tue, 8 Apr 2008 15:28:47 -0700 (PDT) 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 540003A676A for ; Tue, 8 Apr 2008 15:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTuUE2oQSk6n for ; Tue, 8 Apr 2008 15:28:45 -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 8B4F63A6C8D for ; Tue, 8 Apr 2008 15:28:45 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2008 15:29:02 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m38MT2ca001156; Tue, 8 Apr 2008 15:29:02 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m38MT27w014827; Tue, 8 Apr 2008 22:29:02 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Apr 2008 15:29:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Apr 2008 15:28:27 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5804FA1A95@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <47FBCDD9.2090201@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Some comments on tcpsecure Thread-Index: AciZt6bWvfyQK4g3TqmDXqNXpcBYMQAC949Q References: <200804041832.m34IWTC5025090@venus.xmundo.net><47F68794.6050100@isi.edu><200804042012.m34KCk8U022643@venus.xmundo.net><47F68DC7.2050303@isi.edu><200804050557.m355vAjU013266@venus.xmundo.net><47F7B43E.6010004@isi.edu><200804052024.m35KOlmj018418@venus.xmundo.net><47F7E2D0.8010802@isi.edu><200804052353.m35NrdO1031661@venus.xmundo.net><47F82129.2000603@isi.edu><200804061042.m36AgYGx028003@venus.xmundo.net><47F92D13.4020809@isi.edu><200804062241.m36MfGKx010325@venus.xmundo.net><47F9AB92.80405@isi.edu><200804071517.m37FHcq4022232@venus.xmundo.net><47FA4057.7050206@isi.edu><200804081912.m38JCQAM008441@venus.xmundo.net> <47FBCDD9.2090201@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Fernando Gont" X-OriginalArrivalTime: 08 Apr 2008 22:29:02.0301 (UTC) FILETIME=[F25138D0:01C899C7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=611; t=1207693742; x=1208557742; c=relaxed/simple; s=sjdkim3002; 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]=20Some=20comments=20on=20tcpsecu re |Sender:=20; bh=aq1cIICSLKJ67rnKfhslxrsqigAG4sTSEU7LpXmt+5U=; b=XN+Rx3TeHk4icuigVs9s1z+1gdExUqMz1s8eGgbjBJyTXAp9MJjkN4LFWx 6av2NQhPafC9IG/yRgRDuS9mdi/ytaiUO6LW38jQQZAVGHpdAYo2RdUCT8DL /3r0C00KVe; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] Some comments on tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > > I'd like to see a mechanism that's sufficiently easy to > implement that accomplishes the intent, even if it differs > from what's currently deployed. That presumes we're trying to > find a good solution, rather than document the existing > deployed solution. IMO, there is nothing wrong in documenting the existing practices prevailing in the internet. There is no point in waiting for a "good solution" which is non-existent currently and supposed to serve as a replacement for the current undocumented but widely accepted and deployed solution. $0.02, -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Apr 10 17:45:53 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B2028C246; Thu, 10 Apr 2008 17:45:53 -0700 (PDT) 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 52B9F28C17D for ; Thu, 10 Apr 2008 17:45:52 -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 tPBeVzar840p for ; Thu, 10 Apr 2008 17:45:51 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 8357D28C480 for ; Thu, 10 Apr 2008 17:45:30 -0700 (PDT) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3B0ji4Y009300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 10 Apr 2008 17:45:45 -0700 (PDT) Received: (from faber@localhost) by zod.isi.edu (8.14.2/8.14.2/Submit) id m3B0jivA034647 for tcpm@ietf.org; Thu, 10 Apr 2008 17:45:44 -0700 (PDT) (envelope-from faber) Date: Thu, 10 Apr 2008 17:45:44 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20080411004544.GD2659@zod.isi.edu> References: <20080403184929.7D08147605F@lawyers.icir.org> <20080407184324.GC68982@zod.isi.edu> Mime-Version: 1.0 In-Reply-To: <20080407184324.GC68982@zod.isi.edu> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu Subject: Re: [tcpm] minutes from Philly X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1621662842==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1621662842== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NtwzykIc2mflq5ck" Content-Disposition: inline --NtwzykIc2mflq5ck Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 07, 2008 at 11:43:24AM -0700, Ted Faber wrote: > On Thu, Apr 03, 2008 at 02:49:29PM -0400, Mark Allman wrote: > > =20 > > Folks- > >=20 > > Attached are a first cut at minutes from the TCPM meeting in > > Philadelphia. Please let us know if there are corrections. Also, there > > is a "???" where there should be a name in the authentication option > > discussion. If that person could raise their hand, it'd be great. >=20 > These are uploaded as the temporary minutes for TCPM. They'll finalize > on 11 Apr 2008. >=20 > If you have changes, get them to us before that. April 11 is upon us. If you have changes, we need them now. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --NtwzykIc2mflq5ck Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkf+tLgACgkQaUz3f+Zf+XuhPQCfeKjfZhtbKmQ+41ouqUxuMpOI AokAoPTBG75NUm5HeQiSEzwYB4a9rcn7 =aAMG -----END PGP SIGNATURE----- --NtwzykIc2mflq5ck-- --===============1621662842== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1621662842==-- From tcpm-bounces@ietf.org Wed Apr 23 11:45:06 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099783A68EB; Wed, 23 Apr 2008 11:45:04 -0700 (PDT) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 290F53A6960; Wed, 23 Apr 2008 11:45:00 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080423184501.290F53A6960@core3.amsl.com> Date: Wed, 23 Apr 2008 11:45:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-soft-errors-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP's Reaction to Soft Errors Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-soft-errors-08.txt Pages : 16 Date : 2008-04-23 This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages, that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection establishment attempts that may arise in a number of scenarios, including one in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-08.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-soft-errors-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-23113938.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Wed Apr 30 10:45:09 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395AF28C0FA; Wed, 30 Apr 2008 10:45:09 -0700 (PDT) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B6A453A680C; Wed, 30 Apr 2008 10:45:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080430174501.B6A453A680C@core3.amsl.com> Date: Wed, 30 Apr 2008 10:45:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-rfc2581bis-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Congestion Control Author(s) : M. Allman Filename : draft-ietf-tcpm-rfc2581bis-04.txt Pages : 17 Date : 2008-4-30 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-04.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-rfc2581bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-4-30103012.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --NextPart--