From iana-shared@icann.org Mon Jan 4 10:56:59 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5395B3A6877 for ; Mon, 4 Jan 2010 10:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.938 X-Spam-Level: *** X-Spam-Status: No, score=3.938 tagged_above=-999 required=5 tests=[FH_DATE_PAST_20XX=10.357, MISSING_HEADERS=1.581, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHJVNma50b54 for ; Mon, 4 Jan 2010 10:56:58 -0800 (PST) Received: from request.iana.org (request.iana.org [208.77.188.221]) by core3.amsl.com (Postfix) with ESMTP id A0C8B3A6826 for ; Mon, 4 Jan 2010 10:56:58 -0800 (PST) Received: from request.iana.org (localhost.localdomain [127.0.0.1]) by request.iana.org (8.13.8/8.13.8) with ESMTP id o04Ittxk004510 for ; Mon, 4 Jan 2010 10:55:55 -0800 Received: (from apache@localhost) by request.iana.org (8.13.8/8.13.8/Submit) id o04IttB8004509; Mon, 4 Jan 2010 10:55:55 -0800 From: "Amanda Baber via RT" In-Reply-To: References: <002001ca87e7$1885d6a0$0601a8c0@allison> <4B390173.4070003@isi.edu> <02a701ca8a3c$a6b79380$0601a8c0@allison> <4B3CEEF6.4040006@isi.edu> <4B3CF48A.8050103@gmail.com> <4B3D08C3.5070509@isi.edu> <4B3D3926.1000105@gmail.com> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #289079 Managed-by: RT 3.8.3pre1 (http://www.bestpractical.com/rt/) RT-Originator: amanda.baber@icann.org Cc: tcpm@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Mon, 4 Jan 2010 18:55:55 +0000 X-Mailman-Approved-At: Tue, 05 Jan 2010 07:57:21 -0800 Subject: [tcpm] [IANA #289079] unallocated TCP options in-use X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Reply-To: iana-matrix@iana.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2010 18:56:59 -0000 Hi William, We sent this response to your request on November 25th: This registry requires IESG Approval or Standards Action, so we can't take any action yet. Let us know when your draft has been posted, and we'll ask the IESG to review it and approve the assignments. Please note that we can't guarantee that these numbers won't be assigned in the interim. Amanda Baber IANA > Joe Touch wrote: > > IANA also has requirements for assignments - for TCP options, they are > > IESG approval or standards action. > > > > Has either gone through either process? If not, then these too would be > > unauthorized use. > > > You asked about a 5th option, I'm merely pointing you to the current > process (which wasn't covered in the 4 options given). > > Since it is IANA's process, I'm assuming that when we fill out their > form, they send the assignment along to IESG for pro forma approval. > IANA is a collector of information, not an "authorizer" per se. > > As to the latter, this thread is about non-working-group actions, thus > not standards action (by definition). > > If having been informed, IANA fails to handle the processing, then > that's not my problem (nor Cisco's nor anybody else). Does anybody know > whether Cisco bothered to submit the assignment form? > > I do remember MicroSoft, during their embrace and extend days, refused > to even inform IANA or anybody about protocol numbers they were > self-assigning. That lead to conflicts. > > My only interest is avoiding assignment conflicts. > -- > Happy New Year > From lars.eggert@nokia.com Tue Jan 5 08:20:41 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0268B28C112 for ; Tue, 5 Jan 2010 08:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSvVWl9J8Fbj for ; Tue, 5 Jan 2010 08:20:40 -0800 (PST) Received: from smtp.tele.fi (smtp.tele.fi [192.89.123.25]) by core3.amsl.com (Postfix) with ESMTP id E36B03A688D for ; Tue, 5 Jan 2010 08:20:39 -0800 (PST) X-Originating-Ip: [212.213.221.241] Received: from host-241.nrln.net (host-241.nrln.net [212.213.221.241]) by smtp.tele.fi (Postfix) with ESMTP id 2ACD5BDC for ; Tue, 5 Jan 2010 18:20:22 +0200 (EET) Received: from mail.fit.nokia.com ([212.213.221.40]) by host-241.nrln.net (Lotus Domino Release 6.5) with ESMTP id 2010010518262571-5319 ; Tue, 5 Jan 2010 18:26:25 +0200 Received: from [10.0.1.5] (cs95024.pp.htv.fi [212.90.95.24]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id o05GJdVA014234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 5 Jan 2010 18:20:15 +0200 (EET) (envelope-from lars.eggert@nokia.com) From: Lars Eggert Mime-Version: 1.0 (Apple Message framework v1077) Date: Tue, 5 Jan 2010 18:20:14 +0200 In-Reply-To: <4B3D3926.1000105@gmail.com> To: "tcpm@ietf.org WG" References: <002001ca87e7$1885d6a0$0601a8c0@allison> <4B390173.4070003@isi.edu> <02a701ca8a3c$a6b79380$0601a8c0@allison> <4B3CEEF6.4040006@isi.edu> <4B3CF48A.8050103@gmail.com> <4B3D08C3.5070509@isi.edu> <4B3D3926.1000105@gmail.com> Message-Id: <08BCDDDC-AD07-430D-85C1-76C2D40F6189@nokia.com> X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Tue, 05 Jan 2010 18:20:15 +0200 (EET) X-MIMETrack: Itemize by SMTP Server on host-241/srv/nrln(Release 6.5|September 26, 2003) at 01/05/2010 06:26:25 PM, Serialize by Router on host-241/srv/nrln(Release 6.5|September 26, 2003) at 01/05/2010 06:26:40 PM, Serialize complete at 01/05/2010 06:26:40 PM Content-Type: multipart/signed; boundary=Apple-Mail-49-933373328; protocol="application/pkcs7-signature"; micalg=sha1 Subject: Re: [tcpm] [IANA #290479] unallocated TCP options in-use X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 16:20:41 -0000 --Apple-Mail-49-933373328 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [Resending; hasn't made it to the list yet. Probably due to the = spamassassin issue that is hitting everyone right now.] Hi, On 2010-1-1, at 1:52, William Allen Simpson wrote: > For some odd reason, my previous message was assigned a number, so I'm > including it in the subject. this is because you CC'ed the IANA ticket system at iana@iana.org (which = I have dropped from the CC). On 2009-12-31, at 20:59, William Allen Simpson wrote: > BTW, I'm using: >=20 > 31 (0x1f) TCP Cookie Transactions > 32 (0x20) 64-bit Timestamps >=20 > Make a note of it. > Joe Touch wrote: >> Has either gone through either process? If not, then these too would = be >> unauthorized use. >>=20 > Since it is IANA's process, I'm assuming that when we fill out their > form, they send the assignment along to IESG for pro forma approval. > IANA is a collector of information, not an "authorizer" per se. This is not the case. It is true that IANA is not an "authorizer", but = that does not mean that TCP Option Numbers are assigned without = authorization. RFC2780 Section 9.3 is *very* clear that TCP Option Numbers are only = assigned after a Standard Action (i.e., a standards-track RFC published = through the IETF process) or IESG Approval. The latter is very unusual = (i.e., by no means "pro forma") and the IESG will carefully evaluate any = such request. See RFC2434 for details. There is no other way to register = a TCP Option Number. > As to the latter, this thread is about non-working-group actions, thus > not standards action (by definition). It is not possible to register a TCP Option without a Standards Action = or IESG Approval. > If having been informed, IANA fails to handle the processing, then > that's not my problem (nor Cisco's nor anybody else). That is incorrect. You seem to assume that TCP Option Numbers are = assigned after the "First Come First Served" policy in RFC2434, which is = not the case. Lars= --Apple-Mail-49-933373328 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDEwNTE2MjAxNVowIwYJKoZIhvcNAQkEMRYEFBl46YpooKMFgBvd4bgLRpHEsi5EMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBdT0B49fjoZdobg2AkNdvJc44DETr+kbNBuX3R6/0Ox+ERDlzp40rSK/xkAz4pDzW22lLC WAdRujwvtiZOjqU6r2hC4GeuaGF5b2FqTApWodV+jtk6DTqB/CG+QL5tWdkM7VdclSI4YhlYQ87C HakE/QRubvfcVSgBKXF2QuSb2Il60oybs5AcILpNmASdcE2D/eDQX5JE9lJ/mTOlrEi0u1ZVkps3 S7kPKjok2EtOxBvTZROYWoyrtYBtEh1Virtp9OihtBufbQEuB6aC0l4HEUVLjp7HDESJJehmEiym w4icb1eTeFtj8GHCqFKoWrJqA5+aoyOPoGXaQofkV15TAAAAAAAA --Apple-Mail-49-933373328-- From mahesh@cisco.com Fri Jan 8 12:53:08 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509063A6859 for ; Fri, 8 Jan 2010 12:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUHR38zC-HdI for ; Fri, 8 Jan 2010 12:53:07 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 10E583A67C0 for ; Fri, 8 Jan 2010 12:53:07 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAHIqR0urRN+K/2dsb2JhbACDXr1ChwCNB4NZVgQ X-IronPort-AV: E=Sophos;i="4.49,244,1262563200"; d="scan'208,217";a="130564425" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 08 Jan 2010 20:53:05 +0000 Received: from [10.21.50.21] ([10.21.50.21]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o08Kr5hO017998 for ; Fri, 8 Jan 2010 20:53:05 GMT Message-ID: <4B479B2F.1000304@cisco.com> Date: Fri, 08 Jan 2010 12:53:03 -0800 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: multipart/alternative; boundary="------------080103040200080107050101" Subject: [tcpm] New Version Notification for draft-ananth-tcpm-persist-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 20:53:08 -0000 This is a multi-part message in MIME format. --------------080103040200080107050101 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit This version of the draft is about clarifying the intent of RFC 1122. We have all agreed in our mail exchange that the language in RFC 1122 if interpreted literally can cause implementations to become vulnerable. Previous references to possible implementations/solutions that caused quite a bit of confusion have been removed. It incorporates feedback that we received on examples of when it does make sense to keep connections in persist state. A good example of that is the lpd daemon. This draft also adds a reference to a CERT vulnerability note that was published recently. http://www.ietf.org/id/draft-ananth-tcpm-persist-02.txt ------------------------------------------------------------------------------- Filename: draft-ananth-tcpm-persist Revision: 02 Title: Clarification of sender behaviour in persist condition. Creation_date: 2010-01-08 WG ID: Independent Submission Number_of_pages: 11 Abstract: This document attempts to clarify the notion of the Zero Window Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. The motivation for this document stems from the belief that TCP implementations strictly adhering to the current RFC language have the potential to become vulnerable to Denial of Service (DoS) scenarios. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 12, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. The IETF Secretariat. -- Mahesh Jethanandani --------------080103040200080107050101 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit This version of the draft is about clarifying the intent of RFC 1122. We have all agreed in our mail exchange that the language in RFC 1122 if interpreted literally can cause implementations to become vulnerable. Previous references to possible implementations/solutions that caused quite a bit of confusion have been removed.

It incorporates feedback that we received on examples of when it does make sense to keep connections in persist state. A good example of that is the lpd daemon.

This draft also adds a reference to a CERT vulnerability note that was published recently.

http://www.ietf.org/id/draft-ananth-tcpm-persist-02.txt
-------------------------------------------------------------------------------
Filename:	 draft-ananth-tcpm-persist
Revision:	 02
Title:		 Clarification of sender behaviour in persist condition.
Creation_date:	 2010-01-08
WG ID:		 Independent Submission
Number_of_pages: 11



Abstract:
This document attempts to clarify the notion of the Zero Window
Probes (ZWP) described in RFC 1122 [RFC1122].  In particular, it
clarifies the actions that can be taken on connections which are
experiencing the ZWP condition.  The motivation for this document
stems from the belief that TCP implementations strictly adhering to
the current RFC language have the potential to become vulnerable to
Denial of Service (DoS) scenarios.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 12, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the
document authors.  All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
                                                                                  


The IETF Secretariat.

--
Mahesh Jethanandani
--------------080103040200080107050101-- From A.Hoenes@TR-Sys.de Sun Jan 10 12:11:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6611728C116 for ; Sun, 10 Jan 2010 12:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.672 X-Spam-Level: * X-Spam-Status: No, score=1.672 tagged_above=-999 required=5 tests=[AWL=-1.438, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPgoGf1slt0y for ; Sun, 10 Jan 2010 12:11:38 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id A812528C111 for ; Sun, 10 Jan 2010 12:11:37 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA160324287; Sun, 10 Jan 2010 21:11:27 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA05760; Sun, 10 Jan 2010 21:11:26 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201001102011.VAA05760@TR-Sys.de> To: tcpm@ietf.org Date: Sun, 10 Jan 2010 21:11:25 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] New Version Notification for draft-ananth-tcpm-persist-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2010 20:11:41 -0000 At Fri, 08 Jan 2010 12:53:03 -0800, Mahesh Jethanandani wrote: > This version of the draft is about clarifying the intent of RFC 1122. > We have all agreed in our mail exchange that the language in RFC 1122 > if interpreted literally can cause implementations to become vulnerable. > Previous references to possible implementations/solutions that caused > quite a bit of confusion have been removed. > > It incorporates feedback that we received on examples of when it does > make sense to keep connections in persist state. A good example of that > is the lpd daemon. > > This draft also adds a reference to a CERT vulnerability note that was > published recently. 1,$s!.*!This version refreshes the -01 after expiry without changes.! Apparently a time journey or replay attack; the announcement text replicates the announcement once sent for the -01 version. :-) BR, Alfred. From ananth@cisco.com Sun Jan 10 23:02:44 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708AE3A68B4 for ; Sun, 10 Jan 2010 23:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzBPhEHjraFv for ; Sun, 10 Jan 2010 23:02:43 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2DA4F3A67D7 for ; Sun, 10 Jan 2010 23:02:43 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADNcSkurR7Hu/2dsb2JhbADCA4kGCIlbgj8IgWgE X-IronPort-AV: E=Sophos;i="4.49,255,1262563200"; d="scan'208";a="286761175" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 11 Jan 2010 07:02:41 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0B72f2V001711; Mon, 11 Jan 2010 07:02:41 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.3959); Sun, 10 Jan 2010 23:02:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Jan 2010 23:02:38 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5808AA86F6@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: draft-ietf-tcpm-tcpsecure Thread-Index: AcpIM+KRhLtCPJKrQhiJplZ9mOFElhKVD4IQ References: <20091008003703.885C93A684E@core3.amsl.com> <0C53DCFB700D144284A584F54711EC58082480D6@xmb-sjc-21c.amer.cisco.com> From: "Anantha Ramaiah (ananth)" To: "Cullen Jennings (fluffy)" , "Lars Eggert" X-OriginalArrivalTime: 11 Jan 2010 07:02:41.0004 (UTC) FILETIME=[10E59AC0:01CA928C] Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org, draft-ietf-tcpm-tcpsecure@tools.ietf.org Subject: Re: [tcpm] DISCUSS: draft-ietf-tcpm-tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 07:02:44 -0000 =20 Hi, I am forwarding [sorry about the long delay] these comments received during IESG review ( as suggested by Lars) to get some feedback from TCPM. The suggestion below from Cullen is to add more text to the middle-box section and also add some notes to the AS. [ Pl refer below] My comments here are : [ you can find them inside the email responses below, but listed here in brief ] - We have alreaady have mentioned the challenges that middle-boxes pose, this is not just limited to the current RFC, RFC TCP-MD5 or TCP-AO has issues and list can go on. So what we currently have is enough, IMO. But I am also ok to write more text as suggested by Cullen. If there is a consensus from the list I can go update the document. If that is the case I would like to qualify the NATs/Firewalls as "the NAT/Firewalls which doesn't account the tcp-secure changes" [FWIW, the Cisco Firewalls, esp IOS based ones have these fixes in place for a long time] - Regarding the case of a server opening closing connections at a rapid rate implies "short-lived" connections. The document currently says that these mitigations can be very useful in case of long lived connections, short-lived connections may or may not want to implement this. So my thinking is that the current text gives more flexibility for implementers to chose what they want to do, they can have a socket option to turn these mitigations to select ports etc., In case of where the connections are made/broken at a rapid rate, there are other problems that come into play : for example the port collisions happening because the TCB in the server is stuck in the TIMEWAIT state and that causes denying the incoming connection. The orthogonal and somewhat important point is that to note is that typically cleanup involves a client sending an FIN and not RST, sending RST has many other issues and should be used with caution and that typically happens today in implementations. So, I am not really sure about adding a text that says "a server should not be doing that" Comments welcome. -Anantha > -----Original Message----- > From: Cullen Jennings (fluffy)=20 > Sent: Thursday, October 08, 2009 9:25 AM > To: Cullen Jennings (fluffy); Anantha Ramaiah (ananth); Lars Eggert > Cc: tcpm-chairs@tools.ietf.org;=20 > draft-ietf-tcpm-tcpsecure@tools.ietf.org > Subject: Re: DISCUSS: draft-ietf-tcpm-tcpsecure=20 >=20 >=20 > We talked about this issues on the IESG call and I'd like to=20 > propose the following plan >=20 > 1) Update the middle-box section to explain there are some=20 > cases with some existing firewalls/nats that causes the ACK=20 > approach to not work. =20 > Could even encourage >=20 > 2) in the applicability section, add a bit that says about=20 > when a server should not do this. I would something along=20 > lines of some server that are not severely impacted by an=20 > attacker closing a connection, and where the number of=20 > connections requires rapid clean up of state. So certainly a=20 > BGP should do this but a server such as some web servers=20 > where state of TCP connections is an issue and an attacker=20 > killing a connecting is not a big deal as it will just be=20 > redone and it often hard to guess the source port. >=20 > Would a plan along these lines be acceptable for folks? >=20 >=20 > On Oct 7, 2009, at 9:05 PM, Cullen Jennings wrote: >=20 > > > > Thank you both for info. Do you know what the small residential NATs > > (linksys/netgear/dlink) stuff do? I know I could go test - I have a=20 > > few boxes full of them here but uh, too much email to read=20 > to get to=20 > > work doing testing :-) > > > > Updating the middle-box section to talk about this might be a good=20 > > idea but don't worry about doing anything yet - I'm still=20 > getting up=20 > > to speed on what the issues are here and once I understand=20 > it I hope=20 > > it is all just a non issue. > > > > > > On Oct 7, 2009, at 7:57 PM, Anantha Ramaiah (ananth) wrote: > > > >> Cullen, > >> Adding to what Randy said in the other email : (pl see inline > >> comments) > >> > >>> -----Original Message----- > >>> From: Cullen Jennings (fluffy) > >>> Sent: Wednesday, October 07, 2009 5:37 PM > >>> To: iesg@ietf.org > >>> Cc: tcpm-chairs@tools.ietf.org; > >>> draft-ietf-tcpm-tcpsecure@tools.ietf.org > >>> Subject: DISCUSS: draft-ietf-tcpm-tcpsecure > >>> > >>> Discuss: > >>> > >>> I have a question about the applicability of this that=20 > I'd like to=20 > >>> understand the answer to before trying to answer the "updates"=20 > >>> question Lars raised. Imagine we have a client C, talking=20 > from the=20 > >>> "inside" of a firewall that tracks TCP state, to a server=20 > S on the=20 > >>> "outside" of the firewall. If C sends a RST, the firewall=20 > forwards=20 > >>> it and clears state, but when the RST arrives at S. The=20 > reset seq #=20 > >>> is within the window but not exact. S sends and ACK, but=20 > (this is my=20 > >>> question), will the firewall forward the ACK to C or just=20 > silently=20 > >>> drop it? > >> > >> Good question, atleast IOS firewalls have fixed this in their code=20 > >> for what I can recall ( I can double check if interested=20 > since it has=20 > >> been a long time when that event happened!). If this RFC becomes a=20 > >> standard other firewall vendors would also implement this fix I=20 > >> suppose. > >> The inter-op what we did included teams within Cisco and outside=20 > >> (Juniper, QNX etc., ), the focus was on fixing the host behaviour,=20 > >> not the middle-boxes.. > >> > >> So, biting a bit here : if this is a general problem then=20 > every TCP=20 > >> RFC should have a column saying "middlebox compliance" ;-)=20 > Actually=20 > >> we do have a section 9 in the draft that talks about "middlebox=20 > >> considerations" Do you think some more text that needs to be added=20 > >> there? > >> > >> Firewalls could also do the proxy i.e, send an RST for the=20 > incoming=20 > >> ACK if no flow exists releiving the end host to do this function,=20 > >> FWIW. > >> > >>> > >>> I know some firewalls might have the timers to forward=20 > traffic for=20 > >>> some time after the RST but do they all and is it long enough? Is=20 > >>> there something I am just not understanding > >> > >> The characteristics of the timer value to use is somewhat=20 > similar to=20 > >> the TIME-WAIT value which is used on an active closer. > >> > >>> here that would cause this to work? I'm worried that servers with=20 > >>> lots of clients connecting to them not being able to recover TCP=20 > >>> connection in a timely matter might cause more harm that attacks=20 > >>> that tear down TCP connections. > >> > >> Middleboxes definetely pose challenges and that is=20 > probably true for=20 > >> not just this RFC but other existing TCP RFC's as well. > >> > >> -Anantha > >>> > >>> This is a Discuss because I want to talk to the IESG &=20 > authors about=20 > >>> it before deciding an opinion on this draft. > >>> > >>> Thanks, Cullen > >>> > >>> > >>> > > >=20 >=20 From mahesh@cisco.com Mon Jan 11 08:09:05 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D3C13A67E7 for ; Mon, 11 Jan 2010 08:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4b09ihVlAvWY for ; Mon, 11 Jan 2010 08:09:04 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5A4163A679C for ; Mon, 11 Jan 2010 08:09:04 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEACbcSkurRN+J/2dsb2JhbACDXsBuhwCMT4Ergi5WBA X-IronPort-AV: E=Sophos;i="4.49,257,1262563200"; d="scan'208";a="131465441" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2010 16:09:02 +0000 Received: from [10.21.50.86] ([10.21.50.86]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0BG92Gi023792; Mon, 11 Jan 2010 16:09:02 GMT Message-ID: <4B4B4D13.1080002@cisco.com> Date: Mon, 11 Jan 2010 08:08:51 -0800 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201001102011.VAA05760@TR-Sys.de> In-Reply-To: <201001102011.VAA05760@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-ananth-tcpm-persist-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 16:09:05 -0000 Alfred, Neither really. The draft was about to expire, we had no changes but the status of the draft was unknown. We wanted to move forward on the draft and did not want to send a link that was expiring today. Should have checked the policy on what one does under the circumstances :-[ . Alfred � wrote: > 1,$s!.*!This version refreshes the -01 after expiry without changes.! > Apparently a time journey or replay attack; the announcement text > replicates the announcement once sent for the -01 version. :-) > > BR, > Alfred. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- mj From touch@ISI.EDU Mon Jan 11 11:07:33 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05E73A6863 for ; Mon, 11 Jan 2010 11:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAhv-Lbl-2YU for ; Mon, 11 Jan 2010 11:07:32 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9C4A53A683A for ; Mon, 11 Jan 2010 11:07:32 -0800 (PST) Received: from [75.213.76.118] (118.sub-75-213-76.myvzw.com [75.213.76.118]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o0BJ4BWf011191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jan 2010 11:04:14 -0800 (PST) Message-ID: <4B4B762A.7070902@isi.edu> Date: Mon, 11 Jan 2010 11:04:10 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <20091008003703.885C93A684E@core3.amsl.com> <0C53DCFB700D144284A584F54711EC58082480D6@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC5808AA86F6@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5808AA86F6@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Cullen Jennings \(fluffy\)" , tcpm-chairs@tools.ietf.org, tcpm@ietf.org, draft-ietf-tcpm-tcpsecure@tools.ietf.org Subject: Re: [tcpm] DISCUSS: draft-ietf-tcpm-tcpsecure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 19:07:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anantha Ramaiah (ananth) wrote: > > Hi, > > I am forwarding [sorry about the long delay] these comments received > during IESG review ( as suggested by Lars) to get some feedback from > TCPM. The suggestion below from Cullen is to add more text to the > middle-box section and also add some notes to the AS. [ Pl refer below] > > My comments here are : [ you can find them inside the email responses > below, but listed here in brief ] > > - We have alreaady have mentioned the challenges that middle-boxes pose, > this is not just limited to the current RFC, RFC TCP-MD5 or TCP-AO has > issues and list can go on. I think the difference is that people expect NATs and other devices that modify TCP packets to affect any authentication mechanism (MD5, AO), but that they wouldn't expect it to affect this mechanism. I'm not sure how it would, though - what is the case they're thinking of here that would cause this to fail with a middlebox? (transparent rewriting maybe?) > - Regarding the case of a server opening closing connections at a rapid > rate implies "short-lived" connections. The document currently says that > these mitigations can be very useful in case of long lived connections, > short-lived connections may or may not want to implement this. So my > thinking is that the current text gives more flexibility for > implementers to chose what they want to do, they can have a socket > option to turn these mitigations to select ports etc., In case of where > the connections are made/broken at a rapid rate, there are other > problems that come into play : for example the port collisions happening > because the TCB in the server is stuck in the TIMEWAIT state and that > causes denying the incoming connection. The orthogonal and somewhat > important point is that to note is that typically cleanup involves a > client sending an FIN and not RST, sending RST has many other issues and > should be used with caution and that typically happens today in > implementations. So, I am not really sure about adding a text that says > "a server should not be doing that" The point of the comment focuses on the increased load due to packet exchange, not just the lack of benefit. For high-rate servers, there are thus not only reasons they might not benefit, but reasons they might want to deliberately avoid this mechanism. Yes, there are other challenges to building a high-rate server, but it's worth noting that this mechanism might complicate that situation more than it helps. I think that's worth stating, though should take only a sentence or two. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAktLdioACgkQE5f5cImnZrs+fACgicnAFT5xYOujMnJVbwRmWv5K u1UAn0wjGOSvA6IkiEoogJx/Nn0QHBFu =7F/U -----END PGP SIGNATURE----- From bew@cisco.com Thu Jan 14 09:49:39 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40EF03A687F for ; Thu, 14 Jan 2010 09:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDtcNUABakFT for ; Thu, 14 Jan 2010 09:49:38 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 2DAFF3A67D8 for ; Thu, 14 Jan 2010 09:49:38 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF3oTkurRN+K/2dsb2JhbADELokkCYtHgkaBagQ X-IronPort-AV: E=Sophos;i="4.49,276,1262563200"; d="scan'208";a="74428746" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 14 Jan 2010 17:49:35 +0000 Received: from stealth-10-32-244-210.cisco.com (stealth-10-32-244-210.cisco.com [10.32.244.210]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0EHnZHI004977; Thu, 14 Jan 2010 17:49:35 GMT Message-Id: <2ACBDA51-146B-4E60-8656-2C96F1ADDEA0@cisco.com> From: Brian Weis To: "Gregory M. Lebovitz" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 14 Jan 2010 09:49:34 -0800 X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org Subject: [tcpm] Comments on draft-ietf-tcpm-tcp-ao-crypto-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 17:49:39 -0000 Hi Gregory, In prototyping TCP-AO, I noticed the following relatively minor issues with this draft, but not fixing them has interoperability consequences. 1. In order to have an interoperable KDF, the number of bytes for "i" (the counter) and "Output_length" need to be defined. If one side hashes a 4 byte value and the other a 1 byte value, the resulting KDF output will differ. I suggest amending the text something similar to as follows: * In the description of "i", after the sentence "A counter, a binary string that is an input to each iteration of the PRF in counter mode." add the following sentence: "The counter is represented in a single octet." * In the description of "Output_length" add a sentence after "The length in bits of the key that the KDF will produce." add "The Output_length is represented within two octets." I believe 255 iterations ought to be enough for an KDF, which is why I suggest one octect for "i". Also, the overall length of key being produce shouldn't be larger than 65535 bytes. If you're concerned with arbitrary limiting the size of the values for all KDFs that might be defined in the future, you could instead make these statements part of the definition of KDF_HMAC_SHA1 and KDF_AES_128_CMAC. I doesn't matter to me, I just have observed that if everyone doesn't do it the same way there are issues! 2. This example in Section 3.1.1 doesn't match SP 800-108: Traffic_Key = KDF_alg(Master_Key, 0 || Label || Context || Output_length) || KDF_alg(Master_Key, 1 || Label || Context || Output_length) All of the KDFs in SP 800-108 start the counter at "1", not "0". It would be very helpful to start the counter here at "1" as well. As one data point, I could not use my general-purpose KDF that conforms with SP 800-108 for TCP-AO, which was annoying. I also think this singly inconsistency could easily lead to errors in implementations that don't noticed the difference. Thanks, Brian -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From root@core3.amsl.com Tue Jan 19 12:30:01 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6CCE03A68F8; Tue, 19 Jan 2010 12:30:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100119203001.6CCE03A68F8@core3.amsl.com> Date: Tue, 19 Jan 2010 12:30:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 20:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : ICMP attacks against TCP Author(s) : F. Gont Filename : draft-ietf-tcpm-icmp-attacks-08.txt Pages : 40 Date : 2010-01-19 This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. Additionally, describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 23, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-icmp-attacks-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-19122114.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Jan 19 17:00:01 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6D3913A67FB; Tue, 19 Jan 2010 17:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100120010001.6D3913A67FB@core3.amsl.com> Date: Tue, 19 Jan 2010 17:00:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 01:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : ICMP attacks against TCP Author(s) : F. Gont Filename : draft-ietf-tcpm-icmp-attacks-09.txt Pages : 40 Date : 2010-01-19 This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. Additionally, describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 23, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-icmp-attacks-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-19165934.I-D@ietf.org> --NextPart-- From wesley.m.eddy@nasa.gov Thu Jan 21 09:39:11 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463CA3A6A20 for ; Thu, 21 Jan 2010 09:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtN8f5PWvZIL for ; Thu, 21 Jan 2010 09:39:09 -0800 (PST) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id C9BF53A6A21 for ; Thu, 21 Jan 2010 09:39:08 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id E0653A8744 for ; Thu, 21 Jan 2010 11:39:04 -0600 (CST) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o0LHd4hp023953 for ; Thu, 21 Jan 2010 11:39:04 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Thu, 21 Jan 2010 11:39:04 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Thu, 21 Jan 2010 11:39:03 -0600 Thread-Topic: WG status as of 1/21/2010 Thread-Index: AcqawJ8xkaKWBUSJT5yqX2SK7m2jcQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-01-21_09:2010-01-20, 2010-01-21, 2010-01-21 signatures=0 Subject: [tcpm] WG status as of 1/21/2010 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 17:39:11 -0000 As a few things have changed since the last time we sent a snapshot of the WG status, here is the current basket of TCPM work. I think the highest priority items are updates to the AO and AO crypto documents in response to the comments from WGLC (and post-WGLC discussion). Something new on this list is the set of reported RFC Errata that we need to vet as they're on TCP documents. WG Items Nearing RFC Publication =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Early-Retransmit http://www.ietf.org/id/draft-ietf-tcpm-early-rexmt-03.txt Milestone Target: Experimental in July 2009 Status: Publication Requested on 11/19/09, on 12/17/09 IESG telechat agenda All IESG "Discuss" positions have been cleared to No-Objection Action: None in TCPM ICMP Attacks http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-09.txt Milestone Target: Informational in July 2009 Status: Publication Requested on 1/21/10 Action: None in TCPM WG Items in WGLC or being revised after WGLC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TCP Authentication Option http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-08.txt Milestone Target: Proposed Standard in April 2009 Status: WGLC ended 11/24/09, additional comments received afterwards Action: Editors (Joe Touch) to update; chairs to write PROTO TCP Authentication Option Crypto http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt Milestone Target: Proposed Standard with AO spec Status: WGLC ended 11/24/09, additional comments received afterwards Action: Editors (G. Lebovitz) to update; chairs to write PROTO Active WG Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1323bis http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt Milestone Target: Proposed Standard in July 2009 Status: Needs revision Action: Revise & WGLC (action with D. Borman) MSS Option http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt Milestone Target: Proposed Standard in July 2009 Status: WGLC started 8/19, ended 9/8 (extended) Action: being updated based on several of the comments (action with D. Borm= an) Urgent Pointer http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-02.txt Milestone Target: Proposed Standard in January 2010 Status: awaiting WGLC after AO WGLC completes Action: D. Borman to start WGLC TCP Security http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-00.txt Milestone Target: BCP in August 2010 Status: outline discussion dying off? content needs work Action: 00-draft / outline has been under active discussion; but not attain= ed very clear consensus WG might begin working on recommendations while still looking for a possible compromise on outline (action with Fernando Gont) Long Connectivity Disruptions http://www.ietf.org/id/draft-ietf-tcpm-tcp-lcd-00.txt (need to submit WG version) Milestone Target: Experimental in October 2010 Status: sumbitted as initial WG document; authors think no real issues are = left Action: need WG to read/discuss SACK Entry http://www.ietf.org/id/draft-ietf-tcpm-sack-recovery-entry-00.txt Milestone Target: Proposed Standard in October 2010 Action: need WG to read/discuss TBD how this relates to 3517 Documents Under a Poll to Become WG Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TCP Option for Transparent Middlebox Discovery http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery-03.txt Status: discussed on mailing list and updated in response poll for working group adoption opened on 12/9, responses desired by 12/23 Other Proposals =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Clarification of sender behavior in persist condition. http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt Status: discussed on mailing list and in face-to-face meetings Action: chairs to open WG poll for adoption Timestamps http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt Action: ??? Parameter Tuning (no I-D yet) Action: continue good discussion on mailing list presentation given in Stockholm need to determine if one or more I-Ds are to-be written NewReno Modification http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-01.t= xt Action: need WG to read/discuss presentation given, but WG list not yet polled for adoption discussions on Rate-Halving http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt Action: mailing list discussion about the history of this, and whether it needs to be revived AO NAT http://www.ietf.org/internet-drafts/draft-touch-tcp-ao-nat-00.txt Action: WG review/discuss issues raised by Eric Rescorla; to be considered as a potential update to the AO spec AFTER the base AO spec is published Other WG Activities =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Errata Review for legacy TCP RFCs: RFC0793 (1496) 3.9 Technical Legacy Yin Shuming 2008-08-27 RFC0793 (1561) 3.2 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1562) 3.3 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1563) 3.4 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1564) 3.7 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1565) 3.8 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1566) 3.9 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1567) 3.9 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1568) 3.9 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1569) 2.4 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1570) 2.7 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1571) 3.1 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1572) 3.4 Technical Legacy Constantin Hagemeier 2008-10-11 -- Wes Eddy MTI Systems From wesley.m.eddy@nasa.gov Thu Jan 21 09:54:07 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086DD3A6AC0 for ; Thu, 21 Jan 2010 09:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYLFz-qK2Cen for ; Thu, 21 Jan 2010 09:54:06 -0800 (PST) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id 329D33A6924 for ; Thu, 21 Jan 2010 09:54:06 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 2BA752D82FE for ; Thu, 21 Jan 2010 11:54:02 -0600 (CST) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o0LHs12U031522 for ; Thu, 21 Jan 2010 11:54:01 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Thu, 21 Jan 2010 11:54:01 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Thu, 21 Jan 2010 11:54:00 -0600 Thread-Topic: middlebox discovery option number Thread-Index: AcqawrZSesUr0MgTQ6yyPWk8qgJvLA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-01-21_09:2010-01-20, 2010-01-21, 2010-01-21 signatures=0 Subject: [tcpm] middlebox discovery option number X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 17:54:07 -0000 It appears as a result of the poll to adopt the middlebox discovery document (draft-knutsen-tcpm-middlebox-discovery-03) as a TCPM working group item, that there was not significant enough WG support to adopt this. There are two ways to obtain a TCP option number described in RFC 2780 - either IESG approval or Standards Action. Since Standards Action is off the table, IESG approval is the route left. I believe our ADs may be open to this, as there are plenty of options numbers left open. I would like to ask the working group to consider whether we might have TCPM consensus to: (1) leave this up to the IESG to approve or not (2) actively ask the IESG to _block_ the assignment (3) actively ask the IESG to _approve_ the assignment, although it should not be viewed as setting a precedent for how to get options numbers Lacking any inputs (or consensus in the WG), the default is for (1). Since this document/TCP-option has already been discussed quite a bit in the WG, I think it's reasonable to ask for responses by 1/29 in order to not keep our ADs waiting in suspense. My personal inclination is towards (3), which is given here outside the WG co-chair role. -- Wes Eddy MTI Systems From anil.agarwal@viasat.com Fri Jan 22 18:36:38 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61E933A67B7 for ; Fri, 22 Jan 2010 18:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zxOJSTbIMI7 for ; Fri, 22 Jan 2010 18:36:37 -0800 (PST) Received: from viasat.com (hawk.viasat.com [12.198.241.145]) by core3.amsl.com (Postfix) with ESMTP id 7F1593A677D for ; Fri, 22 Jan 2010 18:36:37 -0800 (PST) Received: from ([172.31.1.23]) by hawk.viasat.com with ESMTP id 5B7LFJ1.5981586; Fri, 22 Jan 2010 21:23:48 -0500 Received: from VGAEXCH01.hq.corp.viasat.com ([172.31.1.20]) by VGAEXCH02.hq.corp.viasat.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 21:36:29 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Jan 2010 21:36:28 -0500 Message-ID: <0B0A20D0B3ECD742AA2514C8DDA3B0650318D65B@VGAEXCH01.hq.corp.viasat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ftp IP TOS Usage Thread-index: Acqb1N2RUo9a45sCRYm0Gmf2V9ORxg== From: "Agarwal, Anil" To: X-OriginalArrivalTime: 23 Jan 2010 02:36:29.0410 (UTC) FILETIME=[DE0AC420:01CA9BD4] Subject: [tcpm] ftp IP TOS Usage X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 02:36:38 -0000 Can someone please describe (or point to a document) why ftp uses = non-zero IP TOS values (0x10 and 0x08) for non-SYN TCP segments of the = control and data TCP connections, but uses IP TOS =3D 0 in TCP SYN = segments? telnet seems to use TOS =3D 0x10 in all TCP segments. ssh and sftp seem to use TOS =3D 0 for SYN and the first few data = segments, then switch to a non-zero TOS value (0x08). (Above observations are based on Linux). Thanks, Anil Anil Agarwal ViaSat Inc. Germantown, MD 20876 =A0 From chaks@cisco.com Sun Jan 24 12:00:30 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7053A67A4 for ; Sun, 24 Jan 2010 12:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.752 X-Spam-Level: X-Spam-Status: No, score=-4.752 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FRT_STOCK2=3.988, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uigdFav04Hwc for ; Sun, 24 Jan 2010 12:00:30 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9183F3A692C for ; Sun, 24 Jan 2010 12:00:27 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMs1XEurR7Hu/2dsb2JhbAC+apUshDsE X-IronPort-AV: E=Sophos;i="4.49,335,1262563200"; d="scan'208";a="472062408" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 24 Jan 2010 20:00:31 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0OK0Ul3021860; Sun, 24 Jan 2010 20:00:30 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Jan 2010 12:00:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jan 2010 12:00:30 -0800 Message-ID: <3C50EF6BFB256E448286057DABC00CBE094D68BE@xmb-sjc-214.amer.cisco.com> In-Reply-To: <0B0A20D0B3ECD742AA2514C8DDA3B0650318D65B@VGAEXCH01.hq.corp.viasat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] ftp IP TOS Usage Thread-Index: Acqb1N2RUo9a45sCRYm0Gmf2V9ORxgBWmAfw References: <0B0A20D0B3ECD742AA2514C8DDA3B0650318D65B@VGAEXCH01.hq.corp.viasat.com> From: "Chaks Chigurupati (chaks)" To: "Agarwal, Anil" , X-OriginalArrivalTime: 24 Jan 2010 20:00:30.0877 (UTC) FILETIME=[E1ADD4D0:01CA9D2F] Subject: Re: [tcpm] ftp IP TOS Usage X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 20:00:31 -0000 Just a guess on my part. The differences could be due to the way = setsockopt for TOS is done, i.e. if you set the TOS as soon as the = socket is created but before the connection is established, then SYN = segments will carry the programmed TOS. Telnet could be setting the TOS = before the connection is established. Ssh and sftp could be setting it = after the connection is established. Chaks > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Agarwal, Anil > Sent: Friday, January 22, 2010 6:36 PM > To: tcpm@ietf.org > Subject: [tcpm] ftp IP TOS Usage >=20 >=20 > Can someone please describe (or point to a document) why ftp=20 > uses non-zero IP TOS values (0x10 and 0x08) for non-SYN TCP=20 > segments of the control and data TCP connections, but uses IP=20 > TOS =3D 0 in TCP SYN segments? >=20 > telnet seems to use TOS =3D 0x10 in all TCP segments. >=20 > ssh and sftp seem to use TOS =3D 0 for SYN and the first few=20 > data segments, then switch to a non-zero TOS value (0x08). >=20 > (Above observations are based on Linux). >=20 > Thanks, > Anil >=20 > Anil Agarwal > ViaSat Inc. > Germantown, MD 20876 > =A0 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From lars.eggert@nokia.com Wed Jan 27 05:35:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC453A6A86 for ; Wed, 27 Jan 2010 05:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.605 X-Spam-Level: X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhQz0ftaN7Vx for ; Wed, 27 Jan 2010 05:35:39 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 4B4F03A67A8 for ; Wed, 27 Jan 2010 05:35:39 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0RDZjYT022409 for ; Wed, 27 Jan 2010 07:35:52 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 15:35:35 +0200 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 15:35:35 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0RDZYRw029817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Jan 2010 15:35:34 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-1-676797045; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 27 Jan 2010 15:35:21 +0200 In-Reply-To: <20100120010001.6D3913A67FB@core3.amsl.com> To: "tcpm@ietf.org WG" References: <20100120010001.6D3913A67FB@core3.amsl.com> Message-Id: <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Wed, 27 Jan 2010 15:35:27 +0200 (EET) X-OriginalArrivalTime: 27 Jan 2010 13:35:35.0768 (UTC) FILETIME=[9B291D80:01CA9F55] X-Nokia-AV: Clean Subject: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 13:35:41 -0000 --Apple-Mail-1-676797045 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, below is my AD review for draft-ietf-tcpm-icmp-attacks-09. I have one main issue. The very detailed example of the operation of the = mitigation technique in Section 7.3, and especially the pseudo code that = implements what the document still calls the "proposed" solutions in = Section 7.4 in my opinion go beyond the WG consensus we had, which was = to document and discuss the mitigation techniques implemented in current = stacks. I'd be interested to hear the WG's thoughts esp. on this issue, but of = course also on the rest of my comments below. Thanks, Lars Note: Most comments marked as nits below have been automatically flagged by review scripts - there may be some false positives in there. The goal of this draft is to document and discuss attack mitigation techniques that are implemented by various stacks. In some places, the ID still talks about "proposed mechanisms" or "proposed techniques", etc., which isn't quite aligned with the purpose of the draft. Could you check those phrasings and change them to be about what the surveyed implementations do? INTRODUCTION, paragraph 4: > This document discusses the use of the Internet Control Message > Protocol (ICMP) to perform a variety of attacks against the > Transmission Control Protocol (TCP) and other similar protocols. I find nothing in this document that is not about TCP. Suggest to remove the "and other similar protocols" bit. INTRODUCTION, paragraph 13: > Copyright Notice You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/) Section 1., paragraph 2: > official proposal on how to deal with these vulnerabiliies. In = 2005, Nit: s/vulnerabiliies./vulnerabilities./ Section 1., paragraph 5: > This document aims to raise awareness of the use of ICMP to perform = a > variety of attacks against TCP, and discusses several counter- > measures that eliminate or minimize the impact of these attacks. > Most of the these counter-measures can be implemented while still > remaining compliant with the current specifications, as they simply > describe reasons for not taking the advice provided in the > specifications in terms of "SHOULDs", but still comply with the > requirements stated as "MUSTs". Recommend to add a sentence that this document does NOT constitute an IETF recommendation to implement said countermeasures, and why. Section 1., paragraph 6: > Section 2 provides background information on ICMP. Section 3 > discusses the constraints in the general counter-measures that can = be > implemented against the attacks described in this document. > Section 4 proposes several general validation checks that can be > implemented to mitigate any ICMP-based attack. Finally, Section 5, > Section 6, and Section 7, discuss a variety of ICMP attacks that = can > be performed against TCP, and propose attack-specific counter- > measures that eliminate or greatly mitigate their impact. See the first comment - the purpose of this document is not to propose or recommend any techniques. Please rephrase. (I'll not flag this in the remainder of the ID; please check it for such phrasings though.) Section 2.1., paragraph 2: > When an intermediate router detects a network problem while trying = to > forward an IP packet, it will usually send an ICMP error message to > the source system, to raise awareness of the network problem taking > place. Nit: suggest to say "inform" rather than "raise awareness" - ICMP is not part of some sort of PR campaign :-) (also elsewhere in the document) Section 2.1., paragraph 3: > In the same way, there are a number of scenarios in which an > end-system may generate an ICMP error message if it finds a problem > while processing a datagram. The received ICMP errors are handed = to > the corresponding transport-protocol instance, which will usually > perform a fault recovery function. The first sentence is about generating ICMP, the second about receiving it. Move the second sentence to the previous paragraph, which was all about receiving ICMP? Section 2.1., paragraph 4: > It is important to note that ICMP error messages are unreliable, = and Nit: s/unreliable/transmitted unreliably/ Section 2.1.1., paragraph 0: > 2.1.1. ICMP for IP version 4 (ICMP) For completeness sake, you might want to add a sentence about & a reference to RFC4884. Section 3., paragraph 0: > 3. Constraints in the possible solutions This section dances around the main issue without ever explicitly stating it: If a host wants to more carefully inspect ICMP messages before acting on them, it is limited by whatever chunk of the packet that triggered the ICMP the sender chose to include. And the situation is difficult, because . Section 3., paragraph 2: > can be performed, as there is not much information avalable on = which Nit: s/avalable/available/ Section 3., paragraph 6: > power requirements of authentication might not allow IPSec Nit: s/IPSec/IPsec/ (also elsewhere in the ID) Section 4.2., paragraph 2: > [I-D.ietf-tsvwg-port-randomization] discusses a number of = algorithms > to randomize the ephemeral ports used by clients. And in it, the IETF does recommend that clients use some form of port randomizartion, right? Section 3.2.2.1, paragraph 4: > [I-D.ietf-tcpm-tcpsecure], by means authentication at the network Nit: s/by means/by means of/ Section 5.2., paragraph 13: > Based on this analysis, most popular TCP implementations treat all Odd wording. I doubt that the analysis in this ID has caused existing TCP implementations to change years ago. Do you mean "An analysis of most popular TCP implementations has shown..."? Section 5.2., paragraph 15: > contition, and thus may still abort their connections on their own = if Nit: s/contition,/condition,/ Section 5.2., paragraph 19: > This counter-measure has been implemented in BSD-derived TCP/IP > implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more > than ten years [Wright][McKusick]. The Linux kernel has also > implemented this policy for more than ten years [Linux]. Which counter-measure is "this counter-measure"? The one that is implemented in most stacks, which is described four paragraphs before? Section 7.1., paragraph 1: > systems determine the Path MTU of an arbitrary internet path. Nit: s/internet/Internet/ (also in many other places in the ID) Section 7.1., paragraph 6: > The effect of this attack is two-fold. On one hand, it will = increase > the headers/data ratio, thus increasing the overhead needed to send > data to the remote TCP end-point. On the other hand, if the = attacked > system wanted to keep the same throughput it was achieving before > being attacked, it would have to increase the packet rate. On > virtually all systems this will lead to an increase in the IRQ > (Interrrupt ReQuest) rate and protocol processing time, thus Nit: s/(Interrrupt/(Interrupt/ > increasing processor utilization, and degrading the overall system > performance. I thought most modern operating systems didn't use hard IRQs anymore in their stacks? Isn't it all soft-interrupts or similar now? (I do agree that packet processing overhead per payload byte goes up with smaller packets, but I don't think it's because of IRQs.) Section 7.1., paragraph 8: > results. Another posible scenario is that in which a TCP = connection Nit: s/posible/possible/ Section 7.2., paragraph 1: > The IETF has standardized a Path-MTU Discovery mechanism called > "Packetization Layer Path MTU Discovery" that does not depend on = ICMP > error messages. Implementation of the aforementioned mechanism in > replacement of the traditional PMTUD (specified in [RFC1191] and > [RFC1981]) would eliminate this vulnerability. However, it might > also lead to an increase of the PMTUD convergence time. Add a citation to RFC4821 here. Also, why the conjunctive? PLPMTUD *does* eliminate this vulnerability. Section 7.2., paragraph 11: > On the other hand, maxsizeacked holds the size (in octets) of the > largest packet that has so far been acknowledged for this = connection. > It is initialized to 68 (the minimum IPv4 MTU) when the underlying > internet protocol is IPv4, and is initialized to 1280 (the minimum > IPv6 MTU) when the underlying internet protocol is IPv6. Whenever = an > acknowledgement for a packet larger than maxsizeacked octets is > received, maxsizeacked is set to the size of that acknowledged > packet. Maybe I'm dense, but how does this work with delayed ACKs? If you see the left edge of the window shift by n bytes, you don't know that maxsizeacked is n bytes, right? Section 7.2., paragraph 15: > out. MAXSEGRRTO specifies the number of times a given segment must Nit: s/MAXSEGRRTO/MAXSEGRTO/ Section 7.2., paragraph 20: > MAXSEGRTO can be set, in principle, to any value greater than or > equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the > traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A > MAXSEGRTO of 1 provides enough protection for most cases. In any > case, implementations are free to choose higher values for this > constant. MAXSEGRTO could be a function of the Next-Hop MTU = claimed > in the received ICMP "Packet Too Big" message. That is, higher > values for MAXSEGRTO could be imposed when the received ICMP = "Packet > Too Big" message claims a Next-Hop MTU that is smaller than some > specified value. Which value do the different implementations you surveyed use for MAXSEGRTO? Section 7.2., paragraph 22: > Section 7.3 shows the proposed counter-measure in action. > Section 7.4 shows the proposed counter-measure in pseudo-code. Since the publication target is Informational, calling this the "proposed" something is slightly misleading. Can you rephrase this to be about what current implementations do? Section 7.3., paragraph 0: > 7.3. The counter-measure for the PMTUD attack in action DISCUSS: Section 7.3 is in my opinion going into way too much detail for the purposes of this ID. The extremely detailed example in Sections 7.3.1-7.3.4 should really go into a specification of the mitigation technique (for which we have no WG consensus) and is IMO not needed in this Informational document. Section 7.3., paragraph 1: > This SECTION shows the proposed counter-measure for the ICMP attack s/SECTION/section/ Section 7.4., paragraph 0: > 7.4. Pseudo-code for the counter-measure for the blind performance- > degrading attack DISCUSS: I believe it is fully out of scope for this Informational document to include pseudo code for a mechanism that the WG has decided to not recommend as PS. Section 7.4., paragraph 33: > All comparisions between sequence numbers must be performed = using Nit: s/comparisions/comparisons/ Section 7.4., paragraph 34: > sequence number arithmethic. Nit: s/arithmethic./arithmetic./ Appendix A., paragraph 16: > o The text (particulary that which describes the counter-measures) Nit: s/(particulary/(particularly/ Appendix A., paragraph 19: > o Miscelaneous editorial changes. Nit: s/Miscelaneous/Miscellaneous/ Appendix A., paragraph 25: > o Corrected the threat analysys Nit: s/analysys/analysis/ --Apple-Mail-1-676797045 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDEyNzEzMzUyMlowIwYJKoZIhvcNAQkEMRYEFHXMc3euFtm9XMUN0qSAB/9pcb44MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQA+3ESfxTGWmghLqRV0WARRuMe+wD1uYiiuBE3FwmAnmA8UoMZmZXSizx85Y5an3eAJt38z 9yDkhlXRxNBQoK5+ZzqQF+MzxKZQjICin7e+fLm35nE+SDYJ1azpHjjuPYhU6DFuJUP77XwhMRkI tUmyxiW2COXrX8dIwxBnUn7g80ViXr917kgBbC/n0ZO27pkJQM46+R+qwec3tZRTwXUVywc4uu4G pI+sYA9Fkqx+LEc6NCUCqV3u30kfggP06JKO/fF1BW+DQBHoAHXM4HTJr5suxHqHZ+pveJvk6l3l /tE9TBs1M34A6k75Wbmk75M8AZb0dPnWC1K8SOJ7eX9tAAAAAAAA --Apple-Mail-1-676797045-- From toby.moncaster@bt.com Wed Jan 27 07:35:30 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6DC63A6AB5 for ; Wed, 27 Jan 2010 07:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWcMBwrrH6bh for ; Wed, 27 Jan 2010 07:35:29 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 9C87F3A6950 for ; Wed, 27 Jan 2010 07:35:29 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 15:35:43 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 15:35:40 -0000 Message-ID: In-Reply-To: <0B0A20D0B3ECD742AA2514C8DDA3B0650318D65B@VGAEXCH01.hq.corp.viasat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] ftp IP TOS Usage Thread-Index: Acqb1N2RUo9a45sCRYm0Gmf2V9ORxgDjsrCg References: <0B0A20D0B3ECD742AA2514C8DDA3B0650318D65B@VGAEXCH01.hq.corp.viasat.com> From: To: , X-OriginalArrivalTime: 27 Jan 2010 15:35:43.0025 (UTC) FILETIME=[63054210:01CA9F66] Subject: Re: [tcpm] ftp IP TOS Usage X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 15:35:30 -0000 The ToS field has been redefined several times and now consists of the 6 = bit Diffserv codepoint field and the 2 bit ECN field.=20 Have a look at: = http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/MAN/MAN4/= 0055____.HTM And p.21 of RFC1060 which might explain why telnet uses 0x100. 0x08 = implies that the segments are being sent with the "reliability" flag in = the parlance of RFC1349. Not sure if that helps at all... Toby ____________________________________________________________________=20 Toby Moncaster, Senior Researcher, BT Network Infrastructure Practice B54/70 Adastral Park, Ipswich, IP53RE, UK.=A0 +44 7918 901170=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf = Of > Agarwal, Anil > Sent: 23 January 2010 02:36 > To: tcpm@ietf.org > Subject: [tcpm] ftp IP TOS Usage >=20 >=20 > Can someone please describe (or point to a document) why ftp uses non- > zero IP TOS values (0x10 and 0x08) for non-SYN TCP segments of the > control and data TCP connections, but uses IP TOS =3D 0 in TCP SYN > segments? >=20 > telnet seems to use TOS =3D 0x10 in all TCP segments. >=20 > ssh and sftp seem to use TOS =3D 0 for SYN and the first few data > segments, then switch to a non-zero TOS value (0x08). >=20 > (Above observations are based on Linux). >=20 > Thanks, > Anil >=20 > Anil Agarwal > ViaSat Inc. > Germantown, MD 20876 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From fernando.gont.netbook.win@gmail.com Wed Jan 27 12:20:59 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D2443A67B2 for ; Wed, 27 Jan 2010 12:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGNwEFWRHjVk for ; Wed, 27 Jan 2010 12:20:58 -0800 (PST) Received: from mail-yx0-f123.google.com (mail-yx0-f123.google.com [209.85.210.123]) by core3.amsl.com (Postfix) with ESMTP id D47463A68DF for ; Wed, 27 Jan 2010 12:20:57 -0800 (PST) Received: by yxe29 with SMTP id 29so53917yxe.5 for ; Wed, 27 Jan 2010 12:21:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=EqH+iJyM66ODV6OS0+iaC/xQsNqFujPafvgAAOKpkCQ=; b=N7cRohjm5iGQLU/gcwsBdblXyRYvIOpWMkUdRe4QDNPezpnuwSb9Ih0TZHN0fcQD64 ebQ9X0Fsq88npHXV8KAONYiz+QIWRcrJtMjYgwNhYdnr8VaQVQgAw6a69j53pSk2PLbS VIhDiTwYp6791q9IV+t4ZdKP9ODQXNaWlCrzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=j7rGLL32DazUDgk2701pClstrTsf4o4nvHkYdaivXGDptJz9FZF4RXStFTvzbX+JfH 3YibhaicmHDhrdN/SdM8f465dp9S+YC5/0uwLNNk+EnoDnsKcqHgT452kEHqM9lNbo2u Hf//1bFL+A0ielkGMCGcdSwJb4jnN1D8n4OLM= Received: by 10.91.51.1 with SMTP id d1mr1048619agk.41.1264623661835; Wed, 27 Jan 2010 12:21:01 -0800 (PST) Received: from ?190.48.227.28? ([190.48.227.28]) by mx.google.com with ESMTPS id 13sm129025gxk.1.2010.01.27.12.20.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Jan 2010 12:21:01 -0800 (PST) Sender: Fernando Gont Message-ID: <4B60A022.1080006@gont.com.ar> Date: Wed, 27 Jan 2010 17:20:50 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> In-Reply-To: <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 20:20:59 -0000 Hi, Lars, Comments in-line.... (other comments in my next e-mail...) > I have one main issue. The very detailed example of the operation of > the mitigation technique in Section 7.3, and especially the pseudo > code that implements what the document still calls the "proposed" > solutions in Section 7.4 in my opinion go beyond the WG consensus we > had, which was to document and discuss the mitigation techniques > implemented in current stacks. The pseudo-code is just that: documentation of how the counter-measure works. While there's also verbose description of how the counter-measure works, I'd argue that for many of us the pseudo-code ends-up being a clearer explanation. That said, this text has been in the I-D since draft-gont-tcpm-icmp-attacks-04.txt (circa September 5, 2005), when it had not yet been adopted as a wg item. I has been four and a half years since that, an plenty of revisions since then. And the I-D has passed WGLC. > I'd be interested to hear the WG's thoughts esp. on this issue, but > of course also on the rest of my comments below. Are we kinda going back to WGLC? > Section 1., paragraph 5: >> This document aims to raise awareness of the use of ICMP to perform >> a variety of attacks against TCP, and discusses several counter- >> measures that eliminate or minimize the impact of these attacks. >> Most of the these counter-measures can be implemented while still >> remaining compliant with the current specifications, as they simply >> describe reasons for not taking the advice provided in the >> specifications in terms of "SHOULDs", but still comply with the >> requirements stated as "MUSTs". > > Recommend to add a sentence that this document does NOT constitute an > IETF recommendation to implement said countermeasures, and why. Being an informational document, it does not constitute an IETF recommendation. That said, why it's not a formal IETF recommendation... that's a very good question, that not only me, but also vendors would like to know the answer. I do recall somebody making a comment in an IETF meeting that I attended (back in 2005), asking "why not informational?", and we ended up changing from std track to informational. It remains an interesting question why we insist in ignoring reality-based world.... (but you know I have already debated this one). If you ask this question again, I'm afraid you'll get a response from me, and another one from Joe (and probably not many others). Vendors, and people in general working in real-world code have already applied most of the stuff discussed in the I-D, and probably won't bother getting into this type of debate. Actually, all this endless debates about "you might receive an ICMP error message after five minutes... so you shouldn't implement this", or "it's incorrect to do this unless you know for sure you're under attack" is IMO far from the "E" in "IETF", and the reason many of the implementers we'd need to join the list, don't. We're seen as not belonging to reality-based world. > Section 7.3., paragraph 0: >> 7.3. The counter-measure for the PMTUD attack in action > > DISCUSS: Section 7.3 is in my opinion going into way too much detail > for the purposes of this ID. The extremely detailed example in > Sections 7.3.1-7.3.4 should really go into a specification of the > mitigation technique (for which we have no WG consensus) and is IMO > not needed in this Informational document. Again, this has been in the I-D for more than four years (these particular sections even predate the pseudo-code). And they document and explain the counter-measure. If we don't include this, the reader has to figure this out for himself. I don't know why we insist so much in making documents irrelevant, rather than useful, to the reader. > Section 7.4., paragraph 0: >> 7.4. Pseudo-code for the counter-measure for the blind >> performance- degrading attack > > DISCUSS: I believe it is fully out of scope for this Informational > document to include pseudo code for a mechanism that the WG has > decided to not recommend as PS. The document was adopted with this section in place, has gone through plenty of revisions since then (i.e., 2005), has been reviewed by implementers more than probably any other I-D that this working group has produced, and has passed WGLC with this text in place. This is not the first time that you seem to ignore wg consensus (it has happened with the draft-ietf-tcp-security already, as noted off-list at the time). IMO, this discourages people in general, and particularly implementers, to get involved in the IETF process in general, and with TCPM in particular. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Wed Jan 27 12:37:01 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116E33A688C for ; Wed, 27 Jan 2010 12:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo90qoYLZgiI for ; Wed, 27 Jan 2010 12:36:59 -0800 (PST) Received: from mail-yx0-f123.google.com (mail-yx0-f123.google.com [209.85.210.123]) by core3.amsl.com (Postfix) with ESMTP id 6CEE33A6774 for ; Wed, 27 Jan 2010 12:36:59 -0800 (PST) Received: by yxe29 with SMTP id 29so57515yxe.5 for ; Wed, 27 Jan 2010 12:37:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=VZSVg+68LIov5Qg2vTY7V55OnuIcCftt4aQUSzwbdRY=; b=BuIgie2Vn9w1vHQDjL03nz1L9xazJx8wo/mDx40j5qf0g9j9GgdKq0eupj1rauh24+ vL4YucA3AtpnLG4ZvIeIUq1TJq1/hMaRuJmpeUK83W5/0gMGDBWpoH6QUqliuBANsb5e vy7sXM3UAzTmiDNm7kYPSAxsEMuug4JgHvSvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=ZgPLjqc1Iyb18KKc9e+BQ4lvxp0KE9z+qHYp0Z4ydOl9JJfdmB01IDJ3ro5VmLZaqs enzqNgx2EkxYC6i96P5luU6xGNNI4YILzyFS6dpHRNfiaeU1WtUg3DYJa6uoB0ojRiDi lQk/2Zzoy2+mdy8YjMiG7GquQ/jMBurXQ6bOc= Received: by 10.150.4.7 with SMTP id 7mr13318695ybd.241.1264624631856; Wed, 27 Jan 2010 12:37:11 -0800 (PST) Received: from ?190.48.227.28? ([190.48.227.28]) by mx.google.com with ESMTPS id 7sm79582ywf.40.2010.01.27.12.37.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Jan 2010 12:37:11 -0800 (PST) Sender: Fernando Gont Message-ID: <4B60A3EC.20308@gont.com.ar> Date: Wed, 27 Jan 2010 17:37:00 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> In-Reply-To: <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 20:37:01 -0000 Hi, Lars, This is the rest of my response to your review. Comments in-line.... (I have removed those changes that I will apply as suggested, and that didn't require further discussion). > The goal of this draft is to document and discuss attack mitigation > techniques that are implemented by various stacks. In some places, > the ID still talks about "proposed mechanisms" or "proposed > techniques", etc., which isn't quite aligned with the purpose of the > draft. Could you check those phrasings and change them to be about > what the surveyed implementations do? Yes, I will. Regarding the document calling it (or other stuff) "proposed" solutions, that is something that I should fix (I thought I had done it, already... but apparently there are remaining bits of it). > INTRODUCTION, paragraph 4: >> This document discusses the use of the Internet Control Message >> Protocol (ICMP) to perform a variety of attacks against the >> Transmission Control Protocol (TCP) and other similar protocols. > > I find nothing in this document that is not about TCP. Suggest to > remove the "and other similar protocols" bit. Will do. > INTRODUCTION, paragraph 13: >> Copyright Notice > > You're using the IETF Trust Provisions' Section 6.b License Notice > from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See > http://trustee.ietf.org/license-info/) There was no way (other manual) to fix this (at least when the last rev of the document was published). That said, the "grace period" announced by the IETF Trust still lasts till February 1st, so there's no problem with the old boilerplate text. > Section 2.1., paragraph 3: >> In the same way, there are a number of scenarios in which an >> end-system may generate an ICMP error message if it finds a problem >> while processing a datagram. The received ICMP errors are handed >> to the corresponding transport-protocol instance, which will >> usually perform a fault recovery function. > > The first sentence is about generating ICMP, the second about > receiving it. Move the second sentence to the previous paragraph, > which was all about receiving ICMP? Sorry, I do not follow you. In the second paragraph of Section 2.1, the first two sentences are about packet generation (first one about ICMP generation by routers, and the second about ICMP generation by hosts). Then the third sentence is about ICMP processing. So I'm not sure hwo you'd like the text to be changed... > Section 2.1.1., paragraph 0: >> 2.1.1. ICMP for IP version 4 (ICMP) > > For completeness sake, you might want to add a sentence about & a > reference to RFC4884. Will do. > Section 3., paragraph 0: >> 3. Constraints in the possible solutions > > This section dances around the main issue without ever explicitly > stating it: If a host wants to more carefully inspect ICMP messages > before acting on them, it is limited by whatever chunk of the packet > that triggered the ICMP the sender chose to include. And the > situation is difficult, because . Will do. > Section 4.2., paragraph 2: >> [I-D.ietf-tsvwg-port-randomization] discusses a number of >> algorithms to randomize the ephemeral ports used by clients. > > And in it, the IETF does recommend that clients use some form of port > randomizartion, right? Yes. I will rephrase this. > Section 5.2., paragraph 13: >> Based on this analysis, most popular TCP implementations treat all > > Odd wording. I doubt that the analysis in this ID has caused existing > TCP implementations to change years ago. Do you mean "An analysis of > most popular TCP implementations has shown..."? No, I meant what I wrote: Those implementations that already included the hard_errors -> soft_errors processing did so for the same reason stated in the draft (e.g., I did talk with Kirk McKusick back in 2005 and these guys (and others) got to the same conclusion (e.g., hard-errors -> soft-errors) through the same analysis). That said, other implementations implemented this in response to this I-D (e.g., Cisco, Microsoft, and others). Please see the "ICMP attacks" advisories linked in: http://www.gont.com.ar/advisories/index.html (and there are others). > Section 5.2., paragraph 19: >> This counter-measure has been implemented in BSD-derived TCP/IP >> implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more >> than ten years [Wright][McKusick]. The Linux kernel has also >> implemented this policy for more than ten years [Linux]. > > Which counter-measure is "this counter-measure"? The one that is > implemented in most stacks, which is described four paragraphs > before? Yes. The whole Section 5.2 is about the same thing (hard_errors -> soft_errors). > Section 7.1., paragraph 1: >> systems determine the Path MTU of an arbitrary internet path. > > Nit: s/internet/Internet/ (also in many other places in the ID) I did mean "internet". The mechanism works if you're using it in e.g. a corporate network that is not connected to the Internet. >> increasing processor utilization, and degrading the overall system >> performance. > > I thought most modern operating systems didn't use hard IRQs anymore > in their stacks? Isn't it all soft-interrupts or similar now? (I do > agree that packet processing overhead per payload byte goes up with > smaller packets, but I don't think it's because of IRQs.) Would you be happier with "increased interrupt and context-switching rate"? > Section 7.2., paragraph 1: >> The IETF has standardized a Path-MTU Discovery mechanism called >> "Packetization Layer Path MTU Discovery" that does not depend on >> ICMP error messages. Implementation of the aforementioned >> mechanism in replacement of the traditional PMTUD (specified in >> [RFC1191] and [RFC1981]) would eliminate this vulnerability. >> However, it might also lead to an increase of the PMTUD convergence >> time. > > Add a citation to RFC4821 here. Also, why the conjunctive? PLPMTUD > *does* eliminate this vulnerability. PLPMTUD can be implemented with or without ICMP support (i.e., as a replacement for classical PMTUD, or for black-hole detection). Therefore, it does not necessarily eliminate this vulnerability. > Section 7.2., paragraph 11: >> On the other hand, maxsizeacked holds the size (in octets) of the >> largest packet that has so far been acknowledged for this >> connection. It is initialized to 68 (the minimum IPv4 MTU) when the >> underlying internet protocol is IPv4, and is initialized to 1280 >> (the minimum IPv6 MTU) when the underlying internet protocol is >> IPv6. Whenever an acknowledgement for a packet larger than >> maxsizeacked octets is received, maxsizeacked is set to the size of >> that acknowledged packet. > > Maybe I'm dense, but how does this work with delayed ACKs? If you see > the left edge of the window shift by n bytes, you don't know that > maxsizeacked is n bytes, right? Correct. The worst-case scenario is that you do the "path mtu update phase" rather than "initial path mtu discovery". i.e., the mechanism fails on the safe side. > Section 7.2., paragraph 20: >> MAXSEGRTO can be set, in principle, to any value greater than or >> equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the >> traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A >> MAXSEGRTO of 1 provides enough protection for most cases. In any >> case, implementations are free to choose higher values for this >> constant. MAXSEGRTO could be a function of the Next-Hop MTU >> claimed in the received ICMP "Packet Too Big" message. That is, >> higher values for MAXSEGRTO could be imposed when the received ICMP >> "Packet Too Big" message claims a Next-Hop MTU that is smaller >> than some specified value. > > Which value do the different implementations you surveyed use for > MAXSEGRTO? They use a MAXSEGRTO of 1. I wrote and commited the OpenBSD implementation myself. NetBSD ported the one in OpenBSD to their OS, so they use the same MAXSEGRTO. > Section 7.2., paragraph 22: >> Section 7.3 shows the proposed counter-measure in action. Section >> 7.4 shows the proposed counter-measure in pseudo-code. > > Since the publication target is Informational, calling this the > "proposed" something is slightly misleading. Can you rephrase this to > be about what current implementations do? I can, and I will. However, I think this has been overstressed for this I-D. It's an Informational I-D. So it should be clear from the target itself and the Page-1 boilerplate to be used for the RFC that it does not contain any "formal IETF recommendation". Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From lars.eggert@nokia.com Wed Jan 27 13:09:27 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22393A688C for ; Wed, 27 Jan 2010 13:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.604 X-Spam-Level: X-Spam-Status: No, score=-6.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcK-w7Yy-Aru for ; Wed, 27 Jan 2010 13:09:26 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id F1A0E3A635F for ; Wed, 27 Jan 2010 13:09:25 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0RL8Oif004799; Wed, 27 Jan 2010 23:08:54 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 23:08:48 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 23:08:48 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0RL8ksu014571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 23:08:47 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-7-703989943; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4B60A022.1080006@gont.com.ar> Date: Wed, 27 Jan 2010 23:08:34 +0200 Message-Id: References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> <4B60A022.1080006@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Wed, 27 Jan 2010 23:08:40 +0200 (EET) X-OriginalArrivalTime: 27 Jan 2010 21:08:48.0758 (UTC) FILETIME=[EB721960:01CA9F94] X-Nokia-AV: Clean Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 21:09:27 -0000 --Apple-Mail-7-703989943 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-1-27, at 22:20, Fernando Gont wrote: >> I have one main issue. The very detailed example of the operation of=20= >> the mitigation technique in Section 7.3, and especially the pseudo=20 >> code that implements what the document still calls the "proposed"=20 >> solutions in Section 7.4 in my opinion go beyond the WG consensus we=20= >> had, which was to document and discuss the mitigation techniques=20 >> implemented in current stacks. >=20 > The pseudo-code is just that: documentation of how the counter-measure > works. While there's also verbose description of how the = counter-measure > works, I'd argue that for many of us the pseudo-code ends-up being a > clearer explanation. I'm not arguing that it's clearer, I'm saying that this level of details = seems unnecessary for an Informational document. > That said, this text has been in the I-D since > draft-gont-tcpm-icmp-attacks-04.txt (circa September 5, 2005), when it > had not yet been adopted as a wg item. I has been four and a half = years > since that, an plenty of revisions since then. And the I-D has passed = WGLC. So you're saying I should have flagged this earlier. And I probably = should have. But now I'm re-reviewing the document during AD Review, and = I felt this was an issue, so I'm raising it. >> I'd be interested to hear the WG's thoughts esp. on this issue, but=20= >> of course also on the rest of my comments below. >=20 > Are we kinda going back to WGLC? No, we're not. I do realize that the document has passed WGLC with these = sections in it, so if the WG tells me "this is a conscious decision, we = like this text to be in there" that's fine, but I want to make sure that = that's the case and not "oh, actually, this is maybe an issue." (I know = that passing WGLC in the current form is an implicit OK from the WG - = I'm asking for an explicit one.) >> Section 1., paragraph 5: >>> This document aims to raise awareness of the use of ICMP to perform >>> a variety of attacks against TCP, and discusses several counter-=20 >>> measures that eliminate or minimize the impact of these attacks.=20 >>> Most of the these counter-measures can be implemented while still=20 >>> remaining compliant with the current specifications, as they simply >>> describe reasons for not taking the advice provided in the=20 >>> specifications in terms of "SHOULDs", but still comply with the=20 >>> requirements stated as "MUSTs". >>=20 >> Recommend to add a sentence that this document does NOT constitute an >> IETF recommendation to implement said countermeasures, and why. >=20 > Being an informational document, it does not constitute an IETF > recommendation. >=20 > That said, why it's not a formal IETF recommendation... that's a very > good question, that not only me, but also vendors would like to know = the > answer. >=20 > I do recall somebody making a comment in an IETF meeting that I = attended > (back in 2005), asking "why not informational?", and we ended up > changing from std track to informational. We did deliberate this for issue quite a bit, if I recall correctly. In = the end, I think the WG felt that that the different implemented = mitigation techniques had downsides that were too serious to go for PS. (I'm not saying I necessarily agree with this sentiment, but I think = that was the decision process.) My comment was that the document might want to explicitly say this, so = readers who might wonder why this isn't PS know. > It remains an interesting question why we insist in ignoring > reality-based world.... (but you know I have already debated this = one). >=20 > If you ask this question again, I'm afraid you'll get a response from > me, and another one from Joe (and probably not many others). Vendors, > and people in general working in real-world code have already applied > most of the stuff discussed in the I-D, and probably won't bother > getting into this type of debate. >=20 > Actually, all this endless debates about "you might receive an ICMP > error message after five minutes... so you shouldn't implement this", = or > "it's incorrect to do this unless you know for sure you're under = attack" > is IMO far from the "E" in "IETF", and the reason many of the > implementers we'd need to join the list, don't. We're seen as not > belonging to reality-based world. I don't want to restart the Informational vs. PS discussion. The WG has = decided that already. >> Section 7.3., paragraph 0: >>> 7.3. The counter-measure for the PMTUD attack in action >>=20 >> DISCUSS: Section 7.3 is in my opinion going into way too much detail >> for the purposes of this ID. The extremely detailed example in=20 >> Sections 7.3.1-7.3.4 should really go into a specification of the=20 >> mitigation technique (for which we have no WG consensus) and is IMO=20= >> not needed in this Informational document. >=20 > Again, this has been in the I-D for more than four years (these > particular sections even predate the pseudo-code). And they document = and > explain the counter-measure. If we don't include this, the reader has = to > figure this out for himself. I don't know why we insist so much in > making documents irrelevant, rather than useful, to the reader. I believe the WG consensus was to document and discuss the mitigation = techniques that some stacks are using in this document. I don't believe = the intent was to include a detailed technical specification and pseudo = code for the mitigation techniques. IMO, those are much more appropriate for a PS specification than an = Informational document. If the WG wants to recommend these techniques as = PS, then it should publish them as PS, and not via an Informational = document that reads like a PS document. >> Section 7.4., paragraph 0: >>> 7.4. Pseudo-code for the counter-measure for the blind=20 >>> performance- degrading attack >>=20 >> DISCUSS: I believe it is fully out of scope for this Informational=20 >> document to include pseudo code for a mechanism that the WG has=20 >> decided to not recommend as PS. >=20 > The document was adopted with this section in place, has gone through > plenty of revisions since then (i.e., 2005), has been reviewed by > implementers more than probably any other I-D that this working group > has produced, and has passed WGLC with this text in place. I know. As I said above, I want to double-check that the WG is sure that = this is what they want to publish. > This is not the first time that you seem to ignore wg consensus (it = has > happened with the draft-ietf-tcp-security already, as noted off-list = at > the time). IMO, this discourages people in general, and particularly > implementers, to get involved in the IETF process in general, and with > TCPM in particular. First, I strongly disagree that I'm ignoring WG consensus in any way. It = is part of my duties as AD to review the documents that are coming out = of a WG in my area for issues before I forward them to the IESG, because = I will need to ballot Yes on them. I've done the review, found an issue, = and am asking the WG for explicit feedback. Second, please tell me in which case you believe that I have previously = ignored WG consensus. You're making a very serious accusation here, so = please back it up. Lars= --Apple-Mail-7-703989943 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDEyNzIxMDgzNVowIwYJKoZIhvcNAQkEMRYEFEzA3QvmsBFzFCltHF0kCNsMGJ0uMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBomE+7y0vWmlz8AGuMfJoQ0JkSmsUZZUEiReOa0Azw3gi7ExECAOUE0/YP3LkhNAGAm9gA oMH384Hbumy/MBuCLYpUMaVADo8pHu+al3KOMfP9zzbPY+BZj78CeXXr0AGpPINu64tvggWtHvD/ 9YUxJH19FGwXP5beNVMGglIpx3Xm1UBj5ZfvS+ZUR0G34457ggFdkkV8H2QLfCowyKeQbfMgt3g5 iIEBqqw87kzC8oFEfiTmE2KEOyibKfsMKmy7IjdUCiu92BNhSEp9PbTglGGbwZZuIa5T0BCNMEpx AsIrADCu+EQN3aJK5PcDk0TBTfxNaYHRYhbi4QPLDJmvAAAAAAAA --Apple-Mail-7-703989943-- From wesley.m.eddy@nasa.gov Wed Jan 27 13:34:58 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049E43A688C for ; Wed, 27 Jan 2010 13:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrUDbioLn8nb for ; Wed, 27 Jan 2010 13:34:56 -0800 (PST) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id DE0AD3A68C3 for ; Wed, 27 Jan 2010 13:34:55 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id DA82F2D8712; Wed, 27 Jan 2010 15:35:09 -0600 (CST) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o0RLZAQM024673; Wed, 27 Jan 2010 15:35:10 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Wed, 27 Jan 2010 15:35:10 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Fernando Gont , Lars Eggert Date: Wed, 27 Jan 2010 15:35:08 -0600 Thread-Topic: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 Thread-Index: AcqfjkuEO703yKI6TqyGnNOb3TrDIgABMZPg Message-ID: References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> <4B60A022.1080006@gont.com.ar> In-Reply-To: <4B60A022.1080006@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-01-27_10:2010-01-20, 2010-01-27, 2010-01-27 signatures=0 Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 21:34:58 -0000 This is as a WG participant, not a co-chair. As some of the document heritage predates me co-chairing, I'd have to take a very careful look at mail archives and meeting minutes in order to say anything about consensus in a co-chair role. That said ... I would appreciate less posturing about representing vendors and maintaining relevancy to them, and more focus on what potential action we can take to resolve the DISCUSSes. My contributions toward that are inline below. -- Wes Eddy MTI Systems >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Fernando Gont >Sent: Wednesday, January 27, 2010 3:21 PM >To: Lars Eggert >Cc: tcpm@ietf.org WG >Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 > > >> I have one main issue. The very detailed example of the operation of >> the mitigation technique in Section 7.3, and especially the pseudo >> code that implements what the document still calls the "proposed" >> solutions in Section 7.4 in my opinion go beyond the WG consensus we >> had, which was to document and discuss the mitigation techniques >> implemented in current stacks. > >The pseudo-code is just that: documentation of how the counter-measure >works. While there's also verbose description of how the counter-measure >works, I'd argue that for many of us the pseudo-code ends-up being a >clearer explanation. > >That said, this text has been in the I-D since >draft-gont-tcpm-icmp-attacks-04.txt (circa September 5, 2005), when it >had not yet been adopted as a wg item. I has been four and a half years >since that, an plenty of revisions since then. And the I-D has passed >WGLC. When I checked on this myself, it was indeed representing what's been accepted into some implementations. I believe Fernando has done the right thing at the beginning of section 7.2 by mentioning right away that PLPMTUD eliminates this vulnerability. I did not really see strong WG consensus as to whether PLPMTUD should be recommended more strongly as a mitigation in lieu of the rest of section 7.2, 7.3, and 7.4, and those sections do provide useful explanation and rationale of what's been implemented, in my opinion. I personally think PLPMTUD is a much better thing to recommend, but see the argument about convergence time may be valid, and the WG didn't seem to express strong favor in either direction on this matter. * However, Lars is entirely right that this could be worded more clearly as an implemented behavior rather than a proposal that we're making as the WG. This was always the WG consensus of the document's purpose, from what I can tell. * I think one way to proceed is, for instance, to reword: """ Section 7.3 shows the proposed counter-measure in action. Section 7.4 shows the proposed counter-measure in pseudo-code. This behavior has been implemented in NetBSD [NetBSD] and OpenBSD [OpenBSD] since 2005. """ into: """ Sections 7.3 and 7.4 show the behavior and psuedocode for the mitigation implemented in NetBSD and OpenBSD. """ and do a find-replace of the word "proposed" as appropriate in the rest of the section in order to convey what we really mean: that this is what's being done, not what TCPM necessarily says people need to do. > >> I'd be interested to hear the WG's thoughts esp. on this issue, but >> of course also on the rest of my comments below. > >Are we kinda going back to WGLC? I think Lars is just asking to quickly confirm consensus in this area and make sure the exact text represents that consensus. >> Section 1., paragraph 5: >>> This document aims to raise awareness of the use of ICMP to perform >>> a variety of attacks against TCP, and discusses several counter- >>> measures that eliminate or minimize the impact of these attacks. >>> Most of the these counter-measures can be implemented while still >>> remaining compliant with the current specifications, as they simply >>> describe reasons for not taking the advice provided in the >>> specifications in terms of "SHOULDs", but still comply with the >>> requirements stated as "MUSTs". >> >> Recommend to add a sentence that this document does NOT constitute an >> IETF recommendation to implement said countermeasures, and why. > >Being an informational document, it does not constitute an IETF >recommendation. > >That said, why it's not a formal IETF recommendation... that's a very >good question, that not only me, but also vendors would like to know the >answer. They are very much welcome to approach with a proposal to standardize it ... however, they haven't so the topic is moot. None of us need to try to channel them and speak for them here; the list is open, and last I checked, there were hundreds of addresses of the form "vendor.com" subscribed. As RFC tracks are frequently misunderstood, the sentence Lars proposes seems useful and uncontroversial to me. I'm not sure why we can't just add it as there's no harm done by it. >I do recall somebody making a comment in an IETF meeting that I attended >(back in 2005), asking "why not informational?", and we ended up >changing from std track to informational. > >It remains an interesting question why we insist in ignoring >reality-based world.... (but you know I have already debated this one). > >If you ask this question again, I'm afraid you'll get a response from >me, and another one from Joe (and probably not many others). Vendors, >and people in general working in real-world code have already applied >most of the stuff discussed in the I-D, and probably won't bother >getting into this type of debate. > >Actually, all this endless debates about "you might receive an ICMP >error message after five minutes... so you shouldn't implement this", or >"it's incorrect to do this unless you know for sure you're under attack" >is IMO far from the "E" in "IETF", and the reason many of the >implementers we'd need to join the list, don't. We're seen as not >belonging to reality-based world. Veering off-topic ... can we table this type of discussion? It's not conducive to resolving the questions at hand. >> Section 7.3., paragraph 0: >>> 7.3. The counter-measure for the PMTUD attack in action >> >> DISCUSS: Section 7.3 is in my opinion going into way too much detail >> for the purposes of this ID. The extremely detailed example in >> Sections 7.3.1-7.3.4 should really go into a specification of the >> mitigation technique (for which we have no WG consensus) and is IMO >> not needed in this Informational document. > >Again, this has been in the I-D for more than four years (these >particular sections even predate the pseudo-code). And they document and >explain the counter-measure. If we don't include this, the reader has to >figure this out for himself. I don't know why we insist so much in >making documents irrelevant, rather than useful, to the reader. I would agree with Fernando on this. I expressed a similar concern as Lars does a year or so ago, and there didn't seem to be much significant feeling on this from the rest of the WG. As long as this material is hedged correctly as explaining the implemented behavior, I think the WG consensus of describing implemented behavior is met. We are just describing it in incredible detail rather than giving a high-level view. This is not necessarily bad, I think. >> Section 7.4., paragraph 0: >>> 7.4. Pseudo-code for the counter-measure for the blind >>> performance- degrading attack >> >> DISCUSS: I believe it is fully out of scope for this Informational >> document to include pseudo code for a mechanism that the WG has >> decided to not recommend as PS. > >The document was adopted with this section in place, has gone through >plenty of revisions since then (i.e., 2005), has been reviewed by >implementers more than probably any other I-D that this working group >has produced, and has passed WGLC with this text in place. > >This is not the first time that you seem to ignore wg consensus (it has >happened with the draft-ietf-tcp-security already, as noted off-list at >the time). IMO, this discourages people in general, and particularly >implementers, to get involved in the IETF process in general, and with >TCPM in particular. Veering off track again ... please table this. As mentioned above, I think if the section's content is hedged correctly as describing the implementation that exists, rather than a WG-proposed behavior, then we'll be within consensus. From touch@ISI.EDU Wed Jan 27 14:13:34 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374EF3A6990 for ; Wed, 27 Jan 2010 14:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZKLXUcKoV21 for ; Wed, 27 Jan 2010 14:13:29 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E328C3A6867 for ; Wed, 27 Jan 2010 14:13:28 -0800 (PST) Received: from [70.213.65.212] (212.sub-70-213-65.myvzw.com [70.213.65.212]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o0RMDKKA007135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jan 2010 14:13:23 -0800 (PST) Message-ID: <4B60BA7F.7050308@isi.edu> Date: Wed, 27 Jan 2010 14:13:19 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> <4B60A022.1080006@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF818BA001DA5606A0B9E727E" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org WG" , Fernando Gont Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 22:13:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF818BA001DA5606A0B9E727E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, I'd like to second all of Wes's* points below. I don't have a problem with including the code; it may be unnecessary, but lots of informational docs have exactly that kind of detail to explain things. I do agree that it would be useful to avoid the term "proposed", as the WG consensus as I recall it was to document what was implemented and discuss the issues thereof, but not to make a recommendation. I also agree with Lars's suggestion (and Wes's concurrence) that it would be useful to be explicit in the fact that this doc does not make such a recommendation. I won't belabor other points below; I think Wes said it nicely. Joe ----- * PS - anyone have a good pointer to how to turn proper nouns that end in 's' into possessive adjectives? I found a few, and at least one suggests that "genitive of origin" always adds the 's' ;-) Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > This is as a WG participant, not a co-chair. As some of > the document heritage predates me co-chairing, I'd have to > take a very careful look at mail archives and meeting > minutes in order to say anything about consensus in a > co-chair role. >=20 > That said ... >=20 > I would appreciate less posturing about representing vendors > and maintaining relevancy to them, and more focus on what > potential action we can take to resolve the DISCUSSes. >=20 > My contributions toward that are inline below. >=20 > -- > Wes Eddy > MTI Systems >=20 >=20 >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf O= f >> Fernando Gont >> Sent: Wednesday, January 27, 2010 3:21 PM >> To: Lars Eggert >> Cc: tcpm@ietf.org WG >> Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 >> >> >>> I have one main issue. The very detailed example of the operation of >>> the mitigation technique in Section 7.3, and especially the pseudo >>> code that implements what the document still calls the "proposed" >>> solutions in Section 7.4 in my opinion go beyond the WG consensus we >>> had, which was to document and discuss the mitigation techniques >>> implemented in current stacks. >> The pseudo-code is just that: documentation of how the counter-measure= >> works. While there's also verbose description of how the counter-measu= re >> works, I'd argue that for many of us the pseudo-code ends-up being a >> clearer explanation. >> >> That said, this text has been in the I-D since >> draft-gont-tcpm-icmp-attacks-04.txt (circa September 5, 2005), when it= >> had not yet been adopted as a wg item. I has been four and a half year= s >> since that, an plenty of revisions since then. And the I-D has passed >> WGLC. >=20 >=20 > When I checked on this myself, it was indeed representing > what's been accepted into some implementations. >=20 > I believe Fernando has done the right thing at the beginning of > section 7.2 by mentioning right away that PLPMTUD eliminates > this vulnerability. I did not really see strong WG consensus > as to whether PLPMTUD should be recommended more strongly as > a mitigation in lieu of the rest of section 7.2, 7.3, and 7.4, > and those sections do provide useful explanation and rationale > of what's been implemented, in my opinion. I personally > think PLPMTUD is a much better thing to recommend, but see > the argument about convergence time may be valid, and the WG > didn't seem to express strong favor in either direction on this > matter. >=20 > * > However, Lars is entirely right that this could be worded more > clearly as an implemented behavior rather than a proposal that > we're making as the WG. This was always the WG consensus of the > document's purpose, from what I can tell. > * >=20 > I think one way to proceed is, for instance, to reword: > """ > Section 7.3 shows the proposed counter-measure in action. > Section 7.4 shows the proposed counter-measure in pseudo-code. >=20 > This behavior has been implemented in NetBSD [NetBSD] and OpenBSD > [OpenBSD] since 2005. > """ > into: > """ > Sections 7.3 and 7.4 show the behavior and psuedocode for the > mitigation implemented in NetBSD and OpenBSD. > """ > and do a find-replace of the word "proposed" as appropriate in the > rest of the section in order to convey what we really mean: that > this is what's being done, not what TCPM necessarily says people > need to do. >=20 >=20 >>> I'd be interested to hear the WG's thoughts esp. on this issue, but >>> of course also on the rest of my comments below. >> Are we kinda going back to WGLC? >=20 >=20 > I think Lars is just asking to quickly confirm consensus in this area > and make sure the exact text represents that consensus. >=20 >=20 >>> Section 1., paragraph 5: >>>> This document aims to raise awareness of the use of ICMP to perform >>>> a variety of attacks against TCP, and discusses several counter- >>>> measures that eliminate or minimize the impact of these attacks. >>>> Most of the these counter-measures can be implemented while still >>>> remaining compliant with the current specifications, as they simply >>>> describe reasons for not taking the advice provided in the >>>> specifications in terms of "SHOULDs", but still comply with the >>>> requirements stated as "MUSTs". >>> Recommend to add a sentence that this document does NOT constitute an= >>> IETF recommendation to implement said countermeasures, and why. >> Being an informational document, it does not constitute an IETF >> recommendation. >> >> That said, why it's not a formal IETF recommendation... that's a very >> good question, that not only me, but also vendors would like to know t= he >> answer. >=20 >=20 >=20 > They are very much welcome to approach with a proposal to > standardize it ... however, they haven't so the topic is moot. > None of us need to try to channel them and speak for them here; > the list is open, and last I checked, there were hundreds of > addresses of the form "vendor.com" subscribed. >=20 > As RFC tracks are frequently misunderstood, the sentence Lars > proposes seems useful and uncontroversial to me. I'm not sure > why we can't just add it as there's no harm done by it. >=20 >=20 >=20 >> I do recall somebody making a comment in an IETF meeting that I attend= ed >> (back in 2005), asking "why not informational?", and we ended up >> changing from std track to informational. >> >> It remains an interesting question why we insist in ignoring >> reality-based world.... (but you know I have already debated this one)= =2E >> >> If you ask this question again, I'm afraid you'll get a response from >> me, and another one from Joe (and probably not many others). Vendors, >> and people in general working in real-world code have already applied >> most of the stuff discussed in the I-D, and probably won't bother >> getting into this type of debate. >> >> Actually, all this endless debates about "you might receive an ICMP >> error message after five minutes... so you shouldn't implement this", = or >> "it's incorrect to do this unless you know for sure you're under attac= k" >> is IMO far from the "E" in "IETF", and the reason many of the >> implementers we'd need to join the list, don't. We're seen as not >> belonging to reality-based world. >=20 >=20 > Veering off-topic ... can we table this type of discussion? It's > not conducive to resolving the questions at hand. >=20 >=20 >>> Section 7.3., paragraph 0: >>>> 7.3. The counter-measure for the PMTUD attack in action >>> DISCUSS: Section 7.3 is in my opinion going into way too much detail >>> for the purposes of this ID. The extremely detailed example in >>> Sections 7.3.1-7.3.4 should really go into a specification of the >>> mitigation technique (for which we have no WG consensus) and is IMO >>> not needed in this Informational document. >> Again, this has been in the I-D for more than four years (these >> particular sections even predate the pseudo-code). And they document a= nd >> explain the counter-measure. If we don't include this, the reader has = to >> figure this out for himself. I don't know why we insist so much in >> making documents irrelevant, rather than useful, to the reader. >=20 >=20 > I would agree with Fernando on this. I expressed a similar > concern as Lars does a year or so ago, and there didn't > seem to be much significant feeling on this from the rest of > the WG. As long as this material is hedged correctly as > explaining the implemented behavior, I think the WG consensus > of describing implemented behavior is met. We are just > describing it in incredible detail rather than giving a > high-level view. This is not necessarily bad, I think. >=20 >=20 >=20 >>> Section 7.4., paragraph 0: >>>> 7.4. Pseudo-code for the counter-measure for the blind >>>> performance- degrading attack >>> DISCUSS: I believe it is fully out of scope for this Informational >>> document to include pseudo code for a mechanism that the WG has >>> decided to not recommend as PS. >> The document was adopted with this section in place, has gone through >> plenty of revisions since then (i.e., 2005), has been reviewed by >> implementers more than probably any other I-D that this working group >> has produced, and has passed WGLC with this text in place. >> >> This is not the first time that you seem to ignore wg consensus (it ha= s >> happened with the draft-ietf-tcp-security already, as noted off-list a= t >> the time). IMO, this discourages people in general, and particularly >> implementers, to get involved in the IETF process in general, and with= >> TCPM in particular. >=20 >=20 > Veering off track again ... please table this. >=20 > As mentioned above, I think if the section's content is hedged > correctly as describing the implementation that exists, rather > than a WG-proposed behavior, then we'll be within consensus. >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------enigF818BA001DA5606A0B9E727E 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.9 (MingW32) iEYEARECAAYFAktgun8ACgkQE5f5cImnZruihwCgnSJACt8ZPGkHssaKkVxeiDY5 B9QAoMwKjDBRklvyLnznsHhTKngPBqv2 =w1Ig -----END PGP SIGNATURE----- --------------enigF818BA001DA5606A0B9E727E-- From fernando.gont.netbook.win@gmail.com Wed Jan 27 14:34:51 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789833A69D0 for ; Wed, 27 Jan 2010 14:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPy28A0GyNkN for ; Wed, 27 Jan 2010 14:34:50 -0800 (PST) Received: from mail-yx0-f123.google.com (mail-yx0-f123.google.com [209.85.210.123]) by core3.amsl.com (Postfix) with ESMTP id 8EB053A635F for ; Wed, 27 Jan 2010 14:34:50 -0800 (PST) Received: by yxe29 with SMTP id 29so13780yxe.5 for ; Wed, 27 Jan 2010 14:35:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=7MSG07XSaF0el9rPj55iBa0wAKZOTzna4uquhLeLpjk=; b=DL5VdYdsDFHILBu4i94Mlj4ok/PLMAsaV8fbqQF9gtU447+59VZ1OWMS741SE6cLrd FWeqvLNA0Zk9eBC024vFLxdfOYulzCOfq9KpPzrLDV3/2OGmKLhfEGhiiMhAOnR+YocF XF4Ec3ZDjcLoQXeVeoWRMYyxPJaQgee6p+HwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=yHC2MsybMbvBrb7bwIB/GoU+iEhIKB+xhJ82Fz0qpIzWJQ3i4Q6Ve7HvVw7qNo4jzN /OBNO4q1vi68CBaduvhmseKSO7v2S7XbENCSj+pWjj2OTmOO5tEtHSuVPSsh+Sh4Z0oY Ht1pN7H7DJ958sFS6qqNtqZn7l18bJ7R+ixuI= Received: by 10.101.168.27 with SMTP id v27mr13045545ano.45.1264631702088; Wed, 27 Jan 2010 14:35:02 -0800 (PST) Received: from ?190.48.216.120? ([190.48.216.120]) by mx.google.com with ESMTPS id 22sm117174yxe.3.2010.01.27.14.35.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Jan 2010 14:35:01 -0800 (PST) Sender: Fernando Gont Message-ID: <4B60BF86.8080100@gont.com.ar> Date: Wed, 27 Jan 2010 19:34:46 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> <4B60A022.1080006@gont.com.ar> <4B60BA7F.7050308@isi.edu> In-Reply-To: <4B60BA7F.7050308@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 22:34:51 -0000 Hello, Joe, > I do agree that it would be useful to avoid the term "proposed", as the > WG consensus as I recall it was to document what was implemented and > discuss the issues thereof, but not to make a recommendation. I agreed to remove any instances of "proposed" (Actually, I really meant to eliminate them... it seems I just missed a few of them). > I also agree with Lars's suggestion (and Wes's concurrence) that it > would be useful to be explicit in the fact that this doc does not make > such a recommendation. I have no problem with that, either. Would something like this text from the soft-errors RFC address this issue?: > We note that the counter-measures discussed in this documentare not > part of standard TCP behavior and this document does not change that > state of affairs. The consensus of the TCPM WG (TCP Maintenance and > Minor Extensions Working Group) was to document this widespread > implementation of nonstandard TCP behavior but to not change the > TCP standard. Note: I believe some of the countermeasures may be within the specs in that they are reasons for not applying some of the "SHOULDs". But at this point in time, I don't feel like committing yet more energy to fight this one... so I'd be happy about including the above check. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Wed Jan 27 14:45:44 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10BCD3A6809 for ; Wed, 27 Jan 2010 14:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdexQS8JbQYa for ; Wed, 27 Jan 2010 14:45:43 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 540B33A69DB for ; Wed, 27 Jan 2010 14:45:43 -0800 (PST) Received: from [70.213.65.212] (212.sub-70-213-65.myvzw.com [70.213.65.212]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o0RMjgr6013570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jan 2010 14:45:45 -0800 (PST) Message-ID: <4B60C215.6000502@isi.edu> Date: Wed, 27 Jan 2010 14:45:41 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> <4B60A022.1080006@gont.com.ar> <4B60BA7F.7050308@isi.edu> <4B60BF86.8080100@gont.com.ar> In-Reply-To: <4B60BF86.8080100@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig270F120A8A7C453FBFA999F0" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 22:45:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig270F120A8A7C453FBFA999F0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando, See below... Fernando Gont wrote: > Hello, Joe, >=20 >> I do agree that it would be useful to avoid the term "proposed", as th= e >> WG consensus as I recall it was to document what was implemented and >> discuss the issues thereof, but not to make a recommendation. >=20 > I agreed to remove any instances of "proposed" (Actually, I really mean= t > to eliminate them... it seems I just missed a few of them). >=20 >> I also agree with Lars's suggestion (and Wes's concurrence) that it >> would be useful to be explicit in the fact that this doc does not make= >> such a recommendation. >=20 > I have no problem with that, either. Would something like this text fro= m > the soft-errors RFC address this issue?: >=20 >> We note that the counter-measures discussed in this documentare not= =20 >> part of standard TCP behavior and this document does not change tha= t=20 >> state of affairs. The consensus of the TCPM WG (TCP Maintenance an= d=20 >> Minor Extensions Working Group) was to document this widespread=20 >> implementation of nonstandard TCP behavior but to not change the=20 >> TCP standard. Useful to fix the typo (documentare -> document are). I prefer some of the text Wes provided. The text above just says "we're not changing the spec". Wes had an additional tone of "and we aren't even making any recommendations" (e.g., on how to interpret SHOULDs). Joe --------------enig270F120A8A7C453FBFA999F0 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.9 (MingW32) iEYEARECAAYFAktgwhUACgkQE5f5cImnZrsqHgCfTDjw6NnyzriQNMmBb3FvbK0+ XwwAmwbbcV8AzFtbfZc9AKABrbLg3GAy =rtqW -----END PGP SIGNATURE----- --------------enig270F120A8A7C453FBFA999F0-- From root@core3.amsl.com Wed Jan 27 16:00:01 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 869333A68C0; Wed, 27 Jan 2010 16:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100128000001.869333A68C0@core3.amsl.com> Date: Wed, 27 Jan 2010 16:00:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-early-rexmt-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 00:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Early Retransmit for TCP and SCTP Author(s) : M. Allman, K. Avrachenkov, U. Ayesta, E. Blanton, P. Hurtig Filename : draft-ietf-tcpm-early-rexmt-04.txt Pages : 12 Date : 2010-1-27 This document proposes a new mechanism for TCP and SCTP that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-early-rexmt-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-early-rexmt-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-1-27154746.I-D@ietf.org> --NextPart-- From lars.eggert@nokia.com Wed Jan 27 22:28:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E855A3A6856 for ; Wed, 27 Jan 2010 22:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.604 X-Spam-Level: X-Spam-Status: No, score=-6.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+L-j-4E+rlX for ; Wed, 27 Jan 2010 22:27:47 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 27C253A69CB for ; Wed, 27 Jan 2010 22:27:43 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0S6R7fC012777; Thu, 28 Jan 2010 00:27:08 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 08:27:07 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 08:27:06 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0S6R5I9019274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 08:27:05 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-8-737487570; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4B60A3EC.20308@gont.com.ar> Date: Thu, 28 Jan 2010 08:26:52 +0200 Message-Id: References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> <4B60A3EC.20308@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Thu, 28 Jan 2010 08:26:58 +0200 (EET) X-OriginalArrivalTime: 28 Jan 2010 06:27:07.0022 (UTC) FILETIME=[E9F78AE0:01CA9FE2] X-Nokia-AV: Clean Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 06:28:02 -0000 --Apple-Mail-8-737487570 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-1-27, at 22:37, Fernando Gont wrote: > Comments in-line.... (I have removed those changes that I will apply = as > suggested, and that didn't require further discussion). I'll do the same in this reply. >> INTRODUCTION, paragraph 13: >>> Copyright Notice >>=20 >> You're using the IETF Trust Provisions' Section 6.b License Notice=20 >> from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See >> http://trustee.ietf.org/license-info/) >=20 > There was no way (other manual) to fix this (at least when the last = rev > of the document was published). That said, the "grace period" = announced > by the IETF Trust still lasts till February 1st, so there's no problem > with the old boilerplate text. Yes, but it's unlikely that the final revision will be submitted before = Feb 1? IETF Last Call and IESG Review are still coming. >> Section 5.2., paragraph 13: >>> Based on this analysis, most popular TCP implementations treat all >>=20 >> Odd wording. I doubt that the analysis in this ID has caused existing >> TCP implementations to change years ago. Do you mean "An analysis of >> most popular TCP implementations has shown..."? >=20 > No, I meant what I wrote: Those implementations that already included > the hard_errors -> soft_errors processing did so for the same reason > stated in the draft (e.g., I did talk with Kirk McKusick back in 2005 > and these guys (and others) got to the same conclusion (e.g., > hard-errors -> soft-errors) through the same analysis). That said, = other > implementations implemented this in response to this I-D (e.g., Cisco, > Microsoft, and others). Please see the "ICMP attacks" advisories = linked > in: http://www.gont.com.ar/advisories/index.html (and there are = others). But this is a TCPM WG document, and it was your personal involvement = that caused the changes, and not the TCPM WG document. So it wasn't = "this analysis" in the sense of this document, but "an analysis done by = someone who now happens to be editor of the WG document." >> Section 7.1., paragraph 1: >>> systems determine the Path MTU of an arbitrary internet path. >>=20 >> Nit: s/internet/Internet/ (also in many other places in the ID) >=20 > I did mean "internet". The mechanism works if you're using it in e.g. = a > corporate network that is not connected to the Internet. So that by "internet" you mean "IP-based isolated network" was = completely lost on me. Is this really an important point? Why wouldn't a = technique for this that works on the Internet work for isolated = deployments? And if it does, why don't you simply say "Internet"? >> I thought most modern operating systems didn't use hard IRQs anymore >> in their stacks? Isn't it all soft-interrupts or similar now? (I do >> agree that packet processing overhead per payload byte goes up with >> smaller packets, but I don't think it's because of IRQs.) >=20 > Would you be happier with "increased interrupt and context-switching = rate"? I'd just talk about increased processing overheads, but this isn't a = terribly important issue. >> Section 7.2., paragraph 1: >>> The IETF has standardized a Path-MTU Discovery mechanism called=20 >>> "Packetization Layer Path MTU Discovery" that does not depend on=20 >>> ICMP error messages. Implementation of the aforementioned=20 >>> mechanism in replacement of the traditional PMTUD (specified in=20 >>> [RFC1191] and [RFC1981]) would eliminate this vulnerability.=20 >>> However, it might also lead to an increase of the PMTUD convergence >>> time. >>=20 >> Add a citation to RFC4821 here. Also, why the conjunctive? PLPMTUD=20 >> *does* eliminate this vulnerability. >=20 > PLPMTUD can be implemented with or without ICMP support (i.e., as a > replacement for classical PMTUD, or for black-hole detection). > Therefore, it does not necessarily eliminate this vulnerability. OK, but then say this in the document. It wasn't clear to me at all that = you tried to allude to that by saying "would eliminate." >> Section 7.2., paragraph 11: >>> On the other hand, maxsizeacked holds the size (in octets) of the=20 >>> largest packet that has so far been acknowledged for this=20 >>> connection. It is initialized to 68 (the minimum IPv4 MTU) when the >>> underlying internet protocol is IPv4, and is initialized to 1280=20 >>> (the minimum IPv6 MTU) when the underlying internet protocol is=20 >>> IPv6. Whenever an acknowledgement for a packet larger than=20 >>> maxsizeacked octets is received, maxsizeacked is set to the size of >>> that acknowledged packet. >>=20 >> Maybe I'm dense, but how does this work with delayed ACKs? If you see >> the left edge of the window shift by n bytes, you don't know that=20 >> maxsizeacked is n bytes, right? >=20 > Correct. The worst-case scenario is that you do the "path mtu update > phase" rather than "initial path mtu discovery". i.e., the mechanism > fails on the safe side. Let's discuss this for a second to make sure I understand this = correctly. The definition for acked_packet_size is: "Variable holding the packet = size (data, plus headers) the ACK that has just been received is = acknowledging." But that's actually not accurate, because an incoming = ACK doesn't ACK a specific transmitted segment - all you know when you = receive an ACK is that the left edge of the window moved by a certain = amount. Is acked_packet_size simply set to that amount? If yes, then with delayed ACKs (or otherwise in corner cases) = acked_packet_size is actually larger than maxsizesent always. On second = reading, I don't think that's a problem for the technique, but the name = and description of the variable confused me earlier. >> Section 7.2., paragraph 20: >>> MAXSEGRTO can be set, in principle, to any value greater than or=20 >>> equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the=20 >>> traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A >>> MAXSEGRTO of 1 provides enough protection for most cases. In any >>> case, implementations are free to choose higher values for this=20 >>> constant. MAXSEGRTO could be a function of the Next-Hop MTU=20 >>> claimed in the received ICMP "Packet Too Big" message. That is,=20 >>> higher values for MAXSEGRTO could be imposed when the received ICMP >>> "Packet Too Big" message claims a Next-Hop MTU that is smaller >>> than some specified value. >>=20 >> Which value do the different implementations you surveyed use for=20 >> MAXSEGRTO? >=20 > They use a MAXSEGRTO of 1. I wrote and commited the OpenBSD > implementation myself. NetBSD ported the one in OpenBSD to their OS, = so > they use the same MAXSEGRTO. I forgot to say in my original comment that that may be interesting = information to put in the draft, for readers who are wondering. >> Section 7.2., paragraph 22: >>> Section 7.3 shows the proposed counter-measure in action. Section=20 >>> 7.4 shows the proposed counter-measure in pseudo-code. >>=20 >> Since the publication target is Informational, calling this the=20 >> "proposed" something is slightly misleading. Can you rephrase this to >> be about what current implementations do? >=20 > I can, and I will. However, I think this has been overstressed for = this > I-D. It's an Informational I-D. So it should be clear from the target > itself and the Page-1 boilerplate to be used for the RFC that it does > not contain any "formal IETF recommendation". Not all readers know the differences between different types of RFCs, = and I'd prefer if the wording in the text was consistent with the = message that the WG wants to send about these mitigation techniques. Thanks, Lars= --Apple-Mail-8-737487570 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDEyODA2MjY1M1owIwYJKoZIhvcNAQkEMRYEFL/thWzpxZlUaXz6DBc1KFzT8ewSMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBtaKCzgrEyFjaKsn72oMaoS3Jez2sP2eQs+Adc6Ve6Gxqba3PNSf5Z2TFCYRLzEAEr25S4 ZdQdk1UDryyDA6cZnJ+cJi7xNB9Mjv08FqcGdLYs7SD9XC1K9A9moO9IsIpDsQQUFNCoW2REWcDo UYmBvmUY3rGeJc6JRt9gP9p56RZesxDAVLgPYg4J/GxQab7VWGYHuFM7xR22jJC+lwKiahAENY/N bnm3Wr+UDPoaVfrsrOvgbVlTOFu2R8y4m75X/X3+tCk1zkoyDrJjyp9sW9Y1ypESf6JykklM+BBQ D34PakKYTyZSNZsGNdiZiEUVsNP68A7Y+rtG1+IpTiCrAAAAAAAA --Apple-Mail-8-737487570-- From lars.eggert@nokia.com Wed Jan 27 22:30:36 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8DD23A69F2 for ; Wed, 27 Jan 2010 22:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.603 X-Spam-Level: X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zded0DA1Pq1r for ; Wed, 27 Jan 2010 22:30:35 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 5E4293A69F7 for ; Wed, 27 Jan 2010 22:30:34 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0S6TioR006642; Thu, 28 Jan 2010 08:29:59 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 08:29:46 +0200 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 08:29:46 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0S6Thcu028092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 08:29:44 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-9-737646945; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Thu, 28 Jan 2010 08:29:31 +0200 Message-Id: <46BF79F9-2E57-440A-A3D4-11F3F788FBB8@nokia.com> References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> <4B60A022.1080006@gont.com.ar> To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Thu, 28 Jan 2010 08:29:37 +0200 (EET) X-OriginalArrivalTime: 28 Jan 2010 06:29:46.0084 (UTC) FILETIME=[48C67A40:01CA9FE3] X-Nokia-AV: Clean Cc: "tcpm@ietf.org WG" , Fernando Gont Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 06:30:37 -0000 --Apple-Mail-9-737646945 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-1-27, at 23:35, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] = wrote: > and more focus on what > potential action we can take to resolve the DISCUSSes. Quick clarification: Those are obviously not IESG Review discusses, as = the document is still in AD Review. I just used the same term in my = review to indicate that I saw those as more important to discuss than = maybe some of the other ones. Lars= --Apple-Mail-9-737646945 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDEyODA2MjkzMlowIwYJKoZIhvcNAQkEMRYEFM4XnoKpg13tlYwLchwslAJZxRH+MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQATeFI+7Xijwm6CdwzUhnVi4KWANm13nIkfOC4kkka8E6qJppdw/vSexKMkV7TC0N4CJ0s+ BtyWJva9l357aTgdQ5mbafgjf0lGJNa7X4T039DYG9+mEN86rsC9nMm4Vir1QKwIXMbEpUjrkgT4 jJ+sKqPX6fxZqwRs75Tv8MgFukRoqJNZNmob8sTbygLpzsqidGM8KzXEkc3JELVnuIFBUdOKpmTb DXMrkMHb8E1fT1nBaM8SHLEWwifm8ZYf4+/99THKv1HCROHR2QrloIfzjt2fGJDFaJiu/sTHsHbU oK4dySC+ulYNGzzpauwUbtS65zZE1LGz2biAgIsqpSrHAAAAAAAA --Apple-Mail-9-737646945-- From wwwrun@core3.amsl.com Thu Jan 28 07:24:53 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 078423A6957; Thu, 28 Jan 2010 07:24:52 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100128152453.078423A6957@core3.amsl.com> Date: Thu, 28 Jan 2010 07:24:53 -0800 (PST) Cc: tcpm chair , tcpm mailing list , Internet Architecture Board , RFC Editor Subject: [tcpm] Document Action: 'Early Retransmit for TCP and SCTP' to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 15:24:53 -0000 The IESG has approved the following document: - 'Early Retransmit for TCP and SCTP ' as an Experimental 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-early-rexmt-04.txt Technical Summary This document proposes a new mechanism for TCP and SCTP that can be used to recover lost segments when a connection's congestion window is small. This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout. Document Quality There is limited implementation experience. There are no MIBs or other special items requiring expert review. Personnel Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. Lars Eggert (lars.eggert@nokia.com) reviewed it for the IESG. From A.Hoenes@TR-Sys.de Thu Jan 28 11:06:47 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08063A67AE for ; Thu, 28 Jan 2010 11:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiEG-gAe44in for ; Thu, 28 Jan 2010 11:06:46 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 342113A67BD for ; Thu, 28 Jan 2010 11:06:44 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA283095611; Thu, 28 Jan 2010 20:06:51 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA10585; Thu, 28 Jan 2010 20:06:49 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201001281906.UAA10585@TR-Sys.de> To: tcpm@ietf.org Date: Thu, 28 Jan 2010 20:06:49 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 19:06:47 -0000 A few notes triggered by the recent discussion: (1) "internet" vs. "Internet" >From FYI 12, the "Internet Users' Glossary" (RFC 1983): internet While an internet is a network, the term "internet" is usually used to refer to a collection of networks interconnected with routers. See also: network. Internet (note the capital "I") The Internet is the largest internet in the world. [...] [[ the subsequent text is mostly OBE ]] So it's been clear since decades that "internet" is the general term to be used in statements of general scope. For the sake of precision, "Internet" should not be used as "pars pro toto" term -- only when the statement to be made is specific to "The Internet" and does not hold more generally in connected networks (that might not be globally routable). Please note that the OPS Area has carefully banned "Internet" from documents related to the SMI and SNMP framework in order to emphasize that these technologies developed in the IETF are _not restricted_ to the (global) "Internet". (2) "the WG" What has been referred to as "the [TCPM] WG" in this thread is by most readers of the TCPM list seen as a tiny group of o^Hverl^Hy active contributors who overwhelm the discussion with iterated notorious statements which many folks that are not in a position to be able to constantly respond at a high rate got tired of over the years. TCPM, in an absolutely annoying manner, is short of ultimately failing its mission to "maintain" the TCP specifications. Maintenance in a rapidly changing world does not mean aseptical conservation of sacred documents in a holy grail; it means evolution, adoptation to requirements, and progress. Implementation experience and changing environments are getting ignored and neglected to a degree I rarely ever have seen in another WG. RFC 5681 is the only Standards-Track document ever published by this WG that resonably falls in the "TCP maintenance" category. Two "minor extensions" have been published on the Standards Track as well, but all other output of the WG so far is either Experimental or Informational. Note that one of these two "extensions" actually is limited to "detecting", and doesn't initiate protocol actions. That's why many folks do not contribute any more to the list, why vendors and implementors do not regularly comment any more on the list, and why the majority of *relevant* TCP related discussions aiming at progress is conducted off-(TCPM-)list now, according to my personal experience. Folks interested in learning what maintenance and constructive WG work and discussion means should look for examples; there are! Observing WGs successfully acting on protocol maintenance isn't difficult. Strong success factors are the tradional confidence in the normative power of robust, interoperable implementations combined with active WG process management and orientation on milestones (once agreed upon). For instance, we can now expect that the revised IKEv2 specification will be completed by mid-2010, within roughly 2 years (unless the IESG runs havoc against it), although the thourough review process has uncovered much more issues in the original specification than envisioned by IETF 72. In this case, implementers have been attracted by seeing their voices are being heard. On the contrary, TCPM has convinced many folks that it doesn't pay to participate. Changing their mind after they have been silenced and/or discouraged over several years will need a major effort and a clear commitment to progress. Seeing a WG constantly exercising the habit of "we're not changing the spec" (even when we admit it's poor, ambiguous, or OBE) and even "and we aren't even making any recommendations" is one of the main reasons why so few people voluntarily undertake the pain of being thrashed for their real-world arguments by a few loud and frequent voices on TCPM. People expect leadership and guidance from the IETF, not documents where "the WG" (see above) says: "Ouch, the authors brought experience and advice to us, but we did not feel comfortable with what we are chartered for and actually do not want to endorse any kind of real-world improvement." Do we really need some kind of "TCP-related Kaminsky++" attack demonstrated at 27C3 (or maybe 28C3 -- ask the web for 26C3 if you don't know) and failure of the IETF to actually maintain TCP reported in the press worldwide before this group is waking up and starting efficient work to bring the TCP specs in alignment with current requirements and generally agreed implementation practices, or do you want to continually further the predominant impression of a WG trying to conserve a clinically "clean", but mummified TCP specification -- up to the point that vendors and open-source TCP implementers regard IETF work there (or in general) as irrelevant for the evolution of the protocol(s)? This list should stop ignoring the "silent majority". >From time to time, ultimately someone's blood boils and he raises his voice on the list, but messages like msg05064 in December ... > ... on all fronts it has shown exactly how the IETF should not do > things. The fact that one vocal and nagging individual can usurp > and upset the effort and the ideas that originated with others was > definitely odd to me.. ... aren't going to be understood as an alarming sign by "the WG". They should! It cannot be denied that the TCPM processes are broken. That's a basic, general matter of fact. Everybody can find evidence in the archives. I've arbitrarily picked a TCPM charter snapshot (from May 2008) : | TCP Maintenance and Minor Extensions (tcpm) | | Last Modified: 2008-04-23 | | ... | | Goals and Milestones: | | ... | | Oct 2006 Submit revision of RFC 2581 to the IESG for publication | as a Draft Standard. (Sic. In May 2008. Time journey? Hibernation? Honest, at least.) As recorded today, with only one additional comment: [script] # ftp ftp.RFC-Editor.ORG [script] ... [script] ftp> dir in-notes/rfc5681.txt [script] 200 PORT command successful. [script] 150 Here comes the directory listing. [script] -rw-rw-r-- 1 6000 1000 44339 Sep 04 22:08 rfc5681.txt # i.e. 2009-09-04 [script] 226 Directory send OK. [script] ftp> ... | | ... | | Jan 2007 Submit ICMP attack document to the IESG for publication | as an Informational RFC. ... <2010-01-28 today> ??? ... At the same time (since early in 2008), there was a *wg* draft not even listed in the charter, about which the _current_ WG page, , reports: | ... | | draft-ietf-tcpm-1323bis -01 2009-03-04 Expired | | ... Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From fernando.gont.netbook.win@gmail.com Thu Jan 28 13:49:51 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6618B3A68F4 for ; Thu, 28 Jan 2010 13:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AAKnr7gqPFr for ; Thu, 28 Jan 2010 13:49:50 -0800 (PST) Received: from mail-yw0-f133.google.com (mail-yw0-f133.google.com [209.85.211.133]) by core3.amsl.com (Postfix) with ESMTP id E25433A688A for ; Thu, 28 Jan 2010 13:49:49 -0800 (PST) Received: by ywh39 with SMTP id 39so281656ywh.17 for ; Thu, 28 Jan 2010 13:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=P28/6TZNVPs5SPT7k2amko8cVtMyr1qAawC1Zu8MnmE=; b=wE0qJBoAmC5bx1eawlOZA3fmw4d4LDCmISTG4+LZUfmbVaeTAwU2PQCmHmUgJFjW2L oVVfL0wL8inGV9T1Rh2mQdyICP0iw1i1agZR9bQJilxA2eAVfmrc1YDfyE2RPyRrHh+f sE7Q+xv4FNl7zTyd3gnOEayUyVD+qUAHRHLK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=Xi5xAiUJ5fM4T1k008WulQVngWY1wDEa6fXxHNz9LWlniPbQI8Wxl9LxruTGHJdz02 P+Ca5ZLMfhdmsKsahx6+apLMCDjh5ZplTuvQSvKtbKUZGFrwVQ6jXxw2mGt4nQzbRUHV Npal1wIeuTWVHvkOt10loq+4/xV09EK6MB4t8= Received: by 10.151.25.16 with SMTP id c16mr535329ybj.44.1264715403530; Thu, 28 Jan 2010 13:50:03 -0800 (PST) Received: from ?192.168.0.100? (144-174-17-190.fibertel.com.ar [190.17.174.144]) by mx.google.com with ESMTPS id 9sm474942ywf.20.2010.01.28.13.49.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Jan 2010 13:50:02 -0800 (PST) Sender: Fernando Gont Message-ID: <4B6204F7.1070908@gont.com.ar> Date: Thu, 28 Jan 2010 18:43:19 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> <4B60A3EC.20308@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 21:49:51 -0000 Hello, Lars, >>> INTRODUCTION, paragraph 13: >>>> Copyright Notice >>> You're using the IETF Trust Provisions' Section 6.b License >>> Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec >>> 2009. (See http://trustee.ietf.org/license-info/) >> There was no way (other manual) to fix this (at least when the last >> rev of the document was published). That said, the "grace period" >> announced by the IETF Trust still lasts till February 1st, so >> there's no problem with the old boilerplate text. > > Yes, but it's unlikely that the final revision will be submitted > before Feb 1? IETF Last Call and IESG Review are still coming. Hopefully by that time xml2rfc will already support the new boilerplate? Or, if anybody can provide the correct boilerplate, I could manually edit the I-D. >> No, I meant what I wrote: Those implementations that already >> included the hard_errors -> soft_errors processing did so for the >> same reason stated in the draft (e.g., I did talk with Kirk >> McKusick back in 2005 and these guys (and others) got to the same >> conclusion (e.g., hard-errors -> soft-errors) through the same >> analysis). That said, other implementations implemented this in >> response to this I-D (e.g., Cisco, Microsoft, and others). Please >> see the "ICMP attacks" advisories linked in: >> http://www.gont.com.ar/advisories/index.html (and there are >> others). > > But this is a TCPM WG document, and it was your personal involvement > that caused the changes, and not the TCPM WG document. So it wasn't > "this analysis" in the sense of this document, but "an analysis done > by someone who now happens to be editor of the WG document." I don't get your point. The BSD people implemented the hard_errors-> soft_errors thing as a result of the same reasoning that is included in the icmp-attacks I-D. Other vendors applied this change in response to this I-D. (For the most part, they don't care about the "individual submission" vs. "wg item" thing, as you may have seen that they link the document as http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html which is supposed to always contain the latest revision). I'm not sure if this serves as a data point, but: many vendors that have a clue don't even care about the "Informational" vs. "bcp" vs. "std track" vs. "individual I-D" vs. "wg item i-d" -- particularly when it comes to security-related issues. It took us something like a year to adopt this I-D as a wg item, and more than five years to get it published as an RFC. Unless we do better time-wise, I'm afraid this situation is unlikely to change (not that I'm happy about it). >>> Section 7.1., paragraph 1: >>>> systems determine the Path MTU of an arbitrary internet path. >>> Nit: s/internet/Internet/ (also in many other places in the ID) >> I did mean "internet". The mechanism works if you're using it in >> e.g. a corporate network that is not connected to the Internet. > > So that by "internet" you mean "IP-based isolated network" was > completely lost on me. Is this really an important point? No. I mean any network that uses IETF technology, no matter whether its connected to the public Internet or not. > Why > wouldn't a technique for this that works on the Internet work for > isolated deployments? And if it does, why don't you simply say > "Internet"? Because Internet implies "the Internet" (i.e., the public Internet). >>> I thought most modern operating systems didn't use hard IRQs >>> anymore in their stacks? Isn't it all soft-interrupts or similar >>> now? (I do agree that packet processing overhead per payload byte >>> goes up with smaller packets, but I don't think it's because of >>> IRQs.) >> Would you be happier with "increased interrupt and >> context-switching rate"? > > I'd just talk about increased processing overheads, but this isn't a > terribly important issue. Ok. >>> Section 7.2., paragraph 1: >>>> The IETF has standardized a Path-MTU Discovery mechanism called >>>> "Packetization Layer Path MTU Discovery" that does not depend >>>> on ICMP error messages. Implementation of the aforementioned >>>> mechanism in replacement of the traditional PMTUD (specified in >>>> [RFC1191] and [RFC1981]) would eliminate this vulnerability. >>>> However, it might also lead to an increase of the PMTUD >>>> convergence time. >>> Add a citation to RFC4821 here. Also, why the conjunctive? >>> PLPMTUD *does* eliminate this vulnerability. >> PLPMTUD can be implemented with or without ICMP support (i.e., as a >> replacement for classical PMTUD, or for black-hole detection). >> Therefore, it does not necessarily eliminate this vulnerability. > > OK, but then say this in the document. It wasn't clear to me at all > that you tried to allude to that by saying "would eliminate." Ok. Will do. >>> Section 7.2., paragraph 11: >>>> On the other hand, maxsizeacked holds the size (in octets) of >>>> the largest packet that has so far been acknowledged for this >>>> connection. It is initialized to 68 (the minimum IPv4 MTU) when >>>> the underlying internet protocol is IPv4, and is initialized to >>>> 1280 (the minimum IPv6 MTU) when the underlying internet >>>> protocol is IPv6. Whenever an acknowledgement for a packet >>>> larger than maxsizeacked octets is received, maxsizeacked is >>>> set to the size of that acknowledged packet. >>> Maybe I'm dense, but how does this work with delayed ACKs? If you >>> see the left edge of the window shift by n bytes, you don't know >>> that maxsizeacked is n bytes, right? >> Correct. The worst-case scenario is that you do the "path mtu >> update phase" rather than "initial path mtu discovery". i.e., the >> mechanism fails on the safe side. > > Let's discuss this for a second to make sure I understand this > correctly. > > The definition for acked_packet_size is: "Variable holding the packet > size (data, plus headers) the ACK that has just been received is > acknowledging." But that's actually not accurate, because an incoming > ACK doesn't ACK a specific transmitted segment - all you know when > you receive an ACK is that the left edge of the window moved by a > certain amount. Is acked_packet_size simply set to that amount? Yes. > If yes, then with delayed ACKs (or otherwise in corner cases) > acked_packet_size is actually larger than maxsizesent always. Well, that depends on the amount of data you send. But yes, you could say that "acked_packet_size is actually larger than maxsizesent *usually*". > On > second reading, I don't think that's a problem for the technique, but > the name and description of the variable confused me earlier. Should I add a clarification? >>> Section 7.2., paragraph 20: >>>> MAXSEGRTO can be set, in principle, to any value greater than >>>> or equal to 0. Setting MAXSEGRTO to 0 would make TCP perform >>>> the traditional PMTUD mechanism defined in [RFC1191] and >>>> [RFC1981]. A MAXSEGRTO of 1 provides enough protection for >>>> most cases. In any case, implementations are free to choose >>>> higher values for this constant. MAXSEGRTO could be a function >>>> of the Next-Hop MTU claimed in the received ICMP "Packet Too >>>> Big" message. That is, higher values for MAXSEGRTO could be >>>> imposed when the received ICMP "Packet Too Big" message claims >>>> a Next-Hop MTU that is smaller than some specified value. >>> Which value do the different implementations you surveyed use for >>> MAXSEGRTO? >> They use a MAXSEGRTO of 1. I wrote and commited the OpenBSD >> implementation myself. NetBSD ported the one in OpenBSD to their >> OS, so they use the same MAXSEGRTO. > > I forgot to say in my original comment that that may be interesting > information to put in the draft, for readers who are wondering. Agreed. Will do. >>> Section 7.2., paragraph 22: >>>> Section 7.3 shows the proposed counter-measure in action. >>>> Section 7.4 shows the proposed counter-measure in pseudo-code. >>> Since the publication target is Informational, calling this the >>> "proposed" something is slightly misleading. Can you rephrase >>> this to be about what current implementations do? >> I can, and I will. However, I think this has been overstressed for >> this I-D. It's an Informational I-D. So it should be clear from the >> target itself and the Page-1 boilerplate to be used for the RFC >> that it does not contain any "formal IETF recommendation". > > Not all readers know the differences between different types of RFCs, > and I'd prefer if the wording in the text was consistent with the > message that the WG wants to send about these mitigation techniques. As I said, I have no problem with this. I will remove any remaining instances of "proposed". Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Thu Jan 28 14:02:48 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8BCC3A69A7 for ; Thu, 28 Jan 2010 14:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIGen-WKXAvc for ; Thu, 28 Jan 2010 14:02:47 -0800 (PST) Received: from mail-yw0-f133.google.com (mail-yw0-f133.google.com [209.85.211.133]) by core3.amsl.com (Postfix) with ESMTP id 5D40C3A69A6 for ; Thu, 28 Jan 2010 14:02:47 -0800 (PST) Received: by ywh39 with SMTP id 39so284069ywh.17 for ; Thu, 28 Jan 2010 14:03:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=9qE8dDBzoFhN1j6tngex4yPtaJWmOWsQIRPXYgThmt8=; b=ZUeh0gD8EPazy/qfb1Y2q2c5Bg9GOPXo+n7TbvldCN08b/m8pYwjYv4c+rAb5P83wH MBXJXJhOeAEiCsR2yQl0IFZFmu2vprdiZ7OakmhmcUrOpiad0g9EckAbM0uR9q+q7mlg rP418HxolI5qxOYrlgxISEJPdYS1ud7opDb8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=i5GtVbfkvkoNG+vCx9jwnTzyJd440pDfjdxj7IR70h31d/YgIPJJQaeag221y0M5ht yRNUXV8Ewos/pZ7JVL8nCMEm5qlF/+5/HOg3Dt3YPvfkoiE6xvbFgFNLpwzRPR86OEAU xItlqsXXKVSZFLtigUw9NVTr9+Kb2pa7LGRpQ= Received: by 10.101.134.16 with SMTP id l16mr2108384ann.119.1264716182364; Thu, 28 Jan 2010 14:03:02 -0800 (PST) Received: from ?192.168.0.100? (144-174-17-190.fibertel.com.ar [190.17.174.144]) by mx.google.com with ESMTPS id 9sm479945ywe.26.2010.01.28.14.02.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Jan 2010 14:03:01 -0800 (PST) Sender: Fernando Gont Message-ID: <4B620986.7020203@gont.com.ar> Date: Thu, 28 Jan 2010 19:02:46 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> <4B60A022.1080006@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 22:02:48 -0000 Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > I would appreciate less posturing about representing vendors > and maintaining relevancy to them, and more focus on what > potential action we can take to resolve the DISCUSSes. FWIW, I'm not claiming to represent vendors. However, I do chat with vendors from different fronts very often, and there is a general agreement on each of the issues I mentioned (specifications being outdated, the impossibility to produce a real-world TCP implementation from the IETF specs, the unnecessarily huge amount of energy that is spent on non-real issues, etc.). At this point in time, I just want to get this document published. But the points I have raised are very general issues that affect not only this I-D, but many other I-Ds that this WG is working on. > I think one way to proceed is, for instance, to reword: > """ > Section 7.3 shows the proposed counter-measure in action. > Section 7.4 shows the proposed counter-measure in pseudo-code. > > This behavior has been implemented in NetBSD [NetBSD] and OpenBSD > [OpenBSD] since 2005. > """ > into: > """ > Sections 7.3 and 7.4 show the behavior and psuedocode for the > mitigation implemented in NetBSD and OpenBSD. > """ > and do a find-replace of the word "proposed" as appropriate in the > rest of the section in order to convey what we really mean: that > this is what's being done, not what TCPM necessarily says people > need to do. Will do. >>> I'd be interested to hear the WG's thoughts esp. on this issue, but >>> of course also on the rest of my comments below. >> Are we kinda going back to WGLC? > > I think Lars is just asking to quickly confirm consensus in this area > and make sure the exact text represents that consensus. I have not problem with that, but... isn't this what the WGLC is for? >> That said, why it's not a formal IETF recommendation... that's a very >> good question, that not only me, but also vendors would like to know the >> answer. > > They are very much welcome to approach with a proposal to > standardize it ... however, they haven't so the topic is moot. > None of us need to try to channel them and speak for them here; > the list is open, and last I checked, there were hundreds of > addresses of the form "vendor.com" subscribed. This has been discussed in other threads and posts, so... in the hope of keeping a good signal/noise ratio, I will not respond. :-) Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Thu Jan 28 14:14:11 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 387B53A68B3 for ; Thu, 28 Jan 2010 14:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSEQKhwFGQmF for ; Thu, 28 Jan 2010 14:13:57 -0800 (PST) Received: from mail-yw0-f133.google.com (mail-yw0-f133.google.com [209.85.211.133]) by core3.amsl.com (Postfix) with ESMTP id 73C9C3A68A9 for ; Thu, 28 Jan 2010 14:13:56 -0800 (PST) Received: by ywh39 with SMTP id 39so286229ywh.17 for ; Thu, 28 Jan 2010 14:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=/VSgsE93Iz5bs+5zT1ndi2jDExnM0ncepbqpbkklk0o=; b=o4co8OdRr6ImwnLyKEWDtq2HQUfOLt1i8GRKXOLd6B9WgeiFepOQKrh3/xor74vGlT C41nOewMJGmxECWgCLufHoo0VIw7s+8AHnVmpr64H5TPOjY11zUQwFS1A2JW2zRcaIhu h701bl5m/3QiQ92S/uHWpryWojJ6JlfDHYfK8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=PY3mH9/o30B53eHumpJtfZGsI9G6XDbvcnlqT4njQFF1LX41ZccjbKgnZLfk8ost0A zyZ/90XjzhZaHcRGjCT6T6x5I8fvOvPK79wmU6gnycTg4LF2Erp8KlV8ku5BbKhTfj4w itZqmwDUdjP8hG+iWugJM5pq9eXBj7lp53D14= Received: by 10.100.75.12 with SMTP id x12mr6984174ana.151.1264716845633; Thu, 28 Jan 2010 14:14:05 -0800 (PST) Received: from ?192.168.0.100? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 4sm482041ywd.29.2010.01.28.14.14.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Jan 2010 14:14:04 -0800 (PST) Sender: Fernando Gont Message-ID: <4B620C1D.4060007@gont.com.ar> Date: Thu, 28 Jan 2010 19:13:49 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> <4B60A022.1080006@gont.com.ar> <4B60BA7F.7050308@isi.edu> <4B60BF86.8080100@gont.com.ar> <4B60C215.6000502@isi.edu> In-Reply-To: <4B60C215.6000502@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 22:14:11 -0000 Hello, Joe, >>> We note that the counter-measures discussed in this documentare not >>> part of standard TCP behavior and this document does not change that >>> state of affairs. The consensus of the TCPM WG (TCP Maintenance and >>> Minor Extensions Working Group) was to document this widespread >>> implementation of nonstandard TCP behavior but to not change the >>> TCP standard. > > Useful to fix the typo (documentare -> document are). Will do. > I prefer some of the text Wes provided. The text above just says "we're > not changing the spec". Wes had an additional tone of "and we aren't > even making any recommendations" (e.g., on how to interpret SHOULDs). Can you Wes provide the exact text you'd like me to include in the I-D, so that we can finish this? :-) Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From A.Hoenes@TR-Sys.de Thu Jan 28 16:10:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF493A688D for ; Thu, 28 Jan 2010 16:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.555 X-Spam-Level: X-Spam-Status: No, score=0.555 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeTxJVUTulTi for ; Thu, 28 Jan 2010 16:10:39 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 6E9D03A6867 for ; Thu, 28 Jan 2010 16:10:38 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA284393845; Fri, 29 Jan 2010 01:10:45 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA11140; Fri, 29 Jan 2010 01:10:44 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201001290010.BAA11140@TR-Sys.de> To: tcpm@ietf.org Date: Fri, 29 Jan 2010 01:10:44 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 -- boilerplate questions X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 00:10:40 -0000 Fernando Gont wrote: >> .. >> > Hopefully by that time xml2rfc will already support the new boilerplate? Definitely : NO. Don't bet. Manual edits needed so far. AFAICT (based on comments from M.T.Rose and Julian Reschke), xml2rfc is seeking new maintainer(s) and it's rather unlikely that the toolkits it is based on (and that turned out to be much less long-lived than expected and run out of fashion quickly) still share a large pool of potentially suitable volunteer guru candidates. Maybe xml2rfc needs to be re-implemented with the current tools of the week every time it needs to be updated. ;-) So we need to admit some more time, I guess. > Or, if anybody can provide the correct boilerplate, I could manually > edit the I-D. [[ ==> TBD Off-list ]] Indeed, currently you can find "normative" text (at layer 8+) on the IETF web site in support of exclusive use of almost all variants of now outdated boilerplate text. Upon explanation of the recent trouble to the administrative executives, the IETF chair has overtaken the reign. The most recent IESG minutes available online at report: > ... > > 1.3 Review of Action Items > > ... > > NEW > o Russ Housley will make sure that the documents that specify the > I-D boilerplate get updated to reflect the new alternate text. So there's hope that the online instructions will soon be aligned with the rules in force. Also there's some hope that the building blocks of the I-D and boilerplate text will be made available individually in .txt form on the IETF or IETF Trust web pages. Compiled RFC boilerplate based on TLP 4.0, RFC 5741, et al. can be copied from draft-reschke-hab-06.txt (and there are rumors that the RFC-Ed / RFC Production Center has made use of that I-D to update the nroff macros they use for RFC production). Further, there are good news regarding the long-pending project if the IESG working on revised specific boilerplate for I-Ds. The same minutes quoted above say: > ... > > 6. Management Issue > > 6.1 Update to the First-Page ID Boilerplate (Lars Eggert) > > The management issue was discussed. The IESG approved alternate > text to the first page I-D boilerplate. > > Action item: Russ Housley will make sure that the documents that > specify the I-D boilerplate get updated to reflect the new alternate > text. > > ... Kind regards, Alfred. From A.Hoenes@TR-Sys.de Thu Jan 28 16:29:41 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57AE53A683D for ; Thu, 28 Jan 2010 16:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.613 X-Spam-Level: X-Spam-Status: No, score=0.613 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxhM8HmlBdUK for ; Thu, 28 Jan 2010 16:29:40 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id E071B3A680A for ; Thu, 28 Jan 2010 16:29:39 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA284484987; Fri, 29 Jan 2010 01:29:47 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA11165; Fri, 29 Jan 2010 01:29:46 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201001290029.BAA11165@TR-Sys.de> To: tcpm@ietf.org Date: Fri, 29 Jan 2010 01:29:46 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] your responses to my comments on "the WG" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 00:29:41 -0000 Thanks to all ... for the overwhelming consenting and supportive feedback received so far (off-list) from listeners to the TCPM list, regarding my comments in item (2) "the WG" of my recent posting [1] ! It's really encouraging to see that the "silent majority" is not _always_ so silent. :-) Please admit that I'll not have the time to respond individually. As a matter of course and due diligence, I confirm that I will not disclose to any other person any names or affiliations of senders. Best regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ [1] From lars.eggert@nokia.com Thu Jan 28 22:08:48 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 133DA3A68AF for ; Thu, 28 Jan 2010 22:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.603 X-Spam-Level: X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvFVs-PvjC8z for ; Thu, 28 Jan 2010 22:08:46 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id DCB693A6805 for ; Thu, 28 Jan 2010 22:08:45 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0T68ioA003368; Fri, 29 Jan 2010 08:09:04 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 08:08:52 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 08:08:53 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0T68pHM007892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jan 2010 08:08:51 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-1-822799311; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <201001290029.BAA11165@TR-Sys.de> Date: Fri, 29 Jan 2010 08:08:44 +0200 Message-Id: <5E266815-608E-49E9-9398-418B9890EA15@nokia.com> References: <201001290029.BAA11165@TR-Sys.de> To: ah@tr-sys.de X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Fri, 29 Jan 2010 08:08:45 +0200 (EET) X-OriginalArrivalTime: 29 Jan 2010 06:08:53.0570 (UTC) FILETIME=[88A1C220:01CAA0A9] X-Nokia-AV: Clean Cc: "tcpm@ietf.org" Subject: Re: [tcpm] your responses to my comments on "the WG" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 06:08:48 -0000 --Apple-Mail-1-822799311 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I'd like to strongly encourage folks who have responded to Alfred = privately to discuss the perceived issue he has raised on the WG list.=20= A WG is what its contributors make it, and for it to change, for example = in the way that Alfred would like to see, requires a vocal majority and = not a silent majority. Thanks, Lars On 2010-1-29, at 2:29, ah@tr-sys.de wrote: > Thanks to all ... >=20 > for the overwhelming consenting and supportive feedback > received so far (off-list) from listeners to the TCPM list, > regarding my comments in item > (2) "the WG" > of my recent posting [1] !=20 >=20 > It's really encouraging to see that the "silent majority" > is not _always_ so silent. :-) >=20 > Please admit that I'll not have the time to respond individually. >=20 > As a matter of course and due diligence, I confirm that I will not > disclose to any other person any names or affiliations of senders. >=20 > Best regards, > Alfred. >=20 > --=20 >=20 > = +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. = | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 = | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de = | > = +------------------------+--------------------------------------------+ >=20 > [1] >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-1-822799311 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDEyOTA2MDg0NFowIwYJKoZIhvcNAQkEMRYEFOgZsF1UhgBwiaKNXpmKzPT2uVsNMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQC/lG0W5MWSL0WQw13B0B6QUXQDAK1Tq0XJ3vUq2BKmoLZs6nSdgD3Nop4EGCi9VYOTOsFW eNTTsNM5D2VbG3XXrc/lZ2S6DYJ43HuLMsQNjb/j7FQOQm+VSJkctobS7jZYkxHW6vUNxIVsfK1m s2ACCkrT6rzeLcfMPw2J+lC+Rf3aQZV4ngvVgJxFclc8YIzG3RzzpEC8RaZ2hxOI8BNNh+kOXfWt jmt6Gg2KJwxLBq6pw0Mzl3gV6ssIJsf2xegk9XTmD1ViptwAA2iBQCMg1xqRcksdh/3vutqIQE4J qKmdHajQ7r6to6CFonCXew1PVXdqXuJeYZyBHBCMRSFSAAAAAAAA --Apple-Mail-1-822799311-- From lars.eggert@nokia.com Thu Jan 28 22:14:04 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567763A692C for ; Thu, 28 Jan 2010 22:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.602 X-Spam-Level: X-Spam-Status: No, score=-6.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpjp4x8K8UOX for ; Thu, 28 Jan 2010 22:14:02 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id F141C3A68AF for ; Thu, 28 Jan 2010 22:14:01 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0T6E0Ow029514; Fri, 29 Jan 2010 00:14:22 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 08:14:17 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 08:14:17 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0T6EFGm014753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jan 2010 08:14:15 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-2-823123982; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert X-Priority: 1 In-Reply-To: <4b4bbba1.8502be0a.1327.ffff884b@mx.google.com> Date: Fri, 29 Jan 2010 08:14:08 +0200 Message-Id: <467024B3-4E75-435F-BB4E-DA8D793A545D@nokia.com> References: <4B3AB8BD.2070907@isi.edu> <4B3C3E6E.4050903@isi.edu> <588ADB01-E63F-4313-9F3F-35A2CE80C0F6@nokia.com> <0F25B30B-DF5A-4D3F-B120-54F5B58947CF@nokia.com> <4b4bbba1.8502be0a.1327.ffff884b@mx.google.com> To: draft-ietf-tcpm-tcp-auth-opt@tools.ietf.org, draft-lebovitz-ietf-tcpm-tcp-ao-crypto@tools.ietf.org X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Fri, 29 Jan 2010 08:14:09 +0200 (EET) X-OriginalArrivalTime: 29 Jan 2010 06:14:17.0478 (UTC) FILETIME=[49B23260:01CAA0AA] X-Nokia-AV: Clean Cc: "tcpm@ietf.org WG" Subject: [tcpm] status of auth-opt and auth-opt crypto? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 06:14:04 -0000 --Apple-Mail-2-823123982 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, authors, the WG was promised updates to auth-opt and auth-opt crypto weeks ago to = address the comments that arrived after WGLC. Where are they? The continued editing delays around what everyone agrees is an important = work item in TCPM are becoming embarrassing. Please set aside sufficient = cycles to complete this work quickly so we can publish, or find = co-editors who can. Thanks, Lars= --Apple-Mail-2-823123982 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDEyOTA2MTQwOVowIwYJKoZIhvcNAQkEMRYEFBn5QS6sB7U4k892aHdqIrs/KML3MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDiT58QbqDA4kB2frSwa6fLKj4InXMjEhEkL41IiMuuwgyJI8C1B8waRhbNHOhDeTsTf0Q1 6dZDTMLssARJQ2GyGqeuOt2N6wpa8Idn30+9AGlKwZikdXhR3ykDjlrAnKLaD83Q++Ls/icuwUHd a+lzGeCNzt1g/ahQEfMpsd5Us9Av7I35CR1C/MUDjSCG0hsHMF4UR+mjP566/EVcQwFzj7c9qNm9 uWNhS8r3QkGX+o28Z2LGTNpE/ab/Jde37kRgJs1qRgBlkIWJ7Yl7LvnWHxhUmUTNPomW1RLgj1rV hJ4yBl6CXEn+a4Hrt5uH1Jpdemld4PlRaMcQHQ0lV9yLAAAAAAAA --Apple-Mail-2-823123982-- From lars.eggert@nokia.com Fri Jan 29 01:22:41 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92D73A689C for ; Fri, 29 Jan 2010 01:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.602 X-Spam-Level: X-Spam-Status: No, score=-6.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxapYjIDQ0cj for ; Fri, 29 Jan 2010 01:22:41 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A4A4F3A6853 for ; Fri, 29 Jan 2010 01:22:40 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0T9MmMI014957 for ; Fri, 29 Jan 2010 11:22:59 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 11:22:51 +0200 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 11:22:51 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0T9MnLu021385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Jan 2010 11:22:50 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-8-834432794; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 29 Jan 2010 11:22:37 +0200 In-Reply-To: <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> To: "tcpm@ietf.org WG" References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> Message-Id: <3C666139-8AAA-4761-9D5E-E88A2FBABDE1@nokia.com> X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Fri, 29 Jan 2010 11:22:44 +0200 (EET) X-OriginalArrivalTime: 29 Jan 2010 09:22:51.0283 (UTC) FILETIME=[A13FD630:01CAA0C4] X-Nokia-AV: Clean Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 09:22:42 -0000 --Apple-Mail-8-834432794 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-1-27, at 15:35, Eggert Lars (Nokia-NRC/Espoo) wrote: > I have one main issue. The very detailed example of the operation of = the mitigation technique in Section 7.3, and especially the pseudo code = that implements what the document still calls the "proposed" solutions = in Section 7.4 in my opinion go beyond the WG consensus we had, which = was to document and discuss the mitigation techniques implemented in = current stacks. >=20 > I'd be interested to hear the WG's thoughts esp. on this issue, but of = course also on the rest of my comments below. what I've heard so far from the WG is that the inclusion of those = sections is desired, so I consider this issue resolved. I'll follow up = to some of the other points I raised in another reply. Lars= --Apple-Mail-8-834432794 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDEyOTA5MjIzOFowIwYJKoZIhvcNAQkEMRYEFBvGeB2iZy+AJ7vbEm017NGRptZiMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCVnNtJaHzdt7x2OVubDQVDRHscycjB51HZaqCaYl/rU7yQrDYHC+tN59rq1KvWa35f554P qSH9lFZWu4a92b5p1HbnM6qc8m6C6o1nYSMRa80z5ZQfaphOV82amtd+764AmoH3ETJClTl4Xxqs qauLip2yJ/iI2VKC5rMtdPjjRdQVZggxPOQtMv4G0ftUig3lF5/ljQKvIZJXgKN18QgPXqNEeHs5 tYRLKy7WS6VGuz2NBUxoXd1DpHfS7orIe++RQTuD5ZR8HlJzUcQ8Okl/V5aD1KelAKdTmYFeq+KG GlVgcivg0TkoyvST7sydiububb8ToBPH4MLkFXFcvuovAAAAAAAA --Apple-Mail-8-834432794-- From lars.eggert@nokia.com Fri Jan 29 01:32:58 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2C53A689C for ; Fri, 29 Jan 2010 01:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.602 X-Spam-Level: X-Spam-Status: No, score=-6.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8cQHjoQX6LT for ; Fri, 29 Jan 2010 01:32:57 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id D9C0A3A6820 for ; Fri, 29 Jan 2010 01:32:56 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0T9WKVj023057; Fri, 29 Jan 2010 11:32:31 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 11:32:22 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 11:32:21 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0T9WK5X008193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jan 2010 11:32:20 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-9-835003932; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4B6204F7.1070908@gont.com.ar> Date: Fri, 29 Jan 2010 11:32:08 +0200 Message-Id: <50DBEEEC-1EA0-4C8D-8B52-3063F13BAB7B@nokia.com> References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> <4B60A3EC.20308@gont.com.ar> <4B6204F7.1070908@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Fri, 29 Jan 2010 11:32:14 +0200 (EET) X-OriginalArrivalTime: 29 Jan 2010 09:32:21.0787 (UTC) FILETIME=[F54BD6B0:01CAA0C5] X-Nokia-AV: Clean Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 09:32:58 -0000 --Apple-Mail-9-835003932 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-1-28, at 23:43, Fernando Gont wrote: > Hopefully by that time xml2rfc will already support the new = boilerplate? > Or, if anybody can provide the correct boilerplate, I could manually > edit the I-D. see Alfred's email. There is a team forming to continue maintenance of = xml2rfc, but esp. the testing and release handling remains an open = issue. >> But this is a TCPM WG document, and it was your personal involvement >> that caused the changes, and not the TCPM WG document. So it wasn't >> "this analysis" in the sense of this document, but "an analysis done >> by someone who now happens to be editor of the WG document." >=20 > I don't get your point. The BSD people implemented the hard_errors-> > soft_errors thing as a result of the same reasoning that is included = in > the icmp-attacks I-D. Yes, but not because of the ID. > Other vendors applied this change in response to > this I-D. That wasn't clear to me so far. Didn't you say earlier that you wrote = those original techniques and got them merged? So essentially, it was = actually that act that caused the ID to be written. In any case: I think I've exhausted my powder on this smallish issue. I = just wanted to make sure that the language in the draft reflects what = actually happened. >> So that by "internet" you mean "IP-based isolated network" was >> completely lost on me. Is this really an important point?=20 >=20 > No. I mean any network that uses IETF technology, no matter whether = its > connected to the public Internet or not. I never ascribed some sort of well-defined different between big-I and = little-i Internet. If this is clear to everyone, leave it as-is. >> If yes, then with delayed ACKs (or otherwise in corner cases) >> acked_packet_size is actually larger than maxsizesent always.=20 >=20 > Well, that depends on the amount of data you send. But yes, you could > say that "acked_packet_size is actually larger than maxsizesent = *usually*". >=20 >> On >> second reading, I don't think that's a problem for the technique, but >> the name and description of the variable confused me earlier. >=20 > Should I add a clarification? I think this would make sense. You might also want to change the name of = the variable. Lars= --Apple-Mail-9-835003932 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDEyOTA5MzIwOVowIwYJKoZIhvcNAQkEMRYEFAMACkNlK/zOlYvalNL8KIZKRjFOMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDAgQX8XuO0Vou3ndVnerohtfSGoL7SGqcevos/C6XoDkua59AV0w5n31xOvYB2GIMQZZmu 6rsHMXwSaHzbd3adId8JybaCEVpOJrKsfoikHHMYYzTeWySe7PJGsanEHvd33Y6RiHWgKzq6J6nM G2uDIOH9hJ3SvEc6kmooBIB6qKtfVM+86bK6AWjPSgvzViy3bm8zikqzWlXgxHqdIav3Zsii/4KS USMjBDzpD7RdagULerLH7weqU2I6AacHXS42vHuIzODbr3CPebky7viBahkVMsTTjq6Aykm8Q86X f0tuOEdrW4meOZjD4diUc0JV5PdGTT/YHZ6AnN5W/MTrAAAAAAAA --Apple-Mail-9-835003932-- From ananth@cisco.com Fri Jan 29 07:51:37 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD523A697F for ; Fri, 29 Jan 2010 07:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGwjiOHXJwf4 for ; Fri, 29 Jan 2010 07:51:36 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 46BB43A686A for ; Fri, 29 Jan 2010 07:51:36 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHGTYkurRN+K/2dsb2JhbADDdJdYAoRABA X-IronPort-AV: E=Sophos;i="4.49,368,1262563200"; d="scan'208";a="142252949" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 29 Jan 2010 15:51:46 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0TFpkEn020608; Fri, 29 Jan 2010 15:51:46 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 07:51:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 07:51:45 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5808CD6088@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <5E266815-608E-49E9-9398-418B9890EA15@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] your responses to my comments on "the WG" Thread-Index: Acqgqa05zxUDJ1CaRfGpEv9UeSbIKAAT47VQ References: <201001290029.BAA11165@TR-Sys.de> <5E266815-608E-49E9-9398-418B9890EA15@nokia.com> From: "Anantha Ramaiah (ananth)" To: "Lars Eggert" , X-OriginalArrivalTime: 29 Jan 2010 15:51:46.0104 (UTC) FILETIME=[F5E2F380:01CAA0FA] Cc: tcpm@ietf.org Subject: Re: [tcpm] your responses to my comments on "the WG" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 15:51:37 -0000 +1 I fully tend to agree with Alfred's email sub-section titled "the WG".=20 (the issues which Alfred's email touches upon are well known which needs to be addressed for the benefit of the IETF community) -Anantha=20 PS:- FWIW, I did not respond to Alfred in private, I saw Alfred's post, liked it, and wanted to respond in public later...) > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Lars Eggert > Sent: Thursday, January 28, 2010 10:09 PM > To: ah@tr-sys.de > Cc: tcpm@ietf.org > Subject: Re: [tcpm] your responses to my comments on "the WG" >=20 > Hi, >=20 > I'd like to strongly encourage folks who have responded to=20 > Alfred privately to discuss the perceived issue he has raised=20 > on the WG list.=20 >=20 > A WG is what its contributors make it, and for it to change,=20 > for example in the way that Alfred would like to see,=20 > requires a vocal majority and not a silent majority. >=20 > Thanks, > Lars >=20 > On 2010-1-29, at 2:29, ah@tr-sys.de wrote: >=20 > > Thanks to all ... > >=20 > > for the overwhelming consenting and supportive feedback received so=20 > > far (off-list) from listeners to the TCPM list, regarding=20 > my comments=20 > > in item > > (2) "the WG" > > of my recent posting [1] !=20 > >=20 > > It's really encouraging to see that the "silent majority" > > is not _always_ so silent. :-) > >=20 > > Please admit that I'll not have the time to respond individually. > >=20 > > As a matter of course and due diligence, I confirm that I will not=20 > > disclose to any other person any names or affiliations of senders. > >=20 > > Best regards, > > Alfred. > >=20 > > -- > >=20 > >=20 > +------------------------+------------------------------------ > --------+ > > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math.,=20 > Dipl.-Phys. | > > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax:=20 > -18 | > > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de =20 > | > >=20 > +------------------------+------------------------------------ > --------+ > >=20 > > [1]=20 > > >=20 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 From fernando.gont.netbook.win@gmail.com Fri Jan 29 08:12:15 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D6E3A695C for ; Fri, 29 Jan 2010 08:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RVpieVnYR0r for ; Fri, 29 Jan 2010 08:12:12 -0800 (PST) Received: from mail-yw0-f114.google.com (mail-yw0-f114.google.com [209.85.211.114]) by core3.amsl.com (Postfix) with ESMTP id 760883A67EB for ; Fri, 29 Jan 2010 08:12:10 -0800 (PST) Received: by ywh12 with SMTP id 12so213880ywh.19 for ; Fri, 29 Jan 2010 08:12:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=GfFVEFj21Z6sirBKFQfe2SCe0Y7W8QfDlux36q6Zso8=; b=UY10EUid6uQ7p8dPhEDzkWgNyzK9EcCYDhqTBL34oA0t81RIDrTWjOz223/OTZa5BW aYZehpNelXot1pab+/DdMd5077xpOopaJWD2qVDSlAEnGf3sDyJYUoxpl/M5cPlbPYaa fh5I2QPd+BT41uDeTrQpLtG4+NhKmjUhMT23c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=eoFkfcwB28Q+c7KEGzt9S1LoPT8VweQGYGsoPbNlkzj4+2MWlFrkQHRJJfEPnzbih3 ir8o06U00+lhEkvS+NNq/HYCzWZ6IXpjU1OHQSGVxt+hPLjta2Lo7wqrfO4O6QPbHVH8 cEJvnYTqsz2FJpzz7Pcv3TN0IzMDQKGz6mDQM= Received: by 10.151.92.5 with SMTP id u5mr1918803ybl.114.1264781550111; Fri, 29 Jan 2010 08:12:30 -0800 (PST) Received: from ?192.168.0.100? (144-174-17-190.fibertel.com.ar [190.17.174.144]) by mx.google.com with ESMTPS id 7sm757675ywf.40.2010.01.29.08.12.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 08:12:29 -0800 (PST) Sender: Fernando Gont Message-ID: <4B6308DE.7050508@gont.com.ar> Date: Fri, 29 Jan 2010 13:12:14 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <201001290029.BAA11165@TR-Sys.de> <5E266815-608E-49E9-9398-418B9890EA15@nokia.com> <0C53DCFB700D144284A584F54711EC5808CD6088@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5808CD6088@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ah@tr-sys.de, tcpm@ietf.org Subject: Re: [tcpm] your responses to my comments on "the WG" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 16:12:15 -0000 Anantha Ramaiah (ananth) wrote: > +1 > > I fully tend to agree with Alfred's email sub-section titled "the WG". > > > (the issues which Alfred's email touches upon are well known which needs > to be addressed for the benefit of the IETF community) +1 Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From L.Wood@surrey.ac.uk Fri Jan 29 08:35:54 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52A583A6A4C for ; Fri, 29 Jan 2010 08:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIDVTkOwK9-V for ; Fri, 29 Jan 2010 08:35:53 -0800 (PST) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id E86DF3A6A4A for ; Fri, 29 Jan 2010 08:35:49 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-14.tower-72.messagelabs.com!1264782970!71523275!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.35] Received: (qmail 28206 invoked from network); 29 Jan 2010 16:36:11 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-14.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 29 Jan 2010 16:36:11 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.124]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Fri, 29 Jan 2010 16:36:10 +0000 From: To: , Date: Fri, 29 Jan 2010 16:35:17 +0000 Thread-Topic: [tcpm] your responses to my comments on "the WG" Thread-Index: Acqg/erJOpg7dWiwS0ub6Amj/QFV7AAAyAHz Message-ID: References: <201001290029.BAA11165@TR-Sys.de> <5E266815-608E-49E9-9398-418B9890EA15@nokia.com> <0C53DCFB700D144284A584F54711EC5808CD6088@xmb-sjc-21c.amer.cisco.com>, <4B6308DE.7050508@gont.com.ar> In-Reply-To: <4B6308DE.7050508@gont.com.ar> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ah@tr-sys.de, tcpm@ietf.org Subject: Re: [tcpm] your responses to my comments on "the WG" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 16:35:54 -0000 +1 Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Fernando G= ont [fernando@gont.com.ar] Sent: 29 January 2010 16:12 To: Anantha Ramaiah (ananth) Cc: ah@tr-sys.de; tcpm@ietf.org Subject: Re: [tcpm] your responses to my comments on "the WG" Anantha Ramaiah (ananth) wrote: > +1 > > I fully tend to agree with Alfred's email sub-section titled "the WG". > > > (the issues which Alfred's email touches upon are well known which needs > to be addressed for the benefit of the IETF community) +1 Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Fri Jan 29 08:49:13 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F024F3A6963 for ; Fri, 29 Jan 2010 08:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boGVimNW-CFC for ; Fri, 29 Jan 2010 08:49:12 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E71283A6A0F for ; Fri, 29 Jan 2010 08:49:11 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10] (may be forged)) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o0TGlsoS020207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jan 2010 08:47:56 -0800 (PST) Message-ID: <4B63113A.9090405@isi.edu> Date: Fri, 29 Jan 2010 08:47:54 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Alfred_=3F?= References: <201001281906.UAA10585@TR-Sys.de> In-Reply-To: <201001281906.UAA10585@TR-Sys.de> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3B2E5DEC577CCCD34BE9F163" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 16:49:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3B2E5DEC577CCCD34BE9F163 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alfred, Alfred ? wrote: > A few notes triggered by the recent discussion: =2E.. > (2) "the WG" >=20 > What has been referred to as "the [TCPM] WG" in this thread is by > most readers of the TCPM list seen as a tiny group of o^Hverl^Hy > active contributors who overwhelm the discussion with iterated > notorious statements which many folks that are not in a position > to be able to constantly respond at a high rate got tired of over > the years.... I'm impressed you have so directly discerned the views the "silent majority". I had not expected clairvoyance. ;-) I'll note that: - the "silent majority" is a majority only in its silence. Until it *speaks*, none of us knows its views, or whether there is even a majority among it. - there are many reasons many on this list are silent: - overwhelmed with long, detailed posts - overwhelmed by exchanges - apathy - ignorance - feels their views are already expressed - lack of time to participate - lack of interest in participating ...among others I've been contacted by many over the years who appreciate some of the exchanges on this list, esp. when they keep the explosion of proposed alternatives in check. In some ways, TCPM has succeeded in this regard. In others, it has failed. That's true for all perspectives of this or most other WGs. There is a tension throughout the IETF between evolution and the tragedy of the commons. The closer a WG is to the core protocols of the Internet, the more dramatic this tension. TCP is the deep end of the pool. There are substantial hurdles to customizing it for specific uses, commercial or otherwise. One is consensus and running code. Another is the IESG and IAB. None of this is 'majority rules'. Keep in mind that if we did what the majority of industry wanted all the time, we'd be running SNA over ATM. In the cases you raise as issues, some deployed changes were not endorsed. This wasn't a lack of leadership, or a debate about scope; it was a lack of *consensus*. It didn't even get to the stage where even consensus could be overturned to protect the long-term health and stability of the Internet (e.g., by the IESG and IAB). > This list should stop ignoring the "silent majority". Agreed. However, until they speak up, we have no idea *why* they are silent **until they speak**. Even if they do speak up, we can't assume they'll improve our ability to reach consensus, or -- even if we have consensus -- to get those views through the review of the IESG or the IAB, which is also required. Joe --------------enig3B2E5DEC577CCCD34BE9F163 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.9 (MingW32) iEYEARECAAYFAktjEToACgkQE5f5cImnZruUIACgzeOAU55lyt1PvmI2RhOKvazG Cf0An3U11Jzt43Cmy18hdGKlEi7usGL3 =RfxI -----END PGP SIGNATURE----- --------------enig3B2E5DEC577CCCD34BE9F163-- From MBashyam@OcarinaNetworks.com Fri Jan 29 08:54:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949883A681A for ; Fri, 29 Jan 2010 08:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNyzWOZPLymN for ; Fri, 29 Jan 2010 08:54:39 -0800 (PST) Received: from mail.ocarinanetworks.com (mail.ocarinanetworks.com [69.3.29.22]) by core3.amsl.com (Postfix) with ESMTP id D8A2A3A67EF for ; Fri, 29 Jan 2010 08:54:39 -0800 (PST) Received: from exchsvr01.ocarina.local ([10.250.1.7]) by exchsvr01.ocarina.local ([10.250.1.7]) with mapi; Fri, 29 Jan 2010 08:56:14 -0800 From: Murali Bashyam To: Fernando Gont , "Anantha Ramaiah (ananth)" Date: Fri, 29 Jan 2010 08:56:10 -0800 Thread-Topic: [tcpm] your responses to my comments on "the WG" Thread-Index: Acqg/hJegawRA2b6T/iPtz+ygpiT4gABV2MQ Message-ID: References: <201001290029.BAA11165@TR-Sys.de> <5E266815-608E-49E9-9398-418B9890EA15@nokia.com> <0C53DCFB700D144284A584F54711EC5808CD6088@xmb-sjc-21c.amer.cisco.com> <4B6308DE.7050508@gont.com.ar> In-Reply-To: <4B6308DE.7050508@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ah@tr-sys.de" , "tcpm@ietf.org" Subject: Re: [tcpm] your responses to my comments on "the WG" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 16:54:40 -0000 TCPM's functioning brings the word "Orwellian" to my mind. I second Alfred'= s email both from a TCPM contributor and a author's perspective. -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Fer= nando Gont Sent: Friday, January 29, 2010 8:12 AM To: Anantha Ramaiah (ananth) Cc: ah@tr-sys.de; tcpm@ietf.org Subject: Re: [tcpm] your responses to my comments on "the WG" Anantha Ramaiah (ananth) wrote: > +1 >=20 > I fully tend to agree with Alfred's email sub-section titled "the WG".=20 > >=20 > (the issues which Alfred's email touches upon are well known which needs > to be addressed for the benefit of the IETF community) +1 Kind regards, --=20 Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From touch@ISI.EDU Fri Jan 29 10:04:31 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE63A3A6936 for ; Fri, 29 Jan 2010 10:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5u6Yh63ZG6K for ; Fri, 29 Jan 2010 10:04:31 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 0BBAD3A6880 for ; Fri, 29 Jan 2010 10:04:31 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o0TI3x9m017330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jan 2010 10:04:00 -0800 (PST) Message-ID: <4B63230A.9010109@isi.edu> Date: Fri, 29 Jan 2010 10:03:54 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Alfred_=3F?= References: <201001290010.BAA11140@TR-Sys.de> In-Reply-To: <201001290010.BAA11140@TR-Sys.de> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDEAC72BD7B16B0CB3481F0D3" X-MailScanner-ID: o0TI3x9m017330 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 -- boilerplate questions X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 18:04:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDEAC72BD7B16B0CB3481F0D3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alfred ? wrote: > Fernando Gont wrote: >=20 >>> .. >>> >> Hopefully by that time xml2rfc will already support the new boilerplat= e? >=20 > Definitely : NO. Don't bet. Manual edits needed so far. >=20 > AFAICT (based on comments from M.T.Rose and Julian Reschke), > xml2rfc is seeking new maintainer(s) and it's rather unlikely > that the toolkits it is based on (and that turned out to be much > less long-lived than expected and run out of fashion quickly) > still share a large pool of potentially suitable volunteer guru > candidates. > Maybe xml2rfc needs to be re-implemented with the current > tools of the week every time it needs to be updated. ;-) FWIW, this issue plagues all the tools, incl. the Word template I maintain. The boilerplate text seems to change more frequently than RFCs are published (I've have an RFC in "AUTH48" by RFC Editor decree for over 400 days), and when it does, we get cryptic instructions rather than "here's what a new ID or RFC should look like". Joe --------------enigDEAC72BD7B16B0CB3481F0D3 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.9 (MingW32) iEYEARECAAYFAktjIwoACgkQE5f5cImnZrt7DACfQd9FSY+ZfM73uUzSO91d4GAs UDsAmgP5GR33h5aGb4a0q5HRlvQAS7sv =PNA7 -----END PGP SIGNATURE----- --------------enigDEAC72BD7B16B0CB3481F0D3-- From touch@ISI.EDU Fri Jan 29 10:12:54 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA993A6941 for ; Fri, 29 Jan 2010 10:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQem-sVjn5SR for ; Fri, 29 Jan 2010 10:12:53 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id E4DCD3A6A3A for ; Fri, 29 Jan 2010 10:12:52 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o0TI9xYZ018852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jan 2010 10:10:05 -0800 (PST) Message-ID: <4B63246B.5070904@isi.edu> Date: Fri, 29 Jan 2010 10:09:47 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <4B3AB8BD.2070907@isi.edu> <4B3C3E6E.4050903@isi.edu> <588ADB01-E63F-4313-9F3F-35A2CE80C0F6@nokia.com> <0F25B30B-DF5A-4D3F-B120-54F5B58947CF@nokia.com> <4b4bbba1.8502be0a.1327.ffff884b@mx.google.com> <467024B3-4E75-435F-BB4E-DA8D793A545D@nokia.com> In-Reply-To: <467024B3-4E75-435F-BB4E-DA8D793A545D@nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0783B94C60677CF1E0DD7B15" X-MailScanner-ID: o0TI9xYZ018852 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-lebovitz-ietf-tcpm-tcp-ao-crypto@tools.ietf.org, "tcpm@ietf.org WG" , draft-ietf-tcpm-tcp-auth-opt@tools.ietf.org Subject: Re: [tcpm] status of auth-opt and auth-opt crypto? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 18:12:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0783B94C60677CF1E0DD7B15 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lars Eggert wrote: > Hi, authors, >=20 > the WG was promised updates to auth-opt and auth-opt crypto weeks ago t= o address the comments that arrived after WGLC. Where are they? >=20 > The continued editing delays around what everyone agrees is an > important work item in TCPM are becoming embarrassing. Please set aside= > sufficient cycles to complete this work quickly so we can publish, or > find co-editors who can. I had set aside cycles well in advance, when the WGLC was issued. Delays in managing that threw 5 weeks into the cycle. We're on schedule based on that delay, IMO - I'm editing it right now, and should have it ready by Monday AM at the latest. Joe --------------enig0783B94C60677CF1E0DD7B15 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.9 (MingW32) iEYEARECAAYFAktjJGsACgkQE5f5cImnZrsDTQCeIOu+DPCJlh9IBT8Q3+A4FX0G IP8AoOVEkd2r4X3aax2fg4+cX6g+YgI9 =K5kK -----END PGP SIGNATURE----- --------------enig0783B94C60677CF1E0DD7B15-- From dab@weston.borman.com Fri Jan 29 10:44:01 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854713A67DA for ; Fri, 29 Jan 2010 10:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioI8A+ycQkcs for ; Fri, 29 Jan 2010 10:44:00 -0800 (PST) Received: from frantic.weston.borman.com (frantic-dmz.weston.BORMAN.COM [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id 9892F3A67E5 for ; Fri, 29 Jan 2010 10:44:00 -0800 (PST) Received: from [172.25.44.5] (weston-43.weston.borman.com [206.196.45.43]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id o0TIiEq3014687; Fri, 29 Jan 2010 12:44:15 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: David Borman In-Reply-To: <201001281906.UAA10585@TR-Sys.de> Date: Fri, 29 Jan 2010 12:44:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <10B73224-5326-4B57-8393-73D0371B6413@weston.borman.com> References: <201001281906.UAA10585@TR-Sys.de> To: =?iso-8859-1?Q?Alfred_H=CEnes?= X-Mailer: Apple Mail (2.1077) Cc: tcpm@ietf.org Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 18:44:01 -0000 On Jan 28, 2010, at 1:06 PM, Alfred H=CEnes wrote: > This list should stop ignoring the "silent majority". More correctly, the "silent majority" should stop ignoring the mailing = list. The only way the "silent majority" will be heard is if they stop = being silent, and start contributing. I did some rough stats from the mailing list. As of today, there are = 405 members on this mailing list. Excluding messages from sources like = Internet-drafts, over the past 2 years there have been 1519 messages = posted to the TCPM mailing list by 98 unique posters. Comparing against = 405 members on the mailing list: 75% have not posted a single message 7.7% (31) posted 1 message, 2% ( 31) of all messages 6.4% (26) posted 2-4 messages, 5% ( 73) of all messages 4% (16) posted 5-9 messages, 7% (101) of all messages 2.5% (10) posted 10-21 messages, 10% (151) of all messages 2.5% (10) posted 22-66 messages, 25% (386) of all messages 1.2% ( 5) posted > 85 messages, 51% (777) of all messages 80% of all messages were contributed by 5% of the members. 90% of all messages were contributed by 8% of the members You have to speak up and contribute to be part of the discussion. -David Borman= From root@core3.amsl.com Sat Jan 30 22:45:02 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 476F93A690B; Sat, 30 Jan 2010 22:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100131064502.476F93A690B@core3.amsl.com> Date: Sat, 30 Jan 2010 22:45:02 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 06:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : ICMP attacks against TCP Author(s) : F. Gont Filename : draft-ietf-tcpm-icmp-attacks-10.txt Pages : 40 Date : 2010-01-30 This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-icmp-attacks-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-30224343.I-D@ietf.org> --NextPart-- From fernando.gont.netbook.win@gmail.com Sat Jan 30 22:46:24 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D06A28C0D7 for ; Sat, 30 Jan 2010 22:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOJwNo+YLen0 for ; Sat, 30 Jan 2010 22:46:13 -0800 (PST) Received: from mail-gx0-f169.google.com (mail-gx0-f169.google.com [209.85.217.169]) by core3.amsl.com (Postfix) with ESMTP id 3904F3A690B for ; Sat, 30 Jan 2010 22:46:13 -0800 (PST) Received: by gxk9 with SMTP id 9so701697gxk.8 for ; Sat, 30 Jan 2010 22:46:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=9crmdtwVSLU/4w7tt+fMqe02mXEgf4dBjpLUBrqcl8k=; b=C/4itX3cljli7z/FJwxO1OoJrUz4EWxKtHVeSfaX+hVmsf43p6Vgu6/dIaT4oLcR9p rsuHU5rqDsDCswqU2QpJdsbCeVetOkAi/EFC1d5+GgJRHCVK8bc7DDYS9WIpCCFB9Dtz UQTr6QXdwerhOs+IBEUcquNfjvOpA9XMATCpM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=mwnIAvvAcFIAvHPcKO5h6hvHOa9agCudukFG/+Zboyr2UqhQ38ruqaBuSgEmJOFoGd 2fHJJELnh1Rc+/FAHmiklRNQnnka/6d36fQjD0IVTPXnMqEwArr6HuwFim/FTQd813Yp 7pW40hIIG1oEpJMip5Pl0FR2q4pYMmxHg9j90= Received: by 10.101.110.14 with SMTP id n14mr3215223anm.236.1264920398700; Sat, 30 Jan 2010 22:46:38 -0800 (PST) Received: from ?192.168.0.100? (144-174-17-190.fibertel.com.ar [190.17.174.144]) by mx.google.com with ESMTPS id 6sm1309207ywd.22.2010.01.30.22.46.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 30 Jan 2010 22:46:38 -0800 (PST) Sender: Fernando Gont Message-ID: <4B65273D.1030403@gont.com.ar> Date: Sun, 31 Jan 2010 03:46:21 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: [tcpm] [Fwd: New Version Notification for draft-ietf-tcpm-icmp-attacks-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 06:46:24 -0000 (CC to tcpm@ietf.org) Lars, I have posted a revision of the ICMP attacks I-D. Please let me know if it addresses all the issues you have raised (I hope it does). Thanks! Kind regards, Fernando -------- Original Message -------- Subject: New Version Notification for draft-ietf-tcpm-icmp-attacks-10 Date: Sat, 30 Jan 2010 22:43:44 -0800 (PST) From: IETF I-D Submission Tool To: fernando@gont.com.ar A new version of I-D, draft-ietf-tcpm-icmp-attacks-10.txt has been successfuly submitted by Fernando Gont and posted to the IETF repository. Filename: draft-ietf-tcpm-icmp-attacks Revision: 10 Title: ICMP attacks against TCP Creation_date: 2010-01-30 WG ID: tcpm Number_of_pages: 40 Abstract: This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. The IETF Secretariat. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Sat Jan 30 23:15:48 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0E3628C0DC for ; Sat, 30 Jan 2010 23:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJ5xQN+oVIjJ for ; Sat, 30 Jan 2010 23:15:48 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id E467F28C0E1 for ; Sat, 30 Jan 2010 23:15:47 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o0V7FQZi000614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 30 Jan 2010 23:15:30 -0800 (PST) Message-ID: <4B652E08.8020203@isi.edu> Date: Sat, 30 Jan 2010 23:15:20 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4B65273D.1030403@gont.com.ar> In-Reply-To: <4B65273D.1030403@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF7B2FD93A17D8586668F6AC2" X-MailScanner-ID: o0V7FQZi000614 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] [Fwd: New Version Notification for draft-ietf-tcpm-icmp-attacks-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 07:15:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF7B2FD93A17D8586668F6AC2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando, The text has the paragraph you proposed and I had issues with: We note that the counter-measures discussed in this document are not part of standard TCP behavior and this document does not change that state of affairs. The consensus of the TCPM WG (TCP Maintenance and Minor Extensions Working Group) was to document this widespread implementation of nonstandard TCP behavior but to not change the TCP standard. I had preferred something that included Wes's view that: As mentioned above, I think if the section's content is hedged correctly as describing the implementation that exists, rather than a WG-proposed behavior, then we'll be within consensus. I would appreciate if the text indicated not only that the WG did not decide to change the standard but that it also didn't decide to recommend it. That can be accomplished by changing the (first paragraph) above to: We note that the counter-measures discussed in this document are not part of standard TCP behavior and this document does not change that state of affairs. The consensus of the TCPM WG (TCP Maintenance and Minor Extensions Working Group) was to document this widespread implementation of nonstandard TCP behavior and neither to change the TCP standard nor to recommend implementation of this behavior. Sorry that this didn't make it before your update; I hadn't though you would submit it so quickly. Joe Fernando Gont wrote: > (CC to tcpm@ietf.org) >=20 > Lars, >=20 > I have posted a revision of the ICMP attacks I-D. Please let me know if= > it addresses all the issues you have raised (I hope it does). >=20 > Thanks! >=20 > Kind regards, > Fernando >=20 >=20 >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for draft-ietf-tcpm-icmp-attacks-10 > Date: Sat, 30 Jan 2010 22:43:44 -0800 (PST) > From: IETF I-D Submission Tool > To: fernando@gont.com.ar >=20 >=20 > A new version of I-D, draft-ietf-tcpm-icmp-attacks-10.txt has been > successfuly submitted by Fernando Gont and posted to the IETF repositor= y. >=20 > Filename: draft-ietf-tcpm-icmp-attacks > Revision: 10 > Title: ICMP attacks against TCP > Creation_date: 2010-01-30 > WG ID: tcpm > Number_of_pages: 40 >=20 > Abstract: > This document discusses the use of the Internet Control Message > Protocol (ICMP) to perform a variety of attacks against the > Transmission Control Protocol (TCP). Additionally, describes a > number of widely implemented modifications to TCP's handling of ICMP > error messages that help to mitigate these issues. >=20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 >=20 --------------enigF7B2FD93A17D8586668F6AC2 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.9 (MingW32) iEYEARECAAYFAktlLg0ACgkQE5f5cImnZrs38ACgksw6W5UdSNATRYXgpkgPz48G U4MAnAz31IiqeMNlCwcFAjWMZkFmkZss =HtaJ -----END PGP SIGNATURE----- --------------enigF7B2FD93A17D8586668F6AC2-- From fernando.gont.netbook.win@gmail.com Sun Jan 31 01:49:30 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846F93A693A for ; Sun, 31 Jan 2010 01:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1lwwYLfpT6s for ; Sun, 31 Jan 2010 01:49:29 -0800 (PST) Received: from mail-yw0-f123.google.com (mail-yw0-f123.google.com [209.85.211.123]) by core3.amsl.com (Postfix) with ESMTP id 907173A6939 for ; Sun, 31 Jan 2010 01:49:29 -0800 (PST) Received: by ywh29 with SMTP id 29so549384ywh.22 for ; Sun, 31 Jan 2010 01:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=1dhB3XBxJxjYkMEmBMVg2wiSGx6+UpnK1RAaTHrl05I=; b=l2BA6IqRxDywiUpplU3vnoUmtxTc38oUKFtszUmj21jSBAjQZwHC8vArj008oiljBm 4xr0RbysQS5NYHioeHgK06736CW9TQwwT+xzCAC/Dv3A759lPYSrZ7+pkedQ2ooIBILO tQTFz9uLsJBFycpNjDDoBcA9P1wX/6LCcawew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=MiZNnKwChX6wLoT3SKtFSJd8kv+IkoaKNpXA48/G6nTVDfYz0KExr+trOjTaZii8dw 5Nso+5s5SKdrrhNb5S4kBEoN7zMpxuuiYEBKrTMSDUfwotDRnDutmYOoWJfp4rzL3SN5 M3zYNZkMjWU5YMNavZXQT8LpNVPPg30qRD9FU= Received: by 10.150.184.3 with SMTP id h3mr2174096ybf.139.1264931392895; Sun, 31 Jan 2010 01:49:52 -0800 (PST) Received: from ?192.168.0.100? (144-174-17-190.fibertel.com.ar [190.17.174.144]) by mx.google.com with ESMTPS id 8sm1341835ywg.49.2010.01.31.01.49.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 31 Jan 2010 01:49:52 -0800 (PST) Sender: Fernando Gont Message-ID: <4B65522E.8060606@gont.com.ar> Date: Sun, 31 Jan 2010 06:49:34 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4B65273D.1030403@gont.com.ar> <4B652E08.8020203@isi.edu> In-Reply-To: <4B652E08.8020203@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] [Fwd: New Version Notification for draft-ietf-tcpm-icmp-attacks-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 09:49:30 -0000 Hello, Joe, > The text has the paragraph you proposed and I had issues with: > > We note that the counter-measures discussed in this document are not > part of standard TCP behavior and this document does not change that > state of affairs. The consensus of the TCPM WG (TCP Maintenance and > Minor Extensions Working Group) was to document this widespread > implementation of nonstandard TCP behavior but to not change the TCP > standard. I submitted this rev so that people could have a look at my working copy. > I had preferred something that included Wes's view that: > > As mentioned above, I think if the section's content is hedged > correctly as describing the implementation that exists, rather > than a WG-proposed behavior, then we'll be within consensus. > > I would appreciate if the text indicated not only that the WG did not > decide to change the standard but that it also didn't decide to > recommend it. Isn't this the same thing? If we're not changing the standard, so why would we be supposed to be recommending this? Or could we be recommending this without changing the specs??? > That can be accomplished by changing the (first paragraph) > above to: > > We note that the counter-measures discussed in this document are not > part of standard TCP behavior and this document does not change that > state of affairs. The consensus of the TCPM WG (TCP Maintenance and > Minor Extensions Working Group) was to document this widespread > implementation of nonstandard TCP behavior and neither to change > the TCP standard nor to recommend implementation of this behavior. Strictly speaking, this text (and the one I proposed) is not 100% correct. e.g., the pmtud fix is within the specs. (one my argue that hard -> soft might or might not be within the specs... as the spec is ambiguous: there's one SHOULD, and one MUST for the very same requirement). But I'll just let others (and Lars in particular) weigh in. As far as I am concerned, I want to get this I-D done. And if this alternative text is supposed to make a difference, I will have no problem with recommending it. But, hey, let's get over it. IMHO, this is being way too paranoid about the sacred RFCs. It's an informational RFC. We're even including a complete paragraph saying that this does not change the spec, and we're still hair-splitting.... > Sorry that this didn't make it before your update; I hadn't though you > would submit it so quickly. Take this rev as an iteration to converge to an "acceptable" I-D. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Sun Jan 31 10:51:13 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE6D23A68BB for ; Sun, 31 Jan 2010 10:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Loxpotcu2npJ for ; Sun, 31 Jan 2010 10:51:13 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 0D7A63A6873 for ; Sun, 31 Jan 2010 10:51:13 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o0VIoK6G007916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 31 Jan 2010 10:50:22 -0800 (PST) Message-ID: <4B65D0EA.9040205@isi.edu> Date: Sun, 31 Jan 2010 10:50:18 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4B65273D.1030403@gont.com.ar> <4B652E08.8020203@isi.edu> <4B65522E.8060606@gont.com.ar> In-Reply-To: <4B65522E.8060606@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDB7EF55DE96F0F864BEBEE31" X-MailScanner-ID: o0VIoK6G007916 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] [Fwd: New Version Notification for draft-ietf-tcpm-icmp-attacks-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 18:51:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDB7EF55DE96F0F864BEBEE31 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Fernando Fernando Gont wrote: > Hello, Joe, =2E.. > I submitted this rev so that people could have a look at my working cop= y. AOK - thanks! =2E.. >> I would appreciate if the text indicated not only that the WG did not >> decide to change the standard but that it also didn't decide to >> recommend it.=20 >=20 > Isn't this the same thing? If we're not changing the standard, so why > would we be supposed to be recommending this? Or could we be > recommending this without changing the specs??? We do various things, including: - changing the standard - making recommendations that are consistent with the standard The second case is "making a recommendation without changing the specs". That's the other thing we didn't have consensus on. >> That can be accomplished by changing the (first paragraph) >> above to: >> >> We note that the counter-measures discussed in this document are no= t >> part of standard TCP behavior and this document does not change tha= t >> state of affairs. The consensus of the TCPM WG (TCP Maintenance an= d >> Minor Extensions Working Group) was to document this widespread >> implementation of nonstandard TCP behavior and neither to change >> the TCP standard nor to recommend implementation of this behavior. >=20 > Strictly speaking, this text (and the one I proposed) is not 100% > correct. e.g., the pmtud fix is within the specs.=20 Agreed. Here's a modified version: We note that the counter-measures discussed in this document are not part of standard TCP behavior and this document does not change that state of affairs. The consensus of the TCPM WG (TCP Maintenance and Minor Extensions Working Group) was to document this widespread implementation of nonstandard TCP behavior and neither to change the TCP standard nor to make any new recommendations herein. Joe --------------enigDB7EF55DE96F0F864BEBEE31 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.9 (MingW32) iEYEARECAAYFAktl0OoACgkQE5f5cImnZrt9zACfcXf9yLW2t0oyMZBaU+u280hM xe4An1snIqI83cqXAgNIVTDVbjPm/QfD =4Rca -----END PGP SIGNATURE----- --------------enigDB7EF55DE96F0F864BEBEE31-- From fernando.gont.netbook.win@gmail.com Sun Jan 31 13:11:30 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232FE3A67E9 for ; Sun, 31 Jan 2010 13:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37ztpvc2VcIP for ; Sun, 31 Jan 2010 13:11:23 -0800 (PST) Received: from mail-yw0-f123.google.com (mail-yw0-f123.google.com [209.85.211.123]) by core3.amsl.com (Postfix) with ESMTP id 2E5B93A6838 for ; Sun, 31 Jan 2010 13:11:21 -0800 (PST) Received: by ywh29 with SMTP id 29so642055ywh.22 for ; Sun, 31 Jan 2010 13:11:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=C2garrM64rr9zgvU94aIC+Zm8EzR6jCyl5EJ9+G/wYY=; b=Tz/YjgVBDXpNodXSB6kiwFkCJlhhcscmPnCGZRO5xgMyLiYRCut2C15bvYpO3UYXBp TTRC9Acaaq1AoVrc8knn911w5/Q4kSdB7bM95tif33hf112DqYTvCsIJaR1C5/wsUSig pjHqbSaPalb+gAQ2DiKLHxSj0Wx6TEmMHvaIg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=OCQxVjnRE4sOrmiP4lXaF1nERe9qlxLxHLLUHwCdDn0Whuqly0L6shq4mJS4JeRTC5 /yqhqRfd27N4jnRQK89A26YvpRWRgZFoA35lyLsvHEU12L/U4mcE3R+9fByK/ypoLGgc qmUthq21ptCwDJX0ks8SScD1NcHikLi1J2l6g= Received: by 10.150.1.21 with SMTP id 21mr723139yba.254.1264972309780; Sun, 31 Jan 2010 13:11:49 -0800 (PST) Received: from ?192.168.0.100? (144-174-17-190.fibertel.com.ar [190.17.174.144]) by mx.google.com with ESMTPS id 9sm1486990ywf.35.2010.01.31.13.11.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 31 Jan 2010 13:11:49 -0800 (PST) Sender: Fernando Gont Message-ID: <4B65F205.2080904@gont.com.ar> Date: Sun, 31 Jan 2010 18:11:33 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4B65273D.1030403@gont.com.ar> <4B652E08.8020203@isi.edu> <4B65522E.8060606@gont.com.ar> <4B65D0EA.9040205@isi.edu> In-Reply-To: <4B65D0EA.9040205@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] [Fwd: New Version Notification for draft-ietf-tcpm-icmp-attacks-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 21:11:32 -0000 Joe Touch wrote: > Agreed. Here's a modified version: > > We note that the counter-measures discussed in this document are not > part of standard TCP behavior and this document does not change that > state of affairs. The consensus of the TCPM WG (TCP Maintenance and > Minor Extensions Working Group) was to document this widespread > implementation of nonstandard TCP behavior and neither to change the > TCP standard nor to make any new recommendations herein. "nonstandard TCP behavior" still seems misleading. How about: > We note that the counter-measures discussed in this document are not > part of standard TCP behavior and this document does not change that > state of affairs. The consensus of the TCPM WG (TCP Maintenance and > Minor Extensions Working Group) was to document this widespread > implementation of TCP behavior and neither to change the > TCP standard nor to make any new recommendations herein. ? Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Sun Jan 31 13:33:39 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29503A69C1 for ; Sun, 31 Jan 2010 13:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ+ZgW0HHOci for ; Sun, 31 Jan 2010 13:33:39 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 1C93E3A6838 for ; Sun, 31 Jan 2010 13:33:39 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o0VLXRJ2012379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 31 Jan 2010 13:33:28 -0800 (PST) Message-ID: <4B65F726.4050102@isi.edu> Date: Sun, 31 Jan 2010 13:33:26 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4B65273D.1030403@gont.com.ar> <4B652E08.8020203@isi.edu> <4B65522E.8060606@gont.com.ar> <4B65D0EA.9040205@isi.edu> <4B65F205.2080904@gont.com.ar> In-Reply-To: <4B65F205.2080904@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB7A40A448561A25606FEAECC" X-MailScanner-ID: o0VLXRJ2012379 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] [Fwd: New Version Notification for draft-ietf-tcpm-icmp-attacks-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 21:33:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB7A40A448561A25606FEAECC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Joe Touch wrote: >=20 >> Agreed. Here's a modified version: >> >> We note that the counter-measures discussed in this document are not=20 >> part of standard TCP behavior and this document does not change that=20 >> state of affairs. The consensus of the TCPM WG (TCP Maintenance and=20 >> Minor Extensions Working Group) was to document this widespread=20 >> implementation of nonstandard TCP behavior and neither to change the >> TCP standard nor to make any new recommendations herein. >=20 > "nonstandard TCP behavior" still seems misleading. I only really added "nor to make any new recommendations herein" and change the phrasing (changed 'but' to a 'neither'/'nor' pair). The 'nonstandard' part was from your original text (below, from v10), and I think it's still needed, i.e., I think the above text is preferable= =2E Joe (from v10: We note that the counter-measures discussed in this document are not part of standard TCP behavior and this document does not change that state of affairs. The consensus of the TCPM WG (TCP Maintenance and Minor Extensions Working Group) was to document this widespread implementation of nonstandard TCP behavior but to not change the TCP standard. ) --------------enigB7A40A448561A25606FEAECC 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.9 (MingW32) iEYEARECAAYFAktl9yYACgkQE5f5cImnZrvYFACg+IL5U4LNdn6ZMsOjg3NiAxqK 7hYAnA4HGAshBnkakCTwZ1MRTRtHYPcc =qD4Q -----END PGP SIGNATURE----- --------------enigB7A40A448561A25606FEAECC-- From fernando.gont.netbook.win@gmail.com Sun Jan 31 13:41:19 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2133A6824 for ; Sun, 31 Jan 2010 13:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pB7xZRVrt5qL for ; Sun, 31 Jan 2010 13:41:19 -0800 (PST) Received: from mail-gx0-f169.google.com (mail-gx0-f169.google.com [209.85.217.169]) by core3.amsl.com (Postfix) with ESMTP id CCCF53A6811 for ; Sun, 31 Jan 2010 13:41:18 -0800 (PST) Received: by gxk9 with SMTP id 9so817424gxk.8 for ; Sun, 31 Jan 2010 13:41:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=lZGB5LA/ub5+snecBu/BmuoNkIogmnGbUQ6Z682YdNY=; b=JYNTbrzLWZt0s9mXV7NFcZJ3I8W/SLA7HUhEoGQhOASj+6ojfGgI6oVtiDj42E1IX3 4e/pD+h4duQ89V5l31b7GhD7641HXdDyUUBVOlimUaJzMGYqY4IsB/aF7k7/BLSQACM1 NZIzQiOC71o4KqL4ts3E0apAykjarClLIk4hU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=XJzP02jJ7EwazyWnWR0M7+9mkiirYlIJi/AiwLg+Iwg4N1+nbIAoGj6yggKcENImTX LkE9b+gvO0NAJUht3vJMi7S57LO4SYcMywRM/Jxu8LyDX3XBpCnEUvVmn49hHwHUwID/ k34j9JBZQAGYb4stFuvpfqET7sPRe6NqdREJQ= Received: by 10.101.133.34 with SMTP id k34mr4018969ann.213.1264974107513; Sun, 31 Jan 2010 13:41:47 -0800 (PST) Received: from ?192.168.0.100? (144-174-17-190.fibertel.com.ar [190.17.174.144]) by mx.google.com with ESMTPS id 9sm1487737ywf.20.2010.01.31.13.41.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 31 Jan 2010 13:41:46 -0800 (PST) Sender: Fernando Gont Message-ID: <4B65F90B.9090200@gont.com.ar> Date: Sun, 31 Jan 2010 18:41:31 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4B65273D.1030403@gont.com.ar> <4B652E08.8020203@isi.edu> <4B65522E.8060606@gont.com.ar> <4B65D0EA.9040205@isi.edu> <4B65F205.2080904@gont.com.ar> <4B65F726.4050102@isi.edu> In-Reply-To: <4B65F726.4050102@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] [Fwd: New Version Notification for draft-ietf-tcpm-icmp-attacks-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 21:41:19 -0000 Joe Touch wrote: > I only really added "nor to make any new recommendations herein" and > change the phrasing (changed 'but' to a 'neither'/'nor' pair). > > The 'nonstandard' part was from your original text (below, from v10), > and I think it's still needed, i.e., I think the above text is preferable. Yes and in retrospective I had said (days ago) that the text might be misleading. (e.g. the pmtud fix is not part of the standard, but does not violate it, either) Can anybody else weigh in, please? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Sun Jan 31 15:17:14 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36A13A69CF for ; Sun, 31 Jan 2010 15:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIf20HYla+xc for ; Sun, 31 Jan 2010 15:17:12 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 155E93A690B for ; Sun, 31 Jan 2010 15:17:12 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o0VNHBMe001979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 31 Jan 2010 15:17:12 -0800 (PST) Message-ID: <4B660F77.5030805@isi.edu> Date: Sun, 31 Jan 2010 15:17:11 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tcpm@ietf.org" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig17B31541F699202C54692EBC" X-MailScanner-ID: o0VNHBMe001979 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] TCP-AO 09 posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 23:17:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig17B31541F699202C54692EBC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The following updates have been made to TCP-AO, and a new draft (09) submitted. Hi, all, An updated version (09) of TCP-AO has been submitted. To the WG chairs - please let me know if this version addresses the comments raised. The announcement should appear on the list shortly. Joe --------------------------------------- *) update header/footer to match title, author list Done. *) add an applicability statement Done. See new Section 2.1 *) update the traffic key security strength discussion Done, though this affects the NAT doc (status indicated separately) more than AO. *) addressing connectionless resets See new Section 9.7. *) largely editorial input from Wes, as addressed below. > 1) editorial - in Abstract: > "TCP-AO uses its own option identifier, even though used mutually > exclusive of TCP MD5 on a given TCP connection." > could this just be: > "TCP-AO uses a separate option identifier from TCP MD5 and the > two options are not capable of being used at the same time." Updated, reworded slightly as: "TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously." > 2) editorial, in Figure 1 (section 4.1): > It's probably clear to everyone that the MD5 digest field wraps through= > the remainder of the option length, but could a "..." or "... (cont.)" > be added to the empty areas to make that explicit? The way it's shown > in Figure 2 is nice, I think.' Done. > 3) editorial, in section 5.2: > "derived from the MKT and the properties of a connection. For > established connections, these properties include the socket pair > (local IP address, local TCP port, remote IP address, remote port)," > could be: > "derived from the MKT and the local and remote pairs of IP addresses > and TCP port numbers," Updated as: A traffic key is a key derived from the MKT and the local and remote IP address pairs and TCP port numbers, and, for established connections, the TCP Initial Sequence Numbers (ISNs) in each direction. Segments exchanged before a connection is established use the same information, substituting zero for unknown values (e.g., ISNs not yet coordinated). > 4) technical/editorial in section 5.2: > I think this is just a typo, but to make sure ...: > "A single MKT can be used to derive any of four different MKTs:" > should be: > "A single MKT can be used to derive any of four different traffic keys:= " Yes, fixed as noted. > 5) editorial, in section 7.2: > The heading is "Key Derivation Functions", I think it would be better > as "Traffic Key Derivation Functions", as it doesn't discuss the > derivation of master keys. Done. ----------- --------------enig17B31541F699202C54692EBC 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.9 (MingW32) iEYEARECAAYFAktmD3cACgkQE5f5cImnZruR+gCg9GhzIXIp5dV0Q4RpyQALAqet fxUAn0jdspGIVc8+fPwQS0yCQamYmneh =Syx2 -----END PGP SIGNATURE----- --------------enig17B31541F699202C54692EBC-- From root@core3.amsl.com Sun Jan 31 15:30:03 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 018453A690B; Sun, 31 Jan 2010 15:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100131233003.018453A690B@core3.amsl.com> Date: Sun, 31 Jan 2010 15:30:02 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 23:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : The TCP Authentication Option Author(s) : J. Touch, et al. Filename : draft-ietf-tcpm-tcp-auth-opt-09.txt Pages : 47 Date : 2010-01-31 This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either static master key tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-auth-opt-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-31151631.I-D@ietf.org> --NextPart-- From touch@ISI.EDU Sun Jan 31 15:40:24 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4F53A69D0 for ; Sun, 31 Jan 2010 15:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpNPYnsgfTy9 for ; Sun, 31 Jan 2010 15:40:24 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 216253A68C4 for ; Sun, 31 Jan 2010 15:40:24 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o0VNeLvI005678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 31 Jan 2010 15:40:22 -0800 (PST) Message-ID: <4B6614E5.1040200@isi.edu> Date: Sun, 31 Jan 2010 15:40:21 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tcpm@ietf.org" References: <4B660F77.5030805@isi.edu> In-Reply-To: <4B660F77.5030805@isi.edu> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAB87AA07D1403B64CE503A15" X-MailScanner-ID: o0VNeLvI005678 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] TCP-AO NAT 01 posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 23:40:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAB87AA07D1403B64CE503A15 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI - the NAT extensions doc has also just been updated to address the following: > *) update the traffic key security strength discussion >=20 > Done, though this affects the NAT doc (status indicated separately) mor= e > than AO. Joe --------------enigAB87AA07D1403B64CE503A15 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.9 (MingW32) iEYEARECAAYFAktmFOUACgkQE5f5cImnZruzYwCg2tV4w5NyfZYoftZUXqTXXfoy 0t4AoL7bF5lRVpjBQ0tHngj9+aZusoYq =AOHZ -----END PGP SIGNATURE----- --------------enigAB87AA07D1403B64CE503A15-- From touch@ISI.EDU Sun Jan 31 16:29:04 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA24C3A69F5 for ; Sun, 31 Jan 2010 16:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ekw6y54JCqDz for ; Sun, 31 Jan 2010 16:29:03 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id C51813A67E5 for ; Sun, 31 Jan 2010 16:29:03 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o110SqLf016021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 31 Jan 2010 16:28:53 -0800 (PST) Message-ID: <4B662044.1040505@isi.edu> Date: Sun, 31 Jan 2010 16:28:52 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4B660F77.5030805@isi.edu> In-Reply-To: <4B660F77.5030805@isi.edu> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig64B07904DD50B154464B5CBC" X-MailScanner-ID: o110SqLf016021 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: [tcpm] TCP-AO 10 posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 00:29:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig64B07904DD50B154464B5CBC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Additional updates (sorry I didn't get these in the previous one): - ICMP hard error defaults included (moved out of security considerations, now a new section 9.8) - discuss ISN randomization in more detail This version should include all pending WGLC items. Joe Joe Touch wrote: > The following updates have been made to TCP-AO, and a new draft (09) > submitted. >=20 > Hi, all, >=20 > An updated version (09) of TCP-AO has been submitted. >=20 > To the WG chairs - please let me know if this version addresses the > comments raised. >=20 > The announcement should appear on the list shortly. >=20 > Joe >=20 > --------------------------------------- >=20 > *) update header/footer to match title, author list >=20 > Done. >=20 > *) add an applicability statement >=20 > Done. See new Section 2.1 >=20 > *) update the traffic key security strength discussion >=20 > Done, though this affects the NAT doc (status indicated separately) mor= e > than AO. >=20 > *) addressing connectionless resets >=20 > See new Section 9.7. >=20 > *) largely editorial input from Wes, as addressed below. >=20 >> 1) editorial - in Abstract: >> "TCP-AO uses its own option identifier, even though used mutually >> exclusive of TCP MD5 on a given TCP connection." >> could this just be: >> "TCP-AO uses a separate option identifier from TCP MD5 and the >> two options are not capable of being used at the same time." >=20 > Updated, reworded slightly as: > "TCP-AO uses a different option identifier than TCP MD5, even though > TCP-AO and TCP MD5 are never permitted to be used simultaneously." >=20 >> 2) editorial, in Figure 1 (section 4.1): >> It's probably clear to everyone that the MD5 digest field wraps throug= h >> the remainder of the option length, but could a "..." or "... (cont.)"= >> be added to the empty areas to make that explicit? The way it's shown= >> in Figure 2 is nice, I think.' >=20 > Done. >=20 >> 3) editorial, in section 5.2: >> "derived from the MKT and the properties of a connection. For >> established connections, these properties include the socket pair >> (local IP address, local TCP port, remote IP address, remote port)," >> could be: >> "derived from the MKT and the local and remote pairs of IP addresses >> and TCP port numbers," >=20 > Updated as: >=20 > A traffic key is a key derived from the MKT and the local and remote IP= > address pairs and TCP port numbers, and, for established connections, > the TCP Initial Sequence Numbers (ISNs) in each direction. Segments > exchanged before a connection is established use the same information, > substituting zero for unknown values (e.g., ISNs not yet coordinated). >=20 >> 4) technical/editorial in section 5.2: >> I think this is just a typo, but to make sure ...: >> "A single MKT can be used to derive any of four different MKTs:" >> should be: >> "A single MKT can be used to derive any of four different traffic keys= :" >=20 > Yes, fixed as noted. >=20 >> 5) editorial, in section 7.2: >> The heading is "Key Derivation Functions", I think it would be better >> as "Traffic Key Derivation Functions", as it doesn't discuss the >> derivation of master keys. >=20 > Done. >=20 > ----------- >=20 >=20 --------------enig64B07904DD50B154464B5CBC 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.9 (MingW32) iEYEARECAAYFAktmIEQACgkQE5f5cImnZrsxJACdEsJ2Q0UTcgKMcNXbpSWlzBem c9YAnRrE8tZA14ra2oTiPEWC0yZr6UdL =ioOc -----END PGP SIGNATURE----- --------------enig64B07904DD50B154464B5CBC-- From root@core3.amsl.com Sun Jan 31 16:45:02 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 480A93A69F7; Sun, 31 Jan 2010 16:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100201004502.480A93A69F7@core3.amsl.com> Date: Sun, 31 Jan 2010 16:45:02 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 00:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : The TCP Authentication Option Author(s) : J. Touch, et al. Filename : draft-ietf-tcpm-tcp-auth-opt-10.txt Pages : 47 Date : 2010-01-31 This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either static master key tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-auth-opt-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-31163825.I-D@ietf.org> --NextPart-- From wesley.m.eddy@nasa.gov Sun Jan 31 16:59:52 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64993A69E3 for ; Sun, 31 Jan 2010 16:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gd7rIWtIRWJ for ; Sun, 31 Jan 2010 16:59:52 -0800 (PST) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id DDA2E3A687C for ; Sun, 31 Jan 2010 16:59:51 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id DCA142D8271; Sun, 31 Jan 2010 19:00:23 -0600 (CST) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o1110Nu6024816; Sun, 31 Jan 2010 19:00:23 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Sun, 31 Jan 2010 19:00:23 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Fernando Gont , Joe Touch Date: Sun, 31 Jan 2010 19:00:23 -0600 Thread-Topic: [tcpm] [Fwd: New Version Notification for draft-ietf-tcpm-icmp-attacks-10] Thread-Index: AcqivjVSXe9Va72uRdSAnwBFvWVsdQAGsVhs Message-ID: References: <4B65273D.1030403@gont.com.ar> <4B652E08.8020203@isi.edu> <4B65522E.8060606@gont.com.ar> <4B65D0EA.9040205@isi.edu> <4B65F205.2080904@gont.com.ar> <4B65F726.4050102@isi.edu>,<4B65F90B.9090200@gont.com.ar> In-Reply-To: <4B65F90B.9090200@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-01-29_10:2010-01-20, 2010-01-29, 2010-01-29 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] [Fwd: New Version Notification for draft-ietf-tcpm-icmp-attacks-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 00:59:52 -0000 I think it's okay to leave the "nonstandard" word out, as it seems that the= re's sufficient other text that's clear about the status of the behavior de= scribed. That said, I don't feel strongly about it, but am just throwing 2 cents in. ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Fernando G= ont [fernando@gont.com.ar] Sent: Sunday, January 31, 2010 4:41 PM To: Joe Touch Cc: tcpm@ietf.org Subject: Re: [tcpm] [Fwd: New Version Notification for draft-ietf-= tcpm-icmp-attacks-10] Joe Touch wrote: > I only really added "nor to make any new recommendations herein" and > change the phrasing (changed 'but' to a 'neither'/'nor' pair). > > The 'nonstandard' part was from your original text (below, from v10), > and I think it's still needed, i.e., I think the above text is preferable= . Yes and in retrospective I had said (days ago) that the text might be misleading. (e.g. the pmtud fix is not part of the standard, but does not violate it, either) Can anybody else weigh in, please? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm= From pekkas@netcore.fi Sun Jan 31 23:19:22 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5353A6359 for ; Sun, 31 Jan 2010 23:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTf2sBuAuFoK for ; Sun, 31 Jan 2010 23:19:21 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 8438C3A677C for ; Sun, 31 Jan 2010 23:19:20 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id o117JoWi014931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Feb 2010 09:19:50 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id o117Jorq014928 for ; Mon, 1 Feb 2010 09:19:50 +0200 Date: Mon, 1 Feb 2010 09:19:50 +0200 (EET) From: Pekka Savola To: tcpm@ietf.org In-Reply-To: <4B6308DE.7050508@gont.com.ar> Message-ID: References: <201001290029.BAA11165@TR-Sys.de> <5E266815-608E-49E9-9398-418B9890EA15@nokia.com> <0C53DCFB700D144284A584F54711EC5808CD6088@xmb-sjc-21c.amer.cisco.com> <4B6308DE.7050508@gont.com.ar> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.95.3 at otso.netcore.fi X-Virus-Status: Clean Subject: Re: [tcpm] your responses to my comments on "the WG" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 07:19:22 -0000 >> I fully tend to agree with Alfred's email sub-section titled "the WG". +1 (Wrt draft-ietf-tcpm-icmp-attacks-10, I prefer to leave out 'nonstandard' but I'm saving paper by sending just one mail. ;-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings