From tcpm-bounces@ietf.org Mon Oct 01 08:51:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcKhh-0000U8-C5; Mon, 01 Oct 2007 08:48:53 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IcKhg-0000U3-8K for tcpm-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 08:48:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcKhf-0000Rb-TT for tcpm@ietf.org; Mon, 01 Oct 2007 08:48:51 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcKhf-0002pd-IK for tcpm@ietf.org; Mon, 01 Oct 2007 08:48:51 -0400 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 l91CmoFc014147; Mon, 1 Oct 2007 05:48:50 -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 5271E1018264; Mon, 1 Oct 2007 08:48:44 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 32E282AB9B1; Mon, 1 Oct 2007 08:47:30 -0400 (EDT) To: "Anantha Ramaiah (ananth)" From: Mark Allman Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <0C53DCFB700D144284A584F54711EC580409FCEF@xmb-sjc-21c.amer.cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Mon, 01 Oct 2007 08:47:30 -0400 Message-Id: <20071001124730.32E282AB9B1@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 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="===============1879687522==" Errors-To: tcpm-bounces@ietf.org --===============1879687522== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hyperbole elided, but still trying to understand ... > but > saying that "SHOULD doesn't give leeway not to do something", is > something which I would want to dis-agree. If tcpsecure is a SHOULD then what would be an invalid reason for me to exclude it from my implementation? allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHAOxiWyrrWs4yIs4RAuuJAKCLkwjr+4lk3wDp9MwNwwZKXaIfkQCfVE1t y1o4gdEFHskod8DZ7GxADA8= =7xPF -----END PGP SIGNATURE----- --=_bOundary-- --===============1879687522== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1879687522==-- From tcpm-bounces@ietf.org Mon Oct 01 10:19:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcM5q-0004ht-Gd; Mon, 01 Oct 2007 10:17:54 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IcM5p-0004eH-Pr for tcpm-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 10:17:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcM5p-0004aw-D1 for tcpm@ietf.org; Mon, 01 Oct 2007 10:17:53 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcM5o-0004W2-Pm for tcpm@ietf.org; Mon, 01 Oct 2007 10:17:53 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l91EHg9D010915; Mon, 1 Oct 2007 17:17:50 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 17:16:36 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 17:16:36 +0300 Received: from [172.21.39.141] ([172.21.39.141]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 17:16:35 +0300 In-Reply-To: References: <200709111615.SAA24923@TR-Sys.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4018CF28-82C9-4089-AD77-A3EA0FACB137@nokia.com> Content-Transfer-Encoding: quoted-printable From: Pasi Sarolahti Subject: Re: [tcpm] Re: draft-ietf-tcpm-rfc4138bis-00 Date: Mon, 1 Oct 2007 17:15:42 +0300 To: =?ISO-8859-1?Q?ext_Ilpo_J=E4rvinen?= X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Oct 2007 14:16:35.0340 (UTC) FILETIME=[AC7844C0:01C80435] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: =?ISO-8859-1?Q? ext_Alfred_H=CEnes ?= , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Sep 26, 2007, at 16:52, ext Ilpo J=E4rvinen wrote: >> Also, the SACK version of F-RTO has not been included in all >> implementations that have the basic version >> (for example Linux distribution has had only the basic version). > > ...That's only partially valid because since 2.6.22 Linux has included > both versions (though both off by default). Its SACK version includes > features discussed in 4138's Appendix B. =46rom 2.6.24 onward it will > enable SACK version by default. So I had outdated information. Thanks for keeping us updated! Ok, we were too hasty in removing the SACK variant from the draft. =20 The feedback so far, on and off the mailing list, seem to be in favor =20= of keeping it. We'll add it back for the next version. > Quite clearly using SACK blocks improves FRTO's accuracy in =20 > detection as > they are rather strong indication what really arrived. However, it =20 > adds > some challenges to aggressive response usage because then lying in =20 > SACK > blocks should also be addressed in Security Considerations, =20 > especially as > "because the sender will have an incorrect state, it cannot retransmit > the segment that has never reached the receiver" does not hold like it > does with SND.UNA. Yet, as long as FRTO is accompanied with a =20 > conservative > response, I don't see how the receiver could have meaningful =20 > benefits from > lying, whereas unnecessary retransmissions are more accurately =20 > mitigated. This reminds me of another issue mentioned in the Chicago meeting =20 that might deserve discussion: what should we say about the response =20 in rfc4138bis? The current draft refers to the Eifel Response and to =20 draft-allman-rto-backoff as possible response algorithms, but also =20 says that if neither of these is implemented, the TCP sender should =20 respond conservatively to spurious timeout, applying the TCP =20 congestion control specification. I wonder if people prefer more =20 definite words here about the response, or is it just enough to refer =20= to the known choices, as we now have done. What you say above seems =20 to indicate that at least with SACK we might want to prefer a =20 conservative response. - Pasi _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 01 12:25:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcO39-0001xu-8V; Mon, 01 Oct 2007 12:23:15 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IcO38-0001xp-RC for tcpm-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 12:23:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcO38-0001xh-Hb for tcpm@ietf.org; Mon, 01 Oct 2007 12:23:14 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcO37-0005D3-Aw for tcpm@ietf.org; Mon, 01 Oct 2007 12:23:14 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 01 Oct 2007 09:23:12 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l91GNCq1007261; Mon, 1 Oct 2007 09:23:12 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l91GN7vd001413; Mon, 1 Oct 2007 16:23:12 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 09:23:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Mon, 1 Oct 2007 09:23:09 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580409FF13@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20071001124730.32E282AB9B1@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgEKXDxD4AUrzV6TGqZmv6DX0P4egAFtEfw From: "Anantha Ramaiah (ananth)" To: X-OriginalArrivalTime: 01 Oct 2007 16:23:11.0069 (UTC) FILETIME=[5BE088D0:01C80447] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1650; t=1191255792; x=1192119792; 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]=20tcpsecure=3A=20how=20strong=20to=20recommend ?=20 |Sender:=20; bh=+/GJ8XuR5ISJY6v+0ZNdAB4UVVcYTg1EKG6I2Za7wq8=; b=eGgAoNS/ny4FBzHMENLuj1EC9Okacvog2b0An1+7u4pMK687WtwUnwf7MzaZ6StgSlpLDvji OjH3Xgs22x0hISlsUgG81jIQk5HBCwYdL9+h7giGBCm/3eT2JUOZHEdQ; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 >=20 > Hyperbole elided, but still trying to understand ... >=20 > > but > > saying that "SHOULD doesn't give leeway not to do something", is=20 > > something which I would want to dis-agree. >=20 > If tcpsecure is a SHOULD then what would be an invalid reason=20 > for me to exclude it from my implementation? It is difficult to say since the implementer is given the choice whether or not to include/exclude it. Yes, both SHOULD and MAY provides that luxury. The only difference is the strength of the advise offered by both these adjectives which needs to be viewed from a recommendation perspective. If you think that these are generally good to have then use SHOULD else these are really optional ones use MAY. The bottomline is that unless it is tagged as MUST, I believe we have already given the flexibility, the key is how "strong" we would want to recommend and that is what we are trying to do and get the consensus. Atleast this *my understanding*. I expressed my opinion and other have expressed theirs.=20 Also, I am trying to understand something here since I wasn't sure how situations like this have been dealt in the past. Actually, I am trying to understand the algorithm used to arrive consensus here?. I was assuming that after the "hums were sought" and the email was sent both offering 3 choices, now after getting the responses the next step would be to derive something out of that once we have reached enough responses or a stipulated time expires if one exists. If we believe there isn't even a rough consensus after the responses so far, what is the next step? Curious. -Anantha=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 01 12:35:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOEu-0008U9-Lm; Mon, 01 Oct 2007 12:35:24 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IcOEt-0008LN-KS for tcpm-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 12:35:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOEt-0008LE-7l for tcpm@ietf.org; Mon, 01 Oct 2007 12:35:23 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcOEs-00075N-SC for tcpm@ietf.org; Mon, 01 Oct 2007 12:35:23 -0400 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 l91GZLj0017989; Mon, 1 Oct 2007 09:35:21 -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 E1046101A380; Mon, 1 Oct 2007 12:35:15 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9CA472ABFBA; Mon, 1 Oct 2007 12:34:02 -0400 (EDT) To: "Anantha Ramaiah (ananth)" From: Mark Allman Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <0C53DCFB700D144284A584F54711EC580409FF13@xmb-sjc-21c.amer.cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Car Phone MIME-Version: 1.0 Date: Mon, 01 Oct 2007 12:34:02 -0400 Message-Id: <20071001163402.9CA472ABFBA@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 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="===============1460851551==" Errors-To: tcpm-bounces@ietf.org --===============1460851551== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > If we believe there isn't > even a rough consensus after the responses so far, what is the next > step? Curious. Per my previous email: It seems to me that this discussion is really divergent because there is no applicability statement in the document, per Lars' comment. I wonder if you guys could go off and generate such a statement and then we could re-visit this question. I think that would factor things into a question of "where" this is applicable and then how strongly we want to advocate these mitigations within that context. Is that reasonable? (From which my understanding was that you guys were going to generate said statement.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHASF6WyrrWs4yIs4RAvTgAJ9Kh+sWCyujBHyPGtBusEm/M6+itgCghowG C1G1ou0TXapoQ3Hu7Un/yqU= =d3ML -----END PGP SIGNATURE----- --=_bOundary-- --===============1460851551== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1460851551==-- From tcpm-bounces@ietf.org Mon Oct 01 14:22:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcPsL-0004uj-ON; Mon, 01 Oct 2007 14:20:13 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IcPsK-0004uW-Ha for tcpm-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 14:20:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcPsK-0004sP-7v for tcpm@ietf.org; Mon, 01 Oct 2007 14:20:12 -0400 Received: from smtp1.pcisys.net ([216.229.32.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcPsC-0008Tp-6b for tcpm@ietf.org; Mon, 01 Oct 2007 14:20:08 -0400 Received: from corallusannulat.ophidian.com (prof-206-53-16-219.cos.pcisys.net [206.53.16.219]) (authenticated bits=0) by smtp1.pcisys.net (8.13.6/8.13.6) with ESMTP id l91IJfss008662 for ; Mon, 1 Oct 2007 12:19:43 -0600 (MDT) Message-Id: <4.3.1.2.20071001113312.00b93e60@pop3.mailpci.net> X-Sender: ophidian-eag@pop3.mailpci.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 01 Oct 2007 12:15:31 -0600 To: tcpm@ietf.org From: "Edward A. Gardner" Subject: Re: [tcpm] tcpsecure: how strong to recommend? In-Reply-To: <20071001163402.9CA472ABFBA@lawyers.icir.org> References: <0C53DCFB700D144284A584F54711EC580409FF13@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I normally just lurk here silently, and I certainly wasn't at Chicago or any of the other meetings discussing this. But it strikes me that people are getting caught up in language problems and losing sight of what is desired. In particular there is confusion between discussing whether implementing tcpsecure itself is mandatory / recommended / optional vs. whether some feature of tcpsecure is mandatory / recommended / optional, given that tcpsecure itself is implemented. Clearly there will be implementations that do not implement tcpsecure. Historical implementations. Those that achieve similar ends through different means (e.g. IPSEC, MD5) and therefore have no need or use for tcpsecure. Clearly there are implementations that need or want tcpsecure, BGP being the prominent example. So there are two implementation variations that we consider necessary. Is there any need or point in more? Remember that compatibility problems, testing, etc. scale as (at least) NxN. There is enormous practical incentive to minimize the number of variations that are implemented and deployed. I contend that the specifications or RFCs should allow exactly two variations. Those implementations that ignore and do not implement tcpsecure at all. And those that implement all of it. I think the way to accomplish that is to include an applicability statement saying that implementing tcpsecure is optional. An implementation MAY or MAY NOT implement it. And giving guidance on when one should or should not. Probably something along the lines of saying one should implement it unless the same ends are accomplished by other means, and giving several examples of other means. But if an implementation does choose to implement tcpsecure, then it MUST implement all of it -- the features, protocol behavior, etc. are described in the RFC using MUST. Conversely, if an implementation chooses not to implement tcpsecure, then it MUST NOT implement any part of it. Either implement all of tcpsecure or none of it. Yes, this requires careful phrasing, but it can be done. I am assuming that all the features included in tcpsecure are considered necessary or desirable for BGP. If any are not, shouldn't they be excluded on the grounds that no one is ever likely to implement them? One might contemplate the impact of the IETF requirement for independently developed, interoperable implementations. The three tcpsecure (three choices of MAY vs. SHOULD that are being discussed) interact to some degree. If each are described using MAY or SHOULD, we get eight implementation variations. Each needing two independent implementations means at least sixteen implementation, which is absurd. Does anyone really want to allow some arguably ill-informed implementors to pick and choose, as opposed to saying all or none? Isn't it our responsibility as architects (who claim to know what we are doing :-) to minimize variations, not unnecessarily expand them? Caveat: my primary experience is with the T10 and T11 standards (SCSI and friends), I apologize for my errors with IETF terminology and practice. Dropping back into my hole to resume lurking. Edward A. Gardner eag at ophidian dot com Ophidian Designs 719 593-8866 1262 Hofstead Terrace Colorado Springs, CO 80907 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 01 17:57:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcTEt-0005Xw-1q; Mon, 01 Oct 2007 17:55:43 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IcTEp-0005UN-CO for tcpm-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 17:55:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcTEp-0005UF-2M for tcpm@ietf.org; Mon, 01 Oct 2007 17:55:39 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcTEi-0004Yl-Lc for tcpm@ietf.org; Mon, 01 Oct 2007 17:55:39 -0400 X-IronPort-AV: E=Sophos;i="4.21,218,1188802800"; d="scan'208";a="10976770" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 01 Oct 2007 14:55:30 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l91LtTHr014818; Mon, 1 Oct 2007 14:55:29 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l91LtPmQ008081; Mon, 1 Oct 2007 21:55:25 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 14:55:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Mon, 1 Oct 2007 14:55:24 -0700 Message-ID: <13D1EAB852BE194C94773A947138483D04245613@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4.3.1.2.20071001113312.00b93e60@pop3.mailpci.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgEWGCMHXhyXXRPQOSfylhZ5GAbHwAGtBYg From: "Mitesh Dalal (mdalal)" To: "Edward A. Gardner" , X-OriginalArrivalTime: 01 Oct 2007 21:55:25.0505 (UTC) FILETIME=[C5BA1310:01C80475] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5491; t=1191275729; x=1192139729; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mdalal@cisco.com; z=From:=20=22Mitesh=20Dalal=20(mdalal)=22=20 |Subject:=20RE=3A=20[tcpm]=20tcpsecure=3A=20how=20strong=20to=20recommend ?=20 |Sender:=20; bh=ys6Vd7FpMP2g9skARrPjlR788sqeBoMDV2bL9fIcvKM=; b=tkc6PWAicxx8BCG2RSXI4+F2JomWNZkeIIEBiu+ZcMnAgDRSsmUHuL4saRanFYekGLfu1kXD DlkmHjHeZgRtWrZFdOnB4oQUX+Xtgu7EaU5AkskV0PqVuDPubbhOPkyb; Authentication-Results: sj-dkim-4; header.From=mdalal@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org well said Edward! I concur with your take on this and was alluding to the same ideas that you mentioned below. To highlight your comment again: > In particular=20 > there is confusion between discussing whether implementing=20 > tcpsecure itself is mandatory / recommended / optional vs.=20 > whether some feature of tcpsecure is mandatory / recommended=20 > / optional, given that tcpsecure itself is implemented. I think it does captures the debate we are having here. My opinion is that if we view these changes as Updates to RFC793, then they may be perceived as mandatory changes and again open discussions around IPR, MAY/SHOULD/MUST language and so on. However if we have a banner statement stating that implementing these changes are recommended/optional and enumerate situations in which they are=20 helpful this should alleviate a lot of opposing view. And once we have this statement and if a tcp implementation does decide to have this feature then it MUST be this way for the feature to work correctly. So to reiterate to the group, we need an applicability statement that highlights the implementations/deployments/applications that are RECOMMENDED to have this fix, with others being OPTIONAL. However, the features/changes themselves being MUST (or SHOULD, if that's what it would take for a consensus). Is the group in agreement here? my 0.02 Mitesh =20 > -----Original Message----- > From: Edward A. Gardner [mailto:eag@ophidian.com]=20 > Sent: Monday, October 01, 2007 11:16 AM > To: tcpm@ietf.org > Subject: Re: [tcpm] tcpsecure: how strong to recommend?=20 >=20 > I normally just lurk here silently, and I certainly wasn't at=20 > Chicago or any of the other meetings discussing this. But it=20 > strikes me that people are getting caught up in language=20 > problems and losing sight of what is desired. In particular=20 > there is confusion between discussing whether implementing=20 > tcpsecure itself is mandatory / recommended / optional vs.=20 > whether some feature of tcpsecure is mandatory / recommended=20 > / optional, given that tcpsecure itself is implemented. >=20 > Clearly there will be implementations that do not implement=20 > tcpsecure. Historical implementations. Those that achieve=20 > similar ends through different means (e.g. IPSEC, MD5) and=20 > therefore have no need or use for tcpsecure. >=20 > Clearly there are implementations that need or want=20 > tcpsecure, BGP being the prominent example. >=20 > So there are two implementation variations that we consider=20 > necessary. Is there any need or point in more? Remember=20 > that compatibility problems, testing, etc. scale as (at=20 > least) NxN. There is enormous practical incentive to=20 > minimize the number of variations that are implemented and deployed. >=20 > I contend that the specifications or RFCs should allow=20 > exactly two variations. Those implementations that ignore=20 > and do not implement tcpsecure at all. And those that=20 > implement all of it. >=20 > I think the way to accomplish that is to include an=20 > applicability statement saying that implementing tcpsecure is=20 > optional. An implementation MAY or MAY NOT implement it. =20 > And giving guidance on when one should or should not. =20 > Probably something along the lines of saying one should=20 > implement it unless the same ends are accomplished by other=20 > means, and giving several examples of other means. >=20 > But if an implementation does choose to implement tcpsecure,=20 > then it MUST implement all of it -- the features, protocol=20 > behavior, etc. are described in the RFC using MUST. =20 > Conversely, if an implementation chooses not to implement=20 > tcpsecure, then it MUST NOT implement any part of it. Either=20 > implement all of tcpsecure or none of it. Yes, this requires=20 > careful phrasing, but it can be done. >=20 >=20 > I am assuming that all the features included in tcpsecure are=20 > considered necessary or desirable for BGP. If any are not,=20 > shouldn't they be excluded on the grounds that no one is ever=20 > likely to implement them? >=20 > One might contemplate the impact of the IETF requirement for=20 > independently developed, interoperable implementations. The=20 > three tcpsecure (three choices of MAY vs. SHOULD that are=20 > being discussed) interact to some degree. If each are=20 > described using MAY or SHOULD, we get eight implementation=20 > variations. Each needing two independent implementations=20 > means at least sixteen implementation, which is absurd. Does=20 > anyone really want to allow some arguably ill-informed=20 > implementors to pick and choose, as opposed to saying all or=20 > none? Isn't it our responsibility as architects (who claim=20 > to know what we are doing :-) to minimize variations, not=20 > unnecessarily expand them? >=20 > Caveat: my primary experience is with the T10 and T11=20 > standards (SCSI and friends), I apologize for my errors with=20 > IETF terminology and practice. >=20 > Dropping back into my hole to resume lurking. >=20 >=20 > Edward A. Gardner eag at ophidian dot com > Ophidian Designs 719 593-8866 > 1262 Hofstead Terrace > Colorado Springs, CO 80907 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 01 19:16:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcUSx-0000oV-Bv; Mon, 01 Oct 2007 19:14:19 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IcUSw-0000j4-7q for tcpm-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 19:14:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcUSv-0000f4-TG for tcpm@ietf.org; Mon, 01 Oct 2007 19:14:17 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcUSr-0008Kv-Ey for tcpm@ietf.org; Mon, 01 Oct 2007 19:14:13 -0400 Received: from [192.168.1.39] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l91NDjx4025456; Mon, 1 Oct 2007 16:13:45 -0700 (PDT) Message-ID: <47017F26.9050908@isi.edu> Date: Mon, 01 Oct 2007 16:13:42 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Mitesh Dalal (mdalal)" Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <13D1EAB852BE194C94773A947138483D04245613@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <13D1EAB852BE194C94773A947138483D04245613@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: "Edward A. Gardner" , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0522330498==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0522330498== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2052913F1E3B6C2F163EDEA8" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2052913F1E3B6C2F163EDEA8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mitesh Dalal (mdalal) wrote: > well said Edward! I concur with your take on this and was alluding to > the same ideas that you mentioned below. To highlight your comment > again: >=20 >> In particular=20 >> there is confusion between discussing whether implementing=20 >> tcpsecure itself is mandatory / recommended / optional vs.=20 >> whether some feature of tcpsecure is mandatory / recommended=20 >> / optional, given that tcpsecure itself is implemented. >=20 >=20 > I think it does captures the debate we are having here. My > opinion is that if we view these changes as Updates to RFC793, then > they may be perceived as mandatory changes and again open discussions > around IPR, MAY/SHOULD/MUST language and so on. However if we have > a banner statement stating that implementing these changes are > recommended/optional and enumerate situations in which they are=20 > helpful this should alleviate a lot of opposing view. And > once we have this statement and if a tcp implementation does decide > to have this feature then it MUST be this way for the feature to work > correctly.\ I think we agree that there are two levels of language needed: 1) for the entire system for which I think MAY is appropriate, and the conditions when useful would be beneficial to note 2) for the components, once you decide to implement MUST/MAY/SHOULDs as needed there. there seem like there are a few MAYs for various parts, MUSTs for others; it's not all MUSTs, but I don't think there will be deep discussions about this Joe --------------enig2052913F1E3B6C2F163EDEA8 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 iD8DBQFHAX8nE5f5cImnZrsRAjXQAJ9Q9ogE2Hd4nN+aC1AEufRwq/eOzACgvDj4 MDZPVo+0OlDsLAkaJfmkjO0= =RZyA -----END PGP SIGNATURE----- --------------enig2052913F1E3B6C2F163EDEA8-- --===============0522330498== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0522330498==-- From tcpm-bounces@ietf.org Tue Oct 02 02:23:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icb6s-00031q-LY; Tue, 02 Oct 2007 02:19:58 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Icb6q-0002z2-Hc for tcpm-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 02:19:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icb6q-0002yf-6S for tcpm@ietf.org; Tue, 02 Oct 2007 02:19:56 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icb6m-0000hF-7j for tcpm@ietf.org; Tue, 02 Oct 2007 02:19:53 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l926JdYI010821; Tue, 2 Oct 2007 09:19:46 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 09:19:28 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 09:19:28 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 09:19:27 +0300 Received: from [192.168.255.2] (essapo-nirac25264.europe.nokia.com [10.162.252.64]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l926JPGb013287; Tue, 2 Oct 2007 09:19:26 +0300 In-Reply-To: <0C53DCFB700D144284A584F54711EC580409FF13@xmb-sjc-21c.amer.cisco.com> References: <0C53DCFB700D144284A584F54711EC580409FF13@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <893A41DE-CAE5-4F25-90F2-1C66BDA33E77@nokia.com> From: Lars Eggert Subject: Re: [tcpm] tcpsecure: how strong to recommend? Date: Tue, 2 Oct 2007 09:19:21 +0300 To: ext Anantha Ramaiah (ananth) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Oct 2007 06:19:27.0817 (UTC) FILETIME=[2F8CAB90:01C804BC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1276677372==" Errors-To: tcpm-bounces@ietf.org --===============1276677372== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-11-397881012; protocol="application/pkcs7-signature" --Apple-Mail-11-397881012 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-10-1, at 19:23, ext Anantha Ramaiah (ananth) wrote: >> If tcpsecure is a SHOULD then what would be an invalid reason >> for me to exclude it from my implementation? > > It is difficult to say since the implementer is given the choice > whether > or not to include/exclude it. RFC2026 says: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Some in the IESG have argued that "(...) implications must be understood and carefully weighed" means that drafts needs to explicitly discuss under what conditions it is OK to disregard a SHOULD ("choosing a different course.") Obviously, few drafts do this. But because we're hung up on what to do with this particular draft, following RFC2026 more closely might help us make progress. Lars --Apple-Mail-11-397881012 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMDIwNjE5MjJaMCMGCSqGSIb3DQEJBDEWBBT3r2+cxepdgHVN iTHiO6OgYl0uxDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAodhNsGpWhjwUtPHk80ECnl+eBY2VjKNgxEYqyndDPTY2p0gr29ME pPE2u/khYUUVVhPA5BGyOjpLNoBFVXIK0HoT3kvvqCNHjZRhnORQI8lVvEDBw9YqtozaHUR2YT8P uborfD/yxZnyuxNt9Vqj37H6Psa8FulQXUDMSOShNxw/U8RyqB+XwgpWWO6p/CgUNJ0R0blh+9mB Js009lBAVvN9SFZoUxYv0YN4ADaaqTJiI5vn+yNgVCmXSMuZtx7GXiUota2KjIMpjtdcBi9HkCwq sa9mDmD2gWtf8G11jJHf3L2HtsbqGsY0xxTE9ADwCr2D6Nzkfs2kWogE8Wu17AAAAAAAAA== --Apple-Mail-11-397881012-- --===============1276677372== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1276677372==-- From tcpm-bounces@ietf.org Tue Oct 02 11:59:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ick7r-00075m-Rs; Tue, 02 Oct 2007 11:57:35 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ick7q-00072Y-Nc for tcpm-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 11:57:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ick7q-00072N-7V for tcpm@ietf.org; Tue, 02 Oct 2007 11:57:34 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ick7p-0005LD-0i for tcpm@ietf.org; Tue, 02 Oct 2007 11:57:34 -0400 X-IronPort-AV: E=Sophos;i="4.21,220,1188802800"; d="scan'208";a="21126402" Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-1.cisco.com with ESMTP; 02 Oct 2007 08:57:32 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l92FvWGh031371; Tue, 2 Oct 2007 08:57:32 -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.12.10/8.12.6) with ESMTP id l92FvA1o022747; Tue, 2 Oct 2007 15:57:32 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, 2 Oct 2007 08:57:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Tue, 2 Oct 2007 08:57:22 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58040A03F3@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <13D1EAB852BE194C94773A947138483D04245613@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgEWGCMHXhyXXRPQOSfylhZ5GAbHwAGtBYgACVf0aA= From: "Anantha Ramaiah (ananth)" To: "Mitesh Dalal (mdalal)" , "Edward A. Gardner" , X-OriginalArrivalTime: 02 Oct 2007 15:57:27.0806 (UTC) FILETIME=[EE6F09E0:01C8050C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=426; t=1191340652; x=1192204652; c=relaxed/simple; s=sjdkim7002; 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]=20tcpsecure=3A=20how=20strong=20to=20recommend ?=20 |Sender:=20; bh=/3fW0aH1570HvASF8dEOvhGKvBW8a1OXO29v5q6LUK0=; b=sPhZDD+AlWUWbOJLjuinlAQuzSdBMHnSMepX+ILhq89jp93np/z6Im308V48J4/eKesUOAnq g2hK8KblYlSzjvfvN8Dz0D6lruiNZ2pq76F7WxEksIBqCbVGAPYNAF2k; Authentication-Results: sj-dkim-7; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > So to reiterate to the group, we need an applicability=20 > statement that highlights the=20 > implementations/deployments/applications that are RECOMMENDED=20 > to have this fix, with others being OPTIONAL. However, the=20 > features/changes themselves being MUST (or SHOULD, if that's=20 > what it would take for a consensus). Is the group in agreement here? ++;=20 (with the author hat off :-) -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Oct 02 12:13:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IckMg-0002En-AH; Tue, 02 Oct 2007 12:12:54 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IckMe-0002Ch-71 for tcpm-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 12:12:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IckMd-0002CX-SV for tcpm@ietf.org; Tue, 02 Oct 2007 12:12:51 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IckMd-0000Ev-EK for tcpm@ietf.org; Tue, 02 Oct 2007 12:12:51 -0400 Received: from [75.214.22.28] (28.sub-75-214-22.myvzw.com [75.214.22.28]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l92GCEHL028773; Tue, 2 Oct 2007 09:12:15 -0700 (PDT) Message-ID: <47026DD7.6000009@isi.edu> Date: Tue, 02 Oct 2007 09:12:07 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC58040A03F3@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58040A03F3@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: tcpm@ietf.org, "Edward A. Gardner" , "Mitesh Dalal \(mdalal\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1823309152==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1823309152== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig79782977197F9CC57FA65C24" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig79782977197F9CC57FA65C24 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > =20 >> So to reiterate to the group, we need an applicability=20 >> statement that highlights the=20 >> implementations/deployments/applications that are RECOMMENDED=20 >> to have this fix, with others being OPTIONAL. However, the=20 >> features/changes themselves being MUST (or SHOULD, if that's=20 >> what it would take for a consensus). Is the group in agreement here? >=20 > ++;=20 > (with the author hat off :-) As a way forward, the following captures the SHOULD/SHOULD/MAY which was most supported in Chicago: -------------------------------------------------------------------------= -- tcpsecure SHOULD be implemented in TCP stacks supporting router. Notable exceptions include deployments where routers are known to use other antispoofing protection, e.g., IPsec, TCP/MD5 and its successors. tcpsecure MAY be implemented in other TCP stacks. ---- within tcpsecure: RST protection MUST be supported SYN protection MUST be supported data segment (i.e., non-RST, non-SYN) protection MAY be supported ------------------------------------------- --------------enig79782977197F9CC57FA65C24 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 iD8DBQFHAm3bE5f5cImnZrsRAuCYAKCJv9bYGfAUoy1Os9M2HtNYlJTorQCgsGql kLzJG1JpN42gLHI9lomROEM= =p3nn -----END PGP SIGNATURE----- --------------enig79782977197F9CC57FA65C24-- --===============1823309152== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1823309152==-- From tcpm-bounces@ietf.org Tue Oct 02 12:46:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcksF-0002I2-MR; Tue, 02 Oct 2007 12:45:31 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IcksE-0002FP-Ea for tcpm-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 12:45:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcksE-0002FH-3f for tcpm@ietf.org; Tue, 02 Oct 2007 12:45:30 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcksD-0001IZ-MN for tcpm@ietf.org; Tue, 02 Oct 2007 12:45:30 -0400 X-IronPort-AV: E=Sophos;i="4.21,220,1188802800"; d="scan'208";a="403400670" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 02 Oct 2007 09:45:29 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l92GjTsE005014; Tue, 2 Oct 2007 09:45:29 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l92GjTvP026485; Tue, 2 Oct 2007 16:45:29 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, 2 Oct 2007 09:45:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Tue, 2 Oct 2007 09:45:27 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58040A0474@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <47026DD7.6000009@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgFDxgnY9bqUd2LRVeE3BxkbgZUIwAAY2+w From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 02 Oct 2007 16:45:28.0933 (UTC) FILETIME=[A3B82150:01C80513] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1877; t=1191343529; x=1192207529; 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]=20tcpsecure=3A=20how=20strong=20to=20recommend ? |Sender:=20; bh=dw+8eEsu9hzCk4uvhRg8ubXwl9Ua+kTrZhMYkbN9UGo=; b=BCZkPqhaBdih/k093Ulp53WmVxu06pQqpuhwPaDWyYU9jPxAGGt1QX9+8jG5FZrzQTGp5Iz3 /KwMKmaOjWqK6hq9FVa3dfrAwuSK9bw0IQ0oJeG0mlw6PupEdD8Xw3l7i8ERnaQIRZp9nddeUr ac198/kp8jaQ/Rnhrjdx06p9k=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tcpm@ietf.org, "Edward A. Gardner" , "Mitesh Dalal \(mdalal\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > As a way forward, the following captures the=20 > SHOULD/SHOULD/MAY which was > most supported in Chicago: >=20 > -------------------------------------------------------------- > ------------- >=20 > tcpsecure SHOULD be implemented in TCP stacks supporting router. > Notable exceptions include deployments where routers are known to use > other antispoofing protection, e.g., IPsec, TCP/MD5 and its=20 > successors. >=20 > tcpsecure MAY be implemented in other TCP stacks. >=20 > ---- > within tcpsecure: >=20 > RST protection MUST be supported >=20 > SYN protection MUST be supported >=20 > data segment (i.e., non-RST, non-SYN) protection MAY be supported >=20 > ------------------------------------------- I think you got it wrong.=20 Most supported in Chicago was about [SHOULD/SHOULD/MAY] WITHOUT the applicability statement in place. It was "STANDALONE" question raised by the chairs for which the consensus seemed to be in favour of S/S/M. Now WITH the applicability statement in place, it completely changes the entire equation. To quote Mark's email : BEGIN QUOTE > It seems to me that this discussion is really divergent because there > is no applicability statement in the document, per Lars' comment. I > wonder if you guys could go off and generate such a statement and=20 > then we could re-visit this question. I think that would factor things > into a question of "where" this is applicable and then how strongly we > want to advocate these mitigations within that context. Is that > reasonable? END QUOTE So, the game plan moving forward is, to generate the AS and revisit the mitigation strengths. Also, just in case you missed, some of responses in this list have indicated no issues with "MUST'ing" all the mitigations provided there is a proper applicability statement in place. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Oct 02 16:32:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcoNn-0008MF-7x; Tue, 02 Oct 2007 16:30:19 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IcoNl-0008LB-Od for tcpm-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 16:30:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcoNk-0008Fc-PP for tcpm@ietf.org; Tue, 02 Oct 2007 16:30:17 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcoNe-0005Cf-72 for tcpm@ietf.org; Tue, 02 Oct 2007 16:30:16 -0400 Received: from [70.213.158.20] (20.sub-70-213-158.myvzw.com [70.213.158.20]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l92KTOQ6015611; Tue, 2 Oct 2007 13:29:28 -0700 (PDT) Message-ID: <4702AA12.2000301@isi.edu> Date: Tue, 02 Oct 2007 13:29:06 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC58040A0474@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58040A0474@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: tcpm@ietf.org, "Edward A. Gardner" , "Mitesh Dalal \(mdalal\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0942033839==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0942033839== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3BEBB10F550E35FD5FB62B90" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3BEBB10F550E35FD5FB62B90 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Notes below.... Anantha Ramaiah (ananth) wrote: >> As a way forward, the following captures the=20 >> SHOULD/SHOULD/MAY which was >> most supported in Chicago: >> >> -------------------------------------------------------------- >> ------------- >> >> tcpsecure SHOULD be implemented in TCP stacks supporting router. >> Notable exceptions include deployments where routers are known to use >> other antispoofing protection, e.g., IPsec, TCP/MD5 and its=20 >> successors. >> >> tcpsecure MAY be implemented in other TCP stacks. >> >> ---- >=20 >=20 >> within tcpsecure: >> >> RST protection MUST be supported >> >> SYN protection MUST be supported >> >> data segment (i.e., non-RST, non-SYN) protection MAY be supported >> >> ------------------------------------------- >=20 > I think you got it wrong.=20 >=20 > Most supported in Chicago was about [SHOULD/SHOULD/MAY] WITHOUT the > applicability statement in place. Agreed. I was trying to capture Chicago in the bottom portion. > It was "STANDALONE" question raised by > the chairs for which the consensus seemed to be in favour of S/S/M. No= w > WITH the applicability statement in place, it completely changes the > entire equation.=20 I don't think it does. Even with a qualified SHOULD on the overall set, data segment protection is still a MAY. What it changes is the SHOULDs on the RST and SYN to MUSTs, to say that you shouldn't implement one or the other as desired *if* you decide to implement the set. =2E.. > So, the game plan moving forward is, to generate the AS and revisit the= > mitigation strengths.=20 I tried to do that above. > Also, just in case you missed, some of responses > in this list have indicated no issues with "MUST'ing" all the > mitigations provided there is a proper applicability statement in place= =2E I know - that was one of the set discussed. OK, so here's what I'm specifically asking: 1) is the AS above reasonable? 2) regarding the RST/SYN/data components: - are the MUST/MUST/MAY above reasonable? - Or should they be SHOULD/SHOULD/MAY? - or something else Joe --------------enig3BEBB10F550E35FD5FB62B90 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 iD8DBQFHAqohE5f5cImnZrsRAvghAJ9OhOTAOf0JsEABpsALlGLlohhHSgCg/NSM OL45Luyu5Ll2vH/kXmvw590= =IaOK -----END PGP SIGNATURE----- --------------enig3BEBB10F550E35FD5FB62B90-- --===============0942033839== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0942033839==-- From tcpm-bounces@ietf.org Tue Oct 02 17:42:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcpUM-0007Hs-H0; Tue, 02 Oct 2007 17:41:10 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IcpUL-0007Hm-Oh for tcpm-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 17:41:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcpUL-0007HZ-Dw for tcpm@ietf.org; Tue, 02 Oct 2007 17:41:09 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcpUL-0001QM-0s for tcpm@ietf.org; Tue, 02 Oct 2007 17:41:09 -0400 X-IronPort-AV: E=Sophos;i="4.21,221,1188802800"; d="scan'208";a="403511865" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 02 Oct 2007 14:41:08 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l92Lf8Fh005999; Tue, 2 Oct 2007 14:41:08 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l92Lepvl002178; Tue, 2 Oct 2007 21:41:08 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); Tue, 2 Oct 2007 14:40:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] tcpsecure: how strong to recommend? Date: Tue, 2 Oct 2007 14:40:50 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58040A06E3@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4702AA12.2000301@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure: how strong to recommend? Thread-Index: AcgFMwnmbhhpUQnuTKSU5OFJh4dlGwAA4r0w From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 02 Oct 2007 21:40:53.0264 (UTC) FILETIME=[E83E6900:01C8053C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1996; t=1191361268; x=1192225268; 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]=20tcpsecure=3A=20how=20strong=20to=20recommend ? |Sender:=20; bh=9DDECyDEZyafMq6mlqx1fGBJmqE6Dq4IOOELklj4s/Y=; b=FFnzVYjShsBb3tzs7ALnxHT4hsjoryazSDacHfHvcLgYPj6kq35hYlJQsUfoiTSM0EGS31pt y+iCKOOivKyYPiJz8JYdUF68DsDVKJM6KcdLYjfY6YAYGlm6FASvFceGtoamfKUOFZQU1rBZTw SrnqRThB0KYD0h0GKuMZkvDeM=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: tcpm@ietf.org, "Edward A. Gardner" , "Mitesh Dalal \(mdalal\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Pl see inline comments... =20 > >> tcpsecure SHOULD be implemented in TCP stacks supporting router. > >> Notable exceptions include deployments where routers are=20 > known to use=20 > >> other antispoofing protection, e.g., IPsec, TCP/MD5 and its=20 > >> successors. > >> > >> tcpsecure MAY be implemented in other TCP stacks. > >> >=20 > > It was "STANDALONE" question raised by the chairs for which the=20 > > consensus seemed to be in favour of S/S/M. Now WITH the=20 > applicability=20 > > statement in place, it completely changes the entire equation. >=20 > I don't think it does. Even with a qualified SHOULD on the=20 > overall set, data segment protection is still a MAY. What it=20 > changes is the SHOULDs on the RST and SYN to MUSTs, to say=20 > that you shouldn't implement one or the other as desired *if*=20 > you decide to implement the set. I dis-agree. All the reasoning so far with the "chosen" adjectives for the individual mitigations are without the applicability statement in place. >=20 > > Also, just in case you missed, some of responses in this list have=20 > > indicated no issues with "MUST'ing" all the mitigations=20 > provided there=20 > > is a proper applicability statement in place. >=20 > I know - that was one of the set discussed. OK, so here's=20 > what I'm specifically asking: >=20 > 1) is the AS above reasonable? Well, I (some others also pointed out) wouldn't mention router, since these mitigations can be/are used in devices not routers per se. But we can use this text as a reference for generating the AS. Others may want to comment here as well. >=20 > 2) regarding the RST/SYN/data components: > - are the MUST/MUST/MAY above reasonable? > - Or should they be SHOULD/SHOULD/MAY? > - or something else Something else. To me, all the mitigations are equally important and hence they classified as MUST after the AS is in place. -Anantha >=20 > Joe >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Oct 02 17:51:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icpdn-0002Ve-LF; Tue, 02 Oct 2007 17:50:55 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Icpdl-0002VW-TJ for tcpm-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 17:50:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icpdl-0002VO-IW for tcpm@ietf.org; Tue, 02 Oct 2007 17:50:53 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icpdl-0001eG-4S for tcpm@ietf.org; Tue, 02 Oct 2007 17:50:53 -0400 Received: from [70.213.158.20] (20.sub-70-213-158.myvzw.com [70.213.158.20]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l92LobZU009181; Tue, 2 Oct 2007 14:50:37 -0700 (PDT) Message-ID: <4702BD28.1010207@isi.edu> Date: Tue, 02 Oct 2007 14:50:32 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC58040A06E3@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58040A06E3@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: tcpm@ietf.org, "Edward A. Gardner" , "Mitesh Dalal \(mdalal\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1890650205==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1890650205== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA79FB0BE44532CBE215F644A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA79FB0BE44532CBE215F644A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: =2E.. >> 1) is the AS above reasonable? >=20 > Well, I (some others also pointed out) wouldn't mention router, since > these mitigations can be/are used in devices not routers per se. But we= > can use this text as a reference for generating the AS. Others may want= > to comment here as well. Can you suggest a term that's useful? How about something specific: "Devices with services where both endpoints are typically known, e.g., BGP." >> 2) regarding the RST/SYN/data components: >> - are the MUST/MUST/MAY above reasonable? >> - Or should they be SHOULD/SHOULD/MAY? >> - or something else >=20 > Something else. To me, all the mitigations are equally important and > hence they classified as MUST after the AS is in place. OK, so here are some options: a) MUST/MUST/MUST b) MUST/MUST/SHOULD c) MUST/MUST/MAY I don't quite understand why we would go with SHOULD for either RST or SYN individually; if anyone can, it'd be useful to make the case. We can mark Anantha as being in favor of (a). I would interpret the WG as *probably* being in favor of (c), since if data was a MAY unqualified, then at best it's a MAY qualified, BUT I'm not trying to make that case myself. I prefer (c), but that's just my individual perspective. I wouldn't care much which of a-c is used. Joe --------------enigA79FB0BE44532CBE215F644A 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 iD8DBQFHAr0oE5f5cImnZrsRAh6MAJ9n3fPFJRi6vyzlHDe/1Le3SUYDaACgh692 ZiFKJ0a9SwwKK9Fv8jQnKmo= =ErFt -----END PGP SIGNATURE----- --------------enigA79FB0BE44532CBE215F644A-- --===============1890650205== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1890650205==-- From tcpm-bounces@ietf.org Tue Oct 02 20:18:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icrup-0002KC-VM; Tue, 02 Oct 2007 20:16:39 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Icrup-0002Hw-2A for tcpm-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 20:16:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icruo-0002Hd-6b; Tue, 02 Oct 2007 20:16:38 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icrun-0004vd-FJ; Tue, 02 Oct 2007 20:16:38 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l930GPPA000794; Wed, 3 Oct 2007 03:16:35 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 03:15:59 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 03:15:59 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 03:15:59 +0300 Received: from [12.104.13.79] (daec-linuxvpn058213.americas.nokia.com [10.241.58.213]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l930FsKW002208; Wed, 3 Oct 2007 03:15:55 +0300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Date: Tue, 2 Oct 2007 20:15:50 -0400 To: tsvwg WG X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Oct 2007 00:15:59.0433 (UTC) FILETIME=[93271B90:01C80552] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: tcpm@ietf.org, draft-larsen-tsvwg-port-randomization@tools.ietf.org, DCCP mailing list Subject: [tcpm] Re: [Tsvwg] consensus call: draft-larsen-tsvwg-port-randomization to WG item X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0940399146==" Errors-To: tcpm-bounces@ietf.org --===============0940399146== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18-462469470; protocol="application/pkcs7-signature" --Apple-Mail-18-462469470 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, my reading of the list discussion is that we do have consensus for TSVWG to take this on this work item with draft-larsen-tsvwg-port- randomization as the basis, i.e., option (1) below. Authors: Please submit the next revision as draft-ietf-tsvwg-port- randomization-00 with a target of Proposed Standard. You should also review the comments that have been made on the list and incorporate them into the revision. For example, several people suggested that the document should more prominently recommend one randomization scheme (or a small number of alternatives). The analysis of the pros and cons of currently implemented schemes that is the bulk of the current document should maybe become an informative appendix. DCCP & TCPM working groups: The continued discussion around this draft will occur on the TSVWG list only, to minimize cross-posting. There will be a joint WG last call eventually, but please participate in the ongoing discussion on TSVWG until then. On 2007-9-12, at 11:38, ext Lars Eggert wrote: > Please comment on the tsvwg@ietf.org list (reply-to set > accordingly), even if you have already commented be on this draft > in the past. > > To make it easy for your chairs, please start your email by > choosing ONE of the options below, followed by any detailed > comments you'd like to make: > > (1) TSVWG should take on this work item, with this document as > the basis > (2) TSVWG should take on this work item, but NOT with this > document as the basis > (3) TSVWG should NOT take on this work item > (4) don't care Lars --Apple-Mail-18-462469470 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMDMwMDE1NTBaMCMGCSqGSIb3DQEJBDEWBBTm46LiD5tSxZ4j aNOguMmBoROwgjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAaB/zlwBeY1opYwNXNeL2zSSrMyPSQ3bk8Wx54xJmaYxNCAU/uCe/ VDNkjjAbx7ps7Ak4nWzhY0Zi8CFQIO5BPKUE5pPvjiWt6eoeUjmSGMppMLyZVAwgTRszZ64ZyXrf M+ezDO5BFxgXUndHiOIenVnnugkxhbYUBE0aBTjMZ14pAhiWwwKAlhJtZisrWec5SHLQvE9Im8le vobjX2gv7WSEEIdic9jzXlY77d9zmB7In/UH4dkhIY8H7Ehwsu2zlhLTyjOyKUuX2cM2QoRA58xX Gxp6n8ZKba8AuviT2aESzvbHh754g8oE61vKOzJ1Np92NpxgwvsOnlUWpjqsqgAAAAAAAA== --Apple-Mail-18-462469470-- --===============0940399146== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0940399146==-- From tcpm-bounces@ietf.org Wed Oct 03 13:27:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id7xs-0005ll-9i; Wed, 03 Oct 2007 13:24:52 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Id7xq-0005lM-S3 for tcpm-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 13:24:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id7xq-0005lE-HM for tcpm@ietf.org; Wed, 03 Oct 2007 13:24:50 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id7xq-0000uv-2V for tcpm@ietf.org; Wed, 03 Oct 2007 13:24:50 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l93HNRce006653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Oct 2007 10:23:27 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l93HNRlY092213; Wed, 3 Oct 2007 10:23:27 -0700 (PDT) (envelope-from faber) Date: Wed, 3 Oct 2007 10:23:26 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] tcpsecure: how strong to recommend? Message-ID: <20071003172326.GE45911@hut.isi.edu> References: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> <46FF3FFA.4080207@isi.edu> Mime-Version: 1.0 In-Reply-To: <46FF3FFA.4080207@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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1045854479==" Errors-To: tcpm-bounces@ietf.org --===============1045854479== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V4b9U9vrdWczvw78" Content-Disposition: inline --V4b9U9vrdWczvw78 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 29, 2007 at 11:19:38PM -0700, Joe Touch wrote: > Anantha Ramaiah (ananth) wrote: > > I will have to dis-agree to this since my viewpoint is different. TCP > > secure adds robustness to the processing of certain TCP segments, which > > in turn helps to counter *some* spoofing attacks. Calling it as an > > authentication scheme seems too far-fetched. >=20 > You are making an assertion about whether you believe the packet is > spoofed or not based on its content matching what you expect from the > true endpoint. >=20 > That is called authentication. Weak, but still authentication. Acting without a chair hat, I disagree. The packet is being categorized as suspicious, for example, it could have been spoofed, corrupted, significantly delayed, whatever. I see the ACK is an attempt to synchronize the endpoints' states, not an attempt to autenticate the peer. The question being asked is closer to "what's going on on your end?" than "who sent this packet?" While some of the discussion has definitely leaned toward security and authentication terminology, I don't think that's the essence of the proposed system. --=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 --V4b9U9vrdWczvw78 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHA9AOaUz3f+Zf+XsRAo7YAJ95Jz0zikfEnml0haUBKsWnDiVkuACcCGbz gHdZmos9Zz3Sctqq9F+Ajl0= =QD47 -----END PGP SIGNATURE----- --V4b9U9vrdWczvw78-- --===============1045854479== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1045854479==-- From tcpm-bounces@ietf.org Wed Oct 03 13:30:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id82r-0005Eo-3v; Wed, 03 Oct 2007 13:30:01 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Id82p-00057A-F9 for tcpm-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 13:29:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id82p-000572-5a for tcpm@ietf.org; Wed, 03 Oct 2007 13:29:59 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id82g-00055z-Mp for tcpm@ietf.org; Wed, 03 Oct 2007 13:29:59 -0400 Received: from [70.213.142.97] (97.sub-70-213-142.myvzw.com [70.213.142.97]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l93HTEAA003163; Wed, 3 Oct 2007 10:29:15 -0700 (PDT) Message-ID: <4703D165.30606@isi.edu> Date: Wed, 03 Oct 2007 10:29:09 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> <46FF3FFA.4080207@isi.edu> <20071003172326.GE45911@hut.isi.edu> In-Reply-To: <20071003172326.GE45911@hut.isi.edu> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0143132363==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0143132363== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAA0968C669B7DC2F1D0FB833" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAA0968C669B7DC2F1D0FB833 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Sat, Sep 29, 2007 at 11:19:38PM -0700, Joe Touch wrote: >> Anantha Ramaiah (ananth) wrote: >>> I will have to dis-agree to this since my viewpoint is different. TCP= >>> secure adds robustness to the processing of certain TCP segments, whi= ch >>> in turn helps to counter *some* spoofing attacks. Calling it as an >>> authentication scheme seems too far-fetched. >> You are making an assertion about whether you believe the packet is >> spoofed or not based on its content matching what you expect from the >> true endpoint. >> >> That is called authentication. Weak, but still authentication. >=20 > Acting without a chair hat, I disagree. The packet is being categorize= d > as suspicious, for example, it could have been spoofed, corrupted, > significantly delayed, whatever. I see the ACK is an attempt to > synchronize the endpoints' states, not an attempt to autenticate the > peer. The question being asked is closer to "what's going on on your > end?" than "who sent this packet?" >=20 > While some of the discussion has definitely leaned toward security and > authentication terminology, I don't think that's the essence of the > proposed system. OK, so that makes it even more strange. You're requiring a unilateral reset (RST) to be issued only when the endpoint states are precisely aligned (no outstanding unack'd segments). Why? What does that tell you about the other end that you didn't know? What purpose relevant to resetting a connection does synchronizing state serve if not to authenticate the other end? If not, then this is an even more bizarre requirement on an otherwise very simple mechanism. Joe --------------enigAA0968C669B7DC2F1D0FB833 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 iD8DBQFHA9FlE5f5cImnZrsRAjm4AKC1mL1vYslpR/OVklD5Mz30bXjEcACfaV01 EDqvDp7MMytr48sMOpSnH1Y= =OhQw -----END PGP SIGNATURE----- --------------enigAA0968C669B7DC2F1D0FB833-- --===============0143132363== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0143132363==-- From tcpm-bounces@ietf.org Wed Oct 03 14:18:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id8mr-00088u-0T; Wed, 03 Oct 2007 14:17:33 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Id8mp-00082S-Lv for tcpm-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 14:17:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id8mp-00082J-CQ for tcpm@ietf.org; Wed, 03 Oct 2007 14:17:31 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id8mj-0006SK-3Z for tcpm@ietf.org; Wed, 03 Oct 2007 14:17:31 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l93IFr5U023596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Oct 2007 11:15:53 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l93IFrhB029604; Wed, 3 Oct 2007 11:15:53 -0700 (PDT) (envelope-from faber) Date: Wed, 3 Oct 2007 11:15:53 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] tcpsecure: how strong to recommend? Message-ID: <20071003181553.GF45911@hut.isi.edu> References: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> <46FF3FFA.4080207@isi.edu> <20071003172326.GE45911@hut.isi.edu> <4703D165.30606@isi.edu> Mime-Version: 1.0 In-Reply-To: <4703D165.30606@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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0773579442==" Errors-To: tcpm-bounces@ietf.org --===============0773579442== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1giRMj6yz/+FOIRq" Content-Disposition: inline --1giRMj6yz/+FOIRq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 03, 2007 at 10:29:09AM -0700, Joe Touch wrote: >=20 >=20 > Ted Faber wrote: > > Acting without a chair hat, I disagree. The packet is being categorized > > as suspicious, for example, it could have been spoofed, corrupted, > > significantly delayed, whatever. I see the ACK is an attempt to > > synchronize the endpoints' states, not an attempt to autenticate the > > peer. The question being asked is closer to "what's going on on your > > end?" than "who sent this packet?" [snip] > >=20 > OK, so that makes it even more strange. You're requiring a unilateral > reset (RST) to be issued only when the endpoint states are precisely > aligned (no outstanding unack'd segments). >=20 > Why? To make it unlikely that spoofed, delayed, erroneously generated, or otherwise invalid packets will terminate an existing connection. A correct implementation intentionally resetting will quickly become synchronized even if the first RST was not from a perfectly synched state. The reset is potentially slower, but a poorly performing abort facility doesn't upset me much. Do you disagree with the characterization of the system or its operation? >=20 > What does that tell you about the other end that you didn't know? What > purpose relevant to resetting a connection does synchronizing state > serve if not to authenticate the other end? If the RST that triggered the ACK was from another connection, the TCPsecure exchange tells you that the other end of this connection has not reset. No new information about the identity of that endpoint has been asserted, simply that the end that got your ACK has state closely enough synchronized with yours to make a sensical reply. The identity of the sender of the RST remains unknown (though if the other end *has* reset, the sender is likely the other end). I don't know anything new about the identity of anyone in the communication; I just don't see authentication there. > If not, then this is an even more bizarre requirement on an otherwise > very simple mechanism. Yeah, this has the feel of us talking past each other. --=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 --1giRMj6yz/+FOIRq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHA9xZaUz3f+Zf+XsRAmIoAKDfgK8KTetCD6g1pF0heOea2YEXswCguXWB TvBE5t2J8UvMBLrgen+SmiU= =OQiI -----END PGP SIGNATURE----- --1giRMj6yz/+FOIRq-- --===============0773579442== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0773579442==-- From tcpm-bounces@ietf.org Wed Oct 03 14:40:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id96q-0005gm-Qj; Wed, 03 Oct 2007 14:38:12 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Id96p-0005eg-Gc for tcpm-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 14:38:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id96p-0005eX-5u for tcpm@ietf.org; Wed, 03 Oct 2007 14:38:11 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id96o-000341-FU for tcpm@ietf.org; Wed, 03 Oct 2007 14:38:11 -0400 Received: from [70.213.142.97] (97.sub-70-213-142.myvzw.com [70.213.142.97]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l93IbgQT022954; Wed, 3 Oct 2007 11:37:43 -0700 (PDT) Message-ID: <4703E173.4060007@isi.edu> Date: Wed, 03 Oct 2007 11:37:39 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> <46FF3FFA.4080207@isi.edu> <20071003172326.GE45911@hut.isi.edu> <4703D165.30606@isi.edu> <20071003181553.GF45911@hut.isi.edu> In-Reply-To: <20071003181553.GF45911@hut.isi.edu> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0356924571==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0356924571== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6618710B7ED571A90A3B57E5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6618710B7ED571A90A3B57E5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Wed, Oct 03, 2007 at 10:29:09AM -0700, Joe Touch wrote: >> >> Ted Faber wrote: >>> Acting without a chair hat, I disagree. The packet is being categori= zed >>> as suspicious, for example, it could have been spoofed, corrupted, >>> significantly delayed, whatever. I see the ACK is an attempt to >>> synchronize the endpoints' states, not an attempt to autenticate the >>> peer. The question being asked is closer to "what's going on on your= >>> end?" than "who sent this packet?" > [snip] >> OK, so that makes it even more strange. You're requiring a unilateral >> reset (RST) to be issued only when the endpoint states are precisely >> aligned (no outstanding unack'd segments). >> >> Why? >=20 > To make it unlikely that spoofed, delayed, erroneously generated, or > otherwise invalid packets will terminate an existing connection. >=20 > A correct implementation intentionally resetting will quickly become > synchronized even if the first RST was not from a perfectly synched > state. The reset is potentially slower, but a poorly performing abort > facility doesn't upset me much. >=20 > Do you disagree with the characterization of the system or its > operation? Asking to 'synchronize with the other end' is authentication, especially when the only purpose behind it is to determine whether a spoofed packet is generated. It's insincere to rationalize events like erroneously generated or delayed RSTs into this discussion. Both kinds of RSTs are just as valid as correctly generated, timely ones, as far as the TCP spec is concerned, unless you're concerned they're beings spoofed. >> What does that tell you about the other end that you didn't know? What= >> purpose relevant to resetting a connection does synchronizing state >> serve if not to authenticate the other end? >=20 > If the RST that triggered the ACK was from another connection, the > TCPsecure exchange tells you that the other end of this connection has > not reset. =20 That presumes that either the RST is floating in the network more than 2 MSLs or that your end decided to accept a connection it shouldn't have since it didn't correctly wait 2 MSLs from a previous connection. If we're going to patch TCP to fix >2MSL errors, there's a lot more work than this to be done. If your end is broken, then expecting this patch to correct the situation is not productive. > No new information about the identity of that endpoint has > been asserted, simply that the end that got your ACK has state closely > enough synchronized with yours to make a sensical reply. The identity > of the sender of the RST remains unknown (though if the other end *has*= > reset, the sender is likely the other end). The identity of the other end is defined by the synchronization process - it's a TCP endpoint with which your ACKs synchronize state. > I don't know anything new about the identity of anyone in the > communication; I just don't see authentication there. You know it's the other end with which you can synchronize state. That's identity. Joe --------------enig6618710B7ED571A90A3B57E5 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 iD8DBQFHA+FzE5f5cImnZrsRAnPRAJ4k2NmTYIim12BJ0AofmGCUmceTyQCgqp/l xBodttQsOIZGtubRWBegCPY= =3McT -----END PGP SIGNATURE----- --------------enig6618710B7ED571A90A3B57E5-- --===============0356924571== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0356924571==-- From tcpm-bounces@ietf.org Fri Oct 05 13:01:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdqXD-00007q-He; Fri, 05 Oct 2007 13:00:19 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IdqXC-000063-E3 for tcpm-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 13:00:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdqXC-00005L-2J for tcpm@ietf.org; Fri, 05 Oct 2007 13:00:18 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdqXB-0003fe-9g for tcpm@ietf.org; Fri, 05 Oct 2007 13:00:17 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l95Gvubf017808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Oct 2007 09:57:56 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l95Gvulg003798; Fri, 5 Oct 2007 09:57:56 -0700 (PDT) (envelope-from faber) Date: Fri, 5 Oct 2007 09:57:56 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] tcpsecure: how strong to recommend? Message-ID: <20071005165755.GA2845@hut.isi.edu> References: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> <46FF3FFA.4080207@isi.edu> <20071003172326.GE45911@hut.isi.edu> <4703D165.30606@isi.edu> <20071003181553.GF45911@hut.isi.edu> <4703E173.4060007@isi.edu> Mime-Version: 1.0 In-Reply-To: <4703E173.4060007@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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0145917286==" Errors-To: tcpm-bounces@ietf.org --===============0145917286== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 03, 2007 at 11:37:39AM -0700, Joe Touch wrote: > Ted Faber wrote: > > On Wed, Oct 03, 2007 at 10:29:09AM -0700, Joe Touch wrote: > >> > >> Ted Faber wrote: > >>> Acting without a chair hat, I disagree. The packet is being categori= zed > >>> as suspicious, for example, it could have been spoofed, corrupted, > >>> significantly delayed, whatever. I see the ACK is an attempt to > >>> synchronize the endpoints' states, not an attempt to autenticate the > >>> peer. The question being asked is closer to "what's going on on your > >>> end?" than "who sent this packet?" > > [snip] > >> OK, so that makes it even more strange. You're requiring a unilateral > >> reset (RST) to be issued only when the endpoint states are precisely > >> aligned (no outstanding unack'd segments). > >> > >> Why? > >=20 > > To make it unlikely that spoofed, delayed, erroneously generated, or > > otherwise invalid packets will terminate an existing connection. > >=20 > > A correct implementation intentionally resetting will quickly become > > synchronized even if the first RST was not from a perfectly synched > > state. The reset is potentially slower, but a poorly performing abort > > facility doesn't upset me much. > >=20 > > Do you disagree with the characterization of the system or its > > operation? >=20 > Asking to 'synchronize with the other end' is authentication, especially > when the only purpose behind it is to determine whether a spoofed packet > is generated. "Did you say that?" is a fundamentally different question that "Who said that" in my mind. Asking the first in this context is both more useful and more practical to determine. If you want to think of them both as authentication, I'm not going to try any more to convince you not to. >=20 > It's insincere to rationalize events like erroneously generated or > delayed RSTs into this discussion. Both kinds of RSTs are just as valid > as correctly generated, timely ones, as far as the TCP spec is > concerned, unless you're concerned they're beings spoofed. I'm perfectly sincere about it. I think pointing out that the technique mitigates several possibilities emphasizes its value from an engineering perspective. I can't argue with your perfectly correct statement that a compliant TCP will treat the spoofed, out of date, erroneously generated, or damaged packets as correct and reset the connection. The argument is whether that behavior is useful or not. =20 I think it's not, but YMMV. >=20 > >> What does that tell you about the other end that you didn't know? What > >> purpose relevant to resetting a connection does synchronizing state > >> serve if not to authenticate the other end? > >=20 > > If the RST that triggered the ACK was from another connection, the > > TCPsecure exchange tells you that the other end of this connection has > > not reset. =20 >=20 > That presumes that either the RST is floating in the network more than 2 > MSLs or that your end decided to accept a connection it shouldn't have > since it didn't correctly wait 2 MSLs from a previous connection. Again, technically correct. I think that addressing the eventuality that (among other things) MSL is incorrectly estimated or configured with an extra packet exchange is good engineering. Yes, I know that an "engineering decision" is often difficult to tell from an "egregious hack." I think that this design is the former. >=20 > If we're going to patch TCP to fix >2MSL errors, there's a lot more work > than this to be done. If your end is broken, then expecting this patch > to correct the situation is not productive. Again, engineering vs. protocol design. IMHO, we're already addressing unlikely events - MSL violation or off-path spoofed RST with known addresses and ports. I think that the cost of one packet exchange to validate that the connection is not about to be terminated by an unlikely event is a reasonable engineering choice. I do not characterize this as provably correcting a protocol flaw. >=20 > > No new information about the identity of that endpoint has > > been asserted, simply that the end that got your ACK has state closely > > enough synchronized with yours to make a sensical reply. The identity > > of the sender of the RST remains unknown (though if the other end *has* > > reset, the sender is likely the other end). >=20 > The identity of the other end is defined by the synchronization process > - it's a TCP endpoint with which your ACKs synchronize state. >=20 > > I don't know anything new about the identity of anyone in the > > communication; I just don't see authentication there. >=20 > You know it's the other end with which you can synchronize state. That's > identity. I think we're arguing over what to name the process. This would be fun to do in person, but I don't think it's advancing the discussion of the system, or in particular of the discussion about the guidance to implementers we're trying to decide on. --=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 --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHBm0TaUz3f+Zf+XsRAoF9AKDr1dOy15xBebb5V12WhZiqQcIJoACfcc3C 8+K24tgIHGFTNGq41woxuVE= =K8o3 -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- --===============0145917286== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0145917286==-- From tcpm-bounces@ietf.org Fri Oct 05 13:22:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idqs3-0002lN-Vn; Fri, 05 Oct 2007 13:21:51 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Idqs3-0002kg-At for tcpm-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 13:21:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idqs2-0002k4-M7 for tcpm@ietf.org; Fri, 05 Oct 2007 13:21:50 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Idqs1-0004dr-Sy for tcpm@ietf.org; Fri, 05 Oct 2007 13:21:50 -0400 Received: from webmail.isi.edu (webmail.isi.edu [128.9.152.28]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l95HLdYn001320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Oct 2007 10:21:39 -0700 (PDT) Received: (from apache@localhost) by webmail.isi.edu (8.12.8/8.12.7) id l95HLdUM015046; Fri, 5 Oct 2007 10:21:39 -0700 X-Authentication-Warning: webmail.isi.edu: apache set sender to touch@isi.edu using -f Received: from system212-7.losangeles.af.mil (system212-7.losangeles.af.mil [138.13.212.7]) by webmail.isi.edu (IMP) with HTTP for ; Fri, 5 Oct 2007 10:21:38 -0700 Message-ID: <1191604898.470672a2ea7cb@webmail.isi.edu> Date: Fri, 5 Oct 2007 10:21:38 -0700 From: touch@ISI.EDU To: Ted Faber Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> <46FF3FFA.4080207@isi.edu> <20071003172326.GE45911@hut.isi.edu> <4703D165.30606@isi.edu> <20071003181553.GF45911@hut.isi.edu> <4703E173.4060007@isi.edu> <20071005165755.GA2845@hut.isi.edu> In-Reply-To: <20071005165755.GA2845@hut.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 138.13.212.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Quoting Ted Faber : > > Asking to 'synchronize with the other end' is authentication, especially > > when the only purpose behind it is to determine whether a spoofed packet > > is generated. > > "Did you say that?" is a fundamentally different question that "Who said > that" in my mind. Asking the first in this context is both more useful > and more practical to determine. > > If you want to think of them both as authentication, I'm not going to > try any more to convince you not to. The only difference between "did you say that" and "who said that" is who is providing the authentication. The latter can be authenticated by a third party, where the first is done exclusively by the other end of the connection. I hope that at least helps explain why I see these as equivalent, even if not everyone agrees with it. > > It's insincere to rationalize events like erroneously generated or > > delayed RSTs into this discussion. Both kinds of RSTs are just as valid > > as correctly generated, timely ones, as far as the TCP spec is > > concerned, unless you're concerned they're beings spoofed. > > I'm perfectly sincere about it. I think pointing out that the technique > mitigates several possibilities emphasizes its value from an engineering > perspective. > > I can't argue with your perfectly correct statement that a compliant TCP > will treat the spoofed, out of date, erroneously generated, or damaged > packets as correct and reset the connection. The argument is whether > that behavior is useful or not. > > I think it's not, but YMMV. I think I've shown above that the utility of the behavior is exclusively motivated by authentication, and that other justifications don't have valid support. You can still think it's useful. I don't think it's not useful, so much as not necessary if you're really concerned about security, and potentially dangerous (unncesssarily complicated and IPR-burdened) if you aren't. > > >> What does that tell you about the other end that you didn't know? What > > >> purpose relevant to resetting a connection does synchronizing state > > >> serve if not to authenticate the other end? > > > > > > If the RST that triggered the ACK was from another connection, the > > > TCPsecure exchange tells you that the other end of this connection has > > > not reset. > > > > That presumes that either the RST is floating in the network more than 2 > > MSLs or that your end decided to accept a connection it shouldn't have > > since it didn't correctly wait 2 MSLs from a previous connection. > > Again, technically correct. I think that addressing the eventuality that > (among other things) MSL is incorrectly estimated or configured with an > extra packet exchange is good engineering. > > Yes, I know that an "engineering decision" is often difficult to tell > from an "egregious hack." I think that this design is the former. Good engineering to update TCP to handle incorrect MSL estimation would be a substantial piece of work. It would require reevaluating everything from SYN exchanges to window offset validation. At the end of the day, if you don't trust the MSL estimation, you need anti-replay. Yet another good reason to use something like IPsec if this is what you're true concerns are, rather than a patchwork of solutions that approximate anti-replay in specific cases. > > If we're going to patch TCP to fix >2MSL errors, there's a lot more work > > than this to be done. If your end is broken, then expecting this patch > > to correct the situation is not productive. > > Again, engineering vs. protocol design. > > IMHO, we're already addressing unlikely events - MSL violation or > off-path spoofed RST with known addresses and ports. I think that the > cost of one packet exchange to validate that the connection is not about > to be terminated by an unlikely event is a reasonable engineering > choice. TCP was designed to be able to unilaterally terminate a connection with a RST. If you wanted a handshake, why did you not use FIN? .. > > > No new information about the identity of that endpoint has > > > been asserted, simply that the end that got your ACK has state closely > > > enough synchronized with yours to make a sensical reply. The identity > > > of the sender of the RST remains unknown (though if the other end *has* > > > reset, the sender is likely the other end). > > > > The identity of the other end is defined by the synchronization process > > - it's a TCP endpoint with which your ACKs synchronize state. > > > > > I don't know anything new about the identity of anyone in the > > > communication; I just don't see authentication there. > > > > You know it's the other end with which you can synchronize state. That's > > identity. > > I think we're arguing over what to name the process. This would be fun > to do in person, but I don't think it's advancing the discussion of the > system, or in particular of the discussion about the guidance to > implementers we're trying to decide on. I agree with that, but we've tripped over some other name issues that are fundamental here: _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Oct 05 13:31:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idqzr-00024W-O5; Fri, 05 Oct 2007 13:29:55 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Idqzq-0001ms-91 for tcpm-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 13:29:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idqzp-0001ka-V0 for tcpm@ietf.org; Fri, 05 Oct 2007 13:29:53 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idqzj-0005gL-MD for tcpm@ietf.org; Fri, 05 Oct 2007 13:29:53 -0400 Received: from webmail.isi.edu (webmail.isi.edu [128.9.152.28]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l95HSn9H003386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Oct 2007 10:28:50 -0700 (PDT) Received: (from apache@localhost) by webmail.isi.edu (8.12.8/8.12.7) id l95HSneM015125; Fri, 5 Oct 2007 10:28:49 -0700 X-Authentication-Warning: webmail.isi.edu: apache set sender to touch@isi.edu using -f Received: from system212-7.losangeles.af.mil (system212-7.losangeles.af.mil [138.13.212.7]) by webmail.isi.edu (IMP) with HTTP for ; Fri, 5 Oct 2007 10:28:49 -0700 Message-ID: <1191605329.47067451d97bc@webmail.isi.edu> Date: Fri, 5 Oct 2007 10:28:49 -0700 From: touch@ISI.EDU To: touch@ISI.EDU Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> <46FF3FFA.4080207@isi.edu> <20071003172326.GE45911@hut.isi.edu> <4703D165.30606@isi.edu> <20071003181553.GF45911@hut.isi.edu> <4703E173.4060007@isi.edu> <20071005165755.GA2845@hut.isi.edu> <1191604898.470672a2ea7cb@webmail.isi.edu> In-Reply-To: <1191604898.470672a2ea7cb@webmail.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 138.13.212.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Anantha Ramaiah \(ananth\)" , tcpm@ietf.org, Ted Faber , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Quoting touch@ISI.EDU: .. > > I think we're arguing over what to name the process. This would be fun > > to do in person, but I don't think it's advancing the discussion of the > > system, or in particular of the discussion about the guidance to > > implementers we're trying to decide on. > > I agree with that, but we've tripped over some other name issues that are > fundamental here: , notably whether this is an update to RFC793 (I think most of us agree that it is). It's important for implementers to know why we're doing what we're doing, and this is purely motivated by security concerns, and provides no real protection from incorrect MSL estimation to TCP as a whole. That's why calling it authentication is important. Calling it a patch to update TCP's robustness is incorrect and misleads implementers into adopting this mechanism unncessarily. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Oct 05 14:41:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ids6A-0008NJ-BJ; Fri, 05 Oct 2007 14:40:30 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ids69-0008Mz-0M for tcpm-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 14:40:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ids68-0008L4-L6 for tcpm@ietf.org; Fri, 05 Oct 2007 14:40:28 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ids68-0007mH-4D for tcpm@ietf.org; Fri, 05 Oct 2007 14:40:28 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l95IdW2j028725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Oct 2007 11:39:32 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l95IdVAr006113; Fri, 5 Oct 2007 11:39:31 -0700 (PDT) (envelope-from faber) Date: Fri, 5 Oct 2007 11:39:31 -0700 From: Ted Faber To: touch@ISI.EDU Subject: Re: [tcpm] tcpsecure: how strong to recommend? Message-ID: <20071005183931.GB2845@hut.isi.edu> References: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> <46FF3FFA.4080207@isi.edu> <20071003172326.GE45911@hut.isi.edu> <4703D165.30606@isi.edu> <20071003181553.GF45911@hut.isi.edu> <4703E173.4060007@isi.edu> <20071005165755.GA2845@hut.isi.edu> <1191604898.470672a2ea7cb@webmail.isi.edu> Mime-Version: 1.0 In-Reply-To: <1191604898.470672a2ea7cb@webmail.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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0678691242==" Errors-To: tcpm-bounces@ietf.org --===============0678691242== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kXdP64Ggrk/fb43R" Content-Disposition: inline --kXdP64Ggrk/fb43R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 05, 2007 at 10:21:38AM -0700, touch@ISI.EDU wrote: > > IMHO, we're already addressing unlikely events - MSL violation or > > off-path spoofed RST with known addresses and ports. I think that the > > cost of one packet exchange to validate that the connection is not about > > to be terminated by an unlikely event is a reasonable engineering > > choice.=20 >=20 > TCP was designed to be able to unilaterally terminate a connection with a= RST. > If you wanted a handshake, why did you not use FIN? That's an instructive example. If your RST is lost - they're not sent reliably as a FIN is - the packet exchange is exactly the one TCPsecure proposes: ACK the last packet. (Strictly speaking the lost RST doesn't do it of course - that would be a nice trick. Either new data goes out (ACKing the last packet as well), or a retransmission occurs, or a window probe goes off.) Receiving the ACK triggers a retransmission of the RST and state synchronizes. If all the RSTs are lost, the state still synchronizes with a timeout. I wouldn't call that an authentication (and I know you didn't), but the process is very similar to how TCPsecure plays out. If we were in a drinking establishment or academic symposium where the navel gazing were appropriate, we could discuss whether that RST packet "unilaterally terminates the connection" or is a hint that the connection has been unilaterally terminated by the destruction of the connection state at one endpoint. I'm sure you can tell what I believe, and I'm suggesting that thinking of both these processes as confirming a hint might be less objectionable to you than thinking of them as authenticating a message. It's a sadder world that we're not in one of those places. But here on the list, I'm hoping that talking about what a "slightly unusual" packet is might steer us back toward the MAY/SHOULD/MUST/applicability statement discussion. --=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 --kXdP64Ggrk/fb43R Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHBoTjaUz3f+Zf+XsRAtyEAKD+RXYB7L/+bggV+IU9A+SxmM1wZACdHASw WZP3qyxt9ebshIEwf0yjPEI= =oPUs -----END PGP SIGNATURE----- --kXdP64Ggrk/fb43R-- --===============0678691242== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0678691242==-- From tcpm-bounces@ietf.org Fri Oct 05 14:45:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdsB2-0005GP-Tc; Fri, 05 Oct 2007 14:45:32 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IdsB2-0005Fq-1g for tcpm-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 14:45:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdsB1-0005F8-JU for tcpm@ietf.org; Fri, 05 Oct 2007 14:45:31 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdsB1-0007vZ-4b for tcpm@ietf.org; Fri, 05 Oct 2007 14:45:31 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l95IiaOG000120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Oct 2007 11:44:36 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l95IiaeC006179; Fri, 5 Oct 2007 11:44:36 -0700 (PDT) (envelope-from faber) Date: Fri, 5 Oct 2007 11:44:36 -0700 From: Ted Faber To: touch@ISI.EDU Subject: Re: [tcpm] tcpsecure: how strong to recommend? Message-ID: <20071005184436.GC2845@hut.isi.edu> References: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> <46FF3FFA.4080207@isi.edu> <20071003172326.GE45911@hut.isi.edu> <4703D165.30606@isi.edu> <20071003181553.GF45911@hut.isi.edu> <4703E173.4060007@isi.edu> <20071005165755.GA2845@hut.isi.edu> <1191604898.470672a2ea7cb@webmail.isi.edu> <1191605329.47067451d97bc@webmail.isi.edu> Mime-Version: 1.0 In-Reply-To: <1191605329.47067451d97bc@webmail.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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0192904728==" Errors-To: tcpm-bounces@ietf.org --===============0192904728== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8X7/QrJGcKSMr1RN" Content-Disposition: inline --8X7/QrJGcKSMr1RN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 05, 2007 at 10:28:49AM -0700, touch@ISI.EDU wrote: > Quoting touch@ISI.EDU: >=20 > .. > > > I think we're arguing over what to name the process. This would be f= un > > > to do in person, but I don't think it's advancing the discussion of t= he > > > system, or in particular of the discussion about the guidance to > > > implementers we're trying to decide on. > >=20 > > I agree with that, but we've tripped over some other name issues that a= re > > fundamental here: >=20 > , notably whether this is an update to RFC793 (I think most of us > agree that it is). Yep. It's not much of an exercise to point at the paragraphs that change. >=20 > It's important for implementers to know why we're doing what we're doing,= and > this is purely motivated by security concerns, and provides no real prote= ction > from incorrect MSL estimation to TCP as a whole. That's why calling it > authentication is important. Calling it a patch to update TCP's robustnes= s is > incorrect and misleads implementers into adopting this mechanism unncessa= rily. I do think it makes TCP slightly more robust, but the occurrances that would trigger that robustness are pretty unusual. The most common cause of that uncommon set is malice. Do you think that concentrating on the likelihood of bad RSTs (and SYNs and data) showing up would steer us back toward the recommendation level? --=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 --8X7/QrJGcKSMr1RN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHBoYUaUz3f+Zf+XsRAvKIAJ9Ud9x805kMPzIKtn7wF2Cd2idkKACfQ7BR KEb79sdvI/tvm8J1UFNJMP8= =Mgcf -----END PGP SIGNATURE----- --8X7/QrJGcKSMr1RN-- --===============0192904728== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0192904728==-- From tcpm-bounces@ietf.org Fri Oct 05 14:47:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdsCu-0007gT-2Y; Fri, 05 Oct 2007 14:47:28 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IdsCs-0007fV-6Q for tcpm-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 14:47:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdsCr-0007dS-Pd for tcpm@ietf.org; Fri, 05 Oct 2007 14:47:25 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdsCr-0007zR-DH for tcpm@ietf.org; Fri, 05 Oct 2007 14:47:25 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l95IkK7U000463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Oct 2007 11:46:20 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l95IkKN2006206; Fri, 5 Oct 2007 11:46:20 -0700 (PDT) (envelope-from faber) Date: Fri, 5 Oct 2007 11:46:20 -0700 From: Ted Faber To: touch@ISI.EDU Subject: Re: [tcpm] tcpsecure: how strong to recommend? Message-ID: <20071005184620.GD2845@hut.isi.edu> References: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> <46FF3FFA.4080207@isi.edu> <20071003172326.GE45911@hut.isi.edu> <4703D165.30606@isi.edu> <20071003181553.GF45911@hut.isi.edu> <4703E173.4060007@isi.edu> <20071005165755.GA2845@hut.isi.edu> <1191604898.470672a2ea7cb@webmail.isi.edu> <20071005183931.GB2845@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20071005183931.GB2845@hut.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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0873981790==" Errors-To: tcpm-bounces@ietf.org --===============0873981790== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="76DTJ5CE0DCVQemd" Content-Disposition: inline --76DTJ5CE0DCVQemd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 05, 2007 at 11:39:31AM -0700, Ted Faber wrote: > But here on the list, I'm hoping that talking about what a "slightly > unusual" packet is might steer us back toward the > MAY/SHOULD/MUST/applicability statement discussion. Who the heck do I think I'm quoting there? Sorry. --=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 --76DTJ5CE0DCVQemd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHBoZ8aUz3f+Zf+XsRAi6wAJ9LNIfed0se08b438S1ocOqMyngmACg5bKe teo/kBxbPZZ0+N92iDDSG1g= =5dMu -----END PGP SIGNATURE----- --76DTJ5CE0DCVQemd-- --===============0873981790== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0873981790==-- From tcpm-bounces@ietf.org Fri Oct 05 21:19:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdyHF-00086p-5a; Fri, 05 Oct 2007 21:16:21 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IdyHE-00086j-Ab for tcpm-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 21:16:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdyHD-00084X-Va for tcpm@ietf.org; Fri, 05 Oct 2007 21:16:20 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdyHD-0003uL-IJ for tcpm@ietf.org; Fri, 05 Oct 2007 21:16:19 -0400 Received: from [128.9.176.73] (c3-vpn2.isi.edu [128.9.176.73] (may be forged)) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l961Fv5n000447; Fri, 5 Oct 2007 18:15:57 -0700 (PDT) Message-ID: <4706E1C3.8020106@isi.edu> Date: Fri, 05 Oct 2007 18:15:47 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> <46FF3FFA.4080207@isi.edu> <20071003172326.GE45911@hut.isi.edu> <4703D165.30606@isi.edu> <20071003181553.GF45911@hut.isi.edu> <4703E173.4060007@isi.edu> <20071005165755.GA2845@hut.isi.edu> <1191604898.470672a2ea7cb@webmail.isi.edu> <1191605329.47067451d97bc@webmail.isi.edu> <20071005184436.GC2845@hut.isi.edu> In-Reply-To: <20071005184436.GC2845@hut.isi.edu> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1774612023==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1774612023== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4A4092AC1DBF6C5B99F0277C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4A4092AC1DBF6C5B99F0277C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: =2E.. > I do think it makes TCP slightly more robust, but the occurrances that > would trigger that robustness are pretty unusual. The most common caus= e of > that uncommon set is malice. Do you think that concentrating on the > likelihood of bad RSTs (and SYNs and data) showing up would steer us > back toward the recommendation level? I don't think considering these RSTs/SYNs/data issues more than malicious is appropriate, and I do think that has a lot to do with the recommendation level. Joe --------------enig4A4092AC1DBF6C5B99F0277C 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 iD8DBQFHBuHEE5f5cImnZrsRAjQgAKD3Y3mx6uHtpNDOasM9VpaU3rAzjACg/oUu GVzhXBVcuhcd+IJce64FbSo= =r1PB -----END PGP SIGNATURE----- --------------enig4A4092AC1DBF6C5B99F0277C-- --===============1774612023== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1774612023==-- From tcpm-bounces@ietf.org Fri Oct 05 21:19:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdyGp-0007fL-LU; Fri, 05 Oct 2007 21:15:55 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IdyGn-0007f0-Oe for tcpm-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 21:15:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdyGn-0007aP-DZ for tcpm@ietf.org; Fri, 05 Oct 2007 21:15:53 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdyGf-00042a-4h for tcpm@ietf.org; Fri, 05 Oct 2007 21:15:51 -0400 Received: from [128.9.176.73] (c3-vpn2.isi.edu [128.9.176.73] (may be forged)) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l961EmGo000293; Fri, 5 Oct 2007 18:14:49 -0700 (PDT) Message-ID: <4706E17F.70903@isi.edu> Date: Fri, 05 Oct 2007 18:14:39 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] tcpsecure: how strong to recommend? References: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> <46FF3FFA.4080207@isi.edu> <20071003172326.GE45911@hut.isi.edu> <4703D165.30606@isi.edu> <20071003181553.GF45911@hut.isi.edu> <4703E173.4060007@isi.edu> <20071005165755.GA2845@hut.isi.edu> <1191604898.470672a2ea7cb@webmail.isi.edu> <20071005183931.GB2845@hut.isi.edu> In-Reply-To: <20071005183931.GB2845@hut.isi.edu> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0558697607==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0558697607== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0F90C2BA1957FF8D471FF40C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0F90C2BA1957FF8D471FF40C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Fri, Oct 05, 2007 at 10:21:38AM -0700, touch@ISI.EDU wrote: >>> IMHO, we're already addressing unlikely events - MSL violation or >>> off-path spoofed RST with known addresses and ports. I think that th= e >>> cost of one packet exchange to validate that the connection is not ab= out >>> to be terminated by an unlikely event is a reasonable engineering >>> choice.=20 >> TCP was designed to be able to unilaterally terminate a connection wit= h a RST. >> If you wanted a handshake, why did you not use FIN? >=20 > That's an instructive example. >=20 > If your RST is lost - they're not sent reliably as a FIN is - the packe= t > exchange is exactly the one TCPsecure proposes: ACK the last packet. > (Strictly speaking the lost RST doesn't do it of course - that would be= > a nice trick. Either new data goes out (ACKing the last packet as > well), or a retransmission occurs, or a window probe goes off.) > > Receiving the ACK triggers a retransmission of the RST and state > synchronizes. If all the RSTs are lost, the state still synchronizes > with a timeout. I wouldn't call that an authentication (and I know you= > didn't), but the process is very similar to how TCPsecure plays out. It's not the same, as you point out. If there's no further data to be sent, then it doesn't necessarily behave like a FIN exchange. If you want a coordinated endpoint exchange, I suggest using a FIN. > If we were in a drinking establishment or academic symposium where the > navel gazing were appropriate, we could discuss whether that RST packet= > "unilaterally terminates the connection" or is a hint that the > connection has been unilaterally terminated by the destruction of the > connection state at one endpoint.=20 I doubt we would debate that long; I agree with you, I suspect, that the latter is more precise. It's a hint. Again, a reason why you either take the hint or not. You don't respond to it, and you don't gain anything - except over-optimization - by telling the other end anything to confirm that hint. > I'm sure you can tell what I > believe, and I'm suggesting that thinking of both these processes as > confirming a hint might be less objectionable to you than thinking of > them as authenticating a message.=20 Confirming that it's a hint? Confirming what? That the hint came from who you thought. Again we're back to authentication. > But here on the list, I'm hoping that talking about what a "slightly > unusual" packet is might steer us back toward the > MAY/SHOULD/MUST/applicability statement discussion. It walks, looks, and quacks like a duck. Whether you will agree to call it a duck or not, I won't worry. But I've treated it like a duck in deciding MUST/MAY/SHOULD. If we truly want to get back to that discussion, I haven't heard others address the proposed way forward I offered... Joe --------------enig0F90C2BA1957FF8D471FF40C 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 iD8DBQFHBuF/E5f5cImnZrsRAiVvAKCWA4RnqyD/CerXQpuZIIsIoSJLVwCg9XFF grRKad2AwnmR9KrxnHmq+Ek= =rNGr -----END PGP SIGNATURE----- --------------enig0F90C2BA1957FF8D471FF40C-- --===============0558697607== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0558697607==-- From tcpm-bounces@ietf.org Wed Oct 10 09:39:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifbl5-0005AA-CD; Wed, 10 Oct 2007 09:37:55 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ifbl4-0005A2-4x for tcpm-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 09:37:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifbl3-00059u-QV for tcpm@ietf.org; Wed, 10 Oct 2007 09:37:53 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifbky-0001TA-C1 for tcpm@ietf.org; Wed, 10 Oct 2007 09:37:53 -0400 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 l9ADbWVM019069 for ; Wed, 10 Oct 2007 06:37:32 -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 20214108281C for ; Wed, 10 Oct 2007 09:37:26 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 2861B2B9905 for ; Wed, 10 Oct 2007 09:36:00 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Drift Away MIME-Version: 1.0 Date: Wed, 10 Oct 2007 09:36:00 -0400 Message-Id: <20071010133600.2861B2B9905@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [tcpm] WGLC for UTO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 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="===============1841078898==" Errors-To: tcpm-bounces@ietf.org --===============1841078898== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- We are starting a WGLC on the UTO specification, draft-ietf-tcpm-tcp-uto-06.txt. We believe the document has addressed the concerns raised by the WG and that there is good consensus for publishing the document. Our charter says the intended status for the document is "Proposed Standard". However, in the draft tracker it says "Experimental". We cannot seem to recall crisply deciding this issue. So, please review the document one last time and raise issues on the mailing list and please also weigh in on whether you think it should be Experimental or Proposed Standard. Also, notes of the form "looks fine to me" are encouraged. The WGLC will run through October 24. Thanks, Mark & Ted --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHDNU/WyrrWs4yIs4RAlG+AJ9+RaQqg6GnA2Jk75Z4Q5cbUZt/6ACfQdyK rkj899SO0RI4rptKFeH9lg8= =bvAG -----END PGP SIGNATURE----- --=_bOundary-- --===============1841078898== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1841078898==-- From tcpm-bounces@ietf.org Wed Oct 10 11:27:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfdRp-0002S5-6y; Wed, 10 Oct 2007 11:26:09 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IfdRm-0002RV-RJ for tcpm-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 11:26:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfdRm-0002RD-Ej for tcpm@ietf.org; Wed, 10 Oct 2007 11:26:06 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfdRl-00085f-UT for tcpm@ietf.org; Wed, 10 Oct 2007 11:26:06 -0400 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 16:26:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] WGLC for UTO Date: Wed, 10 Oct 2007 16:22:18 +0100 Message-ID: In-Reply-To: <20071010133600.2861B2B9905@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC for UTO Thread-Index: AcgLQ0KJZRmr48wbRky8tgHms9+eQQACfPsg From: To: , X-OriginalArrivalTime: 10 Oct 2007 15:26:05.0034 (UTC) FILETIME=[DF84D4A0:01C80B51] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Generally the UTO draft seems absolutely fine and I would support it moving to RFC. There seems no obvious reason for it to be experimental rather than proposed standard.=20 I do have one potential concern and some nits: Concern: Section 4.1 Middleboxes suggests that "In the future, such [stateful] firewalls may learn to parse the TCP User Timeout Option and adapt connection state management accordingly." Would it be worth adding that in this case this could become a potential security issue as it would allow cooperative users to cause a stateful firewall to maintain connection state for over 22 hours? Nits: Section 3:=20 'LOCAL_UTO' "If unspecified, it default to the default system-wide USER TIMEOUT." change to "...defaults to the default..." Para starting 'Before opening a connection...' "The default is to allow this for connections that do not have a specific user timeout concerns." delete "a" "...to prevent UTO options from the other end to override local application requests." change to "options from the other end overriding local..." Next para: "... is a reliable way to initially exchange and potentially adapt to UTO values." add commas: "... is a reliable way to initially exchange, and potentially adapt to, UTO values." Section 3.1 para 1. Delete the first comma in the last sentence so it reads: "In this case they SHOULD, however, notify the application about the user timeout value received from the other end." Para starting "This means that..." change last sentence (remove nevertheless) "...it can still close or abort..." Section 4.2 last sentence change to "Therefore, if a connection that enables keep-alives is also using the TCP User Timeout Option, ..." Toby ________________________________________________________________________ ____ Toby Moncaster, Networks Research Centre, BT Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 648734=20 =20 -----Original Message----- From: Mark Allman [mailto:mallman@icir.org]=20 Sent: 10 October 2007 14:36 To: tcpm@ietf.org Subject: [tcpm] WGLC for UTO =20 Folks- We are starting a WGLC on the UTO specification, draft-ietf-tcpm-tcp-uto-06.txt. We believe the document has addressed the concerns raised by the WG and that there is good consensus for publishing the document. Our charter says the intended status for the document is "Proposed Standard". However, in the draft tracker it says "Experimental". We cannot seem to recall crisply deciding this issue. So, please review the document one last time and raise issues on the mailing list and please also weigh in on whether you think it should be Experimental or Proposed Standard. Also, notes of the form "looks fine to me" are encouraged. The WGLC will run through October 24. Thanks, Mark & Ted _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Oct 10 12:03:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ife01-000724-8b; Wed, 10 Oct 2007 12:01:29 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ife00-00071w-K4 for tcpm-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 12:01:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ife00-00071o-5W; Wed, 10 Oct 2007 12:01:28 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifdzz-0000wu-LC; Wed, 10 Oct 2007 12:01:28 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9AG0idO029882; Wed, 10 Oct 2007 19:01:21 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 18:59:48 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 18:59:48 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 18:59:47 +0300 Received: from [172.18.176.123] (essapo-nirac252124.europe.nokia.com [10.162.252.124]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9AFxhp9031981; Wed, 10 Oct 2007 18:59:45 +0300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <4F48A5DF-F6C9-4910-9189-065F99BB2885@nokia.com> From: Lars Eggert Subject: Re: [tcpm] WGLC for UTO Date: Wed, 10 Oct 2007 10:59:42 -0500 To: "ext tcpm-bounces@ietf.org" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Oct 2007 15:59:47.0979 (UTC) FILETIME=[9549BDB0:01C80B56] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0298636757==" Errors-To: tcpm-bounces@ietf.org --===============0298636757== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-39--1023581739; protocol="application/pkcs7-signature" --Apple-Mail-39--1023581739 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-10-10, at 10:22, ext tcpm-bounces@ietf.org wrote: > Concern: > > Section 4.1 Middleboxes suggests that "In the future, such [stateful] > firewalls may learn to parse the TCP User Timeout Option and adapt > connection state management accordingly." Would it be worth adding > that > in this case this could become a potential security issue as it would > allow cooperative users to cause a stateful firewall to maintain > connection state for over 22 hours? Similar to how UTO is not binding for the ends (i.e., they may close a connection at any time), it is not binding for middleboxes. So these (so far purely hypothetical) middleboxes are free to time out the binding at any time, for example, if they become resource- constrained. We could make that explicit in the draft, if people feel the current text is unclear. > Nits: We'll fix these. Thanks, Lars --Apple-Mail-39--1023581739 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMTAxNTU5NDNaMCMGCSqGSIb3DQEJBDEWBBT+xmcQgGGIVRcU D8g45hihGJBijDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEACuSVU8Wk69mJgRbevXO6ndvpG4p0m/loOCDTHzp+ekucN9tLXS2p PGy0KrWg8+7Ob2WW5Eg7qAaJwRznO7K8bq62KelwcocO/hBWh5G5pPH+bgJDziaw/XUdph1ilTmC ur4Ux8AHTekAjhY+9ab9iweNr8/NmK+9iW4llDgc2g4//jR1E5kW3JoCAwcvpcY6ONJZTlZpnAl1 y+KrOa7Rv7WPWmeMkLVekA3X9/ckGSRir2EFL8Ah/4SQvaJdbY/ZImqA2TIAcT8PqJD97POy+Pt0 lgHlFRvI/DawlSQR0s6vlRCF0/bPRHwrKvGjeSG2Uf+eYbZRnd2hzORFUeDJWQAAAAAAAA== --Apple-Mail-39--1023581739-- --===============0298636757== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0298636757==-- From tcpm-bounces@ietf.org Mon Oct 15 04:30:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhLJW-0004Jw-QW; Mon, 15 Oct 2007 04:28:38 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IhLJU-0004Hn-Bx for tcpm-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 04:28:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhLJT-0004HI-HT for tcpm@ietf.org; Mon, 15 Oct 2007 04:28:35 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhLJS-00088V-WB for tcpm@ietf.org; Mon, 15 Oct 2007 04:28:35 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9F8RwVb012823; Mon, 15 Oct 2007 11:28:26 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 11:28:03 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 11:28:03 +0300 Received: from [172.21.37.234] ([172.21.37.234]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 11:28:03 +0300 In-Reply-To: <20071010133600.2861B2B9905@lawyers.icir.org> References: <20071010133600.2861B2B9905@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <9F3E1D0B-7980-4351-BE4B-DCD1AE92895A@nokia.com> From: Pasi Sarolahti Subject: Re: [tcpm] WGLC for UTO Date: Mon, 15 Oct 2007 11:26:59 +0300 To: mallman@icir.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Oct 2007 08:28:03.0007 (UTC) FILETIME=[4D87FCF0:01C80F05] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1867419580==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1867419580== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--618744688" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1--618744688 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Oct 10, 2007, at 16:36, ext Mark Allman wrote: > We are starting a WGLC on the UTO specification, > draft-ietf-tcpm-tcp-uto-06.txt. We believe the document has addressed > the concerns raised by the WG and that there is good consensus for > publishing the document. Our charter says the intended status for the > document is "Proposed Standard". However, in the draft tracker it > says > "Experimental". We cannot seem to recall crisply deciding this issue. The draft looks fine to me to go forward. Regarding the Proposed Standard vs. Experimental issue, I think this draft, like the other new TCP extensions, should first go to Experimental as a rule of thumb. I'm concerned about the increasing complexity and size of "the standards track" TCP implementation. It would be a good practice to have a careful evaluation in Experimental RFC phase before adding up things to standards track TCP that is expected to be implemented by most vendors. - Pasi --Apple-Mail-1--618744688 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHEyRUoNa7NH1G2csRAl00AJ4xN6aOxrIBYOkuIucAksng2x8yWgCfeiwq CMI+evxZmQ8uSS3W8kFzm5c= =2Dp2 -----END PGP SIGNATURE----- --Apple-Mail-1--618744688-- --===============1867419580== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1867419580==-- From tcpm-bounces@ietf.org Mon Oct 15 07:52:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhOSu-0000pR-1g; Mon, 15 Oct 2007 07:50:32 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IhOSr-0000f7-9B for tcpm-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 07:50:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhOSq-0000PI-Dt for tcpm@ietf.org; Mon, 15 Oct 2007 07:50:28 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhOSl-0000Dx-SN for tcpm@ietf.org; Mon, 15 Oct 2007 07:50:24 -0400 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 l9FBoKLU021056; Mon, 15 Oct 2007 04:50:20 -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 1E9BD10B52FE; Mon, 15 Oct 2007 07:50:14 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id DBF9F2C9F99; Mon, 15 Oct 2007 07:48:34 -0400 (EDT) To: Pasi Sarolahti From: Mark Allman Subject: Re: [tcpm] WGLC for UTO In-Reply-To: <9F3E1D0B-7980-4351-BE4B-DCD1AE92895A@nokia.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Who Are You MIME-Version: 1.0 Date: Mon, 15 Oct 2007 07:48:34 -0400 Message-Id: <20071015114834.DBF9F2C9F99@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 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="===============1029258808==" Errors-To: tcpm-bounces@ietf.org --===============1029258808== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > The draft looks fine to me to go forward. Many thanks for the note! I have a couple questions (with my hat off) ... > Regarding the Proposed Standard vs. Experimental issue, I think this > draft, like the other new TCP extensions, should first go to > Experimental as a rule of thumb. I'm concerned about the increasing > complexity and size of "the standards track" TCP implementation. It > would be a good practice to have a careful evaluation in Experimental > RFC phase before adding up things to standards track TCP that is > expected to be implemented by most vendors. (1) What 'careful evaluation' do you think should be done during Experimental? Or, put another way, how would we know that it was OK for UTO to later move to PS? My own opinion here is that this draft specifies a way to share some information and that is pretty benign. I can't see where it hurts anything if stacks want to do it. It is advisory information if stacks want to ignore it. So, what's the real harm here in putting it on the standards track? Or, what would be the benefit of going experimental? My own answer to both questions is "very little". (2) While I sympathize with the goal of keeping things simple and avoiding needless complexity, I do not believe that just because we put something on the standards track we expect it to be implemented in every TCP implementation. Perhaps that is flawed reading of these things. Just my two bits. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHE1OSWyrrWs4yIs4RAr9MAJ42Ij+FkHGu+pPJwLbjYJbrZWRL8gCggOjN 9vGuNjkyrJM/8bCJNpBPfn0= =MhHA -----END PGP SIGNATURE----- --=_bOundary-- --===============1029258808== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1029258808==-- From tcpm-bounces@ietf.org Mon Oct 15 11:34:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRw0-0006ee-01; Mon, 15 Oct 2007 11:32:48 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IhRvy-0006c3-SY for tcpm-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 11:32:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRvx-0006Zc-QP for tcpm@ietf.org; Mon, 15 Oct 2007 11:32:45 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhRvx-0001kZ-2M for tcpm@ietf.org; Mon, 15 Oct 2007 11:32:45 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9FFWRpT010718; Mon, 15 Oct 2007 18:32:34 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 18:32:16 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 18:32:16 +0300 Received: from [172.21.37.234] ([172.21.37.234]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 18:32:16 +0300 In-Reply-To: <20071015114834.DBF9F2C9F99@lawyers.icir.org> References: <20071015114834.DBF9F2C9F99@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Pasi Sarolahti Subject: Re: [tcpm] WGLC for UTO Date: Mon, 15 Oct 2007 18:31:13 +0300 To: mallman@icir.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Oct 2007 15:32:16.0047 (UTC) FILETIME=[90B9ABF0:01C80F40] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1552919769==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1552919769== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4--593291169" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-4--593291169 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Oct 15, 2007, at 14:48, ext Mark Allman wrote: >> Regarding the Proposed Standard vs. Experimental issue, I think this >> draft, like the other new TCP extensions, should first go to >> Experimental as a rule of thumb. I'm concerned about the increasing >> complexity and size of "the standards track" TCP implementation. It >> would be a good practice to have a careful evaluation in Experimental >> RFC phase before adding up things to standards track TCP that is >> expected to be implemented by most vendors. First of all, I want to clarify that I am proposing this as a general rule of thumb on how to introduce new features to TCP. It has been always a bit fuzzy to me when some new feature should go to experimental, and when it can go directly to standards track. This is not only about UTO (which I think seems like a fine scheme). > (1) What 'careful evaluation' do you think should be done during > Experimental? In case of UTO, given * possibly limited budget of TCP implementation size (in embedded devices, for example) * limited TCP option space * possibility of resource exhaustion attacks as discussed in security considerations Should I implement UTO and when should I enable it? > Or, put another way, how would we know that it was OK for UTO to > later move to PS? If people find UTO useful (I'm sure many will do), they will implement UTO even as an Experimental RFC. After a couple of years of deployment experience advancing the document to PS should be a straight-forward process, if no problems have emerged, right? One could ask the above question for any other experimental document. Having couple of years of kind of a "trial period" for new TCP extensions wouldn't do any harm, would it? > My own opinion here is that this draft specifies a way to share > some > information and that is pretty benign. I can't see where it hurts > anything if stacks want to do it. It is advisory information if > stacks want to ignore it. So, what's the real harm here in > putting > it on the standards track? Or, what would be the benefit of going > experimental? My own answer to both questions is "very little". I agree that UTO seems quite safe and non-controversial extension (like many other experimental RFC). But one could also ask what's the real harm in putting it to experimental first? What would be the benefit of going directly to standards track, instead? Very little? Remembering a past tsvarea presentation at IETF-68 about Window Vista features, where Window scaling (PS) and ECN (PS) were disabled by default, and DSACK (Exp), F-RTO (Exp) enabled... I realize that in the end it is up to the implementors to decide which standards track RFCs they choose to use, and we have indeed seen that some implementations are pretty liberal in selecting the TCP features. Nevertheless, it would be useful to have a meaning to the standards track status, indicating that a feature is considered to be part of the "recommended TCP", to help the people pondering among the number of TCP RFCs out there. The roadmap RFC seems to make this assumption, too, having the standards track enhancements listed as "recommended". - Pasi --Apple-Mail-4--593291169 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHE4fBoNa7NH1G2csRAg0fAJ0QNqOpWw6kplxtibV/jlh6knht2wCeMIG9 VUYTPu+rmktrWgR3D+Ss1VI= =b7aw -----END PGP SIGNATURE----- --Apple-Mail-4--593291169-- --===============1552919769== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1552919769==-- From tcpm-bounces@ietf.org Mon Oct 15 12:16:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhSc0-0007Ad-Kc; Mon, 15 Oct 2007 12:16:12 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IhSby-00078k-UL for tcpm-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 12:16:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhSby-00077w-59 for tcpm@ietf.org; Mon, 15 Oct 2007 12:16:10 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhSbp-0007Sx-SW for tcpm@ietf.org; Mon, 15 Oct 2007 12:16:08 -0400 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 l9FGFeuQ025740; Mon, 15 Oct 2007 09:15:40 -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 1305510B76EA; Mon, 15 Oct 2007 12:15:34 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id CDC992CA32C; Mon, 15 Oct 2007 12:13:55 -0400 (EDT) To: Pasi Sarolahti From: Mark Allman Subject: Re: [tcpm] WGLC for UTO In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Who Are You MIME-Version: 1.0 Date: Mon, 15 Oct 2007 12:13:55 -0400 Message-Id: <20071015161355.CDC992CA32C@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 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="===============1506063521==" Errors-To: tcpm-bounces@ietf.org --===============1506063521== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [[ Folks, we could use some opinions from additional people on this question. ]] > First of all, I want to clarify that I am proposing this as a general > rule of thumb on how to introduce new features to TCP. It has been > always a bit fuzzy to me when some new feature should go to > experimental, and when it can go directly to standards track. This is > not only about UTO (which I think seems like a fine scheme). Point taken. > > (1) What 'careful evaluation' do you think should be done during > > Experimental? > > In case of UTO, given > * possibly limited budget of TCP implementation size (in embedded > * devices, for example) > * limited TCP option space > * possibility of resource exhaustion attacks as discussed in > * security considerations The thing that I don't see is how we'll differently answer these questions in 2 or 3 years than we do today. I don't mean to claim there are not considerations. There are. But, are embedded devices that don't want needless TCP mechanisms going to be gone in a few years? How is that consideration going to change with experience? In a few years will we be able to discount resource attacks? It seems to me that you (and others) are advocating experience for the sake of experience, rather than experience for the sake of figuring something in particular out. > One could ask the above question for any other experimental > document. Sure---and I think we should. But, some documents have good answers and some don't, IMO. E.g., we made NCR an experimental RFC because it delays TCP's congestion response and therefore makes TCP more aggressive. I think the question "is this OK?" is clear and would have to be answered with experimental evidence before we decided that it was OK for standards track (i.e., generally applicable for wide spread deployment). In this case "is it OK?" is a technical question about the mechanism. I think this is in direct contrast to UTO---which is about the exchange of information. We can say we're going to ask "is it OK?", but in the UTO case that is not a technical question. How do we answer that question with an experiment? I don't see any reason why we'd delay putting UTO on the standards track as a **proposed** standard. > But one could also ask what's the real harm in putting it to > experimental first? What would be the benefit of going directly to > standards track, instead? Very little? Point taken. The benefit may also be small. In some sense it depends on the default setting you like best. You want to add an extra step to all documents and I want to add that extra step only when it seems like we really need to add that step (and, it doesn't seem to me that we need the extra step in this case). > Remembering a past tsvarea > presentation at IETF-68 about Window Vista features, where Window > scaling (PS) and ECN (PS) were disabled by default, and DSACK (Exp), > F-RTO (Exp) enabled... (Nit: DSACK is PS and always has been. And, IMO this is important because it is quite close to UTO because they both specify how to share information and not much else.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHE5HDWyrrWs4yIs4RArDKAJ4rIhIfl9Kbmzp3AY8A1rsXI7Db0gCfQJus gU7PbsPAe6TWuvCG4TgI0z8= =QyCB -----END PGP SIGNATURE----- --=_bOundary-- --===============1506063521== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1506063521==-- From tcpm-bounces@ietf.org Tue Oct 16 14:42:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhrKv-0004rf-OB; Tue, 16 Oct 2007 14:40:13 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IhrKr-0004qx-DA for tcpm-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 14:40:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhrKq-0004qU-Fz for tcpm@ietf.org; Tue, 16 Oct 2007 14:40:08 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhrKp-0008HR-6g for tcpm@ietf.org; Tue, 16 Oct 2007 14:40:08 -0400 Received: from [75.213.226.126] (126.sub-75-213-226.myvzw.com [75.213.226.126]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l9GIdheD019592; Tue, 16 Oct 2007 11:39:43 -0700 (PDT) Message-ID: <47150568.8090403@isi.edu> Date: Tue, 16 Oct 2007 11:39:36 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pasi Sarolahti Subject: Re: [tcpm] WGLC for UTO References: <20071015114834.DBF9F2C9F99@lawyers.icir.org> In-Reply-To: X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0180470006==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0180470006== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3CBB8974217E2EF391A2A42F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3CBB8974217E2EF391A2A42F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pasi Sarolahti wrote: >=20 > On Oct 15, 2007, at 14:48, ext Mark Allman wrote: >=20 >>> Regarding the Proposed Standard vs. Experimental issue, I think this >>> draft, like the other new TCP extensions, should first go to >>> Experimental as a rule of thumb.=20 I don't agree. Whether something goes to experimental is determined by whether there is an experiment needed. The standards track has phases for us to gain confidence with extensions - that's why things don't just go straight to Standard. There are three choices, BTW: - standards track should be for things we think are useful to the Internet as a whole, and not harmful to the Internet as a whole if widely deployed - experimental things for which an experiment in deployment will help either gain confidence in group behavior or parameter determination - informational things which are not harmful to the Internet as a whole if widely deployed, but may be useful in specific environments Anything that is harmful to the Internet as a whole should be documented more as something to avoid, IMO. >>> I'm concerned about the increasing >>> complexity and size of "the standards track" TCP implementation.=20 That should be a consideration for all items in the standards track, and is largely - AFAICT - determined by the MUST/SHOULD/MAY designations. I will note, as others have as well, that there's a problem with the menu of choices out there. Many choices are intermingled, and the roadmap should be clear on which current choices are related. The same relationship can be true for items within a mechanism, as we've discused on this list as well. Perhaps it would be useful for us to adopt an informal requirement that TCP mods come with three clear summaries: 1) whether the proposed mechanism is, as a whole, MUST/SHOULD/MAY 2) which components of the proposed mechanism are MUST/SHOULD/MAY 3) what other dependent choices are MUST/SHOULD/MAY It'd be useful to have a section that lists these succinctly in summary, at the beginning of the document, e.g., "Requirements Levels and Dependencies". >> (1) What 'careful evaluation' do you think should be done during >> Experimental? >=20 > In case of UTO, given > * possibly limited budget of TCP implementation size (in embedded > devices, for example) MAY and SHOULD allow designers to omit things for space constraints. > * limited TCP option space MAY and SHOULD allow designers - and users - to disable things for header space limitations. > * possibility of resource exhaustion attacks as discussed in security > considerations That ought to be addressed before being released. Security questions are not the kinds of things we want to gain experience with via widescale deployment. > Should I implement UTO and when should I enable it? MAY handles that. Joe --------------enig3CBB8974217E2EF391A2A42F 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 iD8DBQFHFQVtE5f5cImnZrsRAjB1AKCU3ChPpi/xWzgjOsZTvxy5GBziJACeJECR gNBr0TjZTpchjvu+w+ElFTE= =oUwc -----END PGP SIGNATURE----- --------------enig3CBB8974217E2EF391A2A42F-- --===============0180470006== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0180470006==-- From tcpm-bounces@ietf.org Wed Oct 17 16:22:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiFNO-0002Oa-0t; Wed, 17 Oct 2007 16:20:22 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IiFNM-0002Nf-N0 for tcpm-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 16:20:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiFNL-0002NW-QQ for tcpm@ietf.org; Wed, 17 Oct 2007 16:20:19 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiFNL-00020f-Bd for tcpm@ietf.org; Wed, 17 Oct 2007 16:20:19 -0400 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 l9HKKI1I021467 for ; Wed, 17 Oct 2007 13:20:18 -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 47CDC10D0006 for ; Wed, 17 Oct 2007 16:20:12 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A42472CCEF0 for ; Wed, 17 Oct 2007 16:18:30 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Who Are You MIME-Version: 1.0 Date: Wed, 17 Oct 2007 16:18:30 -0400 Message-Id: <20071017201830.A42472CCEF0@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [tcpm] Re: WGLC for UTO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 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="===============1103150334==" Errors-To: tcpm-bounces@ietf.org --===============1103150334== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Just a reminder that we have one week left on thr UTO WGLC. We have one comment so far. Please take a few minutes and give this one more read and send a note to the list with your thoughts. Thanks, allman > Folks- > > We are starting a WGLC on the UTO specification, > draft-ietf-tcpm-tcp-uto-06.txt. We believe the document has addressed > the concerns raised by the WG and that there is good consensus for > publishing the document. Our charter says the intended status for the > document is "Proposed Standard". However, in the draft tracker it says > "Experimental". We cannot seem to recall crisply deciding this issue. > So, please review the document one last time and raise issues on the > mailing list and please also weigh in on whether you think it should be > Experimental or Proposed Standard. Also, notes of the form "looks fine > to me" are encouraged. The WGLC will run through October 24. > > Thanks, > Mark & Ted --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHFm4WWyrrWs4yIs4RAoQxAKCM3A/Fv9MdHmR85xFUGCqZDTCkigCePYDe SWsr5XQeTBnL5u0s9DivQ3Q= =a2WK -----END PGP SIGNATURE----- --=_bOundary-- --===============1103150334== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1103150334==-- From tcpm-bounces@ietf.org Thu Oct 18 10:04:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiVxv-0000E0-Ru; Thu, 18 Oct 2007 10:03:11 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IiVxu-0000Ds-FL for tcpm-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 10:03:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiVxt-0000DX-3N for tcpm@ietf.org; Thu, 18 Oct 2007 10:03:09 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiVxs-0003Q5-Ch for tcpm@ietf.org; Thu, 18 Oct 2007 10:03:09 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9IE2pmf006096; Thu, 18 Oct 2007 17:02:53 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 17:02:39 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 17:02:43 +0300 Received: from [172.21.38.162] ([172.21.38.162]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 17:02:34 +0300 In-Reply-To: <20071015161355.CDC992CA32C@lawyers.icir.org> References: <20071015161355.CDC992CA32C@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> From: Pasi Sarolahti Subject: Re: [tcpm] WGLC for UTO Date: Thu, 18 Oct 2007 17:01:29 +0300 To: mallman@icir.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 18 Oct 2007 14:02:34.0674 (UTC) FILETIME=[886A9120:01C8118F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0488850562==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0488850562== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-31--339474945" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-31--339474945 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Oct 15, 2007, at 19:13, ext Mark Allman wrote: > E.g., we made NCR an experimental RFC because it delays TCP's > congestion > response and therefore makes TCP more aggressive. I think the > question > "is this OK?" is clear and would have to be answered with experimental > evidence before we decided that it was OK for standards track (i.e., > generally applicable for wide spread deployment). In this case "is it > OK?" is a technical question about the mechanism. I think this is in > direct contrast to UTO---which is about the exchange of > information. We > can say we're going to ask "is it OK?", but in the UTO case that is > not > a technical question. How do we answer that question with an > experiment? I don't see any reason why we'd delay putting UTO on the > standards track as a **proposed** standard. Ok, I think you are right that it is hard to come up with well- defined experiments that would give some additional technical information about the UTO. But I don't understand where this requirement for experiments comes from. I also ask, because this "what is the experiment?" question has come up quite a few times during the past couple of years for Experimental documents in different WGs, and RFC 2026 does not say anything about experiments: The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see below).... (I believe many of the proposed TCP extensions are part of a research project.) > In some sense it depends on the default setting you like best. You > want > to add an extra step to all documents and I want to add that extra > step > only when it seems like we really need to add that step (and, it > doesn't > seem to me that we need the extra step in this case). I didn't mean adding extra step to *all* documents, just that we should by default be conservative when extending standards track TCP with new features. The idea was that during the Experimental state we could, among other things, get better understanding whether there is "enough community interest to be considered valuable", as required for Proposed Standard. This is sometimes hard to judge based on the (lack of) comments during WGLCs. In addition to the comments on the mailing list, a good indication of "community interest" would be, if someone indicated interest in taking a documented extension into a real implementation. >> Remembering a past tsvarea >> presentation at IETF-68 about Window Vista features, where Window >> scaling (PS) and ECN (PS) were disabled by default, and DSACK (Exp), >> F-RTO (Exp) enabled... > > (Nit: DSACK is PS and always has been. And, IMO this is important > because it is quite close to UTO because they both specify how to > share > information and not much else.) Sorry, by "DSACK" I meant Experimental RFC 3708, i.e. the usage part. The UTO document is different that RFC 2883 because it specifies both the new option, and recommended response on receiving the option. - Pasi --Apple-Mail-31--339474945 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHF2c5oNa7NH1G2csRAsoNAKC0/FMttljmHes8AufSeAUWtQ1qUgCg9VFD tK71LdLL13dgxoSwrUtYFEU= =lXi6 -----END PGP SIGNATURE----- --Apple-Mail-31--339474945-- --===============0488850562== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0488850562==-- From tcpm-bounces@ietf.org Thu Oct 18 10:20:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWE7-0000Wk-5b; Thu, 18 Oct 2007 10:19:55 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IiWE5-0000WJ-Tf for tcpm-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 10:19:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWE4-0000V5-HD for tcpm@ietf.org; Thu, 18 Oct 2007 10:19:52 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiWDy-0003RB-0f for tcpm@ietf.org; Thu, 18 Oct 2007 10:19:52 -0400 Received: from [192.168.1.44] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l9IEJT5G001280; Thu, 18 Oct 2007 07:19:30 -0700 (PDT) Message-ID: <47176B5F.2000009@isi.edu> Date: Thu, 18 Oct 2007 07:19:11 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pasi Sarolahti Subject: Re: [tcpm] WGLC for UTO References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> In-Reply-To: <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1322262210==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1322262210== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC73619CAD6CB546F294C9E68" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC73619CAD6CB546F294C9E68 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pasi Sarolahti wrote: > Ok, I think you are right that it is hard to come up with well-defined > experiments that would give some additional technical information about= > the UTO. But I don't understand where this requirement for experiments > comes from. I also ask, because this "what is the experiment?" question= > has come up quite a few times during the past couple of years for > Experimental documents in different WGs, and RFC 2026 does not say > anything about experiments: >=20 > The "Experimental" designation typically denotes a specification tha= t > is part of some research or development effort. Such a specificatio= n > is published for the general information of the Internet technical > community and as an archival record of the work, subject only to > editorial considerations and to verification that there has been > adequate coordination with the standards process (see below).... >=20 > (I believe many of the proposed TCP extensions are part of a research > project.) That has rarely been the case; more typically, the 'research' is being conducted by the proposer and the Internet community at large to determine the efficacy of a spec, and the 'experiment' is part of that 'research or development effort'. Joe --------------enigC73619CAD6CB546F294C9E68 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 iD8DBQFHF2tjE5f5cImnZrsRAnsEAJ44nv7VfO9GkNjfOEjkQsn+yelpBwCfY7TN SfVHjX9Qh2CoOJTzhLdf1xA= =iVIB -----END PGP SIGNATURE----- --------------enigC73619CAD6CB546F294C9E68-- --===============1322262210== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1322262210==-- From tcpm-bounces@ietf.org Thu Oct 18 13:38:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZIC-0006kn-FV; Thu, 18 Oct 2007 13:36:20 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IiZIA-0006fw-R2 for tcpm-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 13:36:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZI9-0006J9-Sh for tcpm@ietf.org; Thu, 18 Oct 2007 13:36:17 -0400 Received: from mx.neterion.com ([72.1.205.142] helo=owa.neterion.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiZI0-0002GY-Ih for tcpm@ietf.org; Thu, 18 Oct 2007 13:36:08 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] WGLC for UTO Date: Thu, 18 Oct 2007 13:36:07 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> In-Reply-To: <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC for UTO Thread-Index: AcgRkK7hCjlUlsbCR+W+gCRhga2uXAAHFh8w References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> From: "Caitlin Bestler" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org UTO manages to provide value for those who want it with no adverse impact on existing implementations. It is also easy for stacks (and stack offloads) to add support. So I fully support allowing this to proceed to standard. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 18 19:12:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IieW4-0004A8-Hc; Thu, 18 Oct 2007 19:11:00 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IieW2-00045a-GQ for tcpm-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 19:10:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IieW1-00042a-0l for tcpm@ietf.org; Thu, 18 Oct 2007 19:10:57 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IieW0-0005AI-BK for tcpm@ietf.org; Thu, 18 Oct 2007 19:10:56 -0400 Received: from [192.168.1.46] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l9INAS1a017753; Thu, 18 Oct 2007 16:10:29 -0700 (PDT) Message-ID: <4717E7D6.7000407@isi.edu> Date: Thu, 18 Oct 2007 16:10:14 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] WGLC for UTO References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1135297855==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1135297855== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4D5264FA49DC94470AD81D75" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4D5264FA49DC94470AD81D75 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I had a few minor points; I don't think any are showstoppers, but the WG might consider whether it'd be useful to fix these before this goes out the door. I think it should, since some are holes in behavior that ought to be defined. --- - MUST/MAY/SHOULD on the whole option I didn't see this; I'm not sure I care what the decision is, but it should be stated in the abstract and intro - sec 3 at "Before opening..." for two paragraphs This section uses 2119 language in ways I don't understand. An app that wishes to do something SHOULD? If it wishes to do something, it "DOES" it. I don't see a reason for 2119 there, or MAY at the end of that paragraph, or MAY in the next. In these cases, there are choices involved that determine what happens. You cannot dictated userland / application behavior when defining these events in this document, IMO. - sec 3 "In addition to" There is no reason in requiring (via SHOULD) a refresh of SYN-coordinated state. Either that state is coordinated, or it is not. If not, then the connection is in error. - sec 3 "A host that supports" What happens if there is no option space in the next outgoing segment? What happens if there is no option space at all? Do you tell the app? Do you do anything special? IMO, this deserves a separate section rather than just a note at the end of 3.0 - sec 3.1 "When a host" "In this case, they SHOULD" - they who? - sec 3.1 "In general" This is contrary to the default values. CHANGEABLE defaults to true, but ENABLED defaults to false. That means, IMO, that received UTO options would be dropped, not acted upon, in the default case. - sec 6 I thought this section should say a few specific things: 1) There are no new IANA namespaces. (which you say) 2) This doc requires IANA to assign a value from the TCP Option namespace, to be referred in section 3.3 accordingly. (which you don't quite ask for!) ----------------------------------------------------------------------- Very minor points, if an edit occurs: - intro near "applications can set" apps typically set/change this param via the OPEN/SEND socket calls, not the TCP OPEN/SEND API. The two use the same names; it'd be useful to be clear here. - intro/throughout 'other end' seems informal; other end of the TCP connection, etc.? - intro last two paragraphs these would be useful to move earlier - sec 3 'per-application basis' -> 'per-connection basis' - sec 3 at LOCAL_UTO it should be more clear what the relationship between the system-wide USER TIMEOUT and local USER_TIMEOUT is; alternately, a list of the global vars would be useful. - sec 3.1 "This means that" This paragraph is part of a discussion on checks and limits; this should not be the first place you introduce the "max" concept. - hysteresis? The doc doesn't describe how quickly the UTO can be changed by the remote end or application. Does it matter, e.g., for security reasons? - sec 3.2 "The host requirements rfc" "seconds is RECOMMENDED" -> append "in that RFC" (you're not doing the recommending; you're quoting 1122) - sec 3.2 If you retransmit the option and attach it to a particular byte, and the byte is ACKd, then why don't you KNOW the option has been received (i.e., second part of the handshake)? if the other end receives data over 1 window away from that byte, why doesn't it KNOW the source end knows it has been recieved (i.e., third part of the handshake)? About retransmission, IMO, it SHOULD be done - or else what's the point of this? - sec 3.4 "TCP implementations" -> "Current TCP implementations" - sec 4.1 Firewalls may parse this option in unencrypted TCP segments only. - sec 5 in addition to IPsec, cite RFC2385 for peer authentication --------------enig4D5264FA49DC94470AD81D75 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 iD8DBQFHF+fWE5f5cImnZrsRAgciAKCiIgvBzUBPTjBjV+7B1Lk6j3VBUgCg2KFh OKcCW9nRbT6+4GyH5FR59s4= =sFif -----END PGP SIGNATURE----- --------------enig4D5264FA49DC94470AD81D75-- --===============1135297855== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1135297855==-- From tcpm-bounces@ietf.org Fri Oct 19 22:37:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij4CU-000593-Cm; Fri, 19 Oct 2007 22:36:30 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ij4CT-00058K-85 for tcpm-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 22:36:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij4CR-00050S-QW for tcpm@ietf.org; Fri, 19 Oct 2007 22:36:27 -0400 Received: from mu-out-0910.google.com ([209.85.134.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ij4CH-0003w2-Ea for tcpm@ietf.org; Fri, 19 Oct 2007 22:36:23 -0400 Received: by mu-out-0910.google.com with SMTP id w8so867713mue for ; Fri, 19 Oct 2007 19:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=x3S1J4M/c7sTQC7jCw6JeUgQeMosogViNIY2X+90rEY=; b=XR7UoAgmj4i6v4aeBEme3cxFJDieEaL9YuVzLUIYn9/J8uAG1ly1WebPWo7kZdYq8V7TGxjoPfCj/rcASlZ2YIyF39fokFfjispyRNyLaMZuvLYvi1RiE4LuwyVkiz6Q6KxDZ+dKYr7ZRu/O9uiBvfVWrCKQo4hogUA7v6fqFn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dJTCQbmb9Ov2ZkIyezF6Eg0aFpJGbED8ECku0diQuoml4443vhM0YO7AZMlFVCtshmr0IoDroH0D7Cam+xeY4AGzw31cTRlFzqunSisJqKkdUw4LewjYOWrjlaUKUyeNMT5wpAd5B1RELYKTWdt9PUp/aUmR8/aRcFoIJSrDUd4= Received: by 10.86.4.2 with SMTP id 2mr1868321fgd.1192847734314; Fri, 19 Oct 2007 19:35:34 -0700 (PDT) Received: by 10.86.49.14 with HTTP; Fri, 19 Oct 2007 19:35:34 -0700 (PDT) Message-ID: Date: Fri, 19 Oct 2007 19:35:34 -0700 From: "Vishal Study" To: tcpm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [tcpm] SYN in SYN_RCVD state X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Consider the following scenario: 1. TCP client sends SYN to server; server goes to SYN_SENT state 2. server responds with SYN+ACK; server goes to SYN_RCVD state but SYN+ACK sent to client is lost somewhere in the network. 3. client re-sends SYN on its timeout (couple of seconds later) to server What should be the server behavior? Should it retransmit SYN+ACK or should it send a RST? thanks! _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Oct 21 03:03:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjUo2-0002DZ-8f; Sun, 21 Oct 2007 03:01:02 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IjUo0-00029p-RZ for tcpm-confirm+ok@megatron.ietf.org; Sun, 21 Oct 2007 03:01:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjUgx-00082C-Gq for tcpm@ietf.org; Sun, 21 Oct 2007 02:53:43 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjUgn-0003DY-4y for tcpm@ietf.org; Sun, 21 Oct 2007 02:53:33 -0400 X-IronPort-AV: E=Sophos;i="4.21,305,1188802800"; d="scan'208";a="240325089" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 20 Oct 2007 23:53:32 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9L6rWlp010078; Sat, 20 Oct 2007 23:53:32 -0700 Received: from [10.21.106.101] (sjc-vpnasa-610.cisco.com [10.21.106.101]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9L6rUsZ003899; Sun, 21 Oct 2007 06:53:31 GMT Message-ID: <471AF76A.3040306@cisco.com> Date: Sat, 20 Oct 2007 23:53:30 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1567; t=1192949612; x=1193813612; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20New=20=20I-D |Sender:=20; bh=qPfhHly4ca0E2xE8YHVTE2qhfr95q740nbvsKzsQGbU=; b=uIef4H470rEg9mWDfIDe6EJEduqlWC8iIMJqkjPr1LH4YO+BbV6r2mJOcH3sSIAYDgO1EL0d O1RiQNx9TQHH+ORmm9Gd1cKW/0LuXm/35O1ZQ3KoXvjY/EtZbUpYtX1uVYE74TxU01aFc0yxHt aL9RwLavppGlEzLwRsTfqZS74=; Authentication-Results: sj-dkim-1; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [tcpm] New I-D X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org A new version of an I-D has been posted on the IETF web site. http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-02.txt "TCP Maintenance and Minor Extensions", Mahesh Jethanandani, Murali Bashyam, 27-Oct-07, Abstract This document describes how a connection can remain infinitely in persist condition, and its Denial of Service (DoS) implication on the system, if there is no mechanism to recover from this anomaly. Summary: In this version of the draft, we have documented our experiment using a simple user level program to create the DoS scenario. The tests were run against both Apache and IIS HTTP servers. The test was run on a larger scale in the lab environment, where we were able to document the behavior of the servers. The test was then run against public and well known sites but on a smaller scale. Sniffer traces were captured to see the behavior of the connections. Our observations were that of the three well known public sites exhibited the DoS scenario. While site A had some mitigation technique in place, it was fairly easy to beat that. Site B and C had no mitigation in place and are currently vulnerable to the DoS attack. Solution: The draft documents some suggested solutions and describes why they are better than any of the techniques out there. In particular it talks about UTO and why UTO cannot solve this problem. It also talks about the role of applications and how they can help. Comments are welcome. /mahesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Oct 21 07:28:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjYwS-00053s-AU; Sun, 21 Oct 2007 07:26:00 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IjYwP-00053i-MZ for tcpm-confirm+ok@megatron.ietf.org; Sun, 21 Oct 2007 07:25:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjYwO-00053a-QY for tcpm@ietf.org; Sun, 21 Oct 2007 07:25:56 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjYwI-0000El-Kv for tcpm@ietf.org; Sun, 21 Oct 2007 07:25:56 -0400 Received: by nf-out-0910.google.com with SMTP id d21so722492nfb for ; Sun, 21 Oct 2007 04:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=GufR2/urlx1spyJ/Hr2JUxsqDxZgw4PGJPEu8iZz00A=; b=gnQc+J5em8YbT8xVBvkpxBoh5tWSFivL7iDPSDRbAt5R9OUaWCfDjyqHNyd3jik8cU1zkZc2hCGWR5dKZ4e9U7gZc+Bs7pnAwT2/xubBrUEtHevjcEdD9q5IpfoWxcb4Q2quMRViRP1fGtIQHSePkrCVbPO6PtevHWachZwCzsI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NhkdgFGQzElwtrNr6II8FhLqzFLbO1YXN7jc33RCb40KBLHAL7g0NFvlptZrxOVH6Ddz/GkVvquZKIi6GE1vJZkwGM3anBo8A1CGAikViORwv2b0k0MlfsiTUou4H/5DgYlj8pIceeRWabb9r/rOqFTgIvfn271JiaoSviC+BCQ= Received: by 10.86.49.13 with SMTP id w13mr2863377fgw.1192965925806; Sun, 21 Oct 2007 04:25:25 -0700 (PDT) Received: by 10.86.49.14 with HTTP; Sun, 21 Oct 2007 04:25:25 -0700 (PDT) Message-ID: Date: Sun, 21 Oct 2007 04:25:25 -0700 From: "Vishal Study" To: "Marco Mellia" Subject: Re: [tcpm] SYN in SYN_RCVD state In-Reply-To: <4719EB76.6040605@tlc.polito.it> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4719EB76.6040605@tlc.polito.it> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org But RFC 793, pg 71 seem to say that the server should send out a RST if SYN is rx in SYN-RCVD state (assuming SYN seq number is within the window, which is true in the example I had mentioned). Any thoughts on this? Thanks! On 10/20/07, Marco Mellia wrote: > Vishal Study ha scritto: > > Consider the following scenario: > > > > 1. TCP client sends SYN to server; server goes to SYN_SENT state > > > > 2. server responds with SYN+ACK; server goes to SYN_RCVD state > > but SYN+ACK sent to client is lost somewhere in the network. > > > > 3. client re-sends SYN on its timeout (couple of seconds later) to server > > > > What should be the server behavior? Should it retransmit SYN+ACK or > > should it send a RST? > > > > > Clearly the first case! > Marco > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Oct 21 15:20:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjgIo-00072R-7w; Sun, 21 Oct 2007 15:17:34 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IjgIl-00070q-OC for tcpm-confirm+ok@megatron.ietf.org; Sun, 21 Oct 2007 15:17:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjgIk-0006x1-KA for tcpm@ietf.org; Sun, 21 Oct 2007 15:17:30 -0400 Received: from harrier.viasat.com ([12.198.241.131] helo=VGAEXCH02.hq.corp.viasat.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjgIg-0005OI-A8 for tcpm@ietf.org; Sun, 21 Oct 2007 15:17:26 -0400 Received: from VGAEXCH01.hq.corp.viasat.com ([172.31.1.20]) by VGAEXCH02.hq.corp.viasat.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 Oct 2007 15:17:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] SYN in SYN_RCVD state Date: Sun, 21 Oct 2007 15:17:32 -0400 Message-ID: <0B0A20D0B3ECD742AA2514C8DDA3B06598DD79@VGAEXCH01.hq.corp.viasat.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] SYN in SYN_RCVD state Thread-Index: AcgT1gl8GWOUJ4kWSTGQcJjme45EFgAP5Drw From: "Agarwal, Anil" To: "Vishal Study" , "Marco Mellia" X-OriginalArrivalTime: 21 Oct 2007 19:17:34.0766 (UTC) FILETIME=[08FCFCE0:01C81417] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On October 21, 2007, Vishal wrote - > But RFC 793, pg 71 seem to say that the server should send out a RST > if SYN is rx in SYN-RCVD state (assuming SYN seq number is within the > window, which is true in the example I had mentioned). > Your example is covered by the rules on page 68 of RFC 793. The retransmitted SYN segment is a duplicate segment and is outside the receive window (SEG.SEQ is < RCV.NXT).=20 Hence, the receiver sends an Acknowledgement and discards the segment. Anil Anil Agarwal ViaSat Inc. Germantown, MD 20876 USA On 10/20/07, Marco Mellia wrote: > Vishal Study ha scritto: > > Consider the following scenario: > > > > 1. TCP client sends SYN to server; server goes to SYN_SENT state > > > > 2. server responds with SYN+ACK; server goes to SYN_RCVD state > > but SYN+ACK sent to client is lost somewhere in the network. > > > > 3. client re-sends SYN on its timeout (couple of seconds later) to server > > > > What should be the server behavior? Should it retransmit SYN+ACK or > > should it send a RST? > > > > > Clearly the first case! > Marco > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 22 14:04:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1cf-0006of-NV; Mon, 22 Oct 2007 14:03:29 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ik1cd-0006ir-F3 for tcpm-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 14:03:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1cc-0006i7-25 for tcpm@ietf.org; Mon, 22 Oct 2007 14:03:26 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ik1bY-00006S-2G for tcpm@ietf.org; Mon, 22 Oct 2007 14:03:26 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9MI1HNc027836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Oct 2007 11:01:18 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l9MI1HJR008021; Mon, 22 Oct 2007 11:01:17 -0700 (PDT) (envelope-from faber) Date: Mon, 22 Oct 2007 11:01:16 -0700 From: Ted Faber To: Vishal Study Subject: Re: [tcpm] SYN in SYN_RCVD state Message-ID: <20071022180116.GE24089@hut.isi.edu> References: <4719EB76.6040605@tlc.polito.it> Mime-Version: 1.0 In-Reply-To: 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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tcpm@ietf.org, Marco Mellia X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2074520409==" Errors-To: tcpm-bounces@ietf.org --===============2074520409== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="N1GIdlSm9i+YlY4t" Content-Disposition: inline --N1GIdlSm9i+YlY4t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 21, 2007 at 04:25:25AM -0700, Vishal Study wrote: > > Vishal Study ha scritto: > > > Consider the following scenario: > > > > > > 1. TCP client sends SYN to server; server goes to SYN_SENT state > > > > > > 2. server responds with SYN+ACK; server goes to SYN_RCVD state > > > but SYN+ACK sent to client is lost somewhere in the network. > > > > > > 3. client re-sends SYN on its timeout (couple of seconds later) to se= rver > > > > > > What should be the server behavior? Should it retransmit SYN+ACK or > > > should it send a RST? > > > > But RFC 793, pg 71 seem to say that the server should send out a RST > if SYN is rx in SYN-RCVD state (assuming SYN seq number is within the > window, which is true in the example I had mentioned). >=20 > Any thoughts on this? I think that because RCV.NEXT was set to SEG.SEQ+1 when the "server" entered SYN-RECEIVED state (as documented on page 66 of 793) the resent SYN is outside the window and will be acked. The "server's" SYN+ACK will be resent if it times out. --=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 --N1GIdlSm9i+YlY4t Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHHOVsaUz3f+Zf+XsRAnIWAKDSsSRy9MFIOfz21pY4ZgjMoRQx7gCfTQS4 xfrNqXslCZexhkJZya8NfhI= =reyv -----END PGP SIGNATURE----- --N1GIdlSm9i+YlY4t-- --===============2074520409== 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://www1.ietf.org/mailman/listinfo/tcpm --===============2074520409==-- From tcpm-bounces@ietf.org Mon Oct 22 15:41:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik37V-0006Jl-PN; Mon, 22 Oct 2007 15:39:25 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ik37T-0006Jb-Kp for tcpm-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 15:39:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik37S-0006JO-NI for tcpm@ietf.org; Mon, 22 Oct 2007 15:39:22 -0400 Received: from wx-out-0506.google.com ([66.249.82.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ik35y-0003zp-9L for tcpm@ietf.org; Mon, 22 Oct 2007 15:39:22 -0400 Received: by wx-out-0506.google.com with SMTP id s8so1244901wxc for ; Mon, 22 Oct 2007 12:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=VOcAdVqrMbhfZ4yeC91XNQ/gRBwrBGF13ZlFkYbZSPM=; b=sXUbAZIE0k/DE5ihDIdTTsPDOZ/6DfXUQue/k/td59oq03u65DRoSJ28/YUtnyRoopSzv8T1QtF8O8VXjKGS1yDhTgJVeTiDPVQYEST6O90VtIVOujL1893BvROEB6sfP7h1aZYuYfZRsT/qFKompJxGRbOv4n4GJelTRXYjZg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iP20h26aIBX5x+bMRfJYp2ByZNZH4CNBZ/83sJK3nzgjqNzwqPAyQpjE40GNNmXHn9gteBGgPx+y1KVEGUR7KMj/17d0tPoOB3Y+d5USAlbsiDz2ScfWB0nWNRUvv0VSK2NIP/WiATfcfd0qXwdz5aoqs1NO656+50q7xs2zyLU= Received: by 10.86.91.12 with SMTP id o12mr4065389fgb.1193081843996; Mon, 22 Oct 2007 12:37:23 -0700 (PDT) Received: by 10.86.49.14 with HTTP; Mon, 22 Oct 2007 12:37:23 -0700 (PDT) Message-ID: Date: Mon, 22 Oct 2007 12:37:23 -0700 From: "Vishal Study" To: "Ted Faber" Subject: Re: [tcpm] SYN in SYN_RCVD state In-Reply-To: <20071022180116.GE24089@hut.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4719EB76.6040605@tlc.polito.it> <20071022180116.GE24089@hut.isi.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi Ted: The server would retransmit SYN+ACK when server times out in SYN-RECEIVED state. I agree and have seen this. But, when the server hasn't timed out in SYN-RECEIVED state and it receives retransmitted SYN from client (due to client's timeout), what is the expected behavior on server side? Is server supposed to send SYN+ACK? Thanks! On 10/22/07, Ted Faber wrote: > On Sun, Oct 21, 2007 at 04:25:25AM -0700, Vishal Study wrote: > > > Vishal Study ha scritto: > > > > Consider the following scenario: > > > > > > > > 1. TCP client sends SYN to server; server goes to SYN_SENT state > > > > > > > > 2. server responds with SYN+ACK; server goes to SYN_RCVD state > > > > but SYN+ACK sent to client is lost somewhere in the network. > > > > > > > > 3. client re-sends SYN on its timeout (couple of seconds later) to server > > > > > > > > What should be the server behavior? Should it retransmit SYN+ACK or > > > > should it send a RST? > > > > > > But RFC 793, pg 71 seem to say that the server should send out a RST > > if SYN is rx in SYN-RCVD state (assuming SYN seq number is within the > > window, which is true in the example I had mentioned). > > > > Any thoughts on this? > > I think that because RCV.NEXT was set to SEG.SEQ+1 when the "server" > entered SYN-RECEIVED state (as documented on page 66 of 793) the resent > SYN is outside the window and will be acked. The "server's" SYN+ACK > will be resent if it times out. > > -- > 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://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 22 16:34:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik3xx-0000TT-M1; Mon, 22 Oct 2007 16:33:37 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ik3xv-0000TF-Vi for tcpm-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 16:33:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik3xv-0000T6-44 for tcpm@ietf.org; Mon, 22 Oct 2007 16:33:35 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik3xu-0008Tw-Cs for tcpm@ietf.org; Mon, 22 Oct 2007 16:33:35 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9MKW8ab029550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Oct 2007 13:32:08 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l9MKW8ZF030910; Mon, 22 Oct 2007 13:32:08 -0700 (PDT) (envelope-from faber) Date: Mon, 22 Oct 2007 13:32:08 -0700 From: Ted Faber To: Vishal Study Subject: Re: [tcpm] SYN in SYN_RCVD state Message-ID: <20071022203208.GD1430@hut.isi.edu> References: <4719EB76.6040605@tlc.polito.it> <20071022180116.GE24089@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: 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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1012758501==" Errors-To: tcpm-bounces@ietf.org --===============1012758501== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BI5RvnYi6R4T2M87" Content-Disposition: inline --BI5RvnYi6R4T2M87 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 22, 2007 at 12:37:23PM -0700, Vishal Study wrote: > Hi Ted: >=20 > The server would retransmit SYN+ACK when server times out in SYN-RECEIVED= state. > I agree and have seen this. >=20 > But, when the server hasn't timed out in SYN-RECEIVED state and it > receives retransmitted SYN from client (due to client's timeout), what > is the expected behavior on server side? Is server supposed to send > SYN+ACK? The spec says no. RFC793 p 69 gives the sequence number test and the ACK requirement: ---- first check sequence number SYN-RECEIVED STATE ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE CLOSE-WAIT STATE CLOSING STATE LAST-ACK STATE TIME-WAIT STATE Segments are processed in sequence. Initial tests on arrival are used to discard old duplicates, but further processing is done in SEG.SEQ order. If a segment's contents straddle the boundary between old and new, only the new parts should be processed. [table and some text snipped. None of it applies; the segment is outside the window and unacceptable. ] If an incoming segment is not acceptable, an acknowledgment should be sent in reply (unless the RST bit is set, if so drop the segment and return): After sending the acknowledgment, drop the unacceptable segment and return. ---- I can imagine an implementor sending a SYN+ACK here, but it would be outside the spec. I assume you have no basis for sending one. --=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 --BI5RvnYi6R4T2M87 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD4DBQFHHQjHaUz3f+Zf+XsRAnljAKDVEpYCPvyQlJJupOn8liJ6KyaqkwCYzjRf avgkrKcnjrcNiqqjkkeOPA== =1Iz+ -----END PGP SIGNATURE----- --BI5RvnYi6R4T2M87-- --===============1012758501== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1012758501==-- From tcpm-bounces@ietf.org Mon Oct 22 18:04:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik5MW-0000R1-6B; Mon, 22 Oct 2007 18:03:04 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ik5MU-0000Qq-Fm for tcpm-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 18:03:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik5MT-0000QL-I9 for tcpm@ietf.org; Mon, 22 Oct 2007 18:03:01 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik5MS-0007AW-VD for tcpm@ietf.org; Mon, 22 Oct 2007 18:03:01 -0400 Received: from [75.214.41.100] (100.sub-75-214-41.myvzw.com [75.214.41.100]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l9MM15N8028350; Mon, 22 Oct 2007 15:01:06 -0700 (PDT) Message-ID: <471D1D8C.5090503@isi.edu> Date: Mon, 22 Oct 2007 15:00:44 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] SYN in SYN_RCVD state References: <4719EB76.6040605@tlc.polito.it> <20071022180116.GE24089@hut.isi.edu> <20071022203208.GD1430@hut.isi.edu> In-Reply-To: <20071022203208.GD1430@hut.isi.edu> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0976772614==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0976772614== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6810FBC343E87C681C4CCA54" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6810FBC343E87C681C4CCA54 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Mon, Oct 22, 2007 at 12:37:23PM -0700, Vishal Study wrote: >> Hi Ted: >> >> The server would retransmit SYN+ACK when server times out in SYN-RECEI= VED state. >> I agree and have seen this. >> >> But, when the server hasn't timed out in SYN-RECEIVED state and it >> receives retransmitted SYN from client (due to client's timeout), what= >> is the expected behavior on server side? Is server supposed to send >> SYN+ACK? >=20 > The spec says no.=20 Agreed. FWIW, Ted already said there are two separate events: 1) the arriving retransmitted SYN causes the server to send an ACK 2) a timeout on the server associated with sending the SYN-ACK goes off, and the server resends the SYN-ACK then (1) doesn't cause (2); timeout does. Joe --------------enig6810FBC343E87C681C4CCA54 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 iD8DBQFHHR2ME5f5cImnZrsRAieBAJ9OcujF6CwseFGsC4K2DrJculIQNACgh4ge FRoKTCg06I3+HLSUWO4YDeE= =zG8V -----END PGP SIGNATURE----- --------------enig6810FBC343E87C681C4CCA54-- --===============0976772614== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0976772614==-- From tcpm-bounces@ietf.org Thu Oct 25 14:17:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il7ET-00059r-Ae; Thu, 25 Oct 2007 14:15:01 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Il7ES-00059h-UF for tcpm-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 14:15:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il7ES-00059Z-Ju for tcpm@ietf.org; Thu, 25 Oct 2007 14:15:00 -0400 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il7ES-00016p-CM for tcpm@ietf.org; Thu, 25 Oct 2007 14:15:00 -0400 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1Il7ES-0007Aj-0D for tcpm@ietf.org; Thu, 25 Oct 2007 14:15:00 -0400 Message-ID: <4720DD05.7040405@ca.afilias.info> Date: Thu, 25 Oct 2007 14:14:29 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] WGLC for UTO Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: -4.0 (----) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I endorse Joe Touch's comments of the 18th of Oct. I am in favor, with those changes, of advancing UTO. Brian Dickson _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 29 17:54:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImcXO-0001Qn-Sl; Mon, 29 Oct 2007 17:52:46 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImcXN-0001Q0-Nt for tcpm-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 17:52:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImcXN-0001Pc-CA for tcpm@ietf.org; Mon, 29 Oct 2007 17:52:45 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImcXM-00027m-QB for tcpm@ietf.org; Mon, 29 Oct 2007 17:52:45 -0400 X-IronPort-AV: E=Sophos;i="4.21,344,1188802800"; d="scan'208,217";a="411403808" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 29 Oct 2007 14:47:38 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9TLlcXO005104 for ; Mon, 29 Oct 2007 14:47:38 -0700 Received: from [10.21.106.209] (sjc-vpnasa-718.cisco.com [10.21.106.209]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9TLlbJr013042 for ; Mon, 29 Oct 2007 21:47:37 GMT Message-ID: <472654F9.5030308@cisco.com> Date: Mon, 29 Oct 2007 14:47:37 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tcpm@ietf.org DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3842; t=1193694458; x=1194558458; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Is=20this=20a=20problem? |Sender:=20; bh=KYEBnwurpKqF2tgLBHFfZmR2Y5/XQMRcdK9rfSoiCFo=; b=rVz3UMaEwXeqcc7whM0T7McfVnHLELMDMwIdz0j9WoKRV0BEMfsJpTezLuGL7wxGks3A0Esa 8qOX/xE9mPMFq5mxPab/OtF7FKpxzTclJ/XQt0ZMo3rgfkGA5lNIcWUKLS+FVPGZfuDYac/7D1 ZeskdiHhFn7ucnw1pPoM5OQ/0=; Authentication-Results: sj-dkim-1; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [tcpm] Is this a problem? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1911801472==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============1911801472== Content-Type: multipart/alternative; boundary="------------010600070207030006020204" This is a multi-part message in MIME format. --------------010600070207030006020204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, We have documented a case of HTTP servers that are prone to resource starvation with the use of a small user level program. The program does not require any special privileges or changes in the kernel. The user level program on the client opens a connection to a HTTP server, sends a GET request for a large file (larger than the advertised window of the client) but never reads the response. Three well-known, public sites were tested for this vulnerability. The two most common HTTP servers, Apache and IIS were the target. While one site had put mitigation technique in place, the others had none. With the latter two we were able to hold connections in ESTABLISHED state for days. The former site had a mitigation in place with a fixed timeout of 11 min., which was easy to guess and work around. We (the authors) believe that this is a huge problem. What do you folks feel? Previous responses to this documentation has been that it is a application problem. It is clear from our experimentation that most HTTP servers (and FTP too) have not implemented any mitigation techniques. We believe that this problem exists across the whole range of TCP based applications prevalent on the internet, although our experiments were limited to the web application. Where applications have tried to put mitigation techniques in place, workaround has been easy. This is mainly because applications do not have the same amount of visibility as TCP does on the state of the connection. If you are interested in reading the draft, you will find it here . /mahesh --------------010600070207030006020204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Folks,

We have documented a case of HTTP servers that are prone to resource starvation with the use of a small user level program. The program does not require any special privileges or changes in the kernel. The user level program on the client opens a connection to a HTTP server, sends a GET request for a large file (larger than the advertised window of the client) but never reads the response.

Three well-known, public sites were tested for this vulnerability. The two most common HTTP servers, Apache and IIS were the target. While one site had put mitigation technique in place, the others had none. With the latter two we were able to hold connections in ESTABLISHED state for days. The former site had a mitigation in place with a fixed timeout of 11 min., which was easy to guess and work around.

We (the authors) believe that this is a huge problem. What do you folks feel?


Previous responses to this documentation has been that it is a application problem. It is clear from our experimentation that most HTTP servers (and FTP too) have not implemented any mitigation techniques. We believe that this problem exists across the whole range of TCP based applications prevalent on the internet, although our experiments were limited to the web application. Where applications have tried to put mitigation techniques in place, workaround has been easy. This is mainly because applications do not have the same amount of visibility as TCP does on the state of the connection.

If you are interested in reading the draft, you will find it here.

/mahesh
--------------010600070207030006020204-- --===============1911801472== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1911801472==-- From tcpm-bounces@ietf.org Mon Oct 29 18:04:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImciJ-0004GR-7F; Mon, 29 Oct 2007 18:04:03 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImciI-0004G6-43 for tcpm-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 18:04:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImciH-0004Fu-Nx for tcpm@ietf.org; Mon, 29 Oct 2007 18:04:01 -0400 Received: from mx.neterion.com ([72.1.205.142] helo=owa.neterion.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImciH-0002u6-FE for tcpm@ietf.org; Mon, 29 Oct 2007 18:04:01 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] Is this a problem? Date: Mon, 29 Oct 2007 18:04:00 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7702765252@nekter> In-Reply-To: <472654F9.5030308@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Is this a problem? Thread-Index: AcgadvbLvjljhruEQAaiZp2HBKxqhgAAGJbw References: <472654F9.5030308@cisco.com> From: "Caitlin Bestler" To: "Mahesh Jethanandani" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0606004907==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0606004907== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81A77.9B740904" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81A77.9B740904 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is indeed a problem. I'm just not convinced it's a transport problem. =20 Only the application layer has enough information to know when a client's behavior is abusive and/or suspicious. The transport layer should remain militantly ignorant of these matters. =20 ------_=_NextPart_001_01C81A77.9B740904 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is indeed a problem. I’m just not convinced = it’s a transport problem.

 

Only the application layer has enough information to know = when a client’s

behavior is abusive and/or suspicious. The transport = layer should remain

militantly ignorant of these = matters.

 

------_=_NextPart_001_01C81A77.9B740904-- --===============0606004907== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0606004907==-- From tcpm-bounces@ietf.org Mon Oct 29 18:44:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImdKG-0003kb-Fb; Mon, 29 Oct 2007 18:43:16 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImdKF-0003kL-7G for tcpm-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 18:43:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImdKE-0003kD-EY for tcpm@ietf.org; Mon, 29 Oct 2007 18:43:14 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImdK9-0005HT-5g for tcpm@ietf.org; Mon, 29 Oct 2007 18:43:14 -0400 Received: from [70.213.237.56] (56.sub-70-213-237.myvzw.com [70.213.237.56]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l9TMgqn2017753; Mon, 29 Oct 2007 15:42:53 -0700 (PDT) Message-ID: <472661E1.9020805@isi.edu> Date: Mon, 29 Oct 2007 15:42:41 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mahesh Jethanandani Subject: Re: [tcpm] Is this a problem? References: <472654F9.5030308@cisco.com> In-Reply-To: <472654F9.5030308@cisco.com> X-Enigmail-Version: 0.95.4 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0442104579==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0442104579== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0FD43574470B37B8D68D6650" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0FD43574470B37B8D68D6650 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mahesh Jethanandani wrote: > Folks, >=20 > We have documented a case of HTTP servers that are prone to resource > starvation with the use of a small user level program. The program does= > not require any special privileges or changes in the kernel. The user > level program on the client opens a connection to a HTTP server, sends = a > GET request for a large file (larger than the advertised window of the > client) but never reads the response. >=20 > Three well-known, public sites were tested for this vulnerability.=20 > The two most common HTTP servers, Apache and IIS were the target. > While one site had put mitigation technique in place, the others had > none. With the latter two we were able to hold connections in > ESTABLISHED state for days. The former site had a mitigation in place > with a fixed timeout of 11 min., which was easy to guess and work > around. >=20 > We (the authors) believe that this is a huge problem. What do you > folks feel? I agree with Caitlin and your previous responses; this is an application problem. > Previous responses to this documentation has been that it is a > application problem. It is clear from our experimentation that most HTT= P > servers (and FTP too) have not implemented any mitigation techniques. W= e > believe that this problem exists across the whole range of TCP based > applications prevalent on the internet, although our experiments were > limited to the web application. Where applications have tried to put > mitigation techniques in place, workaround has been easy. This is mainl= y > because applications do not have the same amount of visibility as TCP > does on the state of the connection. Applications know when a connection hasn't closed. They also know when a write would block due to insufficient socket resources. Either or both of these provide sufficient visibility to avoid the problem entirely. As you note, applications can solve this easily. Since it's their obligation to do so, and it's easy for them to do so, there's no reason to complicate the transport layer with this responsibility. Furthermore, does the propose solution solve the DOS problem? Aren't there other ways to keep a source stalled? (i.e., what about continued SACKs? or repeated ACKs indicating a lost segment? at the very least, we could ACK a byte at a time, sending 3-4 duplicate ACKs for each byte, which would keep the sender from opening its window and stall things a lot...). Joe --------------enig0FD43574470B37B8D68D6650 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 iD8DBQFHJmHhE5f5cImnZrsRAll7AKDh/Q5nxgli2sXDSZhfDWE1XHfcawCgme5Q STvauAqRJd40w9T22TODWqg= =PDNo -----END PGP SIGNATURE----- --------------enig0FD43574470B37B8D68D6650-- --===============0442104579== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0442104579==-- From tcpm-bounces@ietf.org Mon Oct 29 21:24:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imfnb-0007X6-OV; Mon, 29 Oct 2007 21:21:43 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImfnZ-0007Ww-JR for tcpm-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 21:21:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImfnZ-0007Wk-7f for tcpm@ietf.org; Mon, 29 Oct 2007 21:21:41 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImfnY-0005HL-Nr for tcpm@ietf.org; Mon, 29 Oct 2007 21:21:41 -0400 X-IronPort-AV: E=Sophos;i="4.21,345,1188802800"; d="scan'208,217";a="244167043" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2007 17:19:45 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9U0JiWu014825; Mon, 29 Oct 2007 17:19:44 -0700 Received: from [10.21.106.209] (sjc-vpnasa-718.cisco.com [10.21.106.209]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9U0JiTg024245; Tue, 30 Oct 2007 00:19:44 GMT Message-ID: <4726789F.8090906@cisco.com> Date: Mon, 29 Oct 2007 17:19:43 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] Is this a problem? References: <472654F9.5030308@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD7702765252@nekter> In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7702765252@nekter> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5988; t=1193703584; x=1194567584; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Re=3A=20[tcpm]=20Is=20this=20a=20problem? |Sender:=20; bh=bEGetLokrzcZkNGpXiTfVoizN0CIXg77z68INaGpx9w=; b=SK7oqmvrrKuxDx2nIWbh/cdTTl7H422nVeFBYNnjm3xzMo6fknsKxh8XevIBATf7bVNZGaaR dSCysilgGJQCTdyg+Y3Mrhji1lmmBhFAJlqua8uQnKLkZH96LoLwdlI0; Authentication-Results: sj-dkim-3; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0897820725==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0897820725== Content-Type: multipart/alternative; boundary="------------090700010209010108080505" This is a multi-part message in MIME format. --------------090700010209010108080505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Caitlin, Caitlin Bestler wrote: > > This is indeed a problem. I'm just not convinced it's a transport problem. > > > > Only the application layer has enough information to know when a client's > > behavior is abusive and/or suspicious. > Applications if anything have less knowledge than TCP on why a connection is not making progress. In this particular case, HTTP could not make a distinction between a connection not making progress because of congestion in the network or because the client is advertising zero window. And yet all Apache can do is to reset the connection after a fixed amount of time. Again, HTTP may know how many of its connections are in the stuck state, it will not know how many FTP connections are seeing the same issue or how seriously constrained the system is. We have found that a fixed timeout also does not work. It is easy to guess and work around as we did with our client program. The solution has to be adaptive to the condition which in this case involves TCP and applications have little knowledge of the state of all of TCP connections. > > The transport layer should remain > > militantly ignorant of these matters. > When it impacts TCP's ability to function, I can hardly see that being ignorant will help. --------------090700010209010108080505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Caitlin,

Caitlin Bestler wrote:

This is indeed a problem. I’m just not convinced it’s a transport problem.

 

Only the application layer has enough information to know when a client’s

behavior is abusive and/or suspicious.

Applications if anything have less knowledge than TCP on why a connection is not making progress. In this particular case, HTTP could not make a distinction between a connection not making progress because of congestion in the network or because the client is advertising zero window. And yet all Apache can do is to reset the connection after a fixed amount of time. Again, HTTP may know how many of its connections are in the stuck state, it will not know how many FTP connections are seeing the same issue or how seriously constrained the system is.

We have found that a fixed timeout also does not work. It is easy to guess and work around as we did with our client program.

The solution has to be adaptive to the condition which in this case involves TCP and applications have little knowledge of the state of all of TCP connections.

The transport layer should remain

militantly ignorant of these matters.

When it impacts TCP's ability to function, I can hardly see that being ignorant will help.
--------------090700010209010108080505-- --===============0897820725== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0897820725==-- From tcpm-bounces@ietf.org Tue Oct 30 01:19:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImjTD-0002vl-2J; Tue, 30 Oct 2007 01:16:55 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImjTB-0002vg-2h for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 01:16:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImjTA-0002vY-44 for tcpm@ietf.org; Tue, 30 Oct 2007 01:16:52 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImjT9-0004EI-4U for tcpm@ietf.org; Tue, 30 Oct 2007 01:16:52 -0400 Received: from [192.168.1.44] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l9U5G4ud017427; Mon, 29 Oct 2007 22:16:05 -0700 (PDT) Message-ID: <4726BE0B.9010406@isi.edu> Date: Mon, 29 Oct 2007 22:15:55 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mahesh Jethanandani Subject: Re: [tcpm] Is this a problem? References: <472654F9.5030308@cisco.com> <78C9135A3D2ECE4B8162EBDCE82CAD7702765252@nekter> <4726789F.8090906@cisco.com> In-Reply-To: <4726789F.8090906@cisco.com> X-Enigmail-Version: 0.95.4 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tcpm@ietf.org, Caitlin Bestler X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0827481749==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0827481749== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig25DC3EF5E8B976232202F6CE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig25DC3EF5E8B976232202F6CE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Mahesh Jethanandani wrote: > Caitlin, >=20 > Caitlin Bestler wrote: >> >> This is indeed a problem. I=92m just not convinced it=92s a transport = problem. >> Only the application layer has enough information to know when a clien= t=92s >> behavior is abusive and/or suspicious. >> > Applications if anything have less knowledge than TCP on why a > connection is not making progress. In this particular case, HTTP could > not make a distinction between a connection not making progress because= > of congestion in the network or because the client is advertising zero > window.=20 If an application - or host - has limited resources, it doesn't matter why a connection isn't making progress. > And yet all Apache can do is to reset the connection after a > fixed amount of time. Again, HTTP may know how many of its connections > are in the stuck state, it will not know how many FTP connections are > seeing the same issue or how seriously constrained the system is. There is no rule that TCP connections "see" each other per se; from within a single connection, an implementation could be able to access only a single connection's state. And, ultimately, a system is constrained when it runs out of processor or memory - which have nothing to do necessarily with the connections in progress. I.e., an application can ask the OS - or the OS can tell the app - when such limitations come into play anyway. > We have found that a fixed timeout also does not work. It is easy to > guess and work around as we did with our client program. >=20 > The solution has to be adaptive to the condition which in this case > involves TCP and applications have little knowledge of the state of all= > of TCP connections. >> >> The transport layer should remain >> militantly ignorant of these matters. >> > When it impacts TCP's ability to function, I can hardly see that being > ignorant will help. You're declaring that someone who sends a zero receive window longer than you expect to be noncompliant. There's nothing in the spec that says that a TCP connection has to make forward progress in any fixed timescale - even based on RTTs. This has allowed TCP to proceed over shared links where less than one segment succeeds per RTT - e.g., congested transatlantic links. My concern is that this modification will disable correct behavior in the corner cases. Not all TCP connections must - or should - work only for the common cases= =2E Joe --------------enig25DC3EF5E8B976232202F6CE 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 iD8DBQFHJr4LE5f5cImnZrsRAinRAJ9obOG0/qz1OyRvTT2tXtc3FNcrTQCgjku+ 652m/I9CcUhbmB8v5ykiy98= =xi0z -----END PGP SIGNATURE----- --------------enig25DC3EF5E8B976232202F6CE-- --===============0827481749== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0827481749==-- From tcpm-bounces@ietf.org Tue Oct 30 02:01:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imk92-0000sC-Go; Tue, 30 Oct 2007 02:00:08 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Imk91-0000la-JZ for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 02:00:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imk91-0000lS-5t for tcpm@ietf.org; Tue, 30 Oct 2007 02:00:07 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imk90-0005IU-FH for tcpm@ietf.org; Tue, 30 Oct 2007 02:00:07 -0400 Received: from [192.168.1.44] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l9U5xqwx026301; Mon, 29 Oct 2007 22:59:53 -0700 (PDT) Message-ID: <4726C84F.9070706@isi.edu> Date: Mon, 29 Oct 2007 22:59:43 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? References: <322287.14097.qm@web31709.mail.mud.yahoo.com> In-Reply-To: <322287.14097.qm@web31709.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.4 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0073304886==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0073304886== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEEEBDAC87DD0B7D2C028861E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEEEBDAC87DD0B7D2C028861E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MURALI BASHYAM wrote: > I agree with Caitlin and your previous responses; this is an > application > problem. >=20 > So we are placing the responsibility for protecting system-wide TCP res= ources such as buffers > and connections on all the TCP based applications out there?=20 Yes - applications can always start extra TCP connections, and can override default socket sizes, so those resources are already under application control. They are managed by the OS as a whole, i.e., when the OS runs out, the application gets that feedback, and reacts according= ly. > Which "application" > are you referring to here? BGP? NFS ? CIFS? HTTP? SMTP? FTP? The entire= application > community? Potentially several or all of these apps are vulnerable. How= do we bring all these=20 > protocols into a single agreeable framework and accomplish the right t= hing?=20 Any application can misbehave. Any application can hold off receiving data it has asked for. If the sender side application cares, it cuts off the connection. If it doesn't, it leaves the connection in place. TCP doesn't read minds. =2E.. > Applications cannot discriminate between a connection that's stalled du= e to network > congestion and a connection that's being stalled by a malicious receive= r who has closed > his receive window forever. And for how long the connection has been in= in this stalled state etc. Applications shouldn't discriminate between these. First, there's no difference between a connection that's being stalled maliciously and one that's being stalled legitimately. There's no requirement that TCP not be stalled for a particular interval. You'd be disabling TCP's ability (feature) to work over such environments arbitrarily if you change this. > And what about multi-application servers? Surely each application here = is running as an > independent process and indvidually they don't have the system wide awa= reness that TCP has... Nor should it. First, as I noted in other mail, TCP doesn't necessarily have system-wide information - that's an *assumption*. You're talking about the kernel making decisions, not TCP. TCP could be implemented in user space, or in the kernel in a way that it is isolated from information about other connections. That's another reason this isn't TCP's job. > As you note, applications can solve this easily. Since it's their > obligation to do so, and it's easy for them to do so, there's no reason= > to complicate the transport layer with this responsibility. >=20 > Applications can implement a fixed or even an adaptive timeout, but unl= ess they can make > the above distinction i am pointing out, they will be knocking out legi= timate (albeit slow)=20 > connections, i.e there will be a fairness issue.=20 And they'll still be knocking out legitimate (albeit slow) receivers that have a good reason to send a zero window for some period of time - like while you insert a new DVD to backup to. > Applications do not have visibility into TCP connection > sender's state to solve the fairness issue.=20 Visibility into the state of a single connection does not solve this issue. You simply know that the receiver is not accepting data at this time - this is a feature of TCP. It's not a bug. > A solution which penalizes legitimate connections is clearly a broken o= ne. Agreed! > Furthermore, does the propose solution solve the DOS problem? Aren't > there other ways to keep a source stalled? (i.e., what about continued > SACKs? or repeated ACKs indicating a lost segment? at the very least, > we > could ACK a byte at a time, sending 3-4 duplicate ACKs for each byte, > which would keep the sender from opening its window and stall things a > lot...). > How do you propose to carry out these attacks without changing the clie= nt side TCP stack in the=20 > windows or linux kernel? The vulnerability which we have demonstrated a= nd addressed requires a simple user=20 > level program which anyone with a little, basic programming background = can write today. Clearly the bar to creating these attacks you are pointi= ng out is higher. It's not a vulnerability unless the application lets it be one. It's a feature, and no, it shouldn't be disabled just because one interpretation of what is happening is "DOS attack". Is it a DOS attack to receive lots of connections at once? Is it a DOS attack to recieve a connection that opens then doesn't send data for a while? All of these are legitimate behaviors of TCP - as is having the receiver stall the sender. Joe --------------enigEEEBDAC87DD0B7D2C028861E 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 iD8DBQFHJshPE5f5cImnZrsRAjVDAKDJFJgG5sbUNxa0uQWJdJLEmwocUgCgysDb OKIHcA4Cfte/8tgCRRuEZlo= =Z0iw -----END PGP SIGNATURE----- --------------enigEEEBDAC87DD0B7D2C028861E-- --===============0073304886== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0073304886==-- From tcpm-bounces@ietf.org Tue Oct 30 02:12:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImkK7-0000uS-O1; Tue, 30 Oct 2007 02:11:35 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImkK6-0000uL-ST for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 02:11:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImkK6-0000uB-GX for tcpm@ietf.org; Tue, 30 Oct 2007 02:11:34 -0400 Received: from web31709.mail.mud.yahoo.com ([68.142.201.189]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ImkK5-0005c6-Rw for tcpm@ietf.org; Tue, 30 Oct 2007 02:11:34 -0400 Received: (qmail 14528 invoked by uid 60001); 30 Oct 2007 05:44:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=FPa7Di87kFk8mlLnpvxPpjiCaen7ViRHRnz0w188NaUmwg0nQpaEwpiT8+K7IgGT247JrcOPbB8E/nF+Ew7eWbqcPtgeMY8PLmRnr5DuEE81Ic5mb82yycQ/MjjMpc/lGJc5KOjg/4e6eni0jw34e7d1p9z3n3a3K/SW5reErI4=; X-YMail-OSG: NevsUwwVM1nPEPZ7r1TXa4ZrohtM7swvG5lSQITHBoCqJQ1ui_9DqjbEhXLWB_g7Dg-- Received: from [67.161.9.166] by web31709.mail.mud.yahoo.com via HTTP; Mon, 29 Oct 2007 22:44:52 PDT X-Mailer: YahooMailRC/814.05 YahooMailWebService/0.7.152 Date: Mon, 29 Oct 2007 22:44:52 -0700 (PDT) From: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? To: Joe Touch , Mahesh Jethanandani MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <322287.14097.qm@web31709.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org ----- Original Message ---- From: Joe Touch To: Mahesh Jethanandani Cc: tcpm@ietf.org Sent: Monday, October 29, 2007 3:42:41 PM Subject: Re: [tcpm] Is this a problem? Mahesh Jethanandani wrote: > Folks, > > We have documented a case of HTTP servers that are prone to resource > starvation with the use of a small user level program. The program does > not require any special privileges or changes in the kernel. The user > level program on the client opens a connection to a HTTP server, sends a > GET request for a large file (larger than the advertised window of the > client) but never reads the response. > > Three well-known, public sites were tested for this vulnerability. > The two most common HTTP servers, Apache and IIS were the target. > While one site had put mitigation technique in place, the others had > none. With the latter two we were able to hold connections in > ESTABLISHED state for days. The former site had a mitigation in place > with a fixed timeout of 11 min., which was easy to guess and work > around. > > We (the authors) believe that this is a huge problem. What do you > folks feel? I agree with Caitlin and your previous responses; this is an application problem. So we are placing the responsibility for protecting system-wide TCP resources such as buffers and connections on all the TCP based applications out there? Which "application" are you referring to here? BGP? NFS ? CIFS? HTTP? SMTP? FTP? The entire application community? Potentially several or all of these apps are vulnerable. How do we bring all these protocols into a single agreeable framework and accomplish the right thing? > Previous responses to this documentation has been that it is a > application problem. It is clear from our experimentation that most HTTP > servers (and FTP too) have not implemented any mitigation techniques. We > believe that this problem exists across the whole range of TCP based > applications prevalent on the internet, although our experiments were > limited to the web application. Where applications have tried to put > mitigation techniques in place, workaround has been easy. This is mainly > because applications do not have the same amount of visibility as TCP > does on the state of the connection. Applications know when a connection hasn't closed. They also know when a write would block due to insufficient socket resources. Either or both of these provide sufficient visibility to avoid the problem entirely. Applications cannot discriminate between a connection that's stalled due to network congestion and a connection that's being stalled by a malicious receiver who has closed his receive window forever. And for how long the connection has been in in this stalled state etc. And what about multi-application servers? Surely each application here is running as an independent process and indvidually they don't have the system wide awareness that TCP has... As you note, applications can solve this easily. Since it's their obligation to do so, and it's easy for them to do so, there's no reason to complicate the transport layer with this responsibility. Applications can implement a fixed or even an adaptive timeout, but unless they can make the above distinction i am pointing out, they will be knocking out legitimate (albeit slow) connections, i.e there will be a fairness issue. Applications do not have visibility into TCP connection sender's state to solve the fairness issue. A solution which penalizes legitimate connections is clearly a broken one. Furthermore, does the propose solution solve the DOS problem? Aren't there other ways to keep a source stalled? (i.e., what about continued SACKs? or repeated ACKs indicating a lost segment? at the very least, we could ACK a byte at a time, sending 3-4 duplicate ACKs for each byte, which would keep the sender from opening its window and stall things a lot...). How do you propose to carry out these attacks without changing the client side TCP stack in the windows or linux kernel? The vulnerability which we have demonstrated and addressed requires a simple user level program which anyone with a little, basic programming background can write today. Clearly the bar to creating these attacks you are pointing out is higher. Joe __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Oct 30 04:06:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imm60-0006EQ-FS; Tue, 30 Oct 2007 04:05:08 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Imm5y-0006E9-W6 for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 04:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imm5t-0006As-F9 for tcpm@ietf.org; Tue, 30 Oct 2007 04:05:01 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imm5n-0004zC-8z for tcpm@ietf.org; Tue, 30 Oct 2007 04:05:01 -0400 X-IronPort-AV: E=Sophos;i="4.21,346,1188802800"; d="scan'208";a="244277376" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2007 23:46:02 -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 l9U6k2Bm002278; Mon, 29 Oct 2007 23:46:02 -0700 Received: from [10.21.106.209] (sjc-vpnasa-718.cisco.com [10.21.106.209]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l9U6k1lX014411; Tue, 30 Oct 2007 06:46:01 GMT Message-ID: <4726D328.4040209@cisco.com> Date: Mon, 29 Oct 2007 23:46:00 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch Subject: Re: [tcpm] Is this a problem? References: <472654F9.5030308@cisco.com> <472661E1.9020805@isi.edu> In-Reply-To: <472661E1.9020805@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2319; t=1193726762; x=1194590762; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Re=3A=20[tcpm]=20Is=20this=20a=20problem? |Sender:=20; bh=Foc0APi3BGn2TkO9E04nvIorsnRKnPqdZvMR/MtK634=; b=BQWDUdRQYMf/tz0D2GpT7gwmgNlmVFaC42jR5TSP7JHrgbuzq/ck5BatG8inQm403QXpR1+6 NwZAT/6kXP8e/j4ABPokcb4e/hfLc/2Z+g8XjDEVCJVEi0bKRXqKIE/H; Authentication-Results: sj-dkim-3; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > Applications know when a connection hasn't closed. They also know when a > write would block due to insufficient socket resources. Either or both > of these provide sufficient visibility to avoid the problem entirely. > Knowing those two facts only gives applications some of the information. It still would not know why the write is blocked? You agree that penalizing legitimate connections is a broken implementation. How does application then differentiate between a legitimate connection that is slow and one that is malicious (by advertising a zero window for an extended period of time)? It is important to understand that a slow legitimate connection is a behavior that is almost entirely contained within TCP but the client sending zero window can be a case of a malicious user level program (read externally triggered attack) not reading data. Looking into the TCP connection state allows us to differentiate between the two different conditions and treat the connections fairly. > As you note, applications can solve this easily. Since it's their > obligation to do so, and it's easy for them to do so, there's no reason > to complicate the transport layer with this responsibility. > The reality is that few applications if any implement any mechanism to detect a connection that is stalled in such a manner. Our experiment shows that the most commonly used application (HTTP) used on some of the biggest web sites are vulnerable today holding on to connections in EST state for days. Yes, they should implement a mechanism, but can TCP count on it. What is it supposed to do if applications do not clear connections in a timely manner. > Furthermore, does the propose solution solve the DOS problem? Aren't > there other ways to keep a source stalled? (i.e., what about continued > SACKs? or repeated ACKs indicating a lost segment? at the very least, we > could ACK a byte at a time, sending 3-4 duplicate ACKs for each byte, > which would keep the sender from opening its window and stall things a > lot...). > You are talking about a malicious TCP implementation that would require special permissions in a DDoS scenario. What we used was a simple user level program that required no special privileges to run. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Oct 30 09:35:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImrDP-0004gJ-1Z; Tue, 30 Oct 2007 09:33:07 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImrDO-0004gD-Er for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 09:33:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImrDO-0004g5-49 for tcpm@ietf.org; Tue, 30 Oct 2007 09:33:06 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImrDN-0003LF-Eg for tcpm@ietf.org; Tue, 30 Oct 2007 09:33:06 -0400 Received: from [192.168.1.44] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l9UDWjfx013221; Tue, 30 Oct 2007 06:32:45 -0700 (PDT) Message-ID: <47273276.4050300@isi.edu> Date: Tue, 30 Oct 2007 06:32:38 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mahesh Jethanandani Subject: Re: [tcpm] Is this a problem? References: <472654F9.5030308@cisco.com> <472661E1.9020805@isi.edu> <4726D328.4040209@cisco.com> In-Reply-To: <4726D328.4040209@cisco.com> X-Enigmail-Version: 0.95.4 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0911613191==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0911613191== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFD3362D04A7C368AB5AE8A0E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFD3362D04A7C368AB5AE8A0E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mahesh Jethanandani wrote: >=20 >=20 > Joe Touch wrote: >> Applications know when a connection hasn't closed. They also know when= a >> write would block due to insufficient socket resources. Either or both= >> of these provide sufficient visibility to avoid the problem entirely. >> =20 > Knowing those two facts only gives applications some of the information= =2E > It still would not know why the write is blocked? You agree that > penalizing legitimate connections is a broken implementation.=20 My point is that your solution does this. > How does > application then differentiate between a legitimate connection that is > slow and one that is malicious (by advertising a zero window for an > extended period of time)? Since it never can, it shouldn't try. It depends on the application. That's why it's the application's decision as to when to give up on a client, not TCP's. > It is important to understand that a slow legitimate connection is a > behavior that is almost entirely contained within TCP but the client > sending zero window can be a case of a malicious user level program > (read externally triggered attack) not reading data.=20 I agree that sending a zero window CAN be an attack. Unfortunately, it CAN be legitimate behavior. Since you agree we can't decide between the two at the TCP layer, we should not fix this at that layer either. > Looking into the > TCP connection state allows us to differentiate between the two > different conditions and treat the connections fairly. You are asserting that "all zero-window receivers are attackers". This is incorrect, and leading you to the conclusion that TCP should fix this.= A legitimate receiver could have a backed-up application - i.e., a slow processor, more pressing other applications, etc. - which could cause it to advertise a zero window for an arbitrary time. There is no requirement of timeliness in TCP data processing. When data arrives at the receiver, if it backs up, the receiver could send a zero window. That condition could legitimately persist a long time - I gave a real example before (a backup device waiting for a human to insert a new DVD). >> As you note, applications can solve this easily. Since it's their >> obligation to do so, and it's easy for them to do so, there's no reaso= n >> to complicate the transport layer with this responsibility. >> =20 > The reality is that few applications if any implement any mechanism to > detect a connection that is stalled in such a manner. I agree. That doesn't make it TCP's responsibility. > Our experiment > shows that the most commonly used application (HTTP) used on some of > the biggest web sites are vulnerable today holding on to connections in= > EST state for days. Yes, they should implement a mechanism, but can TCP= > count on it. What is it supposed to do if applications do not clear > connections in a timely manner. TCP is the servant of the application, not its master. If the application doesn't clear connections TCP should - and must - sit and wai= t. >> Furthermore, does the propose solution solve the DOS problem? Aren't >> there other ways to keep a source stalled? (i.e., what about continued= >> SACKs? or repeated ACKs indicating a lost segment? at the very least, = we >> could ACK a byte at a time, sending 3-4 duplicate ACKs for each byte, >> which would keep the sender from opening its window and stall things a= >> lot...). >> =20 > You are talking about a malicious TCP implementation that would require= > special permissions in a DDoS scenario. What we used was a simple user > level program that required no special privileges to run. Yes, but as I've shown, your case is indistinguishable from legitimate behavior. Let's not 'fix' that. Joe --------------enigFD3362D04A7C368AB5AE8A0E 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 iD8DBQFHJzJ9E5f5cImnZrsRAhRwAKCx6oPD1zcrZRqjdMMWda0ma6jRFgCfS8KM 1Et27ntoMZrP0FU2THZPGRo= =bII3 -----END PGP SIGNATURE----- --------------enigFD3362D04A7C368AB5AE8A0E-- --===============0911613191== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0911613191==-- From tcpm-bounces@ietf.org Tue Oct 30 10:19:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImruQ-00042m-Si; Tue, 30 Oct 2007 10:17:34 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImruQ-00042h-77 for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 10:17:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImruP-00042Z-TE for tcpm@ietf.org; Tue, 30 Oct 2007 10:17:33 -0400 Received: from mail.enyo.de ([212.9.189.167]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImruP-0004wh-FB for tcpm@ietf.org; Tue, 30 Oct 2007 10:17:33 -0400 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1ImrrJ-0002QZ-Av; Tue, 30 Oct 2007 15:14:21 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.68) (envelope-from ) id 1ImrrH-0004Ie-K0; Tue, 30 Oct 2007 15:14:19 +0100 From: Florian Weimer To: Mahesh Jethanandani Subject: Re: [tcpm] Is this a problem? References: <472654F9.5030308@cisco.com> Date: Tue, 30 Oct 2007 15:14:19 +0100 In-Reply-To: <472654F9.5030308@cisco.com> (Mahesh Jethanandani's message of "Mon, 29 Oct 2007 14:47:37 -0700") Message-ID: <873avsvgec.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org * Mahesh Jethanandani: > Three well-known, public sites were tested for this vulnerability. The > two most common HTTP servers, Apache and IIS were the target. While > one site had put mitigation technique in place, the others had > none. With the latter two we were able to hold connections in > ESTABLISHED state for days. The former site had a mitigation in place > with a fixed timeout of 11 min., which was easy to guess and work > around. > > We (the authors) believe that this is a huge problem. What do you > folks feel? It's a problem, but not at the TCP layer. SSH connections, for instance, can legitimately last for days in ESTABLISHED state without any traffic being exchanged. For HTTP, it may be helpful to have some kind of information regarding the TCP state to mitigate the DoS potential, but I fear that it's too easily manipulated by the attacker to be useful. Even if it's not, it's really a sockets API issue. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Oct 30 11:33:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imt4j-0005Rp-CL; Tue, 30 Oct 2007 11:32:17 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Imt4h-0005Rj-2E for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 11:32:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imt4g-0005RO-OG for tcpm@ietf.org; Tue, 30 Oct 2007 11:32:14 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imt4a-00009n-7D for tcpm@ietf.org; Tue, 30 Oct 2007 11:32:14 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9UFVmQu019814; Tue, 30 Oct 2007 17:31:50 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 17:31:24 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 17:31:23 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 17:31:23 +0200 Received: from [172.21.34.135] (esdhcp034135.research.nokia.com [172.21.34.135]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9UFVMwu031309; Tue, 30 Oct 2007 17:31:22 +0200 In-Reply-To: <4717E7D6.7000407@isi.edu> References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> From: Lars Eggert Subject: Re: [tcpm] WGLC for UTO Date: Tue, 30 Oct 2007 17:31:21 +0200 To: ext Joe Touch X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 Oct 2007 15:31:23.0855 (UTC) FILETIME=[EDD00DF0:01C81B09] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0263889286==" Errors-To: tcpm-bounces@ietf.org --===============0263889286== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-19-702717174; protocol="application/pkcs7-signature" --Apple-Mail-19-702717174 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-10-19, at 2:10, ext Joe Touch wrote: > - MUST/MAY/SHOULD on the whole option > I didn't see this; I'm not sure I care what the decision is, > but it should be stated in the abstract and intro I'd like to ask the opinion of the WG here: Should we recommend that all stacks implement UTO as a PS? Or only some stacks, and in this case, which ones? (Alternatively, if we're going for Experimental with this document, this question is moot, because implicitly only hosts desiring to experiment with this option need to implement it.) > - sec 3 at "Before opening..." for two paragraphs > This section uses 2119 language in ways I don't understand. An app > that > wishes to do something SHOULD? If it wishes to do something, it "DOES" > it. I don't see a reason for 2119 there, or MAY at the end of that > paragraph, or MAY in the next. In these cases, there are choices > involved that determine what happens. You cannot dictated userland / > application behavior when defining these events in this document, IMO. I've rephrased these sentences to not use 211 terms. > - sec 3 "In addition to" > There is no reason in requiring (via SHOULD) a refresh of > SYN-coordinated state. Either that state is coordinated, or it is not. > If not, then the connection is in error. The intent was to make UTO work with SYN cookie implementations that can't encode whether a UTO option was present in the cookie, by including the option also in the first non-SYN packets. It may also help when the option space in the SYN packets was too full to allow UTO to be included. So there is some use to doing this. We could state that including UTo in the first non-SYN packets is only useful if the option was not included in the SYN? > - sec 3 "A host that supports" > What happens if there is no option space in the next outgoing segment? > What happens if there is no option space at all? Do you tell the > app? Do > you do anything special? IMO, this deserves a separate section rather > than just a note at the end of 3.0 I don't know what we can say about this - this is a general issue with TCP. What should be done depends a lot on which other options are in use for a particular connection. Maybe UTO is considered more important than some options, but less important than others. Which options do you include and which ones do you not include, generally? Hard to say. > - sec 3.1 "When a host" > "In this case, they SHOULD" - they who? s/they/TCP/ - fixed > - sec 3.1 "In general" > This is contrary to the default values. CHANGEABLE defaults to > true, but > ENABLED defaults to false. That means, IMO, that received UTO options > would be dropped, not acted upon, in the default case. When the draft was targeted as Experimental, having ENABLED default to false was needed, so that hosts would need to actively enable the mechanism to participate to experiment with the option. If we're going with PS (are we?), ENABLED should default to true, I guess. > - sec 6 > I thought this section should say a few specific things: > > 1) There are no new IANA namespaces. (which you say) > > 2) This doc requires IANA to assign a value from the TCP Option > namespace, to be referred in section 3.3 accordingly. (which you don't > quite ask for!) Right - I made this explicit. > Very minor points, if an edit occurs: ... Most of these are addressed in the next revision. But not these, so far: > - sec 3.1 "This means that" > This paragraph is part of a discussion on checks and limits; this > should > not be the first place you introduce the "max" concept. It's not - the formula further up introduces it. > - hysteresis? > The doc doesn't describe how quickly the UTO can be changed by the > remote end or application. Does it matter, e.g., for security reasons? I don't think there are security implications here. The only result of changing the value very frequently is that all segments have the option attached, so there is some mild increase in bandwidth use. But the app can always just send more data anyway :-) > - sec 3.2 > If you retransmit the option and attach it to a particular byte, > and the > byte is ACKd, then why don't you KNOW the option has been received > (i.e., second part of the handshake)? if the other end receives data > over 1 window away from that byte, why doesn't it KNOW the source end > knows it has been recieved (i.e., third part of the handshake)? *If* you do this, yes, but there was consensus earlier that the WG didn't want the UTO exchange to be reliable, which is why this "attaching" the option to a byte is a MAY. > About retransmission, IMO, it SHOULD be done - or else what's the > point > of this? Is this related to your previous comment? If so, there was consensus to not make UTO reliable, i.e., retransmit lost options. Thanks! Lars --Apple-Mail-19-702717174 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMzAxNTMxMjJaMCMGCSqGSIb3DQEJBDEWBBQz8SjoeyjBRUSK 8pathGRDV8PHFDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAut+art05JksnltUlzizLsP9AaUYzInsDUxUdw9BYQ4hKDuWNSv7p eiYMrL8lJX0HRFFT+JL4tb08/ArNOiQErwk7farr17bqSoX9is6UwuPSM6Garo0uk8dnp1eAca4f hDBEi9cN1M9Vs+I/L5zIGVIXJZ0u1gmSZUpTCxH3ZqJQr/fA4cfv4obaaXTj/IDNjxZD0tHvUNG0 Tp/8khOqNu1dL/qGfFhgO2Y4644C8anpb9/cb81rInfGPluWxYlCzZWUXY1ka+BNb/gHWOVB7BV1 ZFl6S3P8GYklOF034R0/4YPho7eNBrWT5tPfCLmjv+feoMl3DYjuYCpbr6pvgAAAAAAAAA== --Apple-Mail-19-702717174-- --===============0263889286== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0263889286==-- From tcpm-bounces@ietf.org Tue Oct 30 12:08:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtcU-0002CN-Px; Tue, 30 Oct 2007 12:07:10 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImtcU-0002CG-57 for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 12:07:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtcT-0002C1-Qb for tcpm@ietf.org; Tue, 30 Oct 2007 12:07:09 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImtcN-0001Ur-8l for tcpm@ietf.org; Tue, 30 Oct 2007 12:07:09 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9UG6IC7007807; Tue, 30 Oct 2007 18:06:54 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 18:06:28 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 18:06:28 +0200 Received: from [172.21.34.135] (esdhcp034135.research.nokia.com [172.21.34.135]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9UG5uv8028119; Tue, 30 Oct 2007 18:06:26 +0200 In-Reply-To: <200710291733.SAA13049@TR-Sys.de> References: <200710291733.SAA13049@TR-Sys.de> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Date: Tue, 30 Oct 2007 18:05:54 +0200 To: =?ISO-8859-1?Q?ext_Alfred_H=CEnes?= X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 Oct 2007 16:06:28.0643 (UTC) FILETIME=[D45D3730:01C81B0E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: tcpm@ietf.org, fernando@gont.com.ar Subject: [tcpm] Re: draft-ietf-tcpm-tcp-uto-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0874606615==" Errors-To: tcpm-bounces@ietf.org --===============0874606615== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-21-704790100; protocol="application/pkcs7-signature" --Apple-Mail-21-704790100 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed On 2007-10-29, at 19:33, ext Alfred H=CEnes wrote: > (1) Terminology -- Section 3, 3.1 et al. > > Section 3 newly has introduced the variable 'USER_TIMEOUT': > > USER_TIMEOUT > TCP's USER TIMEOUT parameter, as specified in [RFC0793]. > > The subsequent text uses 'user timeout', 'USER TIMEOUT', and > 'USER_TIMEOUT' in a way that seems to be a bit confusing; the > distinction between these terms, and the rationale for selecting > one of these terms remains unclear in some places. USER TIMEOUT refers to the RFC793-defined TCP state variable. USER_TIMEOUT names a variable in the formula in Section 3.1. that is =20 used to set the local USER TIMEOUT. It's not a TCP state variable; =20 USER TIMEOUT is. The lower-case phrase is used in the body of the text when the =20 concept is talked about, and not one of the specific items above. At =20 least that was the intent - we may have used the lower case in some =20 places where we should have used the upper case form. > Also, the title of Section 3.1 contains 'User Timeout' whereas most > occurrences of 'user timeout' have been changed to 'USER TIMEOUT' > in the body of Section 3.1. All section titles have initial capitals. > I propose to reconsider the distinction, and to use 'USER TIMEOUT' > only in the immediate context of RFC 793 as opposed to this draft; > most of the occurrences of 'USER TIMEOUT' should better be replaced > by 'USER_TIMEOUT' (the TCP state variable) or 'user timeout' (the > abstract concept as seen from the application / user). USER_TIMEOUT isn't the TCP state variable, USER TIMEOUT (from 793) is. I'm OK with using the lower-case variant throughout the text, if =20 people think that would eliminate confusion? > Also, the names of the two variables, USER_TIMEOUT and LOCAL_UTO, > are not good mnemonics for the intended purpose of these variables; > IMHO, the naming should be reconsidered again (I already had argued > in this matter). In particular, 'LOCAL_UTO' now has much diminuished > *local* significance, it it just the value advertised to the peer > (=3D> my new proposal: ADV_UTO ); USER_TIMEOUT ist the important local > state variable, and there's now only a loose coupling between both. I like ADV_UTO, change made. > (2) Section 3 > In the second-to-last paragraph of Section 3, there's an unnecessary > word replication: fixed > (3) Section 3.3 > In the last paragraph, remove the duplicate full-stop in =20 > "connection.." done Thanks! Lars= --Apple-Mail-21-704790100 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMzAxNjA1NTVaMCMGCSqGSIb3DQEJBDEWBBT9oZOQG1rt1nBe deL0VXcloT+HzjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAiqYUF8A00WHVI0jyQgghJ9Wrv3zvdsyg/sRoT+YFQFC6/MDncT06 BPmxE8q/vE8nin3qhpxqBUgQaHQ3R8wWn71sqAVjKuJG1FsRRoRTXfUwBqGbHoyc5/7F5x7w+9AJ W/K6agO07Thr5lPBUWcVD0XxPGs90wB2sYpRINTlPTw1AaNJ/95m0VIPJes9qo0o+bd8iQq6GWqh Z3KGBh9gr8X5eBpnwbevlreenBd/sMItTnY7hMJY2dv7DFgkWtO2E7Qmvt4EIvTNJRyuLtOtOaTg /Srn/PoFwYQaRk8Uljcl8EAvL2r9RJXAh4T50p+8jR/fVhUi9KklkPUsQ6sIIAAAAAAAAA== --Apple-Mail-21-704790100-- --===============0874606615== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0874606615==-- From tcpm-bounces@ietf.org Tue Oct 30 12:08:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imtdv-0006bK-Vz; Tue, 30 Oct 2007 12:08:39 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Imtdt-0006Ii-Mv for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 12:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imtdt-0006Hw-D0 for tcpm@ietf.org; Tue, 30 Oct 2007 12:08:37 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imtdn-0001Y8-Kp for tcpm@ietf.org; Tue, 30 Oct 2007 12:08:37 -0400 Received: from [70.213.65.187] (187.sub-70-213-65.myvzw.com [70.213.65.187]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l9UG7tpQ024374; Tue, 30 Oct 2007 09:07:55 -0700 (PDT) Message-ID: <472756CC.8070809@isi.edu> Date: Tue, 30 Oct 2007 09:07:40 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [tcpm] WGLC for UTO References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> In-Reply-To: <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> X-Enigmail-Version: 0.95.4 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0704941783==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0704941783== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigED93437A7749668536A4C840" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigED93437A7749668536A4C840 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lars Eggert wrote: > On 2007-10-19, at 2:10, ext Joe Touch wrote: =2E.. >> - sec 3 "In addition to" >> There is no reason in requiring (via SHOULD) a refresh of >> SYN-coordinated state. Either that state is coordinated, or it is not.= >> If not, then the connection is in error. >=20 > The intent was to make UTO work with SYN cookie implementations that > can't encode whether a UTO option was present in the cookie, by > including the option also in the first non-SYN packets.=20 That should be deemed non-compliant. The point of the SYN cookie is to reestablish the entirety of state that would have been established by the SYN; if the cookie can't do that, a cookie should not be used. TCP has no provisions for post-SYN establishment of new connection state AFAIK. Requiring this of this option would be new, and, IMO, a bit confusing for designers. What happens if the post-SYN packet lacks the option? do you declare state mis-synchronization and drop it? > It may also help > when the option space in the SYN packets was too full to allow UTO to b= e > included. IMO, if that's a concern, then make sure the UTO MUST NOT be included in the SYN. I.e., it's in one place or the other; once in place, it shouldn't be repeated in subsequent segments - only replayed in segments being retransmitted. > So there is some use to doing this. We could state that > including UTo in the first non-SYN packets is only useful if the option= > was not included in the SYN? I'd prefer that, adjusted to say "if the option was not included in the SYN due to space limitations". >> - sec 3 "A host that supports" >> What happens if there is no option space in the next outgoing segment?= >> What happens if there is no option space at all? Do you tell the app? = Do >> you do anything special? IMO, this deserves a separate section rather >> than just a note at the end of 3.0 >=20 > I don't know what we can say about this - this is a general issue with > TCP. What should be done depends a lot on which other options are in us= e > for a particular connection. Maybe UTO is considered more important tha= n > some options, but less important than others. Which options do you > include and which ones do you not include, generally? Hard to say. I'm not making an assertion as to what to do, only that the doc ought to consider the issue. I'll suggest that it ought to send it within 2 segments OR indicate to the application that it has failed; the latter requires a new API variable, though. >> - sec 3.1 "In general" >> This is contrary to the default values. CHANGEABLE defaults to true, b= ut >> ENABLED defaults to false. That means, IMO, that received UTO options >> would be dropped, not acted upon, in the default case. >=20 > When the draft was targeted as Experimental, having ENABLED default to > false was needed, so that hosts would need to actively enable the > mechanism to participate to experiment with the option. >=20 > If we're going with PS (are we?), ENABLED should default to true, I gue= ss. Sure - making the two consistent is the issue. =2E.. >> Very minor points, if an edit occurs: > ... >=20 > Most of these are addressed in the next revision. But not these, so far= : >=20 >> - sec 3.1 "This means that" >> This paragraph is part of a discussion on checks and limits; this shou= ld >> not be the first place you introduce the "max" concept. >=20 > It's not - the formula further up introduces it. It might be useful to introduce the issue in prose first. The reason for using max is the issue, and it's not clear by just stating the formula. >> - hysteresis? >> The doc doesn't describe how quickly the UTO can be changed by the >> remote end or application. Does it matter, e.g., for security reasons?= >=20 > I don't think there are security implications here. The only result of > changing the value very frequently is that all segments have the option= > attached, so there is some mild increase in bandwidth use. But the app > can always just send more data anyway :-) Can someone on the path do something you don't want to your connection by tacking this option on? >> - sec 3.2 >> If you retransmit the option and attach it to a particular byte, and t= he >> byte is ACKd, then why don't you KNOW the option has been received >> (i.e., second part of the handshake)? if the other end receives data >> over 1 window away from that byte, why doesn't it KNOW the source end >> knows it has been recieved (i.e., third part of the handshake)? >=20 > *If* you do this, yes, but there was consensus earlier that the WG > didn't want the UTO exchange to be reliable, which is why this > "attaching" the option to a byte is a MAY. Ah - it might be useful to explain that. I thought MAY implied that the information about reliability was in doubt, rather than that the use of the attachment was optional but would provide reliable UTO exchange if us= ed. >> About retransmission, IMO, it SHOULD be done - or else what's the poin= t >> of this? >=20 > Is this related to your previous comment? If so, there was consensus to= > not make UTO reliable, i.e., retransmit lost options. I have no idea what the point of an unreliable option on a reliable transport protocol means. IMO, options should be retransmitted when their associated segments are. The control protocol ought to be at least as robust as the data. Although I appreciate that UTO isn't as critical as some other options or flags, introducing nondeterminism at this level doesn't seem appropriate, IMO. I.e., I think there are separate questions: 1) is UTO critical enough to ensure correct exchange via an explicitly ack'd handshake no - I agree with the WG 2) should options associated with a segment be retransmitted with that segment in general in TCP I think the answer to this should be YES, always, but I don't think it was asked. Joe --------------enigED93437A7749668536A4C840 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 iD8DBQFHJ1bYE5f5cImnZrsRArL9AJ4hLHC1PMHxZyrTZm4UER5ubcu2wACgqsZA jojKm9UgmPcLWEpwsDZHk3k= =XVry -----END PGP SIGNATURE----- --------------enigED93437A7749668536A4C840-- --===============0704941783== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0704941783==-- From tcpm-bounces@ietf.org Tue Oct 30 13:10:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImuZt-0006ef-OJ; Tue, 30 Oct 2007 13:08:33 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImuZs-0006eZ-DE for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 13:08:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImuZs-0006d0-3g for tcpm@ietf.org; Tue, 30 Oct 2007 13:08:32 -0400 Received: from mx.neterion.com ([72.1.205.142] helo=owa.neterion.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImuZf-0003mr-9t for tcpm@ietf.org; Tue, 30 Oct 2007 13:08:25 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] WGLC for UTO Date: Tue, 30 Oct 2007 13:07:47 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77027653E9@nekter> In-Reply-To: <472756CC.8070809@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC for UTO Thread-Index: AcgbDzCxKNxs0yBzQJubbzxrsPhgTAABuhbQ References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com><78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter><4717E7D6.7000407@isi.edu><14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> From: "Caitlin Bestler" To: "Joe Touch" , "Lars Eggert" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org -----Original Message----- From: Joe Touch [mailto:touch@ISI.EDU]=20 Sent: Tuesday, October 30, 2007 9:08 AM To: Lars Eggert Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for UTO Lars Eggert wrote: > On 2007-10-19, at 2:10, ext Joe Touch wrote: ... >> - sec 3 "In addition to" >> There is no reason in requiring (via SHOULD) a refresh of=20 >> SYN-coordinated state. Either that state is coordinated, or it is not. >> If not, then the connection is in error. >=20 > The intent was to make UTO work with SYN cookie implementations that=20 > can't encode whether a UTO option was present in the cookie, by=20 > including the option also in the first non-SYN packets. That should be deemed non-compliant. The point of the SYN cookie is to reestablish the entirety of state that would have been established by the SYN; if the cookie can't do that, a cookie should not be used. TCP has no provisions for post-SYN establishment of new connection state AFAIK. Requiring this of this option would be new, and, IMO, a bit confusing for designers. What happens if the post-SYN packet lacks the option? do you declare state mis-synchronization and drop it? ----------End of Original Message -------------------------------------------------------- The idea here is to recognize that existing stacks establish the TCB at two different times: on first SYN or on the Ack of the SYN-ACK. To be very pedantic, the TCB is *always* established when the SYN is received. It's just that a SYN Cookie encodes the "TCB" in the SYN cookie value and "stores" the TCB on the network. Which would be a problem with UTO if the UTO option were only present in the SYN cookie. Basically there isn't any more room in the SYN Cookie without stealing information from elsewhere (such as timing resolution or cryptographic quality). That won't happen. Instead anyone using SYN Cookies will simply NEVER support UTO for *any* connection (in which case whether it was in the SYN is irrelevant, which does encode very efficiently). The redundant transmission of the UTO option allows a receiver that uses SYN Cookies to establish connections safely to enable that support only when it is *actually* creating the full-sized TCB. This same benefit actually applies to any strategy where allocation of a full TCB is deferred until after the round-trip (which is a generally recommended practice, although there can be debate about how much the proto-TCB should be condensed and where it should be stored). As to Lars comment, the idea of having it both places is to allow=20 implementations that create the full TCB on receipt of the SYN to properly create the TCB. Currently, most software based SYN Cookies implementations include a "no attack detected" mode where the TCBs are created immediately. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Oct 30 13:15:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imugd-0006uJ-Vv; Tue, 30 Oct 2007 13:15:31 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Imugc-0006u9-MP for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 13:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imugc-0006u1-Cs for tcpm@ietf.org; Tue, 30 Oct 2007 13:15:30 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imugb-000457-3p for tcpm@ietf.org; Tue, 30 Oct 2007 13:15:30 -0400 Received: from [70.213.65.187] (187.sub-70-213-65.myvzw.com [70.213.65.187]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l9UHFD4e014429; Tue, 30 Oct 2007 10:15:14 -0700 (PDT) Message-ID: <472766A0.10608@isi.edu> Date: Tue, 30 Oct 2007 10:15:12 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] WGLC for UTO References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com><78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter><4717E7D6.7000407@isi.edu><14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77027653E9@nekter> In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77027653E9@nekter> X-Enigmail-Version: 0.95.4 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0664191691==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0664191691== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF6B210F440A218956F22B895" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF6B210F440A218956F22B895 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Caitlin Bestler wrote: >=20 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Tuesday, October 30, 2007 9:08 AM > To: Lars Eggert > Cc: tcpm@ietf.org > Subject: Re: [tcpm] WGLC for UTO >=20 > Lars Eggert wrote: >> On 2007-10-19, at 2:10, ext Joe Touch wrote: > ... >>> - sec 3 "In addition to" >>> There is no reason in requiring (via SHOULD) a refresh of=20 >>> SYN-coordinated state. Either that state is coordinated, or it is > not. >>> If not, then the connection is in error. >> The intent was to make UTO work with SYN cookie implementations that=20 >> can't encode whether a UTO option was present in the cookie, by=20 >> including the option also in the first non-SYN packets. >=20 > That should be deemed non-compliant. The point of the SYN cookie is to > reestablish the entirety of state that would have been established by > the SYN; if the cookie can't do that, a cookie should not be used. >=20 > TCP has no provisions for post-SYN establishment of new connection stat= e > AFAIK. Requiring this of this option would be new, and, IMO, a bit > confusing for designers. What happens if the post-SYN packet lacks the > option? do you declare state mis-synchronization and drop it? >=20 > ----------End of Original Message > -------------------------------------------------------- >=20 > The idea here is to recognize that existing stacks establish the TCB at= > two different times: on first SYN or on the Ack of the SYN-ACK. >=20 > To be very pedantic, the TCB is *always* established when the SYN is > received. It's just that a SYN Cookie encodes the "TCB" in the SYN > cookie value and "stores" the TCB on the network. >=20 > Which would be a problem with UTO if the UTO option were only present > in the SYN cookie. Basically there isn't any more room in the SYN > Cookie without stealing information from elsewhere (such as timing > resolution or cryptographic quality). TCP with SYN cookies must decline connections whose state it cannot sufficiently encode in a cookie. > That won't happen. Instead anyone using SYN Cookies will simply NEVER > support UTO for *any* connection (in which case whether it was in the > SYN is irrelevant, which does encode very efficiently). That's inappropriate - the end that ACKs a SYN is responsible for making sure the appropriate TCB is established. AFAIK, we don't have a signal for the client to know that cookies are used and to retransmit options on the next segment, so this would break ALL options established without ACK in a SYN. That may require UTO never be sent in a SYN at all. I don't see why that would be a large problem, and it's cleaner than creating a situation where a cookie doesn't restore full state. (i.e., presuming UTO the only option in a SYN that can succeed unacknowledged?) > The redundant transmission of the UTO option allows a receiver that > uses SYN Cookies to establish connections safely to enable that support= > only when it is *actually* creating the full-sized TCB. This same > benefit > actually applies to any strategy where allocation of a full TCB is > deferred > until after the round-trip (which is a generally recommended practice, > although there can be debate about how much the proto-TCB should be > condensed and where it should be stored). The TCB needs to encode enough information to establish the state that the SYN-ACK explicitly agrees to. It's not up to the endpoint to decide not to keep some of that state - once it's ACK'd, it's ACKd. > As to Lars comment, the idea of having it both places is to allow=20 > implementations that create the full TCB on receipt of the SYN to > properly create the TCB. Currently, most software based SYN Cookies > implementations include a "no attack detected" mode where the TCBs > are created immediately. If this is the only option that has this property (silent source assertion of a SYN option), then the appropriate solution is to prohibit it from SYNs, IMO. Joe --------------enigF6B210F440A218956F22B895 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 iD8DBQFHJ2agE5f5cImnZrsRArofAKCTQ2Aqj15unNzPu7i+0FFjh+pp/wCg7NS8 xcK8NHpvgf7RpM7Nh67iexY= =GKrM -----END PGP SIGNATURE----- --------------enigF6B210F440A218956F22B895-- --===============0664191691== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0664191691==-- From tcpm-bounces@ietf.org Tue Oct 30 15:00:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImwIz-00077S-H4; Tue, 30 Oct 2007 14:59:13 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImwIx-000776-KZ for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 14:59:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImwIx-00076t-AS for tcpm@ietf.org; Tue, 30 Oct 2007 14:59:11 -0400 Received: from mailer1.psc.edu ([2001:5e8:1:3a::64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImwIt-0008Gi-U1 for tcpm@ietf.org; Tue, 30 Oct 2007 14:59:11 -0400 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer1.psc.edu (8.14.1/8.13.3) with ESMTP id l9UIwxfN019358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2007 14:58:59 -0400 (EDT) Message-ID: <47277EF2.6090400@psc.edu> Date: Tue, 30 Oct 2007 14:58:58 -0400 From: John Heffner User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Mahesh Jethanandani Subject: Re: [tcpm] Is this a problem? References: <472654F9.5030308@cisco.com> In-Reply-To: <472654F9.5030308@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mahesh Jethanandani wrote: > Folks, > > We have documented a case of HTTP servers that are prone to resource starvation with the use of a small user level program. The program does not require any special privileges or changes in the kernel. The user level program on the client opens a connection to a HTTP server, sends a GET request for a large file (larger than the advertised window of the client) but never reads the response. This problem has been well documented for at least seven years. http://shlang.com/netkill/ http://shlang.com/netkill/20000421-netkill-bugtraq-announcement.txt > Three well-known, public sites were tested for this vulnerability. The two most common HTTP servers, Apache and IIS were the target. While one site had put mitigation technique in place, the others had none. With the latter two we were able to hold connections in ESTABLISHED state for days. The former site had a mitigation in place with a fixed timeout of 11 min., which was easy to guess and work around. > > We (the authors) believe that this is a huge problem. What do you folks feel? I personally believe it is a problem, but the absence of wide-spread attacks using this technique leads me to believe that other attacks are still more effective. All the same, I would like to see more widespread defense against it. > Previous responses to this documentation has been that it is a application problem. It is clear from our experimentation that most HTTP servers (and FTP too) have not implemented any mitigation techniques. We believe that this problem exists across the whole range of TCP based applications prevalent on the internet, although our experiments were limited to the web application. Where applications have tried to put mitigation techniques in place, workaround has been easy. This is mainly because applications do not have the same amount of visibility as TCP does on the state of the connection. I think nearly all responses (including mine) have been of the opinion that this is not a transport problem. However, I think this is not necessarily an application problem, either. Since the contended resource is system memory, the best place to implement a fairness policy is in the operating system -- possibly but not necessarily in the kernel (for OS's where such a distinction applies). -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Oct 30 15:06:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImwPc-00067Y-Ot; Tue, 30 Oct 2007 15:06:04 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImwPb-00067D-GT for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 15:06:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImwPY-0005zS-Nm for tcpm@ietf.org; Tue, 30 Oct 2007 15:06:00 -0400 Received: from mx.neterion.com ([72.1.205.142] helo=owa.neterion.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImwPX-0005tj-JI for tcpm@ietf.org; Tue, 30 Oct 2007 15:05:59 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] WGLC for UTO Date: Tue, 30 Oct 2007 15:05:57 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7702765475@nekter> In-Reply-To: <472766A0.10608@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC for UTO Thread-Index: AcgbGIDttfCXJvviRiCt+rZARIo9ygADtkAg References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com><78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter><4717E7D6.7000407@isi.edu><14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> <78C9135A3D2ECE4B8162EBDCE82CAD77027653E9@nekter> <472766A0.10608@isi.edu> From: "Caitlin Bestler" To: "Joe Touch" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: . > If this is the only option that has this property (silent source > assertion of a SYN option), then the appropriate solution is to > prohibit it from SYNs, IMO. > Joe If you're allocated a "full" TCB based on only an unconfirmed SYN then you probably would not mind allocating one that is UTO capable. So I don't really see any harm in prohibiting it from the SYN, unless it's presence there is needed to keep connection tracking middleboxes happy or somesuch. The passive endpoint certainly does not need it to be in the SYN. Any timeouts before the connection is fully established are going to have their own logic anyway. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Oct 30 15:58:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImxEH-0002XR-Vb; Tue, 30 Oct 2007 15:58:25 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImxEH-0002XD-Aw for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 15:58:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImxEG-0002X3-VW for tcpm@ietf.org; Tue, 30 Oct 2007 15:58:25 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImxEG-0000E2-5e for tcpm@ietf.org; Tue, 30 Oct 2007 15:58:24 -0400 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 l9UJwMgq023066 for ; Tue, 30 Oct 2007 12:58:22 -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 C9CBF11512E1 for ; Tue, 30 Oct 2007 15:58:15 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9CA6C2D9591 for ; Tue, 30 Oct 2007 15:56:09 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: 30 Days in the Hole MIME-Version: 1.0 Date: Tue, 30 Oct 2007 15:56:09 -0400 Message-Id: <20071030195609.9CA6C2D9591@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Subject: [tcpm] 2581 implementation report, take 2 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 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="===============0227490603==" Errors-To: tcpm-bounces@ietf.org --===============0227490603== 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 Attached is a slightly tweaked version of the 2581 implementation report. The report includes input from the linux community noting that 2581 is implemented in their stack and that they have not seen any sort of big problems because of it. allman --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Disposition: attachment; filename=impl-report.txt Background: + RFC 2581 is a re-write of RFC 2001. RFC 2001 was a description of TCP's congestion control algorithms that was published long after these algorithms were in nearly ubiquitous deployment throughout the Internet (largely triggered by the congestion collapses of the mid-1980s). + While RFC 2001 was a description of the algorithms, RFC 2581 is a more traditional specification. We stress that the RFC was written based on running code and experience. + The mechanisms in RFC 3042 (Limited Transmit) and RFC 3390 (Larger Initial Congestion Window) are also rolled into the current document. Both of these enhancements are Proposed Standards that have gathered wide consensus within the community based on deployment experience. + The traditional test of two interoperable implementations to move a Proposed Standard to Draft Standard is less obvious in the case of congestion control mechanisms. Congestion control is about *when* to send a segment and not *what* that segment looks like, how to process it, how big fields are, etc. Therefore, it is difficult to assess "interoperability" in the traditional sense. Below we cite several sources that show or suggest that multiple implementations of the mechanisms exist and seem to work as intended. + The new version of the document clarifies a number of small issues that implementers have asked about over the years, but does not make any large changes to the algorithms. Known Implementations: + [WS95] discusses the BSD implementation of the core algorithms in RFC 2581 (slow start, congestion avoidance, fast retransmit and fast recovery). This implementation has formed the basis of the TCP stack in numerous operating systems (NetBSD, FreeBSD, OpenBSD, SunOS 4.x, BSDI, etc.). While various operating systems may have diverged in small details (some of which is documented in RFC 2581) the basic algorithms do not seem to have changed. + Linux also supports RFC 2581 and does not report any adverse impacts. See Attachment 1 below. (The complaint in that email is not about the document itself or even the algorithm within RFC 2581, but rather goes to our congestion control principles. Further, as sketched the behavior given in RFC 2581 is more conservative than desired and therefore if this RFC is in error, it is erroring in the right direction for stable operation.) + [Pax97] analyzes a number of implementations, finding both correct and incorrect behavior relative to RFC 2581 across a variety of implementations. The incorrect behavior fed into [RFC2525]. + [MAF05] tests for conformance along a number of angles by probing the TCPs of over 70K web servers with specialized packet streams that induce the stack to show how it handles various situations. The results include: + The vast majority of server reduce their congestion window by half in response to congestion (per RFC 2581's congestion avoidance). + The majority of the web servers used an initial congestion window of 1--2 packets. + Limited Transmit was used in over 20% of the servers. + While some servers do not use fast retransmit the overwhelming majority implement it. + Many web servers use the fast recovery algorithm (with a number using more advanced recovery such as NewReno [RFC3782] or SACK-based loss recovery techniques [RFC2018,RFC3517]. (Note that [MAF05] updates some of the results of [PF01]. The newer results confirm the older results.) References: [MAF05] Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of Transport Protocols in the Internet. ACM Computer Communication Review, 35(2), April 2005. [Pax97] Vern Paxson. Automated Packet Trace Analysis of TCP Implementations. ACM SIGCOMM, September 1997. [PF01] Jitu Padhye, Sally Floyd. Identifying the TCP Behavior of Web Servers, SIGCOMM 2001, August 2001. [WS95] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: The Implementation", Addison-Wesley, 1995. Attachment 1: Date: Mon, 24 Sep 2007 19:55:20 PDT To: mallman@icir.org From: Stephen Hemminger Subject: Re: rfc2581 [...] Yes Linux implements RFC2581 and has not had any unstable or congestion problems caused by that. In recent years, there has been lots of refinements and alternatives added, but all the other algorithms are more complex attempts to ensure proper and stable response in "corner case" domains of large delay bandwidth products and/or small router queues. Linux also implements RFC2861 (congestion window validation) by default which makes it less aggressive than many other implementations. Because this caused some bursty applications to have poor performance it was made optional. The only real complaint against the principles of congestion control has come from the financial community. Slow start can cause connections to have latency, and when latency equates to real $$ during transactions, customers get very sensitive to the added delay. For a discussion of this see the presentation from Credit Suisse at this 2007 Kernel Summit. http://lwn.net/Articles/248878/ For that reason, they are looking to alternatives to TCP/IP such as Infiniband. -- Stephen Hemminger --=_bOundary-- --==_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHJ4xZWyrrWs4yIs4RAu1RAJwI14kOM2WKYwzJZaMVXTRnVosg4gCfYsee kB/+1lISFCRipcusxPa41Pc= =8NLQ -----END PGP SIGNATURE----- --==_bOundary-- --===============0227490603== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0227490603==-- From tcpm-bounces@ietf.org Wed Oct 31 03:51:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In8JU-0006Yt-7b; Wed, 31 Oct 2007 03:48:32 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1In8JT-0006Ym-6H for tcpm-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 03:48:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In8JN-0006Vv-CZ for tcpm@ietf.org; Wed, 31 Oct 2007 03:48:25 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In8JD-00064o-Lf for tcpm@ietf.org; Wed, 31 Oct 2007 03:48:22 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9V7m2Ad005660; Wed, 31 Oct 2007 09:48:03 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 09:47:41 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 09:47:41 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 09:47:41 +0200 Received: from [172.21.35.97] (esdhcp03597.research.nokia.com [172.21.35.97]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9V7ldbx007692; Wed, 31 Oct 2007 09:47:39 +0200 In-Reply-To: <472756CC.8070809@isi.edu> References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <582A6F13-12CC-4B5C-8415-CBDAD73116AA@nokia.com> From: Lars Eggert Subject: Re: [tcpm] WGLC for UTO Date: Wed, 31 Oct 2007 09:47:37 +0200 To: ext Joe Touch X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Oct 2007 07:47:41.0291 (UTC) FILETIME=[50AF73B0:01C81B92] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1985169914==" Errors-To: tcpm-bounces@ietf.org --===============1985169914== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-30-761293241; protocol="application/pkcs7-signature" --Apple-Mail-30-761293241 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-10-30, at 18:07, ext Joe Touch wrote: > Lars Eggert wrote: >> The intent was to make UTO work with SYN cookie implementations that >> can't encode whether a UTO option was present in the cookie, by >> including the option also in the first non-SYN packets. > > That should be deemed non-compliant. The point of the SYN cookie is to > reestablish the entirety of state that would have been established by > the SYN; if the cookie can't do that, a cookie should not be used. Well, if the SYN requests (many) options and the receiver cannot encode them all in the cookie, it can always reply with a SYN-ACK that only echoes those that it can and does encode. That's compliant, no? > TCP has no provisions for post-SYN establishment of new connection > state > AFAIK. Requiring this of this option would be new, and, IMO, a bit > confusing for designers. What happens if the post-SYN packet lacks the > option? do you declare state mis-synchronization and drop it? No - the UTO option is purely advisory and not transmitted reliably. We had a long thread a while ago on the list that boiled down to that consensus. (I can dig it up if you like me to.) The gist was that it should be OK these days to send new options during a connection, even if the SYN exchange didn't negotiate their use. >> So there is some use to doing this. We could state that >> including UTo in the first non-SYN packets is only useful if the >> option >> was not included in the SYN? > > I'd prefer that, adjusted to say "if the option was not included in > the > SYN due to space limitations". That can certainly be done. >>> - sec 3 "A host that supports" >>> What happens if there is no option space in the next outgoing >>> segment? >>> What happens if there is no option space at all? Do you tell the >>> app? Do >>> you do anything special? IMO, this deserves a separate section >>> rather >>> than just a note at the end of 3.0 >> >> I don't know what we can say about this - this is a general issue >> with >> TCP. What should be done depends a lot on which other options are >> in use >> for a particular connection. Maybe UTO is considered more >> important than >> some options, but less important than others. Which options do you >> include and which ones do you not include, generally? Hard to say. > > I'm not making an assertion as to what to do, only that the doc > ought to > consider the issue. I'll suggest that it ought to send it within 2 > segments OR indicate to the application that it has failed; the latter > requires a new API variable, though. We can add that TCP should try for a few segments to include a TO option if it wants to send one, but I don't think notifying the application on failure is necessary, because UTO options are advisory and not transmitted reliably. Not being able to include it locally is equivalent to having the segment that it was included on being dropped in the network. >>> - sec 3.1 "In general" >>> This is contrary to the default values. CHANGEABLE defaults to >>> true, but >>> ENABLED defaults to false. That means, IMO, that received UTO >>> options >>> would be dropped, not acted upon, in the default case. >> >> When the draft was targeted as Experimental, having ENABLED >> default to >> false was needed, so that hosts would need to actively enable the >> mechanism to participate to experiment with the option. >> >> If we're going with PS (are we?), ENABLED should default to true, >> I guess. > > Sure - making the two consistent is the issue. Will do, as soon as the chairs declare consensus on which way they see the WG consensus go. > ... >>> Very minor points, if an edit occurs: >> ... >> >> Most of these are addressed in the next revision. But not these, >> so far: >> >>> - sec 3.1 "This means that" >>> This paragraph is part of a discussion on checks and limits; this >>> should >>> not be the first place you introduce the "max" concept. >> >> It's not - the formula further up introduces it. > > It might be useful to introduce the issue in prose first. The > reason for > using max is the issue, and it's not clear by just stating the > formula. > >>> - hysteresis? >>> The doc doesn't describe how quickly the UTO can be changed by the >>> remote end or application. Does it matter, e.g., for security >>> reasons? >> >> I don't think there are security implications here. The only >> result of >> changing the value very frequently is that all segments have the >> option >> attached, so there is some mild increase in bandwidth use. But the >> app >> can always just send more data anyway :-) > > Can someone on the path do something you don't want to your connection > by tacking this option on? So that's a different question than your original one, which was changing the value very frequently. An attacker that adds or modifies the content of UTO options may be able to affect how long the ends keep the connection alive. Since UTO is advisory, an attacker can't really do anything to the connection that couldn't happen anyway. And the security properties of UTO are similar to other TCP options (window scaling, timestamps), in that none of them are authenticated or encrypted. >>> - sec 3.2 >>> If you retransmit the option and attach it to a particular byte, >>> and the >>> byte is ACKd, then why don't you KNOW the option has been received >>> (i.e., second part of the handshake)? if the other end receives data >>> over 1 window away from that byte, why doesn't it KNOW the source >>> end >>> knows it has been recieved (i.e., third part of the handshake)? >> >> *If* you do this, yes, but there was consensus earlier that the WG >> didn't want the UTO exchange to be reliable, which is why this >> "attaching" the option to a byte is a MAY. > > Ah - it might be useful to explain that. I thought MAY implied that > the > information about reliability was in doubt, rather than that the > use of > the attachment was optional but would provide reliable UTO exchange > if used. The MAY is about that even though the spec says that an UTO is transmitted unreliably, *if* an implementation really wanted to, it could try to implement some local mechanisms to make transmission of its UTOs to the peer more reliable. (But it can't enforce reliability in the other direction.) >>> About retransmission, IMO, it SHOULD be done - or else what's the >>> point >>> of this? >> >> Is this related to your previous comment? If so, there was >> consensus to >> not make UTO reliable, i.e., retransmit lost options. > > I have no idea what the point of an unreliable option on a reliable > transport protocol means. IMO, options should be retransmitted when > their associated segments are. The control protocol ought to be at > least > as robust as the data. Although I appreciate that UTO isn't as > critical > as some other options or flags, introducing nondeterminism at this > level > doesn't seem appropriate, IMO. We had a long discussion on this a year or two ago on this list. The outcome was that because UTO is advisory, a simple, unreliable transmission is sufficient. We can certainly revisit this decision, but I'd personally would like to see strong WG consensus on changing this pretty central assumption behind UTO this late in the game. > I.e., I think there are separate questions: > > 1) is UTO critical enough to ensure correct exchange via > an explicitly ack'd handshake > no - I agree with the WG > > 2) should options associated with a segment be retransmitted > with that segment in general in TCP > I think the answer to this should be YES, always, > but I don't think it was asked. Lars --Apple-Mail-30-761293241 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMzEwNzQ3MzhaMCMGCSqGSIb3DQEJBDEWBBQr4ql4FN83sCy3 DkgfZIRc8dyQgjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEANlwY8aPJVsHul1y1f5NvdG1lifPQca69aIXbHCBuV4rWjMbItIX4 KZp0baEZJstGSgmeUxI+GhHpHMgExZcjm3BkwNMjFSC/JnsWC1anj303RFQw43ihJnQpb1dQ2+jw yDr6jaXjLEscvodL8DtI906jzpEoTczn+D5bzukg5HwmFt/KfaTJxn3xplXbzvQ4/BW24bMIZubH XYfaBSPWUo4AsWMgoidvPrhSmO4bHiZju1lA7osascJ3pth+0BJsAvaMInhjzJH1iUH8ubsaUG5I cCeWe2TYqTd4YcNmxR000bz0jYHOxKi1Q5xHF5QTydUrJjd2dDipN1oLUI11owAAAAAAAA== --Apple-Mail-30-761293241-- --===============1985169914== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1985169914==-- From tcpm-bounces@ietf.org Wed Oct 31 11:56:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFue-0008Qt-7Q; Wed, 31 Oct 2007 11:55:24 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1InFud-0008Qk-0Z for tcpm-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 11:55:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFuc-0008Qc-ML for tcpm@ietf.org; Wed, 31 Oct 2007 11:55:22 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InFuV-0004nU-WB for tcpm@ietf.org; Wed, 31 Oct 2007 11:55:22 -0400 Received: from [192.168.1.44] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l9VFt7Kv022916; Wed, 31 Oct 2007 08:55:07 -0700 (PDT) Message-ID: <4728A553.2020300@isi.edu> Date: Wed, 31 Oct 2007 08:54:59 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [tcpm] WGLC for UTO References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> <582A6F13-12CC-4B5C-8415-CBDAD73116AA@nokia.com> In-Reply-To: <582A6F13-12CC-4B5C-8415-CBDAD73116AA@nokia.com> X-Enigmail-Version: 0.95.4 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2087192506==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2087192506== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2C92F2CC3E157A38270FAA96" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2C92F2CC3E157A38270FAA96 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lars Eggert wrote: > On 2007-10-30, at 18:07, ext Joe Touch wrote: >> Lars Eggert wrote: >>> The intent was to make UTO work with SYN cookie implementations that >>> can't encode whether a UTO option was present in the cookie, by >>> including the option also in the first non-SYN packets. >> >> That should be deemed non-compliant. The point of the SYN cookie is to= >> reestablish the entirety of state that would have been established by >> the SYN; if the cookie can't do that, a cookie should not be used. >=20 > Well, if the SYN requests (many) options and the receiver cannot encode= > them all in the cookie, it can always reply with a SYN-ACK that only > echoes those that it can and does encode. That's compliant, no? It is, but only if current SYN cookie responses for stacks that don't support UTO could be detected. I'm not sure that's possible. >> TCP has no provisions for post-SYN establishment of new connection sta= te >> AFAIK. Requiring this of this option would be new, and, IMO, a bit >> confusing for designers. What happens if the post-SYN packet lacks the= >> option? do you declare state mis-synchronization and drop it? >=20 > No - the UTO option is purely advisory and not transmitted reliably. We= > had a long thread a while ago on the list that boiled down to that > consensus. (I can dig it up if you like me to.) The gist was that it > should be OK these days to send new options during a connection, even i= f > the SYN exchange didn't negotiate their use. Then there's no point in having the SYN cookie encode anything. Receivers that implement SYN cookies MAY drop the option; senders sending UTO have no reason to resend, since it's 'advisory and not transmitted reliably'. I.e., you can't have it both ways. If this is truly unreliable, then there is NO reason to ever retransmit it. =2E.. > We can add that TCP should try for a few segments to include a TO optio= n > if it wants to send one, but I don't think notifying the application on= > failure is necessary, because UTO options are advisory and not > transmitted reliably. Not being able to include it locally is equivalen= t > to having the segment that it was included on being dropped in the netw= ork. Again, if that's the case, then try to send it ONCE. Never retry - there's no point. =2E.. >> Can someone on the path do something you don't want to your connection= >> by tacking this option on? >=20 > So that's a different question than your original one, which was > changing the value very frequently. >=20 > An attacker that adds or modifies the content of UTO options may be abl= e > to affect how long the ends keep the connection alive. Since UTO is > advisory, an attacker can't really do anything to the connection that > couldn't happen anyway.=20 I'm not sure that's true; even though it's advisory, it can cause a change in behavior - if not, then there's no point in sending it. An attacker could cause large UTOs for receivers that act on the option, which could cause a DOS opportunity. > And the security properties of UTO are similar > to other TCP options (window scaling, timestamps), in that none of them= > are authenticated or encrypted. Yes, but the implications of changing these others are different - and each should be explained in their respective security sections. This security section should say what happens when an attacker changes THIS option. =2E.. >>>> About retransmission, IMO, it SHOULD be done - or else what's the po= int >>>> of this? >>> >>> Is this related to your previous comment? If so, there was consensus = to >>> not make UTO reliable, i.e., retransmit lost options. >> >> I have no idea what the point of an unreliable option on a reliable >> transport protocol means. IMO, options should be retransmitted when >> their associated segments are. The control protocol ought to be at lea= st >> as robust as the data. Although I appreciate that UTO isn't as critica= l >> as some other options or flags, introducing nondeterminism at this lev= el >> doesn't seem appropriate, IMO. >=20 > We had a long discussion on this a year or two ago on this list. The > outcome was that because UTO is advisory, a simple, unreliable > transmission is sufficient. We can certainly revisit this decision, but= > I'd personally would like to see strong WG consensus on changing this > pretty central assumption behind UTO this late in the game. Agreed. Thanks, Joe --------------enig2C92F2CC3E157A38270FAA96 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 iD8DBQFHKKVZE5f5cImnZrsRAi8/AKCh8PbNngE7So/5gRVVs49Xf9nZrwCg0/vQ T3/pWJ/Mi02Ijr3mBUhtjXA= =QlMY -----END PGP SIGNATURE----- --------------enig2C92F2CC3E157A38270FAA96-- --===============2087192506== 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://www1.ietf.org/mailman/listinfo/tcpm --===============2087192506==-- From tcpm-bounces@ietf.org Wed Oct 31 12:11:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InG9N-00049u-4P; Wed, 31 Oct 2007 12:10:37 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1InG9L-00044V-Bm for tcpm-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 12:10:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InG9L-000419-28 for tcpm@ietf.org; Wed, 31 Oct 2007 12:10:35 -0400 Received: from mx.neterion.com ([72.1.205.142] helo=owa.neterion.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InG97-0005Xi-3d for tcpm@ietf.org; Wed, 31 Oct 2007 12:10:27 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] WGLC for UTO Date: Wed, 31 Oct 2007 12:10:05 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7701F4C10D@nekter> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC for UTO Thread-Index: Acgbk34S8xubRQBjSQOfPDJoLUd+/AAQ+5y/ References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> <582A6F13-12CC-4B5C-8415-CBDAD73116AA@nokia.com> From: "Caitlin Bestler" To: "Lars Eggert" , "ext Joe Touch" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0183944556==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0183944556== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81BD8.7FBECEDA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81BD8.7FBECEDA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com] Sent: Wed 10/31/2007 12:47 AM To: ext Joe Touch Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for UTO =20 On 2007-10-30, at 18:07, ext Joe Touch wrote: > Lars Eggert wrote: >> The intent was to make UTO work with SYN cookie implementations that >> can't encode whether a UTO option was present in the cookie, by >> including the option also in the first non-SYN packets. > > That should be deemed non-compliant. The point of the SYN cookie is to > reestablish the entirety of state that would have been established by > the SYN; if the cookie can't do that, a cookie should not be used. Well, if the SYN requests (many) options and the receiver cannot =20 encode them all in the cookie, it can always reply with a SYN-ACK =20 that only echoes those that it can and does encode. That's compliant, =20 no? ----------- End of Original Message --------------------- Compliant, yes, but not desirable. It would mean that any system that had enabled SYN Cookie mode would stop accepting UTOs. This is not a very intuitive model for application developers, and would likely just add one more log to the "UTO is not reliable" fire and discourage it's use. What I think we want is for any system in the passive role that is *capable* of doing UTO to refrain from doing any action that would block enabling UTO on the first non-SYN received. It is especially important that the passive side not be *obligated* to remember that there was no UTO option in the SYN packet, as in *expecting* it to reject later packets for having improper options. That would essentially mean that the system would have to disable UTO *permanently* as soon as it enabled SYN Cookies once (unless it was actually going to track which connections were established when and check that in real-time). My understanding of including the UTO in both the SYN as well as the first non-SYN was that network monitoring equipment (or software) would expect any negotiated option to have been present in the SYN and likely would not know that UTO was an exception. ------_=_NextPart_001_01C81BD8.7FBECEDA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [tcpm] WGLC for UTO


-----Original Message-----
From: Lars Eggert [mailto:lars.eggert@nokia.com] Sent: Wed 10/31/2007 12:47 AM
To: ext Joe Touch
Cc: tcpm@ietf.org
Subject: Re: [tcpm] WGLC for UTO

On 2007-10-30, at 18:07, ext Joe Touch wrote:
> Lars Eggert wrote:
>> The intent was to make UTO work with SYN cookie implementations = that
>> can't encode whether a UTO option was present in the cookie, = by
>> including the option also in the first non-SYN packets.
>
> That should be deemed non-compliant. The point of the SYN cookie is = to
> reestablish the entirety of state that would have been established = by
> the SYN; if the cookie can't do that, a cookie should not be = used.

Well, if the SYN requests (many) options and the receiver = cannot 
encode them all in the cookie, it can always reply with a = SYN-ACK 
that only echoes those that it can and does encode. That's = compliant, 
no?

----------- End of Original Message ---------------------

Compliant, yes, but not desirable. It would mean that any system
that had enabled SYN Cookie mode would stop accepting UTOs.
This is not a very intuitive model for application developers, and
would likely just add one more log to the "UTO is not = reliable" fire
and discourage it's use.

What I think we want is for any system in the passive role that is
*capable* of doing UTO to refrain from doing any action that would
block enabling UTO on the first non-SYN received.

It is especially important that the passive side not be *obligated*
to remember that there was no UTO option in the SYN packet, as
in *expecting* it to reject later packets for having improper = options.
That would essentially mean that the system would have to disable
UTO *permanently* as soon as it enabled SYN Cookies once (unless
it was actually going to track which connections were established
when and check that in real-time).

My understanding of including the UTO in both the SYN as well
as the first non-SYN was that network monitoring equipment (or
software) would expect any negotiated option to have been present
in the SYN and likely would not know that UTO was an exception.

------_=_NextPart_001_01C81BD8.7FBECEDA-- --===============0183944556== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0183944556==-- From tcpm-bounces@ietf.org Wed Oct 31 12:32:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InGTV-0004co-0H; Wed, 31 Oct 2007 12:31:25 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1InGTT-0004Z2-DX for tcpm-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 12:31:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InGTT-0004Yu-3e for tcpm@ietf.org; Wed, 31 Oct 2007 12:31:23 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InGTL-0006Y1-Ee for tcpm@ietf.org; Wed, 31 Oct 2007 12:31:23 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9VGUfEk001896; Wed, 31 Oct 2007 18:31:10 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 18:30:50 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 18:30:50 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 18:30:49 +0200 Received: from [172.21.35.97] (esdhcp03597.research.nokia.com [172.21.35.97]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9VGUldL022854; Wed, 31 Oct 2007 18:30:48 +0200 In-Reply-To: <4728A553.2020300@isi.edu> References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> <582A6F13-12CC-4B5C-8415-CBDAD73116AA@nokia.com> <4728A553.2020300@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <6B3D5E1D-F2DA-428C-AAEF-6F548F48F4F5@nokia.com> From: Lars Eggert Subject: Re: [tcpm] WGLC for UTO Date: Wed, 31 Oct 2007 18:30:47 +0200 To: ext Joe Touch X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Oct 2007 16:30:49.0230 (UTC) FILETIME=[655ADAE0:01C81BDB] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1920564859==" Errors-To: tcpm-bounces@ietf.org --===============1920564859== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-66-792682471; protocol="application/pkcs7-signature" --Apple-Mail-66-792682471 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-10-31, at 17:54, ext Joe Touch wrote: > Lars Eggert wrote: >> On 2007-10-30, at 18:07, ext Joe Touch wrote: >>> Lars Eggert wrote: >>>> The intent was to make UTO work with SYN cookie implementations >>>> that >>>> can't encode whether a UTO option was present in the cookie, by >>>> including the option also in the first non-SYN packets. >>> >>> That should be deemed non-compliant. The point of the SYN cookie >>> is to >>> reestablish the entirety of state that would have been >>> established by >>> the SYN; if the cookie can't do that, a cookie should not be used. >> >> Well, if the SYN requests (many) options and the receiver cannot >> encode >> them all in the cookie, it can always reply with a SYN-ACK that only >> echoes those that it can and does encode. That's compliant, no? > > It is, but only if current SYN cookie responses for stacks that don't > support UTO could be detected. I'm not sure that's possible. Can you rephrase? I don't follow. (Maybe it's too late in the day here.) >>> TCP has no provisions for post-SYN establishment of new >>> connection state >>> AFAIK. Requiring this of this option would be new, and, IMO, a bit >>> confusing for designers. What happens if the post-SYN packet >>> lacks the >>> option? do you declare state mis-synchronization and drop it? >> >> No - the UTO option is purely advisory and not transmitted >> reliably. We >> had a long thread a while ago on the list that boiled down to that >> consensus. (I can dig it up if you like me to.) The gist was that it >> should be OK these days to send new options during a connection, >> even if >> the SYN exchange didn't negotiate their use. > > Then there's no point in having the SYN cookie encode anything. If the SYN cookie could always encode the UTO value, we didn't need to also include a UTO with the first non-SYN packet. But I don't know of any SYN cookie encoding that can. (And SYN cookies aren't standardized anyway.) All this is a very narrow corner case anyway. The main motivation for sending UTO twice (in the SYN and first non-SYN segment) was to make sure it takes effect as early as possible in the connection. If this is a showstopper, we could remove the recommendation to send it in the SYNs and only recommend to send it in the first non-SYN. > Receivers that implement SYN cookies MAY drop the option; senders > sending UTO have no reason to resend, since it's 'advisory and not > transmitted reliably'. > > I.e., you can't have it both ways. If this is truly unreliable, then > there is NO reason to ever retransmit it. The reason we special-cased this is that we know of a case (SYN cookies) where a UTO on the SYN will be "dropped" (because it can't be encoded). As I said above, we can remove this special case, if people feel this is cleaner. >> We can add that TCP should try for a few segments to include a TO >> option >> if it wants to send one, but I don't think notifying the >> application on >> failure is necessary, because UTO options are advisory and not >> transmitted reliably. Not being able to include it locally is >> equivalent >> to having the segment that it was included on being dropped in the >> network. > > Again, if that's the case, then try to send it ONCE. Never retry - > there's no point. It was YOUR suggestion in an earlier email to try and include a UTO in one of a small sequence of a few consecutive segments if option space limitation prevented sending it on the next outgoing segment. The draft doesn't have this. >>> Can someone on the path do something you don't want to your >>> connection >>> by tacking this option on? >> >> So that's a different question than your original one, which was >> changing the value very frequently. >> >> An attacker that adds or modifies the content of UTO options may >> be able >> to affect how long the ends keep the connection alive. Since UTO is >> advisory, an attacker can't really do anything to the connection that >> couldn't happen anyway. > > I'm not sure that's true; even though it's advisory, it can cause a > change in behavior - if not, then there's no point in sending it. An > attacker could cause large UTOs for receivers that act on the option, > which could cause a DOS opportunity. Sure, but nothing in TCP is resistant against on-path attackers. We can certainly mention that there is a danger, but an on-path attacker can do all sorts of other things to a connection. >>>>> About retransmission, IMO, it SHOULD be done - or else what's >>>>> the point >>>>> of this? >>>> >>>> Is this related to your previous comment? If so, there was >>>> consensus to >>>> not make UTO reliable, i.e., retransmit lost options. >>> >>> I have no idea what the point of an unreliable option on a reliable >>> transport protocol means. IMO, options should be retransmitted when >>> their associated segments are. The control protocol ought to be >>> at least >>> as robust as the data. Although I appreciate that UTO isn't as >>> critical >>> as some other options or flags, introducing nondeterminism at >>> this level >>> doesn't seem appropriate, IMO. >> >> We had a long discussion on this a year or two ago on this list. The >> outcome was that because UTO is advisory, a simple, unreliable >> transmission is sufficient. We can certainly revisit this >> decision, but >> I'd personally would like to see strong WG consensus on changing this >> pretty central assumption behind UTO this late in the game. > > Agreed. Noted. Thanks, Lars --Apple-Mail-66-792682471 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMzExNjMwNDdaMCMGCSqGSIb3DQEJBDEWBBSKaEEkzVl7LrgW JnzmBVaI/3cagTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAdqRJeL5QVDxAYh6GnF7iXGSviwrYCVyDsRbr1uGh4bQ32Y3Vb7U+ kelm0BF/cm8btrgkvTPl01TSToSMguUnL6T4pSfBVn/4h+TFE+RRg1MUr4agwpjx6dLQ2ilZNT/E 1BY421QgZt0tVoOwrs0/Zdprx3CQhSPwomx6m9aJ39iT/1gcsgnXDyQ/CbB2L2NBEbYEH1IwCzjT 5b17IL+etM7X8MGDzZX3XrdpE0pPcBWfZRiAdvrtuGP8uLqWWDwW9/PO3irBOcEp36ghSecN/0fK 1muorRr3pfHru6UWdldKbpeWpPpvWvAz/kjfyHNt9h58aXH/YED8Ji6tIwBabgAAAAAAAA== --Apple-Mail-66-792682471-- --===============1920564859== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1920564859==--