From tcpm-bounces@ietf.org Tue Apr 03 04: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 1HYeJF-0004OY-22; Tue, 03 Apr 2007 04:24:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYeJD-0004OQ-Tg for tcpm@ietf.org; Tue, 03 Apr 2007 04:24:07 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYeJ2-0007TB-6I for tcpm@ietf.org; Tue, 03 Apr 2007 04:24:07 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8FA22215EF; Tue, 3 Apr 2007 10:23:51 +0200 (CEST) X-AuditID: c1b4fb3e-af9eebb0000061ca-25-46120f179fc3 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6E1D521622; Tue, 3 Apr 2007 10:23:51 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 10:23:50 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 10:23:48 +0200 Message-ID: <46120F14.4030907@ericsson.com> Date: Tue, 03 Apr 2007 10:23:48 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [tcpm] 'Updates' vs an extension References: <20070322191450.90FC41B430B@lawyers.icir.org> <460316DB.60700@isi.edu> <46038F85.8050901@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Apr 2007 08:23:48.0726 (UTC) FILETIME=[676A8960:01C775C9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ext Joe Touch , tcpm@ietf.org, Mark Allman 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 think there is one thing you have been really missing in how to handle this document. If you don't desire to make it an required integral part of TCP but consider it an extension the right way forward seem to be to write an applicability statement initially in the document. The AS describe when it should be used. In that you can put the recommendation to use it for certain TCP usages etc. Under the assumption that you achieve consensus on what to write in it. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Apr 03 16:28: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 1HYpbD-0001f4-FW; Tue, 03 Apr 2007 16:27:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYpbC-0001es-74 for tcpm@ietf.org; Tue, 03 Apr 2007 16:27:26 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYpb9-0003I5-Qx for tcpm@ietf.org; Tue, 03 Apr 2007 16:27:26 -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 l33KAasO002848 for ; Tue, 3 Apr 2007 13:10:36 -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 7BD4898971C for ; Tue, 3 Apr 2007 16:10:30 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 85DAE1C3901 for ; Tue, 3 Apr 2007 16:10:07 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Play Guitar MIME-Version: 1.0 Date: Tue, 03 Apr 2007 16:10:07 -0400 Message-Id: <20070403201007.85DAE1C3901@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [tcpm] strength of tcpsecure recommendation 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="===============0740250599==" Errors-To: tcpm-bounces@ietf.org --===============0740250599== 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- I'd like to try to be a bit systematic about figuring out how to proceed with the tcpsecure i-d and so I have cooked a poll below. The essential questions on the table is the mitigations ought to be labeled as SHOULD or MAY and whether these labels ought to be conditioned or not. We have had some good conversation on the topic and lots of points have been aired (how baked these solutions are, IPR, cost v. benefit, etc.). So, I am asking that the answers to the following questions be succinct and not rehash a bunch of previous argument. If you feel you have a **new** point then that is clearly fine. I am trying to get a good read of the WG here and so even if you have clearly aired opinions before, please take the minute and answer these questions. (Note that SHOULD and MAY are clearly not the only choices. If you want to vote for MUST or MUST NOT then that is fine, even though they are not listed as choices below. If you do, please then do provide some justification.) The questions then ... (1) (a) Do you believe the draft should allow the "blind reset attack using the RST bit" mitigation described in section 3 of the document as a SHOULD or a MAY? (b) Should we apply a condition to the recommendation? If so, please state the condition you'd like to see very succinctly. (2) (a) Do you believe the draft should allow the "blind reset attack using the SYN bit" mitigation described in section 4 of the document as a SHOULD or a MAY? (b) Should we apply a condition to the recommendation? If so, please state the condition you'd like to see very succinctly. (3) (a) Do you believe the draft should allow the "blind data injection attack" mitigation described in section 5 of the document as a SHOULD or a MAY? (b) Should we apply a condition to the recommendation? If so, please state the condition you'd like to see very succinctly. Thanks in advance for the input! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGErSfWyrrWs4yIs4RAinwAJkBw+L9c9La6D332Shcim1AbwWrcwCeIaxg GuibOYoRZ4VbKC2aXMYZBKc= =aNHo -----END PGP SIGNATURE----- --=_bOundary-- --===============0740250599== 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 --===============0740250599==-- From tcpm-bounces@ietf.org Wed Apr 04 15:52: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 1HZBVl-0005iq-GX; Wed, 04 Apr 2007 15:51:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBV7-0004fN-0i; Wed, 04 Apr 2007 15:50:37 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZBV6-0000pE-DC; Wed, 04 Apr 2007 15:50:36 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 6DD1B17689; Wed, 4 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HZBUY-0001gI-5I; Wed, 04 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 04 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-soft-errors-05.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP's Reaction to Soft Errors Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-soft-errors-05.txt Pages : 13 Date : 2007-4-4 This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages received in any of the non-synchronized states, that rejects connections experiencing those errors immediately. This behavior reduces the likelihood of long delays between connection establishment attempts that may arise in a number of scenarios, including one in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-soft-errors-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-soft-errors-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-4132806.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-soft-errors-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-soft-errors-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-4132806.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Thu Apr 05 14:08: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 1HZWMs-0001bL-5w; Thu, 05 Apr 2007 14:07:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZWMq-0001b8-J8; Thu, 05 Apr 2007 14:07:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZWMn-0003oM-Ur; Thu, 05 Apr 2007 14:07:28 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 05 Apr 2007 11:07:25 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l35I7PkO026019; Thu, 5 Apr 2007 11:07:25 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l35I7Own023694; Thu, 5 Apr 2007 18:07:24 GMT From: "Dan Wing" To: , Date: Thu, 5 Apr 2007 11:07:24 -0700 Message-ID: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: Acd3rUMBGcI0xNRnTP+Fkd1y4lbzTQ== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1425; t=1175796445; x=1176660445; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20icmp=20type=203,=20code=2013 |Sender:=20; bh=o9VvQWx4GBNA8CyaJHcacRh3TWkbAgc9x750I2z8vYw=; b=o+7GF4xrMpIZJu6eL/AOCncTx3uhcTUbkx3XAY7u8iZlPJPDTa7ADvq2qwgBSWbqxkpiGnWB 6+Q0le4TlxwxbHR9JXm0dk/IMWbsY3IoDOba/j+3r8XYj2y1miOVSLJq; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Faisal Siyavudeen Subject: [tcpm] icmp type 3, code 13 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 In section 6 of draft-ietf-behave-nat-icmp-03, it is recommended to use ICMP type 3, code 13 to indicate an administratively-prohibited flow. ICMP type 3, code 13 was originally specified in RFC1812: "... 13 = Communication Administratively Prohibited - generated if a router cannot forward a packet due to administrative filtering; ... Routers SHOULD use the newly defined Code 13 (Communication Administratively Prohibited) if they administratively filter packets. Routers MAY have a configuration option that causes Code 13 (Communication Administratively Prohibited) messages not to be generated. When this option is enabled, no ICMP error message is sent in response to a packet that is dropped because its forwarding is administratively prohibited. ..." For the purposes of draft-ietf-behave-nat-icmp, ICMP type 3, code 13 needs to be considered a hard error. However, I am unable to find a reference indicating if ICMP type 3, code 13 is considered a hard error or soft error. Is there such a reference? I doubt existing stacks consider it a hard error, though, as code 13 is not on RFC1122's list of hard errors (which makes sense, as RFC1122 predates RFC1812's publication). (The use of Code 13 was originally my suggestion, but perhaps it is ill-suited if it hasn't been interpreted as a hard error since RFC1812's publication.) -d _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Apr 05 14:28:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZWga-0005D3-S4; Thu, 05 Apr 2007 14:27:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZWgY-0005C2-Ej; Thu, 05 Apr 2007 14:27:51 -0400 Received: from dns2-ana.paetec.net ([66.251.33.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZWgW-0007U5-Up; Thu, 05 Apr 2007 14:27:50 -0400 Received: from [127.0.0.1] ([63.139.31.103]) by dns2-ana.paetec.net (8.13.6/8.13.6) with ESMTP id l35IRYBC004807; Thu, 5 Apr 2007 14:27:41 -0400 (EDT) Message-ID: <46153F88.3000703@isi.edu> Date: Thu, 05 Apr 2007 11:27:20 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Dan Wing Subject: Re: [tcpm] icmp type 3, code 13 References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> In-Reply-To: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> X-Enigmail-Version: 0.94.1.2.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tcpm@ietf.org, behave@ietf.org, Faisal Siyavudeen 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="===============0099980320==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0099980320== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF406B0C2508A9DCDF19BCE54" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF406B0C2508A9DCDF19BCE54 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, Dan Wing wrote: > In section 6 of draft-ietf-behave-nat-icmp-03, it is recommended to use= ICMP > type 3, code 13 to indicate an administratively-prohibited flow. ICMP = type > 3, code 13 was originally specified in RFC1812: >=20 > "... > 13 =3D Communication Administratively Prohibited - generated if a > router cannot forward a packet due to administrative filtering;= > ... > Routers SHOULD use the newly defined > Code 13 (Communication Administratively Prohibited) if they > administratively filter packets. >=20 > Routers MAY have a configuration option that causes Code 13 > (Communication Administratively Prohibited) messages not to be > generated. When this option is enabled, no ICMP error message is > sent in response to a packet that is dropped because its forwarding > is administratively prohibited. > ..." >=20 > For the purposes of draft-ietf-behave-nat-icmp, ICMP type 3, code 13 ne= eds > to be considered a hard error. However, I am unable to find a referenc= e > indicating if ICMP type 3, code 13 is considered a hard error or soft e= rror. > Is there such a reference? I doubt existing stacks consider it a hard > error, though, as code 13 is not on RFC1122's list of hard errors (whic= h > makes sense, as RFC1122 predates RFC1812's publication). >=20 > (The use of Code 13 was originally my suggestion, but perhaps it is > ill-suited if it hasn't been interpreted as a hard error since RFC1812'= s > publication.) I don't see a place where type 3 code 13 is defined in terms of host behavior. I don't know if you can or should require hard or soft error response to this code. Code 10 - communication with destination host administratively prohibited - is similar in spirit (it's a "won't" rather than a "can't"), and 1122 doesn't require either a hard or soft error on that one. IMO, it's up to the host to decide how to handle that error, just like 12, and that seems reasonable. That said, why are you using code 13, vs code 10? This isn't really because of a router doing administrative filtering; IMO, code 10 is sufficient. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigF406B0C2508A9DCDF19BCE54 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.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFT+IE5f5cImnZrsRAkV5AJ4pqbWTx31SbZDkXxdBne/Yhjg6lwCfWs6B Dmj3SxHui3wWl3LRVyYJcVQ= =shJq -----END PGP SIGNATURE----- --------------enigF406B0C2508A9DCDF19BCE54-- --===============0099980320== 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 --===============0099980320==-- From tcpm-bounces@ietf.org Fri Apr 06 11:29: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 1HZqLp-0001LX-O8; Fri, 06 Apr 2007 11:27:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZqLn-0001Gd-Vt for tcpm@ietf.org; Fri, 06 Apr 2007 11:27:44 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZqLm-00087B-IQ for tcpm@ietf.org; Fri, 06 Apr 2007 11:27:43 -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 l36FRfFQ018276; Fri, 6 Apr 2007 08:27:41 -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 1487499E99C; Fri, 6 Apr 2007 11:27:36 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 33E2F1C7EEE; Fri, 6 Apr 2007 11:27:33 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Subject: Re: [tcpm] WGLC for SYN flooding In-Reply-To: <20070327212827.GE26658@hut.isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Play Guitar MIME-Version: 1.0 Date: Fri, 06 Apr 2007 11:27:33 -0400 Message-Id: <20070406152733.33E2F1C7EEE@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Ted Faber 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="===============1950519508==" Errors-To: tcpm-bounces@ietf.org --===============1950519508== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline A quick reminder that the WGLC for the SYN flooding document ends in one week. Even if you have no comments on the document, a quick 'I read it and it looks fine' note would be very much appreciated. We need to make sure people are looking at this. Thanks, allman > Mark and I would like to start a WG last call on the SYN flooding and > countermeasures document: > > Title : TCP SYN Flooding Attacks and Common Mitigations > Author(s) : W. Eddy > Filename : draft-ietf-tcpm-syn-flood-02.txt > Pages : 23 > Date : February 2007 > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-syn-flood-02.txt > > which is slated for informational. Our understanding is that all > feedback to date is reflected in this version and that there are no > known outstanding issues. But, it'd be great if folks can verify that > and in general give this one more look. Please send feedback (even if > just of the form "yep, looks good"). > > Despite the fact we're starting this a day later than we intended, we're > planning on wrapping up comments on 13 Apr 2007. Yes, that's a Friday. > > Again, please send comments, especially of the form "I read it and think > it's fine." --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGFmblWyrrWs4yIs4RArnSAJ0YjA8d2rUmskWcQ6/Ltx9EirPCQwCeK3w3 PGKPp6r5X1jaLpnBaOmGzig= =cD/M -----END PGP SIGNATURE----- --=_bOundary-- --===============1950519508== 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 --===============1950519508==-- From tcpm-bounces@ietf.org Fri Apr 06 13:01: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 1HZrnT-0002WK-0n; Fri, 06 Apr 2007 13:00:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZrnS-0002WA-07 for tcpm@ietf.org; Fri, 06 Apr 2007 13:00:22 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZrnP-0000we-M8 for tcpm@ietf.org; Fri, 06 Apr 2007 13:00:21 -0400 Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 06 Apr 2007 10:00:04 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id D262D2B0; Fri, 6 Apr 2007 10:00:04 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id BED682AF; Fri, 6 Apr 2007 10:00:04 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FDW84459; Fri, 6 Apr 2007 09:59:56 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 9099969CA4; Fri, 6 Apr 2007 09:59:56 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] WGLC for SYN flooding Date: Fri, 6 Apr 2007 09:59:55 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D0360E432@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <20070406152733.33E2F1C7EEE@lawyers.icir.org> Thread-Topic: [tcpm] WGLC for SYN flooding Thread-Index: Acd4YFkeBVqGhgZMSYykGO1dJ1s2KwADJP4g From: "Caitlin Bestler" To: mallman@icir.org, tcpm@ietf.org X-WSS-ID: 6A08A31E38G13494349-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Ted Faber 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 Mark Allman wrote: > A quick reminder that the WGLC for the SYN flooding document > ends in one week. Even if you have no comments on the > document, a quick 'I read it and it looks fine' note would be > very much appreciated. We need to make sure people are looking at > this.=20 >=20 > Thanks, > allman >=20 Looks good to me. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 06 17:17: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 1HZvnU-0001a5-1F; Fri, 06 Apr 2007 17:16:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZvnS-0001Vw-2t; Fri, 06 Apr 2007 17:16:38 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZvnO-00055k-Mc; Fri, 06 Apr 2007 17:16:38 -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 l36LGXoB022390; Fri, 6 Apr 2007 14:16:33 -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 D887B9A08EB; Fri, 6 Apr 2007 17:16:27 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id DF8781C8DBC; Fri, 6 Apr 2007 17:16:24 -0400 (EDT) To: Michael Scharf From: Mark Allman Subject: Re: [tcpm] Extending RFC 1323 window scaling? In-Reply-To: <20070331111615.GA29580@ikr.uni-stuttgart.de> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Play Guitar MIME-Version: 1.0 Date: Fri, 06 Apr 2007 17:16:24 -0400 Message-Id: <20070406211624.DF8781C8DBC@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: tcpm@ietf.org, tsvwg@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="===============1271960261==" Errors-To: tcpm-bounces@ietf.org --===============1271960261== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > (1) The semantics of the SEG.WND field in the TCP header could be > changed, i. e., the receive window is scaled in > segments under some constraints. Whether or not the receive > window is scaled could be announced explicitly by a flag, or > implicitly, e. g., due to the presence of Quick-Start options or > other options. However, changing the semantics of the receive > window header field creates interoperation issues with hosts > that do not implement such a modification. > > (2) The true amount of free buffer space is announced somehow, and > overwrites the (unscaled) value in the TCP header, which remains > unscaled in order to be compatible with hosts that do not > implement this mechanism. This requires some new mechanism to > signal a scaled receive window in segments. > > The proposed new TCP option is a straightforward realization of > approach (2). I am not sure if we need a (2). As you note, Quick-Start is currently the only thing that really runs into a problem and maybe something else could. To be precise, I think we can say that the only place where this is a problem is when the initiator of a connection wants to (and can) send more than 64KB in the first RTT of the connection. Unless we pretty drastically change the rules it seems that this is going to have to be done only with some explicit communication and so using that as an implicit signal seems fine to me. (We clearly botched this in terms of Quick-Start because we were too dumb to think of it and you found it after publication.) Further, it is not clear that we need to add new functionality like this for something experimental (Quick-Start). But, maybe ... If I were going to take approach (2) I would suggest a two-byte option that indicates the value in the standard TCP header is to be scaled. Why add another 2 byte window value when one of them is going to be ignored? This fails safe because if a host doesn't understand the new ("the window is scaled") option it will think the advertised window is unscaled and so less than it really is and so there is no danger in running into problems. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGFrioWyrrWs4yIs4RAq+jAKCPDevUDeFqkHFtZ7yYHWLLBrgwRACfZU3p xqyQPn3AvJ59k5thbqRoMSM= =Evjf -----END PGP SIGNATURE----- --=_bOundary-- --===============1271960261== 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 --===============1271960261==-- From tcpm-bounces@ietf.org Mon Apr 09 11:15:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HavZ4-00018q-3a; Mon, 09 Apr 2007 11:13:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HavZ3-00018l-En for tcpm@ietf.org; Mon, 09 Apr 2007 11:13:53 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HavZ2-0002vA-0w for tcpm@ietf.org; Mon, 09 Apr 2007 11:13:53 -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 l39FDS6J010331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 9 Apr 2007 08:13:28 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l39FDSjX081301 for tcpm@ietf.org; Mon, 9 Apr 2007 08:13:28 -0700 (PDT) (envelope-from faber) Date: Mon, 9 Apr 2007 08:13:28 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20070409151328.GB1285@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.2i 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: c1c65599517f9ac32519d043c37c5336 Subject: [tcpm] WGLC: TCP's Reaction to Soft Errors 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="===============1806546819==" Errors-To: tcpm-bounces@ietf.org --===============1806546819== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l76fUT7nc3MelDdI" Content-Disposition: inline --l76fUT7nc3MelDdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mark and I would like to start a WG last call on the informational document on TCP's reaction to soft ICMP errors on connection set-up: Title : TCP's Reaction to Soft Errors Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-soft-errors-05.txt Pages : 13 Date : 2007-4-4 http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-05.txt Our understanding is that all feedback to date is reflected in this version and that there are no known outstanding issues. Please send feedback (even if just of the form "yep, looks good"). This WGLC will end on Monday 23 Apr 2007. Again, please send comments, especially of the form "I read it and think it's fine." --=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 --l76fUT7nc3MelDdI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGGlgYaUz3f+Zf+XsRAnuDAKCfRS4VI7Xw5hx8RnWV/kOQtRaUZwCgjs7E mKrImGKIzSQFpdgKt0w14Nw= =0XPK -----END PGP SIGNATURE----- --l76fUT7nc3MelDdI-- --===============1806546819== 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 --===============1806546819==-- From tcpm-bounces@ietf.org Mon Apr 09 13:21:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaxXZ-0003yM-Lz; Mon, 09 Apr 2007 13:20:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaxXX-0003va-PF for tcpm@ietf.org; Mon, 09 Apr 2007 13:20:27 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaxXW-0003xh-AO for tcpm@ietf.org; Mon, 09 Apr 2007 13:20:27 -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 l39HJdLr020066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 9 Apr 2007 10:19:39 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l39HJd7Q022371 for tcpm@ietf.org; Mon, 9 Apr 2007 10:19:39 -0700 (PDT) (envelope-from faber) Date: Mon, 9 Apr 2007 10:19:38 -0700 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors Message-ID: <20070409171938.GC1301@hut.isi.edu> References: <20070409151328.GB1285@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20070409151328.GB1285@hut.isi.edu> User-Agent: Mutt/1.4.2.2i 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: 769a46790fb42fbb0b0cc700c82f7081 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="===============0511781642==" Errors-To: tcpm-bounces@ietf.org --===============0511781642== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GZVR6ND4mMseVXL/" Content-Disposition: inline --GZVR6ND4mMseVXL/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2007 at 08:13:28AM -0700, Ted Faber wrote: > Mark and I would like to start a WG last call on the informational > document on TCP's reaction to soft ICMP errors on connection set-up: >=20 > Title : TCP's Reaction to Soft Errors > Author(s) : F. Gont > Filename : draft-ietf-tcpm-tcp-soft-errors-05.txt > Pages : 13 > Date : 2007-4-4 >=20 > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-05.txt Mark points out that I should mention that the last non-editorial change to this draft was the addition of several omitted error codes from Section 2 when the draft was revised from -04 to -05. WGLC readers should make sure that the draft does address all the codes. There have been several editorial only revisions of this draft, so if you had difficulties with tone or focus in earlier drafts, please have a look and see if those issues have been addressed. --=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 --GZVR6ND4mMseVXL/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGGnWqaUz3f+Zf+XsRAv16AKD4Xy7gpPFBFyV0n/jQJXlWE8syGwCdEQix Z0ch96vXCzwJNxaGlQkjNk0= =TyRC -----END PGP SIGNATURE----- --GZVR6ND4mMseVXL/-- --===============0511781642== 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 --===============0511781642==-- From tcpm-bounces@ietf.org Tue Apr 10 01:19: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 1Hb8kC-0007I3-PG; Tue, 10 Apr 2007 01:18:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb8kB-0007Hl-VZ for tcpm@ietf.org; Tue, 10 Apr 2007 01:18:15 -0400 Received: from [2001:fa8::25] (helo=mail.nttv6.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb8k8-0000S9-SE for tcpm@ietf.org; Tue, 10 Apr 2007 01:18:15 -0400 Received: from [192.47.163.196] (dhcp-3-196.nttv6.com [192.47.163.196]) by mail.nttv6.net (8.14.1/8.13.8) with ESMTP id l3A5HwlK078574 for ; Tue, 10 Apr 2007 14:17:58 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-ID: <461B1DCE.1090209@nttv6.net> Date: Tue, 10 Apr 2007 14:17:02 +0900 From: Arifumi Matsumoto User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors References: <20070409151328.GB1285@hut.isi.edu> <20070409171938.GC1301@hut.isi.edu> In-Reply-To: <20070409171938.GC1301@hut.isi.edu> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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, all. Ted Faber wrote: > On Mon, Apr 09, 2007 at 08:13:28AM -0700, Ted Faber wrote: >> Mark and I would like to start a WG last call on the informational >> document on TCP's reaction to soft ICMP errors on connection set-up: >> >> Title : TCP's Reaction to Soft Errors >> Author(s) : F. Gont >> Filename : draft-ietf-tcpm-tcp-soft-errors-05.txt >> Pages : 13 >> Date : 2007-4-4 >> >> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-05.txt > > Mark points out that I should mention that the last non-editorial change > to this draft was the addition of several omitted error codes from > Section 2 when the draft was revised from -04 to -05. WGLC readers > should make sure that the draft does address all the codes. > > There have been several editorial only revisions of this draft, so if > you had difficulties with tone or focus in earlier drafts, please have a > look and see if those issues have been addressed. I looked at changes in section 2, and I found that I couldn't even parse these sentences(2nd paragraph of Section 2). Surely, I know that I'm not good at English, but aren't these a bit complicated ? I like the methods proposed in this draft, but I feel more comfortable if these sentences are written in plainer English. Best regards, -- Arifumi Matsumoto IP Technology Expert Team Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Apr 10 03:22:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbAfh-00026b-8L; Tue, 10 Apr 2007 03:21:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbAfe-00024K-Tu; Tue, 10 Apr 2007 03:21:42 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbAfe-0003r4-Et; Tue, 10 Apr 2007 03:21:42 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l3A7LHsN001738; Tue, 10 Apr 2007 10:21:17 +0300 Date: Tue, 10 Apr 2007 10:21:17 +0300 (EEST) From: Pekka Savola To: Joe Touch Subject: Re: [tcpm] icmp type 3, code 13 In-Reply-To: <46153F88.3000703@isi.edu> Message-ID: References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.1/3058/Mon Apr 9 22:45:50 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tcpm@ietf.org, behave@ietf.org, Faisal Siyavudeen , Dan Wing 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 Thu, 5 Apr 2007, Joe Touch wrote: ... > I don't know if you can or should require hard or soft error response to > this code. Code 10 - communication with destination host > administratively prohibited - is similar in spirit (it's a "won't" > rather than a "can't"), and 1122 doesn't require either a hard or soft > error on that one. > > IMO, it's up to the host to decide how to handle that error, just like > 12, and that seems reasonable. > > That said, why are you using code 13, vs code 10? This isn't really > because of a router doing administrative filtering; IMO, code 10 is > sufficient. 10 is: 10 Communication with Destination Host is Administratively Prohibited while 13 is: 13 Communication Administratively Prohibited [RFC1812] '10' seems to (at least more strongly) imply that all communication with the destination address is administratively prohibited. 13 is less specific; the same code applies even if you filtered the whole network, just one host, or only one port of a host. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Apr 10 04:49:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbC1Z-0003uE-42; Tue, 10 Apr 2007 04:48:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbC1X-0003u1-Ld for tcpm@ietf.org; Tue, 10 Apr 2007 04:48:23 -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 1HbC1W-0003vC-5U for tcpm@ietf.org; Tue, 10 Apr 2007 04:48:23 -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 l3A8mASm018182 for ; Tue, 10 Apr 2007 11:48:20 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 11:48:11 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 11:48:10 +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); Tue, 10 Apr 2007 11:48:10 +0300 Received: from [172.21.34.179] (esdhcp034179.research.nokia.com [172.21.34.179]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3A8m9Pb008069 for ; Tue, 10 Apr 2007 11:48:09 +0300 Mime-Version: 1.0 (Apple Message framework v752.3) To: tcpm@ietf.org Message-Id: From: Lars Eggert Date: Tue, 10 Apr 2007 11:47:58 +0300 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Apr 2007 08:48:10.0874 (UTC) FILETIME=[F7D0DDA0:01C77B4C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [tcpm] last open issue in UTO 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="===============1696129431==" Errors-To: tcpm-bounces@ietf.org --===============1696129431== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14-319183400; protocol="application/pkcs7-signature" --Apple-Mail-14-319183400 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, during the Prague presentation (http://www3.ietf.org/proceedings/ 07mar/slides/tcpm-1.pdf), I described the changes we made in the last revision. We tried to address reviewer comments that the text wasn't consistent with regard to how to respond to incoming UTO options. The change was to introduce a few pieces of per-connection state and describe UTO in terms of those variables. I heard some agreement that this has helped. (I'd like to hear more opinions.) That change has also re-opened an older issue. UTO could: (1) allow hosts to lengthen _and_ shorten the local UTO in response to incoming UTO options (if the local stack has allowed that) (2) allow hosts to only modify the local UTO in one direction, i.e., always lengthen it (lengthening is more useful to survive periods without end-to-end connectivity) (1) is obviously more flexible, but also requires us to maintain one more piece of per-connection state. (1) is also what the draft so far has described, and is thus probably WG consensus. (2) reduces overhead and make the mechanism a bit simpler. It can also be argued that the ability to shorten UTOs hasn't really been shown to be terribly useful (the argument was that busy servers could notify clients that they weren't keeping the connection around for long if end-to-end connectivity would go away, which lets the client do the same and conserve some resources.) I think Fernando prefers (1), and I have a slight preference for (2). Thoughts? (IMO this is the last open issue with the draft, and we should be able to settle this quickly.) Lars --Apple-Mail-14-319183400 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 MBwGCSqGSIb3DQEJBTEPFw0wNzA0MTAwODQ3NTlaMCMGCSqGSIb3DQEJBDEWBBSabSx2FK51WLDL FbjZlv2q94qhEzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAMiWCCsN45RBFKy975GKb5Cd6ZOvjBznQn+DytBNv6hGV30Cdpwa7 E82t87eO1/qB6GdqIBT7N7LQOjqYmD1mQouMrnDLkDc0KUroy7dhgprqUQtnCgoSK0NZUTEAINwo 6dA+AOBLVN10WV9dZTzJFxuweo7160CKXtXowUw/ypQ36KUu1zkN6uOB7JdWdOb+lTC+NPqSQsXe FmOmvKYejTaZe8UxIAUfJPQMX63n23qFglFzlY0jKHI5gdiOs5UjcDhD1d9Tn8Ns/vQbjinOc6gt 9aGnhItpoG6v2OBSJLLve7M/aKxGQ+LD2H56Yw/K0Jyw4rJI3QElQlg+UJua9AAAAAAAAA== --Apple-Mail-14-319183400-- --===============1696129431== 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 --===============1696129431==-- From tcpm-bounces@ietf.org Tue Apr 10 11:18:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbI6g-00074r-7Z; Tue, 10 Apr 2007 11:18:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbI6f-00074h-H2; Tue, 10 Apr 2007 11:18:05 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbI6Y-0000ci-F9; Tue, 10 Apr 2007 11:18:05 -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 l3AFHU49012570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Apr 2007 08:17:30 -0700 (PDT) Received: (from apache@localhost) by webmail.isi.edu (8.12.8/8.12.7) id l3AFHT1o023747; Tue, 10 Apr 2007 08:17:29 -0700 X-Authentication-Warning: webmail.isi.edu: apache set sender to touch@isi.edu using -f Received: from 166.21.12.193 ([166.21.12.193]) by webmail.isi.edu (IMP) with HTTP for ; Tue, 10 Apr 2007 08:17:29 -0700 Message-ID: <1176218249.461baa89926f4@webmail.isi.edu> Date: Tue, 10 Apr 2007 08:17:29 -0700 From: touch@ISI.EDU To: Pekka Savola Subject: Re: [tcpm] icmp type 3, code 13 References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> In-Reply-To: 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: 166.21.12.193 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tcpm@ietf.org, behave@ietf.org, Faisal Siyavudeen , Dan Wing 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 Pekka Savola : > On Thu, 5 Apr 2007, Joe Touch wrote: > ... > > I don't know if you can or should require hard or soft error response to > > this code. Code 10 - communication with destination host > > administratively prohibited - is similar in spirit (it's a "won't" > > rather than a "can't"), and 1122 doesn't require either a hard or soft > > error on that one. > > > > IMO, it's up to the host to decide how to handle that error, just like > > 12, and that seems reasonable. > > > > That said, why are you using code 13, vs code 10? This isn't really > > because of a router doing administrative filtering; IMO, code 10 is > > sufficient. > > 10 is: > > 10 Communication with Destination Host is > Administratively Prohibited > > while 13 is: > > 13 Communication Administratively Prohibited [RFC1812] > > '10' seems to (at least more strongly) imply that all communication > with the destination address is administratively prohibited. > > 13 is less specific; the same code applies even if you filtered the > whole network, just one host, or only one port of a host. If the entire network is filtered, 9 should be appropriate: 9 = communication with destination network administratively prohibited If a single port is filtered, a port-unreachable (code 3) should be generated. Administrative prohibition, as indicated in RFC1812, is based on policy: 13 = Communication Administratively Prohibited - generated if a router cannot forward a packet due to administrative filtering; I don't think NATs are considered filters per se, so 13 doesn't seem appropriate regardless. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Apr 10 12:15:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJ0T-0000f8-Ek; Tue, 10 Apr 2007 12:15:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJ0R-0000Rt-Ie; Tue, 10 Apr 2007 12:15:43 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbJ0Q-0004p5-73; Tue, 10 Apr 2007 12:15:43 -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 l3AGFC22027543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Apr 2007 09:15:12 -0700 (PDT) Received: (from apache@localhost) by webmail.isi.edu (8.12.8/8.12.7) id l3AGFC88024319; Tue, 10 Apr 2007 09:15:12 -0700 X-Authentication-Warning: webmail.isi.edu: apache set sender to touch@isi.edu using -f Received: from 166.21.12.193 ([166.21.12.193]) by webmail.isi.edu (IMP) with HTTP for ; Tue, 10 Apr 2007 09:15:12 -0700 Message-ID: <1176221712.461bb810b298a@webmail.isi.edu> Date: Tue, 10 Apr 2007 09:15:12 -0700 From: touch@ISI.EDU To: touch@ISI.EDU Subject: Re: [tcpm] icmp type 3, code 13 References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> <1176218249.461baa89926f4@webmail.isi.edu> In-Reply-To: <1176218249.461baa89926f4@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: 166.21.12.193 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Faisal Siyavudeen , tcpm@ietf.org, behave@ietf.org, Dan Wing 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: .. > > '10' seems to (at least more strongly) imply that all communication > > with the destination address is administratively prohibited. > > > > 13 is less specific; the same code applies even if you filtered the > > whole network, just one host, or only one port of a host. Let me be more specific: If you care that the source host acts with a hard error, you need to use an ICMP message that indicates that further attempts are not useful (codes 2-4). Other codes imply that there might be a change - e.g., administrative responses may differ later - and so should not be taken as a hard error. I disagree that 13 is less specific than 9 or 10; it's more specific, indicating that the reason for prohibition is filtering, vs. other administrative reasons. At the very least, draft-ietf-behave-nat-icmp-03.txt should be updated to indicate that 13 is used because of a *filter* based restriction. If this is not filter-based, then I think 9 or 10 is more appropriate. So, to get back to Dan's original issue and to summarize: - type 3 code 13 is NOT a hard error - nor, however, are corresponding type 3 codes 9 or 10 - if you want a hard error, use an existing one (safest) or define a new one with hard error behavior (IMO, more appropriate if that's your goal) - if we're talking about filtering, draft-ietf-behave-nat-icmp-03.txt needs to be updated where it discusses code 13 ICMP errors - if this isn't filtering, then code 9 or 10 should be used Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Apr 10 12:35: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 1HbJJ5-0002lI-36; Tue, 10 Apr 2007 12:34:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJJ4-0002l2-Ar; Tue, 10 Apr 2007 12:34:58 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbJIx-0007ih-DL; Tue, 10 Apr 2007 12:34:58 -0400 Received: from [127.0.0.1] (125.sub-75-209-178.myvzw.com [75.209.178.125]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3AGXwsN002001; Tue, 10 Apr 2007 09:34:03 -0700 (PDT) Message-ID: <461BBC60.6000906@isi.edu> Date: Tue, 10 Apr 2007 09:33:36 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Faisal Siyavudeen (fsiyavud)" Subject: Re: [tcpm] icmp type 3, code 13 References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tcpm@ietf.org, behave@ietf.org, "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" 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="===============1088013562==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1088013562== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0A18ADA2DB552AD487C8A716" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0A18ADA2DB552AD487C8A716 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Faisal Siyavudeen (fsiyavud) wrote: > | '10' seems to (at least more strongly) imply that all=20 > | communication with the destination address is=20 > | administratively prohibited. >=20 > Does NAT administrative filtering referred to by > draft-ietf-behave-nat-icmp-03 cover filtering of application traffic > based on destination port? If yes, what error would be generated by a > NAT filtering out a certain type of application traffic to a certain se= t > of hosts? In that case, code 10 would not be the right one, as the host= > might still be reachable on a different port. I feel that the actual > choice of error code would vary - it could be code 10 or code 13 > depending on the type of filtering. I don't see that difference; code 10 just says administratively prohibited, and code 13 says administratively prohibited because of filtering. In either case, other ports could be reachable. Joe --------------enig0A18ADA2DB552AD487C8A716 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.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGG7xkE5f5cImnZrsRAj8RAKC2kTistK0upJx7a2Bjq3kFaEMbowCguhkF c+3qYg4PwSmSzIxF6++NUeQ= =E1a3 -----END PGP SIGNATURE----- --------------enig0A18ADA2DB552AD487C8A716-- --===============1088013562== 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 --===============1088013562==-- From tcpm-bounces@ietf.org Tue Apr 10 13:33:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbKDC-0001QC-9l; Tue, 10 Apr 2007 13:32:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbKDA-0001Py-KA; Tue, 10 Apr 2007 13:32:56 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbKD6-0004G9-4T; Tue, 10 Apr 2007 13:32:56 -0400 Received: from [127.0.0.1] ([128.9.176.75]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3AHWAmM018076; Tue, 10 Apr 2007 10:32:15 -0700 (PDT) Message-ID: <461BCA0B.3010706@isi.edu> Date: Tue, 10 Apr 2007 10:31:55 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Faisal Siyavudeen (fsiyavud)" Subject: Re: [tcpm] icmp type 3, code 13 References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> <461BBC60.6000906@isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: tcpm@ietf.org, behave@ietf.org, "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" 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="===============1105247559==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1105247559== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2F3997FA8D0AA29E9075454C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2F3997FA8D0AA29E9075454C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Faisal Siyavudeen (fsiyavud) wrote: > | > it could be code 10 or code 13 depending on the type of filtering. > |=20 > | I don't see that difference; code 10 just says=20 > | administratively prohibited, and code 13 says=20 > | administratively prohibited because of filtering. In either=20 > | case, other ports could be reachable. > |=20 >=20 > I agree. >=20 > I am sorry I was not clear - my point was that 10 cannot be used where > other ports on the hosts are still accessible, while 13 can be used in > any of these cases. BTW, the following note in RFC 1812 makes me wonder= > if NAT devices can send code 10 at all as they are more like routers: Uh, routers decrement the TTL. NATs do not. I don't think NATs behave like routers per se. > > Codes 9 and 10 were intended for use by end-to-end encryption devices > used by U.S military agencies. Routers SHOULD use the newly defined Cod= e > 13 (Communication Administratively Prohibited) if they administratively= > filter packets. > That argues that NATs should generate their own codes. This is NOT router administrative filtering either. Joe > | -----Original Message----- > | From: Joe Touch [mailto:touch@ISI.EDU]=20 > | Sent: Tuesday, April 10, 2007 10:04 PM > | To: Faisal Siyavudeen (fsiyavud) > | Cc: Pekka Savola; Dan Wing (dwing); tcpm@ietf.org;=20 > | behave@ietf.org; Mahesh Govind (mgovind) > | Subject: Re: [tcpm] icmp type 3, code 13 > |=20 > |=20 > |=20 > | Faisal Siyavudeen (fsiyavud) wrote: > | > | '10' seems to (at least more strongly) imply that all=20 > | communication=20 > | > | with the destination address is administratively prohibited. > | >=20 > | > Does NAT administrative filtering referred to by > | > draft-ietf-behave-nat-icmp-03 cover filtering of=20 > | application traffic=20 > | > based on destination port? If yes, what error would be=20 > | generated by a=20 > | > NAT filtering out a certain type of application traffic to=20 > | a certain=20 > | > set of hosts? In that case, code 10 would not be the right=20 > | one, as the=20 > | > host might still be reachable on a different port. I feel that the = > | > actual choice of error code would vary - it could be code=20 > | 10 or code=20 > | > 13 depending on the type of filtering. > |=20 > | I don't see that difference; code 10 just says=20 > | administratively prohibited, and code 13 says=20 > | administratively prohibited because of filtering. In either=20 > | case, other ports could be reachable. > |=20 > | Joe > |=20 > |=20 --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig2F3997FA8D0AA29E9075454C 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.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGG8oME5f5cImnZrsRAquLAJ97Hl5DA3y+u5pQ1x+CSKLKPjbjgwCcCdqD CAKtAG6iY2F9kFhoBSALvB8= =YA8q -----END PGP SIGNATURE----- --------------enig2F3997FA8D0AA29E9075454C-- --===============1105247559== 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 --===============1105247559==-- From tcpm-bounces@ietf.org Tue Apr 10 13:55: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 1HbKYP-0003Yu-Vr; Tue, 10 Apr 2007 13:54:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbKYP-0003Wb-31; Tue, 10 Apr 2007 13:54:53 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbKYO-0000hJ-JV; Tue, 10 Apr 2007 13:54:53 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l3AHshQH015544; Tue, 10 Apr 2007 20:54:43 +0300 Date: Tue, 10 Apr 2007 20:54:43 +0300 (EEST) From: Pekka Savola To: Joe Touch Subject: Re: [tcpm] icmp type 3, code 13 In-Reply-To: <461BCA0B.3010706@isi.edu> Message-ID: References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> <461BBC60.6000906@isi.edu> <461BCA0B.3010706@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.1/3058/Mon Apr 9 22:45:50 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org, "Faisal Siyavudeen \(fsiyavud\)" , behave@ietf.org, "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" 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 Tue, 10 Apr 2007, Joe Touch wrote: > Faisal Siyavudeen (fsiyavud) wrote: >> | > it could be code 10 or code 13 depending on the type of filtering. >> | >> | I don't see that difference; code 10 just says >> | administratively prohibited, and code 13 says >> | administratively prohibited because of filtering. In either >> | case, other ports could be reachable. >> | >> >> I agree. >> >> I am sorry I was not clear - my point was that 10 cannot be used where >> other ports on the hosts are still accessible, while 13 can be used in >> any of these cases. BTW, the following note in RFC 1812 makes me wonder >> if NAT devices can send code 10 at all as they are more like routers: > > Uh, routers decrement the TTL. NATs do not. I don't think NATs behave > like routers per se. YMMV but all NATs I have seen and used do decrement TTL. (I've heard reports about ones that don't, but never seen one myself.) I'd be interested in knowing in which conditions access to a network, host, or a subset of a host should be considered "administratively prohibited", but that administrative prohibition is not due to filtering (be it a firewall rule, access list, configuration toggle, or whatever). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Apr 10 15:01: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 1HbLaL-0006QD-AR; Tue, 10 Apr 2007 15:00:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbLaJ-0006Pz-VR; Tue, 10 Apr 2007 15:00:55 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbLaI-0001ss-Jo; Tue, 10 Apr 2007 15:00:55 -0400 Received: from [127.0.0.1] (125.sub-75-209-178.myvzw.com [75.209.178.125]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3AIxkjU010705; Tue, 10 Apr 2007 11:59:53 -0700 (PDT) Message-ID: <461BDE8E.9000307@isi.edu> Date: Tue, 10 Apr 2007 11:59:26 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] icmp type 3, code 13 References: <01c501c777ad$43978700$c4f0200a@amer.cisco.com> <46153F88.3000703@isi.edu> <461BBC60.6000906@isi.edu> <461BCA0B.3010706@isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: tcpm@ietf.org, "Faisal Siyavudeen \(fsiyavud\)" , behave@ietf.org, "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" 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="===============1026152389==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1026152389== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA98BF530091599C50B05215F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA98BF530091599C50B05215F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: =2E.. >> Uh, routers decrement the TTL. NATs do not. I don't think NATs behave >> like routers per se. >=20 > YMMV but all NATs I have seen and used do decrement TTL. (I've heard > reports about ones that don't, but never seen one myself.) One of the nasty things about NATs (or the people who design them) is that anything that makes them visible is likely to be disabled by some subset, in the hopes of making it 'transparent'. Although many NATs do decrement the TTL, there is no such requirement. RFC3022 (traditional NATs, informational) doesn't even mention it, and RFC2766 (NAT proposed standard) talks about setting TTL to 0 for DNS, but says specifically that TTLs are not decremented for statically mapped addresses (and has nothing to say about dynamic ones). Other docs (MIDCOM, arch implications of NATs) don't require TTL decrement either. > I'd be interested in knowing in which conditions access to a network, > host, or a subset of a host should be considered "administratively > prohibited", but that administrative prohibition is not due to filterin= g > (be it a firewall rule, access list, configuration toggle, or whatever)= =2E source address/reverse path validation comes to mind. Yes, it might be set with a toggle, but it's not what most people consider when then talk about packet filtering (at least IMO). IMO, because a NAT behaves like an endpoint (to the Internet side), it should send ICMPs like one, and issue ICMP host/port unreachables, not administrative filtering that routers would send. That would also 'do the right thing' by making the ICMPs result in hard errors. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigA98BF530091599C50B05215F 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.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGG96OE5f5cImnZrsRAjPaAJ9CW78ReSSQimSicqAQISXnWXvl1gCeKst7 lBAUO0svufS+nvmIadJdFY4= =I6N+ -----END PGP SIGNATURE----- --------------enigA98BF530091599C50B05215F-- --===============1026152389== 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 --===============1026152389==-- From tcpm-bounces@ietf.org Tue Apr 10 15:12: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 1HbLlj-0005BR-Tv; Tue, 10 Apr 2007 15:12:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbLli-0005BL-Qt for tcpm@ietf.org; Tue, 10 Apr 2007 15:12:42 -0400 Received: from whisker.bluecoat.com ([216.52.23.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbLle-00058W-F1 for tcpm@ietf.org; Tue, 10 Apr 2007 15:12:42 -0400 Received: from bcs-mail2.internal.cacheflow.com (bcs-mail2.internal.cacheflow.com [10.2.2.59]) by whisker.bluecoat.com (8.13.8/8.13.8) with ESMTP id l3AJCXYx027750 for ; Tue, 10 Apr 2007 12:12:33 -0700 (PDT) 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] last open issue in UTO Date: Tue, 10 Apr 2007 12:12:28 -0700 Message-ID: <305C539CA2F86249BF51CDCE8996AFF40386E18F@bcs-mail2.internal.cacheflow.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] last open issue in UTO Thread-Index: Acd7iV3gLQ3eZvPATp+95gQw0JbNawAGjVBg References: From: "Mahdavi, Jamshid" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 > That change has also re-opened an older issue. UTO could: >=20 > (1) allow hosts to lengthen _and_ shorten the local > UTO in response to incoming UTO options (if the local > stack has allowed that) >=20 > (2) allow hosts to only modify the local UTO in one > direction, i.e., always lengthen it (lengthening > is more useful to survive periods without > end-to-end connectivity) >=20 > (1) is obviously more flexible, but also requires us to maintain one =20 > more piece of per-connection state. (1) is also what the draft so far > has described, and is thus probably WG consensus. >=20 > (2) reduces overhead and make the mechanism a bit simpler. It can =20 > also be argued that the ability to shorten UTOs hasn't really been =20 > shown to be terribly useful (the argument was that busy servers could > notify clients that they weren't keeping the connection around for =20 > long if end-to-end connectivity would go away, which lets the client =20 > do the same and conserve some resources.) >=20 > I think Fernando prefers (1), and I have a slight preference for (2). >=20 > Thoughts? As a potential end-user of this feature, I'd prefer (1). I'd like to be able to allow users to control how long we can guarantee that a TCP connection will survive a network outage, and if we offer that as a configurable option that can only be increased it is somewhat hard to explain. (Or more precisely if you decreased it that would only apply to new connections, but not to existing ones.) --J _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Apr 11 01:19: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 1HbVEV-0000qg-9c; Wed, 11 Apr 2007 01:19:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbVEU-0000qb-Nb for tcpm@ietf.org; Wed, 11 Apr 2007 01:19:02 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbVET-0008Uq-4F for tcpm@ietf.org; Wed, 11 Apr 2007 01:19:02 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 03676F0C433; Wed, 11 Apr 2007 02:18:48 -0300 (ART) Received: from fgont.gont.com.ar (180-172-231-201.fibertel.com.ar [201.231.172.180]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l3B5IKfM030475; Wed, 11 Apr 2007 02:18:23 -0300 Message-Id: <200704110518.l3B5IKfM030475@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Apr 2007 02:11:57 -0300 To: Arifumi Matsumoto , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors In-Reply-To: <461B1DCE.1090209@nttv6.net> References: <20070409151328.GB1285@hut.isi.edu> <20070409171938.GC1301@hut.isi.edu> <461B1DCE.1090209@nttv6.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Wed, 11 Apr 2007 02:18:47 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 At 02:17 a.m. 10/04/2007, Arifumi Matsumoto wrote: >I looked at changes in section 2, and I found that I couldn't even >parse these sentences(2nd paragraph of Section 2). >Surely, I know that I'm not good at English, but aren't these a bit >complicated ? Do you suggest to list the messages in a bulleted-list, or what? Like: o Destination unreachable -- codes 0, 1 and 5 o Time exceeded -- codes 0 and 1 o Parameter problem or what? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Apr 11 02:20: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 1HbWAh-0002f5-MN; Wed, 11 Apr 2007 02:19:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbWAg-0002eu-ES for tcpm@ietf.org; Wed, 11 Apr 2007 02:19:10 -0400 Received: from [2001:fa8::25] (helo=mail.nttv6.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbWAY-0003aB-Pu for tcpm@ietf.org; Wed, 11 Apr 2007 02:19:09 -0400 Received: from [192.47.163.196] (dhcp-3-196.nttv6.com [192.47.163.196]) by mail.nttv6.net (8.14.1/8.13.8) with ESMTP id l3B6IaUU089079; Wed, 11 Apr 2007 15:18:36 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-ID: <461C7D82.9030600@nttv6.net> Date: Wed, 11 Apr 2007 15:17:38 +0900 From: Arifumi Matsumoto User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors References: <20070409151328.GB1285@hut.isi.edu> <20070409171938.GC1301@hut.isi.edu> <461B1DCE.1090209@nttv6.net> <200704110518.l3B5IKfM030475@venus.xmundo.net> In-Reply-To: <200704110518.l3B5IKfM030475@venus.xmundo.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > At 02:17 a.m. 10/04/2007, Arifumi Matsumoto wrote: > >> I looked at changes in section 2, and I found that I couldn't even >> parse these sentences(2nd paragraph of Section 2). >> Surely, I know that I'm not good at English, but aren't these a bit >> complicated ? > > Do you suggest to list the messages in a bulleted-list, or what? > > Like: > > o Destination unreachable -- codes 0, 1 and 5 > o Time exceeded -- codes 0 and 1 > o Parameter problem Firstly, I couldn't get that the first sentence corresponds to the second one. To clarify the mapping between ICMP and ICMPv6, how about using a table like below. ----- ICMP ICMPv6 o Destination unreachable --- Destination Unreachable (0,1,5) (0,3) o Time Exceeded (0,1) --- Time Exceeded(0,1) o Parameter Problem --- Parameter Problem(0,1,2) ----- The table above shows the mapping of ICMP erorr *types*. If you want to clarify the mapping of codes, these codes in the table above should be expanded like below. ----- ICMP ICMPv6 o Destination unreachable 0 --- Destination Unreachable 0 1 --- 3 5 --- ? ... ----- Kindest regards. -- Arifumi Matsumoto IP Technology Expert Team Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Apr 11 03:43:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXTk-0001rx-FD; Wed, 11 Apr 2007 03:42:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXTi-0001r9-7j for tcpm@ietf.org; Wed, 11 Apr 2007 03:42:54 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbXTg-0003Z4-1A for tcpm@ietf.org; Wed, 11 Apr 2007 03:42:53 -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 l3B7gJGR003007; Wed, 11 Apr 2007 10:42:43 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 10:42:26 +0300 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); Wed, 11 Apr 2007 10:42:13 +0300 Received: from [172.21.37.135] (esdhcp037135.research.nokia.com [172.21.37.135]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3B7gCEC009692; Wed, 11 Apr 2007 10:42:12 +0300 In-Reply-To: <305C539CA2F86249BF51CDCE8996AFF40386E18F@bcs-mail2.internal.cacheflow.com> References: <305C539CA2F86249BF51CDCE8996AFF40386E18F@bcs-mail2.internal.cacheflow.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [tcpm] last open issue in UTO Date: Wed, 11 Apr 2007 10:41:59 +0300 To: "ext Mahdavi, Jamshid" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Apr 2007 07:42:14.0000 (UTC) FILETIME=[EBBF8F00:01C77C0C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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="===============1152605080==" Errors-To: tcpm-bounces@ietf.org --===============1152605080== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-401624288; protocol="application/pkcs7-signature" --Apple-Mail-4-401624288 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Thanks for the feedback! I think there may be a misunderstanding; let me attempt to clarify. On 2007-4-10, at 22:12, ext Mahdavi, Jamshid wrote: > As a potential end-user of this feature, I'd prefer (1). I'd like > to be > able to allow users to control how long we can guarantee that a TCP > connection will survive a network outage, UTO gives no guarantees. All it does is let the other end know how long your end will leave the connection state around when there is no end-to-end connectivity. If the other end has decided to react to that information by adopting a similar local UTO, there is some likelihood that the TCP connection will survive if connectivity returns before that timeout. But your end can't tell if the other end is reacting to the UTO information you sent, hence no guarantees of anything. > and if we offer that as a > configurable option that can only be increased it is somewhat hard to > explain. (Or more precisely if you decreased it that would only apply > to new connections, but not to existing ones.) The configurable option is (1) what your local end uses as its UTO, and (2) whether that should be send to the other end via the UTO option (i.e., whether UTO is in use at all) and (3) whether your local end is willing to adapt the local UTO based on what the other end uses asa UTO. Your end is always free to increase and decrease its local UTO as it sees fit. The issue I described is with what happens at the other end, if it is configured to adapt its local UTO based on what you send. In the first case, if you send a long UTO and then a short one later, the remote end can decrease its UTO to the shorter value when it had been using the longer one. In the second case, it can't go to a shorter UTO. The question is whether the ability to shorten UTOs on the remote side is useful to have. Lars --Apple-Mail-4-401624288 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 MBwGCSqGSIb3DQEJBTEPFw0wNzA0MTEwNzQxNjBaMCMGCSqGSIb3DQEJBDEWBBSKmc3X6+E6YAVA 2174ycV4mcBKKzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEACXd18t2Iwp9S4BAyeLvurS157p2wDJ20QURveQIVyN6MtVm5Kf77 4TE/cgPieRMC4WuoA/AUNkyyif3u1rj19/uQN1VeNWUIMyk63/Vctey9XVP11K5YZRvZ9SQyXtaa IRqj1zWUYQhfI2+g5lHOmjAuxh6bW431U6SE6EX4krhJaMx4ied25tTJlR67KSTYVCsQQV5N+wNm 2xPnXglwFr0wqpaUuqwidnKgV9tZtBI8pbu7eyA8uvxRJtwce44nGC5LbnuxxMZ3ezEdIXCLL9xN jox/ap5NNj8/fcW5eCPRoLYLU92vdCm1le+eoUKYnv/v68cdK6ja08AL5NGx6gAAAAAAAA== --Apple-Mail-4-401624288-- --===============1152605080== 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 --===============1152605080==-- From tcpm-bounces@ietf.org Wed Apr 11 10:28: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 1HbdnY-0000lC-C8; Wed, 11 Apr 2007 10:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbdnX-0000l7-8Q for tcpm@ietf.org; Wed, 11 Apr 2007 10:27:47 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbdnV-0007Vl-RT for tcpm@ietf.org; Wed, 11 Apr 2007 10:27:47 -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 l3BERiog024031; Wed, 11 Apr 2007 07:27:45 -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 88E859C1207; Wed, 11 Apr 2007 10:27:38 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 8B5071CD248; Wed, 11 Apr 2007 10:27:27 -0400 (EDT) To: Ted Faber From: Mark Allman Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors In-Reply-To: <20070409171938.GC1301@hut.isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Play Guitar MIME-Version: 1.0 Date: Wed, 11 Apr 2007 10:27:27 -0400 Message-Id: <20070411142727.8B5071CD248@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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="===============1965555658==" Errors-To: tcpm-bounces@ietf.org --===============1965555658== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-05.txt > > Mark points out that I should mention that the last non-editorial > change to this draft was the addition of several omitted error codes > from Section 2 when the draft was revised from -04 to -05. WGLC > readers should make sure that the draft does address all the codes. I just did some diff-ing and the old and new paragraphs are appended below. But, basically rev -04 covers these codes: ipv4 dest unreach: 0, 1, 5 ipv6 type 1: 0, 3 and rev -05 covers these: ipv4 dest unreach: 0, 1, 5 ipv4 time exceeded: 0, 1 ipv4 param problem ipv6 dest unreach: 0, 3 ipv6 time exceeded: 0, 1 ipv6 param problem: 0, 1, 2 Just in terms of coverage this seems like a pretty significant change. Fernando- Can you explain why you did this? And, in particular, did you receive feedback that stacks are using this expanded list? (This is targeted as an informational document about what stacks do, not as a standards change.) Thanks, allman -04: The Host Requirements RFC [RFC1122] states, in section 4.2.3.9., that the ICMP "Destination Unreachable" messages that indicate soft errors are ICMP codes 0 (network unreachable), 1 (host unreachable), and 5 (source route failed). Even though ICMPv6 didn't exist when [RFC1122] was written, one could extrapolate the concept of soft errors to ICMPv6 Type 1 Codes 0 (no route to destination) and 3 (address unreachable). -05: The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9., that the ICMP messages that indicate soft errors are ICMP "Destination Unreachable" codes 0 (network unreachable), 1 (host unreachable), and 5 (source route failed), ICMP "Time Exceeded" codes 0 (time to live exceeded in transit) and 1 (fragment reassembly time exceeded), and ICMP "Parameter Problem". Even though ICMPv6 didn't exist when [RFC1122] was written, one could extrapolate the concept of soft errors to ICMPv6 "Destination Unreachable" codes 0 (no route to destination) and 3 (address unreachable), ICMPv6 "Time Exceeded" codes 0 (Hop limit exceeded in transit) and 1 (Fragment reassembly time exceeded), and ICMPv6 "Parameter Problem" codes 0 (Erroneous header field encountered), 1 (Unrecognized Next Header type encountered) and 2 (Unrecognized IPv6 option encountered). --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGHPBPWyrrWs4yIs4RAgN+AKCGxPwzbnfUE9ItpEXCuDi+je29XwCeJOht wgpPhd2345OO8W1ffOCFckk= =3akP -----END PGP SIGNATURE----- --=_bOundary-- --===============1965555658== 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 --===============1965555658==-- From tcpm-bounces@ietf.org Wed Apr 11 11:57:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbfBt-0001nS-IK; Wed, 11 Apr 2007 11:57:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbfBs-0001nN-UD for tcpm@ietf.org; Wed, 11 Apr 2007 11:57:00 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbfBp-0001kB-Jo for tcpm@ietf.org; Wed, 11 Apr 2007 11:57:00 -0400 Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3BFuva9028311 for ; Wed, 11 Apr 2007 15:56:57 GMT Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3BFurjD602509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Apr 2007 08:56:56 -0700 (PDT) Message-ID: <461D0545.5050202@sun.com> Date: Wed, 11 Apr 2007 23:56:53 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 1.5.0.10 (X11/20070303) MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] last open issue in UTO References: <305C539CA2F86249BF51CDCE8996AFF40386E18F@bcs-mail2.internal.cacheflow.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Lars Eggert wrote: > The configurable option is (1) what your local end uses as its UTO, and > (2) whether that should be send to the other end via the UTO option > (i.e., whether UTO is in use at all) and (3) whether your local end is > willing to adapt the local UTO based on what the other end uses asa UTO. > > Your end is always free to increase and decrease its local UTO as it > sees fit. The issue I described is with what happens at the other end, > if it is configured to adapt its local UTO based on what you send. In > the first case, if you send a long UTO and then a short one later, the > remote end can decrease its UTO to the shorter value when it had been > using the longer one. In the second case, it can't go to a shorter UTO. The question to ask is if it is important. Since the option is advisory anyway, so it is really up to the implementation what to do with it. "Specifying" that an implementation SHOULD not decrease its UTO in response to an incoming UTO option seems contrary to the advisory nature of the option. The receiver of the option is free to do whatever it likes. And the sender of the option has no way to find out how the peer reacts. So I don't think it is important to "disallow" the UTO decrease. BTW, why does this require a state LAST_SENT_UTO? -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Apr 11 18:51:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hble8-0004qr-9y; Wed, 11 Apr 2007 18:50:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hble6-0004ql-UR for tcpm@ietf.org; Wed, 11 Apr 2007 18:50:34 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hble5-00057K-JN for tcpm@ietf.org; Wed, 11 Apr 2007 18:50:34 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 2E372F0C43E; Wed, 11 Apr 2007 19:50:37 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l3BMoSaI004423; Wed, 11 Apr 2007 19:50:29 -0300 Message-Id: <200704112250.l3BMoSaI004423@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 24 Mar 2007 11:01:58 -0300 To: "Vishal Study" , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] Restarting Keepalive timer In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Wed, 11 Apr 2007 19:50:35 -0300 (ART) X-Spam-Score: 1.1 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 At 08:33 a.m. 24/03/2007, Vishal Study wrote: >Consider a one-way traffic scenario between host A and B (data traffic >from A to B). > >Should host-A restart its Keepalive timer if it gets an ACK for its >data from host-B? Yes. >Or Keepalive timer can only be reset if host-A gets some data from host-B? No. if that were the case, in scenarios of one-way long data transfers the TCP receiver would end up closing the connection unnecessarily. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Apr 11 20:06: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 1Hbmp6-0006Zi-U1; Wed, 11 Apr 2007 20:06:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbmp6-0006Xf-HJ for tcpm@ietf.org; Wed, 11 Apr 2007 20:06:00 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbmp5-0001sr-4w for tcpm@ietf.org; Wed, 11 Apr 2007 20:06:00 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id E2047F0C44F; Wed, 11 Apr 2007 21:05:52 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l3C05feU007551; Wed, 11 Apr 2007 21:05:42 -0300 Message-Id: <200704120005.l3C05feU007551@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Apr 2007 21:03:38 -0300 To: mallman@icir.org, Ted Faber , Carlos Pignataro From: Fernando Gont Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors In-Reply-To: <20070411142727.8B5071CD248@lawyers.icir.org> References: <20070409171938.GC1301@hut.isi.edu> <20070411142727.8B5071CD248@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Wed, 11 Apr 2007 21:05:50 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 At 11:27 a.m. 11/04/2007, Mark Allman wrote: >I just did some diff-ing and the old and new paragraphs are appended >below. But, basically rev -04 covers these codes: > > ipv4 dest unreach: 0, 1, 5 > ipv6 type 1: 0, 3 > >and rev -05 covers these: > > ipv4 dest unreach: 0, 1, 5 > ipv4 time exceeded: 0, 1 > ipv4 param problem > ipv6 dest unreach: 0, 3 > ipv6 time exceeded: 0, 1 > ipv6 param problem: 0, 1, 2 > >Just in terms of coverage this seems like a pretty significant change. > >Fernando- Can you explain why you did this? Carlos Pignataro sent me off-list feedback. As part of his feedback, he asked why the other codes were not included in the list. I re-checked the draft and RFC1122, and it turns out I simply missed them (actually, the original paragraph had sort of been copied verbatim from the v6onbydefault draft that had given birth to the soft errors draft. And the newly incorporated codes were already missing in the v6onbydefault draft). I checked the source code of the referenced implementations, and they process all the referenced error messages in the same way. That's why I included them. >And, in particular, did you receive feedback that stacks are using >this expanded list? (This is >targeted as an informational document about what stacks do, not as a >standards change.) I looked at the source code myself. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Apr 11 21:32: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 1HboAp-0001Qj-6t; Wed, 11 Apr 2007 21:32:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HboAn-0001Ns-G9 for tcpm@ietf.org; Wed, 11 Apr 2007 21:32:29 -0400 Received: from firestar.cisco.com ([171.68.227.75] helo=av-tac-sj.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HboAn-0006OB-2m for tcpm@ietf.org; Wed, 11 Apr 2007 21:32:29 -0400 X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-sj.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l3C1WRo29401; Wed, 11 Apr 2007 18:32:28 -0700 (PDT) Received: from [10.82.217.122] (rtp-vpn3-376.cisco.com [10.82.217.122]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l3C1WLq13935; Wed, 11 Apr 2007 21:32:21 -0400 (EDT) Message-ID: <461D8C25.6030604@cisco.com> Date: Wed, 11 Apr 2007 21:32:21 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors References: <20070411142727.8B5071CD248@lawyers.icir.org> In-Reply-To: <20070411142727.8B5071CD248@lawyers.icir.org> X-Enigmail-Version: 0.94.2.0 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: tcpm@ietf.org, Ted Faber 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 Mark, On 4/11/2007 10:27 AM, Mark Allman allegedly said the following: >>> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-05.txt >> Mark points out that I should mention that the last non-editorial >> change to this draft was the addition of several omitted error codes >> from Section 2 when the draft was revised from -04 to -05. WGLC >> readers should make sure that the draft does address all the codes. > > I just did some diff-ing and the old and new paragraphs are appended > below. But, basically rev -04 covers these codes: > > ipv4 dest unreach: 0, 1, 5 > ipv6 type 1: 0, 3 > > and rev -05 covers these: > > ipv4 dest unreach: 0, 1, 5 > ipv4 time exceeded: 0, 1 > ipv4 param problem > ipv6 dest unreach: 0, 3 > ipv6 time exceeded: 0, 1 > ipv6 param problem: 0, 1, 2 > > Just in terms of coverage this seems like a pretty significant change. > > Fernando- Can you explain why you did this? And, in particular, did you > receive feedback that stacks are using this expanded list? (This is > targeted as an informational document about what stacks do, not as a > standards change.) I sent some unicast comments/questions to Fernando a few weeks ago about soft-errors-04; the (translated) one that likely prompted this change is: ----->8----- 2. Error Handling in TCP The Host Requirements RFC [RFC1122] states, in section 4.2.3.9., that the ICMP "Destination Unreachable" messages that indicate soft errors are ICMP codes 0 (network unreachable), 1 (host unreachable), and 5 (source route failed). Even though ICMPv6 didn't exist when ###CP> Question: Is there any specific reason why you only consider ###CP> Unreach 0, 1 y 5 as soft errors? And not e.g. timeexceeded? ###CP> RFC1112 says they should be handled the same way: http://tools.ietf.org/html/rfc1122 o Time Exceeded -- codes 0, 1 This should be handled the same way as Destination Unreachable codes 0, 1, 5 (see above). o Parameter Problem This should be handled the same way as Destination Unreachable codes 0, 1, 5 (see above). ----->8----- Thanks, --Carlos. > > Thanks, > allman > > > > > > > -04: > The Host Requirements RFC [RFC1122] states, in section 4.2.3.9., that > the ICMP "Destination Unreachable" messages that indicate soft errors > are ICMP codes 0 (network unreachable), 1 (host unreachable), and 5 > (source route failed). Even though ICMPv6 didn't exist when > [RFC1122] was written, one could extrapolate the concept of soft > errors to ICMPv6 Type 1 Codes 0 (no route to destination) and 3 > (address unreachable). > > -05: > The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9., that > the ICMP messages that indicate soft errors are ICMP "Destination > Unreachable" codes 0 (network unreachable), 1 (host unreachable), and > 5 (source route failed), ICMP "Time Exceeded" codes 0 (time to live > exceeded in transit) and 1 (fragment reassembly time exceeded), and > ICMP "Parameter Problem". Even though ICMPv6 didn't exist when > [RFC1122] was written, one could extrapolate the concept of soft > errors to ICMPv6 "Destination Unreachable" codes 0 (no route to > destination) and 3 (address unreachable), ICMPv6 "Time Exceeded" > codes 0 (Hop limit exceeded in transit) and 1 (Fragment reassembly > time exceeded), and ICMPv6 "Parameter Problem" codes 0 (Erroneous > header field encountered), 1 (Unrecognized Next Header type > encountered) and 2 (Unrecognized IPv6 option encountered). > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Apr 11 22:53: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 1HbpRF-0004BS-Bp; Wed, 11 Apr 2007 22:53:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbpRE-0004BK-Bq for tcpm@ietf.org; Wed, 11 Apr 2007 22:53:32 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbpRD-00035C-1a for tcpm@ietf.org; Wed, 11 Apr 2007 22:53:32 -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 l3C2rPNW000853; Wed, 11 Apr 2007 19:53:25 -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 18F069C62DF; Wed, 11 Apr 2007 22:53:20 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6E82F1CEB53; Wed, 11 Apr 2007 22:53:07 -0400 (EDT) To: Fernando Gont From: Mark Allman Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors In-Reply-To: <200704120005.l3C05feU007551@venus.xmundo.net> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Blue on Black MIME-Version: 1.0 Date: Wed, 11 Apr 2007 22:53:07 -0400 Message-Id: <20070412025307.6E82F1CEB53@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tcpm@ietf.org, Ted Faber 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="===============0677455506==" Errors-To: tcpm-bounces@ietf.org --===============0677455506== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I checked the source code of the referenced implementations, and they > process all the referenced error messages in the same way. That's why > I included them. Fair enough. Thanks for the explanation. Input on this would certainly be good here folks. I think that this change needs some positive feedback before we move forward. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGHZ8TWyrrWs4yIs4RAi/tAJ9ngTmirNWtr6n8+nYpDUQKpGNzygCcCapP wUuoORQ7Wh5MlJRnjzsvL1E= =UikP -----END PGP SIGNATURE----- --=_bOundary-- --===============0677455506== 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 --===============0677455506==-- From tcpm-bounces@ietf.org Fri Apr 13 10:29: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 1HcMmh-0001EP-Vs; Fri, 13 Apr 2007 10:29:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcMmg-0001EF-Q7 for tcpm@ietf.org; Fri, 13 Apr 2007 10:29:54 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcMmg-00027x-DL for tcpm@ietf.org; Fri, 13 Apr 2007 10:29:54 -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 l3DETrHY032503 for ; Fri, 13 Apr 2007 07:29:53 -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 119439D81A0 for ; Fri, 13 Apr 2007 10:29:48 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 41E871D0D41 for ; Fri, 13 Apr 2007 10:29:34 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Haircut MIME-Version: 1.0 Date: Fri, 13 Apr 2007 10:29:34 -0400 Message-Id: <20070413142934.41E871D0D41@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: [tcpm] Re: strength of tcpsecure recommendation 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="===============0712311187==" Errors-To: tcpm-bounces@ietf.org --===============0712311187== 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- I have not seen any input to the following query. We really need some so we can move forward. In particular, we didn't even hear from the folks who have been discussing the issue. I would very much appreciate it if you could take a few minutes to answer the poll. Thanks, allman > Folks- > > I'd like to try to be a bit systematic about figuring out how to proceed > with the tcpsecure i-d and so I have cooked a poll below. The essential > questions on the table is the mitigations ought to be labeled as SHOULD > or MAY and whether these labels ought to be conditioned or not. > > We have had some good conversation on the topic and lots of points have > been aired (how baked these solutions are, IPR, cost v. benefit, etc.). > So, I am asking that the answers to the following questions be succinct > and not rehash a bunch of previous argument. If you feel you have a > **new** point then that is clearly fine. > > I am trying to get a good read of the WG here and so even if you have > clearly aired opinions before, please take the minute and answer these > questions. > > (Note that SHOULD and MAY are clearly not the only choices. If you want > to vote for MUST or MUST NOT then that is fine, even though they are not > listed as choices below. If you do, please then do provide some > justification.) > > The questions then ... > > (1) (a) Do you believe the draft should allow the "blind reset attack > using the RST bit" mitigation described in section 3 of the > document as a SHOULD or a MAY? > > (b) Should we apply a condition to the recommendation? If so, > please state the condition you'd like to see very succinctly. > > (2) (a) Do you believe the draft should allow the "blind reset attack > using the SYN bit" mitigation described in section 4 of the > document as a SHOULD or a MAY? > > (b) Should we apply a condition to the recommendation? If so, > please state the condition you'd like to see very succinctly. > > (3) (a) Do you believe the draft should allow the "blind data injection > attack" mitigation described in section 5 of the document as a > SHOULD or a MAY? > > (b) Should we apply a condition to the recommendation? If so, > please state the condition you'd like to see very succinctly. > > Thanks in advance for the input! > > allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGH5POWyrrWs4yIs4RAs4aAKCdPXm6OQn2X+e15c6Nx9es9tuDTwCfTIlS lsYwZ4C/NEpN+P1Tz2rSqOQ= =Xs3Q -----END PGP SIGNATURE----- --=_bOundary-- --===============0712311187== 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 --===============0712311187==-- From tcpm-bounces@ietf.org Fri Apr 13 18:35: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 1HcUMT-0006ZZ-62; Fri, 13 Apr 2007 18:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcUMR-0006PP-Jb for tcpm@ietf.org; Fri, 13 Apr 2007 18:35:19 -0400 Received: from smtpout.mac.com ([17.250.248.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcUMM-0000EI-8D for tcpm@ietf.org; Fri, 13 Apr 2007 18:35:19 -0400 Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpout.mac.com (Xserve/smtpout05/MantshX 4.0) with ESMTP id l3DMZAnO022826; Fri, 13 Apr 2007 15:35:10 -0700 (PDT) Received: from [192.168.1.64] (adsl-70-231-237-202.dsl.snfc21.sbcglobal.net [70.231.237.202]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id l3DMZ8j7005271; Fri, 13 Apr 2007 15:35:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <07e0ad60d97a8cef94c214554aee0658@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Date: Fri, 13 Apr 2007 15:35:08 -0700 To: tcpm X-Mailer: Apple Mail (2.624) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: David Ros , =?ISO-8859-1?Q?Andr=E9s_Arcia?= , Janardhan Iyengar Subject: [tcpm] Adding Acknowledgement Congestion Control to TCP 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 All - We have just submitted an internet-draft on "Adding Acknowledgement Congestion Control to TCP", available from "http://www.icir.org/floyd/papers/draft-floyd-tcpm-ackcc-00.txt". This is very much a preliminary investigation, at this stage, and any feedback would be appreciated. Abstract: This document adds an optional congestion control mechanism for acknowledgement traffic (ACKs) to TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts, the TCP data sender and the TCP data receiver. The TCP data sender detects lost and ECN-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in DCCP's CCID 2 [RFC4340], [RFC4341]. This acknowledgement congestion control mechanism is being proposed as an experimental mechanism for TCP for evaluation by the network community. Many thanks, Sally, David, Andres, and Janardhan http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 13 20:58:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcWam-0005eC-Ps; Fri, 13 Apr 2007 20:58:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcWal-0005e7-Pz for tcpm@ietf.org; Fri, 13 Apr 2007 20:58:15 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcWak-0006fw-Dy for tcpm@ietf.org; Fri, 13 Apr 2007 20:58:15 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id CD77AF0C435; Fri, 13 Apr 2007 21:58:17 -0300 (ART) Received: from fgont.gont.com.ar (line40.comsat.net.ar [200.47.78.40] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l3E0wAtK008199; Fri, 13 Apr 2007 21:58:12 -0300 Message-Id: <7.0.1.0.0.20070326122351.07649148@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 26 Mar 2007 12:37:44 -0300 To: David Borman , "Vishal Study" From: Fernando Gont Subject: Re: [tcpm] TCP Reassembly: Advertising TCP rcv window In-Reply-To: References: <200703250001.l2P01qw6011468@venus.xmundo.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Fri, 13 Apr 2007 21:58:17 -0300 (ART) X-Spam-Score: 3.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 At 11:19 26/03/2007, David Borman wrote: >received. The out-of-order data is considered part of the window. >If the receiver continues to put in the same value for the window, >the right edge of the window will not advance since the ACK is not >advancing. Fernando is wrong below, the out of order data is, and >must be, within the receivers advertised window, or it would be >dropped by the receiver. I meant that the out-of-order data won't affect the advertised window. As a result, if the TCP sender originally had credit to send, say, five segments of 1000 bytes, and sent them and only the last four segments arrived at the TCP receiver (i.e., the first segment was lost), then (unless the TCP receiver retracted the window), the TCP sender would still have credit to resend those five segments (the receive window at the TCP receiver wouldn't as each of the duplicate acks sent in response to the out-of-order segments would have the same Acknowledgment number and Window that originally allowed the TCP sender to send the five segments in the first place). My apologizes if my explanation added more confusion than anything else. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Apr 18 12:26: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 1HeCyw-00009F-RS; Wed, 18 Apr 2007 12:26:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCyu-000096-RK for tcpm@ietf.org; Wed, 18 Apr 2007 12:26:08 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCyu-0003Zk-5J for tcpm@ietf.org; Wed, 18 Apr 2007 12:26: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 l3IGQ6QI006761; Wed, 18 Apr 2007 09:26:07 -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 628099FD373; Wed, 18 Apr 2007 12:26:01 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 4C37D1D84C9; Wed, 18 Apr 2007 12:25:38 -0400 (EDT) To: Ted Faber From: Mark Allman Subject: Re: [tcpm] WGLC for SYN flooding In-Reply-To: <20070327212827.GE26658@hut.isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Werewolves of London MIME-Version: 1.0 Date: Wed, 18 Apr 2007 12:25:38 -0400 Message-Id: <20070418162538.4C37D1D84C9@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 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="===============0001312297==" Errors-To: tcpm-bounces@ietf.org --===============0001312297== 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 > Mark and I would like to start a WG last call on the SYN flooding and > countermeasures document: > > Title : TCP SYN Flooding Attacks and Common Mitigations > Author(s) : W. Eddy > Filename : draft-ietf-tcpm-syn-flood-02.txt > Pages : 23 > Date : February 2007 > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-syn-flood-02.txt Ted and I believe the WG's consensus is that this document is in good shape and ready to be published as an informational RFC. We will be forwarding it to the ADs with the attached PROTO writeup. Of course, if you believe we have mis-judged the consensus of the WG you should yell. allman --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Disposition: attachment; filename=synflood-proto-summary TCP SYN Flooding Attacks and Common Mitigations draft-ietf-tcpm-syn-flood-02.txt >> (1.a) Who is the Document Shepherd for this document? Has the >> Document Shepherd personally reviewed this version of the >> document and, in particular, does he or she believe this >> version is ready for forwarding to the IESG for publication? Mark Allman (TCPM co-chair) is acting as the shepherd for this document. I have read this version of the draft and believe it is ready for publication as an Informational RFC. >> (1.b) Has the document had adequate review both from key WG members >> and from key non-WG members? Does the Document Shepherd have >> any concerns about the depth or breadth of the reviews that >> have been performed? The document has been reviewed by many WG members and has enjoyed much support over the course of its development. I have no concerns about the review process. >> (1.c) Does the Document Shepherd have concerns that the document >> needs more review from a particular or broader perspective, >> e.g., security, operational complexity, someone familiar with >> AAA, internationalization or XML? I have no concerns that the document needs additional review. >> (1.d) Does the Document Shepherd have any specific concerns or >> issues with this document that the Responsible Area Director >> and/or the IESG should be aware of? For example, perhaps he >> or she is uncomfortable with certain parts of the document, or >> has concerns whether there really is a need for it. In any >> event, if the WG has discussed those issues and has indicated >> that it still wishes to advance the document, detail those >> concerns here. Has an IPR disclosure related to this document >> been filed? If so, please include a reference to the >> disclosure and summarize the WG discussion and conclusion on >> this issue. I have no specific issues that the IESG should be aware of. No IPR disclosures have been filed relating to this document. >> (1.e) How solid is the WG consensus behind this document? Does it >> represent the strong concurrence of a few individuals, with >> others being silent, or does the WG as a whole understand and >> agree with it? I believe the consensus behind this document is quite broad. >> (1.f) Has anyone threatened an appeal or otherwise indicated extreme >> discontent? If so, please summarise the areas of conflict in >> separate email messages to the Responsible Area Director. (It >> should be in a separate email because this questionnaire is >> entered into the ID Tracker.) I am not aware of any threatened appeals or any discontent with this document in any way. (In fact, all the recent work has been fairly editorial in nature.) >> (1.g) Has the Document Shepherd personally verified that the >> document satisfies all ID nits? (See >> http://www.ietf.org/ID-Checklist.html and >> http://tools.ietf.org/tools/idnits/). Boilerplate checks are >> not enough; this check needs to be thorough. Has the document >> met all formal review criteria it needs to, such as the MIB >> Doctor, media type and URI type reviews? The document requires no formal reivews (e.g., by MIB Doctors). I have run idnits on the document and it shows no issues. >> (1.h) Has the document split its references into normative and >> informative? Are there normative references to documents that >> are not ready for advancement or are otherwise in an unclear >> state? If such normative references exist, what is the >> strategy for their completion? Are there normative references >> that are downward references, as described in [RFC3967]? If >> so, list these downward references to support the Area >> Director in the Last Call procedure for them [RFC3967]. The references are labeled as "Informative", as they should be. This is an informational document. >> (1.i) Has the Document Shepherd verified that the document IANA >> consideration section exists and is consistent with the body >> of the document? If the document specifies protocol >> extensions, are reservations requested in appropriate IANA >> registries? Are the IANA registries clearly identified? If >> the document creates a new registry, does it define the >> proposed initial contents of the registry and an allocation >> procedure for future registrations? Does it suggest a >> reasonable name for the new registry? See [RFC2434]. If the >> document describes an Expert Review process has Shepherd >> conferred with the Responsible Area Director so that the IESG >> can appoint the needed Expert during the IESG Evaluation? The document has an IANA considerations section that is consistent with the body of the document. This document has no IANA considerations. >> (1.j) Has the Document Shepherd verified that sections of the >> document that are written in a formal language, such as XML >> code, BNF rules, MIB definitions, etc., validate correctly in >> an automated checker? This does not apply. >> (1.k) The IESG approval announcement includes a Document >> Announcement Write-Up. Please provide such a Document >> Announcement Write-Up? Recent examples can be found in the >> "Action" announcements for approved documents. The approval >> announcement contains the following sections: >> >> Technical Summary >> Relevant content can frequently be found in the abstract >> and/or introduction of the document. If not, this may be >> an indication that there are deficiencies in the abstract >> or introduction. This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks. >> Working Group Summary >> Was there anything in WG process that is worth noting? For >> example, was there controversy about particular points or >> were there decisions where the consensus was particularly >> rough? The consensus within the TCPM WG to publish this document as an informational RFC is strong. >> Document Quality >> Are there existing implementations of the protocol? Have a >> significant number of vendors indicated their plan to >> implement the specification? Are there any reviewers that >> merit special mention as having done a thorough review, >> e.g., one that resulted in important changes or a >> conclusion that the document had no substantive issues? If >> there was a MIB Doctor, Media Type or other expert review, >> what was its course (briefly)? In the case of a Media Type >> review, on what date was the request posted? This document details several techniques that have been used in TCP implementations for many years. The technology discussed in this document is not new, but rather this document is helping the RFC-series "catch up" with common practice and details experience with several mechanisms. >> Personnel >> Who is the Document Shepherd for this document? Who is the >> Responsible Area Director? Is an IANA expert needed? The document shepherd for this document is Mark Allman (TCPM co-chair). The responsible AD is Lars Eggert. The document does not need an IANA expert. --=_bOundary-- --==_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGJkaCWyrrWs4yIs4RAqfzAJ4ygiZg57PLZnl9dYVGF1WL7E+zTwCfUsrH EpKmPcCY7yI+WAwOFotHC8k= =ezaz -----END PGP SIGNATURE----- --==_bOundary-- --===============0001312297== 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 --===============0001312297==-- From tcpm-bounces@ietf.org Wed Apr 18 16:59: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 1HeHFg-0008WF-QY; Wed, 18 Apr 2007 16:59:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHFe-0008WA-Qy for tcpm@ietf.org; Wed, 18 Apr 2007 16:59:42 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeHFb-0007yv-Fk for tcpm@ietf.org; Wed, 18 Apr 2007 16:59:42 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id BC23CC203 for ; Wed, 18 Apr 2007 16:59:34 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l3IKxYwE004012 for ; Wed, 18 Apr 2007 16:59:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l3IKxTlX015039 for ; Wed, 18 Apr 2007 16:59:33 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id lwZqyoutCykK for ; Wed, 18 Apr 2007 16:59:29 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l3IKxRxu015028for ; Wed, 18 Apr 2007 16:59:27 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 9B5A34FD7E; Wed, 18 Apr 2007 16:58:52 -0400 (EDT) Date: Wed, 18 Apr 2007 16:58:52 -0400 From: Wesley Eddy To: tcpm@ietf.org Message-ID: <20070418205852.GA31144@grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:11.94505 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [tcpm] syn-flood update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org An updated version of the syn-flooding draft was just submitted, to fix a few typos that Lars caught in the AD review. Nothing beyond a handful of letters and a couple of non-technical wordings changed compared to the version that was last-called. The diff is available at: http://roland.grc.nasa.gov/~weddy/shared/tcpm/syn-flood-02-to-03-diff.html This version is ready to move forward. Thanks for everyone's effort in reviewing and helping with this document! -- Wesley M. Eddy Verizon Federal Network Systems _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Apr 19 18:44:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HefMH-00011J-Qy; Thu, 19 Apr 2007 18:44:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HefMG-000115-3u for tcpm@ietf.org; Thu, 19 Apr 2007 18:44:08 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HefME-0003rI-8I for tcpm@ietf.org; Thu, 19 Apr 2007 18:44:08 -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 l3JMhOQ1028217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 19 Apr 2007 15:43:24 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l3JMhOt6053551 for tcpm@ietf.org; Thu, 19 Apr 2007 15:43:24 -0700 (PDT) (envelope-from faber) Date: Thu, 19 Apr 2007 15:43:24 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20070419224324.GA52936@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.2i 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: b058151374d77ee76edaac850f7449fb Subject: [tcpm] TCPM Prague minutes for review 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="===============1712962404==" Errors-To: tcpm-bounces@ietf.org --===============1712962404== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The minutes that David Borman merged from the notes taken by Pasi Sarolahti and Gorry Fairhurst are posted at http://www3.ietf.org/proceedings/07mar/minutes/tcpm.txt and attached. Please review and make sure we've spelled your name right and not put words in your mouth. The minutes are due tomorrow. Sorry for the short fuse. TCPM WG Meeting - IETF 68 - Prague Tuesday, March 20, 2007, 17:40 -- 18:40 Note takers: Pasi Sarolahti and Gorry Fairhurst Acting chair: David Borman (for Mark and Ted) Jabber watcher: Lars Eggert (My thanks to Pasi and Gorry for taking good notes, these minutes are mainly just a merger of their notes. -David) Agenda bashing -- no comments WG status * anti-spoof: Passed WGLC, currently in IETF last call * syn-flooding: in seemingly good shape, intent to have WGLC * soft errors: seemingly good shape, intent to have WGLC * rfc2581bis: authors believe issues have been addressed - for Draft Standard we need implementation reports - Mark to survey implementors -- implementors are asked to contact Mark * ecn-syn: Sally working on simulations to get clarity on what is right response to ECN-marked SYN-ACK. Sally and Mark have some disagreements on what the response should be. * tcp-auth: There is WG consensus on developing TCP-MD5 replacement. TCPM to do the transport protocol work. Design team has been established to produce -00 version from two competing drafts, chaired by Steve Bellovin. After that the usual WG process will take over.=20 User Timeout -- Lars Eggert draft-ietf-tcpm-tcp-uto-05.txt * Lars and chairs did not remember if this is going for experimental or proposed. Tim Shepard has preference for experimental. - Tim Shepherd: in San Diego asked this explicitly from chairs during agenda bashing, they said the plan is for Experimental. - Lars: ok * Status - TCP connection dies if there is long period of disconnection without ACKs coming in, relates to mobility, etc. - Draft proposes one way to solve it, a TCP option to signal the appropriate timeout=20 - ver -05 has clarifications, Ted Faber commented earlier that the language needs to be consistent, lot of overload on UTO value. There was also one other issue during author discussion.=20 * Changing to make it explicit of what we talk about -- three pieces of connection state:=20 - "enabled": whether UTO is enabled or not - "local_uto": local UTO in use, system-wide default, or optionally applications to tell TCP stack what to use - "changeable": controls whether local UTO may be changed based on incoming options. Default is true unless application sets local_uto, false if application has set the local_uto. * Last issue - Distinction between UTO I am currently using vs. last sent UTO information. Ability to shorten the local UTO depends on maintaining last_sent_uto information. If don't need to shorten local UTO, the implementation becomes simpler. Does the WG consider this is important?=20 - There will be a revision, then WGLC - Gorry Fairhurst: Is there a real use-case for reducing the UTO? In the = last meeting, we discussed the issues of having too small a value. So, things are sim= pler if we can only make this bigger. - Lars:That is one option. A TCP may wish to shorten this to release reso= urces. Use case for short UTO could be busy web server, for long UTO it is periods of disconnectivity. Fernando would like to keep short UTO, Lars would like to remove. No one has requested short UTO, no one has opposed. - David Borman: if we don't have ability to shorten it, does it affect the web server? If the server uses a shorter timeout and closes the connection, the client would know about it anyway. - Lars: it wouldn't change anything on the web server. Would give the other guy ability to shorten timeout, if a disconnection happens. - Lars: server can locally timeout while client might keep trying for a longer time vs. client would stop immediately. * Next version need to choose which way to go, then we will need committed reviewers.=20 - Do the new variables clarify things? - Do we need to be able to reduce the UTO? Two volunteers: Anantha Ramaiah Arjuna Sathiaseelan TCP-secure -- Anantha Ramaiah draft-ietf-tcpm-tcpsecure-07.txt Improving TCP robustness. Has been around as WG document for two years, would like to go for WG last call. Provides mitigations to known security issues. Has been thoroughly discussed on list. Have been running in Internet for two years. No known serious issues. Changes: * Mitigation recommendations changed from MUST to SHOULD, after a comment by Ted Faber, would have made existing TCP implementations non-compliant with this. * Security considerations text rewritten. * Got many comments: some public, some private. Data injection mitigation: SHOULD or MAY? * explaining data injection mitigation specification * implementations can choose to hard code the value of max.snd.wnd mitigation. Increases robustness to FIN attack. Comments? Ready for WGLC? * Joe Touch: All documents need to be careful with the use of SHOULD - it means most implementations will do this, but there could be cases where a specific implementor will do this. We SHOULD say when (under what conditions) this is NOT OK to implement. Perhaps we could say a SHOULD (or even) MUST for all routers. * Joe Touch: Raising a comment from the list -- this is a general statement for all documents: What SHOULD means, and what it allows? There seems to be consensus about how it is documented in RFC 2119. I would be ok with SHOULD or even a MUST with regard to TCP implementations on routers. Requiring SHOULD without caveats to all hosts in the world, it is not compliant to update. On general host it is MAY.=20 * Scott Bradner: This interpretation is correct. The idea of SHOULD is sayi= ng this is to be done. You may not imagine there is a good reason for not do= ing this, (but you may not know all the possibilities at the time the RFC is published) - the aim is to do something to make the system to work. * Tim Shepard: clarifying question to Joe -- why did you say router? There could be end hosts and all sorts of places where you run long-lived connections that find this useful to improve robustness. Router is a wrong distinction. If you said BGP that might make more sense.=20 * Joe: because in routers TCP attack would be reasonable and likely. * Tim: There could be applications on end hosts, that may need this. Not just "router" it could be that we really mean a BGP session. * Anantha: Distinction to router is gone. We have router that can use TCP for all kinds of purposes, HTTP, voice-over-IP, all kinds of stuff.= =20 * Joe: It may be useful for end hosts that have long-lived sessions were bo= th ends are likely to be known. * Tim: It is needed on any system that may in the future need robustness. * Joe: ... yes, but in cases where the host fails to be implement "proper" security. * Lars Eggert: Note that previous discussions considered the document also = has an IPR statement. The WG needs to include consideration of this in the decisions. * Anantha: why mentioned it now? * Lars: WG needs to include the existence of IPR in its decision. Draft has a long history, and shouldn't forget about the IPR. * Mark Allman - via jabber: The IPR point is that the IPR could have an imp= act on MUST v. SHOULD v. whatever, i.e., I would personally be against saying= a TCP MUST implement tcpsecure, because it has an IPR statement. F-RTO update to proposed standard -- Markku Kojo (RFC 4138) Updating F-RTO to proposed standard. No revised protocol specification available, just an evaluation report Small modification in TCP sender algorithm, allows detecting a spurious RTO * Experimental RFC since Aug 2005. * number of known implementations. * Experimentations with all major implementations show encouraging results. * Interest to promote has been expressed already earlier * Last IETF we were asked to write document to evaluate & show it is not harmful. Material is available on a web page, but not yet in the repository. First question: is F-RTO useful? * showing time-sequence graphs of normal TCP behavior on delay spike * full window of segments unnecessarily retransmitted, wastes requests, breaks the packet conservation principle. * Problem in a mobility case of moving from WLAN to GPRS environment. * Problem is not about causing congestion, but about performance of an individual TCP flow=20 * Presenting time-seq diagram of case using F-RTO. If two segments acknowledge new data, can declare timeout spurious and continue sending new data. Avoids unnecessary retransmissions, and additionally can take RTT samples from the delayed segments. Can F-RTO be harmful? No * If RTO is not spurious or F-RTO cannot detect spurious reverts back to the traditional RTO recovery. Exactly the same number of segments are transmitted as with normal RTO recovery. * There are a few corner cases where F-RTO can declare RTO spurious even if there are packet losses. It would be harmful if congestion control response was aggressive. If congestion window was not halved in response to spurious RTO, it should be ok. * Few known scenarios - 1: loss of unnecessary RTO retransmission. Quite rare situation to happen=20 - 2: severe reordering * Mark Allman (via jabber): You have only ten minutes, get to the point - 3: malicious receiver - Might be harmful if congestion control response is reverted, but proposing that congestion window is reduced in response to spurious RTO, in which case false positives are not be harmful. Next steps * Revise RFC 4138, targeting at Proposed Standard. Specify basic algorithm only, and TCP only, leave out SCTP because there is no implementation experience. Leave out SACK-enhanced variant, because it has only limited benefit. * What to do with response? The draft does not specify any response in the original RFC. Options are 1) do not specify response 2) specify conservative default response, or 3) specify a conservative response in the new draft=20 * Recommend implementing conservative response * Anantha Ramaiah: how does it cooperate with other related enhancements: Eifel, DSACK? - e.g, if all three coexist. * Markku: Does not require additional information. If timestamps have been enabled, Eifel can be used without problems. DSACK does not prevent unnecessary retransmissions. * David: Continue discussion on the mailing list. Please indicate if you want or don't want this to be promoted from experimental to proposed. Non-WG Drafts Identifying Cheating Receivers -- Toby Moncaster draft-moncaster-tcpm-rcv-cheat-00.txt First presentation of a new draft * TCP senders rely on accurate feedback from receivers * Dishonest receiver can do optimistic ACKs, causing sender to transmit at higher rate, conceal lost data, harmful for congestion control=20 * Some existing proposed solutions: - Randomly skipped segments - ECN nonce - Transport layer nonce in TCP headers Listing 7 key requirements for solution * Joe Touch: Proposes re-phrasing "Test should not harm innocent receiver": Anything that network could have done cannot be interpreted as malicious. Sender should not be allowed to do anything that the network couldn't have done anyway. That allows to develop the solution rather than just mess up the receiver. * Joe: The test should not harm an innocent receiver, i.e. anything the network may have done accidentally should not be seen as malicious. * Joe: It also should only do what the network would normally allow a sender to do. Assessing proposed solutions * Table evaluating the earlier solutions * Joe: should have separate column in the draft, or have a separate row works only with certain options. Otherwise I like the table, should be also in the draft.=20 * Toby: it already is Our proposed solution * Based on Rob Sherwood's randomly skipped segments solution 1. delay a segment by small amount 2. delay segment until duplicate ack is received. Graph of stage 1 test Assessing stage 1 test * Meets all requirements set, but does not strictly prove dishonesty. * Joe: Should also say works only work with certain options. * Tim Shepard: if receiver is using SACK, the test gives receiver chance to prove it works nicely with SACK. The table did not mention delayed ACKs. * Toby: main gain of optimistic acking is to reduce RTT * Joe: any indications that things mentioned in tcpsecure have relationship with this. For example if anyone wanting to cheat by bursting.=20 * Toby: need to look at that in detail Stage 2 test * Meets all requirements set, except doesn't harm innocent receiver Conclusion * Cheating receiver gets more resources that it should get. Could possibly cause congestion collapse=20 (Gorry needs to leave a room, other minute taker is gone) * Anantha: what about senders using byte counting? * Joe: should verify that there are no interactions with Nagle in cases when there are segments dropped, should check interactions with partial segments=20 TCP Response to Lower-Layer Connectivity-Change Indications -- Simon Sch=EF= =BF=BDtz draft-schuetz-tcpm-tcp-rlci-01.txt Problem: TCP is unaware of what happens on lower layers. RLCI uses generic indications from lower layers, avoids long idle time due to repetitive RTOs. Connection stays idle after gaining connection after disconnection, because RTO has backed off Why RLCI? * Provides generic approach to overcome problems - hand-overs - connectivity disruptions * Bob Briscoe: The draft was not clear is this about getting information from local link or of the remote link? * Simon: Defining the source of indications is out of scope, defining the response to indications. * Joe Touch: has been discussed before, problem with earlier approaches is that you are trying to get indications from the link layer, transitive to issue on putting this on the API layer. Tickling the end point deliberately, unreasonable thing to do.=20 What's new Next steps * Would like to start discussion on the mailing list * Candidate for experimental. * Soliciting discussion on the mailing list Concluding the TCPM meeting * Explicit reviewers sought for tcpsecure. Send mail to Ted and Mark if you are volunteering. * Looking for people to read tcp-persist and comment on the mailing list --=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 --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGJ/CMaUz3f+Zf+XsRAsmGAKCCG29pk0Vqhoc00j7YOc+jWSAPuwCgk2w0 2IU3wlg8qWAB+3rmXs9UF6U= =SqfN -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- --===============1712962404== 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 --===============1712962404==-- From tcpm-bounces@ietf.org Fri Apr 20 05:35: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 1HepWX-0006mE-6l; Fri, 20 Apr 2007 05:35:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HepWW-0006m3-Cj for tcpm@ietf.org; Fri, 20 Apr 2007 05:35:24 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HepWT-0006Z7-Bz for tcpm@ietf.org; Fri, 20 Apr 2007 05:35:24 -0400 Received: from I2KF03CV-UKBR.domain1.systemhost.net ([193.113.197.45]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 10:35:20 +0100 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.64]) by I2KF03CV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Apr 2007 10:35:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] TCPM Prague minutes for review Date: Fri, 20 Apr 2007 10:35:17 +0100 Message-ID: In-Reply-To: <20070419224324.GA52936@hut.isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCPM Prague minutes for review Thread-Index: AceC1F2d5UHrRCETT5+rxTbL6z4iZwAWeXWQ From: To: , X-OriginalArrivalTime: 20 Apr 2007 09:35:20.0419 (UTC) FILETIME=[367CAB30:01C7832F] X-Spam-Score: 0.2 (/) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 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 fine as far as my section is concerned. Only issue there is the apparent repetition in the following: "Listing 7 key requirements for solution * Joe Touch: Proposes re-phrasing "Test should not harm innocent receiver": Anything that network could have done cannot be interpreted as malicious. Sender should not be allowed to do anything that the network couldn't have done anyway. That allows to develop the solution rather than just mess up the receiver. * Joe: The test should not harm an innocent receiver, i.e. anything the network may have done accidentally should not be seen as malicious. * Joe: It also should only do what the network would normally allow a sender to do." I seem to remember Joe also mentioned Postel's principle One other issue I spotted was that in start of discussion over SHOULD, MUST, MAY, etc the first bit from Joe is probably meant to sat "there may be cases when a specific implemntor will _not_ do this"=20 Toby ________________________________________________________________________ ____ Toby Moncaster, Networks Research Centre, BT Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 648734=20 -----Original Message----- From: Ted Faber [mailto:faber@ISI.EDU]=20 Sent: 19 April 2007 23:43 To: tcpm@ietf.org Subject: [tcpm] TCPM Prague minutes for review The minutes that David Borman merged from the notes taken by Pasi Sarolahti and Gorry Fairhurst are posted at http://www3.ietf.org/proceedings/07mar/minutes/tcpm.txt and attached. Please review and make sure we've spelled your name right and not put words in your mouth. The minutes are due tomorrow. Sorry for the short fuse. TCPM WG Meeting - IETF 68 - Prague Tuesday, March 20, 2007, 17:40 -- 18:40 Note takers: Pasi Sarolahti and Gorry Fairhurst Acting chair: David Borman (for Mark and Ted) Jabber watcher: Lars Eggert (My thanks to Pasi and Gorry for taking good notes, these minutes are mainly just a merger of their notes. -David) Agenda bashing -- no comments WG status * anti-spoof: Passed WGLC, currently in IETF last call * syn-flooding: in seemingly good shape, intent to have WGLC * soft errors: seemingly good shape, intent to have WGLC * rfc2581bis: authors believe issues have been addressed - for Draft Standard we need implementation reports - Mark to survey implementors -- implementors are asked to contact Mark * ecn-syn: Sally working on simulations to get clarity on what is right response to ECN-marked SYN-ACK. Sally and Mark have some disagreements on what the response should be. * tcp-auth: There is WG consensus on developing TCP-MD5 replacement. TCPM to do the transport protocol work. Design team has been established to produce -00 version from two competing drafts, chaired by Steve Bellovin. After that the usual WG process will take over.=20 User Timeout -- Lars Eggert draft-ietf-tcpm-tcp-uto-05.txt * Lars and chairs did not remember if this is going for experimental or proposed. Tim Shepard has preference for experimental. - Tim Shepherd: in San Diego asked this explicitly from chairs during agenda bashing, they said the plan is for Experimental. - Lars: ok * Status - TCP connection dies if there is long period of disconnection without ACKs coming in, relates to mobility, etc. - Draft proposes one way to solve it, a TCP option to signal the appropriate timeout - ver -05 has clarifications, Ted Faber commented earlier that the language needs to be consistent, lot of overload on UTO value. There was also one other issue during author discussion.=20 * Changing to make it explicit of what we talk about -- three pieces of connection state:=20 - "enabled": whether UTO is enabled or not - "local_uto": local UTO in use, system-wide default, or optionally applications to tell TCP stack what to use - "changeable": controls whether local UTO may be changed based on incoming options. Default is true unless application sets local_uto, false if application has set the local_uto. * Last issue - Distinction between UTO I am currently using vs. last sent UTO information. Ability to shorten the local UTO depends on maintaining last_sent_uto information. If don't need to shorten local UTO, the implementation becomes simpler. Does the WG consider this is important?=20 - There will be a revision, then WGLC - Gorry Fairhurst: Is there a real use-case for reducing the UTO? In the last meeting, we discussed the issues of having too small a value. So, things are simpler if we can only make this bigger. - Lars:That is one option. A TCP may wish to shorten this to release resources. Use case for short UTO could be busy web server, for long UTO it is periods of disconnectivity. Fernando would like to keep short UTO, Lars would like to remove. No one has requested short UTO, no one has opposed. - David Borman: if we don't have ability to shorten it, does it affect the web server? If the server uses a shorter timeout and closes the connection, the client would know about it anyway. - Lars: it wouldn't change anything on the web server. Would give the other guy ability to shorten timeout, if a disconnection happens. - Lars: server can locally timeout while client might keep trying for a longer time vs. client would stop immediately. * Next version need to choose which way to go, then we will need committed reviewers.=20 - Do the new variables clarify things? - Do we need to be able to reduce the UTO? Two volunteers: Anantha Ramaiah Arjuna Sathiaseelan TCP-secure -- Anantha Ramaiah draft-ietf-tcpm-tcpsecure-07.txt Improving TCP robustness. Has been around as WG document for two years, would like to go for WG last call. Provides mitigations to known security issues. Has been thoroughly discussed on list. Have been running in Internet for two years. No known serious issues. Changes: * Mitigation recommendations changed from MUST to SHOULD, after a comment by Ted Faber, would have made existing TCP implementations non-compliant with this. * Security considerations text rewritten. * Got many comments: some public, some private. Data injection mitigation: SHOULD or MAY? * explaining data injection mitigation specification * implementations can choose to hard code the value of max.snd.wnd mitigation. Increases robustness to FIN attack. Comments? Ready for WGLC? * Joe Touch: All documents need to be careful with the use of SHOULD - it means most implementations will do this, but there could be cases where a specific implementor will do this. We SHOULD say when (under what conditions) this is NOT OK to implement. Perhaps we could say a SHOULD (or even) MUST for all routers. * Joe Touch: Raising a comment from the list -- this is a general statement for all documents: What SHOULD means, and what it allows? There seems to be consensus about how it is documented in RFC 2119. I would be ok with SHOULD or even a MUST with regard to TCP implementations on routers. Requiring SHOULD without caveats to all hosts in the world, it is not compliant to update. On general host it is MAY.=20 * Scott Bradner: This interpretation is correct. The idea of SHOULD is saying this is to be done. You may not imagine there is a good reason for not doing this, (but you may not know all the possibilities at the time the RFC is published) - the aim is to do something to make the system to work. * Tim Shepard: clarifying question to Joe -- why did you say router? There could be end hosts and all sorts of places where you run long-lived connections that find this useful to improve robustness. Router is a wrong distinction. If you said BGP that might make more sense.=20 * Joe: because in routers TCP attack would be reasonable and likely. * Tim: There could be applications on end hosts, that may need this. Not just "router" it could be that we really mean a BGP session. * Anantha: Distinction to router is gone. We have router that can use TCP for all kinds of purposes, HTTP, voice-over-IP, all kinds of stuff.=20 * Joe: It may be useful for end hosts that have long-lived sessions were both ends are likely to be known. * Tim: It is needed on any system that may in the future need robustness. * Joe: ... yes, but in cases where the host fails to be implement "proper" security. * Lars Eggert: Note that previous discussions considered the document also has an IPR statement. The WG needs to include consideration of this in the decisions. * Anantha: why mentioned it now? * Lars: WG needs to include the existence of IPR in its decision. Draft has a long history, and shouldn't forget about the IPR. * Mark Allman - via jabber: The IPR point is that the IPR could have an impact on MUST v. SHOULD v. whatever, i.e., I would personally be against saying a TCP MUST implement tcpsecure, because it has an IPR statement. F-RTO update to proposed standard -- Markku Kojo (RFC 4138) Updating F-RTO to proposed standard. No revised protocol specification available, just an evaluation report Small modification in TCP sender algorithm, allows detecting a spurious RTO * Experimental RFC since Aug 2005. * number of known implementations. * Experimentations with all major implementations show encouraging results. * Interest to promote has been expressed already earlier * Last IETF we were asked to write document to evaluate & show it is not harmful. Material is available on a web page, but not yet in the repository. First question: is F-RTO useful? * showing time-sequence graphs of normal TCP behavior on delay spike * full window of segments unnecessarily retransmitted, wastes requests, breaks the packet conservation principle. * Problem in a mobility case of moving from WLAN to GPRS environment. * Problem is not about causing congestion, but about performance of an individual TCP flow * Presenting time-seq diagram of case using F-RTO. If two segments acknowledge new data, can declare timeout spurious and continue sending new data. Avoids unnecessary retransmissions, and additionally can take RTT samples from the delayed segments. Can F-RTO be harmful? No * If RTO is not spurious or F-RTO cannot detect spurious reverts back to the traditional RTO recovery. Exactly the same number of segments are transmitted as with normal RTO recovery. * There are a few corner cases where F-RTO can declare RTO spurious even if there are packet losses. It would be harmful if congestion control response was aggressive. If congestion window was not halved in response to spurious RTO, it should be ok. * Few known scenarios - 1: loss of unnecessary RTO retransmission. Quite rare situation to happen - 2: severe reordering * Mark Allman (via jabber): You have only ten minutes, get to the point - 3: malicious receiver - Might be harmful if congestion control response is reverted, but proposing that congestion window is reduced in response to spurious RTO, in which case false positives are not be harmful. Next steps * Revise RFC 4138, targeting at Proposed Standard. Specify basic algorithm only, and TCP only, leave out SCTP because there is no implementation experience. Leave out SACK-enhanced variant, because it has only limited benefit. * What to do with response? The draft does not specify any response in the original RFC. Options are 1) do not specify response 2) specify conservative default response, or 3) specify a conservative response in the new draft * Recommend implementing conservative response * Anantha Ramaiah: how does it cooperate with other related enhancements: Eifel, DSACK? - e.g, if all three coexist. * Markku: Does not require additional information. If timestamps have been enabled, Eifel can be used without problems. DSACK does not prevent unnecessary retransmissions. * David: Continue discussion on the mailing list. Please indicate if you want or don't want this to be promoted from experimental to proposed. Non-WG Drafts Identifying Cheating Receivers -- Toby Moncaster draft-moncaster-tcpm-rcv-cheat-00.txt First presentation of a new draft * TCP senders rely on accurate feedback from receivers * Dishonest receiver can do optimistic ACKs, causing sender to transmit at higher rate, conceal lost data, harmful for congestion control * Some existing proposed solutions: - Randomly skipped segments - ECN nonce - Transport layer nonce in TCP headers Listing 7 key requirements for solution * Joe Touch: Proposes re-phrasing "Test should not harm innocent receiver": Anything that network could have done cannot be interpreted as malicious. Sender should not be allowed to do anything that the network couldn't have done anyway. That allows to develop the solution rather than just mess up the receiver. * Joe: The test should not harm an innocent receiver, i.e. anything the network may have done accidentally should not be seen as malicious. * Joe: It also should only do what the network would normally allow a sender to do. Assessing proposed solutions * Table evaluating the earlier solutions * Joe: should have separate column in the draft, or have a separate row works only with certain options. Otherwise I like the table, should be also in the draft.=20 * Toby: it already is Our proposed solution * Based on Rob Sherwood's randomly skipped segments solution 1. delay a segment by small amount 2. delay segment until duplicate ack is received. Graph of stage 1 test Assessing stage 1 test * Meets all requirements set, but does not strictly prove dishonesty. * Joe: Should also say works only work with certain options. * Tim Shepard: if receiver is using SACK, the test gives receiver chance to prove it works nicely with SACK. The table did not mention delayed ACKs. * Toby: main gain of optimistic acking is to reduce RTT * Joe: any indications that things mentioned in tcpsecure have relationship with this. For example if anyone wanting to cheat by bursting.=20 * Toby: need to look at that in detail Stage 2 test * Meets all requirements set, except doesn't harm innocent receiver Conclusion * Cheating receiver gets more resources that it should get. Could possibly cause congestion collapse (Gorry needs to leave a room, other minute taker is gone) * Anantha: what about senders using byte counting? * Joe: should verify that there are no interactions with Nagle in cases when there are segments dropped, should check interactions with partial segments=20 TCP Response to Lower-Layer Connectivity-Change Indications -- Simon Sch tz draft-schuetz-tcpm-tcp-rlci-01.txt Problem: TCP is unaware of what happens on lower layers. RLCI uses generic indications from lower layers, avoids long idle time due to repetitive RTOs. Connection stays idle after gaining connection after disconnection, because RTO has backed off Why RLCI? * Provides generic approach to overcome problems - hand-overs - connectivity disruptions * Bob Briscoe: The draft was not clear is this about getting information from local link or of the remote link? * Simon: Defining the source of indications is out of scope, defining the response to indications. * Joe Touch: has been discussed before, problem with earlier approaches is that you are trying to get indications from the link layer, transitive to issue on putting this on the API layer. Tickling the end point deliberately, unreasonable thing to do.=20 What's new Next steps * Would like to start discussion on the mailing list * Candidate for experimental. * Soliciting discussion on the mailing list Concluding the TCPM meeting * Explicit reviewers sought for tcpsecure. Send mail to Ted and Mark if you are volunteering. * Looking for people to read tcp-persist and comment on the mailing list --=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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 20 10:50: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 1HeuRf-000382-KB; Fri, 20 Apr 2007 10:50:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuRV-0002vG-VT; Fri, 20 Apr 2007 10:50:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HeuRU-0007rc-Jp; Fri, 20 Apr 2007 10:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 87FCC17739; Fri, 20 Apr 2007 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HeuR0-0000Cc-Ab; Fri, 20 Apr 2007 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 20 Apr 2007 10:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-syn-flood-03.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP SYN Flooding Attacks and Common Mitigations Author(s) : W. Eddy Filename : draft-ietf-tcpm-syn-flood-03.txt Pages : 23 Date : 2007-4-20 This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-syn-flood-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-syn-flood-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-syn-flood-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-20090632.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-syn-flood-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-syn-flood-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-20090632.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Fri Apr 20 11:20:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuuX-0002ud-Iy; Fri, 20 Apr 2007 11:20:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuuW-0002p1-52 for tcpm@ietf.org; Fri, 20 Apr 2007 11:20:32 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeuuS-0006dF-Eb for tcpm@ietf.org; Fri, 20 Apr 2007 11:20:32 -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 l3KFK4cB025074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Apr 2007 08:20:04 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l3KFK3ln068680; Fri, 20 Apr 2007 08:20:03 -0700 (PDT) (envelope-from faber) Date: Fri, 20 Apr 2007 08:20:03 -0700 From: Ted Faber To: toby.moncaster@bt.com Subject: Re: [tcpm] TCPM Prague minutes for review Message-ID: <20070420152003.GE67763@hut.isi.edu> References: <20070419224324.GA52936@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.2i 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: 52f7a77164458f8c7b36b66787c853da 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="===============1150969270==" Errors-To: tcpm-bounces@ietf.org --===============1150969270== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZInfyf7laFu/Kiw7" Content-Disposition: inline --ZInfyf7laFu/Kiw7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 20, 2007 at 10:35:17AM +0100, toby.moncaster@bt.com wrote: > Generally fine as far as my section is concerned. Only issue there is > the apparent repetition in the following: >=20 > "Listing 7 key requirements for solution > * Joe Touch: Proposes re-phrasing "Test should not harm innocent > receiver": Anything that network could have done cannot be > interpreted as malicious. Sender should not be allowed to do > anything that the network couldn't have done anyway. That allows to > develop the solution rather than just mess up the receiver. > * Joe: The test should not harm an innocent receiver, i.e. anything the > network may have done accidentally should not be seen as malicious. > * Joe: It also should only do what the network would normally allow a > sender > to do." I agree that these are somewhat redundant, but I left them there in case there's a subtle distinction that I'm not hearing because I wasn't at the meeting. I don't see any harm in the extra text. Let me know if you disagree. > I seem to remember Joe also mentioned Postel's principle He often does. :-) Seriously, as you mention there's a fair hunk of text there representing his comments. I'm sure he'll speak up if there are key points missing. If you believe that the mention of the principle needs to be in the minutes, please don't hesitate to make it more clear to me.=20 >=20 > One other issue I spotted was that in start of discussion over SHOULD, > MUST, MAY, etc the first bit from Joe is probably meant to sat "there > may be cases when a specific implemntor will _not_ do this"=20 Good catch. That's been corrected. Thanks for the review. --=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 --ZInfyf7laFu/Kiw7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGKNojaUz3f+Zf+XsRAk9GAJ9YXOUDx1g9GvPqr3eGeeT2Me8UFQCg3syT tMRoPB9umGNQYyV9n+/vKDw= =XskY -----END PGP SIGNATURE----- --ZInfyf7laFu/Kiw7-- --===============1150969270== 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 --===============1150969270==-- From tcpm-bounces@ietf.org Fri Apr 20 11:25:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heuz9-0008SZ-Hg; Fri, 20 Apr 2007 11:25:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heuz8-0008ST-Hl for tcpm@ietf.org; Fri, 20 Apr 2007 11:25:18 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heuz6-0007fh-Nb for tcpm@ietf.org; Fri, 20 Apr 2007 11:25:18 -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 l3KFPDws026645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 20 Apr 2007 08:25:13 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l3KFPDps068809 for tcpm@ietf.org; Fri, 20 Apr 2007 08:25:13 -0700 (PDT) (envelope-from faber) Date: Fri, 20 Apr 2007 08:25:13 -0700 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] TCPM Prague minutes for review Message-ID: <20070420152513.GF67763@hut.isi.edu> References: <20070419224324.GA52936@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20070419224324.GA52936@hut.isi.edu> User-Agent: Mutt/1.4.2.2i 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: 97adf591118a232206bdb5a27b217034 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="===============0400197944==" Errors-To: tcpm-bounces@ietf.org --===============0400197944== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9ADF8FXzFeE7X4jE" Content-Disposition: inline --9ADF8FXzFeE7X4jE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 19, 2007 at 03:43:24PM -0700, Ted Faber wrote: > The minutes are due tomorrow. Sorry for the short fuse. Closer review indicates that we can correct the minutes until 9 May, so please take a more leisurely look if you have a chance. Thanks again. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --9ADF8FXzFeE7X4jE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGKNtZaUz3f+Zf+XsRAhibAJ9f6MEXlU4Dmgt3oFHylK0PSrnDaQCgmGJj aX2XvqmDFOZ42xAmjcmduDw= =JTk+ -----END PGP SIGNATURE----- --9ADF8FXzFeE7X4jE-- --===============0400197944== 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 --===============0400197944==-- From tcpm-bounces@ietf.org Sun Apr 22 10:00: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 1Hfcbp-0007lE-68; Sun, 22 Apr 2007 10:00:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfcbo-0007kw-4b for tcpm@ietf.org; Sun, 22 Apr 2007 10:00:08 -0400 Received: from web33309.mail.mud.yahoo.com ([68.142.206.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hfcbk-0006Wm-Kk for tcpm@ietf.org; Sun, 22 Apr 2007 10:00:08 -0400 Received: (qmail 75952 invoked by uid 60001); 22 Apr 2007 14:00:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=40aI+jNESEOlmGUW7EH2XwoUPpSqSxoBl1G1+C09x1S/MC4ixytRjY9D4uutYCrNdmafVMrFCq6Hlqe+zR71XLeBw5wAOWScKY9Snkp7X8Rm9fd1IN/vXOHK6FKWgA0z4yVt7zd842W6lq99f9sWfsYCFnrcBl08YlUsTrBhkl0=; X-YMail-OSG: 586Q18EVM1kFeRYXb1EzZoNEEjKeXDSEmp4u7UJK9zhXHCHVqo0XmEwUFav0DvF25eyogGCJE.k2yLl1MPNUzfflOgBrLjygV1GJIOPw.rRIHlM- Received: from [69.236.67.182] by web33309.mail.mud.yahoo.com via HTTP; Sun, 22 Apr 2007 07:00:03 PDT Date: Sun, 22 Apr 2007 07:00:03 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] RE: [tcpm] icmp type 3, code 13 To: "Faisal Siyavudeen \(fsiyavud\)" , Joe Touch In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <668657.73320.qm@web33309.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: tcpm@ietf.org, behave@ietf.org, "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" 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 Faisal, Sorry for the delay in responding. You are absolutely right. ICMP type 3, code 13 was selected for exactly the reasons you cite below. Thanks. regards, suresh --- "Faisal Siyavudeen (fsiyavud)" wrote: > > | > it could be code 10 or code 13 depending on the type of filtering. > | > | I don't see that difference; code 10 just says > | administratively prohibited, and code 13 says > | administratively prohibited because of filtering. In either > | case, other ports could be reachable. > | > > I agree. > > I am sorry I was not clear - my point was that 10 cannot be used where > other ports on the hosts are still accessible, while 13 can be used in > any of these cases. BTW, the following note in RFC 1812 makes me wonder > if NAT devices can send code 10 at all as they are more like routers: > > > Codes 9 and 10 were intended for use by end-to-end encryption devices > used by U.S military agencies. Routers SHOULD use the newly defined Code > 13 (Communication Administratively Prohibited) if they administratively > filter packets. > > > rgds > Faisal > > | -----Original Message----- > | From: Joe Touch [mailto:touch@ISI.EDU] > | Sent: Tuesday, April 10, 2007 10:04 PM > | To: Faisal Siyavudeen (fsiyavud) > | Cc: Pekka Savola; Dan Wing (dwing); tcpm@ietf.org; > | behave@ietf.org; Mahesh Govind (mgovind) > | Subject: Re: [tcpm] icmp type 3, code 13 > | > | > | > | Faisal Siyavudeen (fsiyavud) wrote: > | > | '10' seems to (at least more strongly) imply that all > | communication > | > | with the destination address is administratively prohibited. > | > > | > Does NAT administrative filtering referred to by > | > draft-ietf-behave-nat-icmp-03 cover filtering of > | application traffic > | > based on destination port? If yes, what error would be > | generated by a > | > NAT filtering out a certain type of application traffic to > | a certain > | > set of hosts? In that case, code 10 would not be the right > | one, as the > | > host might still be reachable on a different port. I feel that the > | > actual choice of error code would vary - it could be code > | 10 or code > | > 13 depending on the type of filtering. > | > | I don't see that difference; code 10 just says > | administratively prohibited, and code 13 says > | administratively prohibited because of filtering. In either > | case, other ports could be reachable. > | > | Joe > | > | > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Apr 22 10:06: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 1Hfchr-0004lM-7t; Sun, 22 Apr 2007 10:06:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfchp-0004jM-73 for tcpm@ietf.org; Sun, 22 Apr 2007 10:06:21 -0400 Received: from web33308.mail.mud.yahoo.com ([68.142.206.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hfcho-0000JF-Tm for tcpm@ietf.org; Sun, 22 Apr 2007 10:06:21 -0400 Received: (qmail 51487 invoked by uid 60001); 22 Apr 2007 14:06:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=S5SvR8rkUuIQk2T9+k3Osy2KsxpKHeUhaby1GXZsRvymIjs0I9p3bajRZJxrzNDCh9hAKdL0lhsAFNb0IY+vkq9KjmkAjN7HrKEDtT0+7x+q/giK/tlhAy0M9cJn4ekbewcL/0CccPFfnvCGBL/5d4mNMI5y4hF82HCvku7O8ZY=; X-YMail-OSG: Gpk97Z0VM1loOlhZdTkhLTbudnO9CxnBTsuASVPTSJCqt_aN6lPcWupPckhN8dBhpcVJfw-- Received: from [69.236.67.182] by web33308.mail.mud.yahoo.com via HTTP; Sun, 22 Apr 2007 07:06:20 PDT Date: Sun, 22 Apr 2007 07:06:20 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 To: Joe Touch , "Faisal Siyavudeen \(fsiyavud\)" In-Reply-To: <461BCA0B.3010706@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <355540.51243.qm@web33308.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tcpm@ietf.org, behave@ietf.org, "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" 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: > > > Faisal Siyavudeen (fsiyavud) wrote: > > | > it could be code 10 or code 13 depending on the type of filtering. > > | > > | I don't see that difference; code 10 just says > > | administratively prohibited, and code 13 says > > | administratively prohibited because of filtering. In either > > | case, other ports could be reachable. > > | > > > > I agree. > > > > I am sorry I was not clear - my point was that 10 cannot be used where > > other ports on the hosts are still accessible, while 13 can be used in > > any of these cases. BTW, the following note in RFC 1812 makes me wonder > > if NAT devices can send code 10 at all as they are more like routers: > > Uh, routers decrement the TTL. NATs do not. I don't think NATs behave > like routers per se. > > > > > Codes 9 and 10 were intended for use by end-to-end encryption devices > > used by U.S military agencies. Routers SHOULD use the newly defined Code > > 13 (Communication Administratively Prohibited) if they administratively > > filter packets. > > > > That argues that NATs should generate their own codes. This is NOT > router administrative filtering either. [suresh] NAT forwards packets between nodes in private domain and public domain. If NAT cannot forward a packet due to resource constrains or administrative restrictions, NAT needs to specify a reason to the sender. ICMP code 13 closely matches the description of the cause. What is your argument against using code 13? regards, suresh > > Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Apr 22 10:43: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 1HfdHy-000771-PA; Sun, 22 Apr 2007 10:43:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfdHx-00076f-HE for tcpm@ietf.org; Sun, 22 Apr 2007 10:43:41 -0400 Received: from web33306.mail.mud.yahoo.com ([68.142.206.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfdHw-00036h-4j for tcpm@ietf.org; Sun, 22 Apr 2007 10:43:41 -0400 Received: (qmail 92709 invoked by uid 60001); 22 Apr 2007 14:43:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=hR/rQ3QTEyVDBLpiERV9uKc8r+DVnhgqP6TMns7IQ/R4TS3SB6xn8Hl1Z/Qx4zmGUJh/m/IsQc0SdZE6WzVEcNcs+mgdRlFTdOEnGe0xjQOhwUzBK0bTkAdkoFvn2IN0NjAijKWiP1N99HOjvXLakDMD05j4Nl5cMoDvqb1TBmQ=; X-YMail-OSG: uqcz44MVM1kY_3eNK7DMaPDEaLuKFzSmq7fvGNk55quTDxX4xX3tjRFYkrSrT.eQ5r5vVcdmuU7zb9SdnIbu.wneBLNja3p6_qUXGEqj9iHh2rY- Received: from [69.236.67.182] by web33306.mail.mud.yahoo.com via HTTP; Sun, 22 Apr 2007 07:43:39 PDT Date: Sun, 22 Apr 2007 07:43:39 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 To: Joe Touch , Pekka Savola In-Reply-To: <461BDE8E.9000307@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <570982.92506.qm@web33306.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: tcpm@ietf.org, behave@ietf.org, "Faisal Siyavudeen \(fsiyavud\)" , "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" 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: > > > Pekka Savola wrote: > ... > >> Uh, routers decrement the TTL. NATs do not. I don't think NATs behave > >> like routers per se. > > > > YMMV but all NATs I have seen and used do decrement TTL. (I've heard > > reports about ones that don't, but never seen one myself.) > > One of the nasty things about NATs (or the people who design them) is > that anything that makes them visible is likely to be disabled by some > subset, in the hopes of making it 'transparent'. > > Although many NATs do decrement the TTL, there is no such requirement. > RFC3022 (traditional NATs, informational) doesn't even mention it, and [suresh] You are right, there is no mention of TTL in RFC 3022. And, we donot have a BEHAVE recommendation on NATs at IP level to suggest a BCP. That said, it does not take away the fact that NAT is fundamentally a router. As Pekka said, most NAT devices do decrement TTL in the IP heder, > RFC2766 (NAT proposed standard) talks about setting TTL to 0 for DNS, > but says specifically that TTLs are not decremented for statically > mapped addresses (and has nothing to say about dynamic ones). [suresh] Joe - the TTL above refers to the time-to-Live of the DNS RR, not the TTL of the IP header. > Other docs > (MIDCOM, arch implications of NATs) don't require TTL decrement either. > > > I'd be interested in knowing in which conditions access to a network, > > host, or a subset of a host should be considered "administratively > > prohibited", but that administrative prohibition is not due to filtering > > (be it a firewall rule, access list, configuration toggle, or whatever). > > source address/reverse path validation comes to mind. > [suresh] You are saying that a router can send ICMP code 13 if source address of a packet it receives is invalid. This is some sort of an administrative configuration/restriction. It seems reasonable for NAT to use the same error code 13 when it runs out of resources or has another type of administrative restriction. > Yes, it might be set with a toggle, but it's not what most people > consider when then talk about packet filtering (at least IMO). [suresh] I do not understand your above comment. What might be set with a toggle? > > IMO, because a NAT behaves like an endpoint (to the Internet side), it > should send ICMPs like one, and issue ICMP host/port unreachables, not > administrative filtering that routers would send. That would also 'do > the right thing' by making the ICMPs result in hard errors. > [suresh] Joe - NAT is not an endpoint device. NAT does not run applications on itself. If it does, that is not within the scope of BEHAVE. You may be stuck on some semantics. But, most people would agree NAT is a routing device. NAT forwards packets between private and public nodes. When NAT doesnt allow a flow to go through it, it must do what is right for an intermediate device and send the appropriate ICMP error code to the sender - be it a public node or a private node. I dont know of any other error code that is more appropriate than ICMP code 13 to do this. regards, suresh > Joe > > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Apr 22 13:46: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 1Hfg8x-0001Fg-55; Sun, 22 Apr 2007 13:46:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfg8u-0001Cy-O8; Sun, 22 Apr 2007 13:46:32 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfg8t-0005V7-Bg; Sun, 22 Apr 2007 13:46:32 -0400 Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3MHkD4g005128; Sun, 22 Apr 2007 10:46:14 -0700 (PDT) Message-ID: <462B9F55.1090008@isi.edu> Date: Sun, 22 Apr 2007 10:45:57 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Pyda Srisuresh Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 References: <355540.51243.qm@web33308.mail.mud.yahoo.com> In-Reply-To: <355540.51243.qm@web33308.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tcpm@ietf.org, behave@ietf.org, "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============1201446119==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1201446119== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD77DCF3A4101327F6AE2C17B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD77DCF3A4101327F6AE2C17B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable NATs are not routers. Using a code defined in RFC1812 for this purpose is to inappropriately imply that a router is generating the code. Joe Pyda Srisuresh wrote: > --- Joe Touch wrote: >=20 >> >> Faisal Siyavudeen (fsiyavud) wrote: >>> | > it could be code 10 or code 13 depending on the type of filtering= =2E >>> |=20 >>> | I don't see that difference; code 10 just says=20 >>> | administratively prohibited, and code 13 says=20 >>> | administratively prohibited because of filtering. In either=20 >>> | case, other ports could be reachable. >>> |=20 >>> >>> I agree. >>> >>> I am sorry I was not clear - my point was that 10 cannot be used wher= e >>> other ports on the hosts are still accessible, while 13 can be used i= n >>> any of these cases. BTW, the following note in RFC 1812 makes me wond= er >>> if NAT devices can send code 10 at all as they are more like routers:= >> Uh, routers decrement the TTL. NATs do not. I don't think NATs behave >> like routers per se. >> >>> >>> Codes 9 and 10 were intended for use by end-to-end encryption devices= >>> used by U.S military agencies. Routers SHOULD use the newly defined C= ode >>> 13 (Communication Administratively Prohibited) if they administrative= ly >>> filter packets. >>> >> That argues that NATs should generate their own codes. This is NOT >> router administrative filtering either. >=20 > [suresh] NAT forwards packets between nodes in private domain and publi= c > domain. If NAT cannot forward a packet due to resource constrains or > administrative restrictions, NAT needs to specify a reason to the sende= r.=20 > ICMP code 13 closely matches the description of the cause. What is your= > argument against using code 13? =20 >=20 > regards, > suresh=20 >=20 >> Joe >=20 >=20 --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigD77DCF3A4101327F6AE2C17B 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.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGK59VE5f5cImnZrsRAlFiAJ91+N8fWbpcWsg11mh07vkG88alqwCfSZrW wRQn08nOIAWBJiH3Vrsk1ek= =BI5y -----END PGP SIGNATURE----- --------------enigD77DCF3A4101327F6AE2C17B-- --===============1201446119== 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 --===============1201446119==-- From tcpm-bounces@ietf.org Sun Apr 22 13:50: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 1HfgCt-0003Us-Id; Sun, 22 Apr 2007 13:50:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfgCq-0003Rr-RW; Sun, 22 Apr 2007 13:50:36 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfgCq-0006OJ-F5; Sun, 22 Apr 2007 13:50:36 -0400 Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3MHoKCc005932; Sun, 22 Apr 2007 10:50:21 -0700 (PDT) Message-ID: <462BA04C.6090208@isi.edu> Date: Sun, 22 Apr 2007 10:50:04 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Pyda Srisuresh Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 References: <570982.92506.qm@web33306.mail.mud.yahoo.com> In-Reply-To: <570982.92506.qm@web33306.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.0 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, behave@ietf.org, "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============1104411720==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1104411720== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCC6E867A554DBE9500992F7E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCC6E867A554DBE9500992F7E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pyda Srisuresh wrote: > --- Joe Touch wrote: =2E.. >> Although many NATs do decrement the TTL, there is no such requirement.= >> RFC3022 (traditional NATs, informational) doesn't even mention it, and= >=20 > [suresh] You are right, there is no mention of TTL in RFC 3022. And, we= donot > have a BEHAVE recommendation on NATs at IP level to suggest a BCP. That= said, > it does not take away the fact that NAT is fundamentally a router. No, it is not. It would need to follow the entirety of RFC1812 to be a router; since decrementing the TTL is not required, it is *clearly* not a router. > As Pekka > said, most NAT devices do decrement TTL in the IP heder,=20 >=20 >> RFC2766 (NAT proposed standard) talks about setting TTL to 0 for DNS, >> but says specifically that TTLs are not decremented for statically >> mapped addresses (and has nothing to say about dynamic ones).=20 >=20 > [suresh] Joe - the TTL above refers to the time-to-Live of the DNS RR, = not the > TTL of the IP header.=20 Thanks for the detail; that is further evidence that NATs have nothing to do with routers, and are not routers. =2E.. >> IMO, because a NAT behaves like an endpoint (to the Internet side), it= >> should send ICMPs like one, and issue ICMP host/port unreachables, not= >> administrative filtering that routers would send. That would also 'do >> the right thing' by making the ICMPs result in hard errors. >> > [suresh] Joe - NAT is not an endpoint device. NAT does not run applicat= ions on > itself. If it does, that is not within the scope of BEHAVE.=20 A NAT sources packets with its own IP address; to the rest of the Internet, it behaves like an IP address source, and so IMO it is required to obey RFC1122 in all respects. > You may be stuck on some semantics. But, most people would agree NAT is= a > routing device. NAT forwards packets between private and public nodes. = When NAT > doesnt allow a flow to go through it, it must do what is right for an > intermediate device and send the appropriate ICMP error code to the sen= der - be > it a public node or a private node. I dont know of any other error code= that is > more appropriate than ICMP code 13 to do this. To the rest of the Internet (the public side), a NAT is clearly an IP source, and so must obey 1122. *IF* we want, we can require that NATs also obey 1812 on the private side - if we believe that the private device thinks the NAT is a router. I think that part isn't as clearly required. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigCC6E867A554DBE9500992F7E 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.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGK6BNE5f5cImnZrsRAivGAJ4rYsoMR66pRCnFZA8FdebhPIuNBwCeMcal 349A0X7US1oUZp0HVhLkdmQ= =IuoR -----END PGP SIGNATURE----- --------------enigCC6E867A554DBE9500992F7E-- --===============1104411720== 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 --===============1104411720==-- From tcpm-bounces@ietf.org Sun Apr 22 17:04: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 1HfjEC-0000wd-Tu; Sun, 22 Apr 2007 17:04:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfjEB-0000wM-JG for tcpm@ietf.org; Sun, 22 Apr 2007 17:04:11 -0400 Received: from web33308.mail.mud.yahoo.com ([68.142.206.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfjEB-0000lA-5u for tcpm@ietf.org; Sun, 22 Apr 2007 17:04:11 -0400 Received: (qmail 79917 invoked by uid 60001); 22 Apr 2007 21:04:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=qQF8vK00SpSbXFeApy/YA5oYG7Qu9kOQHfoayTOxB4TYBfGsHLXABs3jgnuvn2IXCiAWCMwlvqqtx3bWp0BBJ3AIV4GDFs684T8CdZKitxzi3UndfYlrvAPWdjm8Eqnc6pjHRzEh/DVxbaR5MoqA0kZy+Bshz7A+xbx59BI3d8c=; X-YMail-OSG: TdMK0_kVM1k0fPYIbG7aK95tME_5SkCUh2BAdTJSes9ww2QjWep77j8A8DhrJoFiMCkYMw-- Received: from [69.236.67.182] by web33308.mail.mud.yahoo.com via HTTP; Sun, 22 Apr 2007 14:04:10 PDT Date: Sun, 22 Apr 2007 14:04:10 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 To: Joe Touch In-Reply-To: <462B9F55.1090008@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <623076.79726.qm@web33308.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: tcpm@ietf.org, behave@ietf.org, "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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 Below is what RFC 1812 has to say about what constitutes a router. This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. The Internet community usually refers to such devices as IP routers or simply routers. NATs forward IP packets from one network to another. That makes NAT a router. And, it is appropriate for NAT to use the error codes a router device would use. If you insist NAT is not a router, I am not going to argue or get into a debate with you on this. I will simply disagree. So do the vast majority of people taht use NATs to connect to public networks. regards, suresh --- Joe Touch wrote: > NATs are not routers. Using a code defined in RFC1812 for this purpose > is to inappropriately imply that a router is generating the code. > > Joe > > Pyda Srisuresh wrote: > > --- Joe Touch wrote: > > > >> > >> Faisal Siyavudeen (fsiyavud) wrote: > >>> | > it could be code 10 or code 13 depending on the type of filtering. > >>> | > >>> | I don't see that difference; code 10 just says > >>> | administratively prohibited, and code 13 says > >>> | administratively prohibited because of filtering. In either > >>> | case, other ports could be reachable. > >>> | > >>> > >>> I agree. > >>> > >>> I am sorry I was not clear - my point was that 10 cannot be used where > >>> other ports on the hosts are still accessible, while 13 can be used in > >>> any of these cases. BTW, the following note in RFC 1812 makes me wonder > >>> if NAT devices can send code 10 at all as they are more like routers: > >> Uh, routers decrement the TTL. NATs do not. I don't think NATs behave > >> like routers per se. > >> > >>> > >>> Codes 9 and 10 were intended for use by end-to-end encryption devices > >>> used by U.S military agencies. Routers SHOULD use the newly defined Code > >>> 13 (Communication Administratively Prohibited) if they administratively > >>> filter packets. > >>> > >> That argues that NATs should generate their own codes. This is NOT > >> router administrative filtering either. > > > > [suresh] NAT forwards packets between nodes in private domain and public > > domain. If NAT cannot forward a packet due to resource constrains or > > administrative restrictions, NAT needs to specify a reason to the sender. > > ICMP code 13 closely matches the description of the cause. What is your > > argument against using code 13? > > > > regards, > > suresh > > > >> Joe > > > > > > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Apr 22 17:12: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 1HfjM3-0005sc-NL; Sun, 22 Apr 2007 17:12:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfjM1-0005s3-Ir; Sun, 22 Apr 2007 17:12:17 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfjM0-0001zw-6i; Sun, 22 Apr 2007 17:12:17 -0400 Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3MLBmoF012871; Sun, 22 Apr 2007 14:11:49 -0700 (PDT) Message-ID: <462BCF84.6040706@isi.edu> Date: Sun, 22 Apr 2007 14:11:32 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Pyda Srisuresh Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 References: <623076.79726.qm@web33308.mail.mud.yahoo.com> In-Reply-To: <623076.79726.qm@web33308.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tcpm@ietf.org, behave@ietf.org, "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============2102349091==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2102349091== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7C81E59175C4D6D4A9686202" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7C81E59175C4D6D4A9686202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pyda Srisuresh wrote: > Below is what RFC 1812 has to say about what constitutes a router. >=20 > This memo defines and discusses requirements for devices that perform= > the network layer forwarding function of the Internet protocol suite.= > The Internet community usually refers to such devices as IP routers o= r > simply routers. The rest of that document is what defines what is an Internet router. Being a device that does network layer forwarding and violates any of the rest of that doc means that device is not an Internet router. > NATs forward IP packets from one network to another. That makes NAT a r= outer. NATs don't follow the requirement of: - decrement the TTL - do not modify the source or destination IP address (except as per source-routing options) =2E.. > If you insist NAT is not a router, I am not going to argue or get into = a debate > with you on this. I will simply disagree. So do the vast majority of pe= ople > taht use NATs to connect to public networks. They can and have disagreed before, but this isn't up for a popular vote. It's utterly useless to talk about using any sort of IETF standard - including ICMP type 3 code 13 - and expect the rest of the Internet to follow that standard when NATs violate the standard of what it means to be a router. Joe --------------enig7C81E59175C4D6D4A9686202 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.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGK8+FE5f5cImnZrsRAsPSAKD0SmYQL75i5R+Vda+3cb03u33wagCbBgQp efScZuhYs5nCKTXiS1lLZ1Y= =g48G -----END PGP SIGNATURE----- --------------enig7C81E59175C4D6D4A9686202-- --===============2102349091== 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 --===============2102349091==-- From tcpm-bounces@ietf.org Sun Apr 22 18:46: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 1Hfkou-0003tu-1S; Sun, 22 Apr 2007 18:46:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfkos-0003tN-OM; Sun, 22 Apr 2007 18:46:10 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfkos-0007M8-B4; Sun, 22 Apr 2007 18:46:10 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2007 15:46:09 -0700 X-IronPort-AV: i="4.14,439,1170662400"; d="scan'208"; a="414354533:sNHT50946788" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3MMk9At004149; Sun, 22 Apr 2007 15:46:09 -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 l3MMk9ZT023985; Sun, 22 Apr 2007 22:46:09 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Apr 2007 15:46:09 -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: [BEHAVE] Re: [tcpm] icmp type 3, code 13 Date: Sun, 22 Apr 2007 15:46:07 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58033AD7BD@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <462BCF84.6040706@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: [tcpm] icmp type 3, code 13 Thread-Index: AceFIwZrSlG9WE48Smed/fkcaYY6uQABRfhg From: "Anantha Ramaiah \(ananth\)" To: "Joe Touch" , "Pyda Srisuresh" X-OriginalArrivalTime: 22 Apr 2007 22:46:09.0214 (UTC) FILETIME=[04FFB5E0:01C78530] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2921; t=1177281969; x=1178145969; c=relaxed/simple; s=sjdkim4002; 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[BEHAVE]=20Re=3A=20[tcpm]=20icmp=20type=203, =20code=2 013 |Sender:=20; bh=2innWXmD2IX7rlAUasc0ADjxuVRIvDthl40zwYlxrdw=; b=BKKRfsHuyO1cp2ZkW8z5bTEbLwCjMHHX6N9OYSsRNpdAwLDHXwkB/PHlcXuOG8s3Mc2a1Vtd yWWvkzW0mDX0MFHJGisa6KtxHGgnbkJhRt3WHL+3Z1VX2uGmsD97c40V; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: tcpm@ietf.org, behave@ietf.org, "Faisal Siyavudeen \(fsiyavud\)" , "Dan Wing \(dwing\)" , "Mahesh Govind \(mgovind\)" 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 Firstly, why is this being disussed in tcpm? This doesn't apply to TCP directly. [ even in-directly it might apply to all other transport protocols who can/may want to act on these errors] Maybe tsvwg is more appropriate?=20 As far as the current discussion goes, there is a thin line of distinction between hosts and routers, today. Today's routers do all sort of things which were only done by end-hosts at one point of time. So any discussion which is based on the semantics of a router/switch/host is IMO, useless, since things have evolved.=20 Also, actually, when you say "NAT's are not routers", there is a lot of ambiguity there : Typical case where NAT is configured in a router, which means that this device, applies NAT rule and route's the packets. So are you saying :- - generate a ICMP error code if the error is a result of a "routing operation" and NOT as a result of "NAT operation"? I really don't see a value in seperating these and it boils down to pure semantic argument, IMO, without considering the characteristics of the deployed Internet today.=20 -Anantha=20 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Sunday, April 22, 2007 2:12 PM > To: Pyda Srisuresh > Cc: tcpm@ietf.org; behave@ietf.org; Mahesh Govind (mgovind);=20 > Dan Wing (dwing); Faisal Siyavudeen (fsiyavud) > Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 >=20 >=20 >=20 > Pyda Srisuresh wrote: > > Below is what RFC 1812 has to say about what constitutes a router. > >=20 > > This memo defines and discusses requirements for devices=20 > that perform > > the network layer forwarding function of the Internet=20 > protocol suite. > > The Internet community usually refers to such devices as=20 > IP routers or > > simply routers. >=20 > The rest of that document is what defines what is an Internet router. > Being a device that does network layer forwarding and=20 > violates any of the rest of that doc means that device is not=20 > an Internet router. >=20 > > NATs forward IP packets from one network to another. That=20 > makes NAT a router. >=20 > NATs don't follow the requirement of: > - decrement the TTL > - do not modify the source or destination IP address > (except as per source-routing options) >=20 > ... > > If you insist NAT is not a router, I am not going to argue=20 > or get into=20 > > a debate with you on this. I will simply disagree. So do the vast=20 > > majority of people taht use NATs to connect to public networks. >=20 > They can and have disagreed before, but this isn't up for a=20 > popular vote. It's utterly useless to talk about using any=20 > sort of IETF standard > - including ICMP type 3 code 13 - and expect the rest of the=20 > Internet to follow that standard when NATs violate the=20 > standard of what it means to be a router. >=20 > Joe >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Apr 23 10:14: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 1HfzJR-0002v5-3r; Mon, 23 Apr 2007 10:14:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfzJO-0002uT-Vc; Mon, 23 Apr 2007 10:14:38 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfzJM-0002Bx-29; Mon, 23 Apr 2007 10:14:38 -0400 Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net [71.106.84.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3NEEJu4028700; Mon, 23 Apr 2007 07:14:20 -0700 (PDT) Message-ID: <462CBF2B.2040100@isi.edu> Date: Mon, 23 Apr 2007 07:14:03 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 References: <0C53DCFB700D144284A584F54711EC58033AD7BD@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58033AD7BD@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: tcpm@ietf.org, behave@ietf.org, Pyda Srisuresh , "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============0355811873==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0355811873== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig673476E372F3D43386EE838B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig673476E372F3D43386EE838B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > Firstly, why is this being disussed in tcpm? This doesn't apply to TCP > directly. [ even in-directly it might apply to all other transport > protocols who can/may want to act on these errors] Maybe tsvwg is more > appropriate?=20 That's possible; someone in Behave might start by posting a summary of the question there as well. > As far as the current discussion goes, there is a thin line of > distinction between hosts and routers, today. There may be many devices that do both functions, but to the extent they do they must then obey both the host and router requirements. > Today's routers do all > sort of things which were only done by end-hosts at one point of time. Such as? Other than acting like end hosts for connections that terminate at routers, which they have always done, and always required RFC1122-level support... > So any discussion which is based on the semantics of a > router/switch/host is IMO, useless, since things have evolved. Until the requirements in the IETF are updated to reflect this opinion, it is irrelevant. > Also, actually, when you say "NAT's are not routers", there is a lot of= > ambiguity there : >=20 > Typical case where NAT is configured in a router, which means that this= > device, applies NAT rule and route's the packets.=20 Then the part that routes must obey RFC1812 rules. If the part that routes can respond in lieu of the part that NATs, then that's fine. But when the part that NATs acts, it can't act like the router. > So are you saying :- =2E.. > - generate a ICMP error code if the error is a result of a "routing > operation" and NOT as a result of "NAT operation"?=20 Yes. > I really don't see a > value in seperating these and it boils down to pure semantic argument, > IMO, without considering the characteristics of the deployed Internet > today.=20 First, there are plenty of devices that do not combine both functions, and that's where we're talking about. However, in the case of the combined device, it still makes sense to determine WHY an error code is being generated. If because of a routing issue, then RFC1812 works; if because of a NAT issue, then RFC1812 is NOT the guiding document. Joe >> -----Original Message----- >> From: Joe Touch [mailto:touch@ISI.EDU]=20 >> Sent: Sunday, April 22, 2007 2:12 PM >> To: Pyda Srisuresh >> Cc: tcpm@ietf.org; behave@ietf.org; Mahesh Govind (mgovind);=20 >> Dan Wing (dwing); Faisal Siyavudeen (fsiyavud) >> Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 >> >> >> >> Pyda Srisuresh wrote: >>> Below is what RFC 1812 has to say about what constitutes a router. >>> >>> This memo defines and discusses requirements for devices=20 >> that perform >>> the network layer forwarding function of the Internet=20 >> protocol suite. >>> The Internet community usually refers to such devices as=20 >> IP routers or >>> simply routers. >> The rest of that document is what defines what is an Internet router. >> Being a device that does network layer forwarding and=20 >> violates any of the rest of that doc means that device is not=20 >> an Internet router. >> >>> NATs forward IP packets from one network to another. That=20 >> makes NAT a router. >> >> NATs don't follow the requirement of: >> - decrement the TTL >> - do not modify the source or destination IP address >> (except as per source-routing options) >> >> ... >>> If you insist NAT is not a router, I am not going to argue=20 >> or get into=20 >>> a debate with you on this. I will simply disagree. So do the vast=20 >>> majority of people taht use NATs to connect to public networks. >> They can and have disagreed before, but this isn't up for a=20 >> popular vote. It's utterly useless to talk about using any=20 >> sort of IETF standard >> - including ICMP type 3 code 13 - and expect the rest of the=20 >> Internet to follow that standard when NATs violate the=20 >> standard of what it means to be a router. >> >> Joe >> >> >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig673476E372F3D43386EE838B 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.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLL8rE5f5cImnZrsRAkaYAKCxHpQK6ru7L9JJ6eA2rbljJnNUewCgmRX8 htxwE5SggzIVlM9/mRAPMuQ= =+D/E -----END PGP SIGNATURE----- --------------enig673476E372F3D43386EE838B-- --===============0355811873== 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 --===============0355811873==-- From tcpm-bounces@ietf.org Mon Apr 23 12:12:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg19S-0003yC-DV; Mon, 23 Apr 2007 12:12:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg19R-0003xW-4G; Mon, 23 Apr 2007 12:12:29 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg19P-0001bh-MX; Mon, 23 Apr 2007 12:12:29 -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 l3NGALeI010432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Apr 2007 09:10:21 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l3NGALqU093438; Mon, 23 Apr 2007 09:10:21 -0700 (PDT) (envelope-from faber) Date: Mon, 23 Apr 2007 09:10:21 -0700 From: Ted Faber To: Joe Touch Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 Message-ID: <20070423161021.GI66656@hut.isi.edu> References: <355540.51243.qm@web33308.mail.mud.yahoo.com> <462B9F55.1090008@isi.edu> Mime-Version: 1.0 In-Reply-To: <462B9F55.1090008@isi.edu> User-Agent: Mutt/1.4.2.2i 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tcpm@ietf.org, behave@ietf.org, Pyda Srisuresh , "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============0353557347==" Errors-To: tcpm-bounces@ietf.org --===============0353557347== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lqaZmxkhekPBfBzr" Content-Disposition: inline --lqaZmxkhekPBfBzr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 22, 2007 at 10:45:57AM -0700, Joe Touch wrote: > NATs are not routers. Using a code defined in RFC1812 for this purpose > is to inappropriately imply that a router is generating the code. I agree that a NAT that doesn't follow 1812 is not a compliant router. However if this is only a semantic issue there are plenty of words out there that could get around the semantic issue, e.g. "... in this case a NAT may send an ICMP type 3 code 13 packet as a proxy for the router inside its name space in order to simplify the translation ...". Is there a deeper issue here? Will the ICMP being issued with the NAT's address cause functional confusion or malfunction in a host receiving it? Is this a distinction that matters, or are words sufficient? --=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 --lqaZmxkhekPBfBzr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGLNptaUz3f+Zf+XsRAsZ+AJ4+MV4VhHt2xbZPZSipeb6lu1/0QACfR6LC aE5p0sQbRuEkXGINFrHh5Sc= =h7Pa -----END PGP SIGNATURE----- --lqaZmxkhekPBfBzr-- --===============0353557347== 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 --===============0353557347==-- From tcpm-bounces@ietf.org Mon Apr 23 12:26: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 1Hg1NC-0007bB-4x; Mon, 23 Apr 2007 12:26:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1N7-0007Gc-0r; Mon, 23 Apr 2007 12:26:37 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1N6-0005vS-BI; Mon, 23 Apr 2007 12:26:36 -0400 Received: from [127.0.0.1] (152.sub-75-215-23.myvzw.com [75.215.23.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3NGQ7w2001045; Mon, 23 Apr 2007 09:26:10 -0700 (PDT) Message-ID: <462CDE0D.7070605@isi.edu> Date: Mon, 23 Apr 2007 09:25:49 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ted Faber Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 References: <355540.51243.qm@web33308.mail.mud.yahoo.com> <462B9F55.1090008@isi.edu> <20070423161021.GI66656@hut.isi.edu> In-Reply-To: <20070423161021.GI66656@hut.isi.edu> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: tcpm@ietf.org, behave@ietf.org, Pyda Srisuresh , "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============0445534939==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0445534939== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB532D2998087F02859ABB77B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB532D2998087F02859ABB77B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Sun, Apr 22, 2007 at 10:45:57AM -0700, Joe Touch wrote: >> NATs are not routers. Using a code defined in RFC1812 for this purpose= >> is to inappropriately imply that a router is generating the code. >=20 > I agree that a NAT that doesn't follow 1812 is not a compliant router. > However if this is only a semantic issue there are plenty of words out > there that could get around the semantic issue, e.g. "... in this case > a NAT may send an ICMP type 3 code 13 packet as a proxy for the router > inside its name space in order to simplify the translation ...". There need not be a router on either side of a NAT; in that case, what router is the NAT being a proxy for? Besides, if I configure either such router to never send such messages, the NAT has no right to generate them for me. > Is there a deeper issue here? Will the ICMP being issued with the NAT'= s > address cause functional confusion or malfunction in a host receiving > it? Is this a distinction that matters, or are words sufficient? I think the issue is "eating cake and having it too". The fundamental goal of most NATs is invisibility; you can't be invisible and scream when something goes wrong. Joe --------------enigB532D2998087F02859ABB77B 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.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLN4OE5f5cImnZrsRAk0JAKDrm3/GRHgd0VRzx1qhWemSIGWzpACg9YbG 31nNvV3bThCuFUBXkBo5+TI= =5LSI -----END PGP SIGNATURE----- --------------enigB532D2998087F02859ABB77B-- --===============0445534939== 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 --===============0445534939==-- From tcpm-bounces@ietf.org Mon Apr 23 14:18:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg37m-0001Tc-3w; Mon, 23 Apr 2007 14:18:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg37k-0001SI-Cj; Mon, 23 Apr 2007 14:18:52 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg37i-0003LJ-VS; Mon, 23 Apr 2007 14:18:52 -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 l3NIIMYL016150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Apr 2007 11:18:22 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l3NIIMNX016519; Mon, 23 Apr 2007 11:18:22 -0700 (PDT) (envelope-from faber) Date: Mon, 23 Apr 2007 11:18:22 -0700 From: Ted Faber To: Joe Touch Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 Message-ID: <20070423181822.GB1301@hut.isi.edu> References: <355540.51243.qm@web33308.mail.mud.yahoo.com> <462B9F55.1090008@isi.edu> <20070423161021.GI66656@hut.isi.edu> <462CDE0D.7070605@isi.edu> Mime-Version: 1.0 In-Reply-To: <462CDE0D.7070605@isi.edu> User-Agent: Mutt/1.4.2.2i 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: 4b800b1eab964a31702fa68f1ff0e955 Cc: tcpm@ietf.org, behave@ietf.org, Pyda Srisuresh , "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============0333272841==" Errors-To: tcpm-bounces@ietf.org --===============0333272841== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JP+T4n/bALQSJXh8" Content-Disposition: inline --JP+T4n/bALQSJXh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 23, 2007 at 09:25:49AM -0700, Joe Touch wrote: >=20 >=20 > Ted Faber wrote: > > On Sun, Apr 22, 2007 at 10:45:57AM -0700, Joe Touch wrote: > >> NATs are not routers. Using a code defined in RFC1812 for this purpose > >> is to inappropriately imply that a router is generating the code. > >=20 > > I agree that a NAT that doesn't follow 1812 is not a compliant router. > > However if this is only a semantic issue there are plenty of words out > > there that could get around the semantic issue, e.g. "... in this case > > a NAT may send an ICMP type 3 code 13 packet as a proxy for the router > > inside its name space in order to simplify the translation ...". >=20 > There need not be a router on either side of a NAT; in that case, what > router is the NAT being a proxy for? Oh I bet I can find a router on a non-trivial Internet path. :-) I don't want to spend too much time defending a hypothetical rewording. I'd rather talk about the issue that you get to below. > > Is there a deeper issue here? Will the ICMP being issued with the NAT's > > address cause functional confusion or malfunction in a host receiving > > it? Is this a distinction that matters, or are words sufficient? >=20 > I think the issue is "eating cake and having it too". >=20 > The fundamental goal of most NATs is invisibility; you can't be > invisible and scream when something goes wrong. This is a fair point. If a NAT is otherwise acting transparently, it is certainly alarming that it will occasionally pop up with an ICMP message. I can imagine the pain of trying to debug such an error message using standard tools like traceroute or even ping. ("I got an ICMP from something that doesn't respond to a ping!?") I think that the nail you're hitting is that partial visibility is clearly confusing to applications and administrators and needs to be avoided. I'd agree that a device that emits an ICMP but is otherwise invisible to endpoints is difficult enough to deal with in the real world that the behavior needs to be discouraged. If you agree with that, we agree. --=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 --JP+T4n/bALQSJXh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGLPhuaUz3f+Zf+XsRAkDOAJ9AQje5HOG6lomO7JPOwGKIc21JzQCfcgzD nPtSUH+ciHjoiweiIqQDDeU= =3+72 -----END PGP SIGNATURE----- --JP+T4n/bALQSJXh8-- --===============0333272841== 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 --===============0333272841==-- From tcpm-bounces@ietf.org Mon Apr 23 14:40: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 1Hg3T9-0002t2-28; Mon, 23 Apr 2007 14:40:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3T7-0002rF-BV; Mon, 23 Apr 2007 14:40:57 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3T6-0001tP-Uq; Mon, 23 Apr 2007 14:40:57 -0400 Received: from [127.0.0.1] (152.sub-75-215-23.myvzw.com [75.215.23.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3NIecJN004972; Mon, 23 Apr 2007 11:40:43 -0700 (PDT) Message-ID: <462CFD92.5080500@isi.edu> Date: Mon, 23 Apr 2007 11:40:18 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ted Faber Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 References: <355540.51243.qm@web33308.mail.mud.yahoo.com> <462B9F55.1090008@isi.edu> <20070423161021.GI66656@hut.isi.edu> <462CDE0D.7070605@isi.edu> <20070423181822.GB1301@hut.isi.edu> In-Reply-To: <20070423181822.GB1301@hut.isi.edu> X-Enigmail-Version: 0.95.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: tcpm@ietf.org, behave@ietf.org, Pyda Srisuresh , "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============1528124686==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1528124686== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD1A1F59CF37DDDB09348BF86" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD1A1F59CF37DDDB09348BF86 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Mon, Apr 23, 2007 at 09:25:49AM -0700, Joe Touch wrote: >> >> Ted Faber wrote: >>> On Sun, Apr 22, 2007 at 10:45:57AM -0700, Joe Touch wrote: >>>> NATs are not routers. Using a code defined in RFC1812 for this purpo= se >>>> is to inappropriately imply that a router is generating the code. >>> I agree that a NAT that doesn't follow 1812 is not a compliant router= =2E >>> However if this is only a semantic issue there are plenty of words ou= t >>> there that could get around the semantic issue, e.g. "... in this cas= e >>> a NAT may send an ICMP type 3 code 13 packet as a proxy for the route= r >>> inside its name space in order to simplify the translation ...". >> There need not be a router on either side of a NAT; in that case, what= >> router is the NAT being a proxy for? >=20 > Oh I bet I can find a router on a non-trivial Internet path. :-) Unless you can find one on EVERY such path, you can't assume you're generating the message as a proxy for that router. I.e., if a router isn't a required part of that path, then sending one as a proxy isn't an option. =2E.. >>> Is there a deeper issue here? Will the ICMP being issued with the NA= T's >>> address cause functional confusion or malfunction in a host receiving= >>> it? Is this a distinction that matters, or are words sufficient? >> I think the issue is "eating cake and having it too". >> >> The fundamental goal of most NATs is invisibility; you can't be >> invisible and scream when something goes wrong. >=20 > This is a fair point. If a NAT is otherwise acting transparently, it i= s > certainly alarming that it will occasionally pop up with an ICMP > message. I can imagine the pain of trying to debug such an error > message using standard tools like traceroute or even ping. ("I got an > ICMP from something that doesn't respond to a ping!?") >=20 > I think that the nail you're hitting is that partial visibility is > clearly confusing to applications and administrators and needs to be > avoided. I'd agree that a device that emits an ICMP but is otherwise > invisible to endpoints is difficult enough to deal with in the real > world that the behavior needs to be discouraged. If you agree with > that, we agree. Yes. The issue, IMO, is that generating a non-NAT ICMP is what's being requested exactly to hide the fact that there's a NAT here, and that's self-contradictory. Joe --------------enigD1A1F59CF37DDDB09348BF86 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.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLP2SE5f5cImnZrsRAp8YAKDypmW5DIZWzH4+u1RWvBgxZHfV/QCgjdMl sl1xi2c29OqwcjrnyGyKgK0= =Xa57 -----END PGP SIGNATURE----- --------------enigD1A1F59CF37DDDB09348BF86-- --===============1528124686== 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 --===============1528124686==-- From tcpm-bounces@ietf.org Mon Apr 23 14:50: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 1Hg3cR-0003Cj-02; Mon, 23 Apr 2007 14:50:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3cP-0003B9-5E; Mon, 23 Apr 2007 14:50:33 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3cN-0004yB-Nw; Mon, 23 Apr 2007 14:50:33 -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 l3NIo8XX025301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Apr 2007 11:50:08 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l3NIo8Pc003613; Mon, 23 Apr 2007 11:50:08 -0700 (PDT) (envelope-from faber) Date: Mon, 23 Apr 2007 11:50:08 -0700 From: Ted Faber To: Joe Touch Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13 Message-ID: <20070423185008.GC1301@hut.isi.edu> References: <355540.51243.qm@web33308.mail.mud.yahoo.com> <462B9F55.1090008@isi.edu> <20070423161021.GI66656@hut.isi.edu> <462CDE0D.7070605@isi.edu> <20070423181822.GB1301@hut.isi.edu> <462CFD92.5080500@isi.edu> Mime-Version: 1.0 In-Reply-To: <462CFD92.5080500@isi.edu> User-Agent: Mutt/1.4.2.2i 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tcpm@ietf.org, behave@ietf.org, Pyda Srisuresh , "Mahesh Govind \(mgovind\)" , "Dan Wing \(dwing\)" , "Faisal Siyavudeen \(fsiyavud\)" 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="===============0422698138==" Errors-To: tcpm-bounces@ietf.org --===============0422698138== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bu8it7iiRSEf40bY" Content-Disposition: inline --Bu8it7iiRSEf40bY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 23, 2007 at 11:40:18AM -0700, Joe Touch wrote: > Unless you can find one on EVERY such path, you can't assume you're > generating the message as a proxy for that router. I.e., if a router > isn't a required part of that path, then sending one as a proxy isn't an > option. I am so not having that argument. >=20 > Yes. The issue, IMO, is that generating a non-NAT ICMP is what's being > requested exactly to hide the fact that there's a NAT here, and that's > self-contradictory. That seems a more compelling objection to me. --=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 --Bu8it7iiRSEf40bY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGLP/gaUz3f+Zf+XsRAjdEAJsHnoDUFiRJUDHYyfkg8PTYf9WCCgCeINl8 gdD5IGRgDoC08NuLFncqsfE= =aRzM -----END PGP SIGNATURE----- --Bu8it7iiRSEf40bY-- --===============0422698138== 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 --===============0422698138==-- From tcpm-bounces@ietf.org Tue Apr 24 23:47: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 1HgYTG-0008H2-Jl; Tue, 24 Apr 2007 23:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgYTF-0008Gw-K6 for tcpm@ietf.org; Tue, 24 Apr 2007 23:47:09 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgYTE-0005NS-6U for tcpm@ietf.org; Tue, 24 Apr 2007 23:47:09 -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 l3P3l7A7030346; Tue, 24 Apr 2007 20:47:07 -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 48A39A2C792; Tue, 24 Apr 2007 23:47:02 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 117871E18C7; Tue, 24 Apr 2007 23:46:24 -0400 (EDT) To: Ted Faber From: Mark Allman Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors In-Reply-To: <20070409151328.GB1285@hut.isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: After Midnight MIME-Version: 1.0 Date: Tue, 24 Apr 2007 23:46:24 -0400 Message-Id: <20070425034624.117871E18C7@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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="===============0309432665==" Errors-To: tcpm-bounces@ietf.org --===============0309432665== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Mark and I would like to start a WG last call on the informational > document on TCP's reaction to soft ICMP errors on connection set-up: > > Title : TCP's Reaction to Soft Errors > Author(s) : F. Gont > Filename : draft-ietf-tcpm-tcp-soft-errors-05.txt > Pages : 13 > Date : 2007-4-4 > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-05.txt > > Our understanding is that all feedback to date is reflected in this > version and that there are no known outstanding issues. Please send > feedback (even if just of the form "yep, looks good"). > > This WGLC will end on Monday 23 Apr 2007. Folks- We received nearly no feedback on this WGLC. Since this draft has been contentious in the past we need some review before passing it along to the IESG. We are therefore extending the WGLC until May 15. Please take a few minutes and look over the draft and send comments. As Ted notes above, even if you think the draft looks fine a one-sentence note that says this would be very much appreciated. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGLs8PWyrrWs4yIs4RAq1WAKCfR8XgPXS4AuZLJg4N8Pv7YWqKHQCcCr+A Bah/dArD1Z8VEo28LC1Sx98= =KG/Q -----END PGP SIGNATURE----- --=_bOundary-- --===============0309432665== 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 --===============0309432665==-- From tcpm-bounces@ietf.org Wed Apr 25 13:18: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 1Hgl8B-0003tv-A1; Wed, 25 Apr 2007 13:18:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgl89-0003tW-G2 for tcpm@ietf.org; Wed, 25 Apr 2007 13:18:13 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgl88-0003FM-7N for tcpm@ietf.org; Wed, 25 Apr 2007 13:18:13 -0400 Received: by ug-out-1314.google.com with SMTP id 72so378552ugd for ; Wed, 25 Apr 2007 10:18:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=tZbrOBIRiWuCO0xnEiy0BVwfArqgkjjl8KCfI/pwxNvFqO+WUWMiNxbC59fTRoSqGV30nmQnZRCOOjGoLmaZ047hotuOcRc31UVb9XciHQ0/cDH+sWRFMHl8MXVb9JOHZP8T/CXyzxzyloorTOGlWhPLTJr2BbPbLRUNkmXrTw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=APizVWmHApOzaZ/mixiIFBhiCpeR6A2iFmFdeDCj5iDluVVPWP8gzwoeyI8nGL2nH1DELeY/Pj+/1vvHA7kU0HuSD8WOz6UYFcpG76Ir01PrOhK4cxcD2N7RQ/Lzp/ZRp12Nd0MaYejedldQWC1lGcbdunK2bVp1GZFDFX9Duf4= Received: by 10.67.24.18 with SMTP id b18mr1520867ugj.1177521490974; Wed, 25 Apr 2007 10:18:10 -0700 (PDT) Received: by 10.67.56.20 with HTTP; Wed, 25 Apr 2007 10:18:10 -0700 (PDT) Message-ID: Date: Wed, 25 Apr 2007 10:18:10 -0700 From: "Vishal Study" To: tcpm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [tcpm] TCP Reassembly Timer 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: Is there an RFC/draft that talks about TCP Reassembly timer? Scenario: Host begins to receive out of order pkts and enqueues them in its RX_Q. If there are lot of sessions that are stuck in such state (with out of order pkts), the system can go down on resources (memory). Does any standard/RFC talk about what should be the expected behavior? I know there are implementations that have a Reassembly timer and they either drop the session or (atleast) drop out of order pkts when the Reassembly timer kicks off. Any pointers... Thanks in advance, Vishal. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Apr 25 13:45: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 1HglYm-0001pU-Ek; Wed, 25 Apr 2007 13:45:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HglYk-0001p9-WE for tcpm@ietf.org; Wed, 25 Apr 2007 13:45:43 -0400 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HglYk-0002vn-F4 for tcpm@ietf.org; Wed, 25 Apr 2007 13:45:42 -0400 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l3PHjdqR010833; Wed, 25 Apr 2007 10:45:39 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 10:45:39 -0700 Received: from [192.168.117.80] ([192.168.117.80]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 10:45:39 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] TCP Reassembly Timer Date: Wed, 25 Apr 2007 12:45:37 -0500 To: Vishal Study X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Apr 2007 17:45:39.0831 (UTC) FILETIME=[89E37070:01C78761] X-Spam-Score: 0.1 (/) 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: , Errors-To: tcpm-bounces@ietf.org A TCP is free to throw away any out-of-order segments that it has received. They have not yet been acknowledged, so the sender is responsible for keeping copies and resending them. SACK is not a hard acknowledgment, so even packets that have been SACKed can be tossed. Of course, the connection will slow down waiting for the dropped packets to be retransmitted, but I guess the connection is already running slow waiting for missing packets. :-) Various BSD based implementations have implemented tcp_drain() functions that go through and flush all the TCP resequencing queues. I see no reason to have a timer on the resequencing queue, the regular TCP timers should take care of dropping non-responsive connections. Providing a tcp_drain() type function that gets called when resources are low should be sufficient. (Though in practice, I've observed that when memory gets that low, something is hogging all the memory and anything that gets freed up is immediately sucked up by the errant process...) -David Borman On Apr 25, 2007, at 12:18 PM, Vishal Study wrote: > Hi: > > Is there an RFC/draft that talks about TCP Reassembly timer? > > Scenario: > Host begins to receive out of order pkts and enqueues them in its > RX_Q. If there are lot of sessions that are stuck in such state (with > out of order pkts), the system can go down on resources (memory). > > Does any standard/RFC talk about what should be the expected behavior? > > I know there are implementations that have a Reassembly timer and they > either drop the session or (atleast) drop out of order pkts when the > Reassembly timer kicks off. > > Any pointers... > > Thanks in advance, > Vishal. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Apr 25 14:43: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 1HgmSh-0003Kk-Gf; Wed, 25 Apr 2007 14:43:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgmSg-0003HS-7V for tcpm@ietf.org; Wed, 25 Apr 2007 14:43:30 -0400 Received: from lion.bbn.com ([128.89.80.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgmSd-0007FH-V9 for tcpm@ietf.org; Wed, 25 Apr 2007 14:43:30 -0400 Received: from [IPv6:::1] (localhost [IPv6:::1]) by lion.bbn.com (8.13.3/8.12.11) with ESMTP id l3PIhEd3020563; Wed, 25 Apr 2007 14:43:15 -0400 (EDT) Message-ID: <462FA142.5080904@bbn.com> Date: Wed, 25 Apr 2007 14:43:14 -0400 From: "Armando L. Caro, Jr." User-Agent: Mail/News 1.5.0.4 (X11/20060606) MIME-Version: 1.0 To: Sally Floyd Subject: Re: [tcpm] Adding Acknowledgement Congestion Control to TCP References: <07e0ad60d97a8cef94c214554aee0658@mac.com> In-Reply-To: <07e0ad60d97a8cef94c214554aee0658@mac.com> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=A9CE816E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: David Ros , tcpm , =?ISO-8859-1?Q?Andr=E9s_Arcia?= , Janardhan Iyengar 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 like the idea of attempting to separate forward and reverse path congestion. I've been thinking about this problem off and on for some time now, but haven't worked out a detailed solution. In essence, I'd like for ack losses to not affect throughput on the forward path. However, I think the motivation of this draft is slightly different. It seems to be purely motivated by doing proper congestion control in both directions, right? Have their been any studies that show that pure acks are a source of congestion (that we should worry about)? I would expect them to be noise in the bigger scheme of things. Personally, I have never thought of them contributing to congestion too much, but have instead been more concerned with them being affected by the congestion around them. Asymmetric links (eg, DSL and cable) often see this problem: traffic on an uncongested downlink gets a performance hit when the uplink becomes congested. I'm concerned that reducing the number of acks when ack losses occur is likely to make the problem worse. I would add this issue to the list of "possible complications". I realize that this is a preliminary investigation, but has anyone experimented with this proposal. I'd be interested in seeing the results. Some other comments: Re: Section 5.7. Appropriate byte counting allows the cwnd to be increased by the number of bytes being acked, but there is a cap. Each ack may increase the cwnd by at most 2*MSS. Thus, an ACK Ratio > 2 will slow down cwnd growth during slow start. So the text should point to ABC as guidance, but state that you are now proposing to break that cap and use rate limiting to mitigate the bursts. I like the list of possible complications. Except for the one I pointed out above, I think you hit all the issues I thought of as I read the draft. Thanks! -- Armando www.armandocaro.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Apr 26 10:31:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh4zx-0001Tg-B4; Thu, 26 Apr 2007 10:31:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh4zu-0001PP-OF; Thu, 26 Apr 2007 10:31:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh4zu-00076S-4i; Thu, 26 Apr 2007 10:31:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id AB74F26EB6; Thu, 26 Apr 2007 14:31:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hh4zt-0003Dt-Jd; Thu, 26 Apr 2007 10:31:01 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 26 Apr 2007 10:31:01 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tcpm chair , tcpm mailing list , Internet Architecture Board , RFC Editor Subject: [tcpm] Document Action: 'Defending TCP Against Spoofing Attacks' to Informational RFC 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 The IESG has approved the following document: - 'Defending TCP Against Spoofing Attacks ' as an Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-06.txt Technical Summary This document is a description of the sorts of off-path spoofing attacks that TCP is vulnerable to and the various existing proposed mitigations of those attacks. It is a fairly detailed discussion of the attacks and forms a good basis for addressing the problems in TCP as well as starting the discussion for other protocols. More practically, it can be used by designers and implementors to decide which of these strategies are appropriate for their situation. Working Group Summary The draft came in to being primarily because the author was concerned that a new draft addressing these vulnerabilities did not adequately address prior work or present alternatives to that draft's solutions. Eventually, those concerns were separated into this draft, which the group believes has pedagogical and practical value. Document Quality The document has been endorsed by the working group as being complete and well written pretty universally. Personnel Document Shepherd: Ted Faber Responsible AD: Lars Eggert Note to RFC Editor On page 8, replace: 57,000 RSTs with suitably spaced sequence number guesses with: 57,000 RSTs with suitably spaced sequence number guesses within one round trip time On page 9, Fig 2, replace the heading: BW*delay with: Receive Buffer Size _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 27 03:34:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhKxx-0000W3-6Y; Fri, 27 Apr 2007 03:34:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhKxv-0000Vw-L1 for tcpm@ietf.org; Fri, 27 Apr 2007 03:34:03 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhKxt-0004lE-Tg for tcpm@ietf.org; Fri, 27 Apr 2007 03:34:03 -0400 Received: from [139.133.207.156] (dhcp-207-156.erg.abdn.ac.uk [139.133.207.156]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l3R7XVbh003560; Fri, 27 Apr 2007 08:33:31 +0100 (BST) Message-ID: <4631A74B.7000104@erg.abdn.ac.uk> Date: Fri, 27 Apr 2007 08:33:31 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org, fernando@gont.com.ar Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gf@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Gorry Fairhurst , Ted Faber , "mallman@icir.org" Subject: [tcpm] WGLC: TCP's Reaction to Soft Errors X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Review of: draft-ietf-tcpm-tcp-soft-errors-05.txt I think this documents an important issue that has been around for some time and would like to support this progression for publication as an informational RFC. It is disappointing that the IETF could not reach consensus on this issue (I would have liked to have seen that happen), notwithstanding this, it seem to me to be very worthwhile to document what is implemented and offer guidance that relates it to existing specifications. IMHO, we should publish this. Best wishes, Gorry --- Questions: 1) What happens if the SYN segment contains IP or TCP options that a middlebox rejects (and issues an ICMP error code)... if we take the variation of the algorithm, does it imply the sender tries a new IP address, or that it retries with a different option combination? Are there any side effects from this? 2) Normally TCP backs off its timer each SYN it sends for the same connection. Does this imply that the sender still backs-off the timeout value when it retries with a different IP address, or does it just start with the initial time-out value? - In cases where there is congestion or very long network path delays this could impact stability? or even prevent setting up the connection is specific topologies? 3) I do not understand this sentence, can you clarify?: /([Shneiderman] and [Thadani] offer some insight into the interactive systems)./ Editorial comments: ------------ - the abstract is hard to parse: " This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages received in any of the non-synchronized states, that rejects connections experiencing those errors immediately. " I find the first line of abstract a little hard to unravel. The problem part is /that rejects connections experiencing those errors immediately/ " This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages. This immediately rejects connections that receive soft errors in any non-synchronized state. ------------ Section 2 --- Suggest change: /Even though ICMPv6 didn't/ to /Even though ICMPv6 did not/ --- /one could extrapolate the concept of soft errors to ICMPv6/ ^ - Insert a reference - to RFC2463? --- Suggest change: / that's not signaled / to / that is not signaled / --- /to corresponding TCP instance/ ^ - Insert "the" --- Suggest change: /won't change in/ to /will not change in/ --- Suggest change: / before trying alternate addresses./ to / before trying an alternate address./ --- Suggest change: / A particular scenario in which the above sketched type of problem may occur regularly is that where dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments, and the IPv6 connectivity is non-existent/ to / Dual stack nodes represent a case where the type of problem outlined above may regularly occur. This arise when a dual stack node with IPv6 enabled by default is deployed in an IPv4 or a mixed IPv4 and IPv6 environments, and the IPv6 connectivity is non-existent./ --- /Unreachability Detection (NUD)/ ^ - Insert reference. --- Section 6.1 /IP addresses in the list/ ^^^^^^^^^^ - The list has not been mentioned previously in this section. ----- Suggest change: /attack---even if only slightly/ to: /attack, even if only slightly/ --- The suggestion of making a table in section 2, noting the set of error codes in IPv4 and IPv6 ICMP messages seems a usrful additional, which I would encourage. --- Finally in rev-03, I commented that "I see this document is INFO - yet it seems to include an RFC2119 declaration, and does not use keywords." I was concerned that the document did NOT make BCP-Style recommendations. However, I now realise that you do cite keywords, which presumably should be interpretted as per RFC2119. A note to this effect would be OK. (I'm confessing that I may have previously given you wrong advice). _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 27 04:40:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhLzs-0007A4-8d; Fri, 27 Apr 2007 04:40:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhLzr-000762-9f for tcpm@ietf.org; Fri, 27 Apr 2007 04:40:07 -0400 Received: from [2001:660:7301:3192:211:43ff:fea3:7e4b] (helo=laposte.rennes.enst-bretagne.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhLzp-0001Ym-Qp for tcpm@ietf.org; Fri, 27 Apr 2007 04:40:07 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.7/8.13.7/2006.08.14) with ESMTP id l3R8df8m026796; Fri, 27 Apr 2007 10:39:41 +0200 Received: from l2.rennes.enst-bretagne.fr (l2.rennes.enst-bretagne.fr [192.44.77.4]) by laposte.rennes.enst-bretagne.fr (8.13.7/8.13.7/2007.03.20) with ESMTP id l3R8dbWm026785; Fri, 27 Apr 2007 10:39:37 +0200 Received: from [192.44.77.196] (dhcpe196.rennes.enst-bretagne.fr [192.44.77.196]) (authenticated bits=0) by l2.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id l3R8dbxU014360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Apr 2007 10:39:37 +0200 In-Reply-To: <462FA142.5080904@bbn.com> References: <07e0ad60d97a8cef94c214554aee0658@mac.com> <462FA142.5080904@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <7A91CF1B-2670-4843-87EC-F4A9B97C2CED@enst-bretagne.fr> Content-Transfer-Encoding: quoted-printable From: David Ros Subject: Re: [tcpm] Adding Acknowledgement Congestion Control to TCP Date: Fri, 27 Apr 2007 10:40:37 +0200 To: "Armando L. Caro, Jr." X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: -2.8 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: tcpm , =?ISO-8859-1?Q?Andr=E9s_Arcia?= , Janardhan Iyengar 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 Le 25 avr. 07 =E0 20:43, Armando L. Caro, Jr. a =E9crit : > I like the idea of attempting to separate forward and reverse path > congestion. I've been thinking about this problem off and on for some > time now, but haven't worked out a detailed solution. In essence, I'd > like for ack losses to not affect throughput on the forward path. > However, I think the motivation of this draft is slightly =20 > different. It > seems to be purely motivated by doing proper congestion control in =20 > both > directions, right? > Have their been any studies that show that pure acks are a source of > congestion (that we should worry about)? I would expect them to be =20 > noise > in the bigger scheme of things. Personally, I have never thought of =20= > them > contributing to congestion too much, but have instead been more > concerned with them being affected by the congestion around them. > Asymmetric links (eg, DSL and cable) often see this problem: =20 > traffic on > an uncongested downlink gets a performance hit when the uplink becomes > congested. Hi Armando, Well, my own view is that this would be useful (mostly, but not =20 necessarily) in the context of network asymmetry. I'd say that one =20 goal of ACK congestion control would be to avoid the "self-inflicted" =20= congestion due to ACKs filling up the uplink. There are probably =20 other scenarios that I'm missing now where ACK CC could be useful =20 but, again, I see network asymmetry as a motivation. > I'm concerned that reducing the number of acks when ack > losses occur is likely to make the problem worse. I would add this =20 > issue > to the list of "possible complications". > Hmm... I must be missing something, I'm not sure I see your point =20 clearly. > I realize that this is a preliminary investigation, but has anyone > experimented with this proposal. I'd be interested in seeing the =20 > results. > We should start a simulation study Really Soon Now (Andr=E9s is =20 currently coding the stuff in ns-2). Thanks a lot for the feedback! David. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 27 23:33: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 1HhdgN-0001HS-Qv; Fri, 27 Apr 2007 23:33:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhdgN-0001HM-9j for tcpm@ietf.org; Fri, 27 Apr 2007 23:33:11 -0400 Received: from web33312.mail.mud.yahoo.com ([68.142.206.127]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhdgL-0005qk-Tv for tcpm@ietf.org; Fri, 27 Apr 2007 23:33:11 -0400 Received: (qmail 80632 invoked by uid 60001); 28 Apr 2007 03:33:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=e6ALvrjSmdmx4tg06vk61VOMjvEZkE81m6Bi+jKiLE+ihQhbIVYbaNORsPwbWgJqnNkRRCjv0Qml64Y60tqfnqz4hLZxIfxOWQ8C5g8CJO1JKKREOZZubOf6h/wq3Vs1WzF+OHxFXGgJRr4/EqJ7zITCG/e1/r9p5AtYnL2GF7s=; X-YMail-OSG: u6AoOHMVM1l5lW_vFgX70UFKOmcuOoSU3sxGO2iJ_xc5v8l6x_DTc7z.PbKs9fXYVOvLGivpbw-- Received: from [69.236.82.206] by web33312.mail.mud.yahoo.com via HTTP; Fri, 27 Apr 2007 20:33:09 PDT Date: Fri, 27 Apr 2007 20:33:09 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors - draft-ietf-tcpm-tcp-soft-errors-05.txt To: tcpm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <346036.79493.qm@web33312.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: fernando@gont.com.ar 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 Gentlefolk, I find the document extremely useful and practical in its suggestions. I believe, the document is ready to be forwarded to the IESG. I support progressing this as informational RFC without any further delay. My 2c. regards, suresh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Apr 30 13:38: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 1HiZpq-0001iA-NG; Mon, 30 Apr 2007 13:38:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZpq-0001i5-8n for tcpm@ietf.org; Mon, 30 Apr 2007 13:38:50 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiZpp-0002rA-RU for tcpm@ietf.org; Mon, 30 Apr 2007 13:38:50 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 30 Apr 2007 10:38:49 -0700 X-IronPort-AV: i="4.14,471,1170662400"; d="scan'208"; a="482429249:sNHT50525658" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3UHcnvF009754; Mon, 30 Apr 2007 10:38:49 -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 l3UHclMF000054; Mon, 30 Apr 2007 17:38:47 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 10:38:47 -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] strength of tcpsecure recommendation Date: Mon, 30 Apr 2007 10:38:46 -0700 Message-ID: <13D1EAB852BE194C94773A947138483D036A4AC5@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20070403201007.85DAE1C3901@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] strength of tcpsecure recommendation Thread-Index: Acd2LskevLZ6L3h7T/WcEJ4le/aogQVHmwKw From: "Mitesh Dalal \(mdalal\)" To: , X-OriginalArrivalTime: 30 Apr 2007 17:38:47.0057 (UTC) FILETIME=[67EBE010:01C78B4E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3138; t=1177954729; x=1178818729; c=relaxed/simple; s=sjdkim2002; 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]=20strength=20of=20tcpsecure=20recommendation |Sender:=20; bh=WUByrtrilIM6FP7e1pTqRqFyWzEPvAkmPXhsDdChPxo=; b=kln8W2FWtsmuRjDiVm8zfFcfbrxzgSBqD3krC4ICfDa8PY5UhlRzKpa3UBqTtrorjdRxzYzN 6CyiwHzki+Z4irMCL/2ZUmoVi/1y8ghcguonAf+MJYMZscCHoozsp35m; Authentication-Results: sj-dkim-2; header.From=mdalal@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 It would have been great if fresh set of inputs were received on this, rather than have the same set of people discuss this topic :) but since there are no replies, lets see if we can get this to=20 jumpstart (again!) Please see inline. =20 > -----Original Message----- > From: Mark Allman [mailto:mallman@icir.org]=20 > Sent: Tuesday, April 03, 2007 1:10 PM > To: tcpm@ietf.org > Subject: [tcpm] strength of tcpsecure recommendation >=20 > =20 > Folks- >=20 > I'd like to try to be a bit systematic about figuring out how=20 > to proceed with the tcpsecure i-d and so I have cooked a poll=20 > below. The essential questions on the table is the=20 > mitigations ought to be labeled as SHOULD or MAY and whether=20 > these labels ought to be conditioned or not. >=20 > We have had some good conversation on the topic and lots of=20 > points have been aired (how baked these solutions are, IPR,=20 > cost v. benefit, etc.). > So, I am asking that the answers to the following questions=20 > be succinct and not rehash a bunch of previous argument. If=20 > you feel you have a > **new** point then that is clearly fine. >=20 > I am trying to get a good read of the WG here and so even if=20 > you have clearly aired opinions before, please take the=20 > minute and answer these questions. >=20 > (Note that SHOULD and MAY are clearly not the only choices. =20 > If you want to vote for MUST or MUST NOT then that is fine,=20 > even though they are not listed as choices below. If you do,=20 > please then do provide some > justification.) >=20 > The questions then ... >=20 > (1) (a) Do you believe the draft should allow the "blind reset attack > using the RST bit" mitigation described in section 3 of the > document as a SHOULD or a MAY? SHOULD. This issue has sufficent risk to require a SHOULD.=20 > (b) Should we apply a condition to the recommendation? If so, > please state the condition you'd like to see very succinctly. >=20 unconditional. SHOULD in itself leaves sufficient leeway. However, if there are precedents of conditionally defining a requirement, than maybe we can consider an alternate, MUST for routers and MAY for everbody else. > (2) (a) Do you believe the draft should allow the "blind reset attack > using the SYN bit" mitigation described in section 4 of the > document as a SHOULD or a MAY? >=20 > (b) Should we apply a condition to the recommendation? If so, > please state the condition you'd like to see very succinctly. =20 SYN has the same repercussions as the RST bit and hence same comments as in 1 above. > (3) (a) Do you believe the draft should allow the "blind data=20 > injection > attack" mitigation described in section 5 of the document as a > SHOULD or a MAY?=20 >=20 > (b) Should we apply a condition to the recommendation? If so, > please state the condition you'd like to see very succinctly. > This is fairly benign. Would prefer SHOULD but ok to go with either if that will lead to consensus.=20 =20 Thanks Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Apr 30 14:17: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 1HiaQw-0000DX-9o; Mon, 30 Apr 2007 14:17:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiaQu-00009K-2z; Mon, 30 Apr 2007 14:17:08 -0400 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiaQt-0003kA-HI; Mon, 30 Apr 2007 14:17:08 -0400 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l3UIH0T6019423; Mon, 30 Apr 2007 11:17:00 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 11:16:59 -0700 Received: from [192.168.117.80] ([192.168.117.80]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 11:17:00 -0700 In-Reply-To: <20070406211624.DF8781C8DBC@lawyers.icir.org> References: <20070406211624.DF8781C8DBC@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <31BB1FDE-1577-4069-BF40-5C3732FA1CF4@windriver.com> Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] Extending RFC 1323 window scaling? Date: Mon, 30 Apr 2007 13:16:57 -0500 To: mallman@icir.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 Apr 2007 18:17:00.0448 (UTC) FILETIME=[BEE39200:01C78B53] X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tcpm@ietf.org, tsvwg@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 (Catching up on some old email...) On Apr 6, 2007, at 4:16 PM, Mark Allman wrote: > >> (1) The semantics of the SEG.WND field in the TCP header could be >> changed, i. e., the receive window is scaled in >> segments under some constraints. Whether or not the receive >> window is scaled could be announced explicitly by a flag, or >> implicitly, e. g., due to the presence of Quick-Start >> options or >> other options. However, changing the semantics of the receive >> window header field creates interoperation issues with hosts >> that do not implement such a modification. >> >> (2) The true amount of free buffer space is announced somehow, and >> overwrites the (unscaled) value in the TCP header, which >> remains >> unscaled in order to be compatible with hosts that do not >> implement this mechanism. This requires some new mechanism to >> signal a scaled receive window in segments. >> >> The proposed new TCP option is a straightforward realization of >> approach (2). > > I am not sure if we need a (2). As you note, Quick-Start is currently > the only thing that really runs into a problem and maybe something > else > could. To be precise, I think we can say that the only place where > this > is a problem is when the initiator of a connection wants to (and can) > send more than 64KB in the first RTT of the connection. Unless we > pretty drastically change the rules it seems that this is going to > have > to be done only with some explicit communication and so using that > as an > implicit signal seems fine to me. (We clearly botched this in > terms of > Quick-Start because we were too dumb to think of it and you found it > after publication.) Further, it is not clear that we need to add new > functionality like this for something experimental (Quick-Start). > But, > maybe ... > > If I were going to take approach (2) I would suggest a two-byte option > that indicates the value in the standard TCP header is to be scaled. > Why add another 2 byte window value when one of them is going to be > ignored? This fails safe because if a host doesn't understand the new > ("the window is scaled") option it will think the advertised window is > unscaled and so less than it really is and so there is no danger in > running into problems. I'm not sure I agree. Yes, it's safe in that if you treat a scaled window as unscaled, you will not send more data than they are willing to receive. But if the shift value is large enough, and the initial window small enough, you can get a tiny initial window. E.g., an extreme case, if your initial window is 256K, but you have a shift value of 14, that'll become a window of 16 bytes, not enough to send much of anything until you get a window update. An alternate way of dealing with this situation where the initial window exceeds 64K would be to immediately follow the SYN,ACK with a window update; send the two packets out back-to-back. (Has this already been mentioned?) That would mean that Quick-start wouldn't be able to fully act just on the SYN,ACK, but should immediately get the window update with the right value, without having to wait for a full RTT. The only down-side would be if the two packets got re- ordered, and the ACK with the window update arrived before the SYN,ACK. In that case, the window update would be (and should be) dropped, because at a minimum, the scale factor that should be applied to it would be unknown (it's in the SYN,ACK). So, a TCP implementation might need to still send out another window update when it got back the ACK completing the 3-way handshake, just to be sure that the window update got through. -David Borman > > allman > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm